I’ve used many languages for my scripting needs, but my favorite — believe it or not — is probably Bash. Bash may not have any types, and scripting with Bash may be fraught with pitfalls, but sometimes the problem at hand is solved most succinctly and elegantly with small focused programs that compose well.
Bash’s composition comes in the form of piping one program’s output into the next program. No program needs to know where its input comes from, just like Lego blocks don’t care what block they stack on. This is an incredibly useful approach. For instance, take a look at how easy it is process the contents of the clipboard:
pbpaste | base64 | pbcopy
We just base64-encoded whatever was in the clipboard (at least, on Mac OS X; Linux has similar programs under different names, and on Windows you may need to write your own versions of
pbcopy). You can use
pbcopy and the rest of the Bash toolbox to do whatever processing of clipboard text you have in mind, and thanks to pipes, you can do it very concisely. Read more on Plays Well with Others – Lessons in Reusable Tooling…
This short post is intended to serve as a warning about a potential gotcha with git-svn, and how to prevent it.
First, a sort of “postmortem” of my run-in with this issue:
I was working to migrate an old SVN repository full of documents to Git. We had decided that we didn’t need to maintain a complete history going forward, that we would just take what was currently there and put it in a new Git repository. We would keep the old SVN repository around for reference in case we ever did need to go back through that older history. We wanted to preserve the old history in SVN, but make a clean break from it for a fresh start with a new Git repo.
I used SVN to check out a fresh copy of the repo, removed
.svn, turned the directory into a Git repo, and pushed it out to the new remote. All good there. Read more on Git-SVN Gotcha with Empty Directories…
A reminder to those who learned this lesson long ago, and a warning to those that have not learned it for themselves: Don’t use floating point numbers for money.
When doing any kind of calculation with currency, accuracy is extremely important. And floating point numbers (floats and doubles) don’t have an accurate enough representation to prevent rounding errors from accumulating when doing arithmetic with monetary values.
An excellent StackOverflow response that explains the issue states:
Representing money as a double or float will probably look good at first as the software rounds off the tiny errors, but as you perform more additions, subtractions, multiplications and divisions on inexact numbers, you’ll lose more and more precision as the errors add up. This makes floats and doubles inadequate for dealing with money, where perfect accuracy for multiples of base 10 powers is required.
Ways it Can Go Wrong
When it comes to dealing with money in a computer program, a developer needs to stay ever-vigilant. Just because you, or a previous developer, made the right call by using a
DECIMAL column when creating the database schema, doesn’t mean that accuracy can’t be lost before the result of some calculation is displayed to an end user. It’s all too easy to slip up and lose the necessary accuracy without even realizing it. Read more on Floating Point Numbers & Currency Rounding Errors…
Problem statement: You have a list of items that you want to randomize.
I’ve found myself in this situation many times. If the language you’re working in has a shuffle or randomize function, you’re set. However, there are plenty of languages that don’t provide built in support for such a function, leaving you on your own. The first time I was faced with this problem, I wrote a shuffle algorithm that looked something like this:
for i in range(len(items)):
randomIndex = random.randint(0, len(items)-1)
temp = items[randomIndex]
items[randomIndex] = items[i]
items[i] = temp
The above algorithm swaps every element in the list with another randomly-chosen element in the list. But there are three problems with this algorithm: Read more on Fisher-Yates Shuffle – An Algorithm Every Developer Should Know…
Atomic Object has a great tradition of making and customizing tools. It’s a habit I’ve gained and lost several times over my career — keeping tools sharp requires time and effort. Fortunately, one of the best things about becoming an Atom is that all of my colleagues care deeply about software, so it’s easy to find inspiration to start making tools again.
Recently, I’ve been working on a modern Java web app, and I ended up going all-in on IntelliJ 13. It’s a great development environment for mixed language web development (and Android!). The biggest down-side for me is its poor Emacs compatibility out of the box. The pain of hitting keys that don’t work or do something unexpected sent me looking for a cure. As a life-long Emacs user, I just wasn’t willing to down-grade to the Vim plugin, so what started out as key binding tweaks became full-blown plugin development to customize IntelliJ.
My fingers are happy with what IntelliJ can do now, and there’s a clear elisp-style path to add features that I miss. Read more on Customizing IntelliJ for Emacs Compatibility…
For a long time, the only IDE that iOS and OSX developers had was Xcode, and life was okay. Then JetBrains released AppCode. For the last 6 month, I’ve had the opportunity to use AppCode as my primary IDE, and it is head and shoulders above Xcode.
Read more on Why I Prefer AppCode over Xcode…
There are many ways you can take a screenshot on your Mac. The best method often depends on the portion of the screen you need to capture and how you intend to use the captured image.
The tools and tricks themselves are not complicated, but pausing to look something up while in the middle of a work session with a client can be distracting. This blog post, therefore, is a little self serving; I simply collected my favorite options in one place as a quick reference. Hopefully it will be useful to others as well. Read more on Taking a Screenshot on Mac OS X…
Also posted in Developer Tools Tagged Mac OS X
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…
Also posted in Developer Tools
Here are some of my favorite lesser-know features of DevTools. Read more on 5 Awesome Lesser-Known Chrome DevTools Features…
Vim is a good friend of mine. When we met during my freshman year of college at MTU, we quickly hit it off. I never looked back with any regret at my tiny TI-85 screen, Notepad, or QBasic where I first tinkered with bending computing devices to my whims. Since then I have tried other editors, and even used a few for extended periods for a variety of reasons (e.g., Kate because of its SSHFS and KDE tie-ins, Visual Studio for its strength with all things Microsoft). Still, through it all, Vim has been my go-to editor for nearly 15 years.
Read more on A Month with the Atom Editor…