Comments for lesscode.org http://lesscode.org AAaaaaahhhhrrrrrrr! Mon, 17 Sep 2007 09:52:03 +0000 http://wordpress.org/?v=2.0.1 Comment on Control-Space by Anonymous http://lesscode.org/2005/08/29/control-space/#comment-50839 Wed, 04 Jul 2007 03:39:38 +0000 http://lesscode.org/2005/08/29/control-space/#comment-50839 <p>I think there is no issue with option of using ctrl space in fact it reduces lot of coding time by thinking or refering the docs.If you feel like you are unable to remember the code because of this , you have to find other way of remembering it.</p> <p>“ITS LIKE BLAMING THE VEHICLE FOR YOU ARE NOT READY TO WALK TO REACH THERE”</p> I think there is no issue with option of using ctrl space in fact it reduces lot of coding time by thinking or refering the docs.If you feel like you are unable to remember the code because of this , you have to find other way of remembering it.

“ITS LIKE BLAMING THE VEHICLE FOR YOU ARE NOT READY TO WALK TO REACH THERE”

]]> Comment on Design Patterns as a statement of failure by Pianelli http://lesscode.org/2006/10/01/design-patterns-as-a-statement-of-failure/#comment-37879 Thu, 05 Apr 2007 22:03:10 +0000 http://lesscode.org/2006/10/01/design-patterns-as-a-statement-of-failure/#comment-37879 <p>I´m using Design Patterns in all on my projects written in PHP5. And I think you get your code more flexible than without design patterns.</p> I´m using Design Patterns in all on my projects written in PHP5. And I think you get your code more flexible than without design patterns.

]]> Comment on about lesscode.org by James Governor’s Monkchips » On Software Requirements: Just say No… agile is simple http://lesscode.org/about/#comment-24035 Fri, 26 Jan 2007 11:57:33 +0000 http://lesscode.org/about/#comment-24035 <p>[...] You see, lesscode isn&#8217;t just a function of the language you choose to develop in, ie less code to get more work done,  but also how many features you choose to implement in the first place. This is perhaps the key problem with so much Waterfall development- it ends up including every feature that might be needed, rather than focusing on what needs to be done to solve a specific part of a problem at hand. With Agile, on the other hand, features are built with some isolation. Agile development can potentially say no more easily, because there are fewer interdependencies between all the features as specced. Perhaps we should add this sniff test to the smell of agile - you can tell an organisation is agile when development teams can reject feature requests. [...]</p> […] You see, lesscode isn’t just a function of the language you choose to develop in, ie less code to get more work done,  but also how many features you choose to implement in the first place. This is perhaps the key problem with so much Waterfall development- it ends up including every feature that might be needed, rather than focusing on what needs to be done to solve a specific part of a problem at hand. With Agile, on the other hand, features are built with some isolation. Agile development can potentially say no more easily, because there are fewer interdependencies between all the features as specced. Perhaps we should add this sniff test to the smell of agile - you can tell an organisation is agile when development teams can reject feature requests. […]

]]> Comment on about lesscode.org by James Governor’s Monkchips » Don Ferguson Joins Microsoft. 5 things you didn’t know http://lesscode.org/about/#comment-23144 Tue, 16 Jan 2007 16:47:18 +0000 http://lesscode.org/about/#comment-23144 <p>[...] Don was a seriously heavy hitter at IBM. He has taken lumps from people in the past, including me, but some of those barbs were undoubtedly unfair. After all when you&#8217;re at the very apex of the IBM Software Group tree its kind of hard to take a hardcore lesscode approach. [...]</p> […] Don was a seriously heavy hitter at IBM. He has taken lumps from people in the past, including me, but some of those barbs were undoubtedly unfair. After all when you’re at the very apex of the IBM Software Group tree its kind of hard to take a hardcore lesscode approach. […]

]]> Comment on Unnecessary Until Proven Required by Motherhood and Apple Pie http://lesscode.org/2005/07/10/unnecessary-until-proven-required/#comment-22815 Fri, 12 Jan 2007 02:31:57 +0000 http://lesscode.org/2005/07/10/unnecessary-until-proven-required/#comment-22815 <p>[...] So I would like to impress upon you that the languages that dominate the web are not the way they are because we lack the ability to build more complex, sophisticated, flashy tools and languages, they are that way because we assume extra complexity is unnecessary until proven required and we see very little evidence to support the inclusion of the complexities that have been introduced into &#8220;enterprise class&#8221; software over the past decade. [...]</p> […] So I would like to impress upon you that the languages that dominate the web are not the way they are because we lack the ability to build more complex, sophisticated, flashy tools and languages, they are that way because we assume extra complexity is unnecessary until proven required and we see very little evidence to support the inclusion of the complexities that have been introduced into “enterprise class” software over the past decade. […]

]]> Comment on REST wins, noone goes home by S. Potter http://lesscode.org/2006/03/19/rest-wins-noone-goes-home/#comment-22184 Sat, 06 Jan 2007 00:18:46 +0000 http://lesscode.org/2006/03/19/rest-wins-noone-goes-home/#comment-22184 <p>As a former Java head turned Ruby evangelist I have to promote Ruby on Rails' latest offering of <em>ActiveResource</em>, which is a forth coming component of the <em>Ruby on Rails</em> stack. The production version of Rails (1.1) already has ReSTian support for API and web producers. However, ActiveResource will take ReSTian support one step further for REST consumers in addition to producers when the stable version is released shortly under Rails 1.2. A Ruby on Rails plugin already exists for ReSTful authentication based on HTTP Basic (authentication under REST is very unfortunate, but the plugin author isn't to blame for the history of HTTP Authentication).</p> <p>I hope to add a blog entry later this weekend on my experiences with ReSTian Rails at <a href="http://snakesgemscoffee.blogspot.com" title="Ruby, Ruby on Rails vs. Java agile open source programming blog" rel=""><strong>Snakes, Gems &#38; Coffee</strong></a>.</p> As a former Java head turned Ruby evangelist I have to promote Ruby on Rails’ latest offering of ActiveResource, which is a forth coming component of the Ruby on Rails stack. The production version of Rails (1.1) already has ReSTian support for API and web producers. However, ActiveResource will take ReSTian support one step further for REST consumers in addition to producers when the stable version is released shortly under Rails 1.2. A Ruby on Rails plugin already exists for ReSTful authentication based on HTTP Basic (authentication under REST is very unfortunate, but the plugin author isn’t to blame for the history of HTTP Authentication).

I hope to add a blog entry later this weekend on my experiences with ReSTian Rails at Snakes, Gems & Coffee.

]]> Comment on Disposable Software by Seezar Honibe http://lesscode.org/2005/08/16/disposable-software/#comment-20839 Tue, 19 Dec 2006 14:24:16 +0000 http://lesscode.org/2005/08/16/disposable-software/#comment-20839 <p>Lets see if I got this right: </p> <ol> <li><p>Less is more Seems we all agree reuse is fiction. Reuse bloats the code and increases the chance for implementation and production errors. Don't solve for an undefined problem - you cannot. Presentation correlation: If the business presentation were to address a different issue than for what it was created the presentation would confuse the audience. </p></li> <li><p>Consumers create As defined disposable software requires domain expertise. Focus on the problem to solve than being a tools expert. Most hardware products are all disposable and in some cases the factory that creates the specific hardware is also disposable. Here lies the rub; most consumers of the 'software' are still not able to create their own applicatons. Presentation correlation: If I as the presenter need to deliver a board meeting, I would create my own presentation; not my assistant; not the IT guy. In fact what I lack in bling is made up for in focused content. </p></li> <li><p>Half-life matters ( http://en.wikipedia.org/wiki/Halflife ) Knowing how long your application lasts determines how much effort you invest and I submit this defines disposability. Know that production support, network performance and interoperability as is lifetime usage are part of the specific requirements. But don't code for more than you know. Presentation correlation: My presentations, created with PowerPoint, have a halflife of 7 days after which the information is out of date; the problem has been solved. However Microsoft PowerPoint is not at the same level of disposability as the presentation created with PP. That means software (C#) does not create disposability but specific application factories (PowerPoint) create disposable products (mypresentation.ppt). </p> <ul><li>did we not try and get here with 4GLs ;-)</li></ul></li> <li><p>One size does not fit all What is being said about disposable applications is solve a specific problem and not all applications are solved in the sameway. The lifetime of the application may require different tools and different approaches. Ruby on Rails solves a specific class of problem and that is what makes RoR such a powerful factory. (DSL's extend this metaphor) Presentation correlation: At some point I have to put aside PowerPoint and decided that a short video clip (also disposable) is the better presentation to get re-elected. </p></li> <li><p>Use common sense In the business world we constantly make value based decisions as to effort and result. As long as you know the lifetime value of your product you can match the implementation and maintenance effort appropriately. Presentation correlation: This is where I say maybe a verbal conversation or a blog entry is best and I throw away Microsoft PowerPoint and get back to doing real work, like walking my dog ;-)</p></li> </ol> Lets see if I got this right:

  1. Less is more
    Seems we all agree reuse is fiction. Reuse bloats the code and increases the chance for implementation and production errors. Don’t solve for an undefined problem - you cannot.
    Presentation correlation: If the business presentation were to address a different issue than for what it was created the presentation would confuse the audience.

  2. Consumers create
    As defined disposable software requires domain expertise. Focus on the problem to solve than being a tools expert. Most hardware products are all disposable and in some cases the factory that creates the specific hardware is also disposable. Here lies the rub; most consumers of the ’software’ are still not able to create their own applicatons.
    Presentation correlation: If I as the presenter need to deliver a board meeting, I would create my own presentation; not my assistant; not the IT guy. In fact what I lack in bling is made up for in focused content.

  3. Half-life matters ( http://en.wikipedia.org/wiki/Halflife )
    Knowing how long your application lasts determines how much effort you invest and I submit this defines disposability. Know that production support, network performance and interoperability as is lifetime usage are part of the specific requirements. But don’t code for more than you know.
    Presentation correlation: My presentations, created with PowerPoint, have a halflife of 7 days after which the information is out of date; the problem has been solved. However Microsoft PowerPoint is not at the same level of disposability as the presentation created with PP. That means software (C#) does not create disposability but specific application factories (PowerPoint) create disposable products (mypresentation.ppt).

    • did we not try and get here with 4GLs ;-)

  4. One size does not fit all
    What is being said about disposable applications is solve a specific problem and not all applications are solved in the sameway. The lifetime of the application may require different tools and different approaches. Ruby on Rails solves a specific class of problem and that is what makes RoR such a powerful factory. (DSL’s extend this metaphor)
    Presentation correlation: At some point I have to put aside PowerPoint and decided that a short video clip (also disposable) is the better presentation to get re-elected.

  5. Use common sense
    In the business world we constantly make value based decisions as to effort and result. As long as you know the lifetime value of your product you can match the implementation and maintenance effort appropriately.
    Presentation correlation: This is where I say maybe a verbal conversation or a blog entry is best and I throw away Microsoft PowerPoint and get back to doing real work, like walking my dog ;-)

]]> Comment on Motherhood and Apple Pie by Un peu de lecture 02 at Aurélien Pelletier’s Weblog http://lesscode.org/2005/07/21/motherhood-and-apple-pie/#comment-20737 Sun, 17 Dec 2006 22:50:56 +0000 http://lesscode.org/2005/07/21/motherhood-and-apple-pie/#comment-20737 <p>[...] Motherhood and Apple Pie ou the design principles that underlie the web. [...]</p> […] Motherhood and Apple Pie ou the design principles that underlie the web. […]

]]> Comment on REST wins, noone goes home by tndal http://lesscode.org/2006/03/19/rest-wins-noone-goes-home/#comment-20724 Sun, 17 Dec 2006 18:35:05 +0000 http://lesscode.org/2006/03/19/rest-wins-noone-goes-home/#comment-20724 <p>Ben Davies asks: "Say, for example, I GET an image from a REST service. I want to rotate that image by 90 degrees and then PUT it back. The Rotating part cannot be accomidated by REST? Is that correct? Is the PUT transfering the modified Resource, or am I passing a series of actions to be performed upon that Resource? Do I GET the image, rotate the image on the client, then PUT the image back? Or do I PUT a series of transformations to be performed on that resource?"</p> <p>You could do a GET of the image resource followed by a PUT of the updated image resource, as you describe. </p> <p>Or you could define a separate associated resource for the image orientation and do a GET and PUT of that orientation resource.</p> Ben Davies asks:
“Say, for example, I GET an image from a REST service. I want to rotate that image by 90 degrees and then PUT it back. The Rotating part cannot be accomidated by REST? Is that correct? Is the PUT transfering the modified Resource, or am I passing a series of actions to be performed upon that Resource? Do I GET the image, rotate the image on the client, then PUT the image back? Or do I PUT a series of transformations to be performed on that resource?”

You could do a GET of the image resource followed by a PUT of the updated image resource, as you describe.

Or you could define a separate associated resource for the image orientation and do a GET and PUT of that orientation resource.

]]> Comment on Simplest Possible Plugin Manager For Rails by Walker http://lesscode.org/2005/10/27/rails-simplest-plugin-manager/#comment-20307 Tue, 12 Dec 2006 21:07:40 +0000 http://lesscode.org/2005/10/27/rails-simplest-plugin-manager/#comment-20307 <p>What I want to do on my blog, is every few hours take the oldest post and move it to the front of the queue, all automatically. Anyone know if there is a plugin that can do this or a simple way to set up another plugin to do this (use my own feed perhaps)? Thanks.</p> What I want to do on my blog, is every few hours take the oldest post and move it to the
front of the queue, all automatically. Anyone know if there is a plugin that can do this or
a simple way to set up another plugin to do this (use my own feed perhaps)?
Thanks.

]]>