Prototype vs JQuery or Where did Prototype go?

First of all, no, Prototype isn’t completely gone, yet. I know I didn’t expect it either 😀

In general Prototype shouldn’t really be compared with JQuery, because JQuery is just an easy way to write JavaScript and  Prototype type is entirely different abstraction of the JavaScript language but for the sake of argument let’s say that they are comparable.

Several years ago Prototype was the popular framework for JavaScript and then JQuery appeared and Prototype was kinda forgotten.

Now popular applications that were using Prototype in the past are switching to JQuery.

And here comes my question: why? What happened with Prototype?

Well my theory is simple: Prototype is just too complex.

Prototype brings OOP into the JS world. The plain arrays, objects and primitive types that you previously had with Prototype are gathered into doing-stuff classes.

On theory, sure, it sounds cool – you have objects on the back-end you have objects on the JS front-end,  you can reuse functionality and structure logic and etc.

On practice though is more redundancy than good design concept (in my opinion), because you need to program (more or less) the same models twice.

If Prototype was more like ClojureScript and gave you possibility to transfer automatically the domain objects to JS front-end object I would actually understand the point of having Prototype but as it is right now in my opinion – having objects just to gather properties and functionality is not good enough reason to have them.

Btw  if you haven’t check out ClojureScript before please do, it is awesome (on a concept level at least :D)

Joomla Vulnerability Bug

Joomla Vulnerability Problem

I should be honest I am not big fan of Joomla, I don’t really like the quality of their code base and the architecture of their solution at least when it is in comparison with the current state of WordPress for example.

Anywho 2 days ago Joomla gave me quite a scare. One ‘hacker’ – kid with nothing better to do – exploited one dangerous Joomla vulnerability.

There was apparently BUG in the file upload and in the com_media administration component, which BOTH bypass the user session check.

This Joomla vulnerability give you permission to upload files to  every folder in the site, which could be quite dangerous ‘feature’ if the site was in the hands of better (real) hacker.

First the media library present you with nice window which you can reach on:

Joomla Vulnerability

Afterwards the upload file functionality permits you to upload file without any authentication.

This bug is so obvious and so dangerous that I am only let to believe that it was left on purpose.

Joomla Vulnerability Solution


Now let’s try to fix this bug:

1. Check if you have everywhere but mainly in the file /administrator/components/com_media/media.php:

defined('_JEXEC') or die;

2. Restrict the assess for guests:

// Access check: is this user allowed to access the backend of this component?
if (JFactory::getUser()->guest) {
    return JError::raiseWarning(403, JText::_('JERROR_ALERTNOAUTHOR'));

Or if you prefer 404 message

// Access check: is this user allowed to access the backend of this component?
if (JFactory::getUser()->guest) {
    return JError::raiseWarning(404, JText::_('JERROR_LAYOUT_PAGE_NOT_FOUND'));


Maybe that is not the most elegant solution but it still fixes successfully one really dangerous security hole.

If you have better suggestions I will be happy to hear them :)


More Joomla Vulnerability examples you can find under:

If you want to test the ones that are already exploited go to specific vulnerability and scroll down to references:

joomla vulnerability references

There you can find Metasploit code or manual explanation of  the exploit.

You can also try the direct link:

JQuery Performance Tests – Bazaar

JQuery is currently the most popular JavaScript library on the world. Therefore apparently everybody seems to be an expert on it.

I just spend some time reading articles from ‘experts’ and what they advise you to do.

NB! All tests which follow are executed on the 3 browsers: Chrome 35, IE 11 and Firefox 30-32.

1. $(“#id”).find(“p”); JQuery performance is 2 times faster than $(“#id p”); .

After running tests on those 2 I can conclude only that he must be one passionate  IE user :)

For the 2 other browsers the process time for the both functions is nearly the same.

For those who want to try the test on their own:


2. Learn the entire library.

The example that was given in this article to support this theory was the following.

You shouldn’t use that:

a.hasClass('b') ? a.removeClass('b') : a.addClass('b');

You should use that:


I agree that the second one is obviously shorter but that is pretty much all advantages to it.

Let’s prove it though instead of leaving empty statements in the air.

I run the both pieces of code in 3 browsers and here is the results.

The JQuery performance for all browsers is better with the manual and add/remove of class functionality than the toggle one.

Here is the actual test so you can try it on your own:

3. $(“#id p”);  performs faster than $(“p”);

The only browser on which that is true is Chrome. And in IE actually $(“p”); performs much better.

Here is the test

4. Id vs Class selectors vs HTMLselectors

This one is really old advice from the time when JavaScript was still not popular and the experts on it weren’t that many.

Since JQuery is built on JavaScript we would only expect that the  JQuery performance for IDs should be also the fastest.

In this test we have clearly faster ID search for all the browsers.

On second place is the class selector and the last place remains for the HTML selectors.

Mandrill webhooks troubleshooting

mandrill webhooksThis article provides advices for easier testing on custom applications integrated with Mandrill Webhooks.

Mandrill is transactional email platform created from the popular email subscription ‘newsletter’ service Mailchimp. Mandrill is competitor of services like Sendgrid, Mailjet and etc. By far is the cheapest and most flexible solution out there. Furthermore due the fact that it is relatively new it still gets new features every day.



Mandrill supports two ways for sending emails:

On the other end there are Mandrill Webhooks. 

Mandrill Webhooks pushes events (send, open, click) back to chosen from you URL. That makes possible for you to keep track on the email status.

Two things about Mandrill Webhooks that is nice to know in advance:

  • They don’t support email ‘delivery’ event.
  • All events are normally fired with 7-10 minutes delay.

Test Mandrill Webhooks in couple easy steps:

1. Save all possible RAW HTTP requests that Mandrill can send.

Use RequestBin for that.

RequestBin  provides you with temporary URL on which you can submit HTTP requests.  On the same RequestBin URL you will be able to preview all the submitted requests.


2. Import the requests in Postman.

Postman is extremely cool and easy Google Chrome Extension. It is used for testing REST web services and ordinary HTTP requests.

The nice really thing about this solution in comparison with APIKitchen and Hurl is the possibility to store and order your request structure.

As user interface Postman resembles Hurl. Besides the ordinary Parameter/Value input that you can have in both Hurl and Postman, in Postman there is also possibility to use ‘Raw’ requests. This functionality is really handy when you need to copy already existing query source from RequestBin, for example. Unfortunately the syntax of the Raw request is often harder to comprehend. Furthermore unfortunately the Form-data (Parameter/Value) and the ‘Raw’ data are not synchronized.  Therefore if values are added in both tabs you will end up with two completely different requests.


You can use this apps for all kind of developing, testing or debugging. They will definitely safe you hours during the process.


Development of emails – practical tricks

The purpose of this article is to give some practical advises for those who want to make professional and elaborate development of emails from scratch.

Every well developed email should consist of two parts: html and plain-text.


The plain-text version is used from some mail clients which are not able to process the html or are not able to process fully the email content-type.

The plain-text part is relatevely easy but there are still some issues that you should take into consideration during the development of this part of the email.

The most major one is the email constrain for 78 characters per line.

The text version is usually presented as is. That means that is there is a link which takes more and 78 characters it will be presented on several lines. In most cases the mail client highlights only the first line of the link or it makes empty space on the line switch. In both ways normally the client won’t be able to handle such link and he will consider as broken.


  • Consider using shorter links – that is obvious solution but sometimes the most easy solution is also the right one. There is no point for you to develop something too elaborate if you could get around it by making better named links
  • Use link-shortener – I could be buyest but I would recommend the Google library … It is easy to wrap your head around and it is pretty straight forward.

HTML part

The html part is the one that 90% of your clients will end up seeing and it is the one that usually creates the most troubles.

The first think that you should keep in mind when you develop emails is even though that you are using html and css most of the tag and structures won’t be recognized the same way as in a normal web browser.

n other words for those who know the html from 15-20 years ago – this is the level of tags and structures that you are able to use.

And here are some advises for those who don’t want to commit suicide in the middle of some email coding 😀 😀

1. The CSS should be inlined.

Most email clients doesn’t process at all styling which is different than inlined. On the other hand I believe that developing with inline styling is really frustrating in long term. So the thing that I usually do is develop with normal CSS in other style and afterwards I use auto-inline tools, functions, libraries which  process the entire document and put the needed styling on the right places.

Example of such tool is:

2. Use tables and avoid DIVs

Yes, probably that is exactly the opposite that you have heard which developing normal html pages but the truth is that you should consider the mail clients like really outdated browsers and using DIVs could end up horribly.

For example mail clients like Hotmail and Outlook don’t recognize padding and margin on divs at all. Furthermore background pictures on divs are problem in almost every mail client. Furthermore floating, positioning, negative margins and padding is no-go all mail clients.

3. Avoid pictures and text mixed in the same content.

Setting background in email picture can be tricky. Generally you should stick to tables and letting them define the size of the picture.

The code above will work for most mail clients but as usual Oulook is a bit ‘special’ 😀 😀 //as most Microsoft products

In order to make the picture also visible in Outlook you should add group of special tags which only Outlook can process:

4. Code for Gmail and fix for Outlook

You should get real with the fact that you won’t be able to make the email looking exactly as you want for all mailboxes that’s why you should focus your attention on the most popular ones. Gmail is not only one of the most popular clients but it is also the easier way to start with the emails. Once when you make the email looking good in Gmail the Hotmail/Outlook nightmare will begin.

5. Use ‘view online’ link

There are around 10% from the receivers of emails that press on the view online link immediately after opening the email. Having link like that will give additional possibility for your users which have unconventional mailboxes.

Magento directory structure

Magento aims to decrease the amount of time that developer uses for manually including of files into the different modules and on the other hand to decrease the amount of files, which has been load on a single request. In order to do that it uses specific directory structure, xml configuration and some additional configuration under the app/code/Mage/Core.
The most important directories under the Magento root folder one are presented with orange in the figure on the right. At this level in the hierarchy the directory naming is based on keywords.
The files under the directory ‘app’ are, as it can be suggest from the name, build the entire functionality of the web shop application, they are never addressed directly by the browser.

The ‘js’ folder contains all JavaScript libraries used in Magento. The mainly used library in the Magento 1.xx versions is Prototype, therefore the usage of the other popular JavaScript libraries e.g. JQuery should be taken careful, because it can cost conflicts. The expected JavaScript framework for Magento 2 is JQuery.

The ‘lib’ directory contains different libraries – Zend, Varien are the libraries implemented by Magento and other third party libraries. In the Varien library for example contains the autoloader, which loads the PHP files called from the factory methods.

The ‘media’ folder contains the uploaded files for given module. For example the products and categories images are placed under the ‘catalog’ directory.

The ‘skin’ directory contains three design areas/folders ‘adminhtml’, ‘frontend’, ‘install’ and each of them contains images and css files specific for the current area. They are always accessed from the browser.

The ‘var’ directory contains the dynamically-created and temporary files such as cache, logs, session storage. This folder can be completely deletes Magento will recreate it, if it is needed.

The files under the root directory are colored with blue in the figure on the right. The file ‘.htaccess’ contains the host configuration for the apache. It is mainly used for declaring URL rewrites e.g. if you enable the URL rewrites, URL from the type ‘http://xxx/webshop/admin’ will be automatically translated to ‘http://xxx/webshop/index.php/admin’. In the webshop the URL rewrites can be enabled. The index.php is the initialization file – this is the only entry to the web shop application. And cron.php is used for scheduled job functionality.

The most important folder for the proper Magento system functionality is the ‘app’ folder: It is presented in the figure in the right the three folders underneath have different responsibilities to the end system functionality.
The ‘code’ directory consists of the 3 code pools in Magento:

  • core – this is the base, the core Magento functionality. These files should not be changed from the custom modules.
  • local – this is for Magento custom modules in development phase
  • community – this is for Magento custom modules in production phase

The design folder divided the same as the skin into three areas/folders ‘frondend’, ‘adminhtml’ and ‘install’. Each of them consists of its own templates(.phtml) and layouts(.xml) files.

The ‘etc’ folder contains ‘modules’ folder containing the register .xml file for each module e.g. Company_Module.xml. Without file in this directory all files from a certain module are not going to be evaluated from the system.

The ‘locale’ folder contains the different language possibilities and the map file (.csv) is for the different language files.

Can Agile be ad hoc?


Probably the first reaction for everyone would be: Hell no!

I believe though, that the right answer is: yes!

Most people forget the agile is not about planning – yes, in most cases we take Kanban, Scrum, TDD, and etc. for managing and planning the development process but all those activities are not actually part of the initial agile description – Manifesto for Agile Software Development

Furthermore, ad hoc is word used often with negative outtake, it gives us sense of chaos and unpredictability, which is not considered as good even in small dynamic companies. I believe, that ad hoc could work in a way. If company development resources corresponding with the task requests coming daily, the planning is not really necessary even quite the contrary it could be waste of time.

I believe, that planning doesn’t necessarily means increased productivity and better process handling by default. For agile, the people are the greatest resource. I believe that experienced enough developer could be better in planning on the fly and making educated guesses about the severity and the importance of tasks than most managers.


HOWTO: Design good Domain model

Designing domain models is probably the first thing that every software developer learns in school.

The concept for good domain model is quite simple: diagram representing the business objects (entities) in a system and the relations among them.

The purpose of the domain model is to create a common language, terminology and understanding for the system and the business around it.

Even though it might be a simple and well-known definition it somehow seems to be also quite tricky and hard to follow through.

Continue reading HOWTO: Design good Domain model

RabbitMQ Clojure Example

RabbitMQ is a messaging application. You can relate it to similar solutions like ActiveMQ or MSMQ.

Essentially RabbitMQ is commonly-used, light, flexible and relatively fast AMQP solution. The Advanced Message Queuing Protocol (AMQP) is two layered (Functional and Transport) binary protocol specially tunned for message sending 😀 so to say – more information about AMQP and AMQ Architecture here. Furthermore RabbitMQ provides additional plugnins for STOMP, MQTT and bridge for ØMQ

ActiveMQ is more sophisticated, highly configurable and multi wire level protocol solution – currently possible protocols are AMQP, MQTT, OpenWire, REST, RSS and Atom, Stomp, WSIF, WS Notification, XMPP – more information here. The default protocol for ActiveMQ is OpenWire you can see/edit it in /apache-activemq-version/conf/activemq.xml

Continue reading RabbitMQ Clojure Example