Most programs nowadays are written with some code that the developer writes that are built on top libraries. We string together and manipulate the libraries in interesting ways in order build an application. No one goes and rewrites a graphics engine or a networking library anymore (unless you're doing something special or unique in that arena). So besides debugging, for every new type of application a developer is doing, they are mostly spending time figuring out how to use libraries.
I've found that some libraries were really hard to figure out how to use. Other libraries were a lot easier to adopt. Why? I've found that it was mainly due a culture that was common across the libraries, and often times, this is more apparent in some languages than in others.
When I started using Rails, I was struck by how some things weren't dictated by the syntax of the language, but merely a convention set by the framework developer. And as long as you followed the convention, things just worked. This not only simplified the complexity of rails, because it didn't have to handle all sorts of cases, but it also made it simpler to find your way around the framework once you knew its 'culture'.
"Convention over configuration", is what the creator of Rails calls it, and after thinking about it for a little bit, it makes sense. In Rails you don't have to make the mapping of class names to database table names, or their id attribute. There is already a convention, a culture, for doing that. Culture of a framework allows you to make assumptions that lets you say more with less.
It is the same with any human language. Idioms such as, "famous last words", "a rose by any other name", and "rolling a rock uphill" have a lot of meaning behind the words that are the result of references that most other people know--culture. So with just a couple words, you can convey quite a bit. The catch is that the other person has to understand that culture in order for you to convey much with little.
I think programming language--libraries especially--would benefit from a culture, so that programmers can more easily hop from library to library. Culture also has the advantage of being malleable over time. This way programmers can shift their conventions over time if the old ones aren't working.
Friday, February 16, 2007
Wednesday, February 14, 2007
No such file to load — mkmf | mentalized
I was trying to install the Hpricot gem, but it wasn't working. Ends up that you need to install the ruby1.8-dev package on Ubuntu...that's where the mkmf file resides. I suppose it's cuz Hpricot has things it needs to compile, and all those things are in the dev package. It makes sense now, but kind of annoying when you couldn't have guessed. Good thing for Google.
For the love of programmers, we need better concurrency abstractions
Lately, I've been pretty interested in parallelism. Processors are moving to multi-core architectures. And while I expect that computers will keep following Moore's Law for a while more, I think that there's a lot to be gained for figuring how to best make use of multiple processors, especially for the tasks that can be easily parallelized, such as 3D graphics, image processing, and certain artificial intelligence algorithms. If compilers and subsequently programmers can't take advantage of these multiple processors, we won't see a performance gain in future software.
However, in terms of programming for multiple processors, the general consensus among programmers is, "avoid it if you can get away with it." Multi-threaded programming has generally been considered hard, and with good reason. It's not easy to think about multiple threads running the same code all at the same time at different points, and the side effects that it will have. Synchronization and mutex locks don't make for an easy abstraction that works well as the code base gets larger.
One of the ways that people have been able to get around it is to reduce the amount of sharing of data that different threads and processes needs to have. Sometimes, this is enforced by a no side-effects policy in functional programming, and other times, it's by the use of algorithms that are by nature share nothing. Google's MapReduce seems to be a good example of this.
But there are some programs and algorithms that require the sharing of data, multithreaded programming for shared data is in some sense, unavoidable. Since that's what we're introduced with as THE thing for multi-threaded programming, that's all I knew for a long while. Therefore, I started to wonder, is the current concurrent programming abstraction with synchronization of threads and mutexes the only one that exists?
Apparently not. Like all good ideas in CS, they seemed to have all come from the 1960's. However, there here are futures, software transactional memory, actors, and joins (scroll down to concurrency). The post from Moonbase gives a probable syntax for these abstractions in ruby--they don't exist yet, but he's thinking what it might look like. I'm excited about this, if it makes programming multi-threaded applications easier. That way, programmers can more easily exploit multi-core processors or clusters for speed.
Most of the time, parallelism is exploited for speed, but I think parallelism can be also exploited for robustness. It's no secret to programmers that code is fairly brittle. A single component that isn't working correctly is a runtime bug for the entire system. I think parallelism can also be exploited to alleviate this problem, for a trade off of greater execution speed due to parallelism.
The only reason that I think this might be an interesting area to explore is because of the relatively recent interest in natural complex and emergent systems such as ants foraging for food, sugarscape, and termites gathering wood piles. A more technical example are the decentralized P2P technologies, as well as Bittorrent. This seems to be nothing new, as agent based modeling has been around for a while, in the form of genetic algorithms and ant algorithms. However, none of the current popular programming languages has good abstractions for it to exploit it as parallelism-for-robustness.
This might be a bit hard to design for, since it relies on the building of simple actors that will have an emergent system effect, while only sharing or using local information. It's not always easy to ascertain what the global effect of many interacting simple actors will be analytically, since it might not always be tractable. In the reverse, given a desired emergent global system effect, to find the simple actor that will do that isn't a walk in the park. However, I think once achieved, it will have the robustness that will make it more adaptable than current systems.
If anyone out there knows of such things, post a comment and let me know.
--
Update: I found that there was just a debate on Software Transactional Memory just now, and a nice post on how threading sucks. I know nothing compared to these people.
However, in terms of programming for multiple processors, the general consensus among programmers is, "avoid it if you can get away with it." Multi-threaded programming has generally been considered hard, and with good reason. It's not easy to think about multiple threads running the same code all at the same time at different points, and the side effects that it will have. Synchronization and mutex locks don't make for an easy abstraction that works well as the code base gets larger.
One of the ways that people have been able to get around it is to reduce the amount of sharing of data that different threads and processes needs to have. Sometimes, this is enforced by a no side-effects policy in functional programming, and other times, it's by the use of algorithms that are by nature share nothing. Google's MapReduce seems to be a good example of this.
But there are some programs and algorithms that require the sharing of data, multithreaded programming for shared data is in some sense, unavoidable. Since that's what we're introduced with as THE thing for multi-threaded programming, that's all I knew for a long while. Therefore, I started to wonder, is the current concurrent programming abstraction with synchronization of threads and mutexes the only one that exists?
Apparently not. Like all good ideas in CS, they seemed to have all come from the 1960's. However, there here are futures, software transactional memory, actors, and joins (scroll down to concurrency). The post from Moonbase gives a probable syntax for these abstractions in ruby--they don't exist yet, but he's thinking what it might look like. I'm excited about this, if it makes programming multi-threaded applications easier. That way, programmers can more easily exploit multi-core processors or clusters for speed.
Most of the time, parallelism is exploited for speed, but I think parallelism can be also exploited for robustness. It's no secret to programmers that code is fairly brittle. A single component that isn't working correctly is a runtime bug for the entire system. I think parallelism can also be exploited to alleviate this problem, for a trade off of greater execution speed due to parallelism.
The only reason that I think this might be an interesting area to explore is because of the relatively recent interest in natural complex and emergent systems such as ants foraging for food, sugarscape, and termites gathering wood piles. A more technical example are the decentralized P2P technologies, as well as Bittorrent. This seems to be nothing new, as agent based modeling has been around for a while, in the form of genetic algorithms and ant algorithms. However, none of the current popular programming languages has good abstractions for it to exploit it as parallelism-for-robustness.
This might be a bit hard to design for, since it relies on the building of simple actors that will have an emergent system effect, while only sharing or using local information. It's not always easy to ascertain what the global effect of many interacting simple actors will be analytically, since it might not always be tractable. In the reverse, given a desired emergent global system effect, to find the simple actor that will do that isn't a walk in the park. However, I think once achieved, it will have the robustness that will make it more adaptable than current systems.
If anyone out there knows of such things, post a comment and let me know.
--
Update: I found that there was just a debate on Software Transactional Memory just now, and a nice post on how threading sucks. I know nothing compared to these people.
Sunday, February 11, 2007
A link back to referring page in Rails
So here's the quick problem. You have a long list of records in your rails application, such as posts. You end up using the standard pagination offered in rails, which we all know is slow. Regardless, it's pretty annoying to go down into an individual post, edit it in-place, and then hit the back button, since there's no link back to the previous page.
Well, since it's a pagination, there's not a static page to link a "back to list" link. You could pass in the page, but that's a pain in the butt. It's much easier to do:
This'll put a link back to the same page in the pagination list that you came from. Saves pains. Ends up reading the HTTP spec on headers is a helpful, in addition to some Rails source.
Ends up that "redirect_to :back" also uses the same trick. You can use that in your controller to just redirect back to whatever method called it.
Well, since it's a pagination, there's not a static page to link a "back to list" link. You could pass in the page, but that's a pain in the butt. It's much easier to do:
<%= link_to "Back up to list", request.env["HTTP_REFERER"] %>This'll put a link back to the same page in the pagination list that you came from. Saves pains. Ends up reading the HTTP spec on headers is a helpful, in addition to some Rails source.
Ends up that "redirect_to :back" also uses the same trick. You can use that in your controller to just redirect back to whatever method called it.
Friday, February 09, 2007
Spore Gameplay Video - Google Video
Spore Gameplay Video - Google Video
I was fascinated by the video of the new Will Wright game. He's the same guy that created SimCity and The Sims. This looks like nothing but good ol' sandbox type of fun, but on a 'powers of ten' scale. Often times, when I describe Will Wright's games, most people ask, "What's the point? What's the goal?" The goal or point is whatever you make it to be.
At this point, some people that ask that question seemed stunned, since it seems to them that a lot of effort was put into something that was pointless. I imagine these are the same people that can't handle open-ended problems.
Other people get it immediately. When you get to make your own goals, you have to rely on your own imagination, and you start to own the world. That actually make it much more fun, and something that you don't tire of easily.
I was fascinated by the video of the new Will Wright game. He's the same guy that created SimCity and The Sims. This looks like nothing but good ol' sandbox type of fun, but on a 'powers of ten' scale. Often times, when I describe Will Wright's games, most people ask, "What's the point? What's the goal?" The goal or point is whatever you make it to be.
At this point, some people that ask that question seemed stunned, since it seems to them that a lot of effort was put into something that was pointless. I imagine these are the same people that can't handle open-ended problems.
Other people get it immediately. When you get to make your own goals, you have to rely on your own imagination, and you start to own the world. That actually make it much more fun, and something that you don't tire of easily.
Apple's open letter not quite convincing for music companies
Apple - Thoughts on Music
By now, the world has had some time to chew the fat on this letter, which seems much of a surprise to people. In summary, he says:
All the arguments he gives about DRM-free music makes things easier for Apple not for the Music Monguls. Primarily, Apples doesn't have to use up resources to keep working on DRM. Secondly, if this were to happen, he would make commoditize his complement. A music store's complement is music. And if there were nothing to differentiate the music (one can play music from any store on any device), that's an advantage for Apple. It was the same strategy employed by Netscape: since browsers and servers are complements of each other, we'll give away the browsers (make it a commodity), and sell servers.
One last thing is that the argument at the end doesn't quite hold up. Even if music companies are currently selling over 90 percent of their music DRM-free on CDs, CDs aren't where the future revenues will be coming from, and CD revenue will certainly be declining. So of course music companies will be all hot and bothered by no DRM.
I think DRM-free is the way to go, and music companies will have to accept that the world is changing. In addition, they'll have have to lower their costs in publishing music, as well as finding artists. No more of this, pick a handful, throw it on the wall and see what sticks--and hope that the hit artist will make up for losses with everyone else.
By now, the world has had some time to chew the fat on this letter, which seems much of a surprise to people. In summary, he says:
- Apple can sell music, but only if DRM'd according to license
- DRM requires secrets, and they can be broken by smart people
- Alternative 1: do as we've been doing
- Alternative 2: license FairPlay DRM
- Alternative 3: abolish DRMs
All the arguments he gives about DRM-free music makes things easier for Apple not for the Music Monguls. Primarily, Apples doesn't have to use up resources to keep working on DRM. Secondly, if this were to happen, he would make commoditize his complement. A music store's complement is music. And if there were nothing to differentiate the music (one can play music from any store on any device), that's an advantage for Apple. It was the same strategy employed by Netscape: since browsers and servers are complements of each other, we'll give away the browsers (make it a commodity), and sell servers.
One last thing is that the argument at the end doesn't quite hold up. Even if music companies are currently selling over 90 percent of their music DRM-free on CDs, CDs aren't where the future revenues will be coming from, and CD revenue will certainly be declining. So of course music companies will be all hot and bothered by no DRM.
I think DRM-free is the way to go, and music companies will have to accept that the world is changing. In addition, they'll have have to lower their costs in publishing music, as well as finding artists. No more of this, pick a handful, throw it on the wall and see what sticks--and hope that the hit artist will make up for losses with everyone else.
Friday, February 02, 2007
Two submit buttons with form_remote_tag
At the beginning stages of any new framework or language, you can get away with just posting stupid-programming tricks. This was the case with Ruby and Rails. It was fairly new about a year or two ago, but now, it's pretty much old hat, so I sometimes don't bother posting things that I figure out, since I figured it's old news.
Except, I'm still discovering little things here and there. It's not just with the new fancy RJS templates either. Old favorites like link_to_remote() still have unexplored corners (which we'll get to in a minute). Although this one wasn't that painful, I found it as a footnote in the Rails documentation, that others might have easily missed.
So the answer to the common question I was looking for was "How do I have two submit buttons in the same form?" Usually, we need this when there is a set of user-entered data that has more than one action associated with it. For example, in a blog editing page, you usually want to do two things: "save as draft" or "publish". And when you think about it, the file system on your desktop operates with the same metaphor. You select a bunch of files (the user-data), and right-click to select an action (move, copy, delete, etc).
So with a normal form submission, there is the solution of just naming the submit tags, and since the submit button will submit its value along with the form, you can tell which button was pressed:
But after combing through the documentation, apparently someone on the Rails team needed to do something similar before. If you look at the very end of the documentation for link_to_remote(), you'll find this:
One, you can stylize the submit links to look far better than the ugly submit buttons. Two, you no longer need a dispacher method. Each link_to_remote "submit button" routes to its respective actions, which means you can have way more than two submit buttons, and not have a gigantic "if elsif" statement in a dispatcher method in your controller. Neat.
One downside to this is design related. Because the link_to_remote call can be anywhere on the page, unlike a submit button which has to be inside a form tag, one can put it anywhere. This added flexibility means that you have to be careful to put the newly minted submit button where it is obvious and intuitive that it submits the intended data. But if you're aware of that, have fun with your new and shiny multiple action form.
Update:
If you use :confirm in conjunction with :submit, make sure :confirm is in front of submit, as order seems to make a difference here.
Except, I'm still discovering little things here and there. It's not just with the new fancy RJS templates either. Old favorites like link_to_remote() still have unexplored corners (which we'll get to in a minute). Although this one wasn't that painful, I found it as a footnote in the Rails documentation, that others might have easily missed.
So the answer to the common question I was looking for was "How do I have two submit buttons in the same form?" Usually, we need this when there is a set of user-entered data that has more than one action associated with it. For example, in a blog editing page, you usually want to do two things: "save as draft" or "publish". And when you think about it, the file system on your desktop operates with the same metaphor. You select a bunch of files (the user-data), and right-click to select an action (move, copy, delete, etc).
So with a normal form submission, there is the solution of just naming the submit tags, and since the submit button will submit its value along with the form, you can tell which button was pressed:
<%= start_form_tag :action => :post %>And then, in your controller, you simply check whether params["save"] or params["preview"] exists, and do the appropriate action, or call the appropriate callback.
<%= submit_tag "Save", :name=>"save" %>
<%= submit_tag "Preview", :name=>"preview" %>
<%= end_form_tag %>
def postCake, right? But what if you wanted to do this with a form submitted by XML_HTTP_REQUEST? This hack doesn't work with form_remote_tag, since it serializes the entire form, regardless of which buttons was pressed. I was all ready to buckle down and really learn some javascript, instead of the bits and pieces that I know.
if params["save"]
save
render :action => :save
else
preview
render :action => :preview
end
def save
# do saving stuff
end
def preview
# do preview stuff
end
But after combing through the documentation, apparently someone on the Rails team needed to do something similar before. If you look at the very end of the documentation for link_to_remote(), you'll find this:
:submit: Specifies the DOM element ID that‘s used as the parent of the form elements. By default this is the current form, but it could just as well be the ID of a table row or any other DOM element.It ends up that you can use this to serialize anything containing form elements. But not only that, there are two other bonuses.
One, you can stylize the submit links to look far better than the ugly submit buttons. Two, you no longer need a dispacher method. Each link_to_remote "submit button" routes to its respective actions, which means you can have way more than two submit buttons, and not have a gigantic "if elsif" statement in a dispatcher method in your controller. Neat.
<div id="image_collection">Notice that the parent tag doesn't have to be a form. It can be a div.
<% @images.each do |image| %>
<%= check_box "selected_images", image.id %>
<%= image_tag image.path %>
<% end %>
<%= link_to_remote "Group", :url => { :action => :group }, :submit => :image_collection %>
<%= link_to_remote "Delete", :url => { :action => :delete }, :submit => :image_collection %>
</div>
One downside to this is design related. Because the link_to_remote call can be anywhere on the page, unlike a submit button which has to be inside a form tag, one can put it anywhere. This added flexibility means that you have to be careful to put the newly minted submit button where it is obvious and intuitive that it submits the intended data. But if you're aware of that, have fun with your new and shiny multiple action form.
Update:
If you use :confirm in conjunction with :submit, make sure :confirm is in front of submit, as order seems to make a difference here.
Saturday, January 27, 2007
"Installing" net/https library in Ruby
This isn't written anywhere that I've looked, so it's either obvious, or I just missed the boat. But basically, in order to use the "net/https" library, you don't need to download it. It's included in the build of Ruby 1.8.4+
However, what you do need to install is both openssl, and the ruby-openssl packages for it in ubuntu in order for it to be working. Tip!
However, what you do need to install is both openssl, and the ruby-openssl packages for it in ubuntu in order for it to be working. Tip!
How to install Ruby 1.8.5 from source on Ubuntu
Well, it ends up that installing Ruby 1.8.5 and the associated Gems is a pain on Ubuntu. I'm here to take away that pain, yo.
(which is likely on Ubuntu), you'll divine on google that it needs a "glibc-devel-2.3.3-74.i386" package. But I've done the legwork already, and under ubuntu, it's actually called "libc6-dev"
What I did run into was more pain installing Gems.
Again, go get the source tarball of ruby gems, and put it into /usr/local/src
Now, if all is well, you're golden. But since this is Ubuntu, it's likely that you're missing zlib. So, some people seemed to have been able to get it to work from using the "zlib-ruby" package. What I had to do was install zlib from source.
Get the Ruby Zlib source and again put it into /usr/local/src/
If that didn't work, most likely, you got a bunch of stuff that said:
That means that you need the headers for zlib. So install the package "zlib1g-dev"
Then try it again. That should work, and once you get zlib installed, you can get gems up and running.
Installing Ruby 1.8.5 from source
First, get the source tarball of 1.8.5 from the ruby lang web page, and put it in /usr/local/srcsudo tar -xvzf ruby-1.8.5-p12If all goes well, you're in business. But if it complains about "cannot open crt1.o"
cd ruby-1.8.5-p12
sudo ./configure
sudo make
sudo make install
(which is likely on Ubuntu), you'll divine on google that it needs a "glibc-devel-2.3.3-74.i386" package. But I've done the legwork already, and under ubuntu, it's actually called "libc6-dev"
sudo apt-get install libc6-devSo try making Ruby again. It should be ok. If not, well, it's not documented here, since I didn't run into that problem.
What I did run into was more pain installing Gems.
Installing Ruby Gems from source
Again, go get the source tarball of ruby gems, and put it into /usr/local/src
sudo tar -xvzf rubygems-0.9.1
cd rubygems-0.9.1
sudo ruby setup.rb
Now, if all is well, you're golden. But since this is Ubuntu, it's likely that you're missing zlib. So, some people seemed to have been able to get it to work from using the "zlib-ruby" package. What I had to do was install zlib from source.
Installing Ruby Zlib from source
Get the Ruby Zlib source and again put it into /usr/local/src/
sudo tar -xvzf ruby-zlib-0.6.0
cd ruby-zlib-0.6.0
sudo ruby extconf.rb
If that didn't work, most likely, you got a bunch of stuff that said:
checking for deflateReset() in -lz... no
checking for deflateReset() in -llibz... no
checking for deflateReset() in -lzlib... no
That means that you need the headers for zlib. So install the package "zlib1g-dev"
sudo apt-get install zlib1g-dev
Then try it again. That should work, and once you get zlib installed, you can get gems up and running.
Friday, January 05, 2007
How to grep for the negation or not or something on the command line.
I've always wondered how to grep for the negation of something. When SubClipse messes up, I end up spending time in the terminal. I hate it. It should at least be able to recover from itself.
Anyway, I wanted to find the difference between two directories. So for diff, you simply use:
And this will give you a slew of which files are different or same. But it'll give you all this stuff about .svn directories that you don't care about. So how do you grep for the NOT of something? I don't know, the regex for it (if someone cares to divulge, I'd appreciate it), but grep has a switch that does this for you:
And voila, it only gives you the differences other than paths with 'svn' in them.
Anyway, I wanted to find the difference between two directories. So for diff, you simply use:
diff -rq directory1/ directory2/
And this will give you a slew of which files are different or same. But it'll give you all this stuff about .svn directories that you don't care about. So how do you grep for the NOT of something? I don't know, the regex for it (if someone cares to divulge, I'd appreciate it), but grep has a switch that does this for you:
diff -rq directory1/ directory2/ | grep -v 'svn'
And voila, it only gives you the differences other than paths with 'svn' in them.
Wednesday, January 03, 2007
Testing link_to_remote AJAX calls in Rails
I wanted to be able to test ajax methods in a rails controller, but I wasn't able to find good tutorials on this topic...so either no one uses it, or everyone else just got it right away.
let's say I have the following made up method:
So to test out this, all you have to do is:
Also note that you can test for returns of partials with assert_template. It just has to be a string with the preceding "_" as per partials convention.
As for testing RJS templates, you'd want to look into the assert_rjs plugin.
let's say I have the following made up method:
That gets called in the view by:
def edit_importance
@friend = Friend.find(params[:id])
@friend.update_attributes(:importance => params[:importance]) unless @friend.nil?
render :partial => "shared/stars"
end
How does this get tested? Well, I figured out there was an xml_http_request call in ActiveController::Testprocess, but I had no idea what to put in the parameters.<%= link_to_remote(image_html, :update => "friend_stars_#{@friend.id}",
:url => { :controller => "friends", :action => :edit_importance,
:id => @friend.id, :importance => nth }) %>
xml_http_request(request_method, action, parameters = nil, session = nil, flash = nil)It ends up that reading RFC 2616 (HTTP) helped, and request_method is just :get, :put, :post, :delete, etc.
So to test out this, all you have to do is:
def test_edit_importanceRemember to reload the old object, since it will still have the old values. You can also use jon_lee = assign(:friend) after the xml_http_request, if you don't want to reload.
jon_lee = friends(:jon_lee) # from a fixture
old_importance = jon_lee.importance
xml_http_request :put, :edit_importance, { :id => jon_lee.id, :importance => 3 }
assert_template "_stars"
jon_lee.reload
assert_equal 3, jon_lee.importance
assert_not_equal old_importance, jon_lee.importance
end
Also note that you can test for returns of partials with assert_template. It just has to be a string with the preceding "_" as per partials convention.
As for testing RJS templates, you'd want to look into the assert_rjs plugin.
Incorrect use of exception handling
Exception handling was never something that I looked much into. I've caught exceptions from libraries before, but when it came to coming up with exceptions to throw, I never gave it too much thought. So I looked it up in detail, and to my horror, I had been using it wrong.
Documenting my stupidity, hopefully, I'll prevent others from doing the same basic mistake.
In a rails controller, there is always a simple case of creating a model, but sometimes, there's value checking.
I thought, "Hey, why not move that error handling code to the end, so it reads better?"
That way, the error handling code doesn't really get in the way of the 'good condition' code. I personally think it's easier to read, though apparently, this is a bad idea apparently, mostly due to overhead costs in running through an exception, even if there were no exceptions thrown, and that I'm essentially using it as a goto statement. And as everyone knows, gotos taste like ass.
Exceptions are to be used when the method or object that the error occurred doesn't know what to do with the error at that time. Therefore, it will throw an exception, and hope that some other part of the code elsewhere up the stack will know what to do with it. And so hence the adage: "throw early, catch late".
So I'm a reformed exception handling abuser. I guess when you have a new hammer, the world looks like a nail, until someone sets you right.
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
http://today.java.net/pub/a/today/2003/12/04/exceptions.html
Documenting my stupidity, hopefully, I'll prevent others from doing the same basic mistake.
In a rails controller, there is always a simple case of creating a model, but sometimes, there's value checking.
def create
if params[email] == "bob@uiuc.edu"
flash[:error] = "Bobs at UIUC not allowed"
redirect_to :action => :list
return
end
@friend = Friend.create(params)
unless @friend.save
render :action => :edit
else
flash[:notice] = 'Friend was successfully updated'
redirect_to :action => 'list'
end
end
I thought, "Hey, why not move that error handling code to the end, so it reads better?"
class NoBobsError < Exception; end
def create
raise NoBobsError.new if params[email] == "bob@uiuc.edu"
@friend = Friend.create(params)
raise ActiveRecord::RecordNotSaved.new unless @friend.save
flash[:notice] = 'Friend was successfully updated'
redirect_to :action => 'list'
rescue ActiveRecord::RecordNotSaved
render :action => :edit
rescue Exception
flash[:error] = "Bobs at UIUC not allowed"
redirect_to :action => :list
end
That way, the error handling code doesn't really get in the way of the 'good condition' code. I personally think it's easier to read, though apparently, this is a bad idea apparently, mostly due to overhead costs in running through an exception, even if there were no exceptions thrown, and that I'm essentially using it as a goto statement. And as everyone knows, gotos taste like ass.
Exceptions are to be used when the method or object that the error occurred doesn't know what to do with the error at that time. Therefore, it will throw an exception, and hope that some other part of the code elsewhere up the stack will know what to do with it. And so hence the adage: "throw early, catch late".
So I'm a reformed exception handling abuser. I guess when you have a new hammer, the world looks like a nail, until someone sets you right.
http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html
http://today.java.net/pub/a/today/2003/12/04/exceptions.html
Thursday, December 07, 2006
Adaptive polling as an alternative to HTTP streaming
I've been fairly interested in how the HTTP protocol works lately. For a long time, I didn't think much of it. It sat on top of the TCP/IP layers, and there wasn't much I need to do with it. It did what it was suppose to do: let clients fetch pages from servers upon request.
But then I started reading about REST (about a year after the hubbub), and in general about why stateless connections are desirable (it's scaleable). This lead me down equally saturated road of AJAX and eventually some joke about Comet. What was coined as "Comet" was really a play-on-words for another cleaning product applied to another old web technology--namely persistent HTTP connections.
Traditionally, HTTP doesn't allow servers to push data to clients. With the way the web is architectured, most clients are behind firewalls and routers, so the server has no way of knowing which machine to push it to, unless it was talked to first. In other words, only clients can initiate data requests. This isn't enough sometimes, as servers might need to push data to clients, such as live stock ticker feeds in your web browser without page reloading.
The trick to persistent HTTP connections was to get clients to initiate the XHR connection to the server first, and for the server to not immediately reply to the request. The server will hold off on replying (leaving an open connection from the client) until there's actually a message to be sent back to the client (i.e. when there's a new stock update). And that way, it'll look like a server-push. And then the client initiates another connection all over again after a certain wait.
This is the way that LivePage and JotSpot Live implements their responsive apps. However, the concern for most people is that it doesn't scale--at least not when they tried it circa 1998. A server having thousands of open connections to clients will probably buckle, although Twister might have already solved this problem, but I haven't looked into it much yet.
Another concern of mine is that the Ajaxian pattern of HTTP streaming can also require the client and the server to hold state. This is because a server does not know what version of the last set of updates it has received. Therefore, the client sends the server what version it has had (state), and the server will only reply if it has a newer version. This seems to violate the REST architecture. While I only have the original 2000 thesis to say this is not scalable, it seems to make servers a bit more complex.
So why not use polling? Usually, it's because too much polling is wasted bandwidth. And not enough polling, you have stale data. So depending on the nature of the data that you're trying to stream, polling may or may not be a solution. However, it is stateless, and it should scale better, as long as polling isn't overdone.
That lead me to wonder if there was adaptive polling. Why not have clients try and predict their polling frequency based on past observations of their past polling to optimize their polling success. Polling success is defined as every time they poll, they get 1) new data and 2) freshest data.
It ends up that it's a very similar problem in two other fields (and I'm sure many others): web caching and sensor networks. In web caching, you want to cache web pages, so that you can show clients results faster if the page hasn't changed. How do you know the page has changed, and when to throw away the cached copy and obtain a fresh one? In sensor networks, each connection is expensive in terms of energy consumption. How do you know when a node has fresh data, and how often should you poll to obtain polling success? In this case, a master node is analogous to the client and a slave node is analogous to the server.
There's an additional issue to consider. One wouldn't want all the clients hammer the server all at once for a poll. That would make it seem like a flash mob to the server at periodic intervals. It would be best if the clients can spread out their requests, so that the traffic to the server is more constant. That way, the server wouldn't be overloaded. How do you coordinate the polling times of thousands of clients? Wouldn't that create more traffic on the network for the clients to ask each other? I'm guessing no, because the delay in response time from the server would indicate how busy it was at this moment. Using that as a type of "pheromone" from other clients (indicator left by other clients), a client should be able to adjust its offset time for its next polling request.
But then I started reading about REST (about a year after the hubbub), and in general about why stateless connections are desirable (it's scaleable). This lead me down equally saturated road of AJAX and eventually some joke about Comet. What was coined as "Comet" was really a play-on-words for another cleaning product applied to another old web technology--namely persistent HTTP connections.
Traditionally, HTTP doesn't allow servers to push data to clients. With the way the web is architectured, most clients are behind firewalls and routers, so the server has no way of knowing which machine to push it to, unless it was talked to first. In other words, only clients can initiate data requests. This isn't enough sometimes, as servers might need to push data to clients, such as live stock ticker feeds in your web browser without page reloading.
The trick to persistent HTTP connections was to get clients to initiate the XHR connection to the server first, and for the server to not immediately reply to the request. The server will hold off on replying (leaving an open connection from the client) until there's actually a message to be sent back to the client (i.e. when there's a new stock update). And that way, it'll look like a server-push. And then the client initiates another connection all over again after a certain wait.
This is the way that LivePage and JotSpot Live implements their responsive apps. However, the concern for most people is that it doesn't scale--at least not when they tried it circa 1998. A server having thousands of open connections to clients will probably buckle, although Twister might have already solved this problem, but I haven't looked into it much yet.
Another concern of mine is that the Ajaxian pattern of HTTP streaming can also require the client and the server to hold state. This is because a server does not know what version of the last set of updates it has received. Therefore, the client sends the server what version it has had (state), and the server will only reply if it has a newer version. This seems to violate the REST architecture. While I only have the original 2000 thesis to say this is not scalable, it seems to make servers a bit more complex.
So why not use polling? Usually, it's because too much polling is wasted bandwidth. And not enough polling, you have stale data. So depending on the nature of the data that you're trying to stream, polling may or may not be a solution. However, it is stateless, and it should scale better, as long as polling isn't overdone.
That lead me to wonder if there was adaptive polling. Why not have clients try and predict their polling frequency based on past observations of their past polling to optimize their polling success. Polling success is defined as every time they poll, they get 1) new data and 2) freshest data.
It ends up that it's a very similar problem in two other fields (and I'm sure many others): web caching and sensor networks. In web caching, you want to cache web pages, so that you can show clients results faster if the page hasn't changed. How do you know the page has changed, and when to throw away the cached copy and obtain a fresh one? In sensor networks, each connection is expensive in terms of energy consumption. How do you know when a node has fresh data, and how often should you poll to obtain polling success? In this case, a master node is analogous to the client and a slave node is analogous to the server.
There's an additional issue to consider. One wouldn't want all the clients hammer the server all at once for a poll. That would make it seem like a flash mob to the server at periodic intervals. It would be best if the clients can spread out their requests, so that the traffic to the server is more constant. That way, the server wouldn't be overloaded. How do you coordinate the polling times of thousands of clients? Wouldn't that create more traffic on the network for the clients to ask each other? I'm guessing no, because the delay in response time from the server would indicate how busy it was at this moment. Using that as a type of "pheromone" from other clients (indicator left by other clients), a client should be able to adjust its offset time for its next polling request.
Sunday, December 03, 2006
Splatting in case statements
RedHanded � Wonder of the When-Be-Splat
I always feel like I'm playing catch up to Rubyists.
That's pretty damn cool. The thing about new languages is that when you're learning to write with it, you'll write it in the style of the old language that you're use to. C programmers will write C++ as if it were C. Java programmers will write Python as if it were Java. Therefore, you might think that there isn't much to be gained from the new language other than some syntactic sugar sprinkled here and there.
As least for me, being open to other constructs like blocks, closures written more like functional programming has lead to more succinct and readable code.
I would have done this with a for loop before, and that's probably less readable. But I have to admit, succinct code only has meaning if you know the vocab.
I always feel like I'm playing catch up to Rubyists.
BOARD_MEMBERS = ['Jan', 'Julie', 'Archie', 'Stewick']
HISTORIANS = ['Braith', 'Dewey', 'Eduardo']
case name
when *BOARD_MEMBERS
"You're on the board! A congratulations is in order."
when *HISTORIANS
"You are busy chronicling every deft play."
endThat's pretty damn cool. The thing about new languages is that when you're learning to write with it, you'll write it in the style of the old language that you're use to. C programmers will write C++ as if it were C. Java programmers will write Python as if it were Java. Therefore, you might think that there isn't much to be gained from the new language other than some syntactic sugar sprinkled here and there.
As least for me, being open to other constructs like blocks, closures written more like functional programming has lead to more succinct and readable code.
a = [1, 2, 3]
Hash[*a.collect { |v|
[v, v*2]
}.flatten]I would have done this with a for loop before, and that's probably less readable. But I have to admit, succinct code only has meaning if you know the vocab.
Thursday, November 16, 2006
FireBug for all other things
When working with RJS templates, it can be a pain, especially if you roll your own javascript in there. There's almost no way to debug it, so you have to be very very careful, or use your brain-the-compiler.
But aside from that, try out Firebug. It's a pretty need in-browser javascript debugger for Firefox.
But aside from that, try out Firebug. It's a pretty need in-browser javascript debugger for Firefox.
Sunday, November 12, 2006
Symbol conversation in MMORPGs
Blue Rabbit�s Climate Chaos - Adventure Games - GamersHood - Online Games Paradise
This was something that was shown to me by Alison. I just tried it out, just to see what was fun about it. Didn't play much, but I was struck by the fact that this game decided to employ pictograms instead of words for conversation.
Now, I don't know why Blue Rabbit employed this mode of conversation. Perhaps it's because the target audience is young children.
However! I think this would be key to building a more dynamic MMORPGs. I haven't played World of Warcraft, so I don't know if quests are static. But I remember in Everquest, the quests were the same, time after time. Oh sure, there might be grace periods where it wouldn't be there, but for the most part, the same person would have his daughter kidnapped time after time.
Instead of having static quests, I think it would be better to have dynamic quests. It gives a better sense of realism to the world that the gamer is playing in, if the NPCs(non player characters) had different needs at different times.
In the Sims, each NPC is an agent with goals and needs. And it basically interacts with its environment to fulfill those goals and needs as time progresses. But never do any of the characters ask another Sim to fulfill those needs for him. Sure, they have conversations with each other to fulfill the direct need for being social. But they never ask the messy roommate to clean up his mess. They always get irritated and clean it up themselves, or rely on the player to make someone else clean it up.
With a simplified vocabulary of pictogram language, an NPC would be able to express what he desires. And that would be up to the player in the quest to fulfill it. These goals, like in the Sims would change as the environment and needs change.
This was something that was shown to me by Alison. I just tried it out, just to see what was fun about it. Didn't play much, but I was struck by the fact that this game decided to employ pictograms instead of words for conversation. Now, I don't know why Blue Rabbit employed this mode of conversation. Perhaps it's because the target audience is young children.
However! I think this would be key to building a more dynamic MMORPGs. I haven't played World of Warcraft, so I don't know if quests are static. But I remember in Everquest, the quests were the same, time after time. Oh sure, there might be grace periods where it wouldn't be there, but for the most part, the same person would have his daughter kidnapped time after time.
Instead of having static quests, I think it would be better to have dynamic quests. It gives a better sense of realism to the world that the gamer is playing in, if the NPCs(non player characters) had different needs at different times.
In the Sims, each NPC is an agent with goals and needs. And it basically interacts with its environment to fulfill those goals and needs as time progresses. But never do any of the characters ask another Sim to fulfill those needs for him. Sure, they have conversations with each other to fulfill the direct need for being social. But they never ask the messy roommate to clean up his mess. They always get irritated and clean it up themselves, or rely on the player to make someone else clean it up.
With a simplified vocabulary of pictogram language, an NPC would be able to express what he desires. And that would be up to the player in the quest to fulfill it. These goals, like in the Sims would change as the environment and needs change.
file_column is easy to use
HowToUseFileColumn in Ruby on Rails
File_column really is a cinch to use. But not without knowing that you needed:
in the migration. And here I was reading through file_column code. Things are always clearer in hindsight. But it did teach me a few tricks here and there, about how to add dynamic methods to objects.
File_column really is a cinch to use. But not without knowing that you needed:
add_column :entry, :image, :stringin the migration. And here I was reading through file_column code. Things are always clearer in hindsight. But it did teach me a few tricks here and there, about how to add dynamic methods to objects.
Thursday, November 09, 2006
Annologger update: Commenting is available!
It's got no pictures of stars, but it's simple. Commenting is up for annologger!Human verification CAPTCHAs will be done tomorrow, so that you don't get comment spam. In the meantime, get your friends, your readers, your fans, to comment, comment, comment away.
Friday, November 03, 2006
Annologger Update: By popular demand, Annolog Badges available
I'm happy to announce that you can now get annologger badges for your blog or website! What's a badge you say? It's basically a code snippet generated for you that you can cut and paste into any webpage, blog or otherwise. That way, you can floss your events on your blog now. :)You can get your own annolog at http://www.annologger.com. Under the goodies section, you can create your own annolog badge.
It took longer than I had anticipated, due to not ever working with rjs templates before. I'll write a tutorial up later. On to comments for your annolog!
Wilhem has built Annologger, a tool that lets people worship your dentist appointments.
Late to the RESTful party
Apparently, I'm the last fool to really read about it. I only first heard about REST maybe 2 months ago by a long post by one of the rails guys.
Lately (as in the last 6 months), there's been a resurgence in figuring out the HTTP protocol. It's suppose to be RESTful. Mainly, the idea that network architecture are seen as a collection of resources identified uniquely by a URI. And that the whole network application is simply the user in a large state machine, where traversing the different resources equate to state transitions. This has implications of server and client design to be simpler.
Each HTTP request also has a method associated with it. The methods in HTTP most commonly used are GET and POST. In the early days of the web (ie when we were in college), I saw that forms submitted by GET or POST, and for a long time, I had no idea what the difference was. GET is intended to "read" but make no state changes in the server, and POST is intented to make state changes. So doing form submissions with GET is not only semantically wrong, but insecure, since it puts form contents in the url.
In addition to GET and POST, there are others, (I never knew). And the bunch of them map well to CRUD(Create, read, update, delete) operations. And using the native HTTP methods, you can take advantage of things already built into HTTP, like caching (for scalibility) without having to build it yourself.
Here's a simple intro , and I think one of the articles that spawned the discussion. This is the original disseration on RESTful architecture, if you want to read it.
Wilhem has built Annologger, a tool that lets people worship your dentist appointments.
Lately (as in the last 6 months), there's been a resurgence in figuring out the HTTP protocol. It's suppose to be RESTful. Mainly, the idea that network architecture are seen as a collection of resources identified uniquely by a URI. And that the whole network application is simply the user in a large state machine, where traversing the different resources equate to state transitions. This has implications of server and client design to be simpler.
Each HTTP request also has a method associated with it. The methods in HTTP most commonly used are GET and POST. In the early days of the web (ie when we were in college), I saw that forms submitted by GET or POST, and for a long time, I had no idea what the difference was. GET is intended to "read" but make no state changes in the server, and POST is intented to make state changes. So doing form submissions with GET is not only semantically wrong, but insecure, since it puts form contents in the url.
In addition to GET and POST, there are others, (I never knew). And the bunch of them map well to CRUD(Create, read, update, delete) operations. And using the native HTTP methods, you can take advantage of things already built into HTTP, like caching (for scalibility) without having to build it yourself.
Here's a simple intro , and I think one of the articles that spawned the discussion. This is the original disseration on RESTful architecture, if you want to read it.
Wilhem has built Annologger, a tool that lets people worship your dentist appointments.
Subscribe to:
Posts (Atom)