Историята

Така че вие ​​и вашият съосновател имате тази страхотна бизнес идея, нали?

Добавяте функции в главата си.

Често питате потенциалните клиенти за мнението им и те всички го обичат.

Добре, значи хората го искат. Има дори малко пари за правене. И единствената причина да не могат да го получат е, че все още не сте ги внедрили.

След това най-накрая седнете един ден и кажете 'Нека го направим!' Скоро се опитвате да разберете как да приложите бизнес логиката на приложението си, убийствената функционалност, която ще насочи продукта напред - имате идея как да го направите и сега знаете, че можете да го направите.

какво е пробна структура от данни

'Готово! Работи!' ти каза. Вашето доказателство за концепция е успех! Остава само да го опаковате в уеб приложение.

„Добре, нека направим сайта“, казвате вие.

И тогава осъзнавате истината: трябва да изберете език за програмиране; трябва да изберете платформа (модерна); трябва да изберете някои (модерни) рамки; трябва да конфигурирате (и да купите) доставчици на пространство, база данни и хостинг; имате нужда от административен интерфейс; имате нужда от система за разрешения; имате нужда от диспечер на съдържание.

Искате да сте лаконични, искате да бъдете пъргави. Искате да използвате технологии, които ще ви помогнат да постигнете успех в краткосрочен и дългосрочен план. И те не винаги са лесни за избор

Предстоят ви десетки и десетки архитектурни решения. И вие искате да вземете правилните: искате да използвате технологии, които ви позволяват бързо развитие, постоянна итерация, максимална ефективност, скорост, здравина и други. Искате да сте лаконични, искате да бъдете пъргави. Искате да използвате технологии, които ще ви помогнат да постигнете успех в краткосрочен и дългосрочен план. И те не винаги са лесни за избор.

„Съкрушен съм“, казвате, докато си отивате, чувствайки се съкрушени. Вашата енергия не е същата като преди. Опитвате се да съберете парчетата, но това е твърде много работа.

Вашето доказателство за концепцията изсъхва и бавно умира.

Предложението

След като изоставих тонове идеи по този начин, реших да проектирам решение. Аз го наричам проект ' В него '(Начало) (или init.js).

Сърцевината на идеята е да има един проект, който да стартира всички останали, да позволи на разработчика или техническия основател да вземе тези решения едновременно и да получи подходящ шаблон, за да започне въз основа на тези решения. Знам какво ще кажат недоволните: „Едно решение не може да се приложи за всички проблеми“ (Мразещите ще мразят). И може да са прави. Но ние можем да опитаме всичко възможно, за да създадем грубо решение и аз мисля В него е достатъчно близо.

За да постигнем по-добре тази цел, трябва да имаме предвид няколко ключови идеи. Когато разработвах Init, обмислях:

• Компоненти

  Модуларизацията е ключова характеристика на всяка система, тъй като ви позволява да използвате повторно софтуерни компоненти в различни проекти - което е основната цел на В него . Но модуларизацията идва и с „заменяемост“ по продукт, което ще бъде нашият най-добър съюзник, когато става въпрос за атакуване на различни видове проблеми с „почти“ едно и също решение.

• Лесно развитие

  За някои проблеми някъде има написано по-добро решение [Brainf * ck] (https://en.wikipedia.org/wiki/Brainfuck). или майната на мозъка). Но внедрете това решение (в Brainf * uck ) би било почти невъзможно да се пише, камо ли да се чете. Това би ви коствало време и огромни усилия. Като цяло трябва да използвате езици и платформи, които улесняват разработването и не са трудни за вас (или някой, който може да работи с него по-късно).

• Общност

  Каквато и платформа да изберете, уверете се, че има страхотна общност и такава, която може да ви помогне при най-често срещаните проблеми и тези, които не са толкова често срещани. Запомнете: jQuery може да не е най-много бързо , повечето чисти , или най-фантастичният - но той е победител само заради неговата общност .

Имайки предвид тези цели, ще ви покажа как взех собствените си решения при създаването В него .

В основата си Init се възползва от „ пълен стек JavaScript (Някои хора го наричат ​​или част от него като СРЕДСТВО стека ). Когато работите с този комплект, В него той може да използва само един език, като същевременно създава невероятно гъвкава и пълнофункционална среда за разработване на уеб приложения. В обобщение, В него ви позволява да използвате JavaScript не само за разработване от страна на клиент и сървър, но и за изграждане, тестване, оформление и др.

Но нека забавим малко и се запитаме: наистина ли е добра идея JavaScript?

Защо избрах JavaScript

От 1998 г. съм уеб разработчик. По това време използвахме Perl за по-голямата част от нашето сървърно развитие и дори тогава имахме клиентски JavaScript. Оттогава сървърните уеб технологии се промениха изключително много - преминахме през вълна след вълна от различни технологии и езици като PHP, ASP, JSP, .NET, Ruby, Python, само за да назовем само няколко. Разработчиците започнаха да осъзнават, че използването на два различни езика за клиентска и сървърна среда усложнява нещата. Първоначалните опити за обединяване под един език се опитваха да създадат клиентски компоненти от страна на сървъра и да ги компилират в JavaScript. Това не работеше според очакванията и много от тези проекти се провалиха (например подмяна на ASP MVC ASP.NET уеб формуляри , и може да се каже, че GWT ще бъде заменен от Полимер ). в близко бъдеще). Но това беше отлична идея, по същество: един език на клиента и сървъра, който ни позволява да използваме повторно компоненти и ресурси (това е ключът: ресурси ).

Отговорът беше прост: използвайте JavaScript на сървъра.

Всъщност JavaScript се роди с Сървърна страна на JavaScript на Netscape Enterprise Server, но по това време езикът просто не беше готов. След години на проби и грешки, Node.js в крайна сметка се появи, което не само постави JavaScript на сървъра, но и популяризира идеята за неблокиращо програмиране , променяйки начина, по който пишем „fread“ (I / O) завинаги (прочетете повече тук .

В изречение: неблокиращият график има за цел да остави настрана отнемащите време задачи, като обикновено се посочва какво трябва да се направи, след като тези задачи са изпълнени, и позволява на процесора да обработва междувременно други заявки.

Но тези идеи не бяха нови - така че защо станаха толкова популярни сред Node.js? Просто, неблокиращо програмиране може да бъде постигнато по различни начини. Може би най-лесно е да се използват обратни обаждания и a цикъл събитие . В повечето езици това не е лесна задача: докато „обратните обаждания“ са често срещана характеристика на някои езици, циклично събитие не е и обикновено се оказвате, че се придържате към външни библиотеки (например: Python, с Twister ). Но в JavaScript, обратно извикване са вградени в езика, както и цикъла на събитията и почти всеки програмист, който е използвал JavaScript, е запознат с тях (или поне ги е използвал, въпреки че не разбирам напълно какво означава циклично събитие ). Изведнъж всеки от стартиращите компании на Planet Earth може да използва повторно разработчиците (напр. Ресурси) както от страна на клиента, така и от страна на сървъра, решавайки проблемът 'Guru Python Needed' .

Изведнъж всяко стартиране на Planet Earth може да използва повторно разработчиците (напр. Ресурси) както от страна на клиента, така и от страна на сървъра, решавайки проблема с „Python Guru Needed“.

Така че сега имаме невероятно бърза платформа (благодарение на неблокиращо програмиране) с език за програмиране, който е невероятно лесен за използване (благодарение на JavaScript). Но достатъчно ли е? Ще продължи ли? Сигурен съм, че JavaScript ще има важно място в бъдеще. Нека ви кажа защо:

• Функционално програмиране

  JavaScript беше първият език за програмиране, който ръководи функционалната парадигма за масите (разбира се Lisp е на първо място, но повечето разработчици никога не са изграждали приложение на Lisp, готово за производствена употреба). Лисп и аз, Основни влияния на Javascript , те са пълни с иновативни идеи. Тези идеи могат да освободят съзнанието ни да изследва нови техники, модели и парадигми. И всички те водят до JavaScript. Виж монади , Църковно кодиране , или дори (за по-практичен пример) колекцията от функции] (http://underscorejs.org/#collections), от Underscore.js което може да ви спести редове и редове код.

• Динамични обекти и прототипно наследяване

  Безкласовото обектно-ориентирано програмиране (и без безкрайните наследства на класове) позволява бързо развитие (създаване на обекти, добавяне на методи и използване на тях), но най-важното е, че намалява времето за рефакторинг по време на задачи по поддръжката, като позволява на разработчика да модифицира екземпляри на обекти вместо класове. Тази скорост и гъвкавост проправя пътя за бързо развитие.

• JavaScript го интернет

  JavaScript беше предназначен за интернет , е тук от самото начало и няма да си тръгне . Всички опити за унищожаването му са неуспешни, вижте например падането на Аплети Java , заместването на VBScript за Microsoft, TypeScript (който се компилира в JavaScript) и падането на Flash в ръцете на мобилния пазар и HTML5. Невъзможно е да се замени Javascript, без да се разбият милиони уеб страници, така че нашата дългосрочна цел трябва да бъде да го подобрим. И няма по-добър за тази задача от Технически комитет 39 от ECMA.

  Добре, алтернативи на JavaScript се раждат всеки ден, как CoffeeScript , TypeScript , и милионите езици, които се компилират в JavaScript . Тези алтернативи могат да бъдат полезни за етапи на развитие (чрез сопоставяне на изходния код ), но те няма да успеят да се представят за JavaScript в дългосрочен план по две причини: техните общности никога няма да бъдат по-големи и най-добрата им функционалност ще бъде възприета от скрипта на ECMA (например JavaScript). JavaScript не е като асемблерен език: това е език за програмиране на високо ниво с изходен код, който можете да разберете - тогава трябва да разберете.

Сега, благодарение на Проект Esprima , можете да създадете свои собствени инструменти за игра с изходния код, да го модифицирате, да промените стила му, да добавите коментари, инструментариум и всякакви неща, които можете да си представите, когато играете с абстрактното синтаксисно дърво на вашата програма, сякаш играете с DOM дърво.

JavaScript от край до край: Node.js и MongoDB

Така че това са причините да използвате JavaScript. Сега ще използвам JavaScript като причина да използвам Node.js и MongoDB.

• Node.js

  Node.js е платформа за изграждане на бързи и мащабируеми мрежови приложения - това основно казва сайта Node.js. Но Node.js е нещо повече от това: това е предпочитаното време за изпълнение за всяко приложение с достъп до I / O на JavaScript. Дори и да не планирате да пишете основното си сървърно приложение с Node.js, можете да използвате вградени инструменти, изградени върху Node.js, за да подобрите процеса си на разработка. Например: Mocha.js за модулно тестване, Grunt.js за автоматизирани строителни задачи или дори Скоби за да завършите редактирането на код.

  Така че, ако ще пишете сървърни или клиентски JavaScript приложения, трябва да се запознаете с Node.js, защото ще трябва да го използвате ежедневно. Има някои интересни алтернативи ), но никой от тях не достига дори 10% от общността на Node.js.

  за какво е полезно c

• MongoDB

  MongoDB това е база данни NoSQL въз основа на документи, които използват JavaScript като език за заявки, което позволява завършване на завършването на платформата JavaScript. Но това дори не е основната причина за избора на тази база данни.

  MongoDB е база данни без схема което позволява на вашите обекти да продължат по гъвкав начин и следователно да се адаптират по-бързо към променящите се изисквания. Освен това е силно мащабируема Y. въз основа на map-reduce , което го прави подходящ за интензивни приложения. MongoDB е толкова гъвкав, че може да се използва като база данни без схеми, хранилище на релационни данни (въпреки че липсва транзакции ), или дори съхранение ключ-стойност за кеширани отговори.

Модуларизация на сървъра с Express.js

Модуларизацията от страна на сървъра никога не е лесна. Но със Express.js (Y Connect.js ) дойде идеята за „Междинен софтуер“ (или мидълуер). Според мен междинният софтуер е най-добрият начин за дефиниране на компоненти на сървъра. Ако искате да го сравните с известен стандарт, той се доближава доста до тръбите и филтрите.

Основната идея е, че вашият компонент е част от тръба. Конвейерът обработва заявката (вход) и генерира отговор (изход), но вашият компонент не носи отговорност за пълния отговор. Вместо това просто модифицирате това, от което се нуждаете, и след това делегирате на другото парче тръба. Когато последното парче тръба завърши своя процес, отговорът се изпраща на клиента.

Ние наричаме тези „тръбни парчета“ като „междинен софтуер“. Ясно е, че можем да създадем два вида междинен софтуер :

как да използвам node js

• Междинен : Тези, които обработват заявката и отговора, но не са изцяло отговорни за самия отговор, така че те делегират на следващия междинен софтуер.

• Финали : Тези, които поемат пълната отговорност в крайния отговор. Те обработват и модифицират заявката и отговора, но не е необходимо да делегират на следващия междинен софтуер. На практика се препоръчва да делегирате така или иначе следващ междинен софтуер, за да се позволи гъвкавост в архитектурата (напр. Добавяне на още мидълуер по-късно), дори ако този междинен софтуер не съществува (в този случай отговорът ще отиде директно на клиента)

Като конкретен пример разгледайте компонент „потребител на администратор“ на сървъра. По отношение на междинния софтуер ще имаме както крайни точки, така и посредници. В нашия край ще имаме функции като създаване на потребител и изброяване на потребители. Но преди да можем да извършим тези действия, се нуждаем от нашите посредници за удостоверяване (тъй като не искаме заявки за създаване на неудостоверени потребители). След като създадем тези брокери за удостоверяване, можем просто да ги включим навсякъде, където искаме да превърнем съществуваща функция за неудостоверяване в такава с удостоверяване.

Приложения на една страница

Проектът В него съсредоточете се върху създаването приложения на една страница (SPA-приложения на една страница) . Много уеб разработчици са били изкушавани повече от веднъж да опитат да изградят SPA. Разработих с помощта на няколко (предимно собственически) и мога уверено да кажа, че те просто са бъдещето на уеб приложенията. Случвало ли ви се е да сравнявате SPA със стандартно уеб приложение на мобилна връзка? Разликата в отговора е десетки секунди.

Случвало ли ви се е да сравнявате SPA с редовно уеб приложение на мобилна връзка? Разликата в отговора е десетки секунди.

СПА са бъдещето на мрежата - така че защо бихте направили продукта си в стара форма? Чест аргумент, който чувам, е, че хората са загрижени за SEO. Но ако се справяте правилно с нещата, това не би трябвало да е проблем: самият Google има много добър урок за това как да го направя и има много добри коментари тук също.

Клиентски MV * с Backbone.js, Marionette.js и Twitter Bootstrap

За много е казано MVC * рамки за SPAs . Това е сложно решение, но ще кажа, че първите 3 са Backbone.js , Ember.js , Y Angular.js .

И трите са добре оценени. Но кой от тях е най-добрият за вас?

За съжаление трябва да призная, че имам много ограничен опит с Angular.js, така че ще го оставя извън тази дискусия. Сега Ember.js и Backbone.js представляват два различни начина за атака на един и същ проблем.

Backbone.js тя е минималистична, опростена и ви предлага достатъчно, за да създадете просто SPA. От друга страна, Ember.js е напълно професионална рамка за създаване на SPA. Той има повече извивки, но и по-голяма крива на обучение.

В зависимост от размера на вашето приложение, решението може да бъде толкова лесно, колкото да се разгледа съотношението на използвани / налични функции, което ще ви даде чудесна подсказка.

В случай че В него , Исках да обхвана повечето сценарии, затова избрах Backbone.js за лесно създаване на SPA, с Backbone.Marionette.View за модуларизация. По този начин всеки компонент е просто приложение и крайното приложение може да бъде толкова сложно, колкото ние искаме да бъде.

Стилът също е предизвикателство, но отново можем да имаме рамки, които да ни спасят. За CSS няма нищо по-добро от Twitter Bootstrap , който предлага пълен набор от стилове, които са готови за използване и са лесен за персонализиране .

Booststrap е създаден с помощта на езика ПО-МАЛКО който е с отворен код, така че можем да го модифицираме, ако имаме нужда от него. Предлага се с много контроли за използваемост, които са добре документирани на сайта Bootstrap . Освен това има a модел за персонализиране което ви позволява да създавате свои собствени контроли. Той определено е човекът за тази работа.

Най-добри практики: Grunt.js, Mocha.js, Chai.js, RequireJS и CoverJS

И накрая, трябва да дефинираме някои от нашите най-добри практики и да разгледаме как Init може да ви помогне да ги внедрите и поддържате. Нашето решение е фокусирано върху няколко инструмента, които са базирани на Node.js.

• Mocha.js и Chai.js :

  Тези инструменти ви позволяват да подобрите процеса си на разработка, като кандидатствате TDD или BDD , предоставяйки инфраструктура за организиране на вашите модулни тестове и стартер, който да ги изпълнява автоматично.

  Има Хиляди на рамки за модулни тестове за JavaScript. И така, защо да използваме Mocha.js? Кратък отговор: той е гъвкав и изчерпателен.

  Дългият отговор: той има две важни характеристики (интерфейси, репортери) и едно важно отсъствие ( твърдения ). Нека обясня.

  • Интерфейси : Може би сте свикнали с TDD концепции за апартаменти и модулни тестове, или може би предпочитате BDD идеи за спецификации на поведението с „ описва 'Y' трябва ”. Mocha.js ви позволява да използвате и двата подхода.
  • Репортери Изпълнението на теста ще генерира отчети за резултатите и можете да форматирате тези резултати с помощта на различни репортери. Например, ако трябва да подадете сървър за непрекъсната интеграция, можете да намерите репортер, който да направи точно това.
  • Липса на библиотека от твърдения :: далеч не е проблем, Mocha.js е създаден, за да ви позволи да използвате библиотеката на твърдения по ваш избор, предлагайки по-голяма гъвкавост. Има Много опции , но там Chai.js влиза в игра.

  Chai.js е гъвкава библиотека за твърдения, която ви позволява да използвате всеки от трите най-важни стила на твърдения:

  • Утвърждавайте : Класически стил на твърдение за старо училище. Пример:

    assert.equal(variable, ”valor”);

  • Очаквам : Най-често използваният верижен тип твърдение в BDD. Пример:

    expect(variable).to.equal(“valor”);

  • Трябва : Използва се и в BDD, но предпочитам Expect, защото трябва, защото звучи повтарящо се със спецификацията на поведение _'it _ ('трябва да направи нещо ..' - 'което трябва да направи нещо'). Пример:

    variable.should.equal(“valor”);

  Chai.js се съчетава перфектно с Mocha.js. Използвайки само тези две библиотеки, можете да напишете тестовете си в TDD, BDD или друг стил, който можете да си представите.

• Grunt.js :

  Grunt.js ви позволява да автоматизирате задачи за изграждане, всичко от прости копирани и поставени конкатенирани файлове, до предварително компилирани шаблони, компилиран езиков стил (напр. SASS и LESS), модулно тестване (с mocha.js), свързване и компресиране на код (напр. С UglifyJS или Съставител за затваряне ). Можете да добавите своя собствена автоматизирана задача към Grunt или да търсите в рохкане дневник , където има налични стотици и стотици плъгини (отново използването на инструменти с големи общности се плаща добре). Grunt също може наблюдавайте вашите файлове и задействат действия, когато са модифицирани.

• Изисква JS :

  RequireJS може да звучи като друг начин за зареждане на модули с AMD , но мога да ви уверя, че е много повече от това. За да разберем защо, първо трябва да споменем идеята за пространство на имената на модулите (напр. Demo.views.hello), което избягва замърсяването на глобалното пространство от имена чрез обвиване на всеки модул в собствено пространство от имена. Проблемът е, че тези модули не могат да се използват повторно: ако модифицирате пространството от имена на „екземпляр“, вие модифицирате пространството на имената на всички „екземпляри“. За разлика от това, RequireJS ви позволява да дефинирате модули за многократна употреба от нулата. (Също така, това ще ви помогне да осиновите Инжектиране на зависимост за предотвратяване на достъпа на модулите до глобални променливи ).

  заглавен файл в C++

• CoverJS :

  Покритие на кода това е метрична мярка за оценка на вашето тестване. Както подсказва името, той ви казва колко код е обхванат в текущия ви тестов пакет. CoverJS измерва покритието на кодовете на вашите тестове чрез измерване на изявления (вместо редове код като JSCПокритие ) и генериране на инструментирана версия на вашия код. Той също така генерира отчети за захранване на вашия сървър непрекъсната интеграция .

Използване на _Branches_ (_ramas_) за превключване на функции

Когато започнах В него , Имах нужда от начин потребителите да включват и изключват различни функции, които биха могли да пожелаят в своя проект. Реших да предприема радикален подход със системата за разклоняване на git, за да приложа тази функционалност.

По същество всеки клон представлява функция или функционалност, които потребителят може да иска да включи. Ако стартирате проект от нулата, започнете с минималния клон, от който се нуждаете, и след това добавете други технологии, като обедините клона с другите желани. Да предположим например, че искате да стартирате проекта си с Backbone.js и Marionette.js. Е, можете да започнете от клона на Backbone.js и да го обедините с клона на Marionette, като продължите от там за всяка функционалност, която искате да добавите.

Засега идеята за сливане за добавяне на функционалност може да се използва само за технологични шаблони (например Backbone, Node, Express). Но в бъдеще ще можете да превключвате между back-end (например от MongoDB към Postgres) и клиентски внедрения.

Започнете проект с Init и разположете на Heroku днес

Никога не е имало по-лесен начин за стартиране на проект. Отидете на Хранилище на GitHub , проверете клона с най-новите фиксирания (в момента това е потребителски мениджър, въпреки че това може да се промени в бъдеще) и след това:

1. Създайте директория за вашия проект (или използвайте съществуваща).
2. Създайте своето хранилище с 'git init' (или използвайте съществуващо хранилище)

3. Добавете отдалечен сървър с Init

   git remote add init git: //github.com/picanteverde/init.git

4. Изтеглете клона, който искате

   git pull init usermanager

5. Вземете файла с процеса Heroku

   git pull init heroku-webprocess

6. С Heroku Toolbelt инсталиран, създайте приложение

   heroku create

7. Натиснете главния клон до Heroku

   git push heroku master
8. Посетете приложението си, работещо на Heroku!

Сега можете да започнете да разработвате функцията си за убийство само с няколко реда код. Не само това, но вие ще се развивате с най-новите и най-ефективни технологии в пакет за разработка, който е възможно най-автоматизиран.

Надявам се, че можете да използвате В него за да започнете следващата си страхотна идея. Не забравяйте да проверите хранилището на Init за корекции и функции - разработката му е доста активна и се радвам да чуя вашите отзиви.

Съдържание преведено от Пабло Фабрегат, член на TransBunko , пазар за технически преводи.