Историята

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Компоненти

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

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

  Някакъв проблем, някъде има решение, написано най-добре Brainf * ck . Но прилагането на това решение (в Brainfuck) ще бъде почти невъзможно да се пише, камо ли да се чете. Това ще ви коства време и огромни усилия. Като цяло трябва да използвате езици и платформа, които улесняват развитието, а не по-трудно за вас (или за някой, който може да работи по него по-късно).

• Общност

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

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

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

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

Защо избрах JavaScript

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

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

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

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

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

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

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

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

  JavaScript беше първият език за програмиране, който донесе функционалната парадигма за масите (разбира се, Lisp е на първо място, но повечето програмисти никога не са изграждали готово за производство приложение, използващо Lisp). Лисп и аз, Основните влияния на Javascript , са пълни с иновативни идеи. Тези идеи биха могли да освободят съзнанието ни да изследва нови техники, модели и парадигми. И всички те се пренасят в JavaScript. Погледни монади , Църковни номера , или дори (за по-практичен пример) Underscore.js 'с функции за колекции , който може да ви спести редове и редове код.

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

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

• JavaScript е Интернет

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

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

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

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

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

• Node.js

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

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

• MongoDB

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

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

Компонентизация на сървъра с Express.js

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

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

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

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

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

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

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

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

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

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

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

За много е казано MVC * рамки за SPAs . Това е труден избор, но бих казал, че първите три са Backbone.js , Ember.js , и Angular.js .

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

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

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

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

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

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

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

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

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

• Mocha.js и Chai.js :

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

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

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

  • Интерфейси : може би сте свикнали с TDD концепции за суити и модулни тестове, или може би предпочитате BDD идеи за спецификации на поведението с „описва“ и „трябва“. Mocha.js ви позволява да използвате и двата подхода.

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

  • Липса на библиотека за твърдения : далеч не е проблем, Mocha.js е създаден, за да ви позволи да използвате библиотеката за твърдения по ваш избор, като ви дава още по-голяма гъвкавост. Има много възможности , но тук е мястото, където Chai.js влиза в игра.

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

  • Утвърждавайте : Класически стил на твърдение от старата школа на TDD. Например:

    assert.equal(variable, ”value”);

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

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

  • Трябва : Използва се и в BDD, но предпочитам Expect, защото би трябвало да звучи повтарящо се със спецификацията на поведение ‘it („ should done something .. “). Например:

    variable.should.equal(“value”);

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

• Grunt.js :

  Подготовка за сертифициране на архитект за решение на aws

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

• Изисква JS :

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

• CoverJS :

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

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

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

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

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

Стартирайте проект с Init и внедрете в Heroku Today

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

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

   heroku create

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

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

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

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