| adrian » blog » Databases and Life (ASmith) |
 |
|
|
| Databases and Life (ASmith) | ||
|
09.01.2008 12:29
New Year, New BlogThis blog has moved!I look forward to welcoming you over at: http://www.databasesandlife |
||
|
27.12.2007 22:22
Christmas holidaysIt has been suggested that this blog does not contain enough personal content.This Christmas I visited my parents in Seefeld in Austria, am now in the UK with my parents and Christina and will be going to Paris for New Years. You can see the progress of this voyage on the following Maptales story. It contains locations, text and photos. |
||
|
12.12.2007 14:39
Domain-name search Firefox featureInstalling this into Firefox (takes < 1 minute and doesn't require a download) allows you to check for the availability of domain names straight from the browser.It was created by my colleague, who works with me at easyname.eu, but it was his idea, and I genuinely think it's a cool feature! |
||
|
10.12.2007 23:06
Next PHP uselessness of the dayThere is the option "php -l" which checks the validity of a source file. Obviously it doesn't do a wonderful job as it doesn't detect misspelt variable or method names; but I suppose it's better than nothing.So I apply this recursively to all the files under a certain directory. For reasons I won't go into here there are Postscript fonts checked into the source directory. To this files, "php -l" outputs: No syntax errors detected in ./pdflib/fonts/php_Times-Italic.afm
I assert "php -l" is not very useful. |
||
|
10.12.2007 17:27
Unbelievable PHP limitation of the dayIf one defines a class with the member variable:protected static $bytes = 12582912;
then that's fine. However if one defines it as: protected static $bytes = 12*1024*1024; // 12 MB
then that gives a compile error: Parse error: syntax error, unexpected '*', expecting ',' or ';'
I know of no other language that I've ever programmed (i.e. including BASIC, and C) where you can write a value, but you can't write an expression. How broken is that! Putting spaces around the *, or adding brackets around the whole expression, does not help. (PHP 5.2.0) |
||
|
06.12.2007 16:52
Austrian mobile working againMy Austrian mobile phone works again.1) Originally I asked them to send the new SIM card to Macau, they didn't want to do that. Thankfully I am not the sort of business person who relies heavily on their phone while also travelling a lot. If you are that sort of person, probably better not choose Telering. 2) Then they said they would send the new SIM card to Vienna. 1.5 months later when I arrived back from Macau, it wasn't there with my post. 3) I went to my normal Telering shop at Stephansplatz, it was closed. 4) So I went into a different shop today, and they gave me a new SIM card. The girl was quite confused by the fact that there was a "lock" on my account (presumably from when I rang up and told them I'd lost the phone?). But her colleague told her to ignore that. The SIM card she gave me didn't work. 5) Just now I rang up, and they told me "it doesn't work because your account is locked". They unlocked that now, and now it works. |
||
|
02.12.2007 18:00
BeispielChristina and I have a cool HDD/DVD recorder in Macau. One can set up timed programs and it records them from the TV when one is away. You can even copy them to removable media (DVD).I wish I had something similar in Vienna! Ah yes I do, I realize, I own a VHS recorder :) To set up a timed program, I have to first the device date/time. I'd never done that (Blinking "--:--" situation). I took a look at the instructions, and there was the "Beispiel" (example) of setting the clock to December 1998. Ah yes, I remember I bought the device in the summer of 1999. And only today, 2nd December 2007, for the first time, do I set the clock and create my first timed recording :) P.S. The summer of 1999 is so far away in the past, when I bought the recorder I was seriously stumped by the fact the manual was only in German and I didn't speak German back then. |
||
|
01.12.2007 15:27
Back to ViennaI am at Hong Kong airport right now preparing for the journey home to Vienna. I shall be in Vienna tomorrow (Sunday) and will be working for the next two weeks.I have my Macau mobile with me but that doesn't roam to Vienna. I lost my Vienna mobile and they wouldn't send me the replacement SIM card abroad (to Macau), so I won't have that working before I've got to my post, which should be Sunday. So the best way to reach me henceforth is email or Skype. |
||
|
22.11.2007 07:52
Vector graphics in the browserI've taken a look at the state of vector graphics in the browser.Since the beginning of the web, people have been using GIFs to display their headline texts; tables and CSS to do layout; and GIFs for rounded corners etc. A lot of this would become a lot simpler if the browser was able to display vector graphics. There are numerous systems for displaying vector graphics but the two I looked at in detail were the <canvas> tag and DOJO. Initially I realized that the <canvas> tag could not plot text, and I thought the DOJO system could. But it turns out it can't either. So I concentrated on the <canvas> tag. The <canvas> tag, which works on Firefox, Safari and Opera, and a 1-line Javascipt include of excanvas, also works on Internet Explorer. It works well for trivially simple things. But there are a few things that don't work like I expected. (1) No callback for painting. Essentially a <canvas> is just a bitmap (like an <img>) which you can draw into programmatically using Javascript. This contrasts to traditional vector programming, where you register some kind of callback, and the system calls you when it needs the part of the window under your control to be redrawn. The traditional way is certainly more complex, but it has a few advantages. If you are doing any kind of document editing, e.g. you are programming Word, then documents get big. But only a small amount is displayed on the screen at once. This gets more marked if you zoom in to 500%. With the callback mechanism, your application only get asked to draw the small part of the window on display. With the <canvas> approach, you have to draw everything, all the time. Imagine a grid which needs to draw lines every 5 pixels. That's a lot of lines on a 1,000 x 1,000 pixel screen; but it's a lot more if you need to draw everything in a 10,000 x 100,000 pixel workspace that the user could scroll around on. It simply takes too long to draw everything the user could possibly see if you have a large workspace, or view a large document at a higher zoom. On a 5k x 5k pixel <canvas> with such a grid, Firefox complains "script seems to be unresponsive", whereas on a 1k x 1k grid (which is all you can see) it works fine. (2) Large <canvas> takes up lots of memory. As a <canvas> is just a bitmap, if you create a large one, a large amount of memory is immediately allocated. So if you are programming a Word using this technique, and the user scales the document to 500%, immediately their computer will slow down as the browser needs to allocate a huge amount of memory just to store all the pixels the user could potentially scroll around to see. And the Internet Explorer control and the Opera <canvas> seem to have a limit somewhere around 5k pixels. (3) You can't draw text. This is surely the most amazing limitation. Look at all the vector graphics examples in the web and you'll see e.g. beautiful clock examples - but they use a JPEG as the background to the clock including the numbers. That's hardly the way I had imagined vector graphics would be used! But there is a "solution", as we see in this nice windowing example. As the browser can already display text, and the background to a <canvas> is transparent, you can layer one <canvas> on top of another, and put <div> objects inbetween. If one is to display e.g. a Word document, with various vector graphics and various pieces of text, one would have to create lots of <canvas>es and lots of <div>s and absolute-position them on top of one another. That seems to me like a lot of programming work to create this structure, and to maintain it. And it can't be easy or quick for the browser to render such a document. There is a solution in sight though. There will be a <canvas> drawText command in Firefox 3. Currently nobody has Firefox 3 and none of the other browsers support it. But that will no doubt be different in a few years time. (4) There is no way to query text metrics. If you want to have vector graphics and text on the same page, you need a way to find out the size of text in pixels. For example you want to center text on the screen. Or fit text into a weirdly shaped object. Thankfully this is supported with the Firefox 3 drawText command. (5) Opera zooming doesn't work. Maybe this is just an implementation issue, but as the vector graphics are turned into a bitmap at the time the Javascript commands to draw into the canvas are executed, if you say "scale to 200%" in Opera, it scales the generated bitmap, as opposed to scaling the original vectors and re-rendering them. I always object to the name SVG on the grounds that it stands for "Scalable Vector Graphics", and vector graphics are scalable by their nature, so I don't understand why the file format wasn't just called VG. But it seems someone has indeed managed to implement what I thought was impossible: "non scalar vector graphics". Conclusion So what is one to do to implement a client-side app manipulating vector-based documents? It is clearly the way of the future. As far as I can see, it's still not very easy. Which may explain why there are none of them around. The only one I can think of is Gliffy - and that's written in Flash. (a) An alternative scrolling technique will have to be found. If the user is manipulating a large document, or a small document at a high zoom, then creating one big <canvas> and using the browser scrolling isn't going to work. One will have to implement ones own document-navigation (i.e. scrolling) system. This will not be what the users expect. But it's the technique that Google Maps uses: it doesn't have windowing-system scrollbars to let you pan the viewable area within the original document (the world map): it has its own navigation system. (b) Displaying text is going to be a pain. No more myDocument.display(graphicsContext) - where the code to display the document is decoupled from the particular drawing implementation. The code to display a document is going to have to be quite tightly coupled with the display system (create and maintain <canvas> and <divs>). And for making modifications, I'm not sure if it's going to look nice to delete those <canvas> and <divs> and recreate them each time, maybe one is actually going to have to modify them e.g. during a drag operation, which will make the code particularly front-end specific. |
||
|
19.11.2007 07:49
COUNT(*) vs COUNT(pk_col)A while back I was doing some performance tuning on MySQL 5 for a customer. A SELECT was counting the number of rows in the table. I always use COUNT(*) for that but I know a lot of people, including the customer, use COUNT(pk_col). The query was taking a long time (a few minutes). I analyzed that the problem came from the usage of COUNT(pk_col) instead of COUNT(*). With COUNT(*) it was instantaneous.I didn't know that there was a difference between the two. There is no difference in their semantics, therefore it didn't occur to me that there might be a difference in the way they were executed. Just to recap the SQL syntax:
However, the database in question was executing a COUNT(pk_col) query and a COUNT(*) query differently.
So the conclusion is, one should always use COUNT(*) and never COUNT(pk_col). |
||
previous posts
|