Эффективное внедрение зависимостей при масштабировании Ruby-приложений

Но зачем нужна зависимость в Rails Action? Хотя для этих случаев есть before_action callbacks.

Эффективное внедрение зависимостей при масштабировании Ruby-приложений

Похоже, что слишком много «если» :)

Эффективное внедрение зависимостей при масштабировании Ruby-приложений

Мне кажется, что первый пример с явной передачей в конструктор зависимостей на много приятнее читать, понятнее и не подразумевает под собой лишних вопросов в духе: «ой, а как это у нас эта переменная появилась с объектом».

Рецепты тестирования Ruby и Rails приложений

3. .to be проверяет просто наличие инстанса

expect('').to be

например выдаст true, так что в этом случае лучше все же проверить значение через .to be_truthy

Рецепты тестирования Ruby и Rails приложений

1. Это же Ruby, тут можно опускать скобочки и будет красивее
вместо

super().merge!(name: '')

можно писать

super.merge!(name: '')

2. should уже давно не рекомендуют использовать, тем более не красиво смешивать вместе с expect

In version 2.11 expect method was introduced which is now the recommended way to define expectations on an object.

github.com/rspec/rspec-expectations/blob/master/Should.md

3. Стоит использовать встроенные проверки
вместо

is_expected.to eq true

можно

is_expected.to be_truthy

4. К полезным мелочам я бы еще добавил в .rspec

--format documentation

очень приятная мелочь при выводе сообщений

Рецепты тестирования Ruby и Rails приложений

Все давно есть github.com/grosser/parallel_tests и отлично работает.

Ruby On Rails и взаимодействие с REST Qiwi Shop

Все смешалось: люди, кони…

По хорошему вам нужен code review, чтобыразбить все на отдельные сервис классы хотя бы:

— RestClient вынести в отдельный класс, посмотреть может быть хорошо бы подошел Her.
— STATUSES в модели это или state machine или хотя бы enum
— create_bill станет намного короче, если все эти валидации, создание платежей раскидаются по логическим классам, а не такая портянка
— константы лучше в ENV закинуть
— Код в духе

   flash[:error] = 'Невалидные данные'
      redirect_to action: :pay
      return

можо в одну строку написать

   return redirect_to action: :pay, error: t('.invalid_data')

Социальная сеть на Android за несколько выходных — часть I (клиент)

серверный код просто ужасен, нет тестов, не свежий Rails 4.1.1 и ужасно пахнет (константы в моделях, хотя можно enum, as_jsonn с двумя nn) все от моделей до контроллеров, не надо так!

Не совсем крутой Ruby

С 2.2 кстати можно уже и символы поручить GC на сборку, живем!

Не совсем крутой Ruby

Еще раз, сиволы это очень полезный инструмент из мира функционального программирования, то что вам кажется глупостью, помогает всем остальным работать с языком и получать нужные результаты. Если вы не видите разницы между строкой и символом поизучайте вопрос его практического приминения, например в сети — www.randomhacks.net/2007/01/20/13-ways-of-looking-at-a-ruby-symbol

Не совсем крутой Ruby

Символы это не новый тип данных, если только лично для вас, а в остальном это наследие FP и Lisp (создан в 1958 году)

Ruby Together – фонд развития языка Ruby

«40$ в месяц», хм, знаете ли я нищеброд :)

Уходящая эпоха голосовой связи

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

Уходящая эпоха голосовой связи

Не будете вы же своего начальника, клиента или например партнера исключать из числа своих контактов каждый раз :)

Уходящая эпоха голосовой связи

Основная проблема диалога голосом и голосовых сообщений, что потом не найти концы. Кто и что сказал, почему было сделано именно так.
А текст вот он, бери, доказывай.

Создавайте продукты, формируйте привычки. Интервью с Ниром Эйялем

Я конечно понимаю это ваш блог, но возьмите из статьи слово «продукт» и «улучшать жизнь людей», у вас документация дичайшим образом оформлена и неудобна. А еще бы не помешало иметь сразу готовые коннекторы на разных языках к API.

Что лучше для стартапа: Вьетнам или Таиланд?

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

Что лучше для стартапа: Вьетнам или Таиланд?

В Таиланде как раз таки тайские кафе — это обычные, а вы ходите напротив в необычные, farang food рестораны :)

Что лучше для стартапа: Вьетнам или Таиланд?

Я жил на севере Таиланда (в Чиангмае) 1.5 года, даже в офис ездил каждый день. Да жить можно, но везде и свои плюсы и минусы, кому-то в речке купаться претит, если рядом есть море.

Что лучше для стартапа: Вьетнам или Таиланд?

Паттаю я упомянул в контексте «самые популярные направления», на Пхукет я думаю тоже едут «отдыхать», тут вообще можно везде или отдыхать или работать, тут уж выбор человека самостоятельный.