It’s one thing to develop and test a Windows application; it’s quite another to bundle it up into a nice executable that installs correctly on all the different Windows versions that you need to support. I’d like to guide you through the process that I wish I had when I was creating my first installer. Read more on Quick-Start Guide to Creating a Windows Installer…
Protractor Page objects provide a helpful way to organize your end-to-end test code. While your actual tests take actions and make assertions about how your application should respond, page objects encapsulate the details of how to perform those actions on a page. Read more on Protractor Page Objects…
Vim macros let us transform code like no other editor. Here’s how they work:
- Pick a register to record into. (A Vim register is like a little slot where the macro data will be stored. We usually want to record into one of the named
a-zlowercase letter registers.)
Git is a powerful tool that we love as developers. It’s also complicated. I consider the bare essentials of Git, the minimum set of features to be familiar with before we can be productive, to be all of this:
- local interaction: status, add, remove, commit, reset, checkout
- branch management: checkout, merge
- remote interaction: clone, fetch, push, pull
Once we’ve learned these basics well, we move onto advanced features and tricks. Read more on Sharpen Your Git Saw – Aliases, Selective Staging, & Interactive Rebasing…
When our Backbone.js apps become complicated, we need to utilize Backbone’s EventAggregator. From the Marionette docs: “An event aggregator is an application level pub/sub mechanism that allows various pieces of an otherwise segmented and disconnected system to communicate with each other.”
1. Make sure you need it.
It’s harder to follow the execution of an event-based program than of regular synchronous method calls, so make sure you understand why you need an event in the first place. It’s worthwhile to ask: if events weren’t available, what would I have to do to solve this problem? Read more on Backbone Event Best Practices…
If you’re a developer shopping for a new MacBook, choosing a CPU can be confusing. Apple always gives you a handful of different CPUs options, all with different specs and prices, but it’s very difficult to understand how your development experience will be affected by this choice.
You can put thought into the other options that Apple lets you customize. For hard drive capacity, it’s easy to check the amount of space you’re using on your current machine and decide on a hard drive size for your new machine. If you’re comparing two different screen sizes, you can decide if you’d rather have a cheaper and lighter machine or a larger screen.
You can’t do that with CPUs. For instance, the latest round of 15″ Pro Retinas (released in late 2013) gives you three CPU options: Read more on Develop Smoothly with the Right MacBook CPU…
How far should we take unit testing? Should every line of code be covered by a unit test? What about code that’s hard to test? Let’s look at the cost and value of unit testing in a couple of different situations.
Tests We Can All Agree On
It’s easy to see the value of unit tests when we’re writing actual functions. Let’s say we’re writing a helper function called
next_valentines_day for our greeting card application. Here are some tests that we might write:
1 2 3 4 5 6 7 8
describe next_valentines_day do it "returns next year's valentine's day when after Feb 14" do expect(next_valentines_day('2014-02-15')).to eq('2015-02-14') end it "returns same year's valentine's day when on Feb 14" do expect(next_valentines_day('2014-02-14')).to eq('2014-02-14') end end
Even from just these two tests, we we’ve significantly reduced the risk of calculating the wrong Valentine’s day in our software. And that means we’re less likely to lose valuable time fixing bugs in the code or dealing with other fallout from the code being wrong (like decreased greeting card sales). Read more on The Cost of Unit Testing…
At retrospective meetings, we reflect on how our team has been operating, sharing both the good and the bad. We try to identify problems and take actions that solve those problems.
But just as important as fixing procedural problems is giving individual team members the chance to speak, be heard, and “air-out” anything that’s been bothering us. Ideally, we will honestly share our feedback and perspectives, and humbly acknowledge our mistakes. In reality, though, most of our retros fall short of that standard. Here are some common problems and ideas to help work through them. Read more on Tackling Silence, Avoidance, & Negativity in Project Retrospectives…
As engineers, we enjoy solving technical problems and enjoy the results of our hard work. But sometimes, our development suddenly and mysteriously stops working, and we get stuck trying to figure out what happened. Then, hours later, we realize it was a really dumb mistake or oversight. Those times are really unfulfilling and frustrating.
To help you avoid this frustration, here’s list of lessons that have been painfully burnt into my heart over the years.
1. Save the file.
Yeah, we still forget to do this sometimes. We were supposed to have permanently learned this lesson during our first ever
Hello, World program, but sometimes we still forget. Many IDEs have an autosave feature, but watch out when using that same IDE on another machine, since the feature might not be switched on. I’m more likely to neglect saving when I switch between buffers or tabs a lot. Read more on Dumb Development Mistake Checklist…
My recent post gave an introduction to iOS animation, showing how to move elements around the screen. This time, I’ll show you how to animate view elements in response to the keyboard appearing and disappearing. We’ll pretend we’re working on a photo-sharing app that has a text field to enter the photo’s description into.
Unfortunately, our text field gets covered up by the keyboard as soon as we tap it:
1. Dismissing the Keyboard
The user has no way to dismiss the keyboard once it’s been shown. It would be nice to be able to tap anywhere else on the screen and have the keyboard go away. To do this, we add a Tap Gesture recognizer to our view, along with a method that dismisses the keyboard:
Read more on Animating Around the iOS Keyboard…