Learn the workings of Git, not just the commands

Posted by André on 2016-09-19 (Download as PDF).

When you come from using a classical source code repository like Concurrent Versions System (CVS) or Subversion (SVN), it can be difficult to understand the flexibility and the possibilities of Git. This article tries to explain the workings of Git and how it all fits together, so you don't have to try to remember the commands, but instead just know what to do because you understand it well.

Note: this article has originally been published on IBM's developerWorks website in 27 January 2015, and is here republished within IBM's publishing guidelines. Here is the developerWorks link.

Continue reading "Learn the workings of Git, not just the commands"

What Xerox PARC was really "worth"

Posted by André on 2015-08-04.

Here is an interesting read about what Xerox PARC was really "worth". I often have the feeling that large corporations don't see the value in real invention anymore, but are only on the lookout for "innovative companies" to buy and squeeze out. Which may work for a short term to raise revenue and profit, and thus the share price - until this company has been assimilated, talent has drained to other companies, and a new one needs to be bought.at

Continue reading "What Xerox PARC was really "worth""

Linux remote login

Posted by André on 2015-03-01.

For really a long time I have used a really nice feature of the X11 windowing system - remote login. That was rather easy to do. Just enable XDMCP and connecto to the X server remotely. It was not safe over the networks, but I used it only locally. My main use case was and is using the main PC in my home office from other places.

Now for a few releases the Linux distributions started to disable the protocol, or at least make it more complicated to use, as XDMCP isn't supported in the admin tools anymore.

Continue reading "Linux remote login"

The anatomy of a microbenchmark

Posted by André on 2014-08-04.

Almost two years ago I demonstrated a 10MHz accelerator card for the Commodore PET on the Classic Computing exhibition. For this presentation I wrote a small demo program that draws a 3-D cube on the PET's screen - first with 1 MHz, then with 10 MHz. As I was concentrating on the 10MHz speedup, I didn't have enough time to look deeply into the demo program itself. So it was questioned why it was so slow in 1MHz compared to other demos. Finally I found the time to have a look at this, so I'll make this an example of a performance optimization job. Read on to learn about how the proper approach for a performance optimization even helps fixing performance problems in an old Commodore BASIC program.

Continue reading "The anatomy of a microbenchmark"

The XD2031 architecture explained

Posted by André on 2014-08-02.

Recently I have written about refactoring a 20 year old code base, namely of the file system server code for my old Commodore computers (see here: Refactoring-20-year-old-code... ). Here is a description of the internal structure of that code. I do this description in the form of an "architecture overview", a form that I think is missing for many a software project.

Continue reading "The XD2031 architecture explained"

Refactoring 20 year old code...

Posted by André on 2014-08-01.

When I was working on my selfbuilt 6502 operating system, I had a file system server on the PC, connected to the 6502 via a serial line (RS232). It was using a generic, packet-based protocol on the serial "wire", so I decided to reuse the protocol and the server for an AVR-based implementation of a Commodore disk emulator. The Commodore would talk to the AVR via IEEE488 or the CBM serial IEC protocol, which would behave as a disk drive and use the wire protocol to talk to the PC to server files from there. In the beginning it looked like a good idea. But it took much more time than expected. Read on for the full story.

Continue reading "Refactoring 20 year old code..."

Non-Functional Requirements across the full project lifecycle!

Posted by André on 2014-02-23.

It is a well known fact that bugs are the harder and the more expensive to fix the later they are discovered in the project lifecycle. The cheapest one is the bug not made of course. The most expensive one is when your business critical application crashes and can not be recovered. And everything in between.

Continue reading "Non-Functional Requirements across the full project lifecycle!"

Only fix what's broken (But fix that one right)!

Posted by André on 2013-12-08.

I have often been called into projects to investigate performance problems or to optimize a system for performance. What I find is that performance problems can have a lot of causes. Some are design problems, for example using the wrong algorithm for a problem, or processing items one by one instead of by collection. Others are database problems caused by bad access patterns. Network problems add their share. With the growing complexity of modern distributed systems (think cloud!) the situation is getting even worse. More and more systems and services are being combined to provide the business functionalities. Each one could be the cause of a performance problem.

Continue reading "Only fix what's broken (But fix that one right)!"

Contact

Posted by André on 2013-08-19.

My name is André Fachat, and like the "extra miles" you go in your job, those "extra pages" are what I try to write in my spare time.

Sometimes it's more documentation, sometimes more call to action, sometimes rant.

Most will be about my ongoing hobbies and passions - 8 bit computing for one, with my main page here: http://www.6502.org/users/andre/index.html , but the other is software engineering quality, and more specifically performance and other non-functional requirements.

I work as an IT Architect @ IBM Germany for a living, however, this is my private blog. The postings here are my own and don't necessarily represent IBM's positions, strategies or opinions.

If you want to contact me, you can reach me via email on afachat@gmx.de. It has a strong spam filter and I am pretty busy, so it may take a while for me to answer, though.

I hope you enjoy these pages!

André Fachat