Take note: In the Orlowski article, the line following the bit about the lotus-eating is:
"Both these points of view are caricatures, of course."
Thanks to the poster for the sensational, and ultimately false, summary.
With regard to the rails stuff: Mebbe try lighttpd. I've heard _such_ great things about using this in combination with fastcgi. I'll be curious to hear how it turns out. When you've spent some time with it, let us all know.
With regard to xslt: Yeah, this was actually the thing that you listed off that made me wince. I had a bit of a tough time with the xslt library when I tried to use it last. My solution to the problem was to use the templating that ships in the Ruby standard library. I suspect this isn't the answer that you're looking for.
Another solution you may want to consider is shelling out. It's dirty (I guess), but I'm pretty sure that you can get your transform done for cheap by a third party.
I think that there's been a lot of work done on the ruby libraries in the past year. It might be worth your time to revisit them. Good luck, and don't hesitate to try the ruby-talk mailing list next time you work yourself into a corner!
The libraries available to Ruby and not as extensive as Python
What are you looking for that you haven't found? I'd be glad to help you find what you need.
I think that you'd be surprised if you were to look around rubyforge or the RAA. There are a lot of useful libraries available right now. Rubygems can make installing any of them that are packaged as gems a snap!
Also consider checking in with the ruby-talk mailing list. There are lots of smart folks waiting there to help you.
I am a hardcore C++ developer with a lot of Java, so for me Ruby and Python are used for the same position: scripting. Python libraries are very extensive and complete for almost everything I want in a scripting language (even more so than java). Ruby is still a relatively new langugae and the libraries are just not powerful enough (yet...). Withpython I can post to newgroups, send email, do XSLT, generate XML files all with a few lines of code; with ruby I have to do a lot of the work still. I have no doubt Ruby will get there but for now it's still not mature enough.
I think you must not have looked around very hard. All of the tasks that you have laid out are easily accomplished wth existing ruby libraries (which are as often as not ports of python or perl libraries).
It's an honest mistake. When I have to dig through the Python documentation I usually end up curled up in a ball in the corner of the room. It just doesn't work for me. It doesn't take me more than a minute or two to find what I need for my work in Ruby (with a few exceptions).
Like I said, Ruby has excellent constructs for OO development (for a script language); so I have been thinking of a way to embed Ruby into my C++ code to externalize some scripting tasks (Lua is another contender but the documentation to Lua is a bit too obscure and I don't have the time to learn it, Ruby is better documented and easier to get started with).
Lua may be worth looking into. I've a coworker that's looked into it for a personal project . He told me that it was easier for him to pick up than Ruby (for embedding anyway).
I can see how Ruby on Rails is meant for portability (I did you the web brick but in release mode), but I personally need performance to handle the load of 100 hits per seconds (not a lot but when I used RoR for the small DB view part it was noticeably slow so I went back to the JSP page, I'll rewrite it in C++ which should solve the performance issue).
I think that I wasn't clear in my last post. Don't use Webrick and expect to get any kind of performance out of it. Use Apache. Use Lighttpd. It doesn't matter what you do to Webrick. It won't be quick until the ruby interpreter gets real quick.
So develop on Webrick and deploy on a performance server. I think that's a popular approach.
Good luck in your future endeavors and good luck finding the right tool for the job. I think that's something you should focus on.
I used RoR for about a day and wrote a little app then realized that maintenance is a pain and that I would have to manually change all the code anyways to make it behave as I want and that codegen created something I did not want. Then I weighed it against writing sevlets and JSP pages and RoR didn't look so appealing.
I'm certain that this idea will be expressed elsewhere, but please note that the code that rails generates is only a skeleton that you can shape to suit your purposes.
But which code generation feature did you use? I am honestly curious, because I can't really line up these comments with any of the code generation features in rails without making some pretty absurd assumptions.
Performance was quite bad too, about 6 times slower than JSP for fetching some data from a database, manipulating it (which is the bulk of the work) and displaying it (given JSP gens compiled into Java and takes advantage of JIT).
Probably you were using the webrick server in development mode. It's not really supposed to be fast, it's supposed to be simple and portable. If you spend some time looking around, you'll find many production configurations that will run as fast as you need them to.
Ruby is a nice language though, but it's not as useful as python.
The same thing is true for the Programming Ruby book: it's a clear understandable book on object-oriented programming that uses a friendly pseudocode called "Ruby".
I think that you make an important point here. Aside from their use in allowing us to control the behaviors of complex computing machines, programming languages facilitate the recording of and communication of algorithms and data. The "friendly pseudocode" attribute of the Ruby language makes it particulary useful from this perspective.
Make it interesting; get the setup that Dr. Monroe had for the Simpsons therapy session. It'll make for some seriously animated discussion. Not to mention helping people stay awake.
I'm going to weigh in against the long-term viability of the outsourcing scene. I have some hunches that I've yet to see tested, but there are also some that have been proven correct. As a result of my experiences, I believe that outsourcing through the language barrier will in time be proven to have been a fad. The whole thing is a false economy.
Certainly, there will always be markets where you can find someone willing to provide a service for less than a local supplier. When the service doesn't seem to be tied to any geographical location in the way that software is practically universal (like english!), there will always be the temptation to chase estimated or hourly savings.
The cost of interfacing between languages and remote supervision must be taken into account. Also consider the efficiency and accuracy that you can communicate with in your native language. Just for fun, grab a french-english dictionary and try to comment that code that you wrote this afternoon...but in french. Come back to it in a couple of days and see how well you can understand it.
Consider also that currently, a lot of work is being sent to India. There's a reason that workers are willing to accept lower wages. The cost of living is lower. But what will happen if so much work continues to stream into India and it continues to carry with it foreign cash. As some workers increase their assets and income, others around them will demand more as well. So the savings found in India decreases and less work flows there.
Bottom line: vigorous outsoucing cannot continue forever because all of the money flowing out of our country shrinks the deltas between world economies. And that will erase the conditions that made outsourcing attractive in the first place.
Of course, that's just my opinion. I could be wrong.
Be objective and factual. A good encyclopedia article describes a topic in a precise, straightforward manner that is free of bias and opinion. If an issue has two sides, both sides should be presented in an objective manner.
I can't wait to see what the "Microsoft" entry is gonna look like after a while. They're gonna need to hire an editor/firefighter for that entry alone. It'll be a full time job!
I've traditionally been a breadth man. For prototyping, rapid development and non performance-intensive stuff it's worked out for me. In fact, at work I do a little bit of everything, with all of the languages we use (Perl, Python, Ruby, C/++, VBA) and my level of comfort with those languages helps us be a little more flexible.
On the other hand, Ruby has inspired me to go for depth. I _really_ enjoy using it, and for me that's awfully important. I can use a lot of other languages for easy things, but when the going gets tough, I like Ruby because it doesn't seem to fight back quite as much.
Let's not forget about these guys. Absolutely my favorite robo-evolution story ever. Ever.
How many other robots can say they've "forced its way out of the small make-shift paddock it was being kept in"?
it is also worth noting that broadcasting is not a right either. broadcasters (in the case of television and radio) are allocated bandwidth with the understanding that some portion of their programming will be in the public interest. it is s'posed to be part of the FCC's job to make sure that they hold up their end of the deal.
Slashdot Mirror
Nice link. Perhaps you'll be interested in another post from that site?
Charming.
Take note: In the Orlowski article, the line following the bit about the lotus-eating is: "Both these points of view are caricatures, of course." Thanks to the poster for the sensational, and ultimately false, summary.
With regard to the rails stuff: Mebbe try lighttpd. I've heard _such_ great things about using this in combination with fastcgi. I'll be curious to hear how it turns out. When you've spent some time with it, let us all know.
With regard to xslt: Yeah, this was actually the thing that you listed off that made me wince. I had a bit of a tough time with the xslt library when I tried to use it last. My solution to the problem was to use the templating that ships in the Ruby standard library. I suspect this isn't the answer that you're looking for.
Another solution you may want to consider is shelling out. It's dirty (I guess), but I'm pretty sure that you can get your transform done for cheap by a third party.
I think that there's been a lot of work done on the ruby libraries in the past year. It might be worth your time to revisit them. Good luck, and don't hesitate to try the ruby-talk mailing list next time you work yourself into a corner!
I think that you'd be surprised if you were to look around rubyforge or the RAA. There are a lot of useful libraries available right now. Rubygems can make installing any of them that are packaged as gems a snap!
Also consider checking in with the ruby-talk mailing list. There are lots of smart folks waiting there to help you.
I think you must not have looked around very hard. All of the tasks that you have laid out are easily accomplished wth existing ruby libraries (which are as often as not ports of python or perl libraries).
It's an honest mistake. When I have to dig through the Python documentation I usually end up curled up in a ball in the corner of the room. It just doesn't work for me. It doesn't take me more than a minute or two to find what I need for my work in Ruby (with a few exceptions).
Lua may be worth looking into. I've a coworker that's looked into it for a personal project . He told me that it was easier for him to pick up than Ruby (for embedding anyway).
I think that I wasn't clear in my last post. Don't use Webrick and expect to get any kind of performance out of it. Use Apache. Use Lighttpd. It doesn't matter what you do to Webrick. It won't be quick until the ruby interpreter gets real quick.
So develop on Webrick and deploy on a performance server. I think that's a popular approach.
Good luck in your future endeavors and good luck finding the right tool for the job. I think that's something you should focus on.
The same thing is true for the Programming Ruby book: it's a clear understandable book on object-oriented programming that uses a friendly pseudocode called "Ruby".
I think that you make an important point here. Aside from their use in allowing us to control the behaviors of complex computing machines, programming languages facilitate the recording of and communication of algorithms and data. The "friendly pseudocode" attribute of the Ruby language makes it particulary useful from this perspective.
Make it interesting; get the setup that Dr. Monroe had for the Simpsons therapy session. It'll make for some seriously animated discussion. Not to mention helping people stay awake.
This story seems a little skinny on details. Does anyone have any more information?
http://www.shazam.com/uk/do/home
Ummm...I hate to nitpick, but that's 65535 rows. Remember, each row gets you a whole 256 columns of fun!
I'm going to weigh in against the long-term viability of the outsourcing scene. I have some hunches that I've yet to see tested, but there are also some that have been proven correct. As a result of my experiences, I believe that outsourcing through the language barrier will in time be proven to have been a fad. The whole thing is a false economy. Certainly, there will always be markets where you can find someone willing to provide a service for less than a local supplier. When the service doesn't seem to be tied to any geographical location in the way that software is practically universal (like english!), there will always be the temptation to chase estimated or hourly savings. The cost of interfacing between languages and remote supervision must be taken into account. Also consider the efficiency and accuracy that you can communicate with in your native language. Just for fun, grab a french-english dictionary and try to comment that code that you wrote this afternoon...but in french. Come back to it in a couple of days and see how well you can understand it. Consider also that currently, a lot of work is being sent to India. There's a reason that workers are willing to accept lower wages. The cost of living is lower. But what will happen if so much work continues to stream into India and it continues to carry with it foreign cash. As some workers increase their assets and income, others around them will demand more as well. So the savings found in India decreases and less work flows there. Bottom line: vigorous outsoucing cannot continue forever because all of the money flowing out of our country shrinks the deltas between world economies. And that will erase the conditions that made outsourcing attractive in the first place. Of course, that's just my opinion. I could be wrong.
Be objective and factual. A good encyclopedia article describes a topic in a precise, straightforward manner that is free of bias and opinion. If an issue has two sides, both sides should be presented in an objective manner.
I can't wait to see what the "Microsoft" entry is gonna look like after a while. They're gonna need to hire an editor/firefighter for that entry alone. It'll be a full time job!
I'd say that's pretty well put.
I've traditionally been a breadth man. For prototyping, rapid development and non performance-intensive stuff it's worked out for me. In fact, at work I do a little bit of everything, with all of the languages we use (Perl, Python, Ruby, C/++, VBA) and my level of comfort with those languages helps us be a little more flexible.
On the other hand, Ruby has inspired me to go for depth. I _really_ enjoy using it, and for me that's awfully important. I can use a lot of other languages for easy things, but when the going gets tough, I like Ruby because it doesn't seem to fight back quite as much.
Let's not forget about these guys. Absolutely my favorite robo-evolution story ever. Ever. How many other robots can say they've "forced its way out of the small make-shift paddock it was being kept in"?
it is also worth noting that broadcasting is not a right either. broadcasters (in the case of television and radio) are allocated bandwidth with the understanding that some portion of their programming will be in the public interest. it is s'posed to be part of the FCC's job to make sure that they hold up their end of the deal.