Друзья, представляем вашему вниманию вторую часть перевода «Чем PostgreSQL лучше?». Надеемся, она вызовет такое же горячее обсуждение в комментариях, как и первая часть. А также с радостью продолжим с вами дискуссию лично на PG Day'16 Russia, до которой осталось совсем немного!

В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». В первой части этой серии мы рассмотрели хранение данных — модель, структуры, типы и ограничения по размеру, — чтобы дать вам несколько причин, почему Постгрес подтверждает свои слова делом. Во второй части мы поговорим о манипуляциях с данными и поиске, включая индексирование, виртуальных таблицах и возможностях запросов. В этой серии мы выясняем, что выгодно отличает PostgreSQL от других баз данных с открытым исходным кодом, а именно — от MySQL, MariaDB и Firebird.

Сегодня давайте поговорим о преимуществах Postgres перед другими системами с открытым кодом. Эту тему мы обязательно раскроем более подробно на PG Day'16 Russia, до которой осталось всего два месяца.

Возможно, вы спрашиваете себя: «Почему PostgreSQL?» Ведь есть и другие варианты реляционных баз данных с открытым исходным кодом (в рамках этой статьи мы рассматривали MySQL, MariaDB и Firebird), так что же Постгрес может предложить такого, чего нет у них? В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». Мы приведем несколько причин, почему Постгрес делает такие заявления.

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

Наверняка почти у каждого пользователя ОС Linux и ОС Windows, а я имею в виду именно тех, у кого, в силу ряда причин, установлены обе системы, время от времени возникал вопрос: «А нельзя ли, черт возьми, придумать способ, с помощью которого можно было бы устанавливать эти системы в произвольном порядке? Без порчи настроек загрузчика?» Ведь если ставим сначала Windows а потом Linux всё хорошо — линуксовый загрузчик (например GRUB) обычно подхватывает bootmgr. Если ставить в обратном порядке то увы. Даже с использованием GPT + EFI. В случае с EFI нет опасности перезаписи MBR, зато таки есть один нюанс, который лично мне не нравится — установщик Windows в режиме EFI хоть и не перезаписывает сектора диска своим кодом, но зато переопределяет NVRAM, подсовывая туда путь к своему загрузчику. Так что функционал GBUB всё равно приходится восстанавливать. В настройках штатного установщика нет опций для кастомизации процесса установки загрузчика. А что если… не использовать стандартный установщик?! Ну, или почти не использовать…



И такой способ есть. И основан он на технологии установки Windows, которую мы имеем в её дистрибутивах начиная с «семерки». Способ работает для случая Windows версий 7/8/8.1/10, как в случае с MBR + BIOS системы, так в случае с EFI + GPT. Установить систему можно как в раздел HDD, так и на VHD. При этом функционал установщика нужен нам в общем-то для запуска программы настройки BCD-хранилища конфигурации загрузчика. Вместо установочного диска можно использовать загрузочный носитель на основе WinPE. Если бы утилитам bcdedit.exe и BootICE была *nix альтернатива, весь процесс развертывания системы можно было бы вообще выполнить в среде Linux.

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

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

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

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

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

Я очень люблю Leaflet. С его помощью можно очень быстро строить свои интерактивные карты. Однако, практически все доступные поставщики тайлов (слоёв для карт) предоставляют свои услуги за весьма внушительные деньги. Существуют такие OpenSource-проекты, как OSM, но не всегда их тайлы удовлетворяют своим внешним видом.

Цель

Цель заключалась в том, чтобы слепить своего полностью бесплатного кентавра. Мне всегда нравились Yandex-карты, но не их API. Поэтому я заинтересовался вопросом внедрения Яндекс-карты, как слоя для Leaflet.

Заинтересовавшись методологией построения SPA-приложений на Ruby on Rails, я пришел к некоторым идеям, которые реализуются теперь в каждом моем приложении и впоследствии даже были выделены в отдельный гем Oxymoron. На данный момент на Oxymoron написано более 20 достаточно крупных коммерческих рельсовых приложений. Хочу вынести гем на общественный суд. Поэтому дальнейшее свое повествование буду вести уже на его основе.

Пример готового приложения.

Эффективные Рельсы — более точного названия для книги придумать было бы сложно. Всё содержание описывается этими двумя словами и раскрывается для нас в сотне рецептов на 380+ страницах. В ожидании выхода финальной версии Rails 5, данное чтиво — то, на что стоит потратить время, благо потребуется его не так много. Но данное вложение вернётся колоссальной прибылью знаний и позволит, как говорится на обложке, «создавать Rails-приложения с нечеловеческой скоростью». Да и не только Rails, да и не только Ruby. Первые две главы включают в себя обилие информации по работе с терминалом и СКВ. Подробности под катом.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Примечания переводчика:

Всем привет. Данная статья является вольным переводом (ссылка в конце). Я не претендую на какую либо 100% корректность перевода. Однако считаю, что общую суть происходящего передал полностью.

Для кого может быть полезна эта статья? Скорее всего, для начинающих Ruby on Rails разработчиков, кому просто интересно понять некоторые моменты в работе Ruby.

Для кого эта статья может быть бесполезна? Скорее всего, для чистокровных Ruby программистов и прожженых Ruby on Rails разработчиков. Высока вероятность того, что вы это уже знаете.

Зачем я сделал перевод? Эта статья мне показалась интересной и внутри меня просто появилось желание поделиться ею со всем русскоговорящим (м.б. плохо знающим английским) сообществом.

P.S. Если знаете английский, просто перейдите по ссылке в конце.

В данной статье я хочу рассмотреть FileSystem API и File API, разобраться с его методами и показать пару полезных штук. Эта статья является компиляцией материалов с html5rocks (1, 2, 3). Все представленные ниже демки можно посмотреть по первым двум ссылкам. Третья ссылка так же предлагает ряд интересных демо. Ну а теперь займемся изучением материала.

На прошой неделе вышел превью Ruby 2.3.0. Что есть интересного из изменений:

• оператор безопасной навигации вглубь объектов (safe navigation operator), #11537
• в Hash и Array добавлен метод dig для доступа вглубь вложенных хэшей или массивов #11688
• движение в сторону неизменяемых (frozen) по умолчанию строковых литералов (обоснование, обсуждение #11473

Привет, Хабр!

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

Мнение автора может не отражать позицию компании и других коллег.

Знакомьтесь — Александр Ефимов, Configuration manager/DevOps

Есть у меня знакомый, который, будучи первоклассным сисадмином, мечтает стать программистом. По его словам, хочет творить, а не использовать уже существующий… не очень хороший софт. В чем-то я его понимаю: «чистое» творчество — безусловно, круто. Но давайте разберемся, что и как происходит на самом деле.

Я разместила иконки курсов Стэнфордского университета по разработке приложений на iOS в обратном хронологическом порядке. На первом месте стоит иконка Swift — нового языка программирования для создания приложений на iOS, объявленного на WWDC 2014. Кроме Swift реализована новая версия iOS — iOS 8. Уже известно, что Стэнфордский университет запустит зимой 2015 года новый курс CS193P с неизвестным пока названием (может быть будет что-то вроде «Developing iOS 8 Apps for iPhone and iPad»). Лектор тот же — профессор Paul Hegarty.
В традиции Стэнфорда выкладывать курс CS193P на iTunes U в виде бесплатного курса обучения, но делают это они со сдвигом во времени, чтобы не мешать платному обучающему процессу, так что в феврале-марте 2015 года (как это было в 2013 году) можно ожидать постепенное появление лекций на iTunes U. Так что время есть.
Я прошла почти все курсы профессора Пола Хэгарти — от iOS 5 до iOS 7 — до самого конца (смотри Github ).
Для подготовки к перспективному курсу по iOS 8 разместила на своем сайте «Разработка iOS приложений» неавторизованные конспекты лекций, тексты домашних заданий и примеры их решения на русском языке для последнего доступного в настоящее время обучающего курса «Developing iOS 7 Apps for iPhone and iPad», запущенного Стэнфордским университетом в семестре «осень 2013 — зима 2014 года» на iTunes U.

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

Кому это будет интересно?

• Если вы начали писать тесты недавно.
• Если вы пишете тесты и считаете, что в них много копипасты, или можно значительно улучшить их.
• Если вы пишете тесты изредка или не пишете совсем, так как вам не нравится или считаете, что это долго.
• Если вы мастер в написании тестов. Возможно, вы узнаете некоторые тонкости или найдете несколько полезных мелочей.

Предлагаю вашему вниманию перевод фрагмента книги Metaprogramming Ruby 2 за авторством Паоло Перротта (Paolo Perrotta).

Что такое method_missing?

В Руби мы можем вызывать методы которые не существуют, но это будет возвращать нам ошибку. Для примера:

class Lawyer; end
nick = Lawyer.new
nick.talk_simple

NoMethodError: undefined method 'talk_simple' for #<Lawyer:0x007f801aa81938>

Помните ли вы как работает поиск методов? Когда вы вызываете метод talk_simple, Ruby идет в класс объекта nick, и перебирает там методы. Если он не может найти метод там, он ищет его в родителей данного класса, потом в Object и наконец в BasicObject. Ну и поскольку Ruby не может нигде найти метод talk_simple, он запускает метод method_missing для nick’a. Ruby знает что этот метод есть, потому, что это приватный метод BasicObject от которого наследуются все объекты.

Были времена на Хабре, когда каждый уважающий (и не очень) себя рельсовик зачем-то выкладывал свои рецепты настройки боевого сервера и деплоя приложения на Ruby on Rails. Таких статей было 60% от всех статей в хабе Rails, и отголоски того времени до сих пор всплывают: так, например, за август я нашёл две статьи про деплой рельс.

Надоело.

$ gem install from-scratch
$ scratchify your_app_name your.host.com

Что это за магия, читайте под катом.

В этой серии статей я соберу бОльшую часть своего опыта разработки на Ruby on Rails. Эти методики позволяют контролировать сложность и облегчают сопровождение проекта. Большинство из них придумал не я, и, по возможности, буду указывать источник.

Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.

Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.

Привет!

Сегодня новое интервью со спикером предстоящей конференции RailsClub — Клаудио Баччигалупо, контрибьютором Rails с более чем 100 коммитами, членом команды Rails Issues (closing/merging PR on rails/rails), организатором Ruby/Rails митапа в Лос-Анджелесе и одним из авторов еженедельной рассылки This week in Rails.

Предыстория

На создание этой статьи меня толкнула недавняя публикация о деплое. В приведённой статье описан способ разворачивания проекта на основе rbenv, я же опишу ситуацию с rvm и настройкой upstart.

Задачи и требования

Итак, дано: простейшее RubyOnRails-приложение. В случае разворачивания своего проекта я ставил перед собой следующие задачи:

• ОС Ubuntu LTS 14.04;
• Веб-сервер Nginx;
• Сервер приложения Puma;
• Использование RVM для установки ruby требуемой версии;
• Автоматический запуск приложения при запуске VPS-сервера, возможность управлять приложением как службой;
• Автоматизация процесса деплоя с помощью mina;

Почему Ubuntu?
Просто я к ней привык (точнее к её производной — Linux Mint).

Почему puma, а не unicorn или passenger?
О пуме я слышал неплохие отзывы, а у unicron страшненький сайт. Passenger, на мой взгляд, нарушает принцип единственной обязанности — я хочу иметь веб-сервер и приложение-сервер.

Почему RVM?
Я к нему привык — у меня он установлен на локальной машине, хочу его видеть и на production.

Почему mina?
Она действительно проще чем capistrano и при этом быстрее. Скорость достигается за счёт того, что для каждой задачи capistrano создаёт отдельное ssh-соединение. Mina же формирует shell-скрипт и выполняет его в рамках одного соединения.

В данном случае задача легко разбивается на 3 этапа:

1. Убедиться, что приложение корректно запускается (пока без автоматизации);
2. Настроить сервер так, чтобы наше rails-приложение работало как полноценная служба;
3. На основе этого настроить автоматизированное разворачивание с помощью mina.

В этой небольшой статье я бы хотел показать настройку Rails — приложения работающего на Nginx'е с Puma и как это все деплоить с помощью Mina.