Archive for category Misc
According to wikipedia, a revolution (from the latin revolutio, “a turn around”) is a fundamental change in power or organizational structures that takes place in a relatively short period of time.
Somehow, I believe this is exactly what Ruby has done in the programming world, especially with the help of Rails. Over the last few years, Ruby lead a mini revolution in the midst of software development. Thanks to Ruby, developers now look at software development differently. One thing for sure, it pushed DHH to write Rails and then convinced thousands of people to develop Ruby based applications on a daily basis.
How did it happen?
Let’s take a look at history of revolutions. Some people get frustrated their situation, they try to find workarounds until it’s just too much and the revolution kicks in.
Ruby came up with a new holistic perspective on things. Unlike most other programming languages, one of the main key value of Ruby is that writing code should feel right for the developer. You feel good about it because the language was written for humans and not machines. Basically, the language was designed to make you productive because it’s designed to please you.
As people were discovering web 2.0, Ruby also came with an opinionated framework, pushing for productivity, testing, simplicity and elegance. People started to see a new way of doing things and it quickly became the new, cool technology. Rails became a buzz word, developers were hired to work on cool projects, and books were selling by the thousands.
What did it change?
If you ask my mom, she would probably say: nothing, except that now my son works from his home office and he seems to really enjoy what he does for living.
Relatively speaking, Ruby did not change the way we work or live. However, I believe that it has influenced many software developers around the globe. Why else do you think that companies like Microsoft, Apple or SAP are working on their own implementation of the Ruby language?
When I first discovered Ruby, I was amazed at how “right” it felt, at how much fun it was to write code using its syntax and idioms. Now, if I don’t get that feeling when testing a programming language, I think there is something wrong.
The Ruby community also revived the Agile/XP world. Testing being a strong value of the community, we spent a lot of time discussing TDD, BDD, integration test as well as other practices such as pair programming, code review, sprints etc..
A few years ago, when people were asking me what programming language I would write their app in, I would reply Ruby and had to explain what it was, why it is great and would have to answer a lot of questions from potential clients. Nowadays, people don’t even argue, sites like hulu.com, twitter.com, yellowpages.com and many others are written in Ruby and it’s just part of the tools known to work very well.
The revolution is over!
Yes, Ruby made it’s revolution and the world “has changed”. But a real movement doesn’t die after its revolution, that’s actually when it has to be strong and defend its values.
This doesn’t mean that Ruby is dead or that Rails is “passé”. To the contrary, Ruby imposed itself as a new valued and respected player, a new standard if you will.
Ruby is certainly not the “new kid in the block”anymore nor the “popular kid”, however lots of older kids seem to want to have her on their team. (.NET, Java, Objective-C can all use Ruby)
The TDD + Ruby combo doesn’t surprise anyone anymore and the Enterprise is slowly but surely adopting Ruby. Ruby is now just getting better, tools and libraries are improving and the amount of users is growing.
Certainly the Ruby community is still small compared to other software developer communities, but the fundamental change was done and we are now working on improvement and keeping things running smoothly, growing and getting new ideas inspired by our experience and other communities.
Long live Ruby!
I have had the opportunity to go to and speak at many conferences but this year was the first time I had the chance to go to RailsSummit in São Paulo, Brazil.
I was really looking forward to this trip and I have to say it went beyond my expectations. I had really good feedback from people like the Phusion guys (Ninh & Hongli), Gregg Pollack and others.
For those who don’t know, RailsSummit is one of the biggest, if not the biggest, Ruby event in Latin America. It’s organized yearly by Locaweb, the #1 hosting company in Brazil (props to Akita & Cristiane for their work).
As part of my involvement in the Ruby community I have met a lot of Brazilians always willing to help and especially giving time to translate content. (A good example would be the Portuguese version of the Rails wiki or José Valim GSOC contribution) However, I did not realize how fast Rails was growing over here.
To come back to the conference, I have to say it was one of the best conference I have gone to. Chad Fowler, who gave the opening keynote, later told me that it reminded him of the first Ruby conferences in the US . For me, what made a huge difference was the fact that it was a very positive conference. People were happy to be here, eager to share and you could feel the passion. Unfortunately, I missed the first few Ruby conferences, but I can totally imagine how must have been. Passionate people, not trying to push their products but instead, share the cool stuff they’ve been working on. This is exactly the feeling I had during this conference.
Maybe it’s because I don’t understand Portuguese well enough or maybe it’s just a cultural thing, but the people at the conference were just super friendly and always willing to help. I was really glad to meet those who have been using some of my work, some new people to Ruby and people who don’t do Ruby but were just interested in knowing what was going on in the Ruby world.
The schedule was pretty packed and the discussions very interesting, you could certainly feel the excitement in the air. Ruby seems to catching up quickly over there. Brazilian Rubyists seem to be very pragmatic and a good illustration of that was certainly made by Vinicus Teles, Brazil Agile XPert, who shared tips on how to release a successful product.
I stayed a few days after the conference and went to visit the Rubyists in Rio. Rio is a great city. It has some of the best soccer players in the world and some seriously talented software developers. Ruby & Rails are not just the new trendy startup secret to success, companies like globo.com, currently the largest TV network in Latin America and the fourth largest in the world, also started using Ruby and Rails. I had the opportunity to visit their office and meet their teams. It’s very exciting to see how they use Agile/XP and Ruby and how they seem to be so successful. But I will keep that for another post.
Overall, even though the actual traveling to/from Brazil was a bit long, RailsSummit was a blast. I really hope to be able to come back next year, and by then, hopefully my Portuguese will have improved.
I had people asking me how come I was not blogging as much lately. Well, on top of being really busy, I have been blogging on other blogs such as the official Rails blog.
There aren’t a lot of Merb news, we are waiting for Carl and Yehuda to sign out on the 1.1 release and will hopefully soon start the migration work to Rails3. If you want more news about Rails3, check Yehuda’s blog and the official Rails blog. Lots of exciting things are coming up.
Finally, if you are planning on upgrading your Mac to Snow Leopard, these instructions are also valid for all Ruby developers on an Intel mac.
Over the weekend, I spent some time working on a Ruby + Rack +CouchDB project. Three technologies that I know quite well but that I never put to work together at the same time, at least not directly. Let’s call this Part I.
Before we get started, let me introduce each component:
- Ruby : if you are reading this blog, you more than likely know at least a little bit about, what I consider, one of the most enjoyable programming language out there. It’s also a very flexible language that lets us do some interesting things. I could have chosen Python to do the same project but that’s a whole different topic. For this project we will do something Ruby excels at: reopening existing classes and injecting more code.
- Rack: a webserver interface written in Ruby and inspired by Python’s WSGI. Basically, it’s a defined API to interact between webservers and web frameworks. It’s used by most common Ruby web frameworks, from Sinatra to Rails (btw, Rails3 is going to be even more Rack-focused than it already is). So, very simply put, the webserver receives a request, passes it to Rack, that converts it, passes it to your web framework and the web framework sends a response in the expected format (more on Rack later).
- CouchDB: Apache’s document-oriented database. RESTful API, schema-less, written in Erlang with built-in support for map/reduce. For this project, I’m using CouchRest, a Ruby wrapper for Couch.
Goal: Log Couch requests and analyze data
Let’s say we have a Rails, Sinatra or Merb application and we are using CouchRest (maybe we are using CouchRest and ActiveRecord, but let’s ignore that for now).
Everything works fine but we would like to profile our app a little and maybe optimize the DB usage. The default framework loggers don’t support Couch. The easy way would be to tail the Couch logs or look at the logs in CouchDBX. Now, while that works, we can’t really see what DB calls are made per action, so it makes any optimization work a bit tedious. (Note that Rails3 will have some better conventions for logging, making things even easier)
So, let’s see how to fix that. Let’s start by looking at Rack.
Instead of hacking a web framework specific solution, let’s use Rack. Rack is dead simple, you just need to write a class that has a call method.
In our case, we don’t care about modifying the response, we just want to instrument our app. We just want our middleware to be transparent and let our webserver deal with it normally.
Here we go … that wasn’t hard, was it? We keep the application reference in the @app variable when a new instance of the middleware is created. Then when the middleware is called, we just call the rest of the chain and pretend nothing happened.
As you can see, we just added some logging info around the request. Let’s do one better and save the logs in CouchDB:
Again, nothing complicated. In our rackup file we defined which Couch database to use and we passed it to our middleware (we change our initialize method signature to take the DB).
Finally, instead of printing out the logs, we are saving them to the database.
W00t! At this point all our requests have been saved in the DB with all the data there, ready to be manipulated by some map/reduce views we will write. For the record, you might want to use the bulk_save approach in CouchDB which will wait for X amount of records to save them in the DB all at once. Couch also let’s you send new documents, but only save it to the DB every X documents or X seconds.
As you can see, our document contains the timestamps and the full environment as a hash.
All of that is nice, but even though we get a lot of information, we could not actually see any of the DB calls made in each request. Let’s fix that and inject our logger in CouchRest (you could apply the same approach to any adapter).
Let’s reopen the HTTP Abstraction layer class used by CouchRest and inject some instrumentation:
Again, nothing fancy, we are just opening the module, reopening the methods and wrapping our code around the super call (for those who don’t know, super calls the original method).
This is all for Part I. In Part II, we’ll see how to process the logs and make all that data useful.
By the way, if you make it to RailsSummit, I will be giving a talk on Rails3 and the new exciting stuff you will be able to do including Rack based stuff, CouchDB, MongoDB, new DataMapper etc..
CouchDB is an awesome technology. I’m lucky enough to work on quite a big project where we decided to switch from MySQL to Couch for various reasons.
One of the many things I like with Couch is that it handles attachments and can replicate them as well as serve them for you using the Erlang based builtin webserver. (you can load balance your dbs and do some other really cool stuff)
Let’s take a use case. Let’s imagine that you have a web app with logged in users. Every user can have their own avatar.
No big deal, you get the user to upload his/her avatar to your app and add it to the user document in the database. To serve it from the database, you just need to create a proxy in nginx/apache and redirect the virtual avatar url to the protected DB making sure the request is a GET request.
Now, the problem is when you want to serve authorized attachments. Let’s imagine that we want to let our users upload private files, files that should be accessible only by the owner or users designated by the owner.
In this case, a simple nginx rewrite wouldn’t work. We need to authorize attachment requests. Here is a cool way of doing that using nginx and merb’s router. (Expect Rails3 router to do the same).
Let’s start by setting up nginx and create a proxy for couchdb:
Now that this is done, we are going to use Merb’s awesome router to handle the incoming requests. The cool part of this is that we won’t be dispatching requests so, going through the router is almost free. (check on the Merb router benchmarks for more info). Let’s edit our router and set a special route for our assets.
We are using a deferred route which gets executed instead of dispatching the request.
If the attachment route is being matched then we are checking what environment we are currently running in. If we are in production or staging environment then we are sending back a rack response to the webserver. The response is just a forward to the proper couchdb document behind the proxy. Of course, before allowing that to happen, we could authenticate the logged in user, log the request and do a couple of other things. You have full access to your models from the router, so authenticating a session isn’t a big deal. You could even create temporarily urls like AWS s3 does.
If we are not in production or staging mode, then just redirect the request to couch since we assume you have access to the local db. This way, your asset urls will be working in production and dev. In real life, you’ll want to apply the authorization before choosing how to deliver the document/attachment tho as you want it work the same way in development and production.
To celebrate the amazing work being done by Laurent Sansonetti on MacRuby here is a hello world using the new LLVM based compiler.
$ echo "p ARGV.join(' ').upcase" > hello_world.rb
$ macrubyc hello_world.rb -o macruby_says
$ ./macruby_says hello world
Note that to achieve this result, you need to be using the experimental branch of MacRuby and have LLVM installed. (check the readme available in MacRuby’s repo).
Let’s quickly look at what we just did.
We created a single line ruby script that takes the passed arguments, joins them and print them uppercase.
Then, we compiled our script into a Mach-O object file and produce an executable.
Here is an extract from Laurent’s latest status report:
Produced executables embed all the compiled Ruby code as well as MacRuby, statically.
It can be distributed as is and does not depend on anything MacRuby or LLVM at runtime.
The Ruby source code is compiled into native machine code (same process as we do at runtime with the JIT compiler), so it’s also a good way to obfuscate the source code.
The final binary looks like an Objective-C binary (except that it’s larger)
Don’t expect to compile Rails just yet, it’s still in a preliminary stage.
The final release you should let you pick one of the 2 compilation modes:
* normal mode: full ruby specs, compile down to machine code and use LLVM at runtime. (recommended for desktop/server apps)
* full mode: no full ruby spec support, no runtime code generation, no LLVM. (“very light application and/or if the environment does not support runtime code generation” (hint-hint))
As you can see, MacRuby is moving forward and the experimental branch should soon move to trunk.
To start with, I would like to make it clear to everyone that I do sincerely care about the larger gender issues that my presentation touched off. I have also replied and otherwise corresponded with everyone who has contacted me about my presentation, just as I have tried to reply to all of the blog posts that have been brought to my attention. At this point, however, it is clear that this issue has grown too large to be resolved through one-on-one contact, hence this public statement.
I have made a specific point of exchanging emails with most of the bloggers who addressed the gender issue, and I did so because I care about minority involvement in our community. I cared about this issue well before GoGaRuCo or this particular presentation, despite what anyone might think to the contrary, running the presentation past my wife/business partner and other colleagues well before I gave my talk. They, at least, understood the goals of my presentation, which were to leaven an otherwise dry topic with humor. It genuinely was not my intention to cause offense. People may be driven by personal choice or cultural background to take offense at any number of things, of course, but I think there is always a clear difference between trying to offend people vs people choosing to take offense.
My view is that offending someone is walking up to them and saying: “You suck, your code sucks and your partner’s code sucks!”.
That is not what I did in my talk. In the case of my talk, people knew what to expect, they *picked* the talk, and were warned by the organizers before I started that I would be using imagery potentially offensive to some. The topic of my talk was obvious, and I would have hoped that people who were likely to be offended would have simply chosen not to attend my talk or read my slides on the internet. It’s like complaining that television has too much material unsuitable for children, yet not taking steps to limit their viewing of it. You can’t have it both ways.
In the same way, people have been rather quick to judge the entire Ruby/Rails community based on my presentation and the comments of a few people. I have noticed, for example, a lot of comments making sweeping generalizations about Americans, Republicans, women, Ruby, Rails, men etc.. leading to an exchange of insults, things getting personal, and everybody feeling the need to fuel the flames by sharing their own opinion in public. While there is nothing wrong with sharing your approval or disapproval, I think it has also contributed to blowing this entire thing completely out of proportion. I would like to ask people to step back and reflect upon whether we are contributing anything useful to the discussion.
We can argue forever about morals, professionalism, ethics, respect, etc., though this is all a distraction from the real problem that was raised by Sarah, namely that we have very few minorities in the Ruby community, especially women. Minorities do need to be more represented!
So, instead of continuing an increasingly pointless debate about my slides, I would like to encourage the community to look further and see how we can change things.
Education, outreach, and self-censorship are certainly some of the options available. Please read Aaron’s blog post and see how you might make a difference.
For those who still want to talk with me, I will be at the RailsConf devchix’s discussion panel and more importantly, if you care about Rails Activism and you want to see things evolve, be sure to come to our Birds of Feather discussion of Rails Activism.
Update: Some people thought I wasn’t clear enough about my position and I therefore tweeted the following: “I obviously made a mistake. I didn’t mean to offend anyone but since I did, I failed.”
Update 2: Kirrily Robert wrote a very insightful article. Borrowing her words, I’d like to reiterate that “It genuinely was not my intention to marginalize or exclude anyone from my talk or from the Ruby community, nor to make them feel uncomfortable.”