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

Если вы просто хотите ознакомиться с реализацией класса, то эти самые вспомогательные методы очень сильно мозолят глаза, приходится прыгать по коду туда-сюда. Да, конечно, можно разнести их по отдельным модулям, но я считаю, что зачастую это слишком избыточно (я, например, не хочу создавать модуль, который, по сути, определяет только один метод, декомпозированный на n частей). Особенно неприятно, когда эти вспомогательные функции состоят из одной строки (например, метод, который выдергивает определенный элемент из распарсенного JSON).

В этой статье я хотел бы рассказать как можно создавать сценарии сборки имиджей для Docker контейнеров с помощью системы многоцелевых сценариев Sparrow*.

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

Так как я вовлечён во множество Ruby-проектов, люди часто спрашивают меня, почему я не люблю Rails, какие проблемы у меня есть с ним и так далее. Поэтому я решил написать этот длинный пост, чтобы подвести итоги и все объяснить.

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

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

Приветствую!

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

Цель

Что это и зачем нужно?

Предположим у вас есть крупное новостное издание, у которого много разных типов материалов.

Для каждого типа материала существует своя модель: Topics::Article, Topics::Online, Topics::NewsItem и так далее. У них будут одинаковыми большинство полей, такие как заголовок, обложка, текст, авторы. Различие только в нескольких специфичных полях, уникальных для каждого типа топика.

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

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

Макет для отслеживания расходов приложения

1. Когда пользователь создает новую запись через горизонтальную форму, она будет вставлена в таблицу записей
2. Пользователь может редактировать любую существующую запись
3. Кликнув на кнопку Delete он удалит ассоциацию из таблицы
4. Добавление, редактирование или удаление существующей записи будет обновлять сумму в боксах в верху страницы

Инициализация React.js в Rails проект

Недавно (в конце марта 2016 года) делал исследование перспективности языков программирования на upwork.com для одного из своих проектов и подумал, что это может быть интересно кому-нибудь ещё.

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

Процентное соотношение офферов по популярным языкам программирования

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