Saturday, November 21, 2009

declaring and initializing an array in java

array initialization in java
array initialization in java Originally uploaded by rocannon1980

Yesterday I had a little adventure in coding when trying to initialize and declare a Java array "on the fly", so to speak. The problem is illustrated by the screenshot; here's the code:

public class TestMe {
  public static void main(String[] args) {
    HashMap<String, String[]> hm = new HashMap<String, String[]>();
    // Declare and initialize array. This is legal.
    String[] test1 = {"x", "y"};
    // Another way to declare and initialize this array, also legal.
    String[] test2 = new String[]{"x", "y"};
    // why doesn't this work??? Causes syntax error.
    hm.put("x", {"x", "y"});
    // This *does* work - use of "new" operator
    hm.put("x", new String[]{"x", "y"});
  }
}

The line which produces a syntax error in this code is hm.put("x", {"x", "y"});. The syntax error reads:
Multiple markers at this line
  - Syntax error on token "}", delete this token
  - Syntax error on token "{", delete this token
  - The method put(String, String[]) in the type HashMap is not applicable for the arguments (String, String, String)


Here, the compiler did not take the use of curly braces to be the shortcut syntax for declaring and an initializing the array.

I had started out by using the shortcut syntax, and when I saw the compiler error I thought I was losing it. It took some stumbling around to figure out that I could use the new operator to get the compiler to understand what I meant. Strange!

I can't imagine this kind of question would ever come up on an interview, but you never know. I hope that I'll remember it from now on; it's the kind of thing that's easy to forget.

Saturday, November 14, 2009

why is obsessive better than well-rounded?

Trick question: it's not.

I recently saw another editorial by someone who thinks good software developers should always have at least one side project going (won't link, there are plenty of articles like this around). If you're not involved in an open source project, or playing around with a new language, or developing your own little application, you just can't be up to snuff.

This seems to be a popular criterion. When I was interviewed for my current job, I was asked if I ever coded outside of work. I said that I did, although I freely admitted that my little projects rarely went anywhere - and they never turned into full-blown applications that were in use by anyone.

I did not mention that I tend to spend a lot more time experimenting with new projects when I'm unemployed...

I suppose for some small population of developers, coding night and day is fine. But it's ridiculous to suggest that these are the only people who should be coding, or that they're the only ones who are any good.

Many good developers have broad interests, hobbies, or even families *gasp*! They are very productive without coding all the time. Aside from that, software development is not a healthy activity in the long term (unless you're lucky enough to work with a Treadputer). Sitting in one spot, staring fixedly at a monitor for hours at a time is bad for you. Why does the "elite" development community laud people who do this, and point the finger of shame at people who do not?

I've known some developers who had their own little side projects. This was never a distinguishing marker of whether they were any good at coding, or whether they were even good to work with. Some were good, some were bad, some were a giant pain.

So in general, personally, I don't consider it admirable to be a constant coder, and I try not to get into that rut, although there's certainly a lot of pressure to do so.

Unfortunately, I have very little interest in the work I do on the job right now. There are a bunch of other development tasks with which I'd prefer to be experimenting. If I want to do anything about that, either I have to work on my own time, or sneak in time during the work day. I'm trying to do both.

This evening I sat down and started on a coding project that has intrigued me for a little while now. Took me an hour to do the installation and configuration work. That succeeded in dulling my enthusiasm, and I wonder if I'll continue work on it... It's one of the reasons I generally get nowhere with my side projects.

Friday, November 13, 2009

do you really want to wait your life away?

Recently I heard one of my chatty cubicle neighbors complaining about how long it was taking for some computer related task to finish - he was falling asleep just waiting.

It's the nature of working with computers that sometimes a job involves a long wait. I can't stand waiting. I get impatient if something takes more than just a few seconds, let alone minutes. It might be tempting to surf the internet while waiting, but given that most companies track your internet access these days, I rarely do this[1]. So here's what I do to avoid waiting.

If it looks like a task is going to take a long time, I try to make sure that I can't narrow it down to something which will run much more quickly. If I'm debugging a problem that occurs during a long-running process, I'll try to get the problem to occur during a simplified process that takes as little time as possible.

If there's no way around it, and I have to deal with a long-running process, I multitask. "Luckily" I usually have a healthy queue of things that need to be done. And usually there are a few items on that queue that don't require a lot of focus, and can be done in a fairly short amount of time. When I'm slowed down, I open a second instance of my IDE to work on one of those tasks.

I don't enjoy multitasking, and it is an oft-quoted observation that context switching is expensive. But if you have to wait for something, and you're staring at the screen with toothpicks propping up your eyelids, you're context switching anyway. Instead of just napping while I wait, I'd rather use the time to do something productive (whether my job entails doing things that are ultimately productive is a whole other can of worms).

[1] The truth is, I've seen coworkers surfing the net frequently, and I doubt there's any heavy-handed policy against it. But for some reason, it still goes against the grain, so I just don't do it.