Waterloo Region Web Design & Technology meetup: a great event!

Last night we had the pleasure and privilege of presenting at the Waterloo Region Web Design & Technology meetup last night right here in Waterloo, ON at the Barley Works. We had a great time showing off our soon-to-be-released product and got and overwhelmingly positive response. These are some of the tweets about our presentation from last night :-)

I was also very impressed by all of the other presentations from last night! They were:

Corey Dutson (@cdutson) Fast website prototyping using Fireworks CS3: Some great tips for rapid prototyping! Corey showcased several features I didn’t even know existed… like Master Pages

Peter (@TheSignDepot) from The Sign Depot – a great resource if you’ve ever wanted to make a more tangible version of a logo/image for yourself or a client. A great example of how skill and passion of your craft can lead to a great product and a successful company. I know where we’re going when we need a sign for our company :-)

Julia Ouellette (@Jooiah) Tips and tricks in Photoshop. She blew our minds right out the gate with some great features in Photoshop that are really useful and slick, yet not very well known. Great Job Julia!

This is a great event and I would recommend that you attend it if you can. A big thanks goes out to @Jooiah for organizing this great event… and for inviting us to do a demo.

As always, we forgot our camera so I don’t have any pictures to share with you, but if you know of anyone that took pictures and has posted them out there on the Interwebs, please leave a comment below with a link so that we can all enjoy them.

Proxying HTTP Requests in Ruby

So building upon my other jaunts into Ruby I decided to post some code to make http requests to external urls. It could use come polish and there there is most definitely better mechanisms out there (probably a gem or two… or three) but tis fun to write well… code.

First, here is an example of using it.

require 'Proxy'
class HttpCaller
  include Proxy
end

caller = HttpCaller.new

response = caller.call "http://www.somewebsite.com"

if response[:error]
  puts response[:object].message
else
  response[:object].each_header do |key, value|
    puts "#{key}: #{value}"
  end
  puts response[:object].code.to_s
  puts response[:object].body 
end

And I have posted the full code sample here.

JIL Mobile Widget API

Over the past few months we’ve been hard at work building a product that will help mobile widget and mobile web developers better test, debug and deploy their mobile applications. We have started by supporting the JIL mobile widget platform but have been struggling with gaining access to the information we need as well as getting answers from JIL.

Since we believe in the JIL platform and the good that Mobile Widgets will bring to the market, we decided to try and help the community ourselves. We will start posting on a regular basis with any information we think will be helpful to JIL Mobile Widget developers.

The first step is to let everyone know that we’ve created an open gitHub repository into which we’ve checked in Beta 2, 3, and 4 of the full JIL JavaScript API (publicly available from JIL). We did this to allow us to easily see the changes that have been taking place between the different beta releases. The documentation that has been provided by JIL was lacking certain key changes and that was the driving force behind us taking this action.

You can read some more details on our post to the JIL.org forums here: http://www.jil.org/jil-forums/posts/list/307.page

The gitHub repository can be found here: http://github.com/tinyhippos/JIL-API

If you are a JIL Mobile Widget developer and would like to help out by contributing code snippets, advice, etc. Please let us know. We’re currently working on putting together an independent JIL developer community to help our fellow developers get the answers and help they deserve. We’ll blog about that very shortly with more details.

In the mean time, please fell free to leave us a comment here if you have any suggestions.

Mobile Widgets – a primer

This is the first in a series we will be writing over the next few weeks, introducing Mobile Widgets, the different platforms, and why we think they could very well be the future of mobile applications. This article is the primer, an introduction if you will.

Today…

…there are two major and well accepted ways to deliver mobile content to the end consumer. Native applications and the mobile web.

A native mobile application is an application that is installed and runs on the phone, allowing the user to have access to phone functionality such as GPS, contacts, camera, accelerometer, etc. These applications have robust features and tend to work and feel as if they are part of the phone. The challenge here is that they are platform specific. Meaning; if you’ve built your application for the iPhone, you’ll have to re-build it for Android, Blackberry, Symbian, etc. if you want to be able to deliver it across multiple platforms.

The mobile web refers to building a website that is easily accessible to mobile devices. Meaning that it sizes correctly to the mobile device accessing it and delivers it’s content in such a way as to make it easily consumed on the reduced screen real estate available on a mobile device. Many developers are adopting this approach because it allows users on different mobile platforms to access their content. The drawback with this approach is that a mobile website does not have access the same breadth of phone functionality that a native application has access to. Yes, some of the newer mobile web browsers will give websites the ability to retrieve GPS information from the mobile device accessing them (the user has to explicitly approve this), but that is about all they get. HTML 5 is also allowing for much more complex applications to be written (see the Google Voice mobile application).

I’m here to tell you that there is another option! Mobile Widgets have entered the scene and we believe they will change the mobile application development landscape.

What are Mobile Widgets?

Simply put, mobile widgets are mobile applications that are written using web technology (HTML, CSS, and JavaScript) and have access, through a common API, to pretty much all of the mobile phone’s native functions (very much like the native applications mentioned earlier). These mobile widgets are downloaded and installed on a phone the same way native applications are, but since they run on top of common Web Runtime which implements the W3C Technical Recommendation for widgets and then some, it makes them cross platform compatible. That’s right, you can now build your application once and deploy it to multiple platforms. Here is another article on W3C widgets for your enjoyment.

Sounds too good to be true…

It is too good to be true! The above statement is where mobile widgets want and should be. However, much like in the rest of the mobile market, there is fragmentation! Multiple run times, that don’t work exactly the same way and which are not supported to the same extent on all mobile devices that are advertised to support mobile widgets. However, even with those limitations in mind and the platforms being in their infancy (i.e. most are still in Beta), mobile widgets will allow you to, at the very least, re-use a very large percentage of your applications as you port them to different platforms!

The players

There are several big players working hard at trying to bring mobile widgets to a mobile device near you. There is an estimated 1 billion hand held devices in the wild today that will be able to support mobile widgets, compared to the 60 or so million iPhones out there. This number, I’m sure, is making mobile widgets attractive to many. Here are the players involved today (if you know of any that I haven’t mentioned, please feel free to leave a comment).

JIL.org is short for the Joint Innovation Lab; a collaborative effort by Vodafone, Verizon, China Mobile, and SOFTBANK. These large network providers have also teamed up with the following hardware manufactures; RIM (Blackberry), Samsung, Sharp, LG, Dopod, Nokia (supported through a Vodafone runtime installed on the S60 v3 and v5 OS). JIL has created a Mobile Widget API that allows for great access to native phone functionality such as calendar, contacts, camera, accelerometer, local storage, and many more.

Nokia has had widgets for quite a while now. Their widgets run under the Nokia Web Runtime (WRT) and although they are different from JIL, they are remarkably similar as well. Nokia might have fallen behind in sales here in North America, but they still have the largest market penetration across the globe!

RIM, LG,  and Samsung have each published their own widget implementations, even though they will be supporting JIL. This is a little confusing to us, but then again, no one said this market is very clear to begin with. RIMs implementation of their own native widgets is especially frustrating since those widgets are very much proprietary and in my opinion go against the idea of what mobile widgets should be.

Till next time…

In my next article I’m going to expand on widgets in more detail. Talking specifically about JIL and trying to cover the good the bad and the painful aspects of the current implementation as well as where I see things going.

I leave you with another article on a similar topic: http://www.quirksmode.org/blog/archives/2009/11/native_iphone_a.html

Should you patent your idea?

That is the question that has been taunting us over the past week or so. If you’re here hoping for an answer to that question, I’m afraid you’ve come the wrong place. I’ve been struggling with whether patenting in the software world is even beneficial. There have been many articles and posts (here’s one) out there about the thought that patents stifle, or at the very least, slow down innovation. Today, I read a brief post by Brad Feld on the topic and it made me thing about our particular situation in a much more granular fashion.

Seeing that right now there are only two of us working in the office (aka… Brent’s bedroom), all of our time is spent writing code, meeting with advisors, potential clients, etc. Adding the overhead of preparing to file for a patent, will, and is, slowing us down. Preventing us from developing our product at the speed we would like to.  I understand the need to protect ourselves from someone coming along, stealing our idea, and getting to market before us. These are some of the thoughts going through my head:

  • As long as they don’t just plain copy our code (should be protected under copyright). If our competitors get to market with a product that is better then ours, with more features, and offering more value to the customer… do they not deserve to win?
  • A patent can help you get investment because the investors will feel more protected and know that they are investing in “unique” IP. However, I have to wonder if holding a patent won’t lead to letting one’s guard down and perhaps becoming complacent. The phrase… “We have a patent! We’re safe so let’s relax” comes to mind.
  • A patent can help with acquisition, since those acquiring you are also acquiring your IP and patent. Ok, I don’t have a negative for that one.
  • Launching a product into Beta prior to filing for a patent can make it such that you don’t qualify for a patent due to public disclosure. That’s all good and fine, but I believe that your early adopters and beta testers will provide invaluable feedback which could either show you that you have a valuable product or that you have to re-think your approach. Filing for a patent first might land you a patent for a product or an idea that no one wants!

At the end of the day, I’m new to this aspect of the startup world. My views might be too idealistic and there is a good chance that I’m just plain wrong. I just can’t shake the feeling that patents are evil! Perhaps if patents were only used or contributed to innovation in the past, I would have a different take on the subject. Time will tell… it always does :-)

DemoCamp Guelph – recap

Last night we had the great pleasure of presenting at DemoCamp Guelph 12 along with some other really interesting presentations. MonsterFarming.com did a great job of summarizing the presentations so I encourage to read his post :-)

This was our first DemoCamp Guelph and the turn out was remarkable. The venue was great, but a little small for the number of people that came out. Special thanks to Brydon for putting on this event and providing a great value for community in and around Guelph!

Our demo went rather well with the exception of my laptop crashing right at the beginning :-) From now on, I’m not hibernating my Windows machine 10 min before a demo! The one observation I had about trying to present a product in 5 min is… 5 min is a really short time!!! I remember being in 5th grade and having to do an oral report that needed to take 5 min and thinking that was such a long time. It’s funny how perceptions change when you’re actually talking about something you’re extremely passionate about :-)

ps… Brent’s the one representing in his awesome Batman shirt :-)

Demos!

Wow, the past couple of weeks have been a whirlwind of activity around here. We’ve worked hard to get our product to a stage where it can be demoed. Yesterday was the first time we’ve shown our product in action to anyone other than close friends and family. I have to admit that the response has been remarkably more positive that we could have expected!

We were fortunate to be able to demo our product to TechCapital and the folks there are absolutely great. We got some great insight on our product and some really good constructive criticism on our slide deck. A great big thank you to Peter Frisella for taking the time to meet with us!

We also had the privilege of doing a demo at Dev House Waterloo last night and got some really good feed back with regards to some feature sets we could add as well as some very encouraging comments about our product. A very big thank you also goes out to PostRank for hosting this great monthly event.

There were also other very geeky and extremely cool presentations. You can visit the Dev House Waterloo site for a full list and description of each presentation.

We’re currently working on adding a few last minute features for our upcoming presentation at DemoCamp Guelph this Wed (Jan 27th, 2010). We invite you to come out and see us present. You can RSVP here.

Priming CSS, For Fun.

I ran across a cool app for taking in html and spitting out an external css style sheet based on any ids/classes in the markup.

PrimerCSS

So I figured I would attempt my own (albeit more basic) version (in ruby) for fun or maybe my own use. I don’t go as in depth as PrimerCSS does, as I am missing additional features such as tag prefixes and child prefixing. Though I did some extra sorting and grouping.

See the links at end of post for example markup, css results and the ruby file. You can see the differences but its gets the job done.

Lets start with the constructor and some file IO helper methods. Pretty straightforward. Grab the markup file and optional file location to save to, read in the file and parse the data.

class Primer
  def initialize(to_prime, file_location=nil)

    @my_ids = Array.new
    @my_classes = Array.new

    if file_location.nil?
      @fname = "styles.css"
    else
      @fname = file_location
    end

    txt = self.read_in_file(File.join(Dir.pwd,to_prime))

  end
  def save(lines, file_to_write)
    File.open(file_to_write, "w") do |aFile|
      aFile.syswrite lines
    end
  end

  def read_in_file(full_path)
    data = String.new
    if !File.directory?(full_path)
      IO.foreach full_path do |line|
        data += line
      end
    end
    data
  end

end

Now we just need to parse the hell out of the data. Regular Expressions make life very easy.

  def prime(txt)

    txt.scan((/(id="\S+"|class="\S+")/)) do |w|
      if w[0] =~ /^id=/
        css_type = "#"
      else
        css_type = "."
      end
      w[0].scan(/"\S+"/) do |val|
        self.juggle val.gsub(/"/,""), css_type
      end
    end

    self.save_primed

    puts "Done. \nSaved to #{@fname}"

  end

Now for the last two referenced methods…

  def save_primed

    buffer = String.new

    to_do = @my_ids.uniq.sort.concat(@my_classes.uniq.sort)

    to_do.each do |arr|
      buffer += "#{arr[1]}#{arr[0]}{\n\n}\n\n"
    end

    self.save(buffer, @fname)

  end

  def juggle(name, type)

    if type == "#"
      @my_ids.push [name,type]
    else
      @my_classes.push [name,type]
    end

  end

And lastly add a bit of code to take in arguments from the command line.

  if ARGV.length > 0
    Primer.new ARGV[0], ARGV[1]
  else
    puts "nothing to prime.\n"
  end

So there we have it. Not that much and definitely could use some refactoring.

Fun times…

Haiti relief/rebuild fundraiser – retrospective

Last night we organized, with a great deal of help from Karl (@cutegecko) and Amy (@cutergecko), a small tweetup get together to try and raise some money to help with the Haiti relief / rebuild efforts.

I wanted to take a quick moment and thank all of those that attended and donated so generously! We’ve raised a total of $480 for the Canadian Red Cross. Not bad at all :-) A special thanks goes out to the very humble @seyDoggy who donated $200!

I also wanted to take a moment to thank those that donated door and raffle prizes to our little event:

  • First 20 people with donations, got car wash tokens from Waterloo Honda
  • Waterloo Honda also provided several swag items, a tool/bar kit, and a couple of free Oil and Lubes.
  • Cambridge Towel donated some really great towel sets.
  • CuteGecko is donated some local gift cards.
  • StretchYourLife.com have donated a pilates gift card.

And here is a little picture of our donation being handed in to the Canadian Red Cross: http://tweetphoto.com/9140657

It’s really nice to see what a small, but helpful and determined group can do. Thank you all again from the bottom of our tinyHippos hears :-)

A small OMG moment

I’ve read many entrepreneur, VC, and Angel blogs over the past few years. At some point each and every one of the authors of those blogs mention a particular moment in time when they realized that a product, company, person, etc. was just going to make it. Maybe “make it” is a strong statement, but there was definitely a realization that they were on the right path and what they were trying to create was bringing real value to someone.

I am proud to say, that I now know what that moment in time feels like!

Yesterday, we got an email from the interactive media design shop we’ve worked with in the UK to deliver Mobile Widgets to Vodafone Europe. One of their developers had been struggling with one of their widgets. They had spent a couple of days trying to track down a classic “Heisenbug” (see this Wikipedia article). Since they knew we were working on a tool that might help with the testing and debugging of Mobile Widgets, they reached out to us to see if we could help shed some light on the matter.

Seeing that our tool offers a great deal of visibility into what’s going on inside a widget, we were able to: reproduce the bug instantly, diagnose it, fix it, and retest it… All in less then 20 min!

This was it! It was the first time we’ve put our tool to work with code from out there “in the wild” and managed to prove it’s effectiveness. I cannot tell you how good a feeling that was. Knowing that we’ve built something we thought would be useful and actually having that proven out.

To all of you that are out there right now, building/coding/innovating; don’t stop! That one moment in time is definitely worth all of those caffeine fueled sleepless nights :-)