The worst thing you can do as a website owner is to constantly make lots of little changes.
The best thing you can do as a website owner is to constantly make lots of little changes.
You need to know what works on your website, and what doesn't. And your visitor statistics will help you find out. But if you keep making changes on an ongoing basis, you'll never know for sure. I've just put up a change on my own site, and I've realised that it will be really hard to tell if it's going to work or not.
Unless you just love multivariate analysis, it's much better to let things run for a few weeks to really find out what fires up your visitors. Statistics are strange things, and you can get really big swings from one week to the next. The standard deviation is bigger than you think.
So before you panic, and jump around the place changing stuff on your site, just take a deep breath and make sure you know what's happening right now. Measure twice, cut once. Make lots of changes, but make each change deliberately, in a way you can measure. Try to space things out, or makes changes that are independent. Lots of little improvements over time add up to big sales, but you don't want to go for a random walk either.
So be zen about your site. You may know something is wrong. You may have seen someone try to use your site and flounder. You may think you need a new colour scheme. You may even think you need an onsite avatar (no, don't go there!). But make sure you can tell the difference between before and after.
(And the change I made? I put links to my solution-focused tutorials on the top left, above the boring standard navigation menu. I'm sure it'll work, but I've mixed it in with other changes and it'll all be too hard to untangle.)

















2. When I looked at the demo, I wanted to see (a) the code that actually does the parsing, (b) the code that handles the options based on parameters, (c) the code that HTMLizes the parsed code, and (d) the code that handles anything else. I think that is the best order to present them in. But, the demo presents (b) first, which gave me the impression that it was a lot of work to set up the parsing.
3. The demo uses Model 1 JSP, which many (myself included) think is a bad practice. Thos reflects badly on the product, IMO.
4. I saw some Google Ads on the site. I think it is strange to promote other products and send customers off to other websites on a site designed to sell a product. I had mentioned this before regarding your weblog as well, IIRC.
5. Your homepage indicates that XML Manager is faster than the CSV Manager. My intuition tells me that CSV is much easier to lex and parse than XML, so CSV manager should be much, much faster than XML Manager. I also notice that you have a link to ANTLR on the website, which is well-known for poor lexical analysis performance (BTW, I have used ANTLR extensively).
6. http://www.google.com/search?q=CSV+Java : the first hit on your website is for a page that says you are not hiring anybody. While better than nothing, I would expect that the first result for your site would be the product page for CSV Manager.
7. You have competitors. Yet, I don't see any comparisons of your product to your competitors. If you can demonstrate that your product is better than the obvious alternatives, I will be more eager to evaluate your product first; otherwise, I am going to start googling for OSS alternatives. This is important because developers will often choose the first solution that works.
8. Your IP Address -> country example is cool. It demonstrates a very, very common use case for CSV files: loading them into a database. In fact, this use case is so common that I kind of expect that I should be able to do it with much less code than the example shows. Why not implement some CSV<->JDBC logic?
9. Another obvious extension point for CSV Manager is one that handles fixed-length-field (non-delimited) files. The files I import into my database are all in fixed-lenth-field format.
Posted by Brian on April 11, 2006 at 04:12 AM GMT+00:00 #
1. Fixed. My Bad.
2. The demo is badly in need of a complete update. I implemented the XML Manager demo using AJAX, so I think I will use that as well for the new CSV Manager demo.
3. Model 1 JSP was a deliberate choice as a lowest common denominator. But you're right, it's much less used these days.
4. There are google ads on the solution-focused articles, and on the search. Both provide "free" services, so it seems only fair that there are some ads. But it's a fine line, perhaps I have crossed it.
5. Intuition is a dangerous thing :) XML parsing is highly dependent on the underlying SAX parser, and there are some seriously fast ones out there. ANTLR is not the best I agree. I have been considering converting the ANTLR generated code to a more direct parsing algorithm. It stands to reason that it would be even faster.
6. I have been more focused on "java csv". But that "csv java" result is a right pain. Time to get my SEO hat on.
7. Yes, I have considered this. But it's not without problems. First, competitor bashing is not something I want to get into. (I am in fact friendly with some of the coders who have written CSV parsers). Second, commercial software does not compete with OSS on just features. I offer a full-service solution, not just some code that you download. But I suppose a features comparison table might not be so bad.
8. A straight upload of the data to a database is not much code at all. The extra code is for the batch processing so that you can keep using the IP Lookup table on a live site. I should point that out in the article. Also, one of the CSV Manager examples does show the much simpler CSV-JDBC code.
9. I have been considering fixed-length files for some time. But I am not sure of the market potential here.
One more point on performance. CSV Manager is carefully designed for long-term continuous use. Memory usage and speed are constant, independent of file size.
And just to say thanks for the great feedback, I've sent you a mail with a free download of both CSV Manager and XML Manager. I hope you can find a use for them, warts and all! :)
Posted by Richard Rodger on April 11, 2006 at 09:13 AM GMT+00:00
Website: http://www.ricebridge.com #