Что будем писать

В прошлой статье мы писали простенький эмулятор терминала на PHP. Я думаю, теперь время написать что-нибудь более серьезное, на вебсокетах. Какой язык использовать для работы с вебсокетами..? Питон..? Руби..? JavaScript..? Нет! Раз уж зарелизился Go 1, давайте на нём и напишем ;). Я постараюсь не повторяться и не писать сюда целиком код. Я приведу лишь интересные, на моей взгляд, фрагменты.

Демо

Спасибо пользователю Aleks_ja за возможность посмотреть эмулятор терминала в действии (нужен браузер с последней версией вебсокетов — например это Firefox 11 или последний Chrome). С первого раза оно может не подключиться, если демон не успеет стартовать за 100 мс — попробуйте сначала обновить страницу.



Исходный код веб-терминала доступен на гитхабе. Компилировать вебсокет-демон необходимо самостоятельно (командой go build) — это небольшая мера защиты от тех, кто любит «повзламывать» хостеров ;).

Как менеджер проектов в своё время я попытался интегрировать различные Agile/SCRUM методики в свою повседневную жизнь. Ведь она тоже в каком то смысле является долгосрочным и довольно динамичным проектом.

Неоднократно пробовал использовать популярные GTD инструменты, но в итоге именно Google календарь ввиду своей наглядности и привязке ко времени — оказался наиболее эффективным. Получается такой вот Self SCRUM Board с итерациями и планерками :)

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

За время работы с API Facebook я накопил несколько рецептов оптимизации запросов: как увеличить скорость работы скриптов, уменьшить их количество и ресурсоёмкость.



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

Все мы привыкли расширять функционал браузера с помощью дополнений. А разработчики GNOME предлагают нам то же самое делать и с графической оболочкой. Любой пользователь GNOME 3 может зайти на сайт https://extensions.gnome.org/ и установить себе любое понравившееся расширение. Для этого достаточно лишь кликнуть переключать, согласиться с установкой и перезапустить оболочку.

В релизе 2.1 было заявлена реализация такой функциональности, как новый фреймворк агрегирования данных. Хотелось бы рассказать о первых впечатлениях от этой весьма интересной штуки. Данный функционал должен позволить в некоторых местах отказаться от Map/Reduce и написания кода на JavaScript в пользу достаточно простых конструкций, предназначенных для группировки полей почти как в SQL.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

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

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

Из других вариантов, наиболее подходящим была USB Meteo Board от Sparkfun на основе Arduino, или самодельная система на основе того же Arduino или Netduino.

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

Подавляющее большинство из нас использует такое крайне полезное устройство, как источник бесперебойного питания. Качество питания не везде идеальное, да и просто мельчайшие проблемы с электропитанием иногда могут дорогого стоить. Потери данных это всегда неприятно, а иногда просто таки фатально. Устройство куплено, установлено под стол, подключено и владелец его находится в полной уверенности, что в любом случае при перебое в электропитании он успеет корректно завершить работу, а может быть и сделать бэкап на флешку. Время идет, бесперебойник периодически дает о себе знать — как заправский сторожевой пес он подает голос при малейших отклонениях в параметрах электросети. Хозяин спокоен и все хорошо. Но в один из дней перебой таки случается и в этот раз ИБП не просто подает голос и сразу переключается с батареи на сеть, в этот раз свет выключили на долго. Мы спокойно копируем файлы (ведь в запасе у нас минут 15, не меньше) и тут бесперебойник начинает пищать совсем часто и все выключается. Как так? Ведь бесперебойник же должен был нас защитить от подобных ситуаций, а он только вселял нам ложную уверенность в нашей безопасности! Почему так произошло?

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

Иван Гладких и Павел Емельянов сегодня (20 февраля 2012 года) начали свободно (по лицензии OFL 1.1) раздавать шрифт под названием Prosto, разрабатывавшийся в течение последних шести месяцев:



Шрифт раздаётся в архиве (45 Kb RAR, включая лицензию OFL) и предназначен для логотипов, заголовков и презентаций. Начертание единственное (без жирных, тонких и наклонных вариантов).

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

Вот обильная презентационная инфографика (≈½ мегабайта), дающая достаточное представление о форме и возможностях нового шрифта:

TheSortableTree — гем, реализующий функционал Drag&Drop для деревьев построенных на основе гемов awesome_nested_set или nested_set.



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

Мы использовали гем для формирования многоуровневого дерева комментариев. Но было одно но… В тот момент не было ни одного хелпера, который бы позволял отрисовывать эти деревья. Из-за этого приходилось выдумывать свои велосипеды. Свой велосипед сделал и я.

Нет, я не склонен драматизировать и усложнять процесс реализации. У каждого из нас свои предпочтения. Поэтому я сделал самую обычную рекурсию, которая отрисовывает дерево с помощью паршелов.

Да, меня критиковали — это медленно отрисовывается, это не сработает на дереве из 10 000 элементов, надо по-другому и вообще…

Однако с 2008 года я так и не увидел чего-то другого, более доступного, быстрого и простого. Возможно, я плохо искал.

И вот я, потупив взор и нервно теребя в руках носовой платочек, представляю вам реинкарнацию моего хелпера в виде гема основанного на Rails Engines.

Уверен, для отрисовки небольших деревьев (до 100 элементов) и создания небольших CMS, где хочется управлять деревом простым перетаскиванием, мой хелпер подойдет идеально.

https://github.com/the-teacher/the_sortable_tree

Здравствуйте!

Это вторая из трех статей о техниках анализа проблем и принятия решений (первая здесь).

Сегодня речь пойдет о технике, которая называется «Вопросы Леонардо да Винчи» и является скорее способом мозгового штурма.
Откуда такое название? По непроверенной информации метод этот появился после расшифровки и анализа дневников гения, в которых и было найдено описание, а также следы неоднократного применения данного метода.

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

Примеров в этой статье не будет по двум причинам.
1. Пример в первой статье оказался крайне неудачным
2. Текст получился бы слишком громоздким, если бы я использовал хотя бы один пример (сейчас поймете почему)

Всех заинтересовавшихся прошу под кат.

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

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

Продолжаем серию статей, в которой мы знакомим читателей с различными веб фреймворками. И сегодня позвольте представить Goliath (Голиаф, http://postrank-labs.github.com/goliath/) — асинхронный веб фреймворк на Ruby, созданный компанией PostRank (http://postrank.com/), ныне купленной Google.

Главной особенностью Голиафа является применение модели событий для ввода-вывода, посредством библиотеки EventMachine, а также механизма волокон (fibers), появившегося в Ruby 1.9. Его можно считать аналогом столь модного сегодня Node.js, только на Ruby.

В статье мы рассмотрим такие вопросы:

• волокна и события;
• установка Goliath;
• написание простого чата с применением механизма long-polling;

В заключении вы найдете традиционные тесты производительности.

— Феденька, ты очень интеллигентный мальчик, ты мне очень нравишься, но Я БУДУ СТАВИТЬ ДВА В ГОДУ!!! — визжала моя школьная учительница по французскому и делала примерно такое лицо.

Моя школьная учительница по английскому языку делала другое лицо:

Вы в Интернет кафе и вам срочно надо нарисовать что-то в MS Visio? Не волнуйтесь, зайдите на Diagram.ly.

Проблема взаимопонимания

Представьте себе ситуацию: вы — фрилансер и работаете с Ext. С вами удалённо работает один (или несколько) разработчиков back-end. Работа идёт быстро и гладко. Но вот вот случилось так, что разработчик серверной части сменился. Если у нового коллеги есть опыт взаимодействия с Ext — всё замечательно. Но вот если человек впервые будет писать back-end для Ext или впервые будет писать для веба (такое тоже случается), то вам будет необходимо найти общий язык.
И вот тут могут начаться проблемы…
Придётся тратить время на простое объяснение протокола, объяснения как должен реагировать сервер на те или иные запросы. Чтобы избежать этого, я подготовил документ, описывающий все (ну или почти все нюансы стандартного для Ext протокола). Этот документ и представлен под катом.

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

О системе

Фирма, в которой я работаю, разработала свою трейдинговую платформу типа MTF. В этой системе ежесекундно производятся десятки тысяч торговых операций, и с помощью паттерна Disruptor, средняя скорость выполнения трейда не превышает 20.5 миллисекунд. В проекте задействованы сложнейшие интеграции с третьими сторонами — крупными банками, Лондонским Домом Клиринга LCH и другими корпорациями.

На разработку проекта ушло около 3 лет и команда из примерно 20 инженеров. В проекте нету и не было ни одного руководителя проекта, координатора, планов проекта, диаграмм Гантта, документов архитектуры, спецификаций требований, и планов тестирования.

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

Несколько дней назад мы с TheShock создали топик в котором собирали ваши вопросы, касательно JavaScript (архитектура, фрэймворки, проблемы). Настало время ответить на них. Мы получили очень много вопросов, как в комментариях так и по email. Эта первая часть ответов — те вопросы, которые достались мне.