Everything should be back to normal now, the adresses of the feeds have not changed, so no there's no change for you.
Sunday, February 22, 2009
Maintenance
By Jérémie Chassaing on Sunday, February 22, 2009, 23:31
I've been moving the blog address from www.thinkbeforecoding.com to thinkbeforecoding.com and it can cause some temporary troubles with the feeds between 2009-02-22 and 2009-02-23.. all should be ok then.
I don't know why Google MyBrand has changed the CNAME redirection inbetween...
Tuesday, February 17, 2009
Implement Linq to Objects in C# 2.0
By Jérémie Chassaing on Tuesday, February 17, 2009, 15:55 - Linq
I’m still working mainly with Visual Studio 2005 at work, and I was really missing Linq to Objects features. And I’m sure I’m not the only one.
There are workarounds when compiling C#2.0 code using Visual Studio 2008 since it’s using the C#3.0 compiler internally, but it won’t work in VS2005.
How does linq to objects work ?
Linq to Object works by chaining operations on the IEnumerable<> interface.
When writing the following the following linq query statement
var paperBackTitles = from book in books
where book.PublicationYear == 2009
select book.Title;
The compiler translates it to :
IEnumerable<string> paperBackTitles = books
.Where(book => book.PublicationYear == 2009)
.Select(book => book.Title);
The lambdas are used as simple delegates in Linq to Object using the following definitions :
public delegate TResult Func<T,TResult>(T arg);
public delegate TResult Func<T1,T2,TResult>(T1 arg1, T2 arg2);
//...
public delegate bool Predicate<T>(T arg);
public delegate void Action<T>(T arg);
public delegate void Action<T1,T2>(T1 arg1, T2 arg2);
//...
So the preceding code is equivalent to :
IEnumerable<string> paperBackTitles = books
.Where(delegate(Book book){return book.PublicationYear == 2009;})
.Select(delegate(Book book){return book.Title;});
But the IEnumerable<> interface doesn’t provide those methods. These are actually extension methods defined in the Enumerable class.
public static class Enumerable
{
public static IEnumerable<T> Where<T>(
this IEnumerable<T> source,
Predicate<T> predicate);
public static IEnumerable<TResult> Select<T, TResult>(
this IEnumerable<T> source,
Func<T, TResult> projection);
//...
}
The translation is immediate :
IEnumerable<string> paperBackTitles =
Enumerable.Select(
Enumerable.Where(books,
delegate(Book book)
{ return book.PublicationYear == 2009; }),
delegate(Book book) { return book.Title; });
Once we’re here, there’s nothing that cannot be implemented in C#2.0.
What do we need ?
There is plenty of things in Linq to Object, and I prefer to say right now that we will not have the full integrated query syntax !
Implementing the static Enumerable class is not very difficult, let’s provide a implementation for Where and Select :
public static class Enumerable
{
public static IEnumerable<T> Where<T>(
IEnumerable<T> source,
Predicate<T> predicate)
{
if (source == null)
throw new ArgumentNullException("source");
if (predicate == null)
throw new ArgumentNullException("predicate");
return WhereIterator(source, predicate);
}
private static IEnumerable<T> WhereIterator<T>(
IEnumerable<T> source,
Predicate<T> predicate)
{
foreach (T item in source)
if (predicate(item))
yield return item;
}
public static IEnumerable<TResult> Select<T, TResult>(
IEnumerable<T> source,
Func<T, TResult> projection)
{
if (source == null)
throw new ArgumentNullException("source");
if (projection == null)
throw new ArgumentNullException("projection");
return SelectIterator(source, projection);
}
private static IEnumerable<TResult> SelectIterator<T, TResult>(
IEnumerable<T> source,
Func<T, TResult> projection)
{
foreach (T item in source)
yield return projection(item);
}
//...
}
You can notice that I’m splitting the methods in a part that does argument check and another one that makes the actual iteration process. This is because the iterator code will only get called when actually iterating, and it will be really hard to find out why the code throws an exception at that moment. By performing argument checking in a non-iterator method, the exception is thrown at actual method call.
Since C#2.0 doesn’t support extension methods we’ll have to find something so that the code doesn’t look ugly as in the final translation above.
Simulating extension methods in C#2.0
Extension methods are just syntactic sugar and are simply converted to a static method call by the compiler :
books.Where(predicate)
// is translated to
Enumerable.Where(books, predicate)
If we can wrap the books variable in a kind of C++ smart pointer providing the Where method, the trick is done.
To do this, we will use a small struct that encapsulate the IEnumerable<> interface :
public struct Enumerable<T> : IEnumerable<T>
{
private readonly IEnumerable<T> source;
public Enumerable(IEnumerable<T> source)
{
this.source = source;
}
public IEnumerator<T> GetEnumerator()
{
return source.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
public Enumerable<T> Where(Predicate<T> predicate)
{
return new Enumerable<T>(
Enumerable.Where(source, predicate)
);
}
public Enumerable<TResult> Select<TResult>(
Func<T, TResult> projection)
{
return new Enumerable<TResult>(
Enumerable.Select(source, projection)
);
}
//...
}
The return type is Enumerable<> so that calls can be chained.
We can had a small helper to make the smart pointer creation shorter :
public static class Enumerable
{
public static Enumerable<T> From<T>(
IEnumerable<T> source)
{
return new Enumerable<T>(source);
}
//...
}
Now we can write :
IEnumerable<string> paperBackTitles =
Enumerable.From(books)
.Where(delegate(Book book){return book.PublicationYear == 2009;})
.Select<string>(delegate(Book book){return book.Title;});
We just have to extend the Enumerable class and Enumerable<> struct with more methods to get a full linq to object implementation in C# 2.0.
Sunday, February 8, 2009
Lazy loads and persistence ignorance (Part 2)
By Jérémie Chassaing on Sunday, February 8, 2009, 13:17 - Domain Driven Design
In the previous post, I introduced a class to manage function injection for lazy loads to enable persistence ignorance.
Chris was asking where the builder I was talking about should be used, and I tumbled on a StackOverflow question asking how to make lazy loading without using classes like Lazy<T>...
I'll discuss the second part first.
There is a good way to make lazy loading without using classes like that. You can use proxies.
There are two main ways to make transparent proxies
- by creating dynamically a derived class using Reflection.Emit
- by creating a transparent proxy
Still there are some drawbacks with both approaches. For the first one, all your members should be made virtual, for the second your class should inherit from MarshalByRefObject. In all case you should then take care not to mess up between proxies and underlying classes.
The main critic to refuse to use Lazy<T> class is usually that it's not a domain concept, and that it leaks persistence concern in the model.
I reject those critics.
Have you ever seen someone criticize List<T> or Dictionary<,> because it was not a domain concept ? We're writing OO code, and we can use basic tooling to make our models expressive. IEnumerable<T> and Linq to objects are good examples of these useful tools.
And I don't consider that Lazy<T> is a persistence concern. It expresses that the relation between entities is a bit more loose than others. There is nothing in the Lazy<T> signature that ties your entity to any persistence concept. You just provide a way to give the value of the property when needed rather than at construction, but this choice comes from outside of your entity.
And at least it becomes clearer than with derived proxies where the C# keyword virtual is used to express something but tries to hide it in the same time.
For Chris question, I use the builder in the repository.
The repository is responsible for retrieving entities from the data store. The reconstruction of objects is a bit different from the construction. This is underlined in Evan's book in the chapter Factories / Reconstituting Stored Objects.
In my data access layer I use a IDataBuilder<T> interface that represents a service that can build an object of type T from a IDataRecord. This is when I work directly with the ADO.Net and stored procedures.
public interface IDataBuilder<T>
{
T Build(IDataRecord record);
}
I also use a class that encapsulate the access to the stored procedures (or queries if you don't want to use stored procedures).
public class DataAccess
{
public UniqueResult<Entity> GetEntity(Guid id);
{
//...
}
public MultipleResult<Entity> GetEntities()
{
//...
}
}
UniqueResult<T> and MultipleResult<T> provides a methods that take a builder to read data records :
public struct UniqueResult<T>
{
public T With(IDataBuilder<T> builder)
{
//...
}
}
public struct MultipleResult<T>
{
public IEnumerable<T> With(IDataBuilder<T> builder)
{
//...
}
}
In your repository implementation you can then use all this :
// The concrete repository interface that belongs to the domain
public interface IEntityRepository : IEnumerable<Entity>
{
Entity this[Guid id] { get;}
//.. other methods
}
// the implementation that is not part of the domain
// an that is pesistance dependant.
internal class EntityRepository : IEntityRepository
{
private DataAccess dataAccess;
private EntityBuilder builder;
public EntityRepository(DataAccess dataAccess, EntityBuilder builder)
{
this.dataAccess = dataAccess;
this.builder = builder;
}
public IEnumerator<Entity> GetEnumerator()
{
return dataAccess.GetEntities().With(builder);
}
IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
public Entity this[Guid id]
{
get { return dataAccess.GetEntity(id).With(builder); }
}
}
The last part is in the implementation of the builder.
internal class EntityBuilder : IDataBuilder<Entity>
{
private DataAccess dataAccess;
public EntityBuilder(DataAccess dataAccess)
{
this.dataAccess = dataAccess;
}
public Entity GetEntity(IDataRecord record)
{
var id = (Guid)record["Id"];
return new Entity(
id,
Lazy.From(() => dataAccess.GetSubEntity(id)));
}
}
Of course, the repository implementation, the DataAccess class and the builder are all internal to the data access implementation. It can be in a separate Assembly or internal in a sub namespace of the main assembly depending on you module separation preferences.
When using linq, you simply don't need the DataAccess class because you can query the DataContext directly. But you can use the same pattern.
The main point is still that your Entity object knows strictly nothing about what's going on there.
Saturday, February 7, 2009
Lazy load and persistence ignorance
By Jérémie Chassaing on Saturday, February 7, 2009, 14:44 - Domain Driven Design
I often see questions about how to make lazy loads in entities, and wether using dependency injection for it.
The usual response is something like this :
class Entity
{
private Guid id;
private SubEntity subEntity;
private IDataService dataService;
public Entity(Guid id, IDataService dataService)
{
this.id = id;
this.dataService = dataService;
}
public SubEntity SubEntity
{
get
{
if (subEntity == null)
subEntity = dataService.GetSubEntity(id);
return subEntity;
}
}
}
As you can see, your entity is seriously tied to your persistence problem now. Even if it accesses the persistence layer through an interface, it is not persistence ignorant anymore.
The smell is that you cannot create an in memory instance of your entity anymore without worrying about data access.
Should you sill inject the data access service, or is it useless and you should leave it null ?
So believe me : do not inject data services in your entity.
Now, how can we still have the lazy load behavior ?
Through injection. But not dependency injection, I use execution inversion of control through delegate injection.
If you give to your entity a function that will return the value when asked, it's as if you gave the value.
Let's encapsulate this in a small class :
public class Lazy<T>
{
private T value;
private Func<T> loader;
public Lazy(T value)
{
this.value = value;
}
public Lazy(Func<T> loader)
{
this.loader = loader;
}
public T Value
{
get
{
if (loader != null)
{
value = loader();
loader = null;
}
return value;
}
}
public static implicit operator T(Lazy<T> lazy)
{
return lazy.Value;
}
public static implicit operator Lazy<T>(T value)
{
return new Lazy<T>(value);
}
}
Then you can use it like this in your entity :
class Entity
{
private readonly Guid id;
private readonly Lazy<SubEntity> subEntity;
public Entity(Guid id, Lazy<SubEntity> subEntity)
{
this.id = id;
this.subEntity = subEntity;
}
public Guid Id { get { return id; } }
public SubEntity SubEntity
{
get { return subEntity; } // implicit cast here
}
}
The code is more straight forward, the intent is clearly visible.
One benefit here, is that the subEntity field can be marked as readonly, that is a big improvement because our entity is really immutable now. Actually the Lazy<T> is mutable, but it behaves as an immutable value.
If your entity is not immutable, you can still leverage the Lazy<T> class :
class Entity
{
private readonly Guid id;
private Lazy<SubEntity> subEntity;
public Entity(Guid id, Lazy<SubEntity> subEntity)
{
this.id = id;
this.subEntity = subEntity;
}
public Guid Id { get { return id; } }
public SubEntity SubEntity
{
get { return subEntity; } // implicit cast here
set { subEntity = value; } // implicit cast here too
}
}
The last part is about how you use it when instantiating the object.
When creating a new instance in a factory (not linked to database) :
SubEntity subEntity = ...;
Guid id = ...;
Entity entity = new Entity(id, subEntity);
Here again, the implicit cast happen to pass the SubEntity as an already loaded Lazy<SubEntity>.
When binding the entity to the database :
class EntityBuilder
{
private IDataService dataService;
public EntityBuilder(IDataService dataService)
{
this.dataService = dataService;
}
public Entity GetEntity(Guid id)
{
return new Entity(
id,
new Lazy<SubEntity>(() => dataService.GetSubEntity(id)));
}
}
We can use a small helper method to make the instantiation cleaner :
public static class Lazy
{
public static Lazy<T> From<T>(Func<T> loader)
{
return new Lazy<T>(loader);
}
}
Then you can write :
return new Entity(
id,
Lazy.From(() => dataService.GetSubEntity(id)));
Now, the code that instantiate the Entity decides where the sub entity comes from.
The entity has become truly persistence ignorant.
Some would also advice not to use lazy load at all... this is still an option to consider !
Continued in Lazy loads and persistence ignorance (Part 2)
Wednesday, January 21, 2009
Mixing IEnumerable and IQueryable
By Jérémie Chassaing on Wednesday, January 21, 2009, 17:12 - Domain Driven Design
Marcel posted a comment in the previous post saying that even if returning IEnumerable, the new query clauses would be executed in the database… But it’s not.
If the repository use linq internally and returns the result as IEnumerable, on the other side, consider something like this :
var selectedEntities = repository.GetAll().Where(x => x.Selected)
Where GetAll returns an IEnumerable (that is actually a IQueryable).
The Where extension method will be selected on Enumerable. Be careful, Extension methods are static methods, no virtual call is involved here. The static type of the object decide the selected extension method.
Check in your debugger, selectedEntities is an instance of the Enumerable.WhereIterator internal class.
So when enumerating it, it enumerates its source and returns every item that passes the predicate.
When enumerating the source, here the source use linq2Sql to get the items and creates a query that returns all rows from the database.
The where clause was not executed in the database.
So the Linq provider did not leak outside of the repository.
Monday, January 19, 2009
Repositories and IQueryable, the paging case.
By Jérémie Chassaing on Monday, January 19, 2009, 11:50 - Domain Driven Design
Edit : My opinion on this subject have changed… You can read the full story in Back on Repositories and Paging. Introducing reporting.
The technique is still useful to write the query services, but I would not recommend to implement it on a repository.
When it comes to repositories, people have a hard time figuring how to
respect the DDD vision while taking most out of current ORM technologies (Linq
and ORM) and not writing too much code – we’re so lazy.
The war between IRepository<T> generic repositories or not is raging outside, and I took some time to chose my side. Here are the points to consider :
- The repository is a contract between the domain and the infrastructure
- The implementation details should not leak outside
In my opinion, the first point indicates that the repository should be tailored to the domain needs. It cannot be generic, or it is not a contract at all.
When writing a contract, details matter !
This doesn’t mean that we cannot use generic tools to access data behind the interface curtain. Linq DataContext and Tables<T> are very sharp tools to implement repositories. And there is a very good post by Greg Young about that.
There is still a point to be discussed though :
Should the repository methods return IEnumerable<T> or IQueryable<T> ?
The IQueryable<T> is part of the framework, and cleanly integrated in the language.
The problem is that its implementation depends heavily on the underlying provider. And it is a really serious leak !
So lets state the question differently :
- Why would we need IQueryable ?
- Because we can add
new query clauses, and they will be executed directly in the database.
- What kind of clause would you add ?
- Don’t know…
clauses…
- Would it be business specifications ?
- No, these
should already be in the repository..
- So ?
- Sorting and Paging ! These are
presentation concerns !
- Here’s the point.
Paging is not a recent concern for programmers and there is never enough tools to implement it properly. The main problem is that paging once you’ve got all the data is less that effective. And this is what will happen with an IEnumerable approach.
But let’s ask a two last questions.
Why is paging useful ? Is it really a presentation concern ?
We need paging to navigate through large collection of object, and if a collection can grow enough so that is cannot be embraced in a single query, it becomes a domain concern !
- When your object collection is known at design time to stay in small bounds but you still want to page it for presentation clarity, there is no real penalty to fetch all and display only a few.
- But when your collection can grow big, you SHOULD provide a mechanism to retrieve only a range of it, for presentation purpose or simply for batching purpose.
The problem is that if we leak IQueryable, the user can do far more than paging, and problems can arise. So I suggest to use a new interface IPaged<T> that would provide everything needed for paging :
public interface IPaged<T> : IEnumerable<T>
{
///<summary>
/// Get the total entity count.
///</summary>
int Count { get; }
///<summary>
/// Get a range of persited entities.
///</summary>
IEnumerable<T> GetRange(int index, int count);
}
And here is a simple implementation on a IQueryable :
public class Paged<T> : IPaged<T>
{
private readonly IQueryable<T> source;
public Paged(IQueryable<T> source)
{
this.source = source;
}
public IEnumerator<T> GetEnumerator()
{
return source.GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
public int Count
{
get { return source.Count(); }
}
public IEnumerable<T> GetRange(int index, int count)
{
return source.Skip(index).Take(count);
}
}
Then your repository can return IPaged collections like this without leaking implementation details :
public IPaged<Customer> GetCustomers();
This seems to be a major step in the repository pattern understanding, and it’s underlying war. And you, on which side are you ?
Thursday, January 8, 2009
Asp.net MVC binding security issue
By Jérémie Chassaing on Thursday, January 8, 2009, 17:58 - Asp.net
There’s a post on CodeThinked about a serious potential security issue.
The problem comes from an MVC convenience that when using an object as a controller action parameter, Asp.net MVC will bind the form fields to object properties auto-magically. Read the full post for a complete description.
I would recommend a solution using a presentation only model. There is a good reason for this.
The model object passed to the view should not be directly the domain/business object. I always create a thin adaptation layer for presentation, even when it doesn’t add much value. I lets me decouple presentation concerns from domain concerns.
The object coming back from the form should follow the same rule as part of this presentation concerns. There is no problem if those presentation objects provide only non sensitive fields.
But it’s sure that not anyone will know about the risks.
Monday, December 29, 2008
Asp.Net authentication cookie oddities...
By Jérémie Chassaing on Monday, December 29, 2008, 18:24 - Asp.net
Back to low level considerations.
In order to use a specific and shareable encryption scheme between sites, we had to bypass the FormsAuthentication.Encrypt method an write a new one.
Something strange happened then. When using our implementation, the cookie disappeared !
The cookie was added to the Response.Cookies, but was not present in the Request.Cookies of the following request.
After deep search, it appeared that the cookie was actually sent to the browser. Why wouldn’t it be sent back ?
The really weird thing was that the cookie data was in the Response.Headers, but not in Response.Cookies !!!
It seems that when parsing the Cookie header, Asp.net strips off the .ASPXAUTH cookie if it cannot be decrypted by FormsAuthentication.Decrypt !
The solution was to use another cookie name, and everything was working again !
If it can save 2 hours of your precious time…
Wednesday, December 24, 2008
Data Structures and Algorithms
By Jérémie Chassaing on Wednesday, December 24, 2008, 11:05
I had a peek through Jon Skeet’s blog this morning at a free eBook called Data Structures and Algorithms by Granville Barnett and Luca Del Tongo.
The book is clear and presents the usual linked lists, trees, sets structures in a concise yet precise way.
There’s something new I had not seen in other algorithm books before. The algorithms are written in pseudo code, but there is a chapter about unit testing your implementation.
If the writers read this, I just would like to share a little tricks that make linked list algorithms easier to write..
Linked list algorithms are always bloated with tests like this :
if (head == null)
head = ...;
else
node->Next = ...;
Actually the content of head and then content of node->Next are both pointers on next node. But the way to reference those two locations is different, ending in a lot of if statements.
If the language supports reference variables or pointer, you can use a double pointer to hold the current position :
Node** next = &head;
This way there is no more difference between the head (*next) and nodes Next pointers. The little tricky thing is to move to next location :
next = &((*next)->Next);
With this you can consider every ‘Next’ pointer including head as equivalent. No more if statement !
By the way, I was trying to find out how to do this on C#, but is it possible without going unsafe ?
Monday, December 22, 2008
DDD: Specifications
By Jérémie Chassaing on Monday, December 22, 2008, 16:42 - Domain Driven Design
There's an interesting post by Greg Young about Specifications.
I'm currently refactoring some code to move constraints and validation in specification classes, and it really gives a better insight at what is constituting entities and what's not, especially when there are multiple level of constraints (persistence constraints, business constraints...)
Friday, December 19, 2008
Coding and writing - The form
By Jérémie Chassaing on Friday, December 19, 2008, 16:26
There is a number of common points between coding and writing
Spelling
The most basic mistake... Oops I wrote retrun instead of return... hopefully modern text editors check it on the fly.
Syntax
Correct sentences are made of word in a correct order. Here again, on the fly checking helps a lot.
Presentation
Is your code visibly clear... Enough space between parts, but not too much. Is you code clearly indented.
Style
Style is even more subjective. When coding, usually stay concise, but there are a lot of parameters here.
You can :
- choose if statements or ?: alternating operator
- define fluent interfaces to do things on several lines
- use linq to express your intent more clearly,
- use var implicit type or not
- use anonymous types or not
- use lambdas or functions
The important thing is that your style should fit some purpose, the style should emphasis important parts of your primary intent.
Structure
A book is divided in parts, chapters and paragraphs. The code is divided in files namespaces and classes. The structure of the code should help the reader go straight to what is the most important to him and understand how things are related.
Next time, we'll talk about substance. Tell me if you see more analogies !
Wednesday, December 10, 2008
Wow - Book review - Domain Driven Design!
By Jérémie Chassaing on Wednesday, December 10, 2008, 12:46 - Domain Driven Design
Ok, I finished Domain Driven Design yesterday. I think I had no such Aha moment since I read Design Patterns eleven years ago...
I thought I was prepared for it, I had read many things to get maximum info...
I had :
- Read Domain Driven Design Quickly (you can download it)
- Followed threads on the DDD yahoo group
- Peeked at samples on domaindrivendesign.org
- Start to try on my own projects
I had practiced knowledge crunching on my own for long.
But the book go far beyond all that. It has a deep vision of programming on large scale projects, and give really good insight on difficulties that arise when working on complex systems with several teams. These are really precious pieces of advice.
The pattern presentation of the different chapters, even when those patterns are not implementation patterns but team organization patterns is really helpful and clear.
There is not much about implementation details, but it is not a problem. The principles are not tied to a specific technology or framework. Actually this is even a good point, it leaves the book clean from a specific implementation. Implementation books are aging faster.
You definitely should have this book on your shelf.
Tuesday, December 2, 2008
Domain Driven Design
By Jérémie Chassaing on Tuesday, December 2, 2008, 14:41 - Domain Driven Design
I had read a lot of stuff about it these last months, and I think I got the essence and the principles.
I've received the blue book today.
I'm sure I'll have matter for blogging these days...
Monday, December 1, 2008
Problem with the Select N+1 problem
By Jérémie Chassaing on Monday, December 1, 2008, 16:17
Ayende proposes solutions for the Select N+1 problem in NHibernate.
Some will say it is a sign that lazy load is the work of the devil. But I can remember the time when people were saying that garbage collectors are evil.
We all would like to have non intrusive data fetching strategy that work 99% of the time !
The problem is not about lazy load or not. It is that you must take care about your data fetching strategy whenever you make a data access.
There is currently no technology smart enough to infer the right fetching strategy.
If someone builds it, this won't be a problem anymore.
If you know about it, please tell the world !
Ubiquity of language... lost in translation ?
By Jérémie Chassaing on Monday, December 1, 2008, 10:49
I found two collapsing problems :
- You should use the same language between domain experts and development teams (DDD)
- You should use English for naming in your code (Design guidelines)
What if my domain experts don't speak English ?
Tuesday, November 25, 2008
CSS is too Tricky
By Jérémie Chassaing on Tuesday, November 25, 2008, 16:47
I found through Alvin Ashcraft's Morning Dew a post about CSS tricks Six indispensable CSS tips and tricks I use on every project. Very interesting since it gives some ways to make cleaner CSS integration (I really like the Overclear one, don't need the clear both anymore !!).
But while reading this question came to my mind:
Why do we need to find crazy tricks like this for any single thing we want to do with HTML + CSS ?
This is the sign that HTML + CSS is a complete design failure !
When you want to make something as simple as putting several blocks on the same line... you must use float left, but it does not behave exactly has you expect it to do... When using Silvelight and WPF I had none of these problems. There are surely other problems with theses technologies but I have found an important difference :
- In CSS, the elements decide how the fit in their parent
- In Silverlight, parents decide the layout of their children
And it makes a huge difference. Because in CSS, the interactions between sibling children using very different placement models make it a n*n combination problem. For sure it's not manageable and no browser can handle every case gracefully.
In Silverlight, you obtain the layout you want by composition, and each rule remains simple. No need to use Jedi tricks to obtain what you want.
Monday, November 24, 2008
Coincidences just happen...
By Jérémie Chassaing on Monday, November 24, 2008, 15:51
It's quite strange how ideas can appear at the same time in different places. This morning while take a shower I was thinking about a future post series about programming and building architecture and how things had changed in the last few years. Only 1h later I was reading this post by Justin Etheredge, that matches exactly this subject.
I'm still preparing the posts however.
Do you understand what it is all about ?
By Jérémie Chassaing on Monday, November 24, 2008, 15:37
I want to be sure the title of the blog will not be misunderstood: when I
say "Think before coding", I don't mean you should prepare everything before
and the start coding like a robot. This is what is called waterfall model, and
and it has always been considered as as non-working model, even by its author.
Programming is not applying a technique. When confronted twice to a problem, the programmer should not use the same solution, but understand what make both problems so close and build something that solve this class of problems. It can be a simple helper function, a small library or a big framework. This is the DRY (Don't Repeat Yourself) principle.
We all learnt how to implement a Quicksort algorithm at school. When was the last time you had to implement it? Personally I use the Linq Sort() extension method and it does the trick for me.
If you have to implement it for a specific reason, it should be because you understood that your problem was not exactly the same as the one handled by existing implementations.
This is why programming is not about technique or algorithm, if you're smart enough, you can adapt almost anything to any language or technology.
There is still one thing that tools and technology can't do for you : understanding.
Programming IS about understanding
- Understand the problems
- Understand the processes,
- Understand the people,
- Understand the other programmers,
- Understand yourself!
You should have a deep understanding of the problems and processes.
This is the base of modeling, wether it is domain models as in Domain Driven Design or infrastructure framework creation, through Separation of Concerns.
You should understand people.
Because they are the one that ultimately will use what you're building. People are usually hard to understand. This is all the matter about User Experience (UX), but even when programming a framework, you should understand how other programmer will use it and understand it, and how they'll build on it software for other people with their one expectations.
You should understand programmers.
You rarely write your code only for you, and you should write your code so that other programmer have the better understanding of what you intended to do, and what you understood about the problem you're solving by writing this code.
You should understand yourself.
Even when you write code only for yourself, you should understand what you wrote in the first place, as Andy Hunt and Dave Thomas say :
All Programming is Maintenance Programming
Bill Venners: You say in your book, The Pragmatic Programmer (Addison-Wesley, 1999), that "programmers are constantly in maintenance mode." Why?Dave Thomas: All programming is maintenance programming, because you are rarely writing original code. If you look at the actual time you spend programming, you write a bit here and then you go back and make a change. Or you go back and fix a bug. Or you rip it out altogether and replace it with something else. But you are very quickly maintaining code even if it's a brand new project with a fresh source file. You spend most of your time in maintenance mode. So you may as well just bite the bullet and say, "I'm maintaining from day one." The disciplines that apply to maintenance should apply globally.
Andy Hunt: It's only the first 10 minutes that the code's original, when you type it in the first time. That's it.
But you should also understand how you do things, how you did things, how you changed, and how you will change in the future. Things are moving so fast that you can not simply stay with your current knowledge and expect it to be sufficient in two years.
Friday, November 21, 2008
Must know English to be a programmer ?
By Jérémie Chassaing on Friday, November 21, 2008, 14:55
I found through Scott Hanselman's blog a conversation starting from
I was 8 when I started playing with BASIC on the TI-99/4A my father bought in the early 80's, and at that time I had never learnt an English word... But that was not a problem as long as the documentation was in my native language.
I had no need to know English since I knew what For, Load, Run, Save did. Ok my pronunciation was a bit sloppy (Load was Lo - a - d, with a big french a) but I knew what the computer would do when I used those commands.
Of course you can achieve a better style and discover libraries ways faster when knowing English, but I don't think it's a requirement. It's better though to use a widely spread language when you want to share your code. I've had already hard time reading Italian code, but this is more a problem about languages in general than a problem about programming.
Don't be stopped by your native language, programming languages are languages per se, and you should learn a new [programming] language every year. Why not English ?
« previous entries - page 3 of 4 - next entries »
