In addition, we’re cooking up some new features features that we expect to roll out by Fall 2011. While it is currently only for Ultimate Frisbee, we plan on opening it up to more sports as we get through the “beta” phase.

Technical Side
Playspedia runs on CodeIgniter, MySql and jQuery and was developed with the help of a few friends and my brother. It was my first major personal project where I decided to use the CodeIgniter PHP framework. Having used Zend I decided that it was time to use something leaner, and CodeIgniter seemed like a great fit as it’s very lean and fast. Although some developers consider CodeIgniter to be a basic framework, I think it’s a perfect framework for those who wish to customize and build their own design constructs. It is very basic at its core, but it’s also very easy to extend to create a very well fine tuned application.

Product Side
Coming up with the idea came straight from the Ultimatehandbook website that I run. After hearing from many players, primarily coaches, that they wanted to create plays, I decided it was time to give them this option. Instead of relying on Flash, which is on its way out, using  Javascript made a lot of sense given the progress that has been made with lib/frameworks like jQuery. It was clear from the first early launch that players loved it and that it was actually being used for its purpose. While it’s still in its infancy stages, we are learning a lot and will be releasing a lot of major features to make the site the Ultimate source for plays.

• Blueprint
• 960 GS
• Less

These frameworks basically provide a basic set of tools for front end developers to focus on building and not recreating the same scaffolding code for each project. Also, they address common browser differences and are optimized for particular viewing experiences. One thing these frameworks have in common is that they create a “grid”. The entire site is defined by standardized column widths that make it easier to place content without creating messy divs and floats. They are great for code quality but you do need to make sure the design adheres to the grid. This is often a big issue for most developers/designers who don’t necessarily have control over this.

So to address the title of this post, what is Skeleton? It’s another CSS framework I just came across, but it hits the sweet spot between simplicity and power.  In addition, because it’s new, it addresses mobile displays and focuses on the forward usage of CSS3. Sometimes you don’t have to analyze frameworks with pro/cons matrices and just need to read over the CSS to know it’s right.  I found with Skeleton, that I could read the one page description, download the files and understand it within a few minutes. Other frameworks, often more mature in development, provide too much information, too many options and abstract too much. I like Skeleton because it’s not doing any heavy lifting with Javascript, it’s all good clean CSS with clean documentation.

The official site does a great job of providing a summary of how it works, but here’s my own coles notes version:

• grid based design on 960px
• mobile friendly
• usage of css3/html5
• clean form elements
• jQuery ui tools (fairly basic now)

If you’re looking for a CSS framework, I highly recommend giving skeleton a try.

In the past years, it seems like more and more people have been talking about APIs and yet a lot of  people don’t seem to really know what an API is.  An API in short is defined as an Application Programming Interface, doesn’t sound so special does it?   Well to a developer it’s not that special, APIs have been around for a long time and have been a pretty standard concept.   Typically, a developer that wants to use a 3rd party tool, or any object/class will read a document that explains how to use the object and then will make a connection to this object with code.  So, in a nutshell an API just allows one piece of code to talk with another piece of code.  I’m sure at some higher level, the real definition is much more abstract than that .

Think of RSS

API’s as a buzz word has grown in recent years because it has become standard practice to develop web applications that share data with other applications.  If you’re at all confused then think of RSS feeds and consider how you can read RSS feeds with various programs or web sites.  The concept is similar for an API, there’s a source that provides a information in a standardized format so that the consumer applications (e.g. – RSS reader) know how to read and present the data.

So why is an API important?

Now if you take the model of an RSS and take it further, so that the source application can provide various types of information, you have what is the makings of a RESTful web application (another buzz word).  A web application provides an “interface” for other applications wishing to use the data by exposing a public API that tells the consumer applications how to use the data.  For example, Twitter and Facebook define and refine their public API to dictate what data 3rd party applications can use.   In most cases, a web application’s API should provide ways to create, read, update, and delete (CRUD) data.  So this means that some applications can build around applications like Twitter to extend their own application.  For Twitter, their API has led to an explosion of web applications that allow users to do amazing things.  One good example is hootsuite, a powerful social media dashboard, that combines data from Twitter, Facebook, Linked In, Foursquare and their list keeps growing!

Is that it?  Pros and Cons…

Well not really, I’ve just tried to explain why an API is such an important concept.  It basically allows web applications to work together to build even more powerful applications.  At the moment, the major players (Facebook, Twitter, Google, etc…) use APIs to grow their user base and extend their reach.  For the small players, APIs are like a VIP pass to a club with all the people you want to sell your products to.  You can see that there are dangers with this type of system.  Now all the control lies with the source provider, and generally speaking there is nothing stopping the source from changing the rule.  Speaking from experience, having developed several Facebook applications with their API, there have been more than several times where changes to their API have broken my application.  Or consider the risk you face if the source provider has down time?  There are a lot of factors to take into consideration before creating  an API driven application.  Just think of this, Facebook and Twitter do not communicate with each through an API (at least to my knowledge).  It all comes down to the business strategy and has nothing to do with technology.  An interesting side effect of an API driven web world is that each business must consider new risks about the trade-offs and benefits of using or providing an API.

More coming

This was just a short intro at a very high level to what APIs are and why they have become the buzz word for many business IT folk.  I took liberties in my definitions as my focus for this article was to explain at a high level and not to get bogged down in technicalities.  I will follow this post up with a more technical article explaining the options for PHP developers looking to build a RESTful API.

They will understand

1. Why the time estimate is so long.
2. What the repercussions will be for cutting corners.
3. What the risk is.
4. What needs to be done “later”.
5. Why this piece of code is so great
6. etc…

From my experience, clients/bosses/project managers that understand more about what you do is generally better than the opposite.  You don’t want to overload with technical jargon but being able to explain with analogies for them to relate to is useful.

So, to explain the title of this post, “Hardcoding and Spreadsheets”, I think you may already know what I’m getting at.  Most people have used a spreadsheet and know that formula based sheets save a lot of time.  If you don’t use a formula when you can, and instead “hardcode” a constant number into a cell, any future updates you or someone else makes can “break” the spreadsheet.  Even worse, you may not even know it’s broken.  While this seems very amateur, I would not be surprised if hardcoding in spreadsheets has led to many mistakes, and potentially financially devastating results for accounting firms.  Using a formula requires identifying redundancies and factoring out any opportunities for duplicate data to be required.  For example, if tax is defined by two cells, 5% for GST and 7% PST, then the total tax is defined by the addition of these two cells.  If you decide that you’re too lazy to input GST as a separate cell and instead “hardcode” 5% in the formula for total tax, then you may have more than one place to update if GST changes.  Okay, I know this is not ground breaking material, but it’s pretty much the same issue we developers face on a daily basis.

Hardcoding a particular piece of code is bad because if it can be factored out so the logic is more sound, it should be done.  In most instances, this is the case, but quite often deadlines and/or laziness conflict with this goal.  Perhaps the client needs this particular piece done by tomorrow and you know that if you do it the “right way” it will take 2 days.  Or perhaps, you have a party to go to and decide to fix it “later”.  So, you think “hey, I can hardcode this and deal with it after”.

From a developer’s perspective, it’s not just “hardcoding” but poor programming practices that must be avoided where possible.   As developers, we must weigh the technical and business risks of our choices and decide the best route.  It’s not easy and requires experience to pick a choice.  For instance, hardcoding can be a great solution if the application will exist for a short period of time.  It would be a waste of a budget to code the most elegant piece of software that will only serve one very specific purpose for a short period of time.  On the other hand, if the client mentions “reusable” and future use, then you should consider this and explain why this would cost more.

The difficult situations are where the client or boss decide they don’t care and want short turnaround time, reliability and flexible software.  There is little a developer or anyone can explain to an unreasonable person.  But if they are willing to listen, attempting to relate software to common tasks like formulas in spreadsheets could help.  The last thing you want is to explain that this “bug” was their fault.  As a developer, communication is one piece of the solution to enable sound development.