Joshua Go

Often, you want to look for a particular pattern within a string. Let's say you know that you want to look for the string "revenue" inside a given string. function match_string_for_revenue(string_for_searching) { return string_for_searching.match(/revenue/gi); } var our_string = "We are looking for ReVeNuE."; alert( match_string_for_revenue(our_string) ); You can store the pattern as a regular expression in its own JavaScript variable, which makes your code more readable and its intention better known. function match_string_for_revenue(string_for_searching) { var pattern_to_look_for = /revenue/gi; return string_for_searching.match(pattern_to_look_for); } var our_string = "We are looking for ReVeNuE."; alert( match_string_for_revenue(our_string) ); But what if you want to generalize this matching and be able to search for any given pattern? Can you make it vary based on a parameter given, instead of keeping it in the code? /* NOT GOING TO WO...

By and large, the received wisdom when it comes to configurability and flexible settings for web applications is that more is better. Making something configurable frees up the engineer from having to make mundane (but necessary) changes that can be left to other people. It's desirable to change the state of software without having to rebuild or redeploy the code. There are a lot of obvious benefits to making software configurable, and these benefits are plain to all. What I'm going to focus on here are the costs of configurability, based on my experience and observations over five years of writing web applications full-time. These costs apply to other kinds of software beyond the realm of web applications. I just choose to limit the scope of discussion to web apps because these costs manifest themselves the most when there's a fast development cycle and rapid iteration. The following is intended to be a comprehensive, itemized breakdown of the costs of making an applicati...