От переводчика: Я думаю многие читали статью Rey Bango — What to Read to Get Up to Speed in JavaScript, но до хабра обсуждение так и не докатилось. Предлагаю закрыть этот пробел и поговорить о хороших книгах, блогах, тренингах и конференциях, посвященных в первую очередь клиентскому JavaScript и клиентской веб-разработке. Чтобы не копипастить оформляю статью в виде перевода.

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

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

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

Не так давно, а именно в октябре 2010 года, компания Zend немного обновила систему сертификации PHP5 инженеров. Так, если раньше тестирование проводилось по версии 5.1, то теперь проводится по 5.3 (привет namespaces, late static bindings и замыкания). Были переформированы темы тестирования — вместо 12ти прежних, теперь их 10. И что самое главное, из Zend маркета убрали подготовительные тесты. Раньше их можно было приобрести в количестве 1, 5 или 10 штук за относительно скромные деньги (10 стоили порядка 22$). Сейчас же вместо них за довольно-таки нехилую сумму в 1000$ можно приобрести так называемый Test Prep: Zend PHP 5.3 Certification Training (подготовительный online-треннинг для продвинутых php-программистов) и ваучер на прохождение тестирования. Кстати, о ваучере… если для версии 5.1 он стоил 125$, то теперь цену подняли до 195$.

Я, как человек, связанный университетом с Java, следил за развитием NetBeans практически с момента его становления изначально меня принудил ей пользоваться мне показал эту IDE мой учитель — Вадим Монахов (с гордостью обнаружил, что ссылка на него ведет с wikipedia, раздел литература). Сейчас часто сталкиваюсь с тем, что программисты PHP пишут говнокод ссылаясь на недоразвитость IDE не умеют делать Refactoring и многих из них останавливает отсутствие автоматизированных средств. Собственно, я решил отобрать у них этот аргумент: средства есть и сегодня я рассмотрю NetBeans как среду разработки для PHP и продемонстрирую заложенную в нее мощь.

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



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

Я — PHP-Developer, живу в Стокгольме. Недавно был на собеседовании в один большой шведский сайт (более миллиарда page views в месяц). Интервью проводили 2 программиста из этой фирмы. В определенном моменте, один из них достал листок бумаги и сказал, что предлагают мне решить небольшую задачку (тут же на бумаге, без компьютера). И что у меня есть 10 мин. Попросили так же комментировать каждый шаг.

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

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

Ниже — сама задача. Оставляю все в оригинале, как было.

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

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

Интро

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

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

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

Недавно мне нужно было написать парсер для строки поиска, который приводит строки вида
(aa&bb)^(!cc^!(dd^ee)) в строку вида куска SQL: (?f LIKE "%aa%" AND ?f LIKE "%bb%") OR (?f NOT LIKE "%cc%" OR !((?f LIKE "%dd%" OR ?f LIKE "%ee%")) ). Я написал like и SQL для упращения, на самом деле там был SPHINX, да и не оптребовалось оно в конце концов, но разговор о том как я этого добился написав формальные грамматики и реализовав их на PHP.

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

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

Результат моих потуг вы можете обнаружить здесь. В архиве вы найдёте скрипты, необходимые для функционирования библиотеки, и пример её работы (sample.php). Библиотека собрана как standalone.

Но, я полагаю, интересно было бы разобраться, что там к чему.

О чем пойдет речь?

Мне очень часто приходится проводить собеседования, нанимая на работу PHP-программистов. 2-3 человека в день — это вполне нормально, хотя и на грани выносливости.

Все кандидаты разные, кто-то просто великолепен, кто-то похуже. Но у тех, кто похуже, всегда одни и те же ошибки.

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

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

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

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

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

Давайте попробуем сделать интерпретатор Форта на PHP!

Форт меня всегда манил, как далекая галактика из антиматерии. Стек, слова в словаре, обратная польская нотация… Это только кажется сложным, но на самом деле очень просто, зато здорово «просветляет» и расширяет кругозор.

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

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

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

Итак, что имеем в «ДАНО»

• Имеем 120 чекбоксов — вариант 1/0
• Имеем 30 «радио» с выбором «да/нет/не важно»
• Имеем 2-3 слайдера для указания диапазона цен/размера чего нить
• Имеем самое главное: 12 млн записей в БД.
• Имеем Select * From tovar Where (wifi=true) and (led=false) and (type=3) and ….остальные параметры …; со временем выполнения близкому к истерике клиента.

Некоторое время назад я узнал о лямбдах, но не совсем понимал принципов построения выражений с лямбдой. Но сегодня наткнулся на пост Charlie Calvert'а и всё для себя прояснил.

Предисловие

Эта статья будет посвящена новичкам в скриптовании Unity, но не совсем новичкам в синтаксисе JavaScript’а или любого другого подобного языка программирования. Тут надо маленько уточнить что JavaScript который использует Unity немного отличается от оригинального в пользу улучшенной поддержки ООП и называется соответственно Unity JavaScript. В нем например появились классы и их наследование, о чем не знают начинающие разработчики на Unity знакомые с объектно ориентированными возможностями оригинального JavaScript, поэтому отвергают его используя C# или Boo.

Сделано под вдохновением этого топика.
Обычный JavaScript, к которому все привыкли, не даёт средств работы ни с файловой системой, ни с двоичными данными, поэтому все описанное ниже будет про node.js.

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

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

Предыстория

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

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

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

Введение

Так уж повелось, что любую статью о нечеткой логике принято начинать с упоминания имени Лотфи Заде. И я не стану исключением. Дело в том, что этот человек стал не только отцом-основателем целой научной теории, написав в 1965 году фундаментальный труд «Fuzzy Sets», но и проработал различные возможности ее практического применения. Он описал свой подход в 1973 году в тексте «Outline of a New Approach to the Analysis of Complex Systems and Decision Processes» (опубликованном в журнале IEEE Transactions on Systems). Примечательно, что сразу после его выхода одна предприимчивая датская фирма весьма успешно применила изложенные в нем принципы для усовершенствования своей системы управления сложным производственным процессом.

Но при всех заслугах Л. Заде, не менее важный вклад внесли последователи этой теории. Например, английский математик Э. Мамдани (Ebrahim Mamdani). В 1975 году он разработал алгоритм, который был предложен в качестве метода для управления паровым двигателем. Предложенный им алгоритм, основанный на нечетком логическом выводе, позволил избежать чрезмерно большого объема вычислений и был по достоинству оценен специалистами. Этот алгоритм в настоящее время получил наибольшее практическое применение в задачах нечеткого моделирования.

О чём эта статья

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

В этой статье я напишу как устроен алгоритм шифрования AES (которого иногда называют Rijndael) и напишу его на JavaScript. Почему на JavaScript? Чтобы запустить программу на этом языке, нужен только браузер в котором вы читаете эту статью. Чтобы запустить программу, скажем, на C, нужен компилятор и найдётся совсем мало желающих, готовых потратить время на компиляцию кода из какой то статьи. В конце есть ссылка по которой можно скачать архив с html страницей и несколькими js файлами — это пример реализации AES на JavaScript.

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

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

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

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

var process = processFsAndDb.after('fs', 'db');

asyncFsAccess( file, process.fs);
asyncDbAccess(query, process.db);