Mojomonkey Coding

Man power at a company is easily the most important equity you have. It’s not the awesome state-of-the-art server rack, it’s not the worthless software patents you hold, it’s the people. For this resource to operate at peak efficiency, you must keep the people happy. An employee who is happy about the working conditions and foresees a future with the company will produce significantly better and substantially more work for you.

I’m continually surprised when decisions are made that are a detriment to the employees to save a few dollars in the short term. You should be spending MORE money to provide your team with the best environment possible. Large work areas with substantial personal space, computers that are top of the line (go above and beyond what you believe the developer will need). The best chair you can get, the best food in the break room, etc. Per employee this probably adds a couple thousand dollars more a year than you would get otherwise. But, I guarantee you will make that back and then some by employees who are happy and feel appreciated.

The MOMENT you start cutting corners at the employees expense you are creating a long term expense that you may not be able to recover from. Resentment will swell and is contagious. People will start doing the minimum to get by and not get fired. You will lose any of the work that people do that go above and beyond the requirements, and that is the work that push a product from being good to being great. Higher management usually seems oblivious to employees losing that drive (they must be oblivious to have made the decisions in the first place). They don’t see many people quitting, so feel that everything is good. However, an unhappy employee quitting is not the worst thing that can happen, an unhappy employee staying is. An employee who feels under appreciated and beaten down will contribute very little to the whole, and will often times enlighten employees who are less aware of the poor treatment.

There is such an easy fix for the whole issue. Don’t treat your employees like shit, give them the absolute best, never cut corners, never treat them like whiny ungrateful sods. Never assume that one complaint is an isolated event, but assume that it is a complaint shared by everyone. Spend more money up front, and treat it as an investment in the greatest capital you have that is guaranteed to pay off dividends.

Ah, the most dreaded error. Your app crashes unexpectedly and the only output you have is EXC_BAD_ACCESS. Not a lot of information, and for someone from a Java or other higher level language background it can be very frustrating to track down. First of all, make sure you are running in debug mode always (even if you don’t have any breakpoints). This will give you a stack trace of what generated the EXC_BAD_ACCESS. Again, this may not actually tell you where the problem lies, because all EXC_BAD_ACCESS is telling you is that you are attempting to reference a pointer that is no longer valid. Therefore, at some point previous (unknown where or when) you blew away a pointer you shouldn’t have. Here are the three most common (in my case, at least) causes for these, and how to help mitigate or track them down.

Over Release – You’ve released an object, its retain count has gone to 0 and you try to access it. This is probably the most common thing that bites you when first starting out with Objective-C while learning how to manage memory. The stack trace will at least given you an idea of what object is over released (it may be an object owned by the one pointed to in the stack trace), and if you have designed your code well, encapsulation should keep you from having too many places to check. And trust me, encapsulation is key to minimizing the pain here, if you are throwing references around all over the place retaining and releasing, you are in for a world of hurt.

Once you have all the places that retain/release occur for that object, just make sure you have a one to one ratio. Apple provides a great Memory Management Document and is highly recommended. Pretty much, the gist of calling release is do it ONLY if you call retain, alloc or copy. That simple (but still easy to forget).

dealloc – This is one that bit me, and took awhile to track down. When you override dealloc on an object, remember to call [super dealloc] as this cleans up the object up the chain until it reaches NSObject and does the low level cleanup. When overriding, you need to release any objects you are managing as well. However, my biggest lesson learned here, is calling [super dealloc] LAST. I had called [super dealloc] before releasing my objects and started getting EXC_BAD_ACCESS errors. So, I spent multiple hours trying to track down a retain/releases inconsistency. Until finally realizing, that by calling [super dealloc] before cleaning up my objects, I had lost my reference to those objects.

stringWithFormat – If your stack trace is pointing to a bit of code where you are constructing a NSString via stringWithFormat, confirm that you are not trying to send a primitive (int, float, BOOL, etc) to %@. The runtime is attempting to access memory at a location of the primitive’s value. Let’s just say, I’ve done this more than once.

Those are the top three items that cause me grief with a EXC_BAD_ACCESS and the first three things I check when it appears.

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.