erikars: (Default)
 Finished Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin (3/5)

I wanted to love this book, but instead I just sort of liked it. This book is a member of the extensive genre of books on how to write clean code. It sits alongside books like Code Complete by Steve McConnell[1] and many others. Where Clean Code promised to differentiate itself was in the use of three case studies -- about a third of the book -- showing Martin's code cleanup techniques in action. 

However, I was disappointed by that section. As someone who codes and reviews code professionally, the case studies were not particularly enlightening. As seems obvious in retrospect, watching someone clean-up code in fairly straightforward ways is not interesting if you do and see that everyday. What I really wanted was a book on being a better code reviewer with advice on how to spot areas for improvement and convince others of the value of those improvements.

The examples could be useful for someone who isn't in a code-review-heavy environment. Martin does a reasonably good job of taking code that may seem reasonable on the surface and improving its readabilty. That said, his comments indicate that he often has a higher opinion of the cleanliness of his end result than I do. 

As for the general advice and discussion of how to make clean code, I agree with a lot of his tips and disagree with others. Code cleanliness is an area where the core of just-plain-good ideas is surrounded by a nimbus of sometimes contradictory standards that people pick and choose from. The details of what you choose from the nimbus generally does not matter so much as consistency. (Of course, the real trouble occurs when people don't agree on what belongs in the core and what belongs in the nimbus.)

The book definitely was not a bad read, but it did not fit my needs.

[1] Still my favorite in the genre.http://erikars.dreamwidth.org/269612.html

erikars: (Default)
Finished Test Driven Development: By Example [1] by Kent Beck (2/5)

This is one of those books that I would have rated more highly a few years ago. TDD is not a particularly complicated concept and, these days, it's not particularly new either. Thus, the explanations I've come across online[2] and the one book I've read on the topic[3] have been quite sufficient exposure, making reading another book on the topic superfluous.

That said, Beck's book was, in my opinion, better than Test-Driven Development: A Practical Guide by David Astels. Astels' book is not bad, but it's over 500 pages long, and TDD just isn't really that complicated. Beck's book, at ~200 pages of fairly spacious typesetting, is much more proportional to the complexity of the topic (websites are even shorter, but I prefer to read books, especially when they are available from the library at work).

In short, if you are interested in learning about TDD -- and I think it's an approach all programmer should learn about and apply judiciously but not religiously -- I recommend reading about it on the internet and then, if you're a book person or want to see a more extended example, read Beck's book.

[1] http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
[2] http://en.wikipedia.org/wiki/Test-driven_development andhttp://www.agiledata.org/essays/tdd.html
[3] http://erikars.dreamwidth.org/360140.html
erikars: (Default)
According to some studies I am too lazy to look up, listening to music while doing brain work probably reduces productivity. Yet many people I know, especially programmers, claim that music helps them concentrate and be more productive.

It could be that these programmers, including myself, are just wrong. We feel like music makes us more productive, but it doesn't. We lack the ability to properly measure our productivity. Maybe it's just because I don't like thinking I am wrong, but I don't really buy that.

An explanation I prefer is that programmers often work in high distraction environments. Working with music may less productive than working in a perfectly serene environment, but it beats out working with the noise of the HVAC, people walking through the halls, whatever.

But here's another observation, by no means novel. Programming is an activity made of many small interruptions. Both compiling and running tests take time. In an ideal build environment, that time is seconds, but I at least, work in an environment where these things take at least 30 seconds and can very well take minutes.

Often the easiest way to fill these breaks is to pop over to the browser. Check some email, look at the blogs, see what's up on Facebook, Twitter, Buzz... and before you know it, it's been 15 minutes.

When you listen to music, it is easier to avoid bringing up the browser. When your 30 second pauses stay 30 seconds long, you are more productive. And when you can stay in the flow of programming, the time after that pause will be more productive than if you had to remember what you were doing. Over the course of the day, that extra concentration adds up.
erikars: (Default)
Finiahed Java Concurrency in Practice by Brian Goetz with Tim Peirls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea. As is usual with technical books, I have a more complete summary.

Every programming language needs to have a book like Java Concurrency in Practice. I usually do not like books about specific programming languages because they tend to become obsolete so quickly. They are so specific to a particular version of a particular language that any small change renders them useless.

That is not the case with Java Concurrency in Practice. This book mixes general concurrency background and advice with Java specific advice with advice applicable to only certain versions of Java. Even as new versions of Java come out, this book will still have value. Even as other languages become primary, there are still many parts of the book that will be worth rereading (but not all, which is why I say every language needs its own equivalent of this book).

I highly recommend Java Concurrency in Practice to any Java programmer. Even if you are not explicitly using concurrency in your code, it shows up implicitly in enough libraries that it is worth reading at least the first part of the book. If you primarily program in another language, I would recommend that you find the equivalent book for your language of choice. Understanding concurrency is quickly becoming required knowledge for programmers.
erikars: (Default)
Finished Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

Design Patterns is a very important reference and its contents are also important, but it is kind of a dull book to read. This is mainly because the bulk of the book contains a catalog of patterns. Like most catalogs, it works better when you come to it looking for something specific.

I have two main criticisms of the patterns themselves, both of which stem more from the time the book was written than from any inherent problems with the patterns. First, each pattern contains a list of benefits and consequences. This section never considers the pattern from the view point of testability. This is a pity because most of the patterns, in my opinion, serve to make the relevant components easier to test.

A more serious complaint is that many of the patterns show their age by suggesting implementation inheritance as a good way of implementing these patterns. While implementation inheritance still has its place in the programmer's toolbox, current wisdom shies away from using it as "just a convenience". Instead, current belief leans more toward preferring interfaces (in the Java sense of only defining operations and not implementations) and reserves implementation inheritance for when it provides a tangible benefit.

That said, most of the patterns still have a useful core, even if some of the details of pattern structure or implementation should be modified to fit better into common practice. Just remember though, if you want to read through it you need will power or a reading group (preferably both).
erikars: (Default)
C++ is a language full of quirks. Sometimes these quirks are/were necessary to support the performance characteristics desired by the language designers. Sometimes these quirks are historic artifacts of a language whose design was started 30 years ago. Either way, these quirks often make it so that the language fails to follow bread-and-butter principles like "fail early" or "behave consistently".

Consider the following program:

#include <stdio.h>

class Foo {
 public:
  void bar() { printf("%li\n", (long)this); }
};

int main(void) {
  Foo* foo = NULL;
  foo->bar();
  return 0;
}


After compiling with GCC 4.3.1, the output of this program was 0. Despite the fact that foo is NULL, we are able to call a method on foo, and, since that method does not access any members, it executes successfully.

Change bar() to be virtual and the program will seg fault when run.

From an implementation point of view, this makes sense. In the first case, the call site can be replaced with a call to a method known at compile time. this is passed to that method, and an error occurs when this is dereferenced, not at the call site.

In the second case, the compiler does not know at compile time what method it will need to call. As such, at run time it needs to look up the vtable for the object. Since foo is NULL this call fails at the call site.

But things that make sense from an implementation point of view but not a language design point of view still make me sad.
erikars: (Default)
Finished test-driven development: A Practical Guide by David Astels. The book contains three parts. Part 1 introduces the reader to test-driven development. Part 2 discusses various tools and techniques for doing TDD. Part 3 presents an extended example by going through the test-driven development of a movie rating application.

Test-driven development builds on the principle that developers should write tests before they write code. The tests determine the code that needs to be written. As a side effect, this results in a suite of programmer tests. However, the book stresses that TDD primarily exists as a development methodology, not a testing methodology. The test suite produced by this methodology should not be considered a replacement for through testing by those who have testing as their primary goal.

My detailed impressions of the book and test-driven development.

test-driven development: A Practical Guide provides a good introduction to test-driven development. It contains many useful insights and practical tips. However, I suspect that you can find more focused, up-to-date introductions to the topic than the one found in this book.

My life

Jul. 20th, 2009 03:37 pm
erikars: (Default)
Eclipse: Ooops, can't find that import
Developer: What do you mean you can't find that import? You knew where it was 5 minutes ago.
Eclipse: Whatever, can't find it. Oh, and did you know the function you're calling doesn't exist?
Developer: Yes it does! You created the stub.
Eclipse: Sure I did.
Developer: Haha! I will refresh you and make you acknowledge my truth.
Eclipse: You fail puny mortal! I refuse to bend to your will.
Developer: Grrrr. Now you won't even find my file? I shall refresh you again.
Eclipse: Oh hello, I everything sure is hunky dory today, isn't it? What lovely files you have open. No need for any red squigglies here.
Developer: Curse your psychological games Eclipse. Some day I will defeat you! But for now, back to work.
erikars: (Default)
Eclipse can be infuriating. It is giving me an error saying that some type does not exist (it does). When I try to fix the error by creating the type, it fails because the type already exists. Yet even after this, it still insists the type doesn't exist.
erikars: (Default)
A name solidifies a concept and helps it do develop, but it can also make skeptics dismiss the idea as "just jargon".

I see this in the reactions of some of my coworkers to recent discussions about adopting some development practices from the Agile community. To a large extent, "Agile" is just a codification of best practices and an acknowledgement of the limitations of more fixed, linear development methods.

But naming these best practices makes some people worry that they are Methodologies, Processes, Procedures. That is they fear, as DeMarco and Lister discuss in Peopleware that the process will be valued for its own sake rather than for the benefit they may or may not give.

That is not an unfounded fear. Some flavors of Agile do seem more like a Methodology than like a set of methods for effective development. However, individual instances do not imply universality, and we should not assume that a ideology is empty rhetoric just because it is named.
erikars: (Default)
Finished Pragmatic Unit Testing by Andrew Hunt and David Thomas. Pragmatic Unit Testing is a book about testing for developers. The content is appropriate for developers who do not have much experience testing and for developers who do unit test their code but do not have formal training in testing.

The book describes the purpose of unit tests, how to write them, and what makes a good unit test. They give lots of examples to help developers figure out what kind of things are good to test and how to test them. Although a lot of the information can be found in general software engineering and development books, Pragmatic Unit Testing provides a concise, well explained introduction to developer testing.

I have a more complete summary here.
erikars: (Default)
Any readline experts around? I have need of one.
erikars: (Default)
Finished Ajax in 10 minutes by Phil Ballard. Every once in awhile you form a fondness for a book even though it is not a particularly good book. In this particular case, I knew that Ajax in 10 minutes by Phil Ballard would not be of the quality I usually expect out of CS books the moment I picked it up. Fate is the contents of the bookshelf near the massage chair.

My full summary can be found here.

Despite being from a publisher that prides itself as being for "When you only have time for the answers®", the book was quite educational. It started with a refresher of web technologies, went into an excruciatingly detailed description of how to use the XMLHTTPRequest object to interact with the server and update a web page, described some other technologies that are useful with Ajax, and finished off with a description of several libraries.

Overall, this book could have said the same thing a lot more concisely. At the same time, it could have included more details about error checking and programming defensively (I don't expect every code snippet to be bullet proof, but at least point out the potential trouble spots!). That said, I still learned a lot, and I will always have a fondness for this book since it was my first complete overview of Ajax.
erikars: (Default)
To backup my LJ, I ended up using the jbackup.pl script from SixApart's Subversion repository for LiveJournal. Using that, I was able to get an XML backup of my LJ with no problems. (Public and private data, includes comments, tags, etc.)

Since I did not want one giant XML file, I wrote a quick Python script to break the file into one file per day under a year/month file hierarchy. If you want a copy of this script, email me. It all worked, and now I have a nice, organized backup of my LJ.
erikars: (Default)
Over the last couple of days I have written up some notes on fault tolerance. I provide them here for your viewing pleasure. These notes may be interesting to you if you want to learn the vocabulary of fault tolerant systems. Notes on specific strategies for achieving fault tolerance are high level and generally focus on techniques that could be applied to or adapted for distributed systems.

As is normally the case with GoogleDocs converted to web pages without adding extra formatting, it is ugly but functional.
erikars: (Default)
I have recently been learning about software estimation. My full notes can be found here (let me know if the link does not work. I have never tried to share a Google Doc before.) My summary is a bit long, but then again it is summarizing my 20 pages of notes which are summarizing well over 100 pages of actual text.

The summary version )
erikars: (Default)
An interesting article on how amongst those who cheat, those who see themselves as morally superior cheat the worst. The basic idea is that those who feel morally superior and see something such as cheating as sometimes okay are more likely to claim the ends as justifying the means (e.g., if I cheat on this test I can get into med school and become a doctor and help people). Those who view themselves as morally superior and think cheating always wrong cheat the least.

The article reminds me of some programmers I have worked with. The people I have worked with who ignore things like the programming style guide just because they dislike the choices made there are also some of the most brilliant people I have worked with. They justify themselves by saying that their way has always worked for them and is therefore strictly better. Now, these are not exactly moral questions, but it seems like a similar principle. For better or for worse, many people who see themselves as superior have a tendency to see only their own ends and do what they need to justify them.
erikars: (Default)
Finished Secure Coding: Principles and Practicies by Mark G. Graff and Kenneth R. van Wyk. The book explores security considerations at all stages of the development process. The authors stress that security is not just an architecture or a design or an implementation or an operations issue. Ignoring security at any point in the development process can compromise the precautions taken during the rest of development. Security is not the responsibility of any single part of the development process or any one part of the system. Multiple layers of well reasoned security are necessary to make the program secure enough.

Notice that I said "secure enough" and not "secure". The authors of this book stress that there is no such thing as a completely secure system. Security is relative to the needs of the people running the system, and those needs change over time as new vulnerabilities are discovered and as the system is used in new ways. When considering security during the development process, one should always have a plan and a goal in mind. It is not enough to make the program secure; one must know that the system needs to, for example, guarantee the integrity of a company's financial information or the privacy of a user's credit card number. And it needs to do so in the face of adversaries who do not play by the rules the system sets forth.

This book will be worth rereading. As a developer with very little security experience, I only extracted high level ideas from my reading. Someday, when I have really absorbed the high level ideas, the details will be meaningful.

Profile

erikars: (Default)
Erika RS

May 2012

S M T W T F S
  123 45
6789101112
13141516171819
20212223242526
2728 293031  

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 21st, 2017 03:09 am
Powered by Dreamwidth Studios