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

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

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

Целью данной заметки я ставлю в подробностях описать организацию сервера для Rails приложений в самой популярной на данный момент связке: rvm + Rails + Nginx + Unicorn. К написанию статьи побудило отсутствие полной пошаговой документации по этой связке, понятной не только ядреным профессионалам этой области. Далее я попытаюсь подробно, шаг за шагом, описать идеологически правильный процесс организации сервера для обслуживания нескольких Rails приложений (на примере одного) — если у вас есть абсолютная уверенность в том, что на подопытной машине никогда не будет работать более одного приложения — настройка может быть существенно короче и проще. Хочу предупредить, что тонкости, касающиеся работы приложения под высокой нагрузкой в статье не описываются, т.к. цель ставилась иная — заставить работать приложение в связке и сократить количество конфликтов с другими приложениями до минимума.

Проблемы контроля версий баз данных и миграций между версиями уже не раз поднимались как на Хабре (1, 2, 3 и др.), так и в Интернете (преимущественно, англоязычном).

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

Наша команда долгое время использовала известную практику rvm gemset per project. Однако, после работы с пакетным менеджером nodejs мы поняли, что гораздо удобнее складывать зависимости в папку проекта (дефолт для нодовского пакетного менеджера).

Немного покопавшись в документации бандлера я обнаружил, что тоже самое можно сделать и на его основе.

RVM — Ruby Version Manager
Программа для управления версиями Ruby.

Как быть если один проект использует Ruby 1.8.7, а другой 1.9.2? А что если при этом у вас 2 проекта под версией 1.9.2, но с разными наборами гемов? Хотелось бы вам иметь отдельные наборы gem's для каждого проекта?

Основные задачи:
1. Физическое разделение версий ruby и наборов гемсетов
2. Возможность иметь несколько версий ruby и переключаться между ними
3. Возможность для каждой версии ruby иметь несколько gemsets — наборов gem's и переключаться между ними

Под катом будут описаны:
1. Установка RVM
2. Работа с разными версиями Ruby
3. Работа с gemsets
4. Задание окружения под отдельный проект с помощью .rvmrc
5. Команды RVM которые могут оказаться полезными
6. Шпаргалка по основным командам RVM

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

Извините фальстарт, это не я, это андроидный смартбук.

Когда мы только запускали облако, первой проблемой было «как нам получить консоль». Штатный механизм XCP поразумевает, что консоль рисуется с помощью VNCTerm, а желающий её увидеть должен сначала пойти в XenAPI, получить там session-id консоли, пойти на порт консоли, передать session-id, получить RFB, завёрнутый в HTTP, развернуть HTTP, вынуть RFB (он же VNC), отдать её локальному рендереру VNC (VNC-клиенту или java-апплету с тем же функционалом). При этом консоль закрывалась (сессия рвалась) при каждой перезагрузке виртуальной машины. Она рвалась даже при миграции виртуальной машины. Другими словами, это была технология, которая подразумевала «глянул одним глазком, починил ssh/iptables и забыл». Неудобно, медленно, сложно. Выкатывать такое в продакт совсем не хотелось.

И я залез в дебри serial-howto, console-howto и ещё несколько ужасных документов, рассказывающих о том, как правильно нужно конфигуриовать прерывания на ISA плате у мультикарт, а так же специфику настройки linux-2.2 для работы с оными. Параллельно изучалось устройство консоли в зене (внимательный читатель мог даже заметить, когда именно я более-менее разобрался в этом вопросе — я писал на хабре краткий обзор того, что происходит с консолью).

После этого пришла мысль: нужно писать своё, потому что готового чужого хорошего нет.

Сначала мы хотели взять хотя бы готовые компоненты и сделать из них своё. Я помню до сих пор ту замечательную схему, в которой мы планировали сохранять в БД вывод anyterm'а, делать двойное туннелирование последовательного порта с использованием UDP… Выглядело это, мягко скажем, неприглядно.

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

Через некоторое время мы пришли к идее «нам нужен свой эмулятор терминала».
Задача казалась относительно простой, пока мы не прикоснулись к бездне, именуемой «escape-коды и типы терминалов...».

Пишущие машинки

Итак, в начале была пишущая машинка. В какой-то момент возникло желание совместить телеграф с пишущей машинкой. Так возник телетайп
Разумеется, инженерам, создававшим телетайп, не было никакого резона делать все с нуля. Они просто приделали коды к каждой клавише пишущей машинки. После некоторых боёв в стиле MS VS Netscape, был создан стандарт html5 на коды для оных машинок, то бишь телетайпов. Если мне память не изменяет, то это ASCII, где предусмотрены все комбинации клавиш, характерные для американской пишущей машинки. Включая код BELL, который, кстати, должен вовсе не делать BEEP, а делать «дзыньк», ибо у пишущих машинок был именно колокольчик, а не спикер.

Не обманывайтесь — каждый хочет продать свой стартап. Мы все восхищаемся тем, как Groupon и другие компании превращаются в миллиардных гигантов, хотя, в общем-то, это ложь самим себе. Даже Ларри Пейдж и Сергей Брин хотели продать Google за $1 миллион Yahoo в течение 10 секунд после начала работы, однако последняя ответила отказом.

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

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

1. Готовьтесь за год вперед. Основательно готовьтесь ко встрече с каждым, кому вы хотите продать свой бизнес. Начинайте разговаривать с ними уже сейчас. Первая компания которую я продал (в 1998) начала вести переговоры со всеми рекламными агентствами за год до фактической продажи. Я не был готов (всмысле, я бы продал ее сразу, но она была слишком мала), поэтому я держал каждого потенциального покупателя в курсе ежемесячными рассылками. И завтраками или обедами каждые три месяца, просто для того чтобы рассказывать новости о бизнесе, в общем. К тому моменту, когда я был окончательно готов продать компанию, мы получили 4 или 5 срочных предложений. Наконец, мы продали ее компании, с которой я даже не контактировал ранее, но она слышала о нас потому что все остальные обсуждали это.

Давайте подумаем, кому нужны гуманные методологии разработки? Команда, ответственность, храбрость, доверие…

Инвестор

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

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

Менеджер проекта

Ему нужно, чтобы проект:

а) Был довольно точно описан, согласован с Заказчиком и требования не менялись. Тогда его несложно оценить, распланировать этапы работ и водопадно выполнить.

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

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

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

Скучно!

Где же креатиффность? Неужели не хочется не просто раскрыть свою тему, а сделать это так, чтоб даже тем, кому не интересна тема, будут заинтересованны подачей материала? Блин, мы ж веб-девелоперы, так почему же мы создаем презентации в левых программах, а не там, где мы лучше всех?

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

Но что делать, если хочется чего-то большего? Если надоело писать однотипные классы для онлайн-казино, ковыряться в Joomla/Drupal/PHPBB очередного заказчика?

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

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

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

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

Недавно Центр речевых технологий — компания, одна из немногих имеющая собственные системы синтеза и распознавания речи, — начала озвучивание на русский язык материалов конференции TED, используя технологию синтеза русской речи. Озвученные роботом материалы размещаются в блоге «Фабрика речи» (VoiceFabric).

На вопрос, как сделать AJAX запрос к другому домену, я всегда отвечал, что никак, и предлагал в качестве альтернативы jsonp, прокси, флеш, фреймы. Но, оказывается, большинство современных браузеров (IE8+, FF3.5+, Chrome 6+ и Safari 4+) вполне поддерживает кроссдоменный XMLHTTPRequest.

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

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



(Осторожно, много изображений!)

Внимание

Статья содержит информацию об устаревшей версии PHP Console.

О новой версии PHP Console 3.0 читайте тут.

PHP Console 1.0

Речь пойдёт об одном чудном расширении для Google Chrome, которое позволяет проксировать вывод ошибок и дебаг сообщений из PHP в консоль Google Chrome, а также отображать их в виде всплывающих popup-уведомлений.

Сегодня я хотел бы рассказать Вам о замечательном дополнении для Gimp'а под названием Gimpbox.

Многим уже порядком поднадоел многооконный режим Gimp'a и пока все в ожидании стабильного релиза 2.8 где разработчики обещали сделать возможность выбора между многооконным и однооконным режимом, китайские разработчики подумали как можно решить эту проблему малой кровью и сделали дополнение Gimpbox, смысл которого заключается в том что бы объединить все окна Gimp'а в одно окно как это сделано например в Adobe Photoshop, Paint.net и других редакторах.

Gimpbox является frontendом для Gimp'а, т.е. он будет работать только с уже установленным Gimp'ом.

Под катом инструкция по установки.

Разрешите немного с вами познакомиться. Зовут меня Алексей, представляю я на Хабре компанию ООО «Сэнюэл» (Sanuel). И в данном посте я бы хотел немного рассказать о том, чем мы занимаемся, и о чем я буду писать на Хабре. Заранее прошу прощения, если топик получится рекламным (не представляю, как можно рассказать о себе, своих продуктах, избежав рекламы).

С 2004-го года мы разрабатываем программные продукты (только для стран СНГ) для управления личными финансами. Уверен, тема эта интересна большому кругу людей (а если Вас это не интересует – обязательно прочтите следующий мой пост, где я постараюсь объяснить, почему так важно заниматься контролем своих финансов, что это реально дает). Постараюсь писать здесь только интересные и полезные заметки.

Чуть ниже Вы узнаете о линейке наших программ под названием Family. Данный продукт достаточно известен на рынке СНГ, и если Вы о нем еще не слышали, уверен, Вам он должен понравиться. Постараюсь писать кратко и по делу!

Заметка навеяна постом Помогите, а то я скоро сойду с ума (реальная история, реальной разработки проекта), затем была опубликована как комментарий, а теперь, по просьбам, и как топик.

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

И так, как же разработать стартап лучше?

Пошаговый план эффективного запуска первой версии:

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