This interesting piece from Will Hughes titled How to Level up as a Developer was a great read, but it focuses too much on “developer-as-producer-of-diffs” and not enough on “developer-as-solver-of-problems”. Although I’ve written in detail in my book “The Senior Software Engineer” what I think you need to do to be a great developer, I’m going to augment and modify some of the specific points Will makes.
Ernie Miller started a tweetstorm on Friday that really rang true to me, about how certain abstractions are “dishonest”. In my mind, the dishonesty is calling them abstractions in the first place.
Writing on the Stitch Fix blog about how feature and product design can’t just focus on the “happy path”, but must account for, among other things, network flakiness:
The other thing I’ve realized is that you cannot address these issues with entirely technical solutions. You have to account for these realities in the design of your product.
About a year ago, PragProg approached me to see if I was working on anything book-worthy. I’d just created https://angular-rails.com to document the pain of configuring Rails to do something it clearly didn’t want to do—let you write an application with lots of front-end. Meanwhile, I’d been learning more and more how great Postgres is.
The result is my new book “Rails, Angular, Postgres, and Bootstrap: Powerful, Effective, and Efficient Full-Stack Web Development”. It’s been in beta for a while, but official print verison is now for sale.
You can buy it now and start embracing the full stack of web development using some awesome tools that will serve you well for years to come!
If you regularly work with web technologies, you’ve no-doubt pulled your hair out dealing with the technologies used for front-end development (and, let’s be honest, back-end development, too :). Almost everything about front-end work feels terrible, from the weakness of JavaScript as a language, to the myriad half-documented tools that all somehow manage to do less than make, to the absolute bizarre notion that we are building user interfaces with technologies designed to write term papers.
But why are these experiences unpleasant? I would argue simply that they don’t fully meet our needs as programmers. And we can think about those needs as a hierarchy, each need building on the need below it.
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:
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
New post on the Stitch Fix Tech Blog about how we create Rails-based HTTP APIs using a simple gem called stitches:
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.