Скрипт генерирует приглашения для регистрации на сайте в виде картинки 51x51 пикселей формата PNG, написан на PHP, в качестве базы данных использует MySQL. Сделан ради интереса, будет интересен только новичкам.

Wireshark — одна из незаменимых утилит для «прослушки» сети, при работе с сетевыми протоколами. В состав программы уже входит некое количество диссекторов¹, которое помогают детально рассмотреть пакеты базовых протоколов. Но при работе над проприетарным протоколом компании Nortel я столкнулся с отсутсвием подходящего диссектора. А нужен он был как воздух. Выход был очевиден — написать свой. Что я и сделал.
Таким образом, имея небольшой опыт написания плагина «анатома» под Wireshark, я решил поделиться знаниями и опытом с сообществом. Ну и для себя записать, на случай, если в будущем понадобится.

Диссекция — лат. dissectio, от dissecare, рассекать

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

Обычно все сводится к советам не использовать Float, использовать Decimal, транзакции там всякие и прочее. И в большей части случаев этих советов вполне достаточно для того, чтобы разработчик чувствовал себя сухо и комфортно.

А сталкивались ли вы с ситуацией, когда, скажем, приложение должно обслуживать жителей более чем одной страны?

Во время недавнего обсуждения IPO Яндекса в комментариях прошла дискуссия на тему того, как торгуются акции на бирже, как проходит IPO, кто и какую от него получает пользу. По совету других участников обсуждения выношу в отдельную тему — а точнее, в серию тем — небольшой рассказ, который был рассредоточен по нескольким комментариям. Если вы тогда внимательно следили за темой, основная часть рассказа вам уже известна, но тем не менее… Если нет, вы наверняка найдете что-то интересное.

Disclaimer: эта и дальнейшие статьи серии написаны двумя хабраобитателями: honeyman — программистом стартапов, в свободное время экспериментирующим с торговлей на бирже и созданием аналитического софта для этого, в сотрудничестве с kaichik — журналистом и главредом автомобильных проектов. Если вы в предыдущем предложении не заметили слов «финансист», «лицензированные консультативные экономические услуги» и «богатый опыт» — то наверное, это потому, что их там не может быть.

• Часть I: акции, мажоритарии, контроль над компанией.
• Часть II: стоимость акций, биржа, самый лучший способ торговать картошкой, и кого же можно встретить на рынке бирже.
• Часть III: процесс IPO, его польза для компании, основателей и владельцев, а также почему у руководства компании при открытии торгов такой замученный вид.
• Часть IV: влияние IPO на доход от адулт-партнёрок.
• Часть V: жизнь после IPO.
• Часть VI: сложности выбора — два Lamborghini Gallardo или один Aventador?
• Часть VII: про инсайд.
• Часть VIII: о мотивации.

Итак, часть I: акции, мажоритарии, контроль над компанией.

Что такое акции, и для чего они нужны?

iq¹² (что примечательно, это студия, которая профессионально занимается разработкой при помощи Flash) портировали на Flash V8 Benchmark Suite — набор тестов предназначенный для определения скорости исполнения JavaScript в разных средах. Основной целью этого было сравнить скорость исполнения Flash vs JavaScript (вычислений, но не отрисовки). И, в итоге, они получили очень интересные результаты — за последние два года все популярные JavaScript-движки обогнали Flash по скорости вычислений:

В текущем проекте возникла необходимость выполнить последовательную серию ajax запросов и, по завершении — что-то сделать со всеми их результатами.
Довольно типовая задача, паттерн ее решения обычно называют waterfall (водопад). Реализации этого паттерна есть для node.js, хотя некоторые работают и в браузере — async.
Но включать целый модуль ради одного метода не хотелось. Copy/paste тоже не стал делать, но по соображениям скорее эстетическим. В async в метод передается функция обратного вызова, у нас же везде используется jQuery.Deferred. Разницы, конечно, никакой, но «ломать» стиль проекта мое «чувство прекрасного» мне не позволило :)
В результате написал небольшую утилитку по аналогии с jQuery.when

www.youtube.com/watch?v=NisCkxU544c

Посмотрев презентацию Юрия (yrashk) с Erlang Conference о веб-фреймворках в эрланге я заинтересовался и решил сделать сайтик не на node.js, как намеревался изначально, а используя какой-нибудь эрланговский фреймворк.

В итоге я наткнулся на фреймворк Chicago Boss. Про сам фреймворк я слышал и раньше, но пользоваться пока не довелось.

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

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

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

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

Крупный интернет-магазин. Десятки миллионов наименований товаров.
Задумывались ли вы когда-нибудь как происходит сборка заказа?

Пока ребята в Гугл наполняют автобус баскетбольными шарами, подумайте о том, какую площадь должен иметь склад, чтобы разместить товарный запас amazon.com или ozon.ru. Небольшой заказ из двух книг, настольной игры и набора карандашей может собрать и работник склада, затратив на этоот 10 минут до часа — ведь то, что все наименования находятся на соседних полках никем не гарантировано.
Желающие могут проанализировать математическое ожидание среднего времени сборки заказа.

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

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

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

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

Данный обзор инструментов идет в продолжение первых двух статей (см часть 1 и часть 2)

Сейчас мы разберем такие важные вопросы как:

• Присвоение региона сайту
• Формирование особых сниппетов
• Обзор самых важных слов сайта
• Анализ мета-описаний страниц сайта
• Проблемы индексации

Эти инструменты хорошо известны профессионалам, но далеко не все, кто самостоятельно занимается продвижением своего сайта, знает о них. Эта статья именно для них.

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

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

У многих из нас, бывают ситуации когда проект требует подготовки к выводу в продакшн, и зачастую эта подготовка состоит из множества действий, которые приходится выполнять много раз(например при сборке релизной версии). Зачастую задачи сводятся к выполнению простых консольных команд, очистке кеша, минификации JS и CSS или сборки их в один файл, но вся эта рутина может занять довольно продолжительное время, а так как выполняется, чаще всего, в конце рабочего дня, довольно легко опечататься и отправить несколько дней\часов\минут работы над проектом в небытие. В такой ситуации программисты стараются, как то автоматизировать сборку и подготовку проекта к рабочему состоянию, в чём им помогают различные системы сборки, об одной из которых и пойдёт речь в статье.

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

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

У нас на работе как-то был довольно жаркий спор о том, считать ли python 2.7 стабильным. Итоги спора и сам вопрос я оставляю в стороне, а тут я хочу изложить и систематизировать определённые мысли о реальных программах, которые сильно противоречат миру Фон Неймана и Тьюринга.

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

Мир же системного администрирования другой. Тут код, который «какой есть, такой есть». Невозможно даже мельком прочитать исходные тексты всех пакетов даже для самой маленькой и скромной установки. 300+ Мб линукса, исходные коды основных библиотек и программ… Оно в принципе необозримо. Можно знать конкретные программы, конкретные места программ — но невозможно знать весь runtime, всё программное окружение, из которого состоит ОС.

И оно полно ошибок. Можно сколько угодно рассуждать про прелести мат. доказательств кода, но это совершенно не поможет, если сбой обнаружится в проприентарном драйвере видеокарты (казалось бы, и при чём тут сервер?) или сетевой карты с TCP offload.

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

И вот вокруг этого «иногда» и строится вся концепция «стабильности» и product-ready.

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

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

Проблемы при разработке больших проектов

Отделение котлет данных от представления, проектирование, велосипеды… главное без фанатизма. Какая проблема часто встречается при разработке RIA приложений. Команда сильных программистов «влюбляется» в новый проект, и с мыслями «сейчас мы сделаем нечто — главное все сделать самим, чтобы ни один чужой баг не закрался» начинают отказываться от готовых фреймворков, библиотек, решений.
Правда существует одно логичное объяснение этой тенденции, боязнь завязаться на чужой продукт, бывает такое, что в ходе разработки выясняется — такой интерфейс будет очень сложно разработать на доступном инструментарии, и рождаются костыли, правки чужих фреймворков и тд. Хотел бы предложить решение этой проблемы. Создание менеджера интерфейсов (модулей). Один модуль может использовать ExtJS, другой dhtmlx, а может и вообще чистый Javascript

Привет. В этой серии постов я попробую рассказать про тестирование кода на питоне, в частности проектов django. Мы рассмотрим модульное тестирование (юнит-тесты), статический анализ кода и некоторые подводные камни тестирования веб-сайтов.

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

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

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

Поскольку и Петя и Вася ни на чем, кроме джаваскрипта, программировать не умели, свои продукты они на нем и написали.

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

Теперь начинается самое интересное.

Начинающие программисты (а вполне возможно, что и их коллеги с опытом), должно быть, часто спрашивают себя, нужно ли им учить JAVA, или знания JavaScript, Python или Ruby будет вполне достаточно в современном мире. Учитывая спрос на программистов в нынешней экономике, многие находят достойную работу еще учась в университетах, и зачем тогда, спрашивается, представителю этой профессии заглядывать в такое далекое прошлое, как COBOL?

Согласно исследованию Gartner от 2001 года (в случае с данным конкретным языком это вполне можно назвать «недавно»), 85% мирового объема бизнес-информации обрабатывалось на языке COBOL, а к текущему моменту объем кода, написанный этим языком программирования, начинает снова увеличиваться. Компания Micro Focus, занимающаяся разработкой и продажей инструментов модернизации COBOL, заявляет, что 70% мирового бизнеса до сих пор активно использует этот язык.

И хотя очевидно, что многие из приложений, изначально написанных на COBOL будут переписаны, в Micro Focus уверены, что большая часть оригинального кода все-равно останется в ходу, а приложения будут использоваться еще долгие годы. Они безопасны, стабильны, а компании использующие их, не готовы от них просто так отказаться. Программный менеджер Micro Focus по имени Арунн Рамадосс (Arunn Ramadoss) говорит: «Ни один другой язык неспособен представлять бизнес-данные так точно, как это делает COBOL».

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