Anton

Crossrider Extensions shutting down

2016-09-26T20:28:00.002+03:00

Right, as we observed back in January, Crossrider has moved away from its extensions platform, and now (the 26th of September, 2016) I received the following termination notice from them:

Dear Partners,

All good things must come to an end eventually and, regretfully, so does the Crossrider Extensions Development Platform. After several years of collaborating with you, we have decided to terminate the service.

Please be advised that termination of the service is effective immediately upon publication or otherwise receipt of this notice. For your ease, Crossrider Extensions Development Platform will remain available for another 30 days from 27.09.2016 for you to download your project code / source code / extensions, following which your data will be lost.

See below an instruction note on how to download the project code from our server for your easy reference; but kindly note that Crossrider is not able to provide further assistance. We would like to thank you for all your support and trust throughout the years and hope we can have the opportunity to collaborate again in the future. Best, Crossrider Team

So you can still download your source code in the remaining 30 days, and with careful review you can try to adapt it to creating your own native extensions for your preferred browsers.

I had good results moving to WebExtensions for Firefox and Chrome, some concepts are different from Crossrider's API, but still recognizable. I have no recent experience with Safari or Edge, so can't recommend much. Feel free to add your comments.

I'll say it again — I really enjoyed working with Safari's support team, so I wish those guys all the best, they'll do well in any company. It was a good time working with Crossrider, but I am glad that the browsers are getting their stuff together in offering easier development routes.

Reading Digest 06, or What does Leo Tolstoy have to do with it?

2016-01-21T22:54:00.000+02:00

Hello there, it's been a while, here's what interested me recently. Learning is fun!… and it will be even more fun to revisit these, say, a year from now and verify that I don't remember a thing :)

Binary in Javascript—for me this firmly falls into the category “I doubt I'll ever need to use it, yet it is still very cool”. Using bitwise operators in JavaScript to pack large collections of small data.

Write What You Know (Now)—resonates well with my reasons for writing to this blog (as rare as it happens), to leave breadcrumbs of my own experience, and also to possibly help others walking on a similar path:

…“But nobody will read it,” you say. That may be true. But the opposite could also happen.

ContentEditable — The Good, the Bad and the Ugly—alright, how did I missed this? There is a browser-supported (with LOTS of small print, but hey) method for inline editing of HTML contents. Looks like it existed for years, and slowly improving. Something to keep an eye on.

An Intuitive Guide To Exponential Functions & e—as a math-head, I blush to admit my ignorance about e. I knew it pops up in formulas often, and it's value is “2.7 then Leo Tolstoy's birth year twice” (I kid you not, 2.718281828…). Incidentally, that's the sole reason I know Mr.Tolstoy's year of birth. This article explains the meaning of e, and even calculates its value for us. Enlightening!

How to Stay Focused When You Get Bored Working Toward Your Goals—here's one to motivate all of us normal people who sometimes get bored, but still understand that any worthwhile goal takes some of that “while” to get some of that “worth”:

…He was saying that really successful people feel the same boredom and the same lack of motivation that everyone else feels. They don’t have some magic pill that makes them feel ready and inspired every day. But the difference is that the people who stick with their goals don’t let their emotions determine their actions. Top performers still find a way to show up, to work through the boredom, and to embrace the daily practice that is required to achieve their goals.

Five things I’ve learned at Failbetter: Producer Lottie Bevan—good brief humane insights, where I especially second things 4 (People > processes) and 5 (sometimes it is OK not to plan your future). Of course I'd agree with a fellow intellectual omnivore (what a term!).

Speaking of terms, Bikeshedding!

“…A committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively.”

Been there, done that.

Crossrider no longer recommended for cross-browser extensions, sadly

2016-01-12T21:21:00.000+02:00

Update (2016-09-26): 8 months later the Crossrider Extension Platform is shutting down.

Some time ago, I shared about developing cross-browser extensions using JavaScript with Crossrider framework, and even investigated unit testing these extensions. These articles are quite popular, so I ought to provide an update on where Crossrider stands.

It isn't doing very well, unfortunately.

I still think it is a solid framework with rich API. It is clear the team spent countless hours ironing out the quirks of every supported browser, and presented us with a unified development environment. I still applaud Crossrider's support team for their responsiveness and helpfulness. Thing is… browsers change, while Crossrider fails to keep up.

Even when I started studying the framework almost two years ago, it seemed to be in a “feature complete” state, with most visible work done by the support team. There was no clear roadmap for future enhancements.

Not much have changed. My best guess is that their development team was dramatically reduced, rerouted to another project, or both. Probably a project with more clear and direct financial gain—selling advertisements for extensions is unlikely to fly unless you work very closely with extension developers, to ensure you have lots of popular and successful extensions to sell ads for. I can't blame them—keeping a good development team afloat (looking at their framework I can say that they are a good team) takes a steady income.

Enough of speculation. Here's what I've seen happen with different browsers in regards to Crossrider.

Firefox

Last March I wrote:

…One significant weakness is that currently it isn't possible to publish Crossrider extensions to Mozilla Addon Directory. which is a huge shame. Extensions fail automatic checks performed on submission, and, having gone through this process myself, I see that the complaints aren't about my code — they are about the code provided as part of Crossrider framework, and thus out of our control. Crossrider team is aware of this, yet it is hard to say whether any progress is being worked on in this regard.

No progress here. AMO (addons.mozilla.org) still does not allow uploading Crossrider extensions. I gather from several support threads that Mozilla's validation algorithms take issue with the way Crossrider wrapper is built. Changing it would require full rework, so they tried to “talk” to Mozilla, probably failing to impress them. Too bad.

That's not all, though.

In order to increase addon security for end users, Mozilla is introducing a signing process. In Firefox vv.42 and 43 it was just a warning, while v.44, slated for January 26th, 2016, will simply disallow all unsigned extensions. This may be somewhat postponed, yet looks inevitable.

Crossrider extensions fail the signing process, even if you sign it as an “unlisted” addon, which skips most checks required for AMO. You can check the relevant support thread. Response from the team is that they cannot do anything about it. Sigh.

Thus for Firefox I recommend writing a native extension instead of using Crossrider.

This is especially valid now that Mozilla started active implementation of WebExtensions API, which is planned to be compatible with Chrome's extension API. It is not fully implemented yet, but working with Firefox Developer Edition / Nightly versions I can confirm that it has enough features in place to allow migrating from Crossrider, at least for our extension.

WebExtension support is planned for Firefox 45, expected around end of March 2016. Great news if you'd like to start developing Firefox extensions—your code will also work on Chrome (with minor tweaks)

Of course, Mozilla also announced plans to phase out their old extension API, which caused much weeping and gnashing of teeth in the community. Let's hope this doesn't trigger such a decline in the browser's popularity that a year from now Firefox won't matter anymore, WebExtensions or not.

It is a nice browser, especially from development point of view—still the best to develop, test and debug extensions on and for.

Chrome

Not all is well in the state of Google, either. For Crossrider, that is.

It isn't bad yet, the extensions are fully supported and work well, but Google constantly “enhances” extension security and validation, so at one point last autumn their new algorithm axed all of Crossrider extensions.

Ouch. You can almost hear the cries for mercy in the support thread.

Luckily, contacting Google support actually helped (I was amazed), they reinstated the extensions. Yet this is a sign that something in the Crossrider wrapper doesn't sit well with Google's logic either. It wouldn't worry me if the Crossrider development team was actively (and visibly) doing something about it, but, as it stands, the situation can only get worse as Chrome moves on and Crossrider doesn't.

I admit, I am pessimistic here. One [solved] problem is not the end of the world. But I am pessimistic in a practical way, since we have a solution. If you use WebExtensions API (Chrome's link this time), then you can support two browsers—Chrome and Firefox,—all with one codebase.

So for Chrome, while there isn't much urgency, I recommend to plan your migration to native API, while keeping one eye on Mozilla's progress.

Safari

This browser is… limited. Looks like the only reason people use it is because “it came with the OS” (much like IE). It is not a healthy situation for any software, and it shows. I can only imagine the lengths the Crossrider development team went to support it, with some of framework's features still marked as “absent on Safari”.

Yet, surprisingly, Apple's browser still lives most peacefully with Crossrider-based extensions. Perhaps this is the blessing of stagnation—it doesn't change much (even with new extension requirements that came with El Capitan), so Crossrider continues to work with it like nothing ever happened.

You need to be aware of possible issues with publishing to the Apple Extension Directory, yet those are usually solved fairly quickly with aid of Crossrider support team.

So, hey, Crossider is still good for Safari!… I wonder if anyone cares, though.

Internet Explorer

Quote from last March:

Theoretically, the extension should work, and for simpler extensions it should be OK to test and claim IE support. In our case, though, it is an uphill battle to try to make it work. Since so few people use it, we decided to leave working out the “IE wrinkles” as lower priority, and then it turned out that the Internet Explorer extension runs in some limited JS context, that even some simplest JavaScript functions fail to run (e.g. .indexOf, .forEach etc). The error reporting is almost absent, too, so even debugging these issues means placing tons of console.log statements around the code, trying to guess where it fails now. On top of this, updating an extension once you change something in the code doesn't always work, sometimes requiring going to Control Panel / Add & Remove Programs, and even that is flaky.

And that's all I can say. We simply didn't claim IE support after those initial tests, as it would be lots of pain for our customers and for our support, so I can't tell you one way or the other: whether the situation has improved or (gasp!) got worse.

Edge is not supported, and no current plans to implement it. Not surprised.

Conclusion

Software development is like that. We produce perishable high-maintenance goods.

That cute Tetris clone you wrote in Turbo Pascal 6.0 for Windows 3.11? If you didn't stay on top of things, it probably won't run easily today. The site you wrote in Notepad in 1995, making your first steps in HTML? Likely beyond repair, with GeoCities dead, domain name unpaid for decades, and even if it worked—it would look bad on today's browsers, since <blink> is no longer supported.

Crossrider is a nice framework, and a pleasant team to interact with, so I am thankful for all their help. They saved me tens and hundreds of hours to support three browsers. If they manage a comeback—I'll be happy for them! Yet currently, for technical, financial, political or personal reasons, the framework is gradually sliding into history, and it is time to start looking for alternative solutions, so that we can keep our tasks—done, customers—happy, and children—fed.

A simple Telegram bot with Node.js

2016-01-04T18:59:00.000+02:00

Recently I found a simple real-life task to allow me to experiment with Node.js (I've been peering at it and the surrounding full-stack JavaScript tools). Basically, I wrote a Telegram bot, which periodically posts links to Instagram photos with a specific hashtag.

This was a learning experience for me, so a) I can't claim this is the best approach, and b) I'd appreciate constructive feedback.

The problem

My friends from “Alpha and Omega” Christian Youth Centre started using Telegram messenger (it is nice, by the way, as messengers go, clean and tidy) for their conversations. Also, there is a hashtag in Instagram (#AlphaTopic) which is used by the same group of people for weekly picture contests.

So, a friend suggested (oh well, not my idea), that, since Telegram boasts a simple Bot API, we could implement a mechanism to post hash-tagged Instagram photos into the Telegram chat. This would increase visibility of the ongoing contests, plus could serve as a conversation starter on quieter days.

Challenge accepted!

Solution approach

A telegram bot is a bit of server-side code, which I need to host myself, and which communicates with the API (Application Programming Interface) via simple HTTP calls. In order to be active in a given chat, it needs to be added manually by chat's patrons. Then the bot can respond to commands directed at it (if you implement this functionality) and post messages.

There are two ways to trigger a Telegram bot, as you can check in the Telegrams Bot API docs.

One is via webhooks. These are URLs on the bot's side, which Telegram will call once the bot receives a command from the chat where it is registered. Not a suitable method for me, since I want the bot to periodically post Instagram images, regardless of whether it was asked directly or not.

The second method is for the bot to run by itself, for example on a Cron task, and perform whatever actions it needs. There is a complication that we need to know which chats the bot is registered in, this can be achieved by asking Telegram API whether there are any updates in the chats that it is added to, via a getUpdates call. This returns a list of recently active chats, and then you can post whatever you need to them.

Then it is just a matter of coding a request to Instagram to get media by a hashtag, check which ones haven't been posted yet, and post them to the chat. Easy.

Tools

I tried to use free tools and services, and generally minimize bot's footprint.

For hosting I chose Heroku: it supports Node.js (and lots of other addons, if needed later), and allows running a simple free web-server if it is active less than 6 hours per day. This is another reason I don't want my bot to be triggered by someone's commands—it runs when it needs to, and sleeps otherwise.

Heroku has several Cron addons, yet I don't want to overload it for now, so employed a separate free service, SetCronJob, which allows 50 executions per day. Way more than enough, and for several months it has served me reliably.

On Node.js side I only use built-in modules: HTTPS for communication, QueryString to deal with POST parameters, and Process to get environment variables for server-specific configuration.

It turned out possible to make the bot stateless, so no DB-like storage is required.

Source code

You can check the code on GitHub: https://github.com/npc/ant-lab

I may use it for other toolbelt-type tasks, hence the naming. For now, if you check index.js, you'll see it performs a single meaningful task—if called on a certain URL (configured as “bot_invocation_path” in config.js, it executes method telegram.runInstagramBot() from lib/telegram.js:

app.get('/' + config.bot_invocation_path, function(request, response) {
  console.log('\n\n--=== Telegram Instagram Bot triggered at ' 
              + new Date().toISOString() + ' ===--');
  telegram.runInstagramBot();
  response.render('pages/trigger'); // TODO: Render something useful
});

The response is needed to tell the Cron service that everything is OK (200), it doesn't do anything else for now (as you can tell from my TODO comment). Otherwise Cron will notify me.

Moving to lib/telegram.js you'll see that runInstagramBot() makes a call to get updates chats—telegramGetUpdatedChats(), which returns an Array of chat IDs in the callback.

Then, if chat count is above zero, we retrieve Instagram media via instagramGet() function, and post all recent media (posted less than config.instagram.max_time_difference milliseconds ago), and post process.env.INSTAGRAM_MAX_MEDIA_COUNT (default 5) of these images as links to each Telegram chat, by calling our telegramPost() function.

If no suitable media was found, the bot posts a random quip to the chat using getNotFoundMessage() function (currently in Russian, I guess it would be nice to move these to config.js as well). The main point of these is for me to see that the bot is doing something even if there is nothing to post.

All interactions with Telegram and Instagram are done via GET and POST calls to their open APIs, you can see which ones by following the code. Ping me if you think more explanations are in order.

You'll note that there are debug mode statements, which ignore the list of Telegram chats, and make all posting to a specified chat ID—for testing I started a private chat with the bot (yes, it is that kind of bleak future where I talk to bots privately), and configured this chat ID for debug mode:

if(config.bot_debug_mode)
 chatIDs = [ config.telegram.debug_chat ]; // Private chat for testing

And that's mostly it!

Configuration

For my purposes I decided that the bot should run twice a day, to post updates in the mornings and evenings. So I've set the Cron to run it every 12 hours, and set config.instagram.max_time_difference to 12*60*60*1000 ms. Thus the bot only posts images which were posted since it was last run.

All other meaningful configuration, including the URL that gets called (to sidestep potential DoS attacks, since that would simply stop my free Heroku host from working) is set in config.js.

You'll get Telegram API token when creating you bot on their site (very easy, just talk to the BotFather), and I got my Instagram API token by looking it up in their API console.

I found it very convenient to use process.env.* (Process module from Node.js) to retrieve configuration from the environment. This allows me to share my source code, without risk to sensitive data, such as Telegram and Instagram API tokens, as these values are set on the server side (this is how Heroku does it).

Stateless Caveat

One last note is that for Telegram's getUpdates call to return anything, there should be recent messages in each chat. Otherwise the bot won't know the chat exists. This is a side effect of the bot's statelessness.

This is not ideal—first of all, it means the bot should be allowed to see chat messages (see Privacy mode), or it will not get any updates at all. If there are no active discussions, Telegram won't report anything older than 3 days, so the bot will quietly “forget” about the chat. For my purposes this is perfectly fine, yet if you develop your own bot you may need to address this. This probably will require some storage bot-side, to remember which chats it was ever added to, and watch the response to Telegram's sendMessage call, to see whether all those chats are still valid.

Conclusion

This was a great exercise for me: the actual coding was fairly simple, yet I learnt a lot about setting up the tools and configuring their interaction. Plus, there is nothing like the pleasure of seeing your little bot, you baby, chirping in the chat twice a day, sharing links to photos that my friends posted :)

Let me know if you have any questions, or if you notice any glaring mistakes in my source code.

Reading Digest 05

2015-05-07T21:19:00.000+03:00

Sharing what impressed, inspired and made me think this week, even if to thank the authors for taking the time for putting their thoughts and experiences together.

Why Comments Are Stupid, a Real Example—OK, OK, the example is not very “real”, yet a good demonstration of ways to improve code readability. I usually err on the side of “too many comments”, especially when analyzing someone else's code. So it is a good reminder for me to be thoughtful about them—and perhaps improve the code itself instead. Comments are still good, if used well. If you never comment your code—ignore the article. I hate you :)

HTML vs Body in CSS—hmm, dealing with these seems more like “This is how it's done!” than actually making sense. But oh well, I guess we just need to know and remember. A nice comment about relative font sizes, though, I do need to use those rem's more.

A/A Testing: How I increased conversions 300% by doing absolutely nothing—which sounds like an April Fool's joke (a well written one!), until you read into it. Takeaway—don't waste time on trendy techniques unless you understand what you're doing, and the statistics could mislead, especially without a large user-base (which is most of us, to be honest).

Top Drupal 7 Modules: Final Edition—lately I've been leaning more towards Wordpress for “standard” sites, since there's a lot to be said about simple tools for simple jobs (“don't use a cannon to shoot small birds”). Yet I may still go back to the powerful flexibility of Drupal if a problem requires it. Then I'll probably use a lot of the modules listed here. Nice to see some good old friends mentioned—we've been through a lot together, eh?

Brands redesigned by hand, an experiment in lettering—these look great! I mean, that's really bad. They're just… wrong! This is a good demonstration why thoughtful font usage matters—even when something is beautiful, it may still be completely inappropriate for your brand.

And, finally, the golden ratio is a lie. I knew it!

Double Trouble: Two risky features come together for a conflict in JavaScript

2015-05-01T23:46:00.000+03:00

On the value of being careful with modifying global scope. There is a code conflict I encountered recently when combining somebody else's JavaScript code with a 3rd party library. It didn't go well, and took time code-digging / stepping-through / debugging / tracing, until finally the cause became apparent.

JavaScript in general is very flexible (beyond loose), which is reason to both love it (“With great power…”) and hate it (“…comes great responsibility”). But blaming one's tools isn't helpful when you need to get a job done.

These are the two things that caused the conflict. Both are discouraged, but you won't understand why until you see them together.

Array.prototype.[method]

There is a very powerful ability in JavaScript to modify a prototype (a sample Object template similar to class in OOP languages) by adding new methods:

MyClass.prototype.newMethod = function() {
   // New method for "class" MyClass
}

Then you can call this method on any object of MyClass. Sweet.

Yet what then seems extra-powerful, is the ability to do the same with system classes. And, since (almost) everything is an object in JavaScript, you can add your own methods to String, Date, RegExp. This could really help locally improve readability of your code, since instead of getPresidentNames(getAllNames()) you could call getAllNames().getPresidentNames(), potentially chaining operations instead of matrushka-dolling them.

But modifying system objects like this is discouraged, because the change is global. Your added method will be visible to all of your code (which, in our day and age, 90% is made of code not written by you).

In my case, Array object was expanded with .max() and .min() methods. This sounds useful, but…

Array property iterator

Here's another convenient feature—you can iterate over all of the object's properties:

for(var prop in myObject) {
   console.log("myObject has property " + prop);
}

Very powerful, though potentially dangerous. If you run this in a controlled environment, where every single line of code was written by you, you'll get the list of properties that you've yourself defined. It is a very nice and expected result.

But what if someone redefined the object elsewhere?

Custom objects—not a problem, especially if you use closures.

System objects—not a problem… until somebody decides to add a method. Then you get list of properties and methods, including the newly added one.

For arrays, iterating with for(… in …) goes through the list of existing array indices. If you add methods—it will include them too. E.g. the list of values will be "1", "2", "newMethod".

The painful part (and that makes it hard to detect these kinds of issues) is that even if you make the change inside a closure, you're still modifying a global object, so you'll affect all of your code. Here's a simple Fiddle demonstrating this:

What should we do?

Two options.

None of the above features are really damaging by itself. Your code will work fine if you do either. So, when a conflict happens, you can play the blame game (Don't you expand prototypes! No, don't you iterate over arrays as objects!).

But that's not very productive.

On the other hand—you can understand that both practices are risky, since you don't always have control over all the code. So just avoid these.

For methods on global objects it is probably safer to use functions, if you really need to. They don't look as nice, but they are local to your closure, so—safe.

For iterating over arrays, there are other methods (for(i = 0; i < Array.length; i++), or Array.forEach()), whatever suits you. Or, if you are so adamant on using for(… in Array), then make sure to type-check to exclude functions (at least!).

You'll figure it out :)

Micro-solution: Automatic Value Axes Offset in amCharts

2015-04-21T20:21:00.001+03:00

Working with amCharts library for visualizing various report's data in I-Plan Supply Chart Planning software, I came across a difficulty configuring multiple value axes for our specific case.

amCharts is very flexible, allowing to set several axes, define their position (“left” or “right”), title, colour, min/max values, tick formatting etc. It even allows defining an offset (in pixels) to avoid overlap of axes.

Yet in our case the reports are built by the users, various values assigned to different axes based on units, and can be aligned left or right at will. This means that a constant offset value simply doesn't cut it—if you have report values that are too wide they'll overlap, and if they're narrow—they will leave a gap.

Life is like a box of axes with fixed offsets.
Neither look good.

To test various permutations I created this fiddle based on amChart's own demo. In the demo the value range is known for all axes, so it is simple to hand-pick the required offset. Yet if the values are outside of your control, you could get the picture on the right.

Not nice.

So, with the aid of extremely helpful Martynas Majeris from amCharts support team, I set out to identify actual axis widths after they have been rendered, and automatically update the axes' offsets.

You can jump straight into the code:

// Render chart (your code may vary)
chart.write(sChartID);

var oAxesOffsetPerPosition = {};

// After chart is rendered, find value axes in the SVG
// Using class names from http://www.amcharts.com/tutorials/css-class-names/
chart.valueAxes.forEach(function (oAxis, nAxisIndex) {
    chartElem.find('.value-axis-' + oAxis.id).each(function () {
        // amCharts has three elements per .value-axis-[axisId], find the one with labels
        if ($(this).find('.amcharts-axis-label').length > 0) {
            if (!oAxesOffsetPerPosition.hasOwnProperty(oAxis.position))
                oAxesOffsetPerPosition[oAxis.position] = 0;

            chart.valueAxes[nAxisIndex].offset = oAxesOffsetPerPosition[oAxis.position];

            oAxesOffsetPerPosition[oAxis.position] += $(this)[0].getBBox().width + 20;
         }
    });
});

// Redraw chart with updated .valueAxes data
chart.validateData();

The idea is very simple, though has some finer points:

Identifying the axes: Thankfully, since v3.12 amCharts support including class names into the generated SVG—otherwise it would be near impossible to find the value axes. Make sure to enable these. The next hurdle is that for a given axis ID there are three (!) SVG elements with the corresponding class—this includes the grid lines etc. The element we need is the one that contains “[prefix]-axis-label” elements.
Determine axis width: My go-to function $.outerWidth() doesn't work on SVG elements, so using .getBBox().width instead. Thank you, StackOverflow :)
Accumulate width per axis position: This is straightforward, I created an object with properties for “left” and “right” positions, and increment them by each axis.
Update the chart: After a property of the amCharts' “chart” object is updated, I call .validateData(). Interestingly, calling .validateNow(true, true) causes the chart to visibly jump around—so .validateData() is empirically better.

After all that, our mission is accomplished:

And even weirdo users can get their way now. At least they are not playing with real axes—that could be dangerous:

Take care!

JavaScript Unit Testing in Crossrider Browser Extensions

2015-04-14T21:09:00.002+03:00

Note: Please see my update on Crossrider status (12 Jan 2016).

Here's the approach I found looking for a way to implement unit tests for my JavaScript browser extension (written using Crossrider framework). The method is quite straightforward, yet still required me to do some research and testing. This approach in theory is agnostic of the testing library you use, or at least it should be. I will demonstrate it with both QUnit and Jasmine.

Setup

Let's create a basic browser extension in Crossrider, uploading the necessary library files as resources. Your folder structure may vary (“Show me your file structure and I will tell you who you are” :)), you can see how I decided to do it on the right.

Everything related to unit tests is inside “testing” sub-folder, so it doesn't mix with whatever potential resources will be added for the extension itself.

Files jasmine-tests.js and qunit-tests.js contain the testing code that I wrote—I'll show the contents of these files below.

Note that files extension.js and background.js are required by the extension (as I wrote earlier), these files contain all of the extension logic, and load additional JS resources as necessary.

Triggering Condition

Now, the key issue is that JS unit tests are usually run inside of an HTML harness—it is used to store the HTML markup necessary for the tests (if your JavaScript is presentation-heavy, which usually is the case), and also it is used to output test results.

Yet the extension doesn't run on your given HTML file, it runs in the context of each page open in the browser (speaking of the code inside extension.js file—background.js scope is a different matter, I'll talk about it below).

So here's the simple yet robust method that I've used—to stop the tests from running on every page, I check that there is a very specific string contained in the page address. For example, check that there is “test-crossrider” string at the end of the URL. Then I can trigger unit tests by opening, e.g., http://www.amaslo.com/?test-crossrider in my browser (with the extension installed).

Here's the code I've placed in extension.js:

/*
 *  extension.js
 *  Testing BDD approach with Crossrider Extensions
 */

var bRunTests = true; // Allows disabling tests in production release

appAPI.ready(function($) {
    // Unit Tests
    // Run with e.g. http://www.amaslo.com/?test-crossrider
    if(bRunTests && appAPI.isMatchPages('*test-crossrider')) {
     // QUnit
     //appAPI.resources.includeJS('testing/qunit-tests.js');
     
     // Jasmine
     appAPI.resources.includeJS('testing/jasmine-tests.js');
    }
    
    // This function will be tested
    function funcForTest(sInput) {
     return true;
    }
});

Hopefully it is self-documented enough, yet what happens is if the page address matches, and the tests are enabled—corresponding JS file is included and run.

Simple.

Actual Tests

QUnit tests:

/*
 *   Collection of Unit Tests
 *  Using QUnit
 */

(function() {
 // Testing library
 appAPI.resources.includeCSS('testing/qunit/qunit-1.18.0.css');
 appAPI.resources.includeJS('testing/qunit/qunit-1.18.0.js');
 
 // This will keep the actual page still displayed below the report
 $('body').prepend('<div id="qunit"></div><div id="qunit-fixture"></div>');
 
 QUnit.test('Set of Tests Description', function(assert) {
  var value = 'hello';
  
  assert.equal(value, 'hello', 'Expecting value to be hello');
  assert.ok(funcForTest(value), 'funcForTest() should return true');
 });
}) ();

Which results in the following output on the page:

And for Jasmine (which I frankly prefer—it feels less like robo-talk, yet this is a matter of personal preference—definitely outside of this article's scope):

/*
 *   Collection of Unit Tests
 *  Using Jasmine
 */

(function() {
 // Testing library
 appAPI.resources.includeCSS('testing/jasmine/jasmine.css');
 appAPI.resources.includeJS('testing/jasmine/jasmine.js');
 appAPI.resources.includeJS('testing/jasmine/jasmine-html.js');
 appAPI.resources.includeJS('testing/jasmine/boot.js');
 
 // Clean the document
 $('body').html('');
 
 describe('Set of Tests', function() {
  var value;
  
  beforeEach(function() {
   value = 'hello';
  });
  
  it('works', function() {
   expect(value).toBe('hello');
  });
  
  it('calls functions', function() {
   expect(funcForTest(value)).toBe(true);
  });
 });
}) ();

Yielding:

Sometimes I need to refresh the page a couple of times for Jasmine report to show up. This may be linked with extension loading / running, and doesn't really cause any inconvenience.

Both QUnit and Jasmine tests above are identical setup-wise—include library files, do whatever needs to be done with the actual page (for example just wipe it as I do for Jasmine, or append/prepend necessary markup), which will depend on what your extension does, and running the tests.

You'll notice that all unit tests are inside a closure (i.e. (function() { ... })();), this is basic variable and function scope hygiene. The functions defined in extension.js file (or the files it loads prior to running the tests) will be available in the tests' scope.

And… that's it. Really.

Real-life Tests

Of course, the above tests are extremely primitive. Checking a variable's value, and a function's return value. These only demonstrate how to incorporate unit tests in a browser extension, trigger them and view the report.

In your actual, down to Earth, real-life code you'll need to employ a lot more kung-fu from your library of choice.

For example, since my extension works with Basecamp pages, I need to have corresponding HTML markup to test the JavaScript with. Instead of depending on actual Basecamp page, which will always have changing list of todo's, I've snipped a pre-defined portion of the page and stored it in my Resources under ../testing/3rd-party/bcx.html. Then I can include this markup in the tests page (any page!) before the tests where I need it (using Jasmine):

describe('BCX Todos', function() {
 beforeEach(function() {
  var sHtml = appAPI.resources.get('testing/3rd-party/bcx.html');
  $('<div id="rm-test-bcx"></div>').appendTo('body').html(sHtml);
  // ...

Just don't forget to tear it down in afterEach() call, so that subsequent tests start from the clean slate.

For mimicking API calls you can use things like spyOn([object], [method]).and.callFake([function]), for testing asynchronous logic you'll use the “done()” callback passed into the it() statement, and so on. There's a lot to figure out, but this is part of standard unit code logic.

Testing Background and Popup Scopes

A brief note on background.js and popup.html. These contain extension code that doesn't run on a given page, so testing them could be tricky.

Depending on your situation, may I suggest minimizing the logic actually stored in background.js, and instead move everything to separate resource files (*.js). Then these files can be included and validated in unit tests.

For example, in my extension there is a lot of interaction with Roadmap API, and this is used both from extension.js and background.js. I chose to put all corresponding methods in file rm_api.js, and this file is then included as needed, in extension.js:

appAPI.resources.includeJS('js/rm_api.js');

Or in background.js (since appAPI.resources.includeJS isn't supported there):

$.globalEval(appAPI.resources.get('js/rm_api.js'));

This even avoids code repetition, so win-win. Still, I feel that this approach is not ideal. If you have better ideas—I'd love to hear them.

Regarding popup.html scope—I have no solution for now, sadly. This part of code corresponds to the popup shown on pressing the extension's button in the browser bar, and this functionality is still very limited. Neither appAPI.resources.includeJS nor appAPI.resources.get are supported in this scope, so I see no way to load additional code files into it. I guess this logic will have to be tested manually, until someone comes up with a wonderful solution.

Conclusion (and a free advice)

So, testing your extensions requires an adjustment of mindset, yet it is still possible, and not overly complicated, except for some nuances.

If you allow me to share one advice—think about unit tests before you write your code. Not after. Unless you prefer to learn the hard way. Like I did.

The reason is obvious in hindsight—structure and quality of your code is defined by necessity to call specific functions, test branches of logic, validate responses. Functions, methods, objects will almost naturally start forming into units with clearly divided responsibilities, complex spaghetti code will split into simpler pieces, and obscure solutions will look even less attractive—before you undertake to implement them!

Yes, it will take time. Yet ultimately it is a good thing. Even if tests don't “catch” all of the future issues, having a well-structured source code is a gift for the future “you”.

You'll thank yourself, trust me.

Developing browser extensions using JavaScript with Crossrider framework

2015-03-11T22:29:00.001+02:00

Note: Please see my update on Crossrider status (12 Jan 2016).

As developers (or humans) we need to balance our skills. Sharp focus is valuable, yet tunnel-visioning oneself is not a good idea — there's so much to learn!

While honing my HTML/CSS/JS kung-fu, I was unexpectedly tasked with something new. We needed to create a browser extension to go with Roadmap, a product our company works on.

A completely new area — or so I thought. Some searching showed a simpler path. I could create extensions with my existing experience. Even more — those extensions could share a (more or less) common code base across all mainstream browsers.

I do not intend to do a full comparison of possible frameworks. When we made our choice a year ago one company stood out — Crossrider. After having developed (as I mentioned before), tested, deployed and updated an extension that runs on Chrome, Firefox and Safari, I have to say that Crossrider delivers on the promise of, quoting their front page, “Cross Browser Extensions in Minutes”.

Any serious logic will need more time, sure, but the core can be up and running in minutes. Bonus part — actual development is done using my (currently) favorite JavaScript!

Sold. Here are some notes and observations from this experience.

The Task

Our extension allows accessing Roadmap's data and functions (e.g. task start dates, multiple assignments, estimations, time tracking) when viewing to-do items on integrated 3rd-party sites — Basecamp (New and Classic) to start with, with more to come.

You can see (or use, if you register) the result here: Roadmap Extension in Chrome Web Store. Note that the visual style wasn't developed by me, except for a few personal minor touches it was provided by the skillful Roadmap team. My work was to implement the extension: lock, stock and barrel. I mean — markup, style and logic.

Features & Process

Crossrider is, in layman terms, a wrapper around your JavaScript code with a consistent set of API methods. For each browser the wrapper's implementation could be different, yet it is transparent to our code. The API methods cover most needs for interacting with browser tabs, loaded pages, network requests etc.

This is where it was a discovery process for me: you can't simply bundle all your logic in the same source code, browsers are more nuanced than that. Crossrider introduces three “scopes”, which manage different functional areas of your extension.

Configuration popup
allows setting global values used across tabs.

“Page” scope — JavaScript in this scope gets injected into any page that the browser opens. Here you can have logic to manipulate the DOM — add, remove, modify on-page elements; add user event handlers, inject custom styles, and so on.

Basically, this part of code handles everything that happens on the page. Any page you visit — browser loads it first, then Crossrider injects and runs your code. You can check if this is the page you need (by URL or any other on-page criteria) and do what you need with it.

“Background” scope performs tasks that are outside of the page context, and are instead “closer” to the browser. For example — manipulating browser tabs, monitoring network requests (a very neat and powerful feature!), configuring display of browser button.

“Popup” scope — speaking of browser buttons, pressing on one opens a special HTML page, which is defined in this “popup” scope. This feature is quite limited, yet still needed to provide a visible way to configure your extension.

While these scopes are separated by their nature, Crossrider offers a handy messaging API, which allows sending data-loaded messages between scopes. For example, if background scope of Roadmap extension detects an “update” network request from Basecamp New, then it tells the page scope to check for changes on the page — since it is possible that new todos were added.

All the API is neatly documented, and the actual development happens in Crossrider's online IDE, which is able to connect to already installed extension in the same browser and update it as needed (except for Safari and Internet Explorer — below I'll share my thoughts on browsers). It is possible to add resource files (you may need it to include CSS, HTML or images, and to modularize your JS code), and in general the IDE is on the simple side, but it does its job. There's even integration with JSHint, which warns about most obvious errors before pushing code update to the extension.

The IDE.
It is also possible to configure a “Debug Mode”,
which allows editing files using your editor of choice,
yet I didn't bother with it since the stock IDE works for me.

Roadmap Extension

While figuring everything out took a while, the extension itself is fairly simple.

When a page loads, the extension checks whether it is being run on either of the two Basecamp sites. If yes — it detects the todo items are shown on the page, sends an API request to the Roadmap server, and displays the necessary information.

To start with, it adds neat “R” icons to each todo that RM knows about. Clicking on these opens a popup with detailed todo information, and it is possible to edit this data, start / stop a timer, or log worked time for the task.

The red icon stands for “running timer”.
The todo popup shows minimal required data “at a glance”,
allowing to go directly to detailed page in Roadmap itself.

All of this requires quite a lot of user interaction, a number of API requests to the server etc, but the pleasing outcome is that it works.

Browser Support

Crossrider claims support for desktop versions of Chrome, Firefox, Safari and Internet Explorer. In my experience this is true, but there are nuances to be found with each.

Firefox has been the best one to work with. The extension “just runs”, not compatibility issues or any such thing. The browser itself is democratic, not trying to limit how you install your extension or what you do with it.

Yet one significant weakness is that currently it isn't possible to publish Crossrider extensions to Mozilla Addon Directory. which is a huge shame. Extensions fail automatic checks performed on submission, and, having gone through this process myself, I see that the complaints aren't about my code — they are about the code provided as part of Crossrider framework, and thus out of our control. Crossrider team is aware of this, yet it is hard to say whether any progress is being worked on in this regard.

One more problem that I found with Firefox is an incorrect implementation of Content Security Policy (CSP), which could be problematic in some cases. Briefly — same-URL policy, if set by the site, doesn't allow running browser scripts (which includes bookmarklets or extensions) on pages that don't allow loading scripts from other sources. Thankfully, Basecamp doesn't have this, but we saw this while testing with some other task-tracking systems, and I've shared with Crossrider team the result of my investigation in their GetSatisfaction support system.

Chrome, thus, is our main development and distribution platform. The browser itself causes the least pain, everything is compatible, and submission to Chrome Web Store works wonderfully.

Presentation often means attention.
Google tries hardest to “sell” our extension.
Apple doesn't even bother, and Mozilla doesn't allow us on their store. Sigh.

The only issue that really bothers me is the recent ban on installing extension from sources other than the Web Store. There are “developer” ways to side-step it, so really not an issue, yet I am concerned about the direction that Chrome is heading — from openness to “caring about the users” by limiting them to least possible options.

Which naturally brings us to Safari :) The compatibility of extensions is good when it works, but you'll need to go through several gates of Apple hell before you even get there — running your extension in your browser on your computer requires a special developer certificate, developer tools are quite limited, and there are enough browser quirks to drive a mad person even madder. Best approach I found was to perform all development in Chrome, and then load the result in Safari, testing and debugging the Safari-specific issues.

So while with a bit of sweat and pain, the extension does work on Safari, and we're happily featured in the Safari Extensions Directory.

Did I forget anyone? Ah. Yes…

Internet Explorer. Oh. Theoretically, the extension should work, and for simpler extensions it should be OK to test and claim IE support. In our case, though, it is an uphill battle to try to make it work. Since so few people use it, we decided to leave working out the “IE wrinkles” as lower priority, and then it turned out that the Internet Explorer extension runs in some limited JS context, that even some simplest JavaScript functions fail to run (e.g. .indexOf, .forEach etc). The error reporting is almost absent, too, so even debugging these issues means placing tons of console.log statements around the code, trying to guess where it fails now. On top of this, updating an extension once you change something in the code doesn't always work, sometimes requiring going to Control Panel / Add & Remove Programs, and even that is flaky.

Don't get me wrong, otherwise I think that IE10 is a huge improvement on the previous versions, but its extension support looks to be an afterthought. May be Microsoft's “Spartan” effort will be better — we'll see.

But for now we decided to support Firefox, Chrome and Safari. This covers an overwhelming majority of our user base.

Summary

You can tell that I am pleased with this approach. Some development, especially debugging (especially on some browsers) can be fiddly, yet in general it feels great to know that almost any extension (within reason) can be developed using this approach — given time, perseverance and creativity :)

And this is the main takeaway for me — I am glad that this project came about, and that I didn't try to wriggle out of it because “I don't know how to do it” and “This is outside of my expertise”. Turns out, I can do it, and I hope I'll have more new and interesting projects in the future.

We die the day we stop learning.

One thing that I especially wanted to highlight is Crossrider's wonderful support team. They can't always fix everything, some of the more significant issues were communicated to the development team and are still pending, yet they respond quickly, always pay the maximum attention to your request, are willing to check your code and suggest possible improvements, and left me impressed.

No, I am no affiliated with them in any way. I just enjoyed working with their product and communicating with their staff.

Makes me think that doing your job well and treating your customers with care means so much in our hectic world.

Photo: Emmanuel Huybrechts

UX is about organization

2014-11-13T00:04:00.002+02:00

Google Inbox is certainly not complete.

I miss being able to simply paste images from clipboard. I do want to have more text-formatting options (being especially fond of "quotation" formatting in any kind of software). Speaking of quotes, their detection in replies and forwards is still somewhat wonky in Inbox. And I am scared by a barren "Settings" screen — almost no tweaks or configs. What, Google is becoming like Apple? What a dreadful thought…

But! I love what Google Inbox is, and, even if it makes some things less convenient, I am sticking to it, amazed at the fact that it just "works".

When I first read about it, and then watched not a very helpful demo, I assumed it would be akin to automatic "Spam" folder, just with more folder types. I was afraid it would hide things from me, to make it look simpler.

And it certainly hid some settings, but that's not the point.

I was concerned it would hide some emails. And, while I have a lot coming to my inbox — too much, in fact, — I can't allow a robot to decide what I see and what I don't see. This way I could miss something important, and with my job being a lot about communication — it could be disastrous.

Instead of hiding, it reorganizes.

Actually, it feels like somebody looked into my brain, how I use messages, and for different tasks I have different contexts. It means that at any given time I don't need to see all of the messages in my inbox — I need to drill into groups, like "Work" or "Family", and then I can respond to something immediately, and some other messages I think that I need to look at "later tonight", or "after the meeting on Thursday", and, until then, I don't need to see them anymore.

And I just love the nice touch that messages aren't being read, they're being done. There's palpable satisfaction in pressing that green tick button to say that "I've dealt with it".

So for me the lesson is that good UX approach doesn't mean simply hiding something. It means logically organizing visible data, so that I can quickly reach what I need — while not being distracted by what I don't need at the moment.

I was afraid Inbox would take control out of my hands — yet it actually feels empowering. That's a buzz-word, I know.

PS And yes, I'd like to always see my "Spam" folder too. I don't trust a system to decide what to hide from me.
PPS While you're at it, please allow selecting all messages in "Spam". Thanks ;)

Micro-solution: Preserving input values against all odds (JavaScript)

2014-09-05T01:47:00.000+03:00

The problem: How do you keep the already entered values of HTML inputs if you can't control when the containing document is closed or reopened?

In my case, I am developing a browser extension which requires a configuration popup with some input fields. The user is expected to enter several values into the fields and there is a specific “Save” action, which performs an authentication check etc. I can process button presses etc — yet the popup itself (with all of its HTML, CSS and JavaScript) may be brutally closed by the browser without any prior notifications.

For example, if the user clicks outside of this popup on the browser toolbar — bang! — the popup is dead. Our favourite user then re-opens the popup — and all the data they lovingly typed in — gone.

So I need a simple method to store and repopulate input fields without any additional user action.

Solution

Start with the code:

// Preserve real-time inputs data in case popup is closed externally
// Set input event monitoring
$('input').on('input', function(){
 var popInputs = appAPI.db.get('popup_inputs') || {};
  
 popInputs[$(this).attr('id')] = $(this).val();
 
 // Using Crossrider local DB - could be localStorage
 appAPI.db.set('popup_inputs', popInputs);
});

// Populate the inputs with pre-stored values
// Retrieve the stored values from whatever you saved them to
var storedInputs = appAPI.db.get('popup_inputs');
 
if(storedInputs) {
 Object.keys(storedInputs).forEach(function(prop) {
  if(storedInputs[prop])
   $('#' + prop).val(storedInputs[prop]);
 });
}

The answer consists of two parts.

First, we set watch for “input” events on our input controls (you may want to narrow it down with IDs and classes, I have no such need since I only have three inputs). Surprisingly, this works for every button stroke, and even for pasting text into the fields.

This the current value of the field is then saved in your preferred storage, as part of an “popup_inputs” object, that just contains input values for each element ID. Nice and simple.

Note that I am using this in Crossrider API context (it is a nice framework for creating browser extensions), so for convenience I use their local storage. You may use browsers localStorage instead, or whatever means you prefer.

Second, when our form is rendered, I check for presence of stored input values, and, enumerating the stored object's own properties (Object.keys(your_object) is really handy for this!), populate the inputs with their values — our property names are input IDs, so they're really easy to find now.

And. It. Works.

I'll appreciate any feedback and comments.

Photo by Eunice

Reading digest 04

2014-02-21T14:13:00.002+02:00

Not an easy time to for my country and for me, hard to watch the unfolding events and do something else — yet I am looking forward to a better future (what is man without hope?), and thus continue to learn and grow, as a human being and as a professional too.

Also, I would have many more cool links to share if I held off any longer, don't want to War-and-Peace you, my dearest reader.

Developing

The Current Generation of CSS3 Selectors — a good reminder of some potentially useful things. For example, I completely forgot about first-/last-/nth-of-type, and these could come in handy one day.

45 Useful JavaScript Tips, Tricks and Best Practices — even if you quickly scroll through it, I am quite sure you'll find something you didn't know — or knew and forgot. Nice and concise collection, not too verbose, so easy to quickly scroll through :)

Thinking

Choose the Right Chart Type for your Data — a “thought starter”, now that's a good approach! You may not agree with some of the choices, but — ha, that made you think, didn't it? So the thought-starter did its job! Also, it doesn't have Sankey diagrams, so may be you don't see some other cool — even if not very useful, — chart types? Let me know, I like this topic.

Everything we know Google is working on in 2014 — some stuff is cool, some is mundane, but Google in general is becoming scarier and scarier…

The Psychology of Waiting, Loading Animations, and Facebook — Houston airport extends walking distance to baggage claim by 500% — now that explains a lot of airports' I've seen! Back to the topic — the observation about custom vs stock waiting animation is also a neat one, even if not entirely credible it still makes sense.

The Reciprocity Principle: Give Before You Take in Web Design — love the idea that you need to provide value, show care, before expecting a return from your visitor. This correlates greatly with the Golden Rule of the Bible — “So in everything, do to others what you would have them do to you” (Mattew 7:12a), great to see that our society and good work depends on following such timeless principles

Motivating

Something small, every day — I can testify how much small but steady steps can make, and it is indeed easy to find this time. The hard part is faithfully keeping at it.

Two big announcements (by 37 Signals) — hey, I actually liked their name! The decision about focusing on one product is… controversial. On the one hand, focused teams and products are for the win. On the other hand, there is always the issue of “all eggs in one basket”. Yet post-factum of Basecamp's overwhelmping success this is probably not a concern to them. Still, they had a cool name, shame about that.

10 Things Nobody Told You About Being Creative — «A work of art represents a struggle against limitations!» — love this! Despite a markety title (10 things? Nobody told me? Rrrrright) — good and ponder-some points. Keep scrolling after the final photo, for some more tidbits of advice.

Simple street art personifies inanimate objects — to this I say, always try to find a way to bring joy to what you do, and to people who surround you!

With that in mind — take care.

Propaganda versus Glasnost

2014-02-18T12:14:00.001+02:00

Issues arise in any sizable project. Devil hides in the details, and no plan can take them all into account. If you are managing such a train on fire, do you pretend that everything is great? Or…

Photo by Dmitry Komarovsky

Actually, keeping a good and constructive attitude is a useful technique. “Don't panic!” is an excellent advice for any traveler from A to B, not just interstellar hitchhiker. If you allow the weight of all the issues, problems, risks, known and (worse!) unknown, to “get to you”, it could stop you from doing your job effectively, it could get conveyed to your team, and thus make matters only worse.

Panic doesn't help.

But! Does it mean you need to pretend everything is dandy, when in fact it is not?

I've grown in a culture, first USSR then its heavy legacy, which encourages superficial grand successes, huge monuments, grandiose architecture, massive choreographed events for display of power — surrounded by poverty and broken economics. Showing off at the cost of… well, everything. This year's Sochi games, a “feast in time of plague”, is an obvious illustration of this approach, yet it is happening on many many levels in our culture.

In project management this means working on how you look, instead of on the project. You either postpone acknowledging the issues until it is inevitable (and then find anyone, anything, that you can blame, since even mentioning the fact of issues damages your image of a perfect leader), — or you work on solving the issues, which sometimes means involving the customer, losing your face a little, hearing unkind responses — but pushing forward to get the job done.

The arguments in favour of a superficial approach are simple:

The customer may not trust us in the future if they see that we were struggling.
The competition should not be aware of our weakness, or they'll pounce.
Everyone should think we never err, this will bring us more customers.
(the final blow) Encountering issues is unprofessional.

This is ridiculous. Ensuring that you look great at the cost of the service you are providing is as far from being “professional” as possible. And, when dealing with a pragmatic customer (not one who is also interested in just the surface success), they will understand that issues happen, so if we pretend that we are perfect — we look as simple liars. What a pragmatic customer needs to know if how do you plan to address issues that may happen, how you deal with the issues that did happen, and how you learn on the mistakes you've made.

Gorbachev was arguably forced to accept the “Glasnost” policy, yet this was the only way to start addressing the issues that have been accumulating for decades. Either that, or starve to death, North Korea-style. Many unwisely blame Gorbachev for “creating the issues”, though there is a huge difference between “creating” and “uncovering with the aim to solve”.

If you do spot a customer who only needs a pretense success — run. In our locale this happens in government budget projects (almost guaranteed, in fact). In your case it may differ. Yet working on a project which emphasises form over substance, shining reports for a job poorly done, destroys you. Don't do it.

On the other hand — be diplomatic about risks and issues. Don't scare the customers off, don't panic yourself, but get your act together, face the obstacle — and deal with it. If you fail — learn from the experience, and be better prepared next time.

Or worry about how grand your mausoleum is going to be. Your choice.

Reading Digest 03

2014-02-06T14:30:00.000+02:00

Fun fact — did you know that dialing “03” in USSR would allow you to call an ambulance? Anyway, here are some hand picks from what I read recently.

The Work

The MEAN Stack: MongoDB, ExpressJS, AngularJS, and Node.js — I've been looking at this one from a distance (the distance I typically call a “lack of time”), yet the ability to use JavaScript on all levels looks very attractive, at least for quick prototype building or solo-projects (along with all the Grunts and Gulps it brings along). Gotta try it out myself!

Why are there three default worksheets in MS Excel — don't you love it when the top answer starts with “I was on the Excel team when this was designed…”, history in the making! Quite a good answer, too, teaches you a thing or too about working with legacy software and an existing user base.

jQuery 1.11 and 2.1 Released — for me the interesting part is their work with npm and Bower — more community awareness, I suppose? No library is an island unto itself, yay!

7 Lessons a Writer Learned from Tweeting — while the list itself is a bit too obvious, I totally agree on welcoming limitations in creativity — we're forced to think, choose carefully, edit-edit-edit, and make sure every word counts. Which also brings me to this:

5 Ways to Write a (Very) Good Sentence — nice analysis of building bricks for powerful writing (and them bricks are not just “words”, nay).

The Fun (at work)

Comparative maps create surprising size perspectives — some enlightening information to be sure, yet also makes you think about how far you'd want to go to visualize data. Also — Monaco!

Color Matching Game — a bit too hectic for me, but a nice visual tool-lite to teach a “feel” for color. Make sure to check their other games too, I find that a lot of homegrown designers have no clue as to the basics (kerning, whaa?), and this could be a good start.

The Conclusion

I like observing solutions that people come up with, especially talented people in very limiting situations. So, may we all learn to be as efficient in our work and live, as these firefighting planes that refuel on the go. Can you imagine what it'd be like? If you can — do it! :)

You need to step away from your computer. Probably now.

2014-02-04T14:54:00.004+02:00

If you are a developer, designer, writer, editor, or any sort of person who gets so absorbed in your work that you can start in the morning and then be shocked by the time on your watch when you reluctantly force yourself to stop in the evening — then you probably need someone to remind you to take breaks from your engrossing and exciting creative work (which is a great problem to have, to be honest).

You need this:

Yes, this.
(photo by Andris)

…yet keep forgetting about it. So I'll share a small gem of a tool I am using for this (on Windows) — WorkRave.

It is a small tool that sits in your tray, with a possibility to show a tiny countdown panel, which will remind you to take your prescribed break at preset intervals of time. You can use this time to relax your eyes, stretch your legs, take a walk to get another cup of tea or (even better!) pure water, breathe some fresh air* and smell the roses. Unless you're allergic to those.

* — smokers, as I understand, don't need an external reminder, yet I would hardly call such breaks healthy.

You can configure micro-breaks (to close your eyes for a second, I suppose), rest breaks, and a daily limit. I only use rest breaks, here's the configuration (5 minutes every 45 minutes):

I wouldn't call WorkRave unobtrusive, yet that is the idea, isn't it? When the time comes for your configured rest break — you will get a floating pop up which will allow you to lock the PC, skip the break (sometimes you have to), or postpone the break:

The tool also tracks periods of inactivity (i.e. lack of keyboard / mouse input — it cannot see your deeply thoughtful face when you do nothing), and doesn't ask you to take a break after you just got back from a long meeting away from the desk.

I recommend this to colleagues too — doing the same thing for too long causes issues for productivity, and sometimes stepping away for a couple of minutes may help your brain (i.e. — you) solve a problem that you could not crack open for hours.

You can download it here. It even shows a Linus version, yet I didn't try it.

My main issue, and it has nothing to do with the software, is that I “postpone” way too often — looks like I have a cool job after all! :) Otherwise, it helps me take much needed breaks and thus keep my health, my eyesight and my sanity (however relative) in check.

Designing a logo for Friday.Night youth events

2014-01-29T17:42:00.000+02:00

Recently I designed a logo for Friday.Night events («Пятница. Вечер» — in Russian) held by “Alpha and Omega” Christian Youth Society. I had to do it rather quickly, yet I quite enjoyed both the result and the process (which is precious, won't you agree?). Below I'll share the thinking and the approach I took in this.

The Task

Friday.Night events are weekly meetings for Christian youth to enjoy their time together and be able to invite their unbelieving friends to. Each Friday the meetings could have a different theme and format (e.g. we had an Acoustic Music concert, a “Mafia” game night, a New Years Masquerade and cooking evenings dedicated to sushi, and then pirogi). Yet the common characteristic of these evenings is that they are friendly and fun, with the goal of welcoming new people in for them to get to know Christians better and not be afraid to come to a Sunday gathering.

The Idea

I have to admit that I took a very straightforward route here, yet it may not be obvious on the first glance. The rectangles represent the week (in our culture it starts on Monday), with different random “things to do” on each one, yet two of them stand out. Friday, obviously, is the big one, since it is the focus of the logo. If shows the Sun setting, and stars are starting to shine — because, you know, “night”. The second important day is Sunday, since these are Christian events, so the last rectangle signifies a church, with the burgundy colour and welcoming doors — instead of windows of the other “buildings”.

The Sunday colour is then consciously repeated in the capital letters and in the “dot”, for balance and unity.

So that's that. I hoped to introduce the fun / youthful factor by playing with the typography, and achieved it to some extent, yet I believe it still looks a tad too formal. I guess it comes from my experience, where I almost always work on logos / designs for serious things. I need to improve my “crazy” skills, then :)

The Process

This was created in Inkscape, a freeware vector editing software. I don't know how it compares to Adobe Illustrator since I never used it, yet I've found Inkscape to be good for my needs — even if it is a bit awkward and rough around the edges, it is still a powerful tool.

For the text, each letter was created as a separate “text” object, since I wanted maximum freedom in sizing and position — since that would be the main vehicle for expressing the “fun” effect, while also I needed to balance them carefully (and I believe this could still be improved). Highlights are additional freehand vector shapes, roughly directed towards the setting Sun:

Highlights proved to be a great asset to the “feel” of the logo, with them it looks… well, polished.

I've made several attempts at conveying the “Night” idea in the Friday rectangle. I browsed through a ton of samples on LogoPond for ideas and inspiration, though I made sure not to directly copy anything I saw.

A lot of vector shapes are used, as well as an overlay of gradient glow, to prevent a sterile mechanical feel (half-successfully):

A palm tree on Saturday is also a nice touch, /me thinks.

Since a lot of stray shapes and objects were involved, I worked in layers, to be able to select / copy / edit a certain part of the image without affecting the rest. Here's the list of layers I used:

This also serves as a primitive versioning structure, you can tell I had several goes at text placement.

For low-resolution usage I created a smaller version, which lacks any details in the buildings, has less highlights on the letters, and uses simplified “Night” graphic on the tallest building. This is necessary to avoid visual noise — though, to be honest, it may require further refinement if this logo gets used in such limiting contexts.

I wouldn't be a proper creative if I were fully happy with this, yet I still like the look of it. The main downsides are that it should be less formal and strict, both in the graphic and the colouring, and the idea behind it is too down-to-business, I would like it to be less straight forward.

Also, I can't shake the feeling that I've seen it somewhere, yet can't nail it either. Nothing new under the Moon, eh?

Do Not Read It Later!

2014-01-21T23:33:00.000+02:00

If you're in IT, you probably read a lot. If you are on the Internet, you probably read a lot too (or look at pictures, which is like reading a thousand words… almost). And it happens in spells, doesn't it? You open an article, follow a link or two, check up a definition of a new term, a biography of a famous person, follow to a page of their quotes, then reading reviews of their books, then checking an article describing the nuances of backend architecture of the site you were reading the reviews on… and it continues, an endless fractal of spreading links, in space and time.

You'll see what I'm getting at.

Then you end up with too much to read. A good problem to have, surely — you don't want to miss the useful information, yet you can't afford to spend so much time reading this very moment. So you postpone the reading. And there are services that help you do it — like the precisely named Read It Later (now sadly re-christened as “Pocket”, thus losing all personality). There are other services of the kind, all nice and helpful.

My opinion and experience of this may be a very subjective one, your mileage may vary, yet my advice — don't. It's a trap! (couldn't resist, sorry)

For me these fire-and-forget backups simply turn into the same kind of storage where you put stuff to forget about it. Like your attic. Like your basement. Like that endless warehouse in the Raiders of the Lost Ark. David Allen was right when he said that putting things down in writing helps ease your mind. Putting things in RIL-type service you tell yourself “I'll read it”, yet you never* do.

* — opening the service once a year to see hundreds of unread articles doesn't count. Sorry, no, it doesn't.

So what do I recommend? Somewhat unrealistic, and doesn't reduce your stress level, yet I try to either read it immediately, just close it or keep it in an open tab in your browser.

The reasoning:

Read it immediately — obvious. You can skim it, you can diagonal-read it, if only to get the gist of it and be done with it. Problem solved.
Close it — be decisive, for goodness sake! You thought it would be interesting, and it could be fun, yet you just don't have the time, and it isn't that useful after all, is it?
Keep it in the open tab — so it annoys you. Yes! First it won't bother you much, then you'll have so many tabs that you won't be able to read their titles — that's when you will be gently nudged towards the decision to either read it (see above) or close it (see above).

Information ages. You move on (and age, too). Not everything you thought was useful at the time is actually useful even a couple of days later. Adding more stuff to the huge dump does not increase your chances of ever getting to the business of cleaning the dump out.

Now, you may have a system, a recommendation, an approach to how you deal with this — and I'd love to hear it. I may learn something interesting. And my open tabs annoy me :)

Reading Digest 02

2014-01-17T13:47:00.001+02:00

So, I've been reading (again, yes), and here are some links that I think your could find useful and interesting. Remember — keep studying, yet strive to learn!

The Useful

Managing a Mind — a very sincere and open confession with a way forward, how our virtual presence can cause a very real crisis in our psyche. Even though it is not a specific to-do list, still I find that being aware about such issues can be of huge practical use for us.

Gov.UK Design Principles — surprised to see a government agency take such a straight-forward no-BS approach. Good example for all of us. I especially like their VAT page screenshot, how they identified the single number most users will be looking for and just put it at the top, in huge font (the concept of “desire paths” is also mentioned, and it is a fun thought to look into)

JavaScript: Taking off the training wheels — right, I am guilty of being somewhat un-learned in the deeper concepts of JavaScript, so this is a nice overview of what I or any person in a similar position might want to try next, to strengthen their footing.

ALA's style guide — what is it with me liking to read (at least skim over) style guides? I like to see a clear structure laid out, which should help anyone joining the team quickly get onboard. So this is a neat read, though looks like outdated (I couldn't find their article headings in H2, so there).

The Interesting

The flow fallacy — I don't fully agree with this, yet this is a nice and thoughtful alternative-angle look. Of course all developers want their rooms, don't want anyone to ever bother them, and… an ice-cream. Or two. Yet working in a team (or working for a customer) means that sometimes you have to step on your wounded introvercy and talk, listen, get interrupted — or even interrupt.

Eldritch: Mountains of Post-Mortem-ness — ah, game development, isn't that why we all picked up the job? Probably not, but still it is very interesting to read an overview of a moderately successful personal project. I really like how this guy approached the task — methodical, meticulous, careful. The financial overview is also enlightening, both the plan and the outcome.

Lots of visual colouring / rendering tutorials — good food for study, if you're into that kind of thing. Or just look at how illustrators approach the task nowadays.

Oculus VR Best Practices document — this is what Neo (Mr.Anderson) was afraid of, and what many of us are looking forward to. Some educating points on this document, about what is required for a good virtual reality experience.

The Inspiring

The Year 2013 In Kickstarter — not only a very well presented, yet also really inspiring to see how the online community comes together to “make things happen” (forgive me the shameless cliche). I am aware that Kickstarter is not all good and perfect, yet its highlights are excellent.

With that in mind — let's make stuff happen! Take care :)

Conditional Enter / Submit handling in HTML forms with JavaScript

2014-01-14T12:22:00.002+02:00

The problem: if you press Enter key while inside a field of HTML form — the form will execute its submit action. Thus if your users are used to pressing return to move to the next field — they will be unpleasantly surprised. I'll show how this can be changed on example of a simple login form.

This will be a quick one, since the task is rather straightforward.

Let's assume a very simple HTML form structure:

<form>
    <input id="login" name="login" type="text" placeholder="Your login">
    <input id="password" name="password" type="password" placeholder="Your password">
    <button type="submit" id="submit">Submit</button>
</form>

If you don't do anything about it, pressing Enter key while in the Login input field will invoke the Submit action. Not good.

To demonstrate it I'll add an alert on submit action (using jQuery for readability in this case), this will help us see clearly when it is actually being invoked:

$('form').submit(function() { 
    alert('Submit!'); 
});

For this study let's concentrate on just the Login field. If you want to stop submit from being invoked on an empty Password field you can apply the same principle.

The code:

$('#login').on('keydown', function (e) {
    if (e.keyCode == 13) {
        // Move to password field if login not empty
        if($('#login').val() !== '')
            $('#password').focus();
        
        // Stop submit from being invoked
        e.preventDefault();
    }
});

The following is happening above:

keydown even is being overridden for the login field.
In the event handler we check for key code 13, which corresponds to Enter key press.
If the login field is not empty (val() is not an empty string) — then move the cursor (with .focus() method) to the password field.
preventDefault() is called on the event to, er, prevent it from executing the default action. In our case, the default action on pressing Enter is to submit the form, so this action is being prevented. Just what we need!

Here's the corresponding demo fiddle. You can comment out the keydown event override to see how Submit is called without it.

I hope this helps, and take care!

PS I do need to spend some time getting away from reliance on jQuery — it is one of my (plenty) weaknesses. I plan to do some studying this week, yet it is so easy to demonstrate event handling etc using it, so I think I'll keep using it in my code examples, except for when pure JavaScript is easier to understand.

Reading digest 01

2014-01-09T10:52:00.000+02:00

Right, sometimes I'd like to share some of the cool/useful/thoughtful things that I've read/watched, so here goes. Note that this may look like an odd mix, but so are my interests :)

The Useful

Demystifying this in JavaScript — as it says on the tine, a brief overview of how “this” is handled in JS. Some interesting nuances with it (or, shall I say, this) depending on the way you call a function, and also ways to override it (this!) if needed. Also, the article has a GIF that is both one of the funniest and one of the saddest at the same time.

Scott Hanselman's 2014 Ultimate Developer and Power Users Tool List for Windows — a huge (no exaggeration) list of Windows tools and tweaks, often offering several options. A good read to see if you've missed any of recent (or old) developments. I am sure to go back to this list every once in a while.

How to write at work — business communication is something I do all the time at work, so not much new here frankly, yet I greatly enjoy more people talking about how to write properly. The sad part is that people who really need to see such advice probably don't care. The main message, as always, is think (!) before you hit that “Send”.

The Thoughtful

'Marines Don't Do That': Mastering The Split-Second Decision — I'll put this under “Work”, since sticking to our principles is what matters in the end. Especially if you believe in God, yet for everyone else too. Would you be comfortable telling your children what you’re planning to do? Will you sleep well? Will you be able to calm your conscience year down the road, when the money earned by an immoral decision is already spent, and all you're left with is yourself?

The Smartest Book About Our Digital Age Was Published in 1929 — I find this parallel fascinating (not everyone does, and a brief FB argument sparked to life about this article), as well as the general observation of the world turning its back on educated opinion in less precise fields. If you need a site made — you'll take someone with experience. If you need a music commentary — you'll rather trust someone who splashes in the same kiddie pool as you are in, over someone who'll attempt to take you to new heights. This is how I behave, too, sadly. Applies to everything with at least one level of abstraction.

The Interesting

How to draw gesture — a lot of such videos around, yet this one concentrates on 30 seconds and 2 minute poses, what shortcuts are required, how motion is emphasised (over contour), with a lot of quick examples (note that this is N-e-SFW — not entirely safe for work). Need to do more of these, I never managed to get into the habit.

How it's made: Piano — unfortunately a lower-resolution video, yet still very impressive. How much time, care and precision goes into making one of the most beautiful instruments in the world!

The Bizarre

This is an actual academic paper about tracking time travelers online — sharing this in the hopes of promoting the idea so that, perhaps, some future readers notice this and post the requested hashtags in the past. If they do, though, I will not need to post this link anymore, so in the new future they will not find out about the hashtags, and then… Doc, help me out here!

Drawing the colour wheel with JavaScript

2014-01-03T12:01:00.000+02:00

A brief follow-up to my earlier post on automatically generating colours using JavaScript, I just couldn't stop! It slightly irritated me that I had to search online for a picture of the colour wheel for the previous article (and found it on Kuler web-site, which is cool and all, but…), while I could easily generate it myself!

So, here's what I came up with, adding some niceties:

This is an example of using a scripting language for quick prototyping and demos, so the approach is not the most efficient performance-wise, but gave me a quick result. The main thing I would change if it were needed for actual usage — I would not use the DOM for individual “pixels”, this is a luxury. Canvas is a better candidate for such things.

The Code

Here's the working example of JSFiddle, and the important snippets are below:

var dim = 51; // Beware of setting too high
var html = '';

for(var i = 0; i < dim; i++) {
    // Draw row
    for(var j = 0; j < dim; j++) {
        // Draw pixel
        html += '<span class="pixel' + (j == 0 ? ' first' : '') 
        + '" style="background-color: ' + getColour(i,j,dim/2) 
        + '"></span>';
    }
}

$('#wheel').append(html);

// Returns colour of pixel based on its offset
//   and circle's radius (square width / 2)
function getColour(i, j, radius) {
    var angle;
    var col = '#fff';
    var x = j - radius;
    var y = radius - i;
    
    var dist = Math.sqrt(x*x + y*y);
    
    // If inside the circle
    if(dist <= radius) {
        angle = Math.round(180 * Math.acos(x / dist) / Math.PI 
           * (y < 0 ? 1 : -1))
           + 90;
        col = 'hsl(' + angle + ', ' 
           + (Math.round(dist / radius * 100)) + '%, ' 
           + (80 - Math.round(dist / radius * 20)) + '%)';
    }
    
    return col;
}

And you need this CSS to have the pixels align correctly:

.pixel {
    display: block;
    float: left;
    height: 6px;
    width: 6px;
    margin: 0 1px 1px 0;
    border-radius: 3px;
}

.first {
    clear: left;
}

Calculations

The logic is simple — remember those trigonometry classes, the ones you couldn't understand why you will ever need them? Why, for drawing colour wheels, of course!

I am drawing a square (wait), and for each pixel from its (x, y) coordinates I detect whether it is within the radius of the circle (see?). If not — draw pixel white (could make it transparent too, if I needed). Distance from the circle origin is the square root of sum of squares of the coordinates. This distance also determines saturation of the resulting colour, and a slight variation of lightness (that makes it look nicer).

The hue is the angle of direction to the pixel compared to the vertical. To determine this I use arccosine — inversion of cosine value (school strikes back). Keep in mind that this gives you result in rads (full circle is two Pi), not degrees, so I still need to convert it.

Put angle and distance together to get a colour — and voila, — you get the nice-looking wheel.

Playing Around

With some time, inspiration and luck there can be many variations of the resulting picture:

…or even the “proper” wheel:

Automatic colour generation in JavaScript (with a trick!)

2013-12-30T14:46:00.000+02:00

The task — generate a number of sufficiently different colours for display on a page.

For example, this is needed to display a lot of elements, which belong to one of several categories (say, 10-20 categories), and in colouring them you will help the viewer to easier identify elements of the same group.

Colour Theory

The pep-talk version of it, anyway :)

In web-world we are all used to the stock RGB (Red/Green/Blue) palette, yet it is in fact not the best choice. It works well for defining brightness of each of the three-coloured pixels on our screens, but it does not actually reflect nature of colour much. Try to manually create yellow out of that, for instance. Good luck.

See, it is much easier to find differing colours on what is called a “Colour Wheel” (invented by some really smart person, I am sure), where different colour hues (tints) are signified by an angle out of 360 degrees (a circle indeed, hence a “wheel”):

Da Wheel.

If you pick a single hue value, then you can control how much of that colour is being displayed (Saturation), and how light/dark it is (Brightness). Very easy to find opposing / nearby / lighter / darker / whatever shades this way. This is why those artsy designer-types quite often (if not always) prefer an HSB format (stands for Hue / Saturation / Brightness) over RGB. This is like choosing English (a formal and precise subset of it) over Assembler programming language.

Equidistant Colours

How does it help us? It helps a lot. In order to generate several colours that are as far from each other as possible, yet still possess similar lightness — i.e. to solve our basic problem of autogenerated set of differing colours, — we, in the very simple method, need to only pick different hue “angles” with the same saturation and brightness values.

This is not precisely true, I'll explain below why, but good enough for now.

And we have a huge blessing disguised in support of HSL format (Hue / Saturation / Lightness — lightness being synonymous to “brightness”, fine by me) by all modern browsers. Yay for technological progress!

So, if we pick saturation and lightness at 80% and 70% respectively, if we need, say, 12 colours, we can just divide the 360° by 12 (yields step of 30°), and then plot them starting from zero. These values can be used as a background colour, in the following style declaration: “background-color: hsl(0, 80%, 70%)”.

Easy.

You'll see my code below, and this is the result I get from running it for 16 colours:

Not bad, huh?

The Trick

It is okay, but being the grumpy type I have to say it could be better (and it'll never be ideal, oh well). Nearby colours, especially in the green range, are too close together visually. This is important if you have a poorly tuned monitor, or view it slightly off-normal angles (on cheaper screen types).

Let's improve it. The hues are already equidistant, so you can't really gain much more contrast in picking the tint. Yet the immense variety of colours we see in real life is not achieved by hue alone!

So the small trick I propose is to alternate between slightly different saturation/brightness values for adjacent colours — say, for even colours use SL of (80%, 75%), and for odd ones use (70%, 80%).

This results in the following sequence (old one shown to the left, for comparison):

Before — After*.
*Improvement guaranteed or your money back after 15 years of following this Simple Exercise Routine™!

Better, I say. This can be tweaked further, depending on how many colours you need (perhaps you need to alternate every three colours, for example), and the actual saturation/brightness values will vary depending on the specific needs of your project — whether you need lighter or darker colours etc. Even hue range could be limited to a portion of the spectrum.

I hope this gives you a good idea and a starting point for your own experiments.

The Code

You can check the working demo in the corresponding JSFiddle (I hope it lives long and prospers!).

Here's the JS code, to give you an idea of what is happening:

$('#gen-btn').click(generate);

function generate() {
 var genQty = $('#gen-qty').val();
 
 populateList('#colour-show-1', genQty, 0);
 populateList('#colour-show-2', genQty, 1);
}

// Creates an HTML demo list with generated colours
// variant is the choice of which method to apply
//   0 - basic; 1 - with the odd/even saturation/lightness trick
function populateList(selector, qty, variant) {
 var html = "", colour;
 var step = Math.floor(360 / qty);

 for(var i = 0; i < qty; i++) {
  colour = getColour(i, step, variant);
  html += '<li style="background-color: ' + colour + ';">&nbsp;</li>';
 }

 $(selector).html(html);

 return;
}

// Returns individual colour, based on its 
//   number in the sequence, 
//   the angular step, and 
//   the chosen method 
//   (0 - without or 1 - with the saturation/lightness trick)
function getColour(num, step, variant) {
 var col;

 switch (variant) {
  case 1:
   col = 'hsl(' + (num * step).toString() + ', ' // Hue
    + ((num % 2 == 0) ? 80 : 75) + '%, ' // Saturation, even/ odd
    + ((num % 2 == 0) ? 70 : 80) + '%)'; // Lightness, even/odd
   break;
  default: col = 'hsl(' + (num * step).toString() + ', 80%, 70%)';
 }

 return col;
}

Possible Improvements

I would actually like to hear if you have any ideas on how this can be improved further. One observation I made earlier is that the colours in the green section are visually too close together — perhaps some nuance of how our (mine?) eye sees it. So we could gain better result by spreading that particular range further apart, while there is room to make red-orange, and blue-purple hues closer and still have them distinguishable.

That's just an idea, though, and may be you'll have more. For now the simple version works for me, and it may work for you. Take care!

I wish for the customer to always be right

2013-12-04T11:40:00.000+02:00

The customer is always right!

Right… like they're not human. Perhaps, humanity will be overrun not by perfect automatons created by SkyNet (or Hasbro's Furbies, whichever you prefer), but instead by the Infallible Customer (or did that already happen)! It's just not true.

These are always right! In a cute'n'scary kind of way.
(photo by The Justified Sinner)

No, wait, it is true in the motivational sense!

Say, you give a task to one of your developers (including your inner developer, hello!), and, upon studying it, he starts to grumble. Oh, so-and-so customer, again they are coming up with most stupid things to occupy us with, complicating everything: our product, our code, our testing, our very life! And on he goes on and on, stupid task, silly customer, smart me, and so on, and so forth.

In such cases your are totally entitled to un-sheath the above slogan. The customer is right. They are the one who have a problem that needs solving, and they are the one, who will (hopefully) pay for this in the end. Also, they probably know their business much better than we do. So — study the task, try to understand the underlying problem, and solve it, instead of ceaselessly whining, thank you very much.

But, apart from such inspired speeches, we need to keep in mind that the customer is, in fact, not always right. They just can't be. Nor, I noticed, do they always try to be.

Think about it — they're busy with their work (just as you are with yours), they also have lots of tasks, priorities and distractions to manage On top of it, they may have a pressing problem (like, their boss forcing them to describe something to you, or even them facing an urgent issue which they really really hope you could help them solve), which adds to the stress.

Plus, wait for it, they are not always as technically savvy as you pretend to be. So they can't really tell your “current DB structure only allows for this” from “JSON over AJAX with jQuery from IE6”.

And, if they are good and nice people, they also try to help you by describing their imagined solution to the problem, instead of describing the problem itself. It doesn't always help, yet they do try.

Thus some inconsistencies in their requests: contradictions, omissions, odd fantasies and things that are just wrong. If we expect the “customer to be always right”, and, after a while of intensive arguments and hurt feelings, we just decide that, right, I've had it, I'll just do what they say, and then they will see that I was right all along! — we are not helping anyone. Not even ourselves.

So — let's be merciful and gentle. Study the task carefully. Hold our horses on arguing, blaming and bashing. Try to understand. And try to be helpful. And just be humanely nice, as much as it is possible.

And, in my experience, the customers love it. You act like a member of their team, you worry about their problem like it is your problem (and indeed it is, if you're tasked to solve it), and, for all intents and purposes, you act like your customer is always right, by graciously allowing them to be wrong every once in a while.

A bit of a rant, yes, but it is something I have to remind myself very very often, since my inner developer likes to complain no less than that other guy. This toxicity can be contained. Let's make this industry — and this world, — a better place to work in :)

Take care!

Multiple columns in HTML/CSS (and JS for poor old Internet Explorer)

2013-11-13T13:39:00.000+02:00

A quickie on how I solved a need to display multiple columns, before I forget (and may be helpful to some of you, my dear readers).

The problem — I have a dynamically generated text (parameter fields in a settings form), which I need to display on the screen utilising as much width as possible. If the fields were not dynamically created, it would of course be better to layout the form manually — then you can make intelligent choices about what goes where. Not in this case, though, so I needed an automated way to display this content in columns.

Cascade Style Sheet FTW!

Of course, there is CSS3, which is really cool and can do it nicely and fairly easily:

#content
{
    -moz-column-count: 3;
    -moz-column-gap: 20px;
    -webkit-column-count: 3;
    -webkit-column-gap: 20px;
    column-count: 3;
    column-gap: 20px;
}

column-count defines how many columns CSS will attempt to lay the content out (utilising the width that is available to the element), column-gap is the margin between the columns. Of course there is the -moz and -webkit prefix madness that we've all learnt to expect already.

This works surprisingly well on all desktop browsers (didn't test on mobile, not required for this project, yet I hope the newer ones will render this too… or — see below), except for… drumroll… opening the envelope… ah, you knew it already — IE9 and below.

Poor things, they've worked enough and need their rest, but people keep using them. Anyway, we need a solution that would work on these too.

JavaScript FTW!

I don't go with a JS solution for everything because it is less transparent (and, therefore, error-prone and harder to fix if things go wrong in some obscure situation), may slow the page down, and, well, is not the tool for the job. Unless you're on IE.

So, I used a combination of Columnizer (a jQuery plugin) and Modernizr (what's with all the -zr fashion?).

Modernizr is a very nice library that can be used to detect support of the CSS columns feature, and, if it is not present, introduce a fallback to JS.

Even better — and I love this part, — Modernizr can load the Columnizer library if it is required — so this improves page load time for the browsers that do support columns. Here's how it is done (in your JS code, on page load):

Modernizr.load({
   test: !Modernizr.csscolumns,
   yep: '/js/jquery.columnizer.js',
   nope: ''
});

Very simple — we test support for CSS columns, and if not supported — load the additional JS code.

Note that the .load method is not included in Modernizr development build (a very odd decision, I'd say), so if you plan on using this feature — you need to select it in the main Modernizr download builder (in the Extras section).

Now, where you need to apply the columns, you can use the following JS code:

if (!Modernizr.csscolumns && $('#content .column').length == 0) {
   $('#content').columnize({ columns: 3 });
}

What it does is again check whether CSS columns are supported, and applies columnization (isn't a word, I know) to our element of choice, to create three columns. The element in my case may be shown multiple times, and this script is called each time, this is why I check for presence of .column class in our element ($('#content .column').length equals zero) — Columnizer add this class to its generated columns for easy styling, and thus I can also detect whether it has done its job before or not.

Note that I am not checking “if the browser is IE” — this is the beauty of Modernizr. Instead we can check for support of a specific feature, so this will work on other browsers that don't support it, not just limited to IE (I am thinking about older mobile browsers here). Nice, isn't it?

Then I just need to apply my column-gap style to the HTML generated by JS:

#content .column /* Needed for columns created by the Columnizer script */
{
   padding-right: 20px;
   -webkit-box-sizing: border-box;
   -moz-box-sizing: border-box;
   box-sizing: border-box;
}

box-sizing (with unavoidable entourage of prefixes) is needed to make sure the padding does not increase the width of the columns, or else it all falls apart.

That's it, it works :)

This is obviously not the only solution, something may suit you better in your situation. On another occasion I needed more complex rules for splitting items between columns, so had to write my own JavaScript code to handle the whole thing.

Let me know if you have any feedback / questions, and take care.

A Fire-and-Forget Worker

2013-07-25T16:20:00.000+03:00

This is not about a worker whom you fire and then easily forget about (with a sigh of relief, perhaps?). No, this is quite different. You know them fire-and-forget missiles? Their key strength is that they don't require additional guidance after being fired. Point them to the target, give a brief motivational speech, and off they go! Now imagine this for people and their tasks.

…and Tony Stark can turn his back to the explosion — to spread his hands in triumph :)

There are many qualities of a truly good professional, yet close to the top of the list (somewhere along with ability to listen and learn) is the ability to take your task (or, shall we say, a “mission”!) and then do it.

Yes, there may be issues along the way — you'll make sure to solve them. You don't even need to do it yourself — there may be additional approvals or decisions required, so you'll go and talk to the required people and see to it that the decisions are made, etc etc. And you'll then check the result before clapping your hands together for a happy “Another job well done!”, since you're probably the best person to check your work for potential weak spots, omissions or cut corners.

This is as opposed to sitting on your soft… chair (or standing on your hard floor, if you prefer) and building up a list of excuses for every obstacle you encounter, waiting for someone to come along and ask whether you're moving according to plan — and helping you overcome whatever minor issue you decided was good enough to relax for now. This is as opposed to sending avalanches of emails to ensure that “the ball isn't in your court” at any given time. This is as opposed to people who need a lot of hand-holding (not a good thing, even if it sounds romantic) to get through their projects.

Why is this helpful to your colleagues? If they don't need to double- and triple-check you — they are freed to work on their tasks, and, as a team, you achieve more.

Why is this helpful to you? Well, interestingly, you'll notice that such people get quickly noticed in a work environment, and, if the environment is at least somewhat healthy, their position improves. They get more trust, more things depend on them, so, as such people are reliable, so is their job and — gasp! — even their salary.

So even if you're ambitious and have lofty goals — I'd say that being dependable is an honest, morally right and emotionally satisfying way to get to where you want to be. As opposed to, say, playing cover-my-ass or career-ladder games and all that shameful nonsense that we see probably too often.

Therefore I'll definitely strive to be more of this kind of person, and encourage you to do the same.

Anton

Crossrider Extensions shutting down

Reading Digest 06, or What does Leo Tolstoy have to do with it?

Crossrider no longer recommended for cross-browser extensions, sadly

Firefox

Chrome

Safari

Internet Explorer

Conclusion

A simple Telegram bot with Node.js

The problem

Solution approach

Tools

Source code

Configuration

Stateless Caveat

Conclusion

Reading Digest 05

Double Trouble: Two risky features come together for a conflict in JavaScript

Array.prototype.[method]

Array property iterator

What should we do?

Micro-solution: Automatic Value Axes Offset in amCharts

JavaScript Unit Testing in Crossrider Browser Extensions

Setup

Triggering Condition

Actual Tests

Real-life Tests

Testing Background and Popup Scopes

Conclusion (and a free advice)

Developing browser extensions using JavaScript with Crossrider framework

The Task

Features & Process

Roadmap Extension

Browser Support

Summary

UX is about organization

Micro-solution: Preserving input values against all odds (JavaScript)

Solution

Reading digest 04

Developing

Thinking

Motivating

Propaganda versus Glasnost

Issues arise in any sizable project. Devil hides in the details, and no plan can take them all into account. If you are managing such a train on fire, do you pretend that everything is great? Or…

Reading Digest 03

The Work

The Fun (at work)

The Conclusion

You need to step away from your computer. Probably now.

Designing a logo for Friday.Night youth events

The Task

The Idea

The Process

Do Not Read It Later!

Reading Digest 02

The Useful

The Interesting

The Inspiring

Conditional Enter / Submit handling in HTML forms with JavaScript

The problem: if you press Enter key while inside a field of HTML form — the form will execute its submit action. Thus if your users are used to pressing return to move to the next field — they will be unpleasantly surprised. I'll show how this can be changed on example of a simple login form.

Reading digest 01

The Useful

The Thoughtful

The Interesting

The Bizarre

Drawing the colour wheel with JavaScript

The Code

Calculations

Playing Around

Automatic colour generation in JavaScript (with a trick!)

The task — generate a number of sufficiently different colours for display on a page.

Colour Theory

Equidistant Colours

The Trick

The Code

Possible Improvements

I wish for the customer to always be right

The customer is always right! Right… like they're not human. Perhaps, humanity will be overrun not by perfect automatons created by SkyNet (or Hasbro's Furbies, whichever you prefer), but instead by the Infallible Customer (or did that already happen)! It's just not true.

Multiple columns in HTML/CSS (and JS for poor old Internet Explorer)

The customer is always right!

Right… like they're not human. Perhaps, humanity will be overrun not by perfect automatons created by SkyNet (or Hasbro's Furbies, whichever you prefer), but instead by the Infallible Customer (or did that already happen)! It's just not true.