A Confluence dashboard-like page layout using section-, column- and panel-macros

Every wiki landing page usually features a kind of overview layout to provide links to the most interesting topics or articles. This might constitute a classic table of contents, quite lengthy at times, a tag cloud of the hottest keywords (and relations, maybe), for iterative exploration, or, if you like, a dashboard of context grouped / block visualized widgets of important articles. Whatever you prefer, me, I almost always take on the dashboard approach, because it provides a great productivity in information to space ratio. Furthermore, dashboards also greatly serve the figurative memory in that one can plainly remember some article link resides in a widget up in the upper right corner of the page or yet within another widget with an outstanding background color.

However, I’m not planning to advertise dashboard / widget user interfaces here. What is to follow comprises an implementation pattern and example of setting up a simple dashboard layout in recent Confluence environments. All you need is to employ section-, column- and panel-macros in that order and hierarchy, respectively. For reference see the latest Confluence docs concerning:

Javascript linting with interactive-linter in brackets

Brackets is a great web editor that extraordinarily manages editing the gang of four of web development languages, JavaScript, HTML, CSS and JSON (not to be neglected), just in one place (or pane). What I also very much appreciate aside of that, is the built-in availability of language linting, like one may know it from PyCharm using Python-PEP’s already. However, using language linting, especially for JavaScript, takes a couple of decisions first, in particular what linting approach to employ and how to fit the selected approach to one’s needs.

To me, there are essentially four widely known approaches to JavaScript linting (jsx unregarded): jslint, jshint, jscs and eslint. jslint is the great-grandfahter of this ancestry (iff you like), originally trying to safeguard the developer against the sloppyness that is possible coding JavaScript. jslint is quite strict in judging what code performs in quality and what lines do not. Some people do get really bugged along with jslint from time to time such that jshint came up, taking things much more relaxed by being more configurable and introducing code format analysis in addition. Code format analysis then, important in team development above all, was the main topic of jscs, extending what was already available in jshint even to modern patterns of web development. eslint, eventually, may be seen as a current fork merge of jshint and jscs, taking the best of both worlds and additionally offering user-defined linting rules. In fact, the implied ancestry may become a carved picture regarding pages like jslinterrors where you can look up different rule names for the same semantics of linting in jslint, jshint and eslint, respectively.

Evaluating free mockup apps: pencil and prototyper-free

There is quite a lot of mockup apps around whereas only some of them are under active development and additionally are offered with a non-commercial licene. I (only rawly) evaluated two of them, namely pencil (2.0.3) and prototyper-free (2.1.0) for an application in a web-ui project.

pencil is a classic in the mockup scene and may became most popular by shipping a firefox plugin variant that allows for quick web-based mockup production. however, since firefox meanwhile outruns any developer by updates, the current plugin rendered incompatible with my running firefox installation and i settled for the windows installation package. prototyper-free is, on the other hand, a branch of the commercial, fully fledged mockup tool that has been restricted in functionality and more specific in extensionability (see below) without preventing you from getting your mockup job done efficiently.