Playing around

Submitted by Vidar on

Just checked: my previous blog post was published in March 2013! Nearly two years ago.

It's been a crazy couple of years!

It's been a period that probably have the potential for some blog posts in the spirit of Marcus Hammarberg (a big inspiration, and well worth reading.) But, it also mean I've gotten to do less coding at work, and definitely less fun and exciting coding.

The solution?

A fun and exciting side project of course!

Work and play are words used to describe the same thing under differing conditions.

-Mark Twain

On the inferred reality of F# and the mysterious appearance of the equality constraint

Submitted by Vidar on

mysterious.jpg

Photo by Kees de Vos
(CC license)

I was happily coding away passing functions around and I was adding a function to a list when it appeared:

 f# list does not support the 'equality' constraint because it is a function type

I was a bit puzzled by this. I was quite sure functions where regarded first class citizens in the realm of F#. In fact I had recently added another function to another list without any complaints.

I spent quite a bit of time trying to figure out what caused this. Try googling for answers with the words F#, function, and list in them, not an easy combination when dealing with a functional language. I tried creating simple test cases, but I could not seem to provoke the same error. At some point I started pondering less rational explanations like perhaps my list felt discriminated in some way, or was upset because it was starting to get late.

Extending the Lokad DSL tool

Submitted by Vidar on

antlr.jpg

Photo by Al_HikesAZ (CC license)

What, where, why

I need to fast forward past several planned blog topics to establish a context for this one:

  • I'm working on a legacy VB6 app that is about to get some ddd, messaging love in the process of moving off the VB6 platform.
  • I've landed on using the Lokad DSL tool (Github) for defining messages.

The Lokad dsl tool does what it says on the box: It lets you define immutable, datacontract serializeable, message classes. But without all the mind numbing typing normally required to write out such classes in C#.

DSL code:

AddSecurityPassword?(SecurityId id, string displayName, string login, string password)

Becomes c# code:

[DataContract(Namespace = "Sample")]
public partial class AddSecurityPassword : ICommand<SecurityId>
{
    [DataMember(Order = 1)] public SecurityId Id { get; private set; }
    [DataMember(Order = 2)] public string DisplayName { get; private set; }
    [DataMember(Order = 3)] public string Login { get; private set; }
    [DataMember(Order = 4)] public string Password { get; private set; }
 
    AddSecurityPassword () {}
    public AddSecurityPassword (SecurityId id, string displayName, string login, string password)
    {
        Id = id;
        DisplayName = displayName;
        Login = login;
        Password = password;
    }
}

But I needed more

There is another branch of c# coding that requires a lot of typing:
COM interop code.

Categories: 

Cleaning up legacy mess by functional composition

Submitted by Vidar on

In my experience Vb6 is used mostly as a procedural language, with objects used without the author knowing it's actual objects (like the auto instantiating of forms.) In a lot of cases you'll inherit (no sane person would start a new greenfield Vb6 project, right?) a collection of subs and functions that are mostly global.
You'll find that after a while common functionality got called from several different places, and the original author found that something needed to be done slightly different for the latest use case.

Categories: 

Bending Vb6 in the functional direction

Submitted by Vidar on

Update:Code available and developed further on GitHub

A substantial amount of my day to day work is spent maintaining a legacy VB6 codebase.
Unfortunately I also create new features for our users on slightly less ancient platforms.

This has the unwanted side effect that back in the land of VB6 i miss some of the language features from the newer platforms.

The feature I miss the most is probably an efficient way of working with collections.
In C# there's linq, in most functional languages there are som variant of map/reduce functionality.

In VB6 you have loops.

Categories: 

Sequence diagrams with VIM and PlantUML

Submitted by Vidar on

Today I needed to sketch out some ideas on how to model a process.
I've found that simple sequence diagrams are often useful to visualize how a process flows. Combined with the mighty tools that are paper and pencil I can quite quickly grasp the structure of an otherwise abstract idea.

Going digital

Some times though, the paper and pencil approach comes to short.
This could be because I need to work on an idea over a longer period of time. Or it could be because the diagram is rather complicated and I find myself changing large parts of it. The result either way is that the diagram gets really cluttered, and so loses its ability to help me structure my thoughts.
And this is when moving to a digital tool can help.
There's no shortage of diagram creation tools out there, but I've found that the majority takes too much effort to use efficiently. The result is that I spend more time thinking about how I use the tool rather than the idea I'm sketching out. I'm sure those tools have their place too, but it's probably not quick sketching and structuring of ideas.

Following up on my Simple.Data Faking experiment

Submitted by Vidar on

A couple of weeks ago I blogged about an idea I had for mocking (and / or stubbing) database results from Simple.Data.
Since then I've attempted to write out my ideas, and I've gotten the project into a state where it actually is usable for some cases.
In short this post will be explaining how to use Simple.Data.FakeResult.

Categories: 

Mocking database integration with Simple.Data

Submitted by Vidar on

I just discovered what might be a super-duper-happy-path to mocking database integration using the Simple.Data framework.
Mocking Db integration seems to be a constant source of frameworks and practices. And now I've got one myself.

Some context

The Simple.Data framework allready provides an XML mocking provider that allows you to define data in xml that later can used as a datasource.
Using this provider can be rather cumbersome as you have to define all your data up front in XML.
But:
Simple.Data is based the .Net 4 dynamic realm, and all return values are allways dynamic. This fact provides us the freedom to simply replace whatever Simple.Data returns, with our own mock data.
The only requirement is that the call to Database.Openxxx is abstracted into som kind of wrapper, as the starting poin in Simple.Data is a static factory class (Simple.Data.Database) and thus it cannot be intercepted.

Categories: 

Pages

Subscribe to zbz5.net RSS