Eclipse & java.lang.OutOfMemoryError

Ik ontwikkel regelmatig in Java en gebruik dan de integrated development environment Eclipse. Voor sommige klanten heb ik in het verleden geheugen-intensieve applicaties ontwikkeld. Als deze applicaties binnen Eclipse gedraaid worden, bijvoorbeeld om te testen, is het mogelijk om een melding als deze te krijgen:

Dit betekent dat er niet genoeg geheugen binnen de Java Virtual Machine gereserveerd kan worden om de applicatie (verder) uit te voeren. De oplossing is om binnen Eclipse meer geheugen toe te wijzen aan de JVM. Dit is mogelijk door naar de eigenschappen van het project te gaan (rechter muisklik -> Properties). Vervolgens naar Run/Debug settings, en bewerk de configuration voor de klasse met de main-methode. Onder tabblad Arguments kunnen argumenten opgegeven worden voor het programma of de Java virtuele machine. Vul onder VM arguments bijvoorbeeld het volgende in:

  • -Xms512M -Xmx1524M

Dit houdt in dat de minimale heap size 512MB is, en dat het kan groeien tot 1524MB. De waarden 512 en 1524 kunnen aangepast worden voor een ander resultaat (bijvoorbeeld -Xms40M -Xmx256M)

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone

Android: App Inventor van MIT

App Inventor, onderdeel van MIT Media Lab, is een tool waarmee eenvoudige Android applicaties ontwikkeld kan worden. En dat allemaal met alleen een browser en een Android smartphone (of emulator).  Inmiddels is aan het eind van 2013 versie 2 van deze tool uitgebracht.

Sinds 2009 hebben meer dan een miljoen mensen al gebruikt gemaakt van de App Inventor, waarmee meer dan 3 miljoen projecten zijn gecreëerd.  Met App Inventor versie 1 kon men via de web browser de lay-out componenten definiëren. Vervolgens werd de Java Web Start applicatie Blocks Editor gestart om verdere invulling aan de applicatie te geven. Het screenshot is een onderdeel van de Blocks Editor, en zoals te zien is, kunnen de acties en vervolgacties vrij eenvoudig gedefinieerd worden.

App Inventor versie 2 werkt vergelijkbaar, maar heeft geen Java Web Start applicatie meer nodig. Het online platform om apps te ontwikkelen bestaat uit twee onderdelen: Designer en Blocks.

Designer

App Inventor versie 2 - DesignerMet het Designer-gedeelte is het eenvoudig om de user interface van de applicatie te ontwerpen. Via de linkerkant is het mogelijk om user interface componenten op het scherm te slepen. Aan de rechterkant staat het overzicht van componenten en de eigenschappen van een geselecteerd component getoond. Eigenschappen zoals de achtergrondkleur, lettertype-grootte en -style, de zichtbaarheid en de tekst kunnen via dit gedeelte ook gewijzigd worden.

Blocks

Het Blocks-gedeelte is vergelijkbaar met de Java Web Start applicatie Blocks Editor van App Inventor versie 1. Via het Blocks-gedeelte kan de logica van de applicatie gedefinieerd worden. In onderstaand screenshot is bijvoorbeeld te zien wat er gebeurd nadat er op de knop btnPress wordt geklikt. De knop btnAgain wordt op zichtbaar gezet, en de tekst van label lblText wordt aangepast. Als er op de knop btnAgain wordt gedrukt, dan wordt deze weer onzichtbaar en wordt de tekst van label lblText weer teruggezet. In het midden is te zien dat er al meerdere acties klaarstaan om gebruikt te worden wanneer een user interface component is geselecteerd.App Inventor 2 - Blocks

App Inventor is een ideale tool voor de beginnende ontwikkelaar om eenvoudig wegwijs te worden met Android applicaties. Heb je weinig ervaring met Eclipse en wil je snel een prototype voor een Android applicatie in elkaar zetten? Gebruik dan App Inventor. Voor het serieuze werk is het waarschijnlijk noodzakelijk om een native Android applicatie in Java te ontwikkelen. Over native Android ontwikkeling in Java verschijnen dit jaar nog enkele artikelen op deze blog.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone

Syntax highlighting bij WordPress blog

In twee eerdere blog-berichten heb ik in de tekst source code (broncode) opgenomen. Aangezien ik mij afvroeg of het mogelijk was om bij WordPress berichten syntax highlighting toe te passen, ben ik op zoek gegaan naar plugins hiervoor.

Syntax highlighting, of in het Nederlands syntaxiskleuring, wordt voornamelijk bij broncode gebruikt om de code visueel te verduidelijken. Door meerdere kleuren voor verschillende leestekens of woorden te gebruiken, wordt de code makkelijker leesbaar. Tegenwoordig wordt dit standaard toegepast bij de moderne ontwikkel-omgevingen zoals bijvoorbeeld Eclipse of Visual Studio.

Bij de code hierboven is syntax highlighting ook toegepast; ditmaal bij een WordPress-bericht. Hiervoor pas ik de Crayon Syntax Highlighter-plugin toe, welke is ontwikkeld door akarmenia‎. Met deze plugin is het mogelijk om broncode op een duidelijke manier bij een WordPress bericht toe te voegen. Het ondersteund haast alle mogelijke ontwikkeltalen en heeft ook extra functies zoals als de broncode in een nieuw scherm te tonen, regelnummering aan of uit te zetten, en de broncode zonder syntax highlighting te tonen.

Ook is het mogelijk om meerdere thema’s te gebruiken bij deze plugins zoals te zien is bij bovenstaande voorbeeldcode. Daarnaast is het ook mogelijk om deze thema’s aan te passen. Kortom, de Crayon Syntax Highlighter is een zeer nuttige plugin voor de software ontwikkelaars die regelmatig broncodes plaatsen in hun WordPress berichten.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone

Chili Publisher – Online Document Editor

Vorige week was ik bij het kick-off evenement ‘Plug in the power‘ van CHILI publisher 4.0. CHILI Publisher, een veelbelovend product van het bedrijf Chili Publish, is een online document editor. In tegenstelling tot de meeste desktop document editors, kan dit product geïntegreerd worden in een web applicatie. Dit zorgt er voor dat eind-gebruikers dezelfde functies kunnen uitvoeren als vergelijkbare desktop applicaties, maar dan in hun browser.

Door middel van de CHILI API is het mogelijk om tegen deze online document editor aan te programmeren. Dit biedt tal van mogelijkheden, voorbeelden hiervan zijn de Magento plugin Chili Publisher Connector of de website Tadaaz waar de online document editor is geïntegreerd in een Drupal website. Voor een van mijn klanten pas ik het Chili Publisher product ook toe in een Business-2-Business omgeving.

Bekijk onderstaand promo-filmpje over Chili Publisher, of kijk voor meer informatie op de website.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone

PDF-documenten genereren in Java of C#

In dit blog-artikel ga ik in op het automatisch genereren van PDF documenten in Java of C#. In het verleden heb ik voor een opdrachtgever met behulp van iTextSharp automatisch PDF-documenten gegenereerd. iTextSharp is een .NET port van iText, een open-source library geschreven in Java. De PDF-documenten werden on-the-fly gegenereerd op basis van dynamische gegevens die een klant had ingevoerd.

Een andere library geschreven in Java is PDFlib, ontwikkeld door PDFlib GmbH. Met PDFlib is het mogelijk om lege blocks in een PDF-document te vullen met dynamische content. Daarnaast is het met deze library ook mogelijk om PDF-documenten uit te lezen en samen te voegen.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone

Yii: performAjaxValidation()-bug en oplossing

In het verleden heb ik voor een project het Yii-framework toegepast om een sociaal platform te bouwen in PHP met een MySQL database. Het voordeel van het Yii-framework is dat er veel documentatie en veel extensies beschikbaar zijn. Het nadeel van het Yii-framework en de extensies is dat er soms bugs kunnen zijn die niet meer worden opgelost. Gelukkig is er dan nog het Internet waarop bugfixs geplaatst worden.

Ik heb bij het bovengenoemde project het Yii-framework toegepast in combinatie met de yii-user-management extensie. Op onze test-server met Apache werkte deze extensie naar behoren. Echter op onze productie-server met Nginx kreeg ik deze error-melding:  “Declaration of YumTranslationController::performAjaxValidation() should be compatible with that of YumController::performAjaxValidation()” bij de user/translation/admin-pagina. Op deze pagina zou normaal gesproken de vertalingen beheert kunnen worden.

Aangezien wij deze vertaal-functionaliteit toepaste bij onze website, heb ik gezocht naar een workaround voor deze bug. Ik heb deze workaround bij de bug-melding op Google Code toegevoegd als opmerking. Het bestaat uit het aanpassen van de volgende 3 methodes in YumTranslationController.php-bestand (modules/user/controllers):

  • actionUpdate
  • performAjaxValidation
  • loadModel

Door de methodes te vervangen door de methodes hieronder lijkt het probleem opgelost.


 

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone

Free Bassel

Afgelopen weekend las ik het verhaal over Bassel Khartabil, een gerespecteerde open-source software ontwikkelaar uit Syrië. Deze ontwikkelaar heeft bijgedragen bij ontwikkelingen op het internet, onder andere door mee te werken aan het Aiki Framework-project.

Sinds 15 maart 2012 zit Bassel Khartabil vast na een golf van arrestaties in het Mazzeh-district van Damascus, zonder dat officiële instanties de familie op de hoogte houdt over de verblijfplaats. Al ruim een jaar is deze ontwikkelaar onvrijwillig verdwenen van de aardbol, zonder een legaal proces en zonder rechten die een vrij mens anno 2013 zou moeten hebben.

Als mede software ontwikkelaar kan ik iedereen alleen maar oproepen om de petitie te steunen die familie en vrienden hebben opgestart: http://freebassel.org/ 

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone

Magento en problemen met de snelheid

Vorig jaar heb ik voor een klant veel met het open-source e-Commerce Magento gewerkt. Magento is een uitgebreid systeem waarmee het mogelijk is om meerdere webshops te draaien binnen 1 Magento installatie. Vooral het feit dat zaken zoals de productenlijst of instellingen gedeeld kunnen worden tussen de webshops maakt Magento een sterk systeem.

Magento heeft echter ook een groot nadeel en dat is de snelheid, of beter gezegd; de traagheid. Het systeem kan soms aan de voorkant langzaam reageren en dat resulteert in een langere laadtijd van de pagina’s. Ook in de backend van het systeem kan het bij sommige acties traag reageren. Destijds ben ik bij deze klant begonnen met pogingen om de snelheid van Magento te verbeteren. Hieronder enkele tips daarvoor:

  • Installeer Magento niet op een shared hosting account, een VPS of dedicated server is beter.
  • Kies een server uit die voldoet aan de systeemeisen van Magento.
  • Probeer Nginx als webserver in plaats van Apache (vooral bij veel bezoekers op hetzelfde moment zou Nginx beter moeten werken).
  • Activeer Magento’s cache optie (via System -> Cache Management).
  • Deïnstalleer plugins die niet gebruikt worden.
  • Gebruik plaatjes die lossless gecomprimeerd zijn.
  • Mocht er veel wijzigingen aan de productinformatie zijn en de backend traag zijn, dan is het handig om via System -> Index Management het automatisch indexeren op handmatig te zetten. Door middel van cron jobs kan elke nacht het php-script indexer.php aangeroepen worden om te indexeren.
  • Repareer en optimaliseer op een rustig moment de MySQL database, en herhaal dit na enkele maanden (dit kan via phpMyAdmin).
  • Voor de gevorderden onder ons, probeer extra tools op de server te installeren en te configureren zoals APC, Memcached en Varnish.

Mijn ervaring is, dat het een verminderen van de traagheid een iteratief proces is van meten en de server configureren. De snelheid van de site valt handmatig te meten met Google Chrome en de Page Speed Monitor plugin. Vertrouw niet te veel op de Site Speed die bij Google Analytics staat vermeld; deze rekent namelijk alleen de gemiddelde laadtijd van bezoekers met nieuwe browsers.

Mochten deze tips niet helpen, het is altijd mogelijk om tips op andere blogs te bekijken, zoals de tips van Guido Jansen.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone

Casus: Joomla-hack en oplossing

Tegenwoordig worden op websites steeds meer standaard Content Management Systemen (CMS) zoals Joomla, WordPress en Drupal gebruikt in plaats van custom-made Content Management Systemen. Het voordeel hiervan is dat er legio plugin’s, thema’s en handleidingen beschikbaar zijn voor deze systemen. Het nadeel hiervan is dat dergelijke systemen ook aantrekkelijk zijn voor kwaadwillende hackers, omdat deze systemen door talloze mensen gebruikt wordt.

Kwaadwillende hackers richten zich vaak op oudere versies van deze systemen, omdat daarvan bijvoorbeeld beveiligingsfouten zijn ontdekt en gepubliceerd. Zo werd ik begin dit jaar door een bekende gevraagd om naar de beveiliging van zijn Joomla-website te kijken. Deze persoon kreeg vaak klachten van klanten dat ze tijdens een bezoek aan de Joomla-website werden doorgestuurd naar vreemde Russische websites, met als gevolg dat de anti-virus & anti-spyware programma’s alarm sloegen. Niet echt positief tegenover je (potentiële) klanten als ze dergelijke zaken meemaken bij het bezoek van je website.

Onderzoek probleem

Bij het horen van de problemen, vermoedde ik al dat de website slachtoffer was geworden van kwaadwillende hackers. Als eerste onderzocht ik welke versie van Joomla werd gebruikt op de website. Dit is simpel te achterhalen door de broncode van de website te bekijken. Bij de meta-tags staat een tag vermeld met als naam ‘generator’ en daarachter de versie, in dit geval Joomla! 1.5. Deze versie is gereleased in januari 2008, maar is tot en met maart 2012 ondersteund met updates [1]. Op dit moment, februari 2013, zijn de meest recente versies: 2.5 (januari 2012) en 3.0 (september 2012).

Vervolgens onderzocht ik welke bestanden als laatste aangepast waren. Al snel ontdekte ik dat de website sinds april 2010 niet meer was bijgewerkt. Des te meer het opviel dat er in oktober 2012 een bestand ‘post.php’ in de map ‘images’ was geplaatst met de volgende regel code:

Opvallend was ook dat pas met Kerst 2012 dit bestand gebruikt (of misbruikt) is om de volgende bestanden te bewerken: CHANGELOG.php, configuration.php, COPYRIGHT.php, CREDITS.php, index.php, index2.phpINSTALL.php, LICENSE.php en LICENSES.php. Aan deze php-bestanden was op de 1e regel van het bestand de volgende code toegevoegd:

Deze code kan tot leesbare code omgezet worden door gebruik te maken van een online Base64 decoder zoals base64converter.com. Dat resulteert in de volgende code:

Uit deze code valt af te leiden wat er gebeurt bij het aanroepen van een van de getroffen php-bestanden. Men wordt alleen doorgestuurd naar http://onotiw.dnset.com/ (inmiddels niet meer bereikbaar), als ze via een zoekmachine zoals Yahoo, Bing of Google de website bezoeken. Dit verklaart ook waarom de werknemers zelf geen last hadden van de hack; zij gingen altijd direct naar de website (zonder gebruik te maken van zoekmachines dus).

Oplossing

De oplossing voor deze Joomla-hack is redelijk eenvoudig. Verwijder het bestand ‘post.php’ in de ‘images’-map. Via dit bestand was het immers mogelijk om overige php-bestanden aan te passen. Wijzig daarna de getroffen bestanden en verwijder de toegevoegde (base64 encoded) code op de 1e regel. Nu zijn de grootste wijzigingen van de hack teruggedraaid, maar het beveiligingsgat is nog niet gedicht. Het is trouwens mogelijk dat een kwaadwillende hacker nog meer bestanden heeft aangepast dan beschreven in dit artikel.

Mijn mening over het beveiligingsgat is dat de hack voorkomen had kunnen worden door het Joomla CMS up-to-date te houden. Een veelgebruikt CMS ruim 2 jaar niet updaten is vragen om problemen, zeker als er verwijzingen naar Joomla 1.5 in de broncode op je website te vinden is. De gevolgen waren bij deze casus nog te overzien, maar het is vervelend als door zo’n simpele hack bijvoorbeeld de gegevens uit je klanten-database op Internet te vinden zijn.

Ook bij het gebruik van open-source Content Management Systemen geldt: voorkomen is beter dan genezen.

Elke maand controleren of uw CMS en bijbehorende plugins en thema’s nog up-to-date zijn is dan ook aan te raden bij het gebruik van open-source content management systemen. Als u ook vermoeden heeft dat uw website gehackt is en u komt er verder niet uit, dan kunt u altijd contact met mij opnemen.

  1. Joomla. (2013). In Wikipedia. Retrieved February 26, 2013, from http://en.wikipedia.org/wiki/Joomla
Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone

Nederlandse language-file voor Image CRUD

Voor sommige opdrachtgevers, maar ook bij eigen projecten, voeg ik open-source libraries toe aan applicaties om zo sneller tot een resultaat te komen. Daarnaast is het ook zonde om steeds het wiel opnieuw uit te vinden als dit wiel door de makers ervan (onder voorwaarden) gratis wordt aangeboden. Laatst heb ik bijvoorbeeld de libraries van Grocery CRUD en Image CRUD in combinatie met het CodeIgniter framework toegepast bij een project.

Grocery CRUD is een library waardoor het eenvoudig is om de basisoperaties Create, Read, Update en Delete uit te voeren op een tabel in een database. Image CRUD is een library van dezelfde ontwikkelaar om de basisoperaties ook uit te kunnen voeren met afbeeldingen. Bij beide libraries is het mogelijk om de taal te wijzigen door het gebruik van language-files; bestanden die de vertalingen van de teksten bevatten. Bij Image CRUD was er nog geen Nederlandse language-file aanwezig. Als dank voor het beschikbaar stellen van de libraries heb ik de Nederlandse language-file voor Image CRUD opgesteld. Deze is inmiddels toegevoegd aan de GIT-repository van Image CRUD, dus beschikbaar voor iedereen.

Als u interesse heeft om Grocery CRUD of Image CRUD bij uw projecten te implementeren, dan kunt u altijd contact met mij opnemen.

Deel dit viaShare on LinkedInTweet about this on TwitterShare on FacebookEmail this to someone