I truly intended to use Rails' extra features. First life just got in the way. And then Rails did.
Grab a bowl of buttery popcorn because the saga continues! The end of the previous chapter saw our intrepid little Rails app camping happily on Heroku. This latest chapter in the hosting chronicles brings with it a twist: not just a change in host, but a complete migration from one programming language to another.
Onward for the Why’s, How’s, and Gottchas of the switch.
Five months and 200 hours later, I’m standing tall, arms-folded, my first-ever training course live on the video wall behind me. How’d I get here?
I won’t kid you; the road to course creation is riddled with potholes, roadblocks, and sketchy checkpoints. It was hard. But the solution to each obstacle taught me new skills and valuable life lessons. I think it’s time to document those lessons.
Code flows effortlessly from your nimble fingers, like fine cloth from a loom. Your face is serene, focused, content. Suddenly, a wrinkle appears in your brow, breaking that pleasant mask of serenity. The frown deepens. “That can’t be right…” What happened? A bug! A hairy bug lurks fiendishly somewhere in that elegant tapestry of code love. How did the bug slip past you? You were so careful! A frustrated hour passes, then two. You comb through each strand of code, retrace your steps through the intricate lattice of if, when, and for…
We sink so much time into the deep pit that is debugging. Yet for all the time we spend on it, there is surprisingly little literature written on the subject. A notable exception is Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, by David J Agans.
Spanish for the Inner Gringo helps intermediate to fluent Spanish speakers correct the mistakes they didn't know they were making.
I recently launched a new learning channel, Spanish for the Inner Gringo! It aims to help you polish up (squeak) your Spanish accent and grammar so that you sound more like a native, and less like a Hawaiian-shirt-wearing, camera-laden tourist.
The videos are short (only two-minutes!) and I will be releasing one video every few weeks. The AV is sub-par, so you’re bound to get some laughs too. Subscribe to the channel and sign up for updates so you won’t miss a single video.
Keyboard shortcuts, it’s a love-hate relationship. On one hand, they unlock hidden cheat code levels of productivity — on the other, they unlock… What was that again? … Oh yeah, you just can’t remember them! What is it about keyboard shortcuts that makes them so hard to remember? Should you even bother? Is there a reliable way to learn them?
Why is it so hard to remember keyboard shortcuts? Simply put, there’s so many shortcuts to remember, and their use taxes a different class of memory.
Refactoring is the lifeblood of a nimble codebase, but we need to stop hand-refactoring via Ctrl-C/V and start using our automated refactoring tool. Prepare to be convinced, then watch in amazement as you memorize your favorite refactoring tools’ keyboard shortcuts in two hours flat – and remember them forever.
You need an automated refactoring tool Refactoring without tests is dangerous Refactoring without tests and without an automated tool is like walking a tightrope over Niagara falls without a safety net - with your product and entire team standing on your shoulders.
Venerable old Vim has been with us since its creation by Bram Moolenaar in 1991. It’s light, it’s terse, it has a learning curve like the “Cliffs of Insanity”, and yet it’s still one of the most popular text editors in the world.
Here was my take on Vim, as compared to an adult beverage: Vim. It’s like being gifted a 50-year-old bottle of scotch. Now if you could just figure out how to open it…
Many believe that to be successful, the members of an Agile team have to be a bunch of highly skilled full-stack hot shots. Some even go so far as to say that you should only hire skilled developers, or “senior” developers. Are the pundits just a bunch of arrogant elitists? Unfortunately, their elitist views aren’t entirely without merit. At their core, Agile teams are supposed to be self organizing and largely autonomous. Take the Scrum framework for example: the Product Owner decides *what* to build, but it’s up to the team to decide *how* to build it. Why is that dangerous if the team is composed of junior developers?