Is anybody doing this yet? I made an effort to use RSpec for iPhone development almost a year ago but got stumped on Ruby mock objects that didn’t seem to to play nice with CocoaTouch objects. I got a lot closer than my blog post would lead you to believe but stopped due to deadlines, and my lack of experience with both Ruby and ObjC. Tonight I dug up the old project and tried to remember where I left off…

…Aahh it’s al coming back to me now! I had wrapped the MockObject support in Ruby to ensure it received parameters from CocoaTouch. For some silly reason parameters passed directly from CocoaTouch objects are dropped/ignored by whatever mock framework Ruby is using with RSpec. Forgive me for not knowing more about the internals but I don’t do Ruby and this was from last November. Here’s an example of the RSpec I modified to allow parameters to pass cleanly. It also has the buddings of a dynamic message dispatch thingy I couldn’t get working because it makes no sense to hard code every anticipated method invocation. If one of you Ruby guys could jump in and patch this up or if somebody could point me to an already viable alternative that’d be so swell…

require File.dirname(__FILE__) + '/test_helper'

require "BowlingController.bundle"
OSX::ns_import :BowlingController
OSX::ns_import :BowlingProtocol
require 'delegate'

include OSX

class ObjCMock
  attr_accessor :delegate
  def roll(num)
    @delegate.roll(num)
  end

  # def method_missing(m, *args)
  #   puts "Forwarding message"
  #   @delegate.send(m, args)
  # end

  def initialize(theMock)
    @delegate = theMock
  end
end

describe BowlingController do
  before(:each) do
    @controller = BowlingController.new
    @bowling = mock('BowlingProtocol')
    @bowling.stub!(:roll)
    @controller.bowling = ObjCMock.new(@bowling)
    @text_field = mock('Pins')
    @text_field.stub!(:intValue).and_return(10)
    @controller.pins = @text_field
  end

  it "should roll a ball" do
    @controller.roll
  end

  it "should roll a ball and get the value from the pins outlet" do
    @text_field.should_receive(:intValue).and_return(0)
    @controller.roll
  end

  it "should be an OSX::NSObject" do
    @controller.is_a?(OSX::NSObject).should == true
  end

  it "should have an outlet to a bowling object" do
    @controller.bowling = @bowling
  end

  it "should send the pin value to the bowling object" do
    #This line wraps the mock with the class defined above
    @controller.bowling = ObjCMock.new(@bowling)
    #The following line will cause failure calling directly into the mock
#    @controller.bowling = @bowling
    @bowling.should_receive(:roll).with(10)

    @controller.roll
  end

  it "should have an outlet to the score" do
    @score = mock('Score')
    @controller.score = @score
  end

end

//
//  BowlingController.h
//  BowlingController
//
//  Created by FIXME on 2008-11-10.
//  Copyright 2008 FIXME. All rights reserved.
//

#import "BowlingController.h"
#import "BowlingProtocol.h"

@implementation BowlingController
@synthesize pins;
@synthesize bowling;
@synthesize score;

-(void) roll{
	int val = (int) [self.pins intValue];
	printf("Value is: %i", val);
	[self.bowling roll:val];
}

@end

// This initialization function gets called when we import the Ruby module.
// It doesn't need to do anything because the RubyCocoa bridge will do
// all the initialization work.
// The rbiphonetest test framework automatically generates bundles for
// each objective-c class containing the following line. These
// can be used by your tests.
void Init_BowlingController() { }

God rest his soul, Michael Jackson moved on yesterday. I don’t normally post about pop artists but this is Michael Jackson, plus I got Gospel classics playing on Pandora (Carlton Pearson – He Lives) and it kinda sets the tone for more serious writing. It goes without saying the Michael was a pop icon and possibly the most recognized and talked about person on the planet. We all have our favorite songs and most of them are likely from one of his first couple of solo albums. You know where you were when you first tried to do the moonwalk. You know how you felt when your buddies lied and told you how you were gliding. “Are my feet right? Was that the move?” Don’t act like it was just me! How many of you kicked somebody else in the face trying his signature leg lift? And I’m not the only one that almost got a nose bleed trying to find the last “authentic” copy of his “Beat It” jacket (with all the zippers) from the swap-shop. Forget the tabloid nonsense that everyone brings up. We know he had problems but who of us doesn’t have any secrets? What if somebody came up in the back of your closet with the 300 watt flashlight shining all on yo’ underwear stains? Let the man have his legacy, stop bringing up the dark stuff. Michael was a legend that changed the way we all danced… sang… watched TV… talked (Sha’mon! What the heck does sha’mon mean?)… dressed… and wore our hair. (Say what you will but you know you had a curl or some sort of wet look back then!)

Lots of stuff missing my radar. First off, AOL/MapQuest is getting with it. If you don’t know where it’s at now you know. you’d think I’d have something to do with it but I don’t. We’re doing all kinds of live stuff lately. Most important is the dropping of MapQuest 4 Mobile on the iPhone. This project, code named Ice internally, was my first attempt at iPhone hackery. It became the #1 navigation app on its release date yesterday. A small team of us at MapQuest hooked up with a larger team in AOL and the end result is something I’m proud to have played a part in. If that’s not John Blazed enough for you then there’s the bit on Maxwell. One of my favorite artists is making his comeback and y’all gotta show him some love. All this and more comin at’cha from AOL. I wish I could ramble more but there’s some particularly difficult stuff I gotta get back to.

This has been confirmed by an unidentifiable but highly reliable source who commented here. (How do we know the source is reliable? We’ve confirmed that by not revealing his identity.) While we all “looked forward” to the return of Steve Jobs we now have the guarantee of his return to Apple. Look for stock prices to jump by close of business tomorrow when an undisclosed press release scheduled for select members of the media is said (By whom? The unidentifiable source! That’s whom!) to announce the return of the black shirt wearing mogul to the Apple empire. Also revealed by our insider, Apple decided to delay the release of iPhone 3G Os until absolute time period that coincides with the time slot of Steve’s official return to Apple. Remember where you heard it first! This breaking story along with others has been brought to you in part by:

Juxtaposition: With just as many letters juxtaposed you get a tax deposition or something close in spelling. No doubt Juxtaposition is responsible for the confirmation of many rumors floating around the internets.

HBCU: While not directly responsible/knowledgeable of any content posted here, HBCU.info makes it easy to connect with friends, create, share and discuss your status, share your photos, and help the development of future Historical Black Colleges and University (HBCU) students all while putting an emphasis on getting the word out about campus happenings. Its this very ease of connectivity that results in the majority of our internet communications.

J2MEPolish: For getting those tough hard to reach stains out of the crevices or your mobile phone try J2ME polish. It removes more stuck-on dirt than the leading polish.

TechKnow: GI Joe said, “Knowing is half the battle”. The other half is knowing which half you’ve won. If you don’t know, now you know… y’know? If not, drop by TechKnow and tell’em I sent you.

A little while ago I posted a great idea involving hacking your prestine XCode install so’s you could take advantage of SVN 1.5 without shelling out dollars for extra tools. As it turns out I had my manager shell out dollars for extra tools. If you visit my site enough you’ll notice a pattern in where I profess to know something that I just read from someone else’s blog minutes ago, thus bolstering my ego, adding cool-points to my imaginative reputation, and thrusting myself on a pedestal slightly less than double the elevation yours. You’ll also notice that most of what I say here should be taken with a grain of salt (and two, that’s exactly two, packets of Splenda). Lengthy story decapitated, my tip for SVN/XCode, while truly functional, would create problems in any existing web-share you have configured for your Mac. (Web Sharing is the little apache daemon that is controlled by the check-box in the “Sharing” preference pane which is invoked by calling up Spotlight, typing share and mashing the enter key.) If you followed my instructions step by step then you can recover by spinning the record back. That means follow my directions in reverse order. Merely dump all of your svn-bkup files back into /usr/lib/ and be done with it.

Recently Apple released iPhone SDK 3.0 beta and with it XCode version 3.1.x. (The SDK may just as well be XCode though I believe it’s available/usable outside of XCode if your hard core enough and your middle name happens to be Gnu. Also I can’t remember the digit for ‘x’ so shoot me!) In the release notes… you know those little things that tag along with new software? Yes I read the release notes because they tell you what’s bundled in the release. Anyhow, in the release notes they announce that XCode now supports SVN 1.5! Yay 1.5!!! I was just about to try to upgrade to Svn 1.6 by the by. So I roll back my earlier 1.5 hack because I wanna finally be able to use web sharing and viola! I no longer can use SVN from XCode! Maybe I should try running the installer again. Maybe I should just stop hacking my internals…

Getting frustrated by this bug. It’s been annoying me for the past couple of years and it still doesn’t seem to be fixed! If anybody has a plausible workaround please speak up!

I’ve been interacting with many more developers in my current company than I ever had in other companies over my career. One pattern I’m noticing is the warm/fuzzy philosophy. That is when somebody gets really comfortable with a certain way of doing things then you show them a new thing. Eventually they will find a way to use or associate the new thing with the way they always do things in order to get that warm/fuzzy feeling of, “it’s just like the other thing.” Hi, I’m Cliff. You’re here because you were probably looking for a product like Sham-Wow, Googled “warm fuzzy“, and clicked on a link to my crazy site. While you won’t find anything that sops up 32oz of Kool-Aid from your hard-woods after a three-year-old decided to play monster trucks on the kitchen table you will get a lesson on how to forget what you thought you knew. Wait a minute, I forgot where I was going with this. You’ll get a lesson on why you should forget what you thought you knew. How to displace that knowledge is an exercise best left to the reader… (You, being that reader… you don’t get much exercise do you? Not with all the online reading and stuff.)

So when I talk to people and explain TDD (hereafter referred to as “the solution”) I usually get the response “it’s kinda like that system I used back at my other job only then we didn’t automate. We were just…”? Better? Honest? More careful? Clever? “Yeah back then we used to catch all of our bugs and…”? Re-fix them? Explain them as features? Double them? I occasionally get responses like, “you really don’t need to test first to get good code.” Let me ask a question. Have you ever seen good code? What does it look like? Does it where a tight-knit skirt and flirt from the corner? Does it come with a “HEMI” label, high RPMs, dual exhaust and chrome wheels? Is it tucked between two all beef patties, special sauce, lettuce, cheese, pickels, onions and a sesame seed… What does it look like, really?

What should it look like?
Call me crazy but I believe code (good, bad, ugly, and indifferent) should look like your spec. Do you know what your spec looks like? No you don’t! Because it just changed! Look again. There, it changed again! A decent spec is like a chameleon. It constantly changes colors, shapes, sizes. (For the record, chameleons don’t change shapes/sizes unless you put them in a blender. It has been proven that such a device, when activated, can render a chameleon very small and suddenly change both the size and appearance of the creature.) A poor spec is like a TV guide from 1976. It’s nostalgic to think about what was showing back then but of no use to anybody that wishes to figure out which station to tune to catch Judge Judy at 7:30EST. That is, it doesn’t tell you what you code should look like right now or what it should look like tomorrow. Did you catch that? I just explained that you need a TV guide to figure out what your code should look like tomorrow… not just any TV guide either. You need tomorrow’s TV guide, well, because it has tomorrow’s TV listings. Let that sink in a moment while I grab some coffee.

Warm/Fuzzy
“Writing tests is like the ECMO system we had back at Rutherford And Son’s company. ECMO was the Enhancement/Change Management Officer in charge of each project. That person was a developer incharge of reviewing your code prior to commits and…” What was ECMO looking for? “We shouldn’t waste time futzing with tests… We just need to designate a [insert warm-fuzzy here]” What does any warm/fuzzy recreation of last year’s change management solution attempt to find? Defects, violation of practices, and unapproved system calls/libraries come to mind as common things to look for. What does any of this have to do with the spec? What does that spec look like again? “Who cares! We’re about to land some code, man! Plus we have approval for the EZ-Test framework which comes with new improved static analysis support.” (Ever wonder how new-improved some products really are?)

What Bad Code looks like
The unfortunate side effect of warm-fuzzy is that it fools you into believing that you’re creating good code. We all have seen Jeff Atwood’s Horror code examples so there’s no question of what bad code looks like, right? Bad code has a smell. We don’t write no stinky code here because we have ECMO! (Trumpets blare to the sound of the Nightly News theme song introducing Brian Williams.) Warm-fuzzy overlooks a subtle point of the agile philosophy. It’s not practiced to get good code, it’s a means of getting correct code. We’ll come back to that point in a moment. Let’s forget warm fuzzy for now. Let’s forget all we remember about ECMO. Let’s forget everything we were ever taught about good code, bad code, Dallas Cowboys and the Indiana Pacers.

Ther UnLearning Curve
Because technology constantly evolves our understanding of it must evolve. People learn things by association which makes picking up new technology and concepts a challenge. With technology you can flip a bit in a micro-processor and dramatically alter the flow of an application. Subtle changes can reveal brand new concepts that completely disassociated with our understanding. (Try explaining the subtle change of a pointer variable which holds an address rather than a value to a Comp. Sci-101 student who only knows Java or VB.) In short, we have to unlearn to evolve. Remember the goto statement? An entire evolution of sub-routine evangelists had to scrub the planet and assassinate all other developers on the planet before it finally got removed from modern languages. Believe it or not, there’s another similar revolution happening between those who do/don’t program with assignment statements. (Maybe one day they’ll remove the equals symbol from your favorite language… sounds far-fetched but so did dropping goto.) Those who lived by the word “goto” were hung up on it’s warm/fuzzy benefits so much that when you explained a subroutine to them they understood only to the point where it would return back to the caller. You truly had to changed your views/ideas/opinions on program flow and structured thinking in order to “get” subroutines. Simply stated, to learn new technology you often have to dis-remember old technology… the benefits in particular.

The Solution doesn’t care about good code
That’s a strong statement to make, but if you ask anyone who understands the true benefit of a philosophy of the solution they’ll tell you that it’s perfectly acceptable to use it with bad code. In fact, some may encourage you to write bad code in order to get a green bar. Better stated, instead of getting the code right you want to get the right code. If I pay you $50K for transportation what will you build me? A car right? Not just any car but a nice sports car with variable five speed transmission, anti-lock brakes, dual suspension and an auto-defog mirror. Nice! Good for you! I’ll go drive you’re treasured car into the ocean because I needed transportation to return to Jamaica and visit my long lost relatives. (What did your transportation spec look like again?) I would have been soo much better off with a shoddy rowboat than I’d ever be with my soggy car. Sure you got the transportation tool right. You even went as far as to pre-load my favorite MP3s. That’s how lots of people work because they’re stuck in “go” mode. Management says go! Get it done!

With software it’s soo much more dangerous because we can be creative and sorta dig ourselves out of the ocean. Many developers, after loading Method Man’s “What Thee Album”, would eventually realize that the delivery date is approaching and maybe they should ask for a destination. I love it when we get to this point because that’s where the creativity truly begins. You might see fins under the tire, or a possible grappling hook that fires to attach to the complimentary aircraft – yet in design. Rarely and only in the most extreme cases does the car get dismantled.

To the left
The solution puts the focus on the left [consumer-facing] side of the code (which is why we lefty’s have so much fun with it!) The shape of the calling code becomes more important than the shape of what others refer to as “the real code”. It feels awkward because we think of ECMO. It feels redundant and slow because we already visited the left side of the equation. We know what we’re doing and we don’t want to waste time obsessing on the left side of the product. How many times should we keep asking “you want me to build you some transportation, right?” So to appease other idiots who obviously think it’s important, we ask a few more questions, like “where are you headed?” When we get a typical answer like, “far away to see my family” it further underscores the time wasted on the left. We then assume total control of the decision making process because our customer is clueless. “You’re obviously going to need dual overhead cam for speed since it’s so far away”, we think to ourselves. Many of us have gotten so good at it that we could literally assemble half the car before asking a third question.

I would continue my babbling but I have to cut it short because I’m off topic. The general idea is lost up there somewhere I’m sure. For all my people that understand where I’m going here speak out and nobody will care. Nobody will care because you’re expressing your opinion here rather than on Slashdot or The Server Side, or some other popular network. Here it’s just you, me, and the chickens… and the chickens have automated regression suites so we should listen to them instead. I now step down from my soap box and yield to the poultry.

It’s a dumb question, I know. Still I can’t help but wonder how programming evolved in other countries. Think about it a moment. Programming languages are shaped around the English grammar, many of them created to resemble the English language as closely as possible. If you come from a foreign country, like Russia or Japan then wouldn’t you have double the learning curve adopting a grammar that’s based on a language that you don’t speak? I bring this up because I am a huge believer in the fact that programming languages are made for humans. That means the grammar, syntax, and idioms present in the language should map closely as possible to the grammar, syntax, and idioms you use every day. It’s when they don’t line up that we begin to have problems.

Let’s think about it another way. Suppose we had Japanese, Russian, Swedish, etc. compilers. What problem have we solved? What problems have we created? What is the net profit margin on the problem exchange? (That last sentence means did we end with more or less problems than where we began. Don’t ask why I worded it so weird. I have a habit of making things more complicated to justify my existence on this planet.) If we create locale-specific compilers to deal with the user’s specific semantics then we’ve solved the problem of user program-language comprehension and closely lined up the program model with the user model. This is a huge profit that should not be under estimated. However we’ve introduced the possibility of cross country code sharing as program source written in Italy will not compiler with the German-Java compiler. We could, of course, include the Italian-Java compiler but the new user now suffers from the original problem we set out to eliminate.

I’m not pretending to have the answer to the problem here. I’m not even suggesting a problem to begin with. See I don’t get out often so I don’t think I could even pretend to know what a Finnish Python script would look like. I was just sitting here reading a tech article when it dawned on me. How the heck did the original Chinese programmers adopt C? (Was it C or was it something more esoterice like Fortran or ADA?) Also, why come (yes I said “why come” all ghetto-like instead of “how come”. It’s my blog and you just have to sit there and read it…) there ain’t no wide-spread programming languages that are based on foreign languages? Hit me up if y’know what I don’t know, y’know?

Given that you use servlet containers for building Web applications and EJB containers for building transactional applications, you may be wondering why you need yet another type of container. The short answer is that OSGi containers are intended specifically for developing complex Java applications that you want to break up into modules.

I’m not cracking on anybody but hear this. It’s my first introduction to a new technical concept, OSGi. Taken alone, OSGi is just a random assembly of a subset of the alphabet. Like many of you, I’ve sweated through EJB, become slick with Servlets, and sweetened up to the Springframework. The last thing I need/want/desire/dream/look for is a container. The nothing scares me more than the need for complexity in Java, other than the thought of a horde of miller bugs tap dancing across my forehead in the middle of the night. (Actually, I take that back. I could live with a night time tap-dancing surprise as I eventually attend counseling to erase the terrifying memories.) I’m still thinking (praying) OSGi could be a lot of fun. Check back for updates as I try to catch up on this and other things I forgot to learn in Kindergarten…

How many times have you tried to buy a product and the salesperson annoys you with extra deals, warranties, options, newsletters, craker-jack prizes, and/or so forth? How many times have you tried to install some software, or download some package with a fancy package manager and felt like the entire internet was plowing its way through your ethernet port? Hi, my name is Cliff and I only want one. I just want the one thing I came for. I don’t want the optimized gcc compiler version-3.3.x. I don’t need the Darwin compatible Linux header files with Wine support. Please don’t pull down yet another JVM. I only want the one thing I came for. Just that one thing. I don’t need or desire a warranty. Don’t sign me up for your weekly newsletter, I can barely keep up with my overloaded inbox now. (Somewhere buried in there are the letters from the online Heroes graphic novel/game/series that I never got to participate in.) Yes, I understand fire insurance is optional and I don’t plan to go dancing around a burning man celebration with my shiny one object of desire and if I did I would gladly accept the consequences of my own poor judgement.

Why is it that people still think you are so enamored with their product that you’ll surely want to be part of their company and evangelize in their vision? Here’s the deal. A product download site should look like, NO! Scratch that!!! A product’s home page should announce three things at the top of the page. These three things should overshadow everything else. They include a brief, pointed description of the problem the product addresses and possibly why it’s better than any competing product. Easily accessible screenshots of the product in action. (It helps if the screenshots are linked from thumbnails.) And… most important… above all else an easy to find download link that refers to an auto-download page which includes a three step or less install guide. (The install instructions should also be included in the downloaded bundle for the guy who’s too impatient to keep the browser tab open long enough to read/notice the install instructions.) Nothing else matters on your product’s home page. Move the pictures of your kitten to your weblog. Add the vision as a footer link with 9 point font. Host your news feed on a separate site. Too many times have I tried to find a package only to be barricaded by the philosophy behind the vision that inspired the package, or news updates regarding “our project is once again active under a new lead” or, “our host is now doubling our bandwidth! Yippee!” I want the binaries then I want to return and get the source. I don’t want to compile your source from make. I don’t want to download your source from git. I don’t even know how to get git???!!! Yes you, your best friend, and your lawyer are all part of the Bzr craze but I still use svn 1.4. I don’t need to be directed to some forum post where you remembered to finally post your idea on page sixteen of some twenty-seven page thread. I understand how these things come up in forum discussions but for pete’s sake (or at least for Cliff’s sake) provide an official download site with a “download here” link. If that’s the only thing on the page then it’s better than scouring the net piecing together random parts of something that you finally find out is a dead end and will never compile/run/light-up on your device/phone/laptop/operating system.

I realize I am guilty of my own frustrating predicament as I write. I remember the unfinished Groovy Invaders, GSpec and some other ideas I left scattered around various sites. Having now felt the pain I promise never to leave an idea undone. I should now build the download site for my Blackberry-Maven plugins. I also need to do the same for my Maven-Gant plugin. That said, don’t be like me. Don’t leave a fellow developer in distress. Finish your thought. And while you’re at it, reply to one of those zero answer posts in the forums from 2006 where the guy was asking about the thing that you specialize in. I hate seeing the same question in one or two forums phrased slightly differently but with zero replies in either place.