Some notes on scaling. There are 2 ways to scale a application :

1. scale up (vertical scaling) : this describes how an application/service can be scaled when running on a single box. The scaling is done by "beefing up" the box: adding RAM, faster CPU(s) etc. The things to note here are: the  application/service's workload cannot be made to run concurrent and use multiple machines and that  after a certain threshold is met there isn't a direct correlation between beefing up the hardware and the workload.  So, for instance, if you increase the processing power by 100% that doesn't guarantees to also support a 100% increased workload.  Sometimes this is referred to as brute force scaling.

2. scale out (horizontal)
This is the preferred way to scale. It means that the application/service is inherently concurrent and works on multiple  boxes. So, to scale like that simply means adding/removing boxes to the network to keep up with the load. Usually this is done using  a load balancer. Using as an example a web farm....a load balancer (which can be either software or hardware) is put "in front" of the network and the IP is "virtualized". That means each request ends up going through the balancer and it's his job to "redirect" the request to a free
box. There are 2 main algorithms that loads balancers use to determine which boxes are free :
 - round rubin scheduler approach (the same that thread scheduling is done by the OS) which rotates between the boxes.
 - server pooling : in which the balancer "pools" different boxes and assigns the request depending on how fast the server responded.

So, the main thing to remember from this, is that always try to design the application in such a way that can be scaled horizontally.

 

Now playing: Apocalyptica - Hope

 

Some thoughts on why the agile methodologies work:

– they keep you focused on the customer. The most important thing is to satisfy the customer. The project itself has a simple goal : bring business value to the customer. 

– welcome changing requirements.  There are 3 sure things in life : death, taxes and changing software requirements.  Sooner or later it would happen…so why fight it ? After all the purpose is to bring business value to the customer. Welcome changes.

– shared code ownership. In most of the “traditional” software development methodologies, the team members end up “owning” different parts of the source code. The changes to these parts, by others than the author, are often discouraged. No so with agile….any member has the right to change the code. There is also a psychological issue with this : if a developer ends up “owning” a part to the source code , he will work only on that part and loose touch with the rest of the project. If some other part of the project will not work as expected he will think: screw it…my part works just fine. Of course the customer doesn’t care if some parts work….he just wants a working solution. So through shared code ownership the agile methodologies encourage the developers to keep on eye on what really matters : a solution which works.

– working together. The customer and the development team must work together to produce results. Face to face conversations is the most effective method of conveying information between the development team and the customer. And the primary measure of progress is working software. So…talk to the customer…..implements its requirements/changes…..show the software and repeat until the customer is satisfied with the result.

– the software should be build by motivated individuals in their environment and with the support they need. This should not come as a surprise to anyone but motivated individuals is the first requirement of a successful software projects. This is not necessary related to agile methodologies because i personally think that motivated individuals will succeed in delivering working, solid software no matter of which methodology they use. But with agile they will obtain faster results. They key point is that the management should be trust the people to get the job done and offer them the environment and support they need.

 – deliver working software frequently. This is tied with working together…..deliver frequent working software and get the customer input. Rinse and repeat until the customer is happy.

 – continuous integration. With continuous integration you are in control. Whatever you do breaks or advances the project. You get instant feedback on your changes and act accordingly. It helps to think of continuous integration and TDD as extensions of the compiler.

– Test Driven Development (TDD).Not much to say here….TDD simply changes the way in which we develop software and this is a “must use” technique.

That’s it so far. I’m not trying to suggest that agile methodologies  should be used in any kind of software project, but i am suggesting to everyone to try agile methodologies in their projects.

 

Now playing: Blind Guardian - Into the Storm

   This is sooo cool. There is a patch (http://bat.org/~tomba/monoco.html) for Mono which implements continuations in the runtime. Personally i am very interested in continuation because of the possibility of writing transactionable memory operations (something that .NET 2.0 System.Transactions doesn't support). Also there is a coroutines implementation dubbed "microthreads".

  Very very nice. Let's just hope that CLR will also implement continuations someday.

 

Sometimes you need to capture the page HTML output (for logging purposes or to mail it). The easiest way to do it is to override the Render event handler like this :

protected override void Render(HtmlTextWriter writer)

{

      //create a new string builder

      StringBuilder builder = new StringBuilder();

 

      //create a StringWriter based on the builder

      StringWriter sw= new StringWriter(builder);

  

      //create a new HmtlTextWriter based on the string writer

      HtmlTextWriter htmlWriter = new HtmlTextWriter(sw);

 

      //call the base Page implementation which generates the HTML

      base.Render(htmlWriter);

 

      //get the output from the string

      string html = builder.ToString();

  

     //do usefull stuff

}

 

  Finally migrated all my older entries here. So…now it’s time for blogging. Why blogging ? It really helps me organising my thoughts. Probably all of those crazy .NET related things which swirl through my mind will get a place in here.

  

I've read the C# 3.0 specs last night and ....well i'm a bit puzzled. I think the C# team is taking the language into
a wrong direction.The design of C# 1.0 was pretty good. Despite making a few small mistakes mr Helsjberg & co clearly were aware
that code is written once and read many times. Little things...like putting ref / out at the function call site showed
that readability is a key point for them in the design of a language.
In my opinion in the design of C# 1.0 they screwed up by adding domain specific functionality in the core language definition.
Domain specific functionality is handled in libraries (in which is easier to deprecate / improve) then the core language itself.
This domain specific functionality i'm talking about is threading. C# includes 2 keywords (volatile and lock) which deal with threading
directly from the language instead of the libraries (never mind that lock "maps" to a Monitor). Adding these functionality in
the language definition is bad because :

- they don't belong there
- it bloats unnecessary the language
- their functionality already exists in the library
- it harder for them to "evolve" the language when they are adding new keywords.
- a small fixed core is always better

Despite this i think the design of C# 1.0 was very good. With C# 2.0 they added again domain specific functionality into the
language definition. You can argue but a nullable type is used mainly in the context of a database operation. In fact nullable
types are implemented in mscorlib like any other type but the made the mistake of trying to add sintactic sugar in the language
definition for nullable types (with the ? and ?? operators). Don't know about you but Nullable x is way more comprehensive
to me than int? x. I guess after all it's just a matter of taste. I have mixed feelings about the rest of the C# 2.0 features.
Were they REALLY necessary ? I guess the C# team think they are in some kind of competition with the Java guys...think about it..
why the heck they added that half assed template implementation in Java ? I am willing to bet my socks that at least 50% of the reason
is because C# will have generics. To me it seems that the C# team is just adding things because they think they have to compete with Java
and because C# must be cool (Ruby style)....without really asking themselves if we REALLY need them. Do they ONESTLY think that the programmer's productivity is increased by introducing lamdbda functions ?

  What happened to the much (in C# 1.0) touted simplicity ?! (please don't gimme the "don't use them if you don't like them" line). I mean...there is already out there a language that pretty much tries to be everything to everyone. And failed. Do we really want C# to follow the same route ?
We really don't need the things added to C# 3.0 ( or should i say LISP wanna be ?). And also it seems to me that at least some of them
were added to simply allow for LINQ implementation. Not because we want them / need them.
So...C# team...what happened to the balance between simplicity and power ?


PS : Also....why the HECK var ? It's not like C# is Pascal. Why not remove the var entirely and just let the name of the variable? It makes
way more sense than var.

 

I wrote a comment to the DLinq PM blog (http://blogs.msdn.com/dinesh.kulkarni) couple of days ago with some critics to Dlinq mapping. It seems to me that Microsoft employees don't take critics too well because my comment got deleted. So i have decided to write them here. So here they are :

Attribute based mapping. Atrribute based mapping has a few disadvantages :
- it's slow. Due to heavy usage of the Reflection API it's slower than Xml based mapping
and , of course, a heck of a lot slower then direct mapping calls.
- it needs a separate API that you need to learn to extend DLinq.
- the mapping atrributes need to be cached for further reuse. Now imagine
what happens when mapping attributes of 100 database tables are cached....the working set goes to the roof.

There are basically 3 ways to map database schema info : attribute mapaping, xml mapping and direct mapping (which
we used in DataBlock). With attribute based mapping MS made the worst choice between those 3.

Database specific attributes mapping :
This pretty much by itself should give us a clue that MS doesn't want DLinq to play nice with other RDBMS vendors.
It saves Sql Server specific types in the attributes mapping. If you want to create a RDBMS independent O/RM that's
definitely a no no. Another problem with their mapping is that it doesn't support type which are not supported by Sql Server.
How would i map a PostgreSql Point type with Dlinq ?

DataContext
So the DataContext itself it pretty much a database connection. In a database independent O/RM a database connection
is pretty much described by 3 attributes :
- connection string
- database server type (Sql Server or PostgreSql for instance).
- provider used to connect to the database. This may not be useful if you're working with SqlServer only but
it's very useful when working with 3rd party RDBMS.
DataContext uses only a connection string. So it seems that there is no way for Dlinq that allows you to use a different
database server then Sql Server. In the documentation it's mentioned a "strong typed connection" using a class which
derives form DataContext. The downside of this approach is that you HAVE TO ADD THE mapped objects to the DataContext !!!!
Why ?! Why ? A mapped object...it's just that....a object. A POCO (Plain Old CLR Object). Why do you constrain me to
associate it with a typed DataContext ?
Another problem with their DataContext approach is that is too low level. In a business application you usually have business
objects to whom you pass these mapped objects and , from there, they go to the database. With a DataContext i'm sure there
will be plenty of people who will update the database from the event handler in the GUI. That's bad...

So there you go....this is what i think it's wrong with the current architecture of DLinq so far.

 

    Just finished reading "Concepts in programming languages" (published by Cambridge Press). It 's a book about programming languages (both procedural and OOP) and concepts (high order functions, templates, OOP pillars etc). Recommanded if you're interested in programming language theory.

Downsides from my point of view :

- no Ruby or C#.

- the praises for the C++ language design were waaaay too much.

Recommanded if you’re into programming languages theory.

 

Finished the game last night. I was interested in the game because the story was written by R.A. Salvatoare so i thought it's going to be good. Big dissapoiment. The game is simply a 3rd person hack and slash  with a vaguely sketched story. Anyway :

good stuff :

- you get to play as Drizzt :)

-nice action packed scenes in the last 3-4 chapters.

bad stuff :

- bugs. Lots of them. I couldn't finished 2 chapters because of showstopping bugs (i had the patch installed).

-simple story.

-fixed keys.

-one dialog said "Please press the triangle button !!!!".

-the game is a little bit hard.

-battle pshysics and mechanics were downright bad when compared to games like POP: Warrior Within.

- too short.

Listened to latest Opeth last night. Very good album. Wholeheartedly recommended. Also...music related...i'm going to a Nightwish concert tonight in Bucharest. It should ROCK.