Blog has been moved

I’d like to announce that Junaid Bhura is now officially a web development studio!

I’ve stopped freelancing, and now run a studio in Bangalore. This blog will now be discontinued, and is being moved to: http://www.junaidbhura.com/blog/ . See you there!

Pixels (px) Vs. Em

Okay so this is a highly debated topic between what I believe are perfectionists in their own regard. Unfortunately for the other group, I’m going to take the side of pixels. Here’s why:

When I build a web site, I write code for it to be viewed on a computer screen. If I make a mobile version of that site, I write code for it to be viewed on a smaller mobile-device screen. And in both cases I believe that my site should render in a pixel-perfect manner across all browsers. Because that’s what is intended of me. That’s what I get paid for.

The W3C recommends using EMs on sites because of their scalable nature. What most people don’t realize is that most of the W3C’s recommendations don’t get adopted by all browsers, and that browsers themselves are customizable software. So there’s no way of determining the final outcome when you use EMs. Pixels on the other hand always deliver the desired results.

Pixels have been criticized of being too rigid. But that’s exactly why I like using them. Because they’re 100% reliable. And I believe that as developers, our jobs end in making sure our web sites render perfectly across browsers. It is the job of the Operating System and browser to make sure the user gets a customized browsing experience. For example, I’m pretty sure visually impaired users and users who have large screen resolutions browse the Internet on a 200% – 300% zoom on their browsers. Unfortunately, that’s where our web technology stands today. What’s the point of making fonts bigger yet images stay the same size?

Mobile devices will continue to rise as a popular means of browsing the Internet. But most “computer” web sites are not meant to be viewed on a mobile device. Either because they’re designed that way, or because there have less bandwidth-heavy mobile versions of the site available. In both cases, pixels play a significant role in ensuring a perfect browsing experience on a mobile device. One must not forget EMs are calculated based on pixels. So its more a question of responsive design than calculation of font sizes.

There definitely are occasions where EMs trump pixels in terms of them being a measure and not a unit themselves. And they should be used in those situations. I don’t see why percentage values (%) based on pixels can’t be used in those situations either.

IMHO pixels should be the standard in web development, not EMs. Not only because of their reliability and ease of use, but also because the pixel is the unit based on which a web page is actually rendered, not hypothetically rendered.

How to make a custom Magento payment extension for an external gateway

Magento is a great open source e-commerce platform and has emerged as the market leader in the recent past. However, it still has a steep learning curve and although the community is growing exponentially, I was not able to find a simple tutorial on how to make a Magento payment extension which links up to an external payment gateway.

In this tutorial, I’m going to attempt to show you how to make a bare-minimum extension, which you’ll need to complete because different payment gateways have different APIs, hooks and functionality. This is by no means a definitive guide, but my attempt to try and get you started. Please note this tutorial assumes that you already know how to build a simple custom extension and have average knowledge of Magento, MVC architecture and of course, PHP. This tutorial is for Magento versions 1.4 and above.

I have created a bare-minimum version of the extension which you need to download from the steps that follow. I hope the code will be self-explanatory. For information from Magento’s wiki click here.

Step #1: Click here to download the ZIP archive for this step. Extract it to app\code\local

Step #2: Click here to download the ZIP archive for this step. Extract it to app\design\frontend\base\default\template

Step #3: Click here to download the ZIP archive for this step. Extract it to app\etc\modules

Once you have done this, you need to follow the following steps to get it working:

1. Open app\code\local\Myname\Mygateway\controllers\PaymentController.php and read through the inline comments carefully. The URL that the payment gateway needs to redirect to on your web site after processing the customer’s payment (based on the naming we’ve used in this example) should be: http://www.yourwebsite.com/mygateway/payment/response . This URL will trigger the responseAction() function in the PaymentController, where we will need to validate the response sent by the gateway (to make sure it’s really from there), and if validated, process the order. The validation code is generally provided by the payment gateway.
2. Open app\design\frontend\base\default\template\mygateway\redirect.phtml . This is where we post our values to our external gateway. We can retrieve any order information and pass it on as hidden form fields, which is submitted via JavaScript.
3. Log into your Magento admin, clear your cache, and make sure the extension is enabled and working fine by navigating to System -> Configuration -> Sales -> Payment Methods and checking if you can see it there.

It is extremely important to go through all the files to get a perfect understanding of the extension. I figured the best way to learn this is to look at a working example. This took me a long time to figure out and I hope this saves a lot of effort for someone. Happy coding!

Do I need HTML 5 and can I use it now?

As of writing this post, the Internet is going bonkers about HTML 5 and how it is going to revolutionize the web as we know it. HTML 5 got a sudden surge in popularity in the last two years because many big players like Apple and Microsoft have started, or have promised to start support for HTML 5.

Although HTML 5 is expected to achieve a ‘W3C Recommendation’ status by 2022, many if not all major browsers have rebelled and have started to implement partial support for HTML 5 increasingly with each release. As things stand, HTML 5 is extremely shaky at the moment with different browsers implementing different features of HTML 5. This reminds me a lot of the browser wars from the ’90s, but the big difference is there no longer is one major player monopolizing the Internet, and browsers are now trying to be nicer to gain popularity. As current trends go, HTML 5 is gaining popularity like never before, and with good reason. It would be the next step in the evolution of the web.

But all that said, one extremely important question remains: Do I need HTML 5 and can I use it now? The answer to that question should be: yes, with the number of tools available, things are certainly looking up for HTML 5.

But …

Unfortunately, I would say NO. But allow me to elaborate. I feel HTML 5 is extremely unstable and would require an additional amount of effort to pull of successfully, if at all. If you are building an HTML 5 site for say, an iPhone, there will be no problem because you’ll have to check for compatibility for one device. But if you are looking to start a web site from scratch, or planning to upgrade your web site, I would recommend against using HTML 5 (as of the date of writing this post) because regular XHTML is supported across all modern browsers, and you don’t need HTML 5 today. When it comes to whether you can use it now, again, I would say NO because you can only partially use it now.

I would love to see HTML 5 become what it should be, and soon. Major players like Google and Facebook should impose a mandatory upgrade of all browsers to support HTML 5, and all users to upgrade their browsers. That would be the only way HTML 5 can see daylight anytime soon, other than the few bits and pieces which will slowly start to gain acceptance until it is released fully.

But until that happens, we don’t need HTML 5 immediately, and what’s worse: we can’t use it immediately.

The great payment squeeze

Pay me? Please?

As far as my understanding of services go, one gets paid for services if the client is satisfied with the service offered. A simple connection, and an exchange of synergies. I’m not sure if it is ‘customary’ here in India to not ask for money after a service is rendered, but people squirm where they stand when faced with the moment of sorting out finances. Sometimes, and usually the side which owes money gets offended at this ‘impolite and inconsiderate gesture’ on the part of the service provider. Or I could just be imagining things. I do have a very active imagination.

Whatever the cause, Indian companies, particularly media agencies and other service providers with no tangible products seem to find it difficult to make their clients pay them. This fact caught me by surprise because these agencies are in no way small-time. Quite the contrary, these were established firms with big clients.

Now since there are no funds to go around, it obviously affects the company both in-house and otherwise. Freelancers and vendors get caught in the crossfire, which is extremely unfair, because they are independently functioning businesses.

What I find hard to understand is why these agencies hire services when they are unsure of clearing payments for them. Or rather, with what nerve. The thought process that sparks this kind of behavior is a mystery to me, unless, there is something sinister going on in the background. Again, it could be my active imagination, but maybe… Just maybe.. They don’t really give a crap!

With this lack of empathy and basic business etiquette, a very unhealthy atmosphere is created for all involved. There would need to be a kind of buffer at every level of involvement. The freelancer needs to set a buffer because the client has a history of not paying on time. The client would need to set a buffer because their clients never pay on time, and so on.

I have recently changed my policies to reflect this, where I specifically mention that my client’s payment to me is independent of their clients’ obligation to pay them. I think it would be best if all companies had this term clearly outlined in their contracts, especially if they plan to outsource a certain part, or all of the service.

Anahita Open Source Social Networking Platform finally launched

Anahita Screenshot

Have you seen that scene from the Matrix where we are introduced to Neo in his dark apartment and his computer’s searching the Internet for something? That’s how I was sometime in November of 2009. Only I was looking for the perfect open source social networking platform. I was very impressed by BuddyPress, but then I stumbled upon something that raised the bar so high that anything else just didn’t seem right. It was the Anahita Social Platform.

Despite several revised road maps, changes in technology and promises of public launch in January of 2010; Anahita is finally out.

This underrated social platform is absolutely stunning in terms of architecture, UI and overall design. What’s better, it runs on Joomla and the Nooku framework. It makes BuddyPress and practically all open source social networking platforms look very outdated.

Its demo currently requires an annoying form to be filled out and it does not have free documentation or a developer community, which would turn  about 90% of the their audience off, and I feel this needs to be looked into. But other than that, it is absolutely brilliant and I highly recommend this.

Looking forward to more developments from them!

Hilarious YouTube client-vendor video

The ‘Dear Mr. Last Name’ Client

Good bye, Good riddance

Recently I was taken by surprise by a response to an email I sent, which read:

“I would appreciate if I were addressed  in  proper business terminology”

This was in response to my “Hey, First Name”

As I sat rubbing my eyes in utter disbelief,  I started to come to terms with the fact that the old system of business run by patriarchal males, who could only reach a certain position by establishing dominance… Is still prominent!

Just like people who think that entire web sites can be made in Flash and be happy about it, there are still people who live in the Jurassic period of the Internet (1989 – 1993) and online interaction. In an age where emails are starting to get outdated, and we will soon no longer need to introduce ourselves or have an email signature (sup, Microsoft Outlook), people need to be educated about the new, informal and unpretentious way of communication: “Hi, First Name”

The word “Hi” eliminates the fact that you are “Dear” to me. I’m not going to lie to you, you’re not. It also eliminates the need to use a 16th century title like “Mr.”

The use of the person’s first name directly after “Hi” establishes a bond on a personal level. To not want one, like our client above, is to want to be given special respect and acknowledgment of being important, and that gives an impression of being needy.

Alright, have it your way, Mr. Last Name. Could you also get your bullock cart because we need to be in the next town by nightfall and greet everyone by their titles and last names! Fun!

Junaid Bhura Poll: 2

Why would you want a web site? (Pick the top answer) . Share your opinion. It’s fast and instant.

Rich Internet Applications (RIA) and the future of the Internet

Flex

No doubt, RIAs (Rich Internet Applications) are the future of the Internet, today. There seems to be a surge in demand for Adobe Flex and other RIA frameworks which can be rapidly developed and with amazing results.

I’m going to highlight Flex, because its the best example I can think of to make my point. RIAs were built to bridge the gap between old browser technology and what is about to unfold in the next year or so. So, in short, Flex and other such technologies will be on the decline once HTML 5 is officially out. This is because one will not need plug-in RIA technology like Flex (which btw is basically Flash, and hence is the proprietary technology of Adobe).

This reminds me of an interesting person I met in a company I used to work for who mentioned that optimizing web sites for mobile phones was the future. I insisted otherwise, stating the simple fact that mobile technology was then leaning towards computer technology, and hence the market that was being referred to was very short-lived. And it has happened now.

This is on almost identical lines to the RIA surge we are seeing today. Flex, Flash, Sun Java, Microsoft Silverlight and all other proprietary technologies will have a run for their money once HTML 5 is out, and there would no longer be a need for these plug-ins to be installed on the browser.

What will remain, though, is good old JavaScript. Now, the second and more important point I would like to make is this: What can Flex, Silverlight and Java do that JavaScript cannot? Absolutely nothing. They are all exactly the same thing. Microsoft and Adobe have done an excellent job in creating a need in the market and tapping them in just the right places. But if they are going to survive the HTML 5 aftermath, they’d better come up with something spectacularly unique.

What I am heading at, if you haven’t already guessed the flow, is that JavaScript and AJAX are the best technologies to use (IMHO) in terms of scalability and in terms of availability of resources and developers (check my previous post on what web technology to use on your web site). If Google Maps, GMail,  Facebook, Yahoo, Bing, Twitter, WordPress, Banks, Airways, Railways and virtually every major player use JavaScript and AJAX; there is something obviously very wrong with everything else, right?