Weekly Report: 15th July 2019
FrontierNav
- Unified data across every game
- Added data tables to every game
- Improved search performance
- Fixed various navigation bugs
- Progressed ideas on static generation
- Further improved security headers
Blog
Thoughts and writings.So Many Security Updates
It seems every week there's a new vulnerability found in an npm package. While this is great progress for the community, it's a pain to deal with when maintaining multiple projects. Automation is a solution, but then you need to maintain the automation. Removing dependencies and writing your own just means you'll probably have vulnerabilities that you don't know about since no one's looking. Eventually dependencies rot and security issues take over. At that point you need to abandon ship and find a new one.
It's an unsolvable problem as far as I can tell.
FrontierNav Search Performance
I've become more comfortable using Web Workers now. My first implementation of it for the Universal Search had a single global Worker searching across multiple indexes. Now, there's one for each index, created only when Search is activated and discarded after. I really can't tell what difference it's made since there aren't any Dev Tools that show individual performance metrics, but from an implementation point of view, it makes a lot more sense. There's no point having Workers waiting around, hogging resources.
Agility Bug Fixes and Maintenance
Agility, the mobbing timer I made a while back, had a bug report. Since it's just a single web page, I recently stripped it down from a Middleman static generated site, to a simple static site with no build step. It's a lot easier to maintain now. I'm still a bit reluctant to be maintaining it though since it's not something I use anymore and I'm not getting anything out of it. But it's not a big deal.
FrontierNav Static Generation
FrontierNav is a JavaScript heavy application. So much so that loading it up without JavaScript will just show a warning. This is fine, since without JavaScript, FrontierNav becomes a bare bones wiki and there are plenty of better wikis around.
However, it does cause issues with search engines, social network sharing and others where they expect relevant information in the HTML on request. Google's search engine does use JavaScript, but others like Bing don't. Share a link to FrontierNav on Twitter and you'll just see a generic embed. This is a problem as it means FrontierNav isn't interacting properly with the rest of the web.
The proper solution to this is "Server-Side Rendering" (SSR). I've tried SSR before, but it doesn't work. A lot of the code wasn't made for it in mind so it just fails. To fix it would mean going through a lot of code and also making sure any future code works in both cases. It's a big investment.
An alternative I've been thinking of is to go through every page in a web browser and dump the HTML. I've tried it this week using Puppeteer to automate the process and... it works.
There are a few issues though: cache invalidation (as always) and deciding where to run it. It can't run server-side since it's using a whole web browser which is slow and eats up a lot of resources, so it'll need to run in parallel. Which in turn means it'll need to know which pages to cache.
Right now, the experiment is using the sitemap.xml to scrape FrontierNav. That works for the more simple pages. But pages like the Maps have potentially hundreds of elements, and dumping all of that into HTML will be ridiculous. These pages are the most likely to be shared on social media. I could strip the excess post-render, but then the solution becomes more complex, at which point SSR becomes more appealing again.
Running in parallel is also a lot of waste since the vast majority of pages won't be directly navigated to. I could make it more intelligent and have it use access logs to find the pages it should cache, but then it's caching after the fact so it'll always be one step behind.
Decisions. Decisions.
Weekly Report: 8th July 2019
I wrote this entire blog post and it was really long, so I broke it down into separate posts. This is just a summary.
FrontierNav
- Data can now be completely edited, but there's no way to save changes yet.
- Restricted which scripts and resources get to load on FrontierNav for security.
Linux
I spent a lot of time sorting out my workstation. It's a bit long and boring so I wrote a separate blog post on it.
Thanks for reading.
FrontierNav Security - CSP and SRI
I can't remember how I started going down this route, but I do know that as someone with multiple websites, I should be doing the most to ensure nothing malicious is being loaded onto my viewer's computer.
Actually, I do remember. I was looking into how FrontierNav can introduce an iframe-based, postMessage API to allow third-party integrations -- an exciting topic for another time. Loading iframes from other places is of course open to abuse, so I looked into securing it.
Linux Madness
My sound card died this week. I didn't mind. A year ago I assumed the inteference coming from my speakers was from my motherboard's on-board sound so I bought a PCI one, avoiding an external one so that I don't have to deal with more cabling.
When I switched from Windows to Linux as my main operating system, the main issue I had was with drivers. Sound (Asus), Wi-Fi (Broadcom) and Video (Nvidia). They're all propertietory and Linux support is abysmal thanks to various free versus proprietary conflicts in interest.
I use CentOS on my servers, so I thought I'd try Fedora. But since Fedora has a Free Software policy, most of the drivers weren't officially supported. The sound didn't work at all. So I chose Linux Mint which came with everything out of the box.
After a few months, I noticed my speakers were still picking up random radio stations every now and then so I bought new ones. Problem solved. I didn't notice a difference in sound quality either with the sound card. So it was all a waste of time.
It seems since then Fedora 30 has greatly improved its support. After the sound card died and with the issues I've been having since last week, I gave Fedora another chance. This time, everything worked -- except the WiFi, so I switched over to my old PowerLAN, which now works because I relocated my router to a different room. Though, I'm not sure if the PowerLAN or Fedora is the cause of the random lag I've getting on my network. What a mess.
On the bright side, I actually like using GNOME now. I've always been an Xfce fanboy, but I've had do deal with a ton of caveats over the last year. Firefox flickers randomly and gives me a headache. The panels go out of sync with my multi-monitor setup. Music stops playing when I lock the screen. Screen tearing everywhere with Nouveau drivers. Broken resolutions with Nvidia drivers. The list is endless.
I wonder what new issues I'll run into over the next year with Fedora...
Still better than Windows 10.
Thanks for reading.
Weekly Report: 1st July 2019
Weekly Report is going to be a new series of blog posts giving an update of what I did in the current week. The aim is to share what I've done and also to help me appreciate and compare my acheivements.
While there will be FrontierNav-related updates in this series. They'll also contain unrelated updates related to my other projects. If you just want FrontierNav updates, you can wait for the monthly FrontierNav Progress Reports.
FrontierNav Report: June 2019
Changes in June
In case you're wondering, April and May don't have progress reports.
User Profiles
- You can now see a "Current Goal" for each game. This is like a per-game status so others know what you're focusing on.
- Game-specific user profiles show the current goal and recent posts.
- Global user profiles now list recent goal updates and posts.
- Avatars now have a customisable background colour.
User Settings
- Overhauled the user settings look and feel.
- Look and feel for all future forms will follow a similar style.
Community Feed
- Added list of recently active users
Universal Search
- Overhauled the search look and feel.
FrontierNav Editor
- Started implementing the editor, work in progress.
