De upgrade van Ubuntu 9.10 ("Karmic Koala") naar Ubuntu 10.04 LTS ("Lucid Lynx") verliep soepel. Enige probleem was dat o.a. de NetworkManger en de dropbox iconen niet meer in het (desktop)panel verschenen.

Hiervoor worden verschillende oplossingen beschreven, zie o.a. https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/482684. M.i. wordt dit probleem veroorzaakt door het uitschakelen van het notificatie gebied (Notification Area) in het panel. Op te lossen door Add to Panel... --> "Notification Area".

Aanpassingen aan /etc/network/interface (wat ook problemen zou geven met de localhost) of het installeren van WICD, zoals elders beschreven lossen dit probleem niet op.

Bijna een jaar geleden (30 juni 2009) kwam PHP 5.3 uit. PHP 5.3 wordt o.a. standaard geleverd bij Ubuntu 10.04 LTS ("Lucid Lynx"). Een upgrade van versie 5.2 gaf enkele problemen, hieronder een samenvatting. Sinds versie 5.3 ondersteunt PHP ook namespaces, juist daarmee hadden daarmee enkelen van de hieronder beschreven problemen voorkomen kunnen worden.

Nieuwe functies
Vanaf versie 5.3 zijn o.a de volgende functies beschikbaar getHostname en lcfirst. Beide functies waren al gedefinieerd in Opensourcecms. De eerste functie is hernoemt. Voor lcfirst is nu het volgende gebruikt:

if (!function_exists('lcfirst'))
{
function lcfirst($string)
{
return strtolower(substr($string,0,1)) . substr($string,1);
}
}

lcfirst() biedt afhankelijk van de lokale instellingen (via setlocale()) ook ondersteuning voor speciale teken zoals ë.

Regular expressions
PHP had altijd een eigen implementatie van Regular expressions (POSIX Regex Functions). Daarnaast kon ook gebruik gemaakt worden van regular expressions zoals die in Perl gebruikt worden (PCRE Functions). Van de laatste was al bekend dat deze vele malen sneller waren. Sinds versie 5.3 wordt dan ook afgeraden nog langer gebruik te maken van de POSIX Regex Functions, zoals ereg() en ereg_match(). Webapplicaties die bijvoorbeeld error level E_ALL gebruiken geven nu een waarschuwing.
Voor de verschillende foutmeldingniveaus in php (instelbaar via error_reporting()) kent php een aantal (voorgedefinieerde) constanten zoals E_ALL (2047). Sinds versie 5.3 komen hier de volgende constanten bij: E_DEPRECATED en E_USER_DEPRECATED. Daarmee kunnen dus de eerder beschreven foutmeldingen ook onderdrukt worden:

error_reporting(E_ALL ^ E_DEPRECATED);

Naast de POSIX Regex Functions worden sinds versie 5.3 nog een hoop meer functies afgeraden, zie hier voor een overzicht.

Onlangs deelde ik de volgende mening met Mathias HD (recent afgestudeerd informaticus uit Vlaanderen); "In de toekomst hebben websites (domeinen) mogelijk steeds meer een samenvat- en doorverwijsfunctie. E.e.a. is al terug te vinden in de (amateur)muziekindustrie. Op de website van een artiest is slechts beknopt informatie te vinden, verder staan foto's flicker, muziek op myspace en filmpjes op youtube.
Daar kwam ik achter tijdens mijn werkzaamheden aan Jazz Festival Delft.
Terugkoppeling naar de website van deze netwerksites wordt nog maar zelden gebruikt, daarbij zou gedacht kunnen worden overzichten van updates op flicker, myspace, twitter, etc. bijvoorbeeld via rss. De website wordt dan een samenvatting van wat elders te vinden is.
Als je deze lijn doortrekt kun je ook afvragen hebben personen in de toekomst
nog een website? Of is een linkedinpagina voldoende of zelfs beter?
Hoe gaan bedrijven daarmee om?
Heb je een webshop? Bouw je die zelf of verspreid je slechts een productfeed
(xml) waarbij de gebruiker zelf de device / shopapplicatie kiest?"

Mathias reageerde hierop met een verwijzing naar: Google Chrome OS is 7 years too late.

Tja..... zelf bouw ik webapplicaties en websites......... hoe lang nog?

Link: http://ediblepet.net/2009/05/23/web-applications-should-be-compile/

Vanmiddag wees @birgerjansen mij op een leuke en vooral interessante blog; "Web Applications Should Be Compiled". Reageren op het artikel kan niet meer. Zelf kan ik nog steeds niet reageren via twitter, dus dan maar op deze manier....

Zelf ontwikkel ik webapplicaties en websites in Opensourcecms.eu, wat is geschreven in PHP. Ontwikkelen gaat inderdaad snel. PHP is helemaal toegesneden op het ontwikkelen voor het web, dus dat biedt zeker voordelen voor 'ad hoc' implementaties. Performance issues spelen natuurlijk altijd een rol en in die zin zou compiled code absoluut een verbetering opleveren.

Bij de comments van het genoemde artikel wordt verwezen naar Mongoose. Mogoose is een webserver, m.i. in eerste instantie te vergelijken met bijvoorbeeld Jetty. Er van uitgaande dat de gecompileerde webapplicaties, tevens webserver zijn (onder port 80) kan het toch interessant zijn Mogoose nader te bekijken.

Goed stel; ik zou een webapplication framework willen bouwen, wat bij voorkeur ook direct inzetbaar is als CMS, in C of C++, wat zou ik dan nodig hebben. Beginnen 'from scratch', is meestal alleen leuker, maar niet per definitie efficiënter. De auteur van het artikel geeft de voorkeur aan C boven C++. Mijn mening is, wanneer herbruikbare code even snel geschreven kan worden als niet herbruikbare code, dan te kiezen voor het eerste. Naast C zou C++ dus zeker een optie zijn.

Zelf heb ik de volgende reeds bestaande projecten kunnen vinden:

Wexus Labs een C++ library voor web application development. Het idee achter Wexus lijkt duidelijk. Verder is mijn indruk dat er na 2006 weinig meer is gebeurd. Veel verder dan een 'hello world' wordt dan niet gekomen.

Wt, uitgesproken als 'witty', is zeker een interessant project. Wederom een C++ library. Zelf beschrijven ze het als een applicatieserver voor het ontwikkelen en onderhouden van webapplicaties. Goede indruk maakt natuurlijk, dat de site zelf gebouwd is in Wt. Nadere inspectie van de html-broncode wijst wel uit, dat Wt code produceert waarvan de zoekmachines waarschijnlijk niet echt blij worden..... na een korte analyse denk ik dat dit niet simpel op te lossen is. Wt lijkt mij bepalend in de uiteindelijke output. Webapplicaties die werken met en zonder javascript is natuurlijk mooi, maar voor het bouwen van websites is zoekmachineoptimalisatie (voor mij) ook belangrijk.

De meeste indruk maakte CppCMS op mij. Zoals ze zelf zeggen;
"CppCMS is Free C++ Web Development Framework (not CMS) aimed for Rapid Web Application Development". Het is dan op zichzelf geen CMS, er is wel een implementatie voor database-connectie(sql), sessies en caching. CppCMS lijkt mij een interessant project om binnenkort nog eens beter te bekijken.

Tot slot nog een vraag voor 'de heren' van CNOC. Hoe zien jullie de mogelijkheden wat dit betreft voor het ontwikkelen in Free pascal?

Afgelopen maandag zag ik opeens dat mijn twitteraccount @basjobsen niet meer werkte. Het account van op inactief gezet en daar van kreeg ik na het inloggen een melding. De melding verwijs naar een pagina met uitleg, die helaas niet meer bleek te bestaan. De meest voor de hand liggende oorzaak zou het maken van te veel requests per uur zijn. Ik wist zeker dat niet te veel requests had gedaan. Hoe lang ik er ook over nadacht, ik kon echt niet bedenken wat ik fout gedaan zou kunnen hebben.

De enige oorzaak die ik kon bedenken; ik had in een van mijn tweets "White Widow" genoemd. Misschien was deze tweet in verkeerde aarde gevallen????. Ik kon mij niet voorstellen dat dit de oorzaak was, maar het was toch het enige wat ik kon bedenken. Via Twitter Support! heb ik een verzoek ingediend mijn account weer te activeren. Het toewijzen van mijn support-ticket aan een medewerker duurde langer dan 24 uur. Na de toewijzing duurde het nog ruim 10 uur voordat ik een reactie ontving.

De reactie van Twitter Support! luidde; "Twitter is a free service, and we can't answer every email we receive; we do try to help with problems of broken accounts as much as possible." en "Thanks for writing Twitter Support. For answers to your questions, please check out our Help Resources". Na deze berichtgeving werd mijn ticket ook gesloten. Ik had geen kans meer om überhaupt te reageren. Best frustrerend, want ook al zou ik uit de Help Resources kunnen achterhalen waarom mijn account op non-actief is gezet, dan ik kan ik het nog steeds niet gebruiken. Om te kunnen reageren kon ik niet anders doen dan een nieuw support-ticket starten en hopen dat hierop wel een actie zou volgen. Toewijzing van het ticket duurt weer meer dan 24 uur en nu wacht ik nog steeds op een reactie.

Naast mijn persoonlijk account had ik nog een tweede account @ictcongres. Dit twitter account gebruikte ik om ICTCongresDelft.nl te promoten. Na de afsluiting van @basjobsen kon ik op dit account verder twitteren. Op deze manier kon ik dinsdag tweets versturen van het boeiende en in mijn ogen succesvolle #sm29. Deze pret duurde ook weer niet heel lang, want voor het einde van de dag was, de 's morgens uit de oplader gehaalde, iphone helemaal leeg.

Woensdagavond merkte ik dat @ictcongres plotseling ook op Suspended stond. Dat kon geen toeval zijn..... Op de iphone twitter ik via Twitterrific. De meest voor de hand liggende oorzaak lijkt dan ook dat deze applicatie beide problemen veroorzaakt. Mogelijk doet Twitterrific te veel request, waardoor mijn batterij letterlijk leeg stroomt en mijn accounts worden geblokkeerd.

Ik heb Twitter Support! hiervan melding gemaakt. Nog geen reactie ontvangen. Vandaag heb ik Twitterrific geüpdate van versie 2.0 naar 2.1. Of deze versie nog steeds te veel requests doet kan ik niet testen. Na de update blijft mijn batterij leeglopen. Ik heb inmiddels besloten Twitterrific helemaal van mijn iphone te verwijderen.

Ik hoop dat mijn batterij nu weer een acceptabele tijd zal meegaan. Ook hoop ik natuurlijk dat mijn account spoedig weer geactiveerd zullen worden. Het zou jammer zijn als dit voor mij een definitieve Twexit zou betekenen.