Migrate to jekyll for static gen
This commit is contained in:
parent
8280d4fcab
commit
0cc7d7fe42
GPG key ID:
61209BF70A5B18BE
27 changed files with 1424 additions and 100 deletions
9
.gitignore
vendored
9
.gitignore
vendored
|
|
@ -1,2 +1,7 @@
|
|||
build/*
|
||||
blog/*
|
||||
_site
|
||||
.sass-cache
|
||||
.jekyll-cache
|
||||
.jekyll-metadata
|
||||
vendor
|
||||
|
||||
old
|
||||
|
|
|
|||
1
.ruby-version
Normal file
1
.ruby-version
Normal file
|
|
@ -0,0 +1 @@
|
|||
3.1.2
|
||||
25
404.html
Normal file
25
404.html
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
permalink: /404.html
|
||||
layout: default
|
||||
---
|
||||
|
||||
<style type="text/css" media="screen">
|
||||
.container {
|
||||
margin: 10px auto;
|
||||
max-width: 600px;
|
||||
text-align: center;
|
||||
}
|
||||
h1 {
|
||||
margin: 30px 0;
|
||||
font-size: 4em;
|
||||
line-height: 1;
|
||||
letter-spacing: -1px;
|
||||
}
|
||||
</style>
|
||||
|
||||
<div class="container">
|
||||
<h1>404</h1>
|
||||
|
||||
<p><strong>Page not found :(</strong></p>
|
||||
<p>The requested page could not be found.</p>
|
||||
</div>
|
||||
44
Gemfile
Normal file
44
Gemfile
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
source "https://rubygems.org"
|
||||
# Hello! This is where you manage which Jekyll version is used to run.
|
||||
# When you want to use a different version, change it below, save the
|
||||
# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
|
||||
#
|
||||
# bundle exec jekyll serve
|
||||
#
|
||||
# This will help ensure the proper Jekyll version is running.
|
||||
# Happy Jekylling!
|
||||
gem "jekyll", "~> 4.3.2"
|
||||
# This is the default theme for new Jekyll sites. You may change this to anything you like.
|
||||
gem "minima", "~> 2.5"
|
||||
gem "no-style-please", git: "https://github.com/atomaka/no-style-please", branch: "atomaka"
|
||||
# If you want to use GitHub Pages, remove the "gem "jekyll"" above and
|
||||
# uncomment the line below. To upgrade, run `bundle update github-pages`.
|
||||
# gem "github-pages", group: :jekyll_plugins
|
||||
# If you have any plugins, put them here!
|
||||
group :jekyll_plugins do
|
||||
gem "jekyll-feed", "~> 0.12"
|
||||
gem "jekyll-gist"
|
||||
gem "jekyll-tidy"
|
||||
end
|
||||
|
||||
group :development do
|
||||
# import for medium
|
||||
gem "jekyll-import", git: "https://github.com/jekyll/jekyll-import"
|
||||
gem "mdl"
|
||||
gem "rss"
|
||||
gem "safe_yaml"
|
||||
end
|
||||
|
||||
# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
|
||||
# and associated library.
|
||||
platforms :mingw, :x64_mingw, :mswin, :jruby do
|
||||
gem "tzinfo", ">= 1", "< 3"
|
||||
gem "tzinfo-data"
|
||||
end
|
||||
|
||||
# Performance-booster for watching directories on Windows
|
||||
gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin]
|
||||
|
||||
# Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem
|
||||
# do not have a Java counterpart.
|
||||
gem "http_parser.rb", "~> 0.6.0", :platforms => [:jruby]
|
||||
152
Gemfile.lock
Normal file
152
Gemfile.lock
Normal file
|
|
@ -0,0 +1,152 @@
|
|||
GIT
|
||||
remote: https://github.com/atomaka/no-style-please
|
||||
revision: e281fa0bbecc82e84fe61be9a92baad5a1a46763
|
||||
branch: atomaka
|
||||
specs:
|
||||
no-style-please (0.4.7)
|
||||
jekyll
|
||||
jekyll-feed
|
||||
jekyll-seo-tag
|
||||
|
||||
GIT
|
||||
remote: https://github.com/jekyll/jekyll-import
|
||||
revision: 6499317a81aeda119b6ceefb37ab81c9f6219659
|
||||
specs:
|
||||
jekyll-import (0.21.0)
|
||||
jekyll (>= 3.7, < 5.0)
|
||||
nokogiri (~> 1.0)
|
||||
reverse_markdown (~> 2.1)
|
||||
|
||||
GEM
|
||||
remote: https://rubygems.org/
|
||||
specs:
|
||||
addressable (2.8.1)
|
||||
public_suffix (>= 2.0.2, < 6.0)
|
||||
chef-utils (18.1.0)
|
||||
concurrent-ruby
|
||||
colorator (1.1.0)
|
||||
concurrent-ruby (1.2.0)
|
||||
em-websocket (0.5.3)
|
||||
eventmachine (>= 0.12.9)
|
||||
http_parser.rb (~> 0)
|
||||
eventmachine (1.2.7)
|
||||
faraday (2.7.4)
|
||||
faraday-net_http (>= 2.0, < 3.1)
|
||||
ruby2_keywords (>= 0.0.4)
|
||||
faraday-net_http (3.0.2)
|
||||
ffi (1.15.5)
|
||||
forwardable-extended (2.6.0)
|
||||
google-protobuf (3.21.12-x86_64-linux)
|
||||
htmlbeautifier (1.4.2)
|
||||
htmlcompressor (0.4.0)
|
||||
http_parser.rb (0.8.0)
|
||||
i18n (1.12.0)
|
||||
concurrent-ruby (~> 1.0)
|
||||
jekyll (4.3.2)
|
||||
addressable (~> 2.4)
|
||||
colorator (~> 1.0)
|
||||
em-websocket (~> 0.5)
|
||||
i18n (~> 1.0)
|
||||
jekyll-sass-converter (>= 2.0, < 4.0)
|
||||
jekyll-watch (~> 2.0)
|
||||
kramdown (~> 2.3, >= 2.3.1)
|
||||
kramdown-parser-gfm (~> 1.0)
|
||||
liquid (~> 4.0)
|
||||
mercenary (>= 0.3.6, < 0.5)
|
||||
pathutil (~> 0.9)
|
||||
rouge (>= 3.0, < 5.0)
|
||||
safe_yaml (~> 1.0)
|
||||
terminal-table (>= 1.8, < 4.0)
|
||||
webrick (~> 1.7)
|
||||
jekyll-feed (0.17.0)
|
||||
jekyll (>= 3.7, < 5.0)
|
||||
jekyll-gist (1.5.0)
|
||||
octokit (~> 4.2)
|
||||
jekyll-sass-converter (3.0.0)
|
||||
sass-embedded (~> 1.54)
|
||||
jekyll-seo-tag (2.8.0)
|
||||
jekyll (>= 3.8, < 5.0)
|
||||
jekyll-tidy (0.2.2)
|
||||
htmlbeautifier
|
||||
htmlcompressor
|
||||
jekyll
|
||||
jekyll-watch (2.2.1)
|
||||
listen (~> 3.0)
|
||||
kramdown (2.4.0)
|
||||
rexml
|
||||
kramdown-parser-gfm (1.1.0)
|
||||
kramdown (~> 2.0)
|
||||
liquid (4.0.4)
|
||||
listen (3.8.0)
|
||||
rb-fsevent (~> 0.10, >= 0.10.3)
|
||||
rb-inotify (~> 0.9, >= 0.9.10)
|
||||
mdl (0.12.0)
|
||||
kramdown (~> 2.3)
|
||||
kramdown-parser-gfm (~> 1.1)
|
||||
mixlib-cli (~> 2.1, >= 2.1.1)
|
||||
mixlib-config (>= 2.2.1, < 4)
|
||||
mixlib-shellout
|
||||
mercenary (0.4.0)
|
||||
minima (2.5.1)
|
||||
jekyll (>= 3.5, < 5.0)
|
||||
jekyll-feed (~> 0.9)
|
||||
jekyll-seo-tag (~> 2.1)
|
||||
mixlib-cli (2.1.8)
|
||||
mixlib-config (3.0.27)
|
||||
tomlrb
|
||||
mixlib-shellout (3.2.7)
|
||||
chef-utils
|
||||
nokogiri (1.14.1-x86_64-linux)
|
||||
racc (~> 1.4)
|
||||
octokit (4.25.1)
|
||||
faraday (>= 1, < 3)
|
||||
sawyer (~> 0.9)
|
||||
pathutil (0.16.2)
|
||||
forwardable-extended (~> 2.6)
|
||||
public_suffix (5.0.1)
|
||||
racc (1.6.2)
|
||||
rake (13.0.6)
|
||||
rb-fsevent (0.11.2)
|
||||
rb-inotify (0.10.1)
|
||||
ffi (~> 1.0)
|
||||
reverse_markdown (2.1.1)
|
||||
nokogiri
|
||||
rexml (3.2.5)
|
||||
rouge (4.0.1)
|
||||
rss (0.2.9)
|
||||
rexml
|
||||
ruby2_keywords (0.0.5)
|
||||
safe_yaml (1.0.5)
|
||||
sass-embedded (1.58.0)
|
||||
google-protobuf (~> 3.21)
|
||||
rake (>= 10.0.0)
|
||||
sawyer (0.9.2)
|
||||
addressable (>= 2.3.5)
|
||||
faraday (>= 0.17.3, < 3)
|
||||
terminal-table (3.0.2)
|
||||
unicode-display_width (>= 1.1.1, < 3)
|
||||
tomlrb (2.0.3)
|
||||
unicode-display_width (2.4.2)
|
||||
webrick (1.8.1)
|
||||
|
||||
PLATFORMS
|
||||
x86_64-linux
|
||||
|
||||
DEPENDENCIES
|
||||
http_parser.rb (~> 0.6.0)
|
||||
jekyll (~> 4.3.2)
|
||||
jekyll-feed (~> 0.12)
|
||||
jekyll-gist
|
||||
jekyll-import!
|
||||
jekyll-tidy
|
||||
mdl
|
||||
minima (~> 2.5)
|
||||
no-style-please!
|
||||
rss
|
||||
safe_yaml
|
||||
tzinfo (>= 1, < 3)
|
||||
tzinfo-data
|
||||
wdm (~> 0.1.1)
|
||||
|
||||
BUNDLED WITH
|
||||
2.3.26
|
||||
23
README.md
Normal file
23
README.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# atomaka.com
|
||||
|
||||
Website managed by jekyll.
|
||||
|
||||
## Pre-requisites
|
||||
|
||||
* Python
|
||||
* whatever version lets you install `requirements.txt`
|
||||
* Ruby
|
||||
* Preferably the version in `.ruby-version`
|
||||
|
||||
## Setup
|
||||
|
||||
1. `pip install -r requirements.txt`
|
||||
2. `bundle install`
|
||||
|
||||
## Testing
|
||||
|
||||
* `bundle exec jekyll serve`
|
||||
|
||||
## Deployment
|
||||
|
||||
* `./build.sh`
|
||||
60
_config.yml
Normal file
60
_config.yml
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
# Welcome to Jekyll!
|
||||
#
|
||||
# This config file is meant for settings that affect your whole blog, values
|
||||
# which you are expected to set up once and rarely edit after that. If you find
|
||||
# yourself editing this file very often, consider using Jekyll's data files
|
||||
# feature for the data you need to update frequently.
|
||||
#
|
||||
# For technical reasons, this file is *NOT* reloaded automatically when you use
|
||||
# 'bundle exec jekyll serve'. If you change this file, please restart the server process.
|
||||
#
|
||||
# If you need help with YAML syntax, here are some quick references for you:
|
||||
# https://learn-the-web.algonquindesign.ca/topics/markdown-yaml-cheat-sheet/#yaml
|
||||
# https://learnxinyminutes.com/docs/yaml/
|
||||
#
|
||||
# Site settings
|
||||
# These are used to personalize your new site. If you look in the HTML files,
|
||||
# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
|
||||
# You can create any custom variable you would like, and they will be accessible
|
||||
# in the templates via {{ site.myvariable }}.
|
||||
|
||||
title: Andrew Tomaka
|
||||
email: atomaka@atomaka.com
|
||||
description: >- # this means to ignore newlines until "baseurl:"
|
||||
Personal website of Andrew Tomaka
|
||||
baseurl: "" # the subpath of your site, e.g. /blog
|
||||
url: "https://www.atomaka.com" # the base hostname & protocol for your site, e.g. http://example.com
|
||||
github_username: atomaka
|
||||
favicon: favicon.ico
|
||||
|
||||
# Build settings
|
||||
theme: no-style-please
|
||||
theme_config:
|
||||
appearance: "auto" # can be "light", "dark" or "auto"
|
||||
plugins:
|
||||
- jekyll-feed
|
||||
- jekyll-gist
|
||||
|
||||
# Exclude from processing.
|
||||
# The following items will not be processed, by default.
|
||||
# Any item listed under the `exclude:` key here will be automatically added to
|
||||
# the internal "default list".
|
||||
#
|
||||
# Excluded items can be processed by explicitly listing the directories or
|
||||
# their entries' file path in the `include:` list.
|
||||
#
|
||||
exclude:
|
||||
- .ruby-version
|
||||
- build.sh
|
||||
- old/
|
||||
- README.md
|
||||
# - .sass-cache/
|
||||
# - .jekyll-cache/
|
||||
# - gemfiles/
|
||||
# - Gemfile
|
||||
# - Gemfile.lock
|
||||
# - node_modules/
|
||||
# - vendor/bundle/
|
||||
# - vendor/cache/
|
||||
# - vendor/gems/
|
||||
# - vendor/ruby/
|
||||
27
_data/menu.yml
Normal file
27
_data/menu.yml
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# For documentation on this file, see:
|
||||
# https://github.com/riggraz/no-style-please#customize-the-menu
|
||||
|
||||
entries:
|
||||
- title: info
|
||||
url: false
|
||||
entries:
|
||||
- title: coding
|
||||
url: https://github.com/atomaka
|
||||
- title: emailing
|
||||
url: mailto:atomaka@atomaka.com
|
||||
- title: speaking
|
||||
url: https://slides.com/atomaka
|
||||
- title: tooting
|
||||
url: https://pub.atomaka.com/@atomaka
|
||||
- title: working
|
||||
url: https://www.linkedin.com/in/atomaka
|
||||
|
||||
- title: all posts
|
||||
post_list:
|
||||
limit: 5
|
||||
show_more: true
|
||||
show_more_text: See archive...
|
||||
show_more_url: archive
|
||||
|
||||
- title: rss
|
||||
url: feed.xml
|
||||
61
_posts/2012-10-25-force-print-document-on-11x17-scaled.md
Normal file
61
_posts/2012-10-25-force-print-document-on-11x17-scaled.md
Normal file
|
|
@ -0,0 +1,61 @@
|
|||
---
|
||||
layout: post
|
||||
title: Force "Print Document on" 11x17 Scaled
|
||||
tag:
|
||||
- technical
|
||||
---
|
||||
|
||||
The Print Spooler API in Windows does not seem to have an option to force
|
||||
scaling to another paper size. Formerly, we would install the printer save the
|
||||
registry key in `HKCU\Printers\DevModePerUser`. Then, we could check the "Print
|
||||
Document On" option, apply the settings, and save the registry key again.
|
||||
Performing a diff of between the two sets of roughly 4000 hex values should give
|
||||
a subset of values that relate to "Print Document On." Finally, on installation
|
||||
we could read in the registry key after everything else had been setup, cycle
|
||||
through it changing the appropriate values based on our diff and then save the
|
||||
registry key. This stopped working.
|
||||
|
||||
No new diffs could be collected that would update the scale to fit functionality
|
||||
that we needed. However, if the "Print Document On" option is manually set and
|
||||
the registry key is collected, that key can be used as the "diff" and the newly
|
||||
added printer would print scaled as desired. This has the unfortunate side
|
||||
effect of modifying all other settings on the printer including the name and
|
||||
color settings. As a work around, two different registry key "diffs" are used:
|
||||
one for color and one for black&white. Then, the first 30 hex characters can be
|
||||
chopped off in each key to make sure the printer name is not overwritten.
|
||||
|
||||
```
|
||||
#include <windows.h>;
|
||||
|
||||
int stf[][2] = {
|
||||
{8, 0},
|
||||
{10, 0},
|
||||
// and more keys
|
||||
};
|
||||
|
||||
int setPrintDocumentOn(char *printerName) {
|
||||
HKEY hkey;
|
||||
|
||||
// find the tree where the key we need to change resides
|
||||
RegOpenKey(HKEY_CURRENT_USER, "Printers\\DevModePerUser", &hkey);
|
||||
|
||||
DWORD requiredSize = 0;
|
||||
DWORD dataType;
|
||||
|
||||
// read in the key
|
||||
RegQueryValueEx(hkey, printerName, 0, &dataType, NULL, &requiredSize);
|
||||
char *DevModePerUserData = malloc(requiredSize);
|
||||
RegQueryValueEx(hkey, printerName, 0, &dataType, (BYTE *)DevModePerUserData, &requiredSize);
|
||||
|
||||
// update the key
|
||||
int i = 0;
|
||||
for(i = 0; i < sizeof(stf) / 8; i++) {
|
||||
DevModePerUserData[stf[i][0]] = stf[i][1];
|
||||
}
|
||||
|
||||
// and save our updates
|
||||
RegSetValueEx(hkey, printerName, 0, REG_BINARY, (BYTE *)DevModePerUserData, requiredSize);
|
||||
RegFlushKey(hkey);
|
||||
RegCloseKey(hkey);
|
||||
}
|
||||
```
|
||||
14
_posts/2013-02-02-serious-regular-expressions.md
Normal file
14
_posts/2013-02-02-serious-regular-expressions.md
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
---
|
||||
layout: post
|
||||
title: Serious Regular Expressions
|
||||
tag:
|
||||
- humor
|
||||
---
|
||||
|
||||
```
|
||||
$n = '[0-9]';
|
||||
$reg = '/^[AZ]'.$n.$n.$n.$n.$n.$n.$n.$n.'$/';
|
||||
if(preg_match($reg, $id)) {
|
||||
// ...
|
||||
}
|
||||
```
|
||||
58
_posts/2013-09-25-password-checking-in-c.md
Normal file
58
_posts/2013-09-25-password-checking-in-c.md
Normal file
|
|
@ -0,0 +1,58 @@
|
|||
---
|
||||
layout: post
|
||||
title: Password Checking in C
|
||||
tag:
|
||||
- humor
|
||||
---
|
||||
|
||||
```
|
||||
if (strlen(encrytedenteredpassword) != 13) {
|
||||
passwordcorrect=0;
|
||||
} else {
|
||||
for (i=0; i<13;i++) {
|
||||
switch (i) {
|
||||
case 0:
|
||||
if (encrytedenteredpassword[i] != 'f') passwordcorrect=0;
|
||||
break;
|
||||
case 1:
|
||||
if (encrytedenteredpassword[i] != 'J') passwordcorrect=0;
|
||||
break;
|
||||
case 2:
|
||||
if (encrytedenteredpassword[i] != 'c') passwordcorrect=0;
|
||||
break;
|
||||
case 3:
|
||||
if (encrytedenteredpassword[i] != 'l') passwordcorrect=0;
|
||||
break;
|
||||
case 4:
|
||||
if (encrytedenteredpassword[i] != 'Q') passwordcorrect=0;
|
||||
break;
|
||||
case 5:
|
||||
if (encrytedenteredpassword[i] != 'v') passwordcorrect=0;
|
||||
break;
|
||||
case 6:
|
||||
if (encrytedenteredpassword[i] != 'P') passwordcorrect=0;
|
||||
break;
|
||||
case 7:
|
||||
if (encrytedenteredpassword[i] != 'i') passwordcorrect=0;
|
||||
break;
|
||||
case 8:
|
||||
if (encrytedenteredpassword[i] != 'l') passwordcorrect=0;
|
||||
break;
|
||||
case 9:
|
||||
if (encrytedenteredpassword[i] != 'N') passwordcorrect=0;
|
||||
break;
|
||||
case 10:
|
||||
if (encrytedenteredpassword[i] != 'A') passwordcorrect=0;
|
||||
break;
|
||||
case 11:
|
||||
if (encrytedenteredpassword[i] != 'z') passwordcorrect=0;
|
||||
break;
|
||||
case 12:
|
||||
if (encrytedenteredpassword[i] != '.') passwordcorrect=0;
|
||||
break;
|
||||
default: passwordcorrect=0; break;
|
||||
}
|
||||
if (!passwordcorrect) break;
|
||||
}
|
||||
}
|
||||
```
|
||||
300
_posts/2014-01-19-intro-to-puppet.md
Normal file
300
_posts/2014-01-19-intro-to-puppet.md
Normal file
|
|
@ -0,0 +1,300 @@
|
|||
---
|
||||
layout: post
|
||||
title: 'Intro to Puppet: The Bare Minimum'
|
||||
tag:
|
||||
- puppet
|
||||
- technical
|
||||
---
|
||||
|
||||
Last month, some of my coworkers were looking for a brief introduction to
|
||||
[Puppet](http://www.puppetlabs.com/). Puppet is a type of configuration manager
|
||||
for your servers. It allows you to create definitions of your server that can
|
||||
then be automatically maintained. Puppet is mostly self documenting so it makes
|
||||
it easy to know what your servers are doing while giving you a great way to
|
||||
automate setting up large numbers of servers.
|
||||
|
||||
This is that brief talk. All code is available on
|
||||
[Github in my puppet-walkthru repository](https://github.com/atomaka/puppet-walkthru).
|
||||
You will need [Git](http://www.git-scm.com/),
|
||||
[Virtual Box](https://www.virtualbox.org/) and
|
||||
[Vagrant](http://www.vagrantup.com/) installed. To begin, clone the repository
|
||||
and launch the Vagrantfile:
|
||||
|
||||
```
|
||||
git clone https://github.com/atomaka/puppet-walkthru.git
|
||||
cd puppet-walkthru
|
||||
vagrant up
|
||||
```
|
||||
|
||||
This will setup a virtual machine on your computer with Puppet installed. All
|
||||
code can be found on the virtual machine in the /vagrant directory.
|
||||
|
||||
```
|
||||
vagrant ssh
|
||||
sudo su cd /vagrant
|
||||
```
|
||||
|
||||
You are now ready to work through the first example.
|
||||
|
||||
## 1. Managing Users
|
||||
|
||||
Puppet maintains state on your computer using what are referred to as
|
||||
[resources](http://docs.puppetlabs.com/references/latest/type.html). The
|
||||
built-in resources provided by Puppet provide a good start. In
|
||||
[example one](https://github.com/atomaka/puppet-walkthru/blob/master/manifests/1-user-type.pp),
|
||||
you can see how to use a Puppet resource to add and remove a user.
|
||||
|
||||
```
|
||||
user { 'tm':
|
||||
ensure => present,
|
||||
}
|
||||
user { 'fowlks':
|
||||
ensure => absent,
|
||||
}
|
||||
```
|
||||
|
||||
You can run this code on your virtual machine with
|
||||
`puppet apply manifests/1-user-type.pp`. Afterward, you should notice that the
|
||||
user "tm" exists on your system.
|
||||
|
||||
The [user resource](http://docs.puppetlabs.com/references/latest/type.html#user)
|
||||
type manages local users on your system. This works on a wide variety of
|
||||
systems, although some do not support some of the more specific features. In
|
||||
this example, we make sure the user "tm" is present on the system and make sure
|
||||
the user "fowlks" is not present.
|
||||
|
||||
ensure is a keyword for all Puppet resources. present and absent are the most
|
||||
common values although some resource types have others. ensure will make sure
|
||||
that definition exists on your server and absent will obviously do the opposite.
|
||||
|
||||
## 2. Managing Files
|
||||
|
||||
Managing files is one of the most common tasks for server administration and
|
||||
Puppet offers many ways to handle this. We’ll explore these in the
|
||||
[next example](https://github.com/atomaka/puppet-walkthru/blob/master/manifests/2-file-type.pp).
|
||||
|
||||
```
|
||||
file { '/tmp/test1.txt':
|
||||
ensure => present,
|
||||
content => 'Hello',
|
||||
}
|
||||
file { '/tmp/test2.txt':
|
||||
ensure => present,
|
||||
source => '/vagrant/files/test2.txt',
|
||||
}
|
||||
$something = "Hello"
|
||||
file { '/tmp/test3.txt':
|
||||
ensure => present,
|
||||
content => template('/vagrant/templates/test3.txt.erb'),
|
||||
}
|
||||
```
|
||||
|
||||
Run this on your virtual machine using `puppet apply manifests/2-file-type.pp`
|
||||
and you should be alerted that three files were created. You can verify this by
|
||||
viewing the contents of the tmp directory with `ls /tmp`.
|
||||
|
||||
The first
|
||||
[file resource](http://docs.puppetlabs.com/references/latest/type.html#file)
|
||||
simply creates a file at the specified location that says "Hello."
|
||||
Unfortunately, this isn’t very useful since we do not want to have to type our
|
||||
entire cnfiguration file in our Puppet definition. The second resource is
|
||||
slightly more useful. This allows us to copy a file from our Puppet repository
|
||||
to a specified location.
|
||||
|
||||
Finally, we can also create templates. The last example uses a file from our
|
||||
repository and copies it to the specified location. However, we can also include
|
||||
variables that can be used in our file. In this case, we set a variable to
|
||||
something and it is then displayed in the file: `You said: Hello`. The contents
|
||||
of `$something` are used in the file.
|
||||
|
||||
## 3. Installing Packages
|
||||
|
||||
The last common task we’ll look at is installing packages. Puppet provides a way
|
||||
to define which
|
||||
[packages](http://docs.puppetlabs.com/references/latest/type.html#package) can
|
||||
be installed. By default, this uses your distributions built-in package manager
|
||||
although there are ways to specify various providers. Our example
|
||||
[shows the most basic usage](https://github.com/atomaka/puppet-walkthru/blob/master/manifests/3-package-type.pp).
|
||||
|
||||
```
|
||||
package { 'vim':
|
||||
ensure => present,
|
||||
}
|
||||
package { 'alpine-pico':
|
||||
ensure => absent,
|
||||
}
|
||||
```
|
||||
|
||||
Try to open vim and you will notice it cannot run. Once you run this code with
|
||||
`puppet apply manifests/3-package-type.pp`, the vim package will then be
|
||||
present.
|
||||
|
||||
## 4. Ordering (or lack thereof)
|
||||
|
||||
The trickest thing for beginners to Puppet is dealing with its
|
||||
[non-deterministic behavior](http://puppetlabs.com/blog/inside-puppet-about-determinism).
|
||||
This is easier to
|
||||
[show than explain](https://github.com/atomaka/puppet-walkthru/blob/master/manifests/4-order-example.pp).
|
||||
|
||||
```
|
||||
notify { 'First': }
|
||||
notify { 'Second': }
|
||||
notify { 'Third': }
|
||||
notify { 'Fourth': }
|
||||
notify { 'Fifth': }
|
||||
notify { 'Sixth': }
|
||||
notify { 'Seventh': }
|
||||
```
|
||||
|
||||
When run, you would expect this to spit out First, Second, …, Seventh in order.
|
||||
Invoke this code with `puppet apply manifests/4-order-example.pp` and be
|
||||
surprised at the results. The order of the code is much different than what is
|
||||
in the file. Furthermore, if you were to add `notify { 'Eighth': }` the ordering
|
||||
might change completely.
|
||||
|
||||
## 5. But I Need Order
|
||||
|
||||
But there are dependencies when setting up systems. Puppet allows for this, you
|
||||
just are required to
|
||||
[explicitly define them](https://github.com/atomaka/puppet-walkthru/blob/master/manifests/5-ordered-example.pp).
|
||||
The biggest advantage here is that if one line of dependencies fails, your
|
||||
entire configuration does not. It takes some getting used to and can be
|
||||
frustrating, but it is worth it.
|
||||
|
||||
```
|
||||
notify { 'First': }
|
||||
notify { 'Second':
|
||||
require => Notify['First'],
|
||||
}
|
||||
notify { 'Third':
|
||||
require => Notify['Second'],
|
||||
}
|
||||
notify { 'Fourth':
|
||||
require => Notify['Third'],
|
||||
}
|
||||
notify { 'Fifth':
|
||||
require => Notify['Fourth'],
|
||||
}
|
||||
notify { 'Sixth':
|
||||
require => Notify['Fifth'],
|
||||
}
|
||||
notify { 'Seventh':
|
||||
require => Notify['Sixth'],
|
||||
}
|
||||
```
|
||||
|
||||
By using the `require` parameter, we have have forced ordering. If you run this
|
||||
code with `puppet apply manifests/5-ordered-example.pp`, you will see the order
|
||||
you expected in example number four.
|
||||
|
||||
## 6. Know Your Environment
|
||||
|
||||
Puppet also provides a way for you to know about the system that the Puppet code
|
||||
is running on with a system called Facter.
|
||||
|
||||
```
|
||||
notify { "${::osfamily}": }
|
||||
notify { "${::ipaddress}": }
|
||||
notify { "${::uptime}": }
|
||||
```
|
||||
|
||||
When run with `puppet apply manifests/6-facts-example.pp`,
|
||||
[this code](https://github.com/atomaka/puppet-walkthru/blob/master/manifests/6-facts-example.pp)
|
||||
will display the information about the virtual machine you are running on. We
|
||||
will look at why this is useful later.
|
||||
|
||||
## 7. Doing Something Useful
|
||||
|
||||
Now that we have seen some quick forced examples of how to use Puppet, we now
|
||||
have enough knowledge to do something that is actually useful. Using Puppet, we
|
||||
can
|
||||
[configure an entire service](https://github.com/atomaka/puppet-walkthru/blob/master/manifests/7-full-example.pp).
|
||||
If you are not familiar, [NTP](http://www.ntp.org/) is a networking protocol for
|
||||
time management. It is useful for mainitaining the same system time across all
|
||||
of your servers. And we can use Puppet to install it!
|
||||
|
||||
```
|
||||
package { 'ntp':
|
||||
ensure => present,
|
||||
}
|
||||
file { '/etc/ntp.conf':
|
||||
ensure => present,
|
||||
require => Package['ntp'],
|
||||
source => '/vagrant/files/ntp.conf.debian',
|
||||
}
|
||||
service { 'ntp':
|
||||
ensure => running,
|
||||
enable => true,
|
||||
subscribe => File['/etc/ntp.conf'],
|
||||
}
|
||||
```
|
||||
|
||||
When running this code with `puppet apply manifest/7-full-example.pp`, you
|
||||
should notice three things happen. First, the ntp package will be installed.
|
||||
Since we are on Ubuntu, this is done using apt-get. Secondly, a configuration
|
||||
file was copied from our Puppet repository to the location specified. Finally,
|
||||
the ntp service was started.
|
||||
|
||||
Install, configure, start is one of the most common patterns in Linux/UNIX
|
||||
systems administration and we can easily automate it with Puppet.
|
||||
|
||||
Something to note is our use of subscribe when using the
|
||||
[service resource](http://docs.puppetlabs.com/references/latest/type.html#service)
|
||||
type. This makes sure that the ntp service is restarted only if the
|
||||
configuration file has changed.
|
||||
|
||||
## 7. Managing Multiple Operating Systems
|
||||
|
||||
Before this section, be sure to reset what we did in the previous example by
|
||||
running bash support/cleanup7.sh. We just need to uninstall ntp and our config
|
||||
file so we can do it all again.
|
||||
|
||||
Unfortunately, our environments are never uniform and we are stuck dealing with
|
||||
different versions of operating systems. Luckily, we have tools that we can use
|
||||
to deal with it. We touched on this in section six, but now we will actually use
|
||||
them
|
||||
[to install ntp again](https://github.com/atomaka/puppet-walkthru/blob/master/manifests/8-independent-example.pp).
|
||||
This time, our code will work on both Debian and RedHat family Linux
|
||||
distributions.
|
||||
|
||||
```
|
||||
case $::osfamily {
|
||||
'RedHat': {
|
||||
$service = 'ntpd'
|
||||
$conf = 'ntp.conf.redhat'
|
||||
}
|
||||
'Debian': {
|
||||
$service = 'ntp'
|
||||
$conf = 'ntp.conf.debian'
|
||||
}
|
||||
}
|
||||
notify { 'OS Information':
|
||||
message => "${::osfamily}: Setting service to ${service} and conf to ${conf}",
|
||||
before => Package['ntp'],
|
||||
}
|
||||
package { 'ntp':
|
||||
ensure => present,
|
||||
}
|
||||
file { '/etc/ntp.conf':
|
||||
ensure => present,
|
||||
require => Package['ntp'],
|
||||
source => "/vagrant/files/${conf}",
|
||||
}
|
||||
service { $service:
|
||||
ensure => running,
|
||||
enable => true,
|
||||
subscribe => File['/etc/ntp.conf'],
|
||||
}
|
||||
```
|
||||
|
||||
When on our Ubuntu virtual machine, running this code with
|
||||
`puppet apply manifest/8-independent-example.pp` will setup NTP just as we did
|
||||
in example seven. However, this code can also run on RedHat / CentOS machines
|
||||
without any adjustments.
|
||||
|
||||
This is handled using the facts we discussed in section six. We check to see
|
||||
what distribution we are using with `$::osfamily` and make choices based on
|
||||
that. Since the service and the config file are different on RedHat, we assign
|
||||
variables to these and adjust them as needed.
|
||||
|
||||
You now have enough knowledge to get started with Puppet!
|
||||
78
_posts/2014-02-11-get-away-from-me-you-creep.md
Normal file
78
_posts/2014-02-11-get-away-from-me-you-creep.md
Normal file
|
|
@ -0,0 +1,78 @@
|
|||
---
|
||||
layout: post
|
||||
title: Get Away From Me You Creep
|
||||
tag:
|
||||
- humor
|
||||
---
|
||||
|
||||
Almost ten years ago, I took a telecommunication history with course with one of
|
||||
the most eccentric people I had ever met. Unfortunately, it was during a time
|
||||
where I was attending very few courses and I missed most of my opportunities to
|
||||
listen to him speak. Still, I managed to make it to enough classes to have
|
||||
distinct memories of him. Dr. Barry Litman passed away a few years ago and these
|
||||
are his stories.
|
||||
|
||||
I attended the first day of class just as I did the first day of every class I
|
||||
took. I sat down and was probably scribbling in the notepad I purchased that I
|
||||
knew would never be used or barely staying awake. He began giving a brief
|
||||
overview the history of telecommunication in extreme story telling mode with an
|
||||
unprecedented excitement. I don’t remember anything from that day except for the
|
||||
way he ended class: “And just like that, the entire industry evolved into a star
|
||||
just waiting to supernova.”
|
||||
|
||||
I explained this to a couple of students I was working with and they immediately
|
||||
knew who I was talking about. They warned me about David Sarnoff but would not
|
||||
give me any other information. I was forced to attend class for several sessions
|
||||
before the story was revealed.
|
||||
|
||||
David Sarnoff was a corporate kingpin during the pioneering of radio and
|
||||
television serving as an executive for the Radio Corporation of America. Dr.
|
||||
Litman was visibly agitated as he explained this and other RCA history to the
|
||||
class. And then he began talking about Edwin Armstrong.
|
||||
|
||||
Edwin Armstrong was an employee of RCA and eventually credited inventor of FM
|
||||
radio. He developed this while working for RCA, but Sarnoff saw it as a threat
|
||||
to the AM technology that the company was already producing. Because of this and
|
||||
their focus on television, Sarnoff and RCA chose not to purchase the patents for
|
||||
the technology. But after hearing the quality and seeing its success, RCA first
|
||||
tried to have the FCC ban usage of the wave and eventually claimed the invention
|
||||
of the technology and won the patent. Armstrong spent nearly all his time and
|
||||
money fighting for the rights to his own technology.
|
||||
|
||||
As he was explaining these details, Litman went from agitated to infuriated. His
|
||||
face reddened, he began sweating and spoke louder and louder. The entire class
|
||||
was looking around at each other and no one knew how to respond.
|
||||
|
||||
He eventually came to the close of the story. Armstrong ended up committing
|
||||
suicide. And even though he was eventually given the credit he deserved, it came
|
||||
too late. The professor was visibly exhausted and saddened but managed to
|
||||
literally spit out one final angry yell: “And it was all because of that son of
|
||||
a bitch, David Sarnoff.” He then walked out of the room.
|
||||
|
||||
I mostly stopped going to class after that. I don’t know why. He was an
|
||||
incredible teacher and his enthusiasm kept me interested during most lectures.
|
||||
In the few classes I did attend he frequently referenced Vanna White as someone
|
||||
who used to be one of his favorite people, but never expanded the story. The
|
||||
last day before finals I went to class in hopes of getting some hints for the
|
||||
final. Instead, he shared his story.
|
||||
|
||||
He explained to us that once a year, he and one of his close friends/colleagues
|
||||
would attend a conference related to telecommunication. A few years prior, Vanna
|
||||
White was attending something loosely related and he managed to convince his
|
||||
friend to attend. Vanna White’s booth was highly trafficked and Litman was
|
||||
forced to wait in line for three hours to see her. During this time, he was
|
||||
extremely nervous which led to him soaking through his shirt with sweat. When it
|
||||
was finally his turn to meet her, he walked up and blurted out about how big of
|
||||
a fan he was and how long he had followed her.
|
||||
|
||||
And then he paused. I remember it feeling like ten minutes, but it was probably
|
||||
closer to one. Finally, he asked the class “And do you know what that bitch said
|
||||
to me?” He walked over to the side of the classroom and held the button to
|
||||
retract the overhead. Slowly, the words she spoke were revealed having been
|
||||
written in chalk on the board before the class had begun:
|
||||
|
||||
"Get away from me, you creep."
|
||||
|
||||
I wish I had written about these ten years ago. Even then, I wouldn’t have done
|
||||
the man justice. Truly great speakers are rare and it’s unfortunate he passed so
|
||||
soon.
|
||||
143
_posts/2015-11-21-dockerizing-lubot.md
Normal file
143
_posts/2015-11-21-dockerizing-lubot.md
Normal file
|
|
@ -0,0 +1,143 @@
|
|||
---
|
||||
layout: post
|
||||
title: Dockerizing Lubot
|
||||
tag:
|
||||
- docker
|
||||
- technical
|
||||
---
|
||||
|
||||
Lubot is the [Lansing Codes](http://lansing.codes/) chat bot responsible for
|
||||
bringing updates about all local events to chatters everywhere…or just in
|
||||
Lansing. Previously, it resided on a Heroku Free instance and was required to
|
||||
sleep for six hours out of every twenty-four hours. After some issues with him
|
||||
waking up, we began looking for alternatives. Since I already had a server
|
||||
hosting several Docker containers, it seemed like the best choice.
|
||||
|
||||
Docker is basically a way to create a container that can be easily distributed
|
||||
across many operating systems. Using it, we can take the code, runtime, and
|
||||
libraries that Lubot requires and put them in a package. You can read more about
|
||||
it in the
|
||||
[Official “What is Docker” article](https://www.docker.com/what-docker).
|
||||
|
||||
To begin, we need to determine the necessary dependencies for our application.
|
||||
Lubot is built using NodeJS and uses npm to manage dependencies. Specifically,
|
||||
we are using Node v5.0.0 and npm v3.3.9. There’s an official Node Dockerfile to
|
||||
use to begin with so it is pretty easy to start.
|
||||
|
||||
```
|
||||
FROM node
|
||||
|
||||
ENV NODE_VERSION 5.0.0
|
||||
ENV NPM_VERSION 3.3.9
|
||||
```
|
||||
|
||||
After that, we want to take care of the dependencies for our application.
|
||||
Because of the way Docker works, we want to cache this step so when our
|
||||
packages.json file does not change, we do not have to rebuild our dependencies.
|
||||
|
||||
```
|
||||
ADD package.json /tmp/
|
||||
RUN cd /tmp && npm install
|
||||
RUN mkdir -p /opt/hubot && cp -a /tmp/node_modules /opt/hubot
|
||||
```
|
||||
|
||||
Then, we need to add the application code to the container.
|
||||
|
||||
```
|
||||
ADD . /opt/hubot
|
||||
WORKDIR /opt/hubot
|
||||
```
|
||||
|
||||
Finally, we can start the service.
|
||||
|
||||
```
|
||||
CMD ["/opt/hubot/bin/hubot", "--adapter", "slack"]
|
||||
```
|
||||
|
||||
Combine these steps and we end up with a
|
||||
[Dockerfile](https://github.com/lansingcodes/lubot/blob/master/Dockerfile). This
|
||||
gets added to the repisitory so that we can build the application. Building an
|
||||
image is easy.
|
||||
|
||||
```
|
||||
docker build -t lansingcodes/lubot .
|
||||
```
|
||||
|
||||
This will download and build the necessary filesystems, caching where necessary
|
||||
and giving us a runable container image. Starting the container is also simple.
|
||||
|
||||
```
|
||||
docker run lansingcodes/lubot
|
||||
```
|
||||
|
||||
Lubot expects some environment variables to be there. But since we are in a
|
||||
container, no environment variables exist on the system and we need to pass them
|
||||
in. Our new run command accounts for this.
|
||||
|
||||
```
|
||||
docker run -d --restart=always --name lubot \
|
||||
-e HUBOT_SLACK_TOKEN=$HUBOT_SLACK_TOKEN \
|
||||
-e TWITTER_LANSINGCODES_CONSUMER_KEY=$TWITTER_LANSINGCODES_CONSUMER_KEY \
|
||||
-e TWITTER_LANSINGCODES_CONSUMER_SECRET=$TWITTER_LANSINGCODES_CONSUMER_SECRET \
|
||||
-e TWITTER_LANSINGCODES_ACCESS_TOKEN=$TWITTER_LANSINGCODES_ACCESS_TOKEN \
|
||||
-e TWITTER_LANSINGCODES_ACCESS_TOKEN_SECRET=$TWITTER_LANSINGCODES_ACCESS_TOKEN_SECRET \
|
||||
-e GOOGLE_API_KEY=$GOOGLE_API_KEY \
|
||||
-e LUBOT_MEETUP_API_KEY=$LUBOT_MEETUP_API_KEY \
|
||||
-e TZ=$TZ \
|
||||
-e REDIS_URL=$REDIS_URL \
|
||||
lansingcodes/lubot
|
||||
```
|
||||
|
||||
Lubot is now running in a container. However, Heroku also provided easy
|
||||
continuous deployment when combined with [Circle CI](https://circleci.com/).
|
||||
Being able to have changes deployed when the master branch changes is handy.
|
||||
Circle CI allows us to specify post-build commands to run. Typically, we’d want
|
||||
to build the container on our CI server and then push to a Docker registry, butI
|
||||
didn’t have one of those available. We can still use Circle CI to execute
|
||||
commands on a remote server with SSH. This makes our deploy process simple.
|
||||
|
||||
- clone the repository on our remote server
|
||||
- build the docker image from that repositry
|
||||
- run the docker image that was build
|
||||
|
||||
Our CI build file will trigger these actions via a script.
|
||||
|
||||
```
|
||||
scp deploy/deploy.sh lubot@app.atomaka.com:/home/lubot
|
||||
ssh lubot@app.atomaka.com "bash /home/lubot/deploy.sh"
|
||||
```
|
||||
|
||||
And then, deploy.sh will take care of the parts we already discussed.
|
||||
|
||||
```
|
||||
#!/bin/bash
|
||||
|
||||
cd $HOME
|
||||
source lubotrc
|
||||
|
||||
git clone https://github.com/lansingcodes/lubot.git
|
||||
|
||||
cd $HOME/lubot
|
||||
sudo docker build -t lansingcodes/lubot .
|
||||
cd $HOME
|
||||
rm -rf $HOME/lubot
|
||||
|
||||
sudo docker rm -f lubot
|
||||
sudo docker run -d --restart=always --name lubot \
|
||||
-e HUBOT_SLACK_TOKEN=$HUBOT_SLACK_TOKEN \
|
||||
-e TWITTER_LANSINGCODES_CONSUMER_KEY=$TWITTER_LANSINGCODES_CONSUMER_KEY \
|
||||
-e TWITTER_LANSINGCODES_CONSUMER_SECRET=$TWITTER_LANSINGCODES_CONSUMER_SECRET \
|
||||
-e TWITTER_LANSINGCODES_ACCESS_TOKEN=$TWITTER_LANSINGCODES_ACCESS_TOKEN \
|
||||
-e TWITTER_LANSINGCODES_ACCESS_TOKEN_SECRET=$TWITTER_LANSINGCODES_ACCESS_TOKEN_SECRET \
|
||||
-e GOOGLE_API_KEY=$GOOGLE_API_KEY \
|
||||
-e LUBOT_MEETUP_API_KEY=$LUBOT_MEETUP_API_KEY \
|
||||
-e TZ=$TZ \
|
||||
-e REDIS_URL=$REDIS_URL \
|
||||
lansingcodes/lubot
|
||||
```
|
||||
|
||||
Deploying Lubot is now just as easy as it was with Heroku and he never has to
|
||||
sleep again.
|
||||
|
||||
- [Other details surrounding the deployment](https://github.com/lansingcodes/lubot/tree/master/deploy)
|
||||
- [Lubot repository](https://github.com/lansingcodes/slackbot)
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
---
|
||||
layout: post
|
||||
title: Testing Your Docker Images with GitLab CI
|
||||
tag:
|
||||
- continuous-integration
|
||||
- gitlab
|
||||
- docker
|
||||
- devops
|
||||
---
|
||||
|
||||
I have been using [GitLab](https://about.gitlab.com) for over four years. My
|
||||
[first commit](https://github.com/gitlabhq/gitlabhq/commit/0760ba3efb7566b9f56bb066f4b15ba8ea34e1e7)
|
||||
to the project came nearly three years ago. And although I was pretty
|
||||
disappointed when they began
|
||||
[releasing an enterprise edition](https://about.gitlab.com/2013/07/22/announcing-gitlab-enterprise-edition/),
|
||||
the community edition of the project remains impressive. More recently, GitLab
|
||||
has included a
|
||||
[continuous integration software](https://about.gitlab.com/gitlab-ci/) along
|
||||
with their code collaboration solution.
|
||||
|
||||
Recently, I have been using this to produce [Docker](https://www.docker.com/)
|
||||
images for my production environment. Although I had been using Docker for all
|
||||
of my build stages, I was never using the image I was producing for validation.
|
||||
Since I want to be as sure as I can that my production images are functioning, I
|
||||
decided to update my build to use the project Dockerfile to run tests.
|
||||
|
||||
I looked around and found a
|
||||
[few](http://sirile.github.io/2016/09/29/minimal-go-containers-with-docker-and-gitlab-ci.html)
|
||||
[articles](https://www.andrewmunsell.com/blog/ci-cd-with-docker-containers/) on
|
||||
using Docker with Gitlab CI. Unfortunately, they all outlined methods that
|
||||
[did not test the image](https://www.stefanwienert.de/blog/2015/11/07/gitlab-ci-with-docker-starting-guide/)
|
||||
directly or did so in a
|
||||
[complicated way](http://blog.lwolf.org/post/How-to-build-and-test-docker-images-in-gitlab-ci/).
|
||||
I thought I could do better.
|
||||
|
||||
We always want to use Docker for our builds, but running Docker inside of Docker
|
||||
is not recommended. To resolve this, we can mount the host system’s Docker
|
||||
socket inside the container when creating our test runner for building images.
|
||||
|
||||
```
|
||||
[[runners]]
|
||||
name = "docker-runner"
|
||||
url = "https://gitlab.example.com/ci"
|
||||
token = "YOUR_TOKEN"
|
||||
executor = "docker"
|
||||
[runners.docker]
|
||||
tls_verify = false
|
||||
image = "docker:latest"
|
||||
privileged = false
|
||||
disable_cache = false
|
||||
volumes = ["/var/run/docker.sock:/var/run/docker.sock"]
|
||||
```
|
||||
|
||||
Now that we are using the host Docker, we can leverage its image storage and
|
||||
caching for our build. We can also use that image in our other build tasks.
|
||||
|
||||
```
|
||||
stages:
|
||||
- prepare
|
||||
- test
|
||||
- deploy
|
||||
|
||||
build-test-container:
|
||||
stage: prepare
|
||||
script:
|
||||
- docker build -t your-image .
|
||||
tags:
|
||||
- your-docker-tag
|
||||
|
||||
spec:
|
||||
stage: test
|
||||
script:
|
||||
- bundle exec rake db:create db:migrate
|
||||
- bundle exec rspec
|
||||
image: your-image
|
||||
services:
|
||||
- postgres:latest
|
||||
|
||||
# ...
|
||||
```
|
||||
|
||||
The container built from our project Dockerfile is now being directly tested by
|
||||
our continuous integration. As you can see, we can also use any container links
|
||||
without writing extra code.
|
||||
|
||||
Clean and simple!
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
---
|
||||
layout: post
|
||||
title: Singular and Plural Rails Routes for the Same Resource
|
||||
tag:
|
||||
- api
|
||||
- ruby-on-rails
|
||||
- restful
|
||||
---
|
||||
|
||||
Sometimes when building your API with Rails,
|
||||
[following best practices](http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api)
|
||||
may seem difficult. I recently came across one of these cases and was tempted to
|
||||
take a shortcut. However, I held strong and eventually came to a quality RESTful
|
||||
solution — but not without issue.
|
||||
|
||||
I wanted to allow users of my API to quickly access their own user profile. Our
|
||||
application had already implemented a route to allow this via
|
||||
`GET /profiles/:id` and simply implemented with
|
||||
`resources :profiles, only: [:show]` in our routes configuration.
|
||||
|
||||
Unfortunately, our API users wanted to be able to access their profile without
|
||||
providing their ID. My first pass at resolving this was passed in a "fake
|
||||
resource" to accomplish this.
|
||||
|
||||
{% gist 1a056f8dca8931d8872c6cfefebb2d1a %}
|
||||
|
||||
But I had broken one of the RESTful best practices. /profiles/me is not an
|
||||
actual resource but we are pretending it is. So I looked to the
|
||||
[Rails routes documentation](http://guides.rubyonrails.org/routing.html) for
|
||||
guidance and came across
|
||||
[singular resources](http://guides.rubyonrails.org/routing.html#singular-resources).
|
||||
|
||||
> Sometimes, you have a resource that clients always look up without referencing
|
||||
> an ID. For example, you would like /profile to always show the profile of the
|
||||
> currently logged in user.
|
||||
|
||||
I should not have been surprised that my exact use case was cited!
|
||||
|
||||
Now we are back on track! I get to go back to my simple route declaration with
|
||||
`resource :profile, only: :show` and without changing my controller code at all.
|
||||
|
||||
But now I needed users to be able to access each other’s profiles. Again, the
|
||||
Rails documentation had me covered.
|
||||
|
||||
> Because you might want to use the same controller for a singular route
|
||||
> (/account) and a plural route (/accounts/45), singular resources map to plural
|
||||
> controllers. So that, for example, resource :photo and resources :photos
|
||||
> creates both singular and plural routes that map to the same controller
|
||||
> (PhotosController).
|
||||
|
||||
And our implementation stays clean.
|
||||
|
||||
{% gist e8d6641349e4d0ea7e68d22dd3755e9d %}
|
||||
|
||||
This was awesome until I needed to use path helpers. With this implementation,
|
||||
`profile_path(:id)` works as expected but `profile_path` does not. If the order
|
||||
is reversed in the routes configuration, `profile_path` will work and
|
||||
`profile_path(:id)` will not. This is the result of a bug in the Rails core that
|
||||
touches some pretty intricate code that is linked to other issues.
|
||||
[One has even been open for five years](https://github.com/rails/rails/issues/1769)!
|
||||
|
||||
And we can work around that one as well by
|
||||
[overriding the named helpers](http://guides.rubyonrails.org/routing.html#overriding-the-named-helpers).
|
||||
Passing as: to our resource definition creates the helpers with a new name.
|
||||
|
||||
Our final code is ready!
|
||||
|
||||
{% gist e9dcc4cd4bad89554fb01be6627c7b63 %}
|
||||
|
||||
In our application, we can reference a generic profile with `profile_path(:id)`
|
||||
while still having `current_profile_path` to direct the user to their
|
||||
own profile.
|
||||
150
_posts/2017-03-01-a-more-flexible-dockerfile-for-rails.md
Normal file
150
_posts/2017-03-01-a-more-flexible-dockerfile-for-rails.md
Normal file
|
|
@ -0,0 +1,150 @@
|
|||
---
|
||||
layout: post
|
||||
title: A More Flexible Dockerfile for Rails
|
||||
tag:
|
||||
- rails
|
||||
- docker
|
||||
- devops
|
||||
---
|
||||
|
||||
One of my primary motivations for working with [Docker](https://www.docker.com/)
|
||||
was creating a single artifact that I could toss into any environment. It has
|
||||
been fantastic at this. I can throw together a simple Dockerfile that will build
|
||||
my [Rails](http://rubyonrails.org/) application as an image for production in
|
||||
about five minutes.
|
||||
|
||||
```
|
||||
FROM ruby:2.3-alpine
|
||||
|
||||
ADD Gemfile* /app/
|
||||
|
||||
RUN apk add --no-cache --virtual .build-deps build-base \
|
||||
&& apk add --no-cache postgresql-dev tzdata \
|
||||
&& cd /app; bundle install --without test production \
|
||||
&& apk del .build-deps
|
||||
|
||||
ADD . /app
|
||||
RUN chown -R nobody:nogroup /app
|
||||
USER nobody
|
||||
|
||||
ENV RAILS_ENV production
|
||||
|
||||
WORKDIR /app
|
||||
CMD ["bundle", "exec", "rails", "s", "-b", "0.0.0.0", "-p", "8080"]
|
||||
```
|
||||
|
||||
Except now that when I need to run the application’s test suite, I do not have
|
||||
the dependencies I need. That Dockerfile might look something like this.
|
||||
|
||||
```
|
||||
FROM ruby:2.3-alpine
|
||||
|
||||
RUN apk add --no-cache build-base postgresql-dev tzdata
|
||||
|
||||
ADD Gemfile* /app/
|
||||
|
||||
RUN cd /app; bundle install
|
||||
|
||||
ADD . /app
|
||||
RUN chown -R nobody:nogroup /app
|
||||
USER nobody
|
||||
|
||||
|
||||
WORKDIR /app
|
||||
CMD ["bundle", "exec", "rails", "s", "-b", "0.0.0.0", "-p", "8080"]
|
||||
```
|
||||
|
||||
Many people decide to include both of these Dockerfiles in their repository as
|
||||
Dockerfile and Dockerfile.dev. This works perfectly fine. But now we have a
|
||||
production Dockerfile that never gets used during development. Of course, it is
|
||||
going through at least one staging environment (hopefully) but it would be nice
|
||||
if we had a little more testing against it.
|
||||
|
||||
Much like Docker provides us the ability to have a single artifact to move from
|
||||
system to system, I wanted to have a single Dockerfile shared between all
|
||||
environments. Luckily, Docker provides us with
|
||||
[build arguments](https://docs.docker.com/engine/reference/builder/#/arg). A
|
||||
build argument allows us to specify a variable when building the image and then
|
||||
use that variable inside our Dockerfile.
|
||||
|
||||
In our current Rails Dockerfile, we have two primary differences between our
|
||||
environments:
|
||||
|
||||
- The gem groups that are installed
|
||||
- The environment that the application runs as
|
||||
|
||||
Bundler’s
|
||||
[BUNDLE_WITHOUTBUNDLE_WITHOUT](http://bundler.io/man/bundle-config.1.html#LIST-OF-AVAILABLE-KEYS)
|
||||
allows us to specify the gem groups to skip via an environment variable making
|
||||
both of these resolvable through environment configuration. Using this, our
|
||||
shared Dockerfile could look like this:
|
||||
|
||||
```
|
||||
FROM ruby:2.3-alpine
|
||||
|
||||
ARG BUNDLE_WITHOUT=test:development
|
||||
ENV BUNDLE_WITHOUT ${BUNDLE_WITHOUT}
|
||||
|
||||
ADD Gemfile* /app/
|
||||
|
||||
RUN apk add --no-cache --virtual .build-deps build-base \
|
||||
&& apk add --no-cache postgresql-dev tzdata \
|
||||
&& cd /app; bundle install \
|
||||
&& apk del .build-deps
|
||||
|
||||
ADD . /app
|
||||
RUN chown -R nobody:nogroup /app
|
||||
USER nobody
|
||||
|
||||
ARG RAILS_ENV=production
|
||||
ENV RAILS_ENV ${RAILS_ENV}
|
||||
|
||||
WORKDIR /app
|
||||
|
||||
CMD ["bundle", "exec", "rails", "s", "-b", "0.0.0.0", "-p", "8080"]
|
||||
```
|
||||
|
||||
The secret sauce here is `ARG BUNDLE_WITHOUT=test:development`. Running
|
||||
`docker build -t rails-app .` will use the default value provided for the
|
||||
`BUNDLE_WITHOUT` build argument, test:development, and a production Docker image
|
||||
will be built. And if we specify the appropriate build arguments, we can
|
||||
generate an image suitable for development.
|
||||
|
||||
```
|
||||
docker build -t rails-app --build-arg BUNDLE_WITHOUT= --build-arg RAILS_ENV=development .
|
||||
```
|
||||
|
||||
will generate our Docker image with all test and development dependencies
|
||||
available. Typing this for building in development would get pretty tedious so
|
||||
we can use docker-compose to make it easier
|
||||
|
||||
```
|
||||
version: '2'
|
||||
services:
|
||||
app:
|
||||
build:
|
||||
context: .
|
||||
args:
|
||||
- BUNDLE_WITHOUT=
|
||||
- RAILS_ENV=development
|
||||
links:
|
||||
- database
|
||||
ports:
|
||||
- "3000:8080"
|
||||
env_file:
|
||||
- .env
|
||||
volumes:
|
||||
- .:/app
|
||||
tty: true
|
||||
stdin_open: true
|
||||
```
|
||||
|
||||
Now, `docker-compose up -d` is all we need in development to both build and
|
||||
launch our development image.
|
||||
|
||||
Finally, we have a single Dockerfile that can be used to build an image for any
|
||||
of our application’s needs. Of course, there are some trade-offs. For example,
|
||||
build time in development will suffer in some cases. But I have found only
|
||||
maintaining a single Dockerfile to be worth these costs.
|
||||
|
||||
Have another way to deal with this issue? Please share!
|
||||
106
_posts/2017-04-18-write-good-git-commits.md
Normal file
106
_posts/2017-04-18-write-good-git-commits.md
Normal file
|
|
@ -0,0 +1,106 @@
|
|||
---
|
||||
layout: post
|
||||
title: Write Good Git Commits
|
||||
tag:
|
||||
- git
|
||||
- github
|
||||
---
|
||||
|
||||
Writing quality Git commits has been written about to death, but it is so
|
||||
important that I could not help myself from sharing my thoughts on the subject.
|
||||
Mostly, I will be rehashing what
|
||||
[Tim Pope has shared](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html),
|
||||
but I will also include a few of the things that I have used to improve my
|
||||
source histories.
|
||||
|
||||
### Limit the subject of your commit to 50 characters
|
||||
|
||||
Many people live life as I do: at the command line. Limiting to 50 characters
|
||||
allows room for us to use an 80 character width for commands such as git rebase
|
||||
--interactive without width concerns. Even for those in a more modern IDE, the
|
||||
limit is important.
|
||||
|
||||
|
||||
|
||||
As commit messages get longer, it becomes more difficult for everyone to
|
||||
traverse your history.
|
||||
|
||||
### Use the commit body for important details
|
||||
|
||||
It is very rare that I see people extend their commit histories into the body
|
||||
portion of a commit but it is the perfect place to offer extra details. Things
|
||||
like what resources you used to make a specific decision are better left in the
|
||||
commit history than in code comments most of the time. In a
|
||||
[recent commit to my dotfiles](https://github.com/atomaka/dotfiles/commit/28a3897995ff21f63f7893f43582532e4717b8d9),
|
||||
I added a quick alias to correct a TouchBar issue I was having.
|
||||
|
||||
```
|
||||
Fix TouchBar when it (frequently) breaks
|
||||
|
||||
From http://osxdaily.com/2017/01/11/manually-refresh-touch-bar-mac/ this
|
||||
will reset the control portion of the touch bar which has been
|
||||
frequently breaking in New and Interesting Ways™.
|
||||
```
|
||||
|
||||
Without these details, I might never be able to find the source for why I
|
||||
added this.
|
||||
|
||||
Also, limit the line length in the body to 72 characters.
|
||||
|
||||
### Do not use the --message option
|
||||
|
||||
Pretty much everyone I watch make a commit will do so directly at their command
|
||||
prompt with git commit -m. Forcing yourself into an editor will encourage you to
|
||||
add additional details about a commit message. Additionally, your editor can
|
||||
configured to alert you to the 50/72 rule. Simply add au FileType gitcommit set
|
||||
t==72 to your vimrc to auto wrap git messages at 72 characters if vim is
|
||||
configured as your Git editor. [vim-git](https://github.com/tpope/vim-git) is
|
||||
also a fantastic option that will highlight based on these rules.
|
||||
|
||||
If you are struggling with breaking your -m habit, try creating a bash function
|
||||
to prevent its usage.
|
||||
|
||||
```
|
||||
function git {
|
||||
if [[ $@ == "commit -m" ]]; then
|
||||
echo "Do not specify -m for commit"
|
||||
else
|
||||
command git "$@"
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
### Commit as if giving a command
|
||||
|
||||
[How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/)
|
||||
made me consider the subject of my commits a little more. In bullet point 5,
|
||||
Chris says "Use the imperative mood in the subject line." Considering Git itself
|
||||
follows this rule, it made perfect sense to jump on board.
|
||||
|
||||
```
|
||||
Merge branch 'bugfix/correct-spacing'
|
||||
```
|
||||
|
||||
And
|
||||
|
||||
```
|
||||
Revert "Implement person CRUD"
|
||||
```
|
||||
|
||||
The best advice I picked up was write your commit as if you are completing the
|
||||
following sentence: "If applied, this commit will..."
|
||||
|
||||
### Rebase your branches, but leave master alone
|
||||
|
||||
Rebasing is a heated topic in the community but the one thing that everyone can
|
||||
agree on is leaving master alone. Once your commit has made it there, it is
|
||||
history and should never be changed. However, your branch is your story. You get
|
||||
to tell it however you want so craft it in a way that is useful to the reader.
|
||||
|
||||
For me, this is particularly important because the second thing I do when
|
||||
reviewing a new code base is look at the commit history to see to story of the
|
||||
application. Unfortunately, most are riddled with messages like "fixed typo" or
|
||||
"asdf" and the history becomes unreadable.
|
||||
|
||||
Take care in crafting your git messages and you will find much more value in
|
||||
your git logs!
|
||||
4
archive/index.md
Normal file
4
archive/index.md
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
layout: archive
|
||||
title: Archive
|
||||
---
|
||||
BIN
assets/gui-git.webp
Normal file
BIN
assets/gui-git.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 39 KiB |
BIN
atomaka.jpg
Normal file
BIN
atomaka.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
11
build.sh
11
build.sh
|
|
@ -1,9 +1,8 @@
|
|||
#!/bin/bash
|
||||
|
||||
rm -rf build/
|
||||
mkdir -p build/
|
||||
mdformat --wrap 80 _posts/
|
||||
bundle exec jekyll build
|
||||
|
||||
cp index.html build/
|
||||
cp keybase.txt build/
|
||||
|
||||
AWS_DEFAULT_REGION=us-east-2 aws s3 cp --recursive ./build s3://www.atomaka.com/
|
||||
aws s3 sync _site s3://www.atomaka.com \
|
||||
--size-only \
|
||||
--storage-class REDUCED_REDUNDANCY
|
||||
|
|
|
|||
BIN
colors.png
BIN
colors.png
Binary file not shown.
|
Before Width: | Height: | Size: 36 KiB |
BIN
favicon.ico
Normal file
BIN
favicon.ico
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
92
index.html
92
index.html
|
|
@ -1,92 +0,0 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>Personal Website of Andrew Tomaka</title>
|
||||
<meta charset="utf-8">
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" />
|
||||
<meta name="description" content="Personal website of Andrew Tomaka">
|
||||
<link rel="canonical" href="http://www.atomaka.com/">
|
||||
<link href="https://fonts.googleapis.com/css?family=Source+Code+Pro" rel="stylesheet">
|
||||
<style>
|
||||
body {
|
||||
background-color: #4995C7;
|
||||
font-family: 'Source Code Pro', monospace;
|
||||
}
|
||||
ul {
|
||||
display: flex;
|
||||
flex-direction: row;
|
||||
flex-wrap: wrap;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
li {
|
||||
list-style: none;
|
||||
display: inline-block;
|
||||
padding: 5px;
|
||||
}
|
||||
@media all and (max-width: 480px) {
|
||||
ul {
|
||||
flex-direction: column;
|
||||
}
|
||||
}
|
||||
h1 {
|
||||
color: #07507F;
|
||||
}
|
||||
a {
|
||||
color: #096EB0;
|
||||
text-decoration: none;
|
||||
}
|
||||
a:hover {
|
||||
color: #2988B9;
|
||||
}
|
||||
.container {
|
||||
height: 100%;
|
||||
width: 100%;
|
||||
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
|
||||
background-color: #72B0D9;
|
||||
}
|
||||
.content {
|
||||
text-align: center;
|
||||
}
|
||||
.item {
|
||||
max-width: 100%;
|
||||
}
|
||||
.contact {
|
||||
position: absolute;
|
||||
right: 15px;
|
||||
bottom: 10px;
|
||||
}
|
||||
|
||||
.color-primary-0 { color: #2980B9 } /* Main Primary color */
|
||||
.color-primary-1 { color: #72B0D9 }
|
||||
.color-primary-2 { color: #4995C7 }
|
||||
.color-primary-3 { color: #096EB0 }
|
||||
.color-primary-4 { color: #07507F }
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="contact"><a href="mailto:me@atomaka.com">contact</a></div>
|
||||
<div class="container">
|
||||
<div class="item top"></div>
|
||||
<div class="item content">
|
||||
<div class="title">
|
||||
<h1>Andrew Tomaka</h1>
|
||||
</div>
|
||||
<nav>
|
||||
<ul>
|
||||
<li><a href="https://medium.com/@atomaka">writing</a></li>
|
||||
<li><a href="https://stackoverflow.com/story/atomaka">working</a></li>
|
||||
<li><a href="https://slides.com/atomaka">speaking</a></li>
|
||||
<li><a href="https://github.com/atomaka">coding</a></li>
|
||||
<li><a href="https://twitter.com/atomaka">tweeting</a></li>
|
||||
</ul>
|
||||
</nav>
|
||||
</div>
|
||||
<div class="item bottom"></div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
6
index.markdown
Normal file
6
index.markdown
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
# Feel free to add content and custom Front Matter to this file.
|
||||
# To modify the layout, see https://jekyllrb.com/docs/themes/#overriding-theme-defaults
|
||||
|
||||
layout: home
|
||||
---
|
||||
2
requirements.txt
Normal file
2
requirements.txt
Normal file
|
|
@ -0,0 +1,2 @@
|
|||
mdformat
|
||||
mdformat-frontmatter
|
||||
Loading…
Reference in a new issue