Oct
13
Need a Friendly, Experienced, Web Developer?
Filed Under Software, Uncategorized, business, life, ruby | Leave a Comment
I have been rolling around the idea of starting up more freelancing to try to bolster my savings for the coming years, so I’ve decided to take on more consulting work. For an indepth look at my work experience and skills, please visit my linkedin profile, here are some highlights.
- 5 years relevant web development experience
I’ve worked a ton with the web, I’ve done everything from ColdFusion to my current favorite, Ruby (and Rails). I have a lot of experience working with JavaScript and XHTML/CSS, very comfortable doing frontend and backend development, as well as database work (although, I don’t want to use the term DBA). If you’d like to see my portfolio, contact me directly.
- Did I mention I love Ruby?
I have done a lot of work with Ruby in the past couple of years, I was highlighted on the RailsEnvy podcast a few weeks ago for a modest open source contribution I made called SmartMonth. I’ve worked on some medium-sized rails deployments, and am looking to grow my portfolio.
- Plays well with others
I love working on small, motivated teams. I always enjoy adding (and learning) from the synergy of a great team. I also test all of my code (quite thoroughly) and won’t break “the build”.
- UNIX Aficionado
I love UNIX, and its my deployment environment of choice, I’ve got a lot of experience working with Capistrano, and am very adamant about automating things wherever possible, and documenting things thoroughly.
- Entrepreneurial-Minded
I have a passion for growing things, I am a very dedicated team member, and am also very aware of the needs of startup-oriented businesses, I’ve worked with a few startups at this point, and have gathered a decent amount of relevant experience helping companies and products grow.
If I sound at all interesting to you, please don’t hesitate to drop me a line, or if you know someone who might be interested in hiring me, please forward my information along and I’ll send you a Christmas card.
Thanks everyone!
Sep
23
Programmatic Migrations for Rails Plugins
Filed Under Software, apple, ruby | Leave a Comment
Today I was faced with an interesting dilemma, how does one programmatically define migrations into a plugin so you can essentially “plug-n-play”. I did a little bit of research into Rails Engines, and I wasn’t too terribly excited about the notion of having a dependency for such a small plugin, if this were something more integrated…I’d probably use it, but for this, I really only need to have these migrations run once you’ve installed the plugin, and be on my way.
So, I decided to do a little bit of research on the ActiveRecord::Migrator class to see how I could approach programmatically executing the migration outside of the standard rake task, so I could build my own custom migration rake task for my plugin.
It turns out, there are a bunch of functions you can utilize to build your own custom migration tasks for your plugin, that I wasn’t immediately aware of. Here is how I did it:
namespace :myplugin do desc "migrates my plugin's migration files into the database." task :migrate => :environment do ActiveRecord::Migrator.migrate(File.expand_path(File.dirname(__FILE__) + "/../db/migrate")) Rake::Task["db:schema:dump"].invoke if ActiveRecord::Base.schema_format == :ruby end end
I simply saved that block of code into my plugin’s /tasks folder and named it custom_migration.rake. Next, I went to the root of my application and ran rake myplugin:migrate, and huzzah! it worked!
Nothing too amazing, and I actually based this entirely on the vanilla db:migrate function. The first line of the task essentially tells the ActiveRecord Migrator to search through my plugin’s db/migrate folder for any migration files it can find, and then brings all of them up! It would be nice if the vanilla db:migrate supported a MIGRATIONS_PATH constant so we could just use the same mechanics and build on top of them, rather than essentially re-write them just to do this.
OR better yet, wouldn’t it be nice if rails db:migrate actually scanned our plugins directory for migration files as well? That sounds like the best option to me.
Now, I am not sure if this is “the ruby way” to handle this problem, and as I stated earlier, Rails Engines is probably the way to go if you have a much larger plugin you are designing, but for me, this seemed to work just fine.
Limitations
There are some limitations to that custom task. For instance, if you were to run db:rollback, it would not be aware of the migration files that I have previously run that live within my plugin, you’d have to build another custom task to manage revoking the migrations you installed. Also, if they end up changing the way you actually migrate migrations, you might be screwed. But, alas, here is hoping for that MIGRATIONS_PATH constant!
Aug
21
A Little Publicity For My Little Plugin!
Filed Under Software, life, ruby, technology | 1 Comment
Thanks to the fellows over at Rails Envy for doing a quick spot on my SmartMonth plugin! I actually had never heard of Chronic until they had mentioned it. I could see how this would actually go very well with a gem like that!
Speaking of SmartMonth, I have a couple of cool optimizations I plan to make in the new week, so stay tuned if you are interested!
Aug
14
My First Ruby/Rails Contribution: SmartMonth
Filed Under Software, business, ruby, technology | 8 Comments
Our big project at Panoctagon has a lot to do with time and dates, so we’ve been developing a series of Rails plugins that make our jobs easier. I had a lot of fun building this one, and I could see other people finding this interesting, so we decided to open source this one. I think it’d make a great addition to Rails core (if I do say so myself :P), but I am not really up to all the effort involved. Instead I created a simple to use, documented, and tested plugin that works with Rails!
So what does it do? Basically, it makes date month values more meaningful by adding a new Month class that can do complex(ish) calculations against the days of the month for you. It also allows you to treat a Month as an enumerable container, allowing you to iterate through the days of the month like an array.
Lets peek at some example snippets:
Getting The First Tuesday of September 2009
1 2 | Month.september(2009).first_tuesday #=> Date object Month.new(9,2009).first(:tuesday) #=> Date object |
Getting Every Friday in August 2008
1 2 | Month.august.every_friday #=> Array of Date objects Month.new("August").every(:friday) #=> Array of Date objects |
Getting Every Thursday and Saturday in June 2007
1 2 | Month.june(2007).every_thursday_and_saturday #=> Hash of Arrays of Date objects Month.new("June",2007).every(:thursday,:friday) #=> Hash of Arrays of Date objects |
Getting The Last Monday in April 2005
1 2 | Month.april(2005).last_monday #=> Date object Month.new("April",2005).last(:monday) #=> Date object |
Enumerating Through the Month of August 2008
1 2 3 4 5 | month = Time.now.month #=> Month object of the current time requested month.each do |day| day.to_s #=> Week day name ie: Saturday, Sunday, etc. day.to_i #=> Date value in context of the month ie: 1..31 end |
Other Odds and Ends
1 2 3 4 5 | Month.april.size #=> total number of days in that month Month.august.next #=> returns a month object populated with August Time.now.month #=> returns the current month in context to the #now response Month[5] #=> May Month object access as array index Month[:april] #=> April month object access as hash key |
So, as you can see, it saves a lot of time and calculations and keeps it easy for you to treat months as essentially a container! Really useful for doing complex calculations against dates.
If you would like to use my plugin, feel free, I’ve released it under MIT, and its located at my github account. Please give me some props if you do, or send me a line.
If you are interested in my rdoc documentation, check our company’s documentation server. Let me know what you guys think!
Aug
13
Got GitHub?
Filed Under business, life, recommendations, ruby, technology | 3 Comments
10 points for most original title, ever.
Lately, my company and I have been looking into the benefits of switching to Git for source code repository management. Its currently the new “hotness” of the hacker world, and with some of the claims that I’ve read, its pretty hard to ignore.
Linus Torvalds has made a few references to how much he hates tools like Subversion and CVS, and he has a lot of interesting reasons for feeling the way he does. I don’t agree with everything, but then again, I am not writing a kernel. Subversion has worked great for me and my team in the past, but we are definitely starting to envy some of the Git advantages.
Its indisputable that Git makes it unbelievably easy to branch and tag your repositories, hands down. The bigger and more integrated my codebase and team is getting, the more of crucial of a feature that is to us. Decentralization is not a big deal to me. Frankly, I never am really “off the grid”, so most times I just do git commit followed by a push.
Fortunately for us, Unfuddle supports Git now, so its easy for us to use our existing project management tool with this new technology, at no extra investment! But, I have to take a moment to say, GitHub is definitely pretty killer. Unfuddle’s support for Git is new and will improve over time, but I am very very impressed with how well GitHub has nailed the integration. The biggest reason for me to move (some) of my code to GitHub is for the public aspect of it. From this point forward, I will be posting my company and I’s open source contributions there. Mostly because Unfuddle doesn’t provide external access to projects in the same way, which is actually sort of strange in my opinion.
Maybe in the future I will be so inclined to product an Unfuddle-Git bridge to keep my repositories (edit: there is one already, why isn’t this a part of GitHub yet?!) synchronized, for projects I plan to open source. Overall, I am pretty happy with Git, I think my initial impressions of it were tainted by the “growing pains” I experienced while trying to get it to work with Unfuddle. Seriously, with GitHub I was up and running with the repo in under 2 minutes!
You can check out my repositories here. There is one project there now that I haven’t talked about too much yet, mostly because I just built and released it in the last 72 hours. More on that soon!
Jul
11
Data Sharding and Replication in Ruby
Filed Under apple, ruby, technology | 4 Comments
The good peole at FiveRuns have just recently released a gem to the Ruby community that allows their ActiveRecord-managed data models to now have built-in sharding and/or replication functionality…with just a few lines of code!
What do I mean by Data Sharding? Read on:
Specifically we needed two features to scale our mysql database: application-level sharding and master/slave replication. Sharding is the process of splitting a dataset across many independent databases. This often happens based on geographical region (e.g. craigslist) or user account (e.g. flickr). Replication provides a near-real-time copy of a database which can be used for fault tolerance and to reduce load on the master node. Combined, you get a scalable database solution which does not require huge hardware to scale to huge volumes.
They call this new gem, DataFabric. DataFabric makes it super simple (and DRY) to make your application scales to multiple database shards, or even just provide basic replication to different database servers if you so choose.
For me, the idea of having something so complex as data sharding built into the core of ActiveRecord is absolutely fascinating! You don’t have to have any sort of mysql_proxy business, or other strange DRb services running in the background, just essentially plug and play.
Jun
20
Rails Continues To Add Polish
Filed Under ruby, technology | 2 Comments
I don’t really have the stones to run “edge” rails, but I try to keep up to date with all of the stable releases wherever it makes sense to. As many know, Rails 2.1 was just released with a host of new, severely awesome, features (like named_scopes, better support for third-party VMs, etc.), but edge already has some intereging functionality that makes me look forward to 2.2. Here is some of the highlights that interest me:
#link_to has new block functionality
Say you had a block of HTML you wanted to wrap an anchor around. there wasn’t a very acceptable way to do this using link_to, you’d have to do something like this to utilize it:
1 2 3 4 | <a href="<%= url_for :controller => 'users', :action => 'view', :id => @user %>"> <strong>Click this to view the user</strong> <em>this is more text that I want to be in the link</em> </a> |
I absolutely hate the idea of having brackets inside of brackets. That just looks, hell it smells wrong! This feature is awesome because it prevents you from writing REALLY ugly code! Now you can just do this:
1 2 3 4 | <%- link_to(:controller => "user", :action => "view", :id => @user) do %> <strong>view this user</strong> <em>more text here</em> <%-end%> |
That to me feels much more correct! Thanks to Sam Stephenson + DHH for this one.
String Inquirer
At first, I didn’t see much value to this feature, but after thinking about it for a bit, I can see its usefulness. Take a look at the example:
1 2 | str = ActiveSupport::StringInquirer("awesome") str.awesome? #=> true |
Basically that new function saves you from manually writing this:
1 2 | str = "awesome" str == "awesome" ? true : false |
Definitely a nice enhancement to the code, makes it much more readable. But, I don’t love the way you have to instantiate it, directly touching ActiveSupport that is. I’d prefer a syntax like “my string”.inquirize or something.
Along the lines of prettier code, we’ve also got the new Array#present? functionality which basically is a cleaner way of saying !Object#blank?
Declarative Block Syntax For Unit Testing
This is a very nice addition to the Test::Unit framework. A lot of people prefer RSpec over Test::Unit, but I prefer how close to the xUnit framework the syntax is. Anyhow, take a look at the old way to write unit test functions:
1 2 3 | def test_should_verify_user_logged_in assert_equal @user.is_logged_in?, true end |
And now the new way to do things:
1 2 3 | test "should verify user is logged in" do assert_equal @user.is_logged_in?, true end |
Its a subtle change, but, it makes the tests far more readable. I also like the move to a more DSL-esque syntax, rather than defining a bunch of functions.
All in all, the next Rails release continues to impress!
Jun
11
Ruby “Enterprise” Edition
Filed Under ruby, technology | Leave a Comment
Since I’ve been talking about Ruby VM’s lately, I thought it’d be interesting to bring up another “segway” technology that is being offered by my friends at Phusion: The Computer Science Company. They call it: Ruby Enterprise Edition. What makes it enterprise? Nothing really :), Its pretty much a marketing name, from what they told me. But, if you look behind the name, you’ll see some serious benefits to utilizing their edition of the Ruby runtime.
Highlights
Allows your Ruby on Rails applications to use 33% less memory on average, when used in combination with Phusion Passenger.
100% compatible with the official Ruby interpreter, version 1.8.6.
Well-tested and extremely stable.
Easy to install, either via a native Linux package or via the included installer.
Can be installed in parallel with regular Ruby. 100% self-contained, 0% installation risk!
The smart folks over at Phusion have improved the built-in Ruby garbage collector by 33%, and according to their benchmarks, its performance is quite substantial.
This edition of Ruby, in my mind, is more of an interim, “drop-in”, replacement until things like MagLev become more prevalent. While improving the garbage collector is definitely helping us in the performance arena, its still not addressing other core needs.
Regardless, as far as what my clients and services will be running in the next months? Passenger has proven itself time and time again to me (they are already to version 2.0 in under a month, amazing release too!), and with the integration of Phusion’s new Ruby interpreter, I can’t wait to see my apps soar!
Jun
7
Ruby Virtual Machines
Filed Under ruby, technology | 5 Comments
There is a lot of talk right now about Ruby/Rails and scalablility. People are watching Twitter fall on its ass due to its massive popularity. A lot of people seem to point the figure at their development team and say they obviously must have written bad code, or they’ve made bad design decisions somewhere in their code, etc. But why couldn’t it be Ruby? Could it be that we’ve finally seen the limits of Rails and Ruby on the web? I’d say its possible. So this begs the question, would Twitter be more scalable in a different language? What if it was written in ColdFusion? What if it was ported to the Google App Engine? Surely the Google stack can handle it, right? :)
Languages like Java, Smalltalk, .NET, etc. Boast virtual machines, which in most performance cases, tends to be what makes or breaks a language under load. There is a ton of discussion out there in the Ruby community about Ruby and virtual machines. We have projects like Rubinius, and MRI which are out to build a “drop in” replacements for the original Ruby runtime that provides all of the benefits and power of virtual machines for the language we love. The only downside is, these projects are green. Rubinius (according to lighthouse) is about 85% away from a 1.0 Preview release. I am not sure that Twitter is going to want to run on a preview codebase, so you can imagine its hard for it to be taken seriously by the “enterprise”. But, there is a contender that has recently come into the spotlight.
MagLev is a Ruby VM based on the GemStone S64 VM, which runs Smalltalk. The Smalltalk VM has been extended with special byte codes to make it Ruby compatible. GemStone’s Smalltalk VM has been used for over 20 years in sectors such as real time financial markets and the worldwide shipping industry. It as a mature, fast, stable, distributed, and transactional data store which can hold over a trillion objects or 17PB (Petabytes) worth of information. The goal of the MagLev project is to bring this distributed object technology to the world of Ruby on Rails.
This caught my attention. We’ve got a VM coming that has been in use for over 20 years running Smalltalk! MagLev has proven reliability and its coming to Ruby and Rails! The burst of innovation that Ruby has been seeing in the last 5 or 6 years is really impressive. Now, we are seeing robust technologies come to the surface to help push this language into bigger and more robust markets, its only a matter of time until we’ve rid ourselves of that “but can it scale?” question.
I can only dream of my future application stack:
- Apache 2 (webserver)
- Passenger (application server)
- MagLev (Ruby runtime)
- MySQL (DB server)
Thats a real dream team in my mind!