We don’t have to tell you that the world of technology is an ever-evolving landscape of ideas and concepts, and that even when you have a firm intellectual grasp of a technology this knowledge can quickly become outdated. With this in mind, we thought we’d readdress one of our blog posts from 2015 with a fresh, 2018 perspective.
Design patterns are solutions to software design problems that are presented in an almost conceptual way. That is to say, a given design pattern has the potential to be applied to a piece of software written in any number of languages but, at a code level, it’s up to the developer to interpret that idea and make it work for them.
Here at Made Tech we’re big fans of Ruby and use Ruby on Rails for most of our web applications. Over the years we’ve had countless conversations about the pros and cons of Ruby.
We’re very excited and proud to announce that we have been named as a leading provider in Clutch.co’s list of Top Ruby on Rails Development Firms, and that we’re the only company in the UK to have been given that accolade!
Spree makes it easy to take payments from any Payment Service Provider, and in this post I will briefly walk you through the process of creating and using your own custom gateway.
I’ve been writing software on my own for years, but one of my biggest challenges since starting at Made has been learning how to work in a team and get up to speed with huge, alien codebases in a short amount of time.
If you write code you write bugs. It is a fact of life as a developer. The more code you write, the more complicated it gets and the more likely it will contain bugs. Consider this logic:
You should always prefer to create complex data structures over complex program logic. In fact, making complex data structures that are intelligent will eliminate the need for complex program logic. This will lead to a more robust system that’s easier to reason about and has less code to maintain.
We’ve discussed using Concerns and Services to keep your ActiveRecords as healthy as they can be. These have dealt with repeated logic in models, and logic that could questionably be placed in either a controller or model. In the third and final part of this series we will be looking at presenters.
Continuing from my previous post, which introduced the idea of concerns to your models, in this post I will be discussing using services to keep your ActiveRecord’s responsibilities toned down.