Published: Wednesday, October 25th, 2006

I’ve actually been meaning to try this myself, well a variation of it. I would , however be comparing these speeds from a C# Application performing data access to the SQL Sever 2005 or MySQL backend. Based on these tests it seems that I’d be better off with an ASP.NET connection, since this will be running on a windows environment.

I will definitely take Karl’s tests into consideration as I perform my own.

Karl Write:

Sidetracked with MySQL & SQL Server Performance
Here’s the short version:

1. This is only for inserting 500 rows into a 3 column table
2. InnoDB really seems screwed on Windows platforms running 5.x - Certainly don’t have anything conclusive, but I’d watch out
3. For my very simple test, MySQL on Linux blew SQL Server 2005 on windows out of the water.
4. On windows, ASP.NET’s connection to MySQL seems as fast as PHP’s

Popularity: 3%



Published: Tuesday, December 13th, 2005

Yakov Fain wrote an interesting article: A Cup of AJAX? Nay, Just Regular Java Please at SYS-CON DEUTSCHLAND.

I can agree that big Internet guys [Google] can and should invest some serious dough into supporting screen-refresh-on-mouse-move in HTML-based screens. But when it comes to a regular Intranet business application, when the users/browsers/platforms are known and when the cost of the project development matters, I’d stay with a fat client written in Java, or (if you like a fancy GUI) Macromedia’s Flash or Flex.

This article caught my eye and I’m including it simply for your perusal, but I disagree with him. For people who have been developing Java Applets for the past um-teen years, then this argument holds a lot of ground, however for people like myself Ajax is the perfect answer. The application that I am working on is primarily developed in C. The whole web application portion of the program is an add-on and soon needs to be automatically generated by the C application. Ajax opens the perfect door for this type of functionality.

I’m curious to hear what you all think. Java or Ajax?

Popularity: 3%



Published: Monday, December 12th, 2005

I found this link somewhere, I can’t remember where. But Li Shen has packaged a nice AJAX wrapper called AJAX Client Engine (ACE). I downloaded it and took a look at it and I must say, it is quite functional. I took a look at his source code and found it to be relatively clean. It’s not too bulky making it a nice thin wrapper and he made it very object oriented. Here are a list of the properties. Visit the site to find one more about each of these:

  • Object-oriented API.
  • Cross-browser support.
  • Request options.
  • Request parameter validation.
  • Callback arguments
  • Callback options.
  • Tracing service.
  • Caching service.
  • Polling service.
  • Common callbacks.
  • Exception handling.

There are some things I just love about this client. The tracing service: When this is enabled, a text area element in a new window (or in the same window if specified) is opened up and a debug is written. Basically, it tells you everything the AJAX client is doing. You can just insert the “trace” function call at various places where you need to debug information like when a request it made, when the AJAX states change, when a call is completed, etc. I must say, it is a very effective tool, one I should have come up with myself.



Published: Sunday, December 4th, 2005

I believe that I now need to rethink the Ajax sequence on the project I am working on for work. As it stands, I had to do some interesting tinkering to make things work and emulate the console side properly. A normal sequence of GETs and POSTs would have been sufficient, except I needed something to handle server pushes. In the console application, there are some instances like popup boxes. Eg. After the client sends a request to the server, the server sends back a simple popup box, sorting. After it is done sorting, the server sends back the information to the browser. And this is the problem. Normally, Ajax does not handle this. This is where I had to implement a modified polling technique.

Basically, the client makes constant requests to the server. Yes, yes, I know that this is very inefficient, but this is a rough draft. Well, rough working draft. The server sends back a NULL flag, which the browser reads and ignores, or it sends back the requested data. This works, but is very inefficient. Normally, server initiated Ajax routines use a polling technique. This involves the client basically pinging the server on regular intervals to request data. I’m doing the same thing but without the time delay.



Published: Wednesday, November 30th, 2005

An interesting article from John Carroll | ZDNet.com explores the differences between AJAX and desktop development.

Ajax is rapidly growing into something a lot of developers did not expect. Web designers can now design flashier web pages (minus the Flash). Other web designers are bridging the gap between desktop applications and web applications. Users have begun to take strong notice to this and are, in some cases, requesting such advances in web development.

From a user perspective, though, AJAX applications - such as Google Maps or Microsoft’s Web Exchange client - are simply web applications that more closely approximate features normally associated with traditional, standalone desktop applications.

All this is all well and good. Ajax is a wonderful new technology, which we should all try to explore and exploit to its full capacity. BUT, that JavaScript portion of Ajax is causing some problems, as John notes:

The fact that you can write interactive web sites in Javascript, though, doesn’t make Javascript a great programming language for complex site development.



Published: Saturday, November 26th, 2005

AHAH: Asynchronous HTML and HTTP.  Or AJA, as I like to call it; Asyhcrhronous JavaScript And…. :).  Also known as AJAH: Asynchronous JavaScript and HTML.  OK, so we’re just throwing around terms here, but basically it boils down to Ajax without the XML component.

XML is the main communication method over the Internet.  Many applications use XML to transmit data to and from servers and clients.  But is it right for all of us?  There was a nice article about this written at Microformats.  They give nice code examples, but if you already have Ajax implemented, it’s not a long stretch of the imagination.  Before that, let me get into why some people may want to use it.

Whether we like to admit it or not, XML is still just text.  There is no sort of data compression done to make it faster to transfer or anything.  It’s just text.  The advantage, of course, is that it is highly structured.  XML does have its place, but sometimes it is just overkill for simple things.  For example, if the server simply needs to reply with a short “YES” or “NO”, then wrapping these in complex XML tags just packs on much more than is needed.  Also, after being received on the client it, it needs to be decoded and handled.



Published: Saturday, November 19th, 2005

This is where many web developers tend to disagree. We can never seem to settle on a good code editor, ever. I’m going to leave you with a few of my favorites and some that I hate.

First off, I live and die by Macromedia Dreamweaver 8 Win/Mac. As a matter of fact, I also use Macromedia Fireworks 8heavily for my web site designs. I just think that they have done a good job and incorporating HTML and CSS together. Especially with version 8.0. But then again, you get what you pay for because it’s going to set you back quite a pretty penny ($399). But it was a good investment for me.

On the other hand we have the Frontpage junkies. I haven’t really looked at Frontpage much since early 2000. I’ve opened up the version that comes with Office XP, but I was not impressed. What I do remember is that back in the day it was horrible. Frontpage used to dump a bunch of Microsoft specific “tags” into the code that it just served to bulk up the final output. There is the small advance of using Frontpage Extensions, which enable things like site counters and other things (sorry, I really haven’t been looking into it), but the problem lies in the fact that Frontpage extensions on servers usually cost more and they are very limited, and simply I haven’t heard anything about Frontpage lately, so I’m staying away from it.

For PHP editing I use a simply text editor called emEditor. One nice feature is tabbed editing. It also has syntax highlighting. Since I don’t write or compose very large PHP scripts, this is more than adequate for me.

When I’m at work and on Linux (Fedora) I stick to KDevelop. Most likely, I would be doing some C programming anyways, so it is just convenient since it is already opened to just drag and drop scripts and HTML files in there. I don’t, however, do any heavy HTML design on Linux though. I haven’t found tools suitable for such yet. There is something called NVU, but it just doesn’t do enough for me to design a site from scratch using this.

Popularity: 3%



Published: Friday, November 18th, 2005

After days of configuring and reconfiguring, I have finally gotten the sequence down for a Fast CGI installation. Please note, these instructions are specifically for a fresh install of Fedora Core 4. This is what I’ve been working with, for distribution purposes. You may generalize the instructions where applicable of course. And as always, proceed at you own risk. Here we go (Italics indicate my personal settings):

  1. Run the following command at the prompt:
    yum -y install httpd-devel
    You may also download the RPM, or if you’re really adventurous, build it from the source. This installs the httpd-devel package, which is needed for this installation. Most systems may already have this installed, but a fresh default install of Fedora Core 4 does not.
  2. Download the “mod_fastcgi” package from FastCGI.com and unzip it to some directory of your choice.
  3. Perform the following commands:
    cd mod_fastcgi...
    cp Makefile.AP2 Makefile
    make top_dir=/etc/httpd
    make top_dir=/etc/httpd install
    chown -R apache /etc/httpd

    The FastCGI Apache module has now been built.

  4. Add following lines to /etc/httpd/conf/httpd.conf:
    LoadModule fastcgi_module modules/mod_fastcgi.so
    Alias /fcgi-bin/ /var/www/fcgi-bin/
    <directory /var/www/fcgi-bin/>
    SetHandler fastcgi-script
    Options +ExecCGI
    </directory>
    FastCgiConfig …. (if needed)


Page 2 of 3«123»