Web Hosting Philippines, Offshore Programming, Offshore SEO Philippines, Cheap Webhosting Manila Philippines


The R5 (Rant, Rave, Rant, Rant, Rave) Blog

Tuesday, March 11, 2008

Javascript anonymous functions - Indispensable Example #1

In this javascript tutorial on anonymous functions, we are shown how anonymous functions (or lambdas, in computer science parlance) work and what the javascript syntax for them looks like. Some people might wonder of what practical value they might be. Well, I've just come across a situation where the utility of having lambdas just shines through and is made unequivocally clear. It is in fact a very general situation which you are likely to encounter often so pay close attention. :-D

In Mozilla, if you want to attach an event to a particular DOM node, you can simply do the below:

document.getElementById("iframe1").
setAttribute("onload","alert('loaded!')")

This causes an alert saying "loaded!" to popup everytime iframe1 finishes loading or reloading its content, and is the equivalent of manually writing:

<iframe src="blah.html" onload="alert('loaded!')">

However, the sad part is that this straightforward technique does not work in IE (as of 6) at all. Instead you must use the proprietary attachEvent() method as follows:

document.getElementById("iframe1").attachEvent("onload",FuncName)

Notice the BIG problem with the above syntax though. You can only pass a function name but cannot specify its parameters! This has vexed me (and I'm sure many others) pretty often in the past. Once you understand how lambdas/anonymous functions work though, the elegant solution becomes obvious:

document.getElementById("iframe1").
attachEvent("onload",function() { alert('loaded!') } )

In the above, Javascript lets us substitute an inline function definition in place of a function identifier. The function is created at this point and exists ('lives') without having to be formally referenced or declared anywhere else. The reason for the term anonymous function now becomes obvious. [ Note: while the above technique will give identical results to the Mozilla method, it is technically not equivalent and involves an additional indirection or at least that's how it seems to me... This is because instead of calling alert() directly, the call lies within an anonymous function which just serves as a dummy wrapper. ]

This sort of power and flexibility that the lambda syntax brings is just impossible in C/C++, Java and other static languages and proves that Javascript does indeed belong in the pantheon of higher order languages along with Python, Ruby, Lisp and others.

Sunday, March 05, 2006

Logitech's Slap In Our Faces (How to get SetPoint/Mouseware to run in Windows Server 2003)

Logitech mice are the best you can find so far. Sure, they may be made by slave labor in China, use increasingly cheap materials and, to top it all off, overpriced (I really should have bought LOGI a long time ago... ;-), but their designs are indeed ergonomic.

In particular, I think they've reached the pinnacle of design with the mouse that came with the old Logitech Cordless Optical Desktop (great ergonomic design paired with el cheapo keyboard action)...



There's really not much to improve upon on it. I love the way the fourth button on the left hand side is conveniently placed where your thumb rests and you can use that to double-click. In fact, in the more recent MX series designs, you get a fifth button, but both it and the fourth buttons are placed a bit higher up...


and this is a mistake because double-clicking gets somewhat harder. So like I said, it's hard to improve upon what was a perfect design earlier.

But slave labor, high prices and cheap materials aside, there is one thing about Logitech mice that really gets my goat and that is... the ^!@#$!@#% driver software or, to be precise, its size.

I recently bought an MX518 (the 'gaming' version of Logitech's MX510) and needed to install the drivers to get the fourth and fifth mouse button to do double-click. I went to the Logitech site to get the latest drivers for it and what I found made my blood boil. The old Mouseware has always had a tendency to be a bloaty POS (but otherwise an excellent of piece of software). Their newest "SetPoint", though, just completely outclasses Mouseware in the shitty bloat department... 32 megabytes for a lousy mouse driver!!!! When your mouse driver software is larger than many DBMS distributions, something is seriously, seriously wrong. Why is it so large you ask? Well, one reason could be that besides the software itself, you get a lot of 'extras' that have nothing to do with mouse functionality - such as some lame 'logitech desktop messenger' application that claims to offer support but is, in all likelihood, nothing but a very thinly disguised attempt to send ads / marketing to the end-user.

You might try to correct me and say that Logitech is just trying to be pro-active in terms of support, but is that really the case?? In the 3 years since Windows Server 2003 was introduced... with all the junk, crap, and bloat Logitech has found time to add to their drivers with each new revision... with their fancy move from Mouseware to SetPoint and all, they have yet to officially provide support for Windows Server 2003 !! Which brings us to the non-rant portion of this blog entry... how to get around this annoyance.

This blog entry shows us the way. With the Setpoint 2.3 that came with my MX518, I also applied the 'Run in Windows XP Compatibility mode' trick to the setup.exe corresponding to Setpoint and I was able to get it to install under Server 2003 with nary a problem. Logitech makes all sorts of dire warnings about Mouseware/Setpoint crashing Server 2003 and requiring a complete reinstall of Server 2003, but so far these seem to be idle threats... I guess their support does not even understand their own product.

Logitech... please get your act together. You are not offering 'good support'... rather, you are making fools out of your customers. You are trying too hard and not doing enough at the same time.

Wednesday, February 01, 2006

Allowing multiple DMOZ editors per category

Dmoz is facing two problems:

1) Accusations are flying fast and furious (do a search for "corrupt dmoz editors") about how corrupt SEO practitioners who are able to monopolize editorialship of commercial categories, are selling Dmoz listings and worse, deliberately failing to include or even removing(!) sites being SEO-ed by their rivals.

2) There is a general perception that it just takes too long to get sites listed. Whether this is due to lack of manpower or due to nastiness by corrupt editors is secondary to the fact that the worth of Dmoz itself is lessened if it is unable to include sites in a timely manner.


There is a simple solution here that should benefit everyone involved (with the exception of corrupt editors). The solution is to allow multiple editors per category. This way there would be more manpower to handle submissions for a particular category and the power of a single corrupt editor is greatly minimized.

A new site listing needs only one editor for it to be listed, but to _remove_ a site listing would need the approval of more than 50% of editors for a particular category. SEO practitioners would still be encouraged to gain dmoz editorialship (adding manpower to the dmoz effort - a positive thing), but would be greatly neutralized in using this position for nefarious purposes. With more manpower allocated per category, it should also become feasible again to revive the practice of giving explanations for why a site is not listed.

Other possible anti-Dmoz corruption tactics would be to reinstitute means to identify and contact the editors for a particular category. Perhaps some public statistics revealing how much work an editor is actually doing (e.g. sites reviewed:listed ratio) would encourage them to be more honest (or hardworking). If there is a cap on the number of editors for a possible category, then perhaps editors who do not perform up to par can be booted out in favor of newer ones.

Saturday, January 14, 2006

What counts as Ethical SEO?

The #1 principle that everyone - SEO practitioners and search engine algorithm designers alike - seem to have forgotten in the fight against search engine spam is that it is all about what the search engine user wants. And what a search engine user wants is nothing more than a website/webpage reflecting the information he had in mind when he typed in the search terms.

As long as the search engine user gets the info he was searching for, he could care less with the usage (or lack thereof) of doorway pages, gateways, redirects, to boost a site's ranking.

Based on this overriding principle, the ONLY criteria for whether SEO is ethical or not is simple and has nothing to do with the usage or non-usage of cloaking techniques or otherwise. It should all boil down to keyword selection.

For Example: A site that sells ringtones is spamming when it tries to get high rankings for keywords related to cellphone manuals.

A site can use all of these so-called black hat techniques, but at the end of the day, if what the search engine user sees is the kind of page he/she is looking for, then practically speaking no spam has taken place. The search engine user got the info he wanted, the search engine did its job and the SEO practitioner provided a value-added service.

Too much effort has been wasted on designing algorithms to fight black hat SEO techniques and too much effort has also been wasted on trying to get around such algorithms. The end result is ironic. Search engines like Google - which ostensibly have superior 'anti-spam' algorithms are returning inferior results to search engines which have simpler algorithms.

The enemy is not SEO practitioners who use 'black hat' techniques per se, it is SEO practitioners who optimize for keywords and search terms that do not apply to the site or page they are optimizing for.

Thursday, January 05, 2006

The Pen is Mightier than the Mouse

After using an HP tc4200 Tablet PC for a couple of months - I hereby declare that the mouse has been rendered absolutely obsolete by the pen!

Using a pen is such an improvement over a mouse that I can't wait for big screen digitizer or touch-pen monitors to arrive. That way, I can also enjoy pen usage with desktop machines and not just tablets. So far, the only touch monitor I know of is the L1510BF from LG and it is only 15" 1024x768... bummer. But I'm praying that will change quickly.

Accuracy and speed of pointing improves by a quantum leap when using pens over mice, and this definitely translates to a significant productivity increase. Moreover, the fact that the pen is far more natural to hold than mice means no more risk of carpal tunnel syndrome. If those aren't solid marketing reasons for touch monitors, I don't know what are.

The only con? Smudged screens from resting your hands on them. But frankly, the smudges are visible only when the monitor is off.

Saturday, April 16, 2005

IUnknown vs. System.Object

The dedication of Andrew Troelsen's "COM and .NET Interoperability" reads:

"This book is dedicated to Mary and Wally Troelsen (aka Mom and Dad). Thanks for buying me my first computer (the classic Atari 400) so long ago and for staying awake during my last visit when I explained (in dreadful detail) how System.Object is so much better than IUnknown. I love you both."

Every time I dip my toes into learning .NET, I wind up dismissing it as a hopelessly complex and overengineered POS, but then I encounter something that makes enough of an impression to make me want to reconsider it. This is one of those things... LOL!

Tuesday, April 12, 2005

OOP: The False Religion

Edsger Dijkstra said: "It is practically impossible to teach good programming style to students that have had prior exposure to Basic; as potential programmers, they are mentally mutilated beyond all recognition."

One look at most people's OO code and I feel like applying the phrase "mentally mutilated beyond recognition" to OOP practitioners as well. Congealed, booger-like masses of heavily-coupled classes (rendering useless the whole reason for using them in the first place!!!) and superfluous inheritance hierarchies are the norm.

Good old functions are a perfectly good abstraction in many many cases, but clearly, a new generation of programmers has been trained to believe that they are committing a mortal sin if they do not immediately think in terms of classes and objects when trying to solve a problem.

[ They should ponder this fact over and over again: Linux, the most successful open source project of all time - with a codebase worth several million lines and teeming with daily activity involving thousands of people - does not make use of classes and objects. ]

Good OO design is extremely hard such that for all but the most experienced programmers, I believe the correct design decision is to actually refrain from designing your own classes. I've come to realize that classes, because they are intended to be heavily reused, require design skills, taste and subtlety on a level approaching that required for language design and are thus not for mere mortals to dabble with. Unfortunately, most of today's popular languages, through a lack of better alternative high level facilities, force everyone working in them to become class designers.

Happily, there are environments, like Python, which allow average programmers to effectively reuse reifications of abstractions (classes included) done by those with the necessary design skills/expertise, largely dispensing with the need to do such work themselves. A good thing, since for the most part, the end results of most such efforts are U-G-L-Y, those based on classes consistently being the worst offenders. In fact, one of the characteristics of the better-designed python 'objects' is that they save you from having to engage in the gobbledygook of object think and talk, delivering not only on the promise of "usage without knowledge of implementation details", but usage without having to master an entire paradigm. This is the promise of scripting taken to a higher level.

So, to all budding Python programmers out there, please keep in mind that you can do a lot of powerful things in this language just sticking to functions and for loops and try to avoid inflicting your class designs on others until you're up to the task of designing elegant ones.

Also realize that there are much neater non-OO abstractions in the language such that classes, and specifically class hierarchies, should be considered an evil to be resorted to only out of sheer desperation. The increasing popularity of interfaces and similar mechanisms nowadays proves that inheritance - IS-A relationships - are only useful in a minority of situations and nowhere near as universally applicable as the OO snake oil salesmen of yore (mid-to-late 90s) like to tout.

Expect more traditional OO concepts to crumble or mutate as time passes to the point where what you thought of as object oriented today will become completely unrecognizable. Come to think of it, 'traditional OO' could be an oxymoron... OO is a circus: friend classes, abstract classes, refactoring, patterns, "cross-cutting concerns", interfaces, members, methods, messages, yada yada yada. The monkey-mind comes up with a new concept every 6 months...