Tuesday, April 25, 2006
Python Challenge
I recently had the opportunity to learn Python as part of a very short term consulting job I took on. Having also taken on Ruby recently this was an interesting task and I could spend a whole blog comparing the two (spoiler: I prefer Ruby); but I won't.
What I want to blog about here is way cooler. While I was looking up some python syntax I happened upon the Python Challenge. How cool is this! The python challenge is a game where each level can be solved using a clever or little known bit of Python code. I decided to take the challenge as a way to hone my newfound python skills. This is a great way to learn a language and to learn the nuances of a language. Of course, with my newborn Ruby (and Rails) passion I think we need a Ruby Challenge! Does one already exist? I think the python challenge format could pretty much be used but I would suggest one small change:
Use the challenge as a tutorial. Hear me out.
The ruby challenge starts with the most simple ruby concepts. Perhaps a sidebar or section at the top that always displays the ruby keywords, general syntax rules, etc. Each challenge gets harder. Eventually they reach a level where they are more puzzle than tutorial and at this point you start to learn the elegances of Ruby. Problems are formed to be solved by Ruby's unique features. So you learn Ruby, you learn more Ruby, and then you master Ruby all as part of a game. Furthermore it would be great to keep track of users and how well they are doing in the challenge so you can have a top 10 board or something. Millions of thoughts here. Feedback?
Nearly every language could use an involved, engaging tutorial/game like this. This is worthwhile Edutainment. I would love to work on this as a part time project. If you're interested in helping me out or you know of something like this that already exists. adaDONTSMAMMEPLEASEm.schepis@gmail.com or post a comment with contact info. If you care about privacy you can find a link to my GPG public key at the bottom of this page.
What I want to blog about here is way cooler. While I was looking up some python syntax I happened upon the Python Challenge. How cool is this! The python challenge is a game where each level can be solved using a clever or little known bit of Python code. I decided to take the challenge as a way to hone my newfound python skills. This is a great way to learn a language and to learn the nuances of a language. Of course, with my newborn Ruby (and Rails) passion I think we need a Ruby Challenge! Does one already exist? I think the python challenge format could pretty much be used but I would suggest one small change:
Use the challenge as a tutorial. Hear me out.
The ruby challenge starts with the most simple ruby concepts. Perhaps a sidebar or section at the top that always displays the ruby keywords, general syntax rules, etc. Each challenge gets harder. Eventually they reach a level where they are more puzzle than tutorial and at this point you start to learn the elegances of Ruby. Problems are formed to be solved by Ruby's unique features. So you learn Ruby, you learn more Ruby, and then you master Ruby all as part of a game. Furthermore it would be great to keep track of users and how well they are doing in the challenge so you can have a top 10 board or something. Millions of thoughts here. Feedback?
Nearly every language could use an involved, engaging tutorial/game like this. This is worthwhile Edutainment. I would love to work on this as a part time project. If you're interested in helping me out or you know of something like this that already exists. adaDONTSMAMMEPLEASEm.schepis@gmail.com or post a comment with contact info. If you care about privacy you can find a link to my GPG public key at the bottom of this page.
Friday, April 07, 2006
Rails won't become mainstream?
I was surfing digg this morning and came across this blog entry by entitled "Why Ruby on Rails won't become mainstream." In it the author (Cedric) points out alot of the _potential_ barriers to Ruby (and Rails) becoming mainstream. Hold Up!! Before you let your indignation get the best and take off to rip him a new one please take note of you take this one little peice of information. He's a Rails lover! Cedric make's alot of good/valid points but I don't agree with his conclusion and as a VERY recent Ruby on Rails convert perhaps I can contribute a different perspective. My comments below to his list of reasons
1) Cedric says that one barrier is Ruby itself and getting it into the toolbox of the PHP/ASP crowd. Ruby _DOES_ have some advanced idioms. I'm still learning Ruby, but I can tell you from experience that I was able to take the Agile Web Development with Rails book and read it, go through the examples and when I was done doing so I was comfortable using Ruby. I hit the API and language references alot and I'm planning on getting the Pickaxe book but once you start to "get" Ruby (which for me was almost immediately) it is straightforward to use
2) Cedric thinks that Rails itself will hinder mainstream adoption because it is complex, does alot for you automagically, and is incredibly clever. He isn't sure that the Web Development community (which, let's remind ourselves, isn't made up entirely of quality, trained software engineers) will ever be ready to embrace the cleverness and magic. I'm not sure how I feel about this one yet except to say that I think Rails gives developers a better chance of building a product well within a reasonable schedule. There are fewer pitfalls than starting from scratch w/ PHP or using other frameworks and languages. Perhaps if we lead by example, they will follow.
3) The author claims that Rails Still has no credible IDE. This is the one point where Cedric is just plain wrong. RadRails is an AWESOME Rails plugin for Eclipse!
4) Next, fanatacism. Cedric thinks that the extreme fanatacism of some in the Rails community will hinder Rails. Now I have to agree here to a certain extent. We need to stop BASHING people who discount Rails and simply prove them wrong. Actions speak louder than words! Build some killing enterprise Rails apps. Don't insult James McGovern, disprove him. The other danger with the ultra-fanatacism that I've pointed out before is that some people look at Rails as a hammer and everything that can possibly show up in a browser window a nail! This is dangerous! Read my "no silver bullets" post to get my opinion on this.
5) The author's next point is that by being so great so soon Rails will stifle innovation in the area of Ruby web frameworks and that because Rails is the only game in town Rails itself will be stifled. This NEVER crossed my mind and I think the reason for that is because I lump ALL web development frameworks into the same bucket regardless of language. I think others tend to do this as well. Although it's important to distinguish which languages and frameworks are good for particular types of problems I believe that if somebody does something REALLY cool in one language/framework it tends to make its way into others. Case in point Grails, Trails, CakePHP, and many more. Rails has single handedly reinvigorated the web development platform and infused it with a fresh perspective! In the future Rails may benefit from the same effect caused by another framework
6) Next Cedric points out that Rails' Enterprise capabilities and scalability unclear. This is a common concern and one that needs to be put to rest. The Rails community needs to nail down the sweetspot of Rails once and for all in a mathematical way. Can a Rails app handle the type of traffic that slashdot and digg see everyday? If we built a peopleSoft type HR app for a company intranet with Rails could it scale when there are thousands of users worldwide constantly coming in and out and the server is seeing hundreds of transactions per second? I have no idea. Let's find out where Rails breaking point is (if there is one... I have no clue.)
7) Cedric's final point is Lack of support from Internet Providers. On this one I'm sort of in the "If you build it, they will come" mentality. Has PHP always enjoyed mainstream Internet Provider support? Maybe in the short term we're going to have to host our own servers or get dedicated servers but there is already a slew of providers with support for rails hosting.
Wow, a long retort! In closing I guess I should thank Cedric for starting this conversation from the perspective of a Rails supporter! The debate that will follow will surely be beneficial for the community.
1) Cedric says that one barrier is Ruby itself and getting it into the toolbox of the PHP/ASP crowd. Ruby _DOES_ have some advanced idioms. I'm still learning Ruby, but I can tell you from experience that I was able to take the Agile Web Development with Rails book and read it, go through the examples and when I was done doing so I was comfortable using Ruby. I hit the API and language references alot and I'm planning on getting the Pickaxe book but once you start to "get" Ruby (which for me was almost immediately) it is straightforward to use
2) Cedric thinks that Rails itself will hinder mainstream adoption because it is complex, does alot for you automagically, and is incredibly clever. He isn't sure that the Web Development community (which, let's remind ourselves, isn't made up entirely of quality, trained software engineers) will ever be ready to embrace the cleverness and magic. I'm not sure how I feel about this one yet except to say that I think Rails gives developers a better chance of building a product well within a reasonable schedule. There are fewer pitfalls than starting from scratch w/ PHP or using other frameworks and languages. Perhaps if we lead by example, they will follow.
3) The author claims that Rails Still has no credible IDE. This is the one point where Cedric is just plain wrong. RadRails is an AWESOME Rails plugin for Eclipse!
4) Next, fanatacism. Cedric thinks that the extreme fanatacism of some in the Rails community will hinder Rails. Now I have to agree here to a certain extent. We need to stop BASHING people who discount Rails and simply prove them wrong. Actions speak louder than words! Build some killing enterprise Rails apps. Don't insult James McGovern, disprove him. The other danger with the ultra-fanatacism that I've pointed out before is that some people look at Rails as a hammer and everything that can possibly show up in a browser window a nail! This is dangerous! Read my "no silver bullets" post to get my opinion on this.
5) The author's next point is that by being so great so soon Rails will stifle innovation in the area of Ruby web frameworks and that because Rails is the only game in town Rails itself will be stifled. This NEVER crossed my mind and I think the reason for that is because I lump ALL web development frameworks into the same bucket regardless of language. I think others tend to do this as well. Although it's important to distinguish which languages and frameworks are good for particular types of problems I believe that if somebody does something REALLY cool in one language/framework it tends to make its way into others. Case in point Grails, Trails, CakePHP, and many more. Rails has single handedly reinvigorated the web development platform and infused it with a fresh perspective! In the future Rails may benefit from the same effect caused by another framework
6) Next Cedric points out that Rails' Enterprise capabilities and scalability unclear. This is a common concern and one that needs to be put to rest. The Rails community needs to nail down the sweetspot of Rails once and for all in a mathematical way. Can a Rails app handle the type of traffic that slashdot and digg see everyday? If we built a peopleSoft type HR app for a company intranet with Rails could it scale when there are thousands of users worldwide constantly coming in and out and the server is seeing hundreds of transactions per second? I have no idea. Let's find out where Rails breaking point is (if there is one... I have no clue.)
7) Cedric's final point is Lack of support from Internet Providers. On this one I'm sort of in the "If you build it, they will come" mentality. Has PHP always enjoyed mainstream Internet Provider support? Maybe in the short term we're going to have to host our own servers or get dedicated servers but there is already a slew of providers with support for rails hosting.
Wow, a long retort! In closing I guess I should thank Cedric for starting this conversation from the perspective of a Rails supporter! The debate that will follow will surely be beneficial for the community.
Wednesday, April 05, 2006
Killer code snippet!
This is straight out of Agile Web Development with Rails:
class Customer <>
has_many :orders
has_one :most_recent_order,
:class_name => 'Order',
:order => 'created_at DESC'
end
God damn this is beautiful! And powerful! The point is that the equivalent of this in other popular scripting languages used for building web apps includes you typing something like (pardon my horrendous psuedo code):
query = 'SELECT o.* FROM orders as o, customers as c WHERE o.customer_id = c.id ORDER BY created_at DESC LIMIT 1'
result = execute_query()
row = get_row(result)
// do something with the data.
Whether you do it in your php code, or a stored procedure you're still typing a messy SQL statement for something that should be simple. In Rails (or Ruby using ActiveRecord) you can simply do this:
customer = Customer.find(17) # get customer by id
puts "your last order was for #{number_to_currency(customer.most_recent_order)}"
And best of all, ZERO config. The ability to infer objects based on the schema of the underlying database is powerful. To then be able to define relationships that transcend that schema and fall into the realm of business logic (such as "your last order" and "orders pending shipment") at the model level is incredibly powerful particularly considering the amount of code you have to write. This is a great example of Rails allowing you to assist you in solving your problems as opposed to other frameworks that get in your way.
class Customer <>
has_many :orders
has_one :most_recent_order,
:class_name => 'Order',
:order => 'created_at DESC'
end
God damn this is beautiful! And powerful! The point is that the equivalent of this in other popular scripting languages used for building web apps includes you typing something like (pardon my horrendous psuedo code):
query = 'SELECT o.* FROM orders as o, customers as c WHERE o.customer_id = c.id ORDER BY created_at DESC LIMIT 1'
result = execute_query()
row = get_row(result)
// do something with the data.
Whether you do it in your php code, or a stored procedure you're still typing a messy SQL statement for something that should be simple. In Rails (or Ruby using ActiveRecord) you can simply do this:
customer = Customer.find(17) # get customer by id
puts "your last order was for #{number_to_currency(customer.most_recent_order)}"
And best of all, ZERO config. The ability to infer objects based on the schema of the underlying database is powerful. To then be able to define relationships that transcend that schema and fall into the realm of business logic (such as "your last order" and "orders pending shipment") at the model level is incredibly powerful particularly considering the amount of code you have to write. This is a great example of Rails allowing you to assist you in solving your problems as opposed to other frameworks that get in your way.
Subscribe to Posts [Atom]