Thursday, November 12, 2009

Virtualization Technology versus VMWare Server :)

Spent quite some time trying to make VMWare Server run 64-bit system (linux gentoo) on the host with 64-bit processor (and 32-bit Vista, which was actually not the problem but seemed to prevent the VM from detecting 64-bit proc). Luckily, I have found this article which cleared up the mist for me :)

What I did wrong:
- I should not have enabled all VT settings. I had Dell OptiPlex 960 with E8400 Intel Core2 Duo processor, and in my BIOS there were 3 settings under Virtualization Support, including the one mentioning "trusted execution". This one should not have been enabled;
- I should have powered the PC down. Virtualization settings are locked when the machine powers up and simple reboot is not enough to change them!

One other thing I did now:
- I have added the setting mentioned in this article:
hv.enableIfUnlocked = TRUE
to my VMWare Server configuration file (I have a Vista Ultimate machine and it happens to be found at C:\ProgramData\VMWare\VMWare Server\config.ini).
May be this also helped, don't feel like disabling it again now when the things work:)

Tuesday, October 20, 2009

Just came back from the very interesting talk (which seems to be obliged with its taking place to twitter and to AgileHolland community) by Robert Martin.

The announced topic was "next programming languages", but the discussion was more broader than that. It was not a specially prepared event, which was just right.

For me, the most noticeable moments were (in no particular order):

- Brief introduction to Ruby and Clojure. What a pity I've not been involved with Ruby earlier! Seems like fun. Clojure - at first glimpse, not sure if it's the language for biological humans but who knows... it does seem to be very concise, but the code with minimal syntax is far from being easily understood. Well, may be, those who did program in List think otherwise. I didn't. Wouldn't mind to give it a try though!

- More about Ruby: the absense of interfaces, or rather, the interfaces reduced to the logical end: every separate function is an interface. Have to think about it. From one side, it seems to be logical. From another side, my feeling is that in this case, you definitely need other methods (like TDD) to ensure you are not getting an unexpected mess, if some object you use does have the method you want to call, but it's not what you think of it!

- The discussion about Scala which followed afterwards. Everybody present appeared to be very interested! Great that Scala seems to be "in the spot". May be transition from Java to Scala might occur in the same way as the transition from C to C++ occured? Again, who knows?.. The key question in relation to this statement was: "What is that little difference in Scala in comparison to Java which would make it like C++ was to C?"  (For me, the biggest similarity is really in the possibility to more or less painlessly switch from Java to Scala, without the need to immediately introduce big changes... and the little difference is "functionality" - the same way as "object orientation" was in C++).

- Seeing somebody at hand distance who can quote the number PI up to 200 digits after decimal point...

Also, the audience (which consisted of an intersection between the Dutch twitter community and the members of Agile Holland) was very enthusiastic and helpful, otherwise the discussion would not be that interesting.

By the way, what would be the next next step? If the functional languages, as it was also mentioned tonight, are on the raise because of the need to handle concurrency properly, what could happen if - for now still very mystical - quantum computation would prove to be a reality after all? Or will it be considered just a very specific type of concurrency? Will assembly still have a chance then? ;)

Last but not least: recommended reading: the book "Structure and Interpretation of Computer Programs" (available online here). "This book will explain, why assignments are bad and why concurrency is a disaster, and how we still can handle concurrency if we get rid of assignments", - according to our guest:)

Now, that's it.

Friday, October 9, 2009

So called little changes...

Almost every time when you hope to escape a little known effort with the help of some less-known trick, you are guaranteed to end up doing more work than was planned.

Fresh example.

We needed to provide a Subversion account for beta-testers (at that moment, there were not too many of them, due to the nature of the project). It could be done by adding one more user to the "real" subversion database, and giving him restricted access to one sandbox directory only. However, this was considered to be too much of a burden (also because until now, there was no per-directory policy). So it was decided to establish a new "sandbox" subversion repository to be used for this project (which was not a bad decision in fact, only it should have been made much earlier).

As a result of that, we've got a week or so delay until all problem with new Subversion repository (which also happened to be established on a newly arrived machine and was using different protocol than the other one - svn instead of http) were cleared up.

Those were:
- some research to adapt the SVN connection layer to svn protocol;
- discovery that if we have SVN with anonymous access (easiest option) then SVN doesn't log the users which breaks some project requirements -> some time to set up the non-anonymous access;
- discovery that the SVN server on that machine was too old in comparison with the one used in the "real" repository, which manifested in the nasty side effects. As a matter of fact, there was a bit of luck, because the machine was using Solaris and the support for a suitable SVN has just been introduced. If it was not the case, the whole effort of setting up SVN there would have to be considered waste;
- discovery that updating SVN server required updating quite a few other services on the same machine and spending time doing that;
- last but not least, one more workaround had to be provided to solve a problem with one library that was mysteriously not found while SVN was running.

To sum up: as a result, we have got some knowledge and lost some time. It was not 100% critical for the given project, but in more pressing situation, a week of delay might have very bad implications. May be, in the research-like project it even makes sense to go untested routes in order to gain knowledge (and actually, this one could be defined as a research).

In the hindsight, at the moment when it was decided to do the less known thing it had to be communicated that the time estimations become risky. But the nice additional twist was that the person who made that decision was sure that "it was supposed to be easy".

How to anticipate that? Via micromanagement, asking everybody to come up with a sketch of what they are going to do? But then you might end up with the other type of waste; besides, in case the person responsible for the task is considered to be a senior specialist, he/she might take such requirement as an offence. (Well, I know how to handle that part in theory: by establishing a formal procedure everybody must follow prior to make any changes... these things don't happen overnight, and I've yet to see the place where they really work).

It all seems to be boiling down to convincing the people to follow these procedures. They can't be forced if nobody sees their value. How to convince people to change? May be they have some deeper reasons to behave like thay behave? (Like the ones described in this article, for example :) )

Remains an open question.

Thursday, October 8, 2009

Some people just don't cooperate - how to convince them?

Quite discouraging to see people who try to be irreplaceable by not sharing their knowledge with others and/or preventing others from helping them.

It often happens when somebody is insecure about themselves - for whatever reason - and is concerned that if he/she gives away all his/her knowledge, he/she will be replaced by somebody who can do the same things quicker.

I wonder what could be done in this situation? (Don't say "fire them", because this is the last resort). How everybody copes with such team members? They are not useless, quite the contrary. They usually know a lot about what has been done in the past. But when it comes to the new things, they are slower and they see it themselves. This makes them nervous and they begin to be suspicious and close down. Add to this the communication problems because of the age / culture gap and you have it :(

Are there any examples of achieving a win-win outcome?

Sunday, September 20, 2009

those redundant brackets :)

this or similar fragment of code :
val a="Hello"
println a
for (i<-args data-blogger-escaped-blockquote="" data-blogger-escaped-i="" data-blogger-escaped-println="">will produce the following error from Scala 2.7.5 compiler:
error: illegal start of simple expression
for (
- which is an example of wrongly reported problem.
The real issue here not with for (which is fine) but with the fact that println argument is not in brackets, and there is no semicolon ending the string. Therefore, the compiler apparently tries to look ahead finding if there is more to add to this string, finds something it doesn't get, and reports an error.

Putting the brackets around the arguments in first println:
val a="Hello"
println (a)
for (i<-args data-blogger-escaped-blockquote="" data-blogger-escaped-i="" data-blogger-escaped-println="">solves it :)

Sunday, September 13, 2009

Found a remarkable piece in The C++ Standard Library of Nicolai M. Josuttis (very useful book, by the way) in the beginning of the chapter dedicated to valarrays:
The valarray classes were not designed very well. In fact, nobody tried to determine whether the final specification worked. This happened because nobody felt "responsible" for these classes. The people who introduced valarrays to the C++ standard library left the committee a long time before the standard was finished. For example, to use valarrays, you often need some inconvenient and time-consuming type conversions...
How many bells did it ring to you, dear software development experts? And we are talking about C++ standard here :) (More revelations about design flaws and omissions could be found in the chapters about the other Standard C++ library components, - bitsets,for example).

By the way, the book has been written 10 years ago and it's still relevant because not many things have changed there. The work to introduce a better C++ standard is going anything but quick.

This probably explains, at least partially, at least to me, why younger folks are turning to the other languages (I mean Java-based crowd) which are largely feedback-driven, with the ability to adapt and/or evolve quickly, and which don't have a gloomy committee overseeing the Grand Design in the authoritative way...

Thursday, March 19, 2009

A necessary preface

This blog is supposed to be a place where I put stories related to my work. I am a programmer (until recently, it was mostly in C++ but times are changing).

Apart from the technical stuff, I am also interested in the ways to optimize the work and to get things better. Don't want to use buzzwords though.

What else? I live in Holland, am a physicist by education and interested in linguistics and AI, but this is not directly related to what I am doing now. At least, not yet.