В эфире пилотный выпуск стенгазеты Вечерний Анахорет™
Коль скоро компания наша разбросана географически, то жизнь кипит и бурлит порознь. И вновь устное народное творчество стало основным способом узнавать новости. Вечерний Анахорет™ призван исправить это недоразумение.
В коммерческих проектах жизнь бурлит и развивается. И не удивительно — ведь больше всего времени мы тратим именно на этот вид программирования.
Активная разработка новой версии трекера на этой неделе ознаменовалась переосмысливанием фильтров, и последующим рефакторингом и работоспособной формой создания новой истории.
В это же время Сухинина Ольга не покладая рук работает над макетами для трекера. Внешний вид истории претерпел значительные изменения.
Кстати, новый вид трекера доступен на демонстрационном сервере. Вход возможен только по короткому имени, и не доступен по адресу электронной почты, дабы не слать спам.
Благодаря усилиям Игоря Афонова, в проекте Getsocio значительно упростилась работа с инфраструктурой и системным администрированием. Игорь добавил к проекту фреймворк Chef. Установка и интеграция прошла не без проблем, но полученные преимущества с лихвой покрывают трудовые затраты.
Из литературы Игорь советует начинать с официальной документации.
Успешно завершился перевод на последнюю стабильную версию рельсов 3.1.1 проекта TurbineHQ.
На протяжении всех трех недель, в процессе работы над устранением проблем с изменением API рельсов Дмитрий Кириенко и Алексей Осипенко получили 350 очков опыта и массу новых ощущений.
Как оказалось, самая большая проблема в этой задаче была связана с внедрением замечательной возможности компилировать статические ресурсы с помощью библиотеки sprockets добавленной в рельсы по-умолчанию. Ребята с радостью ответят на вопросы, если кто-то еще захочет попасть в этот дивный и чудесный мир рельсов 3.1.
Нерешенной проблемой осталась так называемая «still waiting» проблема библиотеки mysql2. Пришлось отступить и использовать в тестовом окружении вместо mysql2 ее предшественницу — библиотеку mysql. Да, ’still waiting’ проблема проявлялась только в тестовом окружении.
Самой кропотливой частью работы было последовательное выпиливание вызовов устаревших методов и обновление второстепенных библиотек, которые зависят от АПИ рельсов.
В проекте Advanceclaim количество процессов, необходимых для работы приложения, уже давно перевалило за единицу. И вот, Андрей Кончин вместе с Павлом Митиным решили упростить процесс разработки, и начали использовать библиотеку foreman для управления процессами на машине разработчика.
Установка и настройка у ребят заняла чуть больше часа, и особых проблем в процессе не возникло.
Также Андрей обращает внимание на то, что при использовании foreman для запуска сервера не удастся воспользоваться ни стандартным отладчиком руби, ни новомодным pry — само приложение нужно запускать привычной командой rails server.
Совсем недавно среди нас, друзья, проводился опрос на тему верстки. Результаты были предсказуемыми, но от этого не менее интересными.
rails new
Последняя неделя примечательна была все еще плюсовой температурой за окном и вялой активностью на просторах оупенсорса.
Иван Ростовский активно занимается разработкой jquery плагина swap.jquery.js. Плагин предоставляет возможность поменять два DOM элемента местами с помощью простой команды
$(from).swap(to);
Младший научный сотрудник Бродяной Александр, по совету Додатко Вячеслава испытывает на прочность библиотеку Faye в своем проекте
faye_demo_app. С помощью Faye можно с легкостью делать push/pull уведомления в рельсовом приложении. Райан Бейтс в рейлскасте #260 рассказывает о этой библиотеке.
Судя по сниппету Алексея Левжинского, в котором сказано как подсветить рельсовый код в Sublime Text 2, он использует этот кроссплатформеный редактор для написания кода.
Есть вещи, которые забываешь с радостью.
Дмитрий является ведущим разработчиком компании. За его плечами многолетний опыт работы в джава и руби.
Работал в таких проектах, как Ringorang, Groupistan, Grublife и ActiveConversion. Сейчас трудится над британским
проектом TurbineHQ. Никогда не работал ни в Getsocio, ни в Трекере. Характер крайне дружелюбный. Женат.
Насколько нам извесно, ты являешься контрибьютором проекта Ruby on Rails. На твоем счету около десяти коммитов в рельсы. Какие советы ты можешь дать будущим контрибьюторам в большие оупенсорс проекты?
Во-первых, читайте исходный код. Благо к этому нас поощряет сам open source, в котором документация довольно часто либо недостаточна, либо расходится с реальностью. По поводу и без повода заглядывайте в исходный код библиотек, с которыми вы работаете. Это очень полезно. Вы увидите, почему вещи работают так или иначе. То, что вы считали магией, обернётся простыми и понятными строчками кода.
Во-вторых, не бойтесь. Если посмотреть историю коммитов в Rails, можно увидеть, что больше половины работы выполняется людьми за пределами так называемой core team, а core team всего лишь принимает pull requests. Если вы встречаете очевидно неверное поведение библиотеки, и, заглянув в код, видите ошибку — делайте fork и исправляйте. Вклад Github в развитие open source трудно переоценить — никогда ещё участие в open source разработке не было столь лёгким.
Что до участия в разработке Rails, тут я советую прочитать раздел rails guides, посвящённый этому вопросу. Это сэкономит вам часик-другой. В корне каждой части Rails (таких как ActiveRecord, ActiveSupport, и т.д.), лежит файлик RUNNING-UNIT-TESTS с инструкциями по запуску модульных тестов. Это сэкономит ещё полчасика. Обязательно пишите тесты на вносимые изменения — патч без тестов, скорее всего, не будет принят. Лучше вносить изменения в режиме «вначале тесты».
Если очень хочется поучаствовать в разработке Rails, но что сделать — не знаете, просмотрите список открытых issues, особенно тех, которым присвоен тот или иной milestone. Там всегда есть что-то простое и быстрое. Ещё изучите Github markdown — ваши pull requests будут лучше смотреться.
В общем, ничего военного. Просто загляните в код, улучшите его, отправьте pull request. Это просто.
А как на счет своих оупенсорс решений? Многие разработчики в своих проектах, не найдя готового решения, пишут свою библиотеку. Ты являешься автором нескольких готовых решений среди которых гем soprano или abacus_count. Когда наступает тот самый момент, когда код из папки ’lib’ должен перекочевать на github?
Не стоит называть меня «автором» soprano. Soprano — не более чем реинкарнация сборника рецептов Capistrano от Дениса Барушева, который назывался Capone и больше не поддерживается. Моего кода, по большому счёту, там и нет совсем. Я добавил «поддержку» mysql2, убрал рецепты, которые больше не нужны (такие как rake gems:install) и переделал инфраструктуру проекта с Jeweller на Bundler-style. Да, я планирую поддерживать этот сборник рецептов, но пока что я не его автор. Скорее, maintainer.
Что же до вопроса, отдельный gem и папка lib равнозначны. Если код достоин папки lib, значит, он достоин и того, чтобы стать библиотекой =). Критерий для обоих случаев я формулирую так: если вы можете описать, что делает код, не используя слов из предметной области проекта — это точно библиотека. Если нет — это возможно библиотека.
Однако, жизнь вносит свои коррективы, и, казалось бы, чисто инфраструктурные решения прозябают в многочисленных папках lib многочисленных Rails проектов. Только в моём текущем проекте их около 5. Почему так происходит? Помимо элементарной нехватки времени и лени, есть два больших препятствия: тесты и проблема «неуловимого Джо».
Да, чтобы выложить библиотеку на Github, она должна включать в себя автоматические тесты. Если этого не сделать, развитие библиотеки будет парализовано — у потенциальных авторов fork’ов просто не будет способа узнать, не сломали ли они чего-то. Очень часто у нас хорошо протестировано собственно приложение, затем, в ходе рефакторинга из него выделяются инфраструктурые части, но вовсе не в режиме «вначале тесты». Потом тесты на саму библиотеку тоже не пишутся. Это приводит к тому, что код обречён пребывать в папке lib долго-долго-долго. Что тут сказать? Помимо очевидного — выделяя инфрастуктурный код, переписывайте его заново в TDD — могу ещё добавить: выкладывайте как есть. Когда появится первый fork, его автор сам попросит у вас тесты — будет хороший стимул.
Вторая же беда — проблема «неуловимого Джо» — гораздо серьёзнее. Бывает такое, что ваше инфраструктурное решение подобно неуловимому Джо — оно никому даром не нужно. Приведу пример.
В ходе работы над моим текущим коммерческим проектом возникла необходимость сделать боковую панель с набором разнообразных фильтров, управляющих коллекцией записей, отображаемых на странице. Примером может служить список фильмов kinobaza.tv. Пройдя несколько реинкарнаций родилось довольно миленькое решение с ограниченно приятным интерфейсом и разумным набором характеристик (фич). Когда же я «созрел» для того, чтобы переписать его в TDD, оформив в виде библиотеки, я уже пришёл к мнению, что такие задачи нужно решать совершенно по другому. Если заботит проиводительность, нужно прибегнуть к чему-то наподобие Sunspot/Solr или Elastic Search (особенно привлекательно выглядит Elastic — обязательно его пощупаю в ближайшем будущем), а если хочется чего-то инфраструктурно простого — что бывает гораздо чаще — я категорически рекомендую использовать Ransack (ранее известный как MetaSearch) от замечательного open source разработчика Ernie, автора ещё как минимум двух замечательных must-use библиотек для ActiveRecord. Если же Ransack не решает какой-то специфической проблемы — лучше вложиться в Ransack pull request’ом и/или временно использовать свой fork.
Наверное, с проблемой «неуловимого Джо» стоит поступать так же, как и с тестами — игнорировать и всё равно выложить. Разрабатывают же Clearance и Sorcery, при том, что стандартом де-факто является Devise.
В качестве хорошего пособия по написанию библиотек для Rails приложений я настоятельно рекомендую книгу Crafting Rails Applications всем известного Хосе Валима (кстати, она есть у нас на вики).
Резюмируя, скажу, что нужно больше библиотек, хороших и разных. Во-первых, вам же будет легче — в следующий проект ваши решения будете не копировать, а просто повторно использовать. Во-вторых, если кто-то ещё будет этим пользоваться — он быстрее вас может найти ошибку и, тем самым, позволит вашему решению стать лучше. В-третьих, в масштабах организации размера Анахорета это вообще основной способ появления новых open-source решений — пишем для себя, пользуемся, обкатываем, получаем новую популярную библиотеку.
Лучшая благодарность — это ваши коментарии и замечания.
Даже специальная страничка для комментирования есть.