В большинстве рельсовых проектов основная концентрация кода приходится на модели. Все наверняка читали про Slim controllers & fat models и стараются впихать в модели как можно больше, а в контроллеры как можно меньше. Что ж, это похвально, однако в стремлении утолстить модели многие часто забывают про принцип DRY — don't (fucking) repeat yourself.
Я тут постараюсь вкратце расписать, как в районе моделей и рыбку съесть, и про DRY не забыть.
Для рельс уже написан миллион и один туториал про то, что делать, если вдруг приходится писать приложение, которое работает с деньгами.
Обычно все сводится к советам не использовать Float, использовать Decimal, транзакции там всякие и прочее. И в большей части случаев этих советов вполне достаточно для того, чтобы разработчик чувствовал себя сухо и комфортно.
А сталкивались ли вы с ситуацией, когда, скажем, приложение должно обслуживать жителей более чем одной страны?
Допустим, вы пишите крутой вебдванольный проект на рельсах. У вас есть друг Петя — сильный программист на джаваскрипте. Поскольку Петя пишет много и задорно, он решил облегчить себе жизнь и придумал новый язык с красивым и простым синтаксисом, который будет транслироваться в джаваскрипт.
Еще Петя — большой любитель зеленого чая, поэтому назвал он свой новый язык GreenTeaScript.
Кроме Пети, у вас есть еще один друг-программист-на-джаваскрипте Вася. Вася как-то раз придумал написать программу, которая разбирала бы JS на AST, оптимизовала его, а потом собирала обратно в красивый, структурированный код, отсекая всякое лишнее и форматируя по Кроуфорду. Назвал он свое детище BeautifyJS. Кстати, BeautifyJS еще умел собирать AST в минимизированный сжатый код и делал это быстрее и лучше остальных существующих в природе альтернатив.
Поскольку и Петя и Вася ни на чем, кроме джаваскрипта, программировать не умели, свои продукты они на нем и написали.
И тут вам, опять же допустим, первому в мире в голову пришла идея прикрутить эти замечательные штуки к своему крутому вебдванольному проекту на рельсах. Писать фронтенд на GreenTeaScript вам сильно понравилось, а сжатие скриптов с помощью BeautifyJS наверняка сильно ускорило бы сайт.
Недавно вышло обновление rake с версии 0.8.7 до версии 0.9.0, которое наделало много шума в сообществе и в очередной раз выявило проблему управления версиями. Мне бы хотелось прояснить ситуацию и снова проговорить основные моменты, которые я уже упоминал во времена релиза Bundler 1.0. Вначале я расскажу о простых правилах работы, а затем слегка углублюсь в детали.
Несмотря на заголовок, речь пойдет скорее о руби, чем о рельсах. Поэтому я решил разместить этот перевод в блоге руби.
Последние релизы MRI Ruby показывают значительное замедление при подключении файлов.
Например, наше средненькое рельсовое приложение при загрузке делает require около 2200 раз — это где-то совсем в правой части графика. Совсем никуда не годится. На 1.9.2 приложение стартует за 20 секунд, а на 1.9.3 уже 46. Слишком медленно!
Джед Шмидт, Томас Фухс и Дастин Диаз — достаточно известные в JavaScript-коммьюнити ребята в последнее время нашли себе новую развлекуху — писать полезные штуки размером не больше одного твита, то есть 140 байт. Даже домен зарегали — 140byt.es, куда приглашаются все желающие попробовать свои силы в написании супер-компактных функций.
Естественно, в ход идут все самые изощренные способы и техники уменьшения размера исходника. У них есть вики-страничка с советами, которую я и решил перевести.
Сразу оговорюсь, что читаемость обработанного таким образом кода стремится к нулю, так что использовать эти трюки стоит только в случаях, когда размер действительно превыше всего. Например, при участии в конкурсе JS1k.
Все менеджеры пакетов в Unix имеют определенные недостатки и большинство Linux-дистрибутивов пытаются по-разному эти недостатки обойти. В этом посте я расскажу про Homebrew — новый менеджер пакетов, нацеленный на простоту использования.
До Homebrew было несколько различных попыток создать эффективные пакетные менеджеры для OS X. Две наиболее популярные вылились в итоге в Fink и Macports, но у каждой из них все равно есть свои острые углы. В частности, в обоих создание своих пакетов или портов является черезчур сложным.
В Homebrew создавать новые пакеты и работать с ними проще пареной репы. Давайте посмотрим.
