Tuesday, 10 June 2008

The Bucharest Bicycle Lane Scam

A year ago I wrote about being a bicycle rider in Bucharest. I complained then that there are no bike lanes and no one gives a damn about bicycle riders or the very law that should protect them. Things have changed, apparently, and now beautiful bike lanes are criss-crossing Bucharest's sidewalks. But it is all for show and appearance.

First of all, they serve no purpose on the sidewalk. Given the peculiar psychology of the majority of the population when they have to choose between walking on a nicely marked yellow/green stripe and the normal gray sidewalk, they will walk where the nice colors are. Even if they would somehow decide to think a little and ponder on the significance of the big bike signs painted on those lanes, there are children that have no idea what they are doing and could always jump in front of you. Normally, the population of the bike lanes in bucharest is comprised of mothers with babies, lovers holding hands, old ladies and people that just wouldn't give a damn. Very often I see young stylishly dressed women walking right towards my bike, ignoring me completely, expecting me to move aside. Do they even consider the damage that I would do if I'd just decided on a whim NOT to move aside? Not to mention places where there is space only for the bike lane and it would be stupid to expect people not to walk on it. And of course, the cars that park right on the lanes and about nobody does anything.

Second of all, the lanes were built close to autumn last year, a season not favourable to biking. Then, of course, winter came, and the plastic like stripes that mark the lanes were pretty much destroyed. So they had to put them again. However, during the spring they started working on fixing the streets. That meant scraping the asphalt (bike lanes on the street included) and puting it back on. But they did draw the lanes back on. Then they started changing the street border stones, usually placing them idiotically high right on the bike lane. And if it wasn't enough, they started placing all above ground wires under ground. That meant digging narrow, yet deep trenches in the sidewalk, interrupting the lanes from side to side, so that there is no way to go around, and they never filled them up! Basically every one in two bike lanes is now broken by this. And, as this was not enough, more often than not the lane is of worse quality than the rest of the sidewalk.

Therefore I will ignore these lanes completely, except the days when I am really tired and don't trust myself around cars, and risk my life and the paint on the cars around me rather than the lives of the people on the sidewalk. What a sham this all is. The Bucharest European mask is there only for outsiders, NOT for the people living in it.

Sunday, 8 June 2008

Coalescent by Stephen Baxter

In 1973, Frank Herbert wrote a book called Hellstrom's Hive in which it described a sect of people that lived underground, in a system much alike insects, with individuals specialised for different tasks and all living for the big hive organism. The book did not explain how it all got there, it just quickly described the situation and then delved into the action.

Book cover Jump to Stephen Baxter's Coalescent, the first book of the Destiny's Children series, which pretty much details how a group of humans would reach a plausible hive like society. Unfortunately, the book is more descriptive than anything else, failing to deliver in the action part. A lot of characters are developed and a lot of history (both personal and general) is detailed, but in the end the characters vanish as if they never mattered. It is, after all, the whole point of the novel, that ignorant individuals following certain rules lead to the emergence of patterns, but it did not fit well within a book.

Not that the book itself is not fascinating and well written, because it is, but the pace is very slow at the beginning, accelerating to a snail pace in the end, while the different parts of the book seem fractured, too little related to one another. I intend to read the rest of the books in the series, but I might just give up, too.

Bottom line, I think it would be a nice read to start with Coalescent and then read Hellstrom's Hive, although I do think the second book to be much better.

Friday, 6 June 2008

Google Toolbar for Internet Explorer with XP SP3 sucks!

No, it's not one of the The World Sucks rants, it's actually very serious. I was terribly annoyed that after installing Windows XP SP3 my Internet Explorer 7 browser would (sometimes) freeze when closing tabs. I could replicate the bug easily enough by folowwing these steps:
  1. Open Internet Explorer
  2. Go to http://siderite.blogspot.com
  3. Scrollwheel click on Sign in, thus opening it in another tab
  4. Wait until the title of the second tab changes to Redirecting (because I have the cookie from a previous login)
  5. Press F5 (Refresh) in the first tab
  6. Click on the second tab and close it while the first tab is refreshing


At this time Internet Explorer would freeze with no error message. Waiting for a few seconds I could access the context menu on the taskbar button and choose Close or click on the X Close button, but everything inside the Internet Explorer window would be inactive. If I would switch tasks back and forth, the IE window would appear completely blank inside.

Now, whenever you look for the solution for this you get three answers:
  • Check the Warn me when closing multiple tabs option in the Internet Explorer tabs settings.
  • Run IExplore.exe with the -extoff command line parameter which will disable all add-ons and this will tell you if the addons are causing this
  • Check for spyware/malware


I did all this and nothing changed! I've reinstalled all addons. I've reinstalled IE7. I've switched to IE8 beta! Nothing worked. Then I proceeded in uninstalling all addons, see what happends. Finally, it wouldn't cause any issues. It was just after I've uninstalled Google Toolbar! I suspect the cause for the bug is coming from the popup blocker which interprets tabs as popups and tries to close them. Then there is the setting in GT that is trying to preserve any software from modifying its settings. Maybe that is why -extoff doesn't affect it!

Just to be sure I installed it again and tested the bug and I could replicate it. Something in Windows XP Service Pack 3 messes Google Toolbar up!

Bottom line: uninstall Google Toolbar until I can find out which part of it actually causes the bug.

Monday, 2 June 2008

YouTube is going down

As I was writing in the previous post, because of that law suit they are in, Google is starting to take measures to protect the copyright of videos on YouTube. The result is that all the blogs and sites that embedded video content that is supposed to be copyrighted now have beautiful flash players with a play button in them, but then the nasty surprise of seeing "video not available" when pressing play. At least display the damn message from the beginning instead of forcing me to play every video on my blog to see if there are still available!

But I did that anyway, for music videos for now, and switched to (currently) unaffected French video content site DailyMotion. Of course, lots of YouTube clones are on the net and even YouTube leecher sites. I mean sites showing a wonderful error when trying to play videos that now are removed from YouTube.

So, please folks, if you find some post with missing videos or pictures or anything wrong, really, please comment on it and I will fix it. Thank you and damn all lawyers to hell!

Korn - Falling Away from Me

I really like Korn, they are heavy, melodic and the lead singer is pretty unique. I haven't posted anything by them yet because I was a teenager when I was listening to them. I remembered loving the video for Falling Away from Me and wanted to share it with my bloggies :).

Friday, 30 May 2008

The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>).

This annoying error appeared out of nowhere in a project that used to work. I thought that the fault was of the new AjaxControlToolKit and the way it tries to register a CSS file. I was about to make really complex and , apparently, useless changes to my code until I've stumbled upon Rick Strahl's blog. It is not in the entry, but further down in the comments, but it's there.

Here is a distilled version: the error is not a page error, but a naming container control error. That means that if you do this in a PlaceHolder, let's say, it will only throw an error if the PlaceHolder has code blocks. The same applies to the header! The problem was not AjaxControlToolKit, but my own modifications to the MasterPage, where I had added script blocks with a dynamic URL.

So I added the script tags from the codebehind using this:

private void AddHeaderScript(string src)
{
HtmlGenericControl hgc=new HtmlGenericControl("script");
hgc.Attributes.Add("type", "text/javascript");
hgc.Attributes.Add("language", "JavaScript");
hgc.Attributes.Add("src", src);
Page.Header.Controls.Add(hgc);

}
. I don't know how this would work during an Ajax postback, but I wasn't interested in this, being a MasterPage thing. And it worked.

So, next time you get this error, be sure you know what control generated it. It can be solved by putting an extra PlaceHolder or, as is this case, replacing just some specific few code blocks.

Thursday, 29 May 2008

Text searching in .NET, not as I expected.

Update: the title of the post should have been "Text searching in general, not as I expected". I did a quick test in javascript. Do 1000 indexOf and then 1000 search(RegExp object) in a long text and measure time. Here are the results:
Internet Explorer 7: search 90% of indexOf time!
FireFox: search 355% of indexOf time!?!
Chrome: search and indexOf same speed.


Update February 2016: I've tried it again, with Firefox 44.0.2, Chrome 48.0.2564.109 m and Internet Explorer 11.0.9600.18163 and indexOf is marginally faster than regex for all of them. For the case insensitive search, Firefox and Chrome take 50% than indexOf, while Internet Explorer is not only the fastest, but also only adds 4% when searching case insensitive.

It makes sense to have the same implementation of indexOf and regular expressions as in .Net for the Microsoft browser, so I am not that surprised, but what happened with FireFox? My hypothesis is that they used Boyer-Moore in indexOf (as any decent programmer should have!) yet used a simpler implementation for their regular expression engine.

A few days ago I was preaching that IndexOf with StringComparison.Ordinal is the fastest thing for text searching. I was even implying that it uses the Boyer-Moore algorithm from a Windows system library written in c++. I was dead wrong!

Thanks to Meaflux who told me that the Internet said things differently, I delved even further into the code, past the .NET code and into the library code of mscorwks.dll where the IndexOfString method that ordinal IndexOf uses, written in c++, appears to be a pathetic linear algorithm!!

Even worse, the Boyer-Moore algorithm is used in the .NET framework in the Regex class! The Regex class is written entirely in managed code, even if it uses all sorts of cool hacks. I've also tried a Boyer-Moore implementation from Codeproject that also included the Apostolico-Giancarlo, BCL, Horspool and Turbo Boyer Moore algorithms. IndexOf was slower!

Anyway, the code is simple: take a one megabyte Harry Potter text book and search a 100 byte text from somewhere near the middle of the text. Use IndexOf with StringComparison.Ordinal, then Regex with both variants, compiled and ad-hoc creation, then the class from CodeProject.

    Results for 100 tries:
  • Ordinal IndexOf - 390 milliseconds
  • Normal IndexOf - 2380 milliseconds (6 times slower!!)
  • AdHoc Regex - 190 milliseconds (take into acount the creation of the regex 100 times plus the use of Regex.Escape 100 times on the search pattern)
  • Compiled Regex - 160 milliseconds
  • Codeproject Boyer-Moore - 230 milliseconds


Would you have believed this?

Maybe the algorithm was better because the search string was 100 bytes, so I made it 12 bytes and redid the test:

    Results for 100 tries:
  • IndexOf - 440 milliseconds(more than with 100 bytes!)
  • Normal IndexOf - 2410 milliseconds!!
  • AdHoc Regex - 235 milliseconds
  • Compiled Regex - 230 milliseconds
  • Codeproject Boyer-Moore - 368 milliseconds (a lot more, similar to IndexOf, yet still less)


Ok, maybe the problem was that the string in which I searched was big. Let's make it 5000 bytes!

    Results for 100000 (1000 times more operations):
  • Ordinal IndexOf - 1109 milliseconds
  • Normal IndexOf - 1109 milliseconds
  • AdHoc Regex - 2500 milliseconds
  • Compiled Regex - 375 milliseconds!!!
  • Codeproject Boyer-Moore - 1312 milliseconds (finally something slower than IndexOf)


So Regex appears to be best for string searching in most cases!

Update: after optimizing the Boyer-Moore class and adding my own goodness to it, I made more tests. The Boyer-Moore algorithm can be improved by adding more preprocessing, therefore it is more and more efficient as the pattern size increases and the number of pattern searches decreases. In those cases (pattern length of a few thousand characters) Regex is not so good, especially if one has to Escape the entire sequence and instantiate the class on each search. Anything over 500 characters in search pattern length made Regex perform less than the most preprocessing BM I've used.