So here I am 6 months later, installing Firefox 4 and transferring all the bookmarks to it from Chrome. I switched to Chrome half a year ago (or maybe even more) when Firefox 3 became so slow and bloated I could not take it anymore. Chrome seemed like a refreshing drink after a boxing match; me vs. Firefox 3, where Firefox 3 was punching me in the face over and over again.

Few days ago, as we were doing a site for a client, I saw the site in HTML/CSS coding state at one of our coders. He was using Firefox 4. Then I went back to my computer just to see if the site is looking OK in my Chrome. Shazam, the ugly-stick hit me in the head.

Here is a small test platform for you to test out the difference in rendering. It is a pure CSS example, with no images. Visit it with Firefox and Chrome and see what happens.

Here is a screenshot so you can compare, just in case:

You would have to be blind not to notice the difference. Firefox has much smoother shadows and gradients, Chrome just slaps them on screen. I guess it is a typical Google engineering thinking - "let's just make it work, no need to make it pretty".

You could argue now that this is a Webkit "feature" but A-HA! No it is not! If you open the same test page in Safari, you will notice that Safari renders shadows, both outer and inset, much smoother (still not as smooth as Firefox). It seems that the folks in Mozilla did something exquisite this time considering rendering.

I have checked all the usual pages I go to, from Wunderlist and all sorts of news sites, to Facebook & web Twitter clients, and the difference is obvious. Firefox makes stuff look pretty. Paired with the fact that it is blazing fast, has smooth scrolling with scrollbar ease as it approaches bottom/top, it is good bye Chrome, hello my dear old friend Firefox. I missed you. Do not bloat too much this time, you silly you.

You could say now "who cares, these are too small issues", but I say "I care". It is those little polished details that separate good looking website from great looking one. If we developers are moving away from using images to using CSS-only technique to accomplish something, this quality of rendering means a lot. From time to time such differences force us to fall back to using images for buttons (for example) instead of doing it all in CSS. And that matters.

From mid March, companies in Croatia can finally receive electronic money transfers via PayPal (read background story in my article published in Nacional).

Payment processing isn't something new in Croatia, but PayPal is. On-line stores were able for years to process user credit cards via some of our local popular credit card processing services like T-Com Pay Way or Webteh - WebPay (or directly through connections with each bank - less popular method). But only recently (a year ago), with arrival of Kolektiva and similar sites oriented to wider online consumer public, online payments started to become more popular, widely accepted and less frightened to a regular Joe.

In our e-commerce web development work so far, we had chance to work in close with following regional internet payment service providers:

• T-Com Pay Way (Croatia)
• Webteh - WebPay payment gateway (Croatia)
• PBZ MyCheckout (Croatia)
• EMS (Serbia)
• qVoucher (Serbia)
• Telemach - EON MegaPOS (Slovenia)
• direct connection with various banks in the region

And just recently - the PayPal.

No matter PayPal is mature product, integration was not walk in the park. From developers standpoint, I would definitely commend T-Com Pay Way, Webteh and qVoucher services for ease of integration and support they have. In contrast to PayPal's undocumented features (or lack of documentation and examples) or EMS's infinite redirects to 3rd party pages (enforced by other parties) in payment process.

PayPal
After some headache & time spent at the PayPal sandbox (self-contained environment within which you can prototype and test PayPal features and APIs) we finally managed to get it working.

We used widely used HTML way to integrate Website Payments Standard with our shopping cart (please see “Third-Party Shopping Carts – The Cart Upload Command”) since integration via API has been proven to be more complex and undocumented than Facebook's SDK.

For security we used Encrypted Website Payments (please see “Protecting Payment Buttons by Using Encrypted Website Payments”.

Encrypted Website Payments relies on public-key cryptography using OpenSSL which is available both as external program that can be executed from PHP and as php extension. Prepare to enter world of pain with this one, since most of examples use executable file to do actual encoding.

Using OpenSSL as extension with PayPal is not straightforward, best example can be found at PayPal SDK in php toolkit.

We implemented support for both IPN and PDT notifications:

• PDT (Payment Data Transfer) – is secure method to retrieve details about PayPal transaction after (and if) user chooses to return to our site after paying on the PayPal. It should be used only to display information to the user. Our system is not depending on it since there is no guarantee that this action will be executed.
• IPN(Instant Payment Notification) – is direct PayPal to our system communication. In order to verify authenticity of IPN data received from PayPal should be checked and then sent back to PayPal in exact order it was received. PayPal should respond with “VERIFIED”.

Please note that although PayPal send newline as CR+LF (%0D%0A), PHP returns these new lines as LF (%0A) – so, newlines transformed by PHP into LF must be replaced with CR+LF before data is sent back to PayPal. This bug can easily be reproduced if you enter both Address line 1 and Address line 2 during payment, because those two lines PayPal combines into one field separated with CR+LF.

You can try all all this, or you can just contact us for consulting and/or implementation services. :)

jQuery v1.6 release has been announced for May 1st and it will include rewritten internal method jQuery.attr and the addition of jQuery.prop. That will bring a solid performance improvement, a modularized implementation, and a cleaner way of dealing with attributes but this rewrite will confuse some people who have been using jQuery.fn.attr for cases for which it was not intended, but have always worked. Read more details about this on Timmy Willsons's blog (jQuery Core Bug team member) and check performance increase by the numbers.

$("div").attr("id", "holder");  // OK
$("video").attr("autofocus", true);  // OK
$(window).attr... // NO
$(document).attr...  // NO

Our friends at the bonbon network, knowing my deep hate for Android phones, have sent me this little phone.

Ideos, by Huawei.

Apparently, it is a joke on their side to send me one of the cheapest (if not the cheapest) Android phone to try to combat my iPhone 4. But, I went open minded into it.

read more