Часть 1 — Теория

Данный блок про историю, как движение появилось в индустрии и как другие люди сами себе представляют эту профессию.

Барух Садогурский — DevOps для разработчиков (или против них?!)

Доклад начинается с того что ведущий пытается сам для себя определить что же такое devops, враг или друг он обычному разработчику 🤔

Барух Садогурский — DevOps не человек — Мы обречены #27

Данное видео — это не полноценный доклад, а интервью. Но не смотря на это, интервью является органичным продолжением предыдущего выступления (в комментариях есть таймкоды)

Часть 2 — Практика

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

Андрей Листочкин — DevOps for A Busy Developer

Докладчик с улыбкой делится своим опытом в данной сфере. Приводит практические примеры задач, инструментов и решений которые можно выбрать 🧑‍💻

Илья Климов — Ламповый CI/CD. Как и с чего начать

Практическая лекция возможностей CI/DC в GitLab

Почему Ruby медленный

Данный доклад не только про Ruby, он затрагивает тему работы языков программирования. Вкратце, у любого языка есть 3 скилла, как у персонажа в типичной RPG: удобство синтаксиса, скорость работы и расширяемость. Все три прокачать нельзя, поэтому приходится выбирать любые два 😅

Ruby CPU and Memory — Pareto principle

Хороший и вдохновляющий доклад для тех кому нравится или хочется заниматься оптимизацией производительности. Докладчик приводит в пример рабочий кейс как в Купибилет сэкономили большую сумму денег благодаря оптимизации производительности.

Небольшие видео Немчинского про книгу Чистый код (Clean Code)

Книга о которой все слышали, но не все читали. Сергей Немчинский, очень популярный человек на YouTube, в своей ламповой манере говорит основные принципы из книги и добавляет примеры из своего опыта. Советую! На момент написания статьи уже вышло 6 видео на YouTube, все их можно найти через поиск.

Дмитрий Цепелев / Как ускорить GraphQL API

Очень классный доклад в котором собраны все методы ускорения GraphQL. 🚀

Методы борьбы с legacy-кодом на примере GitLab

Доклад показывает как работают люди в больших компаниях с большими проекта. Как там у них все устроено и как они борются в legacy-кодом.

Building a Ruby web app using the Ruby Standard Library (Maple Ong)

Один из самых вдохновляющий докладов на Euruko 2021. Спикер решил написать простое веб-приложение для учета ежедневного кол-во шагов, но чтобы это было интересно, реализовать приложение на чистом Ruby без использования дополнительных библиотек. Дополнительно рассказать как работает TCP/IP протокол и на пальцах показать из каких модулей состоит любой веб-фреймворк а-ля Rails. Очень круто 😮

Барух Садогурский — Как правильно продать себя ради фана и профита

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

Самое скучное решение: как выбирать технологии, когда ты уже не стартап / Илья Климов

Еще одно хорошее выступление Ильи Климова о работе над большими проектами. На этот раз затрагивается темы выбора и обновления технологий.

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

TL;DR

• Если ты пишешь мини приложение — выбирай key-value БД (redis)
• Если нужно быстро сделать прототип — документоориентированная БД (mongoDB)
• Социальная сеть — тебе подойдет графовая БД (neo4j)
• Посчитать статистику — документоориентированная БД (mongoDB)
• Для всего остального есть SQL

Техническая часть

База данных — это всего лишь инструмент, для решения своей задачи: не только хранить информацию, но и давать интерфейс для манипулирования. Есть два больших семейства БД: SQL и NoSQL. Разберем их подробнее.

SQL

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

Такие БД активно используются с 80-х годов. Это уже зрелая и надежная технология с огромной методологической базой.

SQL развивался в первую очередь как стандарт. Если вы раньше слышали про такие БД как MySQL, SQLite, MariaDB — то знайте что это все реализации SQL и отличия только в нюансах.

NoSQL

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

Есть следующие семейства которые по-разному хранят данные:

• Key-value хранилища (ключ-значения)
• Документноориентированные БД
• Графовые базы данных

Key-value хранилища

Про них можно сказать что данные хранятся в одном глобальном JSON’е в которых вы записываете данные по ключу и по этому же ключу читаете информацию.

Преимущество такой реализации — это скорость работы т.к. O-большое по поиску в хеше — это 1. Она очень быстро находит данные и записывает их. Плюс она наименее требовательная к ресурсам. Из-за этого она хорошо подходят под небольшие проекты.

Самая популярная база данных данного семейста — Redis

Документноориентированные БД

Если базы данных предыдущего семейства хранили данные в одном глобальном JSON’е, тот тут у нас есть массив в который мы может складывать JSON-объекты. Такие массивы тут называются коллекциями.

Вы сохраняете в коллекцию JSON’ы с произвольными наборами данных и достаете данные из этой коллекции. JSON — это очень гибкая структура данных которая может быть сколько угодно вложенная по глубине. Плюс, не проблема добавить или удалить ключик из объекта в любой момент времени

Преимущества данного подхода — гибкость. У нас нет строгой схемы данных, как например в таблице, поэтому вы можете хранить в одной коллекции объекты с разнообразными ключами.

Дополнительно на уровне БД у вас есть простой, но мощный функционал подсчета статистики по вашим данных — достаточно пройтись по массиву с помощью `map/filter/reduce`

Самая популярная база данных данного семейста — MongoDB

Графовые базы данных

Как видно по названию, такие БД хранят графы. Но что же такое граф? — это очень математическая структура данных, и её лучше разбирать на примере.

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

Как уже понятно, такие БД идеальны для написания социальной сети где между объектами большое кол-во связей.

Структура хранения данных — следующая. Представьте что теперь у нас есть целых два массива в который мы складываем наши JSON’ы. Но в один мы складываем только данные с информацией обо всех объектов нашей системы (так называемые ноды), а во второй информацию о связей между объектами.

Для понимания тут хорошо подойдет пример: мы пишем сервис с информацией о фильмах, как Кинописк. У нас будут данные о фильмах и о том какие люди занимались его созданием.

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

Такая структура удобная тем что мы в одном запросе к БД достаем сразу все объекты которые нам интересны и связи: например при запросе, дай мне всех людей с кем работал этот режиссер.

Кроме соц-сетей, графовые БД хороши для реализацией систем рекомендаций т.к. нам удобно обходить графы и находить самые короткие маршруты между нодами. Самая популярная база данных данного семейства — Neo4J

Практические советы

А теперь к практике

Кейс: Мы пишем маленькое приложении чтобы выводить какую то одну информацию пользователям (курсы валют, погода в их родном городе и прочее)
Что взять: key-value БД(redis)
Почему: В данном кейсе достаточно использовать примитивные структуры данных. Положили строки/числа в массив и сохранил массив в БД по ключу — удобно

Кейс: Маленькое приложение чтобы трекать информацию (кол-во пройденных шагов, кол-во выпитых стаканов воды или что-то другое)
Что взять: key-value БД (redis)
Почему: смотри выше

Кейс: Наше приложение будет собирать данные из разнообразных источников, делает агрегацию по ним чтобы показать пользователям красивые дашборды, графики и прочее
Что взять: Документноориентированные БД (mongoDB)
Почему: Идеальна чтобы хранить в одной коллекции разнообразные данные. Так как данные хранятся не в таблице, хеши могут содержать разные ключи. Дополнительно поддержка функционала `map/filter/reduce` позволяет делать агрегации на уровне БД, а не приложения.

Кейс: Мы до конца не понимаем что мы хотим реализовывать, очень смутная цель, но мы уверены что за одну неделю напишем прототип и потом скорее всего все переделаем. Нам нужна гибкость для изменений структуры данных
Что взять: Документноориентированные БД (mongoDB)
Почему: Так как у нас нет строгой схемы данных, мы может легко менять информацию о наших объектов (добавлять и удалять ключи из JSON’а). Благодаря этой гибкости наши мы можем свободно и быстро менять данные.

Кейс: Мы пишем масштабное приложении где у каждого элемента, будет огромное кол-во связей. Функционал очень похож на типичную соц-сеть
Что взять: графовые базы данных (neo4j)
Почему: В графовых БД очень легко манипулировать связями между объектами в нашей БД

Кейс: Мы пишем систему рекомендации. Нам нужно записывать максимальное кол-во связей между и находить связи между ними
Что взять: графовые базы данных (neo4j)
Почему: Идеальная БД чтобы строить графы и находить короткие маршруты между ними

Кейс: Мы идеально представляем как записать наши данные в табличку в экселе. Или же мы хотите углубится в теорию и методологию реализаций баз данных
Что взять: Любую реализацию SQL
Почему: К вашим услугам огромное кол-во проработанной методологии, учебников и статей.

Заключение

Вот и все, надеюсь что этой статьей я ответил на вопрос и она оказалась полезной.

Каждый разработчик работает с git, но к сожалению не все используют rebase в своей работе. Мало кто знает в каких рабочих кейсах он может пригодится, поэтому я написал данную статью с разборами рабочих ситуаций.

Предупреждение: Все примеры представленные здесь про изменение над одним файлом. Это удобно чтобы показать процесс работы, но увеличивает вероятность что при rebase возникнут конфликты. Поэтому разбор конфликтов в статье не будет.

Не удивляйтесь что после rebase придется пушить код в репозиторий через параметр “-f”. Это нужно чтобы принудительно переписать изменения в репозитории

git push origin head -f

Но есть более безопасный способ запушить код — использовать ключ force-with-lease

git push origin head --force-with-lease

Кейсы

1. Поправить коммит в середине (fixup + rebase)
2. Удалить коммит в середине (rebase + drop)
3. Объединить коммиты и поменять текст итогового коммита (rebase/soft reset)
4. Поправить последний коммит (soft reset)
5. Поправить текст последнего коммита (amend)
6. Поменять коммиты местами (rebase)
7. Отребейзить ветку если родительская ветка была смерджена

1) Задача: поправить коммит в середине

Решение: сделать fixup

У нас есть 4 коммита в которых мы правили один файл

$ git log --oneline master..HEAD

aa871c7 (HEAD -> example_1, base_branch) add third paragraph to readme
3774350 add second paragraph to readme
2143008 add first paragraph to readme
1da47ab add title to readme

$ git diff master..HEAD

diff — git a/README.md b/README.md
index e69de29..315b9d6 100644
 — — a/README.md
+++ b/README.md
@@ -0,0 +1,7 @@
+## Hello
+
+First paragraph
+
+Second paragraph
+
+Third paragraph

Нам нужно поправить коммит который добавляет первый параграф (2143008). Открываем файл README.md и правим текст первого параграфа.

$ git diff

diff — git a/README.md b/README.md
index 315b9d6..14dc0b7 100644
 — — a/README.md
+++ b/README.md
@@ -1,7 +1,3 @@
 ## Hello

-First paragraph
-
-Second paragraph
-
-Third paragraph
+First paragraph :)

Так как мы в примере меняем один файл, то нужно сделать так каким он должен выглядеть после коммита (2143008) т.е там должен быть только заголовок и первый параграф.

Делаем “fixup коммит” задача которого поправить другой коммит в истории. Синтаксис операции следующий “git commit — fixup <commit_id>”

$ git add README.md
$ git commit — fixup 2143008

[example_1 4d0edd6] fixup! add first paragraph to readme
 1 file changed, 1 insertion(+), 5 deletions(-)

Готово, у нас есть новый коммит, но надо еще приложить усилия чтобы он применился к коммиту (2143008).

$ git log --oneline master..HEAD

4d0edd6 (HEAD -> example_1) fixup! add first paragraph to readme
aa871c7 (base_branch) add third paragraph to readme
3774350 add second paragraph to readme
2143008 add first paragraph to readme
1da47ab add title to readme

Для этого нужно сделать rebase к коммиту на 1 ниже того который мы хотим поправить (1da47ab) (возможно здесь придется в явном виде решить конфликты, если git не понял как связать hotfix).

$ EDITOR=vim git rebase -i --autosquash 1da47ab

# во время выполнения вы увидите что коммит fixup встал на свое “правильное” место, а не в конце истории

1 pick 2143008 add first paragraph to readme
2 fixup 4d0edd6 fixup! add first paragraph to readme
3 pick 3774350 add second paragraph to readme
4 pick aa871c7 add third paragraph to readme

Successfully rebased and updated refs/heads/example_1.

Посмотрим теперь на историю.

$ git log --oneline master..HEAD

8b8e8b2 (HEAD -> example_1) add third paragraph to readme
9dc3b2f add second paragraph to readme
557541f add first paragraph to readme
1da47ab add title to readme

И на изменения.

$ git diff master..HEAD

diff — git a/README.md b/README.md
index e69de29..ff9fc5e 100644
 — — a/README.md
+++ b/README.md
@@ -0,0 +1,7 @@
+## Hello
+
+First paragraph :)
+
+Second paragraph
+
+Third paragraph

Ура, у нас получилось!

2) Задача: удалить коммит в середине

Решение: сделать drop

У нас есть те же самые 4 коммита где мы правили один файл

$ git log --oneline master..HEAD

aa871c7 (HEAD -> example_2, base_branch) add third paragraph to readme
3774350 add second paragraph to readme
2143008 add first paragraph to readme
1da47ab add title to readme

$ git diff master..HEAD

diff — git a/README.md b/README.md
index e69de29..315b9d6 100644
 — — a/README.md
+++ b/README.md
@@ -0,0 +1,7 @@
+## Hello
+
+First paragraph
+
+Second paragraph
+
+Third paragraph

Мы поняли что первый параграф нам не нужен. Удалять изменения новым коммитом не хочется т.к. мы может просто удалить старый. Для этого делаем rebase к интересующему коммиту (1da47ab).

$ EDITOR=vim git rebase -i 1da47ab

И прописываем drop к тому коммиту, который мы хотим удалить.

1 drop 2143008 add first paragraph to readme
2 pick 3774350 add second paragraph to readme
3 pick aa871c7 add third paragraph to readme

Посмотрим что у нас получилось.

$ git log --oneline master..HEAD

2b87851 (HEAD -> example_2) add third paragraph to readme
db792c4 add second paragraph to readme
1da47ab add title to readme

$ git diff master..HEAD

diff — git a/README.md b/README.md
index e69de29..3354aa2 100644
 — — a/README.md
+++ b/README.md
@@ -0,0 +1,5 @@
+## Hello
+
+Second paragraph
+
+Third paragraph

3) Задача: объединить коммиты и поменять текст итогового коммита

Решение: сделать rebase

У нас есть один README.md файл и несколько «wip» коммитов.

$ git log --oneline master..HEAD

33e58db (HEAD -> example_3) wip
585c26b wip
173ab1f wip
c1f8895 wip
85855c0 wip

$ git diff master..HEAD

diff — git a/README.md b/README.md
index e69de29..6222dc3 100644
 — — a/README.md
+++ b/README.md
@@ -0,0 +1,7 @@
+## h2 header
+
+Some text. Bla-bla-bla
+
+### h3 header
+
+Some text again. LOL

Наша задача объединить это коммиты в один с осмысленным текстом. Для этого надо сделать rebase на 5 коммитов назад.

$ git log --oneline master..HEAD | wc -l
5

$ EDITOR=vim git rebase -i HEAD~5

И поменять pick на squash

1 pick 85855c0 wip
2 squash c1f8895 wip
3 squash 173ab1f wip
4 squash 585c26b wip
5 squash 33e58db wip

После этого вручную поменять сообщение первого коммита.

1 # This is a combination of 5 commits.
2 # This is the 1st commit message:
3
4 Create README.md file
5
6 # This is the commit message #2:
7
8 wip
9
10 # This is the commit message #3:
11
12 wip
13
14 # This is the commit message #4:
15
16 wip
17
18 # This is the commit message #5:
19
20 wip

Вроде получилось

[detached HEAD 30310eb] Create README.md file
 Date: Sun Dec 6 22:00:41 2020 +0300
 1 file changed, 7 insertions(+)
Successfully rebased and updated refs/heads/example_3.

Посмотрим что у нас есть в итоге.

$ git log --oneline master..HEAD

30310eb (HEAD -> example_3) Create README.md file

$ git diff master..HEAD

diff — git a/README.md b/README.md
index e69de29..6222dc3 100644
 — — a/README.md
+++ b/README.md
@@ -0,0 +1,7 @@
+## h2 header
+
+Some text. Bla-bla-bla
+
+### h3 header
+
+Some text again. LOL

Ура, данные объединились в один коммит.

Решение 2: сделать soft reset

Делаем soft reset на 5 коммитов назад

$ git log --oneline master..HEAD | wc -l
5

$ git reset --soft HEAD~5

И сохранить изменения в один новый коммит.

$ git ci -m “Add README.md file”

[example_3.2 22513de] Add README.md file
 1 file changed, 7 insertions(+)

Посмотрим что получилось.

$ git log --oneline master..HEAD

22513de (HEAD -> example_3.2) Add README.md file

$ git diff master..HEAD

diff — git a/README.md b/README.md
index e69de29..6222dc3 100644
 — — a/README.md
+++ b/README.md
@@ -0,0 +1,7 @@
+## h2 header
+
+Some text. Bla-bla-bla
+
+### h3 header
+
+Some text again. LOL

Все получилось!

4) Задача: поправить последний коммит

Решение: сделать soft reset

Итак, у нас есть два коммита. По каким-то причинам нам надо поправить последний коммит.

$ git log --oneline master..HEAD

4efcc59 (HEAD -> example_3.2) Add more text to README.md
22513de Add README.md file

Можно сделать fixup, но он требует несколько действий. Гораздо быстрее сделать по-другому - убираем последний коммит, но оставляем все текущие изменения

$ git reset --soft HEAD~1

В итоге у нас в истории остался только предыдущий коммит.

$ git log --oneline master..HEAD

22513de (HEAD -> example_3.2) Add README.md file

Но все последние изменения остались на файловой системе

$ git st

On branch example_3.2
Changes to be committed:
 (use “git reset HEAD <file>…” to unstage)

modified: README.md

Теперь мы можем поменять данные в файле которые нам надо и создать новый коммит.

$ git ci -a -m “Add more text to README.md”

[example_3.2 87eaff0] Add more text to README.md
 1 file changed, 2 insertions(+)

Вуаля, все получилось

$ git log --oneline master..HEAD

87eaff0 (HEAD -> example_3.2) Add more text to README.md
22513de Add README.md file

5) Задача: поправить текст последнего коммита

Решение: сделать amend

Иногда в тексте коммита можно допустить ошибку и его надо переписать. Самый простой способ это сделать amend.

$ git log --oneline master..HEAD

fb77ed2 (HEAD -> example_3.2) improve documentattion
87eaff0 Add more text to README.md
22513de Add README.md file

В последнем коммите опечатка в слове “documentation”. Поправим его

$ git commit --amend -m “improve documentation”

[example_3.2 ed02c8a] improve documentation
 Date: Sun Dec 6 22:57:22 2020 +0300
 1 file changed, 2 insertions(+)

git log --oneline master..HEAD

ed02c8a (HEAD -> example_3.2) improve documentation
87eaff0 Add more text to README.md
22513de Add README.md file

6) Задача: поменять коммиты местами

Решение: сделать rebase

Итак, у нас опять есть три коммита

$ git log --oneline master..HEAD

98bfce0 (HEAD -> example_6) add footer to Readme.md
9fd509c add header to Readme.md
589ad4d add text to Readme.md

В которых мы меняли один файл.

$ git diff master..HEAD

diff --git a/README.md b/README.md
index e69de29..2c6d4f9 100644
 — — a/README.md
+++ b/README.md
@@ -0,0 +1,7 @@
+# Header
+
+Text. Bla-bla-bla.
+Some text.
+And text, again.
+
+# Footer

Как поменять местами коммиты чтобы сперва в истории было добавление футера (98bfce0), а потом уже хедера (9fd509c)? Для этого делаем интерактивный rebase на 3 коммита назад

$ EDITOR=vim git rebase -i HEAD~3

1 pick 589ad4d add text to Readme.md
2 pick 9fd509c add header to Readme.md
3 pick 98bfce0 add footer to Readme.md

И меняем расположение коммитов

1 pick 589ad4d add text to Readme.md
2 pick 98bfce0 add footer to Readme.md
3 pick 9fd509c add header to Readme.md

Посмотрим что получилось.

$ git diff master..HEAD

diff — git a/README.md b/README.md
index e69de29..2c6d4f9 100644
 — — a/README.md
+++ b/README.md
@@ -0,0 +1,7 @@
+# Header
+
+Text. Bla-bla-bla.
+Some text.
+And text, again.
+
+# Footer

$ git log --oneline master..HEAD

a4e641f (HEAD -> example_6) add header to Readme.md
cf87d0a add footer to Readme.md
589ad4d add text to Readme.md

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

$ git reset --hard HEAD~1

HEAD is now at cf87d0a add footer to Readme.md

$ cat README.md

Text. Bla-bla-bla.
Some text.
And text, again.

# Footer

И взглянем на историю коммитов.

$ git log --oneline master..HEAD

cf87d0a (HEAD -> example_6) add footer to Readme.md
589ad4d add text to Readme.md

7) Отребейзить ветку если родительская ветка была смерджена

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

Решение: Сделать ребейз только нужных коммитов.

От мастера была создана ветка с 2-мя комитами

O - A - B

От этой ветки мы сделали ветку с добавили еще 3 коммита

O - A - B - C - D - E

Первая ветка была смерджена в мастер и вместо 2 коммитов `A — B`, в мастере появился один коммит `F`. Для того чтобы отребейзить нашу ветку от мастера надо отребейзить только уникальные коммиты этой ветки. То есть 3 коммита `C — D — E`. (источник)

git rebase --onto master HEAD~3

Вот и все! Надеюсь что данная статья была полезная 😁

Введение

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

Темные времена

История любой индустрии всегда начинается с темных времен или момента рождения. Применительно к БД мне нравится выражение “темные века”.

Изначально никаких стандартов для БД не было. У каждого компьютера или мейнфрейма была своя имплементация БД. Чаще всего программист не делал в явном виде запрос к данным, а программировал их сам, выделяя для этого память в переменных и сам писал циклы чтобы подгрузить данные или связи.

С 1970-х начался новый тренд, БД представляли собой таблицы в которых была сложена информация. Как в привычном нам Microsoft Excel.

Ренессанс

Смена эпох наступила в 1974 когда IBM впервые представил свою первую имплементацию SQL. SQL менял подход в декларативную сторону и подкупил всех тем что не нужно самому программировать запросы к данных. У программистов уже появился интуитивно понятный интерфейс как это делать. Операторы SELECT и JOIN произвели революцию в своей индустрии. Вот пример запросов на языке SQL.

SELECT first_name, last_name FROM people;

SELECT people.last_name, people.first_name, people.profession_id FROM people INNER JOIN profession ON people.profession_id=profession.id WHERE profession.id = 123;

В 80-х годах SQL стал настоящим стандартном ANSI и ISO под который можно было написать свою систему управления базами данных (СУБД), что запустило эпоху ренессанса в мире БД.

SQL удовлетворял все коммерческие запросы к сохранности и надежности данных: блокировки, транзакции, внешние ключи, проверки на NULL, хранимые процедуры и прочее. Плюс была проделана огромная работа в исследовании, проектировании и работы с реляционными БД, что сделало эту систему стандартом индустрии. Казалось что в базах данных ничего никуда меняться не будет.

Дополнительно надежность SQL была гарантирована схемой данных то есть на данные можно в любой момент посмотреть сверху как на план, как на карту города и схема гарантировала что все данных соответствуют этому плану. Пример: если в схеме написано что в таблице USERS поле FIRST_NAME является строкой и не может содержать NULL, то вариант что у какой-то записи там ничего нет или содержится число попросту не возможен.

Плюсы SQL:

• Накоплен большой опыт проектирования и использования реляционных баз данных
• Надежность хранения данных
• Разнообразные СУБД как имплементации стандарта

Минусы SQL:

• Плохо подходят для сложных поисков по тексту (морфологический/префиксный поиск)
• Плохо подходит для реализации данных которые можно представить как граф

Эпоха модерна

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

До сих пор отношение к NoSQL решениям различные: кто-то считает это все игрушками, а кто-то узкими эффективными инструментами. Рассмотрим для примера несколько БД и поймем в чем их преимущества и минусы: Redis, MongoDB, ElasticSearch и Neo4j.

Дополнительно перед использованием каждой новой NoSQL БД надо было учиться заново т.к. у каждой из них есть свой уникальный язык запросов. Но обычно ORM/ODM имеют похожие интерфейсы.

Redis

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

В Redis хранят данные к которым критически важна скорость доступа, и их не жалко потерять. Пример: данные о сессии, кэш, результаты промежуточных вычислений, очереди задач. Запускать для этих целей инстанс PSQL было бы неэффективно, а отдельная маленькая БД — самое оно.

Еще одно применение это БД — это коммуникация между процессами или доставка уведомлений. В Redis очень хорошо сделан функционал подписки на каналы. Можно моментально уведомить всех что какое-то событие началось, что-то случилось и запустить необходимые операции.

Плюсы:

• Скорость доступа к данным

Минусы:

• Минимальные требования к надежности данным. Обычно Redis держит все данные в ОЗУ не дублируя их на диск, но эту конфигурацию можно легко включить.

MongoDB

Предыдущая БД была представлена как один ассоциативный массив, MongoDB можно представить как массив JSON объектов. Эта парадигма уходит от представления что данные хранятся в таблицах как в MS Excel. С уходом от этого оказалось что схема данных не нужна. Если в SQL схема данных гарантировала целостность, но перед изменением структуры БД приходилось править схему, то тут сами данные максимально гибкие.

MongoDB идеально подходить проектам в которых есть одна (ну максимум две) сущности от которой пляшет весь функционал. Визуально ее можно представить как один массив с кучей данных прямо в нем. Другие таблицы или массивы с данными не нужны так как JSON имеет возможность вложенных данных (по ключу объекта может находится другой JSON-объект).

Эта первая NoSQL БД которая максимально эффективно манипулировала JSON’ом и искала данные в них. Плюс это был максимально простой поиск по данных. Все находится в одном массиве и не надо делать JOIN’ы чтобы собирать данные по таблицам.

Гибкость MongoDB является плюсом для кучи проектов которые только что начинаются, где требования очень туманны и меняются каждую неделя. В таких условиях максимальная гибкость БД и отсутствие схемы является плюсом и дает +10 к скорости внедрения изменений.

Плюсы:

• Максимальная гибкость
• Идеально для обхода древовидных структур данных
• Хорошие возможности по агрегации данных

Минусы:

• Нет гарантий целостности данных. Из-за этого изначально не было плюшек которые давно есть в SQL (транзакции, join’ов и прочего).

ElasticSearch

Эта БД создавалась с одной целью, максимально быстро и эффективно делать поисковые запросы по тексту. Со временем требования к поиску в сервисах усложнялись. Простой поиск по тексту LIKE в SQL не удовлетворял. Пользователей хотели удивить морфологическим и префиксным поиском.

Что такое морфологический поиск? Это поиск по тексту без отвлечения на род и число в языке. Например поиск в котором при введении слова “красный” также ищутся вариации “красная”, “красное”, “красные”. Префиксный поиск — это так называемый поиск с ошибками в котором пользователь может случайно перепутать буквы, но результат будет валидным.

ElasticSearch всегда используют как дополнительную БД в которую дублируются текстовые (иногда не только) данные для поиска по ним.

Плюсы:

• Лучшее решение для реализации морфологического или префиксного поиска

Минусы:

• Лучше не хранить в этой БД данные которые не связаны с поиском.

Neo4j

На мой взгляд одна из самых зрелых NoSQL решений потому что очень хорошо решала задачу с которой у SQL были проблемы. Если задачу по нестандартному поиску по тексту еще можно было как то решить в SQL (добавляя плагины и небольшие хаки), то с графами проблема серьезнее.

Представьте что вам нужно проектировать социальную сеть для студентов. Из функционала:

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

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

Идеальным инструментом будет использование графовых баз данных. В Neo4j также как в MongoDB нет схемы поэтому атрибуты данных можно было добавлять/удалять одним движением. Еще дополнительный плюс — то что атрибуты можно создавать/редактировать и у связей.

Плюсы:

• Все алгоритмы линейной алгебры и теории графов работают максимально эффективно.
• Поиск данных по графам работает быстрее чем в других БД.

Минусы:

• Если структура даных не предоставляет собой граф, то гораздо эффективнее использовать другую БД и не учить новый язык запросов.

Заключение

Закончилась небольшая антология по базам данных. Естественно я не описал весь список NoSQL решений, но описал самые популярные из них. Не смотря на разнообразие NoSQL решений, чаще всего они используются дополнительно как альтернатива узким местам в SQL.

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

Дополнительно: хайп

Упоминая NoSQL невозможно не упомянут в каком инфопотоке они развивались. В индустрию они пришли с хайпом и юношеским максимализмом. Самый громкий из них был MongoDB. Она настолько громко заявляла о своем подходе что только ленивый не хотел ее потрогать.

В итоге полигоном испытаний для новой технологии стали продакшн сервера реальных контор и это время можно описать так:

Это было быстро, модно, молодежно, а с эффективностью и надежностью мы думали что как нибудь потом решиться. В общем “как нибудь” да решилось.

Сейчас эта ситуация породила особое легаси на уровне БД: типо мы в этом продукте до сих пор используем MongoDB потому что так исторически сложилось и проект выстрелил. Переписывать на PSQL очень долго и дорого, а нам надо фичи катить. Поэтому пожалуйста, MongoDB Inc, добавьте нам транзакции и join’ы как в SQL 😇 Факт добавления транзакции, джойнов и схем в MongoDB, как по мне , — показатель что ее юзают на проектах где идеально подходит SQL.

[original post]

Single table inheritance (STI) is useful pattern. It helps organise codebase and split logic into different classes. Many programmers use it and like the pattern, but it has one disadvantage: you can’t preload associations by standard preloadmethod. Now, I show you the way to handle it.

Imagine, you have an Instagram style application where users are able to upload information and create posts. There are different types of post:

• post with one image
• multi images post
• and post with video

You codebase is based by STI pattern

# base class
class Post < ApplicationRecord
end

# standard post with one image
class ImagePost < Post
  has_one :image, dependent: :destroy, foreign_key: :post_id
end

# multi images post
class MultiImagePost < Post
  has_many :images, dependent: :destroy, foreign_key: :post_id
end

# post with video
class VideoPost < Post
  has_one :video, dependent: :destroy, foreign_key: :post_id
end

Also Image class has relation to Asset

class Image < ApplicationRecord
  belongs_to :post, foreign_key: :post_id
  has_one :asset
end

class Asset < ApplicationRecord
  belongs_to :image
end

You have different feeds for each post type, and your application works perfectly.

ImagePost.preload(image: :asset).each do |item|
  render 'image_post', item: item
end

# database queries:
# ImagePost Load (0.8ms)  SELECT "posts".* FROM "posts" WHERE "posts"."type" = ?  [["type", "ImagePost"]]
#  Image Load (1.4ms)  SELECT "images".* FROM "images" WHERE "images"."post_id" IN (?, ?)  [["post_id", 21], ["post_id", 22]]
#  Asset Load (0.9ms)  SELECT "assets".* FROM "assets" WHERE "assets"."image_id" IN (?, ?)  [["image_id", 5], ["image_id", 6]]

MultiImagePost.preload(images: :asset).each do |item|
  render 'multi_image_post', item: item
end

# database queries:
# MultiImagePost Load (0.7ms)  SELECT "posts".* FROM "posts" WHERE "posts"."type" = ?  [["type", "MultiImagePost"]]
# Image Load (1.1ms)  SELECT "images".* FROM "images" WHERE "images"."post_id" IN (?, ?)  [["post_id", 20], ["post_id", 25]]
# Asset Load (1.0ms)  SELECT "assets".* FROM "assets" WHERE "assets"."image_id" IN (?, ?, ?, ?)  [["image_id", 3], ["image_id", 4], ["image_id", 7], ["image_id", 8]]

VideoPost.preload(:video).each do |item|
  render 'video_post', item: item
end

# database queries:
# VideoPost Load (0.9ms)  SELECT "posts".* FROM "posts" WHERE "posts"."type" = ?  [["type", "VideoPost"]]
# Video Load (0.9ms)  SELECT "videos".* FROM "videos" WHERE "videos"."post_id" IN (?, ?)  [["post_id", 23], ["post_id", 24]]

The other day, a customer asked you to render all types of post in one feed. But there is one problem: you can’t use standard preload

ActiveRecord::AssociationNotFoundError (Association named 'image' was not found on MultiImagePost; perhaps you misspelled it?)

What should you do? You can write your custom preload logic for new feed using ActiveRecord::Associations::Preloader You should create new instance of the class and then use preloadmethod. It takes two parameters:
* collection of AR-items
* hash with relations that you want to preload.
The code doesn’t look like rails-magic and you have to describe all relations explicitly, but it works perfectly.

posts = Post.all
preloader = ActiveRecord::Associations::Preloader.new
    preloader.preload(posts.select{ |i| i.type == 'ImagePost' }, image: :asset)
preloader.preload(posts.select{ |i| i.type == 'MultiImagePost' }, images: :asset)
preloader.preload(posts.select{ |i| i.type == 'VideoPost' }, :video)

posts.each |item|
  render 'post', item: item
end

Look into logs, Preloader sends one query for each association, and you there aren’t N+1 queries

# 1) take posts from DB
Post Load (0.4ms)  SELECT "posts".* FROM "posts"
# 2) load images for all ImagePosts
Image Load (1.5ms)  SELECT "images".* FROM "images" WHERE "images"."post_id" IN (?, ?)  [["post_id", 21], ["post_id", 22]]
# 3) load assets for them
Asset Load (1.0ms)  SELECT "assets".* FROM "assets" WHERE "assets"."image_id" IN (?, ?)  [["image_id", 5], ["image_id", 6]]
# 4) load images for all MultiImagePost
Image Load (0.4ms)  SELECT "images".* FROM "images" WHERE "images"."post_id" IN (?, ?)  [["post_id", 20], ["post_id", 25]]
# 4) load assets for them
Asset Load (0.2ms)  SELECT "assets".* FROM "assets" WHERE "assets"."image_id" IN (?, ?, ?, ?)  [["image_id", 3], ["image_id", 4], ["image_id", 7], ["image_id", 8]]
# 5) load videos for all VideoPosts
Video Load (0.4ms)  SELECT "videos".* FROM "videos" WHERE "videos"."post_id" IN (?, ?)  [["post_id", 23], ["post_id", 24]]

В моем предыдущем посте я так нахваливал jQuery что у читателя мог возникнуть вопрос “Почему тогда большие приложения пишутся на react, vuejs и других инструментов?”

Да, jQuery сдал позиции другим библиотекам и на это есть две причины:

• Пришла эпоха SPA (single page application)
• Победа декларативной парадигмы программирования

Почему пришла эпоха SPA ?

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

И однажды появилась идея 💡:

• Почему бы не прекратить рендерить страницу каждый раз заново, а пусть лучше веб-клиент отправляет post-запрос на сервер, получает результат и меняет данные там где нужно 🤔
• Пусть на сайте новостей при клике на новость не перерисовывается вся страница, а отправляется GET-запрос на сервер. Клиент получает заголовок, текст и заменяет данные 🤔
• Пусть клиент всего один раз загружает весь html, css и js а дальше обменивается с сервером только необходимыми данными. 🤔

Это же удобно! 😃

Были небольшие эксперименты но, они были не настолько удачными чтобы стать массовыми. Backbonejs показал что классический ООП-подход плохо ложиться на функционал в браузере клиента.

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

Первая хорошая реализация стала Angular/Ember.js 🤓. Но это был полноценный фреймворк. На нем с нуля надо было писать приложения и процесс обучения занимал много времени.

После этого стартовал react. 😎 Его киллер фича была в том что react — это библиотека и он продвигал функциональный подход. Его можно было просто встроить в проект в виде небольшого функционала (чатик, калькулятор или прочее).

SPA сперва был прекрасен только для приложений и админок. Но потихоньку пришел server site rendering (SSR) и при помощи SPA можно было спокойно пилить любой медиа-ресурс.

Позже маркетологи все это увидели и сказали: “Да с помощью технологии SPA мы можем бесконечный скролл реализовать!!! И вставить кучу рекламы между статьями!” 💵💵💵💵💵

Победа декларативной парадигмы программирования

Чем конкретно хороши эти инструменты для разработчика? Тем что не надо в явном виде ковыряться в DOM! Это реально очень удобный подход, объясню на примере vuejs:

• Сверстал компонент
• Разметил куда должны попадать данные из store
• Навесил события на кнопочки и переключатели (остальное за тебя сделал two-way data binding)
• Описал сериализацию данных перед отправкой на бэк и описал как данные с бека попадают в store
• Все! После этого все работает!

Ты описываешь data-flow (и иногда немного допиливаешь его напильником). А то как в явном виде передаются данные за тебя делает библиотека. Это была победа декларативного подхода в программировании! 👏

Vuejs — показал каким может быть реально удобный cli, как просто поднять проект и что для SPA нужно всего три либы: vue, vuex, vue-router (ну и Axios иногда 😅 ).

Работая с vuejs невозможно подумать что работа с формами может быть сложной (привет, react). Все это облегчило написание больших приложений, но и снизило входной порог в профессию.

Мир дальше углубился в разделение труда

Я, как backend разработчик, счастлив таким положением дел. Моя работа:

• Получил от клиента http-запрос
• Взял данные из БД
• Положил их в json и отправил назад

Каждый в команде занимается своим делом. Фронты верстают, пишут js-код, вставляют данные в красивую верстку. Сейчас осталось мало мест где для правок дизайна проекта, фронту надо поднимать монолит искать где тут вьюхи чтобы их править. Backend программистам не надо ковырять html. Все разработчики занимаются своим любимым делом ❤️

React плох, но он набрал критическую массу

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

Это тоже самое как во время всеобщей пандемии и самоизоляции люди продолжают использовать zoom, в котором большие проблемы с безопасностью. Просто все к нему привыкли и проще написать коллеге “давай созвонимся в zoom?” и получить положительный ответ чем “давай созвонимся в skype”.

Так чем плох реакт? 🤔 А тем что эта библиотека до сих пор заставляет разработчиков плакать если на нем писать большие приложения 😭

• Плохая реализация tree-shaking. Хочется как можно быстрее отдать клиенту его бандл чтобы он был как можно быстрее счастлив, но нет (вы проверяли сколько весит ваш hello world на react?)
• Работа с формами — это боль 🤦‍♀️
• Сложность экосистемы и ее многословность. Берем стандартный react стек: react, redux, redux form, redux-saga и прочее. И я вспоминаю, как раньше шутили о джаве: “Взял одно, другое, склеил первое, второе, третье, написал конфиг. В итоге ты поднял простенький hello world, но выглядит это как enterprise решение для малого бизнеса.”
• Один паттер проектирования — компоненты высшего порядка, который очень плохо заходит новичкам. Плюс при разработке оказывается что в погоне за этой архитектурой начинается куча проблем. Мы обнаруживаем что одни обертки высших порядков зависят от других; что их надо не забыть перечислять в правильном порядке; что писать типы для компонентов высшего порядка либо боль, либо сложно, либо неэффективно.
• Нет одной каноничной жесткой архитектуры с необходимыми абстракциями из коробки. В компонентах очень легко смешать логику и представление в беспорядочную мешанину. Из-за этого большие приложения легко и непреднамеренно превращаются в месиво кода.
• Где конфигурация для create-react-app? И почему это не может быть в react-cli из коробки? После vuejs это все выглядит очень дико.

Хоть мне и очень нравиться подход в vuejs, но никто в здравом уме не будет переписывать работающий большой проект с react на vuejs или ember. Это неадекватно с точки зрения затраты сил и ресурсов.

А что с jQuery?

Он просто работал и не пытался играть в гонку с другими js-библиотеками. jQuery идеальная для того что бы найти нужные элементы в DOM. Да, это просто либа, и она не дает какой либо каркас приложения но в то время это было не нужно.

И тут эпоха SPA заявила: «В DOM мы руками больше не лезем! Это сложно, медленно и от этого на проекте куча багов!»

Поэтому jQuery так и остался либой для работы с DOM, так как никому не пришла в голову идея доработать его для SPA:

• Взять уже готовый handlebars.js для html-шаблонов
• Написать с нуля store
• Функционал для http-запросов уже есть из коробки (даже в документации react написано что для http-запросов хорошо подходит jQuery)
• Написать роутер
• Реализовать необходимый функционал для two-way data binding

То есть инструмент похожий на vuejs мог появится раньше, но с нативной поддержкой http-запросов из коробки. А еще бы добавить к этому create_app как во vue cli и поддержку coffeescript из коробки 😍 Ваще красота) 🔥

Вот так этот старичок оказался преданным своему делу, но потерял позиции перед другими инструментами. Но не все так плохо, он все еще остался хорош для парсинга сайтов: удобный api для http-запросов и самый простой интерфейс для ковырянии в DOM’е 👨‍💻

(The Write Less, Do More)

Первый релиз jQuery был 26 августа 2006 (13 лет назад). Но почему мы все еще в 2020 обсуждаем эту библиотеку?

jQuery — это живая легенда веба и на это есть три причины:

• Удобство
• Стабильность
• Эпоха

У — удобство

Библиотека подключалась одной строчкой с любого CDN

<script src="https://code.jquery.com/jquery-3.5.0.min.js"></script>

Для разработки достаточно было всего одной либы. В ней есть все необходимое для работы с DOM, анимацей и ajax-запросами. Плюс у нее всегда была очень подробная документация. Эта библиотека показала насколько удобной может быть работа с ajax-запросами и что работать с ними может каждый. (для молодых: fetch появился в js только с Chrome 42)

Она показала как крут chaining еще до изобретения промисов 😅. Вот такую красоту мог использовать любой и спокойно работать с элементами как с объектами.

$("#p1")
  .css("color", "red")
  .slideUp(2000)
  .slideDown(2000);

$( "ul.first" )
  .find( ".foo" )
    .css( "background-color", "red" )
  .end()
  .find( ".bar" )
    .css( "background-color", "green" );

jQuery была настолько удобной что разработчики забывали ванильный js. Многим людям для того что бы переквалифицироваться из верстальщика в разработчика было достаточно за пару выходных изучить api jQuery. По этой причине в 2014 году появился сайт youmightnotneedjquery.com

Счастье разработчика не ограничивалось одним core-функционалом. Было и есть огромное количество плагинов для разнообразных операций (вплоть до математических 🤪).

С — стабильность

Было время когда еще не было никаких менеджеров пакетов типо npm или yarn, но и не было проблем с установкой и управлением зависимостями. В гугле без труда можно было найти плагины на любую задачу. Каждый плагин был написан энтузиастом всего один раз и просто работал!

Люди находили плагины в гугле (привет, ruseller.com) или на страницах stackoverflow и просто подключали его к себе на сайт. Крафтовость разработки — 80-й уровень 🧔😎
Не важно когда плагин был написан, он работал стабильно.
Все аккордеоны, тоглы, табы, простенькие модальные окна работали без постоянных патчей и багфиксов.

Но даже если версия jQuery на сайте отличалась от версии которая нужна была для правильной работы плагина, то внутри некоторых плагинов был уже встроенный “no conflict mode”. Изнутри плагина запускалась нужная версия jQuery, а на сайте, в глобальном пространстве имен, разработчик спокойно использовал нужную ему версию jQuery.
Еще был надежный функционал jQuery.noConflict() который освобождал переменную $ для других библиотек 😻.

Бывало я и сам для себя писал плагинчики для jQuery 😀

Либа до сих пор поддерживается на github! https://github.com/jquery/jquery/commits/master А сколько вы знаете фронтовых либ которые поддерживаются 13 лет к ряду?!

Э — эпоха

jQuery — это эпоха которая еще не прошла. Разработчики до сих пор любят и используют jQuery ❤️.

Bootstrap только в феврале 2019-го смог избавиться от jQuery в своем коде, но каких усилий и временных затрат им это стоило. https://github.com/twbs/bootstrap/pull/23586

В статистике npm по jQuery вы можете увидеть 3,504,030 weekly downloads, и это в 2К20! https://www.npmjs.com/package/jquery

jQuery до сих пор часть таких известных библиотек как:
https://www.npmjs.com/package/bootstrap-datepicker
https://www.npmjs.com/package/owl.carousel

Даже используя jQuery сейчас не приходиться думать про поддержку старых браузеров. Подключаешь jQuery 1.12 и твой ламповый сайтик работает на всех старых браузеров.

Резюмируя.

Для многих олдов jQuery — это как первая машина! 🚙
Спустя десять лет человек может купить себе две BMW, но в душе он всегда помнит свою первую четырку которая просто работала и ни разу его не подводила 😊

До сих пор в 2020 году, если тебе нужно написать небольшое приложение, то бывает проще заюзать jQuery чем поднимать create-react-app

Metaprogramming is writing code that manipulates language constructs at runtime. It is an essential component of Ruby, and you can use it to remove duplication in your code and write elegant, beautiful programs.

Metaprogramming is always interesting to me. I have had experience with it, but I still had questions about it. One of my colleagues recommended me to read the book. After that, I have found answers to all my questions. Therefore I highly recommend it everyone who wants to learn more about metaprogramming.

By reading the book, you will be able to learn new by one week. You will be able to understand new constructions, and you will see a lot of code examples (in plain Ruby and code in popular gems):

• how to create new methods in runtime with method_missing and respond_to_missing
• defining new methods in runtime with define_method construction
• how to pass constant by const_missing
• new way to create classes dynamically
• learn more about metaprogramming in ActiveRecords
• monkey patching and how to add a method to a class dynamically
• and you will reach the whole power of DSL (domain-specific language)

Example:

xml.instruct! :xml, :version => "1.0"
xml.rss :version => "2.0" do
  xml.channel do
    xml.title "My Company Blog1"
    xml.description "This is a blog by My Company"
    xml.link '/'
    @topics.each do |i|
      xml.item do
        xml.title i.title
        xml.subtitle i.subtitle
        xml.description i.description
        xml.big_text i.big_text
        xml.rubric_id i.rubric_id
        xml.tag_id i.tag_id
        xml.publication_at i.publication_at
        xml.one_more_time i.one_more_time
      end
    end
  end
end

It is absolutely standard xml view for all RSS feeds in Rails. I began an experiment to rewrite it from xml.bulder to xml.erb and it made render faster. For my app, it made it twice as fast as before.

Example:

<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
  <title><%= 'My Company Blog1' %></title>
  <description><%= 'This is a blog by My Company' %></description>
  <link><%= '/' %></link>
  <% @topics.each do |i| %>
    <item>
      <title><%= i.title %></title>
      <subtitle><%= i.subtitle %></subtitle>
      <description><%= i.description %></description>
      <big_text><%= i.big_text %></big_text>
      <rubric_id><%= i.rubric_id %></rubric_id>
      <tag_id><%= i.tag_id %></tag_id>
      <publication_at><%= i.publication_at %></publication_at>
      <one_more_time><%= i.one_more_time %></one_more_time>
    </item>
  <% end %>
</channel>
</rss>

Almost the same result we can reach to replace gem builder by ox (the fastest optimized XML parser and generator). But, unfortunately, it has quirky syntax and we don’t have action_view’s template out the box.

In conclusion, there is an easy way to decrease rss response time. I prepared a test application in order to check it out and uploaded it to Github. There is the link to test application with the result — github.