Software, Business, and Life
There are plenty of user groups that meet in the evening. We’re going to try one at lunchtime, which is potentially more convenient for those of us with kids in school.
Angular Lunch, in St. Louis MO.
Third wednesday of each month. Noon. At the offices of Oasis Digital, who will supply the pizza and space.
USB has taken over as the “one plug” for most purposes. The coming-soon Power Delivery specification will likely expand that reach quite a lot.
Already though, USB has taken over my desk, thanks to this shiny new 7+2 hub. (Not an affiliate link, I just like it.)
Over at work, we’re re-launching a line of business from some years ago: training. Specifically, an Angular “Boot Camp” course to help developers become productive in some powerful but daunting tool.
Why? Because we think AngularJS (and its competitors like Ember) are an important step forward in how complex “single-page” web applications are constructed. The AngularJS approach is not the only good way to build such applications (for example, over in the Clojure space, Pedestal is genius; elsewhere in JavaScript, Facebook React is very appealing). But AngularJS is popular, growing fast, and suitable for many application needs.
There are rumors around that it is impossible to use the JIRA API anonymously, even with an instance set up for public read access.
This is not true. I wrote a tiny example tiny project to demonstrate it by retrieving info from a public JIRA instance (the one for Hibernate).
The main source of this confusion: neither the official JIRA API Java client, nor the third-party (and easy to work with) rcarz client ships with anonymous access classes or examples.
Get the bits on Github.
I’m looking at you, Crystal Reports!
Opaque binary file formats for development assets are a scourge on the software development community.
Here’s some context. At Oasis Digital we typically work on complex enterprise data systems. These systems have a long life, with multiple (or many) developers working concurrently and over time. These systems are important to the companies which use them, which is to say, we must not accidentally break things.
In that context, we’ve encountered the following problem on numerous occasions, using numerous tools, on multiple platforms, over many years. Today I’m going to pick on one specific and especially painful instance of it: report definitions.
We believe strongly in code review, where code is defined broadly to include things like the definition of a report. That definition can include SQL, layout information, styling, parameter definitions, and so on. Whenever a developer makes a change to a software system, another developer (often a more senior one) reviews the change to see exactly what is changed, and verify it appears correct, and that no accidental changes are included. In this way, we greatly reduce the incidence of accidentally changing or breaking something that was not supposed to be changed.
Code / change review is very common in most or all mature software development organizations.
For source code, almost universally represented in plain text, the mechanics of code change review are straightforward. The diff command, or any of 1000 tools for comparing files, can readily show the differences between version and an version M. (As an aside, whenever someone presents a mechanism for representing source code is something other than plain text, I dismiss it with a chuckle unless there is also a solid solution provided for the question of how to review changes.)
Happily, many reporting tools represent the layout and query information for a report in a text format. Sometimes it is a proprietary text format, sometimes it is XML; regardless of the ugliness, these all have the merit that it is possible to compare them as text and see what changed between two versions. Offhand, I would like to call out:
for doing the right thing: offering a text-based, diffable representation of a report definition.
Crystal Reports, though, is both a popular and problematic tool. It represents reports in an opaque binary format, for which a “diff” produces nothing readble. With only this in hand, “code review” of report change consists of:
I have heard that “Hope is not a strategy” and that is certainly the case here. Yet this tool (and others like it), an opaque binary representation of report definition leaves us with only hope.
I have read that Crystal Reports offers an API (object model) by which software can inspect and manipulate the report definition. Using this, it should be possible to write a tool which takes a report definition is input, and emits a text file as output, such that the text file contains a human readable definition of every important piece of information about the report definition. this simply adds a minor step to a review/diff process: run both the before and after representations through this conversion, and diff the outputs of the conversion.
To be effective, such a tool would need to produce a text representation which is both complete (which is to say, includes essentially everything that will be needed to re-create a report definition) and stable (which is to say, minor changes to the report definition produced by clicking around, result in minor changes to the text output)
Unfortunately, I have not been able to find such a tool. If anybody knows of one, I would love to hear about it.
ClojureScript is a relatively recent addition to the list of languages which compile to JavaScript. Unlike some such languages, it does not only fix the minor difficulties with JavaScript (like syntax oddities), rather it is a wholly different language with a LISP-like syntax and very powerful semantics. Many words have been written on “why ClojureScript”, which I won’t attempt to restate here. Rather, these are the handful of reasons ClojureScript is worthy of a deep dive for projects like ours (at work).