Я, как и многие программисты, после знаменитого выступления Линуса Торвальдса о Git на Google Talks заинтересовался распределенными системами управления версиями, а в особенно Git.

Я довольно таки свободно читаю на английском, но мне приятнее читать на русском языке, при условии нормального перевода.
Существует замечательная книга «Git Magic» Бена Лина (Ben Lynn).
Благодаря труду многих людей вышел первый черновой вариант этой книги. Всех желающих улучшить перевод — приглашаю под кат.

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

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

Я уже писал про обучение детей программированию на основе Лого. Однако возможен и другой, ещё более “симпатичный” подход – это визуальное программирование, в котором вообще не надо писать текст. Причём визуальное – это не обязательно рисование блок-схем! Например, можно исходить из понятия объекта, который находится в разных состояниях и реагирует на внешние события.

В Майкрософт также задумываются над проблемами обучения детей, в частности, уже писалось про проект Kodu Game Lab. Kodu – это интерактивная среда создания трехмерных игр, доступная одновременно на Xbox 360 и на ПК. Я решил написать о ней подробнее, поскольку начиная с сегодняшнего для любой желающий может скачать и попробовать версию для ПК.

Хотел бы начать знакомить всех с фреймворком ExtJS. Оказывается, все не так сложно как может показаться…

1. [ExtJS] :: Часть 1. Вводная. Модель DOM и типы данных в ExtJS
2. [ExtJS] :: Часть 2. Основы пользовательского интерфейса в ExtJS
3. [ExtJS] :: Часть 3. Загрузка, проверка и обработка форм в ExtJS
4. [ExtJS] :: Часть 4. Работа с выпадающими списками и календарем
5. [ExtJS] :: Часть 5. Отображение и редактирование табличных дан
6. [ExtJS] :: Часть 6. Обзор таблиц и списков
7. [ExtJS] :: Часть 7. Вкладки и деревья

Ссылка на ресурс тут

Пока все.

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

PS. С НАСТУПАЮЩИМ!!!

О визуализация графов в вебе говорили здесь, навеяно этой статьей.

Под катом обзор JavaScript библиотек для рисования графов, диаграмм и прочей красоты.

Однажды я зашел на rememberthemilk.com и понял, что хочу такое же контекстное autocomplete меню в свой проект. В результате получился небольшой jquery плагин, который хочу презентовать в этом посте. Работает в ie6+, opera, safari, firefox, chrome (тестировал в последних версиях). В кратце расскажу в чем суть «контекстного» меню в RTM-стиле.

Это меню присоединяется к input-элементу, но, в отличие от обычных autocomplete меню, оно «всплывает» не для ввода всего значения элемента, а для какой-то логической части поля ввода. При этом меню позиционируется непосредственно под автодополняемым текстом. Вот как это выглядит:



Лицензия проекта — MIT / beerware.
Скачать библиотеку с примерами можно тут: js-context-autocomplete.googlecode.com/files/js-autocomplete-v5.tar
Последнюю ревизию забираем тут: svn checkout js-context-autocomplete.googlecode.com/svn/trunk js-context-autocomplete-read-only
Кому интересно поучаствовать в проекте — пишите в личку.
Временное online-demo (upd)

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

Большинство web-сервисов экспортируют данные в разных форматах для дальнейшего использования. Данная статья о том, как экспортировать данные в pdf-формате.
Хотя многие знают как это делать, я опишу кратко для тех кто не знает.

Dklab Realplexor — это Comet-сервер, позволяющий держать одновремено сотни тысяч долгоживущих открытых HTTP-соединений с браузерами пользователей. JavaScript-код, запущенный в браузере, подписывается на один или несколько каналов Realplexor-а и вешает обработчик на поступление данных. Сервер может в любой момент записать сообщение в один из таких каналов, и оно будет моментально передано всем подписчикам (хоть одному, хоть тысяче), в режиме реального времени и с минимальной нагрузкой для сервера.

^{Хотя идейным вдохновителем Realplexor-а был предыдущий проект, dklab_multiplexor, код Realplexor-а не имеет с ним практически ничего общего. Поэтому я и решил сменить название. Несопоставимы также возможности продуктов (см. ниже), да и размер кода увеличился в 7 раз.}

Realtime-направление сейчас довольно активно развивается на Западе, и в нем особенно выделяется продукт Tornado — событийно-ориентированный веб-сервер на языке Python. Правда, Tornado — это не столько Comet-сервер, сколько инструмент, с помощью которого можно запрограммировать «в том числе» и Comet-сервер. Ключевые слова: Comet, Push Server, Long polling, JavaScript, XMLHttpRequest.

Главные преимущества Realplexor-а:

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

Лучше один раз увидеть...

Я сделал отдельную онлайн-песочницу, чтобы продемонстрировать функционал нового Realplexor-а и то, для чего вообще нужны Comet-серверы (кстати, это физически тот же самый демон Realplexor-а, что использует мой новый стартап РуТвит). Песочница реализует что-то типа многоканального чата: зайдя, вы получите как будто бы 2 независимых «браузера», запущенных на разных компьютерах.

• Верхний «браузер» отображает каналы — в них моментально появляются новые сообщения, как только кто-то их туда отправляет на стороне сервера. Конечно же, эту страницу могут просматривать одновременно сотни тысяч пользователей, и они все будут видеть одно и то же (реализовано с использованием Realplexor JavaScript API). Можно «на лету» добавлять новые каналы (подписка) или скрывать уже имеющиеся (отписка).
• Нижний браузер содержит формы, позволяющие добавлять сообщение в произвольный канал, указав его имя. Форма AJAX-ом отправляется на сервер, и уже там PHP-скрипт записывает в Realplexor полученный текст через PHP API. (И да, так можно чатиться.)

По умолчанию на странице открыто 3 канала с именами Alpha, Beta и RuTvit. Но, конечно, вы можете закрыть эти каналы и открыть новые. Вот, например, страница с единственным открытым каналом по имени Habrahabr: http://rutvit.ru/realplexor/demo?ids=Habrahabr.



Песочница демонстрирует следующие функции Realplexor-а:

Рад сообщить, что обновлённый jQuery Wysiwyg 0.6 вышел в свет.

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

Для организации трансляции нам потребуется:

• Linux
• FFmpeg (включает в себя ffserver)

Теория

FFmpeg — это набор свободных библиотек с открытым исходным кодом, которые позволяют записывать, конвертировать и передавать цифровое аудио и видео в различных форматах. Он включает libavcodec, библиотеку кодирования и декодирования аудио и видео и libavformat, библиотеку мультиплексирования и демультиплексирования в медиаконтейнер. Название происходит от названия экспертной группы MPEG и «FF», означающего «fast forward».

© Wikipedia

ffserver идёт в комплекте с ffmpeg и выполняет роль медиа-сервера — получает видеопоток от ffmpeg, который может быть запущен на другой машине, и раздаёт его счастливым пользователям.
Каждый получаемый поток называется Feed’ом (далее будет просто фид). Таких потоков может быть несколько, так же как и отдаваемых (выходных).
FFmpeg у нас будет захватывать видео с веб-камеры или читать из файла.

Мы запустили вчера проект «Чип энд Дэйли» — он продает 1 товар в день, но с большой скидкой. Товар нужно успеть купить :) Американский аналог Woot.com вполне успешен – 1-1,5 млн. уников в месяц, оборот более 120 млн. дол. при марже 10-15%. Я расскажу, что скрыто за «оберткой» сайта и почему этот бизнес совсем не просто скопировать; а также, какие ошибки мы уже успели сделать.

Зачем мне это было нужно?

Проект настойчиво требовал подключения удобных платежных систем. Да, есть webmoney, но не у всех. Да, есть moneybookers для карточек, но слишком долог бюрократический процесс.

Было принято решение принимать платежи через QIWI, во-первых потому что их автоматы есть практически везде, а во-вторых (тссс, большой секрет!) они готовят запуск системы прямых платежей со счета сотового оператора, без всяких дурацких СМС и девяностодевятипроцентных комиссий.

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

Сказано – сделано!

Для сайта был взят вполне заурядный VDS, на котором собран вполне заурядный же серверный набор – nginx спереди, Apache позади.

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

Для работы с SOAP проще всего взять с гуглокода класс nuSOAP (http://code.google.com/p/nusoap-for-php5/).

Затем нам надо сделать две вещи:

1. Отправку на сервер QIWI информации о попытке платежа
2. Прием от QIWI на наш сервер пакета с информацией об изменении статуса платежа.

Документация, жаль, что не очень подробная, есть здесь: https://ishop.qiwi.ru/docs/OnlineStores_Protocols_SOAP.pdf

Беспрецедентные объемы данных заставляют разработчиков и бизнес приглядываться к альтернативам реляционных баз данных, используемым вот уже более тридцати лет. В совокупности все эти технологии известны как «NoSQL базы данных».


Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о high-load проектах). Есть три конкретные проблемных области:

• горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)
• производительность каждого отдельного сервера
• не гибкий дизайн логической структуры.

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

Введение

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

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

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

Защита (или отсутствие защиты) от различных типов атак демонстрируется на примере протоколов популярных сегодня систем: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa и PayPal (платёжные системы), а также OpenID, OpenAuth, OAuth (децентрализованная аутентификация).

Ни для кого не секрет, что в протоколе HTTP, а точнее в той его части, что является ответом с сервера, есть такие замечательные заголовки, как Last-Modified и ETag (Подробнее можно прочитать в спецификации протокола). Призваны они ускорить процесс получения контента с сервера, а точнее избавить клиента от загрузки данных, которые не были изменены с момента предыдущего запроса.

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

Снова приветствую Хабрасообщество. Недельку назад я выкладывал свою либу jQuery.keyboard. Там было несколько недостатков, нереализованных идей, да и огромное количество предложений и положительных отзывов побудили меня к быстрому написанию новой версии

Если нужно дать пользователю возможность загрузки нескольких файлов, традиционное решение на данный момент — использовать для этой цели Flash (реже — Java applet или ActiveX). В случае, если соответствующий плагин недоступен, пользователю, как правило, показывают стандартный HTML-элемент для загрузки файла.

Последнюю ситуацию можно улучшить, если использовать встроенную в браузеры возможность множественной загрузки файлов. Из всех браузеров сейчас данную возможность не поддерживает только Internet Explorer (впрочем, мы ещё не видели девятую версию, может там что-то изменится), остальные браузеры — Opera 9 и выше (а так же версии 3.5—6.05), Firefox 3.6+, Chrome 3.0.191.0+ и Safari 4.0.1+ такую возможность предоставляют.

Достаточно написать что-то вроде

Copy Source | Copy HTML

1. <form enctype="multipart/form-data" method="post">
2.    <input type="file" min="1" max="9999" name="file[]" multiple="true" />
3.    <input type="submit" name="submit" />
4. </form>

PHP оказался готов к такой конструкции (именно для него в параметре «name» стоят квадратные скобки), он просто разложит загружаемые файлы по элементам массива $_FILES, если только мы не используем «Оперу».

К сожалению, «Опера» (ещё с версии 3.5) отправляет, при использовании мультизагрузки, файлы в контейнере «multipart/mixed», который PHP не понимает.

Я попробовал исправить эту ситуацию.

Вслед за первой частью, призванной в первую очередь показать, что «не так страшен чёрт, как его малюют»

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