?

Log in

November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

4. BackboneJS.

Posted on 2015.07.10 at 16:50
Tags: , ,
Допустим, у нас есть группа разработчиков на PHP, которые знают чуть чуть JS и jQuery. Что самое простое мы можем сделать, чтобы начали писать браузерное приложение, и были продуктивны немедленно?

Мы можем попробовать использовать тот же принцип, и те же архитектурны правила, к которым они привыкли в PHP. У них были шаблоны с встроенным PHP? Отлично, мы будем использовать такие же шаблоны со встроенным JS, которые будут разворачиваться в браузере. Они использовали jQuery? Отлично, мы сохраним jQuery.

Нам остается задать этому какую-то структуру. Элемент UI - это будет объект View с присоединенным DOM-элементом, и методом 'render', который должен разворачивать шаблон в присоединенный элемент. Помимо этого, View должен уметь перехватывать события UI, и вызывать свои методы.

Помимо этого, нелишне добавить к этому простые средства для работы с REST API. Класс для кусочка JSON, который умеет создаваться/читаться/сохраняться/удаляться (CRUD) в каком-нибудь стандартном варианте REST. Назовем его Model. Раз у нас REST, то надо еще уметь получать их список. Значит, нужен еще Collection.

У нас сейчас получилось что? Правильно, самый популярный фреймворк для разработки в браузере - backbonejs (http://backbonejs.org), который, в сочетании с модульной системой позволяет из говна и палок собрать браузерное приложение.

читать дальшеCollapse )

Небольшая заметка о том, что это за роль такая и кто это вообще должен быть такой, чтобы от него была польза. А то тоже проясняют уже лет 20, и все нихрена.

Вот в этом определении архитектуры...
*Архитектура* - это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.

...самое важное - это явный акцент на том, что суть архитектуры в правилах для людей. Предмет архитектуры, как таковой - не технологии, а люди, которые их делают, и именно они стоят в центре.

Архитектор несет непосредственную личную ответственность не "за систему", а за продуктивность всех членов команды в их повседневной работе. Его обязанность - усиливать людей, снабжая их необходимыми технологиями для выполнения повседневных задач по проектированию системы. И оказывать им всестороннюю поддержку, если у них будут с этими технологиями какие-либо сложности.

Именно так, и никак иначе. Не придумывать как делать систему под конкретные требования. А давать людям методику (набор правил), руководствуясь которым конкретные эти люди (а не какие-то там абстрактные) смогут проектировать эффективнее.

Совершенно очевидно, что без определенного авторитета, и без разностороннего опыта работы как с технологиями так и с людьми, человек пытающийся быть архитектором быстро превращается в клоуна.

Я видел много людей с этим титулом. Настоящий архитектор не просто умеет писать код, он в состоянии исправить в этом коде вывернутый мистический баг, который приводит людей в суеверный трепет. Настоящий архитектор - он сцуко гуру и рыцарь без страха и упрека, к которому вы с этим багом придете, и скажете - "Обиван, ты наша последняя надежда".

Штука в том, что если он мудак - вы к нему просто не придете.

ЗЫ: А мудак - благодаря Стенфордскому профессору Бобу Саттону - теперь вполне научное понятие. Я лично считаю, вся наука организационного поведения давно к этому шла: https://en.wikipedia.org/wiki/The_No_Asshole_Rule

Теперь поговорим об архитектуре так называемых "одностраничных приложений" более детально.
Это будет непросто - сотни фреймворков, предлагающих десятки подходов - какой из них выбрать? У человека, решившего написать одностраничное приложение, будут большие проблемы. Такое многообразие выбора - это почти что то же самое, что и его отсутствие.

К счастью, основной критерий "хорошести" или "плохости" архитектуры очень простой. Коль скоро архитектура - это правила проектирования, то в первую очередь эти правила должны выполнять свою главную функцию - помогать проектировать:


Хорошая архитектура снабжает вас простыми и понятными правилами, которые помогают легко разбить что-то большое и сложное на набор менее сложных, слабо связанных между собой кусочков. А потом - эти кусочки разбить на более мелкие. И так далее.


Мы будем оценивать фреймворки и технологии именно с этой точки зрения - поддерживают ли они "рекурсивный паттерн проектирования", и если да (что уже неплохо) - то насколько легко пользуясь им разбить что-то сложное на набор мелких фрагментов.


FYI - есть два основных типа "рекурсивного паттерна".

Первый - "слои". Суть его в том, что система организована в "слои сверху вниз", таким образом, что верхний знает про нижние, а нижние про верхние ничего не знают. Слои отделены друг от друга строгим API, а за этим API вполне может царить Адъ. Ну и что.

Этот паттерн теоретически рекурсивен потому, что часто один слой при большом желании можно разбить на два слоя. Или он может быть слоистым внутри. Но, как правило, у каждого "слоя" есть определенный смысл, и бить его дальше некуда.

Второй - "иерархическая декомпозиция". Его суть в том, что сложный модуль состоит из более мелких, они - еще из более мелких, и т. д., таким образом, образуя "дерево". Все модуля отделены API.

"Иерархическая декомпозиция" является архитектурным паттерном только тогда, когда интерфейс "узлов" не уникален, а стандартизован. Например, если мы говорим о UI виджетах - то архитектурное правило говорит нам, как выглядит интерфейс виджета.

В реальной системе они всегда встречаются в сочетании. Например, если есть какой-то фрагмент используется в двух "деревьях" сразу - это означает, что он принадлежит "нижнему слою". Явно отделять слои, и наделять их смыслом - критически важно для архитектуры. Задавая осмысленные слои, с внятными критериями принадлежности им, вы задаете правила.


Надо отметить, что у "голой" браузерной платформы с этим исходно большие проблемы. Для описания UI требется целый трех языка: HTML, CSS, и JavaScript. И каждый более мелкий кусочек должен каким-то образом включать в себя все три. Но все, что может дать нам голый браузер - это один файл HTML, включающий в себя много файлов JS и CSS. А из JS файла сказать, что ему нужен другой JS файл нельзя вообще.

Прежде чем разбираться с фреймворками, надо разобраться с этим. Без нормальных модулей JS с зависимостями, этого элементарнейшего "рекурсивного паттерна", очевидно, ничего сложного в бразуре сделать в принципе невозможно.

Хорошая новость в том, что на JS модули есть открытая публичная спецификация CommonJS/Modules. Именно с такими модулями работает серверный JavaScript, например - nodejs.

Выглядит это так. В каждом файлике .js пишется что-то вот такое:
    var iamimporting = require( 'path/to/js/file' );
    ...
    module.exports = iamexporting;


В node это работает прекрасно, потому, что загрузка модуля с локального диска быстра, и может происходить синхронно. Чтобы это работало в браузере, модуль потребует дополнительной обработки (сборки). Например, мы можем собрать все модули, которые надо загрузить, в один большой файл, и включить его один раз тегом script.

Именно так работают browserify и webpack. При этом, (1) у нас в проекте появляется шаг сборки, и (2) возникает куча нюансов в случае, если приложение очень большое, и мы не хотим грузить все сразу. Мы хотим сразу загрузить необходимый минимум, а далее подгружать то, что нужно, по необходимости.

Это можно сделать, разбив приложение на крупные куски (единицы загрузки), и собрать эти куски
раздельно (по сути очень похоже на DLL). Это особенно удобно делается в webpack.

Или же, можно придумать что-нибудь еще. Это что-нибудь еще называется CommonJS/AMD (Asynchronous Module Definition), позволяет грузить модули без сборки, и в тот момент, когда они действительно нужны. Выглядит это так:

    define( [ 'path/to/js/file', ... ], function( iamimporting, ...){

        return iamexporting;
    });


И есть много загрузчиков, которые позволяют грузить такие модули. Самым популярным из них является requirejs.

Но у этого модуля есть недостаток, который сразу бросается в глаза. Им невозможно пользоваться. Поэтому, помучавшись несколько лет, разработчики придумали формат асинхронного модуля "Simplified CommonJS Wrapper", который допускает асинхронную загрузку, но выглядит по человечески:

     define( function( require, exports, module ){
        var iamimporting = require( 'path/to/js/file' );
        ...
        module.exports = iamexporting;
    });


requirejs также позволяет выполнять сборку проекта в один или несколько больших файлов js, но в данном случае это не необходимость, а оптимизация.

Глядя на это, возникает простая идея. Раз импорт модуля - это не часть языка, и все равно делается неким фреймворком, может ли он быть чуть поумнее, и загрузить прочие нужные нам ресурсы - html-шаблоны, css?

Конечно же может. Например, в requirejs это будет выглядеть так:

    define( function( require, exports, module ){
        require( 'css!./widget');
        var template = require( 'ejs!./widget' );
        ...
        module.exports = mywidget;
    });


В requirejs и webpack это далется при помощи контент-плагинов, они могут грузить практически все, что угодно, выполняя при этом над загружаемым объектом необходимые преобразования. Например, шаблон может на лету компилироваться в JS. И если они не умеют грузить то, что нужно вам - вы можете легко научить их это делать.

Что касается директивы import из ES6, я не думаю, что когда она будет поддерживаться браузерами, она быстро вытеснит модули CommonJS. Во-первых, синтаксис CommonJS совсем не плох, и никакого выигрыша сама по себе замена 'require' на 'import' не даст. Во-вторых, возможность тонко контролировать процесс загрузки, и выполнять преобразования над загружаемыми объектами - это очень большое преимущество для браузерных приложений. Вряд-ли от него кто-то просто так откажется.

Вообще, я бы не советовал уделять слишком большое внимание системе модулей. Она должна быть CоmmonJS, и выбирайте любой загрузчик. Его потом будет не так сложно заменить. Я бы советовал выбирать между requirejs и webpack. Первый - если не хотите вводить в проект шаг сборки. Сел, и поехал. Второй - готовы делать сборку, озабочены тем, чтобы "быть на острие технологий", и не хотите потом горько жалеть о том, что выбрали какую-то фигню.

Но уверяю вас, система сборки и загрузки модулей - это совсем не то острие, которое изменит
всю игру.

С модулями CommonJS и контент-плагинами уже вполне понятно, как в принципе бить приложение на кусочки, разложив их по файлам. Это необходимо, но не достаточно для того, чтобы построить наше приложение - нам надо знать, как примерно будут выглядеть эти кусочки. "UI виджет - это js модуль" - это слишком общо.

Не всякий модуль экспортирует виджет, в конце концов.

SPA (Single-Page Application) весьма сильно изменили архитектуру веб-приложений. Если говорить кратко - архитектура SPA гораздо проще традиционных, и по характеру ограничений практически ничем не отличается от традиционных клиент-серверных приложений. С поправками на веб-технологии, конечно. Остановимся поподробнее на принципиальных возможностях и ограничениях современных веб-платформ - что поменялось с архитектурной точки зрения.
Read more...Collapse )

Для начала в очередной раз внесем ясность в вопрос, что же такое архитектура. Сколько десятилетий термин в ходу, и в него постоянно вносят ясность - без особого толка. Однако, коль скоро мы собираемся о ней говорить, это совершенно необходимо сделать в очередной раз. Иначе будет просто не понятно, о чем речь.




Архитектура* - это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.


Результат проектирования - это как правило некоторая высокоуровневая структура системы, которую тут же снова называют словом "архитектура" (ну вот мало у нас слов, и те все иностранные), а потом начинают ломать голову, чем же это отличается от "дизайна", и пр. И накидывать при этом кучу умняка. Мы не будем. Вместо этого:


  • Мы будем стараться использовать для обозначения нашего понимания термин "Common Design Principles".

  • Постараемся разобраться в определении, и как оно соотносится с фреймворками и структурами. Увидете, как только вы начнете думать об архитектуре как о правилах много встанет на свои места.

Read more...Collapse )



Расскажу, пожалуй, про старую тему - разработку одностраничных JS-приложений. С тех пор, как я послежний раз об этом писал, прошло много времени - наверное, года 3. И с тех пор много чего изменилось. Появилось множество разных JS фреймворков, в моду вошел two-way databinding.

Однако, мэйнстримом (примерно 40% применений) на данный момент является Backbone.js, работающий в связке с jQuery и Underscore.js. Причиной этого, возможно, является его простота. Backbone прост в том смысле, что ему достаточно легко обучить команду, собирающуюся писать одностраничное приложение, и не имеющую в этом опыта. Это безусловный плюс backbone (как и его популярность), однако, его минусом является то, что он слишком прост. То есть, на голом backbone не так просто сделать что-то, кроме совсем простого.

Я расскажу про проблемы backbone, вытекающие из его простоты, и покажу, как их можно решить. Проблемы уйдут. Простота останется.

Read more...Collapse )

Пантера

Posted on 2014.04.07 at 02:37

- Смотри, как этот кот рычит. Прям, как пантера. Когда я был в латинской америке, я ухаживал за пантерой.
- Серьезно? Как это было?
- Пантера была в клетке, а я должен был в клетке убирать, и выводить ее гулять в джунгли. На веревке.
- Зачем?
- Ну, пантерам нужно было раз в день гулять. А джунгли - это такая штука, сам понимаешь. Там без мачете хрен проберешься вообще. И пантера убежит. Кошке то чо - она где хочешь пролезет. Поэтому, я ее привязывал веревкой, и каждый день вел гулять.
- Подожди, ты говоришь, что был привязан к пантере веревкой, и вел ее гулять в джунгли?
- Да.
- Но веревка подразумевает, что ты должен за нее иногда дергать? Иначе зачем она?
- Не, дергать за веревку нельзя, если конечно, ты хочешь остаться жив. Находясь в джунглях с пантерой, не стоит ее злить.
- Тогда я вообще ничего не понимаю. Нахрена тебе тогда веревка? А если пантера захочет рвануть в джунгли?
- Тогда ты просто стоишь. И она понимает, что дальше нельзя. Правда, иногда она залезет куда-нибудь, и веревка запутывается. Тогда приходится лезть, и распутывать, прямо перед ее мордой. Очково.
- Это ад, а не работа. И много тебе платили?
- Нет. На самом деле, это я заплатил 500 баксов, чтобы работать на этой работе. Это некоммерческая организация, они занимаются передержкой пантер, пострадавших от рук людей.

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

- Слушай, а какова смертность следящих за пантерами в этой организации?

- Никого. Иначе их бы закрыли. Но потом ничего, она ко мне привыкла, и я чесал ее за ухом.

- Есть большая разница с этим котом?

- Ну, знаешь, когда я вернулся домой - я так удивился. Какой мой кот все-таки маленький .


Backbone.js. Nested Types./

Posted on 2014.03.31 at 22:04
Tags: ,
http://volicon.github.io/backbone.nestedTypes/

My #backbone plugin. Check it out.

It's cool thing, if you don't care about old browsers. IE is supported from version 9 only (due to the heavy use of ECMAScript native properties).

And RequireJS (or other AMD-compatible loader) is required so far. If you don't use it, I highly recommend start doing it today. Because JavaScript is a mess.

Кто, что, где, когда, зачем

Posted on 2014.03.11 at 00:07
Вдогонку у дискуссии о "хорошем списке задач" у Maxim Dorofeev.

На мой взгляд, нет смысла применять какие-либо методики управления задачами, не имея элементарного навыка ставить сами задачи. И именно этой части уделяется наименьшее внимание. Как это делать?

1) Хорошим принципом, знать и уметь применять который необходимо, является 5W (Что, кто, где, когда, зачем). В идеале - иметь навык формулировать mission statement для задачи в виде одного предложения, отвечающего на все 5 вопросов.

http://en.wikipedia.org/wiki/Five_Ws

В википедии об этом не сказано, однако, 5W также является основной техники приказов, используемой US Marine Corps.

2) Второй полезный навык - уметь формулировать секцию "что" развернуто, в виде списка критериев (чеклиста) наступления момента завершения задачи, допускающих простую проверку. Как я проверю, что задача завершена? Я вообще это сделать могу, это возможно?  "Весь код уже написан, осталось только отладить" - это хороший критерий?

Все остальное от лукавого. Включая S.M.A.R.T. Они автоматически получаются SMART, если следовать двум простым правилам выше.

"Фичи", юзер-стори, и юз-кейсы - не от лукавого, а вполне годные. Это более специфичные для софта способы выразить секцию "Что", иногда вместе с "зачем", и рядом других вопросов (Фичлист, как правило, получается автоматически при выполнении пункта 2).

И вот вам картинка на память - о 5W. Сам придумал. Она какбэ должна намекнуть, что процесс планирования (и формулировки задач) - довольно сложный problem-solving process, имеющий мало общего с рисованием гант-чартов в MS Project. Ошибки в котором обходятся дорого.

5W

Успехов. И чуть не забыл - не начинайте задачу с глаголов. В них нет ничего ни полезного, ни интересного.

Многие руководители-программисты разных уровней, придя в новую компанию, ощущают недостаток "авторитета" в новой команде. Проявляется это не в том, что их поручений не выполняют, а, как бы это сказать, в том, что их воспринимают со скепсисом. "Ну, мы, конечно, сделаем, но...". В общем, в той или иной степени повергают "авторитет руководителя сомнению".

Поэтому, "авторитет надо заработать". Тут уж кто во что горазд.

Кто-то считает, что должен перемерять подчиненных пиписьками, что он знает больше, и ваще очень умный (разные вещи идут в ход, от технических, до сугубо менеджерского сакрала, вроде PMBoK и прочего балшыта, не имеющего прямого отношения к работе подчиненных, а потому им неизвестного).

Кто-то считает, что необходимо немедленно проявить новообретенную власть, чтоб свои и чужие боялись, и ваще поняли, осознали, сцуко. Встречается такой паттерн поведения - все у вас плохо, и ваще, вы все дураки. Далее, не оправившихся от шока подчиненных заставляют немедленно внедрять новые технологии. Ну, это только один из вариантов.

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

Не, конечно есть и такие, кто начинает спокойно принимать дела. :) Но мы сейчас не об этом, а о проблеме "авторитета" среди подчиненных, иррациональной по своей природе, и толкающей людей на иррациональные поступки - каждый руководитель, кто менял работу, в той или иной степени с этой проблемой сталкивался.

У этой проблемы есть имя. Если вы это переживали, поздравляю - вы столкнулись с недостатком "легитимности власти". Может-ли это понимание нам дать что-нибудь практически полезного?
А то!Collapse )


Previous 10  Next 10