As programmers we rarely have a luxury to write a project from scratch. Usually we have to retrofit existing projects with all cool things we need. If a new component, or a library we want to use introduces new concepts that bleed outside its boundary, we have a “culture clash”, when old code is unaware about new concepts have to work with it anyhow. Sometimes the clash is so bad that we have to give up on using shiny new things, or have to significantly rework their code, which requires time and efforts we cannot afford.

This situation calls for elaborate translation facilities between “old” and “new” worlds, or our new component/library should be aware of the problem, and provide necessary hooks, and utilities to adapt for existing projects.

heya-unify was designed from the ground up to support such paradigm. We already saw in heya-unify: custom unification how to unify our custom objects, or modify a unification of existing objects. This post deals with results of unification by cleaning them from unification variables, so they can be used in parts, which are not aware of how those results were produced.

Incomplete objects allow us to concentrate on important properties of JavaScript objects ignoring the rest: we don’t need to specify every single property, and we can deal with cyclical graphs.

Incomplete arrays is a complimentary feature to inspect only the first few array items.

Both features are very useful for patterns, and heya-unify provides rich facilities to automate creating incomplete objects: they can be marked up explicitly on per-instance basis, recursively with a special utility, and we can specify how to deal with objects by default during unification.

Custom unification in heya-unify allows us to deal with our specific objects in JavaScript, create unification helpers, and even custom logical conditions. It is there to bridge unification with our existing projects.

Unification for JS introduced heya-unify — a practical mini library to leverage unification in JavaScript. This post explains when it makes sense to use unification, and gives practical examples of how to use it.

Unification is a very interesting programming tool. Originated from logical programming (its the foundation of Prolog) and used in functional programming (e.g., Haskell) it helps to compare objects for equality, identify known patterns, and reassemble results differently.

Wikipedia gives a somewhat complex definition of unification, but many people see it as an extended equivalence comparison, a pattern matching tool, and some even find parallels with XPath queries, CSS, and even jQuery, all operating on regular objects. See it for yourself.

Time and again working on big web applications we customize files based on user’s platform, and their preferences. We can send different files to legacy browsers, different CSS and JS to mobile browsers depending on their form factor, different images to accomodate bandwidth requirements, and so on.

This post was prompted by my desire to serve sprites produced by grunt-tight-sprite as WebP images to WebP-capable browsers falling back to “classic” image formats for the rest using nginx. While it is hardly a new topic, I was not satisfied with existing solutions, which all used if and rewrite, instead of simpler methods.

Obviously the core solution can be used to serve almost any file conditionally, not only images, but all examples will be about WebP.

ClubAjax invited me to speak about technologies behind Heya, specifically about code generative solutions behind heya-pipe. Pipes are built on a firm foundation of functional programming (FP), and it allows us to use a wide range of technologies to optimize their performance including generating code on the fly (code generation AKA CG).

As soon as we are talking about CG, the first question to ask is: “How to debug such code?”. Heya provides answers for that too. But no spoilers.

Direct link: Practical pairing of generative programming with functional programming.

After 8 years I decided to switch to Octopress. Being a server-less framework, it allows my web site to scale better, and, the most important thing for me, reduces expences on administring an active server (less active components to update). An additional bonus is that it reduces requirements for a web site host, which allows me to be more flexible when selecting a hosting company.

All old links are supposed to work as they used to be redirecting to new URLs. Please let me know, if something doesn’t work for you.

I spoke at ClubAjax about optimization of modern web applications. Usually I speak about theoretical matters, but this time I decided to go practical. This is a huge topic and it was blogged/debated/presented to death, including my Improving performance…. Yet I decided to add to it after realizing that many things have changed in last years, including how we build web applications. I concentrated on technical aspects completely bypassing all other areas (e.g., a psychological angle).

Fair warning: these slides were my talking points. Feel free to ask me, if you found some slides lacking or even puzzling, or can improve on mentioned techniques.

Direct link: Optimization of modern web applications.

Once I wrote a blog post On JavaScript, EDP, and 0ms timeouts, which discussed a "smart" trend to pepper code with timeouts of … 0ms: setTimeout(f, 0). Authors of those "programming pearls" genuinely believed that this code reschedules a function call to the next available time slice after the code that set the timer was executed without introduction of a delay (after all it is 0ms!). In reality a typical delay was 10-20ms. With new generation of browsers it starts with 4ms and jumps to 1000ms for non-current/hidden tabs.