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

Но была одна проблемка: я хотела красивые урлы, например http://play.csssecrets.io/pie-animated, которые бы редиректили на демки на dabblet.com. Любой нормальный человек бы скорее всего стиснул зубы и использовал какой-нибудь серверный язык для этого. Но я же не совсем нормальная :)

TL;DR: github.com/limonte/dear-habr

Уважаемая администрация ТМ, вы сделали и поддерживаете лучший русскоязычный IT-блог. Вы отлично справляетесь со своей задачей, но я верю, что пришло время сделать шаг вперёд и стать чуточку ближе к своим пользователям.



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

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

Восполняя этот пробел, хочу ответственно заявить:

Хабр, ты лучший по функционалу и UI не только в рунете, ты — абсолютный чемпион. И пусть меня кто-нибудь поправит в комментариях, приведя IT-блог на любом языке, который удобнее Хабра.

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

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

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

TL;DR: Mandrill захотел поднять цены в 4 раза. Они нашли способ через интеграцию с MailChimp.

В феврале этого года, как гром среди ясного неба, пришло письмо от Mandrill о том, что с 27го апреля он перестаёт существовать как независимый сервис и теперь чтобы им пользоваться нужно будет интегрировать свой Mandrill аккаунт в платный аккаунт MailChimp. Именно платный, пусть даже и самый дешевый. Вот как выглядит ценник MailChimp:



Напомню, что раньше Mandrill был бесплатным для небольших проектов до 12.000 писем в месяц (около 400 в день). Сейчас же как минимум $20 + сколько напосылаешь писем.

На hh/gt не нашел ни единого упоминания о этом замечательном расширении для Google Chrome. Хочу поделиться им с сообществом, потому как в последнее время оно помогает мне каждодневно экономить минут 10 — уж очень много скриншотов из социальных сетей на разных языках которые с помощью этого плагина переводятся в два клика.

Встречайте — Project Naptha (Chrome webstore).



Список возможностей:

• копировать текст с картинки
• выделить весь текст
• гуглить выделенный текст
• переводить выделенное (бета)
• проговорить (TTS) выделенное

Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.

Одним из самых главных изменений является поведение команды git push. Теперь по умолчанию (если не указана ветка) push будет осуществлен только в текущую ветку. Git 1.* по умолчанию делал push во все ветки, которые были изменены локально. Конечно же можно вернуться к прежнему поведению, для этого служит опция push.default.

Поведение Git 1.*:

git config --global push.default matching

Новое поведение по умолчанию в Git 2.0:

git config --global push.default simple

Другие изменения:

В нашей небольшой компании (6 backend + 4 frontend разработчика) для code review (далее CR) мы использовали Gerrit. Gerrit используется, например, для разработки Android. Это инструмент, дающий очень много свободы в настройке процесса CR, но мы от него отказались. Почему? Он прекрасен для суровых backend парней, который легко делают interactive rebase, merge, resolve conflict, amend commit и т.д. Люди из frontend команды по ночам плачут в подушку от тягот рабочего процесса в Gerrit.

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

Мы пришли к Bitbucket. Под катом ответы на вопросы почему Bitbucket и почему не GitHub.

Сделал изменения в коде, дебажишь и не понимаешь в чем дело — код поменял, а результат тот же. Чёрт побери, да я же отлаживаю на продакшене! Случалось такое с вами? Со мной несколько раз, сегодня вот опять. Мне это надоело и я придумал простой способ избежать таких досадных случаев.

Возможно этот трюк не заслуживает отдельного топика, большинство из вас все поймет из одной картинки:



Суть — для каждого окружения(dev, staging, prod, etc.) своя favicon-ка.

Как это сделать на примере Laravel (попиарю лишний раз этот прекрасный фреймворк):

Самая значимая вещь, которая делает код в компании Google таким хорошим проста — code review (далее CR). Google не единственная компания, использующая CR. Всем известно, что это хорошая идея и множество разработчиков делают это. Но я не видел ни одной другой большой компании, в которой CR был бы так грамотно внедрен. В Google ни одна линия кода не уходит в production пока не получит позитивную оценку на CR.

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

Что же вы получите от использования CR?

Никогда не был фанатом gitk и пользовался им редко, предпочитая консоль и настроенные алиасы. Благодаря хабраюзеру grossws, я открыл для себя tig. Это то, чего мне не хватало. После месяца использования его в работе хочу поделиться находкой с вами.

Tig это консольный GUI(TUI) для Git, основанный на Ncurses.
Основные преимущества:

• потрясающая скорость, 20,000 коммитов готовы к просмотру за четверть секунды
• консольный
• управление в vim стиле

Cкриншоты основных режимов и сравнение с gitk.

К моему удивлению на целом хабрахабре нет ни одного поста где бы было понятно написано про 3 вида git reset. Например, во второй по релевантности статье по запросу «git reset» автор пишет что «данное действие может быть двух видов: мягкого(soft reset) и жесткого(hard reset)». Режим --mixed, используемый по умолчанию, почему-то не удостоился упоминания.

Ничего удивительного, что часто видишь непонимание работы этой команды. Под катом коротко и ясно расскажу о всех трёх режимах git reset, после прочтения топика неясностей остаться не должно.

Иногда встречаю в файле .gitignore то, чего там быть никак не должно. Например, папка .idea, в которой лежат конфиги известных IDE от JetBrains. Это часть вашего рабочего окружения и она никаким боком не относится к проекту и репозиторию. Если над проектом работает несколько человек и каждый из них добавит конфиги своего окружения в .gitignore, то он превратится в нечитаемую помойку.

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

Это пост для тех, кто начинает работу с Git. Все, что здесь написано по частям можно найти в многочисленных простынях о Git на Хабре. Но я подумал, что неплохо было бы иметь отдельный предельно понятный топик, который бы гуглился по запросу «git изменение коммитов».

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

Много лет location.hash был способом в AJAX-приложении заставить работать кнопки «Назад» / «Вперёд» и, например, добавить определенное состояние страницы в избранное и вернуться к нему позже.

Сейчас, когда HTML5 считается нормой, пора обратить свое внимание на History API и забыть про location.hash. HTML5 History API проще для понимания и позволяет сделать URL чуточку красивее (без кракозябры # или #! если вы имеете дело с индексированием ajax приложения).

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

WebRTC позволяет реализовать real-time аудио/видео связь через браузер ( и ).

В этом топике я расскажу как реализовать простейшее WebRTC приложение.

В небольших личных проектах я использую SVN и bug-трекером в таких случаях служит лист формата A4. svn log никогда не был легко читаем для меня, поэтому я написал bash-скрипт, позволяющий наглядно видеть активность разработки за последнее время или список коммитов заданной даты:

Так сложилось, что в данный момент мой рабочий ноутбук оснащен лишь 2GB оперативной памяти. В связи с этим возникла необходимость оптимизации браузера, т.к. при большом количестве открытых вкладок памяти становится недостаточно и используется swap-раздел, что ведет к тормозам.

В работе мне помогает музыка, обычно это открытый таб с плейлистом Youtube. Так вот этот таб в просессе работы съедает до 500MB (!) и даже больше (Google Chrome).

Такое положение дел вынудило написать bash-скрипт, который на входе получает ID плейлиста, на выходе – mp3 файлы, которые можно слушать в любимом плеере, например, в MOC: