Learning.Net

Sharepoint ISO Week Number

2009-02-16T06:42:00.000-08:00

Finding the week number for a date in Sharepoint cand be a real pain in the ass. The Internet provides some solutions, but they don't adhere to the ISO standard concerning week numbers:

- weeks start on monday

- the first week of the year is the one containing the fist Thursday of the year

The starting point for the formula below can be found here. It's pretty complex, and I suggest that first you should build some helper calculated functions for the most used values: day of week (DOW) of the current date, DOW of the first day of the current year, current day/month/year.

And here it is (replace "the_date" with the name of your date column):

=INT(

IF(AND(MONTH([the_date])=1,

5 < WEEKDAY(DATE(YEAR([the_date]),1,1)),

WEEKDAY(DATE(YEAR([the_date]),1,1)) < 9 - (DAY([the_date])-1)),

(IF(WEEKDAY(DATE(YEAR([the_date]),1,1)) < 6,1,0)) +

44 +

(59+WEEKDAY(DATE(YEAR([the_date])-1,1,1))-WEEKDAY(DATE(YEAR([the_date]),1,1)))*9 / 64,

IF(AND(MONTH([the_date])=12,

30-(DAY([the_date])-1) < WEEKDAY(DATE(YEAR([the_date])+1, 1, 1)) - 2,

WEEKDAY(DATE(YEAR([the_date])+1,1,1)) < 5),

(IF(WEEKDAY(DATE(YEAR([the_date]),1,1)) < 6,1,0)) +

4*(MONTH([the_date])-1) +

(2*(MONTH([the_date])-1)+(DAY([the_date])-1)+WEEKDAY(DATE(YEAR([the_date]),1,1))-WEEKDAY([the_date])+6)*36/256)))

... I know, it's horrible... if you have time, make it pretty...

Death to the ORMs

2009-01-12T21:30:00.001-08:00

“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.

Thoughts on Software Security

2008-12-05T03:24:00.000-08:00

Here's something that grinds my gears:

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!

From my experience there are no perfect software programs, from the security perspective. The only thing that matters is the number of exploited security holes. And that number tends to be directly proportional to the popularity|number of users and number of functionalities of the software application.

Or worse. My theory is that the users of public software applications (meaning software meant for the masses, not for X company's HR department), with small user bases, tend to be more technically savvy. As the number of users grows, due to the increassing popularity of that software, the average naivety level tends to go up. This is the first step when things start to go bad, because the easiest security exploits rely on user ignorance.

The second step occurs when the application suffers a surge of new functionalities. This usually happens when it starts supporting some form of plugins or automation, because this greatly increasese the area exposed by that application to the world: longer borders=>more border patrols are needed.

So there is no real security comparison between two software applications, unless they have comparable user bases, have been available for the same period of time and support roughly the same major functions.

My conclusion is this: educate the user! Software doesn't need to be foolproof. Time spent on dumbing down the user interface (and I don't reffer here only to the GUI, but the whole end user experince) can be better employed on improving its functionalities.

Help the user make informed decisions. Even if this means saying "Pushing this button exposes you to the following risks: money loss, health loss, pride loss, etc.". Software applications should not follow the marketing propaganda of consumerism. In a medium where information is a de facto currency, there are better ways to advocate the use of your software. Make a commitment to inform the users what are the strong and week points of your application, when it can and when it shouldn't be used.

Thoughts on Programming Languages

2008-12-02T00:59:00.000-08:00

1. Use declarative code for the UI (XAML, HTML)

2. OO code for infrastructure (data access, etc...)

3. Functional programming for logic implementation and data manipulation

4. Python has one of the nicest syntaxes of all programming languages

5. F# could have gotten a better syntax, even if it had broke OCAML compatibility.

6. Identation for code block delimitation rocks! I wish C# would have something like that... that might be an interesting idea: a precompiler for C# that just wraps indented blocks in curly braces.

Running Linux Apps Seamlessly Insinde Windows for 100EUROS or Less

2008-11-28T01:35:00.000-08:00

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.

My Plea to Microsoft

2008-11-19T08:01:00.000-08:00

Make

Windows

Free!

Python can do:

2008-10-18T14:49:00.000-07:00

Connect to an MS SQL database with integrated security (sample from a TurboGears aplication, using SQL Alchemy + Elixir + pyodbc):
sqlalchemy.dburi="mssql://<server name|named instance>/<database name>?sspi=true"

Next step: run TurboGears behind IIS in order to use Integrated Windows Security.
Even further: investigate if IronPython fits somewhere.

For all our real problems are technical...

2008-10-18T14:45:00.001-07:00

...not social, financial, political or religious:

The Zeitgeist Movement
The Venus Project

Internet Censorship

2008-08-15T00:12:00.001-07:00

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

Punitive Software Development

2008-08-14T02:55:00.001-07:00

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…

Code Generation Is Bad, M’kay?

2008-08-01T05:19:00.001-07:00

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

The Evils of Shared Check Out

2008-07-23T03:56:00.001-07:00

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.

Why You Should Write Your Own O/R Mapper ... Or At Least Try

2008-07-22T23:03:00.000-07:00

Because you will not use it. But in the process you'll probably learn a lot of things about what a data access layer is. And more important, you'll be able to judge the existing O/R mappers and chose the one that fits most of your needs.

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.

Nice Design Example for a Simple Data Access Layer

2008-07-18T06:46:00.000-07:00

If you are in the process of implementing a small data centric application, you'll probably need to write some data access code. I've recently stumbled upon Los Techies, which is a wonderful resource for good programming practices. I especially enjoyed Jimmy Bogard's series on the problem of separation of concerns.

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

Linq to SQL Server CE and uniqueidentifier columns

2008-07-17T00:43:00.000-07:00

There will be a couple of issues if you you try to use linq to sql with a SQL Server CE database. First of all the VS2008 designer doesn't allow adding tables from this type of database. The solution is to use the SqlMetal command line tool in order to generate the dbml or the code file (see here).

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();
}

Implementing a Double Linked List in C# - part III

2007-12-03T11:35:00.001-08:00

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.

Creating a Double Linked List in C# - Intermezzo

2007-12-01T00:53:00.000-08:00

Day by day I am amazed by Google's other services, besides web searching. One of the useful collaboration services offered by Google is Google Code. It is a free service for project hosting, which provides SVN version control.

You can now find the source code for the double linked list series at this location.

Headache Installing Visual Studio 2008

2007-11-29T06:57:00.001-08:00

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.

Implementing a Double Linked List in C# - part II

2007-11-28T12:51:00.001-08:00

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.

First post: Implementing a Double Linked List in C# - part I

2007-11-27T08:41:00.001-08:00

Hello World!

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.

The main purpose of the linked lists is to be a base for other data structures, like stacks and queues. The main benefit over conventional arrays is that they support the insertion and removal of elements, without creating a new instance of the structure. The advantage of the double linked list over other linked lists is that they can be traversed backwards as well as forwards.

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.

Another feature of the .Net framework, available from the v2.0 version, is generics. They enable the user to generalize the definition of types, by leaving a part of the implementation of the type to be provided when the type will be consumed. This will enable the list to contain any type of data, as long as it is of the same type (of course, a collection of object objects will hold any data, but that's not the point).

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.

A double linked list should:

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.