Linux, AMD, VIA and Me

I installed Ubuntu Linux on my AMD64 3000+, S3 DeltaChrome IGP (it's just a big name for chipset which is good value for money), Asus A8V-VM mobo and a Gig DDR RAM. I've been working with many distros for quite sometime now(Mandrake, Knoppix, SuSe, Redhat since 6.2).

I'd some repeating bad experiences with it...

After numerous attempts to install via_drv.so for X, specific to my VIA K8M890 chipset (which is cheap and, not so surprisingly, widely unsupported by Linux), finally I realized this hardware isn't currently supported at all. The generic VESA driver draws at 40Mbits/s, which is *not* good enough for 1280*1024*75Hz GD. The kernel is generic 32bit, SATA drive runs in PIO mode (11Mbits/s, not better than even USB2 babe, hopefully I will fix this problem). Well, If Linux has to support only NForce, Radeon or very regularly expensive hardware, what's the use of it for those who seek the price-performance ratio well beyond brands?

There's an open source project, openchrome.org, for S3 Chrome Linux drivers, which doesn't have support for K8M890. Ironically it supports K8M800, I think I've got 90 more transistors/diode/resistors in my hardware; but this support doesn't excite me to know the differences between the models. And this support seems to be specifically for dear old XFree64 (hard-wired path in make scripts), hmm, its hopeless.

I've no success stories to tell about Linux on AMD based boxes. With three of my AMD based boxes, all I got is handful of driver installation defeats, shaky drags / scrolls and overall miserable system performance. Sad, I've to use Windows for most of my work. Now, I don't even mind keeping driver.cab on my hard drive.

I downloaded and tried Fedora Core 7 Image and it seems it will support my hardware (xfree86), I hope newer versions of Ubuntu will provide drivers for Via chipsets out of the box (Ubuntu is after all "Linux for human" and not for people who understand: Why only kernel headers are required to compile, link, probe and install modules), this is partly the fault of hardware vendors who don't want to develop drivers for Linux (I also read somewhere they don't even open specification for others to develop).

How to: Reinstalling Grub in Ubuntu Edgy, Fixing Windows Boot Record

Since windows likes to play with MBR and can't live without it, it overrode the boot record of my hard disk - wiping Linux boot info :(.

If you ran in similar problem, Here's a quick way of fixing it,

Boot from Ubuntu Live CD

sudo grub
grub> root (hd0,0)
grub> setup (hd0)
grub> exit

In (hd0,0) hd0 suggests first hard disk and 0 is the partition number (starting from 0, 0 means first partition). Also you can find out where the grub is installed by keying the command "find /boot/grub/stage1" in grub prompt.

Then, Add following lines to /boot/grub/menu.lst or wherever grub is installed.

title Windows XP
root (hd0,)
makeactive
chainloader +1

Just in case, if you have lost the boot record altogether ("Can't boot: Invalid Disk"): Boot from Windows CD and start repair just before installation, it will start recovery console. There, type in "fixboot". It is one of the risky windows command, see details here fixboot. Running it will restore the partition boot record and your system should boot (also you may like to use "fdisk /mbr" to restore, default jump on first partition boot record, your master boot record).

Six reasons why TDD is necessary

In Earlier post about experiences with evangelizing TDD, There was a comment by my friend Devang, asking for "real examples" for "real need" of TDD.

I'll write here few benefits of TDD (mostly on why tests are necessary? ) as I understood:

• You want to be confident about your code, with tests backing your code up, you always know your code will work without problems. You get confidence by successful test runs. Every time you see a green bar, you get satisfaction.
  

• Even when you have inevitable bugs, by chance, its easy to isolate them. The test points the exact location, you can quickly reproduce it with other test and fix it. For example, If a test method "testBlah" fails, you can directly look in to the code of that tests and real code tested there. Tests brings fewer surprises without dealing with huge logs and coding horrors.

• Writing good tests forces you to write good code and hence better low level design. For example, if I tell you to write a test for a thousand line C# method, it will be near to impossible to achieve it, so you'll break this method in smaller methods and try to test them each. With each test written, your code becomes good looking and reliable.

• Tests are the best ways to learn about the library, framework etc, tests are documentation. For example, If you want to learn how Hibernate.NET works or how to use APIs and don't want to RTFM, then you can have a quick sneak in Hibernate tests and you'll know how to use it.

• Talking of original TDD sense: If you've always written code first then you never worried about testability of your code. Whereas if you test first develop it, your code becomes testable. And there are many reasons why you want to make your code testable...

• With automated tests, You don't need to repeat yourself with debugging sessions, it's once and for all. Even if you have to debug, it will be at much smaller scale. For example, a bug is repeatedly coming up and you debug each time to fix it, each fix takes days because it involves debugging entire component, even if that component is as simple as build SQL and fetch-map objects with rows, it can turn out to be a debugging nightmare, if you'd written tests for it - they would have saved you hours of pain to step through the buggy code.
  

I hope this list will be helpful for those who are still wondering why TDD has become such a phenomenon or are still skeptic about it.

Believe me, Tests save your life and makes it very easy :). If you like this post and found useful, please share it with others, your comments are welcome.

TDD Evangelizing Experiences

I was discussing about usefulness of developer testing and TDD stuff with one of my friend, Kapil. I told him "you should avoid debugging at all costs" - debugging is painfully mundane and costly activity, "one of the way of avoiding it is; to write automated unit tests", he said, "I avoid it by debugging differently..".

I asked how and what different debugging techniques, and he gave an example of manual technique to avoid seeing what's going in code ("If a file is not found, I'll try renaming or something like that"). I said, "this is no debugging, its kind of troubleshooting to avoid debugging". He would not agree to it.., then I told him why not write an intelligent program which will do the same thing programmatically ?(well, its kinda behavioral testing), then? well then he was interested in listening... and was ready for few pills of TDD :).

With few examples, It was easy to explain him how TDD can change the way you think about developing software, he already knows it a bit, tries to minimize it through other manual hacks (this is partially because PHP has smattering good debuggers and he works on PHP based server apps).

I told him "debugging happens to be one of those trivial activities which doesn't differentiate you from others" (no big deal, everyone can do it, right?); You need to consider audience attitude for a successful systematic evangelizing :).

TDD, in its real sense-the test first, is one thing that I still find difficult to explain to people; It requires you to give it a shot without unveiling providential "Zen" behind it, somethings you should just try without resisting and put in practice if you find it effective.

Once, I explained TDD to my trainee team at C-SAM, I explained it by example, told them what happens when you don't have tests, made them feel the pain of debugging; then write tests and show what great peace of mind this automatic testing gives.

To sum the experiences on evangelizing TDD:

• To a good programmer explain the benefits of writing intellectual tests rather than idiot debugging every time.
• To a novice, give a real example; mock a bad situation and exhibit how to tackle it with TDD.
• To an amateur, explain how tests are better than manual troubleshooting.
  

Kill Debugging, Write tests.

I hope this experiences will find some use and benefits in development.

Taking care of abused Exceptions using JDT AST

How many times you went nuts while dare debugging a large application? and while debugging, faced desperate failure in getting any clue on what went wrong, no exception, no log?

Well, If you work on right smartly large bad code base, this experience is quite common. One of the main reasons, as I think, for this situation is swallowed and mishandled exceptions.

I ran in similar problems once, where it was becoming very hard to find the problems. I came to know mishandled exceptions in many places. And I decided to write a plug-in to manipulate AST and replace it with logging statements.

Here is the code for interesting parts of the plug-in. Created a catch clause visitor, which will visit all the catch clauses in AST. The AST will be parsed for each Compilation Unit in a loop.

private final class CatchClauseVisitor extends ASTVisitor {
@Override
public boolean visit(CatchClause node) {
allCatchClauses.add(node);
return super.visit(node);
}
}

This visitor can be used to collect clauses from AST:

ASTParser parser = ASTParser.newParser(AST.JLS3);
parser.setKind(ASTParser.K_COMPILATION_UNIT);
parser.setSource(lwUnit); // set source
parser.setResolveBindings(true); // we need bindings later on
CompilationUnit unit =(CompilationUnit) parser.createAST(null /* IProgressMonitor */);
unit.accept(new CatchClauseVisitor());

Now that we have all catch clauses, we can iterate on them to execute transformations and rewrite the AST.

try {
for (CatchClause node : allCatchClauses) {
if (list.size() == 0) // SWALLOWED EXCEPTION
putLoggingStatement(node, null, rewrite, null);
else // code to replace SOP statements with logger call
for (Object object : list)
// ....
// computation of the new source code
TextEdit edits = rewrite.rewriteAST(doc,
lwUnit.getJavaProject().getOptions(true));
edits.apply(doc);
String newSource = doc.get();
// update of the compilation unit
lwUnit.getBuffer().setContents(newSource);
lwUnit.save(null, false);

} catch (...){...}

And here is the putLoggingStatement method..

private void putLoggingStatement(CatchClause node, Object object,
ASTRewrite rewrite, ASTNode expStatement) {
MethodInvocation invocation = node.getAST().newMethodInvocation();
setLoggingMethodName(node, invocation);
SimpleName args = node.getAST().newSimpleName(
node.getException().getName().getIdentifier());
invocation.arguments().add(args);
if (expStatement == null) {
ExpressionStatement statement = node.getAST()
.newExpressionStatement(invocation);
ListRewrite listRewrite = rewrite.getListRewrite(node.getBody(),
Block.STATEMENTS_PROPERTY);
listRewrite.insertFirst(statement, null);
rewrite.replace(node, node, null); // replace the nodes
return;
}
ExpressionStatement statement = node.getAST().newExpressionStatement(
invocation);
setContextInstaceVariable(invocation);
rewrite.replace(expStatement, statement, null);
}
// ....

A number of details are removed for the sake of brevity and I don't claim the code to be professionally written. There are some improvements I can thing of, like, the SOP can be replaced with logging statement, a provision for rethrowing exception statement based on some config (no, no configs!)....

Finally let me tell you that writing the code involving AST can become complex and error prone, but it does a real good job. This small job of carefully writing a custom code manipulation saved me from doing it manually for hundreds of java source files as well as code maintainability got much better, what a relief!

The State of software

There's a thought provoking discussion on pragprog on the current state of software. The discussion was really insightful, and I can't disagree with the group that, quality of softwares has gone bad.

These days, People comfortably accept existence of bugs in most software, which is a fact not acceptable at all but it seems the expectation from software is being relaxed and hence limited existence of better software, is this the failure on our part?

Even after almost fifty years, people are still writing code in historical languages, and are happy with it, this is very questionable compared to other disciplines. If we compare software crafting with other domains, it's quite frustratingly slower in improving, this rant is quite valid. Although few of us have started picking up the lessons from domain, lean software development being one of them.

On optimistic fronts, there are few good news also (note that 73.5% of all stats. are made up ;) ). According to these news there are few outright software project failures and look at the bloody success ratios! they are marginally good in comparison!

Of course, there are few world class development in open source, which have outperformed most traditional stuff (e.g. managed environments), but they are not in sufficiently large number.

IMO, all this deserves evolutionary development, and yes Agile helps, not a silver bullet but helps; quite a lot in controlling four essential aspects of four variables.

And this pragprog topic is worth a read...

I'm unemployed

Today is last working day at my organization, After a year I thought to move on...

At my organization, I learned a lot of technologies; most of them related to rich applications based on Eclipse Platform. Other than tech., I got chance to work with complex graph based algorithms, template based generators, UML & BPMN specs, compiler stuff, few model transformations related stuff, licensing, release engineering, heavy weight refactoring (ashamed to say, without tests), great tooling and many more things...

It was really fun doing all that, but finally I've to move on to apply my understanding to the business. Like all geeks out there, I used to fascinate with the tech. curiosity and internal stuff, but now I'm realizing that the value of this knowledge to business domains is much more than mere curiosity. I hope I'll be able to create some value out of my tech. understanding.

I'm now an unemployed Indian programmer.