Tuesday, 21 February 2017

React-ing to the need for a modern MapGuide viewer (Part 13): My first* pull request

Previously, I switched our testing stack for mapguide-react-layout over to Jest, which had some positive flow-on effects, like being able to finally upgrade to Webpack 2 and being able to try out the new OpenLayers npm package, resulting in a nice reduction in production bundle size due to only pulling the bits of OpenLayers that we are actually using. Jest also has code coverage built in, and by piping its coverage output to node-coveralls, TravisCI will automatically upload said coverage reports to coveralls.io resulting in yet another shiny badge to show on our project page.

These badges are becoming like Pokemon: I just want to catch 'em all.

So the next badge for me to collect was greenkeeper. Greenkeeper is a free service that monitors your GitHub repository and keeps your node package dependencies up to date. So last night I enabled greenkeeper integration for mapguide-react-layout.

Today I got a GitHub notification for a new pull request on mapguide-react-layout. Great! I love pull requests. Except, this pull request is not from a human, it's from the greenkeeper bot (*my first non-human pull request). Looking at the pull request in detail was most amusing.

A bot (coveralls) commenting on a pull request opened by another bot (greenkeeper)!

I wonder how many pull requests out there are nothing but full of bot-on-bot comments? How deep does this bot rabbit hole go?

When bots can start writing their own code, I think that's when we can pack it in as the human race and submit to our bot overlords.

Monday, 20 February 2017

React-ing to the need for a modern MapGuide viewer (Part 12): A positive cascading effect

The move to Jest for our testing/coverage needs has opened up some opportunities that were previously roadblocks.

Mainly, we can finally upgrade to Webpack 2. Previously, we were roadblocked because the karma runner just wouldn't work with webpack 2 configurations. Also unlike earlier attempts with Webpack 2 beta releases, this upgrade to Webpack 2 was less painful and more importantly, the bundle size remained the same.

Also OpenLayers recently released 4.0.0, which also includes experimental ES2015 modules, the ES2015 module facilitates a "pay for only what you use" model which is great for us as we don't necessarily want to use the kitchen sink, only the parts of the library we actually use. It turns out based on their webpack example that it requires Webpack 2 to work as Webpack 1 will include said modules verbatim causing most browsers to blow up on the various ES2015 language constructs (like imports).

Well, how convenient that we just upgraded to Webpack 2! Switching over to the new ol package and its ES2015 modules, and making the required fixes in our codebase to use this new package, and checking the final production bundle size shows promise.

That is 150kb smaller than our current production bundle! Once other libraries we're using adopt ES2015 modules, we can expect even more weight loss.

Saturday, 18 February 2017

React-ing to the need for a modern MapGuide viewer (Part 11): I don't say this in jest

... but seriously, Jest completes my holy trinity of web front-end development nirvana.

  • React, because of its high performance and revolutionary component-based way of building frontend UIs. I could never go back to jQuery, data-binding, string templating and those other primitive ways of building frontends.
  • TypeScript, because it is in my opinion, the only sane programming language for frontend development. Just like jQuery was the glue that held together inconsistent browser APIs for many years, TypeScript the the glue that lets us play with future JS technologies in the present. TypeScript is JavaScript with C#-quality static typing. I love that a whole class of errors are eliminated through a simple compile step. I can't fathom having to maintain large code bases in a dynamically-typed language. TypeScript brings order and sanity in that regard. And with TypeScript 2.0, I don't have to deal with billion dollar mistakes.
  • And finally, Jest which I believe to be the total package for JavaScript unit testing that is sooooooo easy to set up! Code coverage is also included.
Before I tried Jest, the current unit test suite for mapguide-react-layout was a convoluted stack of:
I also tried to get code coverage working. But this required a tool called istanbul and because my code was TypeScript, it needed some TypeScript source map plugin for istanbul to recognise it, which resulted in some rube-goldberg-esque contraption that formed the foundation of my unit test suite, that didn't even get the coverage right! So I scrapped the code coverage part and just coasted along with karma/mocha/chai combo until now.

With the introduction of Jest, it does the job of karma/mocha/chai/istanbul in a single, easy to install package. Only some small changes to my unit test suite was required (porting chai assertions to their jest equivalents) and the whole test suite was passing. With a simple addition of a --coverage flag to jest, it then automagically generates code coverage results and reports.

Since I am now getting code coverage reports, the obvious next step was to upload this to the coveralls.io service. It turns out TravisCI already supports automatic upload of code coverage reports to coveralls. It just needed installing node-coveralls and piping the jest coverage output to it.

And with that, I get another shiny badge to brandish on the project home page

This is almost too easy. Results like this easily incentivize you to write good quality code.

One last thing before I close out this post. The 63% coverage is a bit of a misnomer. It turns out that it is actually the percentage of code in modules that your unit tests are currently testing, which makes sense. The moment I start bringing in other components and classes under test, I expect this percentage to plummet, which is merely incentive to write more tests to bump it back up.

Thursday, 16 February 2017

Announcing: mapguide-react-layout 0.8

Here's a new release of mapguide-react-layout

Here's what's new in this release

Multiple Map Support

If you load an Application Definition with multiple map groups, the viewer now properly supports them.

Thanks to the use of redux (as my previous blog adventure post explained), map state is all nicely isolated from each other and makes it easy for components and commands to easily be aware of multiple maps, such is the case of the measure component (notice how recorded measurements switch along with the active map)

Also for Task Pane content, we added some smarts so that you know whether current task pane content is applicable or not to the current active map.

Other Changes

  • Update Blueprint to 1.9.0
  • Update React to 15.4.2
  • Improved performance of redux aware components to avoid unnecessary re-rendering
  • Sidebar Template: Fix a small sliver of the Task Pane content visible when collapsed
  • Legend: Fix infinite loop on maps with multiple (>2) levels of group nesting
  • Hover styles no longer render for disabled toolbar items
  • Clicking an expanded panel in an accordion no longer collapses it (an expanded panel should be collapsed by clicking another collapsed panel). This affects viewer templates that use accordions (eg. Slate)
  • Added support for InvokeURL command parameters
  • Fix default positioning of modal dialogs


Monday, 6 February 2017

Announcing: MapGuide Maestro 6.0m6

Here's another long overdue new milestone release for MapGuide Maestro 6.0.

Here's a summary of what's new.

Friendlier connection error dialog

Rather than say MgConnectionFailedException, perhaps this dialog can explain things better?

Theme support

The latest version of DockPanelSuite supports theming. Maestro now includes a bunch of VisualStudio-style skins that you can choose from the options UI. For example, here's Maestro with the Visual Studio "blue" theme.

Non-modal map previews

Resource previews that use the local map viewer (ie. It doesn't launch an external web browser), now display as additional document-resident view content instead of a modal dialog.


Rather than punching in coordinates for override extents manually, you can now set the extents interactively with Maestro's map viewer component.

Also on that subject, when generating tiles with overridden extents, the total tiles calculation should be more accurate now, having verified the overridden extents against the contents of the physical tile cache, the visual verification made much easier with this new feature.

Other Changes
  • Maestro now has new validation rules for ODBC configuration documents
  • You can now enter a Google Maps API key in the Flexible Layout editor (if you require it)
  • The mapguide-rest addin now generates configuration documents with valid representation nodes
  • Fix NullReferenceExceptions when editing Fusion Flexible Layouts with multiple map groups. A nice timely fix to have to make way in preparation for when this is ready.
  • Upgrading a WebLayout to a 2.4 or newer schema version will now include the MapTip command if it doesn't exist
  • Upgrading a Layer Definition to a 2.4 or newer schema version no longer discards any URL settings.
  • XML editor now automatically trims off null '\0' characters (the source of many bogus content validation errors)
  • FDO stylization functions are no longer falsely reported as unsupported functions by the FDO expression validator.
  • Fusion and Symbol Definition editors should now trigger dirty state more often.
  • IronPython updated to 2.7.7

Tuesday, 31 January 2017

A few days layer ...

Not only does AppVeyor gives us continuous integration, it can give us continuous delivery as well.

So after getting the newly migrated MapGuide Maestro on GitHub hooked up to AppVeyor for CI and automated publishing of code coverage results to Coveralls, I wanted to look at how AppVeyor can be used for automating the creation of GitHub releases. The ideal scenario, is that when I decide to put out a release, I hit some button or run some command and a new GitHub release will show up a few minutes later.

It turns out, AppVeyor has a whole section on their documentation dedicated to this very subject! Some tweaks were required to the AppVeyor build system so that it also builds the API/User documentation and zip/installer packages and then by specifying these artifacts in the artifacts section of appveyor.yml, they will appear in the artifacts section of the AppVeyor build page.

What that means is that you now have access to the latest builds of MapGuide Maestro straight after AppVeyor builds and validates them. However, this is not the way I want you to access official releases of Maestro, I still want GitHub releases created for this particular case, and ideally in an automated fashion.

This is where we set up our AppVeyor configuration to deploy using the GitHub deployment provider, with the trigger being a push of a git tag. What this means in practice is when I decide to put out an official release, I make the release tag in Git, push it out to GitHub. This triggers AppVeyor to do its usual CI and artifact packaging. But because this is a release tag, it will also automatically create a corresponding GitHub release in a draft state and uploads the associated artifacts of this build with it.

From there, I can visit the draft release page and tidy up the release description and add release notes, click the publish button and voila! A new release is ready for you to download. How well is this automated process? Check out this test release and find out for yourself.

I'm really liking this well-oiled CI/CD machine, further solidifying my justification for making the move to GitHub in the first place. Oh, and as the above screenshot shows, I also got my first pull request today for Maestro too. Things are looking up!

Friday, 27 January 2017

A few hours later ...

Moving MapGuide Maestro to GitHub has already paid off!

The code is hooked up to AppVeyor for automatic continuous integration

Our unit test suites are hooked up to OpenCover, whose reports AppVeyor will automatically upload to coveralls.io.

And these services are all free!

And we get some nice badges to show for it!

So just to give some context for that coverage result: This coverage is for the MaestroAPI part of Maestro. It does not cover the WinForms application itself, which I find trying to write automated end-to-end tests (and hence coverage) to be a fruitless endeavor. It will either work or not, that's as good enough of a test as any. MaestroAPI on the other hand, is the engine that drives the application and this is something that definitely needs the test validation and coverage as it has uses outside of the Maestro application and we need objective confidence in the stability and robustness of the MaestroAPI, which these aforementioned services will give us.