Follow latest changes in MS top team and considering facts described in this article, there are string reasons to beliveve that Silverlight is dead or dying. ... or no... let read the post carefully ... is is dying everywhere?
.. but do not rush to through away. Consider also facts and thought described here.
PS: it is interesting that it is also believed that dynamic languages are lacking the public attention and so is under the danger
Saturday, 30 October 2010
Friday, 29 October 2010
A topic for diploma: performance testing strategies.
Another interesting topic for the bachelor and master diploma: performance testing strategies.
In order to start listen carefully this presentation.
Thereafter
1. follow it in writing - consume the known strategies, steps etc
2. Think what questions this presentation raises?! For example, what is most important - test on stable code,i.e. branch the code to be performance tuned or to ensure performance of the most recent code? When one or another scenario can be used?
In order to start listen carefully this presentation.
Thereafter
1. follow it in writing - consume the known strategies, steps etc
2. Think what questions this presentation raises?! For example, what is most important - test on stable code,i.e. branch the code to be performance tuned or to ensure performance of the most recent code? When one or another scenario can be used?
Friday, 22 October 2010
On incorrect attitude of being agile
Another interesting article that races important questions: "Bad attitudes of Agile".
First of all the common believe into the self-organising leads a lot of people to a believe that managers are not needed any longer. Well, although it is partly true, self-organising is an important aspect of been agile, still there is no points to underestimate the role of manager and its duties, which can be fulfilled by people under different labels (names).
1. The leadership role. Somebody need to draw the line following which we arrive to the success and encourage the team in difficult times
2. The secretary or administrative role. We all would like to be self-organised, but don't want to be organising meetings, keeping notes and putting together a budget. Hey, we are developers and that is what we will be doing - is the biggest mistake to make as it produces a chaos instead
Secondly. The iterational development leads us to a believe that there is no end date (we are done right after everything is developed). We easily forget that each iteration should be a ready to deliver software, especially basing on the fact that several iterations in the beginning will not be such. So instead of saying: there is a deadline with a varying content we say - no deadline
Finally the motto "all are equal and no docs" are clearly over prioritised. We cannot build a document in the beginning especially the full one, since we don't know how the prioritisation will be during, what will be added or skipped, how we change the project after each demo. But it doesn't mean we should not keep the track of made decisions and do not doc the functional behaviour of the software. How we later can test it or let know customers how to use without it? Regarding testers. Well everybody is equal and this system is a socialism. In fact "some persons are more equal than others" :) - practically the software engineering skills and much more rare than software testing skills and therefore it is sometimes impractical to make all tests unless we luck testing resources. So we need testing and we need a constant testing of being in development and released software to guarantee a certain level of quality
First of all the common believe into the self-organising leads a lot of people to a believe that managers are not needed any longer. Well, although it is partly true, self-organising is an important aspect of been agile, still there is no points to underestimate the role of manager and its duties, which can be fulfilled by people under different labels (names).
1. The leadership role. Somebody need to draw the line following which we arrive to the success and encourage the team in difficult times
2. The secretary or administrative role. We all would like to be self-organised, but don't want to be organising meetings, keeping notes and putting together a budget. Hey, we are developers and that is what we will be doing - is the biggest mistake to make as it produces a chaos instead
Secondly. The iterational development leads us to a believe that there is no end date (we are done right after everything is developed). We easily forget that each iteration should be a ready to deliver software, especially basing on the fact that several iterations in the beginning will not be such. So instead of saying: there is a deadline with a varying content we say - no deadline
Finally the motto "all are equal and no docs" are clearly over prioritised. We cannot build a document in the beginning especially the full one, since we don't know how the prioritisation will be during, what will be added or skipped, how we change the project after each demo. But it doesn't mean we should not keep the track of made decisions and do not doc the functional behaviour of the software. How we later can test it or let know customers how to use without it? Regarding testers. Well everybody is equal and this system is a socialism. In fact "some persons are more equal than others" :) - practically the software engineering skills and much more rare than software testing skills and therefore it is sometimes impractical to make all tests unless we luck testing resources. So we need testing and we need a constant testing of being in development and released software to guarantee a certain level of quality
Saturday, 9 October 2010
Software architect role in agile projects
Discussing the role of software architect we need to consider the following:
In the agile development we are moving away from the waterfall method. This means that we have no way to build the full architecture of the system in the beginning phase since we have no basis for this, no specification to follow, no full description of features that will be implemented and no time to be spent on this task.
In the result we are urning around the process of building the architecture - from the concept in the beginning to the periodic refactoring after x iterations and the constant control of what is happening in the system, monitoring of problems developers are dealing with due undecided or new gaps in the architecture.
All this (but in the more structure way) is described in this article, and presented here.
TDD is great for some project, but in many it gives just a false feeling that errors are under control
Comments following "Agile Ruined My Life" post
TDD is great, for SOME things. In other cases it can just add hassle and has the danger of providing a false sense of security. If I come across a project that does nothing but TDD and sees that as the only validation of their work that is necessary (this happens very often) I can pretty much guarantee I can find higher level functional, flow and integration cases that break the carefully constructed classes.
Now the core of the app itself involved juggling about 50 complex files at the speed of vim with multiple teardowns and rewrites over the course of a few days. Lots of experimentation and learning. Any tests that I would have written would have broken irreparably within minutes. It was a purely creative endeavor. You cannot do that with TDD and if you try you will spend weeks refactoring tests and not seeing the forest for the trees.
By far the best thing TDD has brought to the table is test frameworks though. Having a nice place to throw all your throwaway assertions on acid is awesome and really does add to the confidence level even if it affirms that you just broke an assumption you intended to break.
TDD - is a very popular technique nowadays. Unfortunately there is very little number of tools that are universal. Therefore it is necessary to clearly identify for yourself - where the tool should be used and can save a project from failure and where appliing the tool can be either pointless or even harmfull.
TDD is great, for SOME things. In other cases it can just add hassle and has the danger of providing a false sense of security. If I come across a project that does nothing but TDD and sees that as the only validation of their work that is necessary (this happens very often) I can pretty much guarantee I can find higher level functional, flow and integration cases that break the carefully constructed classes.
TDD is good for braindead simple crap programming where you have a well defined set of requirements and need to slog through them. I used it today when I needed to write about 30 java classes to fill in the functionality of an app I had built. That allowed me to both ensure that I had all the details working and test the framework itself and ensure it did everything I intended it to do correctly.
Now the core of the app itself involved juggling about 50 complex files at the speed of vim with multiple teardowns and rewrites over the course of a few days. Lots of experimentation and learning. Any tests that I would have written would have broken irreparably within minutes. It was a purely creative endeavor. You cannot do that with TDD and if you try you will spend weeks refactoring tests and not seeing the forest for the trees.
By far the best thing TDD has brought to the table is test frameworks though. Having a nice place to throw all your throwaway assertions on acid is awesome and really does add to the confidence level even if it affirms that you just broke an assumption you intended to break.
TDD - is a very popular technique nowadays. Unfortunately there is very little number of tools that are universal. Therefore it is necessary to clearly identify for yourself - where the tool should be used and can save a project from failure and where appliing the tool can be either pointless or even harmfull.
IKT TTU
FYI:
Lugupeetud doktorandid,
IKT doktorikool kuulutab välja stipendiumikonkursi.
Stipendiumi taotlemiseks tuleb esitada taotlus.
Taotluse elektrooniline vorm on kättesaadav doktorikooli kodulehel aadressil http://iktdk.dcc.ttu.ee/form_
TAOTLUSTE ESITAMISE TÄHTAEG ON 18. OKTOOBER 2010.
Thursday, 7 October 2010
Are we close to the dot agile crash?
One of the best articles I have recently read - "Agile Ruined My Life". The situation, from my point, is very like described and greatly reminds to me our position before the dot com crash - the idea by itself is very good, but we were trying to make it work too fast without properly thinking, using wrong tools and with a lot of people who factually lied consuming the idea, not developing that.
Sunday, 3 October 2010
Repost: Wanted: new scientific talent
Repost
Wanted: new scientific talent to support EU policy-making - The Joint Research Centre launches recruitment drive
Researchers from across the EU are encouraged to apply for a challenging and rewarding job in the European Commission's own research body, the Joint Research Centre (JRC). Working for the JRC brings together research excellence in state-of-the-art facilities, and an opportunity to support EU policy makers by providing independent scientific and technical advice. Competitions are open for researchers in the following fields: chemistry, biology and health sciences; physics; structural mechanics; quantitative policy analysis; spatial sciences; environmental sciences; energy sciences and communication/information technology. Candidates can apply on-line between 30 September and 4 November at: www.eu-careers.eu
Read more:
http://www.jrc.ec.europa.eu/index.cfm&id=2300&dt_code=PRL&obj_id=2840
___________________________________________________________________________
EUROPEAN COMMISSION - Joint Research Centre (JRC)
Internal and external communication
SDME 10/78, B-1049 Brussels
http://www.jrc.ec.europa.eu
Email: jrc-press@ec.europa.eu
Tel: +32 2 2957624, Fax: +32 2 2996322
Saturday, 2 October 2010
Simple rules to remember binding business objects to UI in xaml in .Net 4.0
A post for those who are novice in xaml, binding and .Net 4.0
Remeber that
1. variables cannot be bind in xaml, only properties, so when we write in xaml something like
Text="{Binding MyVar, Mode=TwoWay}"
we need to remember to write declaring the classs: instead of
Public MyVar as integer
the following
Public Property MyVar as integer
although
2. You will need to push a notification if you want UI to be updated updating the business object, so use OnPropertyChanged (link) and so writting the full notation (with Get and Set) instead of the short notation we seen above.
3. Don't forget that you either need to rebind lists, or use instead of simply collections like lists and dictionaries an observablecollection etc (link)
Slightly more advance
1. Don't foget that you can use converters binding a property to UI to represent, for example, a boolean value as a picture
<controls:ChildWindow.Resources >
PS: you can easily find in net how to apply the converter in xaml. Besides Utility.ImageHelper.GetImageSource is just illustrative - you will need to write your own code
2. Notice that you can use converter parameters. For example:
but be aware that nature of them is quite static. I mean that you can pass (bind) a property to that, but unfortunately you cannot bind two properties in the effective two way interaction.
Consider for example a simple case: you have a class, which contains an amount and a format to be applied on the amount in UI. you can bind Amount as above, but then you bind the number format, as the parameter is static. OK, you can change it by using the valueconverter as in the item 1 above, to get the entire instance of the class into the convertion function to read both amount and the number format, but then you will lose the two way nature of binding: the convert back will get a number enter, for example, into a text box, but were after convertion it will go? into the entire class? obviously it will not work any longer since you have no reference to the instance to which the inputted property should be placed to. If two way need to be working bind a simple property to make it automatically routed to the right places within the binded instance to be updated following UI update.
Remeber that
1. variables cannot be bind in xaml, only properties, so when we write in xaml something like
Text="{Binding MyVar, Mode=TwoWay}"
we need to remember to write declaring the classs: instead of
Public MyVar as integer
the following
Public Property MyVar as integer
although
2. You will need to push a notification if you want UI to be updated updating the business object, so use OnPropertyChanged (link) and so writting the full notation (with Get and Set) instead of the short notation we seen above.
3. Don't forget that you either need to rebind lists, or use instead of simply collections like lists and dictionaries an observablecollection etc (link)
Slightly more advance
1. Don't foget that you can use converters binding a property to UI to represent, for example, a boolean value as a picture
<controls:ChildWindow.Resources >
<loc:RO_FavImageTypeConverter x:Key="FavConverter" /> </controls:ChildWindow.Resources>
....
<Image Source="{Binding Favorite, Converter={StaticResource FavConverter}}"/>
Public Class RO_FavImageTypeConverter Implements IValueConverter Public Function Convert(ByVal value As Object, ByVal targetType As Type, ByVal parameter As Object, ByVal culture As Globalization.CultureInfo) As Object _ Implements System.Windows.Data.IValueConverter.Convert If value Is Nothing Then Return Nothing Dim bIsFav = DirectCast(value, Boolean) If bIsFav Then Return Utility.ImageHelper.GetImageSource("Resources/favor_yellow.png") Else Return Utility.ImageHelper.GetImageSource("Resources/favor_grey.png") End If End Function
PS: you can easily find in net how to apply the converter in xaml. Besides Utility.ImageHelper.GetImageSource is just illustrative - you will need to write your own code
2. Notice that you can use converter parameters. For example:
Text="{Binding Amount, Mode=TwoWay, Converter={StaticResource nmbFormat}, ConverterParameter='n0'}"
but be aware that nature of them is quite static. I mean that you can pass (bind) a property to that, but unfortunately you cannot bind two properties in the effective two way interaction.
Consider for example a simple case: you have a class, which contains an amount and a format to be applied on the amount in UI. you can bind Amount as above, but then you bind the number format, as the parameter is static. OK, you can change it by using the valueconverter as in the item 1 above, to get the entire instance of the class into the convertion function to read both amount and the number format, but then you will lose the two way nature of binding: the convert back will get a number enter, for example, into a text box, but were after convertion it will go? into the entire class? obviously it will not work any longer since you have no reference to the instance to which the inputted property should be placed to. If two way need to be working bind a simple property to make it automatically routed to the right places within the binded instance to be updated following UI update.
Subscribe to:
Posts (Atom)
