Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment: My Experiences with a VIA-C7-D and OpenSuse (Score 1) 697

by andrew cooke (#29867879) Attached to: Low-Power Home Linux Server?

I guess I am probably too late to be noticed, but for what it's worth I did exactly this. My notes are here - http://www.acooke.org/cute/SystemRefa0.html

In short: it works just fine, and sits (moderately quietly) in the corner, doing its thing. However, the processor is not really fast enough for desktop, so installing and getting everything working was a little frustrating. Also, that chip doesn't have automatic throttling support in Linux so I have a bit of a hack (see link). And the original fan was small and noisy, so I replaced it with a 120mm one.

My electricity bill dropped by about 1/3 since my main machine, which I use during the day for development work, is off for over half the time.

Comment: variety (Score 1) 601

by andrew cooke (#28476099) Attached to: How To Get Out of Developer's Block?

it's not clear to me (sorry if i've missed some info somewhere) whether this is paid work or not.

if it's a personal project, then one option is to take a break. i've been writing software for way too long (20 years?) and in that time have nearly always programmed in my free time, but there was a period of about a year when i felt burn out and spent my free time building electronics and learning bass guitar.

another option - one that is possible if it's a personal project and may also be possible (perhaps with some negotiation) if it's paid - is so switch focus. sometimes, for example, writing documentation can give you a new view on a project that gets you back working. i am currently working on a parser (called lepl) and whenever i work on documentation i end up with a whole pile of new ideas.

related to that - dog fooding. can you use the software you are developing in some way? that can motivate you to add a feature that would really help you out. similarly, getting a release out. particularly if it's open source (or a free beta?) - feedback from other people is motivating and helps highlight the most important features (which might not be what you were expecting).

at the same time - trust yourself. my guess is that you've not been programming that long. these things always come in cycles. once you've been through a few it's much easier to just take it easy, knowing that the drive will come back. i'm lucky in that i work from home - there are days when i do almost nothing but eat, sleep and surf the web (and there are many more days when i work my ass off - the idea is that there's give and take, it's a two sided deal....)

finally, look after yourself. look at what you're eating, how well you're sleeping, whether you're getting enough exercise. perhaps take a personal day and do something interesting.

Books

+ - Agile Software Development - The Cooperative Game

Submitted by
andrew cooke
andrew cooke writes "Teaser for Slashdot's "above the fold": The second edition of Alistair Cockburn's "Agile Software Development" was released earlier this year. Does it add significantly to the first edition? Who should read it? And is it clear yet what "Agile" means? The answers: Maybe; Everyone; Ri. Amplification and justification below...

This excellent, but imperfect, book might make more sense read backwards — you would start (at the end) with useful, concrete ideas about how to improve the way you make software, progress to a more general discussion, and end with the unifying principles of Shu, Ha and Ri.

Instead, Cockburn starts by explaining those terms. He says that they are from Aikido. Someone who understand them in their original context may find the following (my own summary) to be crude (or plain wrong), but they are central to this book and to Agile as a whole:
  • Shu is the beginner's state. Lost, confused, looking for basic rules.
  • Ha is more experienced. Procedures are automatic; direction certain.
  • Ri goes meta. Higher order functionality. The questioning guru.
One reason (of many) these distinctions are important is that communication changes at each level (I think you can see this in programming languages — Python is designed for learners at the Shu level, while Perl is more concerned with letting Ri level programmers express themselves as they choose).

Although he never comes out and flatly states it, Cockburn clearly implies that Agile development is all about the Ri. I think he's right: that makes this book worth buying, reading, and passing on to others.

But this is all rather vague (another reason to read the book backwards is that it's much easier to tolerate this kind of hand-waving when you've seen some concrete facts; start at the beginning and you face not just this "wisdom", but some of Cockburn's own poetry — Paul Neil Milne Johnstone has a posse). Back to earth. What does this mean, in practical terms? And what does this say about "Agile"?

First rule of Agile: there are no rules. There are too many variables for any one process to be always right. Instead, you do what works in a particular context. Results matter. It's not who uses the latest catchphrase. It's not winning boardroom bingo. It is about getting results out of the door.

How do you get there? Is "Agile" more than the empty tautology "it's best to do the right thing"? After all, while we want to be Ri, we start at Shu. Cockburn provides two answers.

First, reflect. Learn from your own group's experiences. Look at what you do well. Build on it. If reflection fails, reflect on that. Cockburn repeatedly emphasises the need for personal safety — that people need to feel safe to express what they think.

Second, steal. Learn from other groups' experiences. The second half of the book, roughly, discusses possible ideas. These tend to be the "traditional" Agile themes: communication; lightweight documentation; information radiators; pair programming; etc. Useful information when you're at the Shu level.

So this book is targeted at people responsible for process. People that influence a company's culture. People who aim to create an environment in which "The Cooperative Game" — Cockburn's term — can be played well.

Pick up a copy at your local bookstore and you'll see that there are grey "tab marks" printed on some page edges. These indicate new content (the unmarked pages are the original text which has been kept, more or less verbatim). In general the updates are not that substantial, but chapter 5.1 — a retrospective (with notes on various practical cases) — is the exception.

This new section includes reports from others responsible for improving agility. They are in broad consensus: the Cooperative Game cannot be dictated. It must be cultivated; grown from the roots.

Which is why this is also a book for developers. It recognises that everyone can make a difference. At various points in the book Cockburn addresses the question "what do I do about this?" and he's talking to everyone.

I am a programmer working in a distributed, open-source project. There are times when I take a walk round the block to shrug off the less-than-helpful comments of a co-worker, or some anti-pattern in the code, or [any programmer can insert their own examples here — my co-workers are a great bunch, these problems occur everywhere]. Reading a book like this helps keep me sane: it helps me understand how I miscommunicate, and how to communicate better; it lets me understand the (valuable!) role each person plays in our process (before that, it helped me see what our process is); it reassures me that communication in a distributed team is hard and it gives me ideas to help solve these issues. Although, having written that, I think Cockburn could profit from a study of successful global teams.

Your problems will be different, but the best way to solve them will be the same — through careful thought and reflection. And at heart, that is what this book is about. Cognitive Behavioural Therapy for software development.

So this is a good book. It recognises that things go wrong; it admits there is no one size fits all patented wonder potion magical cure; it reaches the logical conclusion, you have to think; it goes on to discuss possible solutions.

But it's not perfect. One of the more amusing sections describes Cockburn's experience producing the previous version — he tried an Agile approach to publishing which met the (very tight) deadline, but alienated his copy-editor. Now I don't know what a copy-editor does, but if he was relying on her to remove duplications, rewrite cliches, or improve metaphors, well, he might not have found the optimal process. And it is a pity that the original text was not more completely revised for this edition.

Two final conclusions. One is that the waterfall model is "Agile" if it's the best approach for the circumstances. The other is that you should be suspicious of anyone trying to sell a single, perfect, recipe.

Disclaimer — I obtained a free copy of this book on condition that I review it."
Java

+ - Java Generics and Collections

Submitted by
andrew cooke
andrew cooke writes "Java Generics and Collections

Java 6 was recently released, but many programmers are still exploring the features introduced in Java 5 — probably the most significant changes in the language's twelve year history. Amongst those changes (enumerations, auto-boxing, foreach, varargs) generics was the most far-reaching, introducing generic programming in a simpler, safer way than C++ templates and, unlike generics in C#, maintaining backwards (and forwards) compatibility with existing Java code.

Given the history of Generic Java, Naftalin and Wadler's Java Generics and Collections has a distinguished pedigree. In this review I'll argue that this is a new classic. Background to Generics

If you're a Java programmer you've probably heard of generics, an extension to the type system that was introduced in Java 5. They give you, as a programmer, a way to write code even when you don't know exactly what classes will be used.

The obvious example is collections — the author of a List class has no idea what type of objects will be stored when the code is used.

Before generics, if you wanted to write code that handled unknown classes you had to use make use of inheritance: write the code as if it would get Objects, and then let the caller cast the result as necessary. Since casts happen at runtime any mistakes may cause a runtime error (a ClassCastException).

Generics fix this. They let you write code in which the classes are named (parameters) and the compiler can then check that the use of these class parameters is consistent in your program. So if you have a List of Foo instances you write List<Foo> and the compiler knows that when you read that list you will receive a Foo, not an Object. History

I'll get to the book in a moment, but first a little history. If you know any type theory — particularly as used in functional languages like ML and Haskell — then you'll recognise my quick description above as parametric polymorphism. You'll also know that it is incredibly useful, and wonder how Java programmers could ever have managed without it.

Which explains why Philip Wadler, one of the people responsible for Haskell, was part of a team that wrote GJ (Generic Java), one of the experimental Java mutations (others included PolyJ and Pizza) that, back in the day (late 90s) helped explore how parametric polymorphism could be added to Java, and which formed the basis for the generics introduced in Java 5.

So if you want to understand generics, Wadler is your man. Which, in turn, explains why I jumped at the chance to review O'Reilly's Java Generics and Collections, by Maurice Naftalin and Philip Wadler. The Book

This is a moderately slim book (just under 300 pages). It looks like any other O'Reilly work — the animal is an Alligator this time. It's well organised, easy to read, and has a decent index.

There's an odd discrepancy, though: Wadler is the generics Guru; this is going to be `the generics reference'; generics are sexy (in relative terms — we're talking Java here) and collections are not; the title has "Java Generics" in great big letters with "and Collections" in little tiny ones down in a corner. Yet very nearly half this book is dedicated to collections.

So in the next section I'll justify the `reference' comment above, and in the one after I'll take a look at the collections half of the book and ask to what extent it's padding. Part I — Generics

This is a great, practical read. It starts simply, introducing a range of new features in Java 5, and then builds rapidly.

If you are completely new to generics, you'll want to read slowly. Everything is here, and it's very clear and friendly, but there are not the chapters of simple, repeated examples you might find in a fatter book. Within just 30 pages you meet pretty much all of generics, including wildcards and constraints.

If that makes your head spin, don't worry. Read on. The next hundred or so pages don't introduce any new syntax, but instead discuss a wide range of related issues. The chapters on Comparisons and Bounds and Declarations contain more examples that will help clarify what generics do. And the following chapters on Evolution, Reification, and Reflection will explain exactly why.

So the first seven chapters introduce generics and then justify the implementation — any programmer that takes the time to understand this will have a very solid base in generics.

There are even some interesting ideas on how Java could have evolved differently — section 6.9 Arrays as a Deprecated Type presents a strong case for removing arrays from the language. It's a tribute to the clarity and depth of this book that the reader is able to follow detailed arguments about language design. Fascinating stuff.

The next two chapters, however, were my favourites. Effective Generics and Design Patterns give sensible, practical advice on using generics in your work, including the best explanation of <X extends Foo<X>> I've seen yet (so if you don't know what I am talking about here, read the book).

(A practical word of advice — if at all possible, use Java 6 with generics. Java 5 has a sneaky bug). Part II — Collections

This part of the book was more along O'Reilly's `Nutshell' lines: the different chapters explore different collection types in detail. I must admit that at first I skipped this — it looked like API docs re-hashed to extend the size of the book.

But then I felt bad, because I was supposed to be reviewing this book (full disclosure: if you review a book for Slashdot you get to keep it). And you know what? It turned out to be pretty interesting. I've programmed in Java for (too many) years, and I guess I've not been quite as dedicated to tracking how the library has changed as I should have been — I learnt a lot.

Again, a wide range of readers are welcome. This is more than a summary of the Javadocs, ranging from thumbnail sketches of trees and hashtables to a discussion of containers intended for multi-threaded programming.

The way I see it now, this part is a bonus: the first half, on generics, makes this book one of the standards; the second half is an extra treat I'm glad I stumbled across (I guess if you're some kind of weird collection-fetishist maybe it's even worth buying the book for). Conclusions

I've used generics since the first beta release of Java 5 and had experience with parametric polymorphism in functional languages before that (in other words, I can tell my co- from my contra-variance). So I guess I'm heading towards the more expert end of the spectrum and I was worried I'd find the book boring. It wasn't. After claiming to be expert I don't want to spoil things with evidence that I'm actually stupid, but reading this book cleared up a few `misunderstandings' I'd had. I wish I had read it earlier.

If you're new to generics, and you don't mind thinking, I recommend this book. If you're a Java programmer who's a bit confused by <? super Foo> then this is the book for you.

The only people who shouldn't read this are people new to Java. You need to go elsewhere first. This is not a book for complete beginners.

A great book in the classic — practical, concise and intelligent — O'Reilly mould."

The tree of research must from time to time be refreshed with the blood of bean counters. -- Alan Kay

Working...