Dani Berg

I always try to have at least one small toy project that I can play with at night. Sometimes it consists of only reading the source code and mailing list from a big project and sometimes my toy project involves writing code and playing with different tools than the ones required by my daily job.

A few months ago I added to my schedule a Windows Day. Brand new world. I dove into Vista, ASP.NET, C#, IIS, MSSQL and Visual Studio one day per week (and occasionally weekends) for a few months.

I was excited because of the novelty. I read a few books on the subject and had  to play with it.

Here are some random thoughts about my experience.

Right on the first day I got frustrated using the mouse for simple tasks like moving and copying files around so I installed cygwin.  A difference between two worlds.

I learned later that there is a Windows option for the command line: Powershell. Although I didn’t try it the Wikipedia article gives me the impression that learning Powershell is probably a good investment for Windows developers.

Back to random thoughts.

I was then ready to try Visual Studio. It is amazing to try examples from books just dragging and dropping icons that build some correctly written snippet of code. I just doubt that experienced developers would follow that approach.

One problem I had with Visual Studio was trying to set the Emacs key bindings. Leaving the keyboard home row to reach keys like arrows, page down and page up is disturbing. I followed this post advice and installed Emacs Everywhere.

The next step was the database. Oh boy, choosing a MSSQL version is so damn confusing! I’m probably getting older and dumber but I couldn’t understand which option to download from the MS website. Installing MSSQL in Vista was quite painful, too. Had to follow some MS black magic recipes to get it running. Installation on Windows 7 Beta was a breeze though.

After setting up the database I went to the HTTP server. IIS is pretty straightforward. You can setup a working environment with just a few clicks.

Working environment ready and I started to follow the books’ examples. A few ASP.NET web forms later and I was ready to start learning C#.

Talking about computer languages is somehow a taboo so it should suffice to say that C# is verbose.

Well, a few months after my first Windows I’m back to a Linux side project but I’m glad that I took some time to get an overall idea about the ASP.NET world. It’s not for me. Once you go open source you never go back.

If you are only interested in building your client project it doesn’t really matter the platform you pick but it’s a disturbing feeling that you can’t build IIS or poke Visual Studio’s source code. There is this sense of being a powerless and passive consumer always trying to catch up every .NET update.

This past week I was documenting part of the system from the company I work for in Brazil, and while running through the payment options code I was again confronted by the ancient file format that bank institutions still use today. You’ll never complain about XML files again if you have to deal with a bank file format in your life.

I don’t know how it works here in the US but years ago banks in Brazil came up with a file format dubbed CNAB to exchange financial transactions. It’s basically a layout where data fields are delimited by their byte positions. Seems pretty straight forward, right? So try implementing one and you will feel the pain.

The first problem is bureaucracy. You need a business account, lots of papers, signatures, phones calls and of course talking to Elaine. She is your bank account manager, really polite and willing to help but obviously completely clueless regarding any technical question. Most of the time she is not allowed to put you in contact with someone who works all day writing Cobol and has all the answers to your questions (I actually empathize with the Cobol guy and pity him whenever he needs to answer the phone).

After everything is set and you are allowed to interact with the bank system via their file format they email you the technical instructions. It’s a word document detailing the layout. Prepare yourself to learn how it works through trial and error and a lucky chance to talk to someone on the phone (yes, a real human being) who actually knows what is the default char for the field delimited between bytes 116 and 118. Is it a blank space or just a zero? Can the file be encoded in UTF-8?

You just need a second bank to send you their layout documentation to prove your inner fear. Each bank implements its own CNAB layout version. This is the time you start praying for a framework to deal with all layout inconsistencies across bank institutions.

All is not lost though. After going through all this you have a new skill set. You are ready to work at any bank institution because you did your homework. You have grasped an understanding of all kinds of bank transactions. You have to do this even if you only want to automate monthly invoices for your customers. It’s a hell of a ride my friend.

Now, I’m not trying to undervalue the CNAB file format. It was probably a good solution 20 years ago. It still works. The problem I see is how banks are outdated compared to companies like Paypal and alike. What are they thinking? Can’t you just build a web interface to deal with your internal file formats? Just give me a Restful Web Service in XML or JSON so I can send monthly invoices or pay the employees.