Skip to content

TIL about Alfred workflows, and they are amazing!

I’ve been using Alfred for a while, and when version 2 came out, I just upgraded without trying to learn any of the neat new features. Today, I needed a change of pace, so I decided to take a peek and created a video of the outcome. In a nutshell, I’ve created a small workflow to convert Android display independent pixels to real pixels. It’s actually very easy to do, and I will definitely spend some more time digging into this.


Posted in Geek Vids.

So, you read a book about parenting…

I come to you as the world’s foremost expert on parenting. To be more specific, I am an expert at parenting my two daughters. There are many lessons you can learn from your own maturing process that can make you a better parent. Lessons in patience and diligence definitely come in handing when dealing with your children.

There are a few hard earned lessons I don’t think I could ever have learned from a book or other parent’s anecdotes. This is a lesson on individuality. I have two daughters who have been brought up in the same environment, been subjected to similar circumstances, and to tell you the truth, they couldn’t be any more unalike.

My oldest daughter is the picture of civility. She is always calm, helpful, and generally just a great person to be around. I can’t see how anyone could ever have a problem getting along with her. My youngest daughter has a very smart wit. She is extremely observant, and always determined to do things on her own. Seeing as she is just four, you can see how life and her like to butt heads constantly.

I have advice for parents or people thinking about becoming parents at some time in the future: You can’t learn to parent from a book. Sure you can read about eating advice that will ensure your child is growing up healthy. You can read about potential sicknesses, and you can also read about ways of helping your child to learn. You should give up the reading now, if you are looking for a magical cure to four year old temper tantrums or a way to relate to a little girl who is getting ready to be a teenager. My best advice is to be pliant and understand that all reactions are caused by some stimulus. Fix the originating problem or learn to deal with the consequences!

These lessons also also apply to “thought workers”. Software developers definitely fit this description. Personalities differ greatly, Moods are sometimes indeterminate. Sometimes you’ll feel that you just can’t relate. 

Unfortunately, I don’t know of the magical incantation that will allow you to relate to software developers on all levels at all situations. To understand them, you’ll have to approach them like you approach anyone else. You’ll have to understand that their reactions are due to previous life experiences, personalities, and what they did or did not have for breakfast that morning. Treat them like people and show genuine concern when issues arise. Don’t stereotype them with some movie you saw on the television. Make sure to give them the respect you expect to receive.

I’m sure these lessons can help you relate to anyone that you meet that is different than you. Whether it be a different race, sex, or ethnicity. No one can tell you how to deal with any random group of people in any random situation. Take the lessons you’ve learned earlier and apply them generously. Use the failures to create future successes.

This is a lesson from a dad. Something passed to me by my dad. Something I hope my coworkers and children can pass on as well.

Happy Fathers Day!

Posted in Smarticus Says.

About that first test…

Yesterday, I was having a discussion with a young, bright, aspiring developer about code, and the subject of tests came up. In the Ruby community these days, the assumption is that everyone tests their apps, so our conversation evolved to the actual testing practice. I appreciate the many approaches to testing, so I started quizzing him about his process.

The conversation moved along nicely until I asked him, “Say you have a new Rails project. What is the first test that you write?” He described that he would use the Rails generators to create a model and then start describing the behaviors for his first model. While not trying to sound rude, I probed if that was really the first test he should write? By generating a model and describing its behaviors, he was subconsciously making a few serious assertions about his application. How do you know you’ll need a relational database? Why would you pick any model over any other? How does that model even fit inside of your applications ecosystem?

Now, with a genuine fear of sounding overly pedantic, I’ve had great internal debates about The First Test. This single test sets the tone for your initial development session. To avoid wasting too much time, what test do you write first?

Today, I’ll try to explain how I write the first test. Maybe, someone can find great errors in my ways, and enlighten me to a better way. Maybe I’ll learn that I’ve been wasting my time, and should move on to more important problems.

My process is pretty simple. In my opinion, the first test is not a unit test. Without a test, those units have no reasons to exist. I start off by writing a higher level functional test. In my parlance, a functional test does not necessarily equate to a Rails functional test. A functional test simply verifies the behavior between objects in a system. Also, a unit test can only describe the behavior of a single unit in isolation in one or more circumstances. So, what’s the first test that I write? My first test describes the simplest assumption of my system. If I was writing a blog, describing the process of creating a new post might be my first task. The first test would most likely have some sort of mock implementation of a post that would naively say it saved itself when asked. Next, after I assured that my process for creating the post was correct, I would then move to implement some type of object to encapsulate a Post. 

I believe this method allows me to describe the system without concerning myself with details of how it works. Is this crazy? What say you?

Posted in Smarticus Says.

Tagged with .

Restarting your apple’s airport network interface

Sometimes things happen and for reasons unknown, your airport stops working. You could go the menu bar, turn WIFI off, and then turn WIFI on again, or you could do create a shell script with these contents

Make sure to replace en0 with en1 if you are on a Macbook Pro.

Hopefully this tip will help someone searching for “restarting airport from the command line” or even “what’s the meaning of life”

Posted in Smarticus Says.

Tagged with , .

Just enough testing

It’s happening again: An extremely successful software developer with a very large following lists his rules for success, and people jump for joy at the occasion, and use that list to justify their practices. That sounds great, doesn’t it?

While reading, Testing like the TSA, I found myself nodding in agreement with what most David was suggesting. I didn’t agree with all of it, but that’s fine; there is definitely room for positive discussion and disagreement when it comes to solving problems with code. The best part about the blog post wasn’t the post itself. The comments and other discussion on sites like HackerNews are the real jewels.

I’d now like to think out loud about testing. We’ve come so far in the Ruby community, but in reality, we still have a long way to go.

Just Enough Testing

A question that I hear constantly is, “How much tests should we have?” I always reply with, “Just Enough.” What does that mean exactly? It boils down to your application or library should have just enough tests that you are confident that it works as it should. Do I think your code base has enough tests? I don’t know. You should know. There isn’t a magic number. You’ll know when you’ve found it. Velocities will increase and regressions will decrease.

There’s a difference between spiking (or prototyping) and writing code that is destined for production.

Too many times, we see a blog post or a book that echoes our thoughts, and we grasp on to it as if were a gospel. When I see a comment that basically says, “… and that’s why I don’t test”, I think we should mark that as a failure. There are plenty of times when all of us don’t test. Last year, while I was learning Clojure, I didn’t write one test (and I still don’t). When I was learning how to write Android apps, I didn’t write tests either. The reason for this is because I wasn’t sure what I was writing. It’s pretty hard to describe the behavior of something with tests. It is even harder when you don’t know the language of description.

This can also be applied to web developers who develop web apps constantly. Sometimes we don’t know what we are trying to build. A little exploratory code helps us understand the problem. What we are looking for is the correct question and you might have to write a little code before understanding that. I suggest that after you learn the right question, you throw the prototype or spike away, and start again using TDD. That might not always be possible due to time or budgetary constraints, so you might have to retrofit it with tests later. This isn’t optimal, but it’s a part of being a professional developer. You can’t learn this by reading blog posts or books.

As an aside, I almost feel confident when test driving Android apps. It isn’t perfect, but I feel like this is the beginning of a conversation rather than any type of a complete solution.

Testing for testing’s sake is a waste of time

You may remember back a few years ago when I spoke about TATFT. You might not have known it, but this was a short talk that was more parody than anything else. Many of you took this at face value. Doing that put you in the same place as taking the “Testing like the TSA” post at face value. You shouldn’t do that. The real value is understanding why we say what we say. I don’t write tests all the time. I do think constantly if I’m writing in a way to make things easily tested. I do write tests first most of the time. Keep in mind, I certainly don’t advocate that I or anyone else should write tests all the f#$@ time. That’s silly.

I rarely look at tools like code coverage or test to code ratios. That isn’t important to me. What I care about is is that the tests that I’ve written properly describe the behavior of the project. The times where code coverage and test to code ratios are important are as a metric over time. If these numbers are going down, it is a sign that code quality is decreasing. David pointed out in his post, “1:2 is a smell, above 1:3 is a stink.” You are going to have learn what’s good and bad on your own. Projects with different developers, with different problem domains will have different tolerances for smells.

TDD is hard

TDD is hard. Think about the first time you sat down to write tests first. What was the first test you wrote? Does that test still exist? I sure hope not. Red, Green, Refactor is a catchy slogan. It seems easy to write a failing test, write some code to make it pass, than refactor. It isn’t, unfortunately. There are some good books on the subject. Test Driven Development by Example (the Kent Beck book) is one people always talk about. Growing Object-Oriented Software, Guided by Tests is much better, and definitely belongs on everyone’s bookshelf.

You also have to remember that TDD is just a suggestion. Take what works for you and form your own opinions. I personally believe in Write a Test, Make it Pass, or Change the Message. This allows me an easier logical transition between Red and Green.

The one thing I can promise you is that with practice and anger, you’ll learn what does and does not work. The goal here is get working software that you can trust as fast as you can.

Don’t use tool X

I feel like this is always bad advice. Some people like RSpec and some don’t. Some people have had great results with Cucumber, while some flail with it. At one time, all of us knew nothing about code. We found a language we liked, and learned how to be productive with it. Sometimes tools aren’t productive because you aren’t using them right. Sometimes tools are just bad. I appreciate that we have a myriad of tools for our arsenals.

Don’t test your web framework

I don’t have much to say about this. Don’t test it until you absolutely have to. Think twice before writing tests for that validation. In our Rails projects, we should be thinking about behaviors of objects and interactions between objects. Your unit tests should reflect that. Your acceptance tests verify the orchestration of those units. Simple, right?


Posted in Smarticus Says.

Tagged with , .

My gitconfig

Here’s my gitconfig, I thought I’d share.

Posted in Smarticus Says.

Tagged with .

My new funky editor. A story about Sublime Text 2

A prologue

Today, I use Sublime Text 2 for just about all my text editing needs. It is fast and fairly stable. It is customizable and it can use plugins from Textmate. It also allows me to have split windows and its concept for finding files, methods, and editor actions make me a productive developer.

Over the years, I’ve used a myriad of text editors. Most of my time has been spent in Vim. My fingers are so used to Vim’s modal editing, I tend to expect the world to move up or down when I press j or k. Every time I’ve tried out new editors, I’ve always missed h/j/k/l. Sublime Text 2′s Vintage editing mode satisfies most of my modal editing needs. All the important commands are there, and new ones are added as users request them.

One big issue I’ve had with editors that can be extended by code, is that the language used for extension isn’t very friendly. I’m not well versed in Lisp, but I can get around. Emac’s ability to be customized is unsurpassed, but personally I don’t feel that I need a complex environment with an editor as a bonus. Most times I just want to create text. On the other hand, Emac’s Org Mode is unsurpassed, so I do find myself wishing that it existed in other places with the same amount of functionality as the the original.

Vim’s vimscript is more than functional. It can be used to create some truly useful plugins. Tim Pope has proven this time and time again. The problem with vimscript is that is really only useful inside of vim. Vim also allows you to extend it using other languages, such as Python and Ruby, but I haven’t explored either of those enough to comment on them.

I tried Sublime Text 2 as a diversion from my normal editor, MacVim. I’d been hearing many things about it, so I wanted to try it out. It passed the 5 minute red face test with ease, so I decided to use it exclusively for a two week period. That was over a month ago, and now I’ve purchased it as well.

Why have I stayed in Sublime Text 2 for so long?

The obvious first response to this question is because it isn’t bad on the eyes. I like soft pastel colors on a dark background, and I wasn’t disappointed with what I saw.

Sublime Text 2's pretty colors

I learned a long time ago that the keyboard is the fastest way to navigate, so I require my editing environment to be fully driven by the keyboard. Finding files is as simple as pressing ⌘P (I use a Mac) and typing a combination of the path and the file name. The interface is fuzzy, so you don’t need to type all the characters to find things in a hurry.

Find files quickly!

There are also ways to find methods/functions in your current file and run commands quickly as well.

Command and Goto Symbol

You didn’t have to read this blog post to see those in action. You could have went to Sublime Text’s home page to see them detailed. I want to share why I’m not moving away from this editor in the foreseeable future.

As I said before, I don’t like to use the mouse. I avoid it to the point of shedding a single silent tear every time I have to use it. Keyboard navigation in ST2 (as I will refer to it from now on) is more than sufficient. You can create files and move between buffers with keystrokes. I can even bring up a Quake style console to see editor output, and show off my elite Python skills if I need to.

ST2's console

As we all know, all problems in computer science have already been solved. (At least that’s what I like to think) Sometimes we need to look to past to solve the problems in front of us. Looking to the past, we find Textmate’s snippet and theming system. Instead of creating yet a new format, ST2 allows you to import Textmate bundles. Problem solved.

You’d be mistaken if you thought that ST2 was just a new skinned Textmate, however. ST2 brings its own configuration to the table as well. It isn’t strictly a Mac style preference dialog, but it’s JSON back configuration is pretty easy to learn.

ST2's preference dialog

ST2′s plugins are all written in Python. Python isn’t too hard to learn if you programmed in any other C style language, and there are already plenty of plugin samples to base your new code off of. The plugins have access to basics, like your where your caret is, what lines you have highlighted, and the details about the current files. Plenty of people have written plugins to extend ST2 to their liking.

I’m currently following the Dev releases of ST2. What this means that I get new and fixed editor functionality a couple times of week. In the past month of using ST2, I’ve seen improvements to editor stability and new features. It’s like Christmas for my editor twice a week.

I’m sure at this point (if they’ve made it this far), that all the emacs and vim people are shaking their heads. Those editors do all this and more. If you are shaking your head, you are missing the point. There is plenty of room for improvement and usability. ST2 is just another attempt at finding that sweet spot. Usage of any editor is not an admission of disdain for any other environment. My vim code folding screencast is still the most popular post on this site. I’m happy to have found something to give me the energy to write blog posts again.

So, now I’ve been using this editor for a while now, and now it is time to make it mine. Stay tuned for part two of this series where I share how I’ve molded the editor to match my coding style.

Posted in Smarticus Says.

Why people don’t ask for advice

I’ve been writing code in some form or another for over 20 years now. In that time, I’ve explored quite a few different languages and problem domains. The great thing about software development, is that there are more problems to solve than any developer or set of hundreds of developers could solve.

Lately, I’ve been exploring a new problem domain. I want to write a graphics rendering engine. It has nothing to do with the web, so it is new territory for me. I’ve been researching question and answer sites, reading books, and writing lots of exploratory code, trying to immerse myself into this new (new to me that is) technology.

Last night, I happened upon a person who is employed by a prominent company, who is paid to do what I’m trying to learn. I don’t get many chances to ask questions to real life gaming people, so I decided to seize the chance. I started off slowly trying to explain what I was trying to learn, the approach I was taking, and what some of my long term goals were. I hope my face didn’t show it at the time, but I was horrified at the response; I was told that I was wasting my time.

No one wants to waste time. Life is finite. Time is a premium resource for someone who works to put food on the table and spend time with their family. So then I had a decision to make: would I take the advice at face value, or would I dig to understand why the advice was given. I kept digging.

The new problem domain I’m working with is based heavily on math. I wasn’t good at math in high school (maybe I just wasn’t good at school), so many of the concepts I’m learning about now are new to me. The advice giver told me no one uses that math. I then asked him how else would he be able transform objects on the screen. He replied that there are libraries to do that. I also wondered about the best method for composing screen graphs. He replied that there were libraries that did that as well. I finally followed up with specific questions about various kind of optimizations, and he told me, that with my level of knowledge and choice of implementation technologies, that I would never run into those problems. The conversation went on, but it wasn’t progressing on any level.

Suddenly, I was questioning my choice of continuing to write the engine. Why would I want to do something that eventually end up being a failure? Why would I want to waste my time? At that point I realized something. I’m not trying to emulate the person giving me advice. I am forging my own path. I thought I was asking for advice, but instead I was giving this guy a chance to steer me wrong.

Why don’t people ask for advice? In most cases, the advice given will not be any good. People generally won’t give you advice that will enable you to be better than them or even as good as them. They’ll just give you a summary of their understanding that will likely enable you to get to one step below their level at best. Maybe at some basic level, we are a selfish species.

What will you do the next time someone asks you advice?

Posted in Smarticus Says.

If your tests don’t scale, you might want to look in the mirror

“Our test suite is slow”

“Our test suite is fragile”

You have to approach your test suite the same way you approach your application. In many cases, people don’t pay enough attention to your test suites. There are only a few guidelines to follow to have sane test suites that run in a decent amount of time.

1. Be careful what you mock. Mocks are deposits on future pain. Sure they speed up execution, but they aren’t resilient to changes you’ve made in other sections of your code.
2. Don’t talk to external services unless you absolutely need to.
3. I bet the box you run your tests on uses multiple cores. Why not introduce a test runner that can actually take advantage of it.
4. Only create just enough setup to actually test your behavior.
5. Be observant of side effects. If you are using something like factory girl, models will be created and run callbacks. Is that really important to what you are testing?

There are techniques you can try that will allow you to reduce test times significantly. Don’t let your previous failures or perceived inabilities trick you into thinking it isn’t possible. Testing most definitely scales. I guarantee it!

If all else fails, just drop me a line. I’m sure I can help steer you in a better direction.

Posted in Smarticus Says.

Tagged with .

Fake camera for smoke testing Android application

While building out my current Android project, I came across the need for a way to have a camera on the emulator that didn’t require any manual input. Since I’m using Robotium to do my smoke testing, I headed to their mailing list first. After a couple of minutes of searching, I found the solution to my problem, so I decided to bundle it up for other developers to use as well. I’d like to thank Marcus Chen for the original idea.

To use this camera, all you have to do is select it during your smoke test run. I’d also suggest that you make it the default.

Currently, the camera only circulates through three images. It is possible to swap them out or add more if you fork the FakeCamera project at Github.

If you are curious what test driven development looks like in Android, I’ve created a sample app screencast that walks you through the basics. (looks great in HD)


If there is interest, I will definitely spend more time in creating a suite of Android development screencasts. I even tossed around the idea of monetizing these as well if folks are looking for higher quality or deeper dives into Android development.

Posted in Smarticus Says.

Tagged with , , .