If you've got a reasonably recent JVM installed you can run CPD via Java Web Start here.
There are some examples of CPD output there too - like the duplicate code chunks that it found in the JDK source code and in the Apache httpd source code.
> Having said that I really don't see why you > have to devote a complete book on regex. > A small tutorial does just fine
I think it depends on how deep you want to go into regular expressions. Mastering Regular Expressions by Jeffrey Friedl is almost 500 pages but is an excellent treatment of the subject - by the time you're done reading it you'll feel comfy even with such madness as negative lookbehind.
> Even with dynamic content you can usually cache for a few seconds without serving stale responses
That's an excellent point... I was thinking about the front page of RubyForge, and caching that for 30 seconds or so shouldn't inconvenience anyone. Maybe I'll give that a whirl. Thanks for posting!
This was mentioned in Rich Bowen's excellent lightning talk and is listed as "experimental" in the Apache 2.0 docs but as an "extension" in the Apache 2.2 docs. Anyone have experience with this? Seems very tweakable...
Many thanks indeed! I was happy to see that the folks at Virginia Tech (Dr Edwards, specifically) are doing the same thing as part of their WebCat automated grading gizmo; more on all that here.
Right, but isn't that the point of the long tail? If Dan Brown sells a bazillion copies of "Da Vinci Code" and I sell 500 copies of PMD Applied, we're both happy since we're meeting the expectations that we budgeted for. Of course, he's then a billionaire, whereas I've still got my office in the laundry room, but, er, anyhow.
...in 37 signals (the guys who made Ruby on Rails), I wouldn't be suprised to see some more RoR happening there as some commenters here have suggested. Good times...
The JavaPosse had some notes on this a while back and they seem to keep an eye on the issue. That podcast definitely worth listening to once or twice a week to keep up with the latest news.
Exactly right. I expect my JavaCC book to sell about that - maybe - each year. But since it's published by a small outfit, that's OK. We'll sell ~60 copies, break even, and consider the rest gravy.
> You should be able to persist the same data model > to web services, databases, XML and so on
If you need that functionality, yes. If you only need to write to/from a specific persistence mechanism, then using a good solution for that persistence layer may be a good way to go.
> This is why most ORMs have a separate mapping layer, which protects against this.
I'd submit that many web apps don't need really this layer and that, in many cases, introspecting the DB like AR does is plenty good enough.
Anyhow, not to thrash this out too much, just wanted to make the point that AR adaptors can be written for something other than a relational DB.
> i went to purchase a rails book the other day and gave this > book and the book "Agile Web Developent with Rais" and found > the agile development book to be better, imho. and $10 cheaper.
I think they serve different needs. Get the Agile book to learn how to build a Rails app, and then get Dr. Black's book to learn how Rails works under the covers.
Re:Right time
on
Ruby For Rails
·
· Score: 3, Interesting
> It's about the right time for a RoR book, since > things have been moving so much of late,
Yup, and this book will last for a while since it focuses on how Rails uses Ruby to do the metaprogramming "magic". So if the APIs move on slightly the techniques in Dr. Black's book still apply.
For those who aren't on the Ruby lists, Dr. Black is a long-time Ruby user, a founder of the 501(c)(3) Ruby Central that organizes the Ruby conferences, and generally a Rubyist from way back. He's rather a guru but he still answers questions on the mailing lists and generally does a lot of grunt work.
> you can create AJAX-based Web applications very easily with RoR
Right on. Ditto with RJS - we're using them on the indi site (click the comments section to see it in action) and they work nicely. A very little bit of Ruby code gets you the Javascript functionality you want. And Rails' architecture seems to make that sort of thing easy to add.
I was kind of suprised to see the recommendation for formal code reviews. In my experience those end up either as "hurt feelings" slugfests or, just as ineffectively, full of "you should put a space after this brace" comments. I feel that pair programming is more effective way of getting multiple eyes on the code, spreading knowledge around, training the new guys, and all that good stuff.
And of course there's always static analysis to catch any problems that do manage to sneak in there...
...that seems to be up and coming in the Ruby world is RJS templates. We're using them for the new indi site and they seem pretty handy. The Javascript to Ruby translation is not perfect, of course, but they make some AJAX-ish things nicer: page.visual_effect:highlight, 'sidebar_heading',:duration =>3.
If you're in the northern Virginia area you might be interested in the next NovaRUG meeting; there'll be a presentation on RJS there. Good times...
Yup, and rubyforge and LuaForge as well. One hard part is sorting out duplicates... getting a list of the actual projects shouldn't be too hard since most project aggregation sites have RSS feeds with that info.
...is Sun's Jackpot, headed up by Tom Ball. What's neat about Jackpot is that it does problem fixing, too, using a domain specific language. From the interview:
$object.show() => $object.setVisible(true)::
$object instanceof java.awt.Component;
Feeding that DSL snippet to Jackpot will transform all Component.show() calls to Component.setVisible(true). Very, very cool stuff. Of course, you don't always want to make the transformation, but in the cases where you do, Jackpot looks like a great solution.
As the lead guy on a "competing" static analysis framework - PMD - I can say that FindBugs is definitely a great piece of work. It catches all sorts of complicated problems with concurrency, does forwards/backwards data flow analysis, etc, etc. It's pretty sweet. Dr Pugh, who runs the project at the University of Maryland, did a JavaPosse interview that's some more good info on the project and where it's going.
Of course, if you really want to do source code analysis (vs bytecode analysis, which is what FindBugs does), then go for PMD, and [plug] get the book! [/plug]
Slashdot Mirror
If you've got a reasonably recent JVM installed you can run CPD via Java Web Start here.
There are some examples of CPD output there too - like the duplicate code chunks that it found in the JDK source code and in the Apache httpd source code.
For much more on CPD, see chapter 5!
> Having said that I really don't see why you
> have to devote a complete book on regex.
> A small tutorial does just fine
I think it depends on how deep you want to go into regular expressions. Mastering Regular Expressions by Jeffrey Friedl is almost 500 pages but is an excellent treatment of the subject - by the time you're done reading it you'll feel comfy even with such madness as negative lookbehind.
> Even with dynamic content you can usually cache for a few seconds without serving stale responses
That's an excellent point... I was thinking about the front page of RubyForge, and caching that for 30 seconds or so shouldn't inconvenience anyone. Maybe I'll give that a whirl. Thanks for posting!
This was mentioned in Rich Bowen's excellent lightning talk and is listed as "experimental" in the Apache 2.0 docs but as an "extension" in the Apache 2.2 docs. Anyone have experience with this? Seems very tweakable...
Many thanks indeed! I was happy to see that the folks at Virginia Tech (Dr Edwards, specifically) are doing the same thing as part of their WebCat automated grading gizmo; more on all that here.
> Your plug-fu is strong, master, you must teach me.
:-)
Practice, young Jedi, practice
> [...] sales "closely track Billboard."
Right, but isn't that the point of the long tail? If Dan Brown sells a bazillion copies of "Da Vinci Code" and I sell 500 copies of PMD Applied, we're both happy since we're meeting the expectations that we budgeted for. Of course, he's then a billionaire, whereas I've still got my office in the laundry room, but, er, anyhow.
...in 37 signals (the guys who made Ruby on Rails), I wouldn't be suprised to see some more RoR happening there as some commenters here have suggested. Good times...
> A podcast is not worth listening to, ever. By definition.
Can't argue with that line of reasoning!
The JavaPosse had some notes on this a while back and they seem to keep an eye on the issue. That podcast definitely worth listening to once or twice a week to keep up with the latest news.
> a few hundred copies per year.
Exactly right. I expect my JavaCC book to sell about that - maybe - each year. But since it's published by a small outfit, that's OK. We'll sell ~60 copies, break even, and consider the rest gravy.
> like Og.
Nice! Don't hear too much about Og or Nitro, although some of the folks on the Ruby list are big fans. Definitely nice to have choices out there...
> Sorry, my opinion is that introspecting the DB (or any
:-). Well, anyhow, best of luck!
> persistence mechanism) at run time is a seriously bad idea, for many reasons.
Ah, well, in that case, you're definitely unlikely to be happy with AR
> You should be able to persist the same data model
> to web services, databases, XML and so on
If you need that functionality, yes. If you only need to write to/from a specific persistence mechanism, then using a good solution for that persistence layer may be a good way to go.
> This is why most ORMs have a separate mapping layer, which protects against this.
I'd submit that many web apps don't need really this layer and that, in many cases, introspecting the DB like AR does is plenty good enough.
Anyhow, not to thrash this out too much, just wanted to make the point that AR adaptors can be written for something other than a relational DB.
> It assumes that the database schema is the centre of the data model.
Hm, although, the folks from salesforce.com wrote a ActiveRecord adaptor to their web services. So AR may be a bit more flexible than your post indicates...
> As our once-proud cities burn into molten pools of blood and steel [...]
Lyrically put sir, well done indeed!
> i went to purchase a rails book the other day and gave this
> book and the book "Agile Web Developent with Rais" and found
> the agile development book to be better, imho. and $10 cheaper.
I think they serve different needs. Get the Agile book to learn how to build a Rails app, and then get Dr. Black's book to learn how Rails works under the covers.
> It's about the right time for a RoR book, since
> things have been moving so much of late,
Yup, and this book will last for a while since it focuses on how Rails uses Ruby to do the metaprogramming "magic". So if the APIs move on slightly the techniques in Dr. Black's book still apply.
For those who aren't on the Ruby lists, Dr. Black is a long-time Ruby user, a founder of the 501(c)(3) Ruby Central that organizes the Ruby conferences, and generally a Rubyist from way back. He's rather a guru but he still answers questions on the mailing lists and generally does a lot of grunt work.
> you can create AJAX-based Web applications very easily with RoR
Right on. Ditto with RJS - we're using them on the indi site (click the comments section to see it in action) and they work nicely. A very little bit of Ruby code gets you the Javascript functionality you want. And Rails' architecture seems to make that sort of thing easy to add.
I was kind of suprised to see the recommendation for formal code reviews. In my experience those end up either as "hurt feelings" slugfests or, just as ineffectively, full of "you should put a space after this brace" comments. I feel that pair programming is more effective way of getting multiple eyes on the code, spreading knowledge around, training the new guys, and all that good stuff.
And of course there's always static analysis to catch any problems that do manage to sneak in there...
Less clicking.
...that seems to be up and coming in the Ruby world is RJS templates. We're using them for the new indi site and they seem pretty handy. The Javascript to Ruby translation is not perfect, of course, but they make some AJAX-ish things nicer: page.visual_effect :highlight, 'sidebar_heading', :duration =>3.
If you're in the northern Virginia area you might be interested in the next NovaRUG meeting; there'll be a presentation on RJS there. Good times...
> sourceforge.net, freshmeat.net, tinyapps.org, packetstormsecurity.org
Yup, and rubyforge and LuaForge as well. One hard part is sorting out duplicates... getting a list of the actual projects shouldn't be too hard since most project aggregation sites have RSS feeds with that info.
...is Sun's Jackpot, headed up by Tom Ball. What's neat about Jackpot is that it does problem fixing, too, using a domain specific language. From the interview:
::
$object.show() => $object.setVisible(true)
$object instanceof java.awt.Component;
Feeding that DSL snippet to Jackpot will transform all Component.show() calls to Component.setVisible(true). Very, very cool stuff. Of course, you don't always want to make the transformation, but in the cases where you do, Jackpot looks like a great solution.
As the lead guy on a "competing" static analysis framework - PMD - I can say that FindBugs is definitely a great piece of work. It catches all sorts of complicated problems with concurrency, does forwards/backwards data flow analysis, etc, etc. It's pretty sweet. Dr Pugh, who runs the project at the University of Maryland, did a JavaPosse interview that's some more good info on the project and where it's going.
Of course, if you really want to do source code analysis (vs bytecode analysis, which is what FindBugs does), then go for PMD, and [plug] get the book! [/plug]