Recently in work Category

Gerade stolpere ich über einen Artikel, der die aktuelle Fassung des IE6-Problems, nämlich die Fraktionierung des Web, durch die Marktmacht von Browsern auf Mobilgeräten anprangert. Im Kern geht es darum, daß WebKit, als Basis von allen Browsern von Apple und Google, den mit Abstand größten Marktanteil bei Mobilbrowsern hält, und daß die Webdesigner in der Folge nur noch für WebKit designen, nicht aber für andere (Mobil-) Browser. Damit sind wir wieder da, wo wir mit IE6 und FrontPage aufgehört zu haben glaubten: Diese Webseiten funktionieren nicht, wenn man sie mit anderen Browsern anschaut. Technisch liegt dem die unsachgemäße Nutzung von inoffiziellen Leistungsmerkmalen zugrunde, die Apple und Google längst hätten zur Standardisierung einreichen können und sollen. Daß sie dies bisher unterlassen haben, ist im Grunde unlauterer Wettbewerb und droht dementsprechend, einen Rückfall in IE6-Zeiten zu bringen, weil jeder Hersteller irgendwie “kompatibel” sein muß, dieses Ziel aber mit offiziellen Mitteln dank fehlender Standardisierung nicht erreichen kann.

Der Originalartikel erschien in dem Weblog des Autors, der Mitglied des des entsprechenden Standardisierungskommitees im W3C ist:

www.glazman.org

Ich kann seinen Aufruf, entsprechend kaputte Seiten zu boykottieren und nur im Zusammenhang mit diesem Fehler zu erwähnen, nur voll unterstützen, und hoffe, daß meine verehrte Leserschaft dies ebenso sieht.

The normal project layout, generated by the scaffolding for Pyramid projects, generates a project structure like this:

project/
            package/
                          tests.py (or tests/*)

In conjunction with Jenkins, it turns out that nose’s plugin for Cobertura-style output fails to discover the test modules properly. Instead of saying

`$ nosetests --with-xcover`

one needs to also specify the configuration file:

`$ nosetests -c development.ini  --with-xcover`

I am using zc.buildout together with a virtualenv to generate my Plone instances. It turns out that Zope requires the Python Profile be installed. However, under Debian, the relevant package, python-profiler has made it to non-free instead of main, due to the licensing of that package. As a result, you only discover that testing doesn’t work until Zope tries to import the profiler, and falls over.

In order to get things to run, you need to do the following:

# Add non-free to the set of repositories that you want to use. Eg.:

  deb http://ftp.debian.org/debian stable main

would have to become

  deb http://ftp.de.debian.org/debian stable main non-free

# Run apt-get update (obviously). # Now you can apt-get install python-profiler, and you should be all set.

Just today I had an experience about what it can mean to have no network neutrality, taken from my professional work:

A client wanted to check out his brand-new VPN gateway, utilising IPSEC from his road-warrior client and a mobile connection, but it just didn’t seem to work. While testing, we found the following:

• The client could not ping his VPN gateway.
• No ISAKMP packet arrived at the gateway.

He then cross-checked with wireshark to see which packets actually leave the system, and found that the relevant packets were being sent out by the PC, but didn’t arrive at his VPN gateway. This is a strong indication that the mobile carrier blocked his IP packets.

This is not the first, but only the latest such incident I saw in my career.

Needless to say, a carrier who blocks users’ packets, is about as useful as a car without an engine…

I demand that carriers who call their service “Internet”, be required to indiscriminantly allow all (halfway sane) packets through. I am almost comfortable with someone blocking packets that have no return route (ie., if someone spoofs their source IP number), but that’s about all restrictions I can think off the top of my head that I might consider acceptable.

There are two web browsers, based on the Google Chrome codebase:

• Google Chrome (of course)
• Chromium

The latter is a free-software-only version of Google Chrome, having the spyware features of the original Google Chrome ripped out, and that can be eg. installed in Debian using apt-get.

Today, I wanted to try the extensions, since the original browser is suitable for not much more than simply looking at a web page. But if you want any kind of extensions, like eg. maybe AdBlock, or the SpeedMeter, or the SessionManager, or whatever else would benefit you as a user, you immediately find yourself locked out of Google’s Webstore. By the way… the name is already giving away what the problem really is: Google, like about any other vendor I am aware of, wants to reduce you to a user, and cut down on your abilities to create, or use the software in ways you deem fit, instead of only ways they deem fit. So, there is eg. no simple way to download the extension to your hard disk drive, maybe for later digestion - no, you can, at best, install the extension online, into your current profile. And if you somehow lose that, you get to try again. So they can not only track every move of you, they can also manage the availability of their extensions to you as they choose. Like eg. Ad sales going down? Poof, no more AdBlock for you.

This way, you sell out your freedom and your privacy in the same way to Google than you probably did before, to Microsoft and Apple, and a plethora of other companies.

Now my question to you is: Are you prepared to accept that, and if so, why?

你好！

如果你知道一个工作有这个特点和g供给够钱，请联系我。

谢谢！

As per the author’s statement, using ZopeProfiler together with Plone4 is unsupported. It really is. First, get a current version of ZopeProfiler instead. Implement in your buildout as usual and run buildout. In the relevant instance’s (eg. secondary) zope.conf, one has to enable it, too:

enable-product-installation on

You also need to fix the output from the pstats module. In Debian, this is located at /usr/lib/python2.6/pstats.py. Copy to your virtualenv’s lib/python2.6 and manually apply the patch mentioned here: http://bugs.python.org/issue7372

After that, following the instructions generally works, except for that the site now runs orders of magnitudes slower, and (at least) I get this error when trying to view the stats (sample traceback):

2011-05-04 13:47:56 ERROR Zope.SiteErrorLog 1304509676.940.218731970327 http://localhost:9082/Control_Panel/ZopeProfiler/showHigh
Traceback (innermost last):
  Module ZPublisher.Publish, line 127, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 47, in call_object
  Module Shared.DC.Scripts.Bindings, line 324, in __call__
  Module Shared.DC.Scripts.Bindings, line 361, in _bindAndExec
  Module App.special_dtml, line 185, in _exec
  Module DocumentTemplate.DT_Let, line 76, in render
  Module DocumentTemplate.DT_Util, line 202, in eval
   - __traceback_info__: stdnameRe
  Module <string>, line 1, in <module>
  Module Products.ZopeProfiler.ZopeProfiler, line 237, in getStatistics
  Module pstats, line 353, in print_stats
ValueError: I/O operation on closed file

I’ve seen the latter error on various other occasions as well, esp. when a long time has passed between the original activity and the display of results (eg. when running ExternalMethods). If someone has a fix for that, I’d highly appreciate it!