- Domain-Specific Languages: An Introductory Example
- Sep 27, 2010
- In this excerpt from his book, Domain-Specific Languages, Martin Fowler offers a concrete example to demonstrate the different forms a DSL can take.
|
- Interview with Andrei Alexandrescu (Part 3 of 3)
- Aug 25, 2010
- Eric Niebler and Andrei Alexandrescu conclude their conversation about the D programming language by discussing concurrency, the complications of sharing data, dynamic loading, specification and licensing, and the future of D.
|
- Interview with Andrei Alexandrescu (Part 2 of 3)
- Aug 18, 2010
- Part 2 of this interview about the D programming language finds Eric Niebler and Andrei Alexandrescu deep in discussion about structs versus classes, the difficulties of copy semantics, rvalue references, the intricacies of garbage collection, and Andrei's occasional failure in serving as the standard-bearer for policy-based design.
|
- All Systems Are Go: An Interview with Rob Pike, the Co-developer of Google's Go Programming Language
- Aug 17, 2010
- Danny Kalev talks with Rob Pike, the co-developer of Google's new Go programming language. In this interview, Pike speaks about the limitations of C++ in large-scale projects, the design philosophy of Go and its unusual type-system, and Go's future.
|
- Interview with Andrei Alexandrescu (Part 1 of 3)
- Aug 11, 2010
- In part 1 of this three-part series, Eric Niebler talks with his pal and fellow InformIT contributor Andrei Alexandrescu about the D programming language and Andrei's new book about it: what makes D different from other languages, whether D's class libraries rival those of Java and .NET, and why Andrei claims not to be a guru.
|
- How to Build a Strong Virtual Team
- May 11, 2010
- Karen N. Johnson provides valuable advice for establishing and maintaining virtual relationships with team members. Using senses other than just your sight, paying attention to subtle clues, and putting in a little extra effort to be available when needed can help you to build a strong team that works together even when they're physically separated.
|
- Improve Your Testing and Your Testers with Paired Testing
- Apr 27, 2010
- Have you ever had testers on your team whose knowledge and skill sets were complementary, and wondered how you could encourage them to exchange and collaborate so that they could both increase their skills? Author Karen Johnson shows a different approach to testing and some of the advantages of pairing testers.
|
- The Design of Design: Exemplars in Design
-
By
Frederick P. Brooks
- Apr 19, 2010
- Few designs are all-new. Usually, even novel designs derive from earlier artifacts intended for similar purposes and built with similar technology. What then is the proper role of exemplars, precedents, in design? How should the designer study and use them? Should each design domain develop an accessible cumulative store of exemplars? Frederick P. Brooks considers these questions in this excerpt from his book, The Design of Design.
|
- What Programmers Have to Know About Testing
- Jan 11, 2010
- Janet Gregory offers some good advice to developers: Even when you know that a dedicated test team will be testing your software, there are some things that your programming team shouldn't leave for the testers to find.
|
- Robert C. Martin's Clean Code Tip #12: Eliminate Boolean Arguments
- Aug 25, 2009
- We join "The Craftsman," Robert C. Martin's series on an interstellar spacecraft where programmers hone their coding skills. In this twelfth tip in the series, the crew learns that Boolean arguments loudly declare that the function does more than one thing. They are confusing and should be eliminated.
|
- Helping the Development Team Learn More About the Business
- Aug 18, 2009
- Your software development team might be brilliant at testing and coding, but the team can support your business much better with software if they know that business inside and out. Lisa Crispin shows how the effort can pay off.
|
- Eight Terrifying Team Project Mistakes
- Aug 17, 2009
- John Paul Mueller shares project mistakes, including these frightening (true) examples.
|
- Robert C. Martin's Clean Code Tip of the Week #8: Your Build Shouldn't Require More Than One Step
- May 16, 2009
- We join "The Craftsman," Robert C. Martin's series on an interstellar spacecraft where programmers hone their coding skills. In this eighth tip in the series, the crewmen learn that building a project should be a single trivial operation.
|
- Robert C. Martin's Clean Code Tip of the Week #7: Clean up Old Commented Out Code
- Mar 30, 2009
- Robert C. Martin explains why old commented-out code is an abomination.
|
- Robert C. Martin's Clean Code Tip of the Week #6: Avoid Poorly Written Comments
- Feb 27, 2009
- We join "The Craftsman," Robert C. Martin's series on an interstellar spacecraft where programmers hone their coding skills. In this sixth tip in the series, the crewmen try to interpret a poorly worded comment.
|
- Robert C. Martin's Clean Code Tip of the Week #4: Avoid Obsolete Comments
- Feb 11, 2009
- A comment that has gotten old, irrelevant, and incorrect is obsolete. Obsolete comments tend to migrate away from the code they once described and become floating islands of irrelevance and misdirection.
|
- Robert C. Martin's Clean Code Tip of the Week #3: Avoid Inappropriate Information
- Jan 28, 2009
- In this third tip of the series, programmers discuss how to avoid inappropriate information.
|
- Robert C. Martin's Clean Code Tip of the Week #2: The Inverse Scope Law of Function Names
- Jan 21, 2009
- The longer the scope of a function, the shorter its name should be.
|
- Robert C. Martinโs Clean Code Tip of the Week #1: An Accidental Doppelgänger in Ruby
- Jan 7, 2009
- Robert C. Martin investigates an interesting dilemma: if the implementation of two functions is identical, yet their intent is completely different, is it still duplicate code?
|
- What Is Clean Code?
- Aug 19, 2008
- Robert C. Martin introduces his book, Clean Code, and polls experienced programmers -- including Bjarne Stroustrup, Grady Booch, Dave Thomas, and Ward Cunningham -- on what their definition of "Clean Code" is.
|