We ain’t got no RSpec

Posted by Brian Fending on July 17th, 2008 — Posted in Music, Rails, Social Media, Technology

I don’t subscribe to many podcasts, but definitely give RailsEnvy a listen when I find the synopsis to be of interest. They recently did something quite interesting and set up a voicemail box to get feedback. Another of their listeners, frustrated that he only uses console to build applications (as I do), left a voicemail that the RailsEnvy people have aptly labeled, “We ain’t got no RSpec - Best Voicemail Ever“. Check it out - and definitely listen to the original voicemail before consuming the “remix”. It is a testament to their creativity as product evangelists and marketers.

CodeIgnitor + Prototype

Posted by Brian Fending on July 3rd, 2008 — Posted in Code, MVC, PHP, Technology

I was at a PHP User Group meeting earlier this week where the presenter was extolling the virtues of the great Symfony MVC framework for PHP, which he started using last month. I’ve been experimenting with it for a few months longer and shared some of the same reactions when I first started a few experiments. I had to leave about thirty minutes in, and no doubt I missed some really hot PHP action, but there’s another MVC I’ve been toying with recently, CodeIgnitor. Couple this with the javascript framework Prototype, and the possibilities are not just endless… they’re really *^%&%$# fast.

That’s my major complaint with untweaked Symfony projects - speed. CodeIgnitor, while it requires you to CODE a bit more (than in Symfony) to accomplish your (same) goals, is blazing. What Prototype gives you is a means by which you can get fast responses on the page (AJAX functionality). This, when you think about making on-screen updating of information *even faster* than conventional PHP, is an amazing concept.

Anyway, I’m working on something that I hope to Beta in a few weeks using this dynamic duo. It’ll be a Web app that works well in mobile browsers, including BlackBerry devices complying with the RIM cHTML constraints. And it’ll be smokin’ fast.

Project SocialSite by example

Posted by Brian Fending on June 17th, 2008 — Posted in Social Media, Technology

This is really quite cool: Embed, for example, OpenSocial containers within something like MediaWiki. All part of the kooky fun (still) going on at Sun’s Project SocialSite!

Building a Company in your Head

Posted by Brian Fending on June 17th, 2008 — Posted in Technology

This is a fun exercise: Who are you working with right now - either in a full time gig or in your consulting practice - that you could throw together to run a company starting tomorrow? I have a short list of people that I like for this, but don’t know that I have all of the necessary players to run a startup. For example, I think I have all of the technical and sales heads, but not the marketing, financial, and general support people.

Who are you missing? And why is that, given that we work for or with already-functioning companies?

Carts & Horses

Posted by Brian Fending on June 9th, 2008 — Posted in Process, Technology

I get a little strong-willed when it comes to doing things the right way. (Read: “Pimp slap.”) Whether it’s telling a company they *need* a development server and can’t get away with a super-secret directory on their live Web server or informing someone that finding a company willing to do your bidding does not constitute “market research,” I’m willing to put it out there that certain levels of effort are unacceptable. After all, the whole “it costs money to make money” thing surely crosses over to, “it takes time to save time,” (bear with me) and, time=money being a given, you need to invest time in proportion to the money you wish to save or make. Right? Well, maybe that’s too convoluted now that I think of it, which may be why it takes a little while to convey these points. I’ll work on it.

Anyway, I got an email from somebody today who was looking to investigate his company’s alternatives to a current email marketing ASP (”outsourced application”, to all of you business folk). The first step? Have the current vendor in, before all of the users of the current tools, to pitch their next-generation solution(s). Never mind that there are ongoing issues with the current product, this demonstration would serve as this company’s baseline for future requirements for applications of this type.

Now, I’m no Harvard MBA… but shouldn’t you sort of figure out what you *want* to do, then try to find a product or suite to accomplish that business goal? I understand to a point just needing to know what *is* possible with any product. That’s market research, reading product slicks, having calls, etc, etc. I also understand that a lot of business users are of the consumer-oriented “deliver me a product to start using tomorrow!” mentality, but this was a seasoned IT person. No kidding. Let the current vendor - with the awful API and really bad implementations - set the stage for Round Two.

I emailed him back, upon learning of this approach and said something to the effect of, “learn what kind of features you want in a car before you drive your car to the dealership for a trade-in… you may just want a different kind of car.” Man, my analogies are weak these days. Anyway, Horse precedes Cart. Requirements precede Vendor flying in for the day. It’s possible to do this with a cross-functional team without a waterfall approach, but even that doesn’t change that defining the business need always precedes a gap analysis. I don’t care where you went to school.

ED. COMMENT (16 Jun 2008): I got some offline backlash for this post from somebody familiar with the situation. I guess my blog is more widely read than I thought. They cited routine vendor management, good practice, no current project, blahblahblah, but it was still - I maintain - awfully bad form to ensconce vendor management in defining the baseline for future requirements (in no uncertain terms!) based on what one vendor has to offer. That’s how companies head down tunnels, and this is no exception. Talk to a vendor all you want, but to prep your business audience with language that invites them not to do any market research - but to rely instead on what this sole, trusted vendor has to say - and you’re doomed to repeat some mistakes.