Wednesday, January 06, 2010

Actor thinking from Kresten Krab Thorup

Kresten Krab Thorup posts a long think on objects and processes, full of great references, which I enjoy. Maybe you will, too.

Tuesday, January 05, 2010

isolate: a new tool for my toolbox

isolate is the newest tool in my toolbox. Paranoids are sometimes correct. (Found thanks to LWN.net.)

Nexus One URL almost there

What is the typical error page for a bad link into Google, say, http://www.google.com/bobsyerunkel? But for http://www.google.com/phone I get a prosaic default 404 page, perhaps in preparation for something more interesting later today.

UPDATE: Not happy! http://www.google.com/phone works now, but T-mobile is disabled as a choice. Only the unlocked phone is offered:

We're unable to sell T-Mobile service plans at this time, but you can still buy the unlocked phone.

This was my Christmas present from my wife!

UPDATE #2: I was premature. The T-mobile option now works, very nicely, too. However, it checked my existing T-mobile phone number and said family plans were not eligible. Time to confer with the wife.

UPDATE #3: Spent 20 minutes on line with T-mobile. She was courteous and did her best, but management left them unprepared for Nexus One release beyond a cursory memo. Several checks with different supervisors, still no answer on how to split family plan, add Nexus One plan for myself. There's always tomorrow.

Monday, January 04, 2010

Revisiting an old post: mixing OSGi, Scala, et al with pax

I overlooked the coolness of Brian Murphy's post the first time I ran across it: OSGi With Scala, Java, Groovy, Maven and PAX. As I am playing with OSGi, guice and peaberry, I ran across his instructions and was struck by how straight-forward pax makes everything.

My contribution to the conversation, bootstrapping a peaberry project:

$ pax-add-repository -i google-maven-repository \
    -u http://google-maven-repository.googlecode.com/svn/repository
$ pax-add-repository -i ops4j.releases \
    -u http://repository.ops4j.org/maven2
$ pax-import-bundle -g com.google.inject -a guice -v 2.0
$ pax-import-bundle -g org.ops4j -a peaberry -v 1.1.1
$ pax-create-module -a wrappers
$ cd wrappers
$ pax-wrap-jar -g aopalliance -a aopalliance -v 1.0
$ cd ..
$ pax-create-bundle -p $your_groupId -n $your_artifactId

This presumes a simple project with only one module ("$your_artifactId").

Top notch post on JDK 1.6 update 14 optimizations

A really good post on JDK 1.6 update 14 optimizations: lock coarsening, biased locking and escape analysis. Found via the Java Specialist newletter.

Wednesday, December 30, 2009

Nexus One: Buy from Google, not T-mobile

I just spoke with my friendly T-Mobile customer care specialist. She was direct and helpful. Point blank I asked to pre-order a Nexus One and sign up for the matching phone plan. As expected, she could not help me with that. But she did tell me some interesting tidbits:

  • T-mobile considers it an HTC phone, not a Google one
  • T-mobile has not yet given customer service details on the phone, but my specialist did know about it
  • T-mobile will not be selling the phone directly; she said I needed to order it from Google, not T-mobile

Anticipation is a great selling device.

Android load webby

My first Android project, AndroidLoad, is very simple. It reads /proc/loadavg every second and and updates a table with the data.

Achieving this much in a single day of browsing and code noodling, I hope to make something more interesting with it soon. So far, Android+IDEA has been a real pleasure to develop with, and I expect the IDE integration to continue improving.

Monday, December 28, 2009

Chocolate sausages: not programming

My 12-year old son sent me a delightful email:

Today, grandma and I made some chocolate sausages and they turned
out great. Here is the recipe so you and Rebecca can replicate it,
but do not attempt without me. Ingredients: 200 grams of good butter 3 tablespoons of sugar 3 tablespoons of water 2 tablespoons of cocoa 50 grams of 90% and up dark chocolate 300 grams tea biscuits 1 egg 5 tablespoons of walnuts chopped wax paper Instructions: Melt butter, cocoa, chocolate, butter, water, and sugar over low heat. Bring to a boil. Turn off heat. Let it sit for 2 minutes. Remove excess water. Mix in eggs, biscuits, and walnuts. Place 2-3 tablespoons on sheet of wax paper and roll up. Repeat until there is no more filling. Freeze for minimum of 2 hours. Enjoy!

This is my one non-serious post for the year. Follow my son's advice: enjoy!

Sunday, December 27, 2009

All I want for Christmas is a Google Phone

I made a simple Christmas wish list for my wife:

  1. A Google phone

Yep, that's it, if I can bear the delayed gratification. And then there are the naysayers, ye of little faith.

Would I be a Android developer with a Nexus One? In a heartbeat—time to get started! I've got faith.

UPDATE: Rumor has it, Nexus One by invitation only. Will code for invite!

Saturday, December 26, 2009

New Ioke release

Ola Bini announced a new release of Ioke. Why is Ioke interesting? From the home page:

 
Ioke = LanguageExperiment with(
  goal: :expressiveness, 
  data: as(code), 
  code: as(data), 
  features: [
    :dynamic, 
    :object_oriented, 
    :prototype_based, 
    :homoiconic, 
    :macros 
  ], 
  runtimes: (JVM, CLR), 
  inspirations: set(Io, Smalltalk, Ruby, Lisp)
)
 
hello = method(name, 
  "hello, #{name}!" println)
 
Ioke inspirations select(
  features include?(:object_oriented)
) each(x, hello(x name))

Saturday, December 19, 2009

Code repository

I used Google Code to setup a Subversion repository for this blog under binkley. So far there are only two items: Soapy and MagicBus. Feedback encouraged.

Thursday, December 17, 2009

Vacation: BlockingIterable

I love vacation: a chance to stretch my coding fingers free of work! Here is a code snack I thought of while daydreaming today—enjoy!

public final class BlockingIterable {
    public static <E> Until<E> over(final BlockingQueue<E> queue) {
        return new Until<E>(queue);
    }

    public static class Until<E> {
        private final BlockingQueue<E> queue;

        private Until(final BlockingQueue<E> queue) {
            this.queue = queue;
        }

        public Iterable<E> until(final E poison) {
            return new Iterable<E>() {
                @Override
                public Iterator<E> iterator() {
                    return new Iterator<E>() {
                        private E next = poison;

                        @Override
                        public boolean hasNext() {
                            try {
                                return poison != (next = queue.take());
                            } catch (final InterruptedException e) {
                                currentThread().interrupt();
                                next = poison;
                                return false;
                            }
                        }

                        @Override
                        public E next() {
                            if (poison == next)
                                throw new NoSuchElementException();
                            return next;
                        }

                        @Override
                        public void remove() {
                            throw new UnsupportedOperationException();
                        }
                    };
                }
            };
        }
    }
}

Monday, December 14, 2009

Gmail smarter than I am

I was typing a personal mail to family members and using Gmail's address completion feature to just type a few characters for each recipient when I got to filling in the message body. I looked up and saw a warning about the To: list. It asked if I really meant to mail PQT, perhaps I really meant PQR? And it was right.

Gmail recognized that I mispicked one of the recipients while using completion, and that I would prefer a relation rather than a friend for this mail. Gmail is smarter than I am.

Thursday, December 10, 2009

How to release software

The wrong way

  • Have no master plan
  • Practise nothing ahead of release day
  • Prepare only on release day
  • Build release packages on release day
  • Have dissimilar production and test environments
  • Hand edit configuration during release
  • Keep no backups of previously working configuration
  • Use trial-and-error to fix configuration

The right way

Do the opposite of everything done the wrong way. Wasn't that simple?

Some elaboration

As much as possible, clone the production environment to your test environment. Any number of weird, unexpected, troubling problems will crop up. Fix them all. Do not release if your test environment is not pristine.

Make complete release packages as early as you can, and release them to the test environment just as you would to production. Do not release if you cannot deploy smoothly.

Keep the entire test environment under release control: everything including binaries, symlinks, logs. Do not release if there are uncommitted changes; do not release if you do not understand the changes since last release.

Above all, have a plan! Discuss it with your team, assign roles and check that everyone understands what they do. Practice the release; practice rollback should something break. Obey the Scout motto: Be prepared.

Postscript

What is the penalty for the wrong way? Eight hours spent with your cell phone glued to your ear during vacation while you fix a slow-moving train wreck of a release. Your family will thank you for the right way.

UPDATE:

And in the comments:

  • Release very seldom with a big bang approach

This is very apropos. Management prefers a few large releases to smaller, more frequent releases. My opinion is that large releases look better to upper management (demonstrates you can deliver large widgets) even though it hurts in cost and quality.

Wednesday, December 02, 2009

Epic fail with agile, or winning the battle but losing the war

Dave Nicolette posts one of the most depressing but realistic outcomes of successful agile engagements: retrenchment by anti-agile forces.

I utterly hate the case studies, but I hate them precisely because they are real.

Friday, November 27, 2009

Extension methods: the case for language-level delegates in Java

Extension methods

In There's not a moment to lose!, Mark Reinhold announces something completely different: Java 7 will have closures after all. Huzzah! And in that announcement, he lists enabling language changes for them:

  • Literal syntax
  • Function types
  • Closure conversion
  • Extension methods

I want to look at extension methods closely. Alex Miller does an admirable task of summarizing JDK7 changes; that's a good place to start. And some code:

public final class Filtering {
    public static <T, C extends Collection<T>> C filterInto(
            Collection<T> input, C output, Filter<T> filter) {
        for (T item : input)
            if (filter.keep(item))
                output.add(item);

        return output;
    }

    interface Filter<T> {
        boolean keep(T element);
    }
}

Given extension methods, a coder can write:

// static imports
Collection<String> names = asList("Bob", "Nancy", "Ted");
List<String> bobNames = names.filterInto(
        new ArrayList<>(), // new diamond syntax
        #(String name) "Bob".equals(name)); // new closure syntax

And some magic means will find Filtering#filterInto(Collection, Collection, Filtering.Filter) and transform the instance method call on Collection into a static method call on Filtering. Rules for finding Filterable vary. (Did you read Alex Miller's link?)

Here is an alternative.

Delegation

I am a fan of delegates and have writen about them often: I'd like them in Java. With delegates, the magic for finding #filterInto is less magical, and more under the control of the coder, but just as clean to use:

public final class FilteringCollection<T>
        implements Collection<T>, Filtering {
    // Some literate programming sugar for the static importers
    public static <T> FilteringCollection<T> filtering(
            Collection<T> input) {
        return new FilteringCollection(input);
    }

    public FilteringCollection(final Collection<T> input) {
        this = input; // the delegation proposal
    }

    public <C extends Collection<T>> C filterInto(
            C output, Filter<T> filter) {
        for (T item : this)
            if (filter.keep(item))
                output.add(item);

        return output;
    }
}

Usage now looks like:

// static imports
FilteringCollection<String> names = filtering(asList("Bob", "Nancy", "Ted"));
List<String> bobNames = names.filterInto(
        new ArrayList<>(), // new diamond syntax
        #(String name) "Bob".equals(name)); // new closure syntax

What's the difference?

Key here is that for the coder the only difference is delegation uses a static factory method to wrap input. This is not a drawback: it is an advantage. Less magic makes Java programs easier to maintain. There is no loss here in power.

Why bother with the delegation proposal?

Would you like to write the boilerplate forwarding methods of Collection? I wouldn't! It gets even worse as you move down the inheritance tree for Collection.

Postscript

How would you move down Collection's inheritance tree any how?

Beyond any current proposals, some javac author could implement type erasure for base classes (very carefully) in context of delegation:

public final class FilteringCollection<T, D extends Collection<T>>
        implements D, Filtering {
    // Only factory/constructor changes
    public static <T, D extends Collection<T>> FilteringCollection<T>
            filtering(D input) {
        return new FilteringCollection(input);
    }

    public FilteringCollection(D input) {
        this = input;
    }
}

Because the coder need not implement the dozens of forwarding methods, neither does he need to know what they are! The compiler sets the type of D to the precise collection used in the factory/constructor, and the resulting object provides all public methods.

But this is well beyond the scope of delegation. Go code Scala, or something.

UPDATE: Food for thought on extension methods from Rémi Forax.

UPDATE #2: This just gets more interesting: in Extension methods vs. method currying, Stefan Schulz discusses the alternative of currying.

Wednesday, November 18, 2009

A future for Java after all?

One of my favorite bloggers, Alex Miller, opens today with Apparently Mark Reinhold announced that closures would be added to JDK 7 at Devoxx today.

When I realized JDK7 would have no closures, I mentally wrote Java off as a language destined to be COBOL or FORTRAN or C: important in a practical way, but not to be where my heart was. (I'm looking around; Scala is likely my next language of choice.)

And, lo! Closure—in Java! Java may remain after all the language I prefer most. What a surprising turn.

UPDATE: Stephen Colebourne posts more details.

Thursday, November 12, 2009

Frankie says, don't do it (but does anyway)

Aleksander Kmetec explains Acme::Dont implemented in Scala.

Is it scarier that I can follow along, or that I recognize the Perl don't pragma? (Naturally Damian Conway is to blame.) Funny I ran across this post while reading Bytecodes meet Combinator: invokedynamic on the JVM.

Wednesday, November 11, 2009

How are your algorithms?

A fabulous post by Peteris Krumins summarizing MIT's Introduction to Algorithms lectures. It's like having a little Knuth in your browser.

A new programming language: Go

Time to brush up my resume and add a new programming language: Go, say 3 years experience?

I chuckle as I type this, but I have interviewed candidates for my present employer with an equally tenuous grasp on Java at variance with their resumes.

Thursday, October 15, 2009

More mana from the Czech lands: IntelliJ IDEA open-sourced

Take THAT, Eclipse!

UPDATE: This announcement is so popular, the JetBrains site is down. Never seen that before.

Tuesday, October 06, 2009

Surprisingly, there really is more to life than programming

Since I started this blog I have stuck consistently to programming topics. But I feel like posting a touch more broadly. Here are some of my favorite links:

And when I'm not browsing the Internet, I write classical music, cook freestyle, and thoroughly enjoy Rebecca, Greg and Ben.