FrontierNav is now open source! I've spent most of the month planning this switch over and thinking about what it means for the project going ahead.
By virtue of being open source, I'll be more open about priorities and plans. There's an Issue Tracker for feature requests, planned changes and bug reports. I've also written some documentation for people to get started so that they can make their own code contributions.
For Xenoblade 2's map, legend toggles have been implemented, allowing you to choose which map markers to show. However as the data bundle now contains substantially more data -- roughly doubled by adding all enemy spawn points -- the current approach to data management may not be feasible. So I've spent some time looking into alternative approaches.
After years of writing log lines and trying to find a perfect format, I've come to a conclusion: Always log JSON.
Logging to JSON makes your code read more consistently, you save time thinking about how to log your message and it allow you to separate concerns between logging data from processing it for various use cases like debugging, generating reports and performance.
I'll be using JavaScript as an example here, but my opinions apply to all languages.
The relationships between Collection Points, Collectibles, Blades, Field Skills, Regions, etc. are all linked up so you can easily navigate between them and find related pieces of information.
Performance Improvements
It's probably not very noticeable on a desktop computer, but I've optimised a lot of the rendering logic throughout the app. There were a lot of unnecessary calculations going on when navigating around, causing a slightly longer wait time. As more data is imported, it gets more noticeable.
Things should feel a lot smoother now. There's more improvements to come in the same vein.
Next Up
I've started importing Enemy locations to the Xenoblade 2 Maps. Before I push that out though, I'll need to introduce a Legend toggle of some sort to reduce the types of markers on screen.
It seems pretty straight forward at first, but there's a lot of decisions to make. Things like:
What markers to show by default.
What to show when a user comes from an external link.
Whether to persist visible markers so that link sharing is consistent between users.
The most convenient place to put the toggle menu for desktop and mobile interfaces.
As with everything, I'll decide on a few things and improve it as I go.
April saw a steady progress towards open sourcing FrontierNav and the gradual introduction of collaborative tooling. The interface has been tidied up too: consistent colours, cleaner layout, better navigation. On top of that, Xenoblade 2's map is almost ready!
It's nearing the end of May now but it's worth mentioning May's update will come in June as usual with Progress Reports. This update was delayed by some weeks.
Xenoblade 2 Maps
The data for the maps is available now. It's just a matter of linking it all up, making sense of it and making it presentable. Can't wait!
With the recent rush for GDPR compliance, services are becoming more aware of the amount of data they hold and if it's really necessary to have all of it.
Application logs contain a variety of historical data coming from both users and third-parties, making it extremely useful when running reports and to monitor production behaviour. However, after a certain period, the burden of responsibility will begin to outweigh the usefulness of the data. Once that point is reached, it's best to shed that responsibility.
A common way to store logs is to put them on AWS S3. But, without the proper configuration, those logs will remain there indefinitely. You could manually delete objects or set an expiry when they're uploaded but there's an even more convenient solution built into S3: Lifecycle Rules.
At Unruly we use Terraform to provision our AWS resources. So, I'll be showing how you can do the same to enforce your retention policies. Before continuing, you'll need to familiarise yourself with Terraform's basics.
Apparently, the current implementation may cause Firefox 60 to crash. This has been fixed in Firefox 61 which will release in June 2018. So if you encounter any crashes, set network.trr.mode back to 0 (i.e. off).
Recently, I've been thinking about browser support for FrontierNav. Most browsers support native ECMAScript 2015 (ES6) code natively, but somewhat popular yet unmaintained browsers like Android 4.4, Internet Explorer 11 and Chrome 29 have been holding things back.
So, I decided to drop support for them and go full ES6 in production. I thought the ecosystem and build tools were ready. I was wrong.
