Earlier this year, I was in the position to choose the framework for the startup at which I’m now the CTO. I could’ve chosen anything. I went with Rails. And you should, too. It still is the best framework for getting up and running and for continued iteration and development.
Way back at RubyConf 2019, I announced a book about sustainable web development using Ruby on Rails, based on my 6+ y ears of experience doing so at Stitch Fix (and 18 months not doing so at LivingSocial).
It’s done, it’s 450 pages, and you can buy it now for $49.95 as an ebook (PDF, epub, Kindle, Markdown formats). If you write Rails code professionally, and struggle with keeping your app maintainable and easy to work on, this is the book for you.
Getting responsive images to work via the
size attributes to
img is not easy, especially because
almost all documentation I have found is vague as to what exactly the word “pixel” means in any given context.
This post will sort that out.
One thing mentioned that isn’t in the SOLID book is that we all need to understand not just the advice we’re given, but who is giving it. What is the actual experience of the person telling us how we should code?
If someone is giving out advice I want to know – “Have you done that? Have you experienced this problem, or is it just theoretical?”
I try very hard to only give advice based on my actual experience, and I try to contexutalize that experience as much as I can to avoid it being mis-applied. It’s not easy and I don’t always do a great job, but I’m very aware of it. Even if my advice boils down to “it worked for me, anyway”, that’s better than “I haven’t tried it, but it seems neat”.
Names of things matter. How we react to the realization that some names of some things offend some people is important. Unlike the names of countries, towns, or Army forts, computer software can actually be renamed relatively easily, yet we still struggle to have even basic conversations about it.
I want to share the way I think about it: acknowledge a person’s feelings, understand who might feel excluded by a name, decide if excluding them is OK, and, if not, figure out how to change the name.
I will be donating 50% of the royalties I make on my books to The Bail Project until the end of 2020. Please see this page for more details. #BlackLivesMatter
I am somewhat obsessed with clean, repeatable, maintainable dev environments and Docker has all the pieces to
create one. For the past several months on several projects, I’ve been using Docker (and
docker-compose) to not
only run services like Postgres and Redis, but also as a virtual machine in which to run all my dev commands. My
Mac is only running Docker and vim.
The problem is that Docker on Mac has very slow file system access. Running
bin/rails server on a fresh Rails
app can take almost a minute to come up. I recently discovered that, by using NFS, file system access is way
faster. This creates a bit of a problem for
webpack-dev-server, but this, too, can be fixed. I want to write
out what I did in case it’s helpful.
At RubyConf last year, I announced a new book I was working on that outlines the way to write Ruby on Rails apps sustainably, so that teams, orgs, and code could continue to be valueable and easy to work with over time.
I worked remotely for Stitch Fix for six and a half years, originally as an engineer, then as a manager, director, technical project manager and architect. With all the tips and tricks going around, I want to talk about the one strategy to be successful working remotely. This strategy should be the basis for everything you do, and any productivity hacks that don’t roll up to this strategy should be set aside. The strategy is to build and cultivate trust.
I had a great time chatting through some of the ins and outs of making a mess in a Rails app. Check it out in your podcast player of choice.