luni, 16 februarie 2009
Sharepoint ISO Week Number
luni, 12 ianuarie 2009
Death to the ORMs
“Necessary evil” is just an excuse for incompetence in finding a solution for a hard problem. There is a long history of applications that didn’t require the user to rewrite the database schema in order to access the data: xBase, MS Access, SSMS, LINQPad. I can’t stand the nonsense surrounding the so called solutions for accessing data from a database, not counting the religious wars on what’s the best ORM. They’re all crap.
Most programming languages, especially the OO breed, are not adapted to data manipulation as good as the plain old SQL. Microsoft made some progress on this front with LINQ and the Entity framework. But that’s not enough, and it has a fundamental flow: it should have been started as a “Set-Based”, not “Entity” framework.
So, a decent set of requirements that an acceptable development platform for enterprise data applications should provide to its users is:
- set based data access
- standard GUI toolkit, geared towards data manipulation (NOT web based)
- standard business logic specifications
- database based security
Subject for the next post: how crappy are web based data applications.
vineri, 5 decembrie 2008
Thoughts on Software Security
You still use bla bla bla Internet Navigator v13.2.256.2?! Don't you know that it's full of security holes? You should usee YYY Firedog 2012 because it's secure and hip, and soon everybody will be using it!
marți, 2 decembrie 2008
Thoughts on Programming Languages
vineri, 28 noiembrie 2008
Running Linux Apps Seamlessly Insinde Windows for 100EUROS or Less
- Get a license and install windows (XP/2003/Vista): blah, blah, blah, next, next, finish ... ~100E for Vista Home Premium
- Download & install Virtual Box: blah, blah, blah, next, next, finish ... 0E
- Download & install Ubuntu (latest): blah, blah, blah, next, next, finish ... 0E
- Press <Host key> + L ... priceless
Tada!
PS: this post was written with Google Docs on Firefox running on Ubuntu linux running on Microsoft Windows 2003.
PPS: only one operating system was restarted during the creation of this post.
miercuri, 19 noiembrie 2008
sâmbătă, 18 octombrie 2008
Python can do:
sqlalchemy.dburi="mssql://
Next step: run TurboGears behind IIS in order to use Integrated Windows Security.
Even further: investigate if IronPython fits somewhere.
vineri, 15 august 2008
Internet Censorship
I thought that the Internet’s purpose was breaking communication barriers:
I’ve seen this situation becoming more and more common. What’s interesting is that it’s not a subtle limitation. They could have made all the links going to the limited content not available to people outside the USA. Hmm…
Update: http://timheuer.com/blog/archive/2008/08/13/nbc-olympics-behind-the-scenes.aspx
joi, 14 august 2008
Punitive Software Development
The current project manager I’m working with, answers to all my whinnying about things that I don’t like in the current project with “M, you’re always complaining about the project and what a torture it is to work on it. You should take my example: I’ve been working on crappy software projects for the last 1134 years and I’ve never complained!”.
To which I respond “Yeah you’re kind of right, but I want my life expectancy to be greater than 50, and I don’t find premature gray hair sexy”. Of course, I don’t say it out loud.
What did I learn from my experience with software projects:
- software projects are always short on time
- software projects must build upon and fix older, incomplete-or-completely-failed, software projects
- there aren’t enough good developers around
- developers have to completely rely on business analysts for the communication with the client
- business analysts will always be more focused on gathering request from the client, rather than trying to find solutions for their problems with the tools that the developers can provide
- the test team will be treated as if they are from Bangladesh even if they work in an office next to yours
- agile techniques are just for showing off: “Yeah, we have a two week release period for each of our builds, and we hold daily scurm meetings, and we are so agile and so extreme that I just can’t stop looking at myself in a mirror”. Yeah you dumb agile f#*k. Just a little more agile and you could lick you own balls. You think you’re agile, but you still plan a project into requirements gathering, development and implementation. Really agile, no waterfall in here. If you wouldn’t have realized that regular testing ensures that your piece of crap software is less shitty (this is the original test driven development: give the test team something that barely resembles a software product and hope they will guide you towards an acceptable application), you’d still be doing testing at the end of the development phase.
All of this must change…
vineri, 1 august 2008
Code Generation Is Bad, M’kay?
Code generation: problem solver.
Composition, abstraction, design patterns, a walk in the park thinking of a better solution: constructive techniques.
It often tempts me to use code generation when I’m facing a problem that requires a lot of code to be written in order to solve each of it’s instances (ex: classes in the data access layer). It is the case when I’ve already used all the tools in my (small) development arsenal, and it seems I can no longer simplify and reduce the code that needs to be written by the clients of the solution. The clients being, in most cases, myself.
And the most annoying thing is that I feel there is still too much repetitive code or logic, and there must be a better way around it. But the programming language doesn’t want to help me anymore, and I can’t think of any other solution. And I try to scribble other designs, and when I think I’m onto something, and try to translate the new solution into code, there is always a catch, some missing feature of the framework library, or of the language itself, or a glitch in my logic.
And there’s the Code Generator behind me, grinning, telling me: “You know you can’t avoid me…”. But I keep on trying: “Go away, leave me alone, there must be a better solution to all this crap (that I’m mostly to blame for)!”. And he goes: “Don’t ignore me, I might be your best friend at the moment.” - “But I hate you! You are possessive, you give my code inertia, and I suffer headaches when I try to make even the smallest change.” - “Hmm, that’s an oxymoron: the best friend you hate the most. C’mon, see the bright side, your code will barely change. It will look as young as when you first wrote it, even after years of use and abuse. It will become immortal :).”
Finally I give up and I try to make up for the compromise I’m committing: “At least I will generate very beautiful code, with all the comments it needs and exception handling and bells and whistles. And there will be extension points, so I will be able to add more features to the definition, like automatic validation-based-on-some-obscure-rules-that-I-will-come–up-with…”. And I feel sad…
Well, I can’t be sad about my work. I’m still a programmer because I like programming, and I expect that software development should bring me joy and fulfillment, not frustration and sorrow. That’s the moment I start to think that if my system was built the right way, every feature should be replaceable. I don’t have to bang my head into finding a perfect solution for a functionality, that will probably be replaced in the future.
Ok, so what I really need to take care of is that the generated code is isolated enough so other parts of the system don’t have direct dependency on it, but rather on a contract the generated code implements. Maybe a smarter person will find a solution for my problem, and they usually do. At that time I’ll be able to end my unpleasant relation with the code generator, and look behind and smile.
Resources
http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell
miercuri, 23 iulie 2008
The Evils of Shared Check Out
I won’t discuss the obvious what-do-you-do-when-somebody-else-checked-in-before-you-and-now-you’ve-ended-up-resolving-the-conflicts. I think there are more subtle motives why the version control shared check out has negative impact on modern software development.
I believe that the shared check out feature of most source control system (svn, cvs, tfs) originated in a time when developers worked on huge code files, when solving one bug meant making adjustments in more than one of these monstrosities at the same moment. In a time of stone age development tools, when modern programming concepts like OOP and FP were in still in the realm of academia and of obscure languages.
The tools and languages evolved, but the way they were used had its own inertia, based on human habit and familiarity with a way of “doing things”. Forget about one class - one concern, some people are still struggling with one function – one concern.
The conclusion is that if you are aware of a couple of development techniques, there will be no need for shared check out. One class should be modified for only one reason, so two people don’t have to edit it at the same time.
Of course there are counter examples. I already hear people shouting “configuration files”, “generated code files” etc. Those are exceptions and at the same time, they are not. If you’re willing to break the structure into small, manageable parts, you’ll find a solution for them. And if you really need to store many things into one file, be sure to set rules for how people should edit it, so they know how to not get into trouble. This is a similar problem to using only pure functional programming. FP is great, but you’ll need to modify state sometime: make sure you’re doing it in a standard, isolated way, so when a problem arises you’ll know what you’re dealing with.
marți, 22 iulie 2008
Why You Should Write Your Own O/R Mapper ... Or At Least Try
The down side is that the period of time before you choose to "upgrade" to an already existing solution will seem a waste, and all the code you've written must be thrown away. That won't be an issue if you keep in mind that things are replaceable and if you build a loosely coupled designed so components, like the data access layer, can be replaced, almost, effortless.
This pattern applies to other general "patterns", like dependency injection containers. Hands on experience with their "entrails" should give you a better understanding of how they work, and a better appreciation of the ones that are already available. And chances are you've already tried to build something similar but never knew exactly what you wanted, or what the big picture of the solution is.
vineri, 18 iulie 2008
Nice Design Example for a Simple Data Access Layer
The series is centered towards refactoring an existing solution to a better design, employing well known patterns and practices. But the interesting part is that at the end the result is a nice blue print for a general data access layer based on Linq. And a really good start point if you're trying to build one.
Below are links for the six parts of the series:
Separation of Concerns - how not to do it
Separation of Concerns by example: Part 1
Separation of Concerns by example: Part 2
Separation of Concerns by example: Part 3
Separation of Concerns by example: Part 4
Separation of Concerns by example: Part 5
joi, 17 iulie 2008
Linq to SQL Server CE and uniqueidentifier columns
The second issue is that uniqueidentifier columns with the rowguid property will not work. More precisely, they will not autogenerate a value upon inserting a new row. Setting the column property to IsDbGenerated in the dbml mapping file is even worst: it will crash the insert operation. There is a workaround for this problem: in the partial class of the respective table entity, create the partial method "OnCreate" and manually set a new Guid for the new record:
partial void OnCreated()
{
if (ID == Guid.Empty) ID = Guid.NewGuid();
}
luni, 3 decembrie 2007
Implementing a Double Linked List in C# - part III
Welcome to the third part of the series on implementing a double linked list. It is now time to finalize the basic functions of the list, as well as some extra helper functions. The latter have the purpose of easing the use of the list for its users.
In this episode we'll cover the following:
- Delegate some of the concerns of the list to its nodes;
- Implement the IEnumerable interface, and the associate iterator;
- Add a bit of "closure" to our list.
- Removing items from the list
Preamble
The main difference between our implementation of the doubly linked list and the one provided by the .Net framework, is in the accessibility of data. While the .Net framework version exposes the data through the nodes containing it, we, on the other hand, expose it directly. This might be a shortcoming in terms of flexibility for navigating locally in the list. But the benefits come in form of structural integrity of the list, while permitting low level alteration of the structure of the list, and a better user experience in terms of accessing the data. What I mean by keeping control over the structural integrity of the list is that the consumer of the list can't make modifications that could break the chain of references or desynchronize the count of nodes, but the list can make modifications at that level internally. Of course these low level operations are also available to the inheritors of the list.
Revisiting the Node Class
Until now we've managed to ignore the Node class, but she "feels" that and tells us: "Listen, I'm pretty good at holding hands (references) with my left and right neighbors, so let me add new neighbor nodes as well as remove myself from the list". So we delegate to the Node class the concern of "keeping up references" during the operation of the list.
Adding a neighbor to the left of a node, means that we have to change:
- the reference of the original left node to its right node, to the new node;
- the reference to the original left node, to the new node;
- the reference of the new node's left node, to the original left node;
- the reference of the new node's right node to the current node.
public Node<T> EnchainBefore(T item)
{
Node<T> node = new Node<T>();
node.Data = item;
node.Previous = Previous;
node.Next = this;
Previous.Next = node;
Previous = node;
return node;
}
Removing the current node means we have to make its two neighbors reference each other:
public void RemoveFromChain()
{
Previous.Next = Next;
Next.Previous = Previous;
}
Implementing the IEnumberable Interface
The interesting part is not implementing the IEnumerable interface, but the IEnumerator. The twist is that the enumerator must "enumerate" through the list in two directions: forward as well as backward. Essentially the iterator will follow the chain of references starting with the left sentinel and ending with the right sentinel for forward enumerating. The iterator will go the other way around for backward iteration. This logic is embodied into the MoveNext method:
public bool MoveNext()
{
if (forwardDirection)
{
current = current.Next;
return current != rightSentinel;
}
current = current.Previous;
return current != leftSentinel;
}
The rest of the code is just plumbing and we shall not go over it.
A Little Bit of Closure
We need a way of applying some function to the list of nodes. The process must be controled by the function, meaning that the function can dictate when to stop the process.
Introducing the predicate. The predicate is a delegate with one generic parameter, which returns a boolean value. We could have built our own delegate, and in one way it would have been better, because we are abusing the purpose of the predicate as intended by its creators. But why reinvent the wheel when it's already there.
So let's define the Apply method, which applies a predicate received as parameter to each node, as long as the predicate evaluates to (returns) true and there are still items in the list:
Public virtual void Apply(Predicate<T> predicate)
{
Node<T> node = leftSentinel.Next;
while (node != rightSentinel && predicate(node.Data))
node = node.Next;
}
Removing items from the list can be easily implemented by using the Apply method. What I intend to do is iterate through the list as long as the current node does not contain the value we are trying to remove, and when we find it we'll ask the containing node to remove itself from the list and stop the iteration:
Apply(delegate(Node<T> node)
{
if (item.Equals(node.Data))
{
node.RemoveFromChain();
count--;
return false;
}
return true;
});
Another method that coud use the help of the predicate is the Add method. This way we could make the items beig added to the list obey certain rules:
public virtual void Add(T item, Predicate<T> check)
{
Node<T> node = leftSentinel.Next;
while (node != rightSentinel && !check(node.Data))
node = node.Next;
AddBefore(node, item);
}
Now we have to tools to implement an ordered list:
public class SortedList : DoubleLinkedList<int>
{
public override void Add(int item)
{
Add(item, delegate (int data)
{
return data < item;
});
}
}
That's all for this episode. Remember you can find the source code here.
sâmbătă, 1 decembrie 2007
Creating a Double Linked List in C# - Intermezzo
You can now find the source code for the double linked list series at this location.
joi, 29 noiembrie 2007
Headache Installing Visual Studio 2008
Last night I've tried to install Visual Studio ‚Orcas' RTM, but the setup kept crashing at the fisrt step of the installation (installation of the 3.5 framework). Digging into the setup log files I've traced the problem to the installation of the 3.0 framework SP1. After some trials and misses (I've even uninstalled the MacAfee antivirus), I've downloaded the framework 3.5 setup redistributable (the full install package). The setup went flawlessly, and after it ended I was able to install the new Visual Studio.
I hope this information will help someone in need.
miercuri, 28 noiembrie 2007
Implementing a Double Linked List in C# - part II
In the previous post we've discussed the domain and the requirements of an implementation of a double linked list. It is now time descend the ladder of abstraction to the level where we can construct an usable artifact.
We'll start by analyzing the domain description and requirements, as we try to synthesize some sort of blueprint for the implementation. Right from the beginning we discover our two main entities: the list, and the nodes. It's pretty obvious we'll have different classes for each of them. Let's begin with the nodes.
The node has two major concerns: it has to hold data, and it has to retain references to it's left and right neighbors. As we've decided that any data can be stored into our list, and presuming the users of the list are kind enough to group multiple fields of data into types, we can make our nodes generic. Anything else is not important at this time.
On the other hand, the list has a bit more concerns. First of all, it has to hold some reference to the data. This is done by the means of the two sentinels. When a list is created, the sentinels hold a reference with each other. As nodes are inserted the references are changed, in such a way as to form a chain o references starting form the left sentinel, and ending with the right sentinel.
The list also has to know the number of nodes stored in the list (excluding the sentinels). We have to do this, without counting the nodes every time this value will be needed. This implies that we must control the process of altering the structure of the list in order to keep an updated count of its elements.
The main source of errors, as far as we are concerned at the moment, are boundary crossings. This can be easily solved by checking the value of received indexes, and throwing the appropriate exceptions.
As we have decided that the list must behave as a collection, it is time to decide on an interface that we'll implement, in order to provide the users of the list with a familiar experience. Searching the MSDN documentation, the IList<T> springs into attention, as it covers most of our needs. Actually, all the necessary functionality of the list will come from implementing this interface. Any other added functionality will only have the purpose of easing the use of the list.
At this moment we can start sketching the implementation of the list. Take note that the comments and documentation were removed for the sake of brevity.
The Node class is short and self explanatory:
public class Node<T>
{
public T Data;
public Node<T> Previous;
public Node<T> Next;
}
Next we start constructing the list:
public class DoubleLinkedList<T> : IList<T>
{
private int count;
private readonly Node<T> leftSentinel;
private readonly Node<T> rightSentinel;
The sentinels and node count will be initialized in the constructor. Remember that the list starts with the two sentinels referencing each other:
public DoubleLinkedList()
{
leftSentinel = new Node<T>();
rightSentinel = new Node<T>();
leftSentinel.Next = rightSentinel;
rightSentinel.Previous = leftSentinel;
count = 0;
}
The insert algorithm works in the following steps:
- Check boundaries.
- Search the n'th node. If there are no nodes, or the specified index is next to the last existing node, return the right sentinel.
- Insert the new value into a new node between the node found above, and its left neighbor.
- Increment the node count.
We will separate the last two steps of the algorithm into a helper method, AddBefore, as we will use them in another insert method, which will add an item directly at the end of the list.
private void AddBefore(Node <T> node, T item)
{
Node<T> newNode = new
Node<T>();
newNode.Next = node;
newNode.Previous = newNode.Previous;
newNode.Data = item;
node.Previous.Next = newNode;
node.Previous = newNode;
count++;
}
The search method can be reused in some other cases(item retrieval and removal), so we'll move the boundary check inside it:
private Node<T> Find(int index)
{
if (index < 0 || index >= count)
{
throw new ArgumentOutOfRangeException("index");
}
Node<T> currentNode = rightSentinel.Next;
while (index > 0)
{
currentNode = currentNode.Next;
index--;
}
return currentNode;
}
Now we can finish the implementation of the two insert methods:
public void Insert(int index, T item)
{
Node<T> nextNode = index == count ?
rightSentinel : Find(index);
AddBefore(nextNode, item);
}
public void Add(T item)
{
AddBefore(rightSentinel, item);
}
Unfortunately, it seems that the posts in this series are getting longer than expected, so I'll have continue the implementation on the next episode.
P.S.: As I've mentioned in the first post, additional requirements will be specified en route:
thread safety;
serialization;
performance;
implement the filter, map and reduce algorithms.
marți, 27 noiembrie 2007
First post: Implementing a Double Linked List in C# - part I
The first blog post is dedicated to a basic, but important data structure: the double linked list. It is intended to be an academic exercise, rather than a practical one.
Acknowledgement: I'm not a native English speaker, and despite Word's spell & grammar checker, please indulge my language faults. Still, constructive criticism is appreciated!
I've separated the plan of this project into 3 parts: the description of the domain of the problem at hand, definition of the requirements and, finally, the design. The article will be separated into two parts, leaving the design into the second part. A third, bonus, part might be included into the series.
First let's describe the DOMAIN of the problem
Wikipedia comes to our help with a definition of a double linked list (approx.): the (double) linked list is a data structure. It consists of a sequence of nodes, each containing arbitrary data fields and two references, to the next and previous nodes.

Some implementations provide two special nodes, called sentinels. These nodes are placed at the beginning and end of the list, and do not contain any data. Their purpose is to provide a uniform way of treating the insertion and removal of standard nodes.
In the .Net world, support for sequential data structures, besides arrays, is provided through collections. Collections are defined by a set of interfaces, which provide a uniform set of patterns for manipulating collections, and the concrete implementations of several types of collections: lists, dictionaries, hash tables and so on.
REQUIREMENTS prescription
The requirements for our double linked list represent what is expected from it. They fall into two categories, what is expected from a double linked list, and what is expected from a collection. The two categories are overlapping. The list of requirements is by no means exhaustive, and might be improved in the course of the implementation.
- Provide storage for data into nodes.
- Permit the insertion of new node(s) when the list is empty as well as when the list has existing items.
- Permit the removal of a specified item.
- Return the number of existing nodes.
- Return a specific node.
- Provide a consistent mechanism for dealing with errors.
- Provide the next and previous nodes for a given node.
A collection should:
- Provide for data into items.
- Permit the addition of new item(s).
- Permit the removal of item(s).
- Iterate over its values.
- Permit the retrieval of a specified item.
- Permit the alteration of the order of its item (ex. Sorting).
This ends the first two parts of our plan. Next time we will see how we can get from a list o requirements to an usable artifact.