General
February 16, 2005
Every other day it seems, I have to suffer an assault of stupidity in one form or another. This time around, I am suffering the foolishness of shipping companies.
I send and receive packages on a regular basis … you’d figure that this common task would (and should) be a trivial thing by now …
–
Stupid shipping company #1: Canpar.
When receiving packages, it is rare that I can choose the shipper. But when I do have the choice, I ask for anyone but Canpar.
Why does Canpar suck?
- They only make two deliver attempts (all the others make 3) and then they’ll ship your package back.
- They cannot give you a time of delivery during the day – they can’t even give you a ball park time!
- They have no easy to access pickup location to get packages – unlike the post office.
My story:
I get a delivery notice on Monday saying they missed me and that they will back Tuesday in the afternoon. So I wait all day Tuesday because if I miss this 2nd attempt, the package gets shipped back.
Tuesday comes and goes with not so much as a phone call. I call them and make arrangements for the package to come Friday. Friday comes and I wait all morning and into the afternoon, with still no word when the package will arrive, so I give them a call.
I figure that in the age of cell phones, they could call the driver and we could coordinate … nope: Canpar tells me that they can’t reach the driver! That high-tech capability (of calling drivers via cell phone,) seems is only for the local pizza delivery guy.
So I sit here waiting, wondering, if Canpar will stiff me yet again!?
The Post Office Rocks
It’s sad to see when a government entity (the post office,) is able to provide a far superior service than a commercial entity. We all know that government is insanely wasteful and inefficient. But let me tell you, the local post office kicks most private /commercial shipping companies asses:
- The post office has easy to find (they give you an address on the slips) locations to pick up packages.
- Pick up locations are always close by.
- Shipping via the post office is much cheaper.
–
I wonder if I will get my package today?
Stefan Mischook
read more
February 16, 2005
For the last several years, when asked about what programming language that I thought people should jump into, I would automatically make Java my first choice – things are changing now.
There is growing appreciation for flexible dynamic scripting languages (like PHP, Python) over strongly-typed compiled languages like Java.
Why?
I see two big reasons why people are looking to the scripting languages as a viable alternative to Java:
- Speed of development.
- Ease of use.
There is no argument (among sane people,) that you can build applications in a scripting language in a fraction of the time that it takes to build the same application in Java.
The Java zealots would argue:
- Scripting code will not be maintainable.
- Scripting code will run too slow
About code maintainability:
The reality is that code maintainability has as much to-do with the programmer as it does with the language – you can write crappy Java that is not easy to maintain or extend … I’ve seen it more than once – maybe even 3 times!
🙂
The same thing can be said of scripting languages …
Another interesting point, is that you can usually write an application with far less code than you would in Java – many times we are talking 1/4 to 1/5 the code! A thousand lines of code is much easier to maintain than 5000!
About speed of code execution:
Again, many times that comes down to the programmers skill. Having said that, the evidence shows that for many applications, the scripting languages out there run more than fast enough.
Anecdote: PHP seems to be fast enough for Yahoo.
The old argument that Java people used when defending Java’s speed (relative to C++ ) can be applied to scripting languages: computers are really fast these days … as such the difference in execution speed (most of the time) is negligible.
Java’s ever increasing complexity- benefits the few at the expense of the many:
It seems to me that the Java community has made the platform more and more complex (in favor of huge projects,) at the expense of productivity of small to medium sized projects. The problem is, that the vast majority of the projects out there are small and medium sized.
Conclusion
I’ve written most of my software in Java over the last several years, I like Java. But these days I don’t look to Java anymore because it just takes too much time to get anything done. Even small Java applications have a lot of overhead in just setting up – xml descriptors, frameworks etc. I’m not even going to get into the verbosity of the code itself …
These days I look to PHP to write my web apps – it’s just too easy and fast to ignore. PHP has got some baggage from its’ roots of being a ‘web designers language’ but it is fast, has support from big players like IBM and most important , it’s everywhere!
What about Ruby?
Looks very cool, but it is a marginal language – nobody uses it these days. Last I checked, in comes in as the 28th most used language – below COBOL, Python, VB … you get the idea.
read more
February 14, 2005
GETTING YOUR FIRST WEB DESIGN JOB
People have been asking for this one, for a long time – I’ve been a total scatterbrain lately with heaps of half-written articles and tutorials!
I must have about 60-70 pages worth of material on everything from web design tips, PHP programming, how to create a database in MySQL, negotiating a web contract – all of them about half finished!
Before I go on with the article on the web design business, I have to say that I have relearned one thing in the last 3 months: do one thing and finish it! I think this is so important, that I’ve even come up with an expression:
‘If you’re half way there, you’re nowhere!’
Wow, I’ve coined my first expression! Keep it in mind when you’re doing your thing – whatever it may be.
GETTING YOUR FIRST WEB DESIGN JOB
One of the first question people ask, is how do you actually get a web design job? This has all to do with your presentation – how the client perceives you is more important than reality!
read more
February 14, 2005
Once you and your client have agreed on a price (for your web design work,) it’s time to get some cash!
Why do you need to get money before you start the work:
Two major reasons:
- You need some sort of commitment from the client – nothing guarantees a commitment like cash!
- Respect: you need to establish respect for your services. By getting a payment upfront, you are establishing a professional relationship.
How much should you ask for?
I work with one of two payment structures:
- Two equal payments – 50% up front and 50% when the job is done.
- Three equal payments – 33% up front, 33% on delivery of the first draft and 33% when the job is done.
The 2nd option is much better because it’s easy to get the first draft out – this way you’ll have 66% of your money relatively quickly.
On the other hand, it can take a long time before the client signs off on the final. Option #2 is especially handy when you have clients who take forever to respond to your questions causing the project to drag on.
– –
OK, I wasn’t going to mention it, but there is a 3rd method of getting paid … and that’s not getting paid because you didn’t get a payment up front!
Always get a payment up front!
Stefan Mischook
read more
February 14, 2005
In a nutshell:
When people surf the web, they have no time or patience to read long blocks of text – keep your writing simple and short.
Some basic tips:
- Use bullets to emphasize major points.
- Keep paragraphs about 7-10 words wide.
- Use lots of white space – give your pages lots of ‘breathing room’.
- Don’t do stupid things like having paragraphs that are all in italics or all bold.
- Make sure your text color is easy to read. For example: dark blue text on a black background is hard to read!
- Keep your text alignments consistent: don’t center align titles on one page, and then shove your titles to the left on another.
Basic writing tips:
- Keep sentences short and again, to the point. Tip: remove unnecessary words.
- Write as you would speak. This could be a problem if you’re a babbling fool … 🙂
- Read over what you have written 3 times.
– –
I can recommend three great books on writing well:
Writing in Bullets: by Kim Long
A good little book that will teach you how to use bullets effectively – there’s more to it than you think.
On Writing Well: by William Zinsser
A classic book on the subject. Not so specialized as Writing in Bullets, it tackles writing from a global perspective.
The Elements of Style: by William Strunk Jr
Another classic. This book gets into the details of writing where you learn about things like:
- Form
- Commonly misused words and expressions
- Basic rules of composition
- And plain old good advice like: omit needless words
Sometimes it can be a little dry, but the book is packed full of great stuff – get it! Actually, you should get all these books – it’s not like they’re expensive!
CIAO,
Stefan Mischook
read more
February 14, 2005
It’s common to hear a lot of talk in the Java community about the importance of:
- scalability
- re-usability
- maintainability
These are important goals (often never reached in real projects btw,) but I wonder why no one ever talks about something that should be considered at least as important: understandability.
Some people might say that understandability would fall under the maintainability category. After all, for code to be maintainable, it should be easy to understand … right? Unfortunately in the real world, Java folk (seems to me) must have forgotten this all too important rule of good programming.
No, not another XML document!
These days, to get even the simplest of Java applications going, you need to do a lot of plumbing work which often includes setting up property files …
When I start filling in XML property and descriptor files, it feels like filling in acquisition forms to buy a new pen … I get this nagging feeling that I’ll have to fill out the XML files in triplicate and get them ok’d by 3 different people.
–
It shows that Java has been designed by huge corporations in a committee process (JCP) – Java ‘feels’ like a big giant corporation!
In it’s youth, Java was nimble language full of possibility and optimism. But like hippies from the 60’s, over time the oppression of corporate reality has turned this spritely language into a pedantic sloth.
So what’s next?
I don’t know what the next big language is going to be. But I do know it will be a scripting language that will:
- Have dynamic typing.
- Have a rapid feedback loop – thus not compliled.
Stefan Mischook
read more
February 13, 2005
Hibernate In Action (Christian Bauer & Gavin King) Manning 2005
Beware: this is big time Java-nerd stuff – not for web designers.
– –
One of the most difficult and time consuming elements of coding most business applications involves the persistence layer. This is particularly the case when object oriented (OO) approaches are used.
While OO programmers tend to think in terms of software objects with properties and behaviors, the truth of the matter is that at some point stuff needs to be loaded and saved in a database.
Anyone who has ever had to write their own object-relational (OR) persistence layer (I have), soon comes to realize that it is an area fraught with peril.
Why use Hibernate?
Hibernate is perhaps the most popular OR persistence framework for Java around today (although there are a number of lighter frameworks available). The authors of Hibernate In Action are part of the core team that developed Hibernate. Diving into the book quickly reveals that the authors know their stuff.
The Details:
The opening chapter (Understanding Object Relational Persistence) presents a detailed overview of pretty much all the main issues one is likely to encounter when it comes to OR persistence. The discussion is lucid and sets the tone for understanding why Hibernate is an attractive solution. The authors also spend some time highlightting why one might NOT want to use OR mapping, which I also found useful.
Sunsequent chapters get you up running relatively quickly so you can see the framework in action. As the book progresses more detailed examples are used to illustrate the potential of the framework, and also some of the limitations.
Conclusion:
Frankly I found the level of detail to be a little tough for a first read, but was pleased to know that the meat was there if I needed to get back to it.
Aside from this minor criticism I found the book to be a relatively entertaining read (7 out of 10) although you probably would need to have an interest in the subject.
All in all a strong book well worth acquiring if you are interested in evaluating the Hibernate framework.
Review by Richard Mischook
You can read more Java book reviews here.
read more
February 13, 2005
DHTML Utopia Modern Web Design Using JavaScript & DOM
First thing I have to say is that I like their (I guess you can call it,) catch-phrase:
‘Create Killer Websites using the power of modern Javascript’
🙂
The pros:
- In the introduction, a section with the title: ‘Whither XHTML’ – here we see Real-World thinking. Basically the author explains why using XHTML does not make sense now.
- Chapter 1 is a good overview of code (HTML, CSS) and how it should be applied in web design today.
- Chapter 2: A good intro the DOM – but it moves fast.
- Chapter 8: A cool section on XMLHTTP: XMLHTTP is a way to ‘talk’ to the server via JavaScript, that makes for a Flash like exchange of data between a web page and server – that means no page refresh.
The cons:
- After chapter 2, I started to fall asleep – and I’m a big nerd!
- Not a knock on the book itself, but most of the stuff described in the book is not worth using (most of the time,) since about 10% of the people out there have JavaScript shut off. That means you can’t count on your JavaScript for anything – so all the JavaScript you use has to be non-essential.
Conclusion:
If you know how to program, and you want to get into the cutting edge DOM scripting world, this is a reasonably good book.
You can read about more JavaScript books here.
CIAO,
Stefan Mischook
read more
February 13, 2005
In this article I am going to look as some of the practices that are promoted by the Web Standards movement, practices that cost web designers (and their clients,) time and money for no real practical advantage.
CODE VALIDATION: validating your web pages.
Web Standards zealots advocate checking of code against an ‘engine’ (W3C validator ) to verify that your code is not breaking any Web Standards rules. This is fine, but it should be the ‘icing on the cake’ and not the focus.
Before you validate using the W3C validator (who’s engine does not reflect most of the browsers being used,) you should ‘validate’ your code against the target market – Internet Explorer and then (a distant 2nd) FireFox.
THE ORDER OF REAL-WORLD VALIDATION:
- Check against Internet Explorer – the most used browser.
- Check against FireFox.
- Check against the w3c validator: if you have time to burn.
read more
February 11, 2005
One of the disturbing mindsets in software development and web design today, is the sacrifice of practical concerns in favor of theoretical constructs.
Case in point:
Recently a young friend of mine (who is studying computer engineering,) told me an interesting story about a class project where each student had to produce a piece of software … the results, and the professors reaction to the results, are interesting.
Sad but true:
When all things were said and done, only one student was able to produce a working application. The irony was that this student got a failing grade because his code did not meet certain theoretical constructs!
The above example illustrates a problem in the way many programmers think: putting theory over practicality.
With that failing grade, the professor has sent the wrong message to his students: that results are not as important as being true to the theory. And people wonder why so many Java projects fail…
Why theory over practicality is total bull:
- Broken but theoretically correct software, doesn’t pay the bills.
- Theories are constantly revised; so don’t be to quick to marry them.
I think the first point is self evident, so let’s look at the 2nd point and consider one of the fundamental theories of modern software development: inheritance.
At one time in the distant past (5 years ago,) design-by-inheritance was the theoritically correct method of software development. At some point though, people began to discover that inheritance had its’ problems and now (in many cases,) design-by-interface* is the preferred method.
Theories change
The shift from design-by-inheritance to design-by-interfaces is but one example of how theories are constantly updated to reflect practical realities.
If anything is consistent of about software development, it’s that theories change. So don’t sacrifice practical application today, to satisfy some theoretical construct that may very well be discredited tomorrow.
–
Stefan Mischook
1. ‘bull’ is a technical term that conveys a complex meaning in a terse and well understood format.
2. In Java, interfaces are classes void of method implementations.
read more
