Apache Commons: Unfortunate Design of FTPClient?

The class FTPClient of the Apache Commons Library encapsulates FTP commands and provides convenient FTP support. To upload a file, your code will probably be like this (error handling ignored):


FTPClient ftp= new FTPClient();
ftp.connect(server, port);
ftp.login(username, password);
ftp.storeFile(remote, input);


where remote is the file name on the remote computer, and input is an InputStream.

So far so good, but suppose you need the file name (remote) to be encoded by a certain convention, say UTF-8, which is not your default encoding. How to do that? You may notice the method FTPClient.setControlEncoding(String), and do


FTPClient ftp= new FTPClient();
ftp.connect(server, port);
ftp.login(username, password);
ftp.setControlEncoding("UTF-8");
ftp.storeFile(remote, input);


Unfortuantely, that does not work. Why?

It turns out that controlEncoding is only used when the connection is established, and, after the client is connected to the remote node, although you can call setControlEncoding, it does not change anything in your current connection. Therefore, we have to do ftp.setControlEncoding("UTF-8"); before ftp.connect;, like this:


FTPClient ftp= new FTPClient();
ftp.setControlEncoding("UTF-8");
ftp.connect(server, port);
ftp.login(username, password);
ftp.storeFile(remote, input);


And now it works fine, the name of the file you create on the remote node is UTF-8 encoded.

The idea of the inventors of this class seems to be clear (see also source code): on calling connect, an OutputStream is created (using controlEncoding), and this stream is used in the control connection to the FTP server. If the encoding is changed after the connection (hence the output stream) is created, it remains effectless.

The question is, however, why the API does provide two methods that are tightly coupled and have to be called in a certain order. Why not just strike the setter, and give connect another parameter? This way, the user would not even have a chance to make the mistake as in our first listing!

Project Euler Problem 30: One Liner Python

One liner Python to solve problem 30 of Project Euler:

sum(filter(lambda i: i == sum([int(x)**5 for x in str(i)]), range(2,400000)))

Project Euler Problem 2

Problem 2 of Project Euler reads:

By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms.

It is important not to check for every Fibonacci number whether it’s even or not. Instead, it’s obvious that only the 3k-th Fib-numbers (k being a natural number) are even.

The python program is pretty straightforward:


def e2():
  a,b,c = 1,1,2
  sum = 0
  while (c <= 4000000):
     sum = sum + c
     a = b + c
     b = c + a
     c = a + b
  return sum

Scala: First and Last Element of a Set?

I just came into two functions of class Set of Scala: head to return the “first” element of the set, and last to return the “last” element. Clearly, this is a case of unfortunate design. Since the elements of a set are not ordered, there is neither a first one nor a last one. I wonder why the Scala team made this design.

Although the documentation warns that the functions may return different values at different runs, I bet a lot of programmers still make the mistake of assuming the result of the functions would be stable. Pretty dangerous!

Project Euler Problem 1

The first problem of Project Euler is pretty simple. It reads:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

Well, the naive way to solve this problem is simply to generate a list, and then to find the sum of its elements:


sum(filter(lambda x: x%3==0 or x%5==0, range(1,1000)))

and the answer is 233168.

Although I appreciate the elegance of functional programming (lambda function, filter, sum), mathematically the above code is not a good solution. The sum of all numbers that are either dividable by 3 or 5 in fact equals the sum of all numbers that ar dividable by 3, plus the sum of all numbers that are dividable by 5, minus the sum of all numbers that are dividable by 15, therefore


rg = range(1,1000)
sum(filter(lambda x: x%3==0, rg)) + sum(filter(lambda x: x%5==0, rg)) - sum(filter(lambda x: x%15==0, rg))


And again, the answer is 233168.

Project Euler

Project Euler is a very nice collection of math/programming problems. It provides very valuable exercises for math/programming. While the first problems are easy to solve, the others may be pretty challenging.

I am now staring a series in this blog to show my solutions to some of the problems.

A Simple Mistake of Using Java Exception

Recently I ran into the following code in a legacy system:

try {
...
} except (Exception e) {
System.out.println(e.getStackElement());
}


While it may look innocent, it’s actually dangerous. In case of an exception, the system prints the String representation of e.getStackElement(), which actually is of type StackElement[]. Since it is an array, its String representation is only the address of the array, instead of the content of the array. Since the output is a one-liner, it does not catch one’s eye in the log, and it may take some time (and really took mine) for the debugger to find the exception.

I have no idea why the original programmer come up with the idea of using getStackElement(). Maybe he thought println(e.getStackElement()) were the same as e.printStackElement().

One Liner Scala for Project Euler Problem 4

It only takes one line code to solve Problem 4 of Project Euler in Scala (and many other functional programming languages):

((for (x <- 100 until 1000; y <- x until 1000) yield x * y) filter (x => x.toString == x.toString.reverse)).max

 

 

How to Use Exceptions: An Example

Today I had to debug a legacy system, including a feature, let me call it xy. In the property file, there were two properties concerning this feature: “xy.enabled” and “xy.url”. “xy.enabled” is used to indicate whether the feature should actually be activated, and if it is true, the system needs to read some data from a URL stored in “xy.url”.

The defect of this system was that even “xy.enabled” is changed to “true”, the feature xy was still not activated in the system.

It was not very easy to find the problem, but after a while of debugging, I finally got it: the original programmer made a mistake while coding, and reading the property “xy.enabled” is done by a method Util.getBooleanProperty(“xy.url”). Obviously, “xy.url” is wrong. I replaced it by “xy.enabled”, and it worked fine.

But why does the original code, with Util.getBooleanProperty(“xy.url”), not throw an exception? Obviously getBooleanProperty is supposed to read a string representing a boolean value, obviously xy.url does not a boolean value!

Yes, that’s true. The method getBooleanProperty reads like this:


public static getBooleanProperty(String property) {
return getProperty(property).equalsIngoreCase("true");
}


where getProperty(String p) returns the String value of property p stored in the property file.

getBolleanProperty really does not throw any exception if the value is not a boolean value at all!

If the original programmer had designed any syntax check, or simpley used Boolean.valueOf, which throws an exception if the parameter is malformed, debugging this problem would have been much easier. This is where exceptions are supposed to help.

Foldr in Python

In [1, p.70] Graham Hutton gives a nice example of the power of the function “foldr” in Haskell. The following function bin2int provides a very elegant way to convert a binary number to a decimal number:
bin2int = foldr(\x y -> x + 2 * y) 0

Since I am programming Python now, I asked myself how to do foldr in Python.

The answer is surprisingly simple: just reverse x and y in the lambda expression, as well as the list. For instance, bin2int can be implemented in Python as:


def bin2int(x):
  t = copy.deepcopy(x)
  t.reverse()
  return reduce(lambda y,x: x+2*y, t)


Voila. There we got a foldr in python!

[1] Graham Hutton. Programming in Haskell. Cambridge University Press. 2007.