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

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

Нет, не Intel. Intl — JavaScript объект, содержащий в себе функции форматирования чисел, дат и сравнения строк. Приходит, потому что 29 апреля Firefox, последний из популярных браузеров, не поддерживающий Intl, обновляется до 29 версии, в которой поддержка интернационализации будет включена.

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

Что же даёт Intl JS программисту?

Вступление

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

К счастью, теперь в Chrome Canary DevTools вы можете отслеживать весь стек вызовов асинхронных функций в JavaScript!

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

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

Под катом попробуем разобраться чем отличаются «высокотехнологичные» компании от «низкотехнологичных», что нужно, чтобы высокотехнологичные компании могли рождаться и выживать, почему с софтом у нас лучше, чем с хардом, с чего начиналась кремниевая долина в США и можно ли её «скопировать», почему Китай всех рвет, а также — окинем взором все, что происходит в Сколково, Роснано, фонде перспективных исследований и приведут ли они к расцвету российских инноваций. Безусловно, я где-то могу ошибаться — буду рад дополнениям в комментариях.

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

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

Что же, в последнее время, в своей работе я во всех проектах задействую lodash (кому-то может больше нравиться underscore). Для меня это, фактически, — стандарт. В очередной раз пробегая глазами API, я решил составить для себя шпаргалку в виде: «название функции» — «краткое описание». Так удобно освежать API в памяти. Может кому пригодится.

Давно не видел статей о BitTorrentSync, и очень удивляюсь: ведь это такой полезный инструмент. Буквально на днях вышла новая версия*, и я решил рассказать, как применил это решение на работе.

Начало

Однажды в нашей компании наступил момент, когда встала необходимость обмениваться довольно тяжёлыми файлами — макетами продукции и упаковки (100-500 мегабайт) между офисами в Москве, Екатеринбурге и офисом в провинции Чжэцзян, КНР. Сложность была в катастрофически низкой скорости и надёжности связи РФ — Китай.

Когда я обратил внимание на проблему, царил полный разброд и шатание:

Предисловие

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

• Получения части конфигурации с веб сервера — Mozilla AutoConfig (https://developer.mozilla.org/en-US/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig)
• Интеграции части конфигурации в дистрибутив продукта (плагина для продукта)
  — CCK (https://addons.mozilla.org/en-US/firefox/addon/cck/)
• Получение части настроек из GPO GPOFirefox (https://addons.mozilla.org/ru/firefox/addon/gpo-for-firefox/)

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

Я стал замечать, что в последнее время build-системам стали уделять всё больше внимания, и, под влиянием этого, их в одночасье стало настолько много, что, честно говоря, уже всех и не упомнить. Последнее время у меня на слуху четыре системы: Grunt, Gulp, Brunch и Gear. Про все что-то где-то было написано, но ни разу не ставился вопрос о том, какие преимущества или недостатки они имеют друг перед другом? И именно поэтому я решил провести сравнительный анализ самых популярных build-систем(по версии google).

Но сперва надо определиться с критериями, по которым мы будем оценивать эти системы:

• Начало работы.
• Производительность. Никто не хочет ждать по минуте после изменения одного coffee-файла.
• Документация. Чем нагляднее и проще — тем лучше.
• Плагины. Ведь мы не хотим столкнуться с проблемой, когда мы начали использовать билд-систему, а в ней нет адаптера, скажем, для jasmine?

Теперь, я полагаю, с вводной частью можно покончить и приступить, наконец, к сравнению.

В течение минуты думал над заголовком, так ничего и не придумал…
Strace. Наверное нет того человека, который бы не слышал про strace. Если кто не слышал, то strace — это утилита, отслеживающая системные вызовы, которые представляют собой механизм трансляции, обеспечивающий интерфейс между процессом и операционной системой (ядром). Эти вызовы могут быть перехвачены и прочитаны. Это позволяет лучше понять, что процесс пытается сделать в заданное время. Перехватывая эти вызовы, мы можем добиться лучшего понимания поведения процессов, особенно если что-то идет не так. Функциональность операционной системы, позволяющая отслеживать системные вызовы, называется ptrace. Strace вызывает ptrace и читает данные о поведении процесса, возвращая отчет. Детали можно прочитать в вики или официальном man. Собственно вот, ну и речь конечно же о Linux. В других ОС свои аналоги.
Так вот, лично для меня strace это как последняя инстанция. Когда уже все логи просмотрены, все debug и verbose ключи включены, а причина проблем так и не обнаружена, я достаю из широких штанин запускаю strace. Есть одно но, strace это такой инструмент который вовсе не является серебряной пулей, которая тут же все покажет и расскажет. Для работы с strace требуется наличие определенных знаний и чем шире и глубже эти знания тем больше вероятность обнаружения проблемы.
В интернетах полно вводных статей, где описываются примеры запуска strace. Я же в этой статье покажу частные проблемы и их решение с помощью strace.

Довольно часто, выступая на различных конференциях, мы делились желанием выпустить под открытой лицензией KittenPHP, согласно традиции, заложенной крупными IT-компаниями, такими как Google и Facebook.

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

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

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

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

Справиться со всеми этими проблемами, призван помочь Capo – модуль, который служит для управления событиями в event-driven js архитектуре и решает один из самых больших недостатков шаблона Mediator – неопределенность триггеров и подписчиков.

Мы уже рассказывали на Хабре про облачную инфраструктуру Яндекса. Сегодня пришёл черёд от слов перейти к делу — мы хотим по шагам показать, как можно развернуть собственное облако на Elliptics и Cocaine.

Схема

Давайте рассмотрим установку небольшого облачка, в котором можно запустить тестовое приложение использующее flask.

Это облачко состоит из следующих элементов:

• cocaine-runtime, запускающий приложения в Docker;
• Docker-registry для хранения образов приложений;
• Elliptics в качестве распределенного хранилища приложений, а также конфигурации облака;
• агрегирующая нода cocaine-runtime — единая точка входа в облако для клиентского кокаинового кода;
• HTTP-frontend как альтернативный способ для доступа к приложениям.

С началом эпохи HTML5, рынку понадобилось большое количество JavaScript программистов. Многие специалисты по другим языкам, начали массово переориентироваться на JavaScript. Я много раз видел, как программисты с большим опытом ругали этот, один из самых гибких и могучих, язык, не понимая его принципов. В этой статье я постараюсь рассказать суть и философию JavaScript. Здесь будет всего 4 строчки кода и много-много того, что не напишут в учебниках. Обещаю, что вы полюбите этот язык, или по крайней мере, станете эффективнее в нём. Итак, поехали!

История

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

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

И наконец, в один прекрасный день вы решили: “Сделаем это!”. И вот вы уже пытаетесь разобраться как реализовать бизнес-логику своего приложения, ту киллер-фичу, которая будет двигать продукт вперед. У вас есть идея как это сделать, и вы знаете, что способны на это. И вот вы говорите: “Готово! Работает!” У вас есть успешный прототип! Осталось только упаковать его в веб приложение.

“Окей, сделаем сайт,” говорите вы.

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

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

“Я перегружен”, говорите вы и чувствуете себя перегруженным. Энергия уже не та, что была в начале. Вы пытаетесь собраться с мыслями, но работы слишком много. Прототип медленно блекнет и умирает.

Одной из самых интересных частей нового стандарта ECMAScript 6 являются стрелочные функции. Стрелочные функции, как и понятно из названия определяются новым синтаксисом, который использует стрелку =>. Однако, помимо отличного синтаксиса, стрелочные функции отличаются от традиционных функций и в других моментах:

• Лексическое связывание. Значения специальных переменных this, super и arguments определяются не тем, как стрелочные функции были вызваны, а тем, как они были созданы.
• Неизменяемые this, super и arguments. Значения этих переменных внутри стрелочных функций остаются неизменными на протяжении всего жизненного цикла функции.
• Стрелочные функции не могут быть использованы как конструктор и кидают ошибку при использовании с оператором new.
• Недоступность «собственного» значения переменной arguments.

Было несколько причин для введения этих отличий. Первоочередная — это то, что связывание (binding) используется довольно часто в JavaScript. Очень легко потерять нужное значение this при использовании традиционных функций, что может привести к непредсказуемым последствиям. Другая причина, это то, что JS-движки смогут легко оптимизировать выполнение стрелочных функций за счет этих ограничений (в противоположность традиционным функциям, которые могут быть использованы в качестве конструктора и которые свободны для модификации специальных переменных).

В данной статье я постараюсь познакомить вас с замечательными утилитами Vagrant и Chef на примере автоматического конфигурирования development environment для PHP разработчика (на самом деле, PHP здесь только как пример, все нижеописанное может быть использовано для любого стека технологий).

Что будем делать?

Будем настраивать виртуальную машину (ВМ) с Ubuntu 12.04 для работы над проектом на PHP, а именно:

• Apache
• MySql
• PHP 5.4
• xDebug
• Memcached
• Composer
• Настроим сразу Virtual Host на определенную папку, доступную как с виртуальной машины, так и с реальной. Всё это параметризируем для удобства создания и использования.
• и другое..

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

Как это может помочь вам?

• Вы не хотите «засорять» свою систему множеством утилит, программ
• Вы хотите тестировать свой код в приближенных к production условиях
• Вы хотите тестировать свой код на разных версиях той или иной платформы (помните, как Travis тестирует билды в различных конфигурациях, например Symfony на разных версиях PHP)
• Вы не хотите больше помогать новому человеку на проекте (верстальщик, программист) устанавливать всё с нуля
• Вы хотите, чтобы у каждого человека в команде была идентичная среда для работы над проектом

Всё это — реальность. Вопрос только «как?».

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


^{photo by Patrick Pleul/AFP/Getty Images}

Джед МакКалеб — известная фигура в мире Bitcoin и p2p. В 2000 году он создал одну из первых успешных файлообменных сетей eDonkey, а в 2010 — открыл биржу Mt. Gox, которая в течение нескольких лет была крупнейшим обменником Bitcoin. Важно отметить, что в 2011 он продал Mt. Gox, и не имеет никакого отношения к проблемам, которые биржа испытывает сейчас.

C 2011 года МакКалеб работал над созданием распределённой биржи Ripple для обмена любых валют и товаров. Однако сейчас на официальном сайте Ripple Labs (ранее — OpenCoin) — организации, которая ведёт разработку и продвижение Ripple, он не упоминается в составе команды проекта. Недавно было опубликовано видеоинтервью с ним, где он подтверждает, что больше не сотрудничает с Ripple Labs. В профиле МакКалеба в LinkedIn указано, что он работал в OpenCoin до июля 2013 года.

10 февраля МакКалеб зарегистрировал домен secretbitcoinproject.com, на котором сейчас висит заглушка в виде фотографии планеты Нептун и следующего текста:

Когда я продал Mt. Gox несколько лет назад, биткоин стоил меньше доллара. Сегодня Биткоин существует в новых условиях. Mt. Gox с трудом удаётся поспевать за ними. Теперь я создаю кое-что, что принесёт пользу как Биткоину, так и всем вам.

Мне нужны альфа-тестеры.

Джед.

Никаких подробностей о своём секретном проекте МакКалеб пока не распространяет — лишь добавляет, что в данный момент он нанимает разработчиков и дизайнеров. Учитывая его опыт в создании распределённых приложений и роль, которую он сыграл в экосистеме Биткоин (его имя не раз и не два всплывало в спорах о настоящей личности легендарного создателя Биткоин Сатоши Накамото) — это может оказаться перспективным и интересным проектом. Для того чтобы лучше понять взгляды МакКалеба на будущее цифровых валют, будет полезно подробнее остановится на его последнем проекте — Ripple.

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

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

Я разработчик, работающий с Ruby on Rails (до этого я программировал в .NET и Python). Для меня было довольно проблематично понять магию, заставляющую Ember.js работать. Иногда я общаюсь с другими начинающими разработчиками, вставшими (или пытающимися встать) на путь Ember.js — все их проблемы начинаются из-за того, что они не понимают, как устроен данный фреймворк.

Да, с одной стороны есть официальная документация в которой детально описаны все аспекты данного фреймворка. Но ей не хватает концепции; для начинающего разработчика это просто осколки информации разбросанные случайным способом. Из документации, например, можно узнать что у нас есть в арсенале контроллеры, модели и виды (controller, model, view). Но для того что-бы узнать за что они отвечают и как работают начинающему разработчику предлагают сначала наступить на грабли пару десятков раз. Плюс в нагрузку к контроллерам, моделям и видам Ember.js нам дает целый взвод разношерстых объектов типа компонентов, шаблонов, маршрутизатора и путей (component, template, router, route).