Slashdot Mirror

Why is that modded Informative? You can't buy just the book.

From their Faq page:

Can I preorder just the paper book under this program?

No, the rules of our credit card processor stop us taking preorders more than 30 days before we ship something.

Notice that you cannot buy just the book at this time.

My main problem with the offer is the fact that they are charging for the Beta PDF on top of the preorder. When I saw the deal I naturally assumed they would be giving out the Beta PDF in exchange for a preorder of the finished book--not using it to squeeze out additional money. I was extremly disappointed when I saw that they are charging for both, even though I would be paying up front for an unfinished product. I don't care if the PDF gets updated later, since I would have the book at that time.

Check out their Beta FAQ

Here is a good article on implementing State Machines (PDF link):

http://www.pragmaticprogrammer.com/articles/nov_02 _state.pdf

I first heard of Ruby on Rails here on Slashdot. Although Rails is dead simple once you get it, getting to the "ah ha" point is a bit of a steep climb.

If you want to learn Ajax in Rails, the best thing I've read has been Dave Thomas' new book "Agile Web Development with Ruby on Rails". The author of Ruby on Rails itself, David Heinemeier Hansson, is also a co-author. Great book, absolutely fantastic web development framework.

Get the Beta book http://pragmaticprogrammer.com/titles/rails/index. html If you're interested in Rails at all, this book is all you need.

When learning Ruby, there is only one idea that you will need to expend some effort getting your head around: blocks. Once you grok them, though, you will appreciate the power and elegance they give you. Using an API that takes blocks is nice. Being able to use blocks in your own APIs is even better.

In fact, Ruby fans wax rhapsodic about blocks so often that it irks a lot of Lisp and Smalltalk hackers who have had them for decades. It's not a new concept, just new to a lot of today's young programmers who grew up on C-like languages (myself included).

Other than blocks, I found Ruby's learning curve to be astonishingly short. In fact, I think it is a great first programming language. In the past I've done serious work in ColdFusion, Java, and C#, and dabbled in C/C+++, PHP, Python, Perl, Lisp, and Visual Basic. Other than blocks, I found Ruby to be the easiest to learn by far (and blocks are the best part).

The pickaxe book is the one you want. Also check out Ruby on Rails if you're primarily interested in webapps (I've only barely looked at it, but a lot of people seem to be ga-ga over it).

I bought the (beta) book Agile Web Development with Rails a week ago. So far Rails looks like a really cool web framework. Who knows perhaps will I participate in next Rails Day 2006.

Here is a pretty cool article on a similar project, but from the software development point of view.

If you write software, take a look at the book Pragmatic Project Automation (I think it was reviewed a few months ago here on /.)

It is geared a lot towards Java projects, but there are some philosophical nuggets there for any project.

due to slashdot abuse they now provide a direct link to the file, no need for an email.

http://www.pragmaticprogrammer.com/hwgh.html

Enjoy.

http://www.pragmaticprogrammer.com/articles/zenph/ index.html

At the Milwaukee No Fluff Just Stuff conference, I was invovled in a lunchtime conversation with Justin and [Pragmatic] Dave Thomas about this subject, just days after Justin completed the Ruby code.

The concensus at that point: it probably wasn't a difference in *execution* speed, but smarter data retreval strategies used by Rails persistance layer. While Hibernate has excellent support for lazy loading, both developers thought that Rails was being *lazier*.

Justin's new numbers also point to faster caching in RoR's persistance layer: while both applications performed about equally without pre-cached data, RoR performed 20x better than the Java stack with cached data [both versions using similar caching strategies].

As for those questioning Justin's java skills: he's one of the best programmer's I've had the privilege to know, one of the best speaker's I've listend to, and is freaking hilarious to boot. He's the co-author of O'Reily's Better, Faster, Lighter Java, and he regularly speaks on advanced Hibernate, Spring, and a bunch of other Java topics.

He also points out a *significant* decrease in Lines of Code[Java:3293 RoR:1164] and Lines of Configuration [Java:1161 RoR:113]. While not an accurate gauge of effort, it is another point in Ruby's favor.

Last point for Ruby: Every single *top notch* Java programmer I know is at least playing with Ruby and RoR, with a large percentage [>50%] transitioning to Ruby as a first choice for new project work.

Don't call it a toy until you've played with it. There's some pretty convincing evidence that Ruby/RoR can beat Java for development effort, and now we're seeing it can beat it for performance, too.

I see your point, but you seem to be mistaking Eclipse for a general-purpose text editor.

Well, I was mistaking it for a programmer's editor actually - silly old me.

The idea that you can have an editor which allows you to code Java, etc but won't let you edit a simple text file is, quite frankly, ludicrous.

Most programmers I know will use the same text editor for everything they do, whether it's coding or creating/editing a simple config file, searching a log file for text, etc. After all, Use a Single Editor Well.

Forcing a programmer to use a different editor just because they're looking at something outside a rigidly defined project is just dumb.

You wouldn't use OpenOffice's word processor to write code, would you?

No, but frankly I don't see the relevance. Editing a simple text file is a subset of editing a source code file, not a completely different activity.

The Pragmatic Progammers sell the PDFs of their books with no DRM and they seem to be doing okay. That is to say, the books aren't all over Google.

http://www.pragmaticprogrammer.com/starter_kit/faq s/pdf_faq.html

I have recently started to play with PHPDoc to create self-documenting code.

That's not quite self-documenting code. That's source code that contains documentation.

I use tools like WinMerge, Subversion (only a little, not so good at it) and ReplaceEm to maintain large codebases.

Keep practicing... it'll come to you. You might also want to look for a copy of Pragmatic Version Control Using Subversion.

I know OOP, but it isn't natural for me, so I'm still a procedural boy, even when Object-Oriented Programming might help.

OOP is not an overnight thing. It takes quite a while to get the "feel" for it.

I have no idea what vectors and matrixes are.

So, quit making excuses... go and learn them!

I'm self-taught, my schooling is as an English major. So I have absolutely no Computer Science education behind what I do. While I try to do well, my solution to a deep and complicated problem is going to be basic compared to a guy who spent years of his life learning algorithms.

The reason people spend years of their lives learning algorithms is so that THEY can produce basic solutions to deep and complicated problems. One elegant algorhithm can save you a lot of tricky coding.

You're not the first "artsy" to ply the coding waters. Those english skills will pay off down the road. Just ask Richard P. Gabriel.

Dave Thomas' new book "Agile Web Development With Rails" is due out in July. It's really, really good so far (I'm one of the lucky ones who is helping review it). My perspective is a person who knows very little about databases, web application development and no previous knowledge of Ruby, the language that Rails is built on.

One of the big problems with Ruby on Rails is that it is well documented, but a lot of it is API's and reference documentation. Dave's new book has an excellent tutorial which is the best thing I've seen written so far about RoR for newbies, and promises to go into the depth and detail similar to his Pickaxe book.

If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released. I'm finally getting over the hump with RoR and I now see what all the fervour is about.

(Oh, don't ask me to post or send copies of his drafts, 'cause I ain't gonna!)

Dave Thomas' new book "Agile Web Development With Rails" is due out in July. It's really, really good so far (I'm one of the lucky ones who is helping review it). My perspective is a person who knows very little about databases, web application development and no previous knowledge of Ruby, the language that Rails is built on.

One of the big problems with Ruby on Rails is that it is well documented, but a lot of it is API's and reference documentation. Dave's new book has an excellent tutorial which is the best thing I've seen written so far about RoR for newbies, and promises to go into the depth and detail similar to his Pickaxe book.

If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released. I'm finally getting over the hump with RoR and I now see what all the fervour is about.

(Oh, don't ask me to post or send copies of his drafts, 'cause I ain't gonna!)

Sample excerpts from the book are available in PDF format from the book website. You can also download the full Using Tags and Branches chapter artima.com (free login required).

<gripe>Most tech books these days have a page on the publishers website, and some offer a sample chapter for download. Book reviewers should include a direct link to this book page, and note what excerpts/chapters are available for preview, if any (and prevent people like me karma whoring).</gripe>

Wheres a good tutorial site? (multipule if possible)

Any books worth reading?

There's more than these, of course, but these will definitely get you started.

General resources sites?

Wheres a good tutorial site? (multipule if possible)

Any books worth reading?

There's more than these, of course, but these will definitely get you started.

General resources sites?

Wheres a good tutorial site? (multipule if possible)

Any books worth reading?

There's more than these, of course, but these will definitely get you started.

General resources sites?

The Ruby language home page is here, and the main reference book is the Pickaxe (from the Pragmatic Programmers)

...one of the nice things about Ruby is that Dave Thomas and Andy Hunt keep Programming Ruby up to date. The second edition just came out, and it's a good one.

If you're using Ruby or are interested in using it, it's an excellent written by someone who's very active in the Ruby community.

Also has cool lava lamp sections! ;) http://slashdot.org/article.pl?sid=04/08/26/155025 5

The book link is here... http://pragmaticprogrammer.com/starter_kit/au/inde x.html

http://pragmaticprogrammer.com/titles/ruby/index.h tml

You must be confusing it with a different book by O'Reilly. "Programming Ruby: The Pragmatic Programmer's Guide" is published by Addison-Wesley.

Oops... you're right, O'Reilly isnt the publisher, but neither is Addison-Wesley for the 2nd edition. It is published by the Pragmatic Bookshelf publishers

I really think that if you're coming from Perl you'll prefer
Ruby to Python. No indentation hassles with Ruby, for example. You'll also like the way Ruby does OO compared to Perl OO. More Rubilicious links...

Also, The Pragmatic Programmers have released a new edition of Programming Ruby that's a great intro and reference to the language - go buy it from their website.

Ruby: Because I can't wait around for Perl 6 to get finished

That's also the home page for the book with downloaded code samples and so on.

thanks!

/\ndy

The Pragmatic Programmers seem to be doing a great job with their new publishing efforts. They're able to get new titles out much more quickly than some of the more established publishers by following their own advice about automation and applying it to publishing. I recall reading on one of their blogs that they were able to go from idea to actual book in under six months.

I can't wait for their upcoming Ruby book.

-- /\ndy

trying again, w/o the trailing slash this time

http://www.pragmaticprogrammer.com/starter_kit/ind ex.html

Build on the brand you already have!

http://www.pragmaticprogrammer.com/starter_kit/ind ex.html/

The timestamps in the 0.9.3 release directory show that the Windows binary has been updated.

Got the supposed 0.9.3 for Windows earlier today, which didn't work. Process appeared in task list, but no window came up. Also, any place the version number appeared, it was still listed as 0.9.2. With the caveat that I don't know how those folks do their releases, I'll say that with the proper automation, that oops-i-forgot-to-increase-the-version-number snafu should never happen.

You need to buy a copy of the Pragmatic Programmer's starter kit

The third book in the series is about project automation, where they teach you how to repeat in a controlled manner all the stuff you learned in the first two books. The basics:

1) Write unit tests before writing your methods
2) Your unit tests should follow the inheritance tree of the classes under test to avoid duplicate test code.
3) Write a vertical "slice" of your application first (all the layers, none of the functionality). This will prove out communications and give the QA people something to work with while you flesh out the app.
4) Build & unit test nightly. Any build or unit-test errors need to be fixed the next day, and no later.
5) Release to QA as often as things get semi-stable, and when they have time to test.
6) Try not to ship with any known bugs. How do you know if you've got bugs? Your unit tests, integration tests, QA tools, and end-users tell you via a bug-tracking tool like BugZilla or FogBugz

Do we do all this at my current employer? No. But we're working towards it.

Chip H.

In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict .

A broken window.

One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment---a sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality.

You can follow the link above to see how they connect crime to poor coding.

I'll second Audible.com for a good site if you have a morning commute.

I wish someone like the Pragmatic Programmers would tape their talks and put them on audible.com for download.

No, it's not obscure. Please have a look at Ruby, where closures are the natural way of doing most things. For example, there is no for-loop, but it is implemented as method for Integer objects (literals are also objects in Ruby):

14.upto(19) do |i|
# do ... end is the closure
end

so, the closure is executed 6 times, the first time with i = 14, the next time with i = 15, the third time with i = 16, up to i = 19.

Just have a closer look at Ruby, and you will see that the whole standard library is built on top of this simple and elegant concept. The book "Programming Ruby" can even be read online and downloaded from www.pragmaticprogrammer.com.

...was a good one for learning about CVS.

Especially helpful was a small appendix which listed various recipes; i.e., the series of 3 or 4 steps necessary to merge a bugfix from one branch to another or whatever. I always forget the order of those cvs -j options...

Andy Hunt, of Pragmatic Programmer fame just released a series on Unit testing while emphacising *NOT* screwing productivity.

I just got to see a presentation from him this past Saturday. He's a sharp guy.

I believe his recent book, Pragmatic Version Control, is self-published. Last I heard, he was in his garage boxing up orders, due to a really large spike that arose from the recent book report on /.. He would probably be able to give you considerable insight into the process.

Here's a couple of decent ones:

http://cvsbook.red-bean.com/

http://www.pragmaticprogrammer.com/starter_kit/vc/

Like a previous post, I'd suggest "evolving" to testability - every time you fix a bug or add a feature, do it test first.
You will have to spend some time setting up the testing framework - a structure for your unit tests, the "non-code" stuff, and a way of finding out asap that you've broken a test.
Depending on your environment, you could use something like AntHill or CruiseControl to automatically run all your unit tests as part of a (timed) build process, and email the results. CruiseControl also allows you to specify regular intervals at which your entire code-base is checked out of source code control, and unit-tested - you get an email if something breaks.
A key problem for most systems is getting all the "non-code" stuff (in my case mostly databases etc.) into a known-good state so you can rely on a unit test reporting accurate errors when trying to insert a duplicate value or delete a non-existing record - again, automate using (something like) Ant - Ant will do a lot of this stuff for you on non-java projects too.
Once you have refactored sufficiently, you can hopefully start testing independently from the "non-code" items.
I'd suggest buying Kent Beck's book "Test Driven Development" for more ideas on how to code in this paradigm - it's very very good.
Another book worth reading is The Pragmatic Programmer (they have a website too). Especially the "no broken windows" section is very worthwhile...

But now I'm learning Oz with the people at Pragmatic Programmers "language of the year" mailing list. I find its syntax easier to grab, and I think it will be a worthwile experience. So one thing at a time.

So this probably won't see the light of day, but...

I thought that this was one of the best essays I've read in some time, even given its lack of technical substance.

The message of this article ultimately is that our languages of choice are often as much a matter of subjective personal preference as anything else.

A major theme of this article, then, was not to bash languages, but to celebrate the variety. The author's really trying to encourage us to explore our personal tastes.

Did anyone else note the link to pragmatic programmers, following admonishments to learn a new programming language each year?

How many on Slashdot try something like this? Maybe not every year, but on a regular basis? What's your experience been? Is it worth it? Anyone switch their language of choice because of it? Expand their respect for other languages?

Paul Graham is a well-known Lisp programmer. He didn't beat us over the head with it in his article, but I'm pretty sure that he considers Lisp (Common Lisp, in particular) to be that good language, for yesterday and today at least.

I suppose that it's an acquired taste, but I'm convinced that it's a taste well worth acquiring. Here is a little screed I wrote to explain why I hold that conviction. Graham wrote several articles which tell his reasons. Some which pop to mind are: Beating the averages, Lisp in web based applications and What made Lisp different

By the way, Lisp doesn't have to be very slow. Here is a pointer to a paper which might get you started.

Bad link -- should be www.pragmaticprogrammer.com/articles/ArtInProgramm ing.pdf

How To Keep Your Job

"Programming Ruby" (aka "The Pickaxe Book") by David Thomas and Andrew Hunt Addison-Wesley Oct 2000 ISBN: 0201710897 is available online, download, or purchase.

If you like the online edition, buy the book so the authors can do a second edition. I am sure this goes the same for Mr. Perens' new line of books.

Here is a free book on Programming Ruby available for download. This free electronic version is actually very good.
http://www.pragmaticprogrammer.com/ruby/downloads/ index.html

Here is a free Japanese comic book, Hikaru No Go, also available for download. It's about Go, the game, but nevertheless it's a pretty addictive comic book.
http://www.toriyamaworld.com/hikago/index.html

1. Have several levels of your Developer Suite. Have cheapy "educational" versions for students, or personal use, and more pricy commercial versions for business who need more support. I don't necessairly support making it FREE, but make at least a compiler/linker etc available for free, and then resonably priced Suites. Reminds me of the Visual C++ Studio that I was able to buy for $180 or 200 because I was a student. I would make it cheaper than that, tho, because students are typically cheap :)

2. Have the ability to NOT rely on your Developer Suite to use the rest of your product. It is kind of old fashioned, I guess, but probably 85-90% of the work that I do at my job is using vi and a gcc-esque compiler.

3. Make sure that using your Developer Suite will not make the code produced in it obsolete elsewhere. Use ready-available, modular code for your add-ons, and make them available and usable for the people who decide not to use the Suite.

4. Good documentation, also available for free. Provide good, solid, documentation for several levels. I think the Ruby Documentation (or download)is a good example of this because it starts out very low level for a newbie or student, but the end is a close to exhaustive set of built in libraries and methods. Publish the book for those that want to have a hard copy, but also make it available to read online. 9 times out of 10, developers will want to have a hard copy that they can put sticky notes in and page marks, but the information should be there for free.

If it is quality, people will use it!