Katrina Owen wrote an interesting piece on SitePoint Ruby called “What’s in a Name? Anti-Patterns to a Hard Problem”. She identifies a lot of pitfalls around naming and method design, but the solutions to the problems she’s identified aren’t as much about naming as they are about using data types effectively.
In March’s PragPub, I’ve got an article titled “Why You Need a JavaScript Framework”.
Remember that application you were working on that started out needing just a bit of JavaScript? And then it needed more? And then just a bit more? And then you had a complete mess on your hands?
You can avoid that next time by using a front-end application framework right from the start.
The issue is a couple bucks. Check out the other contents here.
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.