The following article gives me a possibility to talk about the subject in positive and negative light: It was published in Springer in 2007 and is classified as one of five most popular articles in "Personal and Ubiquitous Computing" subject: check the article "An innovative mobile electronic tourist guide application".
Negatives:
1. From my point of view it was outdated already in 2007 (WAP etc)
2. I was always saying that this kind of working is barely enough for a master of science level and I am extremly surpised to see such article in Springer: it is neither innovative neither analytical: just an engineering task which is rather common
Positive: it gives me a possibility to present to students how little is needed to start the PhD study or how to write master thesis for students having no bright theme
Saturday 31 March 2012
Saturday 30 October 2010
There are strong reasons to believe that Silverlight is dead?
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
.. 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
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.
Subscribe to:
Posts (Atom)
