Little did my happiness last for updating the blog to b2evo 2.0.2, since no longer thereafter did 2.1.0 come out. Oh well, you can't beat fate, today it's time to update again.

This time, nevertheless, it's been a bit easier with a dash of version control using git. Previously I used to just "hack away" some changes, with no control altogether. You know, it's just a blog. Yet time passes by, and thos lonely changes became a bit, and a bit more, until in the latest updates it turned out I had to apply all of 10 to 15 different "patchsets". Too many.

Sadly, this did not prevent some changes in the skins API between 2.0.2 and 2.1.0 to wreak havoc among some parts of this skin, mainly the status info for each post and the list of previous posts. Time ago did I think about moving them to their own plugins, more so now that there is widget support... but right now let them just be temporarily disabled.

Meanwhile, I'll make the most of this change and get some more pieces of the skin converted into widgets/plugins, so that future upgrades would become even easier, perhaps.

I've just come across a great article at the WTF blog, The Mythical Business Layer... with some amazing comments. Not all of them the good kind of amazing, though.

Some people seem to get mixed up about two terms:

• Specification
• Implementation

While any kind of duplication at specification level would prove catastrophic when trying to make any changes, duplication at implementation level is a MUST for both a good user experience and a well secured application (aka: good software). That leads to a third element: tests, which are the correct way to join a specification with no duplication, to an implementation with more or less duplication. Any time specification logic changes, all tests should fail. Any time some implementation logic changes, it's test should tell you if it complies with specifications. It's as simple as that.

All this talk about having a "good" framework -or whatever- in order to get rid of logic duplication at the implementation level, for some kind of "big enterprise applications"... it just gives me the creeps.

Of course, if your "specification" is actually your implementation, you may be in bigger trouble already. That is, unless your project is some kind of free software with more developers than you actually need (think: linux).

I've just switched from Mandriva to Kubuntu some time ago, and one of the first things I noticed was the lack of buttons for fast-switching between view modes.

Ok, so I don't really have the time right now to write it up properly. There ya go a dirty notepad sheet for all ye interested.

This is a dynamic list of actions. You can move it, but if you remove it you won't be able to re-add it.


~/.kde/share/apps/konqueror/konqueror.rc
...
<gui>
 <MenuBar>
  ...
 </MenuBar>
 ...
 <ToolBar newline="true" noMerge="1" name="locationToolBar" fullWidth="true" >
  <text>Location Toolbar</text>
  <Action name="back" />
  <Action name="forward" />
  <Action name="up" />
  <Action name="home" />
  <Action name="reload_stop" />
  <ActionList name="viewmode_toolbar" />
  <Action name="clear_location" />
  <Action name="toolbar_url_combo" />
  <Action name="go_url" />
 </ToolBar>
 ...
</gui>


http://en.archive.ubuntu.com/ubuntu/pool/main/k/kdebase/kdebase_3.5.6.orig.tar.gz
http://en.archive.ubuntu.com/ubuntu/pool/main/k/kdebase/kdebase_3.5.6-0ubuntu20.diff.gz


patch -p1 < kdebase_3.5.6-0ubuntu20.diff


kdebase-3.5.6/debian/patches/kubuntu_84_group_toolbar_viewmode_icons.diff


+++ kdebase-3.5.4.new/konqueror/iconview/konq_iconview.desktop  2006-09-26 19:12:13.000000000 +0200
@@ -81,8 +81,5 @@
 X-KDE-BrowserView-AllowAsDefault=true
 X-KDE-BrowserView-HideFromMenus=true
 X-KDE-BrowserView-Args=IconView
-X-KDE-BrowserView-ModeProperty=viewMode
-X-KDE-BrowserView-ModePropertyValue=IconView
-X-KDE-BrowserView-Built-Into=konqueror
 Icon=view_icon
 InitialPreference=10


sudo vi /usr/share/services/konq_iconview.desktop
	X-KDE-BrowserView-ModeProperty=viewMode
	X-KDE-BrowserView-ModePropertyValue=IconView
	X-KDE-BrowserView-Built-Into=konqueror

sudo vi /usr/share/services/konq_multicolumnview.desktop
	X-KDE-BrowserView-ModeProperty=viewMode
	X-KDE-BrowserView-ModePropertyValue=MultiColumnView
	X-KDE-BrowserView-Built-Into=konqueror

/usr/share/services/konq_*
	/usr/share/services/konq_detailedlistview.desktop
	/usr/share/services/konq_iconview.desktop
	/usr/share/services/konq_infolistview.desktop
	/usr/share/services/konq_multicolumnview.desktop
	/usr/share/services/konq_textview.desktop
	/usr/share/services/konq_treeview.desktop

sudo vi /usr/share/services/konq_treeview.desktop
	X-KDE-BrowserView-ModeProperty=viewMode
	X-KDE-BrowserView-ModePropertyValue=TreeView
	X-KDE-BrowserView-Built-Into=konqueror


http://changelogs.ubuntu.com/changelogs/pool/main/k/kdebase/kdebase_3.5.6-0ubuntu20/changelog

A quantum processor, taking advantage of the qubit mutual superposition effects, should be able to solve O(n²) problems per single clock tick. Likewise, the universe -made up of quantum particles- should have the same computing power, being n the number of particles in the whole universe.

Nonetheless, aside from collapses, there is a fixed limit: the speed of light times distance. That means, two close atoms would process faster than two atoms with a light year between them.

More precisely, the top speed would be given by the number of possible collapses per second times the maximum distance in light seconds between the qubits involved in a given processor.

A fractal system which would use the fact that closer particles process faster, could actually process ¡faster than the universe!

At least at the level of problems not requiring more than a number of qubits divided by the simplification factor of whatever we would like to process. No quantum computer could possibly process the whole universe, as every next particle would require a n+1 higher complexity. Although, it would be an interesting experiment to calculate the possibility of calculating a simplified universe on a lower amount of particles. How much would the speed of light influence it? How bigger would be the increase than the decrease due to resolution?

The interesting part, though, is that with relatively small processors and a level of multiple abstraction good enough, it should be easily possible to simulate slices of reality big enough so the collapses would not differ much from those observed in the real world by those who live in it.

Compressed worlds, accelerated even though at a lower resolution. Would be like to live in them? The speed of light would be no obstacle, given that only the distance between simulating particles would matter, not the simulated ones. Even losing a big amount of resolution in the simulation process, it surely would be quite an interesting place.

But everything poses dangers -and not only social ones- as to much distance reduction could lead to, a black hole!

We think that inside a black hole, relativistic equations should be maintained, so from the point of view of a world simulated by particles in a black hole, there would be no speed increase; it would always be the same.

Will it be our future, to become a phantom world inside a black hole, with no possibility whatsoever to go back and escape the reality we would impose on ourselves?

Or, maybe, the evaporation effect would come to the rescue, letting us extract information from nano-scale black holes, making with them quantum processors at the highest possible speed.

Really, right now I would be glad to have a quantum processor with a few million qubits, if possible running at a few gigaflops, to solve a cool O(n³) problem I have in mind. Maybe in the next decade, the world of programming will be quite different.

This night, fooling around, I got hooked on the idea of "how much would it take me" to make a tiny "thing" (for the sake of not calling it a program, nor a web nor anything) to measure typing speed.

Typing speed test

All similar apps I've seen lying there around, usually have on or more of these problems:

1. they give you a fixed text
2. don't show your typing speed as you type
3. you have to press a button before and after typing (you lose some seconds)

The answer is to allow free text, start counting only after the first keystroke and until you stop typing, and to start counting automatically. Knowing there are some really simple ways to accomplish this in JavaScript (onKeyPress), I couldn't honestly understand how was it possible that I hadn't come across anything similar before... so, this came out.

Tie to develop: 15 minutes

...from which I spent about 5 trying to beat myself at seeing how fast I could type. Seems like I can't get over 650ppm... well, 10 per second is not so bad

Now, all there is to do is beautify the site, add some actual content, extend the available options, and see what happens

The whole idea behind using JavaScript for web pages, would be to enable a clear MVC separation on the client side: HTML for data, CSS for view, JavaScript for the control.

If I've already got MVC on the server so, why do I need any client MVC?

Well, it's all due to bandwidth usage and having smart clients vs. dumb clients (meaning the programs).

In a "web application" we would have the following:

1. Server
   1. Modelo - MySQL/PostgreSQL/Oracle
   2. Control - PHP/Java
   3. View - PHP/templates
2. Client
   1. Model - HTML/XML
   2. Control - JavaScript
   3. View - CSS

It's worth to note that the whole Client is the "view" of the server application. This means it's actually good for it to be easy to write -in ECMAScript- and that choosing the same language for Flash is no wrongdoing (which itself also represents the "view" of the server application).

On the other side, if the question was what amount of business logic should be displaced onto the client, you would have the following choices:

1. Reduced - HTML+CSS+JavaScript / Flash
2. Medium - Java applet
3. High - specific client

The difference between JavaScript en Flash would lie in how important it is to show the data at any cost, even though it might not get rendered the same way everywhere. If we value more the data reaching the user, we should place them in HTML/XML and thus use JavaScript. But if what's more important is the actual view, the right way would be to use Flash... hoping perhaps for a better integration between SVG and the major browsers, and an improvement in JavaScript engines.

From this point of view, the availability of the data, some badly applied AJAX, that would "get possession" of the page (so that it would degrade cleanly) would indeed be a dangerous beast; a crossover between awarding the most value to the data, while completely disregarding any compatibility with browsers that might not support it.

Welcome to the english through-the-mirror version of my blog.

My main blog will still be the spanish one, which for the time being I feel more confident writing in.

Nonetheless, I'll be translating some of the posts, maybe the best ones or maybe just some picked at random, in order to "broaden the availability of my wisdom"... or something

So, that's it. Welcome, and enjoy the visit.