to_lang is a project I've been working on that is now ready for an official introduction. It's a Ruby library for translating strings, backed by the Google Translate API. to_lang is unique in that it allows you to call translation methods directly on strings.
The first thing to do is require the library and call the start method:
require 'to_lang'
ToLang.start('YOUR_GOOGLE_TRANSLATE_API_KEY')
Voilà. Strings now have access to a bunch of dynamic translation methods.
"Very cool gem!".to_spanish
# => "Muy fresco joya!"
You can use similar to_language methods for any of the 53 supported languages. Google Translate attempts to detect the language of the string you're translating, but sometimes the source language is ambiguous, and Google Translate may guess wrong. In this case, you can manually specify the source language by appending _from_language to the end of the method.
"a pie".to_spanish
# => "a pie"
"a pie".to_spanish_from_english
# => "un pastel"
All the dynamic methods are syntactic sugar for a more general method, translate, which is also made available to strings. You can use this as well, as it may make programmatic translations easier.
"hello world".translate('es')
# => "hola mundo"
"a pie".translate('es', :from => 'en')
# => "un pastel"
Give it a try! I'd love to get feedback on it if you do.
The premise
GitHub is a fantastic service – probably one of my favorite sites on the web. I spend a good amount of time there browsing projects and it's inspired me to get more involved in the open source community. Best of all, it's free to do so. Accounts are free to create and you can create unlimited repositories for free, as long as they're viewable by the public. GitHub's beauty and power has whet my appetite to move all private repositories to their service as well, but for that I need to venture into the world of their paid plans.
Currently, there are a few divisions to their paid plans: regular plans and business plans. The regular plans are intended more for individual developers or very small teams, while the business plans seem geared more toward, well, businesses. Rather than list out all the details here, simply take a look at GitHub's plans and pricing page.
The problem
A private repository is defined as one that is only visible to the account holder and other users the account holder explicitly specifies. A private collaborator is one such explicitly specified user. GitHub's plans all have a hard cap on how many of each you can have for a given plan. They seem generally reasonable, but the basis of the system is just not very flexible for the customer. I'd like to see a pricing model that offers a lot more control over exactly how many repositories and collaborators I need.
Want a single private repository? Too bad, you have to pay for a plan with 5.
Want 6 private repositories? Too bad, you have to pay for a plan with 10.
Want 10 private repositories and 6 collaborators? Too bad, you have to pay for a plan with 20 and 10, respectively.
The tiers just don't make very much sense. Having to decide a plan based on these arbitrary numbers just doesn't match the potential needs of the customer well. I'd love to see more of a pay-as-you-go model, perhaps something like Heroku's model where you select explicitly how many dynos and workers you want and your cost is associated with what you actually use, in any combination of the two.
A case study, my case:
Currently I have my private repositories (as well as my sites) on a shared hosting plan with Site5, and when my contract with them runs out in May I'd really like to move all my repositories to GitHub and use Heroku to actually host my apps. I have about 8 sites that I'd want private repositories for, which makes it hard to justify the cost of a setup like this. For the cost of GitHub's small plan, I could buy another year of shared hosting which gives me storage for unlimited git repositories and hosts the sites. Granted GitHub offers a lot more benefit in its repository hosting than just storing the files, like shared hosting provides. But still, I'm finding the lack of control over the cost as compared to what I actually need to be a frustrating aspect of adopting their services.
I know, I know
I shouldn't expect the best for free. I shouldn't expect all the benefits GitHub provides over simple file storage not to come at a cost. I'm not too cheap to just pay for what I need. I will pay for what I need based on their current model when the time comes, but it leaves a lot to be desired. I imagine there are a lot of small-scale developers in a similar state – several small projects that are very economical to host with a setup like shared hosting, but hard to justify moving to a more specialized service like GitHub. More flexibility in pricing would help in making that jump. I'm also aware that they are fairly open to concessions and special cases if you contact them directly to set up a plan, which is great, but still puts another hurdle in the process, and doesn't change the fundamental flaw of the system: the arbitrary tiering and hard caps.
TL;DR
Extra features aside, GitHub's paid plans are an expensive alternative to other means of hosting remote repositories, and the arbitrarily tiered pricing model offers little control for the customer in managing that cost appropriately.
It's been a while since I wrote about what I've been doing in the web development world. Most of my mental energy is used at my day job, but I've been doing some work on my own, slowly but steadily.
I migrated a few of my apps from Rails 2 to Rails 3. This includes More Things Need To, Changesets, and this site itself. The hardest part of the process was deployment – getting all the right dependencies set up on my production machine. I'm thoroughly enjoying Rails 3. In particular, the new ActiveRecord API based on ActiveRelation is really awesome. It allowed me to do some internal refactoring on MTNT that greatly improved the maintainability of some of the basic logic. I'm also enjoying the new routing syntax quite a bit.
More Things Need To has received a bit of work beyond just the Rails 3 upgrade, the most notable of which is a new search feature. You can now search for entries by any string that appears in either its noun phrase or verb phrase. Currently the search just uses a primitive SQL query. I did a little research on indexed search with Sphinx but decided it was overkill for the small amount of traffic the site gets. It's certainly something that would become priority in the future if the site started getting heavier traffic and performance was an issue.
I started on my first real Ruby gem, to_lang. It's a Ruby wrapper for the Google Translate API that mixes a translation method directly into Ruby's String class. For now it simply adds a translate method, but my plan is to include a bunch of automagic methods to allow conversion between languages in plain English, like "a pie".to_spanish or "a pie".to_english_from_spanish.
As evidenced by my work on this gem, I've become more interested in learning Ruby outside the confines of Rails. I've spent some time experimenting with Rack and Sinatra and have been enjoying it. Perceptes now runs on Sinatra, in fact. All it does is pick a random quote to display, but it was a good starting exercise. I'm also looking at Grape as a possible framework for giving MTNT a public API, and considering OmniAuth as a new authentication system for it as well.
The RSpec Book from the Pragmatic Programmers has also reached an official release version, so I've been reading through that as well. I've had the book since its early beta version but ran into various technical problems the times I'd tried working through its examples. This time around, everything is going fine. I'm not a fan of Cucumber and wish there was a version that focused simply on specs, but it's still very useful. I've grown tired of Test::Unit so I'm planning to use RSpec from here on out.
Hosting is another thing I've been giving some thought to. Site5 has been a very good host, but now that I'm focusing solely on Ruby, when my current contract runs out I'm planning to move all my code to private GitHub repositories and host each application on Heroku, with email via Gmail. The only down side is that I would no longer be able to support my legacy PHP applications. Given that they get essentially no traffic at this point, I think it's a reasonable compromise.
On the far horizon, I have plans to redo Altered Perception, as it's embarrassingly out of date, and to recreate this site with a simpler structure, narrower focus, and a more elegant design.
