Optimizing Your Java Code (2)

So as I mentioned earlier, I recently attended the Devoxx Java conference (formerly named Javapolis). At this conference I attended the 'Java Performance' lecture given by Dr. Holly Cummins (I should really use her title, not just Holly but Dr. Holly) and Kirk Pepperdine (not a doctor but an independent consultant).

This is part two of my Java Performance blogs. See the first part here

Today, I will be talking about a subject called Latency.
When you're working on a program or a piece of code you sometimes notice that it isn't running as it should. It seems to be slower than you expect. Or sometimes a customer can come to you and say that the program is doing five transactions per second when it should be doing ten.
In either way, you never quite know what the problem is precisely. All we really know is that the user is experiencing a poor reponse time. The user tries to work with your program but gets annoyed because the system doesn't do everything as quickly as he would like.

Right now, you know next to nothing about what could be causing the problem. It could be that the user's computer just isn't powerful enough to run this application in a responsive manner or it could be that your application just uses too much memory, making the guest's operating system swap like crazy.
Quite generally, we have three possible causes of poor response times
1) Insuffient capacity (hardware-related)
2) Inefficient use of capacity (a dreadful architecture, slow algorithms)
3) combination of the two above

Even if you know that inefficient use of capacity is the bottleneck in this particular case, you will still be hard pressed to find the exact source of the problem. As you will probably know, your hardware has a finite amount of resources available. Every time the processor receives an overflow of information for example, it queues the additional information and processes what it can, then retrieves the data in the queue and processes this. Not only the processor but every piece of hardware works with a queue. The amount of time data has to stay still and wait to be processed is called Latency. Latency is usually expressed by the inability of the application to consume the CPU. This means that if you're running the program at the part where the bottleneck occurs according to the client and you notice that your CPU is getting utilized more but not at its top priority (not 100%), then this should be a reasonable indicator that you're experiencing inflated latency times.

It works the other way around as well. If you're having a fully-utilized CPU, while still getting inflated response times, then one piece of code is dominating the CPU and isn't doing what it should. In this case, you can probably have an infinite loop (even though that shouldn't have gotten through the final testing phase) or maybe you're even doing the String concatenation I warned you about earlier.

There are four kinds of latency that are important to the performance of your Java application. These are:
1) Hardware Induced Latency
2) OS Induced Latency
3) VM Induced Latency
4) Application Induced Latency

Hardware Induced Latency is the form you'll probably understand best. Your computer has definite capacities that cannot be exceeded. You cannot ask more of your hardware than the absolute maximum. Everything you ask of it that does exceed this maximum is queued in memory until the hardware has time to execute these particular commands. The time that these instructions are kept waiting is what we refer to as Latency.

Operating System (OS) Induced Latency is a bit harder to understand, but not really. The OS provides an interface for hardware management. It takes the work out of the programmer's hands. The OS provides in memory management, I/O and other provisions. It's much harder to tell that you're dealing with OS induced latency but symptoms include a relatively high CPU-utilization or a large strain on your hard drive.
You can't really change your Operating System (unless you're running an open source one, of course). I have never found the problem to be lying with the Operating System itself. I just want you to understand that the Operating System is just another layer that queues your requests before it can handle them, thus increasing the complete latency.

The VM Induced Latency, on the other hand, is something you can do something about. The Java Virtual Machine (JVM) provides Garbage Collection (GC) as you know. It removes those objects that are no longer needed from memory. A lot of people don't really realize what the Garbage Collector does precisely. Does it work alongside your application, or does it interrupt your application? I believe, if I remember Dr. Cummins correctly, that it depends on the strategy your JVM follows. The default strategy for the JVM is to interrupt your program, remove those objects from memory and then allow your program to proceed. Think back to my String concatenation example. You create a String object and then concatenate some characters to this String. The result is a new String object. The JVM now interrupts your application, realising that the first String object is no longer needed and removes it from memory. Then it allows your application to proceed again. This is a vicious circle that makes your application run so much slower. The symptoms for diagnosing whether or not the problem lies with the JVM include high object creation rate and a high CPU utilization.
I think the only real thing you can do about this problem is check your object creation and disposal rates. There are easy light-weight monitoring tools out there like starting the JVM with the -verbose:gc switch. This will keep a log of your Garbage Collector. There are other tools out there (from IBM, for instance) that can present the information in this log in a visual way.

The last form of latency is Application Induced Latency. This is your program itself queuing data before processing it. Think of a deadlock happening. Thread A is waiting to gain access to resource R1 (having just used R2), while Thread B is waiting for resource R2 to be released by Thread A (having just used, and still locking R1). This prevents your application from making forward progress. The symptom for diagnosing whether or not the problem lies with your Application itself is an inability to fully utilize the CPU. You notice the response times aren't too good, but the CPU isn't being used all that intensively anyway. That means that some problem is occurring somewhere in your application, causing threads to be parked. For instance, one thread is waiting for an external system (connected e.g. across the Internet) to respond to a request and no threads can proceed without the answer from the external system. Your CPU doesn't have any work, but your application (or a part of) is halted anyway.
When this problem occurs, I think it's safe to say you may need to do some redesigning of your application, to make it less dependent of external systems. If, on the other hand, it is one of those programs that just needs that one web service to perform its task accordingly, this is not an option.

So those are the four forms of latency that are important to understand. It's important that you realize that sometimes the problem does not lie exactly with your code. Your JVM may be intrusive by halting your application all the time as well. You should check out all four forms of latency and
Hopefully you'll have a better understanding of latency now and realize how the different forms of Latency can affect your application.

Optimizing your Java code

I recently attended the Devoxx Java conference, held at Antwerp (Belgium) from Monday, 8th of Decembre 'till Friday,12th of Decembre. Unfortunately, I could only go the first two days but I managed to attend some interesting lectures about Java performance. There seem to be a lot of techniques you can apply to your Java code to make it run faster.
In the following days/weeks, I will discuss quite a few of these.

---

A lot of the people I talk to daily often complain about the speed, or lack thereof, of the Java programming language. Java is not one of the fastest programming languages out there and to understand why, you should dig into the basic structure of Java. Below is included a short explanation of how Java works. If you require more information, feel free to examine the links given at the end of this article. If you already know how Java works, feel free to skip the first part.

The basic structure of Java

Java works on every operating system, provided there is a Java Virtual Machine (JVM) available for this operating system. This is usually the case. If it's not the case, you should probably be wondering why you're working on such a system anyway.

Every instruction you program in the Java programming language gets translated into some intermediary language that only the JVM understands. This JVM (specific to the operating system it is installed on) then translates this to something the operating system can understand. The OS then ensures that these instructions are being executed by the hardware.

So every line of code you write in the Java programming language is translated not once, but thrice. Once, so the JVM understands what you want to make happen. These instructions are then translated again by the JVM so the operating system knows what you want done. The operating system then translates this into machine-code that the hardware can understand. The result (if any) is then calculated by the hardware, sent to the operating system, who gives it to the JVM who sents it to you.

That's a long way for data to travel and this is the first reason why people are quick to say that Java is slow. Sure, Java has its drawbacks when it comes to speedy execution of code and probably shouldn't be used for Grid Computing, for instance. But Java also has advantages. Like I said before, Java is platform-independent. Program once, and run it anywhere. You wrote your program on Windows but it will also work on Linux or Mac OS X without you having to invest extra time in porting your application. Also, Java has automatic memory management, thus removing those objects you no longer need to free up memory while your program is running (see Java Garbage collection) and on top of all of this, Java is also a very secure programming language.

When you write your Java code, there are certain aspects you should be aware of. Some of them will affect the performance of your Java code dramatically (either positively or negatively).

The first problem – String concatenation

One of the lectures I attended concerned itself entirely with testing for performance. The lecture was given by Holly Cummins (noted IBM garbage collection tuning specialist) and Kirk Pepperdine (a primary contributer to javaperformancetuning.com). The very first problem they tackled was that of String concatenation. They demonstrated a little program that was supposed to output the information of various stocks in HTML-form. This was accomplished by a method quite like the one below:

Table 1.1 The method getStockInfo

public String getStockInfo() { String result; result += "<html>"; result += "<head>"; result += "</head>"; result += "<body>"; result += "<table>"; for (Stock s : allStocks) { result += "<tr>"; result += "<td>Name: </td>"; result += "<td>" + s.getStockName() + "</td>"; result += "<td>" + s.getStockDate() + "</td>"; result += "<td>" + s.getStockRating() + "</td>"; result += "</tr>"; } result += "</table></body></html>"; return result; }

So as you can see, we make a String-object, append it using the '+=' operator with tags like <html> and then we get into a ForEach loop, iterating over the allStocks-collection. For every Stock, we append the result object with all data contained in the Stock, surrounded with HTML tags.

What do you think, will this code run smoothly? There is an easy way to find out.

In the Extra-Material-part at the end, you'll find a link to a generic StopWatch class. It is a light monitoring tool and will only have a very small effect on the performance of the application. This class measures performance from one point to another and outputs its result as a Long value.
Note that it's not important to actually understand this Class. I didn't write it myself, either, but found it on the Web. It's a great lightweight tool for performance monitoring though. Just create a new class and paste the code in there. It should work out of the box.

To test this code in an efficient way, I just use the following Main-class:

Table 1.2 The Main class

public Main() { allStocks = new ArrayList(); for (int i = 0; i<10000; i++) { allStocks.add(new Stock()); } StopWatch stopwatch = new StopWatch(); stopwatch.start(); getStockInfo(); stopwatch.stop(); long result = stopwatch.toValue(); System.out.println(result); }

As you can see, I first make 10 000 Stock-objects. That's not an exaggerated number. If you would put this program into production, it might run into instances of having 10 000 Stock objects to keep track of.

Try running this code. On my computer, it took about 17 minutes to complete. (1.6 Ghz single-core cpu, 1 Gb of RAM). As you can probably understand, when I want to see the current data of all Stocks, I don't want to wait 17 minutes. The execution time of this code is completely unacceptable.

There must be something wrong with it. What might we have overlooked?
Well, it's obvious we didn't read the API closely enough because the API for the class String explicitly states:
Strings are constant; their values cannot be changed after they are created. You read correctly. Once you create a String object, you can never change it again. java.lang.String is defined as an Immutable class.

So what gives? I'm changing my String aren't I? No, you're not. You're creating new String objects, containing the previous String and the next part you're trying to concatenate. That's a bummer for performance because every time you create a new String-object the old one becomes obsolete.

Because of the automatic Java memory management (Garbage collection) this old object is destroyed every time. So the Garbage Collector stops your program, removes the old String object from memory and then allows your program to continue. Your program concatenates again. Garbage collector interrupts and removes the old String, and so on and so forth.

Is there a good way to fix this?

Yes there is, fortunately. The Java API provides us with a StringBuilder object. This object works quite like a String-object but for one subtle difference. Internally, the StringBuilder (and StringBuffer as well) holds an array of Characters (char). When you want to concatenate to this String, it just resizes the array and puts the new characters in one by one. At the end, when you really need the String, you call the method toString() of the StringBuilder and for the first time, a String is constructed.
So remember to do all of your adaptations (concatenations, replacement of letters, etc...) on a StringBuilder object and then asking for a String. This is much faster.

But don't take my word for it. By all means. Adapt the getStockInfo() method like so:

Table 1.3 The getStockInfo method revised

public String getStockInfo() { StringBuilder sbResult = new StringBuilder(); sbResult.append("<html>"); sbResult.append("<head>"); sbResult.append("</head>"); sbResult.append("<body>"); sbResult.append("<table>"); for (Stock s : allStocks) { sbResult.append("<tr>"); sbResult.append("<td>Name</td>"); sbResult.append("<td>"); sbResult.append(s.getStockName()); sbResult.append("</td>"); sbResult.append("<td>"); sbResult.append(s.getStockDate()); sbResult.append("</td>"); sbResult.append("<td>"); sbResult.append(s.getStockRating()); sbResult.append("</td>"); sbResult.append("</tr>"); } sbResult.append("</table></body></html>"); return sbResult.toString(); }

I know, it looks pretty counter-intuitive. By using a StringBuilder you get more lines of code so you automatically think that it must be slower than using String concatenation but it's not. It's actually way faster.
The data on my computer is as follows:

• When running with normal String concatenation, the getStockInfo() method took 17 minutes 37 seconds to complete.


• When running with StringBuilder concatenation, the getStockInfo() method took only 148 milliseconds to complete.

Do you see the huge difference? I just sped up my program by more than 500%! And all I did was change String concatenation to StringBuilder concatenation! How efficient is that!!

Conclusion

So what have we learned exactly?
Not only have we learned to never use String concatenation, but we have also learned that the Java Garbage Collector can have a huge impact on the performance of your application. It frequently interrupts your program to get rid of the variables you no longer need. It's useful to keep this in mind when you're writing your code.

So that was the first of my Java Performance posts.
I hope you enjoyed, please drop me a line if you've read this. Anything at all is always appreciated.

Extra Material

The StopWatch class: http://www.javapractices.com/topic/TopicAction.do?Id=85
Podcasts by Holly Cummins: http://www.theserverside.com/tt/knowledgecenter/
The website of Kirk Pepperdine: http://www.kodewerk.com/

Repareer die tags, gebruik Musicbrainz!

Ik gebruik al een tijdje Last.fm. Dit is een handige real-time site die bijhoudt naar wat voor muziek jij luistert en op basis daarvan zoekt naar mensen waar je op muzikaal vlak zeker mee zal overeenkomen. Last.fm doet verder ook nog suggesties naar groepen die je niet kent maar die je misschien wel goed vind. Al wat je hiervoor moet doen is een kleine plugin installeren. Dit kan onder Windows voor zowel iTunes als Windows Media Player en de plugin bestaat ook voor verscheidene muziekspelers onder Linux. Zelfs onder MAC OS X kan de plugin voor Last.fm gebruikt worden.
(meer informatie: http://www.last.fm/)

Sinds ik Last.fm gebruik, valt het me steeds harder op dat de tags van mijn liedjes niet altijd zo juist zijn. De tags bevatten informatie zoals de artiest van het lied, het album waarop het lied verscheen en dergelijke. Door de plugin worden de tags van het lied steeds naar de site verstuurd. Als je dan je profiel bekijkt, kan je zien welke liedjes je het laatste hebt beluisterd en kan je op het liedje klikken om meer informatie over het lied of de artiest te bekomen. Als Last.fm echter geen relevante informatie kan tonen of jou naar een volledig lege pagina brengt, bestaat de kans dat de informatie in de tags foutief is.
Dat gebeurde de laatste tijd redelijk vaak bij mij, dus ik ging op zoek naar een tool om mijn tags mee te kunnen nakijken.

Een vriend verwees me naar MusicBrainz, een open-source databank die honderden, misschien wel duizenden artiesten bevat met hun albums en liedjes. Ik gebruik de muziekspeler Banshee onder Linux en wanneer deze niet de juiste album-omslag kon tonen voor het lied dat ik beluister wist ik dat er iets scheelde met de tags en gebruikte ik de MusicBrainz website om de juiste informatie op te zoeken.

MusicBrainz is ongelooflijk makkelijk om de juiste artiesten, de juiste titels en de juiste albums op te zoeken. Ik houd me nu bezig met elk liedje in mijn bibliotheek te beluisteren en waar de informatie tekortschiet ga ik op zoek naar de juiste tags.

Het verschil is echt merkbaar. Als je mijn Last.fm pagina bekijkt, zie je dat alle liedjes nu de juiste album-omslag vertonen en door er op te klikken kom ik steeds op de juiste pagina terecht waar ik de juiste informatie terug kan vinden.

Maar Last.fm werkt als een wiki. Dit betekent dat telkens iemand een liedje afspeelt met onjuiste tags, dit lied ook in de databank wordt gezet en er een pagina wordt aangemaakt om de juiste informatie te vinden. Door dus onjuiste tags te gebruiken vertraag je Last.fm en vul je dit op met nutteloze informatie. Het kan natuurlijk goed zijn dat Last.fm af en toe deze nutteloze pagina's verwijdert, maar het zou niet moeten gebeuren. Deze pagina's nemen enkel maar plaats in.

We zouden allemaal dezelfde moeite moeten doen en onze tags zo goed mogelijk proberen te verbeteren.

(Meer informatie: http://musicbrainz.org/)

De Grootste Gevaren voor Alledaagse Computergebruikers

We werken allemaal met de computer en we zijn allemaal even hard blootgesteld aan het gevaar van het Internet van vandaag de dag. Ik draai zelf zowel Linux als Windows naast elkaar op mijn computer en voor mij is het opvallend hoeveel bedreigingen enkel voor Windows bestaan terwijl ze ook enkele grote gevaren gemeen hebben. Het staat echter als een paal boven water dat ik meer moeite moet doen om mijn Windows partities veilig te houden dan mijn Linux partitie.

Hieronder soms ik enkele van de belangrijkste gevaren op. Sommige gelden voor zowel Linux als Windowsgebruikers. Telkens bespreek ik ook enkele mogelijke oplossingen.

De grootste gevaren

Surfen zonder Firewall

Dit is zonder twijfel de grootste reden waarom er zoveel virussen in omloop zijn. Een firewall is ontworpen om code die zichzelf automatisch probeert te laten uitvoeren tegen te houden. Toegegeven, niet alle code is schadelijk, maar het merendeel van code dat zich probeert uit te voeren op jouw computer kan schadelijk zijn en wordt beter tegengehouden. Veel browsers bieden mogelijkheden aan om jouw surfervaring nog veiliger te maken door bijvoorbeeld Javascript uit te schakelen of te beperken in zijn activiteiten. Maar deze mogelijkheden zijn helemaal niet genoeg om jou een surfveilige ervaring te laten beleven. Een firewall is noodzakelijk. Je hoeft niet onmiddellijk je zak in te duiken want er zijn ook prima gratis alternatieven beschikbaar via het Internet. Zelf draai ik nu Comodo Firewall Pro. Dit is een gratis firewall oplossing die je hier kan downloaden. Er zijn nog tal van prima alternatieven die je kan vinden door gewoon even via Google op 'free firewall' of 'gratis firewall' te zoeken.
Het cliché dat een firewall een computer enkel trager maakt gaat ook niet meer voor elke firewall op. Als je een groot beveiligingspakket (een "suite") koopt, dan kan je best wel wat vertraging verwachten want deze nemen ten eerste veel plaats in op jouw computer en scannen verder nog eens elke actie die jouw computer onderneemt. Comodo, de firewall die ik hierboven heb aangeraden, neemt amper 30 MB op je harde schijf in en houdt ook de meest voorkomende problemen tegen. Het is duidelijk. Het is niet nodig voor een modale gebruiker die enkel wat surft, zijn mails leest, een word-document typt en andere dergelijke gewone taken verricht dat elke actie gescand wordt. Hier is het belangrijker dat het inkomend en uitgaand Internetverkeer (zowel UDP als TCP) wordt gescand en als er dan toch een mogelijk gevaarlijke actie zou dreigen uitgevoerd te worden, zal deze waarschijnlijk ook opgevangen worden. Een minimum aan een firewall is noodzakelijk om je computer veilig te houden.

Spyware

Spyware is een fenomeen dat de voorbije jaren sterk in opkomst is. Spyware is software die vaak zonder uw medeweten op uw computer geïnstalleerd wordt en belangrijke informatie probeert te registreren zoals de nummer van uw kredietkaart, het paswoord van uw server of uw account en ga zo maar verder. Spyware wordt vaak verspreid met gratis programma's op het Internet.
U wil natuurlijk privé-gegevens ook privé houden en daarom moet u bescherming tegen spyware hebben. Zelfs de meest voorzichtige surfer lijkt hieronder te lijden en er zijn enkele prima alternatieven op het Internet te vinden die bovendien ook nog gratis zijn!
Spijtig was er geen enkel programma die alle courante vormen van Spyware wist te onderscheppen maar twee programma's die samenwerken vinden meer dan een programma alleen. Ik kreeg eerst en vooral het programma Ad-Aware van Lavasoft aangeraden via PC-Magazine voor het verwijderen van spyware. Het programma werkt heel gebruiksvriendelijk en biedt de mogelijkheid aan om een Full-Scan of een Smart-Scan te doen. Ik raad je aan om eerst de Full-Scan zijn werk te laten doen en dan wekelijks of maandelijks te opteren voor een Smart-Scan. De Full-Scan duurt weliswaar lang maar scant elk bestand op je hele harde schijf. Zo kan je zeker zijn dat elk bestand aan een grondig onderzoek is onderworpen. De Smart-Scan scant enkel de locaties waar spyware zich het vaakst vertoont. Deze is sneller maar natuurlijk minder grondig.
Tests van PC-Magazine wezen blijkbaar uit dat hoewel Ad-Aware heel goed is, het niet alle courante spyware kan detecteren. Daarom raad ik je aan om ook Spybot Seek and Destroy te downloaden en te installeren. Deze hanteert een andere werkwijze want Spybot wordt geleverd met een database vol mogelijke dreigingen en waar deze zich zouden moeten bevinden in jouw besturingssysteem. Spybot overloopt bij elke scan de volledige lijst en duid aan waar hij iets (mogelijk) schadelijks heeft gevonden. Zo kan je via een simpele druk op de knop deze spyware het zwijgen opleggen.

Niet up-to-date zijn

Toen mijn moeder me deze middag vertelde dat ze op haar werk steeds zo'n vreemd (en vervelend) icoontje krijgt rechts beneden dat haar vertelt dat er updates beschikbaar zijn voor een of ander product dat Symantec heet en dat ze telkens gewoon op "Remind me later" klikt kreeg ik de kriebels. Dit is volgens mij de derde grootste dreiging die voor jouw computer kan bestaan. Het is een gevaar dat voor elk besturingssysteem onder de zon geldt, updates zijn belangrijk! Als je antivirussoftware niet update, dan kan deze enkel zoeken achter virussen die bekend waren toen de software werd gepubliceerd. Nieuwere virussen ontsnappen dan aan de aandacht van de scanner en dit is niet de bedoeling.
De meeste producten maken het zelfs kinderspel om updates binnen te halen. Ze melden het via een dialoogvenster. Al wat je dan moet doen is op de bevestigingsknop klikken en alles wordt geregeld zonder dat jij iets moet doen. Eigenlijk heb je geen excuus om geen updates binnen te halen.

Alle bijlagen openen

Iedereen krijgt wel eens een mailtje met een bijlage. Dit zijn soms afbeeldingen, tekstbestanden of powerpointpresentaties. Allemaal leuk en wel maar je zou nooit een bijlage mogen openen die van een onbekende afzender komt. Al deze bestanden kunnen geheime code bevatten die bedoeld zijn om informatie te stelen van jouw computer of om jouw computer onklaar te maken. Vroeger waren afbeeldingen nog veilig maar ondertussen is het dankzij extensie-spoofing al mogelijk om in zelfs afbeeldingen schadelijke code te verstoppen. De meeste e-mailproviders bieden wel een virusscan aan en zo worden veel virussen in bijlage van de mail ontdekt maar deze service is niet perfect. De regel hier is: open nooit een mail waarvan je niet zeker bent dat deze 100% betrouwbaar is.

Zeker nu Valentijn nadert zijn bijlagen gevaarlijk. Rond deze feestdagen zijn sommige mensen gewend om mailtjes te krijgen met lieve boodschappen in bijlage. Het is zo dat gevaarlijke virussen zich kunnen verspreiden. Sommige virussen gaan nog zo ver dat ze zelf een mailtje sturen naar iedereen in jouw contactenboek en zo het virus verder verspreiden. Voorzichtig zijn is de boodschap.

Paswoorden

Een goed paswoord is de eerste stap naar een betere beveiliging. Er bestaan tegenwoordig databanken gevuld met de meest gebruikte paswoorden. Hackers gebruiken dan programma's om deze databanken te overlopen en uit te proberen op jouw account. Je moet origineel zijn als je een paswoord kiest. Hoe meer variatie tussen grote en kleine letters en tussen letters en cijfers, hoe moeilijker een computeralgoritme het heeft om jouw paswoord te kunnen raden. Natuurlijk lijkt zo'n paswoord moeilijk te onthouden maar dit kan je makkelijk via geheugensteuntjes oplossen. "Mijn hond sliep vannacht 8 uur lang in zijn mand", kan je omvormen naar "Mhsv8lizm" door gewoon de eerste letter van elk woord te nemen. Het is een goed paswoord, want je hebt afwisseling tussen grote en kleine letters en tussen letters en cijfers. Dit is een redelijk veilig paswoord.

Wat je echter nooit mag doen is je paswoord opschrijven en bij je computer achterlaten. Dit is een vaak voorkomende fout op kantoren waar sommige medewerkers zelfs zo ver gaan als hun paswoord op een post-it aan hun computerscherm te hangen. Zo vraag je voor ongeauthoriseerde mensen om jouw computer even binnen te dringen terwijl jij een lunchpauze hebt. Bedenk ook dat de meeste mensen paswoorden vaker gebruiken. Als een kwaadwillig persoon dus één van jouw paswoorden heeft kan hij misschien aan meer aan dan jouw e-mail.

Een ander groot gevaar bij paswoorden is Social Engineering. Dat is een telefoontje krijgen van een persoon die zich identificeert als "iemand van systeembeheer" of van de "informatica-afdeling". Hij deelt jou dan mee dat er een probleem is met jouw account en dat hij even jouw paswoord nodig heeft om het op te lossen. Dit paswoord geef je natuurlijk niet. Een systeembeheerder vraagt nooit jouw paswoord.

Wireless voor belangrijke gegevens?

Je moet je voorstellen dat jouw computer verbonden is met een server via een standaard netwerkkabel. Stel dat jullie de enige twee gebruikers zijn van deze kabel. Het wordt zo al verdacht moeilijk om gegevensverkeer tussen client en server af te luisteren en dit kan enkel gedaan worden door onderweg de kabel te onderbreken en jouw computer aan te sluiten.
Maar een draadloos netwerk is niet zo veilig! De stralen die in de lucht hangen kunnen door eender wie uit de lucht gepikt worden en gelezen worden. Als je dan belangrijke gegevens verstuurt en die worden onderschept is het nog een kleinigheid voor de onderschepper om deze te ontcijferen en kwaadwillig te gebruiken. Denk zo maar aan een aanlogprocedure. Daarbij wordt (bij sommige technologieën) jouw paswoord verstuurd over het netwerk! Het geeft jou toch geen veilig gevoel dat jouw paswoord ergens in de lucht hangt, waar iedereen het er kan uitpikken?
De regel is hier, gebruik geen wireless networking als het kan vermeden worden. De meeste hogere scholen gebruiken tegenwoordig een draadloos netwerk om hun studenten makkelijk toegang te verlenen tot het schoolnetwerk en daar is geen probleem mee. Begin gewoon niet met belangrijke data via dat draadloos netwerk te versturen waar nog 500 andere studenten mee verbonden zijn. Een ongeluk is snel gebeurd. Vermijd echter het draadloos internet op de werkplaats tenzij het echt niet anders kan. Wees in elk geval dan nog zeker dat je de tips betreffende paswoorden goed opgevolgd hebt.

Dit zijn eigenlijk allemaal simpele stappen die je kan ondernemen om je computer veiliger te houden en de meeste berusten op gezond verstand. Veel mensen handelen echter uit onwetenheid op hun computer en creëert probleemsituaties. Denk heel even na bij elke actie dat je doet en je computerleven wordt er makkelijker van.

Ondersteunen of niet ondersteunen?

Deze blog verscheen eerst op mijn andere blog. Ik heb die gewoon overgenomen naar deze blog

In een perfecte wereld zou elke browser de standaarden perfect ondersteunen en sites zouden er in elke browser precies hetzelfde uitzien. Spijtig genoeg zijn we nog ver van dat doel verwijderd. Er zijn ongelooflijk veel browsers in omloop en ze hebben allemaal hun eigen vreemde karaktertrekjes en hun eigen interpretatie van de Webstandaarden. Zelfs de meest gebruikte browsers zoals Internet Explorer, Opera en Firefox tonen een pagina niet altijd op dezelfde manier.

Je website ontwikkelen zodat deze in alle browsers er precies uitziet zoals je wou, is vrijwel onmogelijk. Als je al ondersteuning wil inbouwen voor de meest gebruikte browsers moet je hier en daar een CSS hack toepassen of rond het probleem werken. Wat een zootje!

Het resultaat hiervan is dat webontwikkelaars verplicht worden om zelf te beslissen welke browsers en welke platformen ze ondersteunen en welke browsers ze links zullen laten liggen. Als er webontwikkelaars elkaar ontmoeten aard de discussie vaak uit in welke browsers hun sites ondersteunen en waarom ze dit besloten hebben.

De laatste jaren wordt er vaak gepraat over het ondersteunen van verschillende browsers. Dit komt zeker door de opkomst van Mozilla Firefox. Er blijkt een inzicht te zijn ontstaan bij webontwikkelaars dat Internet Explorer misschien niet de browser van de toekomst is en velen voerden aanpassingen door aan hun onderliggende code om hun sites met Mozilla Firefox compatibel te maken.

De grote vraag die webontwikkelaars zich moeten stellen is welke browsers ze willen ondersteunen en welke ondersteuning ze in de nabije toekomst willen laten vallen.

Deze beslissingen kunnen op enkele verschillende manieren genomen worden.

• Statistieken

Vele webontwikkelaars baseren hun keuze op statistieken die ze verzamelen op sites zoals WebSideStory. Dergelijke sites verzamelen informatie over welke browsers hun site bezoeken en op welke besturingssystemen deze browsers draaien. Zodra de statistieken dan aantonen dat een bepaalde browser amper gebruikt wordt, laten deze webontwikkelaars dan de ondersteuning voor die browsers achterwege.


• "Don't care about Market Share"

Eric Meyer, de auteur van het gelijknamige artikel toont aan dat webontwikkelaars naar de logs van hun eigen webservers zouden moeten kijken om deze beslissing te maken. Uiteindelijk is het belangrijker dat jouw site goed werkt op de browsers die gebruikt worden om jouw site te bezoeken, dan dat jouw site ook functioneel perfect is bij andere browsers. Je moet het doelpubliek van je site kennen en je beslissingen dan ook afstemmen op dit publiek.

Spijtig genoeg werkt deze aanpak ook averechts. Stel jezelf een browser voor die een bepaalde site niet goed weergeeft. Je zal snel stoppen met deze site te bezoeken omdat deze er toch visueel onaantrekkelijk uitziet of omdat deze gewoon niet werkt. De statistieken die jouw server bijhoudt zullen hierdoor ook aangetast worden en aantonen dat bepaalde browsers zeer weinig gebruikt worden om jouw website te bekijken en dat kan je als webontwikkelaar dan aanroepen om ondersteuning voor deze browsers te laten vallen terwijl je net aan die ondersteuning had moeten werken om die bezoekers niet kwijt te raken.

Er zijn redenen genoeg om ondersteuning voor bepaalde browsers niet in te bouwen. Sommige aanpassingen vergen te veel werk terwijl andere een volledige herstructurering inhouden. Jim Byrne houdt vol dat het Web ontworpen is om informatie voor iedereen beschikbaar te maken. Het zou mogelijk moeten zijn dat alle browsers de Webstandaarden op dezelfde manier ondersteunen zodat elke site precies op dezelfde manier werkt in alle browsers. Dit zou echter een grote inspanning vergen van de leveranciers van de browsers. Het is precies daarom dat er tools worden gelanceerd op het Net zoals de ACID-tests. De ACID-tests zijn proeven die een browser moet doorstaan om als voldaan te worden beschouwd. Internet Explorer, Firefox, Opera en nog andere browsers voldoen misschien wel (ternauwerdood) aan ACID2 maar binnenkort verschijnt er een definitieve ACID3 test. Als jouw browser voldoende compatibel is met de standaarden, moet de browser 100/100 scoren of een score die in elk geval al in de buurt ligt.

Als je hier klikt ondergaat je browser de ACID3 test. Opera, de browser waarmee ik de ACID3 test heb afgelegd scoorde slechts 52/100, wat duidelijk nog sterk ondermaats is. De ACID3 test is echter ook nog steeds onder constructie en kan nog niet als finaal beoordelingsmiddel gebruikt worden.

Sinds de ACID3 test echter werd aangekondigd kondigde Mozilla aan dat ze een nieuwe versie van Firefox zouden uitbrengen die de ACID3 test kon doorstaan en Microsoft volgde door Internet Explorer 8 aan te kondigen. De toekomst zal aantonen of deze nieuwe releases een stap in de juiste richting zijn.


Wat kan je doen om de ondersteuning te verbeteren?

• Vermijd code dat problemen geeft

Er zijn meestal manieren om code te vermijden die problemen kan geven in verschillende browsers. Het vermijden van zo'n code zorgt ervoor dat je veel meer browsers tegelijk kan ondersteunen zonder dat je daar extra veel moeite voor moet doen. Als je dan toch functionaliteiten op je site wil toevoegen die problemen kunnen geven, doe dit dan op een onopvallende manier. Als de functionaliteit dan niet werkt in een of andere browser, dan blijft de site toch nog operationeel en aantrekkelijk om te gebruiken.


• Minimum, minimum, minimum!

Voorzie een versie van je site die voornamelijk uit tekst en HTML bestaat. Als je site Javascript gebruikt en de bezoekende browser ondersteunt geen Javascript (of heeft uit veiligheidsoverwegingen Javascript uitgeschakeld), dan moet de site nog steeds werken. Voorzie bijvoorbeeld een link op de startpagina naar je site zonder Javascript of mét Javascript. Dat vereist echter veel werk om gewoon meer browers te ondersteunen dus dat verslaat het nut alweer. Je kan de browser wel laten detecteren of Javascript ondersteund worden en de site automatisch aanpassen aan deze ondersteuning. Zo blijft de site werken, of de bezoeker Javascript ondersteund of niet.


• Probeer geen browser buiten te sluiten

Probeer altijd objectief te besluiten wat de voordelen zijn om een browser te ondersteunen en hoeveel mensen gebaat zijn bij die beslissing. Als jouw serverlogs aantonen dat niemand van de bezoekers Firefox gebruikt is het nutteloos om uren te spenderen zodat jouw site ook werkt onder Firefox. Overweeg echter wel het tegendeel. Zullen er meer Firefox gebruikers jouw site beginnen bezoeken als jouw site ook goed werkt met Firefox? Het is belangrijk om steeds elk facet te bekijken bij het nemen van een belangrijke beslissing voor het voortbestaan van jouw site.

Bij het schrijven van dit artikel ben ik ongelooflijk geholpen door the Tech Republic.com.