tag:blogger.com,1999:blog-23415029151196318502024-03-13T05:23:58.170+01:00The Puf PrincipleFrank van Puffelens thoughts and ideas on programming, software development and technology in general.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.comBlogger74125tag:blogger.com,1999:blog-2341502915119631850.post-91032756499593188602014-08-24T22:06:00.000+01:002014-08-24T22:06:06.450+01:00StackOverflow killed my blog<p>It's hard enough to have a full-time developer job and to also maintain a blog about development topics. Especially if you can't (or are not willing to) share content from your day-time job verbatim onto your blog.</p>
<p>But it gets even harder to maintain a decent presence on such a blog if you find yourself competing with the most fearsome competitor of all: yourself.</p>
<p>I've found that most of my relevant writing that is publicly accessible happens on <a href="http://stackoverflow.com/users/209103/frank-van-puffelen?tab=answers&sort=newest">StackOverflow</a>. There is just something intensely satisfying about seeing a question there, figuring out what the person asking did wrong and then mentally diving into their brain and trying to understand why they did wrong what they did wrong.</p>
<p>Once I am able to figure out where the OP (Original Poster) went wrong, I try to write a comprehensive answer that doesn't just solve the problem of the OP, but hopefully will also help others in the future that make the same mistake. Because for every person asking a question, there will be 10 more people later with the same problem who are afraid (or unwilling) to ask the question on a public forum. And that is fine. StackOverflow will show up in their search results and developers tend to trust StackOverflow answers, especially those that have received a high number of upvotes.</p>
<p style="margin-left: 3em; margin-right: 3em"><i>I don't know if Google uses the number of votes on a Question/Answer as a quality indicator to determine the rank of a page. But if they don't, they certainly should.</i></p>
<p>Those votes also help StackOverflow users building reputation. And while the whole gamification frenzy luckily died down as rapidly as it started (remember "Office Hero"?), StackOverflow is one of those sites where it really still works.</p>
<p>So that is the long excuse of why I don't blog as much as I probably should. Or maybe I should say: why I don't blog <b>here</b> as much as I should. A technical blog is in part a medium to promote your own brand. And I think I've found a more efficient way to do that (at least as far as programming topics go) in StackOverflow.</p>
<p>I may start occasionally re-posting some of my answers (or questions) from StackOverflow here. Just to ensure that there is some curated list of "puf's best answers". Or to maybe expand on an answer beyond the scope that StackOverflow allows (although that seems less likely, unless I can start sharing more of my day-time job related writing here).</p>Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com5tag:blogger.com,1999:blog-2341502915119631850.post-64119357869183447842013-11-01T20:21:00.000+01:002013-11-01T20:34:41.172+01:00Compile and execute a code snippet from your C# program<h2>The problem</h2>
Every so often I find myself creating little command line programs that:<ol>
<li>Gather a list of items from somewhere</li>
<li>Perform some user-controllable operation on each item</li>
</ol>
My problem for today is in that user-controllable operation. Somehow I often end up designing and implementing a little mini-programming language.
<pre>
> ChangeDocuments "UserName = Frank" "Set RetentionPolicy=30y"
> ChangeDocuments "Today > ExpirationDate" "Add State=Expired"
</pre>
The first parameter to this ChangeDocuments program is a quite regular search query that I can feed into the system I am programming against. The system is well designed, so I can feed nicely complex search queries into it:
<pre>
RetentionPolicy = 30y AND (ExpirationDate = Null OR AnyOtherField = AnyValue)
</pre>
When I am testing my little ChangeDocuments program I can clearly see that the query language was designed by people that know that sort-of stuff and parse search queries for a living.
<p>
Unfortunately that doesn't apply to me. Which means that the second parameter, the one that I have to implement myself, turns into a mini programming language that gets uglier with every step.
<pre>
Set RetentionPolicy=30y
Add State=Expired
Clear RetentionPolicy
Set ExpirationDate=TodayPlus30Years()
</pre>
Ouch? Did you see that last one? Not only is it ugly, but I'll have to find a way to parse that function call out of there and implement the function. And what if they want a different number of years. Sure, I could write a proper parser for that and implement function calls, call stacks, contexts and all that. But I also need it to be done today and to feel slightly more wieldy then the way I'll end up implementing it. Besides... aren't there enough people that implement programming languages for a living already?
<p>
So what I'd really prefer to do, is execute a snippet of C# code. So that the above examples can turn into something more regular, like:
<pre>
Set("RetentionPolicy", "30y")
Add("State", "Expired")
Clear("RetentionPolicy")
Set("ExpirationDate", DateTime.Now + TimeSpan.FromDays(30 * 365))
</pre>
Note that this is still not an ideal language. I'd prefer to have symbols like RetentionPolicy and State to be available like named variables. But short of implementing my own domain-specific language, this is as close as I could get with C# in a reasonable time.
<h2>Walkthrough</h2>
When I first dynamically compiled code in .NET, I was shocked at how simple this is.
<p>
Let's start with this code snippet:
<pre>
DateTime.Now + TimeSpan.FromDays(30 * 365)
</pre>
For the moment, we'll put it in a variable:
<pre>
var snippet = "DateTime.Now + TimeSpan.FromDays(30 * 365)";
</pre>
We'll be compiling the code using .NET's built-in C# compiler. The C# compiler can only handle full "code files" as its input, so the type of thing you'd normally find inside a <code>.cs</code> file.
<p>
So we'll wrap our snippet in a little template:
<pre>
using System;
public class Snippet {
public static void main(string[] args) {
Console.WriteLine(<em>CODE SNIPPET GOES HERE</em>);
}
}
</pre>
In code:
<pre>
var template = "using System;\npublic class Snippet {{\n\tpublic static void main(string[] args) {{\n\t\tConsole.WriteLine({0});\n\t}}\n}}";
var code = string.Format(template, snippet);
</pre>
Note that for now we simply write the result of the expression to the console. We'll see other ways to handle this later.
<p>
Next up is the bulk of our operation: compiling this code into an assembly.
<pre>
var provider = new Microsoft.CSharp.CSharpCodeProvider();
var parameters = new System.CodeDom.Compiler.CompilerParameters{ GenerateExecutable = false, GenerateInMemory = true };
var results = provider.CompileAssemblyFromSource(parameters, code);
if (results.Errors.Count > 0) {
foreach (var error in results.Errors) {
Console.Error.WriteLine("Line number {0}, Error Number: {1}, '{2};\r\n\r\n", error.Line, error.ErrorNumber, error.ErrorText);
}
} else {
var type = results.CompiledAssembly.GetType("Snippet");
var method = type.GetMethod("main" );
method.Invoke(null, new object[] { new string[0] });
}
</pre>
That is really all there is to it.
<pre>
<span id='first'>10/25/2043 1:21:04 PM</span>
</pre>
There are tons of additional parameters you can pass to the CSharpCodeProvider, but this minimal set tells it to:<ul>
<li>generate an assembly, instead of an executable</li>
<li>keep the generated assembly in memory, instead of putting it on disk</li>
</ul>
<h2>Complete code</h2>
This is the complete code snippet that we constructed so far:
<pre>
var snippet = "DateTime.Now + TimeSpan.FromDays(30 * 365)";
var template = "using System;\npublic class Snippet {{\n\tpublic static void main(string[] args) {{\n\t\tConsole.WriteLine({0});\n\t}}\n}}";
var code = string.Format(template, snippet);
var provider = new Microsoft.CSharp.CSharpCodeProvider();
var parameters = new System.CodeDom.Compiler.CompilerParameters{ GenerateExecutable = false, GenerateInMemory = true };
var results = provider.CompileAssemblyFromSource(parameters, code);
if (results.Errors.Count > 0) {
foreach (System.CodeDom.Compiler.CompilerError error in results.Errors) {
Console.Error.WriteLine("Line number {0}, Error Number: {1}, '{2};\r\n\r\n", error.Line, error.ErrorNumber, error.ErrorText);
}
} else {
var type = results.CompiledAssembly.GetType("Snippet");
var method = type.GetMethod("main" );
method.Invoke(null, new object[] { new string[0] });
}
</pre>
I normally run this type of code snippet in <a href="http://www.linqpad.net/">LINQPad</a>, which does something quite similar (albeit likely a lot more elaborate) internally. But if you just paste the above into the <code>main</code> of a command line program in your Visual Studio project it'll also work of course.
<h2>Possible changes and considerations</h2>
<b>Use an instance method</b>
In the above code we use a static main method. If you'd instead prefer to use a regular instance method, you'll need to instantiate an object and pass it to Invoke, like this:
<pre>
var type = results.CompiledAssembly.GetType("Snippet");
var obj = Activator.CreateInstance(type);
var method = type.GetMethod("main" );
method.Invoke(obj, new object[] { new string[0] });
</pre>
If you do this, I recommend that you name the method something else than <code>main</code>, since most people will associate <code>main</code> with a <code>static void</code> method.
<b>Pass parameters to the snippet</b>
The snippet operates in complete isolation so far. To make it a bit more useful, let's pass some parameters into it:
<p>
First we'll need to modify our template to do something with the new parameter:
<pre>
var template = "using System;\npublic class Snippet {{\n\tpublic static void main(string[] args) {{\n\t\tConsole.WriteLine(args[0], {0});\n\t}}\n}}";
</pre>
So we just use the first parameter as the format string for <code>Console.WriteLineargs[0], {0})</code>.
Then we pass a value for this parameter when we invoke the method:
<pre>
method.Invoke(null, new object[] { new string[] { "Expiration date = {0}" } });
</pre>
And now the snippet will print:
<!-- TODO: dynamically calculate this date using JavaScript, as an easter egg -->
<pre>
Expiration date = <span id='second'>10/25/2043 1:21:04 PM</span>
</pre>
<b>Make the script return a value</b>
However interesting writing to the console is, it is probably even more useful if our snippet would return its value instead.
<p>
To accomplish this, we'll change the template for the main method to this:
<pre>
public static <em>string</em> main(string[] args) {{\n\t\t<em>return string.Format</em>(args[0], {0});\n\t}}
</pre>
And the invocation now needs to handle the return value:
<pre>
var output = method.Invoke(null, new object[] { new string[] { "Expiration date = {0}" } });
Console.WriteLine(output);
</pre>
Note that the snippet itself has remained completely unchanged through all our modifications so far. This is a good design principle if you ever allow the users of your application to specify logic in this way: make sure that any changes you make to your code are backwards compatible. Whatever code the users wrote, should remain working without changes.
<b>The line numbers for errors are offset</b>
If there is an error in the snippet, the script will write the error message(s) that it gets back from the C# compiler.
<p>
So when we change the snippet to:
<pre>
var snippet = "DateTime.No + TimeSpan.FromDays(30 * 365)";
</pre>
We'll get this output:
<pre>
Line number 4, Error Number: CS0117, ''System.DateTime' does not contain a definition for 'No';
</pre>
The error message itself is correct of course, but the snippet we provided is one line, to the line number is clearly wrong. The reason for that is that our snippet is merged into the template and becomes:
<pre>
using System;
public class Snippet {
public static string main(string[] args) {
return string.Format(args[0], DateTime.No + TimeSpan.FromDays(30 * 365));
}
}
</pre>
And indeed, this C# contains the problem on line 4.
<p>
The solution for this line number offset is to either subtract the offset from the line number in the error message or simply not print the error message. In a simple case such as this the latter option is not as bad as it may sound: we only support short snippets of code, so the line numbers should be of limited value. But then again: never underestimate the ability of your users to do more with a feature than you ever thought possible.
<b>Make the wrapper class more complete</b>
Probably the most powerful way you can extend the abilities of your snippet-writing users is by providing them more "built-in primitives".
<ul>
<li>Any method you add to the <code>Snippet</code> class, becomes like a built-in, global function to the snippet author. So the <code>Set</code>, <code>Add</code> and <code>Clear</code> methods of my original snippets could be implemented like that.</li>
<li>You can also make the <code>Snippet</code> class inherit from your own base class, where you implement these helper functions.</li>
<li>Any variables that you define inside the <code>main</code> method before you include the user's snippet, will become like built-in, global variables to your snippet authors.</li>
<li>I've had great success in the past with making utilities such as a <code>log</code> variable available like this.</li>
</ul>
<b>Allow importing more namespaces and referencing more assemblies</b>
The template above imports just one namespace and only binds to the default system assemblies of .NET. To allow your snippet authors to use more functionality easily, you can either expand the number of <code>using</code> statements in the template and add additional references to the <code>ReferencedAssemblies</code> of the <code>CompilerOptions</code>.
<p>
Alternatively you can give the users a syntax that allows them to specify their own namespaces to import and even assemblies to reference.
In the past I got some pretty decent results with this syntax:
<pre>
<%@ Import Namespace="Path.Of.Namespace.To.Import" %>
</pre>
<b>Use VB instead of C#</b>
There is also a compiler for Visual Basic code. If you'd prefer to use that, you can find it here:
<pre>
var provider = new Microsoft.VisualBasic.VBCodeProvider();
</pre>
<!-- The JavaScript has to be on a single line, otherwise Blogger seems to break it -->
<script src='//cdnjs.cloudflare.com/ajax/libs/moment.js/2.4.0/moment.min.js'> </script>
<script type='text/javascript' language='JavaScript'>var setDate = function() { if (window.moment) { clearInterval(interval); var date = moment().add('years', 30).format('MM/DD/YYYY h:mm:ss A'); document.getElementById('first').innerText = date; document.getElementById('second').innerText = date; } }; var interval = setInterval(setDate, 1000);</script>
Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com0tag:blogger.com,1999:blog-2341502915119631850.post-5588986148888263582013-04-06T14:23:00.001+01:002013-04-06T14:23:38.939+01:00Gaining knowledge is not the same as asking questions<p>"Does anyone know how xyz works?"</p>
<p>-- silence --</p>
<p>"Guys, I really need to know how xyz works."</p>
<p>-- silence --</p>
<p>Does this sound familiar? It's rude that nobody answers? Right? After all, somebody <em>should</em> know the answer. It's not like your question is difficult. Right? You are asking something relatively straightforward that certainly somebody must know. If they won't tell you, how do they expect knowledge to spread? How can you ever become knowledgeable on these subjects if others outright refuse to answer your questions? Right?</p>
<p>WRONG!</p>
<p>Knowledge is not created by people asking questions and waiting for others to provide answers. Knowledge is gained by people who do things. Instead of asking somebody else to provide the answer for you, think what you can <em>do</em> to find the answer yourself. In fact, first spend a moment to come up with the most likely answer. And then validate that answer, proving yourself right or wrong. Try it, you'll be surprised how quickly you can try certain things. Heck... it may well be faster to try it then to ask again and again. And even if it's not faster, you will almost certainly gain a better understanding of the thing you are working with. In addition to getting an answer to your question, you'll also have a better understanding of the <em>why</em> around that answer. You'll have gained knowledge and understanding.</p>
<p>Yet many people seem to prefer asking a question over trying to find the answer themselves. Instead of building knowledge they are trying to get other people to give them the knowledge. And while I don't mind showing off my knowledge about a topic, mine is often built from doing things - not from asking others. So ask yourself: do you want to be a knowledge sink? Or do you want to be a knowledge source?</p>
<p>This situation is so common that an entire subculture has arissen. When somebody asks a very open question on <a href="http://www.stackoverflow.com">Stack Overflow</a>, someone almost always comments with: "what have you tried?". Matt Gemmell even put his original blog post to that effect on a separate domain: <a href="http://whathaveyoutried.com">whathaveyoutried.com</a>. Have a look around Stack Overflow and see what type of questions solicit the "what have you tried?" response. The phenomenon has spread quite far. Often I feel bad for the person asking the question, because they clearly have no clue what they've done wrong.</p>Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com2tag:blogger.com,1999:blog-2341502915119631850.post-35925156854284118342013-01-20T20:30:00.000+01:002013-01-20T20:30:16.876+01:00Handling asynchronicity in an API<p>Designing a good API is one of the more difficult tasks when it comes to software development. Unfortunately it is also one of the important tasks, since it is really hard to change an API after it's been made public. Well OK, maybe it is not hard for you to change the API, but it is hard on the users of your API: they have to update all their client programs if you decide to make changes.</p>
<p>Nowadays many APIs deal with asynchronous operations, especially when an API bridges the gap between a client-side web application and a server-side back-end. Whenever a web application needs some additional data from the server, it needs to initiate a (XMLHttpRequest) call to the server. And since such a call can take a significant amount of time it should (in almost all cases) be handled asynchronously.</p>
<h4>Checking if the title is loaded</h4>
<p>Here is how I recently saw this done in a JavaScript API:</p>
<pre>
function displayTitle(object) {
if (object.isLoaded()) {
document.getElementById('title').innerText = object.getTitle();
} else {
function onLoaded(object) {
object.removeEventHandler('load', onLoaded);
document.getElementById('title').innerText = object.getTitle();
}
object.addEventHandler('load', onLoaded);
object.load();
}
}
</pre>
<p>To display the title of the object, we first have to check if the data for the object has been loaded from the server. If so, we display the title straight away. If not, we load it and <b>then</b> display the title.</p>
<p>That is quite a lot of code, for what is a quite common operation. No wonder so many people dislike asynchronous operations!</p>
<h4>Use a callback for the asynchronous operation</h4>
<p>Let's see if we can simplify the code a bit. </p>
<p>For example, the event handler is only used once here. And although registered event handlers can be useful for things that happen all the time, clearly in many cases people will want to check if the object is loaded in a regular sequence of code - not respond to whenever the object is (re)loaded.</p>
<p>If we allow the <code>onLoaded</code> function to be passed into the <code>load()</code> call, things clean up substantially:</p>
<pre>
function displayTitle(object) {
if (object.isLoaded()) {
document.getElementById('title').innerText = object.getTitle();
} else {
object.load(function onLoaded(object) {
document.getElementById('title').innerText = object.getTitle();
});
}
}
</pre>
<p>The nice thing about this change it that you can add it to the existing API after releasing it:</p>
<pre>
MyObject.prototype.loadAndThen = function(callback) {
function onLoaded(object) {
object.removeEventHandler('load', onLoaded);
callback(object);
}
this.addEventHandler('load', onLoaded);
this.load();
};
</pre>
<p>This is mostly a copy of the code we removed between the first and second fragments above. But now instead of everyone having to write/copy this plumbing, you just have to write it once: in the prototype used for the object in question.</p>
<p>Note that I named the function <code>loadAndThen</code>, to avoid conflicting with the existing <code>load</code> function.</p>
<h4>Assume asynchronicity</h4>
<p>But when I started using the Firebase API a while ago, I noticed how natural their way of handling asynchronous operations feels. If we'd apply their API style to the above example, the <code>displayTitle</code> function would become:</p>
<pre>
function displayTitle(object) {
object.getTitle(function (title) {
document.getElementById('title').innerText = title;
});
}
</pre>
<p>Since the title might have to be loaded from the server, they require you to <b>always</b> pass in a callback function. And they will simply call that function once the title is loaded.</p>
<p>Now I can see you thinking: "but what happens if the title is already loaded?" That is the beauty of it: if the title is already loaded, they simply invoke the callback straight away.</p>
<p>If we'd like to implement such an API on top of our example, we could implement <code>getTitle</code> like this:</p>
<pre>
MyObject.prototype.getTitleAndThen = function(callback) {
if (this.isLoaded()) {
callback(this.getTitle());
} else {
function onLoaded(object) {
object.removeEventHandler('load', onLoaded);
callback(object.getTitle());
}
this.addEventHandler('load', onLoaded);
this.load();
};
</pre>
<p>Like before I gave the function a suffixed name to prevent clashing with the existing <code>getTitle</code> function. But of course if you end up implementing this in your own API, you can just stuff such code in the regular <code>getTitle</code> function (which probably reads the title from a member field of <code>this</code>).</p>
<p>If you think this is a lot of code to add to your framework, look back at our first example. If you don't add the code to your framework, every user will end up adding something similar to their application.</p>
<h4>Conclusion</h4>
<p>By assuming that certain operations are (or at least can be) asynchronous, you can reduce this code:</p>
<pre>
function displayTitle(object) {
if (object.isLoaded()) {
document.getElementById('title').innerText = object.getTitle();
} else {
function onLoaded(object) {
object.removeEventHandler('load', onLoaded);
document.getElementById('title').innerText = object.getTitle();
}
object.addEventHandler('load', onLoaded);
object.load();
}
}
</pre>
<p>To this:</p>
<pre>
function displayTitle(object) {
object.getTitle(function (title) {
document.getElementById('title').innerText = title;
});
}
</pre>
<p>The biggest disadvantage I see in the second example is that users of your API are more directly confronted with closures. Although I hang around on StackOverflow enough to realize that closures are a real problem for those new to JavaScript, I'm afraid it is for now a bridge that everyone will have to cross at their own pace.</p>Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com0tag:blogger.com,1999:blog-2341502915119631850.post-84540393145540056632011-04-03T04:01:00.003+01:002017-12-04T21:37:12.047+01:00What I use my iPad for - one year laterLast year on April 3rd Apple released the iPad. I stood in line to get the new device day one and one week later I wrote a post here about <a href="http://frank.vanpuffelen.net/2010/04/what-i-use-my-ipad-for.html">what I was using the iPad for</a>. Today marks the iPad's one year anniversary. So it's time to see if my usage has changed over the past year and if my usage patterns hold up for others.<br /><br /><h3>Games</h3><br />When I pick up my iPad it is still very often to play a quick game on it. It really is the perfect device for playing games: the screen is large enough to show a decent play field and touch controls are natural for many of the casual games that I've grown to like over the years.<br /><br />The number one game for me of the iPad's first year has been <b>Plants vs. Zombies</b>. You can play the Flash/PC version of this tower defender game for free on <a href="http://poki.com/en/g/plants-vs-zombies">this ads-supported site</a>, but I only every played the $9.99 iPad rendition. It has quick play, mini games and a fun campaign mode that I must've played through half a dozen times by now.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/-oBdAxbS0bZY/TYVVhiBFFaI/AAAAAAAAFBI/shGe5AIa4SY/s1600/pvz-titlescreen.png"><img style="cursor:pointer; cursor:hand;width: 400px; height: 299px;" src="http://3.bp.blogspot.com/-oBdAxbS0bZY/TYVVhiBFFaI/AAAAAAAAFBI/shGe5AIa4SY/s400/pvz-titlescreen.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5585964947378345378" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/-3b6XGxyBjfU/TYVU6dfdSFI/AAAAAAAAFBA/4uaRmI_Ok2w/s1600/plantsvszombies_1%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 220px; height: 165px;" src="http://2.bp.blogspot.com/-3b6XGxyBjfU/TYVU6dfdSFI/AAAAAAAAFBA/4uaRmI_Ok2w/s400/plantsvszombies_1%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5585964276148684882" /></a><br /><br />Although Plants vs. Zombies by far ate the most of my time in the past year, there are many other games that I play or played regularly. There's the inevitable <a href="http://www.rovio.com/index.php?page=angry-birds">Angry Birds</a>, which is nice but gets boring and frustrating for me after a while. It shares that problem with the beautifully made indy game <a href="http://www.steambirds.com/">Steam Birds</a>. <br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/-F1JISH92BAQ/TYVXaW8XeqI/AAAAAAAAFBQ/6X4Y6OEi0zg/s1600/AngryBirds_ScreenShot_Ingame_01%255B1%255D.png"><img style="cursor:pointer; cursor:hand;width: 400px; height: 267px;" src="http://4.bp.blogspot.com/-F1JISH92BAQ/TYVXaW8XeqI/AAAAAAAAFBQ/6X4Y6OEi0zg/s400/AngryBirds_ScreenShot_Ingame_01%255B1%255D.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5585967023169960610" /></a><br /><em>Angry Birds</em><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/-JyTEUqioev8/TYVXapMlkrI/AAAAAAAAFBY/OGELK_iUF_Y/s1600/steambirds_2%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 267px;" src="http://3.bp.blogspot.com/-JyTEUqioev8/TYVXapMlkrI/AAAAAAAAFBY/OGELK_iUF_Y/s400/steambirds_2%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5585967028069831346" /></a><br /><em>Steam Birds</em><br /><br />You'd almost think I don't like games that are difficult, but I regularly play both <a href="http://www.thinkfun.com/puzzlehunter/?p=87">Rush Hour</a> and <a href="http://itunes.apple.com/mg/app/sherlock-the-game-of-logic/id383644086?mt=8">Sherlock</a> as proof that that's not true. Sherlock is a classic puzzle game that my wife and I have been playing since the good old DOS (EGA graphics) days. Seeing it revived on iOS is wonderful and I gladly paid the $2.99 admission fee.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/-L2KQS3KZpHI/TYVZKAHLveI/AAAAAAAAFBg/Ef8sxRhL9ck/s1600/ipad-RH%255B1%255D.bmp"><img style="cursor:pointer; cursor:hand;width: 400px; height: 301px;" src="http://3.bp.blogspot.com/-L2KQS3KZpHI/TYVZKAHLveI/AAAAAAAAFBg/Ef8sxRhL9ck/s400/ipad-RH%255B1%255D.bmp" border="0" alt=""id="BLOGGER_PHOTO_ID_5585968941186661858" /></a><br /><em>Rush Hour</em><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/-Kmz6DVbwomI/TYVZKYSQQeI/AAAAAAAAFBo/MytpBqEVNWE/s1600/mzl.eipvxxul.320x480-75%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 267px; height: 400px;" src="http://1.bp.blogspot.com/-Kmz6DVbwomI/TYVZKYSQQeI/AAAAAAAAFBo/MytpBqEVNWE/s400/mzl.eipvxxul.320x480-75%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5585968947675546082" /></a><br /><em>Sherlock</em><br /><br />More recently I've been wasting too much time with <a href="http://www.bigfishgames.com/download-games/5876/my-kingdom-for-the-princess/index.html">My Kingdom for the Princess</a>, which is a time/resource management game with a very cute look. Click the link to play it for free on your PC. And <a href="http://www.z2live.com/trade-nations">Trade Nations</a> has also been keeping my attention. I'm not sure what it is with these building games, but keep playing them - even when I've clearly mastered their mechanics.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/-VEjQFlGRJb4/TYVaoRFVTcI/AAAAAAAAFBw/6j8phT33gBc/s1600/screen1%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="http://2.bp.blogspot.com/-VEjQFlGRJb4/TYVaoRFVTcI/AAAAAAAAFBw/6j8phT33gBc/s400/screen1%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5585970560650005954" /></a><br /><em>My Kingdom for the Princess</em><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/-0Q_FMXkR4Qk/TYVaoq7jRdI/AAAAAAAAFB4/CJu7sFt9R6k/s1600/06eb1b356394c94f.jpg%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 267px;" src="http://1.bp.blogspot.com/-0Q_FMXkR4Qk/TYVaoq7jRdI/AAAAAAAAFB4/CJu7sFt9R6k/s400/06eb1b356394c94f.jpg%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5585970567588300242" /></a><br /><em>Trade Nations</em><br /><br />The last game that deserves a mention is <a href="http://www.andreasilliger.com/">Tiny Wings</a>, which has firmly confirmed my suspicion that iPad games must include birds and physics to be successful.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/-sAzhJ1ppcf8/TYVb-6g-8fI/AAAAAAAAFCI/6D0ebcMM35E/s1600/mzl.aynujhzz.320x480-75%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 267px;" src="http://1.bp.blogspot.com/-sAzhJ1ppcf8/TYVb-6g-8fI/AAAAAAAAFCI/6D0ebcMM35E/s400/mzl.aynujhzz.320x480-75%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5585972049240584690" /></a><br /><em>Tiny Wings</em><br /><br /><h3>Reading</h3><br /><br />After playing games I probably spend most time on my iPad reading. Instapaper is still a favorite, as ability to transfer web pages to my iPad with one-click (while improving their readability at the same time) makes it a killer app for the iPad in my book. If only I would spend less time on games, so that my reading stack would get somewhat smaller.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/-DZBEj7TDoaU/TYVlEu4mJSI/AAAAAAAAFCQ/12vA5lIJ1no/s1600/instapaper_logo1_thumb%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 70px; height: 70px;" src="http://4.bp.blogspot.com/-DZBEj7TDoaU/TYVlEu4mJSI/AAAAAAAAFCQ/12vA5lIJ1no/s400/instapaper_logo1_thumb%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5585982044802262306" /></a><br /><br />While Instapaper is great for reading articles, I still don't like the iPad as an e-reader for books. In the past year I read three books in the sames series: two on my Sony Reader and one on my iPad. The reading experience on the iPad is nice, with cool animations at times. But I stick to my opinion that lengthy reading sessions are simply less strainfull on an e-ink screen than they are on the iPad's LCD screen.<br /><br />That said, the iPad has grown into my favorite reader for all shorter length reading. In addition to Instapaper I now also regularly read my RSS and twitter feeds on the iPad. While many people like <a href="http://flipboard.com/">Flipboard</a>, I couldn't really get used to it and (for the moment) stuck with two specialized clients: <a href="http://reederapp.com/">Reeder</a> for RSS and <a href="http://www.tweetdeck.com/">TweetDeck</a> for Twitter.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/-l-U4uKv4bgs/TYvPcO7QH-I/AAAAAAAAFCg/WWhumCiPa9o/s1600/flipboard-ipad%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 323px;" src="http://2.bp.blogspot.com/-l-U4uKv4bgs/TYvPcO7QH-I/AAAAAAAAFCg/WWhumCiPa9o/s400/flipboard-ipad%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5587787846633136098" /></a><br /><em>Flipboard</em><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/-xIceHGUz_3U/TYvPGFKzYBI/AAAAAAAAFCY/n4WLjOakKwg/s1600/ReederiPadReading%255B1%255D.png"><img style="cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="http://1.bp.blogspot.com/-xIceHGUz_3U/TYvPGFKzYBI/AAAAAAAAFCY/n4WLjOakKwg/s400/ReederiPadReading%255B1%255D.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5587787466056884242" /></a><br /><em>Reeder</em><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/-_gV6oht5ok4/TYvPwUSsseI/AAAAAAAAFCo/Q8rOOVT1pdY/s1600/ipad-tweetdeck-1%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="http://3.bp.blogspot.com/-_gV6oht5ok4/TYvPwUSsseI/AAAAAAAAFCo/Q8rOOVT1pdY/s400/ipad-tweetdeck-1%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5587788191671038434" /></a><br /><em>TweetDeck</em><br /><br /><h3>Video</h3><br />I wasn't too much into watching video on my iPad at first, but that has changed over the year. The iPad is of course great for watching video while on the plane, as long as you remember to buy and download the videos before boarding. But I also now use my iPad for watching video while exercising on my indoor rowing machine. Before getting an iPad I used to listen to audio books, but the iPad has solidly taken the Shuffle's place here.<br /><br />Video from iTunes of course work great, but comes at a price. For the past few months I've actually been watching content from iTunes/U, which has lots of great material for free. For the techies amongst you: download CS193P and learn iOS programming while you exercise. This does by the way require the use of wireless (bluetooth) headphones.<br /><br />Aside form iTunes, I also subscribe to Netflix and Hulu+. Although both have great content, I've been having some problems keeping the wifi connection stable while exercising. I have no idea what could be causing this as the iPad is literally less than 15 feet from the wireless access point. But I also haven't bothered too much figuring it out: iTunes/U for the moment has enough content to keep me "entertained".<br /><br /><h3>Creativity</h3><br />An unexpected category of apps doing well on the iPad are the creative creation apps. While the iPad has proven more a consumer than a producer device, this seems untrue of creative applications. Think of music creation apps (my favorite subcategory), image editing apps and video editing apps. The large multi-touch screen of the iPad has proven a great "build your own instrument/control" option for some of the more creative uses.<br /><br />Although I don't spend nearly as much time in these apps than I should, I have a few favorites that I regularly return to. <a href="http://www.mancingdolecules.com/everyday-looper/">Everyday Looper</a> is one of those. It is extremely simple in concept and user interface: you record multiple audio-loops in rapid succession. Doing this allows you to build a song in relatively little time. While I wish the app came with a few more features (such as repeating a "background" loop or creating patterns of the loops you've recorded) it is powerful already enough to keep me coming back every once in a while.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/-aS-edKckncY/TYvS4Ki34sI/AAAAAAAAFCw/Nen22VFQmmA/s1600/Everyday-Looper%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 298px;" src="http://1.bp.blogspot.com/-aS-edKckncY/TYvS4Ki34sI/AAAAAAAAFCw/Nen22VFQmmA/s400/Everyday-Looper%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5587791625028362946" /></a><br /><em>Everyday Looper</em><br /><br />I really wish I could add <a href="http://www.macworld.com/appguide/app.html?id=835978&expand=false">GarageBand</a> to this category. But unfortunately I haven't yet been able to test it on my iPad. The download from the appstore keeps failing. Maybe this will solve itself when I finally take the time to update my iPad to iOS4.<br /><br />If you're more visually oriented there are multitudes of drawing and photo editing tools on the iPad. Given the gorgeous multi-touch screen, that was bound to happen. The image creation app I am most happy to see on the iPad is <a href="http://www.artrage.com/">ArtRage</a>. For a while I used this program extensively on my laptop, using a Wacom trackpad for drawing. Even though I've never painted in the real-world, the controls were very intuitive and precise. That this is in a large part to thank to the Wacom trackpad and its stylus becomes very obvious when you start using the iPad version or ArtRage. Although the interface is very similar, some of the more precise control is definitely lost. That said, it is still very much fun to use a photo from your albums as a background and start painting on top of it using water paint, oil paint of even chalk. The auto-color picker makes it incredibly easy to produce reasonable pieces of "art". Fun!<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/-zoCGXzhHK2s/TYvWXF7LiNI/AAAAAAAAFC4/w1CV5Ntv8iQ/s1600/5373760363_a8b8aa9a01%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 400px; height: 267px;" src="http://1.bp.blogspot.com/-zoCGXzhHK2s/TYvWXF7LiNI/AAAAAAAAFC4/w1CV5Ntv8iQ/s400/5373760363_a8b8aa9a01%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5587795454898964690" /></a><br /><em>ArtRage</em><br /><br /><h3>Work</h3><br />The last category of apps I use regularly is sort of a mish/mash, but I think they all have to do with using my iPad for work. Only in the past few months have I started noticing that I tend to open my laptop less often in the morning. I like reading most RSS feeds, tweets and emails before I head out to the office. I used to do this on my laptop, but since early this year notice that I do this more and more on my iPad. The iPad is the ultimate media consumption device in this sense, which fits great with my morning pattern: I read/scan a lot, but respond fairly little - leaving longer responses until I get to the office.<br /><br />Of course being a software developer means that I also use my iPad for development. Not for writing code (although I would love that), but to test if our software works sufficiently on mobile safari. Somehow my searches for "software to program for the iPad from the iPad" haven't resulted in anything too useful yet.<br /><br />But since I bought a Bluetooth keyboard an <a href="http://www.iteleportmobile.com/connect">iTeleport Connect</a>, I can access the MacMini at home while I'm at the office. Using the keyboard for text input and the touch screen as a (not too accurate) mouse. While the experience isn't perfect, it does allow you to get some things done without having access to the physical machine. I can't wait to see what will happen when VMware launches their iPad viewer app. The iPad is completely silent, using very little power - it may well be the ultimate thin client.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/-EPwerGDbxMU/TYvheooEAPI/AAAAAAAAFDA/dx9tCra8J-E/s1600/bookarc-ipad-big-300x297%255B1%255D.jpg"><img style="cursor:pointer; cursor:hand;width: 300px; height: 297px;" src="http://4.bp.blogspot.com/-EPwerGDbxMU/TYvheooEAPI/AAAAAAAAFDA/dx9tCra8J-E/s400/bookarc-ipad-big-300x297%255B1%255D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5587807679101010162" /></a><br /><br /><br />Two more work-related uses, those are the last... I promise.<br /><br />At one point I was about to board for a transatlantic flight when I got an email with the ever-interesting combination of question marks and exclamation marks: "why isn't this done yet ?!?!?" I had completely forgotten about a report I promised to write days earlier. The long flight and the iPad proved to be job-savers here: the flight was long enough to get a decent version of the report drafted before touch down and the iPad is small enough to fit in front of me on the table in coach.<br /><br />Lastly I sometimes use my iPad for presenting. Our company is a Windows shop, so everything get prepared in Powerpoint. But once the PPTX is done, I drag it into dropbox, open it on my iPad and use keypad to present it. Now if only the projectors we use were as silent as an iPad...<br /><br /><br /><h3>Summary</h3><br />So in summary I don't think my iPad usage has changed too much over the year. It's still the "computer" that is closest by when I want to do something for a few moments: whether it's a quick game, looking up a video that we're talking about with friends or doing some catching up on articles and blogs on the couch. It's taken over quite a few tasks that I previously used laptops for and has come up with new tasks that I previously simply wouldn't do.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com0tag:blogger.com,1999:blog-2341502915119631850.post-90869236348198186382010-09-17T05:02:00.006+01:002010-09-17T05:38:52.133+01:00Color-coding your scrum boardAt my company we've been using Scrum for a few years now. And even though I'm quite sure we're not living up to Schwaber's and Sutherland's standards, we seem to have found a way to make the process work for us across many projects.<br /><br />Like many companies we started out with a simple physical scrum wall:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_QCmUgDEhTiw/Rs_qFy759tI/AAAAAAAAAa4/3u8AvM9I2Sc/s1600/DSC00279.JPG"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 193px;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/Rs_qFy759tI/AAAAAAAAAa4/3u8AvM9I2Sc/s1600/DSC00279.JPG" border="0" alt="" /></a><br /><br />Later we started putting the <a href="http://frank.vanpuffelen.net/2007/08/online-burndown-chart-generator.html">burndowns on our intranet</a>, so that everyone could see them. And we started using colored post-its for indicating different types of work. <br /><br />In our case we use yellow for development tasks, pink for non-development tasks (i.e. testing and documentation) and orange for defects. There's no specific reason for using these colors. They just happened to be the post-it colors we had available when we started using colors. Since then my mind got used to them and I haven't yet heard a reason to switch. Although some of our tech writers are frowning at being "the guys who do the pink work".<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://multimedia.3m.com/mws/mediawebserver?mwsId=SSSSSu7zK1fslxtUO82vn8_ZevVSeChshvTSevTSeSSSSSS--&width=200"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 200px; height: 219px;" src="http://multimedia.3m.com/mws/mediawebserver?mwsId=SSSSSu7zK1fslxtUO82vn8_ZevVSeChshvTSevTSeSSSSSS--&width=200" border="0" alt="" /></a><br /><br />As we've been growing our use of Scrum, we've also been using more and more tools. First was the online burndown charts. And then we started using a virtual scrum wall, so that we could share the same wall between distributed teams. It was a great boost for our distributed development, although most team members still sometimes long back for the days when they had a physical wall. Nothing beats the satisfaction you get from moving a physical post-it across 5 inches of whiteboard space.<br /><br />We've been using Scrum for Team System for a while now to keep track of our stories and tasks. And I thought we were quite happy with it. Sure, we lost the ability to color code our task types. But the task board we used has nice colors too, although it uses them to code the columns. So "done" is green, etc. <br /><br />But recently I noticed that it was difficult to quickly understand the status of a sprint from simply looking at their board:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_QCmUgDEhTiw/TJLsI9qQ0HI/AAAAAAAAEr4/4WwMTKbi4wc/s1600/mono-wall.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/TJLsI9qQ0HI/AAAAAAAAEr4/4WwMTKbi4wc/s400/mono-wall.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5517732132217213042" /></a><br /><br />So is the status of this project? It's hard to say without looking at the details of each task. It could be that everything is going fine, it could be that things are horribly wrong. There is no way to tell which one it is, unless you get closer to the board and read.<br /><br />So over the weekend I re-encoded one of our boards with the colors we used back in our "physical days". Now look at the same board where we've used colored post-its:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_QCmUgDEhTiw/TJLsJGKlasI/AAAAAAAAEsA/L0bM6r7Bw0E/s1600/color-wall.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/TJLsJGKlasI/AAAAAAAAEsA/L0bM6r7Bw0E/s400/color-wall.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5517732134500264642" /></a><br /><i>Yellow = development tasks, pink = non-development tasks, orange = bugs</i><br /><br />When we applied this color coding to our existing scrum board, I was shocked at the amount of insight it could add. <br /><br />So I wrote a quick tool to generate these color-coded task boards for us. The process is purely automatic: read the data from team system, apply a few simple rules (e.g. anything with the word "bug", "defect" or "issue" in it, must be a defect) and output a HTML version of the data. But even with such a simple system we've been able to more easily get a feeling of where all projects stand by simply glancing at the board.<br /><br />So what is your experience with scrum walls? Do you have any tricks you use to help visualize the data?Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com0tag:blogger.com,1999:blog-2341502915119631850.post-80742134272804091132010-06-13T05:14:00.003+01:002010-06-13T05:23:12.039+01:00Block fontMany people seem to doodle while they're in meetings. Doodling is a nice way to distract yourself with something, while ensuring that you can still follow what is being presented. I guess that's why those meeting centers hand out those incredibly thin notebooks. <br /><br />My doodles typically consist of writing down words that have to do with what is being presented. Now before you say "that is called: taking notes" - I take my notes in elaborate fonts.<br /><br />One of the fonts I came up with this time is a 'block font'. And since the meeting was rather long, I decided to create all letters.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_QCmUgDEhTiw/TBRcd1H7s5I/AAAAAAAAEpM/r343eGbRJmw/s1600/blockfont.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="http://1.bp.blogspot.com/_QCmUgDEhTiw/TBRcd1H7s5I/AAAAAAAAEpM/r343eGbRJmw/s400/blockfont.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5482108313963049874" /></a><br /><br />I should apologize to the speakers, because I wasn't paying too much attention near the end of their presentation. Coming up with all letters in a single style is hard work.<br /><br />I'm quite happy with most of the letters, but there's some that I really can't get to look decent. The I and the J are especially painful. Is there somebody with real designer skills that can show me how to do those character properly in this style?Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com2tag:blogger.com,1999:blog-2341502915119631850.post-34652059065597289092010-04-10T19:03:00.009+01:002010-04-10T21:04:10.843+01:00What I use my iPad forIt's been a week since Apple released their latest revolution: the iPad. By now every major site has reviewed it (most positive), but unsure what the device is meant for. I got my iPad on the launch date, so have had a week to play around with it and show it off.<br /><br />In the past week the number one question from everyone has been: what do you use your iPad for? As with any new device type, the most common use-cases are not immediately clear. I don't think Apple ever thought the appstore would be the greatest attractor of new users to the iPhone. The iPad is no different: it's a completely new beast and it'll take some time for people to figure out what to do with it.<br /><br />In the past week, I've used my iPad primarily for these three things:<ul><br /><li>Games</li><br /><li>Surfing</li><br /><li>Email</li><br /></ul><br />In addition I've actually also spent quite some time showing the iPad off to various people. But that is of course a use-case that will be less relevant over time. Until that happens though, I'd advice every iPad owner to buy the apps in the iWorks suite. They show off the serious side of the iPad best for the moment.<br /><br /><h3>Games</h3><br />Not surprisingly the iPad makes a great device for games. For me it has been mostly casual games so far, but I might try out some more serious games (red alert, need for speed) soon. <br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_QCmUgDEhTiw/S8DVhW49MqI/AAAAAAAAEgc/7EDEHh16CIY/s1600/213722-3%5B1%5D.jpg_rand%3D6DB56029-07B1-9AB2-76C12BBFFAF686F7"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 305px;" src="http://1.bp.blogspot.com/_QCmUgDEhTiw/S8DVhW49MqI/AAAAAAAAEgc/7EDEHh16CIY/s400/213722-3%5B1%5D.jpg_rand%3D6DB56029-07B1-9AB2-76C12BBFFAF686F7" border="0" alt=""id="BLOGGER_PHOTO_ID_5458597517429912226" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_QCmUgDEhTiw/S8DWiXJPz4I/AAAAAAAAEgk/J5XdqOAmC8U/s1600/HarborMasterHD-525x393%5B1%5D.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 299px;" src="http://3.bp.blogspot.com/_QCmUgDEhTiw/S8DWiXJPz4I/AAAAAAAAEgk/J5XdqOAmC8U/s400/HarborMasterHD-525x393%5B1%5D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5458598634189737858" /></a><br />My favorite games so far have been Harbor Master, Rush Hour and Labyrinth. All three seem to have been made exactly for this type of device, but with Rush Hour the playing pieces feel a bit too big. Maybe they're ahead of the pack and already made their game for the smaller iPad that is rumored to come next year.<br /><br /><h3>Surfing</h3><br />The iPad comes with Apple's latest Safari release, which is perfect for surfing the web. It doesn't allow tabbed browsing, which I think is a miss. But you can keep multiple pages open and switching between them is relatively elegant. When you shut down/restart Safari the pages take a bit of time to reload, which I think should not be needed on a device with 16GB or more of memory.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_QCmUgDEhTiw/S8DW_2THg-I/AAAAAAAAEgs/MNLzQfS-AGA/s1600/img002320x480%5B1%5D.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 267px; height: 400px;" src="http://1.bp.blogspot.com/_QCmUgDEhTiw/S8DW_2THg-I/AAAAAAAAEgs/MNLzQfS-AGA/s400/img002320x480%5B1%5D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5458599140768842722" /></a><br /><br />The iPad will not soon replace your laptop as your main device for surfing. Although it is totally usable, it is just not made for using at your desk. Maybe that changes when I get a docking station later this month, but for the moment the laptop wins the battle for my desk.<br /><br />Where the iPad really shines is on the couch. I had some discussion with friend who'd say they use their laptop on the couch too. Maybe they do, but it's not the same thing. Whether I'm talking to visiting friends or are watching TV, the iPad is always within immediate reach. You can just leave it turned on all the time, it turns off the screen automatically and never gets hot nor does it ever make any noise. A laptop would simply not fit comfortably in the same seat as me or be waiting on the armrest of my chair just in case I need to look something up. Hmm... I think I've seen that actor before, let's look on IMDB quickly - no need to wait for a commercial break.<br /><br /><h3>Email</h3><br />My number three usage has been reading and responding to email. The on-screen keyboard is quite good, especially in landscape mode. Although as Apple claimed the keys are almost full-size, it does take some time to adapt to them. Without tactile feedback it is very easy to touch a few keys without noticing. So what I see most people do very quickly is arch their fingers a bit more to avoid those accidental key presses.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_QCmUgDEhTiw/S8DXSRpgqaI/AAAAAAAAEg0/3TzqPNcdizc/s1600/iPad-email%5B1%5D.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 278px;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/S8DXSRpgqaI/AAAAAAAAEg0/3TzqPNcdizc/s400/iPad-email%5B1%5D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5458599457348168098" /></a><br /><br />Reading and writing email works like a charm. Switching between multiple mailboxes takes a bit of tapping, but nothing too bad. The iPad really came to my rescue this week when my laptop started acting up. Instead of having to fall back to my iPhone or having to steal somebody else laptop, I could switch to the iPad and write reasonably lengthy responses.<br /><br />So those are my top 3 use cases of the past week: gaming, surfing and mailing. There were also some things that I didn't use my iPad for, even though there is great software available and people had predicted those use-cases.<br /><br /><h3>Not for reading</h3><br />Apple tries to position the iPad as the ultimate eBook reader. I was already skeptical about this before I got my iPad, simply because I've grown to love my Sony Reader over the past half year. The one thing I love about the Sony is the eInk screen. <br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_QCmUgDEhTiw/S8DXiSzoTyI/AAAAAAAAEg8/emXkG3udwhI/s1600/ibooks%5B1%5D.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 266px;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/S8DXiSzoTyI/AAAAAAAAEg8/emXkG3udwhI/s400/ibooks%5B1%5D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5458599732536954658" /></a><br /><br />Although the iPad's screen is gorgeous, for readability it doesn't compare to eInk. Try reading intensely for more than a few minutes and you'll notice the difference. The iPad might look fresher and cleaner, but reading an eInk screen is simply less stressful for the eyes than reading on the iPad. <br /><br />Another thing holding the iPad back as an eBook reader is it's size and weight. I often read my Sony in bed, lying on my back holding it above me. I challenge anyone to do that with the iPad for more than a few minutes. It's simply too heavy and too clunky.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_QCmUgDEhTiw/S8DYwoRFexI/AAAAAAAAEhE/gaFOICCr9yc/s1600/mzl_kdoumyiw_480x48_578424a%5B1%5D.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/S8DYwoRFexI/AAAAAAAAEhE/gaFOICCr9yc/s400/mzl_kdoumyiw_480x48_578424a%5B1%5D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5458601078327442194" /></a><br />That said: the iBook software on the iPad looks great. Apple was kind enough to include an illustrated book of Winnie the Pooh, which perfectly shows the type of material the iPad was made for: colorful books with large fonts and pictures. I can easily see how the iPad might be a kids favorite reading device, even though I will stick to my Sony Reader for lengthy reading sessions.<br /><br />Where the iPad had proven useful is for reading articles. Whenever I want to read an article from a website, I've always had to convert it for reading on my Sony Reader. Although it's not a huge amount of work, I love using Instapaper for the iPad. With a single click on my laptop, I transfer any article from the web over to Instapaper on the iPad - where it is automatically reformatted into easy reading format. I really wish a similar program/feature existed for my Sony Reader though, because I do miss the eInk screen when reading on my iPad.<br /><br /><h3>Not for video</h3><br />I've also not been watching much video on my iPad. I think I should say "not yet" here, because there seems to be no reason not to use the iPad for watching youtube or video's bought from iTunes. <br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_QCmUgDEhTiw/S8DVMYs60NI/AAAAAAAAEgU/e33vsBGVU_8/s1600/YouTube-No-Flash-HTML-5-Video-Option-Great-for-Apple-Mac-OS-X%5B1%5D.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 328px;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/S8DVMYs60NI/AAAAAAAAEgU/e33vsBGVU_8/s400/YouTube-No-Flash-HTML-5-Video-Option-Great-for-Apple-Mac-OS-X%5B1%5D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5458597157139042514" /></a><br />Since the iPad doesn't support flash, many video sites may not work. But hopefully this is just a temporary nuisance until all sites do what youtube did: re-encode their video's to work in H.264 or whatever the format is.<br /><br />When I did watch video, it looked great on the screen. At time the wireless network at some places couldn't keep up with the video, which is an unfortunate consequence of the HD resolution that the iPad supports.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com7tag:blogger.com,1999:blog-2341502915119631850.post-1013359615855750612010-03-04T19:49:00.000+01:002010-03-04T19:51:04.228+01:00Who estimates the stories in Scrum?A few years ago we did a project with an outsourcing company. We gave them the current source code of a product, we gave them the backlog for the new version and we asked them to start implementing that backlog top to bottom.<br /><br />Since the external team was new to both the product and the Scrum process, I decided to also do some rough estimates myself. Given my experience with both the product and the process, those estimates could serve as a rough baseline.<br /><h3>The progress</h3><br />The remote team worked on the project for 5 sprints. During that time we saw an interesting trend.<br /><br />As the team finished each sprint, some of their work was accepted and other work wasn't. Work was sometimes rejected because of its quality, but often it was rejected because it simply didn't do everything that the product owner had expected. In those cases the team put another story on the backlog for the missing parts and provided a fresh estimate for the "new" work. They also re-estimated the existing stories based on the newly gained insight of the previous sprint.<br /><br />So over time the team's backlog grew in size. That is not uncommon, but look at the burnup chart:<br /><br /><img src="http://apps.vanpuffelen.net/charts/burndown.jsp?days=1,2,3,4,5,6&work=250,300,350,400,450,500&work=0,13,30,54,97,117&colors=1&ideal=0" /><br /><em>burnup 1: based on team estimates</em><br /><br />Based on this burnup chart, the project is in serious trouble. The team seems to be doing great, delivering more work with every sprint. But even though more and more work is delivered every sprint, the team is not getting closer to the goal.<br /><br />The fifth sprint here is really disastrous: the team stopped increasing delivering more work. Did they burn out? How are we ever going to get the project out the door?<br /><br />For comparison let's look at the data based on my estimates - that the team never saw and didn't commit to:<br /><br /><img src="http://apps.vanpuffelen.net/charts/burndown.jsp?days=1,2,3,4,5,6&work=210,210,210,238,238,238&work=0,10,18,25,39,43&colors=1&ideal=0" /><br /><em>burnup 2: based on estimates by an external stakeholder</em><br /><br />On my end, for every new story the team added to the backlog I checked if I had considered that part in my original estimate. If so, I split the story points I had originally estimated over the two stories. If the new story was functionality I had not expected in my estimate, I would provide a fresh estimate - also increasing the backlog in my part. As you can see that happened only once, but the increase was substantial (about 10%).<br /><br />In my chart too the team seems to be burning out a bit in sprint 5. But it doesn't seem half as bad as in the firsts burnup chart. They are still getting closer to the goal.<br /><br />And in both charts the team seems to be about 20% done with the total amount of work.<br /><h2>Analysis</h2><br />So what's the difference between the two charts and estimators. From my perspective there are two major differences: the stability of the progress and who made the estimates.<br /><h3>How stable is the progress</h3><br />The charts below show the velocity per sprint as derived from the burndown charts above:<br /><br /><img src="http://apps.vanpuffelen.net/charts/burndown.jsp?days=1,2,3,4,5,6&work=0,13,17,24,43,20&colors=1&ideal=0&width=320&height=240&border=20"/><br /><em>velocity 1: velocity from sprint to sprint in burndown 1</em><br /><img src="http://apps.vanpuffelen.net/charts/burndown.jsp?days=1,2,3,4,5,6&work=0,10,8,7,14,4&colors=1&ideal=0&width=320&height=240&border=20" /><br /><em>velocity 2: velocity from sprint to sprint in burndown 2</em><br /><br />The burnups don't really have a lot of data. But if you look at the first velocity chart, you can see that sprints 1 to 4 show a somewhat exponential growth in velocity (1.3x, 1.4x, 1.8x).<br /><br />The scope/goal line in the corresponding burnup chart (burnup 1) shows a constant growth, mostly because I don't have the exact data anymore. <br /><br />So at some point the two lines in burnup 1 are going to intersect, but it is pretty difficult to determine where they'll intersect with the naked eye.<br /><br />The second burnup doesn't have this growth in velocity and the scope increase is about 10% over 5 sprints.<br /><br />It is a lot easier to see where this project is going to end. And isn't scrum all about transparency and easy to use charts and data?<br /><h3>Who provides the estimates?</h3><br />The second question I posed above is who provides these estimates. With the whole hype about lean development I learned that one way to optimize output is to eliminate waste. Anything that isn't delivered to the customer is waste and should be eliminated.<br /><br />Who needs these estimates? The customer? I don't think my customer cares about estimates. He cares about getting as much software as possible for his/her money. In fact, while the team was providing these estimates they could also have been building more software.<br /><br />So is it the team that needs these estimates then? After all without those estimates, how do they know what they can commit to? Well... the team does need to know how big a story is before they can commit to it. But they only need to know that at the start of each sprint. And only for the stories that they think they might do in that sprint. So although the team needs to know the size of each story it commits to, it doesn't need to know the size of all stories at the start of the project. Nor do they need to re-estimate the stories (another form of waste).<br /><br />So the only person that actually needs those estimates, is the guy drawing the charts. In this case that was me, an external stakeholder who is not a part of the team. In many cases it will be the scrum master, who needs those estimates to give his stakeholders some view of the progress towards the overall goal. In other cases it will be the product owner, since he is most interested in seeing his return on investment.<br /><h3>Conclusion</h3><br />My suggestion: <b>let the guy who needs them come up with the numbers</b>. And if you don't feel comfortable, <b>do a reasonable guess</b>. And if you don't even feel comfortable guessing, <b>set all stories to the same size</b>. In the end it doesn't really matter too much and you'll allow the team to focus on what really matters: building working software.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com1tag:blogger.com,1999:blog-2341502915119631850.post-59428646207599870882009-08-25T08:04:00.005+01:002023-07-04T10:35:37.914+01:00JavaScript Particle Systems part 2: adding some lifeThe frame below shows a demonstration of the particle system we are about to build. Move your mouse through it to have some fun. If it doesn't work for you, click <a href='https://jsparticles.web.app/particles2.html' target='_blank'>this link</a> to open the same demo in a popup window.
<iframe src='https://jsparticles.web.app/particles2.html' width='640' height='480' scrolling='no'> </iframe>
<h3>Introduction</h3>
A few months ago I wrote <a href="http://frank.vanpuffelen.net/2009/05/particle-systems-in-javascript.html">an article that demonstrated how to create a very simple particle system in less than 50 lines of JavaScript code</a>. That article has slowly been finding its way into the Google search indexes and by now it's becoming obvious that I'm not the only one who thinks particle systems deserve more attention and JavaScript is the perfect language to experiment with them.
Back then I was quite pleased with being able to implement a fully functional particle system in less than 50 lines of (quite readable) JavaScript code. But I think we can agree that the particle system was not very exciting. Although the system contained all three required ingredients, the end result was a bit "static". From games and other places where particle systems are used, we are used to them being a lot more "alive".
So that's the goal for this article: to add some life to our previous particle system, while still keeping it small. In this case I've increased my self-imposed limit to a 100 lines. A generous doubling from our previous system, so we'd better have some real interesting "life" to show for the increase.
We'll add three behaviors to the particle sytem.<ul>
<li>Gravity</li>
<li>Grow then shrink</li>
<li>Mouse control</li>
</ul>Lot's of work to do, so let's get started with gravity straight away.
<h3>Gravity</h3>
In our first particle system, the particles would fall at a constant speed. The fall speed of each particle was determined at random when creating the particle.
<pre> dy: Math.random() + 0.5</pre>
And then we just updated the y position every time:
<pre> particles[i].y = particles[i].y + particles[i].dy;</pre>
I always find it very interesting to add some gravity-like behavior to systems I create. So how about making the particles fall at an increasing speed?
<pre> p = particles[i];
p.y += p.dy;
p.dy += 0.1; // simulate gravity</pre>
So we increase the particle's y velocity every time we update its position. I realize that to make this work like real gravity I'd have to know the particle's mass and do a multiplication. But for this simple example just increasing the dy is already convincing enough.
Since the particle will now drop at an ever increasing speed, it is nice to make it go up a bit at first:
<pre> dy: -1 + Math.random()</pre>
So the particles will first move up a bit and then start falling down at an increasing speed. If all goes well, they'll move in a nice arc-like pattern. Again there is no real math or physics reason for these values, these just looked best to me. If you feel the need to make the system more physically correct, just download the source and go ahead. Let me know if you find an interesting combination.
<h3>Grow then shrink</h3>
Another thing I wasn't too happy with in the original particle system is the static size that the particles have. Each particle is created to be 3px in width and height. By the way: there was a bug in the original code such that the sizing didn't work in Internet Explorer. As my team often tells me: "you need to test more with IE Frank!" My bad. Let's hope I got it right this time.
I changed the code to shrink the particle a bit in each update:
<pre> p.s -= 0.1</pre>
This of course requires the particle to have a size when we create it:
<pre> p.s: 3.0</pre>
With this setup the particle will slowly shrink from 3 pixels width and height to 0. Once the size of the particle reaches 0, we can kill it:
<pre> if (p.ttl-- > 0 && p.s > 0) {
updateParticleElement(p);</pre>
This leads to a working particle system, but somehow it's still a bit boring when all the particles start and shrink at the same speed. So let's make the size change random and instead of just shrinking, let's make the particles grow at first and then shrink until they die out.
For the initialization the change is simple:
<pre> p.ds: Math.random()+0.1,</pre>
This gives the particle a growth speed that is guaranteed to be positive. So instead of adding 0.1 each time we update the particle, we add the ds:
<pre> p.s += p.ds;</pre>
If we leave this unchanged, the particle will grow forever - or at least until it's time to live runs out. To ensure the particle also starts shrinking at some point we give it a maximum size:
<pre> if (p.s > 5) p.ds *= -1;</pre>
When the particle reaches its maximum size, we just flip the sign of the growth speed - so it becomes a shrink speed. After this the particle will keep shrinking until it reaches size zero at which point it dies out.
By now I'm not really sure if the ttl property is still needed, as the particles already have an implicit time to live and get their randomness from the growth/shrink speed. But I left the ttl in as a safeguard against my own mistakes when manipulating the size. I wouldn't want to end up with an infinitely living and growing particle by mistake.
If you would reconstruct the particle system at this point it is already quite lively and dynamic. Particles seem to be attracted by the bottom of your screen and particles seem to have a real life cycle, where they grow and shrink to die out. But this particle system is still a spectator sport. Let's see what happens when we give the user some control over what happens on screen.
<h3>Mouse control</h3>
As our last feature we want to give the user some control over the behavior of the particles. Specifically I want to accomplish two things:<ol><li>particles originate close to the position of the mouse cursor</li>
<li>particles move roughly in the direction that the mouse is moving</li></ol>
To accomplish this we need to add four variables to the system.
<pre> mx and my - the position of the mouse
dmx and dmy - the direction and speed of the mouse's movement</pre>
These variables are global to the script, so they are not stored for each particle.
These variables are updated whenever the user moves the mouse, by hooking the onmousemove event of the window. The mousemove handler is a bit tricky to read at first. But since the behavior of the particles only depends on the four variables mentioned here, I will not explain the mousemove handler of the code further.
Now how do we use these variables when creating and updating a particle? The variables are actually only used when we create a new particle:
<pre> x: mx,
y: my,
dx: dmx + Math.random(),
dy: dmy + Math.random() - 1,</pre>
As you can see the code remain quite similar to how it was. We've just substituted our new "mouse dependent" variables for the previous hard coded and random values. We still make the dx and dy a bit random, since otherwise all particles would go in the same direction.
The updating of the particles doesn't have to change for this behavior. The mouse just allows the user to control the position and the direction of the initial movement. After its creation each particle behaves as the rules of our system dictate, which ensures the particles still behave similar even with al their differing properties.
<h3>Summary</h3>
So in <a href="http://frank.vanpuffelen.net/2009/05/particle-systems-in-javascript.html">the first article</a> we created a simple particle system in less then 50 lines of JavaScript code. The system was fully functional, but felt a bit static after you'd been looking at it for a while.
In this second article we've added life to our particle system by adding by:<ol><li>making the environment a bit more "physical" with our simple gravity emulation</li>
<li>making the life cycle of the particles more complex, by making them grow and then shrink and die out</li>
<li>allowing the user to control the particles, by hooking their position and movement up to the mouse movement</li>
</ol>
All in all our particle system has now gotten quite complex. But weighing in at 90 lines, it is still well under my self-imposed limit of a 100 lines of code. I did my best to keep the code readable again and even added some constants to make it easier to change and debug the particle system.
Now go ahead and play with the system. I find it's great fun to see how far up you can throw the particles. Remember: this is controlled by moving the mouse, so start pushing and pulling your mice!
<h3>The code</h3>
<pre>
// constants
var NUM_PARTICLES = 50;
var FPS = 20;
var PARTICLE_LIFETIME = 4; // in seconds
var ANIMATION_LIFETIME = 300; // in seconds
// global variables
var container;
var particles = [];
var framecount = 0;
var mx = 20; // default origin, will be set to mouse position once the mouse moves
var my = 20;
var dmx = 1.0; // default movement, will be set to mouse movement once the mouse moves
var dmy = -1.0
function onMouseMove(e) {
var IE = document.all?true:false
var nmx, nmy;
if (IE) { // grab the x-y pos.s if browser is IE
nmx = event.clientX + document.body.scrollLeft
nmy = event.clientY + document.body.scrollTop
} else { // grab the x-y pos.s if browser is NS
nmx = e.pageX
nmy = e.pageY
}
dmx = (nmx - mx) / 4;
dmy = (nmy - my) / 4;
mx = nmx;
my = nmy;
}
function createParticle(container) {
var p = {
elm: createParticleElement(),
x: mx,
y: my,
s: 0.0, // size
dx: dmx + Math.random(),
dy: dmy + Math.random() - 1,
ds: Math.random()+0.1,
ttl: PARTICLE_LIFETIME*FPS
};
container.appendChild(p.elm);
updateParticleElement(p);
return p;
}
function createParticleElement() {
var elm = document.createElement('span');;
elm.style.border = '1px solid blue';
elm.style.position = 'absolute';
return elm;
}
function updateParticleElement(p) {
p.elm.style.width = p.elm.style.height = p.elm.minWidth = p.elm.minHeight = Math.floor(p.s) + 'px'; // doesn't work on IE
p.elm.style.left = Math.floor(p.x) + 'px';
p.elm.style.top = Math.floor(p.y) + 'px';
}
function updateParticles() {
for (var i=particles.length-1; i >= 0; i--) {
var p = particles[i];
p.s += p.ds;
if (p.s > 5) p.ds *= -1;
p.x += p.dx;
p.y += p.dy;
p.dy += 0.1; // simulate gravity
if (p.ttl-- > 0 && p.s > 0) {
updateParticleElement(p);
} else {
container.removeChild(p.elm);
particles[i] = createParticle(container);
}
}
if (framecount++ < ANIMATION_LIFETIME*FPS) {
setTimeout('updateParticles()', Math.floor(1000 / FPS));
} else {
alert("All done. Reload to watch again.");
}
}
window.onload = function() {
container = document.getElementById('particles');
for (var i=0; i < NUM_PARTICLES; i++) {
particles[i] = createParticle(container);
}
setTimeout('updateParticles()', Math.floor(1000 / FPS));
document.onmousemove = onMouseMove;
}
</pre>Download it <a href="https://jsparticles.web.app/particles2.js">here</a>.
And the corresponding HTML:
<pre>
<html>
<head>
<title>JavaScript Particle System</title>
<script type="text/javascript" src="particles2.js"> </script>
</head>
<body>
<div id="particles" style="width:640px; height: 480px; overflow: hidden"> </div>
</body>
</html>
</pre>Download it <a href="https://jsparticles.web.app/particles2.html">here</a>.
<h3>See also</h3>
<ul>
<li><a href="http://frank.vanpuffelen.net/2009/05/particle-systems-in-javascript.html">the first article, where we create a simple particle system in 50 lines of code</a></li>
<li><a href="http://frank.vanpuffelen.net/2007/06/incremental-search-using-javascript.html">a demonstration of how to do incremental search in JavaScript</a></li>
<li><a href="http://frank.vanpuffelen.net/2007/12/grid-computing-using-web-browsers.html">my ponderings on a computer grid consisting of browser running JavaScript</a></li>
<li><a href="http://frank.vanpuffelen.net/2008/03/finding-primes-using-grid-of-browsers.html">how such a grid could be used to find primes</a></li>
</ul>Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com15tag:blogger.com,1999:blog-2341502915119631850.post-82554717224379380702009-07-25T20:50:00.001+01:002009-07-25T20:58:51.440+01:00Seven rules to keep your twitter followersWith Jon's recent <a href="http://jonontech.com/2009/07/21/follow-forty-twitter-cms-gurus-in-three-clicks/">"top 40 list of CMS gurus"</a> I suddenly got a lot of additional followers. And I added quite a few of those people to my twit-list too. From the first few days it looks like I might start unfollowing some soon, but there's definitely a few that are a great addition to the list. While scrolling through recent tweets, I sought what makes tweets interesting for me and things that I really don't like. So here is the list (in random order) of do's and don'ts to keep my as your follower on twitter.<br /><br /><h3>1. Yet another link retweeter</h3><em>"RT @cmswire Open Source for America: Change We Can Believe In? http://bit.ly/r9sj6 #opensource #oss"<br />"RT @cmswire 39 More Ways to Get Your CMS Twitter Fix http://bit.ly/YiV9I"<br />"RT @OpenText #OpenText Completes #Vignette Acquisition http://cli.gs/bUvzsN"</em><br /><br />There's nothing wrong with retweeting something interesting you've heard somebody say. But if all you tweet is other people's tweets, I'd much rather listen to those other people.<br /><br /><h3>2. Your opinion matters to me</h3>Personal tweeting is fine. I love to hear what friends and family are doing. But from people that don't fall into those categories, I don't need:<br /><br /><em>"Ottawa Organic Market on Bank.... "</em><br /><br />Don't just tell me that you're at an organic market in whatever city. If we're not emailing or calling each other at least once a week, chances are I don't care that much about your whereabouts. Sounds harsh? It's not meant to be harsh.<br /><br />Because I apparently care enough about your opinion to follow your tweets. So how about you tell me your opinion on that market. <br /><br /><em>"the Ottawa organic market is really the best"</em><br /><br /><h3>3. Challenge me</h3>Even better, don't just tell me your opinion. Tease me to give you mine. It's OK to do a bit of trolling as long as long as you don't mind getting trolls back too.<br /><br /><em>"the Ottawa organic market is really the best, certainly beats the one in Amsterdam"</em><br /><br />Now that's a great way start to a discussion. Because I really, really LOVE the organic market in Amsterdam.<br /><br /><h3>4. Don't forget I'm eavesdropping</h3>One of the worst things you can do to me on twitter is to start a 1-on-1 conversation with somebody where you forgot that I'm still there reading along. <br /><br /><em>"Sorry? Barbecue where? Are you kidding me?"</em><br /><br />What barbecue are you talking about? Where is it? Am I invited too? If you don't want to let me know these things, why are you sending your private message as a public tweet?<br /><br />Remember: if you want to have a private conversation, there is always still email or Google talk. Or even better <code>dm</code> in twitter. <br /><br />But if you feel like you want to share your conversation with the world, give me enough context.<br /><br /><h3>5. Give me context</h3>If talking to someone in a public tweet, make it clear who you're talking to.<br /><br /><em>"@john123 glad you liked the post!"</em><br /><br />It certainly beats the tweet about <em>that</em> barbecue. Because here I can at least check the other part of the conversation in john123's tweet stream. But still, giving me a bit of context goes a long way.<br /><br /><em>"@john123 glad you liked the post! http://is.gd/1JyHY"</em><br /><br />One click and I'm at the post. But then again, why not just retweet the original and add your comment to it:<br /><br /><em>"glad you liked the post! RT @john123 good analogy on how to mix persuasive content with relational data in modern CMS. http://is.gd/1JyHY"</em><br /><br />Phew... 138 characters, that's cutting it close. But it has as much context as you can add to your tweet.<br /><br /><h3>6. Tell me something I can use</h3>A friend was apparently enjoying a milkshake a bit too much and had to share it with the world:<br /><br /><em>"Just had the best strawberry milkshake ever"</em><br /><br />I like reading it, because I always love to hear about good food - especially from someone whose taste buds I trust.<br /><br />But how am I going to be able to do something with that? Tell me <em>where</em> you had that milkshake. Believe me, I'd love to know - even if it is a three hour drive.<br /><br /><em>"had the best strawberry milkshake ever at Mill Creek near Mineral, NoCal"</em><br /><br />Honey start the car, we're going for a drive!<br /><br /><h3>7. I don't need more spam^H^H^H^H marketing</h3>Corporate tweeting is hot these days. There are many corporate twitter accounts that are easily recognizable, because they consist of the company's name. But there are also plenty of innocent-looking names that generate a remarkable number of tweets that simply reiterate how great product xyz is or how well product abc would solve the problem I'm (not) having).<br /><br />I don't have a problem with these accounts. We're all luckily free to tweet whatever we want. But if you'd like to keep your followers: keep your marketing to content ratio below 20%.<br /><br /><h3>8. I read your blog already</h3>Some people see link tweets as the natural progression of feed readers. I don't. I still have a healthy 100 or something feeds that I follow, just because they regularly show content that I like to read. <br /><br />In other words: if you have a blog that is of interest to me, chances are it's already in my Google reader. So if all that you are tweeting is links to your blog posts, following you is not really adding any value for me. Now where's that unfollow link?<br /><br />Mind you: there's nothing wrong with tweeting about your own posts. In fact that's what I'll do once I click the publish button for this post too. But if you want to keep me as a follower, be sure to add some original content into your tweets too.<br /><br /><h3>And yours?</h3><br />Those are the rules that sprang to my mind as I was scrolling through the rapidly growing stream of tweets. Do you have any rules of your own? How can I make sure that you don't click the "unfollow" link on me?Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com5tag:blogger.com,1999:blog-2341502915119631850.post-70195318223494261732009-07-06T20:38:00.002+01:002009-07-06T20:41:15.774+01:00Safari 4 on Windows crashes when you provide incorrect credentialsSorry for the long title of this post. But it is the most accurate description of a problem we're having in a project at the moment. Safari 4 on Windows seems to crash in what I perceive to be a common use case. Here are the minimal steps that I came up with for reproducing the problem:<br /><br /><ol><br /><li>create a new web site in IIS</li><br /><li>enable integrated authentication on this web site</li><br /><li>connect to the new web site with Safari 4 for Windows</li><br /><li>provide incorrect credentials</li><br /></ol><br /><br />At this point Safari 4 crashes on my system.<br /><br />Providing correct credentials allows us to continue. But in the application my team is building, we will often encounter another authentication problems later on. <br /><br /><ul><li>Safari pops up a log on box when we open a page from the same web site in an iframe. No matter which credentials we provide, we can't continue.</li></ul><br /><br />I've been searching whether this is a known problem for a while now. But I haven't found a single page that points out the problem we encountered here. Hence this simple write-up.<br /><br />Has anyone had similar problems with Safari on Windows? If so, is there any way to work around the problem? Because as it is, we can't really support our application on Safari 4 on Windows. :-/Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com3tag:blogger.com,1999:blog-2341502915119631850.post-59144050528166939222009-05-16T18:56:00.001+01:002023-07-04T10:34:03.112+01:00Particle systems in JavaScriptParticle systems have always held some magic for me. Or maybe I should explain it more clearly: anything that resembles physics in a game-like fashion has always held some magic to me. In this post we'll look at how to create a simple particle system in JavaScript.<br /><br /><h2>Pod racers</h2><br />A few years ago when I wrote a small 3D pod racer for my own amusement. If you don't know what pod racers are, have a look at this video:<br /><br /><object width="425" height="344"><param name="movie" value="http://www.youtube.com/v/TVQ1Vev33s8&hl=en&fs=1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/TVQ1Vev33s8&hl=en&fs=1" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object><br /><br />My game looked nothing like that of course. I'm a developer, not an artist. And besides I spent lots of time playing with the physics of the pod: where are the thrusters on my pod? How much force do the thrusters give? Does the force get exponentially bigger when the pod gets closer to the track? Fun stuff.<br /><br />I also added a particle system to my pod. After all, those thrusters are bound to give off some exhaust fumes and this was a great way to give an indication of speed. And of course it was a great way for me to get started on particle systems.<br /><br />As it turns out particle systems are really quite simple things. I had a blast playing with the parameters and figuring out how to create a most interesting effects.<br /><br />Of course the pod racer was never finished and the source code has long been lost. That's why today we'll create a completely new particle system. In less than 100 lines of JavaScript. Granted it will only be 2D this time. But believe me, I've already been staring at the flow of particles longer now than it took me to write the script.<br /><br /><h2>parts of a particle system</h2><br /><br />Let's get started with the three things that make up a particle system:<br /><ol><br /><li>an array of particle data structures</li><br /><li>a function that updates all particles each frame</li><br /><li>some form of lifetime management for the particles</li><br /></ol><br /><h2>Parts of a particle</h2><br />First comes the particle data structure. What makes up a particle? If you've ever seen a particle system in its bare essentials, you'll have noticed that it consists of multiple small elements on your screen that each move on their own account, yet in a predictable and similar way.<br /><br />This already means quite a few things. A particle apparently has a location on the screen. And since it moves, it must also have a direction.<br /><pre><br />var particle = {<br /> x: 0.0,<br /> y, 0.0,<br /> dx, 0.5,<br /> dy: 0.5<br />}<br /></pre><br />So this is a particle that is at position (0,0) and moves half a pixel to the right and bottom every time.<br /><br />Creating an array of these objects is of course really simple.<br /><pre><br />function createParticle() {<br /> return {<br /> x: 0.0,<br /> y, 0.0,<br /> dx, 0.5,<br /> dy: 0.5<br /> }<br />}<br /><br />var particles = [];<br />for (var i=0; i < 10; i++) {<br /> particles.push(createParticle());<br />}<br /></pre><br />But of course these are really boring particles. They're all the same. Let's make the particles unique by adding a bit of randomness:<br /><pre><br />function createParticle() {<br /> return {<br /> x: 0.0,<br /> y, 0.0,<br /> dx, Math.random() + 0.5,<br /> dy: Math.randon() + 0.5<br /> }<br />}<br /><br />var particles = [];<br />for (var i=0; i < 10; i++) {<br /> particles.push(crateParticle());<br />}<br /></pre><br />So this creates 10 particles. They all start from the same location on the screen, yet move out in a different directory.<br /><br />With that out of the way, let's move on to the behavior of the particles.<br /><h2>Particle behavior</h2><br />As I said in the previous section, particles move in a predictable way. So we'll need a function that updates the position of each particle every frame.<br /><pre><br />function update() {<br /> for (var i=0; i < particles.length; i++) {<br /> particles[i].x = particles[i].x + particles[i].dx;<br /> particles[i].y = particles[i].y + particles[i].dy;<br /> }<br />}<br /></pre><br />And of course we'll need to call this function periodically:<br /><pre><br />setInterval("update()", 50);<br /></pre><br />Calling the update function every 50ms results in a 20 frames per seconds. This will give us quite smooth animation, without being too taxing for todays browsers/PCs.<br /><h2>lifetime management</h2><br />We're almost done here. But if we would start this particle system now, the particles would just move away from each other indefinitely. That won't be very interesting to look at. <br /><br />What we need to add is some way for the particles to die and for new particles to be born. The simplest way to do this for now is by giving each particle a lifetime counter at birth and just decrease that with every update.<br /><br />Let's first update our createParticle function:<br /><pre><br />function createParticle() {<br /> return {<br /> x: 0.0,<br /> y, 0.0,<br /> dx, Math.random() + 0.5,<br /> dy: Math.random() + 0.5,<br /> ttl: Math.floor(Math.random()*50) + 50 // time to live in frames<br /> }<br />}<br /></pre><br />We now defined that each particle will live between 50 and 100 frames. With a framerate of 20 frames per second, that will give the particles a lifetime of between 2.5 and 5 seconds.<br /><br />Let's use this new property in our update function:<br /><pre><br />function update() {<br /> for (var i=0; i < particles.length; i++) {<br /> particles[i].ttl = particles[i].ttl - 1;<br /> if (particles[i].ttl > 0) {<br /> particles[i].x = particles[i].x + particles[i].dx;<br /> particles[i].y = particles[i].y + particles[i].dy;<br /> } else {<br /> particles[i] = createParticle();<br /> }<br /> }<br />}<br /></pre><br />See the nice little trick we do here? We don't delete the particle, we just replace it with a new one. Of course the new particle will start at the origin again and will have its own direction and speed.<br /><br />This way we will always have the same number of particles in our system.<br /><h2>visualize the particle system</h2><br />I was not completely honest at the start here. There is actually one more step we have to take before we can see our particle system in action. After all what good is a particle system if you can't see it.<br /><br />Up until now the particle system we've created is completely agnostic to the output system. If you use JavaScript for scripting your DirectX game, you might render these particles onto a DirectDraw surface. If you feel really "Linuxy" you might render them onto a 24x40 character display. But for our purposes here, we'll render the particles using HTML.<br /><br />I'll just show the modified fragments here. For the complete script, refer to the end of the article.<br /><br />We visualize each particle as a simple HTML span with a blue border:<br /><pre><br />function createParticle(span) {<br /> return {<br /> elm: span ? span : createParticleElement(),<br /> ...<br /> }<br />}<br />function createParticleElement() {<br /> var elm = document.createElement('span');<br /> elm.style.border = '1px solid blue';<br /> elm.style.position = 'absolute';<br /> elm.style.width = elm.style.height = '3px';<br /> container.appendChild(elm);<br /> return elm; <br />}<br /></pre><br />When updating the particle, we also have to update its span. When the particles dies, we re-use the span for the new particle:<br /><pre><br /> if (particles[i].ttl > 0) {<br /> ...<br /> particles[i].elm.style.left = Math.floor(particles[i].x) + 'px';<br /> particles[i].elm.style.top = Math.floor(particles[i].y) + 'px';<br /> } else {<br /> particles[i] = createParticle(particles[i].elm);<br /> }<br /></pre><br /><h2>demo</h2><br />The frame below shows a demonstration of the particle system we just built. If it doesn't work for you, click <a href='https://jsparticles.web.app/particles1.html' target='_blank'>this link</a> to open the same demo in a popup window.<br /><iframe src='https://jsparticles.web.app/particles1.html' width='340' height='240'> </iframe><br /><h2>next steps</h2><br />As you can see this particle system is about as simple as it can be. Real particle systems in games and simulations are of course much more complex. But the basic ingredients stay the same:<br /><ol><br /><li>an array of particle data structures</li><br /><li>a function that updates all particles each frame</li><br /><li>some form of lifetime management for the particles</li><br /></ol><br />If there is interest in it, I would like to make this post the first of a series where we investigate particle systems. If that is the case, the next step will be to make the particle system a bit more interesting by adding some "physics-like" behavior to it.<br /><h2>the finished script</h2><br />This is the complete script needed to run this particle system. If you count them, you'll see that it is only 47 lines of code. So you can create an (admittedly simple) particle system in less than 50 lines of code.<br /><pre><br />var container;<br />var particles;<br /><br />function createParticle(span) {<br /> return {<br /> elm: span ? span : createParticleElement(),<br /> x: 0.0,<br /> y: 0.0,<br /> dx: Math.random() + 0.5,<br /> dy: Math.random() + 0.5,<br /> ttl: Math.floor(Math.random()*50) + 50 // time to live in frames<br /> }<br />}<br /><br />function createParticleElement() {<br /> var elm = document.createElement('span');<br /> elm.style.border = '1px solid blue';<br /> elm.style.position = 'absolute';<br /> elm.style.width = elm.style.height = '3px';<br /> container.appendChild(elm);<br /> return elm; <br />}<br /><br />function update() {<br /> for (var i=0; i < particles.length; i++) {<br /> if (i == 0) console.log(i+' '+particles[i].ttl);<br /> particles[i].ttl = particles[i].ttl - 1;<br /> if (particles[i].ttl > 0) {<br /> particles[i].x = particles[i].x + particles[i].dx;<br /> particles[i].y = particles[i].y + particles[i].dy;<br /> particles[i].elm.style.left = Math.floor(particles[i].x) + 'px';<br /> particles[i].elm.style.top = Math.floor(particles[i].y) + 'px';<br /> } else {<br /> particles[i] = createParticle(particles[i].elm);<br /> }<br /> }<br />}<br /><br />window.onload = function() {<br /> container = document.getElementById('container');<br /> particles = [];<br /> for (var i=0; i < 10; i++) {<br /> particles.push(createParticle());<br /> }<br /><br /> setInterval("update()", 50);<br />}<br /></pre><br />Download it <a href='https://jsparticles.web.app/particles1.js'>here</a><br /><br />The corresponding HTML:<br /><pre><br /><html><br /> <head><br /> <title>JavaScript Particle System</title><br /> <script type="text/javascript" src="particles.js"> </script><br /> </head><br /> <body><br /> <div id="container" style="width:320px; height: 200px"> </div><br /> </body><br /></html><br /></pre><br />Download it <a href='https://jsparticles.web.app/particles1.html'>here</a>Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com5tag:blogger.com,1999:blog-2341502915119631850.post-36979623799809831512009-04-17T16:40:00.008+01:002009-10-31T15:05:21.491+01:00mstsc /console doesn't work anymore<div style="margin: 20px; border: 1px solid grey; background-color: silver; font-size: 150%">Summary: instead of calling <code>mstsc /console /v:servername</code> you should now use <code>mstsc /admin /v:servername</code>.<br /></div><br /><br />This post should really go under the category: what were they thinking?<br /><br />In our company we use a product that for licensing reasons really wants to make sure that only a single instance of the application is running. One of the things the developers have done to ensure this, is not allowing the application to be started on a remote desktop session. Otherwise: you could install the program on a single machine and let multiple users initiate remote sessions on that machine and this violate the license agreement. Now I'm not saying I agree with this type of licensing setup, but the software is pretty good and we want to make sure we're not doing anything illegal with it.<br /><br />So what we came up with was setting up a server with the software and then asking developers needing the tool to connect to the console session on that server using Windows' Remote Desktop Connection. The console session is (from the little that I understand of it) the first session that is started on a machine. So even on a terminal services server, there is only one console session. Connecting to it is quite simple from a command prompt:<br /><br /><code>mstsc /console v:machinename</code><br /><br />The chances of two of our users needing access to the tool at the same time are pretty slim, so this setup actually worked for us quite well for the last year or so. Until last week that is.<br /><br />Suddenly I was getting reports from one of my team members that he couldn't start the tool due to a licensing error. He checked and double checked, but seemed quite sure that he was using the correct command line. I walked up to the server myself and tried to start the tool - it started without problems. So I left the tool running for him and told him to try again. He did... and said the tool wasn't there when he connected!<br /><br />Anyone with enough experience with multi-session machines knows that this means the remote desktop was in another session than the one I started the application in. But how could that be? My team member clearly told mstsc to connect to the console session.<br /><br />A few Google searches later, I found the answer. Now keep in mind: the problem occurred and was solved last week. But just writing about it here, still makes me angry - very angry with some people at Microsoft.<br /><br />What happened is that a team at Microsoft found out that there was <a href="http://blogs.technet.com/askperf/archive/2007/04/27/application-compatibility-session-0-isolation.aspx">a security issue with the way terminal services worked</a>. So they changed the logic of console vs. administrative sessions for security reasons. Nothing wrong with that - I appreciate security as much as the next guy.<br /><br />So they now separate the real session 0 from the first GUI session. Sounds good. I am no security expert so I don't know if it helps, but I'll take their word for it. But they didn't stop at that. Somebody then also decided that the /console option of the remote desktop client should not be called /console anymore. After all you might not be always be able to connect to the console anymore - on newer servers it would connect you to the first, typically administrative GUI. So they relabeled the "console" session to the "administrative" session. Relabeling is not wrong - I appreciate clarity as much at the next guy.<br /><br />So instead of calling <code>mstsc /console /v:servername</code> you should now use <code>mstsc /admin /v:servername</code>. All clear - nothing wrong with that.<br /><br />All of this so far is fine and can be explained to anyone. But this of course leaves one decision to be made: what do you do with the existing <code>/console</code> option? What do you do with all those existing scripts that might already use <code>mstsc /console</code> in the expectation that they end up connected to the console session?<br /><br />And this is where they did something that I don't understand, that I really, REALLY, REEEAAAALLLY don't understand. They decided to in some cases start ignoring the <code>/console</code> option. So with some versions of the remote desktop client, using <code>mstsc /console</code> will end you up in the console/admin session. And in other versions of the remote desktop client, using the same command will end you up in a completely normal session.<br /><br />Even after a week of thinking about it, I still don't understand why somebody would decide to silently start ignoring the <code>/console</code> a command line switch that users might depend on. The switches of a command line tool are pretty much the API that you expose to the outside world. Whole build scripts have been built against command line tools based solely on the fact that the switches that are there will not change. Switches might be added, but nothing ever gets dropped. Except at Microsoft I guess. There some genius decides that in some cases they would start silently ignoring the <code>/console</code> option on the command line. See this post on the <a href="http://blogs.msdn.com/rds/archive/2007/12/17/changes-to-remote-administration-in-windows-server-2008.aspx">exact behavior in all cases</a> or read this one for <a href="http://blogs.technet.com/askperf/archive/2008/01/04/mstsc-exe-no-more-console-switch-in-rdc-6-1.aspx">non-Windows-2008 servers</a>. Don't expect to understand the logic after that, but at least it is clear that they've spent a lot of time on this change. And after last week: so have I.<br /><br />I know not to expect an apologetic phone call from Redmond on this, nor do I really expect them to change the behavior of the mstsc client. Instead I'll just warn my fellow programmers and be on the lookout for remote desktop sessions that don't behave like I expect them to.<br /><br />Ok... time to breath in and breath out, count to ten and do my exercises. And get back to work of course. Now what was I working on?Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com2tag:blogger.com,1999:blog-2341502915119631850.post-59244141784816236672008-12-25T20:39:00.010+01:002008-12-25T20:57:26.709+01:00Which keyboard is best on mobile phones?It seems that mobile phones are the main place where UI experiments are still being done. One of the types of UI experiment that recently drew my attention was in keyboard design.<br /><br /><h2>Palm Treo</h2><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_QCmUgDEhTiw/SVPj9nrA-7I/AAAAAAAACKo/HViAnE3oBww/s1600-h/DSC01913.JPG"><img style="cursor:pointer; cursor:hand;width: 320px; height: 239px;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/SVPj9nrA-7I/AAAAAAAACKo/HViAnE3oBww/s320/DSC01913.JPG" border="0" alt=""id="BLOGGER_PHOTO_ID_5283817435596651442" /></a><br />I just got a Palm Treo from work. That Treo has a built in QWERTY keyboard with horribly small keys. The keyboard is always available, together with the screen. And although that sounds convenient, it does mean that both the screen and the keyboard are small and the device is clunky.<br /><br /><h2>GPhone</h2><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_QCmUgDEhTiw/SVPkuA22lzI/AAAAAAAACKw/iV7d-PS9ki0/s1600-h/9808_1.JPG"><img style="cursor:pointer; cursor:hand;width: 320px; height: 252px;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/SVPkuA22lzI/AAAAAAAACKw/iV7d-PS9ki0/s320/9808_1.JPG" border="0" alt=""id="BLOGGER_PHOTO_ID_5283818266990909234" /></a><br />Compare this to the design of the first Google phone: the T-Mobile G1. When using this device as a phone the keyboard is stowed away under the screen. When you want to access one of its many PDA functions, you fold away the screen and the mini QWERTY keys become available. So while in phone mode the device is a lot smaller, but in PDA mode it is bigger.<br /><br /><h2>iPhone</h2><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_QCmUgDEhTiw/SVPlAIpN3CI/AAAAAAAACK4/PzrVFB5qhPM/s1600-h/apple-iphone-intelligent-keyboard-on-screen-demonstration%255B2%255D%5B1%5D"><img style="cursor:pointer; cursor:hand;width: 296px; height: 320px;" src="http://3.bp.blogspot.com/_QCmUgDEhTiw/SVPlAIpN3CI/AAAAAAAACK4/PzrVFB5qhPM/s320/apple-iphone-intelligent-keyboard-on-screen-demonstration%255B2%255D%5B1%5D" border="0" alt=""id="BLOGGER_PHOTO_ID_5283818578318842914" /></a><br />Lastly there's the iPhone solution: a virtual on-screen keyboard. There on-screen keyboards were pioneered by Windows PDAs about a decade ago, but leave it to Apple to breathe stylish new life into an existing concept. The screen on your iPhone is big and can be used for normal operation. Until you need a keyboard, then the screen is split into two: the top section remains a normal screen and the bottom section becomes a virtual keyboard. The virtual keys are as miniaturized as their physical counterpart. But they do miss the tactile feedback you get from the other devices. So while it looks endlessly better, inputting text on the iPhone is probably slower than on the others.<br /><br />So what do you think? Which is the better way of inputting text on your mobile device? The Treo approach of an "always on" keyboard? The way the Google Phone hides the keyboard during normal operation? Or do you prefer the iPhone's virtual keyboard?Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com4tag:blogger.com,1999:blog-2341502915119631850.post-29588076892120977292008-10-25T09:12:00.002+01:002008-10-25T09:19:00.016+01:00Optimistic locking vs. pessimistic lockingIf you have an education in computer science you typically learned about locking in databases. I was taught that the only safe way to update a database in a multi-user environment is to use a transaction:<br /><ol><br /> <li>acquire a lock on the record</li><br /> <li>read the current value from the record</li><br /> <li>calculate the new value</li><br /> <li>write the new value to the record</li><br /> <li>release the lock</li><br /></ol><br />Simple. Reliable. Safe.<br /><br />And horribly slow...<br /><br />Imagine thousands of users concurrently hammering your database. Most of these users will be working on different records. So for most of them, the lock is completely useless. But you're still paying the price for acquiring this lock on every database update. That is why this type of locking is called a pessimistic lock. You assume that multiple people will want to update that same record and prevent them from doing so. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://tbn0.google.com/images?q=tbn:k46I8BklSANLWM:http://p-stat.livejournal.com/img/mood/sam/pessimistic.gif"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 50px; height: 50px;" src="http://tbn0.google.com/images?q=tbn:k46I8BklSANLWM:http://p-stat.livejournal.com/img/mood/sam/pessimistic.gif" border="0" alt="" /></a><br /><br />I thought this was the only way to do locking, until I encountered something completely different about 10 years ago. At my company at the time we used an internally built software application to track stock levels of our products. And that application used the pessimistic lock pattern described above. The application worked fine for some time, but as it got more users it started to have more and more performance problems. I was brought in as part of a team to solve those problems. I immediately went to work on some of the heaviest operations and was able to bring startup performance back to acceptable levels in a few days. But the updates to the database were still going as slow as ever.<br /><br />That's when the technical lead of my team came with an interesting suggestion. "Why don't we remove the database locks?" Of course the entire team was in shock. You couldn't remove the locks from the updates. That meant that the data could become corrupt. That is what we told the tech lead: you need locks to keep your data from becoming corrupt. "So why don't we ensure that the data won't become corrupt when we update it?"<br /><br />Nobody understood what he meant. Keep in mind that all of us were brought up with the concept of pessimistic locking. So the lead asked us to show him the queries that were being fired against the database:<br /><ol><br /> <li>SELECT ID, StockCount FROM tblProducts WHERE ID=?</li><br /> <li>application code calculates the new stock for the product</li><br /> <li>UPDATE tblProducts SET StockCount=? WHERE ID=?</li><br /></ol><br />He thought about it for a while and then said "How about this?":<br /><ol><br /> <li>SELECT ID, StockCount FROM tblProducts WHERE ID=?</li><br /> <li>application code calculates the new stock for the product</li><br /> <li>UPDATE tblProducts SET StockCount=? WHERE ID=? AND StockCount=?</li><br /></ol><br />"So we pass in both the new value for StockCount and the value that we expect to be there. That way the update will only be performed when the StockCount has not been modified by anyone else."<br /><br />I can still remember the shock going through my mind. Does this mean that I don't need to lock the record before reading it? What will we do when the StockCount <u>did</u> actually change between our SELECT and our UPDATE?<br /><br />All these questions were answered in the next few hours. If some other user had performed a conflicting UPDATE while our code was busy figuring out the new stock vale, we'd have to reperform the entire sequence above. So the process turned more into a loop:<br /><ul><br /><li>while the stock value has not been updated:</li><br /><ol><br /> <li>SELECT ID, StockCount FROM tblProducts WHERE ID=?</li><br /> <li>application code calculates the new stock for the product</li><br /> <li>UPDATE tblProducts SET StockCount=? WHERE ID=? AND StockCount=?</li><br /></ol><br /></ul><br />And sure the code got a bit more complex. And definitely in the worst case, this code will send a lot more queries to the database than the one with pessimistic locking. After all, it will fire multiple SELECT and UPDATE statements. Potentially an unlimited number of them, because of the loop.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://tbn0.google.com/images?q=tbn:uARDwqVhjhXRsM:http://p-stat.livejournal.com/img/mood/sam/optimistic.gif"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 50px; height: 50px;" src="http://tbn0.google.com/images?q=tbn:uARDwqVhjhXRsM:http://p-stat.livejournal.com/img/mood/sam/optimistic.gif" border="0" alt="" /></a>But that is exactly why people call this the optimistic locking pattern. As I said earlier, most concurrent updates to a database are to different records. So most updates don't have a conflict. But with pessimistic locking all updates pay the price of acquiring a lock. So all updates pay get a penalty for a small fraction of them that do require the locking.<br /><br />Optimistic locking is built on the assumption that most updates are without conflicts. When there is no conflict, there is no penalty. And only when there has been a conflicting update, do we go into the loop of retrying and pay the penalty. The penalty will be much higher than with pessimistic locking, but it will only be paid for the cases where it is needed.<br /><br />So there you have it, the difference between optimistic and pessimistic locking and how I learned about them. Pick whichever one you think will work best for your project. Both of them are perfectly suitable for keeping your data safe. It all depends on the ratio of "updates with conflicts" vs. "updates without conflicts" for your application.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com7tag:blogger.com,1999:blog-2341502915119631850.post-52521390551852751582008-07-13T09:53:00.000+01:002008-07-13T08:56:11.810+01:00Using PageRank to determine the most powerful people on LinkedInLast week I was reading <a href="http://dbpubs.stanford.edu:8090/pub/1999-66">the original paper by Larry Page and Sergey Brin on the PageRank algorithm</a>. <a href="http://en.wikipedia.org/wiki/PageRank">PageRank</a> is an algorithm to determine the relative authority of pages that they came up with while at Stanford University. And it is of course also the algorithm they then just started using for a search engine at Stanford - a search engine they named Google.<br /><br />If you just skip the math for a moment, the PageRank algorithm is surprisingly simple. The basic rules in determining the rank of a page are:<br />1) the links to a page determine its rank<br />2) a page spreads its rank over the links it contains<br /><br />So if you have a page with three links on it, that page will contribute one third of its rank to each of those links. A page with a rank of 100 that has two links on it, will give 50 points to each of its targets.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_QCmUgDEhTiw/SHmxCP-lRbI/AAAAAAAAA6g/aDHgNpW4558/s1600-h/simplified+pagerank.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="http://1.bp.blogspot.com/_QCmUgDEhTiw/SHmxCP-lRbI/AAAAAAAAA6g/aDHgNpW4558/s320/simplified+pagerank.png" border="0" alt="A simplified PageRank calculation, showing that each page re-distributes its own PageRank over the pages it links to" id="BLOGGER_PHOTO_ID_5222399895119676850" /></a><br /><br />One thing you may already have noticed is that the definition of the PageRank can't be determined in one go: you need to know the value of all incoming links to determine the rank of a page, which you need to know to determine the value of all outgoing links. According to the paper you can simply calculate all PageRanks in an iterative fashion until it converges after a quite limited number of steps. I'll gladly take their word for it, since that puts the algorithm back into the hands of us programmers. We can iterate over large collections of data like no other.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_QCmUgDEhTiw/SHmxCSKEc-I/AAAAAAAAA6o/BW8Lq_kwgt8/s1600-h/simplified+converged+pagerank.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="http://1.bp.blogspot.com/_QCmUgDEhTiw/SHmxCSKEc-I/AAAAAAAAA6o/BW8Lq_kwgt8/s320/simplified+converged+pagerank.png" border="0" alt="A converged PageRank calculation, showing that repeated refinement will result in a stable network of PageRanks" id="BLOGGER_PHOTO_ID_5222399895704728546" /></a><br /><br />The PageRank algorithm is so simple that it not only works, it has turned the search engine world (and the internet in general) upside down. I'm quite sure that today's PageRank is determined in a much more complex fashion, but let's stick to this older and more simple model for now.<br /><br />What else could we use PageRank for?<br /><br />What would happen if you let PageRank loose on a completely different type of data? How about instead of taking all the hyperlinked documents on the web, we take a social network? So take the network of people at a site like LinkedIn, Facebook, Plaxo or Orkut and apply the same two basic rules:<br />1) a person's rank is determined by the incoming links<br />2) a person's rank is evenly divided over their outgoing links<br /><br />So the more people link to you, the higher your rank. And if more people link to the people that link to you, your rank will get even higher.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_QCmUgDEhTiw/SHm0mL66N5I/AAAAAAAAA68/A6AII6qoVXY/s1600-h/576632144_54192779fe%5B1%5D.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/SHm0mL66N5I/AAAAAAAAA68/A6AII6qoVXY/s320/576632144_54192779fe%5B1%5D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5222403811040704402" /></a><br /><br />If we let PageRank loose on a social network like this, what will happen? Who will get the highest PageRank? And what does the rank mean in such a scenario? Is your PageRank an indicator of the power of your social network? Will my boss indeed have a higher rank than me, as you would expect? And will his boss have an even higher rank?<br /><br />There are of course differences between links on a social network site and the web in general. For example: in a social network like this the links between people are non-directed, when you are connected to someone that person is also connected to you. This will likely affect the results, but I am too bad at maths to foresee how.<br /><br />Basically I have no idea what the outcome of such an experiment will be. It just seems to me that it would be incredibly interesting to see what the numbers are and then determine what they mean. Much like Page and Brin did with their original PageRank: first let the algorithm loose on the data, then see what you can do with the results. If the algorithm feels intuitively good, the results are bound to be interesting.<br /><br />Does you feel the same? Can this be an interesting experiment? Or is this complete nonsense and is PageRank not applicable to this scenario? And do the social network sites have APIs that will allow you to do this? Or is your data access limited to the people in your own network (as they always promise in their privacy statement) and can only someone working for Facebook/LinkedIn/Plaxo create such an application?Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com1tag:blogger.com,1999:blog-2341502915119631850.post-36644087238009845222008-03-22T09:45:00.003+01:002008-03-22T10:04:17.475+01:00Three ingredients to a better bug reportAt work I've recently been going through lots of bug reports. <img style="float:right; margin:0 0 10px 10px;" src="http://3.bp.blogspot.com/_QCmUgDEhTiw/R-TKUIckRnI/AAAAAAAAA48/x2KCaCPdftE/s320/bug.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5180487918596408946" /> It is part of my job to determine the priority of each defect that gets reported and whether we should still fix it in the upcoming release. With multiple testers trying to break the product in all possible ways and a deadline approaching rapidly, analyzing the newfound defects seems to take more and more time.<br /><br /><br /><h3>What did you see?</h3><br />People entering defects can actually do a lot to reduce the time it takes to analyze their entries. You'd be amazed at the number of defects that say something along the lines:<br /><ul style="list-style-type: none"><li><br /> "when I do A, B happens"<br /></li></ul><br />There are of course cases when this is all there is to say about a defect. For example:<br /><ul style="list-style-type: none"><li><br /> "when I click the Ok button, the browser shows an internal apache error"<br /></li></ul><br />Granted, it would be more useful if the report said a bit more about the error message. But it is at least clear that an internal error message should not be shown to the user.<br /><br /><h3>What did you expect to see?</h3><br />Unfortunately things are not always so clear:<br /><ul style="list-style-type: none"><li><br /> "when try to I delete the last item from the list, I get a message saying at least one item is required"<br /></li></ul><br />When I get an error report like this, I'm not sure what to do with it. <img style="float:right; margin:0 0 10px 10px;" src="http://3.bp.blogspot.com/_QCmUgDEhTiw/R-TK7IckRoI/AAAAAAAAA5E/uvJSlh9yRqk/s320/report.gif" border="0" alt=""id="BLOGGER_PHOTO_ID_5180488588611307138" /> Most likely there is an internal rule in the program that this list may never be empty. And the program seems to enforce this rule by giving a message when you try to delete the last remaining item. So there is a "business rule" in the program and the developer wrote code to enforce that rule. Where is the defect?<br /><br />In cases like these I ask the person who entered the defect why they think this behavior is wrong. Typically I get an answer like:<br /><ul style="list-style-type: none"><li><br /> "if I can't delete the selected item, the delete button should be disabled"<br /></li></ul><br />This added information makes things a lot clearer. So the tester didn't disagree with the fact that there should always be at least one item in the list, they just didn't agree with the way it was handled.<br /><br /><h3>Why do you think your expectation is better than the current behavior?</h3><br />But the above leaves me with a problem. There is a clear rule in the program that the list must never be empty. The programmer implemented this one way, someone else thought it should have been implemented another way.<br /><br />In cases like these I ask the tester (or whoever reported the defect) to explain why they think their expectation is better than the current behavior. In the example we've used so far, the reason could be something like:<br /><ul style="list-style-type: none"><li><br /> "clicking the button when there is only one item in the list will always show an error message - the delete action will never be performed. Buttons that don't lead to an action being executed should be disabled."<br /></li></ul><br />This is a clear - albeit somewhat abstract - description of the reason why the person expected the behavior to be different. <br /><br /><h3>Prior art</h3><br /><br />In this example I doubt whether anyone will disagree with the reasoning of the tester. But there are many cases where someone will disagree. Especially the developer that implemented the functionality will tend to defend the way it works.<br /><br />That's why I normally prefer the defect to point to other places where similar functionality is available in the way the tester prefers it. So in the example defect:<br /><ul style="list-style-type: none"><li><br /> "in screens B and C we have a similar list and there the delete button is disabled if there is only one item remaining in the list"<br /></li></ul><br />This type of argument works especially well when the functionality in screens B and C has already been in a released version of the product. The users of the product have experienced the functionality and they will expect the new screen to behave in the same way.<br /><br />If no similar functionality is available in the application, I often look for other programs that have similar functionality. On Windows the notepad application is one of my favorite examples. Everybody has it and the functionality as not substantially changed for at least a decade. Of course the functionality your program has might not be in notepad. In those cases I often refer to programs like Microsoft Office, Outlook, Firefox or the Google home-page. Not because I think these are perfect programs, but because they're so ubiquitous that most users accept them as a reference point for the behavior they expose.<br /><br /><h3>Summary</h3><br />So a bug report should at least contain the following ingredients:<br /><ol><br /><li>What did you see?</li><br /><li>What did you expect to see?</li><br /><li>Why do you think that 2 is better than 1?</li><br /></ol><br /><img style="float:right; margin:0 0 10px 10px;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/R-TLX4ckRpI/AAAAAAAAA5M/hO6PneXb2uA/s320/fix.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5180489082532546194" /> Now if everyone starts filing their bug reports like that, I will have to spend a lot less time on analyzing them and can get back to fixing those defects sooner. Who knows... maybe we'll make that deadline after all.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com0tag:blogger.com,1999:blog-2341502915119631850.post-74135103840570671162008-03-02T09:19:00.000+01:002015-07-16T00:26:37.974+01:00Finding primes using a grid of browsersIt's been a few months since I talked about my idea of <a href="http://frank.vanpuffelen.net/2007/12/grid-computing-using-web-browsers.html">combining the power of a lot of browsers into a so-called computing grid</a>. Since writing that post I've been working on such a browser based grid. Progress has been slow, but steady. And I'm learning a lot in the process, so I'm not complaining at all.<br /><br />My current prototype grid software has a server-side and a client-side part. Tasks and results get distributed over clients as needed. It's actually pretty cool to see one node start a task and another node finish it. But one thing that my grid lacks is a data storage service. Until I add such a service (in a scalable way) I am stuck with a grid that can only handle tasks like finding prime numbers. But even from such a classic task, there is still a lot to be learned.<br /><br />For example one of the problems we'll need to solve for a browser based grid is the fact that the nodes in the grid are not dedicated to being part of the grid. Whereas people that download <a href="http://setiathome.berkeley.edu/">SETI@home</a> at least consciously decide to contribute their computer cycles to the project, for a browser based grid this decision is less explicit. Of course this is part of the beauty of a using the web for this grid: it becomes very easy for people to join the grid. But it also means that we can't do certain things. Like eat up all available CPU cycles...<br /><br />So how do we find prime numbers without eating up too much CPU time? As you probably recall from school: a prime number is a number that can only be divided by 1 and by itself. So the simplest possible algorithm to determine if a given number is a prime is something like:<br /><pre><br /> function IsPrimeNumber(number) {<br /> for (var i=2; i < number-1; i++) {<br /> if (number % i == 0) {<br /> return false;<br /> }<br /> }<br /> return true;<br /> }<br /></pre><br />As you can see this is quite a literal translation of the definition of primes we all learned. And although there are plenty of optimizations you can do to this algorithm, we'll stick to to this very simple version for now.<br /><br />What happens if we execute this function on a node? It'll work fine for small numbers. But once the number goes beyond a certain threshold, the loop will start eating up quite some time. And since executing JavaScript in the browser is unrestricted but single-threaded, this means the script will eat up all CPU cycles for a noticeable amount of time. As I said before, that is something that I simply don't want to happen on this grid.<br /><br />So we need to modify our algorithm to not eat up all CPU time. We could optimize it by for example skipping all even numbers above 2. But that would only double the maximum number we can check with this function before the user starts to notice. What we need is something that will make this function work without noticeable effect on the CPU for any number.<br /><br />My approach to this has been to split the task into many sub-tasks. So instead of having one loop like in the version above, we split it into multiple loops that each run over a smaller range. Let's say we have the following helper function:<br /><pre><br /> function IsDividableBySomethingInRange(number, start, end);<br /></pre><br />This function will return <code>true</code> if <code>number</code> can be divided by one of the numbers in the range <code>[start, end></code>. With this helper function, we can rewrite our original <code>IsPrimeNumber</code> function to use ranges.<br /><pre><br /> function IsPrimeNumber(number) {<br /> var CHUNK_SIZE = 1000;<br /> for (var i=0; i < number; i += CHUNK_SIZE) {<br /> if (IsDividableBySomethingInRange(number, Math.max(i, 2), Math.min(i + CHUNK_SIZE, number-1)));<br /> return false;<br /> }<br /> }<br /> return true;<br /> }<br /></pre><br />Now if we leave the algorithm like this, we are still executing the work in one go. To actually remove that problem we need to convert the <code>IsDividableBySomethingInRange</code> calls into sub-tasks, which can be executed on the grid separately. The <code>IsPrimeNumber</code> function/task then just has to wait until all its sub-tasks have completed. <br /><br />The splitting of a task into sub-tasks that can be executed separately and independent of each other is a typical fork operation that I learned back in my college days. We would fork off some work to separate sub-threads, so it could be completed in parallel instead of executing each one in turn. Waiting for the sub-tasks is called a join operation. By creating a fork/join algorithm we're not just making task execution more deterministic, we're also improving parallelism by allowing the sub-tasks to run independently from each other.<br /><br />So what we really wanted to create all along is a fork/join version of our <code>IsPrimeNumber</code> function/task.<br /><br />Let's say that we have a <code>fork</code> operation that we can call to somehow fork off a function into a separate sub-task. And let's say that whenever such a sub-task is completed, it will call back into the original task with the result:<br /><pre><br />class IsPrimeNumber {<br /> var number;<br /> var result;<br /> function IsPrimeNumber(number) {<br /> this.number = number;<br /> this.result = true;<br /> }<br /> function forkSubTasks() {<br /> var CHUNK_SIZE = 1000;<br /> for (var i=0; i < number; i += CHUNK_SIZE) {<br /> fork IsDividableBySomethingInRange(number, Math.max(i, 2), Math.min(i + CHUNK_SIZE, number-1)));<br /> }<br /> }<br /> function joinSubTask(subtask) {<br /> if (subtask.result == true) {<br /> this.result = false;<br /> }<br /> }<br />}<br /></pre><br />This is a grid-enabled fork/join version of our <code>IsPrimeNumber</code> task. When we execute this task with a very large number on a grid of nodes, the task will be forked into sub-tasks and each of those sub-tasks can be executed on any of the nodes. When a sub-task is completed its result can be joined back into the <code>IsPrimeNumber</code>, which will assure that the combined result is correct.<br /><pre><br />IsPrimeNumber(2137)<br /> forkSubTasks<br /> |<br /> |--------->IsDividableBySomethingInRange(2137, 2, 1000)<br /> | |<br /> |------------------+-------------->IsDividableBySomethingInRange(2137, 1000, 2000)<br /> | | |<br /> |------------------+---------------------+---------------->IsDividableBySomethingInRange(2137, 2000, 2136)<br /> | | |<br /> joinSubTask | | |<br /> | | | |<br /> |<-----------------+ | |<br /> | | |<br /> |<---------------------------------------+ |<br /> | |<br /> |<---------------------------------------------------------------+<br /> |<br />true<--------+<br /></pre><br />If you know a bit about Google's <a href="http://research.google.com/archive/mapreduce.html">Map/Reduce</a> algorithm (or the open-source <a href="http://hadoop.apache.org/">Hadoop</a> implementation of it) you will probably see the similarities between <code>join</code> and <code>reduce</code>.<br /><br />There is still many things that we can improve here (not swamping the grid with all sub-tasks at once, keep track of the number of missing sub-tasks, etc). But essentially we now have a grid-enabled way of determining whether any given number is a prime.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com1tag:blogger.com,1999:blog-2341502915119631850.post-89207780713065569472008-02-02T10:43:00.000+01:002008-02-02T10:51:35.155+01:00Scrum: story points, ideal man days, real man weeksMy team completed its seventh sprint of a project. Once again all stories were accepted by the product owner.<br /><br />While one of the team member was giving the sprint demo, I started looking in more detail at some of the numbers. Because with seven sprints behind us, we've gathered quite some data on the progress from sprint to sprint. That's the velocity, for XP practitioners.<br /><br /><h2>Looking at the data</h2><br /><br />So far we've had 131 story points of functionality accepted by the product owner, so that's an average of 18-19 per sprint. The distribution has not really been all that stable though. Here's a chart showing the number of accepted story points per sprint:<br /><img src="http://chart.apis.google.com/chart?cht=bvs&chd=s:ecigmyy&chs=320x200&chbh=40,4&chxt=x,y&chxl=0:|1|2|3|4|5|6|7|1:|0|5|10|15|20|25|30" title="Accepted story points per sprint" /><br /><br />Although it is a bit difficult to see the trend in sprint 1 to 5, we seemed to be going slightly upward. This is in line with what you'd expect in any project: as the team gets more used to the project and to each other, performance increases a bit. <br /><br />The jump from sprint 5 to sprint 6 however is very clearly visible. This jump should come as no surprise when I tell you that our team was expanded from 3 developers to 5 developers in sprint 6 and 7. And as you can clearly see, those additional developers were contributing to the team velocity right from the start.<br /><br />But how much does each developer contribute? To see that we divide the number of accepted story points per sprint by the number of developers in that sprint:<br /><img src="http://chart.apis.google.com/chart?cht=bvs&chd=s:ecigmee&chs=320x200&chbh=40,4&chxt=x,y&chxl=0:|1|2|3|4|5|6|7|1:|0|5|10" title="Accepted story points per developer per sprint" /><br />Apparently we've been pretty consistently been implementing 5 story points per developer per sprint. There was a slight drop in sprint 6, which is also fairly typical when you add more developers to a project. But overall you can say that our velocity per developer has been pretty stable.<br /><br />Given this stability it suddenly becomes a simple (but still interesting) exercise to try and project when the project will be completed. All you need in addition to the data from the previous sprints, is an indication of the total estimate of all stories on the product backlog. We've been keeping track of that number too, so plotting both the work completed vs. the total scope gives the following chart:<br /><img src="http://chart.apis.google.com/chart?cht=lc&chs=320x200&chd=s:nnilooxx,AFKPVbjs&chco=cc0000,00aa00&chdl=scope|completed&chxt=x&chxl=0:|0|1|2|3|4|5|6|7" title="project burnup" /><br />So it looks like we indeed will be finished with the project after one more sprint. That is of course, if the product owner doesn't all of a sudden change the scope. Or we find out that our initial estimates for the remaining stories were way off. After all: it's an agile project, so anything can happen.<br /><br /><h2>Story points vs. ideal man days vs. real man weeks</h2><br /><br />Whenever I talk about this "number of story points per developer per sprint" to people on other projects, they inevitably ask the same question. What is a story point? The correct Scrum answer would be that it doesn't matter what unit it is. It's a story point and we do about five story points per developer per sprint.<br /><br />But of course there is a different unit behind the story points. When our team estimates its stories, we ask ourselves the question: if I were locked into a room with no phone or other disturbances and a perfect development setup, after how many days would I have this story completed? So a story point is a so-called "ideal man day".<br /><br />From the results so far we can see that apparently this is a pretty stable way to estimate the work required. And stability is most important, way more important than for example absolute correctness. <br /><br />A classic project manager might take the estimate of the team (in ideal man days) and divide that by 5 to get to the ideal man weeks. Then divide by the number of people in the team to get to the number of weeks it should take the team to complete the work. And of course they'll add some time to the plan for "overhead", being the benevolent leaders that they are. This will give them a "realistic" deadline for the project. A deadline that somehow is never made, much to the surprise and outrage of the classic project manager.<br /><br />I'm just a Scrum master on the project. So I don't set deadlines. And I don't get to be outraged when we don't make the deadline. All I can do is study the numbers and see what it tells me. And what it tells me for the current project is that the number are pretty stable. And that's the way I like it.<br /><br />But there is a bit more you can do with the numbers. If you know that the developers in the team estimate in "ideal man days", you can also determine how many ideal man days fit into a real week. For that you need to know the length of a sprint.<br /><br />Our team has settled on a sprint length of four weeks. That's the end-to-end time between the sprints. So four weeks after the end of sprint 3, we are at the end of sprint 4. In those four weeks, we have two "slack days". One of those is for the acceptance test and demo. The other is for the retro and planning of the next sprint.<br /><br />So there is two days of overhead per sprint. But there is a lot more overhead during the sprint, so in calculations that span multiple sprints I tend to think of those two days as part of the sprint. <br /><br />So a sprint is simply four weeks. And in a sprint a developer on average completes 5 story points, which is just another way of saying 5 ideal man days. So in a real week there is 1.25 ideal man days!<br /><br />I just hope that our managers don't read this post. Because their initial reaction will be: "What? What are you doing the rest of the time? Is there any way we can improve this number? Can't you people just work harder?"<br /><br />Like I said before: I don't believe in that logic. It's classic utilization-focused project management. It suggests that you should try to have perfect estimates and account for all variables so that you can come to a guaranteed delivery date. The problem with that is that it doesn't work! If there's anything that decades of software engineering management should have taught us, is that there are too many unknown factors to get any kind of certainty on the deadline. So until we get more control of those variables, I'd much rather have a <a href="http://frank.vanpuffelen.net/2007/08/scrum-utilization-vs-velocity.html">stable velocity than a high utilization</a>.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com3tag:blogger.com,1999:blog-2341502915119631850.post-86435177082300736462008-01-20T09:42:00.000+01:002008-01-20T09:43:26.954+01:00A WinSCP replacement for the MacAbout half a year ago I wrote a piece on the inability to use my iMac as a web development machine. The reason was very simple: the lack of a utility on OSX with a feature set similar to WinSCP on Windows. <img style="float:right; margin:0 0 10px 10px;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/Rqw2c9A8y2I/AAAAAAAAAUQ/5T35rtllifo/s320/winscp%5B1%5D.png" /> It doesn't need to have all features of WinSCP, but at least being able to browse a remote SSH/SCP file system as if it is local and being able to edit remote files without being bothered too much by the latency and remote-ness are a must-have for me.<br /><br />Apparently I'm not the only one looking for something to replace good old WinSCP on OSX, as this post is one of the most viewed and most commented on this site. In the comments visitors suggested many replacements: Cyberduck, Fugu, Smultron, Filezilla and Transmit. I tried all of them. <br /><br /><img style="float:right; margin:0 0 10px 10px;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/R5MFg_u_n9I/AAAAAAAAA3w/Nv2T_H2CDS0/s320/PanicTransmit.gif" border="0" /> But none of these tools seem to do what I want, as -until last week- I still found myself at my XP laptop whenever I wanted to work on a site. Until last week? Yes, because about a week ago my trial license of Transmit ran out. And although it's no WinSCP replacement, Transmit is a decent SCP program. So I went to <a href="http://www.panic.com/">the vendor website</a> to see what it would cost. On the website I ran into their "One-window web development" program, called Coda. After all the tries one more couldn't hurt, so I decided to give it a go.<br /><br /><br /><img style="display:block; margin:0px auto 10px; text-align:center;" src="http://3.bp.blogspot.com/_QCmUgDEhTiw/R5MFtvu_n-I/AAAAAAAAA34/YnsQKz9IdN8/s320/PanicCoda.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5157472281735176162" /><br />After installing Coda you have to get used to the fact that it is not a WinSCP clone. So it doesn't have a dual pane Norton Commander like interface, but instead just has the list of remote files on the left hand side. And when you open one of those files -instead of getting the WinSCP editor popup- Coda opens the files in a large panel on the right hand side. Open a second file and it adds a tab on that panel, where WinSCP would open a second popup window.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_QCmUgDEhTiw/R5MDK_u_n8I/AAAAAAAAA3o/AlyG_TuGsVQ/s1600-h/sites-screenshot_03%5B1%5D.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/R5MDK_u_n8I/AAAAAAAAA3o/AlyG_TuGsVQ/s320/sites-screenshot_03%5B1%5D.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5157469485711466434" /></a><br /><br />Looking at it like that, it seems like Coda tries to mimic an IDE more than anything else. But then an IDE for remote web site development, which is exactly what I use it for. I'm now about half-way through my trial period for Coda and I must say I love it so far.<br /><br />The file transfers are incredibly fast, way faster than with WinSCP it seems. They're also handled more gracefully. With WinSCP file transfers are handled in the main window, which is typically covered by my editing popup. So I have to alt-tab to the main window to see whether the transfer is complete. With Coda the file transfer is indicated by a throbber animation on the file listing on the left. When the transfer is complete, a brief notification animation is shown in the top right.<br /><br /><img style="float:left; margin:0 10px 10px 0;" src="http://1.bp.blogspot.com/_QCmUgDEhTiw/R5MIhPu_n_I/AAAAAAAAA4A/4uWjPwThvq4/s320/preview-dom%5B1%5D.gif" border="0" /> The editor is decent enough for my needs. It highlights most of the languages you typically encounter during web development and it follows most standard editing conventions. But it could do with some more keyboard shortcuts for faster editing and especially navigation. It also would be nice if it could integrate with external or online help files for supported languages. There's tons of great documentation out there for Java, JavaScript, HTML, CSS, etc. Unfortunately Coda limits its built in help system to the help that comes with the installation. So for anything beyond that, I still need to tab to my browser and search for the help there. This seriously breaks their "one-window web development" mantra and should be addressed if they want to stick to that claim.<br /><br />That said: you might notice that the editor has lots of features that the internal WinSCP editor doesn't have, so I shouldn't be complaining. Syntax highlighting is great of course, as are other features like the overview of functions in the current file. The fact that I'm asking for features that you'd normally find in real IDE's and not in WinSCP are actually a big compliment to the Panic people: Coda really feels like a web development IDE!<br /><br />The biggest downside of Coda I've found so far is the price tag. Like pretty much all software on the Mac it's commercial. Panic decided to set the price tag to $79. Which definitely doesn't make it an impulse buy for me. So I'll evaluate it a bit longer and see what happens when my trial runs out. I'll probably go back to my XP laptop and WinSCP. But if I then find myself missing Coda features, I'll give in and buy it. After all... that would mean it's better suited to my WinSCP. Who would have ever thought that would be possible?Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com11tag:blogger.com,1999:blog-2341502915119631850.post-26907797921909503522007-12-30T10:45:00.000+01:002007-12-30T10:52:56.850+01:00Grid computing - using web browsersGrid computing is one of those areas that seems to have a magic appeal to software developers. There is something very attractive about taking some relatively simple computers and wielding their combined power to perform seemingly infinitely large computing tasks within reasonable times.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_QCmUgDEhTiw/R3NWxfu_n3I/AAAAAAAAA2o/Qsaw-HuKD7Q/s1600-h/cerngrid.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/R3NWxfu_n3I/AAAAAAAAA2o/Qsaw-HuKD7Q/s320/cerngrid.jpg" alt="" id="BLOGGER_PHOTO_ID_5148554207346794354" border="0" /></a><br />I've also always been attracted to grids. But as many <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_QCmUgDEhTiw/R3NWa_u_n2I/AAAAAAAAA2g/E4PeFNMJ53A/s1600-h/google-labs%5B1%5D.png"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/R3NWa_u_n2I/AAAAAAAAA2g/E4PeFNMJ53A/s200/google-labs%5B1%5D.png" alt="" id="BLOGGER_PHOTO_ID_5148553820799737698" border="0" /></a>developers, I too thought this type of power was not within reach for me. Only since Google started documenting the "cloud of commodity PCs" that power their vast computing power, does it suddenly seem quite feasible for even just "large" companies to have their own computing cloud.<br /><br /><br />But my problem remains the same. I don't work for Google, Yahoo or IBM and I'm not a large company myself. So I don't have access to a set of commodity PCs that I can combine into a grid. So for years I decided that I'd never get a chance to work on a grid, unless I'd start working for one of those big boys.<br /><br />Recently I've been thinking about an alternate setup for a grid computer, more along the lines of the SETI@Home project and all its successors. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_QCmUgDEhTiw/R3NXdPu_n4I/AAAAAAAAA2w/3cF5dqk9fZQ/s1600-h/seti%40home-boinc-screenshot-02%5B1%5D.gif"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer;" src="http://1.bp.blogspot.com/_QCmUgDEhTiw/R3NXdPu_n4I/AAAAAAAAA2w/3cF5dqk9fZQ/s200/seti%40home-boinc-screenshot-02%5B1%5D.gif" alt="" id="BLOGGER_PHOTO_ID_5148554958966071170" border="0" /></a>Those programs all allow home PCs of users all over the world to take part in a giant computer network - a global grid in essence. So the people creating these programs get a lot of computing power, yet they don't have to manage the hardware. A powerful setup.<br /><br />But such setups already exist. And they have one downside that keeps them from even more mainstream adoption: they require the user to install software to put their computer into the grid. And although the threshold isn't very high, it's still too high for many people. So a lot of potential computing power is not used, because the barrier of installing software is too high.<br /><br />Now that got me thinking: is there an existing platform on modern PCs that we can just embed our own grid applications in? Preferably a platform that's been around for a few years, so all its quirks are known. And it would be nice if the platform comes with built-in internet connectivity.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_QCmUgDEhTiw/R3NX8fu_n5I/AAAAAAAAA24/w16LCkMp4Ow/s1600-h/Bonjour_Browser%5B1%5D.png"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/R3NX8fu_n5I/AAAAAAAAA24/w16LCkMp4Ow/s200/Bonjour_Browser%5B1%5D.png" alt="" id="BLOGGER_PHOTO_ID_5148555495836983186" border="0" /></a><br />Here's the idea that popped into my head: web browsers! They used to be nothing more than HTML viewers, but those days are long gone. Nowadays our browsers are hosting more and more complete applications, like GMail, PopFly and Yahoo Pipes. These applications prove that there is a lot of computing power in the web browser. Is it possible to use the web browsers that people have open on their PCs all the time and turn those into nodes in the grid?<br /><br />It is a very simple concept: every browser that has a certain URL open is a node in the grid. For a computer to join the grid, they just surf to the URL. To leave the grid again, they navigate away from the URL. It doesn't get much easier than that, right? No software to install, just a page you have to visit. Put it in your favorites in the office, open it every morning when you boot your PC and that's one more node in the grid. From even my own limited reach, I know of at least 5 machines that I could "grid enable" in this way. Those are all PCs and Macs that are on for a large part of the day, just waiting for me or my family to use them. Or that's what they used to be... now I can't stop thinking about them as being nodes in my "web based grid".<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_QCmUgDEhTiw/R3NZv_u_n7I/AAAAAAAAA3I/bf2JX9JkoPc/s1600-h/cobweb%5B1%5D.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/R3NZv_u_n7I/AAAAAAAAA3I/bf2JX9JkoPc/s200/cobweb%5B1%5D.jpg" alt="" id="BLOGGER_PHOTO_ID_5148557480111873970" border="0" /></a>If you're a software developer reading this, than your mind probably started wandering while reading the last few paragraphs. Is this possible? How would the nodes get their tasks? How would they report their results back? How would you manage the nodes in the grid? Where do you keep the data that is needed for/generated by the nodes? How do you handle XSS issues? Wouldn't the nodes quickly overload the server that manages them? The list of challenges is seemingly endless and definitely too much for me to deal with in one go.<br /><br />All I know is that ever since this idea popped into my head, I can't stop thinking about it. And for every problem, I can see at least a few potential solutions. I have no idea whether they'll work or which one is best, but the only way to figure that out is to actually start building the platform.<br /><br />Oh man... I really need to make this my 20% project. Or more likely... I really need a lot of people to make this their 20% project. Help?<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_QCmUgDEhTiw/R3NZNvu_n6I/AAAAAAAAA3A/JecRYRf3V8k/s1600-h/help.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://3.bp.blogspot.com/_QCmUgDEhTiw/R3NZNvu_n6I/AAAAAAAAA3A/JecRYRf3V8k/s200/help.jpg" alt="" id="BLOGGER_PHOTO_ID_5148556891701354402" border="0" /></a>Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com2tag:blogger.com,1999:blog-2341502915119631850.post-51444922569798798392007-12-22T11:50:00.000+01:002007-12-22T11:54:45.361+01:00The origin of the name Apache web serverI read a lot. Not much literature and novels as unfortunately those seem to suffer under my more professional reading habits. I read lots of technical articles, white papers, blog posts and specifications. It's part of what I do to keep up to date with the things happening in the CS field. But in part I also read all kinds of stuff to gain a broader understanding of our profession.<br /><br />Some of the longer things I read this year include "<a href="http://www.quirksmode.org/book/">PPK on JavaScript</a>", "<a href="http://www.amazon.com/Asshole-Rule-Civilized-Workplace-Surviving/dp/0446526568">The no asshole rule</a>", but also the venerable "<a href="stephane.ducasse.free.fr/FreeBooks/Art/artAdded174186187Final.pdf">Art and science of Smalltalk</a>". And some colleagues even caught me reading an OS9 AppleScript manual dated somewhere around 1999. They're still making fun of their discovery almost every day, but I don't mind... having read that manual has given me a better understanding of how the now much heralded Apple engineers thought about making an end-user programming language almost a decade ago.<br /><br />Recently I read the bulk of Roy Thomas Fielding's thesis <a href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm">Architectural Styles and the Design of Network-based Software Architectures</a> in which he introduces the principles of <a href="http://www.xfront.com/REST-Web-Services.html">REST</a>. As with any thesis it is a bit too abstract for my taste, but it did introduce me somewhat better to the background and theory behind REST.<br /><br />Aside from that, I made one stunning discover when I read about <a href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/evaluation.htm#sec_6_4_2">Fielding's involvement in the creation of the Apache HTTP server</a>:<br /><ul><li>At the time, the most popular HTTP server (httpd) was the public domain software developed by Rob McCool at the National Center for Supercomputing Applications, University of Illinois, Urbana-Champaign (NCSA). However, development had stalled after Rob left NCSA in mid-1994, and many webmasters had developed their own extensions and bug fixes that were in need of a common distribution. A group of us created a mailing list for the purpose of coordinating our changes as "patches" to the original source. In the process, we created the Apache HTTP Server Project</li></ul>Please read that last part again, and again... and again. Until it hits you where it finally hit me. What hit me? Well... I finally understood that the name of the Apache web server might (originally) have had nothing to do with the Apache tribe. The server was created by taking an existing code base and then applying all sort of patches. So in a sense it was a patchy web server. A patchy... Apache...!<br /><br />Brilliant! In all my years of knowing the Apache web server and the brand that was created around the Apache name, I never realized where it came from.<br /><br />The <a href="http://apache.org/foundation/faq.html#name">Apache website</a> itself has this to say about it:<br /><ul><li>The name 'Apache' was chosen from respect for the Native American Indian tribe of Apache, well-known for their superior skills in warfare strategy and their inexhaustible endurance. It also makes a cute pun on "a patchy web server" -- a server made from a series of patches -- but this was not its origin.</li></ul>For the moment I'll take their word for it and accept that the name sounding like "a patchy web server" is pure coincidence. I bet it's also more convenient for them in selling the Apache brand: "we named our web server after its inexhaustible endurance" sounds a lot better than "we named our web server after the fact that it was created from a bunch of unrelated patches".Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com3tag:blogger.com,1999:blog-2341502915119631850.post-86531268024684395822007-11-17T16:02:00.000+01:002007-11-17T16:08:21.270+01:00Why devx needs a better print functionI like to read technology articles during my daily commute. And since the train is too crowded for a laptop and I don't have an ebook reader (yet), I still print articles that seem interesting to read during the train ride.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://i.dell.com/images/global/products/314x314/printer_1720.jpg"><img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 320px;" src="http://i.dell.com/images/global/products/314x314/printer_1720.jpg" alt="" border="0" /></a><br />A lot of web sites still have a Print button. What happens when you click that button differs from site to site, but it roughly falls into these categories:<br /><ul><li>Show all pages at once<br />Many sites break articles into multiple pages. The print version of the article puts all of these pages together again, to allow them to be printed in one go.<br /></li><li>Re-layout the site to print better<br />Tables seem to be notoriously difficult to print. That's why many sites revert to a table-less layout in their print version<br /></li><li>Remove navigation elements<br />Global and local navigation elements are pretty useless on paper. So they're removed from the print layout.<br /></li><li>Images - click to see full size version<br />Some graphics-intensive sites show images of reduced size in their normal view, showing the full version in a popup when you click some link. Since you can't click a link in the Print version, the full size images should always be shown there.<br /></li></ul>These are some things that I wish more site would do:<br /><ul><li>Replace animated adds by text adds<br />I don't mind showing adds next to good content. I do mind the ignorance of including animated adds in a print layout. I'm pretty sure no printer will deal with these in a useful way.<br /></li><li>Use images that are more appropriate for B&W<br />Most people still use B&W printers. So it would be nice if sites allowed the option of replacing their colored images with version that are more suited to printing on a B&W printer.<br />A common example of this are mostly-black screenshots like from command prompts/shell windows. When printed these really eat through a toner at high speed. It would be nice if a site would allow me to replace those images with ones that are mostly white, making my toner last longer.<br /></li></ul>That's a pretty long list. And most of these things can actually be accomplished on a website without needing a special print version of the articles. Hiding navigation elements, showing non-animated adds and other layout tricks on a print version can easily be accomplished using CSS media types. And why do most sites still use tables for their layouts? Just remove those tables and you have one less difference between the screen and the print version. And I also think it would make sense to show all content on a single page.<br /><br />So that actually leaves just one reason for having a Print button: showing full sized images inline. And that finally brings us to the title of the article: the print function of <a href="http://www.devx.com/">DevX</a>.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://assets.devx.com/devx/7819.gif"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px;" src="http://assets.devx.com/devx/7819.gif" alt="" border="0" /></a>DevX is a nice development site that sometimes has very interesting content. And one of the reasons their content is good is that they usually include quite a lot of screenshots and diagrams. This just makes their articles so much easier to follow. On screen the articles show the images at a reduced size. Which makes sense, because the images are often full screen screenshots which would otherwise leave hardly any room for text.<br /><br />But if you've ever printed an article from www.devx.com you've probably noticed their print versions still only show the images with a reduced size. They're not replaced by the full-resolution version. They're not printed in a larger box. They're not even added at the end of the article, like appendices. The images in the print version are exactly the same as in the screen version: reduced to sometimes a tenth of the the original size.<br /><br />So whenever I find an article in DevX that I want to read on the train, I start up Word and open the print version in there. Then I remove all tables, because they also don't print very well from Word. Then I go back to the browser and open each image, copy it to the clipboard, paste it in Word and then remove the useless downsized version.<br /><br />And although I normally like the high volume of screenshots that DevX uses in their articles, this is actually a reason why I'd like them to use less screenshots and more text. Because this conversion to Word is not just a lot of mindless work; I sometimes forget to do it and print a DevX article as is. And by the time I realize what I've done, I'm already on the train. So I do my best and squint my eyes trying to read the text in there.<br /><br />So there you have it: please DevX fix your @$@%&^# Print function.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com0tag:blogger.com,1999:blog-2341502915119631850.post-29755763938950694692007-10-06T08:20:00.000+01:002007-10-06T07:22:16.666+01:00Viewing and editing Scrum project management data with Google Mashup EditorWelcome to my first post on the Google Mashup Editor. In this article we'll create a tool for entering and storing data using Google's new mashup editor tool. Depending on available time, the evolution of Google Mashup Editor and the availability of alternative tools, I might improve on the basic data management application in later articles.<br /><h2>Scrum project management<br /></h2>The application we'll be creating is a Scrum project management tool. If you don't know Scrum yet, it's an agile project management framework. Please do yourself a huge favor and read <a href="http://blog.crisp.se/henrikkniberg/2006/11/26/1164574680000.html" title="Scrum and XP from the Trenches">this 90 page story about Scrum</a> (<a href="http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf" title="Scrum and XP from the Trenches">pdf</a>). It's a good and fun read and has already won over many organizations to at least give Scrum a try.<br /><br />My reasons for wanting to create this type of application are many. One of them is that there seems to be no tool that satisfies my needs with the right price tag. XPlanner is good, but very basic. Mingle looks nice, but is too expensive and a real resource hog. ExtremePlanner also looks nice, but again: it seems a bit expensive for my taste. But one other reason is probably more important than the price issue: building this data model seems do-able and gives me a chance to get to know Google Mashup Editor a bit more.<br /><h2>Google Mashup Editor<br /></h2>Mashup tools seem to be a dime a dozen these days. These tools try to take programming to the masses, allowing everyone to create complex web applications based on existing data or logic.<br /><br />Yahoo was the first big player in this field, with their <a href="http://pipes.yahoo.com/">Yahoo Pipes</a>. They're aiming for a <a href="http://en.wikipedia.org/wiki/Visual_programming_language">visual programming environment</a> where the user manipulates blocks rather than writing code. Microsoft followed suit with <a href="http://www.popfly.ms/">Popfly</a>, an even richer mashup creation environment combined with what seems to be the next generation of their MSN Spaces platform.<br /><br />Google was the last entrant into this field (if I recall correctly) and the first glances at their entry into the field left me rather disappointed. No drag-and-drop programming, no cool default widgets, just a pretty basic text editor and some basic tags.<br /><br />But if you look below the surface you can see that Google Mashup Editor (GME) is actually quite different from the other two. Where Yahoo and Microsoft just seem to focus on allowing you to read and combine data from various sources, Google also allows you to create new applications from scratch. In that respect GME is more of an application creation (and hosting) platform than a mashup editor.<br /><br />Much of these additional possibilities seem so originate from Google's adoption of the <a href="http://atompub.org/rfc4287.html">Atom Publishing Protocol</a>, exposed through the <a href="http://code.google.com/apis/gdata/index.html">Google Data (GData) APIs</a>. This API is what makes GME not only a mashup editor, but also a valid tool for creating completely standalone applications. These applications are then hosted on Google's servers, using Google's servers for data storage, using the GME to create and update the applications. Some people might not like to put so much in the hands of Google. But it will certainly lower the bar for creating scalable web 2.0 applications.<br /><br />That's enough of the background talk. Let's get to work on the application.<br /><h2>Initial data model<br /></h2> We'll start by defining the basic entities and relations in our application. We'll probably expand on these later, but we can get pretty far with just the following.<br /><br />A project is something on which a team works in sprints to create a product or a release of a product. This is all intentionally very vague, as our application doesn't need to know the details of the projects it manages.<br /><br />A project has a product owner and a scrum master. Aside from that there are other team members, but we'll leave them out of the equation for now.<br /><br />A sprint is a time period during which the team implements certain stories. A sprint has a start date and end date and a description of the general goal of the sprint.<br /><br />A story is a piece of functionality that the team creates. It has a name, a description of how to demonstrate it and an estimate of the effort it will take to create the functionality. Stories can be either user-focused or technical in nature.<br /><br />All stories combined are called the product backlog. Stories from the product backlog are planned into sprints. So each project has one product backlog and some of the stories in this product backlog are planned into each sprint.<br /><br />This all translates into the following very simple data model:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_QCmUgDEhTiw/RtEs5y759uI/AAAAAAAAAbA/XjEimDBPeYI/s1600-h/scrummer_EAR.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://4.bp.blogspot.com/_QCmUgDEhTiw/RtEs5y759uI/AAAAAAAAAbA/XjEimDBPeYI/s400/scrummer_EAR.png" alt="" id="BLOGGER_PHOTO_ID_5102909224224683746" border="0" /></a>Let's see how we can translate this data model into GME.<br /><h2>Creating the project list in GME</h2>The first step is to create a new project in GME. This will show you a nice empty application with just a pair of <tt>gm:page</tt> tags.<br /><pre><br /><gm:page title="Scrum Project Manager" authenticate="true"><br /><br /></gm:page><br /></pre><br />Everything for our application will be inside the gm:page tags. If you want your application to have multiple pages, just add some more files to it. But for this application a single page will do.<br /><br />Getting data into GME consists of two steps: defining the data itself and defining the GUI for it. The data itself takes the form of a <tt style="color: rgb(0, 0, 153);">gm:list</tt> tag:<br /><pre><br /><gm:list id="Projects" data="${app}/Projects" template="projectList" /><br /></pre><br />The <span style="color: rgb(0, 0, 153);font-family:courier new;" >gm:list</span> tag defines a list of data that is used in the application. In many applications the data will be pulled from an external -RSS or Atom- feed. But we want to store the data inside the application, right in Google's mashup servers.<br /><br />The data of our project list is stored under the <tt style="color: rgb(0, 153, 0);">${app}</tt>. This is a location (a "feed" in GME terms) where the data of all users of the application is stored. If we don't want to share the data between users, we can store it under <tt style="color: rgb(0, 153, 0);">${user}</tt>, which is data that is kept per user. Currently there is no way to have data shared between some users (but not all users of the application), although this feature will probably be added in the future.<br /><br />To display the data in the list, the page needs a template. A template determines what fields to display and how to display them. It's easiest to use an HTML table, so we'll do that for now.<br /><pre><br /><gm:template id="projectList"><br /><table class="gm-table"><br /> <thead><tr><br /> <td width="200">Name</td><br /> <td width="100">Product owner</td><br /> <td width="100">Scrum master</td><br /> <td width="45"> </td><br /> </tr></thead><br /> <tr repeat="true"><br /> <td><gm:text ref="atom:title" hint="Project name"/></td><br /> <td><gm:text ref="gmd:productOwner"/></td><br /> <td><gm:text ref="gmd:scrumMaster"/></td><br /> <td><gm:editButtons/></td><br /> </tr><br /> <tfoot><tr><br /> <td colspan="4" align="right"><gm:create label="New project"/></td><br /> </tr></tfoot><br /></table><br /></gm:template><br /></pre><br />As you can see we're mixing standard HTML tags, with GME specific tags like <tt style="color: rgb(0, 0, 153);">gm:text</tt>, <tt style="color: rgb(0, 0, 153);">gm:editButtons</tt> and <tt style="color: rgb(0, 0, 153);">gm:create</tt>. Also notice the non-HTML <tt style="color: rgb(0, 0, 153);">repeat</tt> attribute on the second <tt style="color: rgb(0, 0, 153);">tr</tt> (a normal HTML table row). This tells GME to repeat that <tt style="color: rgb(0, 0, 153);">tr</tt> for every item in the <tt style="color: rgb(0, 153, 0);">${app}/Projects</tt> feed.<br /><br />If we now compile and test this application, we get an empty table with a "New project" button. Pressing the button adds an empty row to the table, with fields to fill in the values for a product.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_QCmUgDEhTiw/RtEyjS759xI/AAAAAAAAAbY/Ra0rcGYW4gM/s1600-h/gme_new_project.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://2.bp.blogspot.com/_QCmUgDEhTiw/RtEyjS759xI/AAAAAAAAAbY/Ra0rcGYW4gM/s400/gme_new_project.png" alt="" id="BLOGGER_PHOTO_ID_5102915434747393810" border="0" /></a>Note that editing and creation functionality are for free with GME. Although they're not very flexible, they allow you to quickly get started.<br /><br /><h2>Creating the list of stories in GME</h2>Next is a list of stories for a project. Since stories are always part of a project, we store the data under the feed of a project.<br /><pre><br /><h2>Stories for selected project</h2><br /><gm:list id="Stories" data="${Projects}/Stories" template="storyList" /><br /></pre><br />This is where GME really adds a lot of logic automatically. The location refers to a child of the <span style="color: rgb(0, 153, 0);font-family:courier new;" >${Projects}/StoriesProjects</span> list we defined earlier. Each project in the <span style="color: rgb(0, 153, 0);font-family:courier new;" >Projects</span> list will have its own list of <span style="color: rgb(0, 153, 0);font-family:courier new;" >Stories</span>.<br /><br />This list also needs a template to display it, which is really similar to the one for the projects.<br /><pre><br /><gm:template id="storyList"><br /><table class="gm-table">`<br /> <thead><tr><br /> <td width="200">Title</td><br /> <td width="75">Type</td><br /> <td width="25">Estimate</td><br /> <td width="100">How to demo</td><br /> <td width="45"></td><br /> </tr></thead><br /> <tr repeat="true"><br /> <td><gm:text ref="atom:title" hint="Story title"/></td><br /> <td><br /> <gm:select ref="gmd:storyType"><br /> <gm:option value="user" selected="true">User</gm:option><br /> <gm:option value="tech">Tech</gm:option><br /> </gm:select><br /> </td><br /> <td><gm:number ref="gmd:estimate"/></td><br /> <td><gm:text ref="gmd:howToDemo"/></td><br /> <td><gm:editButtons/></td><br /> </tr><br /> <tfoot><tr><br /> <td colspan="5" align="right"><gm:create label="New story"></td><br /> </tr></tfoot><br /></table><br /></gm:template><br /></pre><br />Now the only tricky bit we still need to do for the list of stories, is that it needs to be refreshed when the user selects a different project. This is quite easy, by setting an event handler.<br /><pre><br /><h2>Unplanned stories for selected project</h2><br /><gm:list id="ProjectStories" data="${Projects}/Stories" template="storyList"><br /><gm:handleEvent src="Projects"/><br /></gm:list><br /></pre><br />This tells the story list to refresh itself when an event happens in the Projects list we defined before. So select a different project will display the stories for that project.<br /><br />So after adding the story list and adding some projects and stories, our application looks like this:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_QCmUgDEhTiw/Rwck9ryPUHI/AAAAAAAAAwc/72Ye-_InkHI/s1600-h/Scrummer2.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://3.bp.blogspot.com/_QCmUgDEhTiw/Rwck9ryPUHI/AAAAAAAAAwc/72Ye-_InkHI/s400/Scrummer2.png" alt="" id="BLOGGER_PHOTO_ID_5118100143673921650" border="0" /></a>We can easily do the same for the list of sprints for the project. Since this is really similar to the list of stories, I won't show the code here. If you want to have a look at the code, look at the finished project on <span class="gme-published"></span><a class="gm-nolink gme-published" target="HOSTING" href="http://scrummer.googlemashups.com/">http://scrummer.googlemashups.com</a>.<br /><br />Last is the list of stories for the selected sprint. Note that stories can either be part of the project or part of the sprint. So for now we'll call the first type "unplanned stories". Later we'll want to share the stories between the project and the sprints.<br /><br />Since the list of stories is -again- really similar to the list of unplanned stories, we won't show the code here. But when we now run our mashup it looks like this:<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_QCmUgDEhTiw/Rwcn0LyPUII/AAAAAAAAAwk/Ca379oRrjio/s1600-h/Scrummer4.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://1.bp.blogspot.com/_QCmUgDEhTiw/Rwcn0LyPUII/AAAAAAAAAwk/Ca379oRrjio/s400/Scrummer4.png" alt="" id="BLOGGER_PHOTO_ID_5118103279000047746" border="0" /></a>At the bottom you can see that I am entering a story. This is almost a usable application, at least for entering and browsing the data. To make it something you'd really want your entire team to use for your daily managing of Scrum projects, it would require more work.<br /><br />That's it for now. If you want to have a look at the finished code or play with the application, go to <span class="gme-published"></span><a class="gm-nolink gme-published" target="HOSTING" href="http://scrummer.googlemashups.com/">http://scrummer.googlemashups.com</a>.Frankhttp://www.blogger.com/profile/13688437747795053947noreply@blogger.com2