|
@@ -7,62 +7,54 @@
|
|
|
<meta name="description" content="">
|
|
|
<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#2df346a">
|
|
|
+ <link rel="stylesheet" type="text/css" href="/css/main.css#9682a1d">
|
|
|
</head>
|
|
|
<body>
|
|
|
<header class="group">
|
|
|
<h1><a href='/'>Casey DeLorme</a></h1>
|
|
|
-
|
|
|
<nav>
|
|
|
<ul>
|
|
|
-
|
|
|
- <li><a href='/index.html'>index</a></li>
|
|
|
-
|
|
|
- <li><a href='/projects/'>projects</a></li>
|
|
|
-
|
|
|
- <li><a href='/resume.html'>resume</a></li>
|
|
|
-
|
|
|
+ <li><a href="/projects">Projects</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>
|
|
|
+ <h3><a href="https://github.com/cdelorme/caseydelorme.com">caseydelorme.com</a></h3>
|
|
|
|
|
|
-<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>This site began with the concept of a simplified static site generator, which resulted in writing <a href="accelerator.html">accelerator</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>
|
|
|
+<p>The goal of this site was to replace a traditional dynamic system with raw static content and redirect the domain after.</p>
|
|
|
|
|
|
-<h2>design considerations</h2>
|
|
|
+<h4>design considerations</h4>
|
|
|
|
|
|
<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’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>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 to ensure the browser won’t cache incorrectly. <em>In the future I could continue to version but also minify and upload the changed files to S3 so I could benefit from using it for all “static” files.</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 “immediately up-to-date” 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’s free</a>.</p>
|
|
|
+<p>I decided to implement <code>https</code> because I intend to use the domain for experiments from time to time, <em>and also <a href="https://letsencrypt.org/">because it’s free</a>.</em></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>
|
|
|
+<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 very simple distribution and deployment method.</p>
|
|
|
|
|
|
-<h2>future plans</h2>
|
|
|
+<h4>future plans</h4>
|
|
|
|
|
|
-<p>I have a list of enhancements I’d like to add in the future, which may involve changes to my <code>staticmd</code> project as well:</p>
|
|
|
+<p>I have two considerations for the next steps:</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>
|
|
|
+<li>possibly switch to <a href="https://gohugo.io/">hugo</a></li>
|
|
|
+<li>generate the site on the server after pulling changes and remove html from the repository</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’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>The custom tool I built was more of a proof-of-concept, and while neat it isn’t the best option out there. Another tool built in go with much greater stability is available, and might be worth trying.</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’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>Right now I commit the parsed html directly to the repository, and while this means deployment is a simple <code>git pull</code>, it also means that the compiled version of every file is taking space up in the repository redundantly.</p>
|
|
|
|
|
|
-<p>I took shortcuts with the current implementation of staticmd’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>
|
|
|
+<p><em>Finally, I might move the css and javascript to the same S3 CDN that I use for images.</em></p>
|
|
|
|
|
|
-<h5><em>written on 2014-12-22</em></h5>
|
|
|
+<p><strong><em>updated on 2017-07-18</em></strong></p>
|
|
|
|
|
|
</div>
|
|
|
|
|
@@ -73,7 +65,7 @@
|
|
|
<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#2df346a" async></script>
|
|
|
+ <script type="text/javascript" src="/js/main.js#9682a1d" async></script>
|
|
|
</div>
|
|
|
</footer>
|
|
|
|