If you’re interested in being able to track your time when you’re not in front of your computer (i.e. when you’re working on your next flight or are running errands...) then head over to the AppStore and download the free iPhone Harvest app.

Those of you who’ve already taken a look at our recent release of ObjectiveResource at iPhoneOnRails.com will find it as no surprise that the Harvest app is yet another use of ObjectiveResource to integrate with a Rails-based web-service.  It simplified a large chunk of the work for this project and we hope it has the opportunity to do the same for you.

We found that framework, named ObjectiveResource, served us quite well on that job and on our subsequent iPhone apps.  So much so that we thought some others might find it useful.

We’ve put up iPhoneOnRails.com as a site to both publicize and organize the development efforts around ObjectiveResource and anything else that springs up from the effort.  If this sounds like something you might be interested in, please head on over and maybe join one of our community discussions or fork and play for yourself.

Let us know what you think!

From the start we wanted to make it more stylized and legible than all the other iPhone dictionaries that are out there (and there are plenty).  Most seem to just cram as much text into a page as possible, with no regard to typography, structure or semantics.  Credit goes to Brandon Mathis for choosing a font and structure indicative of a print dictionary and one that’s easy to read on the iPhone.

We also tried our best to combine the feel of a printed page with usability enhancements the iPhone allows, like the ability to quick-scroll through to the various parts of speech and the ability to lookup a word definition from within any other definition.  Check it out at the AppStore and let us know what you think.

Some technical details for the geeks out there:

• 400,000+ definition dictionary
• 350,000+ synonyms and antonyms
• 190Mb embedded SQLite database
• Live-searching of words
• UIWebView powered word views

Squeezing the type of performance out of SQLite that’s necessary for live-searching of hundreds of thousands of words was a bit of a chore, but it performs quite admirably now.  Let us know if you’re doing something similar and need a tip or two.  We’d be happy to help out.

The new look encapsulates our growth from solely a Ruby consultancy to a more general technology solutions firm with additional native iPhone application development availability.  Being an independent firm allows us the opportunity to explore these new technologies, both to the benefit of our clients as well as ourselves, and we plan on making the most of this flexibility.

Download our new company profile document if you want to peek a little deeper into what Y Factorial does, or just see our new identity in document form.

Interested in talking with us about an opportunity you may have on the horizon?  Contact us, we’d love to chat.

yFactorial has recently taken advantage of this flexibility with a conscious decision to diversify from strictly Ruby-based work and into the iPhone development world.  While the geek in all of us needs no explanation as to the logic behind such a decision, the pragmatist in us thinks the iPhone will be a rich platform for which we can offer a lot of value.  Josh has extensive mobile development experience on a variety of other platforms and has already made the transition quite nicely.  Me?  Well I’ve got minimal experience in that area which brings me to my next point…

Why should you feel comfortable handing off your iPhone/iPod Touch development to us when only 50% of us has any relevant experience?  Because what you’re buying when you choose a development team is most importantly their ability to learn new concepts and apply past experiences and paradigms to new problems (not to even mention their professionalism, responsibility and integrity).

Whether it’s the jump from building a CMS web-app to a podcasting app your team’s ability to extend and apply their current body of knowledge to your particular domain is what will determine success or failure.  Is the transition from web development to iPhone development as effortless as that trivial example?  Probably not, but we believe the core assertion to be true - that our technical abilities and experience will make that a non-issue.

Still skeptical?  That’s fine, we don’t mind having to prove ourselves first and are currently actively engaged in our first iPhone project.  Expect more details to come in the coming months, but keep in mind what you’re really purchasing when you hire your next development team:  Exact technology matches on their resumes or the ability to leverage the full depth of their experience to your particular domain?

And don’t settle for what happens to come down the professional-pike.  Make your own career path.

Josh joins Y Factorial as my equal and I’m really looking forward to having his experience and productivity at hand for our next phase.  Plus, I no longer have to lay awake at night trying to wrestle with this conundrum.

Welcome aboard, Josh!

But here’s the rub.  I don’t consider myself to be creative, at all.  Does that mean that nature has somehow left me ill-equipped to be in the upper-echelon of technical minds?

After much distress at this idea of my innate shortcomings in regards to my chosen profession, I’ve come to realize that there is an important distinction between being creative and being artistic.  It is not in my nature to be artistic, but creativity is very much something I am capable of, and that is the skill that is required for software development.

So while artistic people have a natural foundation in both creativity and the arts, they do not hold an exclusive possession of the skills necessary to become an elite developer.

My point?  Don’t be intimidated by the people whose background seems to give them a natural advantage - it’s quite possible that you have the same skills wrapped up in a different package.

And so ends the feel-good post to start the new year.

I just went to download Radiohead’s new album, In Rainbows, and was presented with a form on the checkout page to let *me* enter the price I was willing to pay for the album.  And it wasn’t an auction type sale at all.  I entered 12 pounds (silly brits and their currency) and that’s what I paid.

What a great way to empower the consumers and what a great way to generate buzz in today’s age of the music industry’s piss-poor marketing.  Each subsequent download costs a negligible amount, so why not let the consumer decide what it’s worth to them?  Any amount paid for a download is pure profit and drives the real revenue stream of live shows and memorabilia.  Just beautiful.

I wonder how the market would respond to Y Factorial letting them set the hourly rate?  Not at all the same market dynamics at play, but it’s something I want to chew on.  Perhaps there’s a variant of the same concept that would be applicable?

Juicy stuff.

Fair?

Fortunately, the client and I had very open, honest and frequent communication (something I expect to achieve in all my engagements) and we were able to dissect what about the project was causing this situation.  Thanks to these frank discussions, in addition to good communication and well-defined requirements I’ve added the following to the list of characteristics I look for in the ideal job:

• Design & implementation freedom: Much of the joy I derive from the craft of software development is that there is always the opportunity for good design even with the most basic of implementation tasks.  Without the freedom to implement features utilizing, what I believe is, the best design methodology there is a propensity for frustration and lack of pride in the product.  This can be very discouraging.
• Minimal team size: The more moving parts there are in a development team the less work gets done.  With a language like Ruby and a framework like Rails there’s no reason to have anything but the smallest teams.
• Development process leeway: I love to work on the model layer and really refine the domain model and associations with strong unit tests before moving up to the controller layer.  It’s my preference to work from the inside out.  If a different approach is required then it becomes easier to lose the efficiency of my preferred approach.  Call it a flaw, but it is what it is.

This all seems a bit limiting, yeah?  What you probably hear me saying is that I only accept from-scratch, single-developer gigs from well organized and honest clients.  Well, that is an ideal circumstance, but I realize that can’t always be the case.  Rigidity is no man’s friend.

My point is more that you need to really think about what characteristics in a contract job (or any job) you need present to be motivated, and consequentially, successful.  Maximizing the factors that contribute to your motivation and efficiency will directly affect the client’s impression of you.  You won’t always get all your ideals, but you will at least be able to quantify the areas of risk to your client ahead of time and have an honest conversation about that area prior to any disappointment on any side.

Make the acceptance of a job a conscious decision based on well-defined criteria.

Choose the gig, don’t let it choose you.