It's Okay to Say "I Don't Know"

I've only been working in the tech industry for a couple years now and I'm starting to notice that people (and companies) have a very difficult time saying "I don't know" (or "no", "we can't", etc).  Why is this?  There's nothing wrong with not knowing something, as long as you have the skills and abilities to figure it out.

I was at a local BarCamp meetup a little while back and one the people there was talking about finding jobs.  At one point he said to never say you can't do something in a job interview or else you wont get the job.  I was baffled.  If you can't do something, why would you say you can?  At some point the truth is going to come out anyways.  Is this really what it's come down to?  A better question, do managers expect this when doing interviews?  Do they expect people to say they can do anything even though they can't?  I really don't know, but this kind of scares me.

I have a couple friends from Europe and they're just as confused by this behavior as I am.  Apparently they don't have a problem with this, if you have something on your resume you bloody well know how to do it, if you can't do something they expect you to say so.

And really, what is the problem with hiring someone that might not know every detail of everything the position requires?  If I were hiring someone I'd mainly be interested in their general problem solving and critical thinking skills.  Sure, you would need to have the basic skills for the job, but as long as it's obvious that you're smart and interesting in learning what you don't know what's the difference?  I'll take that over someone who doesn't care about the job and is just there for a paycheck any day.

What have your experiences been, have you noticed the same things?  Do you say "I don't know" enough?  Leave it in the comments.

"We need to accept our ignorance and say 'I don't know' more often"
- Malcolm Gladwell, Blink

Thinking about Testing

I've always been a big fan of including tests for any of the code I write.  It was beaten into us in university, made sense when using JUnit and made easy in ruby with Test::Unit.  Sometimes I still get annoyed when writing tests though.  I've been thinking about testing a little more than usual the last couple of weeks, mostly about what bothers me when writings tests.  I hate writing brittle tests.  I do my best to avoid this, but sometimes in a large project when you're trying to test everything it becomes difficult.  The other thing I really hate is trying to test everything.  I know, I know, code coverage is a good thing, but what good does 100% code coverage do your customers or users?  Does it make the app suck less?  Well, I suppose it could, but isn't it possible that 95% or even 80% coverage would be just as good (for the users), depending on what was tested?  I'd say it's very possible.

To get around my first annoyance, the brittle tests, I've started creating the objects that I need in the test itself instead of using fixtures (this is rails).  This lets me build up the objects for my test without worrying that adding another fixture will break existing tests.  This works alright for unit tests and smaller scenarios, but creates a bunch of duplicate code when a number of tests use objects that are setup in a similar manner (refactoring the setup into methods helps with this, but the tests get confusing as you need to jump around methods).

Next problem, I want to write tests for things that need to be tested, not some far off situation that I think could happen.  In Jamis Bucks talk at RubyConf, Recovering from Enterprise, he said that you should "code just in time, not just in case...there's no excuse to sit and play what if games".  I feel exactly the same way.  Now, I've been thinking over this for a couple days, doing some reading and whatnot and have decided (hope!) that RSpec will be my savior.  From the rspec.info site, "Rspec is a Behavior Driven Development (BDD) framework for Ruby".  The way it works is you write 'specifications' (specs) that define how the system should behave.  By writing he specs first and then writing the implementation methods afterward you are building, and testing, the system as it should behave; you're not testing arbitrary situations that probably wont occur.  Writing tests first and implementation code afterwords also has a neat catch phrase, Test Driven Development (TDD).  RSpec allows you to nest scenarios as well which helps me with the first problem I was having as I could build up the context of the test suite as I went, reusing the earlier setup if I wanted.

So far I've done a lot of reading and have written a few specs, but really haven't scratched the surface of what RSpec has to offer.  I'm not sure if this will solve all my testing woes, but it's defiantly making me think and test a bit differently, which I like.

Let me Introduce you to my Friend Bort

I was just getting started on a new rails project when I came across Bort on GitHub.  Bort is

A base rails app featuring: RESTful Authentication, Will Paginate, Rspec, Rspec-rails, Exception Notifier, Asset Packager, Cap Recipe (multi-stage).


That's pretty cool.  The current repository that's up on GitHub is based on an early release of Rails 2.2 so I've forked and updated to the lates 2.2.2 release (pull request is pending).  I've also made a couple changes because I like using mySQL, so changed the base configuration to reflect that.

I'm going to keep tweaking and updating my branch with the plugins and gems I find useful, feel free to branch my version of Bort or pull changes into your own fork.

Just F*cking Google It

Not really sure what brought it on today but I started thinking about how I don't really learn anything about programming or software development from books.  The world has changed and in IT things move so blindingly fast that by the time a book is published the technology you're using is out of date.  It's really interesting, these days having 'excellent googling skills' should be at the top of every employers list; if you don't know something you can bet that Google does.

I'm the first person to admit that I don't know something (though admitting that you don't know something or can't do something seems to be a no no these days...) but I sure as hell can figure it out pretty quickly.  I don't know why people are so focused on having every detail memorized, isn't having the skills to find a solution just as good as knowing the solution?  That doesn't mean I don't read up on things, I have over 130 blogs that I subscribe to and read on a daily basis, my shared feed is full of gems I've come across.

Every once and awhile I sit back and am still amazed at how the web has changed the way we work and interact, it's really incredible.  Now, time to clear those rss feeds and do some googling.

Prevent Suckage by Reading 'Lessons Learned' by Eric Ries

I subscribed to the blog Lessons Learned by Eric Ries a little while ago based on an interesting article that was sent to me and I'm glad I did.  Eric posted this article last week titled 'Using AdWords to assess demand for your new online service, step-by-step' and I'm glad I didn't miss this gem of a post.  Basically Eric is talking about using an Adwords program to gauge the interest in an idea before spending thousands of dollars moving in the wrong direction.  In his post he outlines how to do this for just a couple dollars a week.  If you're lucky your idea is bang on and you have another piece of evidence for potential investors.  If you're not that lucky at least you haven't lost your shirt and you can rework things to see how the changes affect the program.  Great post, check it out, subscribe to his blog, suck less.

Leaving for RubyConf 2008 Tomorrow

I'm really looking forward to leaving tomorrow afternoon for Orlando Florida to attend RubyConf 2008, it should be a blast.  The hotel looks amazing, the weather is going to be great, what more can you ask for?  Oh ya, there is more, some great talks and presentations from Rubyists around the world!

There are a number of interesting presentations, but a a couple of them really stand out.  One presentation that I'm really looking forward to is 'Recovering from Enterprise: how to embrace Ruby's idioms and say goodbye to bad habits' by Jamis Buck of 37signals.  I really respect the guys at 37, they have a no bullshit way of saying things that just make sense, I like that.  Jamis is also a long time Rubyist and has given so much to the community with the projects he's worked on (capistrano, sqllite ruby bindings), and has been teasing us with interesting blog posts related to his presentation.


I'm also interested in the talk Scott Chacon is giving, 'Using Git in Ruby Applications' mainly because I find Git to be such an in interesting source control system (and maybe I can pull some of my co-workers along so Scott can infect them with the Git as well).  It sounds like Scott is going to be getting into some very interesting things with his presentation as well, such as using git as the backend for a ruby based wiki or file backup system.  Cool stuff.

On Friday I'm probably going to try and catch Yehuda Katz presentation, 'Writing Code That Doesn't Suck: Interface P=Oriented Design' since, if you've read any of my other blog posts, I really like to do as much as possible to make things suck less.  I'm not all that interested in Merb though so I may wander over to 'Ruby Heavy-Lifting: Lazy load it, Event it, Defer it, and then Optimize it.' by Ilya Griorik and see what he has to say beacause, really, can you every know enough about making you code and application run faster?  Didn't think so.

Anyways, that's just a short run down on some of the great presentations that are going to be happening this weekend.  There will also be appearances by Matz (the creator of Ruby) and Dave Thomas (Pragmatic Programmers), both are likely to have something interesting to say.

See you in Orlando!

Facebook Applications are so 2007

 

Facebooklogo  When Facebook released their application platform last year it was revolutionary and a slew of businesses popped up out of nowhere.  A number of these business got huge valuations and outside funding, some even made some money.  But now that the dust has settled from the landgrab and the competitors have caught up with their own offerings (with a varying degree of success) what's next for the app platform?  Well, from where I sit, it looks like it's being retired.

The 'beta' features such as the Data Storage apis have had almost no movement in over a year, the api itself hasn't had any drastic changes (except for the ones do to the new layout) in months, what's been going on?  It used to be that notices would be posted on a weekly basis about updates and new features, now there's nothing.  The chatter around the Facebook platform is dying down to a dull hum.

Applications are pushed out of the main page, multiple clicks away, the directory is bloated with thousands and thousands of pointless applications, how are you supposed to make a mark?  Facebook started out with an 'anything goes' policy for applications, when things started turning into a blue and white version of Myspace they realized their mistakes and clamped down on the restrictions making it impossible for new applications to break in.

Facebooks Solution:  Facebook Connect

Connect seems to be the solution to the broken application platform.  Instead of embedding your application into Facebook you can now have users login through your website to Facebook and allow your application to access their data.  So basically all their doing is Single Sign On and a standard api to access the users data.  What's revolutionary about this?  Nothing.  That $15 billion dollar valuation is seeming more ridiculous every day.

This doesn't mean Facebook applications are totally useless now, it just means there aren't going to be any business built solely on a Facebook app anymore.  Since the spotlights moved on, Facebook needs to work at becoming cash flow positive to make keep things rolling, unless they they can build another Hype Machine to bring back the interest.

Follow The Leader - Linkedin Does an App Platform, Why?

This past week saw something we've seem before, again and again, with Linkedin launching it's application platform.  The big question is why, what's the point?  Their team is pushing it as professional applications for things like sharing book reviews, documents, and extended communication options.

Okay, that's cool, but most of the people you generally connect with on Linkedin are professional peers, if you had a need for this you're probably already doing it with something like IM or google docs.  Since Linkedin is a professional network it doesn't really lend itself to the type of viral sheep throwing applications that made the Facebook platform so popular.

Now, the thing I'm really wondering is why it took them almost a year from announcing the platform (about 5 months after the Facebook platform took off) and actually releasing it.  To me it seems like the first post on their platform was a load of crap and they were just trying to grab onto a bit of the hype that Facebook had generated.  On top of this almost every application I tried to use gave me some sort of error or had information flowing outside of the visible area for the application.  I expect more from such a high profile company with over a year of development time.

This doesn't make Linkedin suck less, if anything it makes them suck more because it seems like all their doing is running after the successful ideas from other companies.  If it doesn't make it suck less, don't do it.

EC2 Makes Getting a Startup Going Suck Less

Obviously getting your startup going doesn't suck (well, hopefully not all the time), but it is a shit load of work.  You need a kick ass idea, people to build it, a way to distribute, somehow get people to pay for what you're doing and countless other tasks.  This is a lot to deal with, and since you're a startup it's probably you or a small team doing all the work.  Well, if you happen to be building a web based product Amazons EC2 platform is defiantly something to check out.

EC2 is Amazons 'Elastic Cloud Computing' platform and it lets you take advantage of Amazons huge server and computing infrastructure to run your own server instances.  There are countless advantages to running your application in the cloud like this, the big ones in my opinion are cost savings as you pay for what you use, flexibility in expanding your server farm and the reliability of a distributed and proven network.

This is really cool.  If you think back to a couple of years ago how you would setup your own infrastructure you'd need to go out and buy some expensive servers and load balances, get it all setup somewhere  and then hope the traffic doesn't blow up the machines before you can get get more in to handle the load.  Now with EC2 you don't need to worry about the hardware and over purchasing to handle the load or running out and buying a new machine when one gets fried.

Things with EC2 aren't quite perfect yet, but they're not far off and a lot of the pain points are going to be addressed in the near future (2009) Amazon says.  From the Amazon Web Services blog, here's a couple of the things to look forward to:

Management Console - The management console will simplify the process of configuring and operating your applications in the AWS cloud. You'll be able to get a global picture of your cloud computing environment using a point-and-click web interface.
Load Balancing - The load balancing service will allow you to balance incoming requests and traffic across multiple EC2 instances.
Automatic Scaling - The auto-scaling service will allow you to grow and shrink your usage of EC2 capacity on demand based on application requirements.
Cloud Monitoring - The cloud monitoring service will provide real time, multi-dimensional monitoring of host resources across any number of EC2 instances, with the ability to aggregate operational metrics across instances, Availability Zones, and time slots.


Awesomesauce.  Those are the exact things that have been creating extra work when using their current offering, Amazon is spot on with the features that their users are really looking for.

I really like what Amazon is doing in this space, but if you don't or if it doesn't do what you need it to there are alternatives.  Google App Engine (GAE) is one such alternative that looks pretty neat.  It's neat because it's built by google, on top of their infrastructure and allows easy integration with existing google services (docs, accounts, etc).  In it's current state it's nothing compared to EC2. 

The biggest difference is that with GAE you're tied to using python for your application development and you can't really customize the platform at all.  With EC2 you start with a basic linux (and now windows) that you can then customize with whatever you want.  But if you don't want to do all that work, and you're a python kind of person, GAE might be perfect for you.  I, on the other hand, prefer the flexibility you get with EC2 and can't wait to see where they go from here.

Go out, get started.

ActiveApi - Wrapping a RESTful API in AS3

ActiveApi is my AS3 wrapper for a RESTful api, I just came up with ActiveApi right now so if I'm stepping on someones toes just let me know.  In my last post I kind of went over how I came up with these classes so I'm just going to dive into some code. 

To get started you need to define a controller class that extends from activeapi.base.Controller.  This class should be a singleton, you can do that however you like.  Controller defines a getter base_url that just throws an error so you'll want to override that so it returns your base url.  This is what you'll get:

package activeapi.example
{
    import activeapi.base.Controller;
   
    public class ExampleController extends Controller
    {
        public const BASE_URL:String = "http://localhost:3001/";
       
        private static var ExampleController = new ExampleController(true);
       
        public function TrackerController(only_one_allowed:Boolean) {
        }
       
        public static function get inst(): ExampleController {
            return _instance;
        }

        public override function get base_url():String {
            return BASE_URL;
        }
    }
}


Controller extends from EventDispatcher so you get all the event listening and dispatching methods from that.  This is the class that you will add listeners to for CREATE and DELETE of your objects, like this:

ExampleController.inst.addEventListener("session"+ActiveEvent.CREATE, auth);


Point to note, I'm prefixing the type of object I am creating to the event string, this isn't the ideal design but it was the best I could come up with.

Next is defining the class that is going to be doing the RESTful operations, the Session class in this example.  For now I haven't found a reason to create a base class to extend from, instead you instantiate an object that will be used to delegate the work to.  This is what the basic Session class would look like:

package activeapi.example
{
    import mx.rpc.events.ResultEvent;
    import activeapi.example.base.ActiveEvent;
    import activeapi.example.base.ResourceHandler;
   
    public class Session
    {
        //Static resource handler, passing in the name of the model and the controller instance.
        private static var resource:ResourceHandler = new ResourceHandler("session", ExampleController.inst);
       
        public var id:String;
       
        public function Session(identifier:String)
        {
            id = identifier;
        }   

        public static function create(args:Object):void {
            //let the resource handler make the call
            resource.create(args, create_complete_callback);
        }
        // static create method Session.create
        private static function create_complete_callback(event:ResultEvent):void {
            //delegate to the resource handler to handle the basic result and fire the events.
            resource.handle_and_dispatch(ActiveEvent.CREATE, Session.parse(event.result), event);
        }
       
        public function destroy():void {
            resource.destroy({id:id}, delete_complete_callback);
        }
       
        private function delete_complete_callback(event:ResultEvent):void {
            resource.handle_and_dispatch(ActiveEvent.DELETE, null, event);
        }
       
        public static function parse(data:Object):Session {
            //return a new session from the data
        }
    }
}


This class has a bit more going on.  First off is the ResourceHandler, it takes the name of the object type you want to create and a Controller as it's parameters.  I made mine static so that I could use it in both my static create method and instance method destroy.  Under the covers the ResourceHandler sets up some HTTPService objects pointing to the urls for creating and destroying the session object and setting op the correct mehod and response type (XML).  These objects aren't accessible but are used by calling the create and destroy methods on the ResourceHandler.  In the callback I use another method on the, handle_and_dispatch, to do some basic parsing of the response and then dispatching the events on the controller.  The second parameter of handle_and_dispatch is an object and is added to the final event that is dispatched.  The auth method that was added to listen for session CREATE before might look something like this:

private function auth(event:ActiveEvent):void {
    if(Session(event.object).id!=null)
        Application.application.currentState = "logged_in"
    else
        Alert.show(event.message.toString());
}


And that's basically it.  The ExampleController kind of acts like a central messaging system and the major work is delegated to the ResourceHandler.  I still need to pull this out from the project I'm using it for, which shouldn't take long, so if you're interested in the code let me know in the comments.  I'd also really appreciate some feedback on the design choices and improvement suggestions.  Personally I'm still left feeling like there's a better way but trying to figure something out has been sucking up way too much time.

FriendFeed Badge

FriendFeed Posts

Google Analytics

CSS Hacks