Heroku Worker Dynos

When we launched LiveShow, we utilized what Heroku calls a “Worker Dyno” to handle background tasks, specifically sending emails.  Using a Heroku worker dyno allows you to offload work to a background task so that it doesn’t hold up the actual web server portion of your app.  The downside to worker dynos is they cost money, $0.05/hour to be exact.  And when you run one all day, everyday for a month, that can add up.  In the case of LiveShow, to the tune of over $50 a month. And for a company that isn’t making any real money at the moment, that’s a lot of money going out with next to none coming in.

Enter HireFire

When doing some research for another project, I stumbled on the HireFire gem.  This gem is a must have for anyone who is using Heroku and the worker dynos.  The use of this gem saved us close to $35 in July alone.

What does it do? It’s simple, you set up this gem, and you deploy the changes to Heroku. Once the changes are live on Heroku, you can turn off your worker dyno because this gem will activate one when you generate a background task. You read correctly, it will “hire” a Heroku worker dyno when it notices a new background task has been created.  Once the background task has completed successfully, the HireFire gem will them kill (read “fire”) the worker dyno.  So the worker dynos are only alive when they’re needed.

You can imagine how something like this would reduce the cost of someone (like Just for Bands) that relies on these workers to push out emails and perform other tasks.

The Downside

If you used scheduled background tasks (DelayedJob’s run_at option), this won’t help.  Because HireFire will see the pending job, it will actually keep the worker alive until that job has been ran successfully.

Also, currently, the gem requires you to store your Heroku account credentials in server environment variables on Heroku. There is work to move to using the Heroku API key that each user is given, but it hasn’t been fully implemented yet.  It needs the credentials in order to hire/fire the worker dynos, since it uses Heroku’s APIs for doing the work.

Conclusion

Seriously, if you’re running a Heroku app, and you are using the DelayedJobs or any of the background task runners that HireFire supports, you should highly consider using this gem.  It will drastically reduce your costs, and thus keep your pocket book in check.

First you’ll need to remove the stuff in your /home directory:

rm -rf .rvm*

Next you’ll want to remove the following line from your .bash_profile

[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function

You’ll then want to remove the /etc/rvmrc file as this has some information about the RVM install in your /home folder

sudo rm -rf /etc/rvm*

Finally you’ll want to remove the group it created (this will be there if you attempted a system wide install, but hadn’t cleared out everything, running this command will have no effect if the group isn’t there)

sudo groupdel rvm

This should remove RVM from your system completely, and allow you to do a system wide install that will install to /usr/local/rvm as expected.

Setting Up a Submodule

Setting up a submodule in git, is actually fairly easy, you just pass in the repository address and the folder you want it to go to. So for example, on my VIM plugins, I use the vim-rails plugin by Tim Pope. So to create a git submodule off of this repository for the plugin I use the following:

[~/git/dotmatrix]$ git submodule add \
https://github.com/tpope/vim-rails.git \
vim/bundle/vim-rails

This will create a “vim-rails” folder in vim/bundle/ and then download the files from the repository. Meaning that when I commit and then push my dotmatrix repository, it will upload the information for the submodules into my repository on Github. When I set up a new computer, I simply install Git, and then run the following:

[~/git]$ git clone \
git@github.com:mkoby/dotmatrix.git --recursive

You’ll note the “–recursive” argument, this is what tells git to first download the files for the repository and then recursively create the folders and download the files for the submodules. I then run my setup script that sets up the various configuration files to their appropriate locations so that I’m ready to code with just a few commands.

Updating the Submodules

Once you have the submodules, you have to update them from time to time. Maybe there’s a bug fix, or maybe a new feature in your submodules. To update them is actually quite simple, you simply run the following command:

[~/git/dotmatrix]$ git submodule foreach \
git pull origin master

This goes through each submodule’s folder and runs a regular “git pull” on the folder bringing in the latest changes. The “foreach” argument is actually built into git’s submodule functionality, so there is no hidden magic here.

Conclusion

This is the primary place I’m using Git’s Submodule functionality, but this could be used to separate out various project files into separate repositories for better project organization. If anyone sees that I’m doing something wrong, just let me know as I’m always looking to improve my workflows.

:!echo 'spec -f specdoc spec/greeter_spec.rb -l 8' && spec -f specdoc spec/greeter_spec.rb -l 8
spec -f specdoc spec/greeter_spec.rb -l 8
/bin/bash: spec: command not found

shell returned 127

Well, since I use RSpec 2.x (since I’m just now starting to use RSpec), the above error is quite annoying because the ‘spec’ command isn’t really used anymore (at least from what I can find on the internet).  So to get the RubyTest plugin to work with RSpec (and the ‘rspec’ command) you have to make a small change the plugin as marked below via a diff.

--- rubytest.vim.old	2011-01-29 14:29:19.897897990 -0600
+++ rubytest.vim	2011-01-29 14:30:16.487584334 -0600
@@ -21,10 +21,10 @@
   let g:rubytest_cmd_testcase = "ruby %p -n '/%c/'"
 endif
 if !exists("g:rubytest_cmd_spec")
-  let g:rubytest_cmd_spec = "spec -f specdoc %p"
+  let g:rubytest_cmd_spec = "rspec -f d %p"
 endif
 if !exists("g:rubytest_cmd_example")
-  let g:rubytest_cmd_example = "spec -f specdoc %p -l %c"
+  let g:rubytest_cmd_example = "rspec -f d %p -l %c"
 endif
 if !exists("g:rubytest_cmd_feature")
   let g:rubytest_cmd_feature = "cucumber %p"

Testing is Built In

Something to know about testing frameworks and Ruby on Rails, there’s one built in.  The built in testing framework in Ruby on Rails is Test::Unit.  There are other frameworks that you can substitute in place of Test::Unit, but as far as “out of the box” frameworks go, you could do worse.  Having a framework built in allowed me to teach Erick (my partner, who had never worked in Rails before) how to follow the TDD workflow: Write test, run test (seeing it fail), write minimal code to make test pass, see test pass, refactor (bold because people tend to forget this step).  Erick had never done test driven development before, and I had never used Test::Unit (or written a Ruby on Rails app) before, so sticking with the built in framework allowed us to minimize the number of things we needed to learn from the get go.

Delegation of Responsibilities

Erick and I had a pretty strict division of responsibilities with regards to the work needed on the application.  Since I’ve been developing code professionally for almost a decade, I was the developer.  Erick was the sweeper, going between design and development duties where ever needed.  And we hired a graphic designer, John to handle the more complex design work.  Having such divisions allowed us to separate out the work.  But it left me in a position where I felt I couldn’t develop a ton of code because I didn’t have any screens to wire up.  This came from a lack of deep understanding of the MVC (Model View Controller) pattern that Rails is based on.  To keep it quick, this pattern means there’s separation between the UI, data, and processing layers.

Testing Allows Coding Without The User Interface

Because the MVC pattern is designed with separation of various application elements in mind, I was able to develop the backend code without any screens.  The idea of testing functionality as you develop using the built in test framework allowed most of the major functionality to be written and built while the design was worked out else where.  This was crucial to our ability to get the product built and launched in one year’s time, while learning new languages and tools.  Once the functionality was done, it was just a matter of tying it together with the user interface once we had a design we were happy with.  Of course there were things that didn’t work quite like expected when we got the interface wired up, but it was less work than doing it from scratch, and having to wait would have meant delaying the product.

Also, with the tests we were able to see if it was the UI not working correctly or if it was really our functionality.  In a couple of places we were testing for the wrong thing, or had an error in our test that caused a false positive.  But those were much quicker to iron out with the tests in place.  Having unit tested as we developed, we were able to save tons of time on the backend of the project fixing bugs.

Observation

I believe that part of the problem is that I’m not surrounded by other Ruby/Rails programmers and doing that kind of work on day to day basis.  I spent 5 years in a C# office and thus was able to learn C# pretty well, and when I left that shop to better pursue programming, I was surround by “better” C# programmers that taught me even more.  I believe that I would be better at Ruby today (not having to look as many things up) if I was in an environment that was utilizing the language (and/or Rails framework) on a daily basis.

The Plan

I plan to continue in my attempt to learn a new language every year.  Upon further reading of several blog posts, I came across one that suggested that not only learning a new language but to also rotate the paradigms behind the language you learn (object oriented, dynamic, functional, etc).  This not only allows you to learn a new language but also new concepts and new ways of thinking about problems because a functional language requires a very different thought process than dynamic one.

So with that in mind, here’s what my language plan looks like over the next few years:

• Oct – Dec 2010: Ruby
• 2011: Clojure
• 2012: C

I went with Clojure for a couple of reasons.  The first being that it’s a functional language.  Secondly, it’s not tied to the Microsoft .NET platform (like F#).  While I’ve heard and seen good things about F#, I wanted to keep the Microsoft stack strictly a day-job thing.  Plus Clojure runs on the Java Virtual Machine, so it can really run on any machine that runs Java.  Finally, going with Clojure will bring some experience with Lisp, since Clojure is very Lisp like.  This will bring me at least a smidging of experience with using Lisp, without actually having to learn Lisp.

As for C, some would argue that the C programming language is a “functional” language.  And while there is truth in that point of view, I personally view C as “systems language” (something used to write drivers, operating systems, etc).  Learning C is also a personal mission of mine, and one that I’ve had since  was 15 and never just banged it out.  Something else always came up.

A good developer already knows that using source control is a good practice that every developer should be following regularly.  So using a online source control repository, means that not only are you doing source control but you also have an offline copy of all your code.  If you computer was to ever crash, then getting back to where you left off isn’t nearly as difficult than having to start from scratch.

But one important aspect that doing this buys you, is when you’re talking to potential employer (or client), and they ask for code samples (as any good interviewer, interviewing people for a programming position should do) you’ll be able to point them at your repositories to allow them to peruse through and see what kind of work you can do.  Seeing someone’s code can really help a good developer interviewer see how a potential employee thinks out problems and organizes solutions to those problems.  This can be an important first step towards determining if the interviewee has some skill.

The downside is that a nice looking code repository can be faked.  A good interviewer will know what questions to ask and what answers to look for when asking about the solutions presented in your code repositories.  If they still have doubts, they could ask you (the interviewee) to take a coding test, but hey if you’re as good as you’re presenting to the interviewers then that should be cake, right?

I’m happy to say that I was successful.  I wrote a simple rotation cipher application (rotation cipher is also commonly known as the Caesar Cipher).  It took me a grand total of maybe 4 hours to write the code (most of it spent on getting the UI just right), and then literally 15 minutes to publish it to the App Market.  The moment I hit the “Publish” button, I was able to open the Android App Market on my phone, do a search, and find my app.  Now that’s quick.

If you want to download and mess with my app, but I promise is not really something to write home about, you can use the QR code below, or goto the AppBrain page directly.

.

I’ve also open sourced the code at GitHub

The thing about editors like Emacs or Vim (VI Improved) is that they are completely cross platform.  There is a version of both that runs on all operating systems (Windows, Mac, Linux, etc).  In fact, VI is part of the Unix standard and any version of Unix doesn’t actually qualify as Unix without VI being installed.

I started back on Emacs because that’s what I had spent the most time in back in the day (as they say).  But lately I’ve been reading that some colleagues and other programmers that I follow (blogs, twitter, etc) are using Vim these days.  Even going so far as to attempt to do their .NET programming in it, so I started looking at that again.  What follows below are some resources that might help you learn about these editors.  Learning either Emacs or Vim will allow you to have an editor that is available on all systems and thus you can truly learn one editor and use it the rest of your life regardless of operating system.

Emacs Resources:

• Peep Code – Meet Emacs ($9): This is a nice one hour screencast that covers many of the basics of using Emacs. It covers navigation, buffers, plugins, and other general use topics.
• Emacs Starter Kit (my personal fork): This is a nice pre-configured emacs.d folder. This comes with several plugins, modes, and other useful things for making Emacs a joy to work with, especially when it comes to dynamic languages. My personal fork includes the color schemes, and yasnippets.
• FOSSCasts Emacs: Some more (free) screencasts for learning Emacs.
• Emacs Wiki: Many useful pages with lots of nice info about using and setting up various features in Emacs.

Vim Resources:

• Derek Wyatt’s Vim Tutorial Videos: This awesome set of videos is designed to take you from novice to beyond novice with using Vim. Derek is energetic enough that you almost never get bored and the videos are informative.
• VimCasts: While not so much for “beginners” there are lots of good screencasts here for Vim users.

There you go. Hopefully these will get you on your way to using an open source cross platform editor. Do try and ignore the holy wars around these two editors, each one serves different people differently and as such what works for you might not work for someone else. Find the one you like and use it.

All video codecs are covered by patents. A patent pool is being assembled to go after Theora and other “open source” codecs now. Unfortunately, just because something is open source, it doesn’t mean or guarantee that it doesn’t infringe on others patents. An open standard is different from being royalty free or open source.

You’ll notice that Steve Jobs says that all video codecs are covered by patents.  However this is just not true.  Theora is patent free and was designed as such.  The Theora codec is similar to the Vorbis codec for audio in that it is designed and written to be patent & royalty free.  Anyone can implement it and use it without having to pay some governing body.

The thing about H.264 is that, while it might be an open standard (in otherwords anyone can write an implementation based on the published standard) it is not in fact royalty free.  The governing body (MPEG LA) has said that H.264 will remain royalty free for web video through 2015.  This means that come January 1, 2016, they could start asking for cash.  And not everyone is going to be able to pay for the right to use it.

Video Codecs, What are They?

Before I go further I want to spend a few lines talking about video codecs. What a video codec is, is an algorithm for encoding a video signal. Different video codecs exist and serve different purposes. The thing about H.264 is that it allows someone to encode higher quality video at smaller file sizes (which is a very good thing). Apple has adopted H.264 as its video codec of choice, also Blu-Ray uses H.264 as it’s codec for encoding movies to the platform. So H.264 is a really good codec and has been adopted by the those in industries who use video, and understandably so. The idea of any codec is to get the highest possible quality into the smallest file.

The argument for which video codec to use for HTML5 is between H.264 and Theora. Theora is a video encoding codec that is free, open source, and royalty free (no one has to pay to use it or implement it). The argument that Steve Jobs is making is that even though Theora is open source and royalty free, it infringes on patents held by others.

The Issue of Software Patents

Lets get this out of the way.  Patents are, at their core, a good idea.  A company invents something, they patent it.  In return for making the idea public knowledge they get exclusive use of the idea for a pre-determined period of time.  During that time anyone using the invention has to license it from the company that holds the patent.  This is a good thing as it makes ideas public and still allows the company to retain some exclusive use of it.  It shows other people what can be done and to some degree encourages innovation, because if you can see how someone did something it might lead to other ideas.

Software patents however are a horrible idea.  The idea that you can patent a way to do something is a little more confining and limits innovation.  If I need to write an algorithm that takes two numbers and returns to me the largest of the 2 numbers, I might do something like

    int ReturnLargerNumber(int a, int b) {
        if(a > b )
            return a;

        return b;
    }

Now, someone later might come along and do something different but similar (as there aren’t a ton of ways to write this kind of code). If I had a patent on returning a larger number then I could sue anyone who implements it, no matter how similar or different. Keep in mind that this is a really lame example but it should demonstrate the idea that patenting an implementation is a bad idea. This is the heart of the software patent issue. If someone came along and had a better way to return the larger of two numbers, I could sue them thus holding back a better solution to the problem.

This all comes down to the idea that there is more than one way to do something.  What Steve Jobs would like us to believe is that there is no possible way that Theora could achieve the same level of compression and quality as H.264 unless it infringes on the patents involved in H.264, thus doing things exactly the same way.  Again, such a argument is good for his business but doesn’t exactly promote an “open web” that he seems to be so vocal about.

When it comes to writing software there is almost always more than one way to achieve the same goal. You can give 5 programmers the same problem and the same tools to solve it and chances are you’ll get 5 different solutions. You might get a couple that are similar but they’ll still be different. So when while Theora might serve the same purpose as H.264, it doesn’t mean they achieve their goals in the same way.

I feel that I should also note that, in most cases where a company has accused an open source project of infringing on patents, the company making the accusations has been unable to prove so in court. In most cases (read: almost all) the accusing company was making false claims in hopes of spreading fear, uncertainty, and doubt (or FUD).

The Case of Open and Royalty Free

In the end this whole thing comes down to the idea of an open web. Steve Jobs says he wants an open web but then says that he won’t use Theora because of possible patent issues. It would make more sense for him to put some time into ensuring Theora and Vorbis don’t infringe on any patents by releasing patches and pushing their use if he truly wanted an open web.

The H.264 video codec requires a license to use, the same way the Mp3 codec requires a license to use.  While the Theora and Vorbis codecs do not require such licenses, companies like Apple don’t like to use them because they have their hands in other codecs (H.264 or AAC in Apple’s case).  

Apple created WebKit (the rendering engine of the Safari web browser) by forking an existing open source project called KHTML and fixing the issues they saw with it. They then in turn released WebKit as an open source project. Why not do something similar with Theora and Vorbis? He’s already done it once, why not do it again. If he was really about an open web, this would be done already.

It makes sense to look into things that are open sourced and royalty free when it comes to internet standards, because not everyone can pay license fees if they want to be completely compatible. And if we rely on open standards and royalty free codecs, then everyone can enjoy the same (or at least very similar) user experience on the web. As it stands right now, only Safari and Chrome implement H.264 for HTML5. Mozilla implements Theora (open source company is always going to implement an open source solution over a licensed solution). Chrome actually includes support for both.

As long as people disagree on what to implement it is going to give web users an inconsistent experience and to me, that’s the largest part of this problem. The idea of standards is to ensure an consistent experience across implementations and if people can’t agree on what goes into a standard programmers are stuck having to do more work to ensure that consistent experience.

This year, Alt.NET Houston will be hosting it’s 2nd Open Spaces Conference.  Last years was such a success that many wanted us to do it again.

The What and When

This year the conference will be held from Friday, April 30th – Sunday, May 2nd. We’re adding Friday (starting at noon) for workshops. We will have 2 concurrent 4 hour workshops that you can attend if you like. The topic for these workshops is still to be determined but will be announced closer to the time of the conference.

Friday evening we will hold the planning session, where we will all gather and suggest topics that we either want to present/convene, or that we’d like to hear about. This is an important part of the event. Your satisfaction with the conference is completely in your hands. If you want to suggest a session, it’s important that you are there Friday evening.

The Where

The conference will be held at the Houston Microsoft office, located on the west side of town. You can find a map here.

How Much

This year the price of admission is $20. This is being done for 2 reasons. First and foremost, it gives us some money to supply food, snacks, and beverages. Secondly, it ensures that people will be less likely to sign up and not attend. We are making an exception for students though, so if you are a college student interested in attending, please contact Ben Scheirman before registering.

Registration

You can register at the Alt.NET Houston website. Here is a direct link.

The first thing you have to do is add the git remote for the other user’s code.

git remote add my_new_remote git@github.com:mypartner/OurProject.git

This adds a git remote, with the name “my_new_remote” and that is pointed at my partner’s fork of our project.

Next you’ll want to fetch the remote repository (as usual, with git this will include the entire change log, and all files).

git fetch my_new_remote

After you have the remote, you can create a new local branch that points at the newly fetched code. Below I create a branch called “partner_dev” and point it at my_new_remote/dev (assuming that there is a branch called dev in my partner’s repository)

git checkout -b partner_dev my_new_remote/dev

Now you can look at the changes made to the repository but keep it separate from your work. This is a nice way to mess around with other people’s work without having to bring it into your own. I’ve been using this method to checkout the UI template changes my partner has been committing every few days.

The main issue I had with many people’s opinions was that they were all targeted at explaining to managers, c-level folks, and others about why craftsmanship was important.  They also focused heavily on how to explain to those people why they should hire someone that is a craftsman over someone that would (in most cases) be cheaper.  I felt this was the wrong approach because it was outward rather than inward in it’s direction.  How can you explain to a manager why hiring a craftsman is important when we personally don’t know what a craftsman is or why being one is important.  I heard very little discussion about what a craftsman is or why you’d want to become one.

So today, I’m going to talk a little bit about what I feel being a craftsman is and how that idea can be applied to the development/creation of software.  And to do that, we have to start at the beginning and define what a craftsman is.

What is a Craftsman

If we look up craftsman in the dictionary, we see something like this

A person who practices a trade or handicraft

So by definition, a craftsman practices a trade.  Our trade is that of software development.  When people think of the word “craftsman” they generally think in terms of woodworking.  A craftsman takes a piece of wood and turns it into something beautiful.  This kind of thing generally takes lots of practice and time.  Time spent messing up, cutting a piece too short, splitting a piece of wood, and so on.  You have to do a lot of things wrong in order to learn how to do them correctly.  Eventually you become a skilled craftsman.  You learn a lot of things to not do.  In generally becoming a craftsman is more about learning what not to do than it is about learning what the right way is.  But the main point here is that the craftsman spends time on his craft.  He works at it daily.  Looking for ways to improve and build a better whatever.  Over time the craft is perfected, at least as much as it can be.

A Software Craftsman

When it comes to software, there are a lot of ways to do things.  You can test, you can design, you can encapsulate, inherit, override, and continuously integrate.  You can spend hours refactoring, changing bits of code until they’re just so tight that on occasion you can’t understand it anymore.  All new software developers start out simply by trying to make the computer do something.  Sometimes it’s just about getting it to show text on a screen.  Eventually they graduate to automating tasks, very functionally (do this, then do that, then to something else) and without very little thought to re-usability.  Then someone shows them how to make methods of common tasks, and then eventually how to break those methods into classes (if their doing object oriented programming).  But it’s a slow process, some of these things can take years to master, many times they learn how to be better from someone else.

The general idea is the same though.  To become a good programmer, you can’t just do it in a nine to five fashion.  You have to practice it at home, spend time working on learning new things, finding those new ways to not do something.  You’re not going to learn everything by doing it at a job day in and day out.  The person learning to build furniture is going to learn how not to make chair by making the chair wrong a few times and so the same goes for someone looking to build software.  They will go through a lot of wrong solutions before they start understanding why the correct one is, in fact, correct.  Sure, someone could tell them, but then they haven’t experienced something for themselves and they don’t understand for themselves why it’s the right way.  They only know it’s the right way because someone told them so.

Driving to be Better

Really it all boils down to a personal choice.  Are you going to work to be better at your trade/craft or are you going to linger and stay in that little space that you are so comfortable in.  Why is software craftsmanship important to you?  Why should your manager care if you don’t?  Why should anyone care if you don’t?  In the end being a craftsman (in anything) isn’t about anything other than being the best you can be at your craft.  If you are developing software then you will strive to create better software regardless of who it’s for.  In the end, you’ll do the things that make you a better craftsman because they are why they make you better.  Not because someone told you to do it that way.  In the end, we all want to be the best at whatever we do.  That to me is the sign of a craftsman.  Someone who as a constant drive to be better at whatever it is they do.

This was my first Open Spaces conference (I missed the one held in Houston last year due to the recent birth of my son), and I have to say I quite enjoyed the format.  There didn’t seem to be quite as many breakout sessions at this one as I’ve heard Open Spaces can be known for, but maybe they happened and I missed them.  The people doing the talks did a great job and the open atmosphere was great.  I was in one session where the speaker had someone take over his laptop to give a demonstration on some areas of the topic he wasn’t too familiar with and it was great.

A wiki was set up for the conference, and people were uploading session notes, links, and even recordings of some of the sessions, so check out that wiki at http://pablosfiesta.pbworks.com/

Having attended this conference, I’m now even more excited about the Open Spaces that the Housotn Alt.NET group is working to put together for the first weekend in May.  The fact that there are so many people that are willing to share their experiences and knowledge with others is great and hopefully I continue to surround myself with these kinds of people.  So bring on the Houston Open Spaces conference.

So if you’re looking for some nice gEdit color themes, check out mig’s repository.

Click for full size

]]> http://www.mkoby.com/2010/02/13/gedit-color-themes/feed/ 3 http://www.mkoby.com/2010/01/25/learning-the-ruby-programming-language/ http://www.mkoby.com/2010/01/25/learning-the-ruby-programming-language/#comments Mon, 25 Jan 2010 15:30:52 +0000 Michael Koby http://www.mkoby.com/?p=1467 Continue reading →]]> I’ve set out to learn a new programming language (for several reasons that will be disclosed at a later date), the language of choice was Ruby, so that eventually I could learn some Ruby on Rails for the purpose of getting back into web development.  I have found a couple of nice ways to help with learning the Ruby programming language.

Ruby Koans

A couple weeks back while attending a geek dinner, someone at the table mentioned the Ruby Koans as an interesting way to learn the Ruby programming language.  They were right.  What are the Ruby Koans?  They are a set of unit tests all set to fail and the object is to make each test past, one at a time.  The goal is that, as you complete the code to make each test pass, you eventually learn the Ruby language.  I’ve been doing them for the last week and a half with great results.  I’m by no means an expert in Ruby but I am learning some interesting things about the language.

RubyQuiz.com

RubyQuiz.com is an archive website of the first 150-ish quizzes that took place on the Ruby Talk mailing list.  While the quizzes still happen on the mailing list, this website only has the first 156 quizzes posted to the mailing list.  The idea is that you are presented with a problem that you must solve using the Ruby language.  Several solutions are provided for each quiz so you can compare your answers.  It’s a great way to get your mind thinking in a Ruby way, once you’ve become familiar with the language (see the Koans above).

The reason for the lack of OAuth and Search being complete is due mainly to 2 simple facts:

1. The search methods return types only come back in the JSON format, and my experience in parsing JSON pretty much non-existent.
2. I don’t understand OAuth enough to feel I can implement it correctly.  I’ll get to this eventually but it’s not overly necessary to do everyday Twitter stuff (update status, read friends timeline, etc)

Also, there is a wiki with some more information as well as some example code to get folks started, so be sure to check that out as well.

Again her are the links to the project and its wiki:  TwitterNET on Github & TwitterNET Wiki.

I’m hoping to see some forks and some user contributions, I currently have the project under the GPL 2.0, but  I’ll probably change this to a more friendly BSD style license in the future.