I’ve seen this quite a few times, and I feel it’s worth mentioning, as it perhaps isn’t obvious. The plural of the word child is children and not childs.

org.apache.wicket.MarkupContainer (add method)

The MySQL function curtime has (at least) the following issues:

1. The function returns the current time as a number i.e. the time quarter past 8 would be returned from the function as the number 201500. (So if you subtract one from such a number you get 201499 which has no meaning.)
2. The function only returns this if you use it in an “integer context”, i.e. (x+0) causes x to be evaluated to an integer. (Otherwise it produces a string in a different format.)
3. At some point the function was changed not to return an integer but to return a decimal with 6 decimal places. As far as I can tell these 6 decimal places are always zero. The example in the documentation also supports this experience.
4. There is no way to specify a timezone. When going from a point in time (e.g. unix time or simply the concept of “now”) to/from an external format (hours, minutes, year, …) you must always specify a timezone. The concept of the “default timezone” should just be eradicated and deleted from the world. If I had a time-machine, the first thing I would do is go back and prevent this concept’s creation. (The user must see the data in their timezone, which on a web application needn’t be the same as the server’s. And if you are writing a desktop application, you need to decide explicitly to use the user’s timezone, as not all data might be for the user, e.g. data from a server or database.)
5. I don’t really think the name of the function is very good (saving characters by abbreviating the name, but why?)

Why would you ever use a function? Why would you ever add it to your database product. *Shakes Head*

I welcome feedback of the form “this is an amazing function, I’ve used it my application and it fitted my need exactly”. I do really welcome this. Please don’t hold back.

Related: curdate, now.

PHP is a weird language.

$x = new Foo();
print $x->bar();

works fine as you’d expect. but

print new Foo()->bar();
print (new Foo())->bar();

all do not work.

I do not understand how you can build an expression parser, where the code above works, and the code below does not. It’s almost as if “$x = new XXX(xxx)” a separate case searched for by the parser?

I mean if you have an expression parser capable of handling brackets, i.e. (1+2)*4, and you have the expression (new Foo()) and you have the concept of $object->method() then how can it possibly not work?

$ cat -n x.php
     1  <?php
     2
     3  class Foo {
     4     function bar() { return 4; }
     5  }
     6
     7  $foo = new Foo();
     8  print $foo->bar();
     9
    10  print (new Foo())->bar();

$ php -e x.php
Parse error: syntax error, unexpected T_OBJECT_OPERATOR
in /home/adrian/x.php on line 10

Quotes in CSV files are a classic case of a solution to a problem, which in fact does nothing to solve the problem, but which does increase complexity.

The problem: If you have a row of data like foo,bar and you wish to include commas in one data element, you can’t, as the recipient system will treat the comma as a field separator as opposed to part of the data. The solution used by programs like Excel: surround such data in double-quotes, i.e. “fo,o”,bar.

In my opinion, there are two solutions to embedding data in other data (e.g. a string in a CSV file, or a piece of arbitrary text in an XML file):

1. Either any character may be contained within the embedded data
2. Or only certain characters may be contained within the embedded data

If you are in situation #2, it doesn’t really matter how many characters you can/can’t contain, the fact is, you’ll have to deal with the situation.

The CSV solution if introducing double-quotes has simply been changed the problem from “you can’t use commas” to “you can’t use double-quotes” which are pretty equivalent problems IMHO. Yet, as with most solutions, the complexity has been increased by its introduction.

There needs to be a solution to the new problem of “you can’t use double-quotes”, and that solution should be to define an escape character e.g. “\” to prefix the double-quotes in case you wish to represent them literally. And that solution would work just as well to solve the original “you can’t use commas” problem!

(In fact the solution chosen by Excel is to use two double-quotes to represent a literal double-quote, and not an escape prefix like the backslash: this makes parsing harder and can’t be used for field separators as they couldn’t be differentiated from two field separators around an empty field.)

I tried to use my company laptop outside of the office for the first time. I clicked on the “VPN” option in the start menu which the company had installed on the laptop. Up came a browser, trying to access the VPN page (accessible from the Internet). However, it didn’t work, as the browser was trying to connect to the company’s web proxy. The company web proxy is obviously only available once one is in the company network, i.e. once the VPN is connected.

(The solution was to include the VPN website server in the list of sites not to use the company proxy for; however as I only just managed that, I wonder how many of the non-technical users within the company will manage it.)

Between Java 1.0 and Java 1.3 (1996-2002 according to Wikipedia) there was no way to split strings into an array or a list.

In Java 1.4 the authors of Java saw it fit to introduce a method to split strings,

String csvData = "field1,field2,field3";
String[] fields = csvData.split(",");

However they did not introduce a method to “join” strings! Even in Java 7 there is no way to do this, e.g. via a static String.join method (2002-now).

OK I realize this is not “rocket science”, and I appreciate it exists in various versions in various third-party libraries, but still, it’s something every program needs to do at some point, it’s annoying to have to re-define it or think about it for each application.

For example, in one project I was working on in the last 6 months, such a function was created, and then had a bug! (OK but to be fair, that was not the only bug in the application!)

Come on, I mean this is a totally trivial function, totally necessary, available in all scripting lanuags why is it still not in Java?!

(P.S. Want to see an “enterprise java” solution to this problem? Check out the number of methods on this class)

In Java 1.4 there was the function Arrays.asList. You could pass it an array and it would make a list out of it.

String[] myArray = new String[] { "foo", "bar" };
List myList = Arrays.asList(myArray);

In Java 1.5 this was retrofitted for varargs; you could simply pass elements to the function

List<String> myList = Arrays.asList("foo", "bar");

I never really understood how that worked in a backwards-compatible way; I mean either the function takes an array of stuff, or it takes individual elements, surely?

It turns out, that with the varargs syntax, the caller is not forced to pass individual elements, the caller can instead pass an array of elements.

List<String> myList = Arrays.asList("foo", "bar");
List<String> myList = Arrays.asList(new String[] { "foo", "bar" });

The above two calls are identical, both return a List<String>.

But surely this is really dangerous? I mean Arrays.asList does not make any assumptions about what types of arguments it accepts; the list can be composed of any object.

How can it be certain that you want to have an List of Strings, and not a List containing a single element which is a String array? (An array is an object.)

To demonstrate this inconsistency:

String[] arr = new String[] { "foo", "bar" };
Arrays.asList(arr);            // returns List<String>
Arrays.asList(arr, arr);       // returns List<String[]>
Arrays.asList(arr, arr, arr);  // returns List<String[]>

Most modern languages use very similar syntax inspired by C; but the features added since C are really non-standard! The “for-each” syntax annoys me particularly. I mean none of these is significantly better/worse than the others, but I program in all these languages (apart from C#) on a regular basis and I always have to think when typing in the line in order not to get the wrong syntax.

For what it’s worth, I think “foreach” is nicer than “for” as it reads more like a sentence (the word “for” really makes no sense at all in that context); and about “in” vs. colon I’ve got no preference really.

How annoying, I upgraded from Debian Etch (Apache 2.2.3-4) to Debian Lenny (Apache 2.2.9), and then my Subversion Server (over HTTPS) gave the following error when surfed to from Firefox, which worked fine before:

An error occurred during a connection to svn.example.com.
SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)

What does that mean!? There’s not a great deal of info on the web.

Fundamentally, in my case, the first thing to work out, is that that error message means (or meant, in my case at least) HTTP was being transmitted over the HTTPS port, i.e. it wasn’t valid HTTPS at all, thus the protocol error. This could be confirmed by surfing to http://…:443/ (i.e. not https://) and seeing that the content (the Subversion server in my case) was correct.

The question was why? I had a bunch of sites in the “sites-enabled” directory, and another one of them (not my Subversion site!) had a

<VirtualHost *>

whereas it should have been

<VirtualHost *:80>

i.e. the port was missing. I’m not quite sure why it had that effect, as the request to the Subversion HTTPS URL did deliver the Subversion content, just not over HTTPS any more. But perhaps without the :80, it decided all ports should be subject to NameVirtualHost, and as that’s not possible with HTTPS, switched HTTPS off for all ports and all sites?

Nightmare ….

See also: http://stackoverflow.com/questions/119336/ssl-error-rx-record-too-long-and-apache-ssl

What can I say? How about “toy language”?

$ php -r 'function foo() { foo(); } foo();'
Segmentation fault

I’m not saying that infinite recursion is a good idea, but during development it can happen by accident, and I don’t expect such a simple error to crash the PHP interpreter! (Also it took me about 20 minutes to debug this problem, as I had no idea where it happened, nor indeed what the problem was..)

PHP 5.2.6 on Linux 2.6.26 Debian