My talk from Full Stack Toronto, called “Rails, Postgres, Angular, and Bootstrap - The Power Stack” is up, where I make the case for using not just using a CSS framework, an MVC framework, a middleware framework, and an amazing database, but for using Bootstrap, Angular, Rails, and Postgres and using them together.
Today through next Tuesday, all three of my books are on sale for 40% off, with the code turkeysale2015:
- Rails, Angular, Postgres, Bootstrap: Powerful, Effective, Efficient Full-stack Web Development ($14.40 for the beta ebook!)
- The Senior Software Engineer: 11 Practices of an Effective Technical Leader ($15!)
- Build Awesome Command-Line Applications with Ruby 2 ($13.20 for the ebook!)
Just use code turkeysale2015 at checkout to get 40% off!
Before using Postgres, I would have to rely heavily on Rails validations to ensure data integrity—MySQL simply doesn't provide the tools
to do this. This always felt wrong. Outside of rogue processes connecting to the database, there's also application bugs
and, well, the ActiveRecord API itself:
update_attribute skips validation! That means it's hard to rely on Rails validations for data
integrity, but there isn't a great alternative for creating a great user experience.
Postgres has the answer: check constraints. As we'll see, check constraints are tool for data integrity and work much better than Rails validations. But Rails validations are still a great tool for user experience.
The latest edition of PragPub is out, featuring an article I wrote on embracing the full stack. This is more of a motivator for why you should be more well-rounded as a developer (which then should motivate you to buy my new book :). I cover things from grid-based design to database indexes.
This may seem like an immense amount of learning and work, but it hopefully feels more achievable now. You could get a cursory understanding of these topics in a week. What happens when you do is that you start to take a more holistic view of your application and of how to build features.
Pick up your copy here
With this set of conventions, it was important that developers not feel these were optional features they could leave out to cut corners, so it seemed logical to make it as painless as possible to follow them. The result is stitches, which works as a generator and backing library. It's not an engine or a DSL or anything complex. It's just a bit of Rails configuration, designed to be explicit and obvious.
As a Rails developer, you care about user experience and performance, but you also want simple and maintainable code. Achieve all that by embracing the full stack of web development, from styling with Twitter Bootstrap, building an interactive user interface with AngularJS, to storing data quickly and reliably in PostgreSQL. Take a holistic view of full-stack development to create usable, high-performing applications, and learn to use these technologies effectively in a Ruby on Rails environment.
I've been working on this for quite a while, and pretty excited about it. If you want to really level up your abilities as a Rails developer, this is the book for you.
In September 2011, I interviewed at Instagram. While I didn't ultimately get/take the job1, the experience had a pretty profound effect on me as a developer.
What I learned during the interview process (which was really enjoyable, and became the basis for my ideal technical interview process) was just how much two engineers with relatively little experience could accomplish.
A tenet of design is that things that are the same should be obviously the same, and things that are different should be obviously different. This is the most basic way to create consonance and contrast, and is a great rule of thumb when designing anything. While Rails diverges from this in an annoying way1, Angular diverges in a baffling way that makes explaining it to a newcomer head-scratchingly difficult.
I haven't been good at blogging for a while. Most of my writing has been toward a new book (details forthcoming), but I did manage to write up how I see designing service objects for Rails applications over at Stitch Fix's Eng Blog.
We've given up on “fat models, skinny controllers” as a design style for our Rails apps—in fact we abandoned it before we started. Instead, we factor our code into special-purpose classes, commonly called service objects.
The post goes over six rules of thumb that I've found useful, including class design, method parameter, and return values.
- Understand what problem you are trying to solve. So many skip this, or don't spend enough time on it or don't even realize that it's something to do. The main failure of good programmers that I've seen is in not knowing what problem they were trying to solve.
- Figure out what you need to do to solve the problem before you solve it. This can be anything from skimming the code you're about to change to organizing your thoughts in a full-blown design document. You have to have a good idea of how you're going to go about solving the problem in the code.
You can apply these steps to pretty much anything you need to do, from fixing bugs, to implementing features, to writing emails, to holding meetings. If you know what problem you're trying to solve, and have a good sense of how you're going to do it, actually solving it becomes a lot simpler and a lot easier to get right.