RSS feed for InstantSpot site EdomGroup Blog

Firefox Developer Extensions

Fri, 29 Jun 2007 05:00:00 GMT

This is just a reference post that I thought others may find valuable as well, but until I get an app that installs them all for me, here is a shopping list of all the Firefox extensions I like to use in my development setup.

Backup & Restore

Since we have a lot of extensions we use, first lets cover the extensions to backup and restore our extensions :-P

Firefox Extension Backup Extension (FEBE)
https://addons.mozilla.org/en-US/firefox/addon/2109
This extension backs up all your installed extensions in FF.

Compact Library Extension Organizer (CLEO)
https://addons.mozilla.org/en-US/firefox/addon/2942
Your restore mechanism :-) From the description:
"CLEO is a Firefox extension that works with FEBE* to package any number of extensions/themes into a single, installable .xpi file..."

General

Web Developer Toolbar
https://addons.mozilla.org/firefox/60/
Probably the most popular web developer extension. This extension has everything from quick access to view source and cookie management functions to validation and CSS / display analysis functions.

Live HTTP Headers
https://addons.mozilla.org/firefox/3829/
Great for viewing HTTP headers and Requests being made to the server via HTML, Javascript, or Flash / Flex.

FireFTP
https://addons.mozilla.org/firefox/684/
An FTP client for FireFox.

Download Statusbar
https://addons.mozilla.org/firefox/26/
A great replacement for Firefox's download manager window.

Google Browser Sync
http://www.google.com/tools/firefox/browsersync/
Useful for synchronizing bookmarks, etc. across computers.

Minimize To Tray
https://addons.mozilla.org/en-US/firefox/addon/2110
Allows Firefox (and Thunderbird if installed for it) to be minimized to an icon on the task bar.

CSS / HTML

CSS Viewer
https://addons.mozilla.org/firefox/2104/
A great extension to help you see exactly what properties are being applied to any element under your mouse cursor.

ColorZilla
https://addons.mozilla.org/firefox/271/
Gets and copies and color from a page.

MeasureIt!
https://addons.mozilla.org/firefox/539/
Allows you to easily measure anything by drawing a square on the page.

IE View
https://addons.mozilla.org/firefox/1429/
A quick way to open Internet Explorer to the current page via right-click.

ColdFusion

ColdFire
http://coldfire.riaforge.org/
A Firefox extension and CF debugging template that allows you to view your debugging info inside the Firebug extension. This is great to have all your debugging info in one place and the debugging info won't mess up your HTML layouts anymore when it is dropped into the page normally.

Javascript

FireBug
https://addons.mozilla.org/firefox/1843/
FireBug is the most valuable extension for Firefox and Javascript development. It has a great JS debugger, inline console, and reviewing of AJAX requests. Beautiful.

Internationalization

Quick Locale Switcher
https://addons.mozilla.org/firefox/1333/
The name says it all.

The Service Layer

Sun, 13 May 2007 01:17:14 GMT

Lately I have read a few blog posts and talked to a few developers that either disagree with or are unfamiliar with the reasons for using a service layer in web applications. After posting this as a comment on the great Peter Bell's blog , where he references the discussion, I realized I might be better off cleaning it up and posting it here. While I don't go into detail about how I use service objects, I will save that for a later post if anyone says they are interested.

What I usually do is create a service layer for all gateways, DAOs and many other types of handlers including an email service that can prioritize outbound emails in an email queue. Some may argue that I even overuse the service pattern, but in all truth, I think it is very underused in web applications.

These are my explanations of why I feel the service layer can be a great benefit to both the developer and the resulting application (in terms of performance and stability).

The Developer

Having services is often the more logical way for a programmer to think...It often puts things in a very real world perspective. For instance, why do i see so many implementations of a shopping cart that not only contain items, but calculate all the invoice totals, manage taxes, shipping, etc. Doesn't it seem a little more logical to take the cart, along with coupons, etc. to a single register (similar to what you would do in real life)? I find it very easy to deal with a large set of requirements this way (no memorizing URL diagrams or looking at classes with 400 functions). With DAOs and gateways for a typical bean I like having the service layer to say, "Hey, go put this thing in storage for me" which could be totally different places (database, xml, etc.) any time I use the same bean. On the other hand, I can enjoy the active record type pattern by using ColdSpring to pass my beans a dao and give them an incredibly simple save method.

The Application

The application becomes incredibly solid with the use of the service layer...I love knowing that my application loads and 90% of the memory it will ever use is set and ready to go (and it is much smaller than reinstantiating a bunch of large objects on every request). My applications rarely bounce up and down by massive percentages of processor and memory usage because a few more or less users are on. It becomes very easy to spot when something is awry because I know what to expect. Alternatively, with tools like Spring, ColdSpring, etc. I can load objects every time, or as a singleton when first needed, or anyway I like with a few keystrokes.

Conclusions

I think sometimes we get a little too radical for our own good. It seems fairly often lately that I run into "Why the heck do we need X debates?" that claim much less complexity, removing item X allows the developer more creativity, and the application more flexibility. While I think these debates are healthy, I try to remember one thing...programming is about us...if it wasn't, then why didn't someone just come up with a cross-platform assembly language so we could stop there. The service layer is a tool for making things easier for us to understand and manage...it is also incredibly flexible.

My reading lately brought me to asking myself:

How much more work is it to have a service object than to embed this into my objects as they are?

Is adding more types by having a bean and DAO singleton over complicating something?

I've come to the conclusion that the difference if there is one is probably within minutes of eachother, and I could see the service layer even winning out quite often only because I think it is often "more human" for the developer to think of many problems that way. Does every customer get a cash register at a store? Do we all have our very own post office? Makes it very easy to have a flexible application and not have to memorize a complicated UML diagram in my head at least. That answers both questions for me at least.

It is easy for us to use tools like the service layer in dynamic languages and we deserve that benefit for as little work as it is now to implement. That being said, if you don't think its the right tool for the job, don't use it...we all have paid the price for using the wrong tool before and we learn from those experiences differently.

Mike.

Java performance analysis - a real life example

Fri, 02 Jun 2006 03:43:25 GMT

For my thesis I'm writing a Java program that parses two text files (representing satellite images) and performs some analysis on them. The two files are 128 MB and each was taking ~33 seconds to parse. The analysis takes only a fraction of that time, then the results are written back to an output file.

Thinking this was very slow, since the files should be pretty much sequential access off the disk and the read-ahead-buffer would have cached the next block, I decided to dig a little. I rewrote the parsing algorithm in C since it's easier to manage the low-level IO. I used the file stream functions (fopen,fread,fclose) provided by stdio. When I ran the program it took ~10 seconds.

This was insane. Java does have more overhead due to its garbage collection, HotSpot optimizer, and object memory management but it should not be a magnitude of 3x slower. After a few minutes looking at the Java implementation I realized I had forgotten to instantiate a BufferedReader. I immediately jumped to the documentation and there it was, each call to the read method of the FileReader blocks until data is available. If no BufferedReader is supplied this means a context switch for each call. No wonder Java was taking so long. Adding the buffering I reran the algorithm and wow, 13 seconds. Not to bad for a “boated” language.

Figuring I had more places in my program which could be optimized I began looking. The first place I went was to one of the main methods, the one which did the analysis on each image. The logic was pretty simple, find the next pattern in the given image, see if it exists in a lookup table, if so update its statistics or create a new key and add it as a new entry. The data structure I was using for the lookup table was a simple HashMap object. When writing that section of the program I was still relatively new to the Java language and just went with what I'd used in other languages, an associative array.

I did a little analysis with some System.out.println statements and found that on average there was a 14,000 : 15 ratio between reads and writes on the lookup table. Knowing this ratio was pretty stable (I wasn't going to get anywhere near 50% writes) I decided a better data structure would be something with read time of O(n) or less, instead of O(h(k)) where h(k) was the hash function on the key. This meant an array would be best, but I didn't want the hassle of managing the size of the array as new patterns where found. Java had to have something for this. After a little searching I found java.util.concurrent.CopyOnWriteArrayList. This was exactly what I needed. After a little tweaking the new code ran in 1/3 the time.

After this I wrote some small timed programs to examine the running time of the HashMap data structure and the CopyOnWriteArrayList. What I found was as the mutations approached 25% the CopyOnWriteArrayList's performance slowed at an exponential rate. Finally, I couldn't evaluate the performance because the tests were taking too long. On the other hand, the HashMap data structure had a fairly constant performance time irrelevant on the read/write ratio.