Comments for doylecentral.com http://blog.doylecentral.com Doyle Blog Thu, 09 Sep 2010 07:57:27 +0000 http://wordpress.org/?v=2.5 Comment on Grails Scaffolding as a <DL> Table by Matt Dertinger http://blog.doylecentral.com/?p=32#comment-29309 Matt Dertinger Mon, 20 Apr 2009 22:19:53 +0000 http://blog.doylecentral.com/?p=32#comment-29309 For custom scaffolding templates you can run 'grails import-templates' from your project's base directory. The view templates will be located in src/templates/scaffolding/ within you project's base directory. Once that's done, you can modify away without changing the default Grails templates. More info can be found on the Grails site: <a href="http://www.grails.org/Scaffolding" rel="nofollow">http://www.grails.org/Scaffolding</a> For custom scaffolding templates you can run ‘grails import-templates’ from your project’s base directory. The view templates will be located in src/templates/scaffolding/ within you project’s base directory. Once that’s done, you can modify away without changing the default Grails templates.

More info can be found on the Grails site: http://www.grails.org/Scaffolding

]]> Comment on Incremental code review (ICR) by Ron R http://blog.doylecentral.com/?p=26#comment-29245 Ron R Sat, 18 Apr 2009 04:40:05 +0000 http://blog.doylecentral.com/?p=26#comment-29245 Review of the code is important. But yeah, I think it's more important to get the business people involved. I mean, I worked on teams where the developers have great communication with each other but form a cabal and pretty well tell the business people to buzz off until the project is finished. And then they worked on stuff that they think is important but not what is important to the business people, who may have a better idea of what the customer wants. Hey, I'm just saying... Review of the code is important. But yeah, I think it’s more important to get the business people involved. I mean, I worked on teams where the developers have great communication with each other but form a cabal and pretty well tell the business people to buzz off until the project is finished. And then they worked on stuff that they think is important but not what is important to the business people, who may have a better idea of what the customer wants.
Hey, I’m just saying…

]]> Comment on Incremental code review (ICR) by PJ http://blog.doylecentral.com/?p=26#comment-26168 PJ Thu, 22 Jan 2009 15:39:09 +0000 http://blog.doylecentral.com/?p=26#comment-26168 IMO you need business people involved because they're often the ones who define the product - they're closer to the customer than the devs are, so they know better what the customer will like/dislike about the way a particular feature works or is implemented. IMO you need business people involved because they’re often the ones who define the product - they’re closer to the customer than the devs are, so they know better what the customer will like/dislike about the way a particular feature works or is implemented.

]]> Comment on Incremental code review (ICR) by Paul Batum http://blog.doylecentral.com/?p=26#comment-7695 Paul Batum Mon, 11 Feb 2008 21:29:07 +0000 http://blog.doylecentral.com/?p=26#comment-7695 I don't understand your final point. My personal experience has been that incremental code reviews are valuable and worthwhile without any business involvement. Care to elaborate further? I don’t understand your final point. My personal experience has been that incremental code reviews are valuable and worthwhile without any business involvement. Care to elaborate further?

]]> Comment on Incremental code review (ICR) by David http://blog.doylecentral.com/?p=26#comment-7693 David Mon, 11 Feb 2008 20:56:50 +0000 http://blog.doylecentral.com/?p=26#comment-7693 What I've found useful in the past is to have ad-hoc code reviews more often than that. We came about it accidentally the first time. We created a build system for our CVS repo and had it build whenever the repo was quiesced for 15 minutes (to give time to check in multiple files, fix merge conflicts, etc). Originally we sent mail only when the build broke, pointing to the most likely suspect in an effort to gently humiliate them and goad them to fix it. But one day someone suggested we also send emails for successful builds. Eventually we started diffing between builds and sending the entire patch as well as all the check-in comments as an email to the entire group. These patch emails allowed incremental and continuous code reviews and let everyone on the project keep track of what everyone around them was doing. The emails got sent from the group so that you just replied to the patch and everyone got your comments. Generally we'd keep all critiques and praises public so that everyone could see the discussion--if they weren't interested, they could just skip the email. We also made the email list very inclusive. We had all the hardware guys on our software list, for instance. When I asked them if all that extra email was annoying they all said, "No! We love seeing what you guys are doing." It was so successful that I've made sure to re-implement this for every project I've since worked on. What I’ve found useful in the past is to have ad-hoc code reviews more often than that. We came about it accidentally the first time. We created a build system for our CVS repo and had it build whenever the repo was quiesced for 15 minutes (to give time to check in multiple files, fix merge conflicts, etc). Originally we sent mail only when the build broke, pointing to the most likely suspect in an effort to gently humiliate them and goad them to fix it. But one day someone suggested we also send emails for successful builds. Eventually we started diffing between builds and sending the entire patch as well as all the check-in comments as an email to the entire group.

These patch emails allowed incremental and continuous code reviews and let everyone on the project keep track of what everyone around them was doing. The emails got sent from the group so that you just replied to the patch and everyone got your comments. Generally we’d keep all critiques and praises public so that everyone could see the discussion–if they weren’t interested, they could just skip the email. We also made the email list very inclusive. We had all the hardware guys on our software list, for instance. When I asked them if all that extra email was annoying they all said, “No! We love seeing what you guys are doing.”

It was so successful that I’ve made sure to re-implement this for every project I’ve since worked on.

]]> Comment on Incremental code review (ICR) by Paul Davis http://blog.doylecentral.com/?p=26#comment-7684 Paul Davis Mon, 11 Feb 2008 16:43:43 +0000 http://blog.doylecentral.com/?p=26#comment-7684 I've always said, if you wait until finished to review the code, it's too late. QA doesn't want changes to anything at that point and the business owners don't want to take the risk of changing something that works. Now, to get QA involved at the beginning for incremental testing.... I’ve always said, if you wait until finished to review the code, it’s too late.

QA doesn’t want changes to anything at that point and the business owners don’t want to take the risk of changing something that works.

Now, to get QA involved at the beginning for incremental testing….

]]> Comment on It’s over for the home button … Browser Consolidation by Paul http://blog.doylecentral.com/?p=21#comment-5379 Paul Tue, 11 Dec 2007 18:34:20 +0000 http://blog.doylecentral.com/?p=21#comment-5379 lol, just got me thinking. I could kill the home (alt-home), forward (alt-right arrow), stop (esc), and reload (F5) buttons. The only reason for the back button is to skip back multiple pages. I've never really thought about how I never use those. lol, just got me thinking. I could kill the home (alt-home), forward (alt-right arrow), stop (esc), and reload (F5) buttons.

The only reason for the back button is to skip back multiple pages.

I’ve never really thought about how I never use those.

]]> Comment on Feisty Fawn and the extrernal USB Drive by bendyboy http://blog.doylecentral.com/?p=12#comment-3797 bendyboy Tue, 30 Oct 2007 22:24:43 +0000 http://blog.doylecentral.com/?p=12#comment-3797 I had this error using my u3 usb thumb drive. deleted key, plugged back in, it worked. I had been getting the quoted error. Ill need to remember this in case it comes back... thank you. I had this error using my u3 usb thumb drive.
deleted key, plugged back in, it worked.
I had been getting the quoted error.
Ill need to remember this in case it comes back…
thank you.

]]> Comment on Setting up a xul development environment with MyEclipseIde by Ashot http://blog.doylecentral.com/?p=7#comment-3778 Ashot Tue, 30 Oct 2007 08:20:23 +0000 http://blog.doylecentral.com/?p=7#comment-3778 DTD's are old fashioned! Use XSD (XML Schema) files. The following is a pretty complete XUL development tool. xulbooster.org DTD’s are old fashioned! Use XSD (XML Schema) files. The following is a pretty complete XUL development tool. xulbooster.org

]]> Comment on Feisty Fawn and the extrernal USB Drive by doyle http://blog.doylecentral.com/?p=12#comment-2541 doyle Fri, 14 Sep 2007 18:15:52 +0000 http://blog.doylecentral.com/?p=12#comment-2541 Yes ... You can check out ntfs-3g. Do a quick search and you will find the info. Yes … You can check out ntfs-3g. Do a quick search and you will find the info.

]]>