This work initiates series of articles for those who are in search of shopping cart software. The goal is to create a profound review that embraces a wide range of questions and unlike the vast number of similar works it aims at providing substantial and penetrating analysis of various shopping carts rather than merely enumerating and comparing their features. The lion’s share of the provided information is targeted at web developers. The goal is to understand how hard it will be to use each of the considered shopping carts to create a trendy online store and supplement it with extra features whenever needed. Thus I intend to examine the internal structure, code quality and overall performance. I can’t but admit that a part of this review may be considered as a subjective opinion. Nevertheless I hope that it will become a source of useful information even in regards to characteristics and features that can’t be measured by precise values.
About ten years ago I used to work for a company which was horrible at human relations. Employees considered their managers as incompetent jerks (most of them deserved that) and managers behaved as though their primary task was to discipline and control the hoi polloi. The company’s president who felt he was the hub of the universe yelled at his vices, his vices yelled at the heads of the departments and so on. There was a lot of disrespect and pressure. The only management enhancements they could come up with was installing spy software on everybody’s computer to be able to check what a person is doing and making everybody record the time when he/she comes or leaves the office. That company still exists but they still produce low-standard problem products and are slowly going down. No wonder. It makes no sense to do your best for people who don’t respect you.
In the first part of this article I was talking about my understanding of what should be in specs. Now I’d like to portray the way specs should look. I want to make a start with the fact that project documentation must be not only explicit but also convenient to work with. It’s supposed to be constantly used during the development by coders, designers, project managers, testers and everybody should feel comfortable reading and understanding the requirements, finding specific details, making schedules, and so on. The larger the specs are the more significant this problem is. Let’s ponder over what makes specs to be convenient.
Functional requirement specifications must be understandable, consistent, and convenient to work with and must provide detailed description of a project. While working as a web developer I had to deal with both excellent and horribly incoherent project documentation. I wanted to learn from some spec authors and had to explain to some others what a developer expects to see in specs.
Although I have already written quite a lot of specs myself this article is mainly an opinion of a spec reader and it can be helpful for those who write project documentation but have never been on the other side. The article doesn’t claim to be exhaustive but it includes some practical pieces of advice. I tried to avoid setting vague goals and put my efforts into picking out essential ready-to-use recommendations. Still no recommendations can guarantee perfect result. It’s important to design carefully every single detail, try to foresee future users experience and think over each sentence that has to be written.
Zillions of web companies publish on their websites texts about their “philosophy”, “methodology” and “strategy”, how “agile” they are and how they adore their clients. A few of them are somewhat convincing but in 95% of cases these texts are lame, unimaginative, and have been written by inflating a few hackneyed phrases. Standard clichés make company management think they follow the latest trends but those of their customers who take some time to read that verbiage only get Déjà vu.
Some of you who are running on Mac OS X and come to necessity of using Apache Ant can be slightly confused by the system requirements posted on their official website. For example, it says “you must have a JAXP-compliant XML parser installed and available on your classpath, such as Xerces”. “Wow! What’s that?” — one may think :-) Then it explains how to build Apache Ant from the sources and at that point you may hesitate even more whether to proceed with the installation because there is danger of spoiling something within your operating system or impossibility to get rid of the Apache Ant sources scattered in various directories if they don’t work. Then after browsing the net you may find something like a piece of advice to install Darwin Ports first. Is that situation familiar to you?
Believe it or not, but: The key method of modern marketing is manipulating facts.
Many programmers who try to make relevant full-text search in MySQL become slightly disappointed when they realize that boolean search doesn’t sort the results by relevance as natural-language search does. In this article I’m going to offer a few solutions which allow to get relevance-ranked search results using boolean full-text search in MySQL.
If your client comes and says that he wants you to build an exact copy of a complex website for a fixed price and writing specs is not necessary since no specs can be better than a working example… Don’t agree or you will regret about that many times. Any person with sober mind can come to this conclusion himself but the temptantion to make “quick” money can be too strong. This is just a reminder that can help to avoid the hook.
This is one of my articles about neural networks published in Latvia in 2006. I hope someone may find it useful.