Всем привет.
Мы наконец-то завершили разработку нашего нового проекта — AnyChart Stock.

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

Runtime компонента написан на Flash. Конфигурация задается через XML или JSON (кому что больше нравится ;-), данные — в формате csv.

Разработка заняла чуть больше полутора лет, но оно того стоило.



Под катом примеры, некоторые фичи, ну и, конечно, хабраскидка!

В рамках проекта для одного из наших заказчиков в очередной раз встала задача построить систему конвертации/ хранения/ доставки видео в интернет. Типичная такая задача создания своего маленького (или не очень маленького) “Тьюба” только с профессиональным, а не UGC-контентом.

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

Наиболее интересными трендами последнего времени, на наш взгляд, являются:

• возможность смотреть один видео-сайт с разных устройств,
• технология адаптивного HTTP стриминга

Эта история началась много-много ревизий назад – тогда SVN Репозиторий был девственно чист, и ни один баг еще не осквернил его своим присутствием. Первые коммиты, первые откаты, просмотры лога – все это было так захватывающе, так ново. И разве мог Репозиторий тогда предполагать, что эти первые, такие приятные шаги впоследствии приведут его на хирургический стол?

Репозиторий рос, креп, матерел. Со временем привык к коммитам, появились первые тэги, и даже мечты о ветках перестали казаться несбыточными. Репозиторий познакомился с другими SVN репозиториями, а с некоторыми даже стал обмениваться файлами. Порой он подолгу выкачивал изменения у своих новых друзей, по ходу процесса наслаждаясь анализом диффов.

Hg Init: Учебное пособие по Mercurial.

Mercurial — это современная распределенная система контроля версий с открытым кодом. Эта система — заманчивая замена для более ранних систем вроде Subversion. В этом простом учебном пособии в шести частях Джоэль Спольски (Joel Spolsky) рассказывает о ключевых принципах Mercurial.

Если вы использовали Subversion, то Mercurial будет непонятным. Эта часть рассказывает о главных отличиях при работе с Mercurial. Если вы никогда не использовали Subversion, то можете просто пропустить эту часть.

Часть 1. Переобучение для пользователей Subversion

В каком же я был смятении, когда программисты в моей компании решили сменить Subversion на Mercurial!

Для начала, я начал приводить всевозможные тупые причины, по которым нам не надо ничего менять. «Мы должны хранить репозиторий на центральном сервере, так безопаснее», — сказал я. Знаете что? Я был неправ. При работе с Mercurial у каждого разработчика на жестком диске хранится полная копия репозитория. Это, на самом деле, безопаснее. В любом случае, почти в каждой команде, использующей Mercurial, центральный репозиторий тоже существует. И вы можете делать резервное копирование этого репозитория со всей необходимой одержимостью. А еще можете устроить трехступенчатую защиту с Сайлонами, Штурмовиками и прелестными лабрадудлами или что там требует ваш IT-отдел.

Я оказываю услуги по настройке web- и БД-серверов. На днях ко мне обратился Иван Усачёв — владелец портала ochevidets.ru с просьбой избавить сайт от торможения.

Страницы в пиковое время стали долго загружаться, вплоть до 5 минут на страницу.

UPDATE: Статья была написана в 2010 году. Кое-что изменилось: вышли новые версии программ, у nginx изменились некоторые директивы и появились новые. Учитывайте это.

Чтобы было понятно о чем речь, прикладываю 3 скринкаста, второй и третий под катом.

1. Знакомство с макетом #1
   

Данная статья давно назревала в моей голове, но совсем в ином формате.
Прочитав последние несколько неуклюжих статей на тему WEB-сервисов (например: http://habrahabr.ru/blogs/development/108973/) и применения в них REST технологии, решил что настало время все-таки откинуть лень, выделить время и написать «переформатированную» в своей голове статью.
Итак, кратко, что Вы найдете в статье и кому она будет полезна:

— новичкам, которые интересуются или планируют написать WEB-сервис для проекта
— профи вряд ли найдут что-то новое для себя
— общая идеология REST
— применение CRUD в WEB-сервисах
— принципы KISS при построении раутеров
— лучшие практики
— немного пиара ;)
— ссылки, литература

Интересная уязвимость для повышения локальных привилегий до уровня системы, появилась 24 ноября в виде статьи на ресурсе The Code Project (http://www.codeproject.com/KB/vista-security/uac.aspx). Буквально через несколько часов она была удалена с этого ресурса, но информация уже распространилась по сети и на мой взгляд удалять ее было бессмысленно. Повысить привилегии можно на системах начиная от XP и до Vista/Win7, причем серверные версии тоже находятся под ударом. А что еще более интересно уязвимость актуальна, как на х86 системах, так и на х64. Правда представленный PoC код удалось успешно запустить только на х86 системах.

Допустим, фирму вы уже создали, отдавать инвесторам 75% долю не хотите, а денег где-то взять надо. Помощь приходит совершенно из неожиданного места – Государства. Речь идет о 350 000 рублей, которые вам (внимание!) подарят! Но заплатить придется некоторой бюрократической возней и потерей времени. Речь будет идти о малых предприятиях, зарегестрированных в городе Москве, так как пишу по собственному опыту.



По программе содействия развитию малого бизнеса г.Москвы (в других регионах есть аналоги) любой субъект малого предпринимательства имеет возможность получить до 350 000 рублей на следующих условиях:

• Необходимо вложить не менее 50% собственных средств;
• Нужно иметь помещение и договор аренды;
• Необходимо потратить более 50% предоставляемой субсидии на покупку основных средств;
• Возмещение арендной платы из бюджета — не более 3 600 руб. за кв.м. в год;
• На расходные материалы можно потратить не более 20% субсидии.

Условия устраивают? Тогда действуем! 

Javascript — очень изящный язык с кучей интересных возможностей. Большинство из этих возможностей скрыты одним неприятным фактором — Internet Explorer'ом и другим дерьмом, с которым нам приходится работать. Тем не менее, с приходом мобильных телефонов с актуальными браузерами и серверного JavaScript с нормальными движками эти возможности уже можно и нужно использовать прям сейчас. Но по привычке, даже при программировании для node.js мы стараемся писать так, чтобы оно работало в IE6+.

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

function Foo(bar){
    this._bar = bar;
}

Foo.prototype = {
    get bar () {
        return this._bar;
    },
    set bar (bar) {
        this._bar = bar;
    }
};

Node.js — вещь, вокруг которой сейчас много шума, восторженных отзывов и гневливых выкриков. При этом, по моим наблюдениям, в умах людей закрепилось следующее представление о том что же такое Node.js: «это штука, позволяющая писать на JavaScript на серверной стороне и использующая JavaScript-движок от Google Chrome». Поклонники языка восторженно вздохнули: «Ах! Сбылось!», противники же процедили сквозь зубы: «Ну вот только еще этой ерунды с прототипами и динамической типизацией нам на серверах не хватало!». И дружно побежали ломать копья в блоги и форумы.

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

Если Вы собираетесь прикручивать на сайте поддержку оплаты через PayPal, а точнее Website Payments Pro (WPP), а точнее Direct Recurring Payments, то скорее всего вы уже ознакомились с документацией от самого сервиса: Integrating Recurring Payments.

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

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

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

История разработки уходит в один проект торгово-рекламной площадки, где необходимо было учитывать кол-во переходов. Было решение на РНР. Но это давало видимую задержку в 0.5-1 сек, что очень раздражало разработчиков (в частности меня) и я думаю пользователей тоже.

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

Как-то вечером для реализации моделей поведения в ORM в моем велосипеде фреймворке мне понадобилось что-то, ведущее себя как примесь (mixin) в Ruby или как метод расширения (extension method) в C# (или как трейт / графт в будущих версиях PHP) Я решил для интереса посмотреть, как у меня получится реализовать примеси на PHP. Если вы не знаете, что такое примесь, не беда, сейчас все расскажу.

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

Дисклаймер: описываю только свой личный опыт и мнения автора могут не совпадать с мнением автора. Статья огромная, читать много.

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

Эта статья адресована тем, кто уже «на грани». Она почти лишена философии и туманных ссылок, просто тупо туду-лист. Бери и делай. Намеренно избавляю тебя от объяснений, зачем молодому проекту нужна госрегистрация, такая ли уж это свобода – быть собственником и от куда взять деньги на госпошлину. Статья адресована московским стартаперам, гео-патчи от других городов приветствуются в комментариях.
Будем считать, что с формой собственности определились — это ООО и упрощенка 6%. Если кому нужно ИП – там проще, справишься и без этой статьи.

Для создания фирмы необходимо:

С самого своего выхода третья версия этого замечательного фреймворка начала активно вытеснять вторую. Это, конечно, прекрасно, но изменений между версиями довольно много, некоторые имеют статус deprecated. А это значит, что одних только знаний второй версии для полноценного использования Rails будет недостаточно.
Именно так я рассуждал, когда начал искать литературу по третьим рельсам. Почему именно литературу, а не документацию? Потому что только осенью я обратил внимание на этот фреймворк, а учиться лучше всё же по книгам (я так считаю). И какова же была моя радость, когда я наткнулся на сайт книги Beginning Rails 3, которая вышла в свет только в сентябре.

Много слов сказано о том, как правильно писать юнит-тесты, и вообще о пользе TDD. Потом ещё и какое-то BDD замаячило на горизонте. Приходится разбираться, что из них лучше и между ними какая разница. Может, это и есть причина, почему большинство разработчиков решили не заморачиваться и до сих пор не используют ни того, ни другого?

Коротко: BDD — это дальнейшее развитие идей TDD, стало быть, его и надо использовать. А разницу между TDD и BDD я попробую объяснить на простом примере.

Рассмотрим 3 ревизии одного юнит-теста, который я нашёл в одном реальном проекте.

Попытка номер №1

Первая версия этого юнит-теста была такой:

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

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

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

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

Топик навеян впечатлениями от докладов на swpiter и постом о том, как не продать машину :)

Как работать над стартапом и всегда оставаться в выигрыше?

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

Картинка слева кликабельна, а ниже — текстовое описание в 12 шагах как инициировать стартап и при этом всегда оставаться в выигрыше.

1. Идея!

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

Самое важное в идее — это не терять мотивацию вплоть до 10 шага и тогда вы в любом случае получите для себя выгоду.

2. Детализация идеи

Необходимо хотя бы примерно ответить на эти вопросы:

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

На этом этапе ещё рано отвечать на вопросы:

• сколько времени вы можете уделить (если идея вас реально интересует, вы перейдёте к следующим этапам)
• сколько на это нужно денег
• кто вам ещё нужен для реализации идеи