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

Добрый день всем.

Недавно столкнулся с интересной проблемой, связанной с апдейтом MVA (multi value attributes).

Начальные условия:

• sphinx-1.10-beta
• sphinx php api

В рамках поставленной задачи мне нужно было реализовать on-a-fly апдейты mva аттрибутов. С начала всё показалось достаточно просто – берём функцию UpdateAttributes() из php-шной API и пишем нужные апдейты. Написал нужную обёртку, стал тестить – все отлично работает. Даже как то не поверилось что так быстро получилось – значит где то есть подвох. Начал тестить, так сказать, с фанатизмом – и подвох всплыл практически сразу.

Библиотека jQuery — это общепризнанное средство манипуляции сразу несколькими форматами данных (XML, HTML, объекты DOM, обыкновенные объекты), да притом работающее посредством удобного (цепного) вызова методов с удобными (краткими) названиями. Поэтому ничуть не удивляют попытки приспособить jQuery не только к одному клиентскому, но также ещё и к серверному джаваскрипту — в частности, к Node.js.

Признаюсь честно, что когда разработчики jQuery превозмогли проблему №7102, то её название («Register jQuery as a CommonJS async module») на какое-то время даже заставило меня обмануться: я сперва подумал было, что и в Node.js (так как модули Node.js и СommonJS имеют немало общего) отныне jQuery станет работать невозбранно. Ан нет, не тут-то было. Пристальное вглядывание в коммит и в запрос на слияние позволяет осознать, что jQuery, в сущности, обрёл возможность регистрироваться только как AMD-модуль и даже проверяет свойства define.amd и define.amd.jQuery перед саморегистрацией.

Собственно говоря, архитектура jQuery «затóчена» под употребление в условиях браузерной DOM: код jQuery полагается на существование объекта window, который служит аргументом главного замыкания, окаймляющего весь код jQuery. Прежде же таких неявных предположений было ещё больше, и только с устранением проблемы №6690 библиотека jQuery перестала полагаться на существование глобальных объектов navigator и location, начав вместо того получать их как свойства объекта window. (Понятно, что такое предположение никак не подходило для Node.js, где глобальные объекты служат свойствами объекта global, а вовсе не window; а равно не подходило и ко многим прочим реализациям CommonJS.)

Потому для запуска jQuery в Node.js применяются готовые реализации браузерной DOM — такие, как пакет jsdom, на основе которого невозбранно работает, например, вот какой код, предлагаемый в качестве примера:

MongoDB — документо-ориентированная система управления базами данных хранящая данные в виде наборов JSON-подобных документов. Для работы с MondoDB в PHP используется pecl расширение mongo, позволяющее полноценно работать с СУБД используя объекты доступа.
В статье пойдет речь об ORM (Object-relational mapping) standalone библиотеках и фреймворках позволяющих упростить использование Mongo в PHP проектах и предоставляющих интерфейс к работе с данными.

«Сталкиваясь с информационными перегрузками, мы не имеем другой альтернативы кроме восприятия по образцам (стереотипам)» Маршалл Маклюэн

Привет всем! Многие уже наверное слышали, а некоторые уже пробовали сервис ResumUp.com. Вы могли слышать о нас по результатам конкурсов WebReady и TechCrunch Moscow. Мнение российских и международных экспертов, конечно, ценно, но живая обратная связь пользователей для нас куда важнее. Также, в связи с локализацией сервиса для российского рынка, мы хотим еще раз пробежаться по основной идее и функционалу сервиса.
Суть проекта — визуализация ваших профессиональных достижений и, как следствие, вашего резюме. Поэтому я постараюсь обойтись минимумом слов и представить сервис визуально.

Долгое время в своих проектах в случае необходимости шифрования, практически автоматически, выбирал AES (он же Rijndael), входящий в библиотеку Mcrypt.

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

Приветствую вас, уважаемый хабрачеловек!

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

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

Из видеокурса вы узанаете:

• С чего начать разработку плагина.
• Что такое хуки, экшены и фильтры.
• Как сделать страницу настроек плагина в админке блога.
• Принципы программирования на PHP функционала плагина.

Не так давно молодая команда разработчиков YTG (Yocto Technology Group) отпраздновала свой первый релиз. Когда я увидела то, что у них в итоге получилось, то была приятно удивлена. McGyro, а именно так называется их игра для iPad, iPhone и iPod Touch, порадовал меня интересной концепцией геймплея, основанной на наличии в устройствах гироскопа, весёлой и лёгкой манерой подачи сюжета, остроумными диалогами, а также запоминающимся визуальным стилем. В художественном исполнении игры, мне, как большому любителю мультяшного стиля, понравилось всё. Нарисовано довольно лаконично, но в то же время стопроцентно передаёт атмосферу американского вестерна. Дух дикого дикого запада чувствуется везде, даже в главном меню игры, которое стилизовано под старый деревянный указатель, слегка раскачивающийся на ветру на фоне пустынного ландшафта. Так и тянет выбрать дорогу и отправиться на поиски приключений.



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

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

Find — аналог SELECT в MySQL. Используется для выборки документов из MongoDB. Возвращает массив документов в виде коллекции, если документов нет — пустую коллекцию. Пример:

> db.users.find();

Вернёт всех пользователей из коллекции.

> db.users.find( { age: 27 } );

Вернёт всех пользователей, у которых возраст равен 27.

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

Этот пост участвует в конкурсе „Умные телефоны за умные посты“.

Ни для кого не секрет, что сегодня мобильные игры очень популярны. Возможность написать одну из таких игр есть у каждого разработчика, даже начинающего. Часто возникает вопрос с выбором платформы. Конечно, хочется, чтобы игра была сразу везде: на iOS и Android, на WP7 и MeeGo, на десктопе и в браузере. И чтобы все это можно было лекго реализовать с помощью бесплатных инструментов.



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

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

Данная статья написана по следам статьи Steve Yegge. A portrait of a n00b (с подачи хабраперевода). Для меня основной посыл статьи прозвучал так — меньше комментариев, меньше классов, меньше методов, больше кода. Делайте код плотнее, не усердствуйте в моделировании. Мне сложно судить это видение мира, да и вообще вопрос комментариев как таковых больше умозрительный. Но вот что засело во мне стальной иглой, так это проблема тестирования такого плотного кода.

Описание проблемы

Представим среднестатистический высоконагруженный сайт. Обычно на таких сайтах между backend'ом и DB ставят прослойку кеша. С увеличением количества посетителей, вероятность того, что несколько пользователей одновременно наткнутся на "протухший" кеш увеличивается. Если такое случается, то нагрузка на backend и DB возрастает, что в свою очередь увеличивает время обработки запроса и увеличивает вероятность возникновения подобной ситуации. Вот такая вот система с положительной обратной связью:Маленькие красные горбики — это "затупившие" на множественном обновлении кеша запросы. Эта статья будет описывать один из подходов к решению проблемы на примере(patch attached) связки PHP/APC, однако теоретическая база применима к любому языку и системе кеширования.

Итак, позавчера Корпорация Добра все-таки закрыла свой бесплатный Translate API. Автор до последнего момента надеялся, что они образумятся и не станут уподобляться остальным так поступать. Поэтому не чесался и ничего не делал. Но вот гром грянул. И в CMS одного небольшого 3-х язычного проекта отвалился переводчик. Не страшно, но неприятно — раньше админ на форме редактирования контента 1 щелчком мыши переводил все поля еще на 2 языка. Переводчик я написал по своей милости, потратил на это минут 20 и не взял за это ни копейки. Тем не менее, клиент звонит, грозится физической расправой над любимым хомячком, просит, опять угрожает. Пришлось закрывать баш и искать альтернативы.

Под катом список (4 варианта, никаких откровений / открытий) чего нашел автор, а также рецепт Javascript-перевода от Bing.

Совсем недавно я побывал на мини-конференции местного разлива, где я размышлял на тему фриланса, с точки зрения веб-дизайнера. Даже подготовил для этого действа презентацию (на украинском). Здесь же попробую описать то, что хотел донести до слушателей Coffee Design Code.

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

В статье рассматриваются особенности применения шаблонов Visitor/Double Dispatch и State при реализации системы на основе конечного автомата. Кроме того, статью можно рассматривать как продолжение цикла публикаций о шаблонах проектирования на Хабрахабре.

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

1. Пишите документацию во время создания API

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

2. Будьте постоянным

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

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

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

{users:[{user:{...}}, {user:{...}}]} // нет
{users:[{...}, {...}]} // да
{username: 'jnunemaker'} // нет
{user: {username:'jnunemaker'}} // да

Ну вы поняли. Постоянство ― важно. Всегда следует придерживаться одного формата.

На данный момент времени, есть следующие альтернативы github:

• Сам github fi (стоит 5000$, не open source)
• Gitorious (open source, написан на RoR, использует ActiveMQ, короче — зверь машина)
• Недавно появившийся gitlab (open source, написан на ruby)

В этот список я хотел бы добавить мое приложение. Может быть, оно еще кому то пригодится. Что у него внутри:

Добрый день, Хабр.

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

В первой (этой, то бишь) статье, на примере простейшего расширения, будут рассмотрены все основные моменты, связанные с разработкой, отладкой и использованием расширения, конфигурационный файл manifest.json и начала chrome.* API. Первая же статья, думаю, будет не очень полезна опытным разработчикам (это дисклеймер).