Recent Updates Page 2

Abhi Rampal 11:04 am on October 21, 2012
Tags: entreprenuership, Product Development, Start-up failure,   

Thoughts on the Wheedle Fiasco

Anyone who works in technology in New Zealand is probably aware of the Wheedle.co.nz and listselltrade.co.nz fiascos from the past few weeks. Social Media has been abuzz with people complaining about the substandard user interfaces, security loopholes, faulty hyperlinks etc. I really admire the audacity of founders to launch products in the NZ online e-commerce market where TradeMe is the undisputed king by market share. The long list of startups that have failed in the process of competing with TradeMe is enough to put any potential founder off from even trying. Sadly, the audacity to compete with TradeMe wasn’t matched with a crafty execution. One cannot help but wonder why both companies failed so spectacularly, why their game was over so quickly, where did they go wrong? Looking closely, some things stand out.

First Impressions
In the web and mobile apps business first impressions are hugely important. They make or break your product. When you’re someone like Wheedle, taking on TradeMe, your site shouldn’t look like a poor cousin of TradeMe. User experience on your site is your first point of attack on grabbing the customer’s attention. The colour combinations, the fonts, the logos and buttons should be begging the customer to click. You’ve already lost the battle if your site looks unfinished and painfully similar to the big brother in the market. Remember, users are going to use your application because they think it will offer something different, something better, something that they’ve been waiting for and has finally arrived, something that really connects with them! If your site looks too similar then you’re already losing your customers. Both Wheedle and ListSellTrade should have invested more in the UI of their respective apps.

Security
When you build an e-commerce application security is right up there with a great user-interface in the list of things you have to get right. For your first release you don’t have to exhaustively spend resources on security. You just have to get the basics right. Make sure your site doesn’t have any of the ‘OWASP top ten list of the 10 most dangerous security flaws’ and unlike Wheedle, please do not send users their passwords in plain text! Even a little suspicion that confidential information is not secure on your app will drive consumers away.

Outsourcing
There is two types of outsourcing. The first, where you outsource because you cannot find people with a specific skill set in your country. For someone trying to innovate, trying to carve out a niche in the market such outsourcing is essential. Then there is the other type, the one where firms that are not really in the innovation business, that are just developing mediocre products and want to achieve that as cheaply as possible. While I personally have some reservations on this as a long term business mode, it seems to have worked for some companies (and others have miserably failed e.g. 2 Degrees). However, here is something to ponder – do you know of any company that launched a successful product, challenged the status quo, made leaps into a new market with a product that was outsourced to cheap overseas developers. I haven’t. Facebook, Google, Amazon, Yelp, Groupon and locally, Orion Health, Xero, MCom, INRO, Telogis and even TradeMe, founders didn’t just come up with an idea and outsourced the development work to India. Entrepreneurship and new product development is more about the execution of idea rather than the idea itself. When you outsource the development of your product you lose control over the execution and poor execution only paves way to failure. Wheedle made a major mistake of outsourcing the software development team to India.

Quiet roll outs
Part of the reason why Wheedle so spectacularly failed is because they created too much hype building up to the launch day. TV, radio, Social Media, they were everywhere. When they did eventually launch and failed subsequently, they got a lot negative press that they could have done without. A smarter way would have been to quietly launch their product, grow it organically, fix all the issues that are reported along the way and then finally go all guns blazing into TV and Social Media campaigns in order to market the product.

Software Development > Marketing Campaign
No Marketing campaign can ever make up for a shoddy product.

Advertisement
Abhi Rampal 10:15 pm on May 17, 2012
Tags: android, gzip,   

Android: download and decompress GZIP file on the fly

Code snippet below shows a neat way of downloading and decompressing a GZIP file on the fly. This saves from having to programmatically download the file first and then decompressing it. I have used this for downloading and unzipping a GZIP file that contained an XML document.

protected String doInBackground(String... sUrl) {
	try {
		URL url = new URL(sUrl[0]);
		URLConnection connection = url.openConnection();
		InputStream stream = connection.getInputStream();
		stream = new GZIPInputStream(stream);
		InputSource is = new InputSource(stream);
		InputStream input = new BufferedInputStream(is.getByteStream());
		OutputStream output = new FileOutputStream("Path to the file");
		byte data[] = new byte[2097152];
		long total = 0;
		int count;
		
		while ((count = input.read(data)) != -1) {
			total += count;
			output.write(data, 0, count);
		}

		output.flush();
		output.close();
		input.close();
	} catch (BufferOverflowException e) {
		e.printStackTrace();
	} catch (IOException e) {
		e.printStackTrace();
		return null;
	}
}
Abhi Rampal 10:13 pm on April 18, 2012
Tags: flying-faucer, java pdf generation   

PDF Document word-split using Flying Saucer/XHTML Renderer

I thought I’d write a post on some bizarre behavior I recently encountered with the Java 5 SAX Parser. This might help people who are using Flying Saucer for PDF generation.

We were reported a bug where the PDF documents generated by a web application we developed, occasionally, had words split across two lines. We tried hard to establish a pattern on when the split happened but after trying out many different scenarios and much deliberation we came to the conclusion that the split was random and no real pattern could be followed to replicate it. It was so hard to replicate that, at times, it would take the tester a whole day to find an example split in the generated PDF documents.

The web application uses Flying Saucer/XHTML Renderer to render PDF from an XHTML document. Flying Saucer is the most widely used PDF renderer in the Java technology stack and therefore it’s quite bizarre to encounter such a problem. Doing some googling also revealed that no one else had encountered a similar problem and for most people Flying Saucer worked like a breeze. This meant that after exhausting all other options of looking for the bug in our code, we were left with no other option than looking through the Flying Saucer code to look for the potential bug.

The web application uses the combination Spring MVC and Apache Tiles to generate XHTML document to represent the format and content of the PDF to be generated. The application was running on IBM Websphere server and used the default websphere Java 6 SAX parser to convert the XHTML document into W3C DOM. Through our investigation it was found that in the DOM, the split words were represented by multiple text nodes. So for example, if performance was to split into ‘perfor’ and ‘mance’ in the PDF, in the DOM, ‘perfor’ and ‘mance’ were parts of the different text nodes. Flying Saucer, the PDF renderer, treats each text node separately, which caused text to break in the middle of words.

We still don’t know why the SAX Parser arbitrarily creates two text nodes to represent one word. An obvious solution to the problem was to use a different parser and using a different parser did seem to solve the problem. However, normalising the document, i.e. combining multiple text nodes and therefore removing the possibility of having a word being represented by multiple text nodes seemed a much easier option since there was already a method available in the Java API to normalise the document and just calling this method fixed our problem.

This seems to have solved the problem with no more word-splits reported to date.
We still don’t know why the SAX parser created multiple text nodes to represent one word.