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.

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.

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?

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?

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.

In eerste instantie werd ik gewezen op de live()-functie. Om deze functie te kunnen gebruiken moest ik Jquery updaten van versie 1.2.3. naar 1.3.2. Toen ik dat gedaan had , kreeg ik nog veel meer problemen......

De laatste versie bleek niet 100% backwards compatibel, jammer. Probleem leek hier in te zitten: Old, XPath, style attribute selectors: [@attr=value]. These have been deprecated for quite some time - and we’re finally removing them. To fix it just remove the @!.

Mijn eerste probleem bleek overigens ook niet met de live()-function te worden opgelost. Probleem bleek het uitlezen van een href-attribuut in een link. In dit attribuut plaatste ik een woord wat ik later weer uitlas. Internet Explorer bleek automatische de complete URL voor dit woord te plaatsen. Of dat logisch is vraag ik mij af. Toen kon ik het oplossen door mijn woord te verplaatsen naar het rev-attribuut.

Phpjs spaart nu toch wel wat tijd, al zag ik eerste instantie het nut niet zo. Ik zag het vooral als een leuk project. Tot mijn spijt ontdekte ik alleen dat zowel preg_replace en preg_match nog niet geïmplementeerd waren. Dat waren nu net de functies die ik nodig had...... In eerste instantie leek het mij logisch om deze functie gewoon te schrijven m.b.v. de javascript regular expressions. Kevin van Zonneveld wees meer er echter terecht op dat de javascript (ECMA-262 standard) regular expressions niet gelijk zijn aan de uit perl ontleende versie (The open source PCRE library) gebruikt voor PHP (zie ook: http://www.regular-expressions.info/refflavors.html). Ondanks deze beperking heb ik nu zelf twee functies geschreven, die voorlopig i.i.g. doen waar ik ze voor nodig heb. Beide functies staan hieronder en maken gebruik van: toRegexp(), omdat een regular expression in javascript geen string is. RegExp is een apart type, met twee parameters, daarom is casting van een string naar een RegExp niet mogelijk.


function toRegexp(regexpstring)
{

var result = regexpstring.match(/(\/)(.+)(\/)(.*)/);
return new RegExp(result[2],result[4]);
}


function preg_replace(search, replace, subject,limit,countername)
{
//
// version: 0.0001
// discuss at: http://phpjs.org/functions/preg_replace
// + original by: Bas Jobsen (http://www.w3masters.nl/)
// * example 1: preg_replace(['/^test | test | test$/g','/ +/g'],[' ',' '],'boektest andertest test');
// * returns 1: 'boektest andertest'
//
// * use a global var with 'countername' to count replacements
// * var counter=0;


var s = [].concat(search);
var r = [].concat(replace);
var lim = 0;

var end = s.length;

var j=0;
var k=0;
for(var i=0; i {
if(i in replace){j=i;}
lim = (limit>0)?limit:-1;
searchstr = toRegexp(search[i]);
while(lim-- && subject!=(subject=subject.replace(searchstr,replace[j]))){k++;};
}
if(countername)eval(countername+'=k');

return subject;
}
function preg_match(pattern,subject,matchesname,flags,offset)
{
//
// version: 0.0001
// discuss at: http://phpjs.org/functions/preg_match
// + original by: Bas Jobsen (http://www.w3masters.nl/)
// * example 1: var matches = new Array();
// * example 1:alert(preg_match('/boek/','tes/t boektest andertest test','matches',1));
// * example 1:alert (matches[0]);
// * example 1:alert (matches[1]);
// * alerts 1: 1
// * alerts 1: 'boek'
// * alerts 1: 6
// * use a global var (array) with 'matchesname' to get matches
// * var matches = new Array();

if(offset>0)
{
subject=subject.substring(offset);
pattern=pattern.replace(/\^/,'');
}

var result = subject.match(toRegexp(pattern));

if(!result) return 0;

for(i = 0; i < result.length; i++)
{
eval(matchesname+'['+i+']=\''+result[i]+'\'');
}
if(flags==1)
{
eval(matchesname+'['+i+']='+subject.indexOf(result[0]));
}

return 1;
}


en

Goed tot zover nu Adf.ly. Deze website koppelt een korte link aan advertenties. Korte links wat betreft Twitter belangrijk, omdat elk bericht maar 140 tekens mag bevatten. Zo verwijst http://adf.ly/rM naar mijn website. Elke keer dat iemand de link klikt, kan mij dat geld opleveren.
Ik ben benieuwd, ik zal deze blog bij wijze van experiment ook op deze manier op Twitter posten.

Zie ook:

Tipjoy betalen via Twitter
Tweetdollar.com

Hierbij viel mij verder op dat Google direct melding gaf van pagina's met de zelfde metatags en /of title-tag voor pagina's waar in na aanpassing nog interne links met index.htm gebruikte.

Daarnaast viel mij vandaag het volgende op: Gisteren heb ik de domeinnaam Idating.be geregistreerd. Hierop heb ik meteen een site gezet. Deze site maakt gebruik van de content van Easyflirt-partners.biz, ik ben benieuwd of dit white-labeled dating concept inderdaad lucratief is. Na het plaatsen van de website heb ik meteen de sitemap geüpload naar het Google webmasterhulpprogramma. Vandaag vond ik onder "Diagnose > Webcrawl" een http-error. De error luidde: "Domeinnaam niet gevonden". Dat zou natuurlijk kunnen als er een vertraging zou zijn in het updaten van de DNS-servers. Echter wordt er bij de fout ook vermeld; Probleem gedetecteerd op; 19 mrt. 2009.

De datum maakt deze foutmelding opvallend want toen bestond de site nog niet, laat staan dat ik al een sitemap had geüpload. Mogelijk had de domeinnaam eerst een andere eigenaar. In Google kan ik echter geen vermeldingen vinden voor idating.be. Tja een vreemd verhaal...... of niet? Misschien kijkt Google bij nieuwe aanmeldingen dus naar de historie van een website. Lijkt misschien onlogisch, maar daarmee kan natuurlijk voorkomen worden dat iemand de content van een website aanpast. Aanpassen van de content van een website is natuurlijk prima. Extreme aanpassingen kunnen er echter toe leiden dat een bezoeker via een zoekmachine iets anders vindt, dan verwacht. Hierbij kun je denken aan een website met een goede ranking, die plotseling verandert in een pornosite.

zie ook Google Hulpprogramma's voor webmasters steeds nuttiger voor s.e.o.