Wed 4 Oct 2006

speaking in boston

Posted by johannes.nel under as
No Comments 

at the design patterns user group tonight. its over at brightcove in cambridge (on the T kendall/MIT)

all good fun.

 

Sat 30 Sep 2006

XP is a productivity metric not a planning process.

Posted by johannes.nel under worflow
No Comments 

For the last couple of years i have been a great proponent of XP. I have seen it work, i have seen it fail. I have seen products delivered where features had to be cut in a realistic fashion due to time constraints which the XP approach pointed out and i have seen deadlines for releases missed due to the aggressive feature creep that some managers think they can slide in because XP is agile after all and if the client/truth wants it, well its got to be there, init.

Any system can only carry the blame if it was rigorously applied and failed to deliver the expected result. So obviously me being negative about XP when i have seen it work would imply that in essence i see nothing wrong with the process itself but rather in its application in real life institutions. I mostly see it fail when companies adopt the xp paradigm (mostly coming over from the waterfall model) and confusing the agile process with doing no planning at all. Yes, change is a constant, but certain features are known from the start. Yes, requirements will change, but all requirements are not guaranteed to change, actually you have no grunter’s that anything will change.

So suddenly the planning game in XP has become the planning process. Features are specified with little requirements, thus stories are underdeveloped and tasks do not meet the descriptive level they should. This makes me uncomfortable, taking the strong point of XP (the iteretive adaptive nature of developing a product) whilst combining it with an extremely haphazard approach. From experience the most successful XP projects i have worked on had the features defined to a level of reasonable granularity before it started, design was 80% fixed already, the the time line as to which features were to be done in which order (according to dependency and weight/importance) mapped out.

Suddenly XP comes into its own under these conditions, it becomes a metric whereby we can determine accurately during the development process (which can take months or years) whether we are on target. We can measure the velocity (the amount of perfect engineering hours they can do in a week) of developers, the accuracy of their estimation (perfect engineering hours quoted versus time took). Using helpers like burn down charts we know each day and each week exactly what the status is of the current iteration and the project as a whole is. This is the beauty of XP, we can adjust what can be done, we can change requirements and the whole time the client knows and feels empowered.

Badly designed features which gets developed in the development process is part of r&d not product development. XP should not be a scape goat for project managers who do not want to do project management.

 

Sun 10 Sep 2006

speaking in london and a bit more

Posted by johannes.nel under Uncategorized
No Comments 

its been a while since i have written anything here. currently i am in boston consulting, one more week to go on this trip. during my time here i have attended the boston flash user group and the boston design pattern meetings managing to win a free copy of flex builder 2 (yeah!! - thanks keith!). both these meetings were brilliant. congrats to chris allen on getting married yesterday, he was looking rather  stressed at the pattern meeting !

my next stop is london, i will be speaking at the london flash platform usergroup about databinding and the flex framework. then ireland and scotland for a bit after which off to africa again, this year i will be in cape town for the south african summer, i will be having a beach christmass and not looking out for snow.
on a side note me and peter hall started a consulting/development company based in london and south africa and then obviously working anywhere in the world. tis been a busy time

 

Wed 28 Jun 2006

states in flex 1.5

Posted by johannes.nel under flex , as
No Comments 

After playing for a while in flex too i had to do two flex 1.5 projects in a row (of which the second one is in progress). I found states to be an excellent mechanism for laying out forms and applications in flex 2, and pined for simmiliar functionality in flex 1.5. As sometimes happens i happened to stumble on an oppurtunity to build this.

so here is my implementation of states in flex 1.5, on my to-do list is being able to specify which transitions should run when changing one state to another as  this is standard at the moment. also due to licensing issues (i have applied for a flex 1.5 community license and it is being processed) i cannot currently post an example swf, but find included a complete application.

the only tag that is suported  at the moment is the setProperty tag. also note that th default property for the basedOn attribute is the currentState="".

so if you, like me, have to do some flex 1.5 stuff from time to time still, well i hope this helps.

here is an sample of a mcml component.

btw do not use this in the root application (mx:application tag) as it doesn't work in there, too lazy to figure out why, and i never put any code in there anyway so...

PLAIN TEXT
XML:
  1. <mx:VBox xmlns:mx="http://www.macromedia.com/2003/mxml"
  2. width="100%"
  3. height="100%"
  4. xmlns:states="com.memorphic.states.*"
  5. creationComplete="onCreateComplete()"
  6. implements="com.memorphic.states.IViewState"
  7. xmlns:examples="com.memorphic.examples.states.*"
  8. resizeEffect="__resize"
  9. >
  10.  
  11. <mx:Script>
  12. <![CDATA[
  13. import com.memorphic.states.ViewStateController;
  14.  
  15. private var __viewStateCon:ViewStateController;
  16. private function onCreateComplete():Void
  17. {
  18. __viewStateCon = new ViewStateController(this,data.firstChild);
  19. }
  20. public function setCurrentState(stateName:String):Void
  21. {
  22. __viewStateCon.setCurrentState(stateName);
  23. }
  24. public function getCurrentState():String
  25. {
  26. return __viewStateCon.getCurrentState();
  27. }
  28. public function set currentState(stateName:String):Void
  29. {
  30. setCurrentState(stateName);
  31. }
  32. public function get currentState():String
  33. {
  34. return getCurrentState();
  35. }
  36. private function changeState(stateName:String):Void
  37. {
  38. currentState = stateName;
  39. }
  40. ]]>
  41. </mx:Script>
  42. <mx:XML id="data">
  43. <states>
  44. <state name="leftExpand">
  45. <SetProperty target="__left" name="width" value="400" />
  46. <SetProperty target="__middle" name="width" value="200"/>
  47. <SetProperty target="__middle" name="x" value="400"/>
  48. </state>
  49. <state name="rightExpand">
  50. <SetProperty target="__right" name="width" value="400" />
  51. <SetProperty target="__middle" name="width" value="200"/>
  52. <SetProperty target="__right" name="x" value="400"/>
  53. </state>
  54. <state name="bottomExpand">
  55. <SetProperty target="__left" name="height" value="0" />
  56. <SetProperty target="__middle" name="height" value="0" />
  57. <SetProperty target="__right" name="height" value="0" />
  58. <SetProperty target="__left" name="visible" value="0" />
  59. <SetProperty target="__middle" name="visible" value="0" />
  60. <SetProperty target="__right" name="visible" value="0" />
  61. <SetProperty target="__bottom" name="height" value="600" />
  62. <SetProperty target="__bottom" name="y" value="0" />
  63. </state>
  64. <state name="bottomAndResize" basedOn="bottomExpand">
  65. <SetProperty target="this" name="height" value="200" />
  66. <SetProperty target="this" name="width" value="200" />
  67. </state>
  68. <state name="bottomAndLarger" basedOn="bottomAndResize">
  69. <SetProperty target="this" name="height" value="500" />
  70. <SetProperty target="this" name="width" value="500" />
  71. </state>
  72. </states>
  73. </mx:XML>
  74. <mx:HBox>
  75. <mx:Button label="left expand" click="changeState('leftExpand')"/>
  76. <mx:Button label="right expand" click="changeState('rightExpand')"/>
  77. <mx:Button label="bottom expand" click="changeState('bottomExpand')"/>
  78. <mx:Button label="middle expand" click="changeState('')"/>
  79. <mx:Button label="based on" click="changeState('bottomAndResize')"/>
  80. <mx:Button label="based on 2" click="changeState('bottomAndLarger')"/>
  81. </mx:HBox>
  82. <mx:Canvas>
  83. <examples:Left id="__left" width="200" height="400" resizeEffect="__resize" moveEffect="__move" hideEffect="__fadeSlow" showEffect="__fadeQuick"/>
  84. <examples:Middle id="__middle" width="400" height="400" x="200"  resizeEffect="__resize" moveEffect="__move" hideEffect="__fadeSlow" showEffect="__fadeQuick"/>
  85. <examples:Right id="__right" width="200" height="400" x="600" resizeEffect="__resize" moveEffect="__move" hideEffect="__fadeSlow" showEffect="__fadeQuick"/>
  86. <examples:Bottom id="__bottom" width="800" height="200" y="400" resizeEffect="__resize" moveEffect="__move" hideEffect="__fadeSlow" showEffect="__fadeQuick"/>
  87. </mx:Canvas>
  88.  
  89. <mx:Effect>
  90.  
  91. <mx:Move name="__move" duration="500" />
  92. <mx:Resize name="__resize" duration="500"/>
  93. <mx:Fade name="__fadeQuick" duration="500"/>
  94. <mx:Fade name="__fadeSlow" duration="1000"/>
  95. </mx:Effect>
  96. </mx:VBox>

i would like to thank my current employers who allowed me to blog this :)

sample app

 

Sat 10 Jun 2006

flex - continues integration

Posted by johannes.nel under worflow
No Comments 

in case you missed this paul barnes-hogget published an excellent article about our CI process we use at the large finicial institution i am contracting to.
http://www.eyefodder.com

this was largly his baby, with the rest of us chipping in here and there.

process is king...

 

— Next Page »