Forem: Alex Lau

The Trailblazing Tax: Why Writing New Code Takes So Long

Alex Lau — Mon, 15 Apr 2024 11:50:42 +0000

I've given a lot of absolutely terrible estimates for software over the years. (But let's be honest, can anyone really say they haven't?) One factor I've grown to appreciate is "The Trailblazing Tax."

The trailblazing tax is the idea that trying to trailblaze a new pattern in code is an order of magnitude more difficult than making a change that abides by an existing pattern.

Let's say you're working on an application and are prompted to estimate the time it takes to create a new report to track how many new users signed up. If there's already a reporting subsystem in place, there's a reasonable chance that all of the "new" logic you'll need to add for the request is copying some existing files and writing the database query itself. If you wanted to, you could find an existing report and list out the exact new files and layers of logic that would be needed for this new report.

However, let's suppose there's no reporting framework in place already. In this case, there is so much more to think about:

What format should the reports be generated in: PDF, CSV, etc. Engineering-wise this begs the question of if you need to add a new library as a dependency to your project.
Who has permissions to see these reports?
How are users accessing reports? Are they being delivered via email or are they able to download them directly in the browser? Maybe this answer depends on how long the report takes to generate and the system has to have both.

The list goes on and on... the more novel this functionality is, the more questions will certainly arise as the developer embarking on the feature request will have. Additionally, there are the "unknown unknowns" of not knowing what roadblocks will be stumbled upon throughout this process.

Yes, this example compares having everything already in place to having nothing already in place. You may even be thinking to yourself, "of course writing a new subsystem from scratch is going to be harder." And you're right, that notion on its own isn't too surprising I suppose.

But where the danger lies is where we as developers find ourselves estimating "just one more thing" in terms of adding new functionality to a system. We often think things will be easy when there's one seemingly innocuous change.

Developers give happy path estimates because that's what has the most concrete information. They don't account for non-happy path factors because it's hard/impossible to predict what those are.

A happy path estimate doesn't account for a new package that has installation errors and is incompatible with other dependencies in the project until they've dug in and started writing the actual code. Maybe there's email logic in place that would let you send a report for small files, but once they hit a certain size a mail server would reject them.

I know when I'm trying to conjure these types of scenarios during an estimation meeting, I feel like I come across as overly-paranoid. And I can't say that I blame anyone for thinking that I'm paranoid when everything that I'm talking about is theoretical.

Spike Tickets

In my experience, the best solution to the problem of hard-to-estimate tickets is to prove out subtasks via "spike tickets" - i.e. tickets whose sole purpose is to have a timeboxed research task of proving out an unfamiliar concept.

Revisiting the new bits of functionality from the reporting example earlier, some spike tickets could cover:

Generating reports in new formats like PDF and CSV
Creating a basic permissions framework for who can see reports
Sending out even one report over email and testing various file sizes with this email attachment

The beauty of this approach is that it minimizes unknowns for a task. Rather than biting off a giant chunk of functionality, spike tickets offer bite sized bits of research effort.

Wrapping Up

Unknown factors have a compounding effect on scope creep for a task. Have you ever seen a task blow up to 2 or 3 times its original estimate? I'd be willing to bet that there were multiple unknowns at play that made the task much harder than it initially seemed.

Software is always going to be hard to estimate, there's no getting around that. Trailblazing code is a necessary part of software development, but acknowledging and planning around it helps keep estimates in check before they get out of hand.

Do you have any strategies you use for handling hard-to-estimate code? Leave a comment below!

Visual Guides For Any Skill With Cloudflare AI

Alex Lau — Sat, 13 Apr 2024 12:37:57 +0000

This is a submission for the Cloudflare AI Challenge.

What I Built

My app, Guide-ify, makes a visual guide for a given life. This is done with a 3-step process:

Make a request to research more about the given skill.
Summarize these findings.
Create a corresponding visual aid for each step in the summary.

These steps each correspond to a different Cloudflare AI model (see "Using AI Models" below for more details).

Demo

You can try out the app here: https://cloudflare-playground-bn1.pages.dev/

My Code

Here's the repo for my project: https://github.com/MrAlexLau/cloudflare-playground

Tech stack:

The front end app was built with Sveltekit
Styling is done with Tailwind with some snippets used from Flowbite
The app itself is hosted on Cloudflare Pages
The logic to generate output is done with Cloudflare Workers

Journey

My goal was to build something fun and useful that stitched together multiple AI models. One of the exciting aspects with new AI tools is how easily they can be integrated together.

Getting Started With Cloudflare

This was my first time using the Cloudflare's Pages and Workers, and I was pleased that they were both a breeze to use! In particular, the guide for deploying a sveltekit page made it very quick to get a site up and running on Pages.

My next step was to submit a request to a Cloudflare Worker. The two main issues I ran into were that my requests were coming across CORS errors and that I wasn't sure how to parse the params within the worker itself.

Fortunately there was sample code for both of these issues as well. I specifically referenced the CORS Header Proxy and the Fetch JSON when writing the code for my Workers. For reference, you can view all of Cloudflare's Worker examples here as well as longer form tutorials.

Using AI Models

My app uses 3 task types of Cloudflare's AI models:

Text-to-Text (for researching the given topic)
Summarization (for summarizing the research results if the given research can't be easily parsed)
Text-to-Image (for creating images for each step in the guide)

The code for these workers ended up being quite straightforward. For example - within a Worker, calling the Text-to-Text model is as simple as:

let response = await ai.run('@cf/mistral/mistral-7b-instruct-v0.1', { prompt: "Tell me everything there is to know about turtles." });

I decided to create separate Workers for each task, which results in a separate REST endpoint that I can call for each of these operations. This worked well since I was able to test them independently and makes them more composable going forward (eg - I could create another app that uses the same Workers without having to change them at all!).

One thing that's really nice about working with Cloudflare Workers is that the editor has the ability to test out the Worker on the fly before you deploy it. Specifically you can log output (as shown in the red boxes) and preview output (as shown in the blue boxes):

Handling Inconsistent Output

If you work heavily with any text-based AI model, one issue you're bound to run into is output data inconsistency. Specifically, my prompt to the models would request something like "Give me an list of actionable steps for learning how to juggle." Sometimes the output would be a numeric list, other times it would be a bulleted list or simply be a paragraph of text. The AI model being called also affected the output, for example the @cf/tiiuae/falcon-7b-instruct model seems to prefer bulleted lists.

I needed some way of ensuring that the data I parsed could be read reliably every time while still making sure I was preserving the intended content of the message. My approach to normalizing this data was with a 2-step process:

Check and see if the output text from the Text-to-Text model is a numbered list. If it is, parse out each step in that list.
If the output is not a numbered list, then send a request to the Summarization AI model.

Using the Summarization model is especially useful since strips out any exclamations added in by the Text-to-Text model. For example, I noticed that the llama text model will often add phrases like *giggles* to its output which aren't relevant for my purposes. Using the summarization model strips out this type of extraneous text as well as preserving the main points from the text model's output.

Next Steps

Being that this is a project that's submitted for a hackathon, it's not production-ready code. My next steps for cleanup would be to:

Restrict CORS settings used by my Worker endpoints. Right now they're open to make development easier, but that's not a practice I'd ever use for a production-grade application.
Add error handling and tests.
Moving worker logic directly into my project and developing via Cloudflare's Wrangler.
- I developed my workers directly within the Cloudflare web ui which worked well for my use case, but I feel like Wrangler would be a more smooth developer experience going forward since I wouldn't have to leave my text editor when modifying Worker code.
- You can find the source code for my Workers here.

What I Learned

There was quite a bit that I learned with this project:

Working within Cloudflare
- How to deploy to Pages and Workers
- Using the Workers web editor to modify, preview, and deploy updates
- I like that the code for Workers is version controlled on the Cloudflare side, you can easily roll back to a previous version if you'd like
- I was surprised that the free tier comes with 100k Worker requests per day for on the free plan
- Having set up these tools now, I feel like creating a new project with Pages and Workers would be very fast
Sharpening up my Svelte and Tailwind skills
Submitting requests and reading responses from Cloudflare AI Models. For example, here's how to turn binary image output into a url that my app can use:

const imageSrc = await fetch(
  // This worker calls the Text-to-Image `@cf/stabilityai/stable-diffusion-xl-base-1.0` AI model
  "https://text-to-image.mralexlau.workers.dev",
  requestOptions({ prompt: sentence })
).then((response) => {
    // response is binary output
    return response.blob();
}).then(function(blob) {
  const objectURL = URL.createObjectURL(blob);

  // now the return value will be a string that an <img> tag can use for its src attr
  return objectURL;
});

Multiple Models and/or Triple Task Types
Again my app uses 3 task types of Cloudflare's AI models. Specifically the models that I used were:

Summarization - @cf/facebook/bart-large-cnn
Text-to-Image - @cf/stabilityai/stable-diffusion-xl-base-1.0
Text-to-Text - Defaults to @cf/tiiuae/falcon-7b-instruct

I also noticed that many of the text models have similar interfaces, so I added a setting to try out other text models. Users can select any of these text models:

@cf/meta/llama-2-7b-chat-fp16
@cf/meta/llama-2-7b-chat-int8
@cf/mistral/mistral-7b-instruct-v0.1
@cf/tiiuae/falcon-7b-instruct
@hf/google/gemma-7b-it
@hf/nousresearch/hermes-2-pro-mistral-7b

Wrapping Up

I had fun on this project! Using a new ecosystem can be daunting at times, but I felt like I was able to get up and running quickly and that future projects would be a breeze to set up. Looking forward to seeing what other AI models Cloudflare adds in the future.

If you have any questions about the code or running this project, please reach out in the comments!

Make Yourself Expendable

Alex Lau — Tue, 02 Apr 2024 10:37:46 +0000

I used to idolize the "rock stars" and lone wolves who knew everything about a particular subsystem in the projects that we were working on. The only problem is that they were the only ones who knew about what they were working on.

I've heard people half-joke that knowing a particularly gnarly domain of an application is a form of job security. And while I think that's a grain of truth to that notion, I don't think it should ever end there.

In fact, I think taking this idea to the opposite end of the spectrum is actually what makes you a better software developer. Rather than being the only person who knows how something works, being able to make a subsystem approachable to everyone else on the team is the mark of an excellent teammate. Paradoxically by making yourself expendable, you become an integral part of the team.

Someone who optimizes for job security ends up subconsciously embracing practices that don't help the team too much. They tend to leave the complex system as-is and only make minimal changes to it when absolutely required. If anything ever happens to them or they take a vacation, the team has to start learning everything from scratch and scramble to make changes.

Whereas a developer who looks to make themselves expendable embraces habits that help amplify the team:

Ensuring there is adequate testing in place
Refactoring the system to make it easier to work in
Writing documentation so others can grasp concepts more quickly

A colleague of mine once summarized this perspective nicely when he was reflecting on his vacation time and told me, "I want to be missed, but not needed." And that's really the goal, isn't it? You want your team to appreciate your contributions and expertise, but you also want to have done enough to enable them to help themselves in your absence.

Taking this notion of legacy a step further - the day is going to come when you part ways with your job. Not to be overly-existential, but how do you want to be remembered on your team? Do you want to be known as the person who knew everything but whose absence sets a tone of panic among the team? Or do you want to be remembered as the person who tackled messy code head-on and made the entire team better for it?

The Virtuous Cycle of Testing

Alex Lau — Fri, 29 Mar 2024 13:18:03 +0000

There are many good reasons to write tests for your code: catching bugs, preventing functionality regressions, defining better interfaces to your modules, the list goes on.

But one reason isn't discussed quite as frequently that I like to call "the virtuous cycle of testing." Put simply, this virtuous cycle is the idea that writing more tests makes it easier to write other tests in the future.

I've seen it time and time again: everybody happily embraces tests until they get too hard to write. It's easy to write the test confirming that a banner component renders on a page; it's harder to write the test that confirms that the login flow and all of its error states are working properly. Similarly, testing interactions with external APIs is a common point for teams to draw the line of what they're willing to test since setting up a tool to mock responses can be daunting.

At a more abstract level, it's easy to write tests when you have a very similar bit of logic you can copy over and apply to the tests you need to write, but it's more challenging to write tests that explore a new domain and require extra setup and overhead. On top of that, if the new code being added isn't mission-critical, there may be a conscious decision to not write tests at all.

And hey, I get it. Timelines force us into uncomfortable situations when it comes to delivering aspirational code. We can't write tests for every single use case in a system and that's ok. But that doesn't mean we should throw our hands in the air every time something is hard. A test suite that only covers easy-to-write use cases is better than nothing, but not much more.

Just as I've seen teams where a testing suite has dwindled over time, I've also seen teams who have a culture of excellence and go to the extra mile for testing even when it's difficult.

The most powerful mental model I've seen with having effective test coverage is to have the attitude "we should default to writing tests for new code unless there is a very good reason not to." Once that's in place, I've seen other pieces fall into place for how the team operates: engineers pointedly ask where the tests are during code review and offer to pair program when tests are missing.

Those are the codebases and teams I've enjoyed working in the most over the course of my career. The difference is palpable - from having fewer regressions in a system to making tests a normalized part of the development workflow. I suppose there's something to be said for the social dynamic as well in these cases - if everyone else is writing tests, I don't want to be "that guy" who just skips over them.

The next time you find yourself tempted to skip over a test because it's difficult, I would encourage you to not think of extra testing overhead as aspirational and instead think of it as an investment. Each time someone contributes a new test that covers one of those hard-to-trailblaze areas of code, it becomes a reference point that pays dividends for every developer on your team in the future. The more others can utilize these reference points, the more tests they'll write that will in turn help you in the future.

In Praise of the Timebox

Alex Lau — Tue, 26 Mar 2024 12:39:04 +0000

You may have heard before that when you work in software development, you eventually build up a sort of "mental toolbox." The more you try out different tools, the more you familiarize yourself with them and know when to apply the right tool for a specific task at hand. One of the most valuable tools I've found myself reaching for over the years is to use the technique of timeboxing.

The concept of timeboxing is extremely simple - within a given task, you limit the maximum amount of time that you're willing to spend on that task.

For example, I may dedicate an hour to adding extra flourish to a congratulatory screen after a user signs up for a product. Once that hour passes, it's "pencils down" mode. If I'm done, great! But if I'm still working on it, too bad. I can save my progress and potentially come back to it in a future task, but for now I've spent all the time I'm willing to allocate to this request.

Given that this concept is so simple, why is it so powerful? I think it's because writing software involves a lot of uncertainty. Software developers are notoriously terrible at providing estimates for code, and timeboxing allows for freedom of exploration within a task that may seem daunting.

Let's take a look at some of the types of tasks I frequently find myself timeboxing:

Front end designs. If a designer has a mockup with an unusual interaction or layout that I suspect is difficult to implement, timeboxing lets me say "let me give this a shot for an hour or two" rather than a flat out "no, we can't do this". Sometimes I'll surprise myself and the interaction is easier to implement than I expected. Other times I'll have to forgo this request and either abandon it altogether or save it for another day.
Refactor suggestions from code reviews. There are many code review comments I receive where teammates have suggestions for refactoring a particular piece of code, but they don't consider it a blocking suggestion for the code review. These suggestions can fall anywhere on the spectrum of impact: from having little/no side effects to refactoring critical areas of the system. If I'm unsure of the impact, timeboxing lets me investigate this difficulty without being beholden to polishing every bit of code to pristine levels before being able to merge it.

What do both of these examples have in common? In general, they're tasks that are nice-to-haves rather than need-to-haves in terms of importance, as well as being fuzzy in terms of amount of effort they'll take to solve. These qualities directly tie into why exactly I find timeboxing so useful:

Focus on what's truly important within a request. Just because the design of the submit button on the form isn't 100% implemented to spec, that shouldn't prevent all of the rest of the work from the form from being shipped. By timeboxing more fringe aspects of a feature request, you're finding that right balance between "we've done our due diligence on this and have decided to delay/forgo it" and "this can't ship until it's absolutely perfect according to the spec."
Embrace unexpected ease of implementation. I happily admit that I don't always know how difficult a task may be. I'm pleasantly surprised when implementing I thought was going to be difficult turns out to be easy. This saves me from giving up on a task too eagerly. Sometimes when you say "we'll do this in another task" that day never comes, especially on teams where tackling tech debt is viewed as a luxury rather than a necessary practice within software development.

And there we have it, timeboxing! Drop a comment to let me know what you think - do you use timeboxing yourself? If so, what has your experience been like?

OO to Elixir: Clean Code With Pattern Matching

Alex Lau — Mon, 29 Jan 2024 17:30:19 +0000

One of the joys of working with new programming languages is uncovering new ways to solve problems. New patterns and tools within languages expand your horizons in terms of how to structure code.

A few years ago, I went from working with Ruby to working with Elixir and was very impressed with how the concept of "pattern matching" allowed me to write elegant functions. Even if you don't know Ruby or Elixir, the explanations below should be simple enough to demonstrate the power of pattern matching.

Pattern Matching Tuples

In Ruby, although it's not a particularly common pattern, you can assign multiple variables on the left hand side of an assignment:

irb> a, b, c = [:hello, "world", 42]
irb> a
:hello
irb> b
"world"
irb> c
42

Per the Elixir pattern matching docs you can do the same thing and assign multiple variables to a tuple:

iex> {a, b, c} = {:hello, "world", 42}
{:hello, "world", 42}
iex> a
:hello
iex> b
"world"
iex> c
42

However, in Elixir you can also specify explicit literals on the left hand side of the assignment that will only perform the assignment when the right side matches that literal:

iex> {:hello, b, c} = {:hello, "world", 42}
{:hello, "world", 42}
iex> {:not_hello, b, c} = {:hello, "world", 42}
** (MatchError) no match of right hand side value: {:hello, "world", 42}

Knowing this, a common pattern in Elixir is to return a tuple that begins with :ok.

case update_user(params) do
  {:ok, user} ->
    "#{user.name} was updated."
  {:error, errors} ->
    "This clause will match when there is an error and update_users can populate the errors variable"
  _ ->
    "This clause matches any unmatched paths in this case statement"
end

Whereas in Ruby, you may write something like this:

if user.update(params) # assume this returns a boolean
  "#{user.name} was updated."
elsif user.errors.any?
  "The user class can hold errors in its corresponding function in the object"
else
  "Something went wrong with the update"
end

One thing that's nice about the Elixir approach is that you get all of the data you need from the update_user function itself (whether it's error details or a user object). Rather than the equivalent ruby approach where you have to call a separate errors function to get the error details.

Pattern Matching function Signatures

Pattern matching becomes especially powerful when used in function signatures since it narrows the scope of the function before the actual body of the function is executed. The Elixir function documentation give this example:

defmodule Math do
  def zero?(0) do
    true
  end

  def zero?(x) when is_integer(x) do
    false
  end
end

In this case, Math.zero?(0) would execute the first version of the function, whereas calling Math.zero?(1) would call the 2nd version of the function. Although this example is trivial, it's easy to see how narrow the scope becomes for each of the function bodies. By the time you reach the code in the body of the zero?(0) version of the function, you're guaranteed to know that the value being passed in is zero.

Conditionals are less frequently needed in Elixir since you can just pattern match against arguments and have multiple versions of the same function. Take this example in ruby:

def character_damage(character_type, weapon, base_damage)
  # bonus damage is zero by default
  bonus = 0
  if character_type == :paladin
    if weapon == :bow
      bonus = base_damage + 5
    elsif weapon == :sword
      bonus = base_damage + 10
    end
  elsif character_type == :wizard
    # wizards always get a bonus
    bonus = 12
  end

  base_damage + bonus
end

In Elixir, you could rewrite all of these as a bunch of 1 line functions!

def character_damage(:paladin, :bow, base_damage)
  base_damage + 5
end

def character_damage(:paladin, :sword, base_damage)
  base_damage + 10
end

# _ matches anything
def character_damage(:wizard, _, base_damage)
  base_damage + 12
end

# if none of the other signatures match, default to no bonus damage
def character_damage(_, _, base_damage)
  base_damage
end

An alternative way to write the ruby example with a more object-oriented approach is:

paladin = Paladin.new()
paladin.set_base_damage!(1)
paladin.damage(:bow) #=> 1 + 5 = 6
paladin.damage(:sword) #=> 1 + 10 = 11

wizard = Wizard.new
wizard.set_base_damage!(1)
wizard.damage() #=> 1 + 12 = 13

generic_character = GenericCharacter.new
generic_character.set_base_damage!(1)
generic_character.damage() #=> 1

Bringing It Together

I love pattern matching because it allows me to write very concise, specific functions. Coming from a background of working in object-oriented languages, another way to think about what pattern matching in function signatures does is affords you the convenience of specificity that object-oriented models has, but at the function level rather than the class level.

How the 80/20 Rule Can Make You a Better Developer

Alex Lau — Wed, 24 Jan 2024 16:55:13 +0000

In a previous job, I had a brief stint where I had transitioned from a software engineer to a product manager. I learned many things in this role (including that I did not want to be a product manager in the long term), but by far the biggest lesson was seeing the 80/20 rule in practice and how it affected my approach to software.

In case you're not familiar with the 80/20 rule (formally known as the Pareto Principle), it's the idea that 80% of results come from 20% of the work. Conversely (and arguably more importantly!) is the idea that the remaining 20% of work takes 80% of the time to finish.

I had known about this principle before working as a product manager, but seeing it in action while working with developers was another story. I was used to being an engineer and going to my product manager to tell them that a feature was more difficult than originally estimated. It was a strange feeling to be on the other side of the table where developers would come to me echoing that same sentiment.

What was particularly interesting was seeing exactly what parts of a feature request developers were getting hung up on. Often the specific parts they were struggling to accommodate was of little/no consequence to me as the feature requester.

For example, a feature may be something like "Add a new pricing page to our website as depicted by the attached mockup." And if a developer came to me saying something like, "this is actually going to take much longer than we estimated because the design of these dropdown boxes is totally new." Chances are I'd be happy to downscope that design or maybe even drop it altogether. The main goal was to add a new pricing page, not recreate a mockup verbatim for the sake of pedantry.

I'd be lucky if that conversation happened early on in the sprint, but often I wouldn't hear about problems until we were close to feature freeze which was always the most painful and rushed time to have to make those sorts of decisions. Many headaches would've been curbed or avoided entirely had I had better insight into which parts of a feature request were going to be the most problematic.

Leveraging the 80/20 Rule to Your Advantage

Now that I've returned to my role as an engineer, I feel like I have more empathy and can communicate better than ever with my teammates.

How can the 80/20 rule make you a better software developer? By knowing that not every feature needs to be implemented verbatim. In fact, you should always be asking yourself: "What is the problem that this feature is trying to solve?" when building software. In the case of the pricing page, the answer was to convey pricing information to users, not to have the fanciest dropdowns a user had ever seen. Know that your product manager and designers don't have complete information about a system, and you're actively doing them a favor by calling out hard-to-implement features early on in the development process.

Hope you enjoyed this read! If you liked this article, I talk about the 80/20 rule more in my book Keep Calm and Code On.

Supercharge Your Workflow With Chrome Profiles

Alex Lau — Fri, 25 Aug 2023 19:37:00 +0000

One of the most impactful changes I’ve made to my workflow in the past couple of years is to use multiple profiles in Chrome. This allows me to run Chrome for multiple users at the same time.

You may be thinking, “Ok, that’s kind of nice – but I can already sign in to different gmail accounts within the same browser window. So what’s the additional benefit here?”

Separate Contexts

The real advantage to maintaining these profiles is that each profile gives you a separate, isolated Chrome context. That means that all of your bookmarks, history, extensions, saved usernames, etc. all stay within the context of one profile.

As a developer, this is a lifesaver. I can have one profile linked to my personal email and one linked to my work email. The work one has an uncluttered list of bookmarks that only pertain to work, remembers my test account usernames, only uses extensions that are relevant to work, and doesn’t reveal embarrassing personal search history like "Can you live off of pizza alone?" when I’m in the middle of a demo. If I were to leave my company my personal profile remains unaffected - there’s no need to rearrange my bookmarks or do any kind of cleanup.

Testing With Multiple User Accounts

You’re probably already done something like this anyway by using an incognito window when testing an application. This does accomplish the goal of keeping your main browser in an isolated environment from your test environment. But separate profiles lets you take this a step further.

Profiles let you test an application with multiple user sessions simultaneously with ease. I regularly keep a separate browser tab open for a demo admin user, a logged out user, and a logged user for applications. Each one has their own history and can persist their session across days or weeks unlike an incognito window which will be lost when it’s closed.

Setting up multiple profiles separates your concerns for how your browser experience is organized. When you only have one Chrome profile, it’s easy for browser data to get out of hand – especially with regard to having too many bookmarks and extensions. Adopting multiple profiles allows you to keep what’s most relevant at hand, without having to open different browsers at the same time.

It’s Not Just Chrome!

Although I’ve mentioned the profiles feature specifically for Chrome, it also exists in other major browsers like Firefox, Edge, and now even Safari. The same techniques and benefits outlined here can be used in any of those browsers as well.