The (Unofficial) ITWorx Technical Architecture Blog

Archive for November, 2006

Book about Creating and Manipulating PDF

Posted by archworx on November 29, 2006

In iText in Action: Creating and Manipulating PDF, author Bruno Lowagie walks through everything PDF, Adobe’s Portable Document Format, from a Java developer’s point of view. Lowagie covers how to use iText in a Java/J2EE application for the production and/or manipulation of PDF documents. Along the way, Lowagie describes interesting PDF features and explains more obscure e-document functionalities. In addition to many small code samples, this book includes XML-based, ready-made solutions that can easily be adapted and integrated into projects.

There is a sample chapter titled “PDF: why and when“. The first section of this chapter explains why PDF was invented and how it evolved into a de facto standard. In the second section, Lowagie describes the different PDF “flavors,” some of which are described in an International Standards Organization (ISO) standard. Lowagie uses a table listing different versions of the PDF specification to focus on specific features such as compression and encryption. He also uses “Hello World” examples to show how to compress/decompress and encrypt/decrypt PDF files.


Posted in Java, Nader, Programming | Leave a Comment »


Posted by archworx on November 27, 2006

A wiki is a Web site that enables users to add new content or edit existing content. As soon as you post on a wiki all users are able to add or change your original content without needing any permissions. The purpose of the wiki to make it easy to collaborate on shared documents, once you publish your document; you relinquish ownership of that content. Most advanced wiki software allows advanced editing such as rich text fonts, graphics and HTML tags. This makes collaboration easy and fast. The term “wiki” comes from the Hawaiian word for “quick”.

For our internal wiki, we choose to use MoinMoin which is a python wiki engine, its open source and very easy to setup and use.

For installation on IIS 6.0 on a windows 2003 server, use the following instructions

For more details on installation of the wiki engine:

For more details on creating the wiki instance:

Posted in General, Nader | Leave a Comment »

Unit testing

Posted by archworx on November 14, 2006

Do you want to know as soon as your new code breaks some older piece of code, either yours or someone else? I’m sure we all would like that. Well, Extreme programming answer to this is automated unit tests. The idea is that you have a set of classes testing your code; you write a test for each function you have, checking the expected result against actual results. Once you change any part of the code base or add new code, you run the test suite and right there you find out if there is anything broken, the failing tests also show you exactly which part is broken. If all the tests pass, then you know for sure you changes are ready to be integrated with the rest of the system.
The biggest resistance to dedicating any amount of time to unit tests is a fast approaching deadline. But during the life of a project an automated test can save you a hundred times the cost to create it by finding and guarding against bugs. The time it takes to find and fix a bug as you are developing your code is much less than finding it and fixing it after you are done and the system is being tested by the client. The harder the test is to write the more you need it because the greater your savings will be. Discovering all the problems that can occur take time, so to have a complete unit test suite when you need it you must begin creating the tests as you build the code.
Examples of unit test frameworks are NUnit ( for .net and JUnit ( for Java

Posted in Extreme Programming, Nader | Leave a Comment »

Reverse Engineering Success

Posted by archworx on November 13, 2006

Disclaimer: Not a Tech Post

I was reading this ( post by Scott Adams when I remembered a strange concept I came to realize a few years ago…

Basically, in Scott’s blog post he discusses a simple idea, that when he set his mind to reach a certain goal, he made it. No matter how seemingly difficult that goal was. For example he decided he would be the valedictorian of his class and he made it. He decided he wanted to become a successful syndicated cartoonist, and now he is the guy behind Dilbert.

If you think about it – it is a very powerful idea. Set your sights for incredibly high goals… and actually achieve them!

In reality, the idea of reaching success is not necessarily based on pure magic. Obviously there are a lot of factors that influence your journey, but the bare truth is that there is a lot that lies directly within your own hands that can greatly propel your progress through life.

I’ll give you a quick example – I used to love creative writing, and thought I’d do well in my English classes at school, but I rarely got the A’s I thought I deserved. I realized one day that there was a fundamental difference between my style and my instructor’s style. One day, I decided to immitate his style, and to my shock, I finally got my long anticipated A.

I quickly dismissed this experiment as unethical, and more importantly to me, not self-gratifying, and never did it again for many years to come. I found happiness in writing in my style, not in Mr. Brown’s.

This same situation happened to me over and over again, until I finally graduated and started working in a software company. Most people who work in software services will tell you that the most important thing you need to get straight is your Software Requirements Specifications!

If you ignore what the client wants, and instead deliver what you prefer or think makes more sense, you’re booking a one way ticket out of the company. Yet, inspite of how easy this seems at first, the reality is that in the software industry, convincing techies to actually do what someone else wants is extremely difficult.

This post is just a primer about a set of thoughts that are spinning around my mind at the time being. It will probably take me a long time before I’m done with them, if I ever am. Today I just wanted to establish the crucial fact that success, in principle can actually be easily attainable if you have the end in mind.

Such a simple sentence, but believe me, it is this elementary deception that is the key difference between performing reasonably well, and delivering exceptionally stellar results.

Stay tuned for the next rant, and till then, make sure you understand your “requirements”!

Posted in mkaram, Rant | 1 Comment »

How to create a Vista Sidebar Gadget.

Posted by archworx on November 5, 2006

I was asked to create a quick POC (proof of concept) for a MS Windows Vista sidebar gadget. I did the usual search and discovered a few posts.

An interesting post was by a guy called Daniel Moth. It had lots of useful information, but unfortunately it just didn’t work for me. There seems to be something missing in the xml file accompanying the gadget, as well as some rubbish text in the file, so your gadget won’t work but you won’t get an error.

I found a more uptodate sample on MSDN. This was also on Daniel Moth’s blog, so many thanks to him.

Now here is my version of the hello world sidebar gadget.

Step 1:

Create the following HTML file:

 <title>Hello, World!</title>
  body {
 <span id=”gadgetContent” style=”font-family: Tahoma; font-size: 10pt;”>Hello, World!</span>

Call it HelloWorld.html

Step 2:

Create the following XML file:

<?xml version=”1.0″ encoding=”utf-8″ ?>
    <name>Hello World!</name>
    <author name=”Your Name”>
        <info url=”” />
    <description>My first gadget</description>
        <host name=”sidebar”>
            <base type=”HTML” apiVersion=”1.0.0″ src=”HelloWorld.html” mce_src=”HelloWorld.html” />
            <platform minPlatformVersion=”0.3″ />

Call this file Gadget.xml

Step 3:

Create a folder called Helloworld.Gadget

Step 4:

1.Simply copy”%userprofile%\AppData\Local\Microsoft\Windows Sidebar\Gadgets” and paste in Windows explorer address bar.
2. When you get to that folder Copy and Paste the “HelloWorld.Gadget” folder there.

Step 5:

Add the gadget to your Sidebar and your done !

That’s how easy it was to create a sidebar gadget. Obviously, you want your gadget to do more than just display “HelloWorld”. You have infinite possibilities. Anything that con be done with DHTML or .NET can be done on a sidebar, you just have to make sure you have the right permissions.

How do I create a gadget with .NET?

If you check out the MSDN link you should find it there, and if I get something done soon, I’ll surely post it.

Also check out the Gadget team blog.

Anyway, that’s it for now, Happy developing!

Posted in MSamy, Programming, Vista | 356 Comments »


Posted by archworx on November 5, 2006

The first practice of extreme programming we are going to discuss is Refactoring. It is the process of changing an existing body of code, changing its internal structure without changing its external behavior. Keeping each refactor (change) small ensures the system is restructured while reducing the chances of things going wrong. Constantly refactoring your code eliminates any duplication and keeps your code-base simple and easy to read and manage. For me it’s always a sign you need to refactor when you find yourself copying and pasting code from one class to another.

There are refactoring tools in most IDEs to make it easier for developers to perform this task; common supported tasks usually include renaming of classes and variables, extracting methods, organizing code and much more. Check your IDE and find out how it can help you refactor and make you life easier and your code cleaner.

Posted in Extreme Programming, Nader | 1 Comment »

Extreme programming

Posted by archworx on November 2, 2006

Extreme programming (XP) is a different approach to software development; it’s been in use with great success by big companies all over the world for the last ten years. The methodology is designed to deliver the customer needs and be flexible enough to adapt to changes in any phase of the life cycle. XP is built on four main concepts; simplicity, developers are encouraged to build the simplest solution that gets the job done. Communication, team members communicate with the customer and each other early and often. Feedback, the code is tested as it’s developed so developers can fix issues as early as possible. Courage, with these concepts in place its easy for developers to change their design and code to react to changing requirements. 

XP practices: 

  1. The Planning Game: The Business team comes up with a list of features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes what is required. The Development team estimates how much of the user stories can be implemented in a given time interval (the iteration). Business team decides which stories to implement in what order.
  2. Start with the smallest useful feature set. Release early and often, adding a few features each time.
  3. Always use the simplest possible design that gets the job done. All you need to do is to meet the requirements as they are right now.
  4. Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Unit Tests are automated tests written by the developers to test functionality as they write it. The customer specifies the acceptance tests to test that the overall system is functioning as specified. When all the acceptance tests pass for a given user story, that story is considered complete.
  5. Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn’t break anything because you have the tests.
  6. Pair Programming: two programmers sitting at one machine write Code. Essentially, all code is reviewed as it is written.
  7. Collective Code Ownership: No single person “owns” a module. A developer is expected to be able to work on any part of the codebase at any time.
  8. Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
  9. Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
  10. Development team has continuous access to a real live customer, that is, someone who will actually be using the system.
  11. Everyone codes to the same standards. Ideally, you shouldn’t be able to tell by looking at a piece of code which developer on the team has touched it.

Of coarse each company and each project should only implement the practices that make sense to them. Even if you don’t follow all the XP rules, you can still take advantage of some of these practices to improve your development methodology considerably. I’ll talk about the practices that I think are essential in future posts.

Posted in Extreme Programming, Nader | 2 Comments »