However, up until recently I didn't know how to make DreamPie cooperate with virtualenv. Because it's a GUI program, I scoured its menu and all the preference windows, searching for any trace of option that would allow me to set the Python executable. Having failed, I was convinced that authors didn't think about including it - which was rather surprising, though.

But hey, DreamPie is open source! So I went to look around its code to see whether I can easily enhance it with an ability to specify Python binary. It wasn't too long before I stumbled into this vital fragment:

The conclusions we could draw from this anecdote are thereby as follows:

• It is indeed true that source code is often the best documentation...
• ...especially for open source programs where actual docs often suck.

With this newfound knowledge about dreampie arguments, it wasn't very hard to make it use current virtualenv:

And after doing some more research, I ended up adding the following line to my ~/.bash_aliases:

Now I can simply type dp to get a DreamPie instance operating within current virtualenv but independent from terminal session. Very useful!

I'm still kind of amazed of how malleable the Python language is. It's no small feat to allow for messing with classes before they are created but it turns out to be pretty commonplace now. My latest frontier of pythonic hackery is import hooks and today I'd like to write something about them. I believe this will come handy for at least a few pythonistas because the topic seems to be rather scarcely covered on the 'net.

Importing: a simplistic view

As you can easily deduce, the name 'import hook' indicates something related to Python's mechanism of imports. More specifically, import hooks are about injecting our custom logic directly into Python's importing routines. Before delving into details, though, let's revise how the imports are being handled by default.

As far as we are concerned, the process seems to be pretty simple. When the Python interpreter encounters an import statement, it looks up the list of directories stored inside sys.path. This list is populated at startup and usually contains entries inserted by external libraries or the operating system, as well as some standard directories (e.g. dist-packages). These directories are searched in order and in greedy fashion: if one of them contains the desired package/module, it's picked immediately and the whole process stops right there.

Should we run out of places to look, an ImportError is raised. Because this is an exception we can catch, it's possible to try multiple imports before giving up:

While this is extremely ugly boilerplate, it serves to greatly increase portability of our application or package. Fortunately, there is only handful of worthwhile libraries that we may need to handle this way; json is the most prominent example.

More details: about __path__

What I presented above as Python's import flow is sufficient as description for most purposes but far from being complete. It omits few crucial places where we can tweak things to our needs.

First is the __path__ attribute which can be defined in package's __init__.py file. You can think of it as a local extension to sys.path list that only works for submodules of this particular package. In other words, it contains directories that should be searched when a package's submodule is being imported. By default it only has the __init__.py's directory but it can be extended to contain different paths as well.

A typical use case here is splitting single "logical" package between several "physical" packages, distributed separately - typically as different PyPI packets. For example, let's say we have foo package with foo.server and foo.client as subpackages. They are registered in PyPI as separate distributions (foo-server and foo-client, for instance) and user can have any or both of them installed at the same time. For this setup to work correctly, we need to modify foo.__path__ so that it may point to foo.server's directory and foo.client's directory, depending on whether they are present or not. While this task sounds exceedingly complex, it is actually very easy thanks to the standard pkgutil module. All we need to do is to put the following two lines into foo/__init__.py file:

There is much more to __path__ manipulation than this simple trick, of course. If you are interested, I recommend reading an issue of Python Module of the Week devoted solely to pkgutil.

Actual hooks: sys.meta_path and sys.path_hooks

Moving on, let's focus on parts of import process that let you do the truly amazing things. Here I'm talking stuff like pulling modules directly from Zip files or remote repositories, or just creating them dynamically based on, say, WSDL description of Web services, symbols exported by DLLs, REST APIs, command line tools and their arguments... pretty much anything you can think of (and your imagination is likely better than mine). I'm also referring to "aggressive" interoperability between independent modules: when one package can adjust or expand its functionality when it detects that another one has been imported. Finally, I'm also talking about security-enhanced Python sandboxes that intercept import requests and can deny access to certain modules or alter their functionality on the fly.

All of these (and possibly much more) can be achieved through the usage of import hooks. There are two distinct types of them, usually referred to as meta hooks (defined in sys.meta_path) and path hooks (defined in sys.path_hooks). Although they are invoked at slightly different stages of the import flow, they are both built upon the same two concepts: that of a module finder and a module loader.

Module finder is simply an object which implements one specific method - find_module:

It receives a fully qualified name of the module to be imported, along with path where it's supposed to be found. and it is expected that the method does one of three things:

• Raises an exception, aborting the import process completely.
• Returns None, meaning that given module cannot be found by this particular finder. It can still be found during the next stages of import flow, either by some other custom finder or just the standard Python import mechanism.
• Returns a loader object that is capable of actually loading the module.

The last case is of course the most interesting one, as it gracefully leads us to the concept of module loader. This one is an object that implements the load_module method:

Again, the fullname parameter is a fully qualified name of the module that we want to import. Return value should be a module object - a final result of the whole importing process. Note that this could be something that was already imported; for such "duplicate" imports the loader should simply return the existing module:

If anything goes wrong at this stage, loader should raise an exception (typically is just an ImportError).

Writing your own importer

Here's where most of the theory ends, as conveniently described in PEP 302. In practice both finder and loader can be the same object and the find_module method can simply return self. As an example, consider this simple hook which is intended to block some specific modules from being imported at all:

Once installed in sys.meta_path, it will intercept every attempt to import a new module and check whether its name exists on our list. This applies to indirect imports as well: if we attempt to use the Python Requests library:

then it will also fail, as requests internally uses urllib3, which in turn uses the restricted httplib package.

A hook that is a total blocker doesn't seem very useful, so let's try something slightly different. Rather than refusing to import a particular module, we'll proceed normally and issue a warning instead. Such a hook can help detect when deprecated Python modules are introduced to the project:

In order to access the normal importing mechanism, we can use the imp package. Its functions find_module and load_module are roughly the equivalents of our import hook's methods with the same names. But imp offers much more, as it also contains functions capable of creating modules from various inputs (e.g. load_source, load_compiled) or even creating them completely from scratch (new_module).

What gives?

While this all is surely very interesting, we may doubt whether import hooks actually have any notable applications at all. There is surely potential for some really impressive things, including importing Python modules straight from remote URLs (security concerns notwithstanding). In my case, though, I had an actual need that import hooks seemed to satisfy best.

There is this great pytz package for supporting date and time calculations involving timezones. In general, it is a really shaky ground to thread upon, where issues related to daylight saving time are among the easier ones to deal with. For the most part, pytz helps navigating through the obstacles in elegant manner but there is one thing where it falls short.

The underlying timezone database has apparently no notion of usable, "generic" timezones - ones based solely on offset from GMT rather than precise location, and without any DST. That's bad because generic timezones are useful in web development as temporary choice for new users, based on automatic detection through timezone offset obtained with JavaScript.
But the keyword here is 'usable'. As a matter of fact, pytz has Etc/GMT+X timezones. However, due to some obscure, decades-old compatibility imperative they are the exact opposite of what we would expect them to be: their offsets are effectively negated. It means that Etc/GMT+2, for example, doesn't refer to normal time in eastern Europe (or DST in center/western) but to a timezone on the other side of Prime Meridian which is almost unused except as DST for few South American countries, and Greenland. It goes without saying that this is completely and utterly insane.

In cases like this there are usually two solutions. You can put a thin layer with appropriate fix in front of (already perfect) library interface and make sure that no one uses the library directly - and this is of course impossible. Or you can fork it and make necessary changes - but then you'll have to maintain the fork, manually pulling changes from upstream whenever the original timezone database is updated (which is every few months). Neither is satisfying; couldn't we just use the library as it is, but somehow patch it on the fly, just before it's used?...

Why, of course - hello import hooks! Using a relatively simple module finder and loader, we can easily achieve the desired effect and transparently expand the pytz library to include more useful generic timezones. The full code can be seen in this gist and it isn't even long or complex.

Further reading

That would be it for today's write-up. If you want to learn more about the intricacies of Python's import hooks - such as the meaning of sys.path_hooks, for example - the canonical source will of course be the appropriate PEP. Beyond that, there isn't really any wealth of information to point at: some blog posts here and there, with this one being probably the most useful.

At that time I didn't really get a good answer that would address this issue. And it's an important one, given the rate at which web applications are springing to life and replacing their equivalent desktop programs. Does it mean we'll be stuck with this UI bonanza for the time being?...

Fortunately, there are some early first signs that it might not necessarily be so.

Enter Bootstrap

Few months later, in August 2011, Twitter released the first version of Bootstrap framework. Originally intended for internal use, this set of common HTML, CSS and JS patterns was made open source and released into the wild. The praise it subsequently gained is definitely well deserved, for it is a great set of tools for kickstarting development of any web-related project. Its features include:

• a flexible grid system for establishing a skeleton of the web page or app
• a set of great-looking styles for HTML form elements
• many complex UI components, like collapsible alerts, dropdowns, navigation bars, modal windows, and so on
• customizable set of CSS styles for typical markup elements, such as headers or tables

Along with universal acclaim came also the popularity: it is currently the most watched project on GitHub.

The value of consistency

However, some want to argue that being so popular has also an unanticipated, negative side. It makes the developers lazy, convinced they can get away without a "proper" design for their site or app. Even more: it allegedly shows disrespect for their users, as if the creator simply didn't care how does their product look like.

Does it compute? I don't think so. Do you complain if you find that any particular desktop application uses the very same looks for UI components, like buttons or list boxes?... Of course not. We learned to value the consistency and predictability that this entails, because it frees us from the burden of mentally adjusting to every single GUI app that we happen to use. Similarly, developers appreciate how this makes their work easier: they don't have to code dropdown menus or modal dialogs, which in turns allows them to spend more time on actual, useful functionality.

Sure, it didn't happen overnight when desktop OS' were emerging as software platforms. Also, there are still plenty of apps whose creators - willfully or unintentionally - chose not to adhere to the standards. Sometimes it's even for the good, as it allows for new, useful UI patterns to emerge and be adopted by the mainstream. The resulting process is still that of convergence, producing interfaces which are more consistent and easier to use.

Bootstrap shapes the Web

The analogous process may just be happening to the Internet, considered as a "platform" for web applications. By steadily raising in popularity, Bootstrap has a chance of becoming the UI framework for Web in general - an obvious first choice for any new project.

Of course, even if this happens, it would be terribly unlikely that it starts reigning supreme and making every website look almost exactly the same - i.e. transforming the Web into equivalent of desktop. What's much more likely is following the footsteps of mobile platforms. In there, every app strives to be original and appealing but only those that correctly balance usability with artsy design provide really compelling user experience.

It will not be without differences, though. Mobile platforms are generally ruled with iron (or clay) fist and have relevant UI guidelines spelled out explicitly. For Web it's very much not the case, so any potential "standardization" is necessarily a bottom-up process whose benefits have to be indisputable and clearly visible. Despite some opposition, Bootstrap seems to have enough momentum to really (ahem) bootstrap this process. It already wins hearts and minds of many web developers, so it may be just a matter of time.

If it happens, I believe the Web will be in better place.

The crux of the issue can be demonstrated in the following, artificial example:

The goal is to build some simple XML tree using the most convenient interface, i.e. the lxml.builder.E manipulator from the lxml library. The real code is somewhat longer and more complicated but this snippet encapsulates the issue pretty neatly.

And strange as it may seem, this little piece produces a SyntaxError at the final closing parenthesis:

In such case, the first obvious thing anyone would do is of course to look for unmatched opening brace. With the aid of modern editors (or even not so modern ones ;>) this is a trivial task. Before too long we would therefore find out that... all the braces are fine. Double-checking, just to be sure, will have the same result. Everything appears to be in order.

But, of course, we still have the syntax error. What the hell?!

As it turns out, the offending line is just above the seemingly erroneous parentheses. It's this one:

Or, to be more specific, it is the very last character of this line that the interpreter has problems with:

See, Python really doesn't like this trailing comma. Which, admittedly, is more than surprising, given how lenient it is in pretty much any other setting. You may recall that it's perfectly OK to include the additional comma after the final element of a list, tuple, or dictionary, and it is quite useful to do so in practice. Not only that - it is also possible for argument lists in function call. Indeed, this very fragment has one instance of such trailing comma that appears after a keyword argument (city=user.address.city,).

But apparently this doesn't really work for all kinds of arguments. If we unpack some positional ones (using * operator), we cannot put a comma afterwards. The relevant part of Python grammar specification is stating this, of course:

but I wouldn't call it very explicit. And it seems that you actually can have a comma after *foo but only if another argument follows. If my intuition of formal grammars is correct, the reason for this rule to prohibit foo(*args,) (or foo(**kwargs,) for that matter) is strictly related to the fact than Python's grammar is LL(1). And this, by the way, is here to stay. Quoting PEP 3099:

Simple is better than complex. This idea extends to the parser. Restricting Python's grammar to an LL(1) parser is a blessing, not a curse. It puts us in handcuffs that prevent us from going overboard and ending up with funky grammar rules like some other dynamic languages that will go unnamed, such as Perl.

I, for one, deem this attitude completely reasonable - even if it results in 20 minutes of utter confusion once in a blue moon.

Footnote: The title is of course a not-so-obvious reference to The Infernal Semicolon.

As a solace, though, you could get quite a pile of cash waiting for you to pick up. Let's say you've put 10,000 dollars (or euro, or your favorite currency) into investment with a yearly interest rate of 10 percent. Every year, this deposit will therefore increase by one tenth, and this will happen continuously over the next 1000 years. Could you quickly tell how big the final amount will be, compared to the initial one? How many times will it increase?...

You shouldn't be very hard on yourself if you answered instinctively with e.g. 100 times or something similar. I mean, such figures are totally, utterly wrong by many orders of magnitude because the actual value is bigger than 10⁴⁰. But it's absolutely common to have problems with grasping exponential functions intuitively. In many ways this is quite pitiful, for they accurately describe many phenomenons that occur in nature, civilization, technology and culture. Yet they often escape understanding, leading to unfulfilled predictions, incorrect extrapolations, and plain old cognitive biases.

What is so bizarre about these functions that they tend to confuse a significant fraction, if not the majority of people?...

A derivative problem

First, let's clarify that the exponential function is a very specific one. It can be defined as the only function which is its own derivative. We can write it down as:

where e (equal to approximately 2.71) is typically known as Euler's number and is easily the most important constant in all of mathematics. Yes, much more significant that , , or whatever the current fashion in geometry dictates.

In practice, we often deal with exponentials of different base. For example, computer scientists are especially fond of base 2 for variety of reasons. While the above equality isn't satisfied for those functions in exact manner, the general principle still stands. Differentiating an exponential function always leaves us with another exponential function.

And this, I believe, might be one of the roots of the problem. A significant portion of human brain - the sensory cortex - is basically a very complicated differentiator that operates on incoming neural signals. We experience it as Weber-Fechner law, which basically states that our senses detect changes in stimuli only in proportion to the already perceived one. In other words: the brain is, for the most part, conveniently ignoring the absolute values of sensory data as it's mostly interested in their proportional changes. It would seem that applying differentiation across the board makes the data more manageable for cognitive processing.

How this relates to our poor intuitions towards exponential functions? Well, we could speculate that some equivalent of before-mentioned law works on deeper level: the one related to our "perception" of numbers, measures, quantities and trends - or just mathematics for short. If that's indeed true, then we can easily see how exponentials fail to comply. Because they are immune to differentiation, we are unable to subconsciously transform them into more "natural" form which would be easier for our mind to act upon. Instead, they appear as conceptual black box that we might never really grasp on a fundamental level.

Reinforced by itself

Regardless of whether the above supposition is sound, it is certainly true that exponential trends mess badly with one of our basic intuitions: that future will be more or less similar to the past. Despite countless fluctuations of human condition over the centuries, this heuristic held ground because significant and overarching changes almost always took longer than a single lifetime. It is only through history (written or spoken) that we can learn of the curious and alien ways of living in the distant past.

But cultural and technological development is a self-reinforcing process. This means that any amount of progress not only has an immediate effect in the present but also results in further improvement of speed and effectiveness of the process itself. In physics, we encounter many phenomena that also exhibit this property (e.g. air resistance), and they are described using certain class of differential equations. Their solutions always take a form of - you guessed it - exponential functions.

Maybe this is why we fail so hard at making any kind of mid- to long-term predictions. Linear extrapolation of exponential trend is bound to diverge from reality at very fast pace. On the other hand, this can be a reason why some things remain almost invisible until they "explode" into ubiquity in very short time frame. If they feed upon themselves - being self-reinforcing processes - this is no coincidence, and we could see that happen in case of social networks and mobile applications. I suppose this is also what founders of technological startups should make sure their idea is like.

Adjusting perception

It would appear that exponential functions are quite a pain to comprehend on intuitive, subconscious level. But, as I believe to have shown above, developing more effective intuitions towards them offers plenty of benefits. I'm just not entirely sure what's the best approach to achieve this end. For one, though, I think that gaining awareness of how exponential trends are interleaving our daily lives seems like a good start.

For a single file, getting the number of text rows is very simple:

Although the name wc comes from "word count", the -l switch changes its mode of operation into counting rows. The flexibility of this little program doesn't end here; for example, it can also accept piped input (as stdin):

as well as multiple files:

or even wildcards, such as wc -l *.file. With these we could rather easily count the number of lines of code in our project:

Unfortunately, the exact interpretation of **/* wildcard seems to vary between shells. In zsh it works as shown above, but in bash I had it omit files from current directory. While it might make some sense here (as it would give a total without setup script and tests), I'm sure it won't be the case all projects.

And so we need something smarter.

A certain way to list all files matching given property (e.g. name) in current and (recursively) child directories is to use the find command:

Can we feed such a list into command taking multiple files, like wc? As it turns out, it is perfectly possible, and the utility that allows to do this is called xargs. Numerous are its features, of course, but the simplest usage is totally option-less; we only need to supply the target command and pipe our list to xargs' standard input:

This is how we get all the lines printed, so counting them is trivial now:

The real power of this technique lies in the fact that we can inject additional modifiers, or filters, at any stage. We can, for instance, eliminate some files we are not interested in by using grep -v:

Likewise, we can get rid of comment lines if we push the output of cat through another regex-based filter:

Obviously, both greps can be present at once:

Complexity of this command likely exceeds many typical use cases for find or grep, although seasoned shell hackers may think otherwise. In any case, I think the power of this technique is very evident, and not only for counting lines.

As usual, I took part in the competition along with Adam Sawicki "Reg" and Krzystof Kluczek "Krzysiek K.". Topic for this year revolved around the idea of "escape" or "survival" kind of game, so we designed an old school, pixel-artsy scroller where you play as a prisoner trying to escape detention by running and avoiding numerous obstacles. We coded intensely and passionately, and in the end it paid off really well because we actually managed to snatch the first place! Woohoo!

A whopping amount of 15 teams took part in this year's Compo, so it might take some time before all the submissions are available online. Meanwhile, I'm mirroring our game here. Please note that it uses DirectX 9 (incl. some shaders), so for best results you should have a non-ancient GPU and Windows OS. (It might work under Wine; we haven't tested it).
Note: There is a file embedded within this post, please visit this post to download the file.

Obtaining a temporary file or even directory shouldn't be a terribly complicated thing - and indeed, it's very easy in case of Python. We have a standard tempfile module here and it serves our needs pretty well in this regard. For one, it has the mkdtemp function which creates a temporary directory and returns path to it:

That's what it does. What it doesn't do is e.g ensuring a proper cleanup once the directory is not needed anymore. This is especially important on Windows where the equivalent of /tmp is not wiped out at boot time.
We also wanted our fresh temp directory to be set as the program's working one (PWD), and obviously this is also something we need to manually take care of. To combine those two needs, I think the best solution is to employ a context manager.

Context manager is basically a fancy name for an object that the with statement can be applied upon. You may recall that some time ago I wrote about interesting use cases for the with construct. This one could also qualify as such, but the principles are very typical. It's about introducing a scope where some resource (here: a temporary directory) remains accessible as long as we're inside it. Once we leave the with block, it is cleaned up - just like file handles, network sockets, concurrent locks and plenty of other similar objects.

But while semantics are pretty clear, there are of course several ways to do this syntactically. I took this opportunity to try out the supposedly simplest one which I learned recently on local Python community meet-up: the contextlib library. It includes the contextmanager decorator: a simple and clever way to write with-enabled objects as simple functions. It is based on particular usage of yield statement which makes it very interesting even by itself.

So without further ado, let's look at the final solution I wanted to present:

As we can see, yield divides this function into two parts: setup and cleanup. Setup will be executed when we enter the with block, while cleanup will run when we're about to exit it. By the way, this scheme of multiple entry and exit points in one function is typically referred to as coroutine, and it allows for several very intriguing techniques of smart computation.

Usage of temp_directory function is pretty obvious, I'd say. Here's a simplified excerpt of the Git-based deployment script that I used it in:

Note how the meaning of '.' (current directory) shifts depending on whether we're inside or outside the with block. Users of Fabric (Python- and SSH-based remote administration tool) will find this very similar to its cd context manager. The main difference is of course that directory we're cd-ing to is not a predetermined one, and that it will disappear once we're done with it.

Why's this?

It is worth noting why JS has the this keyword at all. Normally, we would expect it only in those languages which also have the corresponding class keyword. That's what C++, Java and C# have taught us: that this represents the current object of a class when used inside one of its methods. It only makes sense, then, to use this keyword in a class scope, denoted by the class keyword - both of which JavaScript doesn't seem to have. So, why's this even there?

The most likely reason is that JavaScript actually has something that resembles traditional classes - but it does so very poorly. And like pretty much everything in JS, it is written as a function:

Here, the Greeting is technically a function and is defined as one, but semantically it works more like constructor for the Greeting "class". As for this keyword, it refers to the object being created by such a constructor when invoked by new statement - another familiar construct, by the way. Additionally, this also appears inside greet method and does its expected job, allowing access to the text member of an object that the method was called upon.

So it would seem that everything with this keyword is actually fine and rather unsurprising. Have we maybe overlooked something here, looking only at half of the picture?...

Well yes, very much so. And not even a half but more like a quarter, with the remaining three parts being significantly less pretty - to say it mildly.

Four meanings of this

It might not have been immediately visible, but in the previous example the this keyword has been used in two different meanings. They just happen to blur into single semantic, thanks to our associations with other object-oriented languages. Incidentally, those associations were probably the main reason behind adding the whole this/new mechanism to JavaScript. Unfortunately, it doesn't look quite as appealing when viewed in the context of language as a whole. Because at this wider perspective, this sucks big time.

For starters, here are the possible referents of this, i.e. things it can point to depending on where and how the keyword is used:

• objects constructed using the new keyword, as seen in the Greeting function above
• objects we're calling methods on, as seen in the greet function above
• the global object where all the global variables reside; for browsers, this would be the window object
• any object at all

What you might have noticed is the massive drop of sanity level between the second and third option. There is absolutely no mistake here: this.x = 1; can mean the same as window.x = 1; and create a global variable, happily cluttering our global namespace. In fact, this is the default behavior of this when used inside a function. It's the first two, non-crazy variants that require a special call syntax, while the following "just works":

Chances are, it doesn't work the way we would expect it to work.

It's all in the call

Time for a small brain teaser. Could you compare the Greeting and foo functions, and find some differences between them? Preferably, it should be a difference which is unrelated to naming and would persist even if we compiled minified both functions... Can you find at least one?

You could try for a while, but it would ultimately prove futile: there are none. Nothing is special about the so-called constructor of our Greeting "class": it is an ordinary JavaScript function. While it seems to exhibit some class-like behavior, it is only due to our usage of new. If we called it directly, we would end up with the exact same behavior as with foo example above: this would bind to window and text would end as a global variable.

Not only this is surprising, confusing and error-prone, but it also generalizes to every case where this is used inside a function! The gruesome conclusion is that:

The meaning of this depends on how the function was called, regardless of how it was defined.

To realize how unpleasant consequences this may have, consider a simple object that has a "method":

Let's say that we want counter.inc to be called in response to some external event. In asynchronous, callback- and event-based environments - where almost all of the JavaScript code operates - this would be an extremely common occurrence. Setting aside any specific details, we can safely assume that our method will at some point end up in a variable. It will be deep inside the guts of a framework or library of choice, but in the end, it will be essentially equivalent to this line:

When the event in question actually happens, callback is of course invoked:

And it is invoked like a normal function (rather than a method), so this acquires meaning specific to that invocation. Which means the global (window) object, not the counter object as we would expect... Yuck!

Fortunately, this can be worked around in a relatively straightforward way: by capturing counter object in a closure, therefore ensuring that it ends up as this inside its inc method:

Just think, though: what's the chance that someone notices the "superfluous" function later on and decides to "refactor" it out?... If you ever use this trick in practice, make sure you add some adequate comment.

this and that

What about the fourth point, stating that this can actually refer to anything at all? Again, it is only a matter of how the function gets called - and it so happens that there are some very special ways of calling a function. Those are the apply and call methods, where one can completely specify not only the argument list, but also the referent of this inside the function:

Don't be mistaken: this is a very cool feature, especially when used appropriately (and judiciously) in some well-known libraries:

Problems arise when we already have this in our outer function, because it will be inaccessible ("overwritten") in the inner one. As a remedy, it is suggested to capture the outer this in a local variable that will come as part of inner function's closure:

Conventionally the variable is often called that, although self is also popular for somewhat obvious reasons :)

this doesn't look pretty

As we can see, this keyword in JavaScript is not quite as simple as in many other languages. Care must be taken when calling any function that uses it internally; otherwise we might end up with totally unintended results.

One of those, in my not-so-humble opinion, is the idea of issue tracking. I suppose vast majority of readers is intimately familiar with it but let's put it into words anyway, for the sake of clarity and explicitness. The concept revolves around a system which allows its users to create tickets describing various issues pertaining to some particular project, or part of it, or process, or any similar endeavor. Those tickets necessarily consist of title and content, very much like emails. Usually though, they also have few additional fields that are more meta, and describe the ticket itself. Typical examples include:

• A type or category for ticket. In software project, the distinction between bug and feature request is of utmost importance, although several more kinds of tickets (e.g. documentation-related tasks) are pretty well known too.
• Status of a ticket, indicating what's currently happening with the issue in question. Did it arise only recently, or some work on it has been already done? Maybe it was successfully resolved, or maybe there are more information needed to push the case further... Either way, that's what ticket status should tell us.
• Person currently responsible for issue - the one it has been assigned to. For new issues, this field usually points at project manager, who is subsequently dividing work among members of their team.

Lastly, every ticket allows for discussion in a forum-like manner, and for adding comments to any metadata changes we make.

That's it, in a nutshell. It doesn't seem very complicated and frankly, it may not sound very innovative either. Why do I think such a concept is worthy of attention in broader context, then?...

Because, pardon the pun, it just works.

Issue trackers solve a specific problem (managing cases and incidents related to software project) but the general premise behind them is much more general. They answer a practical question: what should I do if I spot a problem? Not every single little problem, of course, but a defect in a complex system: no matter how small a problem and no matter what system we're talking about, by the way.

Imagine you're driving a straight road going through some secluded area and you notice a speed limit sign. It tells you to slow down significantly for no apparent reason: there is nothing ahead (or around the road) that seems to require turtling. The sign feels out of place and is just confusing, but there is nothing you can do about it. You just leave it behind and maybe slow down slightly, just in case. Before too long, you forget about the whole thing.

Result? The sign will probably stay there for years, precisely because no one really knows what to do once they encounter it.

What could be done, though?... Well, how about pulling over, grabbing your phone, taking a picture of misplaced sign and using a mobile app to create a ticket about the whole issue? "road 42 useless sign" is certainly enough to adequately describe it, along with the photo and GPS coordinates. The whole process takes like two minutes, requires hardly any effort and only one person needs to do it for the issue to not go unnoticed.

On the other side, someone from the transport department (or similar institution) gets notified and glances at your ticket. It's hardly an emergency so it's given low priority and generous deadline but it's nevertheless assigned to appropriate person who should see to it being resolved. And it better is, for her job/salary/bonus/etc. depends on successfully dealing with cases such as these! And besides, if you're really interested, you can follow what's happening to your ticket, up until it is eventually resolved and closed.

A pleasant dream, isn't it? ;) To implement it in reality, there would obviously be numerous obstacles - with technical difficulties of constructing and managing a huge system being the smallest of them. For a massive crowd of people using it, we would certainly need to employ some clever moderation techniques - at least at the level of StackExchange communities. But what I foresee as the biggest challenge is to intertwine this novelty with existing bureaucracy. Starting small and showing tangible results in micro scale seems to be a mandatory first step.

So, are there any brave entrepreneurs who dare to tackle the challenge I hereby lay forth? :) Because, you know, back when the word 'disruptive' still had a meaning, this idea would probably deserve being called like that. But if you prefer the modern wording, then 'frighteningly ambitious' is equally good. In any case, I wouldn't complain to see it happen...