После недели использования новой социальной сети от Гугла я ощутил всю прелесть идеи разделения кругов общения. Действительно, довольно удобно делиться новостями и мыслями только с теми людьми, которым они будут интересны. Однако, в текущей своей реализации, круги, как инструмент разграничения доступа, неидеальны. В качестве примера приведу ситуацию, которая, я уверен, возникала у пользователей Google+ уже многие сотни раз.

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

Теперь представьте, что вы хотите поделиться ссылкой на техническую статью с Хабрахабра. С кем стоит её расшаривать? С кругом «Программисты»? Пожалуй, стоит, но, с другой стороны, у вас в этом круге могут быть и англоязычные программисты-коллеги, которым статья не будет понятна. Значит, нужно расшаривать с кругом «Русскоговорящие»… но там полно людей, которые от программирования далеки. Выходит, нужно создавать отдельный круг: «Русскоговорящие программисты».

Здравствуйте! Мы — команда ниндзя-разработчиков проекта ninjamock.com. Ninjamock.com — это еще один онлайн-дизайнер скетчей и прототипов. Проект полностью написан на javascript и HTML5, серверная часть — на ASP.NET MVC.

За год работы над проектом мы наступили на огромное количество граблей и накопили бесценный опыт разработки больших приложений на JavaScript, которым и хотим поделиться. В этой статье мы расскажем, как прототип из одного файла index.html перерос в полноценный проект с более чем 250 классами и 60000 строк кода (не считая сторонних библиотек). Также, в общих чертах опишем нашу архитектуру и детально опишем реализацию отрисовки на клиенте.


UPD: Следите за апдейтами на нашем твиттере или странице фб

Вступление

Я безумно люблю различные эксперименты на JS. Они словно позволяют заглянуть нам в будущее, и посмотреть, каким захватывающим и футуристичным оно будет. Когда вы будете просматривать приведенную подборку, вы наверняка вспомните про еще недавнего короля — Adobe Flash, а затем осознаете, насколько быстро CSS и JavaScript лишили его трона. Современные браузеры позволяют нам использовать множество различных эффектов и анимаций без сильных тормозов. Однако слово «экспериментальный» подразумевает ряд ограничений, как например некорректное отображение в некоторых браузерах (IE), кроме того, подобные плагины будут, скорее, отличным концептуальным дополнением для персональных страниц, а не для использования в больших проектах.

Meny

Meny — трехмерное меню, которое помимо своей визуальной притягательности еще и экономит место на экране. При наведении (или свайпе на тачскрине, что важно), меню «выезжает» с отличным эффектом.

В подборке сервисы, плагины, темы и другие полезности, облегчающие работу с Twitter Bootstrap.

Стилизация

BootSwatchr — быстрая стилизация Twitter Bootstrap.

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

Хочу поделиться набором ссылок на нексолько полезных, интересных и, возможно, не самых известных материалов по JavaScript. Из них вы узнаете немного больше об истории появления языка, о его настоящем, тонкостях реализации в различных браузерах, и о будущем развития стандарта ECMAScript. О различных способах наследования в том числе об эмуляции «классического» ООП, множественном наследовании и миксинах. О функциональном стиле программирования в JavaScript: чистые функции, map, reduce, частичное применение и композиции функций. И, наконец, что если бы Хемингуэй писал на JavaScript?

Фреймворк Twitter Bootstrap уже давно стал одним из самых любимых средств ленивых сторонников быстрого прототипирования и разработки интерфейсов, а где популярность там много разных сторонних интересных штук.
На этот раз я случайно попал на пополняющуюся коллекцию сниппетов.
Думаю многим пригодится, сейчас там набор небольшой (23 штуки), но уже достаточно полезный чтобы поделиться.
Кликабельные картинки:

Интерфейс аля gmail

В прошлой статье я начал рассказывать о своём опыте разработки экспериментального WEB-проекта «Что делать?» на Node.JS. Первая часть была обзорной, в ней я постарался раскрыть плюсы и минусы технологии, а также предупредить о проблемах, с которыми, возможно, придётся столкнуться в ходе разработки. В этой статье я подробнее остановлюсь на технических деталях.

Несколько слов о «хабраэффекте»

В далёком 2005 году я менял стек технологий с Java на .NET и поначалу в Visual Studio мне очень не хватало возможностей, которыми располагала IntelliJ IDEA. Пробуя различные плагины к студии, я остановился на ReSharper'е и по сей день его использую. Недавно стало интересно, есть ли похожие продукты для работы с SQL Server, а точнее с T-SQL кодом хранимых процедур. Собственно про один такой продукт я и хочу рассказать в этой статье.

Итак, SqlCodeGuard – это бесплатный addin для SQL Server Management Studio для статического анализа T-SQL кода. Ну и плюс пара-тройка других возможностей.

Начнём с примеров практического применения параллельных субтитров:

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

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

3. Фильм смотрят в компании, одним нужен оригинал, другим перевод.

Конечно, всё это смахивает на небольшое маньячество, но человек, знакомый с проблемами перевода, готов мириться с некоторыми неудобствами (отъедание экранного пространства, раздвоение восприятия, небольшая морока с подготовкой материалов).

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

Недавно я писал, что Greensock, прекрасная библиотека для скриптовой анимации на Flash, теперь поддерживает и JavaScript. В этой статье я продемонстрирую основы работы с GSAP v12 (beta). Результат будет примерно таким:


Сразу оговорюсь, что графику и идею для примера я взял из документации $fx(), ведь кто из нас откажется

Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

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

С удовольствием ознакомился с этими рекомендациями и теперь предлагаю вам перевод.

Введение

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

Это относится к рабочим версиям файлов использующих HTML, CSS и GSS

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

Питер Гасстон, автор книги по CSS3, опубликовал статью под названием The future of CSS layouts, перевод которой специально для читателей хабра представлен ниже.

Несмотря на все поразительные возможности CSS, их недостаточно для реализации фундаментальных принципов разметки страницы. Однако, дополнительные возможности для создания более динамических страниц уже начинают появляться.

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

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

Консорциум W3C и создатели браузеров в курсе этих проблем и работают над рядом решений. Лидером среди них является (как не удивительно) Internet Explorer. Похоже, что IE10 будет предвестником новой эры CSS разметки, которая позволит создавать отличные, динамические и привлекательные сайты, используя недосягаемые ранее возможности.

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

Как расположить текст на странице в несколько колонок? И можно ли это делать автоматически? Наверняка, многие из тех из вас, кто занимается или занимался раньше веб-разработкой, сталкивались с такой задачей — и часто упирались в сложные решения, требующие хитрых стилей, либо применения дополнительных библиотек на JavaScript (см. например Columnizer-плагин для jQuery).

Многоколоночная верстка контента (не путать с задачей общей многоколоночной верстки страницы, которая скорее ближе к проблеме расположения блоков по сетке) долго пробивала себе дорогу в мире веб-стандартов и, наконец-то, не просто достигла статуса Candidate Recommendation в виде соответствующего модуля CSS3 Multi-column Layout, но и получила достаточно широкую поддержку в браузерах: где-то с префиксами (-moz- или -webkit-) и где-то в актуальных (Opera 11.1+) и планируемых версиях (IE10+), причем сразу без префиксов.

Я потратил несколько лет на изучение архитектуры компьютеров, и уж если одну вещь я выучил крепко, так это любовь компьютерных проектировщиков к изящным именам, используемым при инициализации или другой работе с памятью. Долгие часы своей жизни я истратил на придумывание забавно выглядящих адресов памяти для употребления в домашней работе или тестировании. Из подобных названий лучше других известен 0xDEADBEEF, а список некоторых других вы можете видеть вон там и там. Можно даже предположить, что этакие названия (особенно с подстановкою символов: например, «1» вместо «i» или «5» вместо «s») стали предтечами псевдо-крутого интернетовского жаргона, известного как leetspeak.

Всё это напомнила мне недавно попавшаяся мне статья о веб-дизайне (извините, я не помню её в точности). Автор статьи приводил пример CSS-кода, и выбранный им для примера цвет был #BADA55. Оказалось, что это даёт несколько безобразный зелёный цвет, но всё равно он побудил меня призадуматься о том, какие ещё английские слова можно сделать шестнадцатеричными кодами цвета.

Набросав краткий PHP-скрипт, получаем довольно обширный список для подбора таких цветов. Разумеется, годятся все коды, полностью состоящие из букв, но я также дозволил подстановку «1» вместо «i», «5» вместо «s» и «0» вместо «o». Та статья Википедии, на которую я выше сослался, также предлагала использовать «7» вместо «t» и «9» вместо «g», но мне кажется, что при этом не получаются сколько-нибудь легко читаемые «шестнадцатеричные слова» (да к тому же тогда список слов, и без того длинный, оказался бы гораздо длиннее).

Итак, когда вам в следующий раз понадобится цветовая гамма для веб-страницы, вы сможете воспользоваться следующей таблицею и достигнуть субкультурного звучания выбранных вами цветов:

████████████████ #ABACA5 → abacas
████████████████ #ABA5ED → abased
████████████████ #ABA5E5 → abases
████████████████ #ABA51A → abasia
████████████████ #ABBE55 → abbess
████████████████ #AB1DED → abided
████████████████ #AB1DE5 → abides
████████████████ #AB0DED → aboded
████████████████ #AB0DE5 → abodes
████████████████ #ACAC1A → acacia
████████████████ #ACCEDE → accede
████████████████ #ACCE55 → access
████████████████ #ACED1A → acedia
████████████████ #AC1D1C → acidic
████████████████ #AD0BE5 → adobes
████████████████ #AD0B05 → adobos
████████████████ #A5D1C5 → asdics

Плагин Chosen создан для оформления красивых и удобных выпадающих списков с помощью jQuery и Prototype. Для установки плагина достаточно просто скачать файлы и прописать одну строчку:

$(".chzn-select").chosen()

(версия для jQuery)

По умолчанию в Chosen вместо длинного текстового списка предлагается поле, по нажатию на которое появляется список. Поддерживается автодополнение ввода, выбор нескольких пунктов меню, элемент optgroup и др. Выглядит вполне нативно. В общем, лучше один раз увидеть.

Поскольку Chosen заменяет стандартный элемент HTML, то не нужно беспокоиться, как он работает с браузерами без поддержки JavaScript. Также не нужно ничего менять в бэкенде: формы сабмиттятся как обычно, изменения только в пользовательском интерфейсе.

Некоторые форки:
Chosen для MooTools
Модуль Chosen для Drupal 7

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

С технической точки зрения юнит-тесты – это очень простой инструмент, основанный на паре несложных концепций: (1) тестируемый класс, (2) набор тестовых методов, завернутых в некоторый класс и (3) набор методов, с помощью которых можно удостовериться в том, что состояние тестового класса соответствует (или не соответствует) некоторому значению.

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach"), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.