Friday, 9 January 2009

Visual Studio slow in source mode [Solved]

It has been a pain in the ass for me to use the graphical designer in Visual Studio. Instead I have used writing the markup of web pages and controls using the keys. It went several times faster, but still, it lacked the speed of any text editor I have ever seen. Moving up, down, left, right with the keys would make the system lag, jerk, etc. It was never too annoying to investigate until today.

What happends is that whenever you work in a VS window, it sends events to just about everything on the screen. The more windows you have open, the more it lags. And the culprit for this particular problem: the Properties window. Every time I was moving with the keys it tried to update itself with the information of the object I was moving over. Closing the Properties window fixed it! \:D/

Thursday, 8 January 2009

Avalon - Bryan Ferry & Roxy Music

I heard a bit of this song in a super market and remembered it and couldn't get it out of my head. The funny thing is that when I listened to it properly, it didn't sound so good as I remembered it... Is there another version or is my memory playing tricks on me?

Anyway, here it is, British singer Bryan Ferry playing with his band Roxy Music.


Creating Dynamic User Controls with ViewState _from_ ViewState

I will write a really short post here, maybe I'll complete it later. I had to create some controls dynamically on a page. I used a ViewState saved property to determine the type of the control I would load (in Page_Load). It all worked fine until I've decided to add some ViewState saved properties in the dynamic controls. Surprise! The dynamically created controls did not persist their ViewState and my settings got lost on postback.

It's a simple google search away: dynamically controls created in Page_Load have empty ViewState bags. You should create them in Page_Init. But then again, in Page_Init the page doesn't have any ViewState, so you don't know what control type to load. It seemed like a chicken and egg thing until I tried the obvious, since the ViewState is loaded in the LoadViewState method, which is thankfully protected virtual, why not create my control there, after the page loads its view state? And it worked.

Bottom line:
protected override void LoadViewState(object savedState)
{
base.LoadViewState(savedState);
CreateControl(ControlName);
}

Scrum and XP in short

First of all, I seem to be the proverbial man who can't do it so he teaches it. I've not worked in a Scrum or XP environment, but I did read a few books about them and this is what I gathered. I beg of you to point out any mistruth or inconsistency. You might want to take a look at this previous post, more general post, on the matter of agile development.

Some key elements of all agile methods I've read about are:
  • the code does not belong to any programmer, in other words anyone can change any piece of code in order to solve an issue
  • the members of the team are interchangeable, so not a bunch of experts in different fields, but people that can do all things (and be easily replaced by people just as agile as them :) )
  • the members of the team must have similar competencies, one cannot do pair programming between a rookie and a senior, for example. That is called teaching :)
  • the client is supposed to change their mind often and unpredictably, one plans for the unplannable
  • the client must be represented in the agile team, so as to not have delays or misunderstandings in requirements


Scrum



The Scrum system does seem to be more of a disciplined way of developing than a method in itself. There are Scrum principles that must be upholded, but if you ignore them, the whole system looks like this:

  • All development is done in fixed time increments called Sprints. Scrum specifies 15 or 30 days, although I bet most dev companies actually plan this on a calendaristic month.
  • At the start of each Sprint a meeting of 8 hours takes place (so the first day) in which half of it is to present the requests by the Product Owner (in our case that would be either the client or the person that did the analysis) and the other half to plan which of the tasks in the Project BackLog (requirements list) can be done in the current Sprint. This last part if the responsability of the Team (that would be the developers and their team leaders and managers).
  • In the last day of the Sprint two meetings will be held: a 4 hour meeting that will allow the Team to present what was done in the current Sprint to the Product Owner (this would be an informal meeting that "is intended to bring people together and help them collaboratively determined what the Team should do next") and a 3 hour meeting in which the ScrumMaster (the person in charge with the implementation of Scrum in the project) "encourages the Team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint"
  • The development is one in the rest of 28 days
  • Each day there is a 15 minute Scrum Meeting held within the Team in which "each Team member answers three questions: What have you done on this project since the last Daily Scrum meeting? What do you plan on doing on this project between now and the next Daily Scrum meeting? What impediments stand in the way of you meeting your commitments to this Sprint and this project? The purpose of the meeting is to synchronize the work of all Team members daily and to schedule any meetings that the Team needs to forward its progress".


What is important about these Sprints is that at the end of each sprint the product should be fully implemented, tested and ready for production. At each increment the client could just take the product and leave. Any changes to the specifications must be included in the backlog and prioritised so that the developers apply them in the next Sprints. Once a Sprint is planned, there are no changes to it.

So, as far as I understand, this is a method of making rigid planning for very small periods of time, then executing it, effectively reducing each project to a bunch of smaller ones. Instead of "Make me a business management application" there will be projects like "Make me a member management interface", then "Add activities management" and so on. It reminds me of the time when I wanted to learn in college and I would divide the number of pages I had to understand and memorize to the number of days remaining till the exam.

I don't consider Scrum a very innovative way of development, although back in 1986 it probably was, but that's also good. One can easily adapt some of these ideas to their own system of development. By allowing the developer to build a finite number of things in a predetermined time, they can select a time to test the application in which they are certain no more requests will delay that process. Of course, I don't know what happends if the client changes their mind about a thing that is supposed to be done in a Sprint. Do we abandon the task in the current Sprint and plan it modified in the next? Do we build it as if nothing happened, then start making the changes or, worse, remove it?

XP (Extreme Programming)



The Extreme Programming development method seems to have the same roots as Scrum does. The idea is to develop in successive iterations that encapsulate planning, testing, development and refactoring. The "12 principles" of XP are again and again mentioned in the book, but I think that's crap. The most important ideas in XP, to me at least, seem to be :
  • User stories as requirements gathering; Most important! a detailed story of what the user will do and why, like a narrative, the Word version of an UML flow diagram, which is the responsability of the client! The actual developing is the implementation in code of those stories
  • iterations, which in the case of XP don't have a specific time length, each one is planned depending on what there is to do and what can be done
  • the separation of user and client, the user is the one that actually uses the program, while the client... well, you know
  • user-on-site, you can always ask the user what they think and receive quick feedback
  • Test driven development, which, together with pair programming, seem the only actual extreme parts of XP, where they insist on tests first, programming later.
  • Spikes: small bursts of programming for no other reason than to research an idea. Developers don't have to be rigurous in spike programming, since they only do the bit of code, test its functionality, then throw it away, the idea being that they learn how to do the actual code they wanted to do and what problems they might be facing. In this particular case, the spike is part of the planning or designing of a piece of code.


I will mention here Pair Programming as well, although I clearly don't see it happening. The idea is that two programmers sit on the same machine, one programs, while the other does just-in-time code review and thinks of the large implications of the code. While the concept is sound and I seldom find myself wanting to be able to code and also think in a larger context, I don't see how this can be done anymore than a master painter could get help from a second one that watches from afar and keeps nagging him on how to do things. Besides, sitting near a code that is being written sounds both boring and terribly frustrating.

But then again, I always like talking to other programmers that are as passionate as I am, so maybe a hands-on discussion, even an argument, might provide the drive to good code. Besides, it is harder to waste time on news sites and online games when you have some guy next to you :)

Conclusion



My conclusion is that agile is a solution to the problems that arose during the Waterfall days. It is not a solution to all problems and it certainly presents some level of difficulty in implementation.

I believe it would be hard to do in a small team with high turnover. One needs a stable team that works well together and has a decent management to implement agile development. But I do see it as a positive thing, as it puts the needs of the customer first and, no matter how good a coder you are, your primary goal is to satisfy the client.

Wednesday, 7 January 2009

i=i++ - The trials and tribulations of the C incrementer

Here is a point raised by Tudor, from the infamous Romanian blog it-base.ro. Incidentally, he does some teaching in the Java field and is a good web designer and PHP programmer.

Ok, some of you know those informatics teachers that start talking about a programming language by giving you a silly problem that would never occur in real life or by asking you to "decypher" a piece of code that looks unusable in any scenario. But bare with me and try to think this through before you read on in the post.
Question: what is the value of i (initially 0) after the following operations in C#?
  • i = i++
  • i = Math.Pow(i++,2)
  • some method that ends in return i++


First, let's think about the meaning of this ++ arcane symbol. It means increment a number, or add 1 to it. In C based languages, you can use it either after or before a variable, thus changing meaning to add 1 to i after or before assignment. As MSDN says: "The increment operator (++) increments its operand by 1. The increment operator can appear before or after its operand:
++ var
var ++
The first form is a prefix increment operation. The result of the operation is the value of the operand after it has been incremented.
The second form is a postfix increment operation. The result of the operation is the value of the operand before it has been incremented."


Now the answer is pretty clear: i will be zero after any of the operations described above. But why?! Let's examine them a little.

The first makes no sense in real world, but you could easily imagine something like i=j++ that could be used somewhere and that makes sense to set i to the original value of j, then increment j. But then doesn't it mean that i should be 1 because it gets incremented after the assignment? Well I think it should, as the last operation, but what I think happends is that the value for i gets pushed in a stack, then retrieved at the end of the sentence like this:
  i = i
push 0 to stack as the value of i
i++
push 1 to stack as the value of i
pop value of i from stack (1)
pop value of i from stack (0)


Ok, ok, I guess that makes some sort of sense, but what about that int F(int i) { return i++; } thing? Shouldn't it increment i after the operation then return it? Apparently not. The method returns the value of i and aborts the pending increment operation.

According to Tudor, PHP would return 1 in these situations, although most C implementations, including javascript, return 0. Update: he later posted a comment retracting that statement. He also suggested it would be hard to debug something like this in case it happends. Ha! My beautiful ReSharper Visual Studio addon immediately added a wiggly line under i and said value assigned is not used in any execution path. ReSharper - Computer teachers : 1-0 ! :)

Monday, 5 January 2009

Serializing objects in .Net

This was something I have been meaning to write for quite some time, but actually, I've never had to work with a proper serialization scenario until recently. Here is goes:

First of all, whenever one wants to save an object to a string they google ".Net serializer" and quickly reach the XmlSerializer because that's what most people think serialization is. But actually, it is not. The whole point of serializing an object is that you can transfer and store it. Therefore you need to use a format that is as open, clear and standard as possible and to send only the relevant data, which in case of objects is the PUBLIC data. And for that, the XmlSerializer does its job, albeit, it does have some problems I am going to describe later.

But suppose you didn't really want to send mere data over to another computer, but an entire class, with its state intact, ready to do work as if the transfer never happened? Then you need to FORMAT the object. Enter the IFormatter interface with its most prominent implementation: BinaryFormatter. Funny enough, the methods used to spurt an object through a stream are also called Serialize and Deserialize. The advantages of the IFormatter way is that it is saving the entire object graph, private members included, and doesn't need all the requirements the XmlSerializer does. It also produces a smaller output. So, is this it? Why use Xml (which everybody secretly hates) when you can use the good ole obscure binary file with almost no trouble? Well, because of the almost. Yes, this way of doing things is not fullproof either.

Some people feel that the sending only the data is not serialization, and that the saving of the completele graph and internal state of the object is. Wikipedia says: "serialization is the process of converting an object into a sequence of bits so that it can be stored on a storage medium (such as a file, or a memory buffer) or transmitted across a network connection link. When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object.". So, they bail by using the obscure phrasing of "semantically identical", which pretty much says "they mean the same thing even if their structures may differ". So, I think I am in the right, as the BinaryFormatter has real issues with structure change.

Now for the quick and dirty reference:
The XmlSerializer
  • Only serializes public READ/WRITE properties and fields - it doesn't throw any error when trying to serialize readonly properties, so be careful
  • Needs the class to have a parameterless constructor - this pretty much restricts the design of the classes you can serialize
  • Does not work on Dictionaries
  • Does use a Type definition to serialize and deserialize, which means you can still use it if the types are named differently or of different versions, even if they are radically different, as it will only fill the values that it stored and not care about the others
  • There are all sorts of attributes one can decorate their classes with to control serialization as well as some events that are fired during deserialization
  • Has issues with circular references
  • If your class implements IXmlSerializable it can control how the serialization is done

The BinaryFormatter
  • It serializes both public and private, readonly or read/write properties and fields as long as their type classes are marked as Serializable - that sucks for classes that are not yours
  • It's a rigid method of serializing objects - if you change the source or destination objects or even their namespace, the deserialization won't work

The SoapFormatter
  • Just when I thought that a class that combines the benefits of both BinaryFormatter and XmlSerializer exists, it appears it has been obsoleted in .Net 3.5. Besides, it did far less than the BinaryFormatter


It seems that Microsoft's idea of serialization blatantly differs from mine. I would have wanted a class that can serialize binary or Xml based on a simply property, send public OR both types of fields and properties, be flexible in how decorating attributes are used and what the output is. In my project I had to switch from BinaryFormatter, which seemed to solve all problems, to XmlSerializer (thus having to change a lot of the classes and design of the app) just because the type of the class sent by the client application could not have the same namespace as the one on the server.

That doesn't mean one cannot build their own class to do everything I mentioned above, of course. Here are some CodeProject examples:
A Deep XmlSerializer, Supporting Complex Classes, Enumerations, Structs, Collections, and Arrays
AltSerializer - An Alternate Binary Serializer.

Update: the .Net framework 3.5 has added an object called JavaScriptSerializer which turns an object into a single line of text, JSON style. It worked great for me in order to log hierarchical or collection based data. Use it just like the XmlSerializer.

Another link to check out is this one: Fast Serialization, but read the entire article before using any code.

Sunday, 4 January 2009

Happy New Year!!! [Party trompet and silly face]

Well, I am alive and blogging. It is a new year, one that brings as much hope and fulfilment as the last one (lots of hope there!), the big 2009. I can vaguely remember a kid that computed his age for the year 2000 and thought "I will be old enough to go to Mars!", but apparently, no human is old enough yet.

So what am I planning this year? Getting back on track would be a good idea. Stop wasting time that I don't have and if I have and waste, then I don't deserve. My book? Ahem. Let's hope I get inspired beyond the mere autobiographic. My AI MMORPG WMATCL project? I still have to design an AI that is worthy of its name. My job? Well, it's still there. I find myself wondering why? from time to time, but I guess it is good to have a job in this troubled time. My blog? Well, I intend to spice it up, but I need to actually do interesting stuff for that. I will update it with info gathered from a new Windows Forms application that I am building as well as information about the ReportViewer control that I've finally managed to use and to love/hate. My personal life? I have reached that point that many people find themselves at without really understanding how they got there. I've made the compromises that make one accept their life "as is" and postpone who they are. Sometimes that "myself" I have imprisoned deep inside growls and pulls on the bars. But maybe he's there for life (pun intended). Then again, maybe not. He feels more and more like a stranger now.

Oi! What's with the depressed text!? Forget all that! It's a new year! Happy new year!!! [Party trompet and silly face]