The app-a-week challenge

The Philly Open Group is all about bringing together designers and developers to create really cool things. Starting this week, we are starting the App-a-Week Challenge.

The goal: Build a web mobile, or other software application each week that will be real working applications. The process from concept to beta will be outlined here on the blog.

The first app-a-week challenge
For the first app challenge, I am going to build a "sexting" web application. Before you go jumping to conclusions, let me explain the reason for building said application.
I have been invited by State Representative Cherelle L. Parker to give a workshop at her Youth Town Hall Meeting this Saturday. The title of my workshop is "Do You Want it All over the Web". My plan is to discuss staying safe in today's technological world, both on and offline. One of the topics suggested by Representative Parker was sexting.

For those who live under rocks, sexting is a portmanteau of sex and texting, and involves the sending or receiving of sexual messages or photographs. This seems to be a growing problem among young people, as many of them now have their own cell phones. So as a fun interactive demo, I am going to setup a sexting web application.

The application will be pretty simple. The app will be a single page, with a number at the very top, instructions below that, and the real-time sexting stream below that.

How it will Work
Users will start off by texting "girl" or "boy" to the number at the top of the page. The user will then receive a "sext message" from the application based on their initial message. The user will then respond to the text with a counter "sext message" and so on. Their message log will appear in real-time under the Real-time stream section.

The goal for this application
The only goal of this interactive application is to provide a fun interactive demo for my workshop presentation. My goal is to bring awareness to the issue in a fun way, and explain to them the dangers of actions like sexting amongst other in appropriate uses of technology and the internet.

Tools used for application:
Twilio API
LAMP Server
Bootstrap from Twitter

Estimated Time to complete application:
3-4 hours

I will follow up when the app is completed, and include a link to where you can download the source code!

If you have ideas for the app-a-week challenge, or you want to participate, let us know! 

Ready. Set....GO!

I recall when I first became interested in computer programming.
I was in sharp young middle school student, just getting introduced to the TI-82 graphing calculator. At the time, my mother taught math at the school I attended, and she had about 20 or so calculators for her classes. I took a liking to this device, which at the time was, (and still is), an impressive computational machine with a solid UI. I ended up taking home the calculator more often than not, and would scour the internet on the many different ways I could make use of the device. If you have ever used a TI calculator you are probably familiar with its ability to handle programs written in its "BASIC" style language. Once I made this discovery, the doors of opportunity opened, and I found myself typing in 1000 lines of code for games like tic-tac-toe and maze. (At the time i didn't have the link that connected the calculator to the computer, so each game I wrote was enter line by line). The code looked something like:

\START82\
\COMMENT=Program file dated 04/12/96, 16:17
\NAME=MAZE
:FnOff 
:AxesOff
:ClrDraw
:ClrHome
:Pxl-On(0,0)
:Pxl-On(2,2)
:Pxl-On(2,3)
:Pxl-On(3,2)
:Pxl-On(3,3)
:Pxl-On(4,4)
:Pxl-On(5,5)
:Pxl-On(4,2)
:Pxl-On(2,4)
:Text(5,7,"START")

Source: http://ostermiller.org/ti82/maze.html

Fast forward a few years to high school, and I am competing in programming competitions. The language of choice: C. It was the first (non-calculator) language I learned. C became my language for any occasion (or at least anywhere I could install a decent compiler). I almost became one of those folks who religiously follow a single programming language.. I then went on to study computer engineering, and discovered other languages that were useful for a myriad of different purposes. (PHP, Python, Javascript, etc.)

The point of that entire "rite of passage" story above was to introduce the latest programming language that has been keeping me busy the past week or two. I vowed to myself that after my borderline addiction with the C language, I would make an effort to learn new languages (as long as I could make use of them in real world applications).

The latest language I am adding to my arsenal is called the Go Language. From the Go language homepage:

The Go programming language is an open source project to make programmers more productive. Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. 

 Whenever I decide to learn a language, there is usually a business requirement or an academic motivation behind it. In the case with Go, I started out learning the language after finding out Google App Engine supported it. (Considering the language was developed by Google Engineers, this makes perfect sense). After spending the 4 and a half minutes (Ubuntu Tutorial Coming soon) it took to setup the environment and get the hello world running, I instantly dove in deeper into the language.

The description above is spot on when it says "Go is expressive, concise, clean and efficient." I've tried some languages in the past that would fall under the exact opposite description as above, and the amount of frustration from using them is often unbearable in the long term. I am looking forward to using it as cheap and reliable data-store solution.

Give the Go language a go at golang.org. Let me know what think of it as a viable language in the short or long term in the comments below.

A brief introduction to OAuth

Web applications are popping up all over the web. Melanie--who we will use in this post as our typical internet user--uses the internet at least 5 days a week. It is hard for Melanie to miss all the applications out there. Facebook. Twitter. Flickr. Picasa. Farmville. I could go on for days listing just the ones Melanie use.
You may (or maybe not) have noticed what all of these have in common. Yep. Thats right. They all want Melanie to verify who she is before consuming the application's services. Once Melanie has verified that she is, in fact, Melanie, she can begin doing things like updating her status, sharing pictures, or managing her growing Agricuture business on Farmville.

This system has worked, and continues to work as a reliable way to access web apps. It ensures that Melanie is only updating her information, and keeps everyone else's information seperate from hers.

So, applications have this great reliable way of authenticating Melanie, but say we want to develop another application or service that (for example) allows Melanie to automatically post updates to her Twitter or Facebook. For simplicity sake, lets use an RSS feed service as an example. Say we want to develop a service that automatically posts the latest Wallstreet news to Melanie's Twitter. I won't go into too much technical detail, but our application will periodically check the news RSS feed for updates, parse the title and summary, and post that to Melanie's Twitter. Nothing trivial so far.
We get to a point where our application sucessfully checks for the latest Wallstreet news updates, and now we are ready to post a Tweet to our Twitter. In order for our application to do this, it needs to authenticate as the user in order to gain write access to the server. Our application could collect the user's twitter username and password, but certainly we do not want to maintain a database of twitter usernames and passwords. We'd be asking for hackers to come and loot us! What to do! Oh sweet baby Jesus, what ever do we do to solve this major security flaw!

Enter OAuth.

OAuth is a protocol that allows a user to grant a third party limited permission to access a web application on her behalf, without sharing her credentials (username and password) with the third party. The third party can be a web application, or any other application with the capability of invoking a web browser for the user, such as a desktop application or a smart phone application. The application requestion access is know as the consumer, and the application granting access is known as the service provider. In our example above, our new RSS feed application would be the consumer, and Twitter would be the service provider. OAuth is starting to make a bit more sense, but how exactly does it provide a secure way for consumer apps to access service providers? Lets take a closer look.

Three-Legged Authentication (http://code.google.com/apis/accounts/docs/OAuth.html)
Most (at least all the applications I've used) applications do OAuth in three steps.
Step 1: To initiate access on behalf of a user, the consumer calls a web service endpoint (url from the service provider) to get a request token for the app. This is a temporary token used solely for the authentication process. The call to get the request token includes a URL where the user's browser will be directed after authentication is complete.
Step 2: The consumer directs the user's browser to the service provider's authorization URL with parameters, including the request token. The user signs in with her credentials, then grants the service provider permission that the consumer is authorized to access the service provider on her behalf. The service provider redirects the user back to the consumer web application at the URL provided when the consumer got the request token.
Step 3: The consumer then calls a web service endpoint again to exchange its temporary token for an access token. This access token is now the key the consumer application will use to access the service provider application on behalf of the user.

Thats pretty much all there is to it. These basic steps are essentially what applications running OAuth are doing. Each service provider application takes a slightly different approach in configuration of its web service endpoint scheme. For example, Facebook makes great use of a scope parameter in Step 2 above. The scope parameter is used to list what level of access the consumer application wants (e.g. Post to User's Wall, Access User's basic information, etc.). This makes sense in Facebook's case because Facebook provides a number of services that a user may or may not want an application to have access to. The access tokens can be controlled by the user usually via the service provider's Account management page. If a user wants, she can reject the consumer app's access token anytime, in which case the user will need to start from step 1 again to grant the consumer application permission.

All this is interesting, but is there an easier way to manage OAuth from all the different service providers?

I am glad you asked! This week while at the Twilio Conference, I was introduced to a service called Apigee. Apigee provides a sleek and easy to use interface for testing out all the popular API's in one place. Check it out for free over at apigee.com/console
What really juiced my berries was their OAuth API available for testing over at developer.apigee.com. The OAuth API gives you a keychain for authenticating to a growing list of API's. What this basically means is that instead of developing and debugging for Facebook's implementation of OAuth, and for Twitter's implementation, and so on, I simply use the OAuth API to consume all of the services. This will significantly cut down on developing applications, as it will make it easier to connect with multiple service providers at once.

If you have done any OAuth development, let me know what you experience has been with it, and your thoughts on a service like Apigee in the comments below.

Hello World!

PhillyOpen is a group of Web and Software Developers, Web and Print Designers, and everything in between. www.phillyopen.org

Thanks for visiting our web log. We plan to use this internet space to post useful open source tools, design tutorials, our open source projects, and other fun and useful stuff!

If you are a member of PhillyOpen and would like to contribute to this blog, let us know!! If you are not a member of the PhillyOpen Meetup Group, you can fix that here. If you want to stay up to date with the latest updates, you can do that over here.

Cheers!