Ruby for Web Development
I recently started a new web dev project, and decided to use it to better learn Ruby. However, I don’t want to use Rails. I’d like to keep it simple. I also prefer to know a lot about the inner workings of a particular technology before I go and use a large framework that hides [...]Xfce at FOSDEM 2009
FOSDEM is over and it was a blast! Finally, after about four years, the team met again. It was the first time for me and it was great to meet them all in person. Olivier, Yves-Alexis, Nick and I stayed at the same hotel. Stephan stayed in Gent and the others spread over several other hotels in Brussels.
I arrived early on Friday and relaxed in the hotel room for a while, going through my slides and listening to a couple having sex next door for hours. If you’re able to count the orgasms then it’s definitely too loud. So I left the hotel and walked around in the inner city of Brussels for a while until Yves-Alexis, and shortly after that, Nick and Stephan arrived. We had a few beers at a bar around the corner and later went to for Pasta and Pizza in an Italian restaurant close to the hotel where Jens joined us. After that we went to the FOSDEM beer event and stayed there until half past midnight, only interrupted by the arrival of Olivier whom we had to take to the hotel. The beer was nice and since the place was so crowded we had a hard time understanding each other … but we somehow managed it.
We got up at around 7am the next morning and of course the beer from the evening before didn’t really make things better. The nice thing about the hotel (Hotel Du Congres by the way) was that there was free breakfast included though. It was rather basic but it did it’s job. Shortly after that we left for FOSDEM. We arrived in time for the keynotes and met Jean-François and Maximilian on our way to Janson (the large auditorium). Later we went for some french fries and mainly spent our time in the X.org devroom. Some of us went to the LXDE lightning talk and were quite amused by their claim that LXDE is better than Xfce (what does better mean anyway?) and the huge number of slides showing photos of their team at different conferences. Later that day we went to a restaurant called Big Mama in the very heart of Brussels were we had a beer and nice food. Everyone went to bed afterwards, except Nick, who kept hacking on the panel.
Sunday was a big day for me – I had a talk about Xfce 4.6 and the future of Xfce scheduled at 11am. I didn’t really sleep well and was nervous the entire morning. It didn’t get any better when I had finally booted up my laptop and the microphone was turned on. I don’t know how long I talked but I have the feeling that I literally speed-talked through the slides. I forgot a few things I would’ve loved to mention but all in all I think it was ok. There were quite a few sceptical faces in the audience but also a few who looked very pleased by the features and plans I presented them. I definitely think it was ok for my first talk in English at a big conference but I know I can do better. So I’d be absolutely happy to do that again next year!
I felt very relieved afterwards. We then went out to take a few group pictures (the following one was shot by Jens). In the meantime, Samuel and Jelle de Jong had joined us (I have no idea where Jelle went afterwards, but Samuel stayed with us for the rest of the day).
After that we want back to one of the devrooms until Maximilian came back from his car with a number of sandwiches he had bought on the way. We had a beer at the FOSDEM bar, ate our sandwiches and then went back to the cross desktop room for Stephan’s talk about Xfce as a platform. I think he did a good job overall, especially considering that he had just finished his slides the night before. I would’ve loved to see more about how to use the different libraries and maybe more details about our plugin APIs but he covered a few very important things about Xfconf.
After that we had another beer at the bar and went to the last talks in Janson. Samuel dropped his full beer, I accidently kicked my empty one and Olivier and I left early for the FOSDEM bus back to Brussels-South. I managed to catch an earlier train to the airport, had a short flight, then had to wait for the bus from Hamburg to Lübeck for 90 minutes and finally arrived at around half past midnight.
I think it was a lot of fun and I’ll definitely go to FOSDEM again. It was nice to put a face to all the names of people I’ve been working with over the last few years. Thanks to everyone I met there, it was a real pleasure! Hope to see you all again! Thanks to all the people who went to our talks (oh, and to that guy who wanted that picture of him and me – could you send it to me please?) and asked questions (“Has the Xfce team ever thought about participating in Google SoC?”, “How good is the relationship of Xfce with Xubuntu?”, “Are you still aiming to be lightweight?” amongst others). It was also great to see several packagers, like Mark from Foresight, Landry from OpenBSD and Christoph from Fedora.
As I’ve mentioned before, I would really like to talk at conferences again. It’s a challenge but definitely a nice one. If you know any that could be interesting for Xfce, please let me know!
Oh, and by the way, if you’ve taken any pictures of us at FOSDEM, please let us know!
Xfce at FOSDEM 2009
FOSDEM is over and it was a blast! Finally, after about four years, the team met again. It was the first time for me and it was great to meet them all in person. Olivier, Yves-Alexis, Nick and I stayed at the same hotel. Stephan stayed in Gent and the others spread over several other hotels in Brussels.
Friday
I arrived early on Friday and relaxed in the hotel room for a while, going through my slides and listening to a couple having sex next door for hours. If you're able to count the orgasms then it's definitely too loud. So I left the hotel and walked around in the inner city of Brussels for a while until Yves-Alexis, and shortly after that, Nick and Stephan arrived. We had a few beers at a bar around the corner and later went to for Pasta and Pizza in an Italian restaurant close to the hotel where Jens joined us. After that we went to the FOSDEM beer event and stayed there until half past midnight, only interrupted by the arrival of Olivier whom we had to take to the hotel. The beer was nice and since the place was so crowded we had a hard time understanding each other ... but we somehow managed it.
Saturday
We got up at around 7am the next morning and of course the beer from the evening before didn't really make things better. The nice thing about the hotel (Hotel Du Congres by the way) was that there was free breakfast included though. It was rather basic but it did it's job. Shortly after that we left for FOSDEM. We arrived in time for the keynotes and met Jean-François and Maximilian on our way to Janson (the large auditorium). Later we went for some french fries and mainly spent our time in the X.org devroom. Some of us went to the LXDE lightning talk and were quite amused by their claim that LXDE is better than Xfce (which is denied by the guys at LXDE, so they might not actually have said that ... what does better mean anyway?) and the huge number of slides showing photos of their team at different conferences. Later that day we went to a restaurant called Big Mama in the very heart of Brussels were we had a beer and nice food. Everyone went to bed afterwards, except Nick, who kept hacking on the panel.
Sunday
Sunday was a big day for me - I had a talk about Xfce 4.6 and the future of Xfce scheduled at 11am. I didn't really sleep well and was nervous the entire morning. It didn't get any better when I had finally booted up my laptop and the microphone was turned on. I don't know how long I talked but I have the feeling that I literally speed-talked through the slides. I forgot a few things I would've loved to mention but all in all I think it was ok. There were quite a few sceptical faces in the audience but also a few who looked very pleased by the features and plans I presented them. I definitely think it was ok for my first talk in English at a big conference but I know I can do better. So I'd be absolutely happy to do that again next year!
I felt very relieved afterwards. We then went out to take a few group pictures (the following one was shot by Jens). In the meantime, Samuel and Jelle de Jong had joined us (I have no idea where Jelle went afterwards, but Samuel stayed with us for the rest of the day).
After that we want back to one of the devrooms until Maximilian came back from his car with a number of sandwiches he had bought on the way. We had a beer at the FOSDEM bar, ate our sandwiches and then went back to the cross desktop room for Stephan's talk about Xfce as a platform. I think he did a good job overall, especially considering that he had just finished his slides the night before. I would've loved to see more about how to use the different libraries and maybe more details about our plugin APIs but he covered a few very important things about Xfconf.
After that we had another beer at the bar and went to the last talks in Janson. Samuel dropped his full beer, I accidently kicked my empty one and Olivier and I left early for the FOSDEM bus back to Brussels-South. I managed to catch an earlier train to the airport, had a short flight, then had to wait for the bus from Hamburg to Lübeck for 90 minutes and finally arrived at around half past midnight.
I think it was a lot of fun and I'll definitely go to FOSDEM again. It was nice to put a face to all the names of people I've been working with over the last few years. Thanks to everyone I met there, it was a real pleasure! Hope to see you all again! Thanks to all the people who went to our talks (oh, and to that guy who wanted that picture of him and me - could you send it to me please?) and asked questions ("Has the Xfce team ever thought about participating in Google SoC?", "How good is the relationship of Xfce with Xubuntu?", "Are you still aiming to be lightweight?" amongst others). It was also great to see several packagers, like Mark from Foresight, Landry from OpenBSD and Christoph from Fedora.
As I've mentioned before, I would really like to talk at conferences again. It's a challenge but definitely a nice one. If you know any that could be interesting for Xfce, please let me know!
Oh, and by the way, if you've taken any pictures of us at FOSDEM, please let us know!
Ruby for Web Development
I recently started a new web dev project, and decided to use it to better learn Ruby. However, I don’t want to use Rails. I’d like to keep it simple. I also prefer to know a lot about the inner workings of a particular technology before I go and use a large framework that hides a bunch of details from me.
However, I want to use ActiveRecord.
So, ActiveRecord. I install it on my laptop with “emerge ruby-activerecord”, and there I go. One “require ‘activerecord’” in my script later, and, awesome, it starts working.
Then I start working on my web host (DreamHost, if you’re wondering). It can’t find ActiveRecord. But it’s obviously installed, because I know DH supports Rails out of the box, and I don’t think you can have an install of Rails without ActiveRecord. So I poke, and then realise it might be installed as a Ruby “gem.” Ok, so I put a “require ‘rubygems’” above my activerecord require. Nice, now it works. Then I think, well, what if I put this somewhere that doesn’t require rubygems? Not hard to work around automatically:
``begin require 'activerecord' rescue LoadError require 'rubygems' require 'activerecord' end``
Nice, ok, that works. It’s probably a foolish micro-optimisation, but whatever.
Then I notice… ugh, this is super slow. Even on the web host, it can take a good two seconds for the “require ‘activerecord’” statement to execute. Yeah, I know, ruby is kinda slow. But 2 extra seconds each time someone hits basically any page of the website? Ugh.
So…. FastCGI. I know DH supports it, so I head over to the control panel and enable it for the domain I’m working on, and start googling around to figure out how to use FastCGI in a ruby script.
Unfortunately, there aren’t too many resources on this. Fortunately I found a couple sample dispatch scripts, one of which I ended up basing mine off of.
But then there was a problem. Inside my app, I use ruby’s CGI class to access CGI form variables and other stuff. Since the FastCGI stuff overrides and partially replaces ruby’s internal CGI class, there’s a problem. Doing “cgi = CGI.new” inside a ruby script that’s being served through FastCGI throws a weird exception. But I wanted to try to retain compatibility for non-FastCGI mode. And I couldn’t figure out how to get the ‘cgi’ variable from the ruby dispatch script into my app’s script, since I was using ‘eval’ to run my script. The dispatch script I saw used some weird Binding voodoo. Up at the top level we have:
``def getBinding(cgi, env) return binding end``
I had no idea what that was doing, so I looked it up. Apparently the built-in “binding” function returns a Binding object that describes the current execution context, including local variables and function/method arguments. Ok, that seems really powerful and cool. So I look down to the sample dispatch script’s eval statement, and I see:
``eval File.open(script).read, getBinding(cgi, cgi.env_table)``
Ok, so it appears it tries to eval the script while providing an execution context that contains just ‘cgi’ and one of its member vars. I only sorta understand this. So I ditched the “cgi = CGI.new” line in my app’s script. But I got a NameError when just trying to use ‘cgi’. Huh? What’s going on? So I get rid of the getBinding() call entirely, and just let it use the current execution context, and suddenly everything works right. Weird.
Well, sorta. Now, remember, I want to preserve compatibility with running as a normal CGI. So the normal CGI needs to create its own ‘cgi’ object, but the FastCGI one should just use the one from the dispatch script. So I came up with this:
``begin
if !cgi.nil?
mycgi = cgi
end
rescue NameError
require 'cgi'
mycgi = CGI.new
end``
Ok, that seemed to work ok. After that block, ‘mycgi’ should be usable as a CGI/FCGI::CGI object regardless of which mode it’s running under.
So I play around a bit more, and suddenly notice that my POST requests have stopped working. I dig into it a bit, and realise that my POST requests are actually just fine. What’s happening is that, somehow, the FCGI::CGI object completely ignores $QUERY_STRING on a POST request, while ruby’s normal CGI object will take care of it and merge it with the POST data variables. You see, to make my URLs pretty, I have normal URLs rewritten such that the script sees “page=whatever” in the query string. So when I did a POST, the page= would get lost, and so the POST would end up fetching the root web page rather than the one that should be receiving the form variables. I’m not sure if this is “normal” behavior, or if the version of the fcgi ruby module on DreamHost has a bug. Regardless, we need a workaround. So I go back to my last code snippet, and hack something together:
``begin
if !cgi.nil?
if cgi.env_table['REQUEST_METHOD'] == 'POST'
CGI.parse(cgi.env_table['QUERY_STRING']).each do |k,v|
cgi.params[k] = v
end
end
mycgi = cgi
end
rescue NameError
require 'cgi'
mycgi = CGI.new
end``
Ick. But at least it works.
So far, I’m liking ruby quite a lot. It’s a beautiful language, and seems well-suited for this kind of work, especially since I want to get something that works up and running relatively quickly.
We’ll see, however, how many more gotchas I run into.
Ruby for Web Development
I recently started a new web dev project, and decided to use it to better learn Ruby. However, I don't want to use Rails. I'd like to keep it simple. I also prefer to know a lot about the inner workings of a particular technology before I go and use a large framework that hides a bunch of details from me.
However, I want to use ActiveRecord.
So, ActiveRecord. I install it on my laptop with "emerge ruby-activerecord", and there I go. One "require 'activerecord'" in my script later, and, awesome, it starts working.
Then I start working on my web host (DreamHost, if you're wondering). It can't find ActiveRecord. But it's obviously installed, because I know DH supports Rails out of the box, and I don't think you can have an install of Rails without ActiveRecord. So I poke, and then realise it might be installed as a Ruby "gem." Ok, so I put a "require 'rubygems'" above my activerecord require. Nice, now it works. Then I think, well, what if I put this somewhere that doesn't require rubygems? Not hard to work around automatically:
``begin require 'activerecord' rescue LoadError require 'rubygems' require 'activerecord' end``
Nice, ok, that works. It's probably a foolish micro-optimisation, but whatever.
Then I notice... ugh, this is super slow. Even on the web host, it can take a good two seconds for the "require 'activerecord'" statement to execute. Yeah, I know, ruby is kinda slow. But 2 extra seconds each time someone hits basically any page of the website? Ugh.
So.... FastCGI. I know DH supports it, so I head over to the control panel and enable it for the domain I'm working on, and start googling around to figure out how to use FastCGI in a ruby script.
Unfortunately, there aren't too many resources on this. Fortunately I found a couple sample dispatch scripts, one of which I ended up basing mine off of.
But then there was a problem. Inside my app, I use ruby's CGI class to access CGI form variables and other stuff. Since the FastCGI stuff overrides and partially replaces ruby's internal CGI class, there's a problem. Doing "cgi = CGI.new" inside a ruby script that's being served through FastCGI throws a weird exception. But I wanted to try to retain compatibility for non-FastCGI mode. And I couldn't figure out how to get the 'cgi' variable from the ruby dispatch script into my app's script, since I was using 'eval' to run my script. The dispatch script I saw used some weird Binding voodoo. Up at the top level we have:
``def getBinding(cgi, env) return binding end``
I had no idea what that was doing, so I looked it up. Apparently the built-in "binding" function returns a Binding object that describes the current execution context, including local variables and function/method arguments. Ok, that seems really powerful and cool. So I look down to the sample dispatch script's eval statement, and I see:
``eval File.open(script).read, getBinding(cgi, cgi.env_table)``
Ok, so it appears it tries to eval the script while providing an execution context that contains just 'cgi' and one of its member vars. I only sorta understand this. So I ditched the "cgi = CGI.new" line in my app's script. But I got a NameError when just trying to use 'cgi'. Huh? What's going on? So I get rid of the getBinding() call entirely, and just let it use the current execution context, and suddenly everything works right. Weird.
Well, sorta. Now, remember, I want to preserve compatibility with running as a normal CGI. So the normal CGI needs to create its own 'cgi' object, but the FastCGI one should just use the one from the dispatch script. So I came up with this:
``begin
if !cgi.nil?
mycgi = cgi
end
rescue NameError
require 'cgi'
mycgi = CGI.new
end``
Ok, that seemed to work ok. After that block, 'mycgi' should be usable as a CGI/FCGI::CGI object regardless of which mode it's running under.
So I play around a bit more, and suddenly notice that my POST requests have stopped working. I dig into it a bit, and realise that my POST requests are actually just fine. What's happening is that, somehow, the FCGI::CGI object completely ignores $QUERY_STRING on a POST request, while ruby's normal CGI object will take care of it and merge it with the POST data variables. You see, to make my URLs pretty, I have normal URLs rewritten such that the script sees "page=whatever" in the query string. So when I did a POST, the page= would get lost, and so the POST would end up fetching the root web page rather than the one that should be receiving the form variables. I'm not sure if this is "normal" behavior, or if the version of the fcgi ruby module on DreamHost has a bug. Regardless, we need a workaround. So I go back to my last code snippet, and hack something together:
``begin
if !cgi.nil?
if cgi.env_table['REQUEST_METHOD'] == 'POST'
CGI.parse(cgi.env_table['QUERY_STRING']).each do |k,v|
cgi.params[k] = v
end
end
mycgi = cgi
end
rescue NameError
require 'cgi'
mycgi = CGI.new
end``
Ick. But at least it works.
So far, I'm liking ruby quite a lot. It's a beautiful language, and seems well-suited for this kind of work, especially since I want to get something that works up and running relatively quickly.
We'll see, however, how many more gotchas I run into.
Ruby for Web Development
I recently started a new web dev project, and decided to use it to better learn Ruby. However, I don’t want to use Rails. I’d like to keep it simple. I also prefer to know a lot about the inner workings of a particular technology before I go and use a large framework that hides a bunch of details from me.
However, I want to use ActiveRecord.
So, ActiveRecord. I install it on my laptop with “emerge ruby-activerecord”, and there I go. One “require ‘activerecord’” in my script later, and, awesome, it starts working.
Then I start working on my web host (DreamHost, if you’re wondering). It can’t find ActiveRecord. But it’s obviously installed, because I know DH supports Rails out of the box, and I don’t think you can have an install of Rails without ActiveRecord. So I poke, and then realise it might be installed as a Ruby “gem.” Ok, so I put a “require ‘rubygems’” above my activerecord require. Nice, now it works. Then I think, well, what if I put this somewhere that doesn’t require rubygems? Not hard to work around automatically:
begin
require 'activerecord'
rescue LoadError
require 'rubygems'
require 'activerecord'
endNice, ok, that works. It’s probably a foolish micro-optimisation, but whatever.
Then I notice… ugh, this is super slow. Even on the web host, it can take a good two seconds for the “require ‘activerecord’” statement to execute. Yeah, I know, ruby is kinda slow. But 2 extra seconds each time someone hits basically any page of the website? Ugh.
So…. FastCGI. I know DH supports it, so I head over to the control panel and enable it for the domain I’m working on, and start googling around to figure out how to use FastCGI in a ruby script.
Unfortunately, there aren’t too many resources on this. Fortunately I found a couple sample dispatch scripts, one of which I ended up basing mine off of.
But then there was a problem. Inside my app, I use ruby’s CGI class to access CGI form variables and other stuff. Since the FastCGI stuff overrides and partially replaces ruby’s internal CGI class, there’s a problem. Doing “cgi = CGI.new” inside a ruby script that’s being served through FastCGI throws a weird exception. But I wanted to try to retain compatibility for non-FastCGI mode. And I couldn’t figure out how to get the ‘cgi’ variable from the ruby dispatch script into my app’s script, since I was using ‘eval’ to run my script. The dispatch script I saw used some weird Binding voodoo. Up at the top level we have:
def getBinding(cgi, env)
return binding
endI had no idea what that was doing, so I looked it up. Apparently the built-in “binding” function returns a Binding object that describes the current execution context, including local variables and function/method arguments. Ok, that seems really powerful and cool. So I look down to the sample dispatch script’s eval statement, and I see:
eval File.open(script).read, getBinding(cgi, cgi.env_table)Ok, so it appears it tries to eval the script while providing an execution context that contains just ‘cgi’ and one of its member vars. I only sorta understand this. So I ditched the “cgi = CGI.new” line in my app’s script. But I got a NameError when just trying to use ‘cgi’. Huh? What’s going on? So I get rid of the getBinding() call entirely, and just let it use the current execution context, and suddenly everything works right. Weird.
Well, sorta. Now, remember, I want to preserve compatibility with running as a normal CGI. So the normal CGI needs to create its own ‘cgi’ object, but the FastCGI one should just use the one from the dispatch script. So I came up with this:
begin
if !cgi.nil?
mycgi = cgi
end
rescue NameError
require 'cgi'
mycgi = CGI.new
endOk, that seemed to work ok. After that block, ‘mycgi’ should be usable as a CGI/FCGI::CGI object regardless of which mode it’s running under.
So I play around a bit more, and suddenly notice that my POST requests have stopped working. I dig into it a bit, and realise that my POST requests are actually just fine. What’s happening is that, somehow, the FCGI::CGI object completely ignores $QUERY_STRING on a POST request, while ruby’s normal CGI object will take care of it and merge it with the POST data variables. You see, to make my URLs pretty, I have normal URLs rewritten such that the script sees “page=whatever” in the query string. So when I did a POST, the page= would get lost, and so the POST would end up fetching the root web page rather than the one that should be receiving the form variables. I’m not sure if this is “normal” behavior, or if the version of the fcgi ruby module on DreamHost has a bug. Regardless, we need a workaround. So I go back to my last code snippet, and hack something together:
begin
if !cgi.nil?
if cgi.env_table['REQUEST_METHOD'] == 'POST'
CGI.parse(cgi.env_table['QUERY_STRING']).each do |k,v|
cgi.params[k] = v
end
end
mycgi = cgi
end
rescue NameError
require 'cgi'
mycgi = CGI.new
endIck. But at least it works.
So far, I’m liking ruby quite a lot. It’s a beautiful language, and seems well-suited for this kind of work, especially since I want to get something that works up and running relatively quickly.
We’ll see, however, how many more gotchas I run into.