В прошлой статье я начал рассказывать о своём опыте разработки экспериментального WEB-проекта «Что делать?» на Node.JS. Первая часть была обзорной, в ней я постарался раскрыть плюсы и минусы технологии, а также предупредить о проблемах, с которыми, возможно, придётся столкнуться в ходе разработки. В этой статье я подробнее остановлюсь на технических деталях.

Несколько слов о «хабраэффекте»

TL;DR:

• Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек.
• На 1 соединение тратится чуть больше 10 Kb памяти (4.1 Kb Javascript Heap + 2.2 Kb Node.js Native + 3.8 Kb Kernel)..
• V8 Garbage Collector не рассчитан на управление > ~500Mb памяти. При превышении нужно переходить на альтернативный режим сборки мусора, иначе «отзывчивость» сервера сильно уменьшается.
• Подобный опыт можно (и нужно!) без особых затрат повторить самому (см. под катом).

Прошла неделя с момента пиара на хабре моего проекта «Что делать?». Я напомню, что этот проект начинался, как эксперимент по разработке среднестатистического WEB-проекта целиком на JavaScript (Node.JS). Сейчас я хочу поделиться с сообществом результатами этого эксперимента, полученным полезным опытом, а также подробной картой с отмеченными на ней граблями.

Эпизод 1: начало пути

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

Наблюдая за своими родителями-пенсионерами, а точнее за размерами их пенсий, я крепко задумываюсь о том, как обеспечить себе нечто оное в достойном меня размере. На государство в составе СНГ рассчитывать, похоже, не приходится. Значит, надо что-то делать самому! И начинать надо сейчас, пока мне 32 года, есть какой-никакой заработок и силы крутиться. Раньше были мысли, что я буду вечно молодым, вечно здоровым и все время что-то делать. Постепенно начинаю осознавать, что лет 20… 30 — и силы будут таять (или распыляться). Поэтому пару лет назад я начал понемногу что-то делать в этом направлении. Получил некоторый опыт, который может быть интересен уважаемому сообществу. Даже если для читателя вопрос пенсии сейчас звучит безумно абстрактно, то все равно рекомендую хотя бы пробежаться. Если бы я 5 лет назад почитал такой материал — я был бы уже существенно богаче!..
UPD: в статье добавил про смысл диверсификации, а то в комментариях много вопросов было…

Сразу раскрою интригу: на заданный в заголовке вопрос я без сомнения даю второй из предложенных ответов. Было бы странно, если бы целая статья была посвящена «выбору неудачника», не так ли? На мой взгляд, «выбор неудачника» — это пиратский Adobe Photoshop с пиратским же Lightroom в качестве проявщика. Нет, я не поддерживаю идею платного программного обеспечения (ПО); наоборот, я всецело за то, чтобы урезать и ограничить аппетиты коммерческих компаний, особенно таких, которые де-факто претендуют на монополию в определённой области. Но бороться с этими эксцессами гораздо правильнее не «пиратством и воровством», а методами чисто экономическими, в первую очередь, всемерным расширением ассортимента и сферы использования разного рода бесплатного и опенсорсного ПО. Проявщик RawTherapee и фоторедактор GIMP, о которых говорится в статье далее, относятся как раз к свободно распространяемому программному обеспечению; между тем, функциональность их почти ни в чём не уступает, а местами и значительно превосходит функциональность признанного лидера. (Да, я помню про восьмибитовый цвет в GIMP. Об этом и пойдёт речь ниже!) Важно лишь использовать её должным образом.

Доброго времени суток, друзья!

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

Но сам пост не об этом. Сегодня я хотел бы поделиться с вами маленькими подсказками по поводу пользовательского интерфейса. О том, чего стоит избежать уже в самом начале разработки, и что потом делать. К сожалению, мой «скилл» недостаточно высок, чтобы писать о чем-то действительно новом и неизведанном в этой области, так что пост будет больше посвящен новичкам в гейм-деве (и в первую очередь тем, кто пока еще боится NGUI), да и пост будет субъективен на все 146%.

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

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

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

«60% лучших профессий ближайшего десятилетия ещё даже не изобретены». — Томас Фрей (Thomas Frey), футурист.

Исследовательское агентство Sparks&Honey предложило своё видение недалёкого будущего. Точнее, видение 20 профессий, которые, по мнению авторов, будут очень востребованы в ближайшее десятилетие.

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

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

На днях я наткнулся на замечательную карманную книгу для PHP разработчиков «PHP: The Right Way». Скорее, она будет более полезна новичкам. Чем именно? По интернету разбросано огромное количество материла по PHP, но многое уже устарело или не приводит к написанию качественного кода. В этой книге присутствуют основные актуальные сведения с ссылками на проверенные ресурсы. На самом деле, сначала я хотел перевести ее, форкнуть репозиторий, благо лицензия это позволяет. Но оказалось, что перевод уже есть. Нет только русской книги в форматах для электронных книг, но так как используется Markdown в русском форке, то это не составит труда.

Захотелось написать этот пост, прочитав сегодня опубликованный «Что делать если клиент — друг / хороший знакомый?». Большинство придерживается мнения, что нельзя работать с друзьями, что надо по возможности отказываться от таких предложений, что дружба в итоге охладеет, что отношения могут разорваться. А я — за клиентов-друзей и друзей-клиентов.
Я считаю, что не важно, кто перед тобой друг или совершенно не знакомый человек — подход к работе, к процессу должен быть один — профессиональный. А это значит, что менеджер проекта (речь идет о веб-разработке) должен всегда:

(Интервьюер: Марина virtualtomato, менеджер проектов в All Correct Localization)

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

Три вечера 2013 года было мной отдано инди-игре Game Dev Tycoon. Это небольшой симулятор студии, разрабатывающей игры. Я с удовольствием прошла ее, и мне захотелось сказать ребятам, которые ее сделали, спасибо. Оказалось, что это был дебют студии Greenheart Games. Дебют — это всегда очень волнительно. Поэтому я подумала, что тем, кто делает сейчас свою первую игру, история такого, пусть и небольшого, но определенно успеха, может придать уверенности и сил завершить начатое. Да и я удовлетворю свое любопытство.

Ну, вот я и написала Greenheart свои вопросы. А они взяли и согласились на них ответить. Ниже мое интервью с основателем, директором и гейм-дизайнером Greenheart Games Патриком Клюгом.

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

В этой статье речь пойдет о таком жанре игр как «поиск предметов» (также встречаются и другие названия, например «я ищу», «hidden objects» и т.д.). Или, проще говоря, о квестах, как их принято было называть несколько лет назад. Ведь слово «квест» от анг. «quest» – «поиски», следовательно, это их базовый (родной) жанр, от которого они взяли большинство характеристик. Но, видимо, плохо взяли, иначе ситуация была бы не такой плачевной. Что ж, теперь все по порядку.

1. Введение в ODR – On-Demand Routing

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

• Статическая маршрутизация – маршруты добавляются вручную администратором.
• Динамическая маршрутизация – администратор настраивает протоколы динамической маршрутизации.

Но в каждом из этих случаев есть недостатки:

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

В принципе нельзя сказать что эти недостатки существенны в современных условиях. Навряд ли сети будут переконфигурироваться часто, современные каналы связи достаточно широки, что бы без проблем передавать относительно небольшой трафик, генерируемый протоколами маршрутизации. И даже проблему внешних динамических IP адресов, получаемых от провайдера можно решить путем использования технологии динамического DNS.
Но на самом деле есть еще один недостаток, общий для обоих вариантов – вам нужен обслуживающий персонал в каждой точке, где стоит маршрутизатор. Тот, кто будет прописывать статические маршруты или настраивать протокол динамической маршрутизации.
Именно для таких случаев компания Cisco разработала проприетарный протокол ODR, который по сути даже не является протоколом динамической конфигурации, это расширение еще одного проприетарного протокола – CDP. С помощью протокола ODR маршрутизаторы могут обмениваться маршрутной информацией специфическим образом (в результате объем передаваемой информации существенно меньше, чем у других протоколов динамической маршрутизации), и при этом конфигурация всех маршрутизаторов сети не требуется. Настраивается только один маршрутизатор – основной маршрутизатор компании, все остальные маршрутизаторы не требуют вообще никакой настройки маршрутизации, ни статической, ни динамической.
Таким образом, получается, что ODR не обладает выше указанными недостатками:

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

Проблема

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

В последнее время все большую нишу на рынке E-сommerce платформ занимают так называемые хостед платформы (hosted shopping carts). Это значит, что, зарегистрировавшись на сайте того же Shopify, в несколько кликов вы сможете получить триальный стор (store), который хостится на самом Shopify. Триального периода да и лимитированного функционала, как правило, вполне достаточно для проверки возможностей карты. Кроме того, такое решение конечно же снимает головную боль, связанную с арендой собственного хостинга, установкой движка и всех необходимых карте РНР-модулей и т. д. Все уже развернуто, как говорится, плати и пользуйся.

В результате разные платформы — это разные способы достучаться к данным магазина. Если у open source карты («не хостед») можно получить доступ непосредственно к базе данных, то SaaS-решения такой возможности не дают. Альтернативными вариантами могут быть доступ через API запросы (и очень хорошо, если платформа позволяет получить все необходимые данные таким способом, потому что иногда разработчики попросту не добавляют все методы работы с той или иной сущностью) или экспорт/импорт данных с помощью файлов (CSV, XML, txt, dat, xls и другие форматы в зависимости от движка).

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

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

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

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

Поэтому рассмотрим 2 первых кейса.

Несколько лет назад, когда я знакомился с сервисом Amazon EC2 была заведена MicroInstance с Ubuntu 10.04 LTS на борту. На ней был поднят Apache и настроено несколько виртуальных хостов, включая блог на MODx Revolution. Выпала тут свободная минутка и подумалось мне, а что будет если на мой потаённый бложик вдруг набежит толпа читателей. Набегать ей в общем то неоткуда, но дух познания, привитый ещё в детстве многократными просмотрами киножурнала «Хочу всё знать», не давал покоя. Мне не доводилось пока участвовать в высоконагруженных проектах, поэтому было проведено небольшое исследование материалов в сети. Из блога в блог кочует утверждение, что необходимо отказаться от использования Apache в пользу Nginx. Это утверждение мне показалось странным, учитывая историю проекта Apache и сообщество разработчиков вокруг него. Неужели разработчики Apache не могут решить проблему ругаемого везде режима prefork? Так ли это на самом деле я и решил выяснить. О результатах читайте под катом.

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

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



Первое и самое существенное нововведение — это появление новых параметров поиска и возможность выбора нескольких пунктов одновременно.

• Тип жесткого диска (sata, sas, ssd)
• Операционные системы, которые можно установить на виртуальный сервер
• Способы оплаты, которые поддерживает хостер
• Наличие бесплатной панели управления сервером (ISPmanager, cPanel, DirectAdmin, Plesk Panel)
• Тип администрирования, который идет в комплекте в VPS
• Возможность поддержки IPv6

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