Yesterday I went to the Florida vs. FSU football game. I haven't had much recent, personal college football history...
Sunday, November 30, 2008
Gator Talk
Posted by
Michael Galpin
at
8:45 PM
0
comments
Labels: college football, Florida Gators
Monday, November 24, 2008
Delta Airlines Entertainment
A few days ago I flew from San Jose back to my hometown, Panama City, Florida. To be accurate, I first flew from San Jose to Atlanta, and then from Atlanta to Panama City. On the flight from San Jose, the 757 was equipped with an onboard entertainment system. There was a free part and for-pay part. The main component of the free part was satellite TV courtesy of Dish Network. The other part was a decent selection of free music to listen to. The for-pay was comprised of movies, HBO programming, and a few games.
Posted by
Michael Galpin
at
9:06 PM
0
comments
Labels: delta airlines
Wednesday, November 19, 2008
Gumbo and Data
This week I was at Adobe MAX. While there I picked up a DVD with a preview of Flex Builder 4 and Flash Catalyst (Thermo.) One thing of particular interest to me was the new data-centric abilities of Flex Builder. Let's take a look at them.

Friday, November 14, 2008
Facebook Puzzler in Scala
An associate of mine pointed out some fun programming puzzles on Facebook. This one was interesting to me. It was interesting because I think it is poorly. Well at the very least it confused on first read. When specifying the cost/weight, if they would have just used the word 'each' in there it would have been far less confusing... Anyways, I decided to solve the problem in Scala, since I've been doing a lot more Scala programming lately. Here is my Solver:
object Solver {
def cache = new scala.collection.mutable.HashMap[(List[Int], Int), List[List[Int]]]()
/**
* Generates a list of solutions to the Diophantine inequality
* w1*x1 + w2*x2 +... wN*xN >= max
* where weights = (w1,w2,...wN)
* Each solution is a minimal solution.
* This means that if (x1,x2,...xN) is a solution
* then (x1,x2, ... ,-1 + xM , ... xN) is NOT a solution
*/
def solve(weights: List[Int], max: Int): List[List[Int]] = {
if (cache.contains((weights,max))){
return cache((weights,max))
}
if (weights.length == 1) {
return List(List(max / weights(0) + 1))
}
var all: List[List[Int]] = Nil
var a = 0
while (a * weights(0) < max) {
all = all ++ solve(weights.drop(1).toList, max - a * weights(0)).map(a :: _)
a += 1
}
val solution = (a :: weights.drop(1).map(_ * 0)) :: all
cache.put((weights,max), solution)
solution
}
/**
* For a given set of weights (w1, w2, ... wN) and costs (c1, c2, ... cN)
* This finds the solution (x1,x2,...xN) to the inequality
* w1*x1 + w2*x2 + ... wN*xN <= max that minimizes the total cost
* c1*x1 + c2*x2 + ... cN*xN
* It returns the solutions as a Tuple where the first element is
* the solution (x1,x2,...xN) and the second is the minimal total cost
*/
def optimizer(costs: List[Int], weights: List[Int], max: Int): (List[Int], Int) = {
val solutions = solve(weights, max)
var answer: List[Int] = Nil
var best = (answer, Integer.MAX_VALUE)
solutions.foreach((solution) => {
val cost = solution.zip(costs).foldLeft(0){(a,b) => a + b._1*b._2}
if (cost < best._2) {
best = (solution, cost)
}
})
best
}
}
Posted by
Michael Galpin
at
9:31 AM
0
comments
Labels: diophantine equation, dynamic programming, facebook, mathematics, puzzles, scala, unbounded knapsack problem
Tuesday, November 11, 2008
Scala Constructors
Tonight at BASE, I had a rant about Scala constructors. So I'll just continue the rant here. Constructors seem great in Scala. At first. They give you some great syntactic sugar where it creates accessors/mutators all in one shot:
class Stock(val name:String, val symbol:String, var price:Double, var change:Double){
}
This lets you do nice things like :
val stock = new Stock("Apple Computers", "AAPL", 94.77, -1.11)
println(stock.symbol) // works great
stock.price = 95 // works good, price is var
stock.symbol = "APPL" // won't compile, symbol is a val
Yay, no getter/setter garbage. But what about overloaded constructors? You can kind of do that...
class Stock(val name:String, val symbol:String, var price:Double, var change:Double){
def this(name:String, symbol:String) = this(name,symbol, 0.0, 0.0)
}
So in Scala you can do implement the telescoping constructor anti-pattern. Nice. But what if you got your stock data as a CSV from Yahoo's web service? You need to do some parsing. You might think this will work:
class Stock(name:String, symbol:String, var price:Double, var change:Double){
def this(name:String, symbol:String) = this(name,symbol, 0.0, 0.0)
def this(csv:String) = {
val params = csv.split(",")
name = params(0)
symbol = params(1)
price = java.lang.Double.parseDouble(params(2))
change = java.lang.Double.parseDouble(params(3))
}
}
Nope, this won't work. You can only do a single statement in the 'this' constructor, and it must be to either the main constructor or another 'this' constructor. No extra code. Bill Veneers pointed out that this often leads to code like the following:
case class Stock(val name:String, val symbol:String, var price:Double, var change:Double){
def this(name:String, symbol:String) = this(name,symbol, 0.0, 0.0)
def this(ser:String) = this(parseName(ser), parseSymbol(ser), parsePrice(ser), parseChange(ser))
def parseName(ser:String) = ser.split(",")(0)
def parseSymbol(ser:String) = ser.split(",")(1)
def parsePrice = java.lang.Double.parseDouble(ser.split(",")(2))
def parseChange = java.lang.Double.parseDouble(ser.split(",")(3))
}
Oy. I think even the most enthusiastic Scala programmer would agree that is some very smelly code (and inefficient to boot.) A more common pattern is to use a factory object:
object Stock{
def apply(ser:String):Stock = {
val params = ser.split(",")
new Stock(params(0), params(1), java.lang.Double.parseDouble(params(2)), java.lang.Double.parseDouble(params(3)))
}
}
class Stock(val name:String, val symbol:String, var price:Double, var change:Double){
def this(name:String, symbol:String) = this(name,symbol, 0.0, 0.0)
}
Having a singleton object and a class by the same name is a construct introduced in Scala 2.7. Now usage looks like this:
val apple = new Stock("Apple Computers", "AAPL", 94.77, -1.11)
val microsoft = Stock("Microsoft,MSFT,21.20,-0.10")
Kind of inconsistent, no? In one place you use the new, but to get the benefit of the factory, you can't use new. So usually people change the class to a case class:
object Stock{
def apply(ser:String):Stock = {
val params = ser.split(",")
new Stock(params(0), params(1), java.lang.Double.parseDouble(params(2)), java.lang.Double.parseDouble(params(3)))
}
}
case class Stock(name:String, symbol:String, var price:Double, var change:Double){
def this(name:String, symbol:String) = this(name,symbol, 0.0, 0.0)
}
Now usage is more uniform:
val apple = Stock("Apple Computers", "AAPL", 94.77, -1.11)
val microsoft = Stock("Microsoft,MSFT,21.20,-0.10")
val test = Stock("Test Stock", "TEST")
I guess that is ok. Becuase Stock is now a case class, you don't have to declare name and symbol as public vals. I kind of like using 'new' and I really don't like having to create both an object and a class just to get overloaded constructors. I think it is still a code smell.
Update: In the comments it was pointed out that the companion object pattern (object and class of the same name) has been around for a relatively long time. What was introduced in Scala 2.7 was allowing case classes to have companion objects. So the last version of the code will not compile on anything but Scala 2.7+, but if you make the Stock class a normal class then it will. Of course then you are back to the problem of having two different syntaxes for the constructor, one that needs the 'new' keyword and one that does not (and cannot.)
Posted by
Michael Galpin
at
10:06 PM
9
comments
Friday, November 07, 2008
Pastrami Dog?
I was driving home tonight and noticed a local Wienerschnitzel advertising a pastrami ... thing ... on a (hot dog) bun. This reminded of exactly one thing: being a kid, in high school or college, and scrounging through the kitchen looking for something to eat. All you find is some sandwich meat and some hot dog buns. There is no bread to make a proper sandwich, so what do you do? You used the hot dog buns. Now Wienerschnitzel has taken this masterpiece and turned it into a product.
Posted by
Michael Galpin
at
10:08 PM
0
comments
Wednesday, November 05, 2008
You Want XUL, You Got XUL
I've written a lot of articles for IBM over the last couple of years. I've covered a lot of topics. It was interesting for me to see which articles have been viewed the most. Last year I did a tutorial on XUL for beginners. To be honest, I really thought XUL was a very niche topic. If you are going to write a Firefox extension, you have to learn XUL. There are lots of resources out there about that. I did not want to write about that kind of XUL development. So instead I wrote about creating a XUL desktop application that used a lot of web development skills. Hey if Adobe can market AIR as a way for web developers to create desktop apps, then why shouldn't Mozilla do the same thing with XUL? It was a fun article to write, but I didn't expect it to be especially popular. Boy was I wrong!
Posted by
Michael Galpin
at
2:10 PM
0
comments
Labels: air, developerworks, firefox, ibm, xul
Tuesday, November 04, 2008
Saturday, November 01, 2008
Vote by Mail
This year I voted by mail. It was very convenient. The state of California even sent me a nice little "I voted" sticker. So how did I vote? Most things will probably not be a surprise if you read my blog on a regular basis. There were a lot of things to vote on, so here is a quick summary.
President -- Barack Obama. I am no fan of his proposed economic policies, but the war remains the most important issue to me. Besides, most of McCain's proposed policies are so similar to Obama's. It is very sad.
Congress -- I voted against my congressman, Mike Honda. I wrote him about the bank bailout, but he still voted for it. Gotta vote against him for that.
Propositions -- These are the fun stuff here in California. The most debated is Proposition 8. This was a no brainer to me, I voted against it. Terry put together a nice post about Prop 8. I was surprised to find myself voting for Prop 2...
Posted by
Michael Galpin
at
7:56 PM
0
comments
Labels: barack obama, politics, prop8


