console.time('삽입정렬'); // console.log(sort(tgArr)); sort(tgArr) console.timeEnd('삽입정렬'); function mergeSort(arr){ if(arr.length < 2) return arr; var mdl = Math.floor(arr.length/2); var left = arr.slice(0, mdl); var right = arr.slice(mdl, arr.length); return merge(mergeSort(left), mergeSort(right)); }
function merge(left, right){ var result = []; while(left.length && right.length){ if(left[0]<=right[0]){ result.push(left.shift()); }else{ result.push(right.shift()); } } while (left.length) result.push(left.shift()); // 어느 한 배열이 더 많이 남았다면 나머지를 다 넣어줍니다. while (right.length) result.push(right.shift()); // 오른쪽도 마찬가지 return result; } console.time('합병정렬'); // console.log(mergeSort(tgArr)); mergeSort(tgArr) console.timeEnd('합병정렬'); function selectSort(arr){ var result = []; while(arr.length){ var min = Math.min.apply(null, arr); var minIdx = arr.indexOf(min); result.push(min); arr.splice(minIdx,1); }
설명한다면? 어떻게 해야되지?… 어렵네요.. 적어봅니다.읽기 전 참고사항 - 저는 잡스러운 개발자(조금씩 어려분야)이지만, iOS 개발을 메인으로 하고 있습니다. 모바일 개발자 입장에서 MVC에 대한 내용을 작성되었을 것 입니다. 😓 - 마지막에 요약한 내용을 작성해 두었습니다.
MVC는Model-View-Controller의 약자입니다.
개발 할 때, 3가지 형태로 역할을 나누어 개발하는 방법론입니다.
비지니스 처리 로직과 사용자 인터페이스 요소를 분리시켜 서로 영향없이 개발 하기 수월하다는 장점이 있습니다.
Model
* 모델은클라이언트에 노출되지 않습니다. * 연산처리및DB가 주 된 목적입니다. * 컨트롤에서 요청이 들어오면 해당 연산처리 후정보를 return 합니다.
Controller
* 사용자의 요청을 받고 응답을 조종합니다. * View 요청 --> Model 연산 --> 가공된 데이터 --> View 응답 이 과정이 컨트롤에서 전부 이루어집니다.
* nodejs에서 app.post/app.get/route.post/route.get
View
* 클라이언트에 나타나는 부분입니다. * HTML / CSS / Javascript 등으로 꾸미고 , 움직이고, 표현하는게 가능합니다.
화면에 무엇인가를보여주기 위한 역활을 합니다. 컨트롤러 하위에 종속되어, 모델이나 컨트롤러가 보여주려고 하는 모든 필요한 것들을 보여줄 것입니다. 그리고 사용자의 입력을 받아서 모델의 데이터를 업데이트를 합니다.
그리고 Controller는 Model과 View가 각각 무엇을 해야 할 지를 알고 있고, 통제합니다. 비지니스 로직을 처리하는 Model과 완전히 UI에 의존적인 View가 서로 직접 이야기 할 수 없게 합니다.
MVC의 한계
MVC에서 View는 Controller에 연결되어 화면을 구성하는 단위요소이므로 다수의 View들을 가질 수 있습니다. 그리고 Model은 Controller를 통해서 View와 연결되어지지만, 이렇게 Controller를 통해서 하나의 View에 연결될 수 있는 Model도 여러개가 될 수 있습니다.
뷰와 모델이 서로 의존성을 띄게 됩니다.
즉, 화면에 복잡한 화면과 데이터의 구성 필요한 구성이라면, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 생길 수 있습니다.
MVC가 너무 복잡하고 비대해져서, 새 기능을 추가할때마다 크고 작은 문제점을 가지고 소드 분석이나 테스트도 어렵죠. 이런 형태의 MVC를
MassiveViewController (대규모 MVC 어플리케이션)
라고 부릅니다. MVC의 한계를 표현한 용어 인 것 같습니다.
대부분의 사람들(당연히 저도 포함)은 MVC를 구성할 때, View와 Model을 중재하는 Controller를 작성하면 Controller의 비중이 크지 않을 것으로 생각했지만, 복잡한 화면을 구현하게 되면 대규모 MVC 어플리케이션 형태로 구현하게 되었습니다.
Controller는 View와 라이프 사이클과 강하게 연결되어있어서 분리할 수도 없고, 코드 분석/수정과 테스트가 모두 힘들어지죠. 그리고 복잡하게 엮어있는 모델과 뷰는 여러 Side-Effect를 불러와서 프로그램 운영을 힘들게 하지요.
요약하자면.. MVC는 Model-View-Controller의 약자입니다. 개발할 때 3가지 형태로 구분하여 개발하는 소프트웨어 개발 방법론입니다.그 3가지 요소를 설명하면
Model은 무엇을 할지 정의합니다. 비지니스 로직에서의 알고리즘, 데이터 등의 기능을 처합니다. Controller는 어떻게 할지를 정의합니다. 화면의 처리기능과 Model과 View를 연결시켜주는 역할을 하지요. View는 화면을 보여주는 역활을 하지요. 웹이라면 웹페이지, 모바일이라면 어플의 화면의 보여지는 부분입니다.
MVC는 복잡한 대규모 프로그램을 개발을 하게 되면서 문제점이 확인되었습니다.다수의 View와 Model이 Controller를 통해 복잡하게 연결될 수 있기 때문에 Controller가 뚱뚱해지게 되는 Massive ViewController(대규모 MVC 어플리케이션)가 되어버립니다.View와 Controller가 라이브사이클에 강하게 연결되어있고, 더불어 Controller를 통해 View와 Model간에도 관계가 복잡하게 연결되어있어서 수정시 테스트가 힘들고, 파악이 어렵기 때문에 여러 Side-Effect를 불러오게 되는 문제점이 있습니다.그래서 MVC는 위 문제점을 해결하기 위해 여러 페러다임을 수용한 다양한 패턴을 파생시켰습니다.
A function's last parameter can be prefixed with ... which will cause all remaining (user supplied) arguments to be placed within a "standard" javascript array. Only the last parameter can be a "rest parameter".
Difference between rest parameters and the arguments objectSection
There are three main differences between rest parameters and the arguments object:
rest parameters are only the ones that haven't been given a separate name (i.e. formally defined in function expression), while the arguments object contains all arguments passed to the function;
the arguments object is not a real array, while rest parameters are Array instances, meaning methods like sort, map, forEach or pop can be applied on it directly;
the arguments object has additional functionality specific to itself (like the calleeproperty).
Rest parameters have been introduced to reduce the boilerplate code that was induced by the arguments
// Before rest parameters, "arguments" could be converted to a normal array using:functionf(a, b){var normalArray = Array.prototype.slice.call(arguments);// -- or --var normalArray =[].slice.call(arguments);// -- or --var normalArray = Array.from(arguments);var first = normalArray.shift();// OK, gives the first argumentvar first = arguments.shift();// ERROR (arguments is not a normal array)}// Now we can easily gain access to a normal array using a rest parameterfunctionf(...args){var normalArray = args;var first = normalArray.shift();// OK, gives the first argument}
In this example, the first argument is mapped to "a" and the second to "b", so these named arguments are used like normal. However the third argument "manyMoreArgs" will be an array that contains the 3rd, 4th, 5th, 6th ... nth -- as many arguments that the user includes.
In the next example, a rest parameter is used to collect all arguments after the first one in an array. Each one of them is then multiplied by the first parameter and the array is returned:
Array methods can be used on rest parameters, but not on the arguments object:
functionsortRestArgs(...theArgs){var sortedArgs = theArgs.sort();return sortedArgs;}
console.log(sortRestArgs(5,3,7,1));// 1, 3, 5, 7functionsortArguments(){var sortedArgs = arguments.sort();return sortedArgs;// this will never happen}
console.log(sortArguments(5,3,7,1));// TypeError (arguments.sort is not a function)
To use Array methods on the arguments object, it must be converted to a real array first.
Store.js has been around since 2010 (first commit! HN discussion!), and is live on tens of thousands of websites - like cnn.com!
For many years v1.x provided basic cross-browser persistent storage, and over time more and more people started asking for additional functionality.
Store.js version 2 is a full revamp with pluggable storage (it will automatically fall back to one that works in every scenario by default), pluggable extra functionality (like expirations, default values, common array/object operations, etc), and fully cross-browser automatic testing using saucelabs.com.
Basic Usage
All you need to know to get started:
API
store.js exposes a simple API for cross-browser local storage:
// Store current user
store.set('user',{ name:'Marcus'})
// Get current user
store.get('user')
// Remove current user
store.remove('user')
// Clear all keys
store.clearAll()
// Loop over all stored values
store.each(function(value,key){
console.log(key,'==', value)
})
Installation
Using npm:
// Example store.js usage with npm
var store =require('store')
store.set('user',{ name:'Marcus'})
store.get('user').name=='Marcus'
Using script tag (first download one of the builds):
To support all browsers (including IE 6, IE 7, Firefox 4, etc.), use require('store') (alias for require('store/dist/store.legacy')) or store.legacy.min.js.
To save some kilobytes but still support all modern browsers, use require('store/dist/store.modern') or store.modern.min.js instead.
If you're using script tags, you can either use store.everything.min.js (which has all plugins built-in), or clone this repo to add or modify a build and run make build.
Write your own plugin
A store.js plugin is a function that returns an object that gets added to the store. If any of the plugin functions overrides existing functions, the plugin function can still call the original function using the first argument (super_fn).
// Example plugin that stores a version history of every value
Each storage has different limits, restrictions and overflow behavior on different browser. For example, Android has has a 4.57M localStorage limit in 4.0, a 2.49M limit in 4.1, and a 4.98M limit in 4.2... Yeah.
To simplify things we provide these recommendations to ensure cross browser behavior:
