Grenzgenial

This is my personal blog. It mainly treats UI Design, Javascript, AJAX and node.js. It's an attempt to share some of my ideas and findings I encounter, during my way of developing and working out a new startup company, that hopefully will help make the internet an even nicer place to be. It's a small contribute to making computers more intuitive. So have a nice read of my articles and if you like them, help distributing some of the concepts behind them! DISCLAIMER: All I do here is free of charge, but you can support me writing articles and developing cool new software, by flattering my entries. Have fun;)

[grenzgenial-blog]

Quicklook Mac OSX UTI Hell (or what Apple did omit in its documentation)

After some blogging abstinence I am back. And we are coming up with a really nice topic, which hasn't been blogged about out there on the web yet ;)

It's all about Apple's UTI's and what Apple omitted to say about them.

UTI's are one of the most powerful features of MacOSX and most CoreServices like LaunchServices, Spotlight and Quicklook depend upon it.

However documentation about it is unclear about which strategy applies when UTI's are missing.

So what are UTI's anyway:

UTI stays for Uniform Type Identifier, which means they identify a file type, very similar to a file extension or a MIME type, but more generic and with builtin inheritance.

So for example an image file has the UTI public.image, which inherits from public.data.

(you can learn more about UTI's here)

Ok. That's great, but where does a file hold the information about its UTI? Extension information comes from the filename and MIME types come from HTTP header information, but UTI??

Well it turns out that UTI information is stored in the extended attributes of a file on HFS+. You can show this metadata by typing mdls "filename" in a Terminal window.

The fields kMDItemContentType and kMDItemContentTypeTree will save information about the filetype and its inheritance.

But what happens if a file has not been created by a Mac OSX application and therefore has no UTI information at all??? That's actually an interesting question, cause it happens quite oft.

MacOS X will generate a dynamic UTI, but most importantly it will fall back to file extensions, which is what Apple calls "Idintifier Tags", but lets look at the information lookup flow a bit.

Lets say you have this awesome new file extension called .markdown and want to preview it with Quicklook. 

The relevant UTI information looks like this:

In case of Readme.md the relevant information is:

kMDItemContentType             = "dyn.ah62d4rv4ge8043a"

kMDItemContentTypeTree         = (

    "dyn.ah62d4rv4ge8043a",

    "public.data",

    "public.item"

)

OSX has no clue about it. So what's gonna happen? First off, OS X will generate a dynamic UTI, but that's not of a big help here. (see above)

So Quicklook will lookup the file extension and choose the appropriate program, that can 'handle' such file.

How can Quicklook know about which program is mapped to a certain file extension?

Each application has an Info.plist file in it's Contents folder. This Info.plist can contain a key called UTImportedTypeDeclarations or UTExportedTypeDeclarations, both of which do more or less the same. The first is more generic as it says, which UTI's (but also file extensions) an application will handle and registers it in the system. (The second one, says, that the application is not only able to handle such type, but is the actual 'owner' of the type).

Within UTImportedTypeDeclarations the application can then give a list of UTI Types the file type also conforms to. So an UTI inheritance list gets generated. E.g. Markdown being also public.plain-text.

So what we have till here is: file extension -> application that says it can handle extension -> inherited UTI's for file extension.

Now back to Quicklook. Based upon the file extension Quicklook will try to find a Quicklook generator (.qlgenerator), a small Plugin, that says how to render a file type. First in the Application, then in ~/Library and /Library. The Quicklook generator itself has an Info.plist, where it can communicate to the system, which UTI's (or file extensions) it is able to handle.

As a side information: Quicklook generators always renderer ouput to PDF, Text or Image Buffers.

If for a certain UTI or file type no qlgenerator is found Quicklook will display a standard dialog, but no Preview :(

As with Markdown, there is no .qlgenerator installed per default (actually one exists at https://github.com/toland/qlmarkdown, but we won't use this one now).

As Markdown actually is a text file, it would be sufficient to start of the classic public-plain-text UTI qlgenerator, but markdown has no inheritance list that includes plain-text.

However if nothing is found the next lower UTI communicated by the application in UTTypeConformsTo is taken. This is where we can hook in the magic.

So take an application of your choice (which one is not important) and paste in the following in the Info.plist.

<key>UTImportedTypeDeclarations</key>

<array>

 <dict>

<key>UTTypeConformsTo</key>

<array>

<string>public.plain-text</string>

</array>

<key>UTTypeDescription</key>

<string>Markdown document</string>

<key>UTTypeIconFile</key>

<string>public.text.icns</string>

<key>UTTypeIdentifier</key>

<string>net.daringfireball.markdown</string>

<key>UTTypeReferenceURL</key>

<string>http://daringfireball.net/projects/markdown/</string>

<key>UTTypeTagSpecification</key>

<dict>

<key>public.filename-extension</key>

<array>

<string>markdown</string>

<string>mdown</string>

<string>md</string>

<string>mdml</string>

<string>text</string>

<string>mdwn</string>

<string>mkd</string>

<string>mmd</string>

<string>rst</string>

</array>

</dict>

 </dict>

</array>

So what we have now is: file extension -> application that says it can handle extension -> inherited UTI's for file extension under ConformsTo is plain-text-> inherited UTI qlgenerator for plain-text will be used if no qppropriate qlgenerator was found before.

In order to reload the UTI table for the application, delete the app from the Application folder, then go to Trash and put it back into Applications. (Comments on an easier way to reregister the UTI's of an app are appreciated!)

and here we go! :) Quicklook for Markdown!

Please note, that it was not important at all, which UTI the file has or which application we choose, as we are (ab)using the UTTypeTagSpecification of the application, mapping an extension to a list of conforming UTI's.

Final hint: We were talking about Quicklook to find the right qlgenerator for preview here, still this has nothing to do with the application, which will be opening the file. This depends also on UTI's and File Extensions,  CFBundleDocumentTypes, Creator Codes etc. but each app registers for them seperately. There is a very nice Preference Pane, that shows all registered extensions for an application and it's called: RCDefaultApp http://www.rubicode.com/Software/RCDefaultApp/

Go get it and play around with the mappings!

[grenzgenial-blog]

Javascript and the brain: Why Javascript is the future of programming languages

I discover myself all the time comparing programming languages to brain functions. 

While I have never designed a programming language myself, I have used many of them, and think, that I know their strengths and weaknesses quite well by now. 

But more importantly, I have studied brain functions and neural sciences to some extend over the years (especially starting with reading von Neumann's and Turings books)

It is not a case that von Neumann, was also one of the founders of the computer paradigm. After all he just invented computers after the human prototype he was studying.

Over the decades however programming languages diverged from his principles and I always found myself reaching a dead end after some while with modern programming languages like Ruby, Java, .Net. etc. Strangely at first contact with Javascript over 15 years ago, I suddenly had this "feels right" feeling, but couldn't describe why. Today, after some more years and some more experience with computer languages, I finally understand why Javascript not only feels right to me, but objectively is the right language for building future applications.

Let me explain why:

Preamble: I must explain some basics of how basic brain functionality in order to explain my conclusions:

The brain is a neural network

Neural networks are connections of neurons

Neurons are cells

So what's the brain for?

The brain is a world simulator. It's a big approximator. It takes input from it's senors (the eyes, etc.) and produces output (which in someway should reproduce what's happening or will happen in the real world)

How does the brain do that? It does it by a process called "learning", which was studied quite extensively by von Neumann, reaching also very surprising conclusions about the learning process itsself. All that neural networks do, is they modify their connection weightings all time, until the output produced by the network is coherent to what the sensor input says. It's some sort of "Calibration" that takes place during learning. When you learn things right, chances are you will make the right conclusions, before things happen, and you probably will survive. Yes, you see that car rushing at you with 100 km/h. Well your brain should be able to precalculate, that if it continous on its trail like that it will just hit you in the next minute. Therefore it's better to jump in the bush before. Your brain might even be able to precalculate, that the driver might be drunk or that he will see you in the next 20 seconds and therefore tell you to wait a moment to not make too fast or early conclusions. Your brain is fantastic!

Ok. Probably you knew this already.

What does this have to do with programming languages?

Well. If you think about the above, there is a powerful conclusion you can make, which is:

The brain is a (sophisticated) computer! It's a big processor. But most importantly and this is what computer languages forgot over the years. It's a parallel processor! That's what most programming languages are not. They just took some of von Neumann's paradigms, but forgot about the most important ones. Parallelism and self modification. Aehm, self modification? Yes, the brain modifies it's functions by learning. Neural networks function, in that electronic impulses coming from the human sensors, run through it parallely. It's evented non-blocking IO. Yes! I hope now you understand the hype about node.js. Node is an evented non-blocking IO framework written in Javascript.

 Ok so let's see why Javascript fits in perfectly in imitating the brain.

a) No types: types are stupid. The brain has no notion of a type. A neuron is a neuron. A type is an artifical creation of computer scientists, in order to distinguish, what an object can do. It turns out, that object are actually all the same. They are objects in OO programming languages. The type comes over their metadata and the objects they are connected with in memory. In fact one of the big "revolution" in OOP languages was to move away from basic types like int, float, etc. to a generic object oriented model. However still some languages use types to distinguish such basic objects. It's not necessary. The compiler can find out by itself over heuristics. That's what Javascripts tracing JIT does! And as we see in the last years with Tracemonkey, Spidermonkey and Google V8 or Crankshaft it starts doing it really well and fast!

b) Dynamic: Javascript is a dynamic language. This means that code can modify code during runtime. This was something like the devil for programming language designers over the last decades. They thought it was evil to do that and would lead to code, that wasn't clear anymore and so they tried to prevent such use in their languages. Well it turns out that they were wrong. Self modifying code will be the future, and while we are not there yet, I think it will be the 4th and last revolution in software design in this century.

c) Functions in Javascript are first class citizens: Well to explain this I have again to make reference to brain functions and "brain functions".

What are equivalent to functions in the brain? Well the brain has no distinction between functions and memory. Everything is taking up memory in the neural network. Functions and data. But Functions are like a set of neurons, with a specific scope. That's data (signals) runs through them to produce some output data (other signals). In fact the way this works in Javascript is completely the same. Functions are just again objects in memory and thus can group functionality. Not only! They will also map to process memory perfectly.

The objects that run through such functions are electric impulse codificated objects coming directly from our sensors.

In computers sensors quantize these information to 0-1 bit streams.

So a binary diff function somewhat operates however on the same memory and therefore is a first class citizen. That's why javascript is the future of languages, cause it treats functions as first class citizens, whereas other languages don't.

d) Javascript scope and closures: Javascripts scope keeps your working environment and variable in place, also after you come back from some asynchronous function. This is important and is like the brain is connected to neurons it uses more often in a more "near" or "local scope" fashion.

e) IPC communication: well todo communication we need to marshal data in a protocol. The way this is done nowadays is mainly http. And parsing text on both sides. Javascript is a perfect fit for this with it's human readable JSON object notation.

f) Push and not pull, and Javascripts event model: The brain works by emitting electrical signals to connected neurons. The brain doesn't "call" functions it always "emits" events. In computer science it is well known by now that passing objects to functions leads to tight coupling, which makes code less maintainable over time. Javascript although it is not perfect has a quite simple notation for emitting events. Whilst other languages can do that too over patterns like inheritance, delegates and interfaces or notification centers. Javascript's implementation is more powerful cause it uses simple function pointers, which are more leightweight, than passing around objects.

g) Inheritance, Annotations and Mixins: The brain has no notion of inhertitance. It's an interconnected graph so there is no hierarchy. While other languages try to create object hierarchies through inheritance, Javascript doesn't. Instead you can modify or extend every existing object or just "connect" to it over a pointer. That's why Javascript immitates better the connection between neurons, than any other language I know.

This article was really fun writing. I think creating the brain analogy was a good idea. Comparing programming language features to brain functions, somewhat works quite well, so this means that there is a strong correlation between the two.

Have another brain analogy. Post me a line.

[grenzgenial-blog]

Wikileaks and the definition of "secrets"

It's in these days and weeks, where everyone talked about wikileaks and it's founder Julian Assange, that I read much about national security and secrets, but I realize, that what people mean with these terms and what they really stand for are somewhat completely different things and that's what makes the discussion full of misunderstandings.

E.g. today I read the following note:

"he [Mr. Assange] doesn't accept any secrets of governments, whereas he himself makes heavy use of them with his project Wikileaks".

I want to analyze, the sentence above and show, why this is a wrong conclusion.

First off I want to explain the simple and powerful concept of Wikileaks. Wikileaks is all about transparency, to fight corruption and abuse. Nothing more nothing less.

It's about bringing transparency to where concentration of power runs together and where wrong decisions can really be threats for society and humanity, meaning in governments and big societies.

As soon as you understand that, you understand that Wikileaks is not a threat for democracy, but the fundamental of it. No government or company has the right to preclude information from the public.

Does this mean, that there don't have to be secrets anymore? Absolutely not! 

But lets analyze the term secret a bit more:

A secret is something, that only some people are authorized to see. Not everyone. It's about authorization in a value system. Who can see the secret? That's already more difficult to define: In most cases there is a fine grained hierarchy of "trust", that determines who is authorized to access secret information and this shows already, that secrets are somewhat "unnatural" to nature and difficult to handle. After all it's human being accessing secrets.

What kind of information might be secret?

- well obviously the information must have some value. It is not your shopping list. What's the highest value an information can have? When information becomes so filtered, that it becomes knowledge. Does knowledge have to be secret? No, knowledge is a public porperty of humanity. So what has to be secret? Well it turns out, that there are not many informations, that have to be kept secret. In nature secrets don't exist! And there is a good reason for it. The natural value system regulates itsself by weightings. So authorization is replaced by heuristics. That's how humans act between each other. You won't tell all your private things to a perfect stranger, but perhaps to your mother. That's because, your mother has a higher rating of trust in your brains neural circuit. 

I have always wondered, how potentially insecure networks, like e.g. credit card networks are after all quite safe. Well it turns out, that they make heavy use of these heuristics. E.g. they can detect over mathematical algorithms, if an access pattern is somewhat "unnatural" to your normal behaviour and block your card. As a simple case immagine your credit card is stolen and someone is continuously accessing your bank account from abroad. This is an unnatural context for your normal behaviour and might therefore be detected by the system as a fraud.

After this excurse, I want to go back to the initial question:

Do states have to have secrets?

The answer is yes, until we don't live in a perfect world, states sometimes must have secrets (especially, when it comes to national security), but most of the time the answer is NO! Why? Cause states are only legitimated by the civilization itsself. (It's the people who finance governments, it's their money!). So everything they do must be transparent to the people. Governments don't have to ask every individual its consent, but it must be transparent, what they intend to do and how they gonna spend the money. I am really astonished these days, to see how many politicians and journalists seem to not have understood this.

Does Wikileaks have secrets? No! Cause Wikileaks is not about authorizing anybody to have the information, the information is completely public. It's about anonymizing the source of the information so that no one not even Wikileaks itsself can find out where this information came from and trying to make sure the authenticity of it,  This is fundamental in democracy (see the constitutional anonymity principle in elections).

So to keep the conclusion of this article short:

When people talk about secrets, they should differenciate between authorization and anonymizing!

[grenzgenial-blog]

Sammy.js and Express.js the dynamic Duo for progressive website enhancement

I could have called this blog article Sammy Davis Jr. and Frank Sinatra - Me and my shadow, but no one would have understood, that this is all about fancy web development and Node.js. However after you have read this article, you might actually think and smile, about what a good fit this title would actually be...so let's go:

Yeah, we all love the fancy world of AJAX, but unfortunately, we don't live in a perfect world. When it comes to publishing real world apps to the Web, normally the first thing you encounter is the world crashing in your face, cause you start to test your page in non fancy browsers (yeah talking about you here, IE ;)

I follow up to the great writeup from Ben Nolan and Dav Glass upon how to do progressive enhancement with node.js and the concept of serverside DOM rendering of javascript, if for some reason it is not available in the clients browser. 

While Ben's writeup is somewhat theoretic and involves Firefox pushState functionality, Dav gives a real cool demo with YUI 3. 

All this fancyness however comes with higher complexity...so I actually left it apart until I discovered Sammy.js a week ago and hey, saw it clear in front of me: That was the solution to progressive enhancement we are all searching for!

What's Sammy.js and what does it have to do with progressive enhancement?

Sammy.js (yeah Sammy David Jr. inspired) is to the clients browser, what is Express.js (Sinatra inspired) to the server. Or to put it simple, Sammy.js is all about encoding AJAX state on the client into the hash URL, whereas Express is about serverside routes = encoding serverside state into the URL.

What is so beautiful here is, that while both do substantially the same, but one on the client to enable your seemless AJAX navigation, and the other on the Server to prevent you from writing strange regexp patterns and do unfancy URL parsing, the way they encode state is quite the same: they both use URL encoding.

So let's look @ how Sammy encodes an URL:

  // string get('/user/:id', function() { ... });

And now lets look @ how Express encodes an URL:

app.get('/user/:id', function(req, res){ ... });

Looks familiar? This is because both use "routes" as there way of mapping query strings to variables, so in the above example, user:id could be the name of a user to search for.

With sammy, this search would happen on the client involvimng perhaps some AJAX request to the client. With express this search is done on the server.

All things are beautiful here, cause Sammy will keep away nasty problems developers had to face with AJAX development. E.g. the browsers back button not working. Sammy does it all for you and it does it the same way as Express does it on the Server!

Well, so how do you connect both up together:

The point is you don't have to do anything! If the browser has Javascript support, Sammy will disable the links (prevent the default action for clicks) and handle them with Sammy's  Javascript functions instead.

If there is no Javascript support, the Browser will simply call out to the Server and Express will handle the request, like in a normal Client-Server scenario. 

Well there is one Gotcha however. AJAX apps normally do massive clientrside DOM manipulation, whereas this cannot be done on the Server normally.

Well fortunately there comes some help from Elijah Insua and his awesom JSDOM project on Github. JSDom basically is a serverside DOM parser and enables you even to use JQuery on the server.

So big up yourself and get fancy with Sammy and Express!

[grenzgenial-blog]

javascript console.log revamped with stacktrace

This post is a small tip about how I revamped console.log.

Actually console.log is a handy function, but having a stacktrace at the time of the log would be sometimes nice. Therefore I wrote a log function, which keeps stacktraces of the log in a global history. So you keep logging as before and when you need more information you can get it from the global history object. The idea for this came to me, when I saw a similar implementation from Paul Irish (without stacktrace though).

so I revamped it to something like this: 

Try it out in console:

[grenzgenial-blog]

Security - Google Chrome Background Pages

UPDATE: Actually Chrome Extensions do ask you for a permission, when you install them to have privileged access to certain domains, which they couldn't access due to Cross Domain Origin Policy. However this just means, that e.g. they cannot do e.g. a POST to yourbank.com, if you hadn't allowed them. But nothing hinders them to spy on your passwords, etc.

This is a fast writeup of what came to my mind today. As the Browser is always more becoming a Platform for "Applications" (Extensions) to run on, I started thinking about some security implications today.

I am using the Google Chrome Extension API lately to develop for a Google Chrome Extension.

I realized quickly, that many many extensions can load Javascript (so called contentscripts) on every page, doing all kind of weird stuff.

This is nothing new, cause everyone knows that Javascript is not safe right? Well no!

Javascript is as safe as any other language, but the point is the architecture of Web-Browsers today allows extensions to run scripts and potentially, spy on your web-browsing, banking activities and so on.

Background pages and content scripts are actually a big security flaw. Just immagine only some things they can do:

open and close tabs in the background

click ok for you somewhere in a page (e.g. while you are authorizing someone via oAuth)

listen to keystrokes

make cross-domain XMLHTTPRequests in the background using or transmitting your session secret and/or banks mobile TAN.

The only "normative" force is that extensions are actually delivered in Javascript and therefore can be inspected by developers. So normally they won't do weird stuff. But anyways, who knows?

I think Google should start allowing only signed extensions, which they have reviewed to not do any harmful stuff, similar to how Apple reviews their apps and let only signed extensions run on the Google Chrome platform. By the way the same is true other web-browsers like Firefox and IE9 too.

I think Safari is the only browser allowing only signed extensions, which is a big plus.

Comments are appreciated!

[grenzgenial-blog]

How to manually set a breakpoint in Chrome / Firebug / Firefox

I just found out a feature of Chromes debugger today, that I was searching for a while, but never found out:

How to set breakpoints in code, so that when you run over a function the debugger will automatically stop at that line of code.

Whenever you use the special keyword debugger in your script, FireBug / Chrome will treat that line as if it was a breakpoint, and stop your script right there.

This is so handy! Of course you can still set breakpoints by clicking on the line number in debugger.

So have fun debugging your code!

[grenzgenial-blog]

Google TV vs. Apple TV / Apps and the UI

There are some unsung revolutions coming up this year.

While Microsoft and the others are chasing behind to catch up on the mobile market, but will always remain one step behind with Google and Apple, both companies are already up into other things, especially TV.

So fresh so good. Google is here with the long awaited Google TV and I must say "Yeah I like it!". 

While there has been some buzz around Apple's TV, presented last month, but always declared a "hobby" of the company, I think Google TV has taken the right direction and introduced some really nice new features, especially one: Apps for TV.

While the idea of Apps, could actually come from Apple itsself (see the iPhone), Apple TV lacks to become the platform for Apps, the iPhone became. Hey you Apple guys, I think this was a big mistake and I think it is the real revolution behind Google TV.

I think, that its clear by now, that TV's need some update and especially need their own UI and controls to interact with. It's similar to how the iPhone revolutionized the mobile market, with it's innovative touch interface.

You cannot just bring a classical webpage like Facebook to the TV screen, you have to modify it, to make use of TV's features. (see my follow up guide on UI design for TV apps)

The combination Google chose is great, and is the same that Apple chose too, a mobile device, like the iPhone, with a rich UI as remote control and a TV as the screen for it. Apps for TV will have to be developed to render pages, that look nice on a big screen, while still being used from a cell phone device. (Googles Android and iPhone being a good platform for that)

Google TV (contrary to Apple TV) also greatly interacts with the "old" way of watching TV, making it a good start of migration to some sort of web based TV, that Apple TV is.

So while Apple TV is becoming more the "video recorder" substitute in our homes making it possible to rent and buy films, Google TV is becoming the "set top box" substitute, making it possible to connect to your Satellite, the Web and see webpages on your TV screen. 

So ok Google, I think you got it good this time! I think we will see many cool apps come out for Google TV in the next time.

Here is my comparison to what are the main differences and "killer" features:

Apple Tv vs Google TV:

Sources:

GoogleTV:

classical: Satellite, TV 

new: Web

AppleTV:

classical: no 

new: iTunes Store for TV shows and films

Stream vids to the TV:

(through vids on it from iPhone, Mac)

Google TV: no, yet?

AppleTV: yes

Stream from it:

Google TV: no, yet

AppleTV: no

Remote control it with your phone:

Google TV: yes

Apple TV: yes

Apps:

Google TV: yes

Apple TV: no

[grenzgenial-blog]

Debugging Node.js with Node-Inspector

Today I had another mind-blowing experience.

As I was writing a software project in Node, which has reached it's critical level for me, where I just don't want to go on, with sys.puts and sys.inspect to find out, what my code is doing, I was in search of a Debugger for node.

Yesterday I tried out Cloud9's Javscript IDE, but while being really a great project, is still in the very beginnings and I wasn't able to set breakpoints in Chrome nor in Firefox. Perhaps I was doing something wrong, but it just didn't work out of the box for me and I couldn't find any documentaion yet. Anyways, Cloud9 is going to be really a great IDE some day!

So I was tinkering around and remembered, that I came accross a link to a project that involves Webkit's Web Inspector as a debugger for Node.js. The Project is called Node- Inspector.

A npm install node-inspector gave me a good start and I got all that was necessary on my system.

Node-Inspector itsself is written in Javascript as it should be and runs with node. ;) The way node-inspector works is that it spawns a Webserver on port 8080 by default, where you can see Web Inspectors debugger Interface. Then it connects to Node's Debug port, which in my case is 5858.

There is some confusion in the Readme and the screencast of how to startup node-inspector.

However a fast node --help, made things clear.

So here is my Installation Instruction:

Start node-inspector, by typing: node-inspector& (this will start the Webserver)

Startup your favourite Webkit browser (e.g. Safari, Chrome, etc) and go to 127.0.0.1:8080

start node with the --debug-brk option. This will start a TCP debug port at 5858 and set a startup breakpoint on the first line of your Javascript file.

So if youR Javascript file is called "hello.js".

node --debug-brk hello.js will startup things.

Now go back to your browser and hit the "Connect to Node" button.

all your node are belong to us now!

Web Inspector is about the greatest debugger around and seeing it full screen debugging node is just mind-blowing cool!

So check it out!

[grenzgenial-blog]

Why Windows Mobile 7 should be a fail (AGAIN)

There are companies, that will never learn. One of them is Microsoft.

I thought, I will never blog about companies and stuff, cause this blog is mainly intended to my writeups about AJAX geekiness, but the news and writeups spreading on the next "big thing" from Microsoft urges me to share some thoughts, about this "new" phone operating system.

What I see from the videos on Youtube is a far from complete phone operating system.

Rule No #1: Free Markets and the Killer Feature

Dear Microsoft, there are markets, which you don't conquer being "fast", but only having a killer feature. While Microsoft was not fast at all, since the iPhone is dominating the Market with it's innovative design and features since 4 years, Windows Mobile 7 was anounced only last autumn. So while Microsoft's decision was to launch Windows Mobile 7 in these months, it is still is to see if there is enough innovation in it.

Of course in pay markets also price plays a role, and Microsoft can surely be competitive, if they want to (by greatly reducing their profit). In fact Microsoft will not make any profit at all with Windows Mobile 7, cause there is already a cheap (cause free) OS in the market: namely ANDROID from Google!

I think, that from, what I see Windows Mobile 7, doesn't offer any feature, that you won't find on iPhone.

Rule No #2: Save costs by using a common codebase

Windows Mobile 7 seems to be built on Silverlight (Microsofts proprietary Flash software). This means, that developing Windows Mobile 7 and Windows are two completely different things. No common codebase (Silverlight) is bad for costs. 

Rule No #3: Innovation in the UI

I do not see any innovation in the UI: Despite some "Widgets" which you can put on the start screen, and which will clutter up the Home screen even more, than Apple's app centric approach, I don't see anything new! 

You must think, that this is the best Microsoft's engineers seem to be able to come up with at the moment!

While with Windows the excuse has always been, that Microsoft can't confront people with too radical changes in the UI (although windows made such changes, not for the better, by introducing even more substructures and even more complicated workflows), with Windows Mobile 7 they had the opportunity of a fresh relaunch.

Well, for me the conclusion is clear from what I can see this company completely lost its way to innovate.

Well, all this of course, doesn't mean that Microsoft cannot improve, and that consumers won't buy the phone anyways. People most often don't even know, what is the operating system on their phone and Microsoft has good distribution and marketing channels, but I don't believe they can do it with such a product. Let's see, what will be the consumers choice!  Anyways I am waiting for the big Web OS re-launch next year. I think, that HP is doing really good in waiting the whole buzz this year, and then coming up with something mind-blowing for the beginning of next year. I still believe that WebOS is going to be the real competitor of the iPhone!

[grenzgenial-blog]

Why OAuth Specification 1.0 is a quite big security flaw / IETF get moving!!!

I actually have been a big fan of OAuth and its usage, until I didn't read how it works, yesterday!

Let me say that, while offering some security, OAuth is not safe for work at all!

Read the article about at http://hueniverse.com/2009/04/explaining-the-oauth-session-fixation-attack/

This is not a small security hole, it's a flaw by design!

So I read, that OAuth 2.0 is the next upcoming version of OAuth and already implemented e.g. by Facebooks Graph API and Github. However the draft is still under development.

UPDATE: After having read the OAuth v2.0 specification as far as I can see the problem has been resolved, cause the spec. requires now TLS for authorization requests and generates the token on the server and not on the client anymore, which however could be sniffed, if it wasn't for the TLS mechanism.

So what's the issue with OAuth 1.0 all about?

How OAuth authorization is working:

A consumer makes an authorization request to get access to the users data. (Actually he gets authorized to see some of the users data, not all). To enable this, the consumer therefore receives a so called request token, which then gets transformed in an access token + an access secret (all depending on the request token), which is not exchanged securely or over an encrypted channel, but just appended to the URL.

How it should be working:

The request token secret should be transmitted over a secure (encrypted with public key of provider) and authenticated (both sides know who is who) connection (similar to how the SSH Handshake works).

In fact the session fixation attack uses this flaw, in that:

In the authorization workflow, the user authenticates ("signs") a request secret generated on the client and appended to a request URL, to be authenticated to access users data, which is ok under normal conditions, but the problem is, that an attacker can read in plain text, what the request token secret is (cause its not transmitted safely).

Substantially OAuth 1.0 is giving the master secret ~ request token to everyone.

Now even if a server developer limits the requests to only originate from the client(=consumer) an attacker can still hijack this mechanism by making a request "over" the consumer by using the request token and thus giving him access to the result of the request! 

Note: although the request token is not the shared secret it directly "leads" to it, thus making it "equivalent" in many ways to the master key. Of course an attacker still has to go through the consumer site, which will do the calculations necessary to access the users data for him (request->access token secret) + signing (=hashing over consumer key and access token secrets), cause the attacker has none of them, and you could built infrastructure, thats lets this be done only by authenticated consumers. But even if consumers are authenticated, as you see, you can still go "through" the consumer and get out the users data!

Even worse with IP and domain poisoning, an attacker can trick the whole machinery (e.g. the service provider) into believing, he is the consumer and do the whole access key + hash calculations himself, thus even getting out access keys, etc.

This attack just wouldn't work, if consumer and provider were authenticated to each other over a secure HTTPS channel.

[grenzgenial-blog]

Google Percolator, Core data, CouchDB and the real time indexing chain

It was really a great read today, to see how Google re-vamps its search infrastructure to get even more real time search results.

http://www.theregister.co.uk/2010/09/24/google_percolator/

I think Googles instant search together with Percolator is intended to offer realtime updates to Googles index.

A Google bot makes such trigger happen (being effectively a pull request) and then pushes that through their Percolator pipeline so that results show up in the index nearly immediately.

This is needed for data, where real time is important like news, twitter feeds etc. 

I think the more elaborated information becomes the less important real time gets!

However it great to see Google innovate and always be one step ahead to its competitors.

The problem is, that if small portions in a document change, especially with regard to links to other web-pages, Map Reduce has to process the whole data set again, to update link counts in other documents for Google's Pagerank algorithm. In fact such link counts represent some sort of "dynamic" data in the database, thus making them not get updated automatically by the MapReduce algorithm.

In fact what's happening here, is that, some objects in the data pool, contain "aggregate" data about other objects.

The way Percolator does these updates, by using, what they call "observers" reminds me much of how you can subscribe to update events in Cocoa's Core Data using Key Value Observing mechanisms.

In fact immagine you have an application with a departments and employees table. Lets say, you want the number of employees in a department be stored as a property of the department. In Core data you can subscribe the departments attribute, to get notified, when the employees change, thus automatically updating also the departments table.

What Google did here, however is make this step completely integrated on a database level, which is really where it belongs to be!

Above is particularily interesting, as I was thinking of using CouchDB for my upcoming project, which will use real time data and was interested the limitations of Map Reduce Tables described in above article are generic to every Database and therefore also exist also in CouchDB.

The short answer is unfortunately: YES!

There is no database (RDBM or document based) I know of, which doesn't have this limitation. (Correct me if I am wrong in the comments section)

So first lets take a look at CouchDB's implementation of a Map reduce algorithm:

I read the CouchDB View Index Updates Implementaion, and found out, that it is important to note, that views are updated lazily and incrementally.

How CouchDb works:

CouchDB substantially is in first just a big set of unrelated data (documents) on which it imposes so called "views" which are B+Trees upon such data. The B+Trees are actually the efficient way to access and search the data. They are "paths" into the data. You can lookup data from different point of views (hence the term "view") E.g. by location, time,etc.

Now if new documents get added to CouchDB the index gets updated incrementally, looking first for changes to the DB , that arrived since the last View calculation and updating the B+Tree.

Now does this mean, that our data will get updated automatically.

No, this just means, that the B+Tree gets updated, the documents themselves remain unmodified! 

This means, that also CouchDB has this limitations.

I am really looking forward seeing someone implement Percolator in CouchDB!

[grenzgenial-blog]

YQL website scraping with pagination

Recently I wrote about pagination and why the way it is implemented in major websites, represents a major UI design mistake.

While the idea of limiting the results per page is a good one, thus greatly reducing load times and server load, it makes websites inefficient and complicated to use.

Today I want to talk about a further drawback of pagination, especially when it comes to retreiving information from websites, that don't offer RSS feeds or any other form of machine readable data. The process of retreiving such information is called: website scraping.

The use case:

I recently needed to get the email addresses of all doctors in my area. While public yellow pages exist that offer such information, they all present their results in form of about 10 results per page. 

This is obviously a problem if you have more than hundred results and each one has the email address on a separate details page.

Well, if you are like me and don't want to waste your time going through each of them one by one, but instead prefer spending your precious time on finding out how to get this stupid job done by a computer, then hold on. Here is the solution:

The solution:

This is where YQL comes into play.

If you don't know about YQL yet, YQL is a free webservice offered by Yahoo, which substantially lets you scrape any website, with a common SQL-like query syntax and using Yahoo's botnet to get your data;)

Lets look at a simple query statement.

SELECT * FROM html WHERE url = ‘http://www.amazon.de’ AND xpath=’descendant-or-self::title | descendant-or-self::meta’

This returns all title and meta elements in the amazon.de website. You can try this query out here.

What make YQL even cooler, is that you can create your own tables, which is what YAHOO calls open data  tables. These tables, can run custom functions on Yahoo's servers to make the queries even more sophisticated. Immagine it like being some sort of stored procedure for YQL. The cool thing about this is, that you can write such functions in Javascript, then upload them to your server and Yahoo will do the rest for you. This makes this tool a super-potent-nuclear-weapon scraper.

This is what I needed to get the pagination under control:

First lets see how a query looks like:

select * from {table} where url="http://a-paginated-website.com/page1" AND xpath="//table[@class='results']" and paginationXPath="//li[@class='next']"

You first select the custom table (in my case the table is called otb. This is defined in the xml file that describes the table.). Then you pass in the following parameters to select:

url = the url of the first page you want to scrape

xpath = an xpath describing the content you are interested in (if you xpath is uncommon to you check out the great pages about xpath at w3schools.com

paginationXPath = is the xpath leading to the pagination link on the website

Now lets have a look at the javascript for the YQL table:

var paginationUrl = url; var i=0; var responseData= []; var data; while (true){ data = y.rest(paginationUrl).accept('text/html').get().response; responseData=responseData+y.xpath(data,xpath); var x= y.xpath(data,paginationXPath); if(x.length()!=0){ paginationUrl =y.xmlToJson(y.tidy(x)).html.body.a[0].href; y.log(paginationUrl); if (paginationUrl.indexOf('http://')!=-1){ continue; }else{y.log('not a link');}//but continue }else{ var XMLresponse= y.tidy(responseData).body.a; response.object = {XMLresponse}; break; } }

What this does is the following: 

starts an endless loop

makes a request to the url provided in the select statement

gets the content selected by the xpath and concatenates it with any result from previous runs

gets the pagination link specified by paginationXPath

does some logic to ensure, that we actually found a valid link to the next page

loops through all pages that have a valid 'next' link

when there is no further link, writes all data in the response object needed by YQL to return results

That's it! We can now scrape through hundreds and hundreds of pages ... and get back beautiful JSON!

You can download the full definition of the data table here and a run a full query here! Have fun;)

P.S. there are some considerations you should keep in mind, while using this

YQL spiders run under the name "Yahoo Pipes 2.0"

when a request is made, YQL looks in the robots.txt file on the server to see if scraping of the website hasn't been disabled. If it is disabled, YQL will not scrape the page!

YQL's timeout is set to 30000 ms. If your query exceeds this timelimit it will get aborted. I have no idea, if it is possible to circumvent this!

[grenzgenial-blog]

UI Design: Modal dialogs and Lightboxes: A common UI-Design mistake in websites and some workarounds

I wrote about pagination as a common UI design mistake in my last post. This time I want to talk about another common design mistake: Modal Dialogs a.k.a. Popups.

Modal dialogs (e.g. lightboxes) One common design mistake in webdesign and UI design are modal popups done with DHTML techniques. The most common being some form of lightbox, slimbox, etc. Whats wrong about popup techniques? Popups are always obtrousive, as they overlay the user's screen and the user's interaction with the page. They are a clear statement to the user. The statement is: "I am not part of this website!"

I personally know just one good reason, when to use this technique and it's, when you actually want to tell the user, that something is not part of your website. For example if you have to bring the corporate identity of a 3rd party website to your website.  An example: Let's immagine you have to authenticate your user with a common authentication service (E.G. Facebook Connect OR Twitter) or for a 3rd party payment service (e.g. Paypal). In this situation you want to give a clear statement to the user: "Hey this is the official Facebook site!" or "You are now redirected to Paypal!". In all other cases there are other, much more effective techniques to use. Some of them being fixed or slideout panels, menus, tabs, accordion panels, etc. I personally like everything that fades in and out with come cool animation, but that's individual. What is more important is picking the right size of your panel, it can even be fullscreen! The most common mistake I see is, when websites want to display images or videos in a gallery.  Normally websites display small versions of images somewhere within the website and when the user clicks on such an image, present a larger version of the image to the user. And where do they show it? In a lightbox! Don't do that! This is a complete fail for 2 reasons: Not only does a lightbox waste precious screen estate, which could be used to display details of an image, it also makes the rest of the page become unusable. Moreover many Lightbox implementation just close, when you click on a small close button, whereas they should close as soon as the user clicks somewhere outside the dialog! However, what I want to say, is that lightboxes have nearly no benefit at all. Your user wanted to see the details of an image and you just showed him half, while disabling the whole page! Remember: If a user clicks on a detail, he wants the page and controls out of the way and just see as much of a picture/video as possible. So you want to give the picture or video as much space as possible or as much as the user has available and display it to him in fullscreen mode. UPDATE: Sideways jQuery Plugin is a good example of how to do image galleries right.

There is one exception to this, which is Previews. Previews work differently, in that the user, wants a big representation, but wants to be able to switch back to the website immediately. But again you won't display previews in a Lightbox, because, when the user displays a preview, he wants to keep control over the rest of the page , so one good way to display previews is in a non-modal, tooltip-like fashion and not in a lightbox! The worst things you can do with modal popups:

  The worst things you can do with lightboxes,  is putting them into scrollviews or scrolling divs. Most interestingly even Google makes this mistake in its well designed Google AdWords page. Huh? Where are the controls here? How do you close this window?  

Ahh, the close button scrolled of the page ;) Please: Don't use modal dialogs in scrollviews! Instead use full screen centered dialogs and if not all controls fit in the window, don't make the dialog scroll but instead give scrollbars to the dialog and make the close button fixed on screen, so it cannot scroll off the screen like in the above example! 

Make the web a better place, by adopting these techniques!

[grenzgenial-blog]

UI Design: Pagination: A common UI-Design mistake in websites and some workarounds

Today I would like to introduce to you a very common UI design mistake, still encountered in many major websites today.

Pagination: While pagination itsself is a good idea and actually a very common technique to save load time and reduce server load, the way it's implemented in many sites nowadays is just not user friendly at all. For anyone who doesn't know, what pagination on websites is, here is an example: Pagination is a way of providing a limit and an offset  to the number of items fetched e.g. from a database and presented  to the user.

The problem with pagination is, that the user has to reload the whole page, thus having to deal with long response times waiting for new data and doing nothing. This completely breaks the user experience, which should be much more fluid and dynamic. So how can we do pagination right? A common technique used today to do pagination is the AJAX lazy loading technique. (I will explain this technique in detail in another blog entry so stay tuned;)). Such technique is applied e.g. by Tumblr.com to load Blog entries. While I don't see any good reason for webdesigners today not to use such techniques, they are still not very widely adopted. The AJAX and DOM manipulation needed is actually available nearly everywhere, even in very old browsers and even if users have Javascript turned off, sites can provide fallbacks to classical pagination links.

Most notably even big sites like Google and Amazon use old pagionation techniques. But this doesn't make them more acceptable! Instead it's just a sign of how old these pages actually are and how slow innovation is moving towards... Fortunately there are workarounds available in form of browser extensions: One of them is called AutoPagerize, and is written by a Japanese guy. (Fortunately Google Chrome has the ability to translate Japanese pages into something I can read and understand too; I really love to read the twitter feed of this guy in Japanese!!)

The extension is available for Chrome/Safari and Firefox. With the extension installed you can now do AJAX pagination in all major sites, including Google, Amazon, etc. It's one of the rare extensions, that after having them installed you get this "Man, how could I live without it till now?" feeling. You "feel" the difference! Well, that's what good UI design is about after all! The way the extension works, is, that it comes with a preset of so called "SiteLinks". SiteLinks are XPATH descriptions, which for a certain page define, where to find pagination links. What's even cooler is, that you can provide further SiteLinks to AutoPagerizer over the WeData.net Wiki. WeData.net also provides an API to post new SiteLinks to it in form of key/value pairs. So if a page has no pagination info available yet, why not write one of your own?  

[grenzgenial-blog]

Inspecting cookies using Web Inspector's / Firebug's console

Ever wanted to know, which cookies are set for your domain?

Modern Browsers often have the possibility to see the cookies saved on your system.

Google Chrome even has a very detailed list under "Preferences / Show Cookies and other data for websites", which also gives you the possibility to see if a site uses HTML5 LocalStorage.

However there is a simpler trick: Just open up Web Inspector in Google Chrome /Safari or  Firebug in Firefox and type "document.cookie" in the console window. This will show you all  cookies for a given website.

Cool isn't it?

[grenzgenial-blog]

Let's start this blog

function foo() { var me= { id: dotmaster, age: 35, nationality: "Austria", twitter: "www.twitter.com/dotmaster" properties: [ "Enterpreneur", "Manager", "AJAX Geek", "Technologist", "Awesome Coder;)" ] }; return "Hello World!"; }