Psychics, Magic and Cryptology

Stumpled upon a couple of excellent blogs today thanks to GameLife!

Check out Table of Malcontents, "Wired's wonder closet of ephemera, spotlighting those highly creative misfits on the fringe of art and culture", and the posts Psychic Fraud, The Confession of james Haydrick and Million Dollar Challenge.

Table of Malcontents linked to the crypto blog Exhaustive Search, by Matt Blaze, and 27 B Stroke 6, "Your daily briefing on security, freedom and privacy in the wired world".

Table of Malcontents and 27 B Stroke 6 is hosted at Wired blogs.

And there is of course James Randi's site as well.

And yes, you are right if you think you recognized that publication number 27B/6 ...

PKI

When programming crypto you'll sooner or later end up trying to figure out what X509 certificates are all about. Start reading the RFC 3280 Internet X.509 Public Key Infrastructure. And then read Peter Gutmann's excellent article X.509 Style Guide.

Silent Shout, The Knife

Too much programming and no rock'n'roll lately!

Crypto Libraries

I've been posting about OpenSSL earlier since I'm currently using it both for CMS stuff and TLS. And it works reasonable well.

I've started to look into other open/free alternatives as well though. Here is a list of the ones I've found so far:

1. OpenSSL, homepage
2. GnuTLS, homepage
3. Network Security Services (Mozilla), homepage
4. S/Mime Freeware Library (SFL), (DigitalNet, BAE Systems, for US gov), using Crypto++

I've also found a commercial product that Peter Gutmann is involved in:
CryptLib

Cryptography

Here some articles on cryptography in general:

1. Introduction to Cryptography, written by Murdoch Mactaggart and hosted by IBM developerWorks
2. Crypto Tutorial, written by Peter Gutmann and hosted at his homepage

And one more focused on public key:

1. Introduction to Public Key Cryptography, hosted at Mozilla

And at last some lighthearted guides describing various PKI technologies from Carillon.CA!

SSL Basics

Here are articles on SSL/TLS:

1. The Transport Layer Security 1.0 RFC 2246
   
2. The Transport Layer Security 1.1 RFC 4346
   
3. SSL: Foundation for Web Security, by William Stallings, hosted at Cicso
4. Introduction to SSL, hosted at Mozilla

History of Agile

Here is an interesting article about the history behind iterative and evolutionary processes. It is written by Craig Larman and in it he gives examples of iterative processes being used as early as the sixties by NASA!

Jez Humble had the chance to see Craig Larman doing a keynote about the subject on Agile India 2006 and the presentation is available here!

The opposite of agile processes is of course the everlasting waterfall process. The origin of the waterfall process has mostly been cited as the paper Managing the Development of Large Software Systems by Dr Winston Royce. But in fact he describes this method as "risky and invites failure" and actually recommends to "do it twice", ie a simple iterative process!

One of the major reasons for the waterfall process to get such a tight grip on software development process during the seventies and eighties was the US Defense that in standards like DoD-Std-2167 forced a waterfall process. This was later changed to a recommendation of iterative development in Mil-Std-498, as described here. (498 was later replaced by IEEE 12207.)

According to Craig's article "In hindsight, he (the 2167 author) said he would have made a strong recommendation for IID rather than the waterfall model".

Xbox Media Center

Two weeks ago our DVD died and I finally got a reason to mod my old xbox. Been thinking about it for a couple of years now and visiting a friend some months ago demoing xbmc just made me wanna do it more! So I dropped it of at psxcare and got it back a week later with a sweet SmartXX LT OPX chip (with Evox M8 bios), a 160GB drive and some programs including an old version of xbmc installed. It set me back 1600SEK (ie 200$) but so far it is totally worth it! I updated xbmc to the latest release from GasGiver and now everything works perfectly! Watching picures and listening to music stored on our pc (shared on smb), and playing backups of course ripped to the internal harddrive.

So how to update xbmc? Well, I mainly followed the online manual. I had a 1.x version installed that booted on C:\evoxdash.xbe and used the xboxmediacenter.xml (which refered to the application folder C:\xbmc).

1. So I uploaded the new xbmc to F:\Apps\xbmc2
2. Dropped the included .xbe and .cfg on C:\ and renamed them to xbmc2.xbe/.cfg
3. Changed the path in the xbmc2.cfg to F:\Apps\xbmc2\default.xbe
4. Tested them by starting the xbmc2.xbe from my old media centers file manager
5. When everything started OK I made a backup of the old evoxdash.xbe
6. And then renamed my new xbmc2.xbe/.cfg to evoxdash.xbe/.cfg
7. Now the xbox boots to my new media center (and the old installation is still there as a backup...)

Actually it boots to xbmc when pressing the eject button. When pressing the power button the original xbox dash is booted (C:\xboxdash.xbe). This is configurable on the SmartXX chip! (To boot to SmartXX OS just press first power then eject!)

OpenSSL

The best OpenSSL introduction and tutorial is the book Network Security with OpenSSL, by Pravir Chandra, Matt Messier, John Viega.

So far the best online documentation I've found is An Introduction to OpenSSL, written by Holt Sorenson and published at Security Focus.

And of course there is the online manual pages...

Update 20070315
Found another article focusing on using SSL/TLS. An Introduction to OpenSSL Programming, part 1 and part 2 by Eric Rescorla hosted at Linux Journal.

Agile development processes

The Developer Bill of Rights
• You have the right to know what is needed, via clear requirements, with clear declarations of priority.
• You have the right to say how long each requirement will take you to implement, and to revise estimates given experience.
• You have the right to accept your responsibilities instead of having them assigned to you.
• You have the right to produce quality work at all times.
• You have the right to peace, fun, and productive and enjoyable work.

The Customer Bill of Rights
• You have the right to an overall plan, to know what can be accomplished, when, and at what cost.
• You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.
• You have the right to change your mind, to substitute functionality, and to change priorities.
• You have the right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date. You can even cancel at any time and be left with a useful working system reflecting investment to date.

The quote above is from Robert C. Martin´s article The Process. I think it describes the purpose of agile processes in an excellent way!

There is quite a lot of material available online about agile development processes, but the best introduction I've read is still a book, Agile and Iterative Developmen: A Manager's Guide, by Craig Larman.

Here are some links to articles and repositories on the internet:

1. Manifesto for Agile Software Development
2. The New Methodology, by Martin Fowler and hosted at his site
3. The declaration of interdependence for modern management (agile project management), by Alistair Cockburn, his site has lots of interesting articles.
4. RUP resources at IBM, e.g. Top five RUP implementation process killers and RUP in the dialogue with Scrum
5. RUP resources (and other) at Dunstan Thomas, e.g. More RUP Anti-Patterns
6. Agile UP, by Scott W. Ambler at Ambysoft, lots of other articles as well
7. The Process (a minimal UP call dX), by Robert C. Martin, hosted at Object Mentor

Goldeneye live-action, N64

Hahaha! Goldeneye rules! Thanks to zakiechan and joystiq for the tip!

The Weeping Song, Nick Cave and the Bad Seeds

Patently Absurd

Patently Absurd is a very interesting article about software patents written by James Gleick. It is a couple of years old but I haven't read it until now.

Squash That Fly, Fu Manchu

Books you need to buy

If you haven't got them already, buy them. Books are still the best source to programming and development knowledge.

General
Software Fundamentals: Collected Papers, David L. Parnas
Code Complete, Steve McConnell 2004

Development Processes
Applying UML and Patterns, 3d edition, Craig Larman 2004
Agile and Iterative Developmen: A Manager's Guide, Craig Larman 2003
Agile Software Development, Principles, Patterns, and Practices, Robert C. Martin
The Pragmatic Programmer: From Journeyman to Master, Andrew Hunt, David Thomas
Practices of an Agile Developer: Working in the real world, Venkat Subramaniam, Andy Hunt

Design Patterns
Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Refactoring
Refactoring: Improving the Design of Existing Code, Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Working Effectively with Legacy Code, Michael Feathers

C++
The C++ Programming Language, Bjarne Stroustrup

COM
Essential COM, Don Box 1997
Inside Com (Microsoft Programming Series), Dale Rogerson 1997
ATL Internals (The Addison-Wesley Object Technology Series), Brent E. Rector, Chris Sells 1999
Programming Distributed Applications With Com & Microsoft Visual Basic 6.0, Ted Pattison

Windows
Programming Windows, Charles Petzold 1998
Programming Windows With MFC, Jeff Prosise 1999

MFC
MFC Internals: Inside the Microsoft(c) Foundation Class Architecture, George Shepherd 1996

Computer Security
Applied Cryptography: Protocols, Algorithms, and Source Code in C, Bruce Schneier 1995
Building Secure Software, Gary McGraw 2001
Exploiting Software, Gary McGraw 2004
Software Security: Building Security In (Paperback), Gary McGraw 2006
Writing Secure Code, Michael Howard 2002
Secure Programming Cookbook for C and C++, Matt Messier, John Viega 2003

OpenSSL, SSL, TLS
Network Security with OpenSSL, Pravir Chandra, Matt Messier, John Viega 2002
SSL and TLS, Eric Rescorla 2000

Another pattern!

Martin Fowler is a smart guy that works as chief scientist at Thought Works.

He has written an article about a pattern called Dependency Injection (a.k.a Inversion of Control) that is really interesting. This pattern can be used to reduce coupling.

And another one about Continuous Integration. Since this is a practice and not a pattern or principle it nicely leads us into the upcoming posts about development processes!

More about principles (SOLID)

Since the previous post only mentioned coupling and cohesion I thought that I'd make another post on the subject. Robert C. Martin who works for Object Mentor (their blog) has written a interesting series about principles and the following quote is from the Dependency Inversion article.


The definition of a bad design

Have you ever presented a software design, that you were especially proud of, for review by a peer? Did that peer say, in a whining derisive sneer, something like: “Why’d you do it that way?”. Certainly this has happened to me, and I have seen it happen to many other engineers too. Clearly the disagreeing engineers are not using the same criteria for defining what “bad design” is. The most common criterion that I have seen used is the TNTWIWHDI or “That’s not the way I would have done it” criterion. But there is one set of criteria that I think all engineers will agree with. A piece of software that fulfills its requirements and yet exhibits any or all of the following three traits has a bad design.

1. It is hard to change because every change affects too many other parts of the system. (Rigidity)

2. When you make a change, unexpected parts of the system break. (Fragility)

3. It is hard to reuse in another application because it cannot be disentangled from the current application. (Immobility)

Moreover, it would be difficult to demonstrate that a piece of software that exhibits none of those traits, i.e. it is flexible, robust, and reusable, and that also fulfills all its requirements, has a bad design. Thus, we can use these three traits as a way to unambiguously decide if a design is “good” or “bad”.

The Cause of "Bad Design"

What is it that makes a design rigid, fragile and immobile? It is the interdependence of the modules within that design.

A design is rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules. When the extent of that cascade of change cannot be predicted by the designers or maintainers, the impact of the change cannot be estimated. This makes the cost of the change impossible to predict. Managers, faced with such unpredictability, become reluctant to authorize changes. Thus the design becomes officially rigid.

Fragility is the tendency of a program to break in many places when a single change is made. Often the new problems are in areas that have no conceptual relationship with the area that was changed. Such fragility greatly decreases the credibility of the design and maintenance organization. Users and managers are unable to predict the quality of their product. Simple changes to one part of the application lead to failures in other parts that appear to be completely unrelated. Fixing those problems leads to even more problems, and the maintenance process begins to resemble a dog chasing its tail.

A design is immobile when the desirable parts of the design are highly dependent upon other details that are not desired. Designers tasked with investigating the design to see if it can be reused in a different application may be impressed with how well the design would do in the new application. However if the design is highly interdependent, then those designers will also be daunted by the amount of work necessary to separate the desirable portion of the design from the other portions of the design that are undesirable.

In most cases, such designs are not reused because the cost of the separation is deemed to be higher than the cost of redevelopment of the design.

So how do we solve these problems? Well there following principles (SOLID) gives us some guidelines:

Single Resonsibilty principle (the same as cohesion)
There should never be more than one reason for a class to change.
If a class has more then one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.


Open-Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad” design. The program becomes fragile, rigid, unpredictable and unreusable. The openclosed principle attacks this in a very straightforward way. It says that you should design modules that never change. When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works.

Liskov Substitution Principle
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

The importance of this principle becomes obvious when you consider the consequences of violating it. If there is a function which does not conform to the LSP, then that function uses a pointer or reference to a base class, but must know about all the derivatives of that base class. Such a function violates the Open-Closed principle because it must be modified whenever a new derivative of the base class is created.

Interface Segregation Principle
Clients should not be forced to depend upon interfaces that they do not use.

When clients are forced to depend upon interfaces that they don’t use, then those clients are subject to changes to those interfaces. This results in an inadvertent coupling between all the clients. Said another way, when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class. We would like to avoid such couplings where possible, and so we want to separate the interfaces where possible.

Dependency Inversion Principle
A. High level modules should not depend upon low level modules. Both should depend upon abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

The structure that results from rigorous use of OCP and Liskov can be generalized into a principle all by itself. I call it “The Dependency Inversion Principle” (DIP).

Consider the implications of high level modules that depend upon low level modules. It is the high level modules that contain the important policy decisions and business models of an application. It is these models that contain the identity of the application. Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change.

This predicament is absurd! It is the high level modules that ought to be forcing the low level modules to change. It is the high level modules that should take precedence over the lower level modules. High level modules simply should not depend upon low level modules in any way.

Most of these principles and some others covered in the article Design Principles and Design Patterns as well.

Object Mentors article archive is here and the ones related to object oriented design are here.

Update 090827!
The principles of OOD

Design principles and patterns

Principles and patterns are really interesting to know a bit about. Foremost of course since you become a better programmer when you have some knowledge about how to best solve a problem. Which is the basic idea behind these thoughts. Principles are ideas that are always true and that you should try to abide to at all times. Patterns are templates for solutions that you can combine (which are of course based on the principles).

To have some knowledge about principles and patterns also makes discussions about different solutions and their pros and cons so much easier since you don't have to explain in detail what you doing. You can just put it like "...and then we use a bridge pattern to...". Or "someone totally forgot about single responsibility when designing this and now everything sucks". Excellent don't you think!

Here are a couple of resources:

1. GRASP (General Responsibility Assignment Software Patterns), Craig Larman came up with these (or do he just refer to them? can someone plaease set me straigh on this issue?) and they are well documented in his superb book Applying UML and Patterns
2. SOLID, Robert C. Martin
3. GoF (Gang of Four) Patterns, the mother of all patterns, these patterns were originally published in the book Design Patterns by Eric Gamma, Richard Helm, Ralph Johnson and John Vlissides
4. Patterns and Principles, a page that refers to the above and more and links to other excellent sites as well
5. David Hayden has some nice articles in his archive about the GRASP patterns.

Blogging in the country side

Alright, the network at my parents place that I talked about in the ZyXEL post have actually started working. They have a Telia ADSL .25 Mbit so it's not the hottest line in town. But maybe in the country side. The telephone wires are running in the air the last couple of kilometers so its really old school and I'm quite impressed that it works at all! So now me and my brother can blog instead of watching boring tv in the evening!

UML

It's always nice to know a little bit if UML when you want to explain a design for someone. Perhaps to yourself if no one else is interested?

Here are two nice links:

1. Guide to UML Diagrams, hosted at .netCoders
2. Unified Modeling Language Syntax Reference, written by Claudio De Sio Cesari and hosted at his website

Rebellion (Lies), Arcade Fire

Alright, I know I'm the last one to find out about this band...

Friday

Ok so far I've only posted old links that I used in old projects in old jobs so I've got a bit bored. But I'll soon finish off the old stuff with some really interesting links about design, patterns and development processes. That'll cheer me up! And after that I'll dig into the current stuff I'm doing, network security! Wohaa!