Marius Gheorghe

Building software : make it work, make it good, make it fast

More protected

You can't alter a page's viewstate with a instance variable  because it's protected. I hate the fact that if MS employees cannot think of a good reason why something should be public , they make it protected.  More context here .

Model Viewer Presenter. Take 3

In the past months i have been implementing in my projects MVP Passive View. You can find the description here. It works pretty good (in Windows Forms and Silverlight projects) and , from my point of view, it's far better than the "other" MVP implementation because the view remains without any logic responsability.

Here's how i implement it. Basically for each view action there is a associated method in the presenter.

public class OrderViewPresenter
{
  private OrderViewDialog dialog = null;

   public OrderViewPresenter(OrderViewDialog d) 

  { 
dialog = d; 
  } 


  public void DisplayData()
 {
//invoke the Order Business Object and load the order
Order o = .......
d.textBoxOrderDate = o.OrderDate;
 }


 public void CreateNewOrder()
 {
//create the new order base on the dialog data
 }

}


No branching. You're kidding...right ?

In real world you get to see a lot of WTF code. A lot. And then you stumble upon things like this. It looks like Flickr doesn't do branches , has only trunk and it pushes the trunk code into production a few times a day. For any software developer that's a giant WTF moment. It simply cannot be a good ideea. 

Funny thing is that i met people who used to think that's a good ideea. I bet that when the next guy comes along will point that blog post to me and say : "But look at Flickr guys. It works for them" .  Sigh...

 

Coders at work



Good stuff. I enjoyed Joe Armstrong interview the most. The only nitpick i have is that the author didn't insisted more on "development tools". From my point of view a programmers is partially "defined" by the tools is using so it was a little disappointing to see that they talked so little about this.Recommended.

Duct tape ? No no no

Joel's latest piece takes the cakes as being the crappiest piece of advice. It's pretty fucked up to read development advices about Netscape developers. That's the Netscape who had a crappy codebase and crappy product (see a relation between those two ?).
Don't duct tape any code today. DO not be a "event handler programmer". Think about the future

Documentation error in EntityFramework

Here's the description for entityCollection.Load(MergeOption.OverwriteChanges);

 "Objects are always loaded from the persisted store. Any property changes made to objects in the object context are overwritten by the store values."

 

Wrong.

If you add an item to the entity collection and then call Load(MergeOption.OverwriteChnages), you will STILL find that item there. To get data from database, you'll need to do :

entityCollection.Clear();

entityCollection.Load(MergeOption.OverwriteChanges);

 

Thoughts on code : Documenting a business software system

So, first of all, how would a GOOD documentation would  help us ? What would we gain from it ? Well :

- new people could be brought to speed very easely. No need to chaperon them while they understand the system, no need for different programmers to each explain to the new guy a small piece of the system.

- easy maintainance.

- remove dependency from the people who designed/understand the system.

 

Here's my take on what and how this should be done.


- document the initial requirements of the project.

- the "core" of a business system is the database schema . That's the most important thing which should be documented.  SqlDoc is a great tool for this. If you can't afford it then use a simple text editor. But DO document the schema of the database.

- document all the business procedures and requirements of the system. Some businesses have some pretty wacky procedures and requirements (if you worked with a financial system for instance, you probably already know that). Gather all these procedures and requirements and document them. Make sure the documentation is "tied" to the documentation of the database schema.

- create a entity relationship diagram.

- the most important advice of all : be explicit. Do not use shortcuts in the name of the database columns and do explain the specific business terms.

 

The last wish review


Funny thing....the intro movie from The Witcher is actually based on the first chapter of the book. Good stuff. The book is composed of a few short stories interwoven together. It's okeish but nothing great. I hope the saga will be better  (although it will take some years until it will be translated in english....the second book in the serie was written in 1995 and it will be released in english in 2010).

 

Thoughts on code : Comments

My thoughts about code comments :

- code and API comments are 2 different things and should be treated differently. 

Code comments :

- most of the time "method" comments should NOT be necessary.  Code should be written using guidelines that specify long and meaningfull names to all types. Hence if the method is called GetAvailableUsers then what's the point in adding a comment like "Gets the available users"?  The method name already tells the person who's reading the code what is does.

- comments should ONLY explain the WHY (why is the code doing this thing in this way ?). We can find the HOW just by reading the code.

- comments should be added only when there is need for them. There is no point in commenting everything (most people hate "green noise" when they read code).

- some people use comments hoping to "fix" badly written/broken code. This is SOOO wrong.  Documenting a mistake will not make it better. Consider refactoring the code and removing the comment.

- comment rot is very bad. When you refactor a piece of code, DO remove the unnecessary  comments.

- do NOT create a file header (with the name of the person who created the file, creation date etc etc). These stuff can be easely inferred from source control.  


API Comments :

- code samples are much more important than comments.  It's much more simple for the API user to have a sample on how to achieve a certain thing then to try figuring for himself by reading the API comments.

Netscape's Code Rush

Interesting documentary about the first days of the Mozilla project.

Few things jumped (back) to mind :

- Microsoft was beeing sued for making a free product. Oh...the irony.

- Netscape Navigator was pretty crappy compared to IE (4). Using IE4 in Win98 was a MUCH better experience than using Netscape.

- try to imagine the browser landscape today if Ms wouldn't have abbandoned IE after winning the Netscape battle.

- kind of ironic to see that a corporation opened the code to save itself, failed to do so (AOL buy Netscape sealed the deal) but , years later, there is a company which makes money from Netscape's code (yeah..i know....most of the code is rewritten but you get the point).

360 top JRPGS

Here my personal top of JRPGS  on the 360 :

1. Lost Oddysey

By far the best one on the platform. It's a massive release (spanning 4 DVD) and takes around 30 hours to complete. The best feature of the game it's the writing (both the storyline and the little stories you find through the game). Related to the little stories......it's pretty weird to have a 28GB game on a HD system and say that the best time you have in the game is simply squinting to read pieces of text. The combat is kind of annoying (standard turn based jrpg fare) but again the writing more than makes up for all the game shortcomings.

2.Tales of Vesperia

This one is a game from the tales series by Namco. Pretty good overall, with some "strong" connections between the party members and some genuine funny writing. The overall story arc is not that interesting. I liked the graphics style (cell shading) and while the quality doesn't reach Eternal Sonata's level , it is quite good.

 

3.Eternal Sonata

Gorgeous cell shaded graphic and THE best battle system (it's real time in a "arena") in any JRPG. These 2 are the best elements of this game. The quirky setting also helps....the game is based on the last hours in the life of Chopin. The storyline is not that interesting unfortunately.

4. Infinite undiscovery

The only good part of this game is the battle system (it's real time on the same map as exploring). Unfortunately the characters are not that interesting and neither is the story.

5. The last remnant

Again a interesting battle system (it's a little more tactical than the rest and it's based on the idea of controlling multiple units) is the only good part of this game.

 

6. Star Ocean : The last Hope

From my point of view the worst game so far....uninteresting plot, cliche characters, worst checkpoint position in the history of JRPGS and the list goes on. Avoid this one.

Disappointed by Silverlight support in Visual Studio

I've started working on a pet project in Silverlight a few days ago (using VS 2008). And frankly there are quite a few problems with Silverlight itself and support for it in Visual Studio :

- the designer is useless. Basically there is NO designer support (meaning drag and drop) for both Silverlight 2 and 3 in Visual Studio 2008. 

- no *proper* SOAP  Web Services support. Instead web services are invoked using WCF backward compatibility model and, here is the kick, are async ONLY. Async calls would make sense if Silvelight didn't have threads.....but since it has threads, why the heck am I forced to call everything aysnc ?!  Also SOAP headers are not properly supported  event though these guys say otherwise.

- still not enough controls.