1. NARF 2. ruby-web 3. ???? 4. Profit!!!
Chad Fowler just linked to an article describing local maximums and career optimization. I guess Point C is the same as 3. ????.
Each time I sit down and think about Ruby vs other web environments, I see so much room for improvement. I thought the scary stuff was behind me, and then I started thinking about database support.
The next dip will be in sorting out the nitty gritty of database support. I think the main problem with DBI is driver support -- that'll teach me C for sure! Sorting out easy to use binary installers is also a pain.
Btw, Kirk Haines, developer of IOWA, pointed out that IOWA already has developed a Drb connection pool.
Each time I sit down and think about Ruby vs other web environments, I see so much room for improvement. I thought the scary stuff was behind me, and then I started thinking about database support.
The next dip will be in sorting out the nitty gritty of database support. I think the main problem with DBI is driver support -- that'll teach me C for sure! Sorting out easy to use binary installers is also a pain.
Btw, Kirk Haines, developer of IOWA, pointed out that IOWA already has developed a Drb connection pool.
Comments:
<< Home
DBI really needs some TLC. It has such amazing promise.
There's some things I really dislike about DBI -- I find the connection strings to be beyond ugly -- but good documentation would solve most of it. It's the undocumented and ugly that I hate the most.
Efficiency is a problem, but I really don't think there's an API problem, just lots of optimization needed. Lots of things should be moved out into the database drivers -- Postgresql's native layer returns everything, including numbers, as strings! I think that's a bit nutty, since it's more conversion code that has to run. Pushing optimizations low in the stack I think will yield a fast, stable and powerful system.
Post a Comment
There's some things I really dislike about DBI -- I find the connection strings to be beyond ugly -- but good documentation would solve most of it. It's the undocumented and ugly that I hate the most.
Efficiency is a problem, but I really don't think there's an API problem, just lots of optimization needed. Lots of things should be moved out into the database drivers -- Postgresql's native layer returns everything, including numbers, as strings! I think that's a bit nutty, since it's more conversion code that has to run. Pushing optimizations low in the stack I think will yield a fast, stable and powerful system.
<< Home