|
|
 |
 |
 |
 |
Ruby Programming Language
|
 |
 |
 |
 |
 |
 |
 |
 |
Kiss your boring tasks goodbye: Everyday Scripting With Ruby
Chances are, you do some boring, repetitive data-related tasks at work -- ones a computer could easily do, if only it was told how. "At one desk, a tester is entering test data into a database by hand. At another, a programmer is sifting through the output from a version-control system, trying to find the file she wants. At a third, a business analyst is copying data from a report into a spreadsheet. Why are these people doing work that computers could do perfectly well?" asks Brian Marick, author of the book "Everyday Scripting With Ruby." --- I've got a review of the book up at Computerworld.com, for those who might be interested, it's at http://www.computerworld.com/action/article.do?command=viewArticleBas... --Sharon Machlis Online Managing Editor Computerworld -- Posted via http://www.ruby-forum.com/.
Because many corporations that have leaders that are not tech savy hire people who are and force them to work in conditions that are paradoxical to the goal and not allowing for enough time to weed out bugs, proffering that their coders instead create subroutines to solve the problem instead of writing it out--not to mention the fact that the leaders don't even understand the problem to begin with! I don't think I care to make my diatribe any longer, but worserthanfailure.com showcases this type of corporate failure all the time. Also, I'd like to mention that I'd rather people have jobs than have computers doing them efficiently. In the future, there will be very few jobs that need actual humans and no one will NEED jobs. But how will we get there? Will poverty take us over first? (I know this isn't the place for political commentary, but why computers don't take over is a very touchy subject. Do we want computers taking over?)
On Wed, May 30, 2007, Hak @gmail.com wrote: > Also, I'd like to mention that I'd rather people have jobs than have > computers doing them efficiently. In the future, there will be very > few jobs that need actual humans and no one will NEED jobs. But how > will we get there? Will poverty take us over first? From this, I infer that you're not a system administrator. Note that I'm not saying that's a bad thing, just an observation :) I have been a sysadmin, and I will be again, and one thing I've learned is this: if ever you perform a task more than twice, automate it. You'll save yourself time in the future to deal with real problems. I used to work in a Network Operations Center where we were primarily doing reactive "maintenance". When a system at a site needed to be kicked, we could either log in and do the multi-step process by hand, or run a script that automated the process, thus removing the error of (say) restarting a service on the wrong machine. I haven't read the book yet, but from the synopsis it seems that it's really about how you can leverage Ruby to help you do your job more effectively and efficiently, rather than replacing yourself (or others) with code. It's all about finding ways to make your life easier by automating repetitive, error-prone manual tasks. I suspect that the type of everyday scripting and automation suggested by the book is the kind that must be driven by a person, not the kind that replaces one. Ben
Ben Bleything wrote: > I suspect that the type of everyday scripting and automation suggested > by the book is the kind that must be driven by a person, not the kind > that replaces one.
You're right. The idea of the book isn't to write code that replaces people. It's to have people write code that eliminates some of the most boring, repetitive tasks they do, so that they can spend their time doing more productive and interesting things. The fact that I was able to write a script that saves an editor here, say, 10 minutes a day is certainly not going to replace that editor. But it could save a couple of hours of editing time a month that could be put to better use. It also makes for a happier editor, because he's not doing low-skill drudge work and instead can spend more time doing actual editing. Sharon -- Posted via http://www.ruby-forum.com/.
> I suspect that the type of everyday scripting and automation suggested > by the book is the kind that must be driven by a person, not the kind > that replaces one.
I have the book and I would describe it as entry level. If you automated tasks in the fashion you suggested, you are way past learning anything from the book.
I've read the book too. Anyone who's already been a sysadmin probably doesn't have much to learn from it conceptually. And if you're new to scripting, it's probably not structured or complete enough to get you started. It's a good resource, though, if you are new to Ruby and/or new to scripting. Gives you a bunch of solid concepts, some decent tips for the ordinary shortcuts the gurus don't want to admit knowing/bother teaching, and enough idiomatic code to get you going. Personally, I wish it ran you through some of the better command line gems (e.g., cmdparse). But hey, that's personal preference. There's some good stuff in here. +0.02 On 5/29/07, Sean T Allen <s@ardishealth.com> wrote:
> > I suspect that the type of everyday scripting and automation suggested > > by the book is the kind that must be driven by a person, not the kind > > that replaces one. > I have the book and I would describe it as entry level. If you automated > tasks in the fashion you suggested, you are way past learning anything > from the book.
On May 30, 9:44 am, "Stephen Smith" <4fi@gmail.com> wrote:
> I've read the book too. > Anyone who's already been a sysadmin probably doesn't have much to > learn from it conceptually. And if you're new to scripting, it's > probably not structured or complete enough to get you started. > It's a good resource, though, if you are new to Ruby and/or new to > scripting. Gives you a bunch of solid concepts, some decent tips for > the ordinary shortcuts the gurus don't want to admit knowing/bother > teaching, and enough idiomatic code to get you going. > Personally, I wish it ran you through some of the better command line > gems (e.g., cmdparse). But hey, that's personal preference. There's > some good stuff in here. > +0.02 > On 5/29/07, Sean T Allen <s@ardishealth.com> wrote: > > > I suspect that the type of everyday scripting and automation suggested > > > by the book is the kind that must be driven by a person, not the kind > > > that replaces one. > > I have the book and I would describe it as entry level. If you automated > > tasks in the fashion you suggested, you are way past learning anything > > from the book.
Though not directly to the topic of the book mentioned, I just wanted to say that there's another Ruby book, for the area of enterprise integration, that's pretty good, in an analogous way to the scripting one mentioned - though it discusses things at a level targetted at more experienced programmers. I think its a pretty valuable resource for anyone doing integration work. I blogged a short review of it here: http://jugad.livejournal.com/2007/04/15/ Enjoy, Vasudev Ram Dancing Bison Enterprises http://www.dancingbison.com "Eventually hardware fails. Eventually software works."
On May 30, 6:16 pm, vasudevram <vasudev@gmail.com> wrote:
> On May 30, 9:44 am, "Stephen Smith" <4fi @gmail.com> wrote: > > I've read the book too. > > Anyone who's already been a sysadmin probably doesn't have much to > > learn from it conceptually. And if you're new to scripting, it's > > probably not structured or complete enough to get you started. > > It's a good resource, though, if you are new to Ruby and/or new to > > scripting. Gives you a bunch of solid concepts, some decent tips for > > the ordinary shortcuts the gurus don't want to admit knowing/bother > > teaching, and enough idiomatic code to get you going. > > Personally, I wish it ran you through some of the better command line > > gems (e.g., cmdparse). But hey, that's personal preference. There's > > some good stuff in here. > > +0.02 > > On 5/29/07, Sean T Allen <s@ardishealth.com> wrote: > > > > I suspect that the type of everyday scripting and automation suggested > > > > by the book is the kind that must be driven by a person, not the kind > > > > that replaces one. > > > I have the book and I would describe it as entry level. If you automated > > > tasks in the fashion you suggested, you are way past learning anything > > > from the book. > Though not directly to the topic of the book mentioned, I just wanted > to say that there's another Ruby book, for the area of enterprise > integration, that's pretty good, in an analogous way to the scripting > one mentioned - though it discusses things at a level targetted at > more experienced programmers. I think its a pretty valuable resource > for anyone doing integration work. > I blogged a short review of it here: > http://jugad.livejournal.com/2007/04/15/ > Enjoy, > Vasudev Ram > Dancing Bison Enterpriseshttp://www.dancingbison.com > "Eventually hardware fails. Eventually software works."
P.S. Forgot to mention a disclaimer: I'm not affiliated with The Pragmatic Bookshelf or the author of the Enterprise Integration in Ruby book in anyway. I just think its quite a good book. Vasudev
Sean T Allen wrote: >> I suspect that the type of everyday scripting and automation suggested >> by the book is the kind that must be driven by a person, not the kind >> that replaces one. > I have the book and I would describe it as entry level. If you automated > tasks in the fashion you suggested, you are way past learning anything > from the book.
yes i am agree with you. -- Posted via http://www.ruby-forum.com/.
|
 |
 |
 |
 |
|