Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

Некоторые люди, столкнувшись с проблемой, думают: «О, а использую-ка я регулярные выражения». Теперь у них есть две проблемы.
Джейми Завински

Юан-Ма сказал: «Требуется большая сила, чтобы резать дерево поперёк структуры древесины. Требуется много кода, чтобы программировать поперёк структуры проблемы».
Мастер Юан-Ма, «Книга программирования»

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

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

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

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

На написание этого поста меня сподвиг замечательный пост «За что конкретно я ненавижу некоторых отдельно взятых маркетологов — или как айтишник по магазинам ходил». Сразу хочу извиниться за возможные опечатки — пишу с планшета, сидя в микроавтобусе и вытягивая сеть телефоном. Hacker's keyboard очень удобен для ssh-доступа, но большие тексты писать им не очень удобно.

IT- специалисты — народ любопытный. То соберут на базе микроконтроллеров автоматическую систему полива и освещения для любимого фикуса, то пропатчат прошивку мультиварки для раздачи торрентов. Но, по непонятной и загадочной причине, когда дело доходит до еды, пресловутый принцип DIY дает сбой. И наш герой, способный часами переделывать кинескоп старого телевизора в Луч Смерти, идет на кухню утолить голод соевым текстуратом пополам с гидроцеллюлозой и «коллагеновым сырьем».

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

Вводная часть

Так сложилось, что я переехал жить и работать из Москвы в Минск. Часто видел подобные материалы про аналогичные переезды в какие-то экзотические для меня или совсем далеки страны, я же хочу поделиться опытом эмиграция «к соседям».

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

Если возникнут какие-то вопросы, напишите в личку или в комментарии к посту.

Привет! Меня зовут Сергей Константинов, в Яндексе я руковожу разработкой API Карт. Недавно я поделился опытом поддержки обратной совместимости со своими коллегами. Мой доклад состоял из двух неравных частей. Первая, большая, посвящена тому, как правильно разрабатывать API, чтобы потом не было мучительно больно. Вторая же про то, что делать, если вам нужно что-то рефакторить и не сломать по дороге обратную совместимость.



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

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

В этой статье я подробно расскажу и покажу, как правильно и быстро прикрутить распознавание русской речи на движке Pocketsphinx (для iOS порт OpenEars) на реальном Hello World примере управления домашней техникой.
Почему именно домашней техникой? Да потому что благодаря такому примеру можно оценить ту скорость и точность, которой можно добиться при использовании полностью локального распознавания речи без серверов типа Google ASR или Яндекс SpeechKit.
К статье я также прилагаю все исходники программы и саму сборку под Android.

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

Что такое Монады?

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

В этой статье я не буду говорить о том зачем в javascript нужны промисы и в частности JQuery.Deferred. Также не буду приводить справочную информацию, ее достаточно в интернете. Например тут или тут или вот тут.
Эта статья для тек кто уже немного знаком с объектом Deferred из библиотеки JQuery, но не имеет опыта написания сложных цепочек (очередей).

Подготовка

Все примеры кода, рассмотренные здесь, используют асинхронный метод $.ajax(), который возвращает так называемый jqXHR в котором реализованы промис-методы (done, fail, always, then). Нам нужны будут только они, поэтому будем считать что $.ajax возвращает промис (promise).
В некоторых примерах используются методы $.map() и $.each(), которые входят в состав библиотеки JQuery.

Последовательное выполнение

Простейшее использование промисов — это последовательное выполнение асинхронных операций. То есть следующая операция не начинается пока текущая не закончится.

$.ajax('http://echo.jsontest.com/id/1')
.then(function(result){
    console.log(JSON.stringify(result));
    return $.ajax('http://echo.jsontest.com/id/2')
}).then(function(result){
    console.log(JSON.stringify(result));
    return $.ajax('http://echo.jsontest.com/id/3')
}).then(function(result){
    console.log(JSON.stringify(result));
});

Живой пример тут.

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

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



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

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

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

Попытался начертить схему моей комнаты со всеми устройствами объединёнными в сеть, картинка кликабельна:



Вся идея держится на трёх китах:

• Децентрализация — вся система функционирует без какого-либо главного модуля;
• Простота — минимум компонентов и лёгкость подключения;
• Дешевизна — себестоимость устройства легко уложить в 100 рублей.

Тема «Умный дом» уже у всех на слуху. Про неё говорят, в неё вкладывают, её развивают… По этой теме к таким гигантам как Siemens, General Electric и др. присоединились, казалось бы, не совсем профильные компании, такие как Microsoft, Google, Apple.

Единого стандарта по теме нет, равно как нет инструкции, мол, «делай так и вот так», поэтому теоретически построить свой умный дом может каждый и именно так, как ему захочется и потому эту тему я не смог пропустить и активно к ней подключился. Не скажу, что с умными домами я собаку съел… нет, скорее так, понадкусывал, но тем не менее, на основе свое опыта и своих наблюдений попробую выложить развёрнутый… ммм… How-To? Нет, не потянет. Обзор? Тоже не то… Скорее это будет напутствие или некий набор советов.

Театр начинается с вешалки, а я начну с того, что сразу расставлю все точки над «И», чтобы у читателей не возникало в процессе чтения необоснованного негатива или просто какого-то недопонимания.

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

Теперь термин.
Будем честны, «Умный дом» — это не только такая система с искусственным интеллектом, которая разговаривает с Вами по утрам в ванной (пока вы бреетесь) и готовит Вам ужин пока вы едете домой. Не нужно путать систему с женой.

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

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.