Anyway, the project I’m working on?  Just a twitter clone.  Why?  For the sake of learning, that’s all.  It’s actually for a project in school.  The idea is to implement this idea in something that I’m already familiar with (PHP) and then implement it again in another language I’m not familiar with at all.  After I’m doing with the first part I want to implement it in Python using the Django framework.  Python has always been one of those languages I’ve been meaning to learn.  In fact it seems I try to learn it every summer, but I just don’t seem to have the dedication to sit in doors learning it.

Regardless, I hope to use this knowledge in my professional life.  The last PHP project I worked on was stressful just because of some of the design decisisons I made (Doing a half-assed MVC implementation…didn’t do the best job of dividing up the view and controller).  However, I’ve learned from those mistakes and I might be taking up a new project at work where I’ll probably be using this framework.

A few months back I registered the domain http://picturesofpeopletakingpictures.net because my friends thought it would be funny. (Alcohol was also involved and it seemed like a good idea at the time). I still don’t know what I want to do with it, but I put wrote up a small script using Rails that queries flickr and displays a random picture tagged “picturesofpeopletakingpictures.” It turned out to actually be a huge pain in the ass because the flickr gem I used had their own API key built in. Once I hacked together a fix for using my own, I got it working pretty quickly. When I uploaded it to my web server, nothing worked. Duh I forgot to freeze the flickr gem! Nope that wasn’t the problem. Apparently you have to use a folder structure like ~/flickr-ver_num/lib/flickr.rb. The library had ~/flickr-ver_num/flickr.rb. After struggling with that for at least 45 minutes, I had it up and running. Anyways, if anyone has suggestions of something better, leave a comment.

I started on a project that could turn into a DevHouse competition. More on this later if it actually happens.

Lastly, I started looking at the Android Java Framework by Google for Cell Phones. I mean why not? Google has some pretty good documentation and tutorials that I was able to follow and I end up writing a Hello World program!

One of the things I wanted to focus on are the differences between three different types of iterators in Ruby that are commonly used in Rails: find, each, and collect. Let’s first start by asking what is an iterator? An iterator goes through each element in an array or hash table and let’s us perform an action using the individual element. Let’s check out the differences between these iterators.

find

Find is a bit misleading. The classical definition of a find method would be to return the index of the element (or perhaps the entire element itself) that matches a string. The find iterator method in ruby will instead compare each element using some comparison operator (<, >, ==, etc.) and based off of the boolean result (true or false), it will return the first matching value. For example say we have an array called a:

a = [ 1, 2, 3, 4, 5 ]

Using this array we want to find the first even value. Our code would look something like this:

a.find { |n| n % 2 == 0 }

Since 2 is the first even number, that would be the result.

each

Each is the simplest iterator method of the three. It simply traverses all elements in the array and returns each one individually. So if we want to print all lements of the array a, it would look something like this:

a.each { |n| print n }

The result would look like 12345

collect

Collect, or also known as map, is pretty much the same as each, except that collect returns an array of values. For this example, we’ll increment each element in array a and save the new element in b.

b = a.collect { |n| n + 1 }

This returns the array [2, 3, 4, 5, 6]

I hope this gives some insight on how Rails uses these methods.

On another note, I REALLY need to sit down and learn regular expressions. I’m tired of having to google search this sort of thing. I heard O’Reilly’s book on Regular Expressions is a good resource; perhaps I should pick it up. I’m going to have to learn them anyways, the sooner the better I suppose.

Afterthought: Perhaps instead of re-learning everything, I should just learn the PEAR library instead and fill in the gaps along the way. Anyways, I guess I know what books I’ll be ordering soon.

I think I might be going about this idea of consolidating your online identity with the OpenID simple registration extension and microformats wrong. I found this microformat library for PHP; It works by by retrieving the microformatted data (in this case hCard) by simply feeding it a URL and it then saves the hCard data for future manipulation. I’m starting to realize this same practice may be another way to consolidate your online identity with OpenID.

Before we get ahead of ourselves, let’s see how the applicable portion of the OpenID protocol works. The first step is to supply our OpenID URL to the consumer site and hit “submit.” For example, I would enter “nickpeters.net” as my OpenID URL to the consumer site ma.gnolia. What is a consumer site exactly? According to the OpenID Specification, the consumer is:

A web service that wants proof that the End User owns the Claimed Identifier.

Pretty much it means a site that wants to find out whether or not we are who we say we are by first asking for our OpenID URL.

After we hit the “Submit” button, an internal script on the consumer site will redirect itself to the given URL and look for two link tags in the head of the given HTML document. For the sake of simplicity, we’re only going to discuss the one of them: rel=”openid.server.” The href value of this link tag is going to be the script that actually authenticates you by asking you for the username and password you use on all OpenID-enabled sites. This practice is useful because you can offload the authentication process to a site like Vox or livejournal instead of setting up a server on your own server. This means I can enter the URL for the livejournal authentication script or a script hosted on my site. It also means your username and password isn’t sent to the consumer site and is only sent to the specified script.

That should be enough information for now, so let’s see how hCards can fit into this. Let’s say we log in to our OpenID consumer site (ma.gnolia) and go through the login process as normal. While the consumer site looks for the and OpenID.server URL in the head of our page, it would also look for some sort of clue as to the location of your hCard information. Perhaps this “clue” could follow in the steps of the existing OpenID protocol and also be a link tag, such as rel=”hcard” in the head of the document. From there, the consumer-site script can retrieve the hCard location by looking at the href value, properly redirect itself, and retrieve your information (Perhaps even using the hKit library).

The pros of this is that you can add as much or as little information as you want about yourself in your hCard. The simple registration data fields are very limited and there maybe some information in there that you don’t want to be shared (such as email address).

The cons is that it requires more administrative overhead. You’ll have to edit the header information of your site. You may not even be able to do this on all OpenID identifiers (such as ones on livejournal) because you don’t have permission to edit the header information.

Right now there are discussions going on in the microformat community about authoritative hCards that could possibly guide this idea in the right direction. I will continue to think about this and would appreciate any ideas from others.

With everyone working on their projects, it gave me the opportunity to begin filling in the gaps of my knowledge. I began researching new (to me at least) concepts, ideas, etc. Some examples are microformats, JQuery, and JSON. On top of that, I began going through AJAX tutorials, something I should’ve started a long time ago.

One of the unique things about being around this many people with similar interests are the conversations had throughout the night. Most of my conversations focused on web technologies: something I never have the opportunity to talk about at home. Topics included Ruby on Rails, the manageability of PHP in large projects, peoples’ current projects (including personal and business related). Most of all, I was able to network with people in the industry. There were a variety of people including CTOs, bloggers, and even someone from google. Hollywood has celebrities, but the bay area has eCelebrities.

This event has inspired me to form this sort of community back at home, but will it really be worth it? If I plan on moving in January (oh please make it happen), my efforts will be wasted in San Luis Obispo. I feel I should instead wait till I move to Camarillo for this sort of thing.

Anyways, can’t wait for Dev House 14!