Tuesday, January 29, 2008

Erlang fast :)

I want to write about this right now cause it gets kind of lost on me, so I want to be able to refer back to it. Why is Erlang so fast? Imagine you write a Java program that spawns two threads, and you run said program on a multi-core machine. Pretend both threads have a reference to the same Integer (of the proper Object sort), and at every moment of each thread's existence they are going to increase the value of that Integer by one over and over. Each time each thread attempts to increase the value of the Integer it must perform a check/lock/update/unlock to make sure it can access and update the memory that the Integer refers to. That check/lock/update/unlock slows your program down. On a single core system, the check/lock/update/unlock isn't necessary since only one thread is running at a time, but on multi-core machines threads run concurrently, so the check is necessary. In Erlang you can't update variables. Variables can be given a value once and only once, and since you can't change the value, that check isn't necessary, and that's why Erlang is faster.

I guess this begs the question: how would you write the same program in Erlang? Well in my Programming Erlang book they are very careful to explain that Erlang doesn't have threads, it has processes, and the difference is that threads share information (the Integer in the example given), and processes don't (well, you can pass processes the same variable, but they can't update it, so I guess that's the same thing). So, I guess you'd go about solving the problem in an entirely different manner. I am new to Erlang, so I don't feel comfortable giving a definitive answer, but it seems to me, that you'd simply have to solve problems with a different approach than you would in Java... not drastically different, but different, nonetheless... maybe, one process spawns two processes that return the message "1" every moment which is added to the parent processes' message queue (all processes in Erlang have message queues), which it iterates through to accumulate values. That sounds good to me :) Maybe I'll write both programs this weekend and see which one can get to Integer.MAX_VALUE the fastest.

Sunday, January 27, 2008

Keynesian beauty contest

I had not hear of this before. I like it :)

iTunes :(

I have an album at work that I bought on iTunes that I really want to listen to at home. I want to listen to it so badly that I actually bought the album again from home. iTunes really ought to let us download music we've already purchased. I understand that bandwidth isn't free, so I'd be totally willing to spend 99 cents to download it again, but I shouldn't have to pay $9.99 to buy the whole album. Yeah maybe I should be more patient and save myself ten bucks, but I don't wanna!

keeping music collections synchronized is a pain in the ass :(

Wednesday, January 23, 2008

Web Frameworks

Yesterday it was overcast and I was in a bad mood. I wanted to write an angry rant about how one MUST justify their use of anything but Ruby on Rails or Grails (or, I'm told, Django) when building websites, but I held off, and I'm glad, because when one gets up on a soapbox, they usually end up looking like a fool. However, today I'm in a good mood, and I still feel the same way. I read this today. I haven't used Django, but I've heard great things.

Why do I feel one MUST justify their use of anything but RoR, Grails (or, I'm told, Django)? The reason why is just plain ol'experience. I am currently knee deep in a straight up Java project, using Spring MVC. I think Spring MVC is great (Grails is built on it after all), but every time we encounter a problem, right there in the back of my head is a little voice saying, "why oh why didn't we use Grails (or Rails, or, I'm told, Django)?" At work when I bring up RoR, people are always quick to say, "RoR has problems scaling." Our Java project doesn't scale very well, and it won't ever scale well. We spend so much of our time coding around oddities that are inadvertently brought about by the lack of structure in our project that we don't have time to focus on scaling. Go ahead! Criticize our team for lacking structure, a structure common to the really "good" developers out there. Bah! Lack of structure is status quo, and that's why things like Grails and Rails (or, I'm told, Django) came about. They enforce structure by default. They enforce rich domain models by default (I've been through my share of anemic domain models to know why they are valuable). They enforce separation of concerns, and they are really FUN to use!

So if you aren't going to use one of these hip, new frameworks, that's fine, but you'd better have a good justification for it.

Tuesday, January 22, 2008

Rate Cuts and the Dollar

Today the Federal Reserve Bank cut the federal funds rate by 75 basis points. In all the time I've been paying attention (since college) I have never seen a cut this big. Cutting the fed rate is supposed to increase the money supply by encouraging people to borrow. On the down side it can carry inflation along with it, and the dollar did in fact trade down today. What's crazy is that even with a cut like this the DJI and S&P 500 closed down! If a cut like that can't increase investor confidence, then maybe a cut like that won't bring inflation along with it. And if there is an ominous global recession on the horizon, maybe we won't see the dollar decrease much because other central banks will cut their rates too. It'll be interesting to see, so let's start documenting it! Here is a list of exchange rates:

GBP: 1.9577
CAD: 0.9758
EUR: 1.46089
AUD: 0.868402
JPY: 0.009409

I'll keep track over the next while to see what happens.

Sunday, January 13, 2008

speling

A client at work keeps insisting that we improve the search results on one of my current projects, and one of the things they want is the nifty Google "spell check"... you know, the thing that asks if you meant to search for something else when you misspell a word?  I once read an article on how it works, and it does some comparisons behind the scenes to see if searching by another similar word will result in a significant amount more of results.  The difficulty is in finding those "other words".  I found two ways around this.  The first is that Google actually makes the spell check available through a REST interface, and you don't even need an API key to use it.  Here is some code that will make it work:


import java.net.*;
import java.io.*;

public class Post{

public static void main(String args[]) throws Exception{
String data = "<?xml version=\"1.0\" encoding=\"utf-8\" ?><spellrequest textalreadyclipped=\"0\" ignoredups=\"0\" ignoredigits=\"1\" ignoreallcaps=\"1\"><text>I lik pzza</text></spellrequest>";
URL url = new URL("https://www.google.com/tbproxy/spell?lang=en&hl=en");
URLConnection connection = url.openConnection();
connection.setDoOutput(true);
OutputStreamWriter writer = new OutputStreamWriter(connection.getOutputStream());
writer.write(data);
writer.flush();

BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()));
String line;
while((line = reader.readLine()) != null){
System.out.println(line);
}
writer.close();
reader.close();
}
}

My worry with using Google is that they'd decide they didn't like me querying that service every time a user does a search, and it's very likely against their terms and services agreement.  But lo, dear reader, I found another method of generating those "other words"  It's in this great article by Peter Norvig who happens to be a director of research at Google.  So Thanks Peter, I never could have done it without you.