Уважаемые хабравчане.

Поскольку дискуссия вокруг статьи идет весьма активно, Жан-Жак Дюбре (он читает комментарии) решил организовать чаты в gitter.

Вы можете пообщаться с ним лично в следующих чатах:
https://gitter.im/jdubray/sam
https://gitter.im/jdubray/sam-examples
https://gitter.im/jdubray/sam-architecture

Также автор статьи разместил примеры кода здесь: https://bitbucket.org/snippets/jdubray/

По поводу кода он оставил следующий комментарий:

I don't code for a living, so I am not the best developer, but people can get a sense of how the pattern works and that you can do the exact same thing as React + Redux + Relay with plain JavaScript functions, no need for all these bloated library (and of course you don't need GraphQL).

Frontend Guidelines

Правила и руководства оформления, форматирования HTML, СSS и JavaScript кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.

От переводчика

Приветствую всех снова, меня зовут Максим Иванов, и сегодня я подготовил перевод, который, возможно, окажется для вас полезным. Бенджамин Де Кук (Benjamin De Cock), разработчик из Бельгии, собрал некоторые указания по оформлению кода, которые позиционируют себя как лучшие практики по написанию HTML, CSS, JS. Конечно, существует множество рекомендаций, например, есть хороший гайдлайн от Google, наверное, есть еще что-то, однако, если следовать хотя бы некоторым из них, то можно надеяться, что ваш код станет лучше. В отдельных случаях следование этим гайдлайнам не полезно, а совсем наоборот. В общем и целом, все зависит от вашего опыта и виденья дела, если вы новичок, то скорее вам будет полезно оценить то, что пишут другие и в обществе считается верным, если вы гуру, то наверное вам и не нужны гайдлайны, которые написаны непонятно кем на ваш взгляд. Итак, приступим.

Все CSS-селекторы живут в глобальной области видимости.

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

Абсолютно каждый селектор потенциально может вступить в борьбу с другим селектором или стилизовать «посторонний» элемент. В этой «глобальной» борьбе селектор может даже полностью проиграть, в итоге не применив к странице ни одного из своих правил.

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

Так не должно быть. Пора оставить позади эру глобальных стилей. Наступило время закрытого CSS.

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

Привет, Хабр! Меня зовут Владимир, мне 28 лет и я наркоман наркоман. Мой наркотик – простота. На простоту я подсел из-за своего перфекционизма, которым меня наградили при рождении.

Врачи говорят, что это взаимосвязано, мол перфекционизм — это стремление к совершенству, а простота позволяет подобраться к этому мифическому совершенству. Чем проще решение, тем меньше ошибок можно допустить, вот я и подсел. Я не стал с ними спорить и вместо того, что бы искать виновников моей истории, решил с этим жить и постараться повысить качество этой самой жизни.

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

CSS Protips

Это современные решения типичных проблем, коллекция советов, которая поможет вам улучшить ваши профессиональные навыки CSS.

От переводчика

Приветствую, для вас подготовлен еще один перевод заметок на тему CSS. Мэтт Смит, разработчик из Портленда, поделился CSS-советами и выложил их на GitHub. Мне особенно понравилась его подборка, она структурирована, не особо громоздкая в плане скучных больших текстов и описаний, и в целом будет понятна даже новичку. Я буду рад, если в комментариях мы с вами обсудим каждый пункт и в итоге дадим некоторые заключения. Итак, приступим.

Cодержание

1. Используем псевдо-класс :not для задания рамки навигации
2. Добавляем межстрочный интервал элементу body
3. Центрируем по вертикали все что угодно
4. Правильно разделяем запятыми элементы списков
5. Отрицательный порядковый номер в nth-child
6. Используем SVG-логотипы
7. Аксиоматический CSS
8. Максимальная высота у CSS-слайдера
9. Наследуем box-sizing
10. Одинаковая ширина ячейки таблицы
11. Динамические внешние отступы при помощи flexbox
12. Используем селектор атрибутов пустых ссылок
13. Стили по умолчанию для обычных ссылок

Доброго времени суток, уважаемые хабравчане! Обычно мои подборки ориентированы сугубо на веб-разработку, но этот выпуск охватывает все сферы программирования. Но самое главное, что интересность и полезность каждого материала имеет социальное доказательство, благодаря замечательному сервису Slant.co. Это некий аналог Quora, сфокусированный сугубо на разработчиков.

Коллекция из почти 200 ответов в Slant на вопросы «Какие лучшие...»

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

И вновь в эфире цикл переводов полезных советов для веб-разработчика. На этот раз автор расширил спектр исследуемых инструментов, добавив туда редактор Sublime Text и фреймворк Node.js. Предыдущие части: 1-16, 17-32.

Поехали!

Содержание:
   33.  Разворачивание упрощенной записи CSS-свойств
   34.  Определение совпадения селекторов по цвету
   35.  Использование визуальной навигации и просмотр снятых скриншотов процесса загрузки страницы
   36.  Sublime Text: нечеткий поиск при помощи функциональности GOTO
   37.  Быстрое изменение значения CSS-свойств при помощи клавиатуры и колеса мыши
   38.  Прокрутка элемента в области видимости
   39.  Node.js: Использование Babel для запуска ES6
   40.  Переход к просмотру и редактированию CSS или Javascript-файлов из панели «Elements»
   41.  Отображение значений Javascript-переменных рядом с кодом в процессе отладки
   42.  Использование цветовой группировки в панели «Network» для упрощения идентификации типа ресурса
   43.  Активация псевдо классов DOM-элемента
   44.  Инспектирование самих инструментов разработчика
   45.  Запуск выбранного блока кода из панели «Sources»
   46.  Установка условных точек останова
   47.  Переход к следующему вхождению выбранной строки при помощи горячих клавиш
   48.  Редактирование CSS-файла в панели «Sources» и упрощенное изменение значений CSS-свойств

Шифрование. Мы все его любим и хотим использовать везде. Но почему оно до сих пор не применяется повсеместно?

Проблема в сертификатах?

Первый и наиболее распространённый барьер к переходу на HTTPS это цена получения, настройки и поддержки валидного сертификата. Вы должны найти поставщика сертификатов, подтвердить свою личность, заплатить за него и настроить сервер, а также своевременно продлевать.

Большинство предложений перехода на повсеместное шифрование звучат примерно так: «NSA записывает весь наш трафик, почему бы не шифровать его?». Целью подобных предложений является повышение стоимости пассивного слежения за всем трафиком, а не более сложные и целевые атаки, которые применяются злоумышленниками.

Ребята из Let's Encrypt уже догадались, что проблема с сертификатами почти полностью поддаётся автоматизации, и что её реализация для выпуска, установки, конфигурации и продления на нескольких наиболее распространённых платформах может покрыть подавляющее большинство Интернета. Замечательная работа, и, хоть и осталось сделать многое, я думаю, что мы можем считать проблему сертификатов решённой.

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

Манифест для сайта – это простой JSON-файл, который позволяет вам настроить следующие вещи:
1. Какая будет иконка у пользователя, после того как он добавит ваш сайт на рабочий стол
2. Как будет запускаться ваш сайт (с адресной строкой, без нее или в полноэкранном режиме)
3. Splash screen
4. Цветовую тему
5. Ориентацию экрана
6. Начальный url
и многое другое

Привет! Я продолжаю про буквы для блога Текстброкера — моих хороших друзей.

Начнём с того, что сегодня, пожалуй, уже не осталось сайтов, где главная страница — единая точка входа. Это во времена Арпанета был список нод с адресами, по которым надо было ходить. Это у BBS были меню и текст на входе. Сейчас люди заходят на ваш сайт со всех сторон. Поэтому каждая значимая страница – главная. То есть к странице любого товара на сайте интернет-магазина надо относиться как к главной. И к странице услуги. И к любой другой.

На главную люди часто попадают либо через поиск, набирая название вашей компании, либо через бумагу или ещё каким-то «социальным» образом, например, когда с ними делятся ссылкой.

AngularJS — прекрасный фреймворк для построения веб-приложений. У него замечательная документация, снабженная примерами. В обучающих «пробных» приложениях (вроде TodoMVC Project) он очень достойно показывает себя среди остальных прочих фреймворков. По нему есть отличные презентации и скринкасты.

Однако если разработчик никогда ранее не сталкивался с фреймворками, подобными Angular, и пользовался в работе в основном библиотеками вроде jQuery, то ему может быть трудно изменить свой образ мышления. Как минимум, так было со мной, и я бы хотел поделиться некоторыми заметками на эту тему. Может быть, кому-то это будет полезно.

1 Введение

В статье мы сравним три популярных MV* фреймворка для веб-разработки: AngularJS, Backbone и Ember. Выбор подходящего фреймворка для проекта кардинально влияет на вашу возможность выполнять задачи вовремя и поддерживать ваш код в будущем. Вам нужен надёжный, проверенный фреймворк, но вы не хотите, чтобы он вас ограничивал. Веб быстро развивается, и старые методики уходят в прошлое. Займёмся же подробным их сравнением.

2 Познакомьтесь с фреймворками

У всех рассматриваемых фреймворков есть общие черты: их код открыт, выпущен под лицензией MIT, и они решают задачу создания одностраничного приложения через шаблон проектирования MV*. У всех есть концепции видов, событий, моделей данных и путей.

AngularJS родился в 2009 как часть большего коммерческого продукта GetAngular. Вскоре после этого Миско Хевери, один из инженеров-основателей GetAngular, сумел воссоздать при помощи этого продукта веб-приложение, состоявшее из 17 тысяч строк кода и делавшееся в течение 6 месяцев, всего за 3 недели, и уложиться при этом в тысячу строк кода. В Google впечатлились таким фактом и стали спонсировать проект с открытым кодом AngularJS. Среди его возможностей – двустороннее связывание данных, инъекции зависимостей, простой для тестирования код и расширение возможностей HTML при помощи директив.

Backbone.js – легковесный MVC-фреймворк, родившийся в 2010. Популярность набрал в качестве альтернативы тяжёлым фреймворкам вроде ExtJS.

Ember родом из 2007 года. Он начинался как SproutCore MVC фреймворк, и сначала его разрабатывали SproutIt, затем – Apple. В 2011 году его форкнул Иехуда Кац, один из главных программистов в проектах jQuery и Ruby on Rails.

(Дата публикации оригинала — 12.04.2013)
Выбор JavaScript MVC фреймворка — тяжёлая работа. Нужно учесть много факторов, и число вариантов выбора может быть огромно. Достаточно взглянуть на проект ToDoMVC (о нем по-русски).

Я работал с 4 фреймворками: Angular, Backbone, CanJS и Ember. Поэтому решил сделать сравнение, чтобы помочь вам решить, какой из них использовать. Я выделю несколько факторов, которые вы можете использовать при выборе. Каждый фактор будет иметь оценку от 1 до 5 (больше — лучше). Я старался быть беспристрастным, но, конечно, оценки основаны на личном опыте.

Сегодня Google Chrome является самым популярным браузером среди веб разработчиков. С быстрым, шести недельным, циклом релизов и мощным набором постоянно расширяющихся инструментов разработчика, превратившим браузер в инструмент, который вы обязаны иметь. Большинство из вас, вероятно, знакомы со многими его функциями, такими как «живое» редактирование CSS, используя консоль и отладчик. В этой статье мы с вами рассмотрим 15 захватывающих советов и хитростей, которые позволят улучшить вашу производительность еще больше.

Всем счастливых выходных!

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



При помощи двух регуляторов можно настроить объём поливаемой за раз воды, а также период между поливами. Кому интересно — далее подробная инструкция, как сделать такое устройство.

Введение

«Нужно больше золота»
Непризнанный экономический гений

Всё началось с вот этого разговора в комментах. Если вкратце, содержание можно свести к следующему: заказчик хочет «красиво», дизайнер хочет сделать красиво (без кавычек); заказчик фонтанирует идеями, зачастую вредными для юзабилити и продаж, дизайнер знает, как действовать в рамках типовых решений по юзабилити и стилю.

И тут на сцене появляется рекламщик/продажник. У него тоже есть свое мнение. И мнение это такое: к лешему красоту истинную и крикливый кич, выбросите на помойку споры по поводу идей; сайт должен работать, приносить прибыль: инициировать продажи, служить для брендинга, привлекать звонки — то, что требуется заказчику. Нужно исследовать целевую аудиторию — и выяснить, какой дизайн поможет добиться от неё нужной реакции. И создать с нуля именно то, что требуется для достижения цели. Типовые решения не годятся — они не продуманы для конкретного сочетания заказчик/целевуха. Хуже того, они примелькались.

«Хорошо», — согласятся с ним. Даже здорово. Но как сделать оригинальное решение там, где оригинальности быть в принципе не может (приведу пример из той дискуссии — «интернет-магазин по продаже букетов для новобрачных»)? И как понять, что именно хочет аудитория?

Полный ответ на этот вопрос занял бы немало страниц. Автор попытается изложить определенные основы того, в каком направлении двигаться, опрашивая заказчика и изучая ЦА будущего сайта, и как потом использовать эти данные для создания такого дизайна, который сам по себе служил бы поставленной задаче — то есть, приносил бы прибыль тем или иным образом. При этом автор не планирует касаться конкретики и вдаваться в частности — они слишком многочисленны для короткой статьи.

Предупреждение. Под катом — длинный текст без картинок.
Предупреждение 2. Честно говоря, автор не подозревал, что это — не прописные истины. Поэтому не надейтесь найти что-то новое в тексте.

В течение месяца мы проводили на сайте одного из наших клиентов (интернет-магазина подарков) АБ-тест, в котором сравнивали конверсию посетителей в оплаченные заказы для трех разных вариантов оформления заказа:

Сразу о главном: победил вариант №2 с приростом конверсии +58% по сравнению с вариантом №1. Под катом подробнее о проведенном тесте, варианте №3, некоторые числа и графики.