Returning to the Moon: Launch-Failure Safety

Proof-of-concept for deployment of Hexo-generated static blog folders on my Windows 10 PC to one of my hosted-site blog folders is confirmed.  I can set up an optimized 1-2-button publish mechanism.

The next proof-of-concept is to have a source-code management and recovery mechanism for Hexo-operated authoring folders. 

I’ve confirmed that Visual SourceSafe 2005 is usable on the Windows 10 PC where I will perform authoring.    The VSS repository is located on a separate local machine that houses my development web server where there are recovery-usable mirrors of my public, hosted web sites.

Backup and source-code version control using the web-development VSS repository covers all but one folder of the experimental authoring folder.

The VSS client on Windows 10 shows the HexoWingnut folder holding backups of the wingnut/ authoring folder now under source-code management

The hexo-created wingnut/node_modules/ folder cannot be backed-up to the $/HexoWingnut VSS Project folder.   VSS prohibits file names starting with “$” and there are some of those.  Fortunately, there is no need my source-code management of node_modules.  I won’t be touching it.  Recovery can be from normal backups if not Hexo.

Although Visual SourceSafe is no longer under development and there are more appealing source-code management approaches these days, it is very handy in this case.

  • I already have it and I have workflows where it is already tied into support of my web-site development and mirroring of the material published to my hosted web sites.
  • Using VSS source-code management for my work in the authoring folder, including modifications of the Hexo and theme materials, will avoid collisions with parts of the authoring folder that are cloned from GitHub and may be updated from their GitHub origin.

Next Steps: Customization of a Hexo theme for satisfactory blog operation, writing about my current projects,  and removal of Movable Type software from my hosted web site. 

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

Returning to the Moon: Mercury Retro

For restoring my blogging capability using modern static-blog generation, I have completed an initial end-to-end proof-of-concept: confirmation of direct-publishing capability from my Windows 10 PC’s authoring folder to my hosted-site blog-folder location.

End Points

  • The launch pad is a Hexo-created authoring folder, wingnut/, on my Windows 10 PC.
    • There is a barely-usable initial configuration of theme Polar Bear.
    • The Hexo-provided “Hello World” post is all there is.
    • Operation “hexo generate” produced blog-site content with that single post in authoring-folder location wingnut/public/.
  • Splashdown is into my hosted-site location of blog “Spanner Wingnut’s Muddleware Lab” (“Wingnut” for short).
    • “Wingnut” is a sandbox for experimentation and confirmation of blog setups before I migrate more-serious blogs.
    • It preserves the original, Blogger-produced “Spanner Wingnut” posts, archives and feed.
    • It preserves the subsequent sandbox work using Movable Type posts, archives, and feed.
    • The deployment of Hexo-generated material to this site location shall not splash on any of that material.
    • This situation applies to all locations where I have existing blogs to migrate.

Sub-Orbital Transfer

The Windows 10 Pro File Explorer provides file-folder access to FTP servers.  Simply type the ftp name (here, in the location field and click Enter.

FTP login is by typing the ftp server location in the File Explorer location field and supplying login credentials

The dialog has not been modernized along with the evolution of Windows.  It appears to be a still-supported legacy feature.  It will do the job.  The warning about FTP making unencrypted transfers is also important to appreciate.

After log-on and navigation to the proper folder, files can be copied manually.  That’s sufficient for proof-of-concept.  Refinement comes later.

The five folders and two files of the generated author material (first folder view) on the PC are dragged to the splashdown folder reached by FTP (second folder view below).

The authoring folder generated public/ content is selected and dragged to the FTP-accessed hosting-site location without any conflicts, leaving current material intact

None of the Hexo-generated material splashes over existing material of the splashdown location. 

Safe Landing

The Hexo-generated blog’s entry page is at index.html.   The safe landing has the expected minimal page at first.

The Hexo-generated home page displays properly from the uploaded index.html location

Following the “Hello World” link successfully reaches the full content of the test post.

The Hexo-generated initial post is correctly linked from the  blog home page, showing the desired light content of the Polar Bear theme

Although the blog page “Archives” and “About” links are not connected (and no About page has been authored), the Hexo-generated archives folder is present and occupied with a correct entry and link.

The Hexo-generated archives folder is not connected to the other pages.  It is present and connects to the default initial page supplied by Hexo.

I am declaring victory for proof-of-concept.  Streamlining and optimization of the upload process comes later, along with further customization and organization of the blog.


  • Hexo-generated blogs uses index.html for the blog home page.  
    • That is necessary for local “hexo server” viewing of the authoring folder.
    • On the hosted-site, I had intentionally made index.html subordinate to index.htm which is subordinated to default.htm in the search rule for folder default pages.  Automatic production of indexes at the server is not permitted.
    • Requiring index.html  is a fortunate coincidence.  It allows for a sandbox for static-generation confirmation without interfering with existing content.
  • My site architecture requires default.htm for the blog home page.  The index.htm page is reserved as part of site-wide scaffolding and construction annotation.
    • Before migration to Hexo-generated static material, I will preserve the existing default.htm page under a new name.
    • The production deployment scripts for Hexo-generated site content will  copy  public/index.html to public/default.htm before posting to the hosted site, blending into the site-wide architectures.
    • Migrated Hexo-generated blogs will provide links to the archives, feed, and last post produced earlier with  Movable Type and/or Blogger.

Onward to the next challenge.

Posted in Blog Development, blogs, Golden Geek, Spanner Wingnut, Toolcraft | Tagged , | 1 Comment

So Close, Yet an FTP Too Far?

I am continuing my investigation of Hexo, a static blog generator that has these useful characteristics:

  • Hexo installs and runs under Node.js and runs in JavaScript.
  • The generated public/ directory consists of static material that can be uploaded and served from any conventional web server, with GitHub a popular choice
  • There is an ecosystem of plug-ins and customizable themes

There are some worrisome concerns around how to customize the blog.

It is important to stop fretting about perfecting the blog though.  Instead, I need to confirm an end-to-end approach that takes a proof-of-concept simple blog through the workflow necessary for publishing on my hosted web sites.  Only then should blog design be addressed.

Here’s how I am explaining all that to myself.

Authoring Configuration

  • A local authoring folder is created on my PC.  The authoring folder is set up by Hexo for generating web pages of a single personalized, customized blog.     I will have an authoring folder for each of my published blogs, along with some number for experimental purposes.
  • A fresh Hexo-initialized authoring folder includes a pre-installed default setup for generation of a simple blog that can be viewed locally and authored immediately.
    • Verify installation and first-run by viewing the pre-installed “hello-world” initial post via the default setup.   
    • An initial theme,  “landscape”, is pre-installed and enabled.  This establishes the appearance of the generated web pages and other aspects of the published blog site.
    • The initial configuration will need some customization for the title and published location of the generated blog. 
  • Practically everything in the authoring folder can be customized.  
    • Some customizations must be enabled by NPM installation of plug-ins for Hexo to employ as directed by edits to configuration files.
    • Installation of theme definitions in the authoring folder is typically by cloning them from GitHub projects.
    • Themes also require configuration and may be customized further.
  • It is unclear how to manage and backup an authoring folder.
    • Providing preservation and source-code management of local customizations and of the authored sources of blog content.
    • Providing for possible updates to downloaded themes that have been customized locally.
    • Providing for possible updates to the Hexo-provided basic configuration and its initial content that may have been customized locally.

Not So Fast, Sparky

I have several requirements for authoring new posts of existing blogs of mine.

  • Atom feeds of each Hexo-generated blog, with the feed locations already used
  • Root-entry of the blog provide at least the latest full post on the default page, with links to the chain of previous posts and the archive of posts by year and month
  • Previous – Top – Next post links for navigation are valuable
  • Having Tags and Categories
  • Having DISQUS for comments
  • Having a light appearance with legible colorization of code blocks and pleasant quotation blocks
  • Providing social-network information, an author page, and similar information

All of these are achievable with existing Hexo plug-ins and themes.  Having them all in combination with an authored appearance, a private theme, that works for me is the challenge.

I have been dithering around learning how to customize an authoring configuration that satisfies all of my requirements.  What I am learning is how little I have of the tacit knowledge that the authors of templates must have.  I also don’t know where there is  documentation that I need.

I am also fretting over the wrong problem. 

What I need most of all is a nearly-one-click mechanism where I can author a blog post, have it generated, and have it appear near-instantly on my hosted site.  That’s what I have right now as I use Open Live Writer to compose and then publish this post, even though it goes to and not any property of mine.

With the point of generation being on my local PC, the question is, “How do I get deployment from there to the hosted site with 1-2 clicks?  How do I integrate that into my site mirroring and backup arrangements?

I need to stop fussing about having the generated blog be perfect and start with something that is minimally adequate.  There is no point in further refinement until an effortless deployment arrangement has been confirmed.   That’s the critical proof-of-concept.

Deployment Concerns and Approach

  • I want to publish in the same location as my existing blogs, in a manner that preserves the previous content
    • So far, there is no conflict with the material that Hexo generates, in the authoring folder public/ subdirectory, so the Hexo-generated blog content can sit side-by-side with the older pages and archives of the previous version. 
    • Hexo uses index.html as the default root page of the generated blog.  For technical reasons, I may have to use default.htm.   I can work around that on my servers without changing anything in Hexo.
    • I do need a publishing mechanism that will leave the old-blog material intact when uploading new/updated Hexo-generated blog content.
    • I need a backup and source-code management system that covers a complete authoring folder.
  • Direct Publishing
    • I will directly FTP new generated public/ files to the hosted site.   There are a number of ways to do this.  I will want to find one that  can be turned into one-click operation via a batch script or by use of the hexo deploy command.  
    • Having an effective direct-publishing approach needs to be confirmed first.
  • Backup and Source-Code Management
    • If the Visual Source Safe repository co-located on my web development server can be reached from Windows 10 on my PC, I can put entire authoring folders under source-code management in appropriate Mirror VSS projects of the nfoCentrale Web Deployment Pillars.  
    • This protects against customization loss when Hexo themes installed by cloning from GitHub are updated from GitHub. 
    • This, with appropriate included documentation, also supports any need to completely re-initialize an authoring folder.
    • The use of VSS in the Hosted-Site Mirror Projects also supports restoration of the blog (and more) from a mirror of the hosted site.
    • This or an equivalent is needed before I risk too much authoring-folder customization without any good backup, recovery, and source-code management.
    • Having an effective source-code management and recovery approach needs to be confirmed next.

Simple early steps.  Fail early if fail I must.  Recover quickly.

Posted in Blog Development, Toolcraft | Tagged , , , | Leave a comment

Awaking from Slumber

I lost the blog habit.  It appears I am not alone.

Distractions that took me away from my self-expression on blogs and in development of some personal software projects have ended.  I have been slowly restoring the software-development and computer-science explorations that have called to me in my Golden Geek years.

There are some key themes to be developed further as I perform the considerable maintenance to have my internet presence fully restored. 

Two immediate efforts: The Miser Project and Blog Restoration.

The Miser Project

I have been a fan of functional programming since my first exposure in the mid-1960s.  I have been musing about a miniature approach in applicative style ever since, noodling on that formulation since being at Stanford for the first-ever Lisp (now ICFP) conference.  The maturing idea is to provide a practical demonstration of computation-theoretical aspects of software and also how programming and software development navigate abstractions.

It is time to make that work more visible.  Some baby steps are underway.

  • Restore the Miser Project site for delivery of updated and new material.
  • Start a GitHub Project for work on proof-of-concept implementations, to be grown to a stable operating version of the core interpreter and an usable interface.
  • Create a Facebook Page as a way to rapidly capture notes and make the effort visible.

It is neither coherent nor visible so far.  Restoring the Numbering Peano blog will help.

Blog Restoration

In 2010, Blogger ceased providing FTP publication of static blog pages to author-controlled web sites.  I am determined to have static, plain-as-possible sites that are easily preserved, readily accessible, and not subject to the life-cycle of a blog publishing system.

Even the use of is a stop-gap substitute, as was the experimental Windows Live predecessor of “Orcmid’s Live Hideout.”   The advantage is that I can use Windows Live Writer (now Open Live Writer) for easy publishing, if I bother to do it.  The disadvantage is with the blog being hostage to a third party and providing advertising that I have no control over.   Orcmid’s Live Hideout will eventually be merged back into the Orcmid’s Lair blog, once that dormant blog is revived.

My first effort at taking control over my several blogs was to install Movable Type 4.  The choice was based on wanting static pages to be created and preserved, using a database for creation but not for access.  This is out of fashion.  I failed to complete the efforts first-established at Spanner Wingnut’s Muddleware Labs and nfoCentrale Status.

Next Steps for Blogging

  • Explore use of static blog generators that provide modern static pages on the server, even though they impose more effort on browsers.
    • Hexo is selected for investigation and proof-of-concept
    • Icarus is promising as a customizable theme
    • Resolve workflow and content-management challenges for having blogs under source-code control without authoring-to-publishing requiring too many steps. The published blogs must fit into the nfoCentrale construction structure and site-server preservation/publication architecture.
    • Switching in a replacement blog will preserve the previous posts and archives so that all historical material is retained and accessible.
    • Demonstrate cutover with Muddleware Labs demonstration of a successful process.
    • The second cutover will be with Numbering Peano in support of The Miser Project.
    • Relaunch nfoCentrale Status so that Movable Type can be removed.
    • Dismantle Movable Type on in a form that preserves all existing posts, their archives and assets.  Move carefully while eliminating the presence of now-obsolete code on the server.
    • For Orcmid’s Lair, migrate Orcmid’s Live Hideout to the cutover blog along with the development of new content.
    • Migrate remaining blogs as needed.
Posted in Blog Development, blogs, Golden Geek, Miser Project, Numbering Peano | Leave a comment

Welcoming Open Live Writer

Although many have asked for it, today was the day that a team of Microsoft and other Volunteers managed to fork Window Live Writer to become Open Live Writer under the .NET Foundation.

I am creating this post with Open Live Writer right now.   It is version 0.5. 

I noticed it picked up my blog history that was on my system, including unpublished drafts.  Nice.

In the past week I had already become excited about Visual Code, a lean mean and very appealing code editor with the look and feel and some of the great functionality of Visual Studio, built into a source-code editor that loads and runs very quickly.  Also open-sourced and on GitHub, it has an exciting execution and plug-in model for developing collaborative distributed operation.  

I can see both of these tools growing into parts of a powerful multi-platform ecosystem for geeks. 

Visual Code is essentially JavaScript and Python built, with a smattering of node.js and some interesting frameworks from Google and elsewhere.  It works on Windows, Macintosh, and Linux.

Open Live Writer is more on the C# end of things, but that can be multi-platform too, now.

Another reason for my excitement is these are desktop GUI applications of a scale and directness that may be great avenues for many novice and hobbyist developers to get their teeth into and begin to develop class applications.

Oh boy, … .

Posted in nfoWare, nfoWorks, Toolcraft, Windows Live Writer | Tagged , , | Leave a comment

Identity Is not a Thing

It is amazing to me how many ways notions of identity are employed and how nebulous identity itself remains.  Consider all of the variations identified in Wikipedia.  Contrast the social-science distinctions of identity with the tacit assumption of identity as a definite thing in “specifications of persons” and the way personally identifiable information (PII) is spoken of as pertaining to identity.  

These different explorations of ‘identity’ demonstrate how difficult a concept it is to pin down. Since identity is a virtual thing, it is impossible to define it empirically. Discussions of identity use the term with different meanings … .  In any case, the concept that an individual has a unique identity developed relatively late in history. [Wikipedia]

I agree that each of us might be distinguishable and identifiable in various contexts, including via manifestations of ourselves in the digital realm: cyberspace.  I don’t think my being identifiable requires there to be an identity, so-called, that is distinguished and is what is identified.  Yet that way of speaking seems to be common. 

I am not my driving license.  I am identifiable with it, to some degree.  I say it was issued to me.  It does not express my identity.  

I also wonder, in the pursuit of some sort of absolute/complete identity, how witness protection programs and anonymity are expected to operate.  Or could it be that there are only trusted legends, not absolute identities, arising in our social existence and experience?

I have come to the conclusion that there is no thing that expresses a unique identity for me.  I propose, therefor, to be rather detached about assertions concerning identity as some comprehensible thing.  I propose to examine how we and others are identifiable, casually or more formally.  At a personal level,

  • How do we recognize, however reliably, activity and presence of others, especially in cyberspace?
  • How are we made known and recognizable to others via activities and presence, especially in cyberspace?

I suggest those questions can be explored satisfactorily without requiring a tangible capture of identity.

The “Identity” cachet is too seductive to be given up.   Just the same, when I encounter such notions as “Identity Theft,” “Identity Management,” and “Identity Ecosystem,” it is useful to consider that such Identity is not a thing.  From that position, apply critical judgment to determination of what is actually involved, identifying what is tangible and useful about those notions, thus grounded.

Identity.  It’s not a thing.  You can’t have it.  You can’t hold it in your hand.  You can’t write it down.  You can’t sell it or buy it.  You can’t transfer it or bequeath it.   You might not even be able to protect or damage it.  And you definitely can’t take it with you.

[update 2014-04-30T16:04Z A lingering typo cried out for removal.
update 2014-04-30T00:26Z: There were some wordings I had to adjust upon seeing them in the published post.]

Posted in Civil Society and Democracy, Computers and Internet, Privacy and Security, Social Networking, trust | Leave a comment

Guardian, Dictator, Manager, Mentor, or Collaborator Be?

For open-source projects that I initiate, I want some way to acknowledge differentiation of roles that permit me to preserve in some friendly way my vision of what is essential for trustworthy development, releases, and life-cycle support.  I settled on the idea of being the project Guardian while recognizing there are benevolent dictators, managers, mentors and collaborators with low-friction use of source-code management.   For decentralized participation, that means getting my head around guardianship using Git.


The open-source projects to which I pay the most attention are little nanoISV projects of my own, where I am almost exclusively the sole developer.  Indeed, you are pretty deep into my collegial inner circle if you are aware of any of them.

I also use source-code management for everything.  I use it in the development of my web sites.  I use it in all manner of software projects, even little throw-away and practice projects of any kind.   I’m surprised that I use it so little in other kinds of digitally-born activities, although I do have personal document-management practices.

The Politics of Tools

Source-code management systems do have political leanings with regard to how collaborative development works.  With some systems, one can pretty much set up a structure without worrying too much how branching, forking, and working will work, and how various contributions will work.  At least, I always thought so.

I have finally had to look at Git with regard to the kinds of project organization that it encourages.   Although I am still learning, I have in the back of my mind that Linus Torvalds had his own interests as the total dictator of the Linux kernel in mind when he figured out Git-based collaboration workflows that would allow him to manage all of the contributions that are made to the Linux kernel.  It is his model that I am interested in.

Although the idealization of Git is that all of the distributed repositories are equals among many, and this is literally true, there are reasons to have different levels of authority associated with particular public repositories.  I recommend the presentation of Linus Torvalds on Git for his views on that subject and how it fits with the practice of curating contributions to the Linux kernel.

Dictator versus Guardian

I am certain that I want to be the dictator.  I just don’t like the title.  Not even “benevolent dictator.”   Dictator doesn’t fit my picture of what a trustworthy collaborative arrangement should look like.

I’ve settled on “Guardian.”  I saw that used in a tutorial on Git Workflows as part of Using Git with Visual Studio 2013, and I like it.  It works like this.

Decentralized Repositories and Project Roles

There is an official integrated baseline repository.   (Sometimes, it is a set of repositories, but we’ll think of that as virtually one collective repository.)

The baseline repository is the master truth of public project artifacts and their history.  It may be organized a number of ways, but it is all about that.  I also think it is all about how the deliverables of the project are derived, documented, and deployed, whether that is simple or complex.   The baseline is backed-up and it can be inspected for the complete project history, of course.  And many people can have clones of it that preserve their provenance with respect to the baseline at the point it was cloned.  If there is ever need to make a forensic investigation as part of incident resolution, the baseline repository has what’s needed.  

Measures to maintain the integrity and provenance of the baseline repository will be appropriate depending on the nature of the project and its artifacts and the level of dependability and authenticity that is to be assured.

New work starts from a baseline.  Developers, including contributors, clone working repositories from the baseline repository.  They might continue completely independently, basing a fork on the baseline but never expecting to contribute back to the advancing baseline.   They could have the clone for testing.  They could be developing a fork for any purpose.  To maintain future synchronization of the fork with changes in the baseline, they will have a private branch structure that is amenable to merges from the developing baseline.

Contributors have share-back structures.  When developers are working on contributions to be made back to the baseline project, they can make their modifications and additions available to the original project in some semi-private manner.  This can be via their own repository or a public repository of theirs to which they publish (“push”) their contribution.  The contributor semi-private repository could also be a repository/branch of the baseline repository to which the contributor is authorized to push contributions and from which the guardian and any delegates can pull or merge those contributions to a public release.  (Casual projects can be without authorization barriers, at least among the few participants of such projects.)

Auditing and accepting contributions.  It is the guardian, or delegates (feature managers or leads, say), who pull contributions to their working repositories for verification and integration.  Contributors might have pull access to those repositories so they can align their contributions to the result of any adjustments made by the leads.  Ideally, leads request changes from the contributors and do not generally do the modifications themselves.  This is part of the community spirit of Apache Software Foundation projects, for example.  Torvalds has a practice where he does not resolve contribution merge conflicts himself.  He requests that the contributor whose contribution exposes the conflict resolve it.

Reconciliation at intermediate staging.  The guardian and the leads have whatever arrangement they require for review and developing an integrated view that is pushed to the public base repository.   In one approach, the guardian has master development repositories to which changes are merged from the leads (or the contributors where leads are not involved), and the reconciliation is then published to the integrated baseline, which is always collision-free.  This must be history-preserving where the provenance and chain of custody back to original contribution must be preserved.

No one is everybody at once.  I think the guardian hat should be different than a lead hat.  To the extent that the guardian is also a feature lead/manager, those roles should be kept separate.  In particular, the guardian hat should not require having to accomplish merge conflict reconciliation.  That is a manager/lead responsibility.  And, ideally, contributors would already have done that, but for the fact that there may be multiple contributors making changes that may lead to conflicts in the integration of their branches. 

Feature-oriented development.  If a feature is being coordinated this way, a feature lead might have the only working integration of feature contributions at intermediate times, though.  There are ways to keep this public, if only by having the feature-integration repository part of a set of repositories that are the collective integration baseline, with some of them having more ephemeral activity than among release material.  This might work for subprojects, too.  

This doesn’t square with having all of the truth at a single baseline (or reference) integration all of the time.  These concerns are beyond the reach of my personal-computing focus, but scale does seem possible, and I’m satisfied that’s enough to move ahead.

Mentoring is different than managing.  In this picture, guardians and leads can also be mentors, although mentors don’t have to be leads or managers.  A mentor works with contributors that are new to the project to help them fashion contributions that satisfy the development norms of the project.   Mentors are seasoned contributors who work directly with new contributors in having them fashion satisfactory contributions.  Mentors have in common with managers the desire for the development and success of the contributor.  Mentors can rely on the guidance of leads and the guardian with regard to project direction and process requirements.

Contributors are created equal and not the same.  I have been speaking of contributors as developers, new or experienced, who want to be direct contributors to the project and who are or aspire to becoming adept users of the project repository and its artifacts.

Contributions can be casual.  Contributors might only be interested in submission of patches or tests or documentation corrections that have pretty low ceremony.   Contributors might report bugs and not have the capacity or interest to identify the specific defect and propose corrections.  That’s all good.  The leads and guardian will encourage and acknowledge such effort in the trustworthy projects I have in mind.  Contribution is a precious act to be honored.

Distinguishing the guardian.  I think the guardian’s responsibility, at any scale, is to be accountable for the articulation and preservation of the conceptual integrity of the effort and its products.  

You can think of the guardian as the chief architect/engineer of the undertaking.   The point is where the guardian focuses, something that the guardian should not be distracted from, as happens so easily when immersed in other, nose-in-the-code roles.   The same is true for project management, especially for a solo developer or a low- ceremony team.  Someone has to keep their eye on the ball and that means not doing anything else at the time.

The Mixed-Blessing of Small Projects

For small projects, guardianship, feature management, mentoring, and contribution will involve the same person(s).  It is important, in that case, to have periods of activity when only one of those hats is being worn at a time by any individual.  That’s how to ensure that the perspective required of the role is brought to bear without the distraction of other concerns and interests.  That applies to the extent that project management roles are required as well. 

It can be difficult for a solo developer to switch hats when required.  It is valuable to be part of a team that assists its members to keep their hats on straight, whatever the wardrobe of the day happens to be.  This can also be aided by colleagues who are not all working on the same project, but who can provide buddy-support.

It doesn’t have to be hierarchical.   It is easy to see that guardianship, management, and mentoring are all aspects of leadership roles.   In a fluid team, these roles can move around, often spontaneously with little or no ceremony.  Specific accountabilities for set periods emerge when scale requires clear points of contact and visible, confirmable process.  It’s about structures for workable communication and reduction of friction in achievement of a common purpose.

Repository Versus Project Structure

I was led to this thinking because I am designing a project where Git is to be used as the repository.  I don’t think it matters whether a distributed or centralized version-control system is used for management of project artifacts.   The philosophies that the different approaches engender are adaptable enough, it seems to me.  

On the other hand, Git was designed by someone who wanted loose coupling and flexibility among developers while also providing a way for the benevolent dictator to easily review and accept contributions to a project with very high provenance and artifact integrity.  I wanted to understand how Git affords that.  This guardianship explanation is what I arrived at for structuring small projects that can scale to full-blown guardian cases as project growth might require.

Posted in Geekiness, nfoWare, nfoWorks, Professor von Clueless, Toolcraft, trust | Leave a comment