The document discusses best practices for using RSpec, a testing library for Ruby projects. It provides examples of good and bad ways to write RSpec tests and describes techniques like using contexts and shared examples to organize tests and DRY up code. The document emphasizes testing edge cases, mocking only when needed, creating data dynamically in tests rather than using fixtures, and following practices like describing methods under test and having single-expectation tests. It encourages starting to use RSpec and provides contact information for the author to learn more.
The document discusses best practices for using RSpec, a testing library for Ruby projects. It provides examples of good and bad ways to write RSpec tests and describes techniques like using contexts and shared examples to organize tests and DRY up code. The document emphasizes testing edge cases, mocking only when needed, creating data dynamically in tests rather than using fixtures, and following practices like describing methods under test and having single-expectation tests. It encourages starting to use RSpec and provides contact information for the author to learn more.
Solit 2014, Минусы ООП на примере языка PHP, Соловей Василийsolit
Василий Соловей, Солигорск. PHP-разработчик в в «Электронном Солигорске».
«Минусы ООП на примере языка PHP». Development секция. Для разработчиков (начальный и средний уровень).
1. Что есть ООП (легкое повторение уже знакомого)
2. Лучше доверять авторитету мнения, чем мнению авторитета (во всем нужно разбираться основательно, а в ООП тем более)
3. Неизменная скупость в похвалах — верный признак посредственного ума (плюсы ООП)
4. Не все то солнышко, что блестит (основная часть доклада – минусы ООП)
5. Кто владеет информацией, тот владеет ситуацией (пояснение сути доклада:
доклад не принижает и не умоляет достоинств ООП он создан расширить кругозор)
«Начинать никогда не поздно!». Мотивационное выступление. На личном примере, я могу рассказать, что начинать никогда не поздно, и если есть желание – нет повода себе отказывать.
1. Путь в тысячу миль начинается с одного шага (с чего начать)
2. И на верном пути повстречаются распутья (как не сбиться с дороги начав)
3. Кто ты программист? (мой взгляд на программирование)
4. Успех – дитя настойчивости
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
Архитектура кода нового 2ГИС Web API или куда мы дели MVCDevDay
Сергей Коржнев
Архитектор версии 1.4 2ГИС Web API
Архитектура кода нового 2ГИС Web API или куда мы дели MVC
Тезисы:
● Как организован код в старой версии.
● Вдумчиво смотрим, как мы используем Yii, хватаемся за голову и клавиатуру. Там отрезаем, тут пришиваем, и вуаля!
● Ну и делаем выводы, как мы забороли две классические проблемы программирования: борьба с дублированием кода и сложностью системы.
D2D Pizza JS Илья Беда "Куда мы все катимся?"Dev2Dev
Окружение JavaScript, наверно, самая быстроразвивающаяся отрасль в мире разработки программного обеспечения. Все слышали шутку про книгу “36 новых JavaScript фреймворков, выпущенных в марте”, и это не далеко от правды.
В своем обзорном докладе я расскажу о своем пути во frontend. О том, как вижу современную индустрию, о существующих проблемах и путях их решения. Все не так уж радужно, как может показаться. Надеюсь, мой доклад позволит вам взглянуть на мир JavaScript с другой стороны или, по крайней мере, задуматься о том, в правильном ли направлении вы движетесь?
Доклад с конференции D2D Pizza JS - http://dev2dev.ru/events/8/
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
Юлия Ковалёва. Fscheck — альтернативный путь для unit тестовMskDotNet Community
Как помочь тестам находить баги? Что лучше: каждый новый запуск на новом наборе данных или же стабильность? Как сделать тестовые данные эффективными?
В докладе рассматривается Property based подход для написания unit-тестов.
На реальных примерах будет показано то, какими возможностями обладает FsCheck в связке с C#, какие есть плюсы и минусы у данного инструмента и стоит ли тратить время на его изучение.
This document discusses how to break bad habits by using GitLab CI to automate routine tasks. It provides examples of automating tests, packaging code, and deploying artifacts and websites. Specifically, it shows how to:
1. Run automated tests with GitLab CI
2. Package code into downloadable artifacts
3. Deploy packages and websites to AWS S3 and GitLab Pages
4. Separate testing and production using environments
5. Allow multiple developers to work on the same project simultaneously
6. Avoid mistakes by not deploying directly to production
This document discusses common problems that arise when developing Ruby on Rails applications. It argues that Rails principles like DRY, KISS, and fat models/skinny controllers are often misunderstood and misapplied. This leads to complexity over time as applications grow. The document recommends approaches like SOLID principles, design patterns, refactoring techniques, and separating business logic from controllers to help address these problems.
More Related Content
Similar to Рефакторинг rails-приложения. С чего начать?
Solit 2014, Минусы ООП на примере языка PHP, Соловей Василийsolit
Василий Соловей, Солигорск. PHP-разработчик в в «Электронном Солигорске».
«Минусы ООП на примере языка PHP». Development секция. Для разработчиков (начальный и средний уровень).
1. Что есть ООП (легкое повторение уже знакомого)
2. Лучше доверять авторитету мнения, чем мнению авторитета (во всем нужно разбираться основательно, а в ООП тем более)
3. Неизменная скупость в похвалах — верный признак посредственного ума (плюсы ООП)
4. Не все то солнышко, что блестит (основная часть доклада – минусы ООП)
5. Кто владеет информацией, тот владеет ситуацией (пояснение сути доклада:
доклад не принижает и не умоляет достоинств ООП он создан расширить кругозор)
«Начинать никогда не поздно!». Мотивационное выступление. На личном примере, я могу рассказать, что начинать никогда не поздно, и если есть желание – нет повода себе отказывать.
1. Путь в тысячу миль начинается с одного шага (с чего начать)
2. И на верном пути повстречаются распутья (как не сбиться с дороги начав)
3. Кто ты программист? (мой взгляд на программирование)
4. Успех – дитя настойчивости
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
Архитектура кода нового 2ГИС Web API или куда мы дели MVCDevDay
Сергей Коржнев
Архитектор версии 1.4 2ГИС Web API
Архитектура кода нового 2ГИС Web API или куда мы дели MVC
Тезисы:
● Как организован код в старой версии.
● Вдумчиво смотрим, как мы используем Yii, хватаемся за голову и клавиатуру. Там отрезаем, тут пришиваем, и вуаля!
● Ну и делаем выводы, как мы забороли две классические проблемы программирования: борьба с дублированием кода и сложностью системы.
D2D Pizza JS Илья Беда "Куда мы все катимся?"Dev2Dev
Окружение JavaScript, наверно, самая быстроразвивающаяся отрасль в мире разработки программного обеспечения. Все слышали шутку про книгу “36 новых JavaScript фреймворков, выпущенных в марте”, и это не далеко от правды.
В своем обзорном докладе я расскажу о своем пути во frontend. О том, как вижу современную индустрию, о существующих проблемах и путях их решения. Все не так уж радужно, как может показаться. Надеюсь, мой доклад позволит вам взглянуть на мир JavaScript с другой стороны или, по крайней мере, задуматься о том, в правильном ли направлении вы движетесь?
Доклад с конференции D2D Pizza JS - http://dev2dev.ru/events/8/
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
Юлия Ковалёва. Fscheck — альтернативный путь для unit тестовMskDotNet Community
Как помочь тестам находить баги? Что лучше: каждый новый запуск на новом наборе данных или же стабильность? Как сделать тестовые данные эффективными?
В докладе рассматривается Property based подход для написания unit-тестов.
На реальных примерах будет показано то, какими возможностями обладает FsCheck в связке с C#, какие есть плюсы и минусы у данного инструмента и стоит ли тратить время на его изучение.
This document discusses how to break bad habits by using GitLab CI to automate routine tasks. It provides examples of automating tests, packaging code, and deploying artifacts and websites. Specifically, it shows how to:
1. Run automated tests with GitLab CI
2. Package code into downloadable artifacts
3. Deploy packages and websites to AWS S3 and GitLab Pages
4. Separate testing and production using environments
5. Allow multiple developers to work on the same project simultaneously
6. Avoid mistakes by not deploying directly to production
This document discusses common problems that arise when developing Ruby on Rails applications. It argues that Rails principles like DRY, KISS, and fat models/skinny controllers are often misunderstood and misapplied. This leads to complexity over time as applications grow. The document recommends approaches like SOLID principles, design patterns, refactoring techniques, and separating business logic from controllers to help address these problems.
What I Have Learned from Organizing Remote Internship for Ruby developersIvan Nemytchenko
This document describes a remote internship opportunity for Ruby developers. Interns would work on a portfolio project for 20 hours per week minimum, gaining experience with the full development cycle, teamwork, and remote work. Applicants would take an aptitude test assessing their skills with requirements like user registration, permissions, and integrating with external APIs. Successful interns would work independently on assigned features while receiving guidance from mentors. Lessons from past internship programs are discussed, like the need for clearer communication and ensuring interns have enough support to avoid burnout.
1. The document discusses using GitLab CI to automate software development tasks like testing, packaging, and deployment.
2. It provides examples of configuring GitLab CI pipelines to run tests, package code as gzip and ISO files, and deploy artifacts to S3 storage and GitLab pages.
3. The document also covers more advanced topics like using environments to separate staging and production, enabling manual deployment for production, and automatically deploying feature branches to separate review environments.
A document lists several cities and dates for Lean Poker events in Eastern Europe and Russia, including events in Belgrade, Omsk, Moscow, and Lviv on March 26th with event websites provided.
How to use any static site generator with GitLab Pages. Ivan Nemytchenko
It is possible to delegate all the routine work of static site generation to GitLab Pages. It is possible because of built-in CI service.
March, 19 2016, Kiev, Ruby Meditation
At the early days, Rails community accepted few principles unconditionally because they sound like axioms.
People use principles and acronyms to compress meanings. By doing so, there's a risk for them to be misunderstood. And I think this is exactly what's happened to with some people in Rails community.
So let's try to decompress them, and see what might be wrong with our understanding.
It is common for rails-teams to stuck at some point. It happens when team doesn't try to manage complexity of their app.
In this talk I demonstrated my path from a Rails-application to somewhat modular architecture app: things like Form Objects, Repositories, Entities etc. emerged naturally, as a solutions for existing problems, not because we were told by someone to use them.
March 15, Wroclaw, wroc_love.rb 2015
Different approaches to ruby web applications architectureIvan Nemytchenko
This document discusses different ways to organize Ruby code, including code organization styles used in Semaphore, various Ruby libraries like Lotus and Chassis, and resources for learning about design patterns from authors like Sandi Metz and Avdi Grimm. It also provides contact information for the presenter to discuss code examples.
- The document discusses moving away from the traditional "rails way" architecture to a more modular architecture for a Rails application.
- It describes splitting the application into separate frontend (AngularJS) and backend (Rails API) components. The Rails backend is refactored using patterns like entities, repositories, and presenters to separate concerns and improve testability/reusability.
- Examples demonstrate implementing validation modules, form objects, service classes, and separating domain logic from data access using a repository pattern with the Sequel ORM rather than ActiveRecord. This leads to a cleaner architecture.
This document provides an overview of ActiveRecord and Mongoid object document mappers for Ruby on Rails applications. It describes MongoDB as a scalable and high-performance NoSQL database without transactions or joins. It explains how Mongoid provides a similar API to ActiveRecord but is designed for MongoDB's schemaless and document-based data model. Various Mongoid associations like embeds_many and embedded_in are demonstrated through code examples. Additional MongoDB features through Mongoid like localization, GridFS for file storage, and hybrid ActiveRecord/Mongoid applications are also briefly covered.
14. module UseCases::Samples
class UseCase
def initialize(initiator, project_id)
@initiator = initiator
@project_id = project_id
end
def run(input_data)
some_really_complex_stuff_here do |data|
b = bla(data)
c = blabla(project_id, data, b)
bla!(initiator, project_id, c)
end
end
private
attr_accessor :initiator, :project_id
def project
@project ||= Project.find_by_id(project_id)
end
end
end
