A short flight from KL landed us in Penang - the pearl of the orient. There are good reasons for Penang to be called that. It's definitely Malaysia and Asia's food capital and perhaps also the...

A one stop shop for Sumeet Moghe's thoughts about learning in the modern enterprise.

In the quest to get agile and UX to get along better, and following successful retreats in the US, last weekend Johanna Kollmann brought together a bunch of agile and UX folk for an Agile UX retreat in London sponsored by.  Giving up a weekend was hard, but was worth it, meeting a great bunch of people and sharing thoughts and experiences from the agile and UX camps.  So what did I learn.

Rethink what we do

Coming out of the retreat it is clear that the way we do UX today needs a fundamental rethink.  As UX professionals we have fought long and hard to gain credibility and traction in organisations for what we do, but we need to be ready to evolve and embrace the changing world around us.  A world where IT no longer needs to have detailed specifications signed off before development start.  We no longer have the need (or the luxury) to do the up-front research that we are used to doing.  We no longer need to sign-off detailed wireframes before handing them over the fence to the developers to implement.  Software today really is soft.  It is more about creativity than engineering (see below).  The serialisation of activities is inefficient and wasteful.  It is time to ask how do we focus upon doing what is needed and when, working in parallel and infecting the whole system with user-centric thinking rather than siloing it into the upfront design.  This after all is what systems ergonomics is about; a forerunner to UCD that we know today, thinking about the macro (a broad system view of design, examining organizational environments, culture, history, and work goals) as well as the micro (fitting the task to the human).

But I am digressing from what I wanted to blog about, the Agile UX retreat.  Some key takeaways for me included Anders Ramsey’s analogies to the restaurant and the theatre.

Thinking analogies

Think of a restaurant.  We have the kitchen, the back room world that is focussed upon delivering consistency of servings.  Everything in the kitchen is utilitarian, serving the purpose to meet this goal.  At the front of the restaurant we have the dining room where the dishes (of consistent(ly good) quality) made in the kitchen are served.  The dining room is all about the ambiance.  Quality here is far more subjective, but a successful restauranteur will be as passionate about the dining room as she is about the food that is cooked in the kitchen.  This is the way that software is all too often built, with the kitchen and dining room being separate entities, however the way they are organised, paid for and owned, there’s little communication between the two.  To quote another Ramsey, Gordon, it is a Kitchen Nightmare.

Anders’ second analogy to consider was the Theatre.  An overly simplistic representation is that the director starts with a script.  From the script he iterates the production.  The producer’s role is to provide the director with what he needs to make the production successful.  Just be ready for the premiere which is on a fixed date.  In the lead up to the premiere the director assembles the cast, the crew and they rehearse.  They’ve got a strawman plan to work from – MacBeth, but how they implement it will evolve according to the stage, actors and artistic direction the director wants to take.  The producer does not care how or when they rehearse, she is only concerned with the success of the end goal.  As they rehearse they increase the fidelity of their performance until they premiere (go live).  but even then they are not done.  They are happy to accommodate changes to the performance, and if something different happens that clearly delights the audience they will happliy incorporate that into future performances (releases).  Sure, the audience is seeing a performance of Shakespere’s MacBeth, but it is a unique performance that has taken the initial plan and evolved as it has been created.

And so should we approach software development.  Not as an exercise in engineering, where our raw materials are fixed and highly stable, but as a creative artform, where our iterations are rehearsals for the premier and ongoing performances.

Thinking tensions

I’m sure there are more, but some examples of tensions that emerge when we try to work together:

AUX promotes rapid open communication and sharing but designers fear sharing.  (They worry early designs will be seized upon before they are ready)
AUX promotes visualisation and use of walls but corporate policies prevent this
AUX promptes doing just enough, just in time but a legacy of deliverable expectations gets in the way (research is rarely bought by the developers who will ultimately consume it).

Thinking people

At the end of the day, success comes down to people.  Agile zealots have done Agile no favours when they bang on about business value and see anything other than code as waste.  Good product design needs vision, it needs research to ensure you are building the right thing for the right people.  No one has the right to tell a UXer that testing ideas or building a prototype or undertaking research is waste if it is right for their context.  But it doesn’t need to take the time it does today.  The UX community needs to get out and spend time with the development community and understand how software is built today.  UXers need to start seeing developers as partners rather than consumers of what they do.  What if we aligned our teams around the products we build rather than the functional silos that the roles describe?  Bringing agile and UX together is more fundamental than arguing about the process (one iteration in front, washing machine cycles etc), it is about fundamentally changing the way we build software; see it as a team activity that works collaboratively rather than a factory production line with process gates and separation of responsibility.

More on the #auxretreat twitter feed

Here I sit, next to a stuffed suitcase. Intoxicated, but sober enough to catch my spelling mistakes and probably not drunk enough to deal with the fact that this is my last night here in Bangalore.

I am rather disappointed in myself for not having done a better job of updating this blog. I know that some, maybe many, friends out there were counting on entries and stories and pictures galore. I am sorry to have let you down. The possibly good news is that I am thankful for all y'all's positive feedback and I am determined to blog as much as ever once I get home and maybe get some free time... maybe.

I've heard many times that ThoughtWorks can become your life. And I always refused to believe it. I had my own life, my own friends, my own direction, my own ambitions. It's been six weeks since I've stubbornly and skeptically boarded a plane, confident that I could handle whatever ThoughtWorks threw at me. And now, even I know I am still Rose Fan, my own person, ThoughtWorks has become a part of me too. TWU has confirmed my suspicions that being a "ThoughtWorker" is different from being an "Accenturer" or an "IBMer" because ThoughtWorks is a culture, a movement, an initiative towards something that is beyond just technology or Agile or consulting, something greater and more important to us as a society. I've never been around so many different people who've all been so passionate and so accepting and so different - it's quite wonderful. I think about all those conversations I had about omg should I become a paralegal or a business analyst for this crazy company just a few months ago, and now I finally, finally know I made the right decision.

These past six weeks have also taught me a lot about others - maybe a little too much, but these things are important to understand. It's also taught me a lot about myself. What I'm good at, what I'm not. What I should strive towards and be grateful for. What is decency, what is motivation, what is humility and acceptance.

The Angels Orphanage website is now live. We still have to fix a bunch of CSS and content details, but the gist of it is there: http://orphanage.heroku.com/home

I'm so excited to come home. And I am deeply sad to leave. It's been a wonderful experience here, one that I will never forget in my years to come.

Thanks for reading this blog. If you'd like to know the URL to my other one, just ask.

• Stevey's Blog Rants: Wikileaks To Leak 5000 Open Source Java Projects With All That Private/Final Bullshit Removed
• Other Android Languages
  android python

As I’ve covered in several blog posts, I visited the Emerging Languages camp last week. It was an interesting experience for many reasons, and some of my conclusions are still half formed. I wanted to talk a little bit about some common themes in several languages presented at this camp, and also what the trends are leaning towards. Now, I’m not entirely sure what my insights will be yet, but hopefully I’ll know as I approach the end of this blog post.

There are several different axises you can divide the presented - about 26 - languages. The first one is in terms of age and maturity. The oldest language presented was probably Parrot, Frink, Io, Factor and D - who have all been around for eight to ten years. All of these languages are very mature and you wouldn’t hesitate to use them for real life work. The second category are the languages that range from a few years in age to quite new ones. Most of these languages are still evolving, still not stable, but definitely on the path to getting there. The final set of languages are the most interesting in my view - the new ideas that have just started germinating, or even concepts that aren’t actually there yet. From my list of interesting things, Wheeler is definitely a language in that category.

But you can also look at the types and features you find in the new languages (and I will exclude the oldest group of languages when talking about these features and ideas). There is a large group of languages that are evolutionary rather than revolutionary. This is fine, of course. Many of these languages take much inspiration from Ruby and Smalltalk. Object orientation is extremely common among these languages, several of them prototype based. There was also several languages with indentation based syntax. I was surprised about the amount of languages that target native instead of a virtual machine. AmbientTalk, Clojure, Ioke/Seph, Frink and Mirah targets the JVM, Stratified JavaScript, E/Caja and CoffeeScript targets JavaScript and F# targets the CLR. All the other languages can be considered native. I was quite surprised about this - anyone got a good explanation?

There are also several graphical languages presented. These are harder to categorize from a traditional paradigm perspective. Thyrd is more of a proof of concept, very graphical, but backed by a stack language in the style of Forth. Kodu seems to have a quite traditional backend, but the graphical interface hides that in most cases. Both of these languages are optimized to run in situations where you don’t always have a keyboard - Thyrd for tablet PCs and Kodu for the XBox. Subtext/Coherence is based around non-syntactic thinking, but didn’t seem to have a graphical interface either at this point.

As mentioned above, the trend of using JavaScript as a target language also seems to be on the way up - both CoffeeScript, Caja, and Stratified JavaScript follows that approach. Parts of Ur/Web are also compiled to JavaScript to allow the based language to describe behavior in both the server and the client. Gilad reported that he was very interested in getting Newspeak to run on JavaScript too, and there has been a lot of talk about getting Io to work on that platform too. This seems to be an interesting idea for many languages, and the benefits of compiling to a language that can run in any browser is definitely compelling. However, there seems to be a lot of problems with that approach too. Some people create a bytecode machine in JavaScript that then executes generated bytecodes. Some languages have to do lifting of functions because of bugs in several JavaScript implementations. And of course, the JavaScript language doesn’t give you good ways of generating code that is easy to debug.

The low level languages all seem to give interesting capabilities. D is what C++ should have been. BitC allow you to write programs with strong guarantees. ooc gives many of the high level benefits to a low level language. Go makes it possible to handle concurrency in an easy and powerful way.

I’m at the end of my thoughts right now, and there is no grand conclusion to be found. Just some interesting observations. Maybe they are indicative of the future in language development, and maybe not.

The release of 1.0 EAP has been getting great responses. In less than 10 days, it got 866 downloads and 11 ratings with an average of 4.5 stars. So here is the 1.0 release.
Changes
+ calibration so that it can work with different ambient sensors on different phones.
+ be able to remember settings
Two help related features pushed to 1.01
Enjoy.

I’ve just come back from three days in Santa Clara, spending time with some of the brightest people in the Java world - the JVM language summit is truly a fantastic collection of great people. And I was there too…

THe goal of the JVM language summit is to collect the people who work with languages on the JVM and have them share their projects, their experiences and their networks - and let them network with the people in charge of implementing the JVM’s for different companies. This year, a lot of discussion about JSR 292 and project lambda was on the plate. The presence of hardware and VM people was also more pronounced. I counted principals for at least six different virtual machines in the audience or presenting (Hotspot, JRockit, J9, Azul, Maxine, and Monty).

Among the experienced platform and language people there, some of the notables included Kresten Krab Thorup, Joshua Bloch, Bob Lee, Neal Gafter, John Rose, Brian Goetz, Alex Buckley, Rich Hickey, Charles Nutter, Cliff Click, Doug Lea, Per Bothner and many more. A great collection of people.

As an example of the funny happenstance that can happen in this collection of people, I was sitting rebinding my Java implementations for Mac OS X - and I had remove lots of links in /usr/bin. A few minutes later the person next to me started asking some questions about my experience with Java on the Mac - and it turns out he’s the manager for the Apple JVM team. Or at one point Rich Hickey reported on a quite puzzling problem that causes bad semantics when iterating over data that doesn’t fit in memory - and Cliff Click immediately opens up his laptop, says “give me an half hour and I’ll see what I can do”.

Another funny anecdote was when Doug Lea pointed out that if you use fibonacci to test performance against yourself or others, it’s important that the implementations actually agrees about the first values of fib. Funnily enough, I saw three different implementations of the ground rule in fib during the summit - all of them different. (if n < 2 return 1, if n<=2 return n, if n < 2 return n).

There were way too many interesting presentations and discussions for me to be able to talk about all of them - instead I just wanted to give some highlights.

Charles Nutter

Charles gave a quick introduction to JRuby and Mirah, and what kind of optimizations JRuby is currently doing. He also talked about how far he’s gotten in inlining invoke dynamic calls inside of JRuby (and he’s gotten very far - it’s really cool).

Fredrik Öhrström

Fredrik is the JRockit representative on JSR 292, and way too smart. He presented a solution to how you can use method handles integrated with function types to solve many of the current problems in project lambda. A very powerful and interesting presentation.

Doug Lea

Doug spent his keynote trying (quite successfully) to concinve the room of the hegemony of fork-join as a good solution to concurrency problems. A very good and thought provoking keynote.

Josh Bloch

Last year at the JVM language summit, Josh talked about what he called “the Semantic Gap”. This year, after being beat up by some linguists, he changed the name of this concept to “Performance Anxiety”. The basic idea is that in our current infrastructure we have traded performance for predictability. Two examples from his talk about when this happens in Java was pretty interesting. He had one benchmark that consistently showed about the same numbers for the same JVM run, but differed between JVM runs. There was no undeterminism in the benchmark itself, but they benchmark times continued to oscillate between 0.7 and 0.85 depending on JVM run. Cliff Clicks explanation for this is that it is probably the compilation planner, which is a separate thread. Depending on when that thread runs the compilation strategy will be different, and makes a difference in times. And it’s really hard for the programmer to take this difference into account.

The other example is simpler (and don’y change your code because of this). In some circumstances it turns out that & is faster than && in Java, because a && will short curcuit, which means it will branch. The single ampersand will always execute both sides, which means the CPU can pipeline both of them to execute at the same time.

All the examples he shown comes down to the same thing - we can’t really reason intuitively about the performance of our language constructs anymore. Our systems have become to complex in order to support better performance, and we give up predictability to get that performance. And at the end of the day it doesn’t even matter if you go down to C or assembler - you still cannot control exactly what the CPU is doing anymore.

Kresten Krab Thorup

Kresten is the CTO of Trifork, and one of the main organizers of many of my favorite conferences (like JAOO and QCon). The last nine months he has worked on an Erlang implementation for Java, which he talked about. It seems to be a very good implementation, and he’s getting surprisingly good performance and context switching numbers. In fact, several of the ideas in Seph will be stolen from Erjang.

Rémi Forax

Rémi showed off his PHP.reboot project, implemented using JSR 292 and getting quite good performance. His JSR 292 backport seems to be really useful and I think I’ll use that to make sure Seph can run on pre Java 7 machines. Good stuff.

Rich Hickey

Rich spent some time collecting comments from people in the room of what was problematic with the JVM in its current incarnation. To start us off, he showed one piece of hilarious/horrible Clojure code. Any one wants to guess what it does?

static public Object ret1(Object ret, Object nil) {
    return ret;
}

public static int count(Object o){
    if(o instanceof Counted)
        return ((Counted) o).count();
    return countFrom(Util.ret1(o, o = null));
}

We then went on to a few other things (which you can find on the JVM Language Summit wiki). The consensus seemed to be that tail calls is really very important. Last year, it wasn’t as crucial but now that we see how powerful method handles and lambda will be, tail calls turn out to be very nice to have. Hopefully we can make that happen.

JSR 292

The JSR 292 expert group got lots of chances to work on ideas and designs for the future. Lots of interesting results came out of these discussions. Some of the more notable ones are skisses on how method handles and function types can work together, how invoke dynamic and bootstrap method can be used to implement defender methods and several other interesting ideas.

All in all it has been a fun few days, going far out in language and implementation geekiness. I hope to come back to this next year.

Software Product is a bunch of functionality assembled together and tied within the boundary of business rules. Each line of code which is written to implement a functionality has a potential bug in them. And each valid bug raised requires a change in the code written.

Are these forming a vicious circle ? Let me explain.

In a typical agile methodology, we write the Unit Tests first and then the actual functionality. So that means we actually know how the system would be tested (to some extent). But after writing the functionality, the developer calls a fellow tester to do a Dev Box Testing. Dev Box Testing is generally done on a developer’s machine with a very minimal set of test data (Thanks to developers laziness ! :)). It’s done to ensure that the intended functionality is properly developed and there are no major bugs. It also gives developer the chance to debug the application in case of any exception (if encountered). So till now we have done Unit Testing and Dev Box Testing. What next? Post the developer check in, the application is generally deployed in a Test Environment for a further round of testing. This testing is intensive and is iterated over a large set of sampled data. This kind of full fledged testing often results in uncovering of many bugs.

So we are still left with bugs even after Unit Testing –> Dev Box Testing. So if we see the whole process process,

We write code –> We induce bug –> We find bug -> We write code to fix bug –> We induce bug –> …

I have something to confess:  I’m an information addicted. I’m always reading books, checking out news, following a few hundred blogs, following another few hundred people on twitter and the list just goes on and on. I bet you do the same.

First of all, this is not about how to just pass over your next university exams but how to keep yourself updated or learn something with all the information we are throw everyday. It’s not possible (for me at least) to keep track from everything I read. People like me reads hundreds of information sources, mostly online. Besides that we also read books, attend conferences, meet new people, etc. We are literally bloated by information from everywhere.

how can we manage to digest this huge amount of information we face everyday ?

We all know there’s no unique answer for that question. Everybody has a different approach when it comes to learn something. Some people prefer to take notes while reading, some people prefer to record audio snippets, some people like to create songs that resemble the information, (your method here). As you might think, I happen to have my own technique (probably not only mine) and it’s being very useful to me.

I read somewhere else a good analogy: we have two “databases” in our brain. One is the short-term memory database and the other is the long-term one.  When we read something, every piece of information goes to our short-term memory which is something like a “heap” of unclassified information . As this “database” isn’t classified, our brain doesn’t know if the information is useful or not.  Later on, it can be even 10 minutes, when we try to recall some information from it, we may not be able to easily do it because isn’t classified yet. But no worries : how many times happened to you that you remembered something just a few hours later while doing something else? That happens because our searching process is asynchronous.

Ok, our information searching process is asynchronous, so what ? It literally means, your brain is still learning some subject even after you stopped thinking about it. It’s like dispatching a background process. The problem is you need to constantly remember that subject in order to transfer it to your long-term memory.

You can achieve that by keeping a sort of learning log. I’ve tried many tools to help me keeping track of what I want to learn. For instance, a simple text editor, an iphone app. You just need to ensure you have quick and easy access to it….As I’m a very moody person I keep changing, right now, for instance, I’m using a folder of my browser’s favorites bar which I sync across my computers. Sometimes I also use the favorites features from twitter. As I’m always checking them, I keep remembering the subjects I have demonstrated interest. Most of this links are shortcuts to blog posts, interviews, podcasts, which I may have read/listened only once. But just the fact I’m recalling the title, it helps me to internally recall the content I read before from that source. In case I don’t remember what’s the content is about I just go there and skim over the text so I get the general idea. If even doing so, I don’t understand the content, then I mark it to read it later using a javascript snippet.

What happens when my learning log stack is getting excessively big ? Just use your common sense! If you get to the point where you always need to recall every item in your list, something is wrong! So, how many items should you have in your list? It may vary from person to person. In my case I found 10 to be a good size. It doesn’t mean I need to first learn all 10 items and them move to the next 10 items. Some items can be in your list for a relatively long time, it’s strongly dependent on how complex is the subject and how fast you can learn.

Defining when you “learned” something is very subjective. In my opinion, you can’t know everything. My “learned” definition is when I get to the point where I can explain the subject to someone else and they properly understand it. Having a time constraint can help too, like imposing yourself a 15 days limit for the items in your list.

Resources used:

• Learning log (official way) http://www.csudh.edu/titlev/learninglog.htm
• Read it later http://readitlaterlist.com/

Probably Related posts:

1. RELEASED – “Rails 2.1 – What`s new ?” Book
2. Why I have been away
3. Google Summer of Code

I've been on tour in South East Asia for the last few days and it's been great fun, I must confess. For those who may have waited for an article and didn't see it on time, I apologise - and I'll try...

A one stop shop for Sumeet Moghe's thoughts about learning in the modern enterprise.

Luiza Pagliari and I, Paulo Caroli, gave a talk on the history of Continuous Integration (CI) and CruiseControl at the 2010 FISL conference (International Free Software Forum).

We talked to Martin Fowler and other colleagues at Thoughtworks and to gather (and validate) data on CI and CruiSeControl history. Below is short presentation with this data.

Continuous Integration and CruiseControl history


Please contact me if you are interested in the CI history topic and blog about it. I will add your links to this blog post.

I’m currently in the process of implementing Seph, and I’ve reached an inflection point. This point is the last responsible moment to choose what I will target with my language. Seph will definitely be a JVM language, but after that there is a range of options - some quite unlikely, some more likely. The valid choices are:

• Target Java 1.4
• Target Java 5/6
• Target Java 7
• Target Java 7 with extensions

Of these, the first options isn’t really interesting for Seph, so I’ll strike it out right now. The other three choices are however still definitely possible - and good choices. I thought I might talk a little bit about why I would choose each one of them. I haven’t made a final decision yet, so that will have to be the caveat for this post.

Before talking about the different choices, I wanted to mention a few things about Seph that matters to this decision. The first one is that I want Seph to be useful in the real world. That means it should be reasonably fast, and runnable for people without too much friction. I want the implementation to be small and clean, and hopefully as DRY as possible - if I end up with both and interpreter and just-in-time compiler, I want to be able to share as much of these implementations as possible.

Java 5/6

The easiest way to go forward would be to only use Java 5 or 6. This would mean no extranice features, but it would also mean the barrier to entry would be very low. It would mean development on Seph would be much easier and wouldd in general make everything simpler for everyone. The problem with it would mainly be implementation complexity and speed, which would both suffer compared to any of the Java 7 variants.

Java 7

There are many good reasons to go with Java 7, but there are also some horrible consequences of doing this. For Seph, the things that would make things from Java 7 is method handles, invoke dynamic and defender methods. Other things would be nice, but the three previous ones are the killer features for Seph. Method handles make it possible to write much more succinct code, not generate lots of extra classes for each built in method, and many other things. It also becomes possible to refer to compiled code using method handles, so the connection between the JIT and the interpreter would be much nicer to represent.

Invoke dynamic is quite obvious - it would allow me to do much nicer compilation to bytecode, and much faster. However, I could still build the same thing myself, to much greater cost and it would also mean inlining wouldn’t be as easy to get.

Finally, defender methods is a feature of the new lambda proposal that allow you to add new methods to interfaces without breaking backwards compatibility. The way this works is that when you add a new method to an interface, you can specify a static method that should be called when that interface method is invoked and there are no other implementations on the concrete classes for a specific object. But the interesting side effect of this feature is that you can also use it to specify default implementations for the core language methods without depending on a shared base class. This will make the implementation much smaller and more flexible, and might also be useful to specify required and optional methods in an API.

The main problem with Java 7 is that it doesn’t exist yet, and the time schedule is uncertain. It is not entirely certain exactly what the design of the things will look like either - so it’s definitely a moving target. Finally, it will make it very hard for people to help out on the project, and also it won’t make Seph a possible language for people to use until they upgrade to Java 7.

Java 7 with extensions

It turns out that the interesting features coming in Java 7 is just the tip of the iceberg. There are many other proposed features, with partial implementations in the DaVinci project (MLVM). These features aren’t actually complete, but one way of forcing them to become more complete is to actually use them for something real and give lots of feedback on the feature. Some of the more interesting features:

Interface injection

This feature will allow you to say after the fact that a specific class implements an interface, and also specify implementations for the methods on that interface. This is very powerful and would be extremely helpful in certain parts of the language implementation - especially when doing integration with Java. The patch is currently not very complete, though.

Tail calls

Allowing the JVM to perform proper tail calls would make it much easier to implement many recursive functional algorithms easily. Since Seph will have proper tail calls in the language, this will mean that I will have to implement this myself if the JVM doesn’t do it, which means Seph will be slower based on this. The patch seems to be quite good and possible to merge and harden to the JDK at some point. Of all the things on this list, this seems to be one of things that we can actually envision see being added in the Java 7 or Java 8 time frame.

Coroutines/continuations

Both coroutines and continuations seem to be possible to do in a good way, at least partially. Coroutines might be interesting for Seph as an alternative to Kilim, but right now it seems to be a bit unstable. Continuations would allow me to expose continuations as a first class citizen which is never bad - but it wouldn’t give me much more than that.

Hotswapping

Hotswapping of code would make it possible to do agressive JITting and then backing out from that when guards fail and so on. This is less interesting when we have invoke dynamic, but will give some more flexibility in terms of code generation.

Fixnums, tuples, value types

We all want ways of making numbers faster - but these features might also make it possible to efficiently represent simple composite data structures, and also things like multiple return values. These are fairly simple features, but have no real patch right now (I think).

Light weight code loading (anonymous classes)

It is horrible to load byte code at runtime in Java at this point. The reason is that to be able to make sure your loaded code gets garbage collected, you will have to load each chunk of code in a new class in a new classloader. This becomes very expensive very fast, and also endangers permgen. Anonymous classes make this go away, since they don’t have names. This means you don’t actually have to keep a reference to older classes, since there is no way to get to them again if you lost the reference to them. This is a good thing, and makes it possible to not generate class loaders every time you load new code. THe state of this seems to be quite stable, but at this point JVM dependent.

The price

Of course, all of these lovely features comes with a price. Two prices in fact. The first price is that all the above features are incomplete, ranging from working patches to proof of concepts or sketches of ideas. That means that the ground will change under any language using it - which introduces hard version dependencies and complicates building. The other price is that none of these features are part of anything that has been released, and there are no guarantees that it will ever be merged in Java at any point. So the only viable way of distributing Seph would be to distribute standard build files with a patched OpenJDK so that anyone can download and use that specific JDK. But that limits interoperability and causes lots of other problems.

Somewhere in between

My current thinking is that all of the above choices are bad. For Seph I want something inbetween, and my current best approach looks like this. You will need a new build of MLVM with invoke dynamic and method handles to develop and compile Seph. I will utilize invoke dynamic and method handles in the implementation, and allow people to use Rémi Forax’ JSR 292 backport to run it on Java 5 and 6. When Java 7 finally arrives, Seph will be more or less ready for it - and Seph can get some of the performance and maintainability benefits of using JSR 292 immediately. At this point I can’t actually use defender methods, but if anyone is clever enough to figure out a backport that will allow defender methods to work on Java 5 or 6, I would definitely use them all over the place.

This doesn’t actually preclude the possibility of creating alternative research versions of Seph that uses some of the other MLVM patches. Charles Nutter have shown how much you can do by using flags to add features that are turned off by default. So Seph could definitely grow the above features, but currently I won’t make the core of the language depend on them.

• nottingham-http-cache-channels-01.txt (tags: cache squid http ietf)
• mnot’s Weblog: Cache Channels (tags: cache squid http)

.. to http://www.akshaydhavle.com/blog alongwith all posts and comments..

See you there! And sorry for the inconvenience.

Following the recommendations of Corey Haines, Michael Guterl, James Martin and Michael Hunger I decided to get Kent Beck's screencasts on Test Driven Development which have been published by the Pragmatic Programmers.

I read Kent's 'Test Driven Development By Example' book a couple of years ago and remember enjoying that so I was intrigued as to what it would be like to see some of those ideas put into practice in real time.

As I expected a lot of Kent's approach wasn't that surprising to me but there were a few things which stood out:

• Kent wrote the code inside the first test and didn't pull that out into its own class until the first test case was working. I've only used this approach in coding dojos when we followed Keith Braithwaite's 'TDD as if you meant it' idea. Kent wasn't as stringent about writing all the code inside the test though – he only did this when he was getting started with the problem.

  The goal seemed to be to keep the feedback loop as tight as possible and this was approach was the easiest way to achieve that when starting out.

• He reminded me of the 'calling the shots' technique when test driving a piece of code. We should predict what's going to happen when we run the test rather than just blindly running it. Kent pointed out that this is a good way for us to learn something – if the test doesn't fail/pass the way that we expect it to then we have a gap in our understanding of how the code works. We can then do something about closing that gap.
• I was quite surprised that Kent copied and pasted part of an existing test almost every time he created a new one – I thought that was just something that we did because we're immensely lazy!

  I'm still unsure about this practice because although Ian Cartwright points out the dangers of doing this it does seem to make for better pairing sessions. The navigator doesn't have to wait twiddling their thumbs while their pair types out what is probably a fairly similar test to one of the others in the same file. Having said that it could be argued that if your tests are that similar then perhaps there's a better way to write them.

  For me the main benefit of not copy/pasting is that it puts us in a mindset where we have to think about the next test that we're going to write. I got the impression that Kent was doing that anyway so it's probably not such a big deal.

• Kent used the 'present tense' in his test names rather than prefixing each test with 'should'. This is an approach I came across when working with Raph at the end of last year.

  To use Esko Luontola's lingo I think the tests follow the specification style as each of them seems to describe a particular behaviour for part of the API.

  I found it interesting that he includes the method name as part of the test name. For some reason I've tried to avoid doing this and often end up with really verbose test names when a more concise name with the method name included would have been way more readable.

  A couple of examples are 'getRetrievesWhatWasPut' and 'getReturnsNullIfKeyNotFound' which both describe the intent of their test clearly and concisely. The code and tests are available to download from the Prag Prog website.

• One thing which I don't think I quite yet grasp is something Kent pointed out in his summary at the end of the 4th screencast. To paraphrase, he suggested that the order in which we write our tests/code can have quite a big impact on the way that the code evolves.

  He described the following algorithm to help find the best order:

  • Write some code
    • erase it
    • write it in a different order

  And repeat.

  I'm not sure if Kent intended for that cycle to be followed just when practicing or if it's something he'd do with real code too. An interesting idea either way and since I haven't ever used that technique I'm intrigued as to how it would impact the way code evolved.

• There were also a few good reminders across all the episodes:
  • Don't parameterise code until you actually need to.
  • Follow the Test – Code – Cleanup cycle.
  • Keep a list of tests to write and cross them off as you go.

Overall it was an interesting series of videos to watch and there were certainly some good reminders and ideas for doing TDD more effectively.

One of the other neat ideas I was reminded of when watching Kent Beck's TDD screencasts is the value of 'calling your shots' i.e. writing a test and then saying what's going to happen when you run that test.

It reminds me of an exercise we used to do in tennis training when I was younger.

The coach would feed the ball to you and just before you hit it you had to say exactly where on the court you were going to place it – cross court/down the line and short/deep.

The point of this exercise is that it's relatively easy to just hit the ball over the net but to have control over exactly where the ball's going to go is way more powerful albeit more difficult.

This applies to TDD as well – it's easy to write a failing test but much more useful to write a failing test which fails in exactly the way that we expect it to.

I've written previously about the value of commentating when pair programming and calling your shots is a really easy way of keeping the conversation flowing in a pair.

I like to ask not only how a test is going to fail but why it's going to fail in that way. I think it's a pretty good way of making sure that you as a pair understand exactly what you're doing. It also slows the pace just enough that you're not coding without thinking about what you're doing.

I quite like Bryan Liles' take on this which he described in a talk at acts_as_conference 2009. Bryan suggests that we first write a test and then either make it green or change the error message that you're getting.

We should know whether or not the test is going to go green or the error message is going to change before we run the test and the idea is that we want to either get the test to pass in one go or at least get a step closer to a passing test.

I’ve been dropping a few hints and mentions the last few weeks, and I thought it was about time that I took some time to preannounce a new project I’m working on. It’s going to be much easier writing my next few blog posts if people already know about the project, and my reasons for keeping quiet about it have mostly disappeared. It’s also a moot point since I talked about it at the Emerging Languages camp last week, and the video will be up fairly soon. And I already put the slides online for it, so some things you might have already seen.

So without further ado, the big announcement is that I’m working on a new language called Seph. Big whoop.

Why?

I already have Ioke and JRuby to care for, so it’s a very valid question to ask why I would want to take on another language project - outside my day job of course. The answer is a bit complicated. I always knew and communicated clearly that Ioke was an experiment in all senses of the word. This means my hope was that some of the quirky features of Ioke would influence other languages. But the other side of it is that if Ioke seems good enough as an idea, there might be value in expanding and refining the concept to make something that can be used in the real world. And that is what Seph is really about. That blog post I wrote a few weeks ago with the Ioke retrospective - that was really a partial design document for Seph.

So the purpose of Seph is to take Ioke into the real world while retaining enough of what made Ioke a very nice language to work with. Of course, being the person I am, I can’t actually avoid doing some new experimentation in Seph, but they will be mostly a bit safer than the ones in Ioke, and some of the craziest Ioke features have been scaled back a bit.

Some features

So what’s the difference? Seph will still be prototype based object oriented, in the same way as Ioke. It will definitely consider the JVM its home. It will be homoiconic, and allow AST manipulation as a first class concept - including working with message chains as a way of replacing blocks. It will still have a numerical tower. It will use almost exactly the same syntax as Ioke. It will still allow you to customize operators and precedence rules.

The big difference. The one that basically makes most all other design changes design themselves is a small but very important difference: objects are immutable. The only way you can create new objects is by creating a new object that specifies the difference. This can be done either by creating a new child of the existing object, or creating a new sibling with the specified attributes changed. In most cases, the difference between the strategies isn’t actually visible, so it might be an implementation strategy.

Now once you have immutable objects but still focus on polymorphic dispatch, that changes quite a lot of things. It changes the core data structures, it changes the way macros work, it changes the flow of data in general. It also changes what kinds of optimizations will be possible.

Another side effect of immutability is that is becomes much more important to have a good module story. Seph will have first class modules that ends up still being simple Seph objects at the same time. It’s really a quite beautiful and simple scheme, and it makes total sense.

If you’re creating a new Object Oriented language, it turns out that proper tail calls is a good idea if you can do it (refer to Steele for more arguments). Seph will include proper TCO for all Seph code and all participating Java code - which means you’ll only really grow the stack when passing Java boundaries. This will currently be done with trampolining, but I deem the cost worth the benefit of a tail recursive programming style.

I mentioned above that objects are immutable. However, local variables will be mutable. It will also be possible to create lexical closures. I’m still undecided whether it’s a good idea to leave a big mutable hole in the tyoe system, or whether I should make it impossible for lexical closures to mutate their captured environment. Time will tell what I decide.

Stealing is good

Seph believes in reusing concepts other people have already made a great job with. As such, many pieces of the language implementation will be stolen from other places.

Just like in Ioke, the core numbers will come from gnu.math. This library has served me well, and I’ll definitely continue to use it. The big difference compared to Ioke is that the gnu.math values will be first class Seph object, and won’t have to be wrapped. Seph will also have real floats instead of bigdecimals. This is a concession to reality (which I don’t much like, btw).

Seph will incorporate Erlang style light weight threads with an implementation based on Kilim (just like Erjang).

As mentioned above, the core data structures will have to change. And the direction of change will be towards Clojure. Specifically, Seph will steal/has stolen Clojures persistent data structures, all the concurrency primitives and the STM. I don’t see any reason to not incorporate fantastic prior art into Seph.

As mentioned above, the module system is also not new - it’s in fact heavily inspired of Newspeak. Having no globals force this kind of thinking, but I can’t say I would have been clever enough to think of it without Gilad’s writings, though.

Basically everything else is copied from or inspired by Ioke.

Isn’t mutability the essence of Ioke?

If you have worked with Ioke, or even heard me talk about it, you might have gotten the impression that mutability is one of the core tenets of Ioke. And your impression would be correct. It wasn’t until I started thinking about what a functional object hybrid version of Ioke would look like, that I realized most of things I like in Ioke could be preserved without mutability. Most of the macros, the core evaluation model and many other pieces will be extremely similar to Ioke. And this is a good thing. I think Ioke has real benefits in terms of both power and readability - something that is not easy to combine. I want Seph to bring the same advantages.

Will you abandon Ioke now?

In one word: no. Ioke is still an experiment and there are still many things that I want to explore with Ioke. Seph will not fill the same niche, it won’t be possible for me to do the same experimentation, and fundamentally they are still quite different languages. In fact, you should expect an Ioke release hopefully within a few weeks.

So will it be useful?

Yes. That’s the whole goal. Seph will have an explicit focus on two areas that Ioke totally ignored. These areas are concurrency and performance. As seen from the features above, Seph will include several powerful concurrency features. And from a performance standpoint, Ioke was a tarpit - even if you wanted to make it run faster, there wasn’t really anything to get a handle on. Seph will be much easier to optimize, it’s got a structure that lends itself better to compilation and I expect it to be possible to get it to real world language performance. My current idea is that I should be able to get it to JRuby performance for roughly the same operations - but that might be a bit optimistic. I think it’s in the right ballpark though. Which means you should be able to use it to implement programs that actually do useful things in the Real World ™.

Is it available?

No. At the current point, Seph is still so young I’m going through lots of rewrites. I would like the core to settle down a little bit before exposing everything. (Don’t worry, everything is done in git, and the history will be available, so anyone who wants to see all my gory mistakes will have no trouble doing that). But in a nutshell, this is why this is a preannouncement. I want to get the implementation to the stage where it has some of the interesting features I’ve been talking about before making it public and releasing a first version.

Don’t worry though, it should be public quite soon. And if I’m right and this is a great language to work in - then how big of a deal is another month of waiting?

I’m very excited about this, and I hope you will be too! This is an adventure.

I've been watching Kent Beck's TDD screencasts and in the 3rd episode he reminded me of a mistake I used to make when I was first learning how to test drive code.

The mistake happens when testing collections and I would write a test which would pass even if the collection had nothing in it.

The code would look something like this:

[Test]
public void SomeTestOfACollection()
{
	var someObject = new Object();
	var aCollection = someObject.Collection;
 
	for(var anItem : aCollection)
	{
		Assert.That(anItem.Value, Is.EqualTo(...));
	}
}

If the collection returned by someObject is empty then the test will still pass because there is no assertion to deal with that situation coming up.

In Kent's example he is using an iterator rather than a collection so he creates a local 'count' variable which he increments inside the for loop and then writes an assertion outside the loop that the 'count' variable has a certain value.

In my example we can just check that the length of the collection is non zero before we iterate through it.

[Test]
public void SomeTestOfACollection()
{
	var someObject = new Object();
	var aCollection = someObject.Collection;
 
	Assert.That(aCollection.Count(), Is.GreaterThan(0));
	for(var anItem : aCollection)
	{
		Assert.That(anItem.Value, Is.EqualTo(...));
	}
}

It's a relatively simple problem to fix but it's certainly one that's caught me out before!

Just saw 'Inception' last week. Its was a superbly crafted mind game by Chris Nolan. The man is a genius. The Alfred Hitchcock of my generation! I have nothing more to add. Period.

• The worlds longest photo exposure (tags: photography longexposure pinhole)