The Guelph Seven

Beginning March 5th, 2011, 7 University of Guelph students will take up the challenge to make 7 awesome applications in just one week.

After following the previous Seven Cubed Project, where 7 University of Waterloo students attempted to write an app a day for 7 days, we were inspired to try the experiment for ourselves.

Join us on our adventure!

Follow us! Like us! Fork us! Email us!

First thing’s first

We admit it; we’re a bit late.

Next thing’s more fun

Our application today is called Pinchy. It absolutely has room to grow - but for now, we’ll give you a rundown of what it’s all about: think of Pinchy as a simple, pure HTTP message sending protocol.

You, or your friend, or any other whitelisted* person can use POST requests to send messages to one another. A message would ideally be anything - text, data-blobs, images, video - but for simplicity we’ve ended up tuning this down to 4k-max blobs of text (per message) today. The request you make has the following parameters:

username, password, recipient, data

Meaning you authenticate, say who you’re sending to, and provide the object to be sent. Dead easy. Now things get cool on top of it:

Your messages are accessible through just an HTTP GET, with your username as a parameter. Your messages are stored in a database and transmitted to you as XML Objects – RSS2/Atom/our own Feed schema at the moment, and we’ll likely end up implementing JSON soon.

This means that you effectively have an RSS feed that your friends* can publish to. The big idea here is a very easy to use, rich channel of data that we’ve opened.

This is a simple, pure HTTP message sending protocol. To write to it, it’s just an authenticated HTTP POST. To read from it, it’s just an unauthenticated HTTP GET. Reliably communicating ‘when you want it’ information across platforms is surprisingly hard, and it shouldn’t be. Now it isn’t, because Pinchy makes it easy.

We wrote an API first

That may not be super meaningful to some people, but we hope you see the use: we’ve built something that allows us to do more interesting things. By using it continuously, we’ll both prove its utility and increase its robustness and power.

We have several ideas for applications that will use Pinchy. In fact, we started out working on one of them today, but all threw our hands up when we realized we’d want to figure out this communication scheme first anyway. Having a simple, straightforward HTTP messaging system will allow us to do some excellent stuff in the days ahead - unified notifications, location-based services, globally available statuses, getting in contact across devices and services, and things we haven’t thought of yet.

Why so late?

There’s several reasons we ran late today. Two reasons are that we had a lot of initial setup to do and took some time to hit our stride, but the strongest reason is that this application was really hard to make, because it’s actually useful.

Pinchy is dead-simple to use and has a small code footprint. We spent the lion’s share of our time today solidifying just what we were building, how it had to work, how it could be extended, and ultimately why this is useful at all.

We’ll be improving Pinchy as we use it over the next few days, but the basic message system is available and operational in the /api directory on our github. We’ve built a few small services to test it - notifications delivered from IRC, publication to multiple clients, and integration with twitter/facebook/generic chat over Jabber were made as tests, but none of these are the App. The App is the API.

* - whitelisted, friends: This should be configurable to be public or users of your choosing.

(edit: just informationally, this was posted a few hours after most of us are asleep. We’re not crazy people, here.)

The Guelph Seven are off to a loud start!

Bells and whistles announced our arrival at 349 this morning – we moved upstairs and got right down to work. Ideas were drawn up on a whiteboard and evaluated by two factors: feasibility and impact (you can see our influence from the original 7cubed project). We aligned them in a 2D grid and decided to focus on ideas that were both highly feasible and highly useful - visibly on the top right - then voted using a cool process known as dot voting (thanks, Declan!) to determine what to work on today.

Almost immediately after making our decision, we realized that a different idea in our list would make our chosen application trivial. We soon recognized that it could be usefully applied to 2-3 other (high ranking) apps in our list, and went with it. The problem was that it was at best vaguely specified, which had kept it down in terms of feasibility earlier. This meant extended specification, but it will pay off by making subsequent apps easier to write.

After a great deal of back and forth, countless diagrams, a broken test server, lunch, and a review of existing technology, we set down to hacking. There’s people writing python, php, perl, and html/css right now and we hope to have a minimum viable product soon; then we can iterate and expand outward. Hopefully what we have to show this evening will be worth looking at!

We’re definitely finding our footing, but we’re optimistic and hungry to make something great. More to come – in the meantime, check out our twitter.

Our warm up day was a blast!

We produced 3 Zimlets by the end of our Dry Run last Saturday at 349. All the source and the ready to deploy zip files are on our github. We’ve had a friendly suggestion to rename the packages from ‘com_zimbra_*’ to 'com_guelphseven_*’ as that’s the way the namespace is intended to be used. We hacked from just before midday well on into the evening, and we’re undoubtedly happy with the results. We hope that the University of Guelph’s CCS will use our Zimlets!

Assemble

We showed up across the morning, but before we could get down to the dark art of hacking at zimbra, we had to install it! Our team came into this one blind for the sheer challenge of it, and had reams of documentation to read. We ended up having a teammate at nearly every step of the process - first glance at documentation through to running test code and development. It was useful because we were able to help each member behind us.

Training Day

Declan Whelan is a local agile coach who incredibly offered to provide advice on our process, and boy are we glad! He arrived around 1 and none of us were quite sure what to expect - other than that it would be helpful to have some guidance. We started off describing our general plan:

1. 1. Arrive and Brainstorm
2. 2. Choose an idea
3. 3. Design and spec
4. 4. Code
5. 5. Eat and review our progress.
6. 6. More code
7. 7. Success! Repeat each day as needed.

Declan’s suggestions were lightweight refinements to our original process that gave it the structure it sorely required. He promised to take only an hour of our development time and did just that – a whirlwind tour of how to choose an idea, good methods for arriving at consensus, a structure for retrospective times, working agreement, and a dead simple task board were all shown off and given life. He also generously gave us some super sticky postits and materials to work! When he left, we were nothing short of envigorated - ready to design, hack, and power our way through to success. Huge thanks to Declan for his suggestions and guidance.

Tough nut

It turns out, Zimbra’s Zimlet development documentation is not very excellent, but they’re trying. In fact, it’s rather confusing! Our team spent a few hours just getting everyone’s laptops (mac, linux, and windows) to run zimlets within the desktop host of the zimbra software. This started before (and in some cases, quietly continued while) Declan worked through our process with us, and it wasn’t long after he left that everyone had begun work on an app.

We came into the day with two key ideas:

1. Fix the 'sort by sent address’ feature in Zimbra.

2. Add an alert that would suggest using Bcc if an email has a high number of recipients in the To: field.

These were motivated by user requests and our own experiences - countless times, professors or student groups have piled entire email address lists into the To: field, starting an unwieldy 'reply all’ battle, and it just seems shameful that you can’t sort your sent email by who you sent it to. We were in for a treat.

Unbelievable

It turns out that the sent mail sorting issue is kinda like Zimbra’s Moby Dick. We did research into our plans and found out that this has been an issue for nearly six years, is the most discussed bug across all Zimbra development team meetings, and is prompting a major architecture overhaul in the upcoming Zimbra 8. It’s a backend issue that has to do with the email storage database, and we decided to scrap it.

Because there were several of us to work at once, we branched out and found some additional ideas.

Success

Getting the basic apps to run was a challenge, but we did eventually get the example tooltip and onclick material to work. From there, we found some code to pull RSS content onto a page, and simultaneously started trying an app called Attachment Alert to run. It notifies the user if they try to send an email that mentions attachments but has no files attached. It’s similar in concept to Bcc Alert, so we wanted to see how it does its magic. Unfortunately, the attachment alert application turned out to be broken!

We decided to write an RSS-feed app that would pull our University’s news feed into a little region above the calendar in Zimbra, and also to fix the Attachment Alert zimlet which wouldn’t operate on any of our platforms, in any browser we tried.

Good Work

From there on it was just navigating existing code, debugging javascript, and working within the guidelines of the API. Things came together over a 2-3 hour period and both the RSS Feed and Attachment Alert apps were operational. Then people started polishing them a bit and commenting code while the Bcc Alert app was written, and everything wrapped up by the mid-evening.

Finale

It was a great day. We established a good team dynamic, got a lot of work done, came to know and love the space we were in, and learned a huge amount. It was indispensable training on our journey to today, where we’ve got a good start on building some fantastic stuff.

Keep abreast of our news by checking out our twitter, our github, or our website.

We’ve got a much prettier site now, and we’re gearing up to begin. There’s just over a week left before we start developing stuff like crazy!

This Saturday we’ll be at 349 doing a dry run to get ourselves prepared. We’re going to create a Zimlet for the Zimbra mail/calendar system just to get our feet wet and our build process down. From 3 to 5, 349 will open their doors - you can come check out their sweet coworking digs, whisper app ideas into the ears of The Guelph Seven, and hopefully meet some other cool tech people from the Guelph area.

We’re going to start posting bios soon, as we ramp up to the week of awesomeness. You should keep your eyes here – who knows, we might develop an app for them.

-g7