В нашем блоге мы часто пишем о создании адаптивных почтовых рассылок (раз, два, три) и вообще уделяем большое внимание email-верстке. Сегодня речь пойдет о способе создания адаптивных писем для почтового клиента Gmail, известного своей довольно скудной поддержкой различных возможностей для верстки. Данную технику в 2014 году описал Джастин Ку (Justin Khoo), позднее метод был дополнен статьей Марка Роббинса в блоге Email Code Geek. Мы представляем вашему вниманию адаптированный перевод основных моментов двух публикаций.

^{Капитан Немо у штурвала «Наутилуса»}

Индексы — один из самых мощных инструментов в реляционных базах данных. Мы используем их, когда нужно быстро найти какие-то значения, когда объединяем базы данных, когда нужно ускорить работу SQL-операторов и т.д. Но что представляют собой индексы? И как они помогают ускорять поиск по БД? Для ответа на эти вопросы я изучил исходный код PostgreSQL, отследив, как происходит поиск индекса для простого строкового значения. Я ожидал найти сложные алгоритмы и эффективные структуры данных. И нашёл.

Здесь я расскажу о том, как устроены индексы и как они работают. Однако я не ожидал, что в их основе лежит информатика. В понимании подноготной индексов также помогли комментарии в коде, объясняющие не только как работает Postgres, но и почему он так работает.

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

К чему мы приходим:
— Использование внешних стилей и последующий прогон кода через инлайнер. Из-за усложнения кода это стало целесообразным
— Улучшение семантики через именование классов и сокращение участков кода
— Частичная поддержка the Bat! Хотя Николь на него забила.
— Полная поддержка всех мобильных почтовых клиентов
— Использование ранее опасных конструкций. Благодаря усердному тестированию проблемы решены.

Андрей Глазков, Ито Хаято из Google, а также другие специалисты на Github работают над составлением спецификации Shadow DOM. Уже проделана огромная работа, однако еще много предстоит сделать. В рамках поддержки работы на этом направлении создан перевод существующей версии спецификации от 7 июля.

Эта спецификация описывает способ объединения нескольких DOM-деревьев в одну иерархию, и взаимодействие этих деревьев друг с другом в одном документе, что позволяет построить DOM более правильно.

«Начало — более чем половина всего».

Это очень древний GTD-принцип: возраст его, вероятно, исчисляется тысячелетиями. (Например, Викицитатник в настоящее время приписывает его Аристотелю, хотя и без подтверждающего указания на первоисточник.) Суть его в том, что с чистого листа начинать какой-либо проект бывает очень трудно (и даже приходится заставлять себя); а вот если есть несколько простых начальных шагов, выполнение которых приводит к появлению частично готового проекта, то продолжить работу над ним «по инерции» становится куда проще — так просто, как если бы проект этот ужé был не только начат, но и готов даже более, чем наполовину. А кроме того, когда заранее хорошо знаешь, какими должны быть начальные шаги, то тогда трудно бывает допустить ошибку, совершая их.

Мне довелось сочинить более десятка модулей для Node.js с открытым исходным кодом и опубликовать их в качестве пакетов npm. Чем больше модулей я делал, тем сильнее понимал (в том числе путём проб и ошибок), что начальные шаги для их создания могут быть одинаковыми и даже могут совершаться в одном и том же порядке. Сегодня я публикую этот порядок в надежде на то, что он станет подспорьем в работе программистов, сочиняющих свой код на языке JavaScript для движка Node.

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

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

• разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
• UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Часто ли вам приходится использовать Git? В смысле, вы коммитите изменения каждый час или каждые несколько минут? Я делаю это очень часто и не слежу за чистотой репозитория, так как считаю его не более чем журналом изменений, а не произведением искусства. Такой подход требует от редактора хорошей интеграцией с Git, позволяющей в пару нажатий клавиш создать новый коммит, вернуться в прежнее состояние, перейти на другую ветку и так далее. Если вы используете современную среду разработки, в которой реализована интеграция с Git, вам очень повезло, но что делать пользователям редактора Vim? Есть ли плагин, который не просто реализует Vim-команды по тиму GitCommit, GitCheckout и GitBranch, а предоставляет удобный интерфейс в лучших традициях редактора?

Git — штука не то чтобы особо сложная, но гибкая. Иногда эта гибкость приводит к забавным последствиям. К примеру, посмотрите на этот коммит на GitHub. Он выглядит как нормальный коммит, но если вы клонируете себе данный репозиторий, то такого коммита в нем не найдете. Потому что это потерянный коммит, более известный как git loose object или же orphaned commit. Под катом — немного про внутренности Git, откуда такое берется и что делать, если оно вам встретилось.

По следам недавних топиков, а также постоянных рассказов в стиле «мой стартап не взлетел, потому что его зохавала лапша из callback-ов».

Как раз недавно я закончил небольшой проект (ссылку не даю, чтобы не заподозрили — кому надо см. профиль), полностью и на всех этапах написанном только на JS, и притом полностью асинхронный. Разумеется, я столкнулся с пресловутой проблемой «лапши». И, вы не поверите, совершенно спокойно решил её без всяких там фреймворков и хитрых приемов.

Итак, допустим, у нас есть задача: асинхронно выбрать из базы количество книг, потом асинхронно же выбрать из базы нужную пачку книг, потом асинхронно же выбрать из базы метаданные по книгам, а потом свести всё это в один dataset и отрендерить шаблон. Как это обычно выглядит?

Вступление

Привет всем хабровчанам, любителям Yii и Node.js. Почему объединены любители PHP-фреймворка и серверного JavaScript?
Потому что Yii теперь доступен и на JavaScript (как для Node.js, так и для браузера)!

В этой статье мы рассмотрим Query Builder, полностью сохранивший API от Yii2 и работающий на Node.js.
Конструктор запросов — это лишь одна из реализованных частей Jii (не путать с Yii), в данной статье я специально не буду рассматривать фреймворк в целом, потому что его вполне можно использовать и частями.

Что такое Jii?

Jii — это компонентный JavaScript MVC фреймворк, который повторяет архитектурные решения легендарного PHP фреймворка Yii 2, в большинстве случаев сохраняя его API. Отсюда происхождение названия Jii — JavaScript Yii.

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

Проекты, это то, чего очень не хватает редактору Vim. Реализация проекта позволяет не только выделить его как отдельную сущность среди других папок и файлов в ФС, но и реализовать такие свистелки, как:

• Автоматическое сохранение и восстановление последней сессии проекта так, что после повторного открытия, мы получим редактируемый в прошлый раз файл(ы), с теми же настройками и положением
• Хранение информации о проекте, такой как автор проекта, лицензия, версия и так далее. Все эти данные можно будет добавлять в шаблоны и сниппеты
• Корневой каталог проекта строго определен. Это упростит использования других инструментов, на пример xUnit, дебагеры, генераторы документации и т.д.
• Отдельный, принадлежащий только проекту каталог .vim и файл .vimrc, аналогичный пользовательским версиям. Теперь настройки и плагины проекта будут хранится в нем

Привет, хабраюзер!

Вот уже второй год я активный пользователь и поклонник редактора Vim. За это время я прошел путь от двух команд в .vimrc, до файла в несколько килобайт и обратно. Я испробовал очень много плагинов, а так же активно писал собственные, и теперь это мой основной текстовый редактор для работы и отдыха.

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

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

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

В NGINX версии 1.9.1 появилась новая возможность, позволяющая использовать сокетную опцию SO_REUSEPORT, которая доступна в современных версиях операционных систем, таких как DragonFly BSD и Linux (ядра 3.9 и новее). Данная опция разрешает открывать сразу несколько слушающих сокетов на одном и том же адресе и порту. При этом, ядро будет распределять входящие соединения между ними.

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

Послушайте первые два выпуска и вы узнаете про:

• SPL структуры данных (стек, очередь, массив) против классического array и что нам принесёт PHP 7
• эффективное пересечение массивов, поиск элемента или проверку вхождения в массив
• проблему с хешами паролей, даже если вы используете новые функции хеширования из PHP 5.5
• Russia Laravel Meetup и DevConf 2015
• сравнение производительности Golang, Scala, Elixir, Ruby, Python 3 и PHP в сферических попугаях в вакууме
• оптимизацию использования памяти и как написать свой сборщик мусора на PHP
• почему Doctrine ORM не подходит для PHP
• рендеринг ReactJS шаблонов на сервере с помощью PHP
• пример использования генераторов (yield)
• прошлое, настоящее и будущее Code Coverage от автора PHPUnit
• проблемы Zephir с PHP 7
• хорошие статьи о PHP 7, которые уже есть на хабре
• написание и тестирование API на PHP, Rails и Go от Phil Sturgeon
• TDD — Train Driven Development

Привет.

В очередной раз получив письмо от хабра, я расстроился. А дело вот в чем. На скриншоте слева мы видим нормальное адаптированное письмо. Так оно отображается во всех вменяемых мобильных почтовых клиентах, которые поддерживают media queries. Теперь давайте взглянем на скрин справа. Таким письмо мы видим в мобильных Gmail, Yandex, Mail.ru клиентах как на андроиде, так и на яблочке. Как вы уже возможно догадались, эти клиенты media queries не поддерживают.

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

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

Обратите внимание: На момент написание данной книги, большинство новых возможностей ES6 уже были имплементированы как популярными браузерами(Firefox, Chrome и т.п.), так и множеством интересных окружений. Но к сожалению не все браузеры или же окружения могут работать с ES6. Как мы говорили в прошлой главе — транспилинг это наше все. С помощью данного подхода вы можете запустить любой из приведенных в этой книге примеров. Для этого в нашем распоряжении есть ряд инструментов — ES6Fiddle (http://www.es6fiddle.net/) отличная и простая в использовании площадка, для того, чтобы попробовать ES6 и REPL для Babel (http://babeljs.io/repl/).

C момента появления Node.js его и критикуют, и превозносят. Споры о достоинствах и недостатках этого инструмента не утихают и, вероятно, не утихнут в ближайшее время. Однако часто мы упускаем из виду, что критика любого языка или платформы основывается на возникающих проблемах, зависящих от того, как мы эти платформы используем. Вне зависимости от того, насколько Node.js усложняет написание безопасного кода и облегчает его распараллеливание, платформа существует уже довольно давно, и на ней создано огромное количество надёжных и сложных веб-сервисов. Все они хорошо масштабируются и на практике доказали свою устойчивость.

Но, как и любая платформа, Node.js не застрахован от ошибок самих разработчиков. В одних случаях падает производительность, в других — система становится практически непригодной к использованию. И в этом посте я хотел бы рассмотреть 10 наиболее частых ошибок, которые делают разработчики с недостаточным опытом работы с Node.js.

Ожидание закончилось! Phalcon 2.0 уже здесь!

После более чем года разработки, мы невероятно рады объявить о выпуске финального релиза Phalcon 2.0.

Разработчик Бен Фрейн (Ben Frain) однажды заметил: «Писать CSS-код легко. Масшабировать и поддерживать его — нет».

К счастью, на просторах интернета можно найти множество решений этой проблемы. В данной статье рассмотрены основные киты структуры CSS-кода, а также интересные рыбы/млекопитающие поменьше.

Статья служит лишь памяткой или кратким справочником — для подробного ознакомления с методологиями настоятельно рекомендуется изучать оригинальную документацию.

Итак, начнем.

Документация на русском
Github репозиторий

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

Пост является краткой компиляцией переводов из этого репозитория.