Recently, the beta for version 7 of Zend Studio was released. Very unhappy with version 6, I decided to compare my complaints against the new beta.

While this is a beta release, I don’t foresee switching back from NetBeans because many of the problems that plagued the last one are problems with the base software, and will continue as long as they continue building upon this platform.

The user interface has been cleaned up feel more consistent. It’s download size is a massive 358MB, while netbeans was roughly 25MB. Zend has improved the performance both in start up times and in memory usage.

The applications feels a bit less “clunky” but the usability still suffers from almost every single complaint I had about version six. It seems that little has changed besides some basic code editing improvements, performance, and even more integration with other zend products.

For those considering using Zend Studio, I would currently recommend against it unless you’re deeply tied to other zend products (server, framework, etc). It’s poorly designed and offers little functionality for several hundred dollars over an absolutely free NetBeans.

After an hour of searching, I found that the problem for me was that java 1.5 on mac was forcing netbeans to run in 64bit mode which was causing it to crash before it even opened.

By following the instructions (reposted with more info) at http://blogs.sun.com/yakshaving/entry/netbeans_will_not_start_on) I was able to get things resolved. As far as I can tell, I have not affected anything else I have.

A lot of clients have difficulty understanding why things take the time that they do. It’s always been a point of discussion during estimate time and can become a problem when something is added last minute to a project. I wanted to clarify some facts about the web development /design field to help avoid these problems.

The time necessary to develop a clean, well-organized, well-written application that adheres to the standards set by the W3C and community can often surprise clients and leads.

An example…

Client asks for the ability to manage contacts and assign them to groups. They’re mock up shows a list of contacts on the left, and list of groups on the right. Sounds like a simple drag and drop to add contacts to groups.

What clients often overlook is that we have to solve a lot of additional problems - each one requires more planning, design, development, and testing time.

In reality, this simple drag and drop becomes:

• Create drag and drop support.
• Add support for adding new groups.
• Adding ability to create new contact.
• Ability to edit groups?
• Ability to edit contacts.
• Ensure newly added group may have contacts dropped on it.
• Ensure contacts may be removed from group.
• Ensure groups may be deleted, with a warning first.
• If not using browser default, warning dialog must be available
• Warning dialog alone takes more time to create/integrate and design.
• Remove all connections to contacts from deleted group.
• Prevent duplication of group names.
• Ignore contacts dropped on groups they’re already in.
• Handle any database query/traffic errors properly.
• Use some method of keeping contacts list short enough to drag.

In the web development world, that entire process would utilize PHP, Javascript, CSS, XHTML, MySQL, and the JSON or XML data formats. That’s SIX different technologies. This is the type of work involved in items that often seem as if they can be “turned on” or “plugged in”.

We try to test the most common systems. However, there is an infinite number of combinations of web browser, browser plugins, operating systems, screen sizes, display types, firewalls, computer assistance software, etc. When so many possible combination are possible, the probability of a conflict somewhere is high.

It’s important to realize the level of work we’re involved with. A single select box with nested options may take a few days to create and test.

Many times, fellow developers choose to do it quickly rather than do it right to please a budget, sometimes it’s the clients choice. Yet what eventually happens, is that decision comes back to bite. It may be in the form of failure to extend well, failure to work after a upgrade. Even a poorly written / documented application can cost more to fix than it ever would have to do right the first time.

Thank you!

In several recent projects we attempted to replace Tinymce as the leading content editor of choice with the much simpler Nicedit. We did not have any great need for the advanced features Tinymce offers and were looking for a much smaller, easier, faster tool.

While I’ve used nicedit before in basic situations and had no problems, I encountered several fatal issues which caused us to revert to Tinymce.

Inner-DIV Implementation
Nicedit creates a new DIV element that relies on some newer HTML features to work properly. Multiple issues stemmed from this, but the primary problem was that all CSS from parent elements would cascade into the DIV, thus forcing me to reset or modify some of them.

Tinymce uses an iframe which is a completely new document, so all CSS does not filter through. This also helps avoid the following content problems.

API
When ajax load/save techniques were used, there were problems with how Nicedit would copy it’s content back to the textarea, thus requiring extra programming. The API documentation is not that great, so it was a little difficult.

Elements Used
In firefox, Nicedit would use a different set of markup elements than it would in IE, making the output harder to predict. This issue is partly due to the use of the Inner-DIV and contenteditable attribute. When filtering the input for markup, we had to allow for both sets of elements. In firefox, the elements were all SPANs with style attributes, which isn’t anywhere near semantic.

Firefox LI Bug
Instances of the editor inside of a list item would have a fatal problem with newlines. While you could type alphanumeric characters, newline key presses would have no result. This was a fatal problem that took some time to debug, but it’s been filed and is awaiting resolution.

Obviously, nicedit is a lot less powerful and has a much smaller community. While it works well for quick needs, nicedit just didn’t work for more standard uses, and we found tinymce a much better solution despite it’s bulk. Since then I’ve managed to weed out a lot of tinymce code we weren’t using, optimize it like crazy, and create some custom plugins for it.

Since the recent policy changes we announced in January, it’s become necessary to expand on the new policy regarding project specifications. Project spec documents can be a chore sometimes, but they’re almost the most important aspect of the entire project.

The new policy from January requires that any projects above $1k have an official specifications document and (optionally) mockups that define the official scope of the work. This document needs to be started by the client as they document what they want, and finished on our end as we document the work and technology involved.

But what happens is that it’s often a chick-or-the-egg scenario where clients need an estimate before they can spend time doing a spec, and we need a spec before I can do an estimate.

Beginning immediately, we’re slightly modifying the policy:

We will provide a pre-spec estimate for initial approval. This estimate will clearly be labeled as pre-spec, but will not guarantee the final cost. Once approved, we will require a spec document/material to be submitted by the client. We’ll review the documents, add the technical portion, discuss the revisions, and then provide a final estimate. Before work begins, a signed copy of the project spec and the final estimate must be returned.

To help explain why this document is necessary and how it can be created, please read the “Project Spec Requirements” document.