Out of Hanwell

September 28, 2005

Fun with Internet Explorer

Filed under: Uncategorized — Matthias Miller @ 2:15 pm

It can be a lot of fun to develop web pages for Internet Explorer. Without further ado, here are two pages I have prepared just for you:

  • “Operation Aborted” message. This is just an odd error message that you get when loading a page. If you have a script inside a form, and the script calls createElement while the page is loading, Internet Explorer fails to load the page.

  • Internet Explorer crash. As a courtesy, this page prompts before crashing. There page has many facets that must be present for the crash to occur, yet the code is surprisingly simple.

Who’s says you need to be ashamed about creating pages that can only serve their purpose in Internet Explorer?

Enjoy.

Advertisements

September 26, 2005

Object-Oriented JavaScript and this Keyword

Filed under: Uncategorized — Matthias Miller @ 9:02 pm

The limitations of object-oriented JavaScript can really make web development difficult. Today I was refactoring some newly-written code and was surprised to find my page had broken because this was evaluating to an unexpected value.

Here’s what the code looked like:

function SampleObject(value)
{
this.value = Number(value);
this.Increment = PrivateIncrement;
this.getValue = function() { return this.value; }

function PrivateIncrement() {
this.value++;
}

/* try to automatically increment number
* when instantiated; (will fail because
* "this" will equal "window")
*/
PrivateIncrement();
}

/* displays 10; number not incremented */
var myObj = new SampleObject(10);
window.alert(myObj.getValue());

/* displays 11; increments as expected */
myObj.Increment();
window.alert(myObj.getValue());

When I looked at the PrivateIncrement function more closely, I noticed that this was evaluating to the window object when SampleObject was being instantiated. However, it was evaluating to myObj when myObj.Increment was called. I could work around it by:

/* calling PublicIncrement directly */
this.Increment();

/* using the "call" syntax */
PrivateIncrement.call(this);

I then remembered a workaround that I had seen before but that I hadn’t bothered to understand:

function SampleObject(value)
{
var self = this;
...
function PrivateIncrement() {
self.value++;
}
...
}

Yech. All this finally makes sense at the technical level, but…why can’t you just let me call PrivateIncrement directly?

If the gurus tell me I can write object-oriented JavaScript, why are articles about object-oriented JavaScript always about technique, not design? Why is it that I have to force basic tenets of object-oriented programming into JavaScript’s primitive worldview?

Why does JavaScript have to make web development so difficult sometimes?

September 21, 2005

JavaScript Arrays the Long Way Around

Filed under: Uncategorized — Matthias Miller @ 6:41 am

There’s an Indian proverb that says there are two ways to touch one’s nose: you can touch it directly or you can touch it the long way around.

I was searching the Internet for JavaScript array extensions when I found this function:

Array.prototype.insertAt = function (what, iIndex)
{
if (iIndex < this.length) {
var aAfter = this.splice(iIndex, 100000, what);
for (var i = 0; i < aAfter.length; i++) {
this.push(aAfter[i]);
}
} else {
this.push(what);
}
}

What’s so odd about this?

You can do it in a single function call:

myArray.splice(index, 0, element);

Updated post not to point fingers; slice is simply a weird function.

September 19, 2005

Nested CSS Blocks

Filed under: Uncategorized — Matthias Miller @ 11:06 am

Besides incomplete browser implementation, I haven’t found much in CSS about which to gripe. But today I came up with a way to greatly improve the useability of CSS.

Imagine that you write a MagicWidget tool with an indefinite number of edit controls and buttons. One day your boss tells you, “You know, that MagicWidget works well, but it looks awful. The edit controls should have orange text and the buttons should have bold text with a yellow background.”

You write the following CSS:

input {
color: orange;
}
button {
font-weight: bold;
background-color: yellow;
}

The next day your boss asks you to add a feedback form and a “search this site” form to the same page. You forget about the styles you had added for MagicWidget, and when you open the page, these controls have bizarre colors!

You dutifully change the CSS to:

div#MagicWidget input {
color: orange;
}
div#MagicWidget button {
font-weight: bold;
background-color: yellow;
}

As you develop your project, you continue to tweak the styles for the items in your MagicWidget and soon you have dozens of styles like these that are prefixed by “div#MagicWidget”.

“Oh,” you cry, “if only I could nest these CSS blocks! It would make so much more sense and would eliminate so many awkward keystrokes.”

You reformat the CSS just to see what it would look like:

div#MagicWidget {
input {
color: orange;
}
button {
font-weight: bold;
background-color: yellow;
}
}

“Eureka!” you shriek. “The world has got to know! CSS rules make so much more sense when they model the tree structure of the DOM!”

Ah, but the world refuses to listen. You sullenly return to your CSS, slavishly typing these awkward selectors as your boss continues to find new ways to tweak the widget.

You can only marvel where the world is ignorantly headed.

September 16, 2005

String Manipulation in C vs. Perl

Filed under: Uncategorized — Matthias Miller @ 2:38 pm

There’s is a great difference between the techniques for string manipulation in Perl and C. The former makes heavy use of unreadable regular expressions; the latter makes heavy use of loops through null-terminated strings.

Today I wrote a string comparison function in C++. The requirements were simple: create a comparison function for a case-insensitive sort, ignoring all hyphens and apostrophes. The comparison function must return either -1, 0, or 1.

After I wrote it, it looked really verbose, so I rewrote it in C:

int compareStrings(const char *s1, const char *s2)
{
int i;
const char *t1, *t2;
t1 = s1;
t2 = s2;
while (1) {
/* skip hyphen and apos */
while (*t1 && (*t1 == '-' || *t1 == '\'')) t1++;
while (*t2 && (*t2 == '-' || *t2 == '\'')) t2++;

/* check if:
* -first string has fewer letters than second
* -strings have same number of letters
* -second string fewer letters than first
*/
if (!*t1 && *t2) return -1;
else if (!*t1 && !*t2) return strcmp(s1,s2);
else if (*t1 && !*t2) return 1;

/* case-insensitive compare */
i = tolower(*t1)-tolower(*t2);
if (i < 0) return -1;
else if (i > 0) return 1;

t1++;
t2++;
}
}

But then I saw the value of i was being checked twice for each character. “Oops. That will make the computer slow to a crawl,” I thought. So I replaced it with this:

if (i) return (i|0x100) & 0xFF;

I then removed all comments:

int compareStrings(const char *s1, const char *s2)
{
int i;
const char *t1, *t2;
t1 = s1, t2 = s2;
while (1) {
while (*t1 && (*t1 == '-' || *t1 == '\'')) t1++;
while (*t2 && (*t2 == '-' || *t2 == '\'')) t2++;
if (!*t1 && *t2) return -1;
else if (!*t1 && !*t2) return strcmp(s1,s2);
else if (*t1 && !*t2) return 1;
i = tolower(*t1)-tolower(*t2);
if (i) return (i|0x100) & 0xFF;
t1++, t2++;
}
}

My eyes glazed over as I reread the code. “Hmm,” I thought, “perhaps there are some similarities between string manipulation in Perl and C.”

September 14, 2005

Finding Duplicate Code

Filed under: Uncategorized — Matthias Miller @ 8:38 pm

As an interesting experiment, I wrote a program a while back to find snippets of duplicated code. The algorithm was quite simple:

  • Load all files into memory
  • Hash each line, as well as a user-configurable number of lines following it
  • Match snippets based on these hashes, double-checking matches byte by byte
  • Merge duplicate sections and report the results.

The primary bottleneck was disk access and memory allocation. When the OS had the files cached, it took about 3-4 seconds to run it on a >500K-line code base. The secondary bottleneck was hash calculation. After all, each line of code was being hashed a dozen times over (depending on the user-configurable option).

Several days ago I decided to implement rsync’s rolling checksum algorithm to see if it would be faster. I had to modify it slightly to be able to roll multiple characters in and out of the hash, but I was able to drop the profile from 4-5 seconds down to 3-4 seconds (depending on whether you include yielded processor time).

That makes me wonder if I can get it any faster. I figure on some long, blustery weekend, I’ll be changing this tool to be multithreaded and perhaps to manage its memory and I/O more carefully.

Until then, I’ll keep wasting several seconds every time I run it.

Further Reading:

Modifications to librync’s rollsum:


#define RollsumRollinOther(sum,sumOther) { \
(sum)->s2 += (sum)->s1*(sumOther)->count + (sumOther)->s2; \
(sum)->s1 += (sumOther)->s1; \
(sum)->count += (sumOther)->count; \
}


#define RollsumRolloutOther(sum,sumOther) { \
(sum)->count -= (sumOther)->count; \
(sum)->s1 -= (sumOther)->s1; \
(sum)->s2 -= (sumOther)->s1*(sum)->count + (sumOther)->s2; \
}

September 8, 2005

My Job Went to India

Filed under: Uncategorized — Matthias Miller @ 8:10 pm

I had an unusual opportunity the last two days to catch up on some reading. Today I read the PDF version of My Job Went to India by Chad Fowler, and I found it to be a great book. There are too many good facets to put into a single blog post, but here are some of them that impacted my outlook at work.

  • Be a Generalist. Don’t Put All Your Eggs in Someone Else’s Basket. There are certain practices that I cling to. I am primarily a C++ programmer, and if anyone on the team is making a case for procedural programming, it’s me (admittedly sometimes only in jest). I avoid using exceptions for error handling in C++, and I write almost no multi-threaded solutions. I develop almost exclusively in Windows.

    These habits may be fine, but software development is not about forming habits. Software development is a craft. By breaking free from these habits and diversifying your skills, you gain awareness of other coding techniques and make yourself more valuable to any company you might work for.

  • Mind Reader. Learn to pick up hints from your manager and team. If there’s some cleanup or enhancement that can be done with little cost, go ahead and do it right away. (Of course, be careful when it locks in a certain design decision or requires changes to the user interface.) Often these change will come up in a later discussion. By making these changes now, you become aware of the direction of your project, and others will start depending on you as you take the initiative in following your team leader’s path for the project.

  • A Pebble in a Bucket of Water. You are not the genius you like to think you are. Others will come after you, so make yourself replaceable. Do your work well so that when others need to modify your code, they can do it comfortably and safely. After all, the more replaceable you are, the more you are worth to the team and the more likely you can move on to other, more difficult projects.

  • Eight-Hour Burn. You work eight-hour days and forty-hour weeks for a reason. When you work, work. But stop when you’re done. As Fowler writes, “If you work intensely every day, you’ll find that the work doesn’t follow you home. Not only are you deliberately stopping yourself from working after-hours, but your mind will actually allow you to stop working after-hours.”

  • Path with No Destination. It’s quite easy for software developers to get wrapped up with their goals–the next bug to fix, the next feature to code, the next version to release, the next promotion to get. Goals are great, but the funny thing about them is you’re always jumping from one to the next. Sure, work towards your goals, but don’t get so caught up with them that you don’t enjoy what you’re doing now.

I walked away from this book rejuvenated, but it was more than a motivational pep talk. These are basics principles that every software developer should absorb, and honestly, I wish I had had this book before now.

Each chapter is only several pages long, so you can read this book in large or small pieces. I’ve read it through once as a PDF, but I think any serious developer should get a printed copy. I want to be able to pick up the book in a week from now, open it to any chapter, and be reminded exactly what it is that makes a software developer great.

Update: Book excerpts are available on the Pragmatic Programmer website.

My Job Went to India

Filed under: Uncategorized — Matthias Miller @ 8:10 pm

I had an unusual opportunity the last two days to catch up on some reading. Today I read the PDF version of My Job Went to India by Chad Fowler, and I found it to be a great book. There are too many good facets to put into a single blog post, but here are some of them that impacted my outlook at work.

  • Be a Generalist. Don’t Put All Your Eggs in Someone Else’s Basket. There are certain practices that I cling to. I am primarily a C++ programmer, and if anyone on the team is making a case for procedural programming, it’s me (admittedly sometimes only in jest). I avoid using exceptions for error handling in C++, and I write almost no multi-threaded solutions. I develop almost exclusively in Windows.

    These habits may be fine, but software development is not about forming habits. Software development is a craft. By breaking free from these habits and diversifying your skills, you gain awareness of other coding techniques and make yourself more valuable to any company you might work for.

  • Mind Reader. Learn to pick up hints from your manager and team. If there’s some cleanup or enhancement that can be done with little cost, go ahead and do it right away. (Of course, be careful when it locks in a certain design decision or requires changes to the user interface.) Often these change will come up in a later discussion. By making these changes now, you become aware of the direction of your project, and others will start depending on you as you take the initiative in following your team leader’s path for the project.

  • A Pebble in a Bucket of Water. You are not the genius you like to think you are. Others will come after you, so make yourself replaceable. Do your work well so that when others need to modify your code, they can do it comfortably and safely. After all, the more replaceable you are, the more you are worth to the team and the more likely you can move on to other, more difficult projects.

  • Eight-Hour Burn. You work eight-hour days and forty-hour weeks for a reason. When you work, work. But stop when you’re done. As Fowler writes, “If you work intensely every day, you’ll find that the work doesn’t follow you home. Not only are you deliberately stopping yourself from working after-hours, but your mind will actually allow you to stop working after-hours.”

  • Path with No Destination. It’s quite easy for software developers to get wrapped up with their goals–the next bug to fix, the next feature to code, the next version to release, the next promotion to get. Goals are great, but the funny thing about them is you’re always jumping from one to the next. Sure, work towards your goals, but don’t get so caught up with them that you don’t enjoy what you’re doing now.

I walked away from this book rejuvenated, but it was more than a motivational pep talk. These are basics principles that every software developer should absorb, and honestly, I wish I had had this book before now.

Each chapter is only several pages long, so you can read this book in large or small pieces. I’ve read it through once as a PDF, but I think any serious developer should get a printed copy. I want to be able to pick up the book in a week from now, open it to any chapter, and be reminded exactly what it is that makes a software developer great.

Update: Book excerpts are available on the Pragmatic Programmer website.

My Job Went to India

Filed under: Uncategorized — Matthias Miller @ 8:10 pm

I had an unusual opportunity the last two days to catch up on some reading. Today I read the PDF version of My Job Went to India by Chad Fowler, and I found it to be a great book. There are too many good facets to put into a single blog post, but here are some of them that impacted my outlook at work.

  • Be a Generalist. Don’t Put All Your Eggs in Someone Else’s Basket. There are certain practices that I cling to. I am primarily a C++ programmer, and if anyone on the team is making a case for procedural programming, it’s me (admittedly sometimes only in jest). I avoid using exceptions for error handling in C++, and I write almost no multi-threaded solutions. I develop almost exclusively in Windows.

    These habits may be fine, but software development is not about forming habits. Software development is a craft. By breaking free from these habits and diversifying your skills, you gain awareness of other coding techniques and make yourself more valuable to any company you might work for.

  • Mind Reader. Learn to pick up hints from your manager and team. If there’s some cleanup or enhancement that can be done with little cost, go ahead and do it right away. (Of course, be careful when it locks in a certain design decision or requires changes to the user interface.) Often these change will come up in a later discussion. By making these changes now, you become aware of the direction of your project, and others will start depending on you as you take the initiative in following your team leader’s path for the project.

  • A Pebble in a Bucket of Water. You are not the genius you like to think you are. Others will come after you, so make yourself replaceable. Do your work well so that when others need to modify your code, they can do it comfortably and safely. After all, the more replaceable you are, the more you are worth to the team and the more likely you can move on to other, more difficult projects.

  • Eight-Hour Burn. You work eight-hour days and forty-hour weeks for a reason. When you work, work. But stop when you’re done. As Fowler writes, “If you work intensely every day, you’ll find that the work doesn’t follow you home. Not only are you deliberately stopping yourself from working after-hours, but your mind will actually allow you to stop working after-hours.”

  • Path with No Destination. It’s quite easy for software developers to get wrapped up with their goals–the next bug to fix, the next feature to code, the next version to release, the next promotion to get. Goals are great, but the funny thing about them is you’re always jumping from one to the next. Sure, work towards your goals, but don’t get so caught up with them that you don’t enjoy what you’re doing now.

I walked away from this book rejuvenated, but it was more than a motivational pep talk. These are basics principles that every software developer should absorb, and honestly, I wish I had had this book before now.

Each chapter is only several pages long, so you can read this book in large or small pieces. I’ve read it through once as a PDF, but I think any serious developer should get a printed copy. I want to be able to pick up the book in a week from now, open it to any chapter, and be reminded exactly what it is that makes a software developer great.

Update: Book excerpts are available on the Pragmatic Programmer website.

My Job Went to India

Filed under: Uncategorized — Matthias Miller @ 8:10 pm

I had an unusual opportunity the last two days to catch up on some reading. Today I read the PDF version of My Job Went to India by Chad Fowler, and I found it to be a great book. There are too many good facets to put into a single blog post, but here are some of them that impacted my outlook at work.

  • Be a Generalist. Don’t Put All Your Eggs in Someone Else’s Basket. There are certain practices that I cling to. I am primarily a C++ programmer, and if anyone on the team is making a case for procedural programming, it’s me (admittedly sometimes only in jest). I avoid using exceptions for error handling in C++, and I write almost no multi-threaded solutions. I develop almost exclusively in Windows.

    These habits may be fine, but software development is not about forming habits. Software development is a craft. By breaking free from these habits and diversifying your skills, you gain awareness of other coding techniques and make yourself more valuable to any company you might work for.

  • Mind Reader. Learn to pick up hints from your manager and team. If there’s some cleanup or enhancement that can be done with little cost, go ahead and do it right away. (Of course, be careful when it locks in a certain design decision or requires changes to the user interface.) Often these change will come up in a later discussion. By making these changes now, you become aware of the direction of your project, and others will start depending on you as you take the initiative in following your team leader’s path for the project.

  • A Pebble in a Bucket of Water. You are not the genius you like to think you are. Others will come after you, so make yourself replaceable. Do your work well so that when others need to modify your code, they can do it comfortably and safely. After all, the more replaceable you are, the more you are worth to the team and the more likely you can move on to other, more difficult projects.

  • Eight-Hour Burn. You work eight-hour days and forty-hour weeks for a reason. When you work, work. But stop when you’re done. As Fowler writes, “If you work intensely every day, you’ll find that the work doesn’t follow you home. Not only are you deliberately stopping yourself from working after-hours, but your mind will actually allow you to stop working after-hours.”

  • Path with No Destination. It’s quite easy for software developers to get wrapped up with their goals–the next bug to fix, the next feature to code, the next version to release, the next promotion to get. Goals are great, but the funny thing about them is you’re always jumping from one to the next. Sure, work towards your goals, but don’t get so caught up with them that you don’t enjoy what you’re doing now.

I walked away from this book rejuvenated, but it was more than a motivational pep talk. These are basics principles that every software developer should absorb, and honestly, I wish I had had this book before now.

Each chapter is only several pages long, so you can read this book in large or small pieces. I’ve read it through once as a PDF, but I think any serious developer should get a printed copy. I want to be able to pick up the book in a week from now, open it to any chapter, and be reminded exactly what it is that makes a software developer great.

Update: Book excerpts are available on the Pragmatic Programmer website.

Older Posts »

Blog at WordPress.com.