Ношу шлем, тяжело дышу

Музыка для работы #5

2015-03-07T00:00:00+00:00

Белый шум

2015-01-25T00:00:00+00:00

Решил пожаловаться на жизнь :D

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

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

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

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

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

Я прекрасно знаю как обычно это происходит. В большинстве случаев, статьи — простой перевод или аггрегация источников разного качества с теми выводами, на которые способен автор. Тут не пахнет каким-то качественным анализом проблемы с разных сторон. А есть ли у автора реальный опыт работы с тем, о чём он пишет? И я говорю не о паре недель. А насколько он глубоко забрался?

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

Конечно, я драматизирую. И, конечно, это всё относится не только к хабру. Фидли я практически перестал читать по той же причине.

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

Немного о том, что я прочитал:

Async JavaScript — очень и очень крутая книга, которая здорово объясняет все нюансы асинхронности в JS. Уж точно не ровня статейкам с хабра о setTimeout(function, 0).
Bash Reference Manual — внезапно очень простая и понятная книга о программировании на Bash. Я узнал о таких возможностях Bash, о которых я даже не догадывался. Правда я прочитал только половину.
Просто о Vim — потрясающе короткая, простая и действенная книга о Vim. Вот да!
Эмоциональный веб-дизайн — отличная книга о том, почему важно быть человечным. Этот лейтмотив я встречаю очень часто. Наверное, это такой, даже не голос, а скорее уже крик эпохи. Возвышенный язык, дизайн, и даже люди. Разве так ведут себя с друзьями?
«Король Лир» — одна из моих любимых книг у Шекспира и вообще. «Ромео и Джульетта» – розовые сопли на голубом заборе по сравнению с трагедией целого государства, такой глобальной и в то же время такой личной. Конечно же все умерли.

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

PS. Я ни в коем случае не предлагаю отказаться от интернета, фидли, хабра или чего-то еще. Просто так сложилось у меня. Ну, как говорится: «ОЙ ВСЁ!».

CommonJS для браузера

2014-12-14T00:00:00+00:00

слайды

Музыка для работы #4

2014-12-10T00:00:00+00:00

фото: Daniel Kulinski

Четвертый плейлист ждал своего часа с сентября. Октябрь и ноябрь выдались просто безумными — упарывался я в основном под лондонский пост-хардкор от Marmozets (спасибо, Эрик Рикка), a последние недели под пару треков Lady Sovereign по кругу (1, 2). В SC заглядывал как-то совсем эпизодически.

Но я делаю успехи, и за последний месяц мне уже не так стыдно — стыд всех предыдущих месяцев в купе с огромной скидкой на Things App убедил моего Внутреннего ~~Нарк~~^w ~~Прокр~~^w Деятеля восстановить былое величие GTD, и вот уже 3 недели я наверстываю упущенное. Честно сказать, даже не знаю, выйдет из этого что-то или нет, но пока что-то да выходит.

Хотя, кого я обманываю — конечно, Ферелден не сам себя спасет от порождений тьмы.

Ссылка на SoundCloud.

Буду рад, если вы поделитесь в комментариях треками, под которые вам нравится работать :D

Instapaper и Pocket

2014-11-28T00:00:00+00:00

Though this be madness, yet there is method in’t.

William Shakespeare

Недавно я решил прибраться в Instapaper. Я был честен и беспощаден: я удалял каждую ссылку вызывающую хотя бы толику сомнений. И я выпилил всё к чёртовой матери.

Из 150 ссылок осталось 4:

In search of the perfect JavaScript framework — статья от ребят из Opera.
What to Eat for Fat Loss — я не умею в здоровое питание, но всё время собираюсь начать.
Митио Каку: Учеба уже не будет базироваться на запоминании — не смог удалить: интересно же!
Как учить английский всю жизнь — видео доклада Рахима. Давно собирался посмотреть.

Я понял, что я всё делал неправильно. Pocket или Instapaper — не место для закладок. Не нужно класть туда всё, что попадается под руку — это трата времени. Трата внимания.

Отложенных статей всё больше. Желания их читать всё меньше. Это раздражает.

К чёртовой матери.

Я не хочу больше читать всё, что кажется интересным. Объявив презумпцию буллшита, я удалил Instapaper из яндекс браузера — добавлять редкие статьи можно через сайт. Или вообще читать сразу.

Я путал отложенные статьи и закладки. Первые полезны прямо сейчас. Вторые же могут стать полезными. Я сохраняю их на всякий случай в pinboard.in. Не читая.

Byobu

2014-11-18T00:00:00+00:00

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

До этого я использовал сплиты iTerm2, чтобы держать на одном экране несколько панелей с консолью. В принципе, этого может вполне хватить — если не закрывать терминал или использовать его лишь изредка. Я же 90% времени провожу в консоли, так что iTerm меня уже давно перестал устраивать. Ну и еще одна печальная печаль — в полноэкранном режиме iTerm не показывает открытые табы. Только если удерживать cmd пару секунд.

Сначала я попробовал tmux. Если приноровиться к его «удобным» хоткеям (хотя, я пользуюсь Vim, кого я обманываю…), то, как говорится, «мне норм». Но из коробки в tmux ~~скушные обои~~ достаточно скромный статусбар. Я хотел что-то более прекрасное, но мне было лень настраивать. Обычно на такое дело уходит добрая пара дней, а я даже не знал, буду ли я вообще использовать tmux.

И тут добрые люди показали мне byobu. Byobu — это что-то вроде набора полезных утилит и биндингов для tmux/screen. Вот здесь есть клёвое видео о том, как удобно им пользоваться.

Увы, удобные хоткеи в iTerm не заработали. Но я нашел решение, и просто перебиндил в iTerm эскейп-коды для нужных сочетаний клавиш. Говорят, что в обычном Terminal.app все должно работать отлично, но у меня там много чего другого работает из рук вон плохо, поэтому даже ради интереса я проверять не стал.

Выглядит у меня byobu примерно так:

Byobu. Сплиты и статусбар внизу.

Установка, не считая той проблемы с хоткеями вполне простая:

brew install byobu
byobu-config

Вроде бы, всё. Можно пользоваться.

Подписывайтесь на РСС. Всем добра и штурмовиков.

Чейнинг

2014-10-24T00:00:00+00:00

фото: ep_jhu

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

// …
initialize: function(options) {
  return this
    .parseOpts(options)
    .setElement($('.js-labels'))
    .tagsCollectionCreate()
    .tagsCollectionSavable()
    .renderSearch()
    .renderTags()
  ;
},
// …

Многие библиотеки поддерживают чейнинг «из коробки»: jQuery, Backbone, Underscore.

// jQuery
$('.circle')
  .animate({left: '+500px', top: '+250px'}, {duration: 800})
  .animate({
    width: '200px',
    height: '200px',
    borderRadius: "100px"
  }, {duration: 1500})
  .animate({textIndent: 100}, {
    step: function(now,fx) {
      $(this).css('-webkit-transform','rotate('+now+'deg)');
    }
  }, {
    duration: 1000,
    easing: 'linear'
  })
;

// Backbone
this.tags
  .setElement($('.js-labels'))
  .on('remove', this.save, this)
  .on('reset', this.save, this)
  .on('add', this.save, this)
;

Как работает чейнинг

Чейнить космически просто: нужно лишь возвращать this в каждом методе цепочки:

{
  // ...
  parseOptions: function(options) {
    if ('string' === typeof options) {
      this.options = {};
      this.options.tags = options;
    } else {
      this.options = options;
    }
    return this;
  },
  // ...
}

Или вот пример с плагином для jQuery:

$.fn.sticky = function () {
  this
    .each(function (el) {
      // make element sticky
    });
  return this;
};

$('.js-header')
  .sticky()
  .fadeIn()
;

Вот такой нехитрый способ одной строчкой сделать код проще.

Подписывайтесь на РСС. Всем добра и штурмовиков.

«An introduction to programming in Go», Caleb Doxsey

2014-10-14T00:00:00+00:00

Недавно я отправился в славное путешествие в Пермь. Как раз перед самой поездкой я наткнулся на бесплатную книгу о Go «An introduction to programming in Go» от Caleb Doxsey.

Книга небольшая — я прочитал ее в дороге часа за 4-5. Большая часть совсем для начинающих: системы счисления, редакторы, базовые типы. С другой стороны, в там есть много интересного о типах, которых нет в моем любимом JS: pointers, maps, slices, о структурах, интерфейсах, тестах, синтаксисе, пакетах, которые идут с языком.

Когда я открывал книгу, я хотел научиться писать на Go утилиты, и инструменты, которые я сейчас пишу на NodeJS. В этом книга полностью себя оправдала. Я закрыл последнюю страницу, и решил написать на Go CLI для поиска документации в браузере прямо из терминала с возможностью хранить в ~/.search список сайтов для поиска. Я писал эту штуку последние пару дней на NodeJS, и вот что получилось на Golang. Правда, и там, и там код требует рефакторинга, так что не судите слишком строго! :D

The Pretty Wagon to Go

После NodeJS, Go выглядит чертовски круто ( ⚆ _ ⚆ ) Теперь я понял и могу согласиться с тем, о чем писал TJ Holowaychuk в своем посте «Farewell Node.JS».

Строгая типизация, проверка типов, синтаксиса и забытых переменных во время написания кода — это потрясающе! В JS я чувствую себя уверенно только с линтером, написав достаточно unit-тестов. В Go я начинаю думать, что успешный билд — это уже тест. Строгая типизация тоже выглядит потрясающе. Правда я еще не чувствую себя уверенно с некоторыми типами, вроде pointers, slices или maps. Возможно, структуры лучше подходят для тех вещий, где я пытаюсь использовать эти типы.

Документация в Golang

Мне очень понравилась идея документации — просто пишешь комментарии над методами. godoc сделает остальное сам:

// Finds the average of a series of numbers
func Average(xs []float64) float64 {}

godoc golang-book/chapter11/math Average

Gorutines

Многопоточность в Go очень приятна. Есть gorutines в которых запускаются подпрограммы, есть channels, которые обеспечивают транспорт между gorutines. По-моему, это выглядит гораздо проще, чем EventEmmiter‘ы в NodeJS и WebWorker‘ы.

func pinger(c chan<- string)
func printer(c <-chan string)

Еще раз о книге

Книга клёвая — и определенно стоит 4 часов чтения. У меня вот получилось что-то написать на Go практически сразу, после того, как я закончил ее читать, так что это отличный способ начать. Вообще в книге, очень много совсем элементарных вещей в программировании, так что, наверное, ее могут читать даже те самые «юноши бледные со взором горячим». Но если вы уже работаете с Go, то, как мне кажется, ничего нового вы там не найдете. Книгу можно скачать в PDF бесплатно, или читать прямо на сайте, так что… А почему бы и нет? :D

фото: Martin Fisch

Подписывайтесь на РСС.

Анализ покрытия JavaScript-кода тестами

2014-10-02T00:00:00+00:00

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

И сразу дисклеймер — утилит для инструментирования и тестирования, ровно как и облачных сервисов очень много. Я использую mocha для тестов, jscoverage для инструментирования и Coveralls прикрученный к Travis как CI-сервис для анализа покрытия. Просто потому что я так привык.

Зачем знать процент покрытия тестами?

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

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

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

Инструментирование и анализ кода

Если файл один…

Инструментируем модуль:

cd my-project
jscoverage index.js index-cov.js

Затем при тестировании покрытия нужно подключить специально подготовленную cov-версию эту версию вместо настоящей библиотеки. Для этого логичнее всего использовать переменную окружения. Советуют называть эту переменную MYPROJECT_COV. Некоторые библиотеки используют просто COV, но у меня возникли конфликты где-то в jscoverage, так что лучше добавлять префиксом название проекта.

/* test/index.js */
var myProject = process.env.MYPROJECT_COV
  ? require('../index-cov')
  : require('../index');

Теперь остается запустить тесты и сгенерировать отчет о покрытии. Делается это так:

MYPROJECT_COV=1 ./node_modules/.bin/mocha -R html-cov > coverage.html

Файлы coverage.html и index-cov.js стоит добавить в .gitignore, чтобы не закоммитить случайно.

Если файлов много…

Если в проекте много JS-файлов, которые скрываются за index.js, то обычно все эти штуки убираются в lib/, который инструментируется в lib-cov/:

cd my-project
jscoverage lib lib-cov

В index.js остается только код, который, в зависимости от переменной окружения подключает lib/ или lib-cov/:

/* index.js */
module.exports = process.env.MYPROJECT_COV
  ? require('../lib-cov')
  : require('../lib');

Ну и в tests/ проверять переменную окружения уже не нужно — так что там не остается ничего необычного. Не забудте добавить lib-cov/ в .gitignore.

Coveralls

Окей, Google. Теперь мы знаем насколько наш модуль покрыт тестами — можно смотреть в coverage.html, улучшать покрытие тестами, и всячески делать этот мир лучше.

Но вот беда — coverage.html есть только локально, да и при каждой генерации отчета о покрытии он перезаписывается, не оставляя никакой истории, и, соответственно, возможности наблюдать прогресс. Если вы разрабатываете небольшой модуль — наверное, в этом нет ничего страшного. Но если вы пишете что-то посложнее, то, скорее всего, вам хотелось бы знать, какое покрытие кода в разных бранчах, пулл-реквестах, иметь возможность заглянуть в историю. А как насчет клёвого бейджа — в readme.md?

Насколько я знаю, таких сервисов не мало. К примеру, code climate может следить за покрытием кода. Я же пока остановился (хотя, конечно, я только начал :D) на Coveralls. Coveralls интегрируется с Travis CI. В .travis нужно будет добавить несколько скриптов, которые после завершения обычного тестирования будут запустят тесты на покрытие и отправят результаты на сервер Coveralls.

after_success:
  - ./node_modules/.bin/jscoverage lib lib-cov
  - MYPROJECT_COV=1 ./node_modules/.bin/mocha test -R mocha-lcov-reporter | ./node_modules/coveralls/bin/coveralls.js

package.json

Для работы Coveralls понадобится парочка модулей:

mocha-lcov-reporter, который адаптирует данные о покрытии кода в lcov-формат, с которым работает Coveralls,
coveralls — CLI-реализация API coveralls.

Кстати, ничего не мешает вынести вынести генерацию coverage.html в package.json — не писать же руками каждый раз:

// package.json
"scripts": {
  "test": "mocha",
  "test-cov": "jscoverage lib lib-cov; MS_COV=1 ./node_modules/.bin/mocha -R html-cov > coverage.html",
  // ...
}

Теперь можно просто писать npm run test-cov и не вспоминать нужные команды каждый раз. Осталось только бейдж из coverals в readme.md добавить.

Примеры

В примерах можно посмотреть .travis.yml, package.json и покликать на бейджи:

ms-to — небольшая утилита для работы с миллисекундами в JS.
page.js — роутер в духе ExpressJS только для браузера.
microlog — небольшой и удобный логгер для NodeJS приложений.

фото: Cyril Bosselut

Подписывайтесь на РСС. Всем добра и штурмовиков.

Ссылколог #9

2014-09-23T00:00:00+00:00

Есть одно очень крутое сообщество, в котором разные ребята делятся классными идеями о том, как сделать этот веб лучше. Cреди этих самых ребят @mathiasbynens, @paulirish, @sindresorhus, @isaacs, @addyosmani, контрибуторы Bootstrap, HTML5 Boilerplate и куча других крутых чуваков. Пишут туда не так уж часто, чтобы следить за сообществом было в тягость, так что советую подписываться!
NPM обновился до версии 2.0.0. Как пишут разработчики, мажорная версия сменилась потому что run scripts теперь научили принимать аргументы, но сломали обратную совместимость. Вообще, изменений много: к примеру, npm теперь использует semver@4.0.0, а еще в package.json появилась возможность указывать бранчи для зависимостей, которые ставятся с github как-то так: component/entejs#branch.
Stack Overflow запускает js-песочницы прямо в ответах.
Интересная статья о том, как использовать console.log на 100%. Я вот вообще ничего не знал о фильтрах и CSS для стилизации вывода консоли.
Интересная минималистичная замена Evernote. Похоже на нечто среднее между Writer Pro и Evernote. Мне как фанату Markdown очень интересно попробовать. Пока еще не поставил, так что если кто-то уже попробовал — поделитесь мнением :D
Забавная игра, в которой нужно строить кривые Безье.
Automations в OS X теперь можно писать на JS,
и в iOS 8 Apple добавили в Safari и WebView просто огромное количество HTML5 и JS фич. Ну не милахи ли?

фото: Kristina Alexanderson

Подписывайтесь на РСС. Всем добра и штурмовиков.

Из Pocket в Instapaper

2014-09-20T00:00:00+00:00

Недавно в твиттере @juev написал:

Обалденно! Открыл в Instapaper for iOS статью на русском языке и включил проговаривание. Так четко читает, слушать приятно.
— Denis Evsyukov (@Juev) 18 сентября 2014

И я, конечно же, решил заставить робота ласкать своим милым голоском и мои уши. Качество очень сильно зависит от статьи. В вычурных материалах ударения и эмфазисы в гротескно-напыщенных выражениях стоят отнюдь не там где им полагается, а код даже люди читают вслух очень забавно. Но в большинстве статей качества произношения вполне хватает для того, чтобы слушать статьи как подкасты. В платной версии Instacast можно даже делать плейлисты из статей. Потрясающе, не правда ли? Теперь можно ~~читать~~ слушать отложенные статьи за работой, быстрее опустошая огромный завал из Pocket’а :D

Еще одна вещь, которая продала мне Instacast — возможность выделять текст. Мне просто лень тянуться за Evernote каждый раз, когда я нахожу что-то интересное, и я давно мечтал делать это как в iBooks: провел пальцем по строчкам — готово.

Перенос статей из Pocket в Instapaper

Внезапно, я не нашел абсолютно никаких быстрых способов перенести статьи из Pocket в Instapaper: ни импорта, ни утилит. Всё что было, датировалось годом 2012, было покрыто пылью и работало с предсказуемым результатом никак.

Я посмотрел на эти пыльные труды и решил сделать все в консоли.

В Pocket нужно доскроллить страницу до конца, чтобы появились все статьи
Затем нужно собрать ссылки на все статьи и скопировать результат без первой и последней кавычки:

JSON.stringify(
  $('.original_url')
    .map(function () {
      return this.href
      .replace('http://getpocket.com/redirect?url=', '')
  }).toArray()
);

После этого идем на сайт Instapaper, и создаем переменную, куда запишем ссылки из Pocket:

  var urls = /* скопированные ссылки */

И осталось только добавить каждую ссылку через API Instapaper к себе в аккаунт:

urls.map(function (url) {
  url = decodeURIComponent(url);
  console.log(url);
  $
    .ajax({
      url: 'https://www.instapaper.com/api/add',
      data: {
        url: url,
        username: /* email */,
        password: /* password */
      }
    })
    .done(function () {
      console.log(arguments)
    })
})

Ну и, о чудо, теперь о Pocket можно забыть.

Подписывайтесь на РСС. Всем добра и штурмовиков.

«Просто о vim», Суэруп Си Эйч

2014-09-17T00:00:00+00:00

Полтора месяца прошло с тех пор, как я променял на Vim Atom и Sublime Text. Оказалось, что двух недель вполне хватает чтобы освоиться, но без этой книги я вряд ли я смог бы так быстро справиться.

С первых страниц книга завораживает магией вроде :50,100s/old/new/g. Список «случайных» примеров работы в Vim мгновенно подкупил меня, и только спустя два с лишним часа я понял, что я закутавшись в одеяле все еще, в три ночи как опытный мьсе ковыряюсь с этими примерами в Vim — не спроста же автор практически сразу рассказывает как пользоваться документацией для поиска невлезших в семьдесят две страницы объяснений, подробностей да и вообще ответов на любые интересные вопросы.

Три часа. ಠ╭╮ಠ

Ещё из книги я узнал о самом нужном в работе с vim: режимах, работе с курсором, окнами и вкладками. На сладенькое автор приберёг создание собственных плагинов и что-то вроде GTD с помощью Vim (берегись Omnifocus).

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

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

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

фото: Sean MacEntee

Подписывайтесь на РСС. Всем добра и времени.

Ссылколог #8

2014-09-15T00:00:00+00:00

Плагин для Photoshop, позволяющий отслеживать типичные проблемы, за которые верстальщики недолюбливают дизайнеров: невоспроизводимые эффекты, имена слоев в стиле «Layer 1 copy», режимы наложения, использование point-текста вместо блоков, и еще целую кучу всего. Интересно, достаточно ли вежливо будет купить такую штуку паре дизайнеров, чьи макеты я верстал? :D
Потрясающая бесплатнная гарнитура «Fira» от Mozilla. Я уже месяца 4 использую шрифт «Fira Mono» в тех редакторах, где я пишу код. Что действительно здорово — гарнитура включает шрифты «Light» и «UltraLight» и хорошие жирные начертания с поддержкой кириллицы. Так что это можно назвать достаточно хорошей бесплатной заменой «Helvetica Neue».
Простой и достаточно отзывчивый онлайн секвенсор. Похоже, что скоро музыку можно будет писать прямо в браузере.
Smashing Magazine делится списком инструментов тестирования поведения сайтов на мобильных устройствах.
Разбирая избранное твиттера наткнулся на статью @subzey о хороших и плохих названиях переменной, в которую сохраняется this в замыканиях.
Шикарно оформленный список названий цветов в css.
(づ｡◕‿‿◕｡)づ Сайт со смешными ascii-лицами, которые еще и как npm-модуль с cli можно поставить.

Подписывайтесь на РСС. Всем добра и штурмовиков.

фото: Nukamari

Интересные эксперименты на CSS, HTML и JS

2014-09-12T00:00:00+00:00

Иконка «Encription» на SVG и CSS

See the Pen Encryption by Ken Chen (@kenchen) on CodePen.

Скролл в перспективе

Думаю, эту штуку можно применить на лендинге. Только вместо скролла я бы сделал галерею.

See the Pen Scroll iPhone in iPhone by makoto (@typista) on CodePen.

IronMan рисуемый скроллом

See the Pen Scroll controlled SVG animation by Ben Laley (@paintbycode) on CodePen.

Эффект глитча на тексте

See the Pen CSS Glitched Text by Lucas Bebber (@lbebber) on CodePen.

Интересная реализация меню

See the Pen ebqmk by White Wolf Wizard (@WhiteWolfWizard) on CodePen.

Диаграммы в iWatch

See the Pen Apple Watch Radial Chart by Mark (@xna2) on CodePen.

Магия CSS-фильтров

See the Pen Playing with CSS Filters. by Sam Jarvis (@samthejarvis) on CodePen.

Видео-бекграунд

See the Pen Fullscreen HTML5 Page Background Video by Dudley Storey (@dudleystorey) on CodePen.

Разбегающиеся от курсора круги на Canvas

See the Pen lvwhs by pimskie (@pimskie) on CodePen.

Летающая геометрия на Canvas

See the Pen background animation by Alex Bergin (@abergin) on CodePen.

Паттерн «объект-представление»

2014-09-09T00:00:00+00:00

фото: shuttermanic

17 октября 2012 года Bryan Helmkamp, основатель Code Climate написал пост описывающий 7 паттернов для рефакторинга толстых ActiveRecord-моделей в Ruby on Rails. Здесь, в Crush & Lovely, у всех Rails-разработчиков этот пост является основным ориентиром для написания модульного, лаконичного, выразительного и тестируемого кода.

В этой серии статей мы расскажем о подобных концепциях в JavaScript. Как и работа Bryan Helmkamp, эта серия так же применима к моделям данных, и не менее полезна. В этом посте обсудим паттерн «объект-форму.

Паттерны рефакторинга JavaScript-приложений

Объект-представление

Лучше всего храненить логику и атрибуты необходимые только для формирования представления (HTML в обычных сайтах или JSON в API) вне моделей. Хранение специфичной информации непосредственно в модели создает путаницу в том, что является «настоящими» данными модели (и хранится в базе), а что требуется только для представления. Объект-представление работает как адаптер между «настоящими» данными модели и представлением этих данных.

Представим, например, модель товара с атрибутом price, который хранится в базе со значением 599 центов, но в представлении продукта значение изменяется на $5.99. С одной стороны, хранить это значение как второй атрибут price в модели совсем не правильно. С другой, также неправильно включать логику форматирования в шаблон.

Объект-представление «одевает» данные модели, трансформируя, добавляя или удаляя значения, и возвращая новый объект для использования в слое представления. Этот подход создает хорошее место для логики и атрибутов, связанных с представлением и не смешивает их со свойствами модели.

Я хочу отметить, что существуют различные мнения о том, что именно подразумевается под этим паттерном. Helmkamp упоминает об этом в оригинальной статье, да и у нас в Crush & Lovely это частая тема для споров — наши инженеры предпочитают не употреблять название «объект-представление», в основном, потому что обычно под представлением имеют в виду HTML, а этот паттерн может использоваться и для формирования ответа API, и для передачи данных внешним сервисам и любыми другим способами. Мы предпочитаем название «Presenter», в первую очередь потому что это имя хорошо отражает суть паттерна — формирование представления данных, вне зависимости от их конечной формы.

Пример

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

Скрипт для генерации отчетов находит каждого студента и оценки которые он получал в течение года, создавая «настоящее» представление объекта:

{
  "id": "123456",
  "firstName": "Susan",
  "lastName": "Smith",
  "gender": "f",
  "phone": "5551234567",
  "assignments": [
    {
      "grade": 0.65
    },
    {
      "grade": 0.83
    },
    {
      "grade": 0.90
    },
    ...
  ]
}

PDF-верстка отчета «глупа» и ничего не знает о форматировании данных:

...
<p class="average-grade">Average grade across all assignments: </p>
<p class="passing-status">Passing: </p>
...
<p>
  For any questions, please call the teacher at .
</p>
...

Формирование данных студента для представления станет проще если мы воспользуемся объектом-представлением, который, после создания, передадим прямо в шаблон. Вот пример того, как должен выглядеть объект-представление «одевающий» модели наших студентов для использования в шаблоне:

var _ = require('underscore');
var DetermineStudentPassingStatus = require('./determineStudentPassingStatus');
var GetAverageGradeFromAssignments = require('./getAverageGradeFromAssignments');

var StudentGradeReportPresenter = function( students ) {
  // ensure students variable is array
  this.students = ( students instanceof Array ) ? students : [students];
};

StudentGradeReportPresenter.whitelistKeys = [
  'firstName',
  'lastName',
  'isPassing',
  'averageGrade',
  'phone'
];

StudentGradeReportPresenter.prototype = _.extend( StudentGradeReportPresenter.prototype, {

  present: function() {
    var process = _.compose(
      this.sanitizeAttributes.bind( this ),
      this.getAverageGrade.bind( this ),
      this.getPassingStatus.bind( this ),
      this.formatPhoneNumber.bind( this )
    );

    this.result = _( this.students ).map( process );

    // return same type of primitive that was passed in
    // either Array or single object
    return ( this.students.length > 1 ) ? this.result : this.result[0];
  },

  sanitizeAttributes: function( student ) {
    student = _.pick.apply( null, [student].concat( StudentGradeReportPresenter.whitelistKeys ));
    return student;
  },

  getAverageGrade: function( student ) {
    student.isPassing = new DetermineStudentPassingStatus( student.id ).fromAssignments( student.assignments );
    return student;
  },

  getPassingStatus: function( student ) {
    student.averageGrade = new GetAverageGradeFromAssignments( student.assignments ).run();
    return student;
  },

  formatPhoneNumber: function( student ) {
    student.phone = student.phone.replace(/(\d{3})(\d{3})(\d{4})/, "$1-$2-$3");
    return student;
  }

});

module.exports = StudentGradeReportPresenter;

Так что, все, что нужно сделать — взять данные студентов и передать их в представление для рендеринга:

new CurrentStudentsWithAssignmentsQuery().run()
  .then(function( students ) {
    return new StudentGradeReportPresenter( students ).present();
  })
  .then(function( students ) {
    res.render('reportCard', students);
  });

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

Тестирование

Юнит-тесты для проверки изменений данных на удивление прямолинейны, так как все, что вам нужно сделаеть — передать сквозь объект-представление один объект или массив а затем получить другой на выходе. Остается только проверить корректрость обработанных данных.

var expect = require('chai').expect;
var StudentGradeReportPresenter = require('./studentGradeReportPresenter');
var Grade = require('./grade');

describe('StudentGradeReportPresenter', function(){
  var student;
  var presentedStudent;

  before(function(){
    student = {
      id: '123456',
      firstName: 'Susan',
      lastName: 'Smith',
      gender: 'f',
      phone: "5551234567",
      assignments: [
        {
          grade: new Grade(0.65)
        },
        {
          grade: new Grade(0.83)
        },
        {
          grade: new Grade(0.90)
        }
      ]
    };

    presentedStudent = new StudentGradeReportPresenter( student ).present();
  });

  it('returns only the specified properties', function(){
    expect( presentedStudent ).to.have.keys('firstName', 'lastName', 'phone', 'averageGrade', 'isPassing');
  });

  describe('.phone', function(){

    it('returns the correct value', function() {
      expect( presentedStudent.phone ).to.equal('555-123-4567');
    });

  });

  describe('.isPassing', function(){

    it('returns the correct value', function() {
      expect( presentedStudent.isPassing ).to.equal(true);
    });

  });

  describe('.averageGrade', function(){

    it('returns the correct value', function(){
      expect( presentedStudent.averageGrade ).to.equal(0.79);
    });

  });

});

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

фото: shuttermanic

Подписывайтесь на РСС. Всем добра!

«Как рушатся комплексные системы», Ричард И. Кук

2014-09-05T00:00:00+00:00

О статье

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

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

Надавно я прочитал книгу Митника «Искуство обмана», и многие приемы социальной инжинерии, если их считать теми самыми катастрофами, о которых говорит Ричард Кук, наглядно демонстрируют проблемы больших комплексных систем: несогласованность, неверный пост-анализ ошибок, поиск «главной причины»…

Как рушатся комплексные системы

1. Коплексные системы опасны по своей природе

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

2. Комплексные системы надежно защищены от ошибок

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

3. К катастрофе приводят несколько ошибок — одной не достаточно

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

4. Комплексные системы работают с ошибками, которые остаются незамеченными

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

5. Комплексные системы разрушаются в процессе работы

Из предыдущего пункта выходит, что комплексные системы функционируют в сломанном состоянии. Системы продолжают работать из-за своей избыточности, из-за людей, которые могут заставить их работать не смотря на существующие ошибки. После анализа инцидента, практически всегда видно, что система имела «прото-инцидент», близкий к катастрофе. Аргументы о том, что условия, которые привели к деградации системы возможно было распознать перед происшествием обычно основываются на достаточно наивном представлении о работе системы. Система постоянно взаимодействует с различными компонентами (организационными, техническими, с людьми), которые ошибаются и изменяются постоянно.

6. Катастрофа происходит на пересечении

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

7. Сама идея понять «главную причину» не правильна

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

8. Пост-анализ работы людей после происшествий

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

9. Человеческая роль двойственна: он и разработчик и защитник от ошибок

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

10. Все действия врачей — азартные игры

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

11. Действия — нож, раскрывающий неопределенность

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

12. Люди — адаптивный элемент комплексных систем

Практикующие врачи и первое руководящее звено активно адаптируют систему для максимизации результатов и минимизации несчастных случаев. Эти адаптации происходят время от времени. Некоторые из адаптаций включают:

Реструктуризацию системы для ослабления уявимостей,

Концентрацию критического ресурса в зонах повышенного внимания.

Обеспечивание пути для отступления или восстановления в случае внезапных или ожидаемых сбоев.

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

13. Экспертиза людей в сложной системе постоянно меняется

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

14. Изменения приводят к новой форме ошибок

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

15. Оценка «причин» ограничивает эффективность борьбы с ошибками в будущем

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

16. Безопасность — это характеристика системы, а не отдельных ее компонентов

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

17. Люди постоянно создают безопасность

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

18. Безошибочная деятельность требует экспертизы в ошибках

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

Подписывайтесь на РСС.

Ссылколог-7

2014-09-01T00:00:00+00:00

Основательная статья о CSS-архитектуре GitHub, еще и от автора Bootstrap. Об Autoprefixer, BEM, линтинге и рефакторинге.
Презентация Эдди Османи об управлении памятью в JavaScript. Много любопытных вещей, к примеру, я никак не думал, что удалив у объекта поле через delete, расходы памяти ни только не уменьшишь, а наоборот, из-за сброса внутренних оптимизаций v8, значительно увеличишь.
Как-то я искал курс по функциональному программированию в JavaScript, и тут как раз наткнулся на что-то похожее на то, что искал — Hardcore Functional Programming in JavaScript. Надо будет купить.
Крутая статья о дизайне и программировании от Романа Шамина «Как успокоиться насчет кодинга и начать жить».
Скринкасты о Vim — наверное, все о них уже знают, но, на всякий случай напишу — огромный список скринкастов для тех, кто только начал разбираться с vim.
Забавная статья «Если бы языки программирования были оружием»
15 бесплатных книг по UX

Подписывайтесь на РСС. Всем добра и штурмовиков.

фото: Nukamari

T Doug

2014-08-31T00:00:00+00:00

Strongloop And Express

2014-08-31T00:00:00+00:00

Open Source Dickishness

2014-08-31T00:00:00+00:00

Скринкаст: месяц в редакторе Vim

2014-08-30T00:00:00+00:00

Решил попробовать 2 новых штуки: сначала, месяц назад я решил, что как минимум месяц буду работать в Vim, а позднее я подумал, что было бы здорово попробовать записать скринкаст. Ну и в какой-то момент, я понял, что вполне мог бы рассказать о первом месяце работы в этом, можно сказать, обросшем легендами, редакторе.

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

Как открыть, закрыть и сохранить файл в Vim
Режимы: normal, insert, visual.
Vundle: установка и удаление плагинов
Работа с деревом проекта в NERD tree
Поиск по открытым файлам
Быстрый и удобный поиск по проекту с помощью Ack
Открытие файлов проекта по названию с помощью ctrl-p
Работа с окнами
Работа с табами
Работа с буферами

Месяц в Vim

Для тех кто решил использовать vim — вот мой .vimrc-файл. Надеюсь, вы разберетесь в почти отсутствующих комментариях к моим настройками для vim :D

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

Так что, я буду очень рад вашим комментариям, советам, замечаниям и идеям :D

«Эмоциональный веб-дизайн», Аарон Уолтер

2014-08-30T00:00:00+00:00

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

купить

Готика и гротеск

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

Эмоции и люди

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

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

Возможно дело в том, что теперь зарабатывать в сети стало проще — людям больше не нужно доказывать, что ты «надежный», «проверенный», «самый лучший», и у тебя «работают более 7000 сотрудников по всему миру». Гораздо круче признаться, что за новым стартапом стоит Серёжа, который со своей девушкой Машей и другом Ильей сделали классный сервис для удобного хранения закладок, интернет-магазин по продаже кофе или маленькую но гордую дизайн-студию.

Связь «человек-компания» больше не эффективна — ей на смену пришла связь «человек-человек», даже если второй «человек» — всего лишь программа. Эмоциональный дизайн стремится везде подчеркнуть человеческую сторону: впечатления, людей, эмоции..

Примеры

Для примера, можно взглянуть на Рокет Банк с его дружеской поддержкой пользователей (если зарегистрируетесь по моему инвайту мы оба получим по 500 рокет-рублей :D), Authentic Weather с забавными прогнозами погоды, MailChimp с его обезьяной-маскотом, Etsy с уютной атмосферой и потрясающими снимками товаров, сервис личных водителей Wheely — все эти продукты очень разные, но все они по-своему человечные и оставляющие приятные воспоминания. Еще приятнее понимать, что теплые воспоминания — это не случайно возникшие эмоции, а кропотливая и вымеренная до мелочей работа дизайнера.

Думаю вы тоже вспомните не мало подобных проектов, не так ли?

Подписывайтесь на РСС. Всем добра!

фото: jdhancock

Музыка для работы #3

2014-08-25T00:00:00+00:00

На этот раз плейлист получился достаточно эклектичным: мягкий саунд Nori в начале плавно перетекает в забавный indie-rock от «Now, Now» и «Sadnes» через немного драматичные треки Andian и Greyhat. Затем все немного оживляется более динамичной электроникой The Glitch Mob, а потом после мягкой ямы все переходит в кульминацию из breakcore/IDM от Kashiwa Daisuke и более жесткого и драматичного развития от Igorrr с многоточием трека «Memory Stream» от Peter Clark.

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

Ссылка на SoundCloud.

Буду рад, если вы поделитесь в комментариях треками, под которые вам нравится работать :D

7 паттернов для рефакторинга JavaScript-приложений

2014-08-24T00:00:00+00:00

фото: Dmitry Baranovskiy

В этой серии статей мы расскажем о подобных концепциях в JavaScript. Как и работа Bryan Helmkamp, эта серия так же применима к моделям данных, и не менее полезна.

Паттерны рефакторинга JavaScript-приложений

Подписывайтесь на РСС, чтобы не пропустить новые публикации!

Паттерн «объект-запрос»

2014-08-20T00:00:00+00:00

фото: shuttermanic

Паттерны рефакторинга JavaScript-приложений

Объект-запрос

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

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

Пример

Давайте представим какой-нибудь метод API, который возвращает список всех студентов, перешедших на следующий курс, в JSON-формате.

Без использования объекта запросов у нас могла бы быть функция в API-контроллере или объект-сервис, как в примере ниже. Стоит отметить, что DetermineStudentPassingStatus я взял из статьи об объекте-сервисе.

// expecting all collection variables to be defined

var _ = require('underscore');
var Q = require('q');
var DetermineStudentPassingStatus = require('./determineStudentPassingStatus');

var getCurrentlyPassingStudents = function() {
  var token = Q.defer();  

  // find all current students
  studentCollection.findAll({ isCurrent: true }, function( students ) {
    var studentIds = _( students ).pluck('_id');

    // find all assignments for those current students
    assignmentsCollection.findAll({ studentId: { $in: studentIds }}, function( assignments ) {
      var passingStudentIds = [];

      // group the assignments by studentId and then assess passing status
      // adding the studentId to the array of passing students if passing
      _( assignments ).chain()
        .groupBy('studentId')
        .each( function( assignments, studentId ) {
          var passingStatus = new DetermineStudentPassingStatus( studentId ).run( assignments );
          if ( passingStatus === true )
            passingStudentIds.push( studentId );
        })
        .value();

      // filter all current students down to those that are passing
      // and resolve the deferred
      var passingStudents = _( students ).filter( function( student ) {
        return passingStudentIds.indexOf( student._id ) !== -1;
      });
      token.resolve( passingStudents );
    })
  })

  return token.promise;
};

Мы сейчас не просто спустились на последние круги коллбек-ада, мы написали код, который очень сложно прочитать. Благодаря объекту запросов, мы можем создать гораздо более выразительный модуль.

var _ = require('underscore');
var async = require('async');
var Q = require('q');

var CurrentlyPassingStudentsQuery = function() {};

CurrentlyPassingStudentsQuery.prototype = _.extend( CurrentlyPassingStudentsQuery.prototype, {

  run: function() {
    this.deferred = Q.defer();

    _.bindAll( this, 'fetchCurrentStudents', 'fetchAssignmentsForCurrentStudents', 'compilePassingStudentIds', 'filterAllPassingStudents', 'result' );
    async.waterfall([
      this.fetchCurrentStudents,
      this.fetchAssignmentsForCurrentStudents,
      this.filterAllPassingStudents
    ], this.result );

    return this.deferred.promise;
  },

  fetchCurrentStudents: function( next ) {
    studentCollection.findAll({ isCurrent: true }, function( currentStudents ) {
      next( null, currentStudents );
    });
  },

  fetchAssignmentsForCurrentStudents: function( currentStudents, next ) {
    var currentStudentIds = _( currentStudents ).pluck('_id');

    assignmentsCollection.findAll({ studentId: { $in: studentIds }}, function( assignments ) {
      next( null, currentStudents, assignments );
    });
  },

  compilePassingStudentIds: function( currentStudents, assignments, next ) {
    var passingStudentIds = [];

    _( assignments ).chain()
      .groupBy('studentId')
      .each( function( assignments, studentId ) {
        var passingStatus = new DetermineStudentPassingStatus( studentId ).run( assignments );
        if ( passingStatus === true )
          passingStudentIds.push( studentId );
      })
      .value();

    next( null, passingStudentIds );
  },

  filterAllPassingStudents: function( passingStudentIds, next ) {
    var currentlyPassingStudents = _( students ).filter( function( student ) {
      return passingStudentIds.indexOf( student._id ) !== -1;
    });
    next( null, currentlyPassingStudents );
  },

  result: function( err, currentlyPassingStudents ) {
    if ( err ) {
      this.deferred.reject( err );
    } else {
      this.deferred.resolve( currentlyPassingStudents );
    }
  }

})

Сгруппировав все связанные с запросом операции, мы получили более организованную структуру и создали выразительный API, который удобно использовать в приложении. Например, в виде контроллера ExpressJS:

var CurrentlyPassingStudentsQuery = require('./currentlyPassingStudentsQuery');

// for route GET /api/students/passing
var currentlyPassingStudents = function( req, res ) {
  new CurrentlyPassingStudentsQuery().run()
    .then(function( currentlyPassingStudents ) {
      res.send( 200, currentlyPassingStudents );
    })
    .fail(function( err ) {
      res.send( 422, err );
    });
};

Данные, которые возвращает этот метод API будут простой строкой, полученной из хранилища данных, без какой-либо обработки. Зачастую, это не совсем то, что нам нужно. В этом примере, объект-запрос может быть объеденен с объектом-представлением (о котором мы напишем в следующей части). Объект-представление обеспечивает единое место для трансформации объекта перед показом пользователю.

Есть еще одна вещь, которую хочется отметить. Паттерн «объект-запрос» открывает очень интересные возможности композиции. К примеру, в коде приложения может быть много мест, где вам понадобится получить все оценки определенной группы студентов, и в этом случае мы можем вынести эту операцию в отдельный объект-запрос, and use it in the #fetchAssignmentsForCurrentStudents method.

Тестирование

Создание объекта-запроса вне контекста его использования позволяет легко покрывать его тестами. Если вы используете тестовую базу данных, все что вам нужно — загрузить необходимые данные в базу для того, чтобы обеспечить ожидаемые результаты при выполнении запросов. Остается только убедиться в том, что результаты корректные

var expect = require('chai').expect;
var CurrentlyPassingStudentsQuery = require('./currentlyPassingStudentsQuery');

describe('CurrentlyPassingStudentsQuery', function(){
  var currentlyPassingStudents;
  var err;

  before(function( done ){
    // first build all records in the necessary
    // tables for testing (steps not shown)
    // then run the Query Object
    new CurrentlyPassingStudentsQuery().run()
      .then( function( _currentlyPassingStudents ) {
        currentlyPassingStudents = _currentlyPassingStudents;
        done();
      });
      .fail( function( _err ) {
        err = _err;
        done();
      });
  });

  it('returns the correct set of records', function(){
    expect( currentlyPassingStudents ).to.have.length( expectedLength ); // however many you are expecting
  });

});

В следующем посте мы обсудим объект-представление — отличный инструмент для изоляции преобразований данных модели в их представление.

Подписывайтесь на РСС. Всем добра!

фото: shuttermanic

ASI и мистические знаки перед IIFE в JavaScript

2014-08-18T00:00:00+00:00

В JavaScript часто можно встретить такую констркуцию и различные вариации:

;(function($, undefined){
  // my awesome code here
})(jqery);

В числе странных мистических знаков перед IIFE могут встречаться, наверное, любые унарные операторы (~, ! или void) и точка с запятой. Впервые увидев в коде что-то в духе ~(function(){}()) можно и испугаться, но на самом деле причина прозаична.

ASI

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

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

Токен-нарушитель отделён от предыдущего токена как минимум одним КонцомСтроки.

Токеном-нарушителем является закрывающая фигурная скобка }.

фото: RyanRWarner

Проще всего это объяснить на примере. И так, в первом случае ASI сработает, потому что функции foo не существует на уровне грамматики языка:

var a = b + c
foo(a)

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

// 1
var a = b + c
-a ? foo() : bar()

// 2
var a = b + c
(-a) ? foo() : bar()

// 3
var a = b + c
[a, b, c].map(alert)

В этих случая ASI не сработает, и JavaScript проинтерпретирует эти строки несколько иначе, чем мы было ожидали:

// 1
var a = b + c-a ? foo() : bar()

// 2
var a = b + c(-a) ? foo() : bar()

// 3
var a = b + c[a, b, c].map(alert)

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

Сборка JavaScript

На большинстве сайтов JavaScript собирается в один файл с помощью какой-то вариации на тему cat *.js > app.js, затем еще минифицируется, и, скорее всего, регулярными выражениями, потому что строить AST-дерево достаточно долго, и только затем уже записывается в известный каждому фронтент-разработчику файл app.min.js. Но вообще, все может не ограничиваться этим: разработчики могут, к примеру, решить, что нужно вырезать console.log на production-сборке, и, конечно, регулярными выражениями (Esprima, тебя не существует!).

Так вот, благодаря всему этому процессу, может легко получиться ситуация, в которой перед (function(){})() появится что-то, что помешает ASI сделать свою работу, и наградит вас потрясающим гейзенбагом, который будет пропадать, как только вы отключите процессинг JS. Конечно эта ошибка не такая уж и сложная, но не имея представления о ASI, IIFE и минификации, можно серьезно запутаться в происходящем.

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

Подписывайтесь на РСС. Всем добра и приключений!

фото: hperticarati

Паттерн «объект-форма»

2014-08-05T00:00:00+00:00

фото: shuttermanic

Паттерны рефакторинга JavaScript-приложений

Объект-форма

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

Объект-форма инкапсулирует всю связанную с ним логику в один изолированный, сфокусированный и легко тестируемый объект. К примеру, у вас может быть форма логина на сайт, которая имеет связанный с ней объект-форму, содержащий следующую логику:

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

Польза размещения валидации моделей в объекте-форме вместо самой модели, возможно, не так очевидна, если валидация касается одной модели. Но спросите себя: «Где должна происходить проверка данных формы при её отправке на сервер?» Лично я предпочитаю держать валидацию ближе к форме, чем к базе данных, потому как это обеспечивает быструю реакцию формы на введенные данные. Плюс, гораздо семантичнее если валидация находится сразу за кнопкой «отправить», а не где-то в глубине определений. Да и такой вариант позволяет лучше контролировать процесс валидации в его специфичном контексте и не мешает использованию модели в различных других сценариях.

Фактически, если подумать более глобально — с помощью объектов-форм мы разгружаем понятие «Модель», и превращая модели в Data Access Objects (DAO). В таком формате, модель будет полагаться на объект-форму, который гарантирует, что все данные, которые получает модель — корректны. Это хороший паттерн проектирования с позиции архитектуры приложения.

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

Пример

Представим учителя, который регистрирует новых студентов в начале учебного года. Объект-форма в приложении отвечает за все аспекты обработки полученной из формы информации:

var _ = require('underscore');
var async = require('async');
var Q = require('q');
 
var NewStudentForm = function( formData ) {
  this.formData = formData;
};
 
NewStudentForm.prototype = _.extend( NewStudentForm.prototype, {

  process: function() {
    this.token = Q.defer();
 
    async.series([
      this.validate,
      this.persist,
    ], this.result );

    return this.token.promise;
  },
 
  validate: function( next ) {
    // validate object properties,
    // e.g. required fields, pattern matching, etc
    next();
  },
 
  persist: function( next ) {
    // persistence, such as write to DB or send to server
    new CreateNewStudent( this.formData ).run()
      .then(function() {
        next();
      })
      .fail( next );
  },
 
  result: function( err ) {
    // resolve or reject the deferred
    if ( err ) {
      this.error( err );
      this.token.reject( err );
    } else {
      this.token.resolve();
    }
  }
 
  error: function( err ) {
    // send errors back to the user
  }
 
});

Эта форма имеет небольшой и выразительный API для вызова в различных компонентах нашего приложения, таких как контроллер или представление:

new NewStudentForm( formData ).process()
  .then(function() {
    // success callback
  })
  .fail(function() {
    // error callback
  });

Один из потрясающих плюсов объектов-форм в JavaScript — их потенциал к переиспользованию. Мы можем валидировать данные на клиенте перед тем как отправить их на сервер, но мы не хотели бы делать это только на клиенте, потому как пользователь может скомпрометировать эту валидацию, так что мы так же добавим проверку на сервере. Кроме этого, возможно мы так же захотим добавить проверку в различных методах API.

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

var _ = require('underscore');
var async = require('async');
var Q = require('q');
 
var NewStudentFormValidator = function( formData ) {
  this.formData = formData;
};
 
NewStudentFormValidator.prototype = _.extend( NewStudentFormValidator.prototype, {

  validate: function() {
    this.token = Q.defer();
 
    async.series([
      this.validateEmail,
      this.validatePhoneNumber
      // any other validations
    ], this.result );

    return this.token.promise;
  },
 
  validateEmail: function( next ) {
    // run email validation
    next();
  },
 
  validatePhoneNumber: function( next ) {
    // run phone number validation
    next();
  },
 
  result: function( err ) {
    // resolve or reject the deferred
    if ( err ) {
      this.token.reject( err );
    } else {
      this.token.resolve();
    }
  }
 
});

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

// Client-side
new NewStudentFormValidator( formData ).validate()
  .then(function() {
    // submit form to server via standard HTTP form
    // or via AJAX
  })
  .fail(function( err ) {
    // message errors to user
  });
 
// Server-side (application route)
new NewStudentFormValidator( formData ).validate()
  .then(function() {
    return new CreateNewStudent( formData ).run();
  })
  .then(function() {
    // send user to the success page
  })
  .fail(function( err ) {
    // set flash, send user back to form
  });
 
// Server-side (API route)
new NewStudentFormValidator( formData ).validate()
  .then(function() {
    return new CreateNewStudent( formData ).run();
  })
  .then(function() {
    // send 200 OK
  })
  .fail(function( err ) {
    // send 422 with errors
  });

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

Тестирование

Не имеет значения то, как вы составляете свой объект-форму. В плане тестирования он очень прост, благодаря отвязанности от всего стека приложения. Все, что вам необходимо — создать объект с теми данными формы, которые вы должны протестировать, а затем пропустить их сквозь объект-форму. Хорошая практика — проверять и поведение при котором должны возникать ошибки. Это позволит вам убедиться, что приложение правильно сообщает о них пользователю.

var _ = require('underscore');
var expect = require('chai').expect;
var chaiAsPromised = require('chai-as-promised');
chai.use(chaiAsPromised);
 
 
var NewStudentForm = require('./NewStudentForm');
 
describe('NewStudentForm', function(){
 
  describe('Passing Data', function(){  
    var formData = {
      firstName: 'John',
      lastName: 'Smith',
      gender: 'm'
    };
 
    before(function(){
      var newStudentForm = new NewStudentForm( formData ).process();
    });
 
    it('persists the data', function(){
      // check database for persisted documents
    });
 
    it('resolves the promise', function(){
      expect( newStudentForm ).to.eventually.be.fulfilled;
    });

  });
 
  describe('Failing Data', function(){  
    var formData = {
      firstName: null,
      lastName: 'Smith',
      gender: 'm'
    };
 
    before(function(){
      var newStudentForm = new NewStudentForm( formData ).process();
    });
 
    it('does not persist the data', function(){
      // check database for absence of persisted data
    });
 
    it('rejects the promise', function(){
      expect( newStudentForm ).to.eventually.be.rejected;
    });

  });

});

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

Подписывайтесь на РСС. Всем добра!

фото: shuttermanic

Паттерн «объект-сервис»

2014-08-04T00:00:00+00:00

фото: shuttermanic

Паттерны рефакторинга JavaScript-приложений

Объект-сервис

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

Цель объекта-сервиса — изолировать операции, в соответствии со следующими принципами:

Строгость на входе и выходе. Объект-сервис создается, для работы с очень специфичными процессами, так что можно пожертвовать принципом надежности в пользу создания очень узкоспециализированного инструмента.
Тщательная документация. Этот модуль будет использоваться в совершенно неожиданных местах, поэтому очень важно хорошо задокументировать его использование.
Завершение после выполнения операции. Паттерн не должен смешиваться с рабочим процессом, который выполняется с регулярной периодичностью, постоянно слушает сообщения веб-сокетов, или выполняет любые другие операции, которые не могут быть завершены сразу. При вызове объекта-сервиса, он должен выполнить все операции (синхронные и асинхронные), затем завершиться.

Пример

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

var _ = require('underscore');
 
var DetermineStudentPassingStatus = function( student ) {
  this.student = student;
}
 
DetermineStudentPassingStatus.prototype = _.extend( DetermineStudentPassingStatus.prototype, {
 
  minimumPassingPercentage: 0.6,
 
  fromAssignments: function( assignments ) {
    return _.compose(
      this.determinePassingStatus.bind( this ),
      this.averageAssignmentGrade,
      this.extractAssignmentGrades
    )( assignments );
  },
 
  extractAssignmentGrades: function( assignments ) {
    return _.pluck( assignments, 'grade' );
  },
 
  averageAssignmentGrade: function( grades ) {
    return grades.reduce( function( memo, grade ) {
      return memo + grade.percentage;
    }, 0) / grades.length;
  },
 
  determinePassingStatus: function( averageGrade ) {
    return averageGrade >= this.minimumPassingPercentage;
  }
 
});
 
module.exports = DetermineStudentPassingStatus;

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

Тестирование

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

var expect = require('chai').expect;
var DetermineStudentPassingStatus = require('./determineStudentPassingStatus');
var Grade = require('./grade');
 
describe('DetermineStudentPassingStatus', function(){
  var student = {};
  var assignments = [
    {grade: new Grade(0.5)},
    {grade: new Grade(0.8)},
    {grade: new Grade(0.9)},
    {grade: new Grade(0.6)},
  ];
  var determineStudentPassingStatus = new DetermineStudentPassingStatus( student );
 
  describe('#extractAssignmentGrades', function(){

    it('returns an array of grade value objects', function(){
      var grades = determineStudentPassingStatus.extractAssignmentGrades( assignments );
      expect( grades[0] ).to.be.an.instanceof( Grade );
    });
 
  });
 
  describe('#averageAssignmentGrade', function(){

    it('returns the average of all of the grades', function(){
      var grades = determineStudentPassingStatus.extractAssignmentGrades( assignments );
      var averageGrade = determineStudentPassingStatus.averageAssignmentGrade( grades );
      expect( averageGrade ).to.equal( ( (0.5 + 0.8 + 0.9 + 0.6) / 4 ) );
    });
 
  });
 
  describe('#determinePassingStatus', function(){

    it('returns whether or not the student is passing', function(){
      var grades = determineStudentPassingStatus.extractAssignmentGrades( assignments );
      var averageGrade = determineStudentPassingStatus.averageAssignmentGrade( grades );
      var passing = determineStudentPassingStatus.determinePassingStatus( averageGrade );
      expect( passing ).to.be.true;
    });
 
  });
 
  describe('#fromAssignments', function(){
    var passing;
 
    it('returns the correct passing state', function(){
      passing = determineStudentPassingStatus.fromAssignments( assignments );
      expect( passing ).to.be.true;
 
      // overwrite to test false return
      assignments = [
        {grade: new Grade(0.5)},
        {grade: new Grade(0.4)},
        {grade: new Grade(0.8)},
        {grade: new Grade(0.6)},
      ];
      passing = determineStudentPassingStatus.fromAssignments( assignments );
      expect( passing ).to.be.false;
    });

  });
 
});

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

В следующем посте мы рассмотрим объекты-формы.

Подписывайтесь на РСС. Всем добра!

фото: shuttermanic

Паттерн «объект-значение»

2014-08-03T00:00:00+00:00

фото: shuttermanic

В этой серии статей мы расскажем о подобных концепциях в JavaScript. Как и работа Bryan Helmkamp, эта серия так же применима к моделям данных, и не менее полезна. Начнем с паттерна «объект-значение».

Паттерны рефакторинга JavaScript-приложений

Объект-значение

В статье Brayan’а объект-значение описывается как «простой объект, который сравнивается по значению, а не по идентификатору». Поскольку в JavaScript все объекты передаются по ссылке, подобных примеров, за исключением примитивов, нет ни в ECMAScript 5, ни даже в Harmony. Например:

  var foo = new Number( 2 );
  var bar = new Number( 2 );
  foo === bar; // => false

В этом примере примитивы сохраняются в переменные foo и bar, которые равны по значению, но, технически, эти примитивы являются объектами. Конструктор Number, не смотря на то, что он создает примитивный элемент, создаст «простой JavaScript-Object в старом стиле» (POJO), потому переменные сравниваются по ссылке, а не по значению и не будут равны между собой, хотя имеют одинаковое значение.

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

Пример

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

var _ = require('underscore');
 
var Grade = function( percentage ) {
  this.percentage = percentage;
  this.grade = this.grade( percentage );
};
 
Grade.prototype = _.extend( Grade.prototype, {
 
  grades: [
    { letter: 'A', minimumPercentage: 0.9, passing: true },
    { letter: 'B', minimumPercentage: 0.8, passing: true },
    { letter: 'C', minimumPercentage: 0.7, passing: true },
    { letter: 'D', minimumPercentage: 0.6, passing: true },
    { letter: 'F', minimumPercentage: 0,   passing: false }
  ],
 
  passingGradeLetters: function() {
    return _.chain( this.grades ).where({ passing: true }).pluck('letter').value();
  },
 
  grade: function( percentage ) {
    return _.find( this.grades, function( grade ) { return percentage >= grade.minimumPercentage; });
  },
 
  letterGrade: function() {
    return this.grade.letter;
  },
 
  isPassing: function() {
    return this.grade.passing
  },
 
  isImprovementFrom: function( grade ) {
    return this.isBetterThan( grade );
  },
 
  isBetterThan: function( grade ) {
    return this.percentage > grade.percentage;
  },
 
  valueOf: function() {
    return this.percentage;
  }
 
});
 
module.exports = Grade;

Подобная структура дает дополнительное преимущество, делая ваш код более выразительным. К примеру, теперь можно пистать так:

var firstStudent = { grade: new Grade(0.45) };
var secondStudent = { grade: new Grade(0.70) };
 
firstStudent.grade.isPassing() //=> false
firstStudent.grade.isBetterThan( secondStudent.grade ); //=> false

Перед тем как интегрировать объекты-значения в приложение, стоит отметить несколько вещей:

Методы valueOf и toString выполняют специальную роль, и рекомендуются для создания собственных объектов-значений. Применив его в Grade-объекте выше, мы добавили ему поддержку стандартного ECMAScript-синтаксиса, что позволило нам писать такие конструкции:

var myGrade = new Grade(0.65);
alert('My Grade is ' + myGrade + '!'); // alerts, 'My Grade is 0.65!'
 
var myOtherGrade = new Grade(0.75);
myGrade < myOtherGrade; // true

К сожалению, даже если два различных объекта возвращают одинаковое значение с помощью valueOf, они все равно не будут равны.

При конвертировании объекта-значения с помощью JSON.stringify, согласно конвенции, используется toJSON-метод, возвращающий значение, которое будет использовано при конвертировании в строку. Если же метод toJSON не определен, то будет использован valueOf. Если valueOf нет — объект будет конвертирован как Object, что, зачастую, не желательно.
Хороший паттерн — использовать valueOf для возвращения значения, с которым объект был инициализирован, что позволяет воссоздать этот объект с другой стороны транспорта, что очень полезно если приложение имеет клиент и сервер, между которыми передаются объекты-значения. Используя простое значение объекта на входе и на выходе, вы можете взаимодействовать с объектом-значением на сервере, затем отправить значение на клиент, используя valueOf, и воссоздать там объект заново.
Если вы предпочитаете более функциональный подход к объектам-значениям, то вы можете добавить методы в функцию-конструктор вместо ее прототипа. Посмотрите на следующий пример:

		Grade.equal = function( grade1, grade2 ) {
		  return grade1.valueOf() === grade2.valueOf();
		}
 
		var myFirstGrade = new Grade( 0.7 );
		var mySecondGrade = new Grade( 0.7 );
		Grade.equal( myFirstGrade, mySecondGrade ) // => true

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

Тестирование

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

var Grade = require('./grade');
var grade1;
var grade2;
 
describe('Grade', function() {
 
  describe('#isPassing', function() {
 
    it('returns true if grade is passing', function() {
      grade1 = new Grade(0.8);
      expect(grade1.isPassing()).to.be.true;
    });
 
    it('returns false if grade is not passing', function() {
      grade1 = new Grade(0.58);
      expect(grade1.isPassing()).to.be.false;
    })
 
  });
 
  describe('#letterGrade', function() {
 
    it('returns correct letter for percentage', function() {
      grade1 = new Grade(0.8);
      expect(grade1.letterGrade()).to.equal('B');
    });
 
    it('returns A for 100 percent', function() {
      grade1 = new Grade(1);
      expect(grade1.letterGrade()).to.equal('A');
    });
 
    it('returns F for 0 percent', function() {
      grade1 = new Grade(0);
      expect(grade1.letterGrade()).to.equal('F');
    });
 
    it('returns F for anything lower than 0.6', function() {
      grade1 = new Grade(0.4);
      expect(grade1.letterGrade()).to.equal('F');
    });
 
  });
 
  describe('#passingGradeLetters', function() {
 
    it('returns all passing letters', function() {
      grade1 = new Grade(0.8);
      expect(grade1.passingGradeLetters()).to.have.members(['A', 'B', 'C', 'D']);
    });
 
  });
 
  describe('#isImprovementFrom', function() {
 
    it('returns true if grade is better than comparison grade', function() {
      grade1 = new Grade(0.8);
      grade2 = new Grade(0.7);
      expect(grade1.isImprovementFrom( grade2 )).to.be.true;
    });
 
    it('returns false if grades are equal', function() {
      grade1 = new Grade(0.7);
      grade2 = new Grade(0.7);
      expect(grade1.isImprovementFrom( grade2 )).to.be.false;
    });
 
  });
 
  describe('#isBetterThan', function(){
 
    it('returns true if grade is better than comparison grade', function() {
      grade1 = new Grade(0.8);
      grade2 = new Grade(0.7);
      expect(grade1.isImprovementFrom( grade2 )).to.be.true;
    });
 
    it('returns false if grades are equal', function() {
      grade1 = new Grade(0.7);
      grade2 = new Grade(0.7);
      expect(grade1.isImprovementFrom( grade2 )).to.be.false;
    });
 
  });
 
});

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

В следующем посте мы рассмотрим сервисные объекты, которые являются хорошим инструментом для изолирования процедурного кода.

Подписывайтесь на РСС. Всем добра и вкусняшек!

фото: shuttermanic

Музыка для работы

2014-08-01T00:00:00+00:00

фото: Joshua Schnable

Мои плейлисты: теплый glitch, нежные девичьи голоса, интересная электроника и chillwave:

Музыка для работы #5
Немного мурашек по спине…
Музыка для работы #4
Трогательный chillwave, dream pop & glich
Музыка для работы #3
Chillwave, glitch, dream pop и немного breakcore/IDM
Музыка для работы #2
Chillwave, glitch, dream pop и сладкие девичьи голоса
Музыка для работы #1
Ambient, idm, glitch и электроника для хардворкеров

Подписывайтесь на РСС, чтобы не пропустить новые публикации!

Как yield изменит Node.js

2014-08-01T00:00:00+00:00

С выходом версии v0.11.2 Node.js обзавелся поддержкой v8-генераторов. Генераторы не легки для понимания, но, в общем, это что-то вроде оберток над функциями, которые могут выполняться множество раз, продолжая выполнение в различных местах функции.

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

Использование yield

Пример кода заменяет тысячу слов, так что давайте смотреть. Нам понадобится Node v.0.11.2, которую легко установить с помощью nvm (прим. переводчика: мне больше нравится n).

nvm install 0.11.2

Мы будем использовать основанный на промисах сервер под названием mach, и библиотеку для работы с промисами — Q. Вам нужно установить оба модуля через npm, если вы это еще не сделали.

Затем, так как мы используем новейшие фичи из v8, нам нужно указать флаг --harmony при запуске Node.

node --harmony ./generators.js

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

function sleep(millis) {
  var deferredResult = Q.defer();
  setTimeout(function() {
    deferredResult.resolve();
  }, millis);
  return deferredResult.promise;
};

Типичный сервер на основе коллбеков будет использовать чейнинг промиса, примерно так:

var mach = require('../lib');
var app  = mach.stack();
var Q    = require('q');

app.run(function(request) {
  return sleep(2000).then(function(){
    return 'Good day to you sir';
  });
});

mach.serve(app, 3333);

А теперь сделаем то же самое, но с генераторами. Определим функцию-генератор через нотацию со знаком *. Внутри такой функции мы можем использовать yield, передав ему sleep()-промис.

app.run(Q.async(function *(request) {
  yield sleep(2000);
  return 'Good day to you sir';
}));

Как только yield будет вызван, выполнение функции остановится и перейдет обратно к Q.async(). Когда промис будет разрешен, Q обеспечит возврат к выполнению генератора. В нашем случае, это произойдет как только сработает таймаут. Q.async(), в свою очередь, так же возвращает промис в mach, который обрабатывает запросы к node-серверу.

yield деле

Пример со sleep() может показаться бесполезным, так что давайте посмотрим что-нибудь получше. Скажем, доступ к обработанному содержимому запроса. Mach возвращает его в виде промиса с помощью метода request.parseContent(). Так как это промис, мы можем передать его прямо в yield:

app.run(Q.async(function *(request) {
  var body = yield request.parseContent();
  return JSON.stringify(body);
}));

С использованием yield ваши обработчики становятся проще. Еще один пример с сохранением модели.

app.post('/users', Q.async(function *(request) {
  var user = new User(request.params);

  if (yield user.save()) {
    return JSON.stringify(user);
  } else {
    return 422;
  }
}));

Развитие yield

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

Полный пример использования Mach и генераторов вы можете найти в моём форке

Подписывайтесь на РСС. Всем добра!

фото: jdhancock

Open Source Dickishness

2014-07-31T00:00:00+00:00

Ссылколог

2014-07-31T00:00:00+00:00

Здесь я коллекционирую интересные ссылки: типографика, фронтенд, дизайн, книги, и еще много всего, что мне может показаться интересным. Сначала был формат «линколога» с буфером в evernote, и только когда набиралось ссылок 5-7, я публиковал их одним постом. Со временем я понял, что это не так удобно — ощущения притупляются, что-то теряется, забывается. Так что теперь я буду публиковать ссылки в свободном формате — как получится.

Ссылколог #9
Тайная гильдия, NPM@2.0, песочницы на SO и немного о console.log и Apple
Ссылколог #8
Полезный плагин для photoshop, шрифт от Mozila, инструменты для мобильного тестирования, this в javascript, и не только это
Ссылколог-7
Курс по функциональному JS, CSS в GitHub, работа с памятью в JS, vimcasts и бесплатные книги по UX
Ссылколог-6
Три ссылки о типографике
Ссылколог-5
Подборка интересных материалов о дизайне и JavaScript
Ссылколог-4
Подборка интересных материалов о дизайне, JavaScript и управлении проектами
Ссылколог-3
Подборка интересных материалов о фронтенде, node.js и упралении разработкой.
Ссылколог-2
Подборка интересных материалов о фронтенд, Linux'е и дизайне.
Ссылколог-1
Подборка интересных материалов о фронтенде, дизайне и разных интересных штуках.

Подписывайтесь на РСС, чтобы не пропустить новые публикации!

Ведущий мейнтейнер Express о его продаже

2014-07-31T00:00:00+00:00

Я видел много обсуждений в Twitter, Github и других местах о последних изменениях в Node.js проекте Express и его передаче из аккаунта visionmedia к strongloop на GitHub, и я хотел бы поделиться своим мнением.

Для начала, несколько моментов:

Я ничего не имею против StrongLoop Inc. (the Delaware corporation) и я уверен что они очень талантливы и мотивированы.
Я ничего не имею против TJ и я правда считаю хорошим то, что он получил что-то за ту большую работу, которую он вложил в Express и связанные с ним проекты на протяжении нескольких лет.
Я не получил и не хотел бы получать деньги за Express.

Да, TJ написал мне email о том, что StrongLoop собирается спонсировать expressjs.com и писать документацию и обучающие материалы, и я принял именно это за спонсорскую поддержку. Вероятно, здесь мы не совсем поняли друг друга: я посчитал, что они просто разместят свое лого на сайте и/или в README репозитория, в разделе «спонсоры», в обмен на хорошую документацию, обучающие материалы и тд.

Я не знал, что репозитории на GitHub собираются куда-то переносить. Если бы я знал, то я бы немного подготовился к этому, сменив линки, исправив бейджи, настройки Travis CI, Coveralls.io и тд. но StrongLoop ничего не сказали о своих намерениях о перемещении проекта «ведущему мейнтейнеру, и, разумеется, никакая подготовительная работа, связанная с этим, не была выполнена.

Что касается того, что я не участвовал в работе над Express после смены владельца репозитория, я могу просто сказать, что чувствовал себя обманутым StrongLoop. Как мне показалось, они просто ждали, что я буду продолжу свою работу над express дальше, не зависимо от того, где он теперь разместился, ну, и, конечно, бесплатно. Я даже не получил сообщения вроде: «Эй, Даг, мы купили Express у TJ и мы ценим то, что ты сделал для этого проекта, и мы хотели бы чтобы ты остался ведущим мейнтейнером в нем. Что мы могли бы сделать для этого?»

Я провел много времени в своей жизни не просто делая коммиты в Express и связанные с ним проекты(на них пришлось не так много времени), а так же отвечая на каждый issue и pull request, открытый на GitHub. Я пытался работать с людьми, чтобы решить их проблемы. Я наблюдал за #express и отвечал на вопросы. На это я потратил просто огромное количество времени, и не похоже, что StrongLoop, как новый владелец, заинтересован в трате любых собственных ресурсов для того, чтобы продолжить эту работу, в отличии от сообщества, которое готово и дальше этим заниматься бесплатно.

Я не видел никого из StrongLoop, кто пытался поддержать issue-трекер перед передачей прав, и до сих пор никто из StrongLoop не помогает в IRC-канале проекта, ни в рассылке Google Groups. Я очень надеюсь, что компания, которая нацелена на получение прибыли будет что-то поддерживать самостоятельно, и продолжит развивать проект. Я уверен, что они предпочтут помогать людям, которым нужна поддержка по платным продуктам этой компании.

StrongLoop & Express

2014-07-31T00:00:00+00:00

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

Я чатился с ребятами из StrongLoop об улучшениях NodeJS, когда они преложили идею «спонсорства» Express, понимая под этим компенсацию за фактическое использование «бренда», а не исходного кода.

Я собирался разделить компенсацию с Дугласом, так как он был основным мейнтейнером Express в последнее время. Я сообщил ему об этом плане, написав email:

Эй, чел! StrongLoop хотел бы стать «спонсором» (сделать брендинг expressjs.com, например) и я подумал, почему бы и нет, хаха, я доверяю им с тех пор, как они единственные кто работал над ядром Node заботясь о том, чтобы сделать его удобным для пользователей, кроме того, хотя я и не думаю, что это на самом деле что-то значит, они хотят улучшить сайт, к примеру, добавив туда больше гайдов.

В любом случае, я хотел бы отправить тебе немного $$, потому что ты много всего там сделал. У тебя есть paypal?

Я доверяю парням из StrongLoop и я думаю очевидно, что единственный способ StrongLoop доказать это — делать Express лучше. Если бы я не думал о StrongLoop хорошо, то мне это было бы не интересно.

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

Hey TJ

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

У меня есть PayPal-аккаунт, связанный с этим email-аккаунтом, хотя я не очень заинтересован в деньгах, потому что не хочу чувствовать себя обязанным

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

Так, что вот факты. Я надеюсь, вы сможете объяснить, что вам нужно, но писать статьи, что я «тупица» это просто тупо.

TJ Holowaychuk продал ExpressJS

2014-07-31T00:00:00+00:00

фото: jdhancock

Вчера, на удивление комьюнити ExpressJS, создатель фреймворка и мейнтейнер фреймворка TJ Holowaychuk продал проект компании StrongLoop, коммерческому NodeJS-стартапу. Передача проекта шокировала активных мейнтейнеров проекта, которые занимались поддержкой фреймворка без участия автора с января. Из-за небрежной передачи прав на репозиторий мейнтейнеры лишились возможности вносить изменения в проект (позднее права восстановили).

В своем блоге StrongLoop описали передачу проекта как огромный шаг в его развитии. В этом посте продажа проекта называется «передачей спонсорского пакета» (transfer of sponsorship), но если все, что хотели сделать эти ребята — всего лишь поддержка и помощь, то зачем потребовалось переносить проект? Почему пост в блог, а не pull request был первым, что они сделали?

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

Успех проектов с открытым исходным кодом не заслуга его создателя, а результат труда всех его контрибуторов и сообщества. Успех Express — это работа людей, которые участвовали в его разработке, а не одного человека, даже если он «отвечает за ~95%+ проекта»

Когда TJ Holowaychuk потерял интерес к поддержке Express, он поступил правильно, отдав другим его поддержку и развитие. В тот момент проект, фактически, перестал ему принадлежать, даже не смотря на то, что он продолжал храниться в его GitHub-аккаунте. Это вполне обычная практика, когда проект поддерживают другие разработчики.

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

Что делает эту передачу проекта особенно печальной, так это тот факт, что права создателя были переданы компании, которая напрямую занимается монетизацией ExpressJS, продавая как профессиональные сервисы так и продукты, построенные на этом фреймворке. Благодаря возможности влиять на Express и его сообщество, StrongLoop получает несправедливое преимущество перед другими компаниями, которые предоставляют подобные сервисы. Так же это создает потенциальный конфликт интересов между продвижением Express и их коммерческим фреймворком LoopBack (который так же основан на Express).

Покупка проекта приносит пользу исключительно StrongLoop и TJ Holowaychuk, доставляя неудобства тем людям, которые занимались развитием проекта — мейнтейнерам и его коммьюнити.

От переводчика: вот ответ TJ о сложившейся ситуации

«Эмоциональный веб-дизайн», Аарон Уолтер

2014-07-30T00:00:00+00:00

Фреймворк

2014-07-28T00:00:00+00:00

Идея

Во время размышлений над архитектурой ExpressJS и KoaJS, мою голову посетила идея client side MV* фреймворка. Основная концепция и отличие от фреймворков, с которыми я работал — сверхмодульность: все компоненты, которые необходимы в проекте подключаются через Framework.use(module), сам же фреймворк предоставляет исключительно скелет, строительные леса, которые обеспечивают только базовый API для работы подключаемых модулей.

Плюсы

Простота

Являясь развитием идей ConnectJS, Express в релизе версии 4.0 перестал включать в список своих зависимостей предка, тем самым избавился от большого количества middlewares, которые достались в наследство. KoaJS, являясь развитием идей первых двух фреймворков, не включает в себя даже механизм роутинга, оставляя решение этой задачи внешним модулям.

Чем проще фреймворк, тем легче понять его внутреннюю структуру. Для понимания Express достаточно понять принцип работы middlewares.

То же самое вероятно сработает и в контексте клиенского MV* фреймворка. Я нахожу простоту — залогом гибкости и устойчивости концепции.

Гибкие мажорные обновления

Недавно Эдди Османи рассказал об Object.observable — API, позволяющем заменить биндинги, которые используются во всех MV* фреймворках на нативную реализацию, которая работает абсолютно прозрачно, поверх объектов, без необходимости бесконечных плеяд из вызовов getter’ов и setter’ов.

К сожалению, в ближайшее время вряд ли можно увидеть использование нового API в MV* фреймворках: не считая проблемы с кросс-браузерностью, монолитный Backbone не может просто взять и отказаться от legacy-кода.

Для сравнения, чтобы попробовать генераторы, скажем, в KoaJS, достаточно просто поставить послендюю unstable-версию NodeJS и запустить ее с флагом —harmony. В браузере же так просто справиться с Object.Observable не получится.

Если же иметь модульный фреймворк, то подключить, если можно так выразиться, unstable-реализацию можно всего лишь написав необходимый модуль, и подключив его к хост-фреймворку: Framework.use(webkitObservableModels).

Готово.

Гибкие минорные обновления

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

Только необходимое

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

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

Open Source Friendly

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

Форк Backbone? Такое я последний раз слышал на YAC от SoundCloud. Популярный форк Angular? Ember? Этого я не слышал. Контрибутить в эти фреймворки не просто: у монолитной системы есть большое количество пользователей, которые не могут просто так перейти на другой API. Такой подход поддерживает интерфейсы для устаревших систем. Это бремя несколько ограничивает фреймворк в развитии.

К примеру, jQuery потребовалось много времени для выпуска версии 2.0, без поддержки устаревших браузеров. В это время успели появиться различные альтернативы, такие, как Zepto.

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

Минусы

Порог входа. Модульность — это развитие простоты Backbone. Но, тут, как с Gulp и Grunt. Первый проще, но порог входа значительно выше.
Зависимость от качественного проектирования основной части фреймворка. Но эта проблема присутствует везде. Едва ли в этом случае она представляет что-то особенное.
Проблема качества сторонних модулей. Из-за низкого порога входа, этой проблеме подвержено все JS-коммьюнити.
И еще миллионы минусов, разумеется.

Итог

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

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

Ссылколог-6

2014-07-21T00:00:00+00:00

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

«Памятка верстальщика. Основные ошибки при выключке текста по левому краю, по центру и по формату» — очень интересная статья от nobelfaik о выключке текста и основных проблемах, с ней связанных.
«Выключка по формату: примеры, ошибки, как сделать» — продолжение первой статьи. На этот раз речь идет об истории и особенностях выключки по ширине. Кроме этого, автор рассказывает как добиться хорошей выключки по ширине в Illustrator’е. Правда, я еще не придумал как такое потом в веб перевенести? :)
«Конгрев как символ тирании» — потрясающая статья из журнала «Шрифт» об истории советской архитиктуры и типографики.

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

Подписывайтесь на РСС. Всем добра и штурмовиков.

фото: jdhancock

Rambler

2014-07-04T00:00:00+00:00

Уфф… Кажется, постепенно все приходит в норму, поэтому можно уже написать сюда. В начале июня я оставил проект интерактивных книг в пермской Enaza. Работа изменилась достаточно радикально — теперь я в живу Москве, работаю в Rambler и пока что занимаюсь фронтендом Ленты и ее проектов. Это очень даже интересно, потому что за последний год мое развитие в направлении фронтенда было стремительным, но несколько ограниченным рамками webkit-only проекта.

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

node-clusterize-cli — утилита для запуска и демонизации кластера из nodejs-приложения без изменения его исходного кода;
microlog — маленький но гордый логгер с поддержкой форматов. Замена монструозному winston. Сейчас как раз думаю о мажорном релизе с поддержкой транспортов, ну и с адекватным readme;
next-done — очень маленькая утилита для подсчета асинхронных коллбеков, полезна как легковесная замена большому async, в некоторых случаях;
grunt-clinch — плагин для grunt, собирающий CommonJS-модули для браузера, с помощью clinch, в котором я, опять же открыл не мало ишью, и, наверное, сделал его немного лучше;
ну и еще я сделал немного переводов, форков, фиксов, ишью в разные крутые проекты…

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

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

Я точно так же буду стараться и дальше приносить пользу сообществу, но не ради клеточек на GitHub, а ради того, для чего эти вещи и предназначены — для того, чтобы приносить пользу людям, а в особенности мне :)

Year of contributions: 1,771 total
Longest streak: 198 days
Current streak: 6 days

Музыка для работы #2

2014-06-23T00:00:00+00:00

Я продолжаю подбирать саунд-треки к обычному рабочему дню программиста: chillwave, dream pop, chiptune, glitch, нежные девичьи голоса — все как надо.

Ссылка на SoundCloud. Спасибо за комментарии к прошлому треклисту — я открыл для себя очень много интересного! Будет очень круто, если вы поделитесь со мной треками под которые вам нравится работать :)

Читаемый код — самообман

2014-05-15T00:00:00+00:00

Когда я вижу такой код return (~ memo.indexOf(item) ? null : memo.push(item)), memo; — хочется обратиться ко всем начинающим (или «продолжающим») JS разработчикам — не пишите так никогда. Совсем никогда. Вы можете подумать, что это какой-то крутой, «джедайский» код — который позволяет очень лаконично выразить вашу бизнес-логику, используя доступные только «гуру» «экзотические» операторы и конструкции. Это абсолютно не так.

мнение эксперта Хабрахабр.ру

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

Ну как, не нужен — есть прописные истины: DRY, KISS, маленькие методы, тонкие контроллеры, паттерны проектирования, линтинг, тесты, не ударяться в «однострочники», цикломатическая сложность и далее по списку. Все это, действительно, важно, потому что это делает код понятным и единообразным. Эти принципы, в силу разных причин (дедлайн, оплата за строки кода, пристрастие к героину и тд.), не вседа получается соблюдать, это нормально. Но, все равно, к этому нужно всеми силами стремиться.

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

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

Стайлгайды

Единообразие — это сверхзадача читаемого кода. Это идея, это «ради чего». Именно единообразие определяет подходящие лексемы и конструкции языка: если команда использует тернарные операторы — пишешь их, если в коде есть лексемы ~arr.indexOf(item) — используешь их. Если никто не говорит на крутом джедайском кокни, то тебе тоже не стоит хвастаться. Для оттачивания своего стиля есть GitHub, Open Source и разные диванные проекты по захвату мира — там можно придерживаться своих правил, и лучше бы делать это, опять же, единообразно. Главное, не забывать, что эксперименты это здорово, и проводить их нужно в правильном месте.

Вернемся же к этим великолепным тернаркам (вы ведь уже поняли по аватарке, что на джедайском наречии я немного понимаю?). В JavaScript есть некоторые «неудобные конструкции» — hoisting, автоподстановка точки с запятой, у которой найдется пара стрел для всех двух ваших колен, а предназначение конструкций ;(function () {…})(); или !function () {}(); я разгадывал несколько месяцев. Но все это не значит, что этими штуками грешновато пользоваться. Отнюдь! Только присмотритесь, сколько команд не используют точку с запятой, сколько действительно великолепных JavaScript-разработчиков пишут тернарные операторы вместо if/else там, где это уместно. TJ Holowaychuk, Isaac Schlueter — у каждого состоявшегося разработчика есть предпочтения, и это не просто нормально. Это отлично! А best-practices к написанию плагинов для jQuery? Пишут же ;(function () {…})();, и ничего.

«Читаемый» код

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

Если вы не знакомы с побитовым оператором ~ — разберитесь с ним. Если вы знакомы, то в чем проблема запомнить лексему ~arr.indexOf()? Вы же не думаете, что больше никто не будет ее писать, потому что она вам не нравится?

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

Возвращаясь к примеру

return (~ memo.indexOf(item) ? null : memo.push(item)), memo; даже мне кажется довольно странной конструкцией. Я бы предпочел такой вариант:

return ~memo.indexOf(item)
  ? memo
  : memo.concat([item]);

Смущают меня две вещи: null в одном из полей тернарного оператора — верный признак задуматься, действительно ли он должен быть тернарным; запятую же после тернарки я нахожу немного двусмысленной — в однострочнике немного неочевидно относится ли она к третьему операнду тернарки, или она выполнится после всей конструкции, да и причина ее возникновения — push, который возвращет длинну нового массива вместо самого массива.

Итог

В любом случае, указывать другим как писать код — это весело, но нужно иметь свою голову на плечах и понимать причины тех или иных гайдов. А «читаемость» кода, призывающая вас использовать пробелы между всеми словами, только if/else, отбивать каждую строку кода двумя переводами строки и тд. — это не более чем комформизм и вопрос привычки.

Ссылколог-5

2014-05-08T00:00:00+00:00

«Liquid for Designers» — совершенно случайно нашел хорошую документацию по шаблонизатору Liquid, который используется в Jekyll.
«Веб-лицензии для платных шрифтов могут стоить вам дорого» — Павел Радьков рассказывает о вопросе лицензии для веб-шрифтов. Раньше я как-то даже и не задумывался над этим вопросом и был очень удивлен восокой ценой.
«ECMA-262 by Dmitry Soshnikov» — очень полезные статьи о внутреннем устройсте JavaScript. Дмитрий очень понятным языком объясняет такие непростые моменты в JS, как this, замыкания, область видимости, объект переменных. Я считаю эти статьи обязательным к прочтению каждым JS-разработчиком.
«Stop Abusing JSPerf» — небольшая статья на английском о преждевременной оптимизации. Я сталкивался с тем, что под этим термином зачастую подразумевают совершенно иные вещи — тесты, написание читаемого кода и проектирование(sic!).
«Jekyll 2.0». Jekyll — движок для блога, который использует генерацию статического контента. Сайты на Jekyll можно хостить на GitHub Pages, к примеру, как это делаю я с этим самым блогом. Так вот, Jekyll наконец-то обновился до новой мажорной версии: появились коллекции, поддержка Sass и CoffeeScript и куча других очень крутых изменений.

Подписывайтесь на РСС. Всем добра и штурмовиков.

фото: jdhancock

Музыка для работы #1

2014-05-05T00:00:00+00:00

Иногда, во время работы я гоняю по кругу Nerevar Rising, иногда работаю под шаффл из iTunes, а изредка и под бодрый deathcore или умиротворяющие мотеты, но больше всего мне нравится писать код под сладкие девичьи голоса, замысловатые глитчи и обволакивающе-сказочную атмосферу электронной музыки.

Так от чего бы не сделать компиляцию самых крутых треков? Тем более, в моей ленте на SoundCloud каждый день появляются десятки новых и не менее крутых!

Ссылка на SoundCloud. А под какую музыку пишете код вы?

Ссылколог-4

2014-04-29T00:00:00+00:00

«Графический интерфейс» — Данил Ковчий о признаках хорошего дизайна, системном подходе, чувстве формы, цвета и шрифта.
«Прописные истины проектирования интерфейсов» — Антон Ловчиков нескольких о паттернах и антипаттернах в дизайне. Главное, не следовать им слепо, и не забывать о том, что все очень сильно зависит от конкретной задачи.
«QuakeJS» — порт Quake 3 — это отличный пример двух вещей: возможностей браузерных игр на JavaScript,, портирования LLVM-кода на JavaScript с помощью emscripten
«Не нравится — давай досвидания!» — Антон Волков из Alternativa Platform рассказывает о причинах проблем с коммуникациями внутри компаний.
«WakaTime» — open-source сервис для сбора статистики о времени, проведенном в IDE, а так же трекинга времени по конкретным языкам программирования.

Подписывайтесь на РСС. Всем добра и штурмовиков.

фото: jdhancock

Установка словарей на iOS без JailBreak

2014-04-28T00:00:00+00:00

Dictionary.Appender

Недавно я узнал как установить словари из Mac OS X на iOS. Самое забавное, что dictionary.appender, с помощью которого можно устанавливать словари, был выложен в App Store еще в мае 2013-го года. И вот, сижу я тут, в своем апреле 2014-го и думаю, до чего же крутая эта программа.

Еще один интересный момент в том, что приложение не подключает явно приватные API iOS, оно хитрит, получая доступ к нужным интерфейсам через зависимости публичных фреймворков. Думаю, что этот момент, вместе с тем фактом, что приложение опубликовано еще в 2013-ом году, позволяет надеяться, что эту штуковину завтра не выпилят ко всем чертям из App Store.

Установка словарей на iOS

Бесплатно через приложение можно установить один словарь. После этого, приложение за 33 рубля предложит снять ограничение на установку словарей.

Процесс установки очень простой:

В iTunes нужно выбрать iPad/iPhone > Apps > File Sharing > Dict.append;
Нажать на кнопку «Add», и загрузить словари
На устройстве зайти в Dict.append, найти среди неактивных словарей загруженные и нажать install.
Дождаться завершения установки и проверить работу.

Словари можно поискать здесь.

«Sony. Сделано в Японии», Акио Морита

2014-04-23T00:00:00+00:00

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

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

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

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

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

Мне вспоминается история о двух торговцах обувью, приехавших в одну развивающуюся страну. Один из них телеграфировал своему руководству: «Перспектив продажи нет, потому что здесь никто не носит ботинки». Другой же торговец сообщил: «Немедленно высылайте большую партию обуви, население ходит босиком и крайне нуждается в обуви».

Большая часть книги посвящена истории и философии компании Sony. Ценности, которые Акио Морита описал еще в 1986-ом актуальны и сейчас.

О философии управления

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

О техпроцессе

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

О маркетинге и наивности

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

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

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

О Генри Форде

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

О киллер-фичах

… С первым «Уокмэном» я побежал домой и проиграл на нем разную музыку. И я вдруг заметил, что мой эксперимент раздражает мою жену, которая была недовольна тем, что она не может принимать в этом участия. Прекрасно, решил я, нам надо установить две пары наушников. На следующей неделе производственное отделение изготовило еще одну модель с двумя парами наушников.

Через несколько дней я пригласил поиграть в гольф своего партнера по гольфу писателя Каору Седзи, и когда мы сели в машину, чтобы отправиться в мой клуб, я дал ему пару наушников и включил магнитофон. Я надел вторую пару наушников и наблюдал за выражением его лица. Он был удивлен и обрадован, услышав, как его жена пианистка Хироко Накамура исполняет концерт Грига для фортепиано. Он расплылся в улыбке и хотел что-то сказать, но не смог этого сделать, потому что мы оба сидели в наушниках. Я видел в этом потенциальную проблему. Я разрешил эту проблему, попросив своих сотрудников добавить к магнитофону кнопочный микрофон, чтобы два человека могли говорить друг с другом, не выключая музыки, так сказать, по «горячей линии связи».

О пивоте

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

О людях

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

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

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

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

… Я всегда говорю нашим работникам, чтобы они не придавали слишком большого значения тому, что говорят им их руководители. Я говорю: «Действуйте, не ожидая инструкций». Управляющим я объясняю, что это важный элемент в воспитании способностей и творческих возможностей их подчиненных. У молодых людей гибкий и творческий ум, поэтому менеджеры не должны вдалбливать им готовые идеи, поскольку это может подавить их личность еще до того, как она получит возможность раскрыться.

Об ошибках

… Я готов нести ответственность за любое решение, которое я принял как руководитель. Но если человека, который совершил ошибку, опозорить и лишить его возможности сделать карьеру, он может потерять стимул на всю оставшуюся трудовую жизнь, а компания лишиться всего, что он мог бы ей впоследствии дать. Если же, с другой стороны, выяснить причины ошибки и сообщить о них, человек, допустивший ошибку, никогда ее не забудет и не повторят другие. Я всегда говорю нашим людям: «Продолжайте работать и делайте то, что считаете правильным. Если вы ошибетесь, вы извлечете из ошибки урок. Только не допускайте одну и ту же ошибку дважды».

Заключение

Возможно, в виду размера книги, но, скорее всего, в виду происхождения автора, книга оставляет ощущение некоторой затянутости, которую сам Морита описал цитатой одного иностранного журналиста, посетившего страну самураев:

Мне не надо слушать, что они говорят вначале. Я начинаю прислушиваться к их словам лишь после того, как они скажут „однако“… потому что до этого они высказывают всевозможные чужие мысли. После этого слова они высказывают собственные идеи.

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

Ссылколог-3

2014-04-21T00:00:00+00:00

В этот раз всего четыре ссылки.

«Библиотека для создания динамических теней на JavaScript» — крутая штука!
Доклад Бобука об управлении программистами.
«Монолитный Node.js» — большая статья на английском о различиях в проектировании приложений между Java и Node.js.
«Выбор инструментов для фронтенд-разработки» — интересный пост от Веры Колотюк о различных подходах, которые выбирают джуниоры, миддлы и сеньоры.

Подписывайтесь на РСС. Всем добра и штурмовиков.

фото: jdhancock

Плагины для Sublime Text 3

2014-04-18T00:00:00+00:00

Еще несколько лет назад я был фанатом TextMate. Следуя заветам Томаса и Ханта, в этом редакторе я делал практически все, включая даже чтение манов. В то время Sublime Text лишь набирал популярность, и, в какой-то момент, я решил его попробовать. В те времена с TextMate 2 творились странные вещи — эта версия, в течение нескольких лет все еще была в альфе, и, похоже, не собиралась оттуда выходить. Позднее, правда, TextMate стал опенсорсным, и разработка какое-то время шла более активно, но я уже был далеко.

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

И так…

Запуск Sublime Text из консоли

В Mac OS открыть любой файл или директорию из консоли в sublime можно так:

open -a "Sublime Text" .
sudo open -a "Sublime Text" /etc/hosts

Для большего комфорта лучше использовать консольную утилиту, которая идет вкупе с Sublime Text. Устанавливается она так:

ln -s "/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl" /usr/local/bin/sublime

Кроме того, я сразу добавляю пару строк в .zshrc:

alias s='sublime' # теперь можно набирать `s .` вместо `sublime .`
export EDITOR='subl -w' # а так git commit будет открывать sublime вместо vi

Тема

Практически во всех редакторах, с которыми я работаю, я использую тему Birds of Paradise. Sublime не стал исключением, благо он умеет импортировать темы из TextMate.

Линтинг

Для линтинга JavaScript я использую jshint. Для того, чтобы заставить его работать в sublime text 3, я использую комбинацию из двух плагинов:

SublimeLinter — движок для большого количества различных линтеров;
SublimeLinter-jshint — собственно, сам линтер.

Мой .jshintrc выглядит так (в основном я пишу под nodejs):

{
  "browser": false,
  "curly": true,
  "expr": true,
  "indent": false,
  "jquery": false,
  "laxcomma": true,
  "laxbreak": true,
  "maxcomplexity": 10,
  "maxdepth": 3,
  "maxparams": 4,
  "node": true,
  "trailing": true,
  "quotmark": "single",
  "strict": true,
  "undef": true
}

Описание опций можно узнать здесь.

Кроме jshint-линтера можно присмотреться и к паре других: jscs и csslint.

CSScomb

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

Git

Для интеграции с git мне хватает GitGutter — этот плагин отмечает еще незакомиченные изменения в файле соответствующими значками на полях.

Для всего остального я использую консоль и пайпы. К примеру, посмотреть diff всего коммита можно, набрав в терминале git diff | s, так что мне вполне хватает такой минималистичной интеграции.

Emmet

Emmet — набор удобных сниппетов для html и css. Так, к примеру, лаконичное html:5>ul>li.item-$*5>span.title+span.author легким нажатием на tab превращается в…

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Document</title>
</head>
<body>
  <ul>
    <li class="item-1"><span class="title"></span><span class="author"></span></li>
    <li class="item-2"><span class="title"></span><span class="author"></span></li>
    <li class="item-3"><span class="title"></span><span class="author"></span></li>
    <li class="item-4"><span class="title"></span><span class="author"></span></li>
    <li class="item-5"><span class="title"></span><span class="author"></span></li>
  </ul>
</body>
</html>

TodoReview

Я часто пишу todo-комментарии в коде, вроде такого: /* TODO: переписать на промисы */. TodoReview умеет находить все подобные коментарии в проекте и выводить их в виде списка, чтобы можно было избавляться от технического долга систематически, а не просто в очередной раз случайно наткнувшисть на оставленное замечание.

SideBarEnhancements

SideBarEnhancements учит не особенно-то и сговорчивый сайдбар sublime text’а адекватному взаимодействию с файлами: копированию, вставке, удалению, и тд.

Разное

WordCount — счетчик слов и символов в документе. Меленькая полезная штука для оценки размера переводов и статей.
autoFilename — удобный автокомплит путей к файлам.
sublime-node-require — удобная утилита для написания require()-конструкций в NodeJS. Предлагает список из всех установленных в проекте модулей, автоматически подставляя правильные пути к ним.
Ну и куча всяких библиотек сниппетов и подсветок: stylus, mocha, jade, html5, less, handlebars, ect… Ссылки давать не буду, потому что они элементарно находятся поиском.

На этом, кажется, все. Подписывайтесь на РСС. Всем добра и штурмовиков.

фото: jdhancock

Сфокусируйтесь!

2014-04-15T00:00:00+00:00

Много воды утекло с тех пор, когда ученые начали понимать принципы работы силы воли. Сейчас об этом можно найти много информации. К примеру, можно почесть «Силу привычки» Чарльза Дахигга или статью «Я из-за вашего приложения полнею!». В общем-то, под впечатлением от Дахигга я это и пишу. Так вот, как мне кажется, сила воли является одной из фундаментальных основ продуктивности, дизайна и, в какой-то степени, осознание ее устройства помогает делать людей счастливее.

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

Можно подвести маленький итог. Сила воли — ресурс конечный, и тратится он на концентрацию и переживания, с которыми сегодня приходится сталкиваться практически постоянно: медленный непродуманный интерфейс, пробки, страх опоздания, internet explorer 8, переключение фокуса, медленный 3G, социальные сети, мудак, припарковшийся на тротуаре… Миллионы причин.

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

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

Подписывайтесь на РСС. Всем добра и штурмовиков.

фото: jdhancock

Ссылколог-2

2014-04-14T00:00:00+00:00

«25 полемических суждений не в пользу шрифтоцентризма» — очень интересная статья Владимира Кричевского о переоцененности роли шрифта в типографике.
«Интервью с Алексеем Кузнецовым» — Алексей, один из создателей сетевого стека Linux, рассказывает о пути до мейнтейнера Linux, работе над ядром, зарождении Git, Линусе и других интересных вещах.
Небольшая подборка библиотек CSS-анимаций. Сайты с хорошей анимацией — это очень круто! Главное не переборщить с этим.
«Как зацепить и удержать программиста» — Александр Алексеев о том, почему в одних компаниях интереснее других.
Расширение Natives в JavaScript — Андрей Яманов о библиотеке Sugar.js и плюсах от расширения нативных объектов в JavaScript.

Подписывайтесь на РСС. Всем добра и штурмовиков.

Заметки по книге «Getting Real», 37Signals

2014-04-11T00:00:00+00:00

Я продолжаю разбирать старые заметки. На этот раз настал черед «Getting Real». Эту книгу я прочитал где-то в начале зимы. Из книги можно вынести много всего интересного, но как мне кажется, предназначена она скорее project owner’ам — после прочтения появляется навязчивое желание запустить хороший проект. Но, увы, у многих это желание натолкнется на реальность, которая, зачастую, не рада таким порывам. Ха-ха…

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

Основная идея книги заключается в выпуске MVP-продукта в достаточно строго ограниченное время. Для этого 37Signals предлагают уделить серьезное внимание приоритетам задач, отложить в сторону свой перфекционизм и просто выпустить пусть не идеальный, но рабочий продукт. Этой философии приоритетов и ограничений подвергаются и все этапы создания проекта: дизайн, менеджмент, разработка.

Идея MVP не придумана в офисах 37Signals и, возможно кажется чем-то вполне ординарным, но, с другой стороны, в реальности, многие часто забывают о приоритизации, пытаясь сразу же выпустить идеальный продукт, потратив кучу времени. Большое количество примеров из жизни авторов, без сомнения, помогают еще лучше прочувствовать идею MVP.

Заметок оказалось не очень много. Честно говоря, я уже не помню почему.

Заметки

О клиентах

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

Миссия проекта или компании

Создавайте молитвы. Организациям нужны указательные столбы. Им нужен план; работникам каждый день нужно знать, когда они просыпаются, почему они собираются идти на работу. Этот план должен быть кратким и сладким, и затрагивать все: Почему вы существуете? Как это мотивируете? Я называю это молитвой — описание в трех-четырех словах причин, по которым вы существуете. Гай Кавасаки

О внимании к деталям

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

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

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

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

О масштабе проекта

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

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

Подписывайтесь на РСС, читайте другие статьи. Всем добра и котиков:

Ссылколог-1

2014-04-10T00:00:00+00:00

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

Чтобы ничего не пропустить, подписывайтесь на РСС-рассылку. На всякий случай, вот котик:

Частичное применение функций в JavaScript с помощью bind() — любопытный перевод статьи о каррировании функций в JS.
Develop.re — Рахим запустил социальный аггрегатор ссылок для разработчиков. Я уже узнал оттуда кучу ссылок на интересные блоги, подкасты и другие ништяки.
«Как научиться программировать с нуля?» — Вова Старков опубликовал небольшой список полезных материалов для «юнош бледных со взором горящим».
Spring-cleaning Unused CSS With Grunt, Gulp, Broccoli or Brunch — Эдди Османи о рассказывает о своей утилите для удаления неиспользуемого CSS-кода при сборке проекта.
ScrollReveal.js — маленькая библиотека для простых scroll-driven анимаций. Теперь и я использую ее, прямо в этом блоге.
imacss — CLI-утилита для компиляции изображений в CSS-файл с data-URI.
Список советов о пользовательском интерфейсе в трех частях: один, два, три.
По закону Этвуда любое приложение, которое может быть написано на JavaScript, в конце концов, будет написано на JavaScript. Собственно, вот. Glyphr Studio — бесплатный, редактор шрифтов написанный на JS.
Эндрю Ким о Sony Walkman TPS-L2 — хорошие фотографии хорошего дизайна легендарного плеера Sony. Руководство Sony сомневалось в успехе этого продукта, на что Акио Морита заявил: «Если мы не продадим до конца года сто тысяч проигрывателей, я уйду в отставку с поста председателя компании».

Заметки по книге «Как пасти котов», Рейнвотер Дж.Ханк

2014-04-07T00:00:00+00:00

Рейнвотера я прочитал достаточно давно, но так и не собрался написать о ней. И вот, недавно, разбирая mind map’ы по прочитанным в прошлом году книгам, я наткнулся на заметки, которые я делал в процессе чтения.

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

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

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

Не удивляйтесь тому, что вы чувствуете себя некомфортно в новой роли. Ощущение комфорта появится, наверное, через месяцев 6 или 12.
Песики, преданно смотрящие в глаза не нужны. Нужны хорошие программисты, не смотря на все их странности.
Важные навыки руководителя — это наставничество, терпение и проницательность.
Элегантность — это достижимое совершенство.
70% стоимости ПО — это сопровождение. Как следствие, этим можно оправдать и тесты и элегантный код. С последним, правда, есть нюансы.
Тим-лиду нужно уделять внимание коду, но стараться мыслить более глобально.
Вариант с «Днем руководить, вечером писать код» работает только некоторое время, но, в конце концов, от этого устаешь.
Делегирование — это очень важно
Руководство — это рутинные задачи руководителя (контроль сроков и тд.),
лидерство — это умение помогать команде добиваться все более высоких результатов.
Чем выше организованность, тем легче находить баланс между лидерством и руководством.
Кроме самоорганизации нужно еще помогать компании организовывать процессы, которые касаются разработки.
Цель руководителя — сделать успех результатом рутинной работы.
В работе с информацией должна быть система. Это относится как к рабочему столу, так и к информации в целом.
Обязательно нужно писать код. Хотя бы ночью.
Лучшее, что может сделать руководитель — усовершенствовать себя.
Требуйте от своих программистов во всем добиваться безупречности. Если они считают, что это затягивает время — напомните им, что элегантность — это достижимое совершенство.
Нужно думать наперед о проблемах, которые могут занять много времени. Нужно работать на опережение.
Для встречи с коллективом хватит одного раза в неделю.
45 минут на совещание более чем достаточно.
Стоит планировать промежуточные пункты, так как люди часто откладывают все до последнего.
Проектирование прежде, чем технологии.
Работа на дому — отлично! Но уровень дисциплины у всех разный. Обязательно нужно проверять, и следить за метриками работы сотрудников, которым разрешили поработать дома.
Стоит начать писать списки задач программистам, и уже невозможно от этого отказаться — все будут ждать новых задач. Именно поэтому стоит очень внимательно и серьезно подходить к этой работе.
Бизнес: сбор информации необходимой для координирования программных задач.
Спецификация: Системное отслеживание ожидаемых от вас результатов. Единицы измерения: проект, технологическая область, например.
Реализация: дотошное выявление всех подробностей, составляющих ожидаемый результат, углубленный анализ.
Задача руководителя — организовывать производство ПО. Информацию, которая этому не помогает, нужно отфильтровывать.
Большинство «Срочных замечательных просьб» размывают фокус. На такие просьбы нужно отвечать, сказав, что сейчас очень мало времени, но ты обязательно с этим разберешься! Ну и записывать это в очередь задач, чтобы не забыть.
Ваша главная задача — выпустить программный продукт.
Фокусироваться — значит, расставлять приоритеты среди тех сведений, которые претендуют на значимость, и действительно значимых сведений.
Нужно выделять время как на программирование, так и на решение административных задач.
Опирайтесь на ПО для управления проектами.
Не стоит постоянно отвлекаться на skype.
Со всей хитростью и коварством, важно стараться заставить сотрудников концентрироваться на своей работе.
Нужно формировать списки задач на неделю с приоритетами и сроками завершения.
Если разработчики достались в наследство — очень хорошая идея — предложить программистам описать свои текущие задачи. Так можно узнать не только о том, как руководили разработчиками раньше, о том, как кто из них видит свои обязанности.

Ссылка на Ozon

Автоматизация задач с помощью npm run

2014-04-05T00:00:00+00:00

Мысли о RESTful API

2014-04-03T00:00:00+00:00

Я не буду писать о том, что RESTful ни на что не годится, и место его где-то в анналах истории, среди неудачных экспериментов. Но вот свое уверенное «Awesome!» по отношению к нему станет немного более сдержанным. Вообще, с моим отношением к категоричностям, меня очень и очень радует, что я обнаружил очередное бревно в своем глазу.

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

К примеру, у нас есть метод, который по маршруту /users/:userId возвращает, скажем, такой объект:

{
  name: String,
  surname: String,
  nickame: String,
  friends: [{
    type: String,
    ref: 'User'
  }]
}

И вот, появилась у нас задача — кроме массива id друзей, покоящегося в поле friends, получать еще и их имена и ники — нет проблем! У нас же RESTful! Мы просто воспользуемся нашим известным маршрутом, и выполним запрос /users/:userId для каждого дружеского id. А позднее, разработчик API допишет новый метод для получения массива всех друзей друзей. Или не напишет — все ведь и так замечательно работает.

А графы? Мы ведь можем написать приложение которое будет рекурсивно запрашивать id друзей и строить граф связей. Право слово, это великолепно!

Серьезно. Представьте, смог бы я сделать что-то подобное, если бы у меня не было такого метода, а был бы какой-нибудь /init-app, возвращающий мне пользователя, его друзей и еще пару полезных штук, на основе информации, попавшей в сессию после авторизации? Думаю, это было бы не легко. Добавим толику хаоса — наша система будет эволюционировать, и вероятность того, что метод /init-app серьезно поменяется гораздо выше, чем у метода /users/:userId.

И вот я сижу и смотрю на iOS-приложение, которое, только во время открытия, шлет около двадцати запросов на мой замечательный RESTful-сервер. Сижу и думаю, не лучше ли сделать парочку комплексных методов, которые бы решали конкретные задачи, далекие от воздушных замков RESTful API? Что будет важнее в условиях сомнительного качества 3G: гибкость REST или гораздо меньшие транспортные расходы в комплексном API?

А может быть я просто не умею RESTful?

Радости и печали программистов

2014-03-31T00:00:00+00:00

Отсылку к этой цитате впервые я обнаружил в книге Ханка Рейнвотера «Как пасти котов», где она была дана тезисно, в сжатом виде.

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

И вот, я решил исправить эту досадную оплошность и, заодно, поделиться с вами этой замечательной цитатой.

Радости профессии

Почему заниматься программированием интересно? Какими радостями вознаграждаются те, кто им занимается?

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

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

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

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

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

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

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

Печали профессии

Не все, однако, в радость, и если предвидеть присущие этому ремеслу огорчения, то они легче переносятся.

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

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

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

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

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

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

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

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

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

Коллекция мотивирующих фильмов

2014-03-20T00:00:00+00:00

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

Indie Games: The Movie

История трех инди-игр: Super Meat Boy, FEZ и Braid. Я пересматривал этот фильм три раза. Меня восхищает увлеченность этих людей, которую вряд ли можно сопоставить с любым энтерпрайзом: эти люди живут своей игрой настолько сильно, что даже не верится что такое вообще возможно.

Senna

Документальный фильм. Аэртон Сенна — один из выдающихся гонщиков F1. Целеустремленность этого человека впечатляет.

PressPausePlay

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

Пираты силиконовой долины

История двух людей и двух компаний. Apple и Microsoft. Джобс и Гейтс.

TPB AFK: The Pirate Bay Away from Keyboard

История торрент-трекера The Pirate Bay и команды, которая работала над ним.

Objectified

Фильм о разностороннем мире промышленного дизайна.

Minecraft: История Mojang

Еще один фильм об играх. Minecraft, пожалуй, игра-легенда.

Helvetica

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

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

Первый ленточный магнитофон Sony

2014-03-19T00:00:00+00:00

Несколько дней назад я начал читать книгу Акио Мориты «Sony. Сделано в Японии», и вот сегодня я наткнулся но очень интересный отрывок. «Горькое разочарование», о котором пишет Морита, подчас настигает как стартапы, так и огромные компании, пустившиеся в погоню за инновациями. Речь идет об одной из самых обидных из проблем, с которыми можно столкнуться на этом тернистом пути.

Попробуйте прочувствовать это! Япония только что проиграла войну с Америкой. Токио, после налетов американских бомбардировщиков, выжжен практически дотла зажигательными снарядами. Несколько молодых ученых в полусгнившем деревянном сарае-лаборатории после долгих и тщетных попыток создать проволочный магнитофон, находят потрясающее решение — пленку. Импортировать готовую ленту в Японию не получится, поэтому они учатся производить ее самостоятельно. После долгих экспериментов с целлофаном, бумагой и различными покрытиями, молодым людям удается получить нужный результат. Дальше цитата из книги:

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

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

Дальше я еще не прочитал, но мне стало очень интересно, что бы было, если бы история компании Sony закончилась после этой неудачи?

О сиськах и о программировании

2014-03-02T00:00:00+00:00

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

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

Nuff said.

Изо дня в день, в различных разговорах о программировании, я слышу мнения диванных экспертов: «JavaScript решает проблемы, которых до него не существовало!», «MongoDB — это круто, но потом нужно будет все же нормальную базу сделать», «NodeJS — течет, и его никто не использует, а если использует, то в очень редких случаях», «PHP — отстой, там на каждый запрос новый тред», «Erlang — единственный нормальный язык», «Он — интроверт, интровертам нельзя управлять людьми», «У нас дороги плохие, а вот в Америке-то не так!» и тд.

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

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

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

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

Попробовал в TDD. Люто-бешено доставляет

2014-02-17T00:00:00+00:00

На самом деле — нет. Немного не TDD. Думаю, что правильнее назвать это стремлением к 100%-покрытию кода тестами: у меня нет «красненьких» и «зелененьких» этапов и рефакторинга после n-ного цикла. А иногда (бог ты мой) я пишу код до написания тестов.

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

Однажды в подъезде друзья предложили мне попробовать тесты…

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

npm i -S my-awesome-module

Большинство модулей, которые я находил в npm или на GitHub имели тесты. Более того, они использовали CI-сервис «Travis», который автоматически тестировал каждый коммит и пулл-реквест. Тогда мне это казалось каким-то излишеством. Я помню, как я разбирался с устройством LocomotiveJS, и наткнулся на модуль, который я затем показывал друзьям и говорил: «Ребята! Я решил писать так!».

Шутил, значит.

Вообще, код @jaredhanson мне очень нравится. Изучая его я заметил, что некоторые тесты — всего лишь проверка типа в module.exports.

var merge = require('../index');

describe('utils-merge', function() {
    
  it('should export function', function() {
    expect(merge).to.be.a('function');
  });
  
});

Тут-то я и задумал попробовать тесты. Написать такую штуку можно очень быстро. А «Travis.CI», прогнав тест, скажет мне наверняка — глупой ошибки синтаксиса в коде нет. Кроме того, очень быстро можно написать assert’ы, которые будут проверять соответствие результатов нашим ожиданиям.

describe('merge', function() {

  describe('an object', function() {
    var a = { foo: 'bar' }
      , b = { bar: 'baz' };
    var o = merge(a, b);
    
    it('should merge properties into first object', function() {
      expect(Object.keys(a)).to.have.length(2);
      expect(a.foo).to.be.equal('bar');
      expect(a.bar).to.be.equal('baz');
    });
    
    it('should return first argument', function() {
      expect(o).to.be.equal(a);
    });
  });

  // ...

});

Сейчас в моем проекте есть файл с тестами поведения API ExpressJS в котором около 1500 строк. Большинство из них — assert’ы, написанные банальной копипастой. Нет, это не очень-то правильно. Да, это работает.

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

Коллеги, я вот приду сейчас домой и точно напишу документацию!

Еще одна полезная особенность тестов — это документация. Идея писать тесты на свой код посетила меня еще и потому, что я стал с завидной регулярностью находить себя читающим тесты, а не докуменацию. А началось это с того, что я, разбираясь с MongooseJS, не смог понять, почему же в моем случае .populate() работает совсем не так, как я этого ожидал. Тесты, в отличии от документации, оказались более полными. Возможно, даже более понятными.

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

Вот только, в отличии от документации, тесты всегда актуальны. 1:0, документация!

Эти ваши «состояния потока»

Я помню, как еще год назад мне приходилось держать в голове детали устройства системы, чтобы понимать, в каком месте может появиться брешь при добавлении очередной фичи. Затем, значит, во время разработки фичи я, достаточно регулярно сталкивался с непроясненными требованиями: «В каком виде возвращать значения?», «Боже мой! Мы же не договорились, как он загрузит файл! А вдруг…», «В ТЗ ничего об этом не было, а я забыл спросить менеджера!»… Все это вырывало мой аватар из состояния «потока», и перемещало его в сказочно-прекрасное состояние «ПАНИКААА!!!111121 МНЕ ЖЕ ЗАВТРА НАДО!!!!1». Да и вообще, регулярно отвлекаясь на чтение обычно весьма косноречивых ТЗ, я так боюсь расплескать свою чашу концентрации.

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

А еще я ленив. Сейчас я вспоминаю, как я «тестировал» другое приложение, тоже на express, в Postman, руками отправляя запросы, вглядываясь в прыгающие в глазах буквы и цифры в теле ответа. Все это отнимает драгоценную концентрацию, я становлюсь толстым. А если подумать, сколько полезного времени уходит на это? Ведь тестировать приходится не один, и даже не 10 раз.

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

Это как и с документацией. Смещается фокус. Очищается память. Это бы, конечно, ничего, но ведь если мы и доберемся через неделю до этого костылеточáщего кода, то не сломаем ли мы ненароком систему в каком-нибудь неожиданном месте, переписав все «нормально»? А если переписывать не 10 строк? А если порефакторить захочется, чтобы внукам потом показать и листинги в рамку чтобы?

Беда-беда, огорчение. Сломать что-то случайно — это вам за милую душу. Ваши 2 часа работы окажутся парой дней, а может даже больше. А рефакторить — так, это вообще Сизифов труд — это бесконечно можно. Не страшно?

Мне страшно. И всегда страшно было. Я всегда с опаской смотрю на такие вещи. Думаю, это главная причина, по которой я убежден в том, что сразу написать «нормально» — лучше. Лучше, чем написать костыль, который пообещать себе обязательно исправить. Лучше, и, наверное, даже быстрее.

Так вот, любители рефакторинга, с тестами можно предаваться своим утехам, без страха устроить второе пришествие вашему руководителю, например.

Кода

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

А теперь я бы хотел попросить вас, друзья, о совете. Очевидно, что TDD — это не просто набор тестов. Так же очевидно, что люди, которые разработали эту методологию — отличные ребята. Я бы хотел попросить вас, друзья, посоветовать мне книгу, которую стоит обязательно прочитать, чтобы нормально научиться «в TDD».

Gulp или Grunt, да всё равно

2014-02-04T00:00:00+00:00

Реализация оператора new в JavaScript

2014-01-20T00:00:00+00:00

Вот небольшой фрагмент кода, который очень грубо реализует логику работы оператора new в JavaScript.

function newOperator(Constr, args) {
  var thisValue = Object.create(Constr.prototype); // (1)
  var result = Constr.apply(thisValue, args);
  if (typeof result === 'object' && result !== null) {
    return result; // (2)
  }
  return thisValue;
}

Прототип нового объекта, порождаемого конструктором Constr, — это Constr.prototype.
В реализации конструктора можно переопределить стандартное поведение, когда оператор new возвращает this, возвращая объект. Это может быть полезным, когда конструктор должен вернуть инстанс суб-конструктора.

Перевод книги Эдди Османи «Паттерны для масштабируемых JavaScript-приложений»

2014-01-18T00:00:00+00:00

node-clusterize-cli — кластеризация NodeJS web-сервера

2014-01-13T00:00:00+00:00

Последние полгода я занимаюсь разработкой достаточно большого web-приложения, под капотом которого ревет и дымится NodeJS. Когда дело дошло до деплоя на продакшн я задумался: «почему бы мне не использовать несколько тредов с инстансом приложения?».

Реализовав кластер, я увидел, что производительность от его использования возросла в 1,5 раза, что очень даже не плохо, учитывая малый объем потраченных усилий. Но я решил не останавливаться на этом, и сделать удобный CLI для работы с кластером, чтобы отвязать код, который отвечает за запуск кластера от конкретного приложения. Кроме того, очень хотелось демонизировать кластер, чтобы он висел себе молча в процессах, поднимал упавшие воркеры, писал в логи, и никого больше не отвлекал.

Так появился node-clusterize-cli.

Механизм работы

Модуль устроен просто — для начала он запускает мастер-процесс, в котором стартует то количество воркеров, которое вам необходимо (по-умолчанию, по два процесса на ядро), а затем отвязывает мастер-процесс от CLI интерфейса и оставляет его работать аки демона. Кроме того, мастер-процесс слушает сообщения об ошибках, которые могут произойти в воркерах, и автоматически перезапускает павших товарищей. За то, чтобы каждый запрос обрабатывался случайным процессом отвечает модуль из API NodeJS под названием «cluster».

Использование

В общем-то, все банально:

// Установка глобального модуля
$ npm i -g node-clusterize-cli
// Запуск кластера
$ clusterize --app ./app.js --workers 32 --log ./cluster.log

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

// фактически, алиас `ps -eo pid,comm | grep "clusterize master"`
$ clusterize list 
53416 app.js
// алиас на `kill -9 CLUSTER_PID`
$ clusterize kill 53416

Подробнее можно посмотреть в подсказке — clusterize -h

репозиторий на GitHub Логи нагрузочных тестов ab

Make Streak, Not Holywars

2013-12-15T00:00:00+00:00

В какой-то момент я присмотрелся к панели «Your Contributions» в своем профайле на GitHub. Помню, я тогда подумал что-то типа: «Какого черта мой аккаунт выглядит так заброшенно!? Это же не так!»

GitHub я использую практически ежедневно. В основном это сводится к чтению фида, поиску различных модулей и библиотек, примеров для вдохновения. А вот работу над своими штуковинами я постоянно откладываю. Ну как, откладываю… Периодически что-то выкладываю, но та-а-а-ак редко. И это при том, что я пишу код по будням, по выходным, по праздникам, в новый год, в ванной, в день рождения, и за обедом. И сны мне снятся на Canvas и WebGL.

Я решил, что пора бы что-то здесь менять. Не дня без коммита! Хватит тянуть с тем, что давно хотелось сделать! Хватит откладывать в долгий ящик то, с чем давно хотелось разобраться! Свои велосипеды? Почему бы нет! Будет интересней смотреть на чужие.

NPM

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

Лень

Да, лень! Лень обдумать ответственность компонента. Лень чистить его от хлама. Лень выносить в независимый модуль. Лень его потом поддерживать. Сам смотри:

Скачивай репозиторий,
вноси правки,
заливай на GitHub,
публикуй в npm,
обновляй зависимость в своем проекте.

Сплошные неудобства!

Если вы считаете так же — ударьте себя. Или попросите кого-нибудь сделать это. Черт подери! Вы ведь считаете, что монолитная, громоздкая система, которая получилась в результате вашей лени — это в порядке вещей. В старости, сидя с кружкой пива на прокуренной кухне, вы будете жаловаться своим друзьям: «Я был программистом. Это тяжелая работа». Средний палец — мой самый выразительный жест.

Модулей!

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

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

Сама необходимость создавать независимые модули помогает развивать навык проектирования.
Так как ты работаешь не с монолитным крепко связанным гордиевым узлом кода, а с набором модулей, то ошибки становятся более локализованными, следовательно легче анализировать те или иные факапы.
Фидбек от пользователей, пулл-реквесты, комьюнити, если конечно, повезет.
Приятно получить сообщение: «Ты идиот! Неужели ты не знал о библиотеке X, которая делает в точности то же самое, только лучше!?». Сидишь ты в своем вакууме, создаешь не пойми что, а тут человек показал, что, дескать, все это за тебя уже сделали. А ты такой не в курсе.

Мне нравится то что я делаю, и я хочу делать это лучше. Поэтому, 30 дней назад, я решил уделять больше внимания опенсорсу.

Итоги

В течение последних 30 дней я ежедневно что-то писал на GitHub. Гарантированный результат, который я получу за это — опыт. Если это окажется не единственным, что я получу в итоге — я буду визжать как сучка от радости!

За этот месяц я наконец-то хоть как-то разобрался с юнит-тестами, узнал, как создавать CLI с помощью NodeJS, наконец-то отрефакторил свой блог, написал плагин для GruntJS, пару переводов во Frontender Magazine. Кроме того, я выяснил и опробовал на практике кучу тонкостей языка, пополнил свои сниппеты, сделал пару полезных утилит, и обзавелся массой интересных идей.

Даже если все, что я написал за этот месяц — это никому не нужные велосипеды, ну или, что более вероятно, просто идиотская хрень, то я все равно счастлив. Я чувствую как я продвигаюсь вперед, а Streak на GitHub отличный повод продвигаться вперед ежедневно.

JavaScript, apply, массивы

2013-12-07T00:00:00+00:00

Совсем недавно увидел, как .apply может выступать адаптером для функций, которые не принимают аргументы в виде массива. Самый простой пример — это обертка над… Предположим Array.push:

var arr = new Array();
arr.pushAndLog = function () {
  console.log(arguments);
  this.push(arguments);
}

arr.push(1);
arr.pushAndLog(2,3,4);
console.log(arr); // [1,[2,3,4]]

Как видно, arguments так и отправились массивом. Отправить каждый элемент массива как аргумент функции поможет .apply:

var arr = new Array();
arr.pushAndLog = function () {
  console.log(arguments);
  this.push.apply(this, arguments);
}

arr.push(1);
arr.pushAndLog(2,3,4);
console.log(arr); // [1,2,3,4]

Примеры

/**
 * https://github.com/shuvalov-anton/express-mvc-routes/
 *
 * Здесь .apply используется для вызова app[method] с заранее 
 * неизвестным количеством аргументов.
 */
Route.prototype.createRoute = function(options) {
  var args = [];
  for (var i = options.urls.length - 1; i >= 0; i--) {
    args[0] = options.urls[i];
    args[1] = options.middlewares;
    if (options.controller) args[2] = options.controller;
    this.app[options.method].apply(this.app, args);
  }
};

/**
 * http://www.2ality.com/2013/11/initializing-arrays.html
 * 
 * А вот еще пример посложнее. .apply здесь используется для генерации
 * массива со значениями по умолчанию [0,1,2, ...]
 */
var arr = Array.apply(null, Array(10)).map(function (x, i) {
  return i 
});

Если в терминале не работают приложения node.js

2013-12-06T00:00:00+00:00

Для того, чтобы научить node.js приложения работать в консоли придется добавить в переменную окружения $PATH путь к приложениям nodejs.

Один из способов сделать это — добавить следующую строку в файл ~/.profiles:

export PATH="/usr/local/share/npm/bin/:$PATH"

Как работает event loop в Node.js

2013-12-03T00:00:00+00:00

Правильные модули

2013-11-22T00:00:00+00:00

Basic-авторизация в Express.js

2013-11-13T00:00:00+00:00

Как устроен Passport.js

2013-11-07T00:00:00+00:00

Дизайнер, архитектор, разработчик

2013-11-04T00:00:00+00:00

Сравнение скорости выполнения функций в JavaScript

2013-10-24T00:00:00+00:00

Что круче: числа или строки?

Часто возникает желание узнать, что же все-таки круче: «A» или «B». Например, сегодня я задумался — насколько медленнее работает поиск по подстроке против чисел. Да-да, именно так «насколько медленнее…». Задача — реализация прав доступа.

Экспозиция

Unix Way: права задаются в виде восьмеричного числа, которое конвертируется в двоичное, и каждый разряд этого числа отвечает за определенный тип прав. Например 5 в восмеричной — это 101 в двоичной. И теперь по порядку: 1 — администрирование, 0 — нет редактирования, 1 — чтение.
Строки: права задаются в виде строки которая состоит из букв «rwa», где «r» — чтение, «w» — редактирование, «a» — администрирование.

Для меня было очевидно, что поиск по подстроке должен быть медленнее, чем «простая математика». Но мне было интересно, на сколько медленнее. Я ждал каких-то космических значений, ибо гениальное unix-way решение выглядело очень по-гиковски. Мне казалось, что разница должна была быть в раза в три.

Как узнать, что же круче?!

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

/** 
 * from: habrahabr.ru/ somewhere in comments
 * Полезная штука для того, чтобы оценить какой оператор или конструкция быстрее.
 */
function count(f, q){
    console.profile()
    while(q--){
        f();
    }
    console.profileEnd()
}
function f1( x ){
    return typeof x == 'undefined';
}
function f2( x ){
    return typeof x === 'undefined';
}

count(f1, 10000000000);
count(f2, 10000000000);

Нууу!!1 Что круче??!!111один

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

function count(f, q){
    console.profile()
    while(q--){
        f();
    }
    console.profileEnd()
}


function f1( x ){
    var data = [7, 5, 1];
    for (var i = 0; i < data.length; i++) {
      var r = data[i];
      r[0]==1 ? 'read' : false;
      r[1]==1 ? 'write' : false;
      r[2]==1 ? 'admin' : false;
    }
}


function f2( x ){
    var data = ['r', 'rw', 'rwa'];
    for (var i = 0; i < data.length; i++) {
      var r = data[i];
      !! ~r.indexOf('r') ? 'read' : false;
      !! ~r.indexOf('w') ? 'write' : false;
      !! ~r.indexOf('a') ? 'admin' : false;
    }
}

count(f1, 10000000);
count(f2, 10000000);

Отвечай!!!!1

Неожиданно, все вышло совсем не так. Числа знатно прососали буквам. Мир никогда не будет прежним. Смотрите сами:

Unix Way: 5962ms
Строки: 4989ms

Мораль

Все эти псевдоинтеллектуальные исследования в одном браузере вряд ли имеют какой-то смысл, но делать «зарубки на лавках» как видишь, очень весело! Советую, взять на вооружение этот удобный сниппет для, так сказать, a/b тестирования.

На самом деле нет

По правде сказать, я допустил ошибку в функции получения прав из числа. И вообще, написал ее очень коряво. Правильный вариант такой:

function f1( x ){
    var data = [7, 5, 1];
    for (var i = 0; i < data.length; i++) {
      var r = data[i];
      r & 1 ? 'read' : false;
      r & 2 ? 'write' : false;
      r & 4 ? 'admin' : false;
    }
}

И тогда-то числа и начнут знатно нагибать строки. Примерно раз в 20.

Это вернуло мне веру в мир.

Классификация русского текста с помощью Natural на NodeJS

2013-09-14T00:00:00+00:00

Опыт работы с GruntJS

2013-09-09T00:00:00+00:00

Что посмотреть JavaScript разработчику

2013-08-20T00:00:00+00:00

Поделюсь небольшой подборкой полезных видео по JavaScript.

Курс по инспектору Chrome — очень полезный интерактивный курс по работе с инспектором. От основ до хардкорных штук, типа профилирования памяти.
Скринкасты по NodeJS на русском языке — высшие скринкасты по NodeJS от создателя javascript.ru.
Что помогает нам писать качественный JavaScript-код? — Дмитрий Щадей из Яндекса рассказыает об использовании JSHint, CSS Lint, Git Hooks, code review и pull requests во благо проекта.

Инструменты frontend-разработчика. Утилиты

2013-08-17T00:00:00+00:00

Я думаю что будет полезно, если я расскажу об инструментах, которые я использую в работе. По крайней мере, если меня спросят: «Какие знания могут пригодиться разработчику интерфейсов», то я смогу сослаться на этот пост.

Утилиты

OH-MY-ZSH

ZSH — это интерактивный шелл, гораздо более удобный, чем bash. oh-my-zsh — это фреймворк для ZSH с огромным количеством всевозможных плагинов и удобных штук, которые делают работу в консоли намного проще.

Git

Git — отличная система контроля версий. Если вам нечего скрывать — то можно хостить репозитории со своими проектами на GitHub. Мне очень нравится.

Grunt

Grunt — это инструмент для сборки javascript проектов из командной строки с использованием задач. Не совру, если скажу, что плагины для Grunt.js есть под любую задачу. Недавно я видел yo-генератор, в котором Grunt.js использовался для коммита файлов в git. Деплой проекта, компиляция шаблонов (jade, mustache, все что угодно), css-препроцессинг — на все есть плагины.

Советую быть осторожней с этой штукой. Вызывает привыкание.

JSHint

JSHint — это JavaScript линтер. Другими словами, инструмент для статического анализа кода на предмет различных синтаксических и логических ошибок, антипаттернов. Файл .jshintrc, в корне проекта, практически является стайлгайдом, для написания кода, помогая писать в едином стиле: в этом плане можно задать тип кавычек, требования к отступам в коде, максимальную глубину вложенности кода, нетерпимость к пробелам в конце строки и тд.

CSSComb

CSSComb — инструмент для логической сортировки CSS-правил. Я абсолютно согласен с автором, что сортировать css правила по алфавату — за гранью добра и зла. Хуже только не сортировать правила вовсе. Этот инструмент поможет во все проекте придерживаться единого порядка в CSS, не затрачивая на это больших усилий

Yeoman Generators

Yeoman Generators — это инструмент для генерации базовой структуры(скафолда) приложений. Генераторов много. Backbone, Angular, Node, Knockout, Grunt, AMD, CoffeeScript. NodeJS утилиы, сайты, плагины для GruntJS… MVC, MVVM… С помощью YO можно создавать и расширять структуру проекта буквально одной командой.

NodeJS и NPM

NodeJS — это JavaScript на сервере. Сверхбыстрый, сверхгибкий. В гибкости не последнюю роль играет npm — пакетный менеджер для node.js. Во-первых, в нем есть все. А во вторых, все чего нет в npm можно написать и выложить туда.

Я постараюсь дополнять этот пост, чтобы ничего не забыть

Как создать npm пакеты

2013-04-19T00:00:00+00:00

Стеки и очереди в JavaScript

2013-03-21T00:00:00+00:00

Так получилось, что я только недавно узнал о стеках и очередях. Точнее, раньше я знал, что они существуют, и думал, что это одно и то же. Сначала я узнал о том, что стек — не очередь, затем я узнал о реализации стека с помощью “push” и “pop”. А потом я захотел таких же простых методов, но для реализации очереди на JavaScript.

Итак…

Стек в JavaScript

Стек (англ. stack — стопка) — структура данных, представляющая из себя список элементов организованных по принципу LIFO (англ. last in — first out, «последним пришёл — первым вышел»). Чаще всего принцип работы стека сравнивают со стопкой тарелок: чтобы взять вторую сверху, нужно снять верхнюю.

Википедия

Реализация стека в JavaScript

var stack = [];        // []
stack.push( "first" ); // stack === ["first"]
stack.push( 10, 20 );  // stack === ["first", 10, 20]
var el = stack.pop();  // stack === ["first", 10] && el === 20
stack.push( 2 );       // stack === ["first", 10, 2]
el = stack.pop();      // stack === ["first", 10] && el === 2
el = stack.pop();      // stack === ["first"] el = 10
el = stack.pop();      // stack === [] && el === "first"
el = stack.pop();      // stack === [] && typeof el === "undefined"

Очередь в JavaScript

Очередь — структура данных с дисциплиной доступа к элементам «первый пришёл — первый вышел» (FIFO, First In — First Out). Добавление элемента (принято обозначать словом enqueue — поставить в очередь) возможно лишь в конец очереди, выборка — только из начала очереди (что принято называть словом dequeue — убрать из очереди), при этом выбранный элемент из очереди удаляется.

Википедия

Реализация очереди в JavaScript

var queue = [];         // []
queue.push( "first" );  // queue === ["first"]
queue.push( 10, 20 );   // queue === ["first", 10, 20]
var el = queue.shift(); // queue === [10, 20] && el === "first"
queue.push( 2 );        // queue === [10, 20, 2]
el = queue.shift();     // queue === [20, 2] && el === 10
el = queue.shift();     // queue === [2] && el === 20
el = queue.shift();     // queue === [] && el === 2
el = queue.shift();     // queue === [] && typeof el === "undefined"

Так же очередь в javascript можно организовать с помощью unshift и pop, получиться точно так же, только последний элемент окажется в начале, а первый в конце, что немного не привычно.

Установка PhoneGap. iOS

2013-03-02T00:00:00+00:00

Задокументирую создание нового проекта xcode с помощью phonegap.

скачать PhoneGap
Создать папку для проектов. Например, ~/Desktop/phonegap
Создать проект

/путь/до/phonegap/lib/ios/bin/create "путь до проекта" "имя пакета" "имя проекта"

Пример

mkdir ~/Desktop/phonegap
~/Downloads/phonegap-2.5.0/lib/ios/bin/create ~/Desktop/phonegap/helloworld org.apache.cordova.helloworld helloworld

Скринкасты по основам верстки на русском языке

2013-02-22T00:00:00+00:00

Наткнулся в сети на серию переведенных скринкастов по верстке. В видео автор нарезает макеты, готовит спрайты, пишет HTML и CSS, и комментирует свою работу.

Примечательно, что автор использует linux, emacs и zen-coding. Последний я считаю особенно полезным в верстке. Так же интересно понаблюдать на что способен emacs.

Немного неожиданно увидеть strict xhtml в doctype, да и теплый аналоговый метод создания border-radius с помощью спрайтов и png сейчас уже редкость, но в целом скринкасты достаточно подробны, а порог вхождения минимальный.

PSD2CMS.RU

Как к Mac OS X подключить HDD от DD-WRT

2013-02-10T00:00:00+00:00

Пару лет назад я поставил на свой DIR300 прошивку DD-WRT. Потом был ASUS WL500, к которому я подключил HDD, поставил transmission и открыл к диску доступ по samba. Позднее я сменил роутер на Netgear 3500L. Диск остался прежним. Ну и за пару лет там накопилось много хлама. За упорство, с которым роутер раздавал купленые на humblebundle игры (sic!), ему нужно поставить памятник при жизни.

Вдруг, что то пошло не так, и роутер перестал загружать диск. Передо мной возникла перспектива покупки нового диска и установки заново всех приложений. Их было не так уж и много, но на настройку каждого у меня уходил примерно день или два. К счастью с диском все было ок — причиной сбоя была программная ошибка. Но мне все равно пришлось потратить около недели на восстановление установленных служб и программ. Справиться с грамотной настройкой ProFTP у меня почему-то так и не вышло, да и samba постоянно отпадывала. К этому времени пользование Transmission-Daemon свелось к банальному дублированию загрузок: на ноутбук и, через веб-интерфейс, на роутер для раздачи 24/7. А позднее я совсем перестал пользоваться роутером как торрент-клиентом из-за этих неудобств.

Не так давно я сделал из старого ненужного PC сервер и спрятал его в чулан. Я поставил на него transmission, настроил vpn до своей домашней сети, удалил uTorrent с MacBook и поставил вместо него Transmission Remote GUI. До файлов всегда можно дотянуться через стабильную самбу, да и в перспективе я планирую доставить пару 2TB дисков для файлового архива. Вся эта система работает достаточно удобно, и я решил что пора бы перекинуть торренты с роутера на сервер. Но вдруг оказалось, что эта процедура не такая уж и простая — Mac OS просто не понимала что за файловая система к ней подключена. Изначально я пришел к неправильному выводу и решил, что DD-WRT использует файловую систему JFFS2 на всех дисках кроме свопа. Гугл не предолжил никакого адекватного решения. Качать 100GB через падающую каждые 10 минут samba мне ни как не хотелось.

Сегодня я решил попытаться поднять на роутере ProFTP и скинуть через него файлы, вроде как процесс не сильно отличается от настройки VPN, а там все было очень легко. ProFTP я настроил, подключился к HDD, но не увидел там ни одного файла. Я начал подумывать о том, что бы отложить переезд на еще один неопределенный срок. Прокручивая эти мысли я зашел в настройки USB на роутере, что бы проверить, тот ли каталог я показываю по FTP. Каталог был тот. Но я заметил, что файловая система там была не JFFS2, а Ext3. Смонтировать Ext3 диск на Mac OS вполне себе реально.

Mac OS X Mountain Lion и Ext3

Нужно скачать и установить два приложения:

OSXFuse — Скачать
Fuse-ext2 — Скачать

Fuse-ext2 использует MacFuse для работы. Но MacFuse не работает ни в Mac OS X Lion, ни в Mountain Lion. OSXFuse — это более современная версия MacFuse, которая лишена этих проблем, но это не значит, что Fuse-ext2 будет с работать с OSXFuse. К счастью, OSXFuse содержит MacFUSE Compatibility Layer. Для того, что бы все заработало, OSXFuse нужно установить с этим параметром.

Готово. Все установлено. Теперь достаточно вытащить диск из роутера и включить его в MacBook. Диск смонтируется автоматически. Возможно, понадобится перезагрузка. Мне не понадобилась. Мой диск смонтировался только на чтение, вероятно это связано с правами доступа, вероятно это особенность драйверов. Я решил не выяснять подробности, потому что этого мне было достаточно.

Установка transmission

2013-01-28T00:00:00+00:00

Установка transmission-daemon — штука достаточно простая. Для начала я обновлил пакеты.

sudo aptitude update

Затем я проверил, доступен ли transmission-daemon

aptitude search transmission-daemon

В случае, если демон недоступен, его нужно добавить. В файл /etc/apt/sources.list нужно дописать подходящий репозиторий. К примеру

deb http://ftp.de.debian.org/debian squeeze main

Затем заново обновить порты

sudo aptitude update

И установить transmission

sudo aptitude install transmission-daemon

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

Настройка transmission

Прежде чем править файл с настройками нужно остановить демон — при перезагрузке файл настроек затирается на предыдущий.

/etc/init.d/transmission-daemon stop

Файл с настройками лежит здесь:

/etc/transmission-daemon/settings.json

Для корректной работы сервиса я изменил следующие настройки:

{
  "download-dir": "/home/user/torrents",
  "rpc-bind-address": "192.168.1.101",
  "rpc-enabled": true,
  "rpc-port": 9091, 
  "rpc-whitelist-enabled": false, 
  "rpc-username": "User", 
  "rpc-password": "Password",
  "umask": "002"
}

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

/etc/init.d/transmission-daemon start

Transmission Remote GUI

Для того, что бы реже вспоминать о сервере с торрент-клиентом я сделал так: директория в которую качаются торренты доступна через samba, а для подключения к transmission я использую Transmission Remote GUI. Его легко можно назначить дефолтным приложением для открытия torrent-файлов, тогда скачивание торрентов не будет сильно отличаться от utorrent’а.

MacBook и монитор

2013-01-19T00:00:00+00:00

Поделюсь опытом использования MacBook Pro с дополнительным монитором.

Переходники

В MacBook Pro бывает два типа разъемов: Mini DisplayPort и Thunderbolt. Последний обратно совместим с первым. То есть, что бы подключить внешний монитор к MacBook Pro нужно купить переходник с Mini Display Port на нужный разьем. Переходники бывают оригинальные и китайские. Оригинальные стоят около 2.000 рублей, китайские же стоят около 300 рублей. Китайские уступают качеством разъемов и пайки — такого мне хватило на год, после чего он, похоже, начал люфтить и монитор подключался раза с двадцатого. Хотя, возможно, такая проблема есть у оригинальных.

Нативное управление окнами

В Mac OS X существует такое понятие как рабочий стол. Если работать с одним монитором, то рабочий стол, это, практически, состояние экрана ноутбука содержащее открытые приложения. Между этими состояниями можно переключаться, смахиванием в четыре пальца на трэкпаде. Приложения, в свою очередь можно перемещать между рабочими столами. Рабочие столы можно перемещать между собой.

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

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

Приложения для управления окнами

Есть очень много приложений для того, что бы привязать управление окнами к определенным горячим клавишам. Сейчас я пользуюсь бесплатной программой Spectacle. Кроме нее я бы выделил Size Up, и Better touch tools.

Better touch tools — это приложение для гиков, с его помощью можно сделать совершенно удивительные вещи, например, я поставил на жесты трекпэда типичные положения окна, и перенос окна на другой экран. Это очень круто, но требует приличного количество времени на то, что бы создать нужные настройки.

Настройка VPN на роутере с DD-WRT

2013-01-16T00:00:00+00:00

Расскажу о том, как настроить VPN-сервер на DD-WRT. VPN — это, вообще, очень интересная штука. Для меня, польза от VPN это шифрование траффика и безопасный доступ к домашней сети и к сервисам, которые в этой сети расположены.

Настроить VPN на DDWRT очень просто. Для начала нужно в web-интерфейсе роутера зайти в Services > VPN.

Переключатель напротив PPTP Server должен стоять в режими Enable.
Поддержка Broadcast мне не нужна.
Force MPPE Encription включу.
В DNS1 и DNS2 пропишу DNS-серверы Google: 8.8.8.8 и 8.8.4.4.
WINS1 будет равен DNS1. WINS2 можно оставить пустым.
Server IP 0.0.0.0, хотя, думаю, подойдет 127.0.0.1 или внешний IP роутера, если он статичный.
Client IP — это диапазон IP-адресов, которые присваиваются VPN-клиентам.
CHAP-Secrets — это логин и пароль для подключения к VPN серверу. Пишется так: vpn_user * vpn_password *.

Настройка VPN на MAC

Для начала, нужно создать новое подключение. Делается это с помощью кнопки + под списком существующих подключений. Interface — VPN, VPN Type — PPTP. Имя сервиса, естественно, любое. Дальше в настройках подключения нужно указать IP сервера Server Address, имя пользователя в Account Name, тип шифрования, и, нажав на Authentication Settings... выбрать тип авторизации — password и ввести пароль.

Jekyll Bootstrap и Google Analytics

2013-01-13T00:00:00+00:00

Проблема в том, что блог я генерирую на localhost’e, и выкладываю уже сгенерированый сайт на сервер. Из-за этого хитрый план разработчика Jekyll Bootstrap рушится, и аналитика ни работает нигде. По этому самому плану, если сайт генерируется в продакшне, то аналитика подключается. Если же сайт генерируется на локальной машине разработчика — аналитика не включается. Обходил я это с помощью самого простого решения — захардкодить в шаблон страницы код аналитики. Это, конечно, работало, но количество просмотренных страниц серьезно увеличивалось, когда я писал новую статью на макбуке, или когда я что-нибудь дорабатывал.

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

jekyll --safe

Но этот вариант помогает лишь в том случае, когда ты не используешь плагины. Если же ты их используешь, то в безопасном режиме эти плагины выключаются, что никуда не годится. Я решил завязать аналитику на параметр production_url в конфиге. В файле _includes/JB/analytics я написал такую штуку

{% if site.url == site.production_url %}
    {% if site.JB.analytics.google.tracking_id %}
        {% include JB/analytics-providers/google %}
    {% endif %}
    {% if site.JB.analytics.yandex.id %}
        {% include JB/analytics-providers/yandex %}
    {% endif %}
{% endif %}

Теперь, если запускать сайт с параметром --url, соответствующим ссылке на продакшн, то подключаются скрипты аналитики. Я внес все это в Rakefile.

task :default => :run
 
desc 'Deploy to server'
task :push => :build do
    sh "rsync -az --delete _site/ eva:/home/web/www/anton-shuvalov.info"
end
 
desc 'Build for deploy'
task :build do
  sh "jekyll --no-server --no-auto --url http://anton-shuvalov.info"
end
 
desc 'Run server'
task :run do
    print "> Starting jekyll...\n"
  sh "jekyll --server"
end

Яндекс метрика для Jekyll

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

JB: … analytics : google : tracking_id : ‘UA-26825614-2’ yandex : id : ‘19212163’ …

Ну и, собственно, файл _includes/JB/analitycs-providers/yandex:

  <script type="text/javascript">
    (function (d, w, c) {
      (w[c] = w[c] || []).push(function() {
        try {
          w.yaCounter{{ site.JB.analytics.yandex.id }} = new Ya.Metrika({
          id:{{ site.JB.analytics.yandex.id }},
          clickmap:true,
          trackLinks:true,
          accurateTrackBounce:true});
        } catch(e) { }
      });
     
      var n = d.getElementsByTagName("script")[0],
          s = d.createElement("script"),
          f = function () { n.parentNode.insertBefore(s, n); };
          s.type = "text/javascript";
          s.async = true;
          s.src = (d.location.protocol == "https:" ? "https:" : "http:") + "//mc.yandex.ru/metrika/watch.js";
     
      if (w.opera == "[object Opera]") {
          d.addEventListener("DOMContentLoaded", f, false);
      } else { f(); }
    })(document, window, "yandex_metrika_callbacks");
  </script>
  <noscript>
    <div>
      <img src="//mc.yandex.ru/watch/{{ site.JB.analytics.yandex.id }}" style="position:absolute; left:-9999px;" alt="" />
    </div>
  </noscript>

Как я использую статический IP

2013-01-08T00:00:00+00:00

Я решил купить статический IP. Решил купить давно. Больше года назад. Но купил только сейчас. В принципе, цена, вполне меня устраивает — 450 рублей за подключение и 20 рублей в месяц за аренду IP. Статический IP адрес мне понадобится для того, что бы привязать к домену сайт или сервис, который я буду размещать на своем сервере. Кроме этого я решил осуществить давнишнюю мечту — иметь доступ к своим домашним устройствам и сервисам из любого места.

Устройств и сервисов, которые я бы хотел видеть снаружи, у меня немного есть. А есть у меня роутер NetGear 3500L с DD-WRT на борту. В нем жесткий диск на 320Gb и торрент-клиент. И есть у меня домашний сервер, за состоянием которого я хочу иногда присматривать. Есть немного интересных штук, но я пока не добрался до них.

Подытожу. Я хочу привязать к своему домену такие штуки, как:

SSH сервера
Состояние сервера (webmin)
Веб-сервер (его пока не трогаю)
SSH роутера
Веб-интерфайс роутера
Торрент клиент
FTP-сервер (его тоже не трогаю)

План

Во-первых, нужно привязать субдомены (например, torrents.anton-shuvalov.info, webmin.anton-shuvalov.info) к своему статическому IP адресу, потом подвинуть с 80 порта веб-интерфейс DD-WRT, а на 80-ом поднять nginx. На nginx пробросить прокси ко всем сервисам, вроде:

torrents.anton-shuvalov.info > 192.168.0.1:9091

Как привязать домен к IP

Привязка домена к IP делается с помощью A записи на NS-сервере к которому привязан домен. Мой домен привязан к NS-серверам selectel. Создать там A запись очень просто, хотя я не думаю, что где-то это будет сложнее. В панели управления нужно перейти на вкладку домены, дальше выбрать домен, ну и нажать на кнопку “добавить запись”. В значении “хост” пишу webmin.anton-shuvalov.info, “тип” — A, “Значение” — указываю свой IP.

SSH

На MacBook я создал пару профилей SSH — до консоли роутера, и до консоли домашнего сервера. Создаются такие профили в файле ~/.ssh/config. Два моих профиля выглядят примерно так:

Host ayanami
	# My home server
	HostName myip
	RemoteForward 52698 127.0.0.1:52698 # для rmate
	User user
	Port 11132 # В DD-WRT нужно пробросить этот порт на локальный IP сервера на 22-ой порт
	
Host router
	# My home router
	HostName myip
	User root
	Port 22

В файле /etc/hosts я сделал запись такого вида:

44.144.244.233 myip # home

Это нужно для того, что бы в конфиге SSH зарезолвить myip в корректный IP-адрес.

Настройка DD-WRT

В DD-WRT нужно сделать две вещи для того, чтобы запрос к субдомену доходил до моего еще не установленного проксирующего сервера на nginx, который, собственно, и будет разбираться с тем, что и куда перенаправить.

Во-первых нужно подвинуть веб-интерфейс с 80-ого порта на, например, 81-ый порт (есть альтернативный вариант — перевести веб-интерфейс с http на https, но я его не пробовал).
Во-вторых нужно пробросить 80-ый порт до сервера, на котором будет работать nginx.

Меняем порт веб-интерфейса

Что бы сменить порт интерфейса нужно выполнить в консоли роутера следующие строки

nvram set http_lanport=81
nvram commit
reboot

После перезагрузки интерфейс откроется по адресу http://192.168.0.1:81.

Пробрасываем 80-ый порт

Здесь нет ничего сложного. Нужная форма находится в NAT/QoS > Port Forwarding. Слева направо название, входящий порт, протокол (TCP, UDP или оба), внутренний IP и его порт. Внутренний IP сервера у меня 192.16810.101, порт 80-ый.

Установа nginx в debian

Установка nginx была не особенно гладкой. Ну как, не особенно. Я решил поставить из aptitude, после этого часа два пытался настроить nginx proxy_pass, и, в итоге, измученного и злого, меня озорило:

rei@ayanami:~/$ /usr/sbin/nginx  -v
nginx version: nginx/0.7.67

Уже вышел nginx/1.2.6. Версия в сорцах жутко смердила. Для того, что бы поставить актуальную версию, нужно добавить в /etc/apt/sources.list следующие строчки:

deb http://nginx.org/packages/debian/ squeeze nginx
deb-src http://nginx.org/packages/debian/ squeeze nginx

Так как я ставлю ngixn исключительно для проксирования запросов внутрь моей локальной сети, то ни php-fpm, ни mysql я не устанавливаю. Следовательно я удалил старую версию с помощью aptitude remove --purge nginx, а дальше все просто:

sudo aptitude install nginx

nginx proxy pass

После того, как установка nginx на мой debian сервер успешно завершилась, нужно настроить проксирование запросов в мой маленький интранет. Для каждого субдомена нужно писать отдельный конфиг. Возможно в чем-то эти конфиги могут отличаться. У меня же они одинаковые. Конфигурация сервера помещается в директиву http.

server {
  server_name router.anton-shuvalov.info; # субдомен
  listen 80;
  location / {
    proxy_pass http://192.168.1.1:81; # локальный адрес
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

Я добавил такие конфиги для веб-интерфейса роутера и торрент-клиента.

В Webmin не работают cookies

С webmin не заладилось. После того, как я настроил проксирование по адресу webmin.anton-shuvalov.info меня встретила форма логина, но, введя имя пользователя и пароль, я увидел такую ошибку:

Error - No cookies
	
Your browser does not support cookies, which are required for this web server to work in session authentication mode

Надо отметить, что proxy_pass у меня вел на https://192.168.1.101:10000. Но на самом деле, SSL webmin’а нужно выключить. Для этого в файле sudo rmate /etc/webmin/miniserv.conf нужно поменять ssl=1 на ssl=0. Ну и ниже конфиг сервера в /etc/nginx/nginx.conf:

server {
  server_name webmin.anton-shuvalov.info; 
  listen 80;
  location / {
    proxy_pass http://192.168.1.1:10000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

После этого все должно было заработать. Хотя нет. Webmin очень расстроился из-за подозрительного домена, с которого я до него добрался. Во всех своих фреймах он только об этом и говорил мне. Что бы порадовать старика нужно зайти в webmin через локальный адрес, у меня это 192.168.1.101:10000 перейти в Webmin > Настройка Webmin > Проверка ссылок и вписать, куда влезает, название своего домена. Что-то типа webmin.anton-shuvalov.info. Теперь-то все.

Реприза

Сейчас я очень доволен — я могу добраться до консоли роутера или сервера, который я спрятал в чулане, до интерфейса роутера, до торрент-клиента, до состояния сервера из любой точки мира. Это очень здорово. Позднее я планирую поднять доступ до ftp (хотя, это должно решится с помощью установки нужного optware пакета на роутер). Ну и попробую перенести свой блог на домашний сервер, что бы посмотреть, что из этого выйдет. А на сегодня, вроде как все.

Домашний сервер. Первые шаги

2013-01-06T00:00:00+00:00

Установка Debian

Установка Debian не представляет из себя ничего сложного. На официальном сайте я скачал дистрибутив для AMD64. Прожег диск, вставил его в привод сервера. Согласился с предложением BIOS загрузиться с CD. Когда инсталятор предложил мне выбрать пакеты для автоматической установки, я отметил только SSH-server.

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

После перезагрузки я посмотрел IP с помощью ifconfig. В своем MacBook я открыл конфиг SSH.

mate ~/.ssh/config

И дописал в него свой новый сервер.

Host ayanami
# My home server
HostName 192.168.1.101
RemoteForward 52698 127.0.0.1:52698
User rei
Port 22

Строчка RemoteForward нужна для проброса порта обратно, с сервера на MacBook. Это пригодится мне при настройке rmate. И так, подключаюсь к серверу, и вижу шелл.

ssh ayanami

rmate

поставил по своей же инструкции которую я писал в блог.

ruby

Ruby поставил из aptitude, нужен для того, что бы работал rmate.

Sudo

Sudo пригодится для того, что бы не сидеть под суперпользователем, и не перелогиниваться каждый раз, когда нужны привилегии root’а. Без проблем устанавливается через apt-get или aptitude.

rmate /etc/sudoers

Под строкой root ALL=(ALL) ALL нужно дописать

<user> ALL=(ALL) ALL

webmin

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

Для установки с помощью APT нужно отредактировать файл /etc/apt/sources.list и дописать туда

deb http://download.webmin.com/download/repository sarge contrib
deb http://webmin.mirror.somersettechsolutions.co.uk/repository sarge contrib

Потом нужно добавить ключ к репозиторию.

cd /tmp
wget http://www.webmin.com/jcameron-key.asc
apt-key add jcameron-key.asc

Ну и теперь можно устанавливать

apt-get update
apt-get install webmin

Все зависимости разрешаются автоматически. После набираю в браузере http://server-ip:10000 и видим веб-интерфейс webmin.

zsh

sudo apt-get install zsh

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

chsh

В появившемся диалоге нужно вписать

/bin/zsh

Я пока что поставил первый попавшийся конфиг:

. /etc/zsh_command_not_found #подключаем стандартный вывод убунты 
autoload -U compinit # настраиваем автодополнение
compinit 
HISTFILE=~/.zhistory # устанавливаем файл истории для zsh
HISTSIZE=10000 # размер истории
SAVEHIST=10000 
setopt  APPEND_HISTORY # убираем повторы и пустые строки в истории
setopt  HIST_IGNORE_ALL_DUPS 
setopt  HIST_IGNORE_SPACE 
setopt  HIST_REDUCE_BLANKS 
setopt autocd # смену пути без команды cd
setopt CORRECT_ALL # корректировку ошибок
export PS1 NLSPATH PAGER MAIL LS_COLORS LS_OPTIONS LIBRARY_PATH \
            C_INCLUDE_PATH CPLUS_INCLUDE_PATH EDITOR TERM XFILESEARCHPATH # экспортируем всякие полезности
bindkey -e # устанавливаем клавиши как в e-macs
fc -R $HISTFILE # подгружаем старую историю
# если мы находимся под обычным пользователем то в приветствии, в конце будет - >  если под рутом то - #
if [[ $EUID == 0 ]]; then
PS1=$'%{\e[1;7m%}%n@%m:%~ #%{\e[1;0m%} ';
else
PS1=$'%{\e[1;7m%}%n@%m:%~ >%{\e[1;0m%} ';
fi
PROMPT=$PS1;
#и справа в качечтве приветствия выведем время.
RPROMPT=$'%{\e[1;34m%}%T%{\e[0m%}' 
#добавляем стандартные алиасы
alias ls='ls -F --color=auto'
alias ll='ls -l'
alias la='ls -A'
alias li='ls -ial'
alias lsd='ls -ld *(-/DN)'
#указываем пути к манам
manpath="/usr/man:/usr/share/man:\
/usr/local/man:/usr/X11R6/man:/opt/qt/doc"
export MANPATH

Домашний сервер. Интро

2013-01-05T00:00:00+00:00

В планах зреет переход на AWS Free Usage Tier. Сейчас мои сайты хостятся на selectel.ru и эксперементирую я там же.

После перехода на Jekyll необходимость в таком облачном сервере отпала. Точнее, необходимость разложилась на хостинг для статичных сайтов, плюс сервер для эксперементов. Первую необходимость как раз решает AWS Free Usage Tier, а для второй я решил использовать старый PC, который уже пару месяцев пылился в углу. А точнее:

CPU: AMD Phenom II X2 555 BE ( 2 cores 3.2GHz )
RAM: 4GB ( 2GB x 2GB )
HDD: 500GB

Для чего все это?

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

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

Переезд с WordPress на Jekyll

2012-12-31T00:00:00+00:00

Когда я завел блог я был уверен, что wordpress — это простая и легкая в освоении CMS. В целом так и есть. Да и большинство хостингов позволяют установить эту CMS в один клик. Первоначально я использовал как раз такой хостинг на domain.com. Позднее я перенес свой блог на облачный сервер selectel.ru, где я без особого труда самостоятельно установил WordPress. Так же в плюс этой CMS Я знаю 3 способа создать сайт на WordPress бесплатно.

Можно сделать это официально на wordpress.com, но там есть ряд ограничений (например, нельзя устанавливать свои темы и плагины)
Можно использовать OpenShift от RedHat, где в один клик можно создать сайт на WordPress без ограничений. По характеристикам сервера — этот вариант самый производительный
Воспользоваться популярным хостингом для веб-приложений heroku, для которого есть свой форк wordpress с postgreSQL.

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

Достаточно быстро мной овладела мысль об избыточности WordPress для блога — большая БД, куча запросов, плагинов, кода. Мой блог работал не особенно быстро. По крайней мере не так быстро, как я бы хотел. Я периодически натыкался на различные интересные решения, например на markdown-cms. В принципе, это такой же генератор статичных сайтов, как и Jekyll только менее удобный и на Perl. В то время подход основанный на генерации статичных страниц я не оценил. О Jekyll я слышал достаточно давно в контексте GitHub Pages. Как-то раз и я решил попробовать сделать свой сайт на github с помощью jekyll. Внезапно jekyll оказался очень простым и понятным. До работы с ним у меня не было опыта в ruby. Теперь же у меня есть большое желание углубиться в этот язык. Особенно мне понравился rakefile. Я много времени провел пытаясь понять как пользоваться makefile, но rakefile я освоил за 5 минут, и практически сразу начал использовать его в своих проектах. Для Jekyll в будущих проектах даже найдется место.

Вернемся к переезду. Сеттинг:

source: it-prm.com, хостится на selectel под nginx, php, wordpress
tagget: anton-shuvalov.info, plain-html, jekyll-bootstrap, хостится на selectel

Свои статьи я храню в markdown, по этому их перенос на Jekyll занял минут 20. Написал rakefile с двумя тасками:

task :default => :run

# Push 
desc 'Push site to server'
task :push do
  print "Push _site to server..\n"
  sh "rsync -az --delete _site/ eva:/home/web/www/anton-shuvalov.info"
  print "Done...\n"
end

# Run
desc 'Run server'
task :run do
  print "Starting jekyll...\n"
  sh "jekyll --server"
end

В задаче push eva — это имя сервера, оно забито в конфиге ssh ~/.ssh/config:

Host eva
HostName 88.88.88.88 # ip сервера
User shuvalov
Port 22

Для деплоя на сервер я набрал в консоли rake push и через секунд 10 сайт открылся по адресу anton-shuvalov.info. Осталось настроить 301 редирект с it-prm.com на anton-shuvalov.info. В конфиге сайта в /etc/nginx/sites-available/it-prm.com это выглядит так:

server {
  ...

  # Redirects to anton-shuvalov.info
  if ( $request_uri ~* "/?p=803" ) { 
    rewrite ^ http://anton-shuvalov.info/2012/12/05/backbone-screencasts/? permanent; 
  }
  if ( $request_uri ~* "/?p=772" ) { 
    rewrite ^ http://anton-shuvalov.info/2012/11/18/Textmate2-line-hate/? permanent; 
  }
  if ( $request_uri ~* "/?p=753" ) { 
    rewrite ^ http://anton-shuvalov.info/2012/11/09/.google-analitycs-avtime? permanent; 
  }

  ...

  rewrite ^ http://anton-shuvalov.info? permanent;
  
  ...
		
}

Ну вот и все. Перезагрузил nginx sudo nginx -s reload, все заработало. Проверил редиректы руками — все правильно. Переезд закончен.

Jekyll REXML could not parse this XML/HTML

2012-12-21T00:00:00+00:00

В Jekyll я столкнулся с проблемой. Вставил в текст поста iframe:

<iframe width="620px" height="400px" src="http://player.vimeo.com/video/55084406" frameborder="0" mozallowfullscreen allowFullScreen></iframe>

И получил вот такую такую ошибку:

REXML could not parse this XML/HTML: 
<iframe width="620px" height="400px" src="http://player.vimeo.com/video/123" frameborder="0" allowFullScreen></iframe>

Что бы избавиться от этой ошибки придется отказаться от использования mozallowfullscreen, allowFullScreen. В результате код должен выглядеть так:

<iframe width="620px" height="400px" src="http://player.vimeo.com/video/55084406" frameborder="0"></iframe>

Плагин для vimeo в jekyll

Для того, что бы упростить себе жизнь я использую плагин для видео из vimeo — этот плагин учитывает проблему с парсингом HTML и содержит стили для того, что бы видео корректно меняло свой размер для мобильных устройств. Работает плагин просто — достаточно вставить в тело записи { % vimeo 55084406 % } подставив нужный id.

Интерлиньяж в TextMate2

2012-11-18T00:00:00+00:00

Долгое время не мог понять что не так со шрифтами в TextMate2. Сейчас определился — мне не нравится line-height в редакторе. Изменить высоту строк достаточно просто. Для этого в терминал я ввел следующие комманды:

defaults write com.macromates.TextMate.preview fontAscentDelta -float 0
defaults write com.macromates.TextMate.preview fontLeadingDelta -float 0

По-умолчанию параметры используются со значением 1, так что вернуть все как было можно, набрав:

defaults write com.macromates.TextMate.preview fontAscentDelta -float 1
defaults write com.macromates.TextMate.preview fontLeadingDelta -float 1

Источник

Как правильно считать время в Google Analytics

2012-11-09T00:00:00+00:00

Очень часто в Google Analytics среднее время проведенное пользователем на сайте равно нулю. Это, по меньшей мере, странно — неужели пользователь перешел по ссылке и тут же ее закрыл?

Решение

Все дело в том, что Google считает время между открытием страниц, соответственно пользователь, который просмотрел только одну страницу по подсчетам гугла проводит на ней 0 секунд. Для того, что бы считать время, проведенное пользователем на странице, правильно — можно периодически отправлять в Google Analytics сообщения. Самый простой способ — сделать это в цикле:

var trackingByInterval = (function trackingByInterval () {
	var timerCallback = function timerCallback () {
		_gaq.push(['_trackEvent', 'Reading', 'every 5 sec']);
	}
	setInterval(timerCallback, 5000);
})();

Ссылка на gist

Этот код нужно добавить после скрипта Google Anaytics. Скрипт запускается при открытии страницы, и фиксирует время, проведенное пользователем на сайте с частотой дискретизации — 5 секунд.

pgadmin column "datconfig" does not exist

2012-11-06T00:00:00+00:00

Пару дней назад установил Postgres.app и pgadmin v1.8.4. Но при попытке подключения из pgadmin к БД получал ошибку

ERROR: Column "datconfig" does not exist

Решение

Проблема возникает из-за странной сортировки на сайте pgadmin и невнимательности %username%. pgadmin v1.8.4 кажется последней версией, но на самом деле в списке есть версии v1.10.* и старше. Для того, что бы избавиться от ошибки нужно использовать версию pgadmin v1.12.* или старше.

Как писался PostgreSQL

2012-10-19T00:00:00+00:00

Разработка СУБД POSTRGES началась в 1986 году под руководством профессора Майкла Стоунбрейкера (Michael Stonebraker). Концепции системы и архитектурные решения представлены в THE DESIGN OF POSTGRES, The POSTGRES data model, The design of the POSTGRES rules system, The design of the POSTGRES storage system.

Прототипы

В первых версиях POSTGRES было большое количество архитектурных решений. Только после Версии 3 разработчики сконцентрировали свое внимание на переносимости и стабильности СУБД.

Первый прототип заработал в 1987 и был продемонстрирован на Конференции ACM-SIGMOD в 1988 году.
Второй прототип (Версия 1), описанный в The implementation of POSTGRES был выпущен в июне 1989 года.
Третий прототип (Версия 2), выпущен в Июне 1990 года.
Четвертый прототип (Версия 3) выпущен в 1991.

Поддержка

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

Переписывание

В 1994, Эндрю Ю (Andrew Yu) и Джолли Чен (Jolly Chen) добавили в POSTGRES интерпретатор языка SQL. СУБД была полностью приведена к стандарту ANSI C и сократив свой размер на 25%. Были внесены многие внутренние изменения, которые увеличили производительность и обслуживаемость кода. Postgres95 был быстрее на 30-50% согласно Wisconsin Benchmark по сравнению с POSTGRES, Version 4.2. При разработке Postgres95 акцент ставился на обнаружение и понимание существующих проблем в коде сервера.

PostgreSQL

В 1996 году было решено, что имя “Postgres95” не соответствует настоящему времени. Для проекта было выбрано название PostgreSQL. Если при разработке Postgres95 внимание разработчиков было сконцентирировано на обнаружении и понимании существующих проблем в коде сервера, то в PostgreSQL внимание сместилось на расширение возможностей и совместимости при продолжении работы во всех других областях.

Вывод

PostgreSQL — это весьма объемный проект. Путь между прототипом, и версией, имеющей четкую концепцию и всесторонне продуманные архитектурные решения у ребят из Беркли занял 10 лет.

Кэш и ненависть в iBooks

2012-10-11T00:00:00+00:00

Разрабатывая книгу в iBooks Author, я столкнулись с «необъяснимыми» проблемами с HTML5 AUDIO в написанных мной виджетах. Аудио то играло, то не играло, звук иногда пропадал после исправлений, которые не затрагивали ни JS, ни HTML, ни CSS ( например после замены дефисов на тире ). Долгим и, к сожалению, эмпирическим путем я установил корень проблемы — кириллица в имени файла книги и в имени файла виджета. Вроде бы все легко — переименовываем книгу, переименовываем виджет, профит! С файлом книги, естественно, проблем не возникло, а с виджетом все оказалось чуть-чуть сложнее.

WTF?! Cache!

Никто не может просто взять и переименовать виджет. iBooks Author имеет свой механизм кэширования. Упрощенная модель кэша работает примерно так

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

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

Как объеденить две медиатеки в iTunes

2012-10-09T00:00:00+00:00

Наконец я получил optibay, и установил к SSD в своем MacBook Pro еще и HDD. 120Gb памяти в SSD уже не сдерживали меня, и я решил вернуть свою музыкальную коллекцию с внешнего диска обратно на MacBook. Большая и старая медиатека лежала на внешнем диске, а на SSD скопилась совсем небольшая медиатека, в которой я уже успел проставить рейтинги, да и статистику прослушиваний терять не хотелось.

Объединение медиатек

Запускаю iTunes с той медиатекой, которую я хочу экспортировать. Для этого нужно запустить iTunes зажав option, в появившемся окне выбрать Choose Library.. и указать папку с медиатекой.
Экспорт медиатеки.File > Library > Export.
Запускаем iTunes с той медиатекой, в которую мы хотим импортировать первую. Как в первом пункте.
Импортируем медиатеку. File > Library > Import Playlist.

BASH. Чем отличается which от whereis

2012-10-05T00:00:00+00:00

В bash есть две утилиты для определения пути к программе, и я решил выяснить подробности использования обеих утилит. Как оказалось — не зря.

Which

Команда which ищет приложение в пользовательской директории. Например:

which git
/usr/local/bin/git

Ключи

-a — возвращает список путей ко всем найденным программам.
-s — возвращает 0 если хотя бы одна программа есть, и 1 если ничего нет.

Whereis

Команда whereis ищет программы среди стандартных директорий и флагов не имеет. Пример:

whereis git
/usr/bin/git

Архитектура кода

2012-10-05T00:00:00+00:00

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

Из этого спора я сделал вывод — или я не понимаю, что такое архитектура и проектирование, или разработчики. По-моему, в архитектуру закладываются не фичи, а возможность их реализации. При чем, не конкретной фичи, или модуля, а определенного типа модулей и фич. Конечно это увеличивает время на разработку, но под проектированием я подразумеваю именно создание модели такой системы, для внесения существенных изменений в которую не придется переделывать все заново. А если одну “фичу в архитектуру заложить”, то где гарантия, что при чуть изменившихся требованиях к фиче не придется свое детище учить ходить на костылях?

WTF?! Кто прав?

Ссылка на глоссарий в iBooks Author

2012-07-23T00:00:00+00:00

Столкнулся с проблемой — iBooks Author не создавал ссылки на глоссарий. Проблема была в тексте. По какой-то причине он оказался “заполнителем”.

Отзыв о книге «Программист-прагматик»

2012-07-21T00:00:00+00:00

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

Я обязательно перечитаю эту книгу, потому что она великолепна.

Нумерация страниц в iBooks Author

2012-07-19T00:00:00+00:00

В книгах используется нумерация страниц арабскими числами. Но в некоторых шаблонах (например в “Preface”) iBooks author используется римская нумерация. Исправить это очень просто. Выбрав неугодный layout параграфа, в inspector > layout > numbering высталвяем правильную нумерацию.

Что почитать веб-разработчику

2012-06-30T00:00:00+00:00

Я решил составить список интересных ссылок, которые стоит почитать на выходных. Основные темы - Textmate, JavaScript, CSS, ну и чуть-чуть о философии дизайна.

FrontEnd:

JavaScript Гарден - shaman.sir, Антон Шевчук, Максим Лозовой, Елена Пашкова перевели на русский язык потрясающую документацию по всем темным углам JavaScript.

JavaScript: patterns and antipatterns - отличная коллекция паттернов и анти-паттернов JavaScript от Shi Chuan.

Scalable JavaScript Design Patterns - великолепная презентация об основных паттернах проектирования в JavaScript от Addy Osmani. Так же у Addy Osmani есть книга, глубже раскрывающая тему паттернов в JS: Learning JavaScript Design Patterns

Front-end developer interview questions - Вопросы к собеседованию для frontend разработчиков от Darcy Clarke и огромного числа соразработчиков. Основные темы - CSS, JS, jQuery, HTML.

Спецификация W3C по ARIA - ARIA уже в стадии Candidate Recommendation, так что стоит разобраться, что это такое.

TextMate

Textmate 2 Tips - сайт с говорящим названием.

Textmate Repos - аккаунт macromates на GitHub. Поиски TextMate bundles стоит начать именно отсюда.

Дизайн

Планетарная клаустрафобия - архитектурный теоретик Александр Раппапорт рассказывает глобализации в дизайне и ее негативных последствиях.

Просмотр man-страниц в textmate

2012-06-23T00:00:00+00:00

мануал о том как использовать textmate для просмотра мануалов

man

Часто, читая man’ы, я чувствую себя этаким гиком 70-ых. В дебрях терминала, среди черно-белых текстовых полотен. Ни подсветки текста, ни удобной навигации. Кто-то скажет, что, читая man, люди меньше всего думают об интерфейсе. Но с другой стороны, сегодня многие люди предпочитают google, и различные приложения-справочники, олдскуллным консольным man-страницам. Я попробую сделать чтение man’ов более привлекательным.

Использование textmate2 для чтения man’ов

«Использовать один редактор — это хорошо».
Pragmatic Programmer

Для меня, бесспорно, главным и единственным редактором кода является textmate2. Я попробую научить этот редактор читать маны. В этой статье речь пойдет именно о второй версии TextMate. У меня сейчас установлен TextMate Version 2.0 (9090).

Установка бандла

Для начала я установил в TextMate бандл для чтения man-страниц. Скачал, проверил, что название папки заканчивается на .tmbundle. Скопировал бандл в папку.<pre>~/Library/Application Support/TextMate/Managed/Bundles </pre> Перезапустил TextMate.

Использование бандла

Выбираю в меню Bundles->Man Pages->View Man Page. В появившемся окне набираю название shell-команды, например man, и умиляюсь открывшейся TextMate man-страницей. Для того, что бы воспользоваться второй командой бандла - Visit man Page - нужно выделить какую-нибудь shell-команду в тексте. По нажатию на хоткей, либо выбрав в меню Bundles->Man Pages->Visit man Page, откроется новая вкладка со справкой по выделенной команде.

Для гиков и перфекционистов: настройка бандла

Для меня совершенно неудобно тянуться к тэчпаду или мыши, и выделять руками команду. Это лечится настройкой входных данных. Выбираю в меню <pre>Bundles->Edit Bundles…->Man Pages->Menu Actions->Visit Man Page</pre> Слева в настройках нужно установить значение поля input равным word. Здесь же, в редакторе бандлов, можно настроить удобные хоткеи. Они задаются в поле Key Equivalent. Не стоит обделять гуманным сочетанием клавиш и View Man Page. Да, что бы заставить хоткеи работать - мне пришлось удалить значение поля Scope Selector.

Учим textmate читать маны из консоли.

И вроде бы, когда я пишу код в TextMate, все круто: если мне нужна справка - жму хоткей - читаю, просвещаюсь, жгу дальше дальше. Но что мне делать, если я тщетно пытаюсь заставить что-то работать прямо в консоли? Получается, что мне и man там же читать? Нет, это никуда не годится. Я решил использовать bash-скрипт, на котором базируется бандл “Man Pages” как обертку к стандартной команде man.

Для начала узнаем, где лежит оригинальный ман.
which man
Скорее всего это /usr/bin/man. Думаю, что бывают исключения.

Для всех скриптов, к которым я лично приложил руку - у меня есть специальный каталог ~/.scripts. Каталог прописан в переменной окружения $PATH. Я нахожу это удобным. Краткая инструкция о создании такого каталога:

mkdir ~/.scripts # Создаем директорию
mate ~/.profile  # Добавляем ее в $PATH

В открывшемся окне TextMate нужно дописать строчку <pre>export PATH=$HOME/.scripts:$PATH </pre> Либо, если export PATH уже есть, то дописать в нем, сразу после = $HOME/.scripts:. Создадим в ~/.scripts ссылку на наш скрипт:

ln -s /Users/shuvalov/Library/Application\ Support/TextMate/Managed/Bundles/textmate-man-pages.tmbundle/Support/mman ~/.scripts/man

В этот момент, так как я определил директорию с нашим скриптом раньше всего, стандартный man перестанет работать. Вместо него будет выполняться наш скрипт. Теперь осталось изменить в скрипте вызов man на /usr/bin/man (либо путь до оригинальной команды man). Отрываю файл <pre>~/Library/Application\ Support/TextMate/Managed/Bundles/textmate-man-pages.tmbundle/Support/mman </pre> и отредактируем его. (мой пример).
Набираем man man и видим результат труда - man-страница открывается в новом окне textmate, переливаясь чинной подсветкой синтаксиса.

Напоследок. Если, просматривая man в textmate, нажать shift+cmd+t, то откроется меню навигации по ману. Только вот, что бы заставить его работать, нужно в последней строчке скрипта изменить значение sleep на 180, продлив время жизни временной страницы:

(sleep 180; rm -f $tmp) > /dev/null 2>&1 </dev/null &

Заключение.

Читать маны в textmate2 эпически удобно. Так же, удобно уметь использовать один редактор для всех своих задач и не распыляйться.

Планетарная клаустрофобия

2012-06-19T00:00:00+00:00

Цитата из лекции “Симптомы системного кризиса в архитектуре”:

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

Александр Раппапорт

mate и rmate в TextMate 2

2012-06-15T00:00:00+00:00

Введение

Я полностью согласен с авторами книги «The Pragmatic Programmer» Andrew Hunt и David Thomas в том, что иметь один-единственный редактор текста для всего — это прекрасно. Таким редактором для меня является textmate 2. Я стараюсь использовать его везде, где это возможно. В основном я работаю с JS, HTML, CSS и Markdown для статей и заметок. Бывает пишу PHP-код и shell-скрипты. Изредка судьба, ухмыляясь, заставляет меня писать на pascal. С помощью различных дополнений, область применения Textmate можно расширять практически бесконечно.

Textmate поставляется с двумя консольными скриптами mate и rmate. mate позволяет из терминала открыть файл в textmate. Выглядит это, к примеру, так - sudo mate /etc/hosts/. С помощью rmate можно провернуть то-же самое, но на удаленнам сервере.

Раньше я ежедневно пользовался ssh или даже sshfs для редактирования файлов на сервере. С одной стороны перспектива редактирования кода в vim-подобных редакторах, с другой медленная скорость работы sshfs как файловой системы. В целом, удаленное редактирование файлов мне не импонировало ни тем, ни другим…

Mate

В консоли Mac OS X существует команда open, заменяющая в терминале двойной клик по файлу. open -a в терминале заменяет команду «открыть с помощью». Например, что бы открыть из терминала в textmate файл, /etc/hosts, вполне можно обойтись командой open /etc/hosts/ -a TextMate. Несколько файлов открываются командой

open ~/.bashrc ~/.profile -a TextMate

Но команда open имеет несколько ограничений. Невозможно открыть файл на определенной строке. Так же невозможно придержать консоль до закрытия файла. Последнее ограничение не позволяет использовать textmate как внешний редактор, например, для git или svn.

По этому у textmate есть замена неповоротливому open — это mate. Скрипт устанавливатется из textmate-preferences-terminal. mate позволяет использовать textmate из терминала, так как-будто это действительно консольное приложение. Например, для того, что бы использовать его как внешний редактор для всех консольных приложений просто добавим это в ./profile:

export EDITOR='mate -w'

Ключ -w - заставляет терминал дождаться закрытия файла, перед продолжением.

Rmate

SSH-туннель

Если говорить кратко - ssh-туннель перенаправляет траффик с определенного порта на любой порт локальной машины посредством ssh-соединения. Создадим туннель для того, что бы получить возможность редактировать файлы на сервере с помощью textmate:

ssh -R 52698:localhost:52698 <user>@<server>

Возможно, будет проще обновить настройки ssh подключения, для того, что бы туннель всегда создавался автоматически, без ключа -R и объявления пробрасываемых портов.

Для единственного сервера добавим следующие строки в ~/.ssh/config:

Host <адрес сервера>
RemoteForward 52698 localhost:52698

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

Host *
RemoteForward 52698 localhost:52698

Установка

Создаем новый файл на сервере, скопируем в него содержимое rmate (preferences > terminal: ссылка rmate ) и дадим права на выполнение:

# rmate доступен всем пользователям
sudo vi /usr/local/bin/rmate
chmod +x /usr/local/bin/rmate

# rmate доступен только текущему пользователю (проверь, есть ли этот каталог в $PATH)
vi ~/bin/rmate
chmod +x ~/bin/rmate

Альтернативный вариант - использовать команду scp для того, что бы залить скрипт с локальной машины на сервер. Выглядит это примерно так:

scp /Applications/TextMate.app/Contents/Frameworks/Preferences.framework/Versions/A/Resources/rmate <пользователь>@<сервер>:/usr/local/bin/

Вот и все. Больше нам не придется к этому возвращаться.

Теперь можно использовать rmate на сервере. Проверим, как он работает:

rmate ~/test.txt

Мы должны увидеть новое окно textmate с пустым файлом. Напишем что-нибудь в этом файле. После сохранения файл появится на сервере.

Известные проблемы

/usr/bin/env: ruby: No such file or directory

На сервере не установлен ruby-интерпретатор. Michael Newton переписал rmate на php

Warning: remote port forwarding failed for listen port 52698

На сервере 52698 порт уже чем-то занят. Нужно отключиться от сервера, и создать ssh-туннель используя другой порт:

ssh -R <мой-порт>:localhost:52698 <user>@<server>

Теперь, запуская rmate нужно так же указывать номер порта:

rmate -p <мой-порт> rmate_rocks.txt

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

Заключение

rmate и mate расширяют возможности использования textmate до удаленных серверов и консольных приложений. Здесь можно найти миллион замечательных способов применения этого уютного редактора. Например, можно использовать textmate для того, что бы писать комментарии к коммиту изменений на github:

export GIT_EDITOR="mate --name 'Git Commit Message' -w -l 1"

Много всего можно придумать, и я очень рад, что погружаться в дебри консоли я буду с комфортным мне редактором кода.

Установка rmate для TextMate2

2012-06-03T00:00:00+00:00

Решил попробовать в деле одно из нововведений второй версии textmate - rmate. Для того, что бы заставить эту штуку работать нам понадобится:

Установить ruby на сервере.
Выполнить в терминале клиента:

scp /Applications/TextMate.app/Contents/Frameworks/Preferences.framework/Versions/A/Resources/rmate user@example.com:/usr/local/bin

Здесь мы отправляем на удаленный сервер скрипт, обеспечиващий работу комманды rmate (адрес скрипта можно узнать кликнув на слово rmate в preferences > terminal). user@example.com — это адрес нашего сервера и пользователь, под которым мы произведем запись файла. /usr/local/bin - это каталог, в котором находятся наши приложения. Bash в первую очередь будет искать здесь то, что мы пытаемся запустить в терминале. В принципе, можно указать любой другой каталог, но тогда запускать rmate придется либо явно указывая путь, либо добавив этот путь в переменную окружения $PATH.

Для того что бы наш сервер мог делегировать редактирование файла редактору на клиенте - нам нужно установить SSH-туннель. Делается это следующим образом:

ssh -R 52698:127.0.0.1:52698 user@example.com

где user@example.com - имя пользователя и адрес удаленного сервера.

Если в ~/.ssh/config клиента прописать:

Host example.com
RemoteForward 52698 127.0.0.1:52698

то тунель будет создаваться автоматически, без необходимости явно его объявлять.

Проверить работу нашего скрипта, например, написав в консоли rmate test.txt. К этому моменту у нас должен быть открыт textmate. Файл test.txt откроется в его новом окне, где его можно редактировать. Сохранив файл, выполним в консоли vim test.txt и увидим в vim’е все изменения, которые мы внесли с помощью textmate.

Странные ссылки в iBooks

2012-05-24T00:00:00+00:00

Я занимаюсь разработкой книг для iBooks. Одна из задач с которыми я столкнулся в процессе разработки - раелизация таймлайна. Таймлайн должен находиться на каждой странице содержать ссылки на разделы учебника. Сначала у меня были мысли сделать таймлайн с помощью виджета. При подобной реализации у меня были бы развязаны руки для любых извращений в плане дизайна и UX, но я не нашел никакой информаци о существовании какого-бы то ни было API в iBooks, следовательно, я не представлял никакой возможности дотянуться до страниц книги из виджета.

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

Выделяем текст в начале главы.
Создаем из него закладку
Создаем ссылку на этот текст в таймлайне.
Применяем шаблон с таймлайном ко всем страницам
…
Профит

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

Выберите требуемый вариант во всплывающем меню «Ссылка на».

Веб-страницу Введите URL-адрес.

Сообщение e-mail Введите адрес электронной почты и строку темы.

Закладка Выберите закладку во всплывающем меню «Имя». При отсутствии закладок во всплывающем меню «Имя» добавьте их согласно приведенной ниже инструкции.

Рисунок Выберите рисунок в списке «Имя». Для просмотра объектов определенного типа (например, всех фильмов или галерей) выберите требуемый вариант во всплывающем меню «Показать».

Остановимся подробней на пункте 4 со странным названием “рисунок”. Под таким названием переводчики подразумевали все интерактивные элементы книги. Когда я попытался использовать его впервые, то я увидел в списке объектов для ссылок только тесты. Я решил почитать об этой странности, и наткнулся на книгу издательства “O’Reily” Publishing with iBooks Author. Как это ни странно, книга бесплатна. Скачав книгу, я нашел в ней параграф, касающийся ссылок:

Author does make it easier to add links to labeled objects, like Galleries (see “Gallery” (page 59)), Media boxes (see “Media” (page 60)), and Figures (see “Figures” (page 55)). Select the text that you want to turn into a link, and choose Insert → Hyperlink → Figure Reference. The Link Inspector opens, giving you a list of all the labeled objects in your book to choose from. Click the one you want to link to, and your clickable link is all set.

Ключевое слово - “labeled”, то есть объект, должен обязательно иметь метку, а все мои картинки, видео и презентации в книге этих меток не имели. Опять обратимся к документации:

К любому объекту можно добавить заголовок или подпись (или заголовок и подпись одновременно). Заголовок может содержать метку (например, Рисунок или Галерея). Можно создавать пользовательские метки. Если создать для объекта заголовок или подпись, объект будет отображаться в готовой книге и в горизонтальной, и в вертикальной ориентации. В вертикальной ориентации объекты, имеющие заголовок или подпись, располагаются вдоль левого края страницы.

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

Кстати, это удивительно, но ссылки в iBooks author и keynote реализуются совершенно по разному, беспардонно нарушая эвристики Нильсена. Назову пару самых странных отличий:

В KeyNote любой объект может являться ссылкой. В iBooks только текст.
В KeyNote можно ссылаться на слайды(страницы), в iBooks только на определенные объекты (закладки, интерактивные оъекты с метками).

Сломаные заполнители в iBooks

2012-05-05T00:00:00+00:00

Начало

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

Факап…

Проблема, с которой я сталкнулся, когда начал разрабатывать шаблоны — невозможность редактирования заполнителей на страницах. Это было странно. Я создавал необходимый блок в шаблоне страницы, заполнял его текстом. Согласно справке заходил в меню “формат” -> “дополнительные параметны” -> “Определить как заполнитель текста”. Вроде бы все должно было быть круто: бери и меняй заполнители там, где нужно, но не тут то было. Блок с текстом было просто невозможно выделить. Невозможно редактировать. Но ведь заполнитель текста нужен за тем, что бы его редактировать!?… Даже если не использовать заполнители, все равно текст, который я вставлял в шаблоны iBooks не поддавался правке на конечных страницах.

Где решение?

В тот момент я так и не смог найти правильное решение, ни “курение манов”, ни гугл не давали нужного ответа. А так как время - конечный ресурс, я отказался от заполнителей. Я использовал готовые шаблоны, меняя их под свои нужды. Часто я все равно сталкивался с проблемой редактирования объектов из шаблона на странице. Спасая себя магическим сочетанием клавиш “cmd+z”, я сделал более-менее приемлимый шаблон. Для интерактивного-контента я сделал главу, куда поместил все стилизованные виджеты и элементы. Добавлять их в книгу я решил копи-пастом. Можно работать, хотя и не так удобно, как вышло бы с нормально работающими шаблонами.

Недавно, смотря закладки по тегу “iBooks” в pinboard, наткнулся на статью о том, как получить действительно полноэкранное изображение. Без лишних рамок, заголовков и описаний. Внезапно, в конце статьи я нашел решение своей старой проблемы с заполнителями.

Отгадка

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

Формат – Дополнительные параметры – Определить как заполнитель (медиа-файлов или текста).
В разделе инспектора “макет” нужно выставить чекбокс “редактируемы на страницах использующих этот макет”.

Я потратил много полезного времени из-за того, что не знал этого решения. Из-за того, что в документации к iBooks author не нашел упоминания о нужном чекбоксе. Но я рад, что я теперь знаю правильное решение. Теперь я могу использовать шаблоны.

Почему я учу NODE.JS

2012-05-02T00:00:00+00:00

Как многие (если не все), знают, я пишу на python. Пишу каждый день, и мне это нравится. Ради веселья и опыта я начал писать на django, и перенес на него множество строк нативного питона.

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

Я посасывал в HTML, CSS, и JavaScript.

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

Я начал заниматься веб-разработкой в те времена, когда javascript был всего лишь игрушкой, которую использовали для анимации меню. Теперь же этот язык используется везде: на стороне сервера (nodejs), на стороне клиента, и даже в базах данных (mongoDB).

Что ж… Я несколько лет не придавал должного значения JS, теперь же я решил наверстать упущенное, и погрузился в изучение языка. Я поставил себе цель — стать опытным js-разработчиком, и уметь:

Использовать некоторые из новых JS-фрэймворков и инструментов (node, backbone, knockout… )
Принимать участие в разработке тех js-проектов, которые мне интересны.
Писать свой собственный js код, как server side, так и client side, не чувствуя себя тупицей.
Быть в теме всей этой шумихи вокруг js.

К этому моменту, я имел хорошее представление о концепциях программирования. Первая вещь, которую я сделал - прочитал «Javascript: The Good Parts». Это было несколько недель назад, и, до сих пор, я не мог найти хорошей возможности применить полученные знания на практике.

Если ты - опытный программист, и у тебя есть желание получше разобраться с JS, то вряд ли есть лучшей способ, чем «JavaScript: The Good Parties». Эта книга очень приятная, короткая и содержательная. В первую очередь я советую прочитать эту книгу.

Так вот… Я раздумывал о подходящем месте для применения своего нового javasrcipt-фу, и остановился на nodejs. В прошлом я писал большое количество консольных приложений, поэтому меня воротило от бесконечной перезагрузки страниц в браузере, необходимой для отладки своего кода. Nodejs стал подходящим выбором в этом отношении.

Если кто-то не знаком с node.js - это серверный javascript интерпретатор, позовляющий работать с js прямо из командной строки, как с ruby и perl. В комплекте с node.js идет отличный пакетный менеджер — npm, позволяющий легко отправлять, скачивать и устанавливать js-модули.

Раньше я прочитал много негативных отзывов о nodejs, но теперь я могу им только удивляться, ведь node чертовски крут! Я еще не использовал его для создания веб-сайтов или чего-то подобного, но он реально делает js очень простым для таких ребят как я - матерых backend программистов, которые хотят разобраться с JavaScript’ом без глупых барьеров (да-да, сейчас я смотрю именно на вас, браузеры).

У node есть отличный пакетный менеджер, тонны потрясных модулей, огромное сообщество разработчиков, и отличная документация. Я написал свой первый модуль node-opencnam меньше чем за час. Это безумно круто!

Я проделал путь от нулевой отметки до публично доступного модуля меньше, чем за 60 минут!

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

Я буду держать вас в курсе.

В эти выходные я начал читать книгу «Node Beginner Book».