Mojomonkey Coding

Most people use Unit Test to run automatically during the build phase of the project. They provide built in regression testing, allow developers to analyze the code while writing the test, etc. One over looked analysis is seeing what sort of set up is required just to get the test to run. If your Unit Test requires defining and initializing of a large number of external systems (especially those that on the surface don’t seem like they should have anything to do with the system you are testing), you have a design issue. Your application is not Orthogonal, and perhaps a redesign is in order. This is particularly true with static elements of a system (this include Singeltons). As a full suite of tests may rely on the state of an external system not changing, which can’t be guaranteed with static globals.

So, next time you are writing a unit test, take a hard look at your set-up phase and make sure it doesn’t seem overly complicated. If it is, your system is not orthogonal and you are going to have problems if you don’t take care of them.

I’ve universally moved all my editors; Eclipse, TextMate and Xcode to using 16 point font. I’ve had to defend a few “old man” accusations, but at the end of the day, eye strain is NO WHERE NEAR as bad as it was with the standard 12 point font. I can sit further back from the screen, more comfortably and read the text with out effort. Try it, you might like it.

Well, it took me a bit longer than expected. After multiple iterations, I settled on the UI for Celery. It took awhile to build the Nutrition Label and make it look the same as you’d see on packaging, but I’m happy with the results.

Next, I will be working with Core Data for the first time to start storing the servings eaten, and store history.

Typically the first interview question I’ll ask someone is:

What are the three fundamentals of Object Oriented Programming?

This is amazingly good at weeding out those that aren’t qualified for programming positions. Most will at least start discussing what OO provides you. The three I usually look for are Encapsulation, Inheritance and Polymorphism (but there are others that work as well). Once they express these concepts, I’ll ask for a description of each. Many will simply respond by rote from college courses, but the stand outs really go the extra mile.

Encapsulation conceals implementation details about a class from the users of that class. The classic example is Accessor methods (getters/setters) that hides the underlying data. However, the point of Encapsulation really goes further than just hiding the details, it reduces code duplication. Following Pragmatic Programmers DRY (don’t repeat yourself) here is important. For example (from the book), you might implement a Point2D class that has an X, Y and length.

public class Point2D {

private int x, y, length;

public setX(int x) {

this.x = x;

length = Math.sqrt((x*x) + (y*y));

}

public int getX() {

return x;

}

public setY(int y) {

this.y = y;

length = Math.sqrt((x*x) + (y*y));

}

public int getY() {

return y;

}

public int getLength() {

return length;

}

}

This meets the rules of Encapsulation, by not allowing direct access to the data, but there is a lingering issue living here that goes deeper into the concept. Because “length” is encapsulated with an accessor, we can invoke the DRY principal and use the accessor to calculate length on demand.

public class Point2D {

private int x, y;

public setX(int x) {

this.x = x;

}

public int getX() {

return x;

}

public setY(int y) {

this.y = y;

}

public int getY() {

return y;

}

public int getLength() {

return Math.sqrt((x*x) + (y*y));

}

}

This reduction of duplication does two things, lowers the number of places you need to change code (i.e. setX, setY) and therefore, lowers the likelihood of bugs (less code, less bugs) and improves the Orthogonality of our code.

So, Encapsulation does more than just limit the visibility into a class, it empowers the developer to improve the design of the class.

Meyer’s Uniform Access principle: All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.

Well, I’ve done it. I’ve cleared out 17,000 emails from my inbox. I deleted 7,000 and archived the rest. I now vow to quickly categorize all incoming email as it comes in, not letting any required tasks sit in the inbox for me to somehow remember to do.

I read Merlin Mann’s posts on Inbox Zero and listened to his talks. It made sense, it spoke to me. And I tell you what, we I saw an empty inbox I could feel the stress melt away. Better than Calgon.

My particular way of handling email is this:

1. I set Mail.app to check for email only every 15 minutes. The checking every minute was like a gun held up to the little man they call productivity. I simply can not handle seeing the red badge on the mail icon. So, rather than take me away from what I am doing every minute, I check it every 15.
2. When it comes to the 15 minute time, I quickly categorize and remove the emails from the inbox. Absolutely nothing stays in the inbox: If it is junk, delete. If I can reply quickly, I do so. If I just need to read it, but no action is required, I archive it after reading. If it requires action on my part, I add it to Things and then archive it.

Taking control of my inbox has opened up my world. Thank God.

How many times have you set out to build a Prototype, prove a particular high-risk component of an application only to receive pressure from high management to continue forward with the Prototype through production? If the company does not buy into the idea of prototypes or, worse, fully understand that that means. That is, they don’t understand that you truly write code as fast, sloppy and duct-taped as possible to just prove a concept, then throw it out completely at the end. If you find yourself in this situation, how can you convince them that prototyping is the correct way?

There is a very simple solution to this problem. Never, ever, prototype in this environment. If someone above you does not understand the concept, they never will. Therefore, just don’t do it. Instead, iterate on that risky feature, using Tracer Bullets or similar.

Ok, here’s the first post in this series. I’m going to take a critical look at the languages I use the most (or am learning) and try to find 10 things that drive me crazy about them. This doesn’t necessarily mean that I hate the language itself, these are just a few things that might drive me crazy.

1. UI - Doing UI development in Java sucks. Layout management is horrendous. You get the joy of laying something out and then being nice and surprised at the results when you run it. Much like the proverbial box of chocolate, you never know what you are going to get. You have two crappy choices, AWT and Swing. AWT sucks worse than Swing. Good luck.
2. Bloat - Java has gotten HUGE. What better way to gauge it’s unmitigated bloat than to take a look at the page count of the venerable Nutshell books.2nd Edition (couldn’t find 1st) 628 - 5th Edition (latest) 1254 pages! I know, stupid measurement, but it is fairly accurate. Java continues releasing revisions, but does not remove cruft for fear of ruining backwards compatibility. So, as a result we have multiple ways to handle XML parsing, Concurrency, UI development, and more. Sometimes, backwards compatibility isn’t worth the cost.
3. Primitives and Objects - int/Integer, float/Float, double/Double, etc. Why support both? This is an unneeded complication, in my mind. This leads to “autoboxing” to solve the issue of making int == Integer, which then has its own problems. Pick one and stick with it.
4. Generics - I don’t have as big a problem as most with Generics. However, I do hate that it will no accept a primitive, requiring objects. Therefore, I can’t have a List of int primitives. Instead, it’s Integer objects. Treating them like primitives brings “autoboxing” into the fold and creates another level of complication with NPE checks, etc. Again, if they wouldn’t have done (3), this wouldn’t have been a headache.
5. Switches - Now the reverse of Generics. Switches only switch on primitives, I can’t switch on an Object using its built in .equals method. Why?
6. Classpath Mechanism – The complication of classpath management had made it virtually impossible to run a non-trivial application by hand. Have you seen the classpath’s of a production application? God help you if you just need to start it on a Terminal.
7. Runtime and System – Seriously, can anyone ever remember what feature lives where? Why are these two separate classes? I have to pull out a damn reference manual every time.
8. Preferring Verbosity Over Ease - I know, I know, there are a lot of reasons to not support operator overloading in Java, but there are times I would love a little conciseness.
9. Strong Conventions Should Be at Compiler - Yeah, this one is going to sound stupid, but it’s something I think the language should have. Sun is adamant about using a strong coding convention. And people are very good at following it. It’s one of Java’s biggest strengths. I can download any Java API and easily read it, because the code is going to look like all other Java APIs. This is powerful. Enforce it! If you don’t following convention, have the compiler catch it. I’d prefer an error, but a warning would work.
10. instanceof and Casting - Lastly, if I have a block of code that checks instanceof, why are you making me cast in that block’s scope? Be smart! I just made sure it’s the right type, don’t make me create a cast.

And that’s it. 10 things. That felt good to get off my shoulders. I love you Java, we good, right?

I was listening to the Stack Overflow podcast a few days ago. Either Joel or Jeff (can’t remember which) mentioned that one should always figure out what they hate about their favorite language. Basically, the premise was, you don’t really understand the language well enough until you can look at it honestly warts and all. This seems like an interesting exercise, and I thought it would be fun. So, I am going to start a little series of listing 10 things I hate about a particular language (not worrying about the favorite part). I will add to the series as I get comfortable with new languages as I am learning. Which leads me to another goal to learn a couple languages in my own time, so I’ll know that I haven’t “learned” it until I am comfortable enough to honestly hate it.

Every single morning I wake up to a huge amount of posts in my feed reader. Here is how I manage it.

First, I make use of Google Reader and NetNewsWire. NetNewsWire hooks into my Google Reader account and keeps it in sync. Google Reader is great, but NetNewsWire adds a level of polish to my primary computer.

Secondly, I have an Instapaper account that saves web pages to “Read Later”.

My morning ritual involves me quickly scanning through my NetNewsReader. If I see an article that is long and in-depth that I’m interested in, I don’t read it then, I instead hit the keyboard shortcut to “Add to Instapaper” (or use a bookmarklet if I’m not on my primary computer).

The only articles I read in the a feed reader are short blurbs or equally quick reads. Everything else goes into Instapaper.

Periodically, when I have 15 minutes free, I’ll check for something to read in my instapaper account.

Doing this prevents me from spending 2 hours in the morning getting caught up with RSS feeds or, alternatively, missing a great article.

In Predictably Irrational, Dan Ariely discusses Procrastination and a human beings tendency to under estimate their resolve and ability to stay ahead of the game. During an experiement he took three of his classes and gave them an assignment to write three papers over the course of the term.

“As they settled into their chairs that first morning, full of anticipation (and, no doubt, with resolutions to stay on top of their class assignments), the students listened to me review the syllabus for the course. There would be three main papers over the 12-week semester, I explained. Together, these papers would constitute much of their final grade.”

From the outset the students understood the importance of these papers, they would pretty much amount to their final grade. Each class was given a different schedule, the first was given three due dates (4th week, 8th and 12th), the second class was given a sheet (a tool) with which they were to set their own deadlines and turn that in. They would be held to these deadlines. The third class was told to turn all three in at the end of the semester, they could turn papers in early, but there would be no extra credit doing so. The class that had the equal due dates set for them did the best, those that set their own due dates were second and those that turned them in at the end of the semester did the worst, by far.

“What do these results suggest? First, that students do procrastinate (big news); and second, that tightly restricting their freedom (equally spaced deadlines, imposed from above) is the best cure for procrastination. But the biggest revelation is that simply offering the students a tool by which they could precommit to deadlines helped them achieve better grades.”

So, the best way to achieve your goals is to have some Draconian force from above giving you hard but reasonable deadlines. Failing that, give people the tools they need to combat the need to procrastinate.

Agile Development has had a huge surge in the last 5 years or so, to which I believe owes its success by helping people fight off the tendency to procrastinate. Scrum and other Agile methods give developers the tools to set the appropriate deadlines and meet them. Imagine if Agile is the second class in Ariely’s study with Waterfall being the third.

Waterfall development defines a rigid structure of Gather Requirements, Design, Implement, Test, Maintain. However, it doesn’t provide a good mechanism for applying appropriate deadlines (that is up to the higher level management, who typically just want to see the finished product by a certain date.) Therefore, the development team may have a couple months before they have to show anyone anything. Making it that much easier to put things off early in the development cycle.

While, Scrum instill shorter milestones (one month or less, typically three weeks) with something demonstrable at the end. There is the first tool to fighting procrastination, there is less time to do so. Secondly, every developer is given a larger task (Story) and breaks them up into smaller tasks, typically a day or less. With this, it has given each developer the tools they need to set their own deadlines with daily tasks, further reducing the time to procrastinate. Thirdly, daily meetings with peers are used to update the entire team, quickly exposing any potential procrastinators out there.

Agile has a multitude of benefits, helping people understand their work habits and tendency to procrastinate being only a small part.