Информация о проекте — http://intaro.ru/portfolio/gosduma/

Мой пост о настройке системы под нагрузки — http://intaro.ru/blog/2011/01/24/gosduma-highload/.

Всем, у кого есть желание и возможность побывать на конференции разработчиков Symfony, добро пожаловать на Symfony CAMP UA 2010.

Конференция пройдет 3 июля 2010 года, участие бесплатное. Буду освещаться тенденции развития фреймворка, актуальные проблемы разработки и многое другое.

Также приглашаются люди, которые будут помогать в закулисных делах конференции. Если у вас есть желание помочь, при регистрации в комментариях к заявке укажите «хочу в help team».

Сегодня за день наваял и запустил твиттер-бота с рабочим названием «Полиглот».

Адрес — @_polyglot

Суть работы: бот отвечает на реплаи (reply) и личные сообщения (direct message) их переводом. С помощью хеш-тегов задаются исходный и конечный языки перевода в формате #from_lang2to_lang.

Пример

Запрос:

salikhov: @_polyglot Мороз и солнце — день чудесный #ru2en
salikhov: D _polyglot It is wonderful #en2de

Ответ:

_polyglot: D salikhov Frost and sun - a wonderful day
_polyglot: D salikhov Es ist wunderbar

Бот на данный момент поддерживает следующие хеш-теги:

#zh2en #nl2en #en2ar #en2nl #en2fr #en2de #en2el #en2it #en2ja #en2ko #en2pt #en2ru #en2es #en2sv #fr2sv #de2fr #de2sv #el2en #it2en #ja2en #ko2en #pt2en #ru2en #es2en #es2sv #nl2sv #sv2de #sv2en #sv2es #sv2fr

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

Если говорить о технической части, то бот написан на Ruby с использованием gem-пакетов rsay и twitter4r. На данный момент бот обрабатывает входящие сообщения с частотой раз в минуту.

Писал бота в рамках продолжающегося фонового изучения Ruby, плюс ко всему поработал с Twitter API, которое к слову сказать очень «прозрачно» и понятно.

При обнаружении косяков в работе сообщайте мне в личку или здесь в комментарии.

В общем, фоловьте и пользуйтесь на здоровье :)

PS Кстати можете считать меня мазохистом, т.к. разрабатывал, отлаживал и развертывал «Полиглота» я через GPRS.

UPD Все переводы «Полиглот» теперь высылает только на DM во избежание засорения френд-ленты и появления спама. Запросы как и раньше можно отправлять через reply и DM.

Дело в том, что при оптимизации загрузки страницы, как правило, рассматривают вопрос снижения времени скачивания js-файлов, но упускают вопрос инициализации загруженного кода.

Возьмем пример из реальной практики. Допустим, мы имеем портал, в котором клиентская часть (только javascript) состоит из 75 файлов общим объемом 800 Кб, в которых хранятся классы, содержащие управляющую логику, настойки и т.п., и 70% из инициализируется сразу после загрузки.

Если мы открываем такую страничку как есть с подключением 75 небольших js-файлов, то формируются очереди обращений к серверу, который скорее всего не успеет за раз быстро отдать все файлы. Но за счет постепенной загрузки и инициализации файлов пользователь видит плавную, хотя и небыструю загрузку портала.

Если мы возьмем другой крайний случай, когда все файлы минимизированы и объединены в один файл, что, к слову сказать, часто не легко сделать, то с одной стороны у нас все круто: один запрос к серверы, минимальный объем скачиваемых данных (допустим, мы сжали до 400 Кб), а с другой пользователь сидит 10 секунд, а у него ничего не происходит.

Наиболее оптимальным в данном случае мне кажется следующий вариант. Мы разбиваем минимизированный пакет на 2-3 файла, причем первый делаем наименьшего размера и вмещающим тот минимум классов, достаточный для того, чтобы страница начала «оживляться», пока оставшиеся js-файлы будут подгружаться. Далее подгружается файл №2, который подхватывает инициализацию первого файла, в это время догружается файл №3 и далее по аналогии.

При выборе последнего варианта мы оставляем на приемлемом уровне количество запросов к серверу и общий размер js-файлов, но при этом не создаем ощущения «зависшего» браузера у пользователя при загрузке страницы.

Все вышеописанное, конечно, актуально для больших js-библиотек от 500 Кб.

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

Если говорить о конкретных реализациях, то есть несколько готовых способов определения расстояния Левенштейна.

Существуют готовые функции levenshtein в PHP и PostgreSQL, у которых присутствует ограничение на длину сравниваемых строк в 255 символов. Для MySQL и Oracle я обнаружил только хранимые процедуры, которые рассчитывают данное расстояние.

Данную фичу я добавил на этом блоге. Для демонстрации ее работы возьмем адрес:

http://blog.salikhovilyas.ru/2009/06/07/did-you-know/

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

http://blog.salikhovilyas.ru/2009/06/07/didyouknow/

Если адрес отличается достаточно сильно, то система выдает 404 страницу, а также предлагает наиболее похожие адреса:

http://blog.salikhovilyas.ru/2009/06/7/didknow/

Аналогичную логику я добавил в небольшую symfony based cms, которую мы используем в своих проектах.

Если говорить о популярных на данный момент CMS, аналогичный функционал я заметил только в umi.cms, в остальных системах ничего подобного я не нашел.

Добрый день! Очень хочу работать! Не все умею, но быстро научусь.
Пишу на php. Зовите, приеду пообщаемся, может сгожусь. 

Человек даже не напрягся указать, как его зовут. Такое письмо-надежда в никуда.

А если серьезно, то у нас открыты вакансии php-программиста и js-программиста. Работы много, проекты интересные. Резюме — на указанный выше или мой ящик.

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

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

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

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

1. Настроенные и готовые к работе средства коллективной разработки: система версионного контроля (svn, cvs, git, на любителя), багтрекер и средства планирования/обсуждения в отдельных или одном лице.
2. Документация и материалы. Сюда входят ТЗ, описаниях архитектуры, интерфейса, дизайн, а также согласованные командой документы по организации кода, комментариев, базы данных и т.п.

Хаос в этих моментах приведет к хаосу во всем проекте (не путать с Доктором Хаусом ;).

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

P.S. Да, и если вам предлагают поучаствовать в проекте по разработке мессенджера за 2 месяца командой из 2-х человек, я настоятельно вам не рекомендую соглашаться. 

Итак, вот 5 произведений, которые я сейчас по-тихоньку читаю:

«Путь камикадзе». Эдвард Йордон

Автор делится опытом о том, что делать, если вы по воле случая участвуете или руководите «безнадежным» проектом разработки ПО, т.е. там, где реальная стоимость/сроки/план получаются в 1,5–5 и более раз больше заявленных. Рассказывается что с этим делать и как с этим жить. Решил почитать, т.к. начал сталкиваться с такими проектами на практике. 

«Золотой теленок». Ильф / Петров.

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

«Совершенный код». С. Макконнелл

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

И 2 книги стоят в очереди на чтение, пока что не успел начать:

«Александр Македонский». Илья Шифман

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

«Аналитическая психология. Тавистокские лекции». Карл Густав Юнг

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

--

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

Могу сказать, что система полностью восстановилась, как будто жесткий и не менялся вовсе: все на месте и все работает как прежде. Поэтому мой совет: при покупке мака первым делом настройте резервное копирование в Time Machine, а то мало ли что ;)

А сегодня я поставил поверх Snow Leopard. Результатом доволен. Освободилось 6 Гб места, система стала во многом быстрее работать, как известно она полностью 64-разрядная.

Посвежел Dock, сетка раскрывающейся папки стала прокручиваемой и многоуровневой – оч удобно.

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

Система стала нативно поддерживать NTFS, Safari теперь работает не просто быстро, а очень быстро. Система удалась на славу и в ней еще куча мелких доработок, не буду все пересказывать, на официальном сайте о них отлично написано.

Подсмотрено у Виктора Ронина.