cdelorme
/
caseydelorme.com


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778
							<!doctype html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <title>caseydelorme.com | Casey DeLorme's Portfolio / caseydelorme.com</title>
        <link rel="icon" type="image/x-icon" href="https://d2xxklvztqk0jd.cloudfront.net/favicon.ico" />
        <link rel="stylesheet" type="text/css" href="/css/main.css#89872b9">
    </head>
    <body>
        <header>
            <a href='/'><h1>Casey DeLorme</h1></a>
            
            <nav>
                <ul>
                
                    <li><a href='/blog/'>blog</a></li>
                
                    <li><a href='/index.html'>index</a></li>
                
                    <li><a href='/resume.html'>resume</a></li>
                
                </ul>
            </nav>
            
        </header>

        <div class="content group">
            <h1><a href="https://github.com/cdelorme/caseydelorme.com">caseydelorme.com</a></h1>

<p>This site began with the concept of a simplified static site generator.  As a result I built <a href="staticmd.html">staticmd</a> first.</p>

<p>The goal of this site was to replace a traditional dynamic system with raw static content.  I would then replace (and redirect) my <a href="http://www.cdelorme.com">old site</a> with this one.</p>

<h2>design considerations</h2>

<p>One major consideration was taking advantage of content delivery using AWS S3 and CloudFront services for any static or binary contents.  This provides a significantly greater degree of scalability, in that I can create as many servers as necessary to deliver the websites static content, while binary/static files all come from one place.</p>

<p>Right now that includes images, fonts, and some static third-party css and javascript.  Because my own css and javascript are still under construction it made sense to include them using git-hash-versioning.  This ensures the browser won&rsquo;t cache incorrectly.  <em>In the future I could use that versioning to minify, name, and upload my content to S3 and use the CDN exclusively for all versions.</em></p>

<p>Another advantage to moving away from a dynamic website is that when dealing with basic static html we can enable simple caching directly through nginx without concern for other layers; there is no CMS to contend with or concern for &ldquo;immediately up-to-date&rdquo; contents.</p>

<p>I decided to implement <code>https</code> because I intend to use the domain for experiments from time to time, and also <a href="https://www.startssl.com/">because it&rsquo;s free</a>.</p>

<p>Finally, I am using git, as well as github, as a means of version control for my website now.  This allows me to enable a simple cronjob to pull changes hourly, and know that I can update my site from any computer by simply pushing new static html to the github repository.  This also means I have a backup, and a means of distribution/deployment in a way that is scalable.</p>

<h2>future plans</h2>

<p>I have a list of enhancements I&rsquo;d like to add in the future, which may involve changes to my <code>staticmd</code> project as well:</p>

<ul>
<li>move css and javascript to cdn</li>
<li>implement date tracking</li>
<li>improved indexing, navigation, and primary index file identification</li>
</ul>

<p>For any binary file or large file it would make sense to keep it out of the repository and to use a content delivery network.  However, for the builtin css and javascript, being so small, there isn&rsquo;t a problem having as many copies as there are machines with the content.  Further, if I needed to scale the deployment mechanism uses the repository and should always have the latest copy of content.  That said, using some sort of task automator, like <a href="http://gruntjs.com/">grunt</a>, would allow me to minify, name, and upload my javascript and css to the same AWS CloudFront I use for other files.  If anything it would be good practice for any future sites I choose to work on.</p>

<p>I would like to be able to identify when a file was created and last updated, and provide these either below the first header, or at the bottom of the content.  For now, the date created and updated is technically accessible in the repository, but readers won&rsquo;t want to be bothered to look that far, so I can manually add dates for the time being.  The concerns here include whether the file system will correctly track the date created and modified of a file, especially if the files consist of a fresh clone.</p>

<p>I took shortcuts with the current implementation of staticmd&rsquo;s index builder and identification.  Ideally I wanted to go the github route and work with <code>readme.md</code> as the <strong>primary</strong> index file.  However, to conditionally pick between two possible index files adds a bunch more complication, so I ended up sticking with one.  In the future I would like to correct this, and improve how I generate the indexes and main navigation as well.  Things like sort-by-date-order, folders-first, and intelligently ignoring index pages (again complications if two files could both potentially be an index page).</p>

<h5><em>written on 2014-12-22</em></h5>

        </div>

        <footer>
            <a href='https://www.facebook.com/CaseyRDeLorme' class='link facebook'></a>
            <a href='https://www.linkedin.com/in/cdelorme' class='link linkedin'></a>
            <a href='https://www.youtube.com/user/LordOfElm' class='link youtube'></a>
            <a href='https://github.com/cdelorme' class='link github'></a>
            <a href='skype:casey.delorme?chat' class='link skype'></a>
            <div class="scripts">
                <script type="text/javascript" src="/js/main.js#89872b9" async></script>
            </div>
        </footer>

    </body>
</html>