Miser Project: Hark! Is That a Theory I See Before Me?

Once I have a stable experimental setup at the Spanner Wingnut blog, I will systematically revive my permanent, persistent blogs.  My agitation over the restoration of blogging and the use of hexo to generate static server pages reflects my anxious desire to restore Numbering Peano, the blog devoted to The Miser Project and related theoretical topics.

Pending restoration of Numbering Peano, I had begun writing about my capstone career project on a Facebook Page and on GitHub, where there are also preliminary (mock-up) demonstrations of implementation.  Issues on the GitHub project have been used to address questions and provide preliminary documentation.

At the moment, documentation is in plain-text files on GitHub.  That may continue as an ultimately-dependable form of persistent record.   When the hexo-generated pages are reliable, that will have the additional advantage of formatting with images and, most-important, formulas.   Mathematical notation expresses the bridge between the mathematical theory and the operational computation system for Miser.  Web pages can be arranged to do a better job.

At the moment, reliance on mathematical notation is confined to text and the use of Unicode encoding of the text.   Without the notation support for blog pages, the most reliable means of presenting the plain-text form on the web is via images.

The mathematical aspects of Miser are expressed in text using UTF-8  codes for important notational characters for logical notions in the theory

Having web pages and others, expressed in the GitHub MarkDown notation, allows for greater expressive power.  Text has, within its limitations, useful control over layout.  We’d like both, and wrestling the hexo-generated pages into a stable form, with support for mathematical formulas, is the chosen avenue.

Advertisements
Posted in Blog Development, Golden Geek, Hexo, Miser Project, Numbering Peano, Spanner Wingnut, Toolcraft | Tagged , , , , | Leave a comment

Returning to the Moon: Fire Suppression

I have relied on RSS feeds for all of my blogs, including this one, and collecting blog posts of others.

It was satisfying to enable  an RSS feed on the experimental hexo-generated blog now at Spanner Wingnut’s Muddleware Lab.

As part of the PC repaving mentioned the other day, it dawned on me that I have no RSS feed reader installed any longer, and I have no idea if I preserved the history of the discontinued FeedDemon Pro software that I had kept limping along for years. 

I had it in my head that I had failed to backup the FeedDemon database someplace separate from my system drive.  Either way, I chose to reinstall FeedDemon so that I could at least see recent blogs and, especially, confirm the Spanner Wingnut blog hexo-generated RSS feed.

FeedDemon installed with an empty database, and I did find one on my D:\ drive, the one unaffected by my reformatting and reinstall on my system drive.  It took me a bit to realize that this is all called “cache” and the FeedDemon File | Manage Cache menu item allows me to switch to the previously-operated cache. 

Restored FeedDemon restores history and finds recent posts

The current RSS content from Spanner Wingnut is also found, and the plaintext is correct, though not with the exact styles.   On linking to a post, the known Internet Explorer rendering failure is exhibited.

FeedDemon uses Internet Explorer for its internal web browser, exhibiting the same problems when Internet Explorer is used directly.

There’s no escaping this issue, and here’s a case where I can’t control what is used for embedded viewing of blog posts.

I thought I might learn something by viewing the oldest Spanner Wingnut post through the feed.  Not a chance.   Hexo regenerates all pages when it regenerates any of them, and past evidence of something different is eradicated.

I will blunder along.  It is becoming pressing to have the experimental blog stabilizes so that I can replicate the generation scheme for production blogs that it’s urgent to re-activate.

Posted in Blog Development, Hexo, Spanner Wingnut | Tagged | Leave a comment

Returning to the Moon: Escape Tower Incident

There have been a couple of setbacks in my efforts to restore self-hosted blogging capability.  I found a browser/server incompatibility that breaks my brain.  And then I had to do a fresh system drive and operating-system reinstall on my main, development PC.

Browser/Server Flummox

The hexo-generated Spanner Wingnut experimental blog seemed to be going great guns.

The blog appears correctly in Edge and Chrome

Apart from some simple style adjustments, the experimental blog seemed ready for customization and revitalization of my “production” blogs.

Everything works well under local testing and on the live location, using Google Chrome and Microsoft Edge.  The local server also displays properly using Internet Explorer.

The hosted web fails to be browsed properly using Internet Explorer, though.

The page display is completely ruined when using Internet Explorer to access the web-hosting site, but not the local machine server

The complete failure is with Internet Explorer only when accessing the hosted site.  That is completely baffling.

  • It is conceivably a server setting problem, perhaps something to do with MIME types of served content or even something in the formatting of CSS and JS components.
  • It is unacceptable that the site not be viewed properly with what remains the default browser for many users.
  • It appears that the image formatting is a problem, but I notice that the styles for remaining parts of the page are also disrupted.
  • There is nothing revealing when viewing the HTML served up by the hosting site.

My failure in not testing the deployed site in Internet Explorer from the beginning means I don’t know what customization changes first produced this result.

I am willing to remove the top-page image and simplify the top banner, in hopes that eliminates the difficulty. 

I am gathering myself for digging into that.  But first, … .

System-Restoration Priorities

While I was scratching my head over the browser/server failure being limited only to remote access by Internet Explorer, I managed to crater my system SSD drive.   Fortunately, I was able to use a recovery USB drive to get Windows 10 back in operation on a clean SSD.  Also fortunately, all of my data, and some installed programs, were on my D: drive, not the C: system drive.  I also had the good fortune to have code backups (GitHub) and data backups (OneDrive plus an attached USB-connected drive).  Also, many software subscriptions (Office 365, Steam, Cakewalk SONAR, etc.) make it very easy to restore software and, usually, my latest configurations and status.

I have gradually been re-installing software, starting with essential programs for everyday operation, such as Microsoft Outlook on the desktop. 

I have now successfully re-installed node.js and hexo.  The GitHub connections of my working nfoCentrale blog folders were already restored.  Now it is time to have the FTP deployment working again. 

With that last step, I can work on curing the Internet Explorer browser/server failure.

Software Engineering for Everyone

Software engineering is about having reliable processes for making dependable delivery and lifecycle support of computer software.  

There are some elements to computer-aided production and operation of blogs, and web sites generally, that pose tool-chain, workflow, and testing/analysis problems that are very unlike development of standalone PC software. 

My engineering of a dependable blogging-engine authoring mechanism requires quite a bit more software-engineering practice, simply for myself.   I need to look at how I am not creating practices that measure up to my own expectations for dependable operation.

Posted in Blog Development, Hexo, Spanner Wingnut, Toolcraft | Tagged , , , , , | Leave a comment

Returning to the Moon: Launchpad Security Penetration Exercise

There is an unexpected reward for moving source-code management of my Hexo-generated blogging to git and GitHub.  GitHub provides dependency analysis of node.js projects.  I receive an automated email about one dependency of my hexo-spanner code.

GitHub analysis of the hexo-spanner package.lock.json package reveals that UglifyJS2, depended on by Swig, has a known security vulnerability cured in a later version.

The uglify-js package is only depended on by Swig.  That places it in isolated use in confined ways under hexo.  I (will) do nothing to rely on Swig in any other manner.    I’ve dismissed the alert with explanation that the reported dependency is not exposed to the exploit.  I also created an issue on the hexo GitHub wondering if Swig can be deprecated from use in Hexo, since Swig is no longer maintained.

All in all, an amazing reward of my transposition of the Spanner Wingnut source-code management to GitHub.

Posted in Blog Development, blogs, Git, Hexo, Security Vulnerabilities, Spanner Wingnut, Toolcraft | Tagged , , , , | 21 Comments

Returning to the Moon: Tracking Network Modernization

John Stevenson has tips on bringing a hexo-authoring folder, and its themes, under Git for source control management.  I followed the first of those suggestions, although the GitHub Desktop client made the work much simpler than using Git command-line operations.

The GitHub Desktop client is used to put the local hexo-authoring folder, nfoCentrale/spanner/ under Git.   This works just fine for making local repositories that are not clones of repositories published on the internet anywhere (just yet).

When a new local repository is established, there is no association as the clone of any cloud-based repository at GitHub or elsewhere.  The first few commits establish configuration conditions on what is managed, with .gitignore and .gitattributes

First steps include adding .gitattributes and changing the .gitignore file already there, thanks to Hexo Install.   The .gitignore change has the spanner/themes sub-folder be ignored.

The landscape theme being used and customized is added into a separate local repository.

In bringing an existing folder under Git, its name must be used.  Later, the matching GitHub repository can be given a different name when the local one is published.

For each local repository, the existing material is checked-in, identifying different blocks in single commits.  Already-customized items are checked-in individually with messages that reflect their status.

When a git repository is initiated over an already-populated folder-tree, the contents show up as new uncommitted material.  These can be selectively committed to Git in a way that provides an useful initial history.

When all of the material to be tracked and change-managed is committed to one of the repositories, it is published.   Since there is no remote already, GitHub Desktop offers an opportunity to create a GitHub project. 

When the local repository has all of the pre-existing content committed, it can be published to GitHub.  The Publish action invites creation of a new GitHup repository.  The connection is automatic thereafter.

Once published, synchronization is used in the usual way for uploading the local commits to the GitHub repository.

Although the theme and the overall authoring folder are managed as separate GitHub repositories, there is no treatment as forks of any original sources.   Cherry-picking from updates to upstream sources will be reconciled when the time comes.  Similarly, if there is desire to contribute and push changes upstream, forks will be made for that purpose.

Posted in Blog Development, blogs, Golden Geek, Spanner Wingnut, Toolcraft | Tagged , , , , , | 2 Comments

Returning to the Moon: Instrumentation Coms Latency Bottlenecks

In the 2017-10-18 post, “So Close, Yet an FTP Too Far?”, Direct Publishing and then Backup and Source-Code Management are identified as critical for proof-of-concept and subsequent refinement into production practices.  

  • Direct publishing is now working smoothly, with some scale issues remaining to reconcile beyond Reducing Countdown Holds.  That’s a next-order problem.
  • Source-Code Management and Preservation is in dismal shape.  The first-choice solution impedes rapid maintenance and discourages easy authoring.

Blogging Collides with Web Deployment

There’s great appeal in the ancient Microsoft Site Server model for developing, deploying, and backing-up web sites.  The nfoCentrale Web Deployment Pillars are centered on that model.  It works well by virtue of integration between Microsoft Front Page, IIS with FrontPage extensions, and Visual Source Safe (VSS).  VSS also makes it painless to have a staging mirror that can be synchronized with hosted web sites via FTP.   In the nfoCentrale approach, the hosted-site carries static pages and all design-time operations happen with the FrontPage-IIS development server setup.

With node.js for static blog development and generation, the FTP synchronization has been made effortless.  The VSS integration is a terrible bottleneck.

The VSS client (top) distinguishes checked-out files but does not show files not ever checked-in.  The file explorer (lower image) does not indicate anything about source-control status, although checked-in and not checked-out files are set to read-only

There are several pain points.

  • The VSS client (top part of image) does not indicate whether the working folder has files that have not ever been checked in.
  • The checked-in files are set to read-only in the working folder.
  • That a file is checked out (red check mark in the top view) does not mean it has changed, only that it is checked out.
  • The File Explorer view (lower part of image) reveals nothing about the VSS status of the files.

The coordination between the file folders and VSS requires too much attention in this situation.  Also, it is annoying to start to edit a page and learn it is read-only and the VSS client must be opened and the page checked-out.  When inspired to spontaneously initiate and test new posts, diversions to check material in and out tend to be neglected, avoiding the distraction.

Superiority of Git Support

Even for solo development usage, Git support carries the day.

The GitHub client identifies changed and new material and provides check boxes for inclusion in a given commit message.  The file explorer (inset), supplemented by TortoiseGIT, shows where there are modified materials and indicates what other files are already committed.

There are several advantages from switching to Git for the hexo-authoring use case.

  • The GitHub desktop client for Windows supports any Git clone on the desktop, whether the origin is on GitHub or not.
  • The (clone) working-folder files are not locked and can be edited any time.
  • On checking for source-code changes to preserve, the GitHub client provides an easy identification of changed and new files, allowing them to be selectively committed with appropriate commit messages.
  • With TortoiseGit installed, the Windows file explorer (shown in the inset) identifies the committed, changed, and new status on each non-ignored file.  The change/current status is reflected up the file-folder hierarchy of the clone.

Make-Over Challenges

That Hexo and hexo-installable themes/plugins are all developed on GitHub creates a challenge.   That means parts of an authoring folder

  • will be cloned from forks of different GitHub repositories
  • will preserve any customizations in my own forks
  • will have changes to the originals cherry-picked into the customized code as appropriate
  • will be integrated into Git and GitHub in a manner that avoids update-collision/-conflict nightmares

There is some nervousness around this.  Inspiration will be taken from suggestions of John Stevenson’s account of his customization of a hexo-generated blog, including alignment of theme integration.

Steady As We Go

For this change, I will check everything out of VSS, then conduct the Git-integration ceremonies.  If all goes well, I can provide some precautionary VSS tracking by check-in with files kept checked out or (eventually) deleting the VSS project.

This contingency situation is precisely why I preserve version history in managed files themselves, so that change information outlives presence under a particular source-control system and survives when the files are encountered by other means.  The VSS history will not travel to Git, but the annotations in the files will.

Posted in Blog Development, blogs, Golden Geek, Spanner Wingnut, Toolcraft | Tagged , , , , , | Leave a comment

Returning to the Moon: Reducing Countdown Holds

The Hexo-generated Spanner Wingnut experimental blog is now much easier to author and to publish.   Essential features are operating and a series of “unit test” posts are now underway.   Customization is continuing based on unit test results and check-lists for feature adjustments.   Arrival at a complete, stabilized blog is in sight.  All of the customizations will be transposed into to restorations of additional blogs.

Significant improvement has been made for easy posting of new articles and content.  I finally found a one-click deploy that was a critical goal identified in Mercury Retro on 2017-10-21.   Now there’s near-effortless posting and maintenance, demonstrated by the level of activity at Spanner Wingnut.

The solution to one-click publishing is by one-way synchronization using the WS_FTP Pro ftpsync utility and a predefined control file.

The A2wingnut.ctlo file specifies settings for file syncrhonizaation between spanner/public and BlunderDome/wingnut.  Only new and changed files are uploaded to the site and nothing else on the site is touched.

I keep the A2wingnut.ctl file in the spanner/ authoring folder, along with a short-cut, A2wingSync,  that will automatically perform synchronization (a kind of push) of only new/changed files to the web server.

The synchronization is controlled by A2winnut.ctl using the A2wingSync shortcut in the spanner/ folder.  The A2wingnut.log is produced following a synchronization.

The shortcut has been edited to perform ftpsync with A2wingnut.ctl specified on the command line.  The operation is performed in the spanner/ folder.  

The shortcut is established by first creating it at the ftpsync.exe program location, copying it to spanner/, and then adjusting the properties for custom operation.

The A2wingSync shortcut in spanner/ is adjusted to take A2wingnut.ctl as a parameter and to start in the spanner/ folder

The hexo generate operation does not set any ERRORLEVEL when it encounters problems.  Instead of adding synchronization to my tidygen.bat script, I use a separate command line to initiate a desired synchronization.

When tidygen concludes successfully and the changes are OK to synchronize, a "start" command is used to initiate the ftpsync link.

The start command is needed in order to run ftpsync as a Windows application.  It is not a console application.  After the start, a separate window opens in which the ftpsync is performed and can be observed.  A log is also produced.

This part works just fine.  I am encouraged to create and post regularly now.

Posted in Blog Development, blogs, Golden Geek, Spanner Wingnut, Toolcraft | Tagged , , | Leave a comment