Предисловие

Примерно год назад мы решили, что днем рождения нашего Энергослона будет 8-е мая. Как-то так само собой сложилось и, признаться, я не очень хорошо помню почему. То ли в этот день мы начали приглашать первых тестеров, то ли это был день, когда мы создали первую запись в блоге, то ли произошло какое-то другое событие… Не помню. Но так или иначе именно 8-го мая наш Слоник задувает свечи на именинном торте и с удовольствием принимает подарки.

И так случилось, что в преддверии Слоновьего дня рождения Мегамозг преподнес нам неожиданный и очень приятный сюрприз: возможность писать статьи в корпоративный блог. Именно этот подарок подтолкнул меня к написанию очередной статьи из цикла «Семейный бизнес в IT». А рассказать в этой статье я хочу о том, как мы собирали команду.

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

В прошлой статье я обещал, что опишу:

• запуск нескольких процессов для обработки соединений
• межпроцессное взаимодействие
• разделение процессов мастер-воркер
• проксирование вебсокетов с помощью nginx
• запуск из консоли
• интеграция с вашим фреймворком на примере yii
• демонстрация

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

Некоторое время назад я выбирал библиотеку для работы с вебсокетами. На просторах интернета я натыкался на статьи по интеграции node.js с yii, а почти все статьи о вебсокетах на хабре ограничивались инструкциями к тому, как использовать phpdaemon.

Я изучал библиотеки phpdaemon и ratchet, они достаточно монструозны (причём используя ratchet для отправки сообщения конкретному пользователю рекомендовано дополнительно использовать wamp). Мне не совсем было понятно для чего использовать таких монстров, которые требуют установку других монстров. Почитав исходники этих, а также других библиотек, я разобрался как всё устроено и мне захотелось написать простой вебсокет-сервер на php самостоятельно. Это помогло мне закрепить изученный материал и наткнуться на некоторые подводные камни, о которых я не имел представления.

Так я решил написать необходимый для меня функционал с нуля.

Получившийся код и ссылка на демонстрационный чат в конце статьи.

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

В AngularJS реализована поддержка JSON Vulnerability Protection, направленная на то, чтобы противодействовать ситуациям, когда злоумышленник может, при определённых условиях, превратить JSON в JSONP и выполнить какой-то код. В качестве меры противодействия на серверной стороне предлагается добавлять к JSON-данным такой префикс: )]}',

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

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

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

Итак, поехали.

Это история о том, как я бросил все и начал делать игры.

Шаг нулевой — решение

Почти десять лет я занимался электронным документооборотом. Наверное, если бы мне кто-нибудь десять лет назад сказал, что я в этом настолько серьезно увязну — не поверил бы. Тем не менее, хоть предметная область и не менялась, довольно долгое время мне все это было интересно. Интересно было создавать службу поддержки вместо повинности программистов дежурить по очереди, интересно было создавать всероссийское (ух, слово-то какое пафосное) сообщество разработчиков, интересно было встречаться с сотнями неглупых людей из десятков ведущих российских компаний, от производителей бургеров до строителей АЭС. Постоянно искать хитрые решения нестандартных запросов. На этом месте часто пишут «и вот в один прекрасный день я понял...», но, на самом деле, такого дня не было.

В продолжении части 1, мы решили написать статью, как вышли на «новый уровень» по созданию веб-продукта. Хочу сразу уточнить, что это не совсем хелпдеск, который основан на создании заявок клиентами (хоть такая возможность и присутствует), а больше рассчитан на внутреннюю работу организации или IT-департамента. Так же хочу напомнить, что система создавалась конкретно под наши требования, поэтому она не лучше других, но и не хуже. Она просто «другая», у которой есть свои функции под конкретные задачи и возможно займёт достойное место в общем мире продуктов, делающих IT-мир лучше.

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

Для нашего проекта, как учетной системы, характерно производить изменения в других объектах после сохранения текущего, например, проведение документа по регистрам после сохранения. Суть в том, что после сохранения объекта в транзакции ActiveRecord будет считать, что все изменения прошли успешно, хотя это не гарантировано, ведь последующие изменения могут вызвать Exception, а он в свою очередь к откату транзакции. В нашем случае, это грозит тем, что при ошибочном создании записи, экземпляр ActiveRecord уже будет иметь статус существующей записи (флаг isNewRecord == false) или для новой записи уже будет присвоен primaryKey. Если вы при рендере опирались на эти атрибуты (как мы в нашем проекте), то в результате получите ошибочное представление.

От переводчика:
Продолжаем восполнять недостаток информации на русском языке об интереснейшем диалекте Lisp. Предыдущая статья: Разработка веб-приложений в PicoLisp
Домашняя страничка проекта: http://picolisp.com

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

Как правило, в PicoLisp база данных содержит объекты различных классов. Для их обработки в GUI должна быть возможность для поиска, создания и удаления объектов, редактирования их свойств.

Команда PHP фреймворка рада сообщить о выходе версии 2.0.2. Инструкции по установке и обновлению можно найти по адресу http://www.yiiframework.com/download/.

Версия 2.0.2 является патч-релизом Yii 2.0 и содержит около 40 небольших улучшений и исправлений. Полный список изменений можно найти на GitHub. Спасибо всем, кто нам помогал подготовить этот релиз.

Если хотите следить за процессом разработки Yii 2 можно поставить звёздочку или использовать кнопку watch на странице проекта на GitHub. Также у нас есть Twitter и Facebook.

Рассмотрим наиболее значительные дополнения данного релиза.

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

1 Один столбец вместо нескольких

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

Вышел релиз 1.1.16 PHP-фреймворка Yii. Вы можете скачать его по адресу yiiframework.com/download/.

В данный релиз вошло более 120 улучшений и исправлений. Полный список изменений можно посмотреть здесь. Внимание: не все изменения совместимы с предыдущей версией. Внимательно прочитайте инструкции по обновлению.

Спасибо всем, кто нам помогал и без кого этот релиз бы не состоялся.

Отметим, что Yii 1.1 перешёл в режим поддержки, то есть не стоит ждать каких-либо новых возможностей или больших изменений в будущем. В данный момент мы активно разрабатываем и поддерживаем Yii 2.0, в котором используются свежие технологии. Следить за развитием Yii 2 можно поставив звёздочку или нажав на кнопку «watch» на странице проекта на GitHub. Присоединяйтесь к нашим Twitter и Facebook.

Далее мы расскажем о главных улучшениях.

Один французский «исследователь безопасности» этим летом опубликовал невиданно много найденных им уязвимостей типа arbitrary file upload в разных «написанных на коленке», но популярных CMS и плагинах к ним. Удивительно, как беспечны бывают создатели и администраторы небольших форумов, блогов и интернет-магазинчиков. Как правило, в каталоге, куда загружаются аватары, резюме, смайлики и прочие ресурсы, которые пользователь может загружать на сайт — разрешено выполнение кода PHP; а значит, загрузка PHP-скрипта под видом картинки позволит злоумышленнику выполнять на сервере произвольный код.

Выполнение кода с правами apache — это, конечно, не полный контроль над сервером, но не стоит недооценивать открывающиеся злоумышленнику возможности: он получает полный доступ ко всем скриптам и конфигурационным файлам сайта и через них — к используемым БД; он может рассылать от вашего имени спам, захостить у вас какой-нибудь незаконный контент, тем подставив вас под абузы; может, найдя параметры привязки к платёжной системе, отрефандить все заказы и оставить вас без дохода за весь последний месяц. Обидно, правда?

Онлайн-образование становится все более распространенным явлением — в Интернете можно найти возможность пройти онлайн-курс по практически любой специальности. Ранее мы писали о том, как создать онлайн-курсы, которые будут пользоваться популярностью, с помощью плагина WordPress CoursePress. Сейчас нам бы хотелось продолжить тему онлайн-образования, опубликовав перевод статьи Marya Jan о том, как создать свой первый электронный курс и сделать его продаваемым. Пусть мы не всегда согласны с ее подходом, однако, он показался нам достаточно интересным и полезным.

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

Надеемся, наша публикация покажется вам интересной!

Давно не секрет, что в русском сегменте IT порядка 80% всех разработчиков, стартаперов и просто людей, делающих бизнес в данной сфере, ведут его с помощью нерезидентных структур. Т.е. компаний, зарегистрированных за рубежом (оффшорных), т.к. почти все контрагенты у них тоже зарубежные.

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

То есть существует возможность аккумулировать прибыль в зарубежной компании, накапливать её там и использовать для инвестиций или других целей. До тех пор, пока накопленная на уровне компании прибыль не распределена обратно в Россию (в пользу российских бенефициаров), налог на прибыль и НДФЛ не возникает.

Таким образом достигается эффект отложенного налогообложения.

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

Итак, в крупном производственном холдинге есть много компаний, объединённых в одну группу. В 2011 и 2012 году они показывали высокую прибыль, при которой можно забыть об оптимизации и просто фигачить как можно быстрее дальше, пока получается. «Что тут думать, трясти надо» — оптимальная бизнес-стратегия на таких нормах прибыли. В 2013-м году из-за общей экономической ситуации стало понятно, что прибыль будет снижаться. Соответственно, первое, что начало делать большое руководство — это разбираться, куда и как конкретно тратятся деньги, чтобы найти то, что можно безболезненно оптимизировать или просто убрать.

ITIL[1] — библиотека книг в которых подробно и всесторонне описываются различные «хорошие» практики управления ИТ-услугами (IT Service Management). У книг ITIL разные авторы, описанные в них процессы и рекомендации никто между собой не согласовывал, так что любимый тезис специалистов по ITIL — ITIL нельзя внедрить, только адаптировать. Логическим выводом из этого будет то, что ITSM-решение нельзя получить из коробки.

Прежде, чем запустить Service Desk и завести первые тикеты, вам придется сначала получить сертификат по ITIL, пройти обучение по выбранному ITSM-продукту, пригласить консультантов, потратить несколько месяцев и несколько миллионов рублей на проект. Есть, конечно, бесплатные решения, которые можно настроить самому, но голову в процессе настройки придется поломать изрядно. Не лучший подход, особенно для небольшой ИТ-службы с ограниченным бюджетом и ресурсами.

Исходный тезис про необходимость адаптации сам по себе правильный. Конечно, потребуется несколько лет, чтобы обнаружить и автоматизировать несколько десятков процессов, описанных в ITIL. Однако если компания вообще не сталкивалась с ITIL и ITSM, то ни большей части этих процессов, ни какой-либо потребности в них у нее просто еще нет.

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

Это первая наша статья на Хабре (и, надеюсь, не последняя) и хочется максимально честно и открыто рассказать про наш опыт запуска бизнеса в Питере по разработке мобильных приложений «с нуля», какие ошибки мы совершали, какие продолжаем совершать (ну куда же без этого) и про то, как мы пытаемся построить что-то действительно масштабное и «изменить этот мир» — а именно наш проект мобильного товарного агрегатора tapki (название смешное конечно, родилось как производное от английского слова «tap»). Оглядываясь на статью, после ее написания, вижу, что получилось не мало текста (около 18-ти страниц в word’е), но надеюсь, что сказанное будет полезно. Коллеги советовали разбить документ на части, но как мне кажется, цельное повествование, затрагивающее период чуть больше года, позволит дать более полную картину развития компании. В статье читатель найдет экономику (управленческий баланс), который «тянется» с самого начала, с разбивкой по статьям затрат. Мы ничего не добавляли-убавляли и все цифры приводим «как есть».

Я расскажу про запуск бизнеса с самого начала: поиск помещений, поиск инвестиций, про основную (изначальную) идею бизнеса и как она менялась в течении года, про удачи и неудачи. Поскольку мы зарегистрировали юр.лицо в июне 2013 года (а точнее 29 мая), нам, можно считать, исполняется 1 год «с хвостиком» и какие-то нюансы уже не вспомнить, но основные вехи с фотографиями — сохранились. Важно — если где-то в тексте я делаю для себя (и читателей) вывод или даю совет (прямо или косвенно) — прошу расценивать его исключительно как мое личное мнение, которое с вероятностью 50% может быть в корне не верным. И еще — некоторые моменты я не могу вспомнить в деталях, поэтому могут встречаться небольшие неточности в части объяснения тех или иных цифр — это не попытка утаить информацию, а просто элементарная забывчивость, т.к. дневник я не вел (к сожалению — исправляюсь) и пишу по памяти.

Какие языки лучше выбрать для локализации своего продукта? Этот вопрос часто ставит разработчиков в тупик. А от правильного ответа на него могут зависеть самые важные показатели – величина прибыли, количество скачиваний или посетителей. Что ж, спешим поделиться с вами любопытной статистикой на эту тему.