in

Emerald Hand

Emerald Hand, Inc. community home page.

This Blog

  • Home
  • Contact
  • About
  • Directory of Computers/Tech Blogs

Syndication

News

I'm back to blogging

Worm in liquid maze

Design and development of information management tools.

September 2005 - Posts

  • Understanding through writing

    I finally sat down and wrote an article comparing MonoRail to ASP.NET (if you're interested, it's here). There are two interesting things I've learned in the process of writing it.

    First, going into writing the article I had a good idea about the differences and how they compare, but by the time I finished I gained much clearer picture. Having to go through analysing each project step by step, thinking about what each feature means, thinking about pros and cons of each project, helped me to understand them better. I'm sure when I go back to add to and revise the article I will learn even more. In the future, whenever I don't understand something I'm going to sit down and try to write my thoughts down. Maybe because writing has a speed limit (or at least it's really slow in comparison to the speed of thought) I have more time to analyze the subject. I'm not sure what exact reason is, but this experience proved to me that one good approache to understand something is to write about it.

    Another realization came from the fact that I've known about writing technique mentioned above before. I could see that it can be useful logically, but when I tried to understand something I never thought of writing my thoughts down. Well, the lesson I have learned is that it's important to try different things. It's important to listen to what other people have to say, but it's even more important to go ahead and experiment. Everybody is different, with different biases and different opinions, so most likely you won't know for sure what works the best for you until you get your hands on it. So my advice is read and listen to other people, but try as many things as possible (in software development and in life). It's good for you. Try it!:)

    P.S. With this post the blog is starting to go away from the development topic, but I think things I tried to talk about here are important in computer programming world as well as anywhere else.

    Share this post: Email it! | bookmark it! | digg it! | reddit!
    Readability Stats: Word Count: 353; Sentence Count: 20; Grade Level: 8.3, more info...
    Posted Sep 29 2005, 09:44 PM by Ornus with no comments
    Filed under:
  • Word complete in JavaScript

    I've recently found Word Complete web application. It's a cool little JavaScript program that offers word completion to the text user enters in a text area (just like IntelliSense, only in relationship to English. As letters are entered script automatically suggests a complete word).Word suggestion is not new in JavaScript and Google has been offering it (in beta) for some time. Actually that's one of the things that sparkled a lot of renewed interest in XMLHttp. This application seems to be simple, but pretty neat at the same time.

    It is an important step towards on the fly spell-checking support (similar to how Microsoft Word marks misspelled words as you type). In fact, I think adding support for marking misspelled words is just a short step from Word Complete. Instead of suggesting a new word the script can try to look up the word in a dictionary, and if none is found underline it (or highlight it some other way). This leads to a problem of misspelled word indication.

    The simplest solution would be to wrap the word in a span with CSS class name set to some class. A stylesheet could set background image to a wiggly red line at the bottom of the line for this class and so the word would get underlined. This would result in direct modification of the text entered by the user, and if the user would try to select and copy the text out the misspelled span tags would remain in the copied text (I think there's a way to format the text when it is copied or pasted, so this problem is probably solvable). An alternative solution could have a list of misspelled words next to the text area, or something similar. It would allow user to go to the selected word on click or directly fix it.

    Another problem related to inline auto spell checking is showing a list of suggestions on the right click. Displaying a context menu or downloading a list of words from the server can be simple tasks on their own, but putting it all together and ensuring it's easy to reuse the code in web application development can be hard. I might some day have enough time to play around and try to come up with my own inline spell checker, but it would require setting up a spell checking web service, learning XMLHttp with which I'm not very familiar, etc.

    Share this post: Email it! | bookmark it! | digg it! | reddit!
    Readability Stats: Word Count: 412; Sentence Count: 18; Grade Level: 10.1, more info...
  • Turns of liquid maze

    Some of these links are fresh and some are couple of weeks old. I still, however, think they're pretty interesting.

    Web development

    • More Performance Tips - An article on how to improve JavaScript performance when generating web pages using DOM. I'm glad Microsoft is starting to publish more articles on how to write faster and better code for their browser (IE). Now I wish they would reflect more on how to work around IE bugs.
    • A huge gotcha with JavaScript closures and loops - Blog post discussing function object creation inside another function. Basically the browser is free to reuse the inside function object, so if you are trying to create an array of them you might end up with the same function instead of having a collection of distinct objects. My biggest surprise, however, came from the fact that ECMA 262 script specification allows the script host to either reuse the function object or to recreate it. I guess specification gives this choice to script host developers for performance reasons. I don't like it though. Whenever there's "either-or" choice some people go one way, while others go another. Usually this difference won't matter until much later and a lot of time will have to be spent to figure out what's happening.
    • JavaScript Articles - A small collection of good articles on advanced JavaScript features. There are lots of examples and the same material is often presented from several points of view to make understanding an article easier.
    • IIS Server Pro - A lightweight tool to control IIS server from system tray and create multiple websites (same IP, different root on different ports) on Windows XP/2000.
    • Internet Explorer Developer Toolbar Beta - A new toolbar from Microsoft to help web developers (who target IE). It offers some interesting features, but I still like Web Accessibility Toolbar better. Most of the functionality is the same, but there are some small differences (in what and how they outline on the page), so it makes sense to have and use them both. The biggest complaint I have about the new IE Developer Toolbar is that it only allows web page inspection. It doesn't let (or I couldn't find how to do it) developer to modify CSS (for example) and immediately see the results.
    Share this post: Email it! | bookmark it! | digg it! | reddit!
    Readability Stats: Word Count: 380; Sentence Count: 20; Grade Level: 10.4, more info...
    Posted Sep 21 2005, 11:53 AM by Ornus with no comments
    Filed under:
  • JavaScript Logging

    A List Apart has recently published an interesting article on JavaScript Logging. Doing any kind of debugging in JavaScript can quickly turn into nightmare due to the browser differences and often undocumented browser "features". So tools like component described in the article above can help any web developer. I'm glad to see a lot of very useful tools starting to appear to help with JavaScript coding and debugging. There're for example JavaScript Lint (script validator) and Drip (IE memory leak detector). I'm kind of curious though why these tools just started to appear now. JavaScript has been around for many years or am I missing something?

    If any of the tools are used as components (logger, etc.), great care must be taken. JavaScript is a pretty slow language with a lot of overhead. In some aspects JavaScript programming is like programming for an old computer (I'm talking about 20 years ago) where developers had to conserve resources and pay close attention to CPU cycles. Using any components directly in the script can easily increase script execution time by several seconds. It would be very nice if it were possible to enable/disable logging, basically making any log calls as short as possible. Another good option would be to have various places the log can sent to: actual webpage, different webpage, server (via XMLHttp), local file, etc.

    I would like to see another component similar to Debug.Assert appear in JavaScript. It's really just a conditional logging. This can help with contract programming in JavaScript and assumption testing. Still it will need to be very fast to minimize any performance impact on the code, especially in the production environment.

    Share this post: Email it! | bookmark it! | digg it! | reddit!
    Readability Stats: Word Count: 284; Sentence Count: 19; Grade Level: 9.1, more info...
Copyright © 2006-2007 EmeraldHand, Inc. All rights reserved.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems