Sector 0

October 21, 2013

A Memoir of an Architecture – Exceptions contra Return Values

Filed under: Uncategorized — frank @ 19:37

Today I read this question on ars technica which mirrors a question I was asked a few weeks back by one of the junior programmers: why don’t we return booleans or error objects or whatever when something goes wrong in the server? After all, collective wisdom has it that exception handling is slow – unwinding the stack can be a lengthy process, relative to almost anything else in CS, except perhaps I/O.

Indeed, exceptions are slower than just returning a boolean or a string or, as the article suggest, an exception. But that is not an argument. There are extremely good reasons for electing to use exception handling, besides “this is how everyone else does it”.

For this project I have chosen to use exceptions as the primary mechanism for communicating errors; exceptions are for exceptional conditions, and by nature they should be the… well, exceptions.

The reasons for using exceptions are

  • They are a built-in mechanism for handling exceptional conditions, at least in imperative, object oriented languages (functional languages have another standard mechanism).
  • They provide a natural way to halt execution; when using return values instead you force the programmers to actually handle the error in an if-statement. This means that the programmers must constantly be aware of this fact, and manually halt/branch execution due to an error condition, which is a source for errors in the code.
  • Uncaught exceptions are shown immediately when they occur, given that the software will eventually be in the state that produces this error. On the other hand  a return value, which the programmer forgot to check for, goes unnoticed.

This doesn’t mean that exceptions should be used any where, any time. In some pieces of the code it might be better practise to use return values instead. For example in often-run methods, or methods that often fail due to error conditions.

Good unit tests must prove the validity and correctness of the code for any error condition, regardless of mechanism.

October 17, 2013

A Memoir of an Architecture – Dude, Where’s My Database Connection?

Filed under: Uncategorized — frank @ 19:08

Today I had a nice long talk with one of our junior developers. “I have a problem”, he said. “I don’t understand the architecture”.

This guy is fresh from the university so he has no experience, nor knowledge, of how to actually build enterprise level systems.

I said to him that we are on a tight schedule here, that parts of the architecture is still being worked out in my head.

But these kinds of problems has already been taken into account in the design. What brings value to the project? Business logic. Not boiler plate, not supporting infrastructure, not cross-cutting concerns.

Well, I don’t actually mean that is doesn’t bring any value. Sure it does. But this type of code is often very complex and must be written by senior developers. Having the bulk of the developers focusing on the pure business logic without having to concern themselves with how to do auditing, what to do when the database does this and that, authentication, authorisation, et cetera brings value and momentum in a project. Business logic. That is what the software is all about, after all.

So having only pure business logic in the services simplifies a lot of things. Having dependencies abstracted away and injected for you just makes it easier. When I am writing a piece of code that handles updating some part of the domain, should I worry about what persistent storage is used? No.

Storage and retrieval of domain objects and the logic behind that we abstract away in a repository layer. That layer is even so simple that it can be handled by 3 different generic repository classes. More on that later.

Services, dependencies and aspects

Services, dependencies and aspects

(more…)

October 16, 2013

A Memoir of an Architecture – The Initiation

Filed under: Uncategorized — frank @ 21:44

A short while ago I had the good fortune of landing a job as an application architect and team lead at CompuGroup Medical Denmark. It was one of those rare opportunities where you get to start from scratch.

The task: design and implement the next generation eHealth platform for the primary health care sector. No legacy code. No one-to-one code “conversion” where you just reimplement the same stuff in another language (yes, those types of projects exist – for what ever reason). No “we’ve always done it this way so it should work again”.

Yes, a rare opportunity indeed. Needless to say, I accepted the challenge.

(more…)

August 1, 2011

Monadic Parsing in F#

Filed under: .NET,F#,Functional Programming,Programming — Tags: , , — frank @ 21:25

This article is also available in PDF

Abstract

This article is a short tutorial on how to write extensible recursive
descent parsers with no mutable state using monads in F#. The parsers
that are build using the techniques described here are able to accept
ambiguous grammars, and have arbitrary lenght lookahead. These LL(*)
(Parr 2007) parsers are not limited to any finite number of lookaheads.
Although this potentially reduces performance in comparison to machine
generated bottom-up parsers, the techniques described in this article
will make simpler and more elegant parsers. Also the parsers eliminate
the need for lexical analysis (tokenization) which is done on the
fly.

(more…)

November 15, 2008

Is IronErlang (or Erlang.NET) a Good Idea?

I am kind of between projects right now so I am wondering what I should do next. I really like functional programming, and in particular languages like Erlang, Haskell and F#. So I started to wonder if I should make an Erlang compiler for the .NET runtime.

I like Erlang for a number of reasons: It is simple, it is a functional programming language, the language is designed around the actor-model for interprocess (Erlang processes that is) communication, a system written in Erlang is very robust, and creating computing clusters and high-availability servers is almost too easy.

So if I am about to start making an implementation of Erlang for the .NET platform there are a few obstacles and questions that needs to be addressed first:

(more…)

Data Parallelism in Functional Programming

In this small article I will show you how you can use the power of functional programming to write data structures for parallel processing that scales well on any number of cores.

What is one of the primary concerns for programmers right now? Writing high performance code that scales well regardless of whether the software is running on a CPU with one, two or 1000 cores.

Todays software does not scale well, and one of the major obstacles is making it run efficiently on multiple cores without encountering the problems that are bound to arise when programming with multiple threads. When dealing with parallel processing data parallelism is a great tool to accomplish the goal of writing highly scalable software.

In functional programming a list is one of the most fundamental data structures you can find. Furthermore it is also great for – say – iterating, and it is very easy to make parallel. I will show you a few examples written in F# – a functional programming language for the .NET platform with roots in ML and OCaml. I will demonstrate the principles with a simple data type (PList) that can be used in a wide variety of ways for processing data, and which utilizes the number of cores in your computer without you having to worry about it.

Finally I will endulge in a bit of theory for extending this data structure to span multiple machines connected in a computing cluster.

(more…)

November 9, 2008

The Programmers Dilemma

Filed under: Architecture,Design,gobbledygook,Programming,Test — Tags: , , , — frank @ 14:32

So what is all this talking about “automatic testing”? I know my code work so I don’t have to write some “test case” just to verify that; A complete waste of time!

Just kidding. No one in their right mind would say that they write bugfree code. One of the tools to help weed out the bugs before the code hits production is automatic testing, more specifically unit testing. This helps fix some problems but it also presents some of its own.

The Dilemma

The dilemma I am constantly finding myself in is this: I want to make beautiful code and design, but I also want to make sure it is functioning as it should. Now, there are a number of more or less subtle ways to (more…)

August 9, 2008

F# at JAOO 2008 in Aarhus, Denmark

Filed under: .NET,F#,Functional Programming,JAOO — Tags: , , — frank @ 14:19

For a while I have looked at the schedule for the JAOO conference in Aarhus, Denmark this year, and thought: What a pity there is so little about functional programming. I mean, functional programming is really moving into the mainstream developer community these years as yet another (and very powerful) tool in our toolboxes. But that is not reflected in the schedule for JAOO, unfortunately.

There was one presentation of Scheme but the speaker (and I simply can’t remember his name, sorry) unfortunately cancelled. Fortress has been put on the schedule and I managed to get Robert Pickering to come and talk about F#. I also talked to Chris Smith and I am currently trying to persuade the conference organizers to put him on the schedule too. It is a bit late in the process but I am doing my very best!

So pack your tooth brushes and laptops and head for the nearest airport or train station. I look forward to meeting you at JAOO!

June 22, 2008

Using NUnit with F# code

Filed under: .NET,F#,Functional Programming,Programming,Test — Tags: , , — frank @ 21:58

Switching to another programming language is difficult. Especially if you are switching from an imperative one to a functional one. There are a number of reasons why you would think that switching is bad, and when considering F# I dare say that none of those reasons are correct. The language compiles to IL (Intermediate Language) code that runs on Microsofts tried and tested .NET runtime (or Mono’s ditto). You have access to all the same classes in the .NET hierarchy that you have from any other .NET capable language. You can write web applications, WinForms applications or console applications in F#. You can connect to any kind of database that you can connect to from any other .NET language. You can use your existing C# og VB.NET code in your F# applications, or you can write F# code and use it in your existing applications. You have the opportunity to write more concise and maintainable code in a language that has much higher performance than any other functional language I know – with the possible exception of Clean, but that is still debatable, and you can mix functional programming with object oriented ditto at your leasure.

But what about testing? In these TDD (Test Driven Development) oriented days being able to properly test your code with automated unit- and integration tests is paramount. And if you have to use another (or perhaps write your) test framework than the one you are already using and familiar with, that might be an insuperable problem. Fortunately you can easily use NUnit with F# and I will show you how. (more…)

Huffman encoding in F#

Filed under: .NET,F#,Functional Programming,Programming — Tags: , , , — frank @ 13:24

For a while I have been toying with F# – a strict, functional programming language – primarily to get to know the language. I have written a few utility programs and I am working on the problems defined on the Project Euler site. These mathematical problems are perfect for being solved in a functional programming language and it is a great way to work with a new language as well as getting a brush-up on your mathematics.

I have made an implementation of the Huffman compression algorithm in F# to showcase a few of the important things that make functional programming so great to some classes of problems.

Huffman tree generated from the text 'this is an example of a huffman tree'. Source:wikipedia.org

Huffman tree generated from the text ‘this is an example of a huffman tree’. Source:wikipedia.org
(more…)

Older Posts »

Powered by WordPress