Comment Dividing by Palin's Experience is Undefined... (Score 1) 1813
...it's too close to zero.
Submission + - Refactoring: Improving the Design of Existing Code
kabz writes: "Refactoring: Improving the Design of Existing Code
Martin Fowler with Kent Beck, John Brant, William Opdyke and Don Roberts.
In the Addison-Wesley Object Technology Series.
Refactoring (as I'll refer to the book from here on in) is a heavy and beautifully produced 418 page hardback book. Martin Fowler is a UK-based independent consultant who has worked on many large systems and is the author of several other books including UML-Distilled.
Refactoring is a self-help book in the tradition of Code Complete by Steve McConnell. It defines its audience clearly as working programmers and provides a set of problems, a practical and easily followed set of remedies and a rationale for applying those techniques.
Code refactoring is the process of restructuringing code in a controlled way to improve the structure and clarity of code, whilst maintaining the meaning of the code being restructured. Many maintenance problems stem from poorly written code that has become overly complex, where objects are overly familiar with each other, and where solutions implemented expeditiously contribute to the software being hard to understand and hard to add features to.
Typically refactorings are applied over a testable or local scope, with existing behavior being preserved. Refactoring as defined in this book is not about fixing bad designs, but instead should be applied at lower levels.
Testing a la Extreme Programming is emphasized as a control for ensuring that program meaning is not changed by refactoring. It is not over emphasized, and this is not a book about testing, but it is often mentioned and stays in the background through the book.
The refactorings presented in the book are not intended as a comprehensive solution for all problems, but they do offer a means to regain control of software that has been implemented poorly, or where maintenance has been shown to simply replace old bugs with newer ones.
The book is divided into two main sections, introductory material that introduces and discusses refactorings, and a lengthy taxonomy of refactorings that includes both examples and further discussion. The introductory material consists of a long worked example through simple Java code that implements printing a statement for a video store. Despite the simplicity of the code, Fowler shows in clear detail where improvements can be made, and how those improvements make the code both impressively easy to understand, and easy to maintain and add features.
Several key refactorings are demonstrated in the opening chapter including Extract Method, Move Method and Replace Conditional with Polymorphism. This is a book about programming in the object oriented paradigm, so as you might expect, the first two refactorings refer to extracting and moving object methods either into new methods, or between objects. The third example provides a means to replace special cased behavior in a single object type by deriving a sub type of the object and moving type specific code to the sub types. This is a fundamental technique in object oriented programming, and is discussed here in practical terms.
Now that several actual refactorings have been introduced, Fowler provides a solid and well thought-out discussion of the why's, when's and when not's of refactoring. For example, code can decay as features are added, and programmers special-case, or bodge additional functionality into existing objects. Fowler argues that the bitrot and decay makes software more unreliable, leads to bugs and can accelarate as the problem gets worse. Faced with these problems, refactoring should be used to improve local design and clean up and improve code, leading to better software, that is easier to maintain, easier to debug, and easier to improve with new features as requirements change.
However, there is a caveat, in that since software functionality should remain unchanged during refactoring, the process of refactoring consumes resources, but provides no easily measureable value. Fowler confronts this issue in a section that discusses how to communicate with managers, that you are performing refactoring work. He denies being subversive, but his conclusion is that refactoring should essentially be folded in with normal work as it improves the overall result.
This is a bit like goofing off on the basis that you'll think better after 20 minutes of fooseball. I'd definitely subscribe to that theory, but many others may not.
Kent Beck guests in Chapter Three for a review of the issues in typical software that suggest a refactoring may be needed. This chapter is entitled Bad Smells in Code, and most of the smells presented will be familiar to any reasonably experienced programmer, and they will be a great learning experience for less experienced programmers. I got the same feeling reading this chapter as I did when I first read Code Complete. Here was someone writing down names and describing problems that I had a vague unease about, but was too inexperienced to really articulate or do something about. Typically the refactorings address the same kind of issues that a code review with a skilled experienced programmer would address. Long parameter lists, too long methods, objects delving about in each others private variables, case statements, related code spread across different objects etc. None of these problems are debiliting in themselves, but added up, they lead to software that can be prone to error and difficult to maintain.
Most of the remaining substance of the book, 209 pages, is given over to a taxonomy of refactorings. These 72 refactorings are covered in detail with comprehensive simple examples presented in Java. Each refactorings is given a clear name, a number and a line or two of descriptive text. The motivation for the refactoring is then discussed, often including caveats and cautions. The mechanics of implementing the refactoring are then listed, with 1 or more (and often more) examples of implementing the refactoring. Refactorings range from the very simple to more complex examples such as Convert Procedural Design to Objects.
Due to the difficulties of reproducing large and complex sections of code, Fowler sticks with relatively simple examples. These seem to grate on him more than the reader, and he can come across as somewhat embarrassed when we look at the employee, programmer, manager pay example for the tenth time. I certainly didn't have a problem with it though.
Conclusion
This is a very well written and fun to read book. I personally feel that much of the material is implied by from Code Complete, but Fowler does a fantastic job of expanding and formalizing the idea of applying explicit refactorings. Much like Code Complete gave a motivation for keeping code well commented and laid out, this book presents the case for care and feeding of how to structure software. To fight bitrot and technical debt, poorly structured and unclear code should be targetted and refactored to improve structure and clarity. This gives a very real payback in terms of less required maintenance, and ease in adding features later on down the line.
Despite the fact that all the examples are in Java, the ideas are easily transferable to C++ or any procedural object oriented language.
Highly recommended."
Martin Fowler with Kent Beck, John Brant, William Opdyke and Don Roberts.
In the Addison-Wesley Object Technology Series.
Refactoring (as I'll refer to the book from here on in) is a heavy and beautifully produced 418 page hardback book. Martin Fowler is a UK-based independent consultant who has worked on many large systems and is the author of several other books including UML-Distilled.
Refactoring is a self-help book in the tradition of Code Complete by Steve McConnell. It defines its audience clearly as working programmers and provides a set of problems, a practical and easily followed set of remedies and a rationale for applying those techniques.
Code refactoring is the process of restructuringing code in a controlled way to improve the structure and clarity of code, whilst maintaining the meaning of the code being restructured. Many maintenance problems stem from poorly written code that has become overly complex, where objects are overly familiar with each other, and where solutions implemented expeditiously contribute to the software being hard to understand and hard to add features to.
Typically refactorings are applied over a testable or local scope, with existing behavior being preserved. Refactoring as defined in this book is not about fixing bad designs, but instead should be applied at lower levels.
Testing a la Extreme Programming is emphasized as a control for ensuring that program meaning is not changed by refactoring. It is not over emphasized, and this is not a book about testing, but it is often mentioned and stays in the background through the book.
The refactorings presented in the book are not intended as a comprehensive solution for all problems, but they do offer a means to regain control of software that has been implemented poorly, or where maintenance has been shown to simply replace old bugs with newer ones.
The book is divided into two main sections, introductory material that introduces and discusses refactorings, and a lengthy taxonomy of refactorings that includes both examples and further discussion. The introductory material consists of a long worked example through simple Java code that implements printing a statement for a video store. Despite the simplicity of the code, Fowler shows in clear detail where improvements can be made, and how those improvements make the code both impressively easy to understand, and easy to maintain and add features.
Several key refactorings are demonstrated in the opening chapter including Extract Method, Move Method and Replace Conditional with Polymorphism. This is a book about programming in the object oriented paradigm, so as you might expect, the first two refactorings refer to extracting and moving object methods either into new methods, or between objects. The third example provides a means to replace special cased behavior in a single object type by deriving a sub type of the object and moving type specific code to the sub types. This is a fundamental technique in object oriented programming, and is discussed here in practical terms.
Now that several actual refactorings have been introduced, Fowler provides a solid and well thought-out discussion of the why's, when's and when not's of refactoring. For example, code can decay as features are added, and programmers special-case, or bodge additional functionality into existing objects. Fowler argues that the bitrot and decay makes software more unreliable, leads to bugs and can accelarate as the problem gets worse. Faced with these problems, refactoring should be used to improve local design and clean up and improve code, leading to better software, that is easier to maintain, easier to debug, and easier to improve with new features as requirements change.
However, there is a caveat, in that since software functionality should remain unchanged during refactoring, the process of refactoring consumes resources, but provides no easily measureable value. Fowler confronts this issue in a section that discusses how to communicate with managers, that you are performing refactoring work. He denies being subversive, but his conclusion is that refactoring should essentially be folded in with normal work as it improves the overall result.
This is a bit like goofing off on the basis that you'll think better after 20 minutes of fooseball. I'd definitely subscribe to that theory, but many others may not.
Kent Beck guests in Chapter Three for a review of the issues in typical software that suggest a refactoring may be needed. This chapter is entitled Bad Smells in Code, and most of the smells presented will be familiar to any reasonably experienced programmer, and they will be a great learning experience for less experienced programmers. I got the same feeling reading this chapter as I did when I first read Code Complete. Here was someone writing down names and describing problems that I had a vague unease about, but was too inexperienced to really articulate or do something about. Typically the refactorings address the same kind of issues that a code review with a skilled experienced programmer would address. Long parameter lists, too long methods, objects delving about in each others private variables, case statements, related code spread across different objects etc. None of these problems are debiliting in themselves, but added up, they lead to software that can be prone to error and difficult to maintain.
Most of the remaining substance of the book, 209 pages, is given over to a taxonomy of refactorings. These 72 refactorings are covered in detail with comprehensive simple examples presented in Java. Each refactorings is given a clear name, a number and a line or two of descriptive text. The motivation for the refactoring is then discussed, often including caveats and cautions. The mechanics of implementing the refactoring are then listed, with 1 or more (and often more) examples of implementing the refactoring. Refactorings range from the very simple to more complex examples such as Convert Procedural Design to Objects.
Due to the difficulties of reproducing large and complex sections of code, Fowler sticks with relatively simple examples. These seem to grate on him more than the reader, and he can come across as somewhat embarrassed when we look at the employee, programmer, manager pay example for the tenth time. I certainly didn't have a problem with it though.
Conclusion
This is a very well written and fun to read book. I personally feel that much of the material is implied by from Code Complete, but Fowler does a fantastic job of expanding and formalizing the idea of applying explicit refactorings. Much like Code Complete gave a motivation for keeping code well commented and laid out, this book presents the case for care and feeding of how to structure software. To fight bitrot and technical debt, poorly structured and unclear code should be targetted and refactored to improve structure and clarity. This gives a very real payback in terms of less required maintenance, and ease in adding features later on down the line.
Despite the fact that all the examples are in Java, the ideas are easily transferable to C++ or any procedural object oriented language.
Highly recommended."
Submission + - The Future of AJAX and the Rich Web Dscusssed (ajaxworldmagazine.com)
jg21 writes: This AJAXWorld Magazine article indicates how far AJAX has come since devs complained here that it sucked all the time. Eight experts were asked what questions we should now all be asking, with 2008 just around the corner, about where AJAX is headed next. The suggested questions are refreshingly hard-headed, including: "How are we to fix the web?" (Douglas Crockford, JSON inventor), "When will AJAX development finally be easy?" (Google's Christian Schalk), and "Do we really need JavaScript 2.0? Won't it be somewhat irrelevant by the time it becomes commonplace and thus usable?" (Josh Gertzen, lead developer of the ThinWire AJAX Framework). One of the most interesting questions came from Kevin Hakman, co-founder of TIBCO's General Interface: "On what timeline will AJAX skills become commoditized like HTML skills became?" With a question like that, one is reminded that AJAX has come a very long way in a very short time.
Submission + - CompUSA to Close All Stores 1
An anonymous reader writes: Mexican telephone and retail magnate Carlos Slim, in a rare defeat, will exit the U.S. consumer electronics market, shutting the last 100 CompUSA Inc. stores after sinking about $2 billion into the business.
Gordon Brothers Group, a Boston-based retail store liquidator, will oversee a piecemeal sale of the Dallas-based business, the company said in a statement. Financial terms were not disclosed. Stores will remain open through year-end under the supervision of Gordon Brothers, which will also negotiate the sale of real estate and other assets. Two law firms were hired to represent creditors, CompUSA said.
Submission + - The $10 Billion Poker Game 2
Hugh Pickens writes: "Monday was the deadline for potential bidders to file with the Federal Communications Commission over the auction of the 700-megahertz band, a useful swath of the electromagnetic spectrum that is being freed up by the move to digital television. Once bidders file they become subject to strict "anticollusion" rules that in effect prohibit participants from discussing any aspect of their bidding until the auction is over and explains why Google announced Friday that it was going to bid in the auction because it can't discuss its bidding once it files to participate. The next official word will be late December or mid-January, when the FCC announces who has been approved to bid. The auction will start on January 24. Participants will use an Internet system to enter bids on any of 1,099 separate licenses that are being offered (pdf). Most coveted seems to be the C block, 12 regional licenses that can be combined to create a national wireless network. This is the spectrum Google is presumed to be most interested in. The bidding will be conducted in a series of rounds, and the commission will announce the amount of the high bid for each license at the end of each round but it will not identify the high bidder (pdf pages 10 — 14). Then the winning bidder will have ten days to put up 20 percent of the amount it bid. After that, the winner is allowed to discuss its bids publicly and negotiate with potential partners, such as losing bidders who may want to get in on the action but the winner only has ten more days to make deals before it has to pay the rest of the money it bid."
Submission + - BBC creates 'Perl on Rails' 2
Bogtha writes: Long-time users of Perl for their public websites, and having successfully used Ruby on Rails for internal websites, the BBC have fused the two by creating a 'Perl on Rails' that has the advantages of rapid development that Rails brings, while performing well enough to be used for the Beeb's high-traffic public websites. This is already powering one of their websites, and is set to be used in the controversial iPlayer project as well.
Submission + - Mixed news on Wiretapping from 9th Circuit USCoA
abb3w writes: The bad news: the United States Court of Appeals for the Ninth Circuit has ruled that the Al-Haramain lawyers may not submit into evidence their recollections of the top secret document handed to them detailing the warrantless electronic scrutiny they received. "Once properly invoked and judicially blessed, the state secrets privilege is not a half-way proposition." The good news: they have declined to answer and directed the lower court to consider whether "FISA preempts the common law state secrets privilege" with respect to the underlying nature of the program itself... which also keeps alive hopes for the EFF and ACLU to make those responsible answer for their actions.
Coverage at CNET, the NYTimes, and elsewhere; PDF of ruling here.
Coverage at CNET, the NYTimes, and elsewhere; PDF of ruling here.
Submission + - 10 Great Snake-Oil Gadgets (wired.com) 5
The Byelorussian Strikes Again writes: "Wired offers up 10 of the most awesome snake oil gadgets, from industrial cables sold as $200 ionized pain-relieving bracelets to a plastic chip that cures anything, improves gas mileage and cleans swimming pools.
One truly sad development: the infamous $500 wooden volume knob is no longer on sale."
Submission + - Comcast targets unlicensed anime torrents (animesuki.com) 3
SailorSpork writes: "According to the linked thread on the forums of AnimeSuki, a popular anime bittorent index site, Comcast has begun sending DCMA letters to customers downloading unlicensed (meaning that no english language company has the rights to) fan-subtitled anime shows via bittorrent. The letters are claiming that the copyright holder or an authorized agent are making the infringement claims, though usually these requests are also sent to the site itself rather that individual downloaders.
My question is have they really been in contact with Japanese anime companies, or is this another scare tactic by Comcast to try and reduce the bandwidth use of their heavier customers now that their previous tactics have come under legal fire?"
My question is have they really been in contact with Japanese anime companies, or is this another scare tactic by Comcast to try and reduce the bandwidth use of their heavier customers now that their previous tactics have come under legal fire?"
Submission + - Cryptography experts sounding alarms
netbuzz writes: "First we learn from Bruce Schneier that the NSA may have left itself a secret back door in an officially sanctioned cryptographic random-number generator that would allow the good guys to easily decipher encrypted messages sent between bad guys (not to mention anyone else). Now Adi Shamir is warning that a math error unknown to a chip maker but discovered by a bad guy could lead to serious consequences, too. Remember the Intel blunder of 1996?
http://www.networkworld.com/community/node/22026"
http://www.networkworld.com/community/node/22026"
