Updated .gitignore, fixed post, new post 'aperture-study'
This commit is contained in:
Bastian de Byl
12
.gitignore
vendored
12
.gitignore
vendored
@@ -1,6 +1,6 @@
|
|||||||
themes/*
|
archetypes/
|
||||||
test.md
|
flymd*
|
||||||
public/*
|
public/
|
||||||
static/*
|
resources/
|
||||||
r53Batch.json
|
static/
|
||||||
distroConfig.json
|
themes/
|
||||||
4
Makefile
4
Makefile
@@ -9,8 +9,6 @@ DISTRIBUTION_ID=$(shell aws cloudfront list-distributions \
|
|||||||
--query 'DistributionList.Items[].{id:Id,a:Aliases.Items}[?contains(a,`$(WEBSITE)`)].id' \
|
--query 'DistributionList.Items[].{id:Id,a:Aliases.Items}[?contains(a,`$(WEBSITE)`)].id' \
|
||||||
--output text)
|
--output text)
|
||||||
|
|
||||||
default: run
|
|
||||||
|
|
||||||
build:
|
build:
|
||||||
hugo
|
hugo
|
||||||
|
|
||||||
@@ -29,4 +27,6 @@ cache:
|
|||||||
@# Invalidate caches
|
@# Invalidate caches
|
||||||
aws cloudfront create-invalidation --distribution-id $(DISTRIBUTION_ID) --paths '/*'
|
aws cloudfront create-invalidation --distribution-id $(DISTRIBUTION_ID) --paths '/*'
|
||||||
|
|
||||||
|
# Default target for make (<=3.80)
|
||||||
.PHONY: build run deploy
|
.PHONY: build run deploy
|
||||||
|
default: run
|
||||||
|
|||||||
34
README.md
34
README.md
@@ -1,5 +1,33 @@
|
|||||||
# hugo-site
|
# Description
|
||||||
This repository houses the posts for my site [bdebyl.net](https://bdebyl.net).
|
This repository houses the posts for my site [bdebyl.net](https://bdebyl.net).
|
||||||
|
|
||||||
I make occasional updates to add blog posts, tutorials, projects write-ups, etc. The binary static content is all hosted on S3 (i.e. `.jpeg`, `.png`, etc.).
|
I make occasional updates to add blog posts, tutorials, projects write-ups,
|
||||||
It was setup using **Terraform**, or more specifically [alimac/terraform-s3 (from commit 4b32c8d)](https://github.com/alimac/terraform-s3/tree/4b32c8d336ffacc4318c065f8d135973210f535c) -- big thank you to @alimac on GitHub for that!
|
etc. The binary static content is all hosted on S3 (i.e. `.jpeg`, `.png`, etc.).
|
||||||
|
|
||||||
|
It was setup using **Terraform**, or more
|
||||||
|
specifically
|
||||||
|
[alimac/terraform-s3 (from commit 4b32c8d)](https://github.com/alimac/terraform-s3/tree/4b32c8d336ffacc4318c065f8d135973210f535c) --
|
||||||
|
big thank you to @alimac on GitHub for that!
|
||||||
|
|
||||||
|
|
||||||
|
# Usage
|
||||||
|
The Makefile is a simple wrapper for `hugo` and `aws s3`, but provides useful
|
||||||
|
short commands to test the hugo site locally and deploy it to AWS.
|
||||||
|
|
||||||
|
## Development
|
||||||
|
Simply start the Hugo server:
|
||||||
|
```
|
||||||
|
make run
|
||||||
|
```
|
||||||
|
|
||||||
|
## Deployment
|
||||||
|
To deploy to AWS:
|
||||||
|
```
|
||||||
|
make deploy
|
||||||
|
```
|
||||||
|
|
||||||
|
## Cache Busting
|
||||||
|
Bust the Cloudfront cache:
|
||||||
|
```
|
||||||
|
make cache
|
||||||
|
```
|
||||||
|
|||||||
@@ -1,6 +0,0 @@
|
|||||||
---
|
|
||||||
title: "{{ replace .TranslationBaseName "-" " " | title }}"
|
|
||||||
date: {{ .Date }}
|
|
||||||
draft: true
|
|
||||||
---
|
|
||||||
|
|
||||||
91
content/post/aperture-study.md
Normal file
91
content/post/aperture-study.md
Normal file
@@ -0,0 +1,91 @@
|
|||||||
|
---
|
||||||
|
title: "A Study in Aperture"
|
||||||
|
date: 2019-01-16T22:32:33-05:00
|
||||||
|
categories: ["Blog"]
|
||||||
|
tags: ["photography"]
|
||||||
|
---
|
||||||
|
I found out recently that using the maximum aperture for a lens can have
|
||||||
|
deminishing returns. Simply put: it makes the image look "soft", or otherwise
|
||||||
|
out-of-focus. In this post I aim to find out find the best *acceptable* aperture
|
||||||
|
setting for a specific lens.
|
||||||
|
|
||||||
|
<!--more-->
|
||||||
|
|
||||||
|
# The Setup
|
||||||
|
I started out using a tripod, with the same ISO and exposure compensation using
|
||||||
|
a [**Minolta 50mm f1/7**](https://en.wikipedia.org/wiki/Minolta_AF_50mm_f/1.7)
|
||||||
|
lens. Starting at *f/1.7* I worked my way up at reasonable steps to *f/4.0*. My
|
||||||
|
aim was to compare the differences. See the shots below. The target couch
|
||||||
|
cushion was set up roughly a meter from the bottom center of the tripod.
|
||||||
|
|
||||||
|
|
||||||
|
# Depth-of-Field
|
||||||
|
There may be something to be said about maintaining the best DoF
|
||||||
|
(*Depth-of-field*). However, using [PhotoPills DoF Calculator]
|
||||||
|
(https://www.photopills.com/calculators/dof) proves just how **wild**, using a
|
||||||
|
50mm lens, an aperture of *f/1.7* is. Shooting a target of *2 meters* results in
|
||||||
|
a depth-of-field of **16 centimeters** -- that's a very narrow range! Bumping up
|
||||||
|
the aperture value to *f/2.8* provides a much more reasonable *27 centimeters*,
|
||||||
|
though still a bit narrow. Either way this allays any fears I had of losing out
|
||||||
|
on that sweet, *sweet* [bokeh](https://en.wikipedia.org/wiki/Bokeh), though the
|
||||||
|
photos themselves illustrate that not a significant amount of Depth-of-Field is
|
||||||
|
lost at that target distance of 1 meter.
|
||||||
|
|
||||||
|
|
||||||
|
# Comparison
|
||||||
|
## *f/1.7*--*f/4.0*
|
||||||
|
---
|
||||||
|
The biggest difference can be seen between the *f/1.7* and *f/4.0* shots. Note
|
||||||
|
the increase in clarity on the pillows fabric.
|
||||||
|
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
|
## *f/1.7*--*f/2.8*
|
||||||
|
---
|
||||||
|
At *f/2.8* and above I started noticing less increase in perceived sharpness of
|
||||||
|
the image, though the difference in comparison to *f/1.7* was still fairly
|
||||||
|
noticeable
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
|
## *f/2.8*--*f/4.0*
|
||||||
|
---
|
||||||
|
Aside from the perceived exposure difference from what is most likely a
|
||||||
|
difference in shutter speed, the overall difference does not seem as dramatic
|
||||||
|
from *f/2.8* to *f/4.0*. Personally, I'd say that *f/2.8* is the clear winner in
|
||||||
|
finding the best middle-ground between maximum aperture and image quality.
|
||||||
|
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
|
|
||||||
|
# Individual Photos
|
||||||
|
---
|
||||||
|
Below is the entire collection of all the photos taken of the subject at
|
||||||
|
increasing aperture steps.
|
||||||
|
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
@@ -4,70 +4,107 @@ date: 2018-01-11T04:26:57+01:00
|
|||||||
categories: ["Blog"]
|
categories: ["Blog"]
|
||||||
tags: ["electronics"]
|
tags: ["electronics"]
|
||||||
---
|
---
|
||||||
A colleague offered a pair of Bern Bluetooth drop-in headphones to me fore free, with the catch being: _I had to fix them_
|
A colleague offered a pair of Bern Bluetooth drop-in headphones to me fore free,
|
||||||
|
with the catch being: _I had to fix them_
|
||||||
|
|
||||||
<!--more-->
|
<!--more-->
|
||||||
|
|
||||||
# Don't Turn It On, Take It Apart!
|
# Don't Turn It On, Take It Apart!
|
||||||
|
Past mistakes have taught me to be gentle and patient when it comes to taking
|
||||||
|
things apart. This was no exception either. After looking over the unit on each
|
||||||
|
side, I figured the only way *in* was lifting the mesh cover off. So I went at
|
||||||
|
it, carefully, with a pair of tweezers. I worked my way around the edge and
|
||||||
|
wedged the mesh upwards.
|
||||||
|
|
||||||
---
|
{{% admonition info %}}
|
||||||
|
|
||||||
Past mistakes have taught me to be gentle and patient when it comes to taking things apart. This was no exception either. After looking over the unit on each side, I figured the only way *in* was lifting the mesh cover off. So I went at it, carefully, with a pair of tweezers. I worked my way around the edge and wedged the mesh upwards.
|
|
||||||
|
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
|
|
||||||
# Okay, Maybe Turn It On
|
# Okay, Maybe Turn It On
|
||||||
|
Now that the problematic speaker side was successfully opened without any
|
||||||
|
damage, it was time to investigate what was wrong.
|
||||||
|
|
||||||
---
|
I played a song via smartphone on the speakers. The result was as expected: _the
|
||||||
|
right speaker put out no sound._ I checked the known-good left speaker using my
|
||||||
|
**Rigol 1074Z** oscilloscope. This may not have been entirely necessary, but I
|
||||||
|
wanted to find out what to expect when troubleshooting the right channel.
|
||||||
|
|
||||||
Now that the problematic speaker side was successfully opened without any damage, it was time to investigate what was wrong.
|
{{% admonition info "Left Speaker" %}}
|
||||||
|
|
||||||
I played a song via smartphone on the speakers. The result was as expected: _the right speaker put out no sound._ I checked the known-good left speaker using my **Rigol 1074Z** oscilloscope. This may not have been entirely necessary, but I wanted to find out what to expect when troubleshooting the right channel.
|
|
||||||
|
|
||||||
### Left Speaker
|
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
### Right Speaker
|
{{% admonition info "Right Speaker" %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
|
Knowing what to expect on the oscilloscope, I hooked up the probe to the right,
|
||||||
|
problematic, speaker. The result was much different, indicating either noise or
|
||||||
|
an open circuit. It may be worth mentioning that the right speaker was
|
||||||
|
disconnected at this point in time to ease the troubleshooting process.
|
||||||
|
|
||||||
Knowing what to expect on the oscilloscope, I hooked up the probe to the right, problematic, speaker. The result was much different, indicating either noise or an open circuit. It may be worth mentioning that the right speaker was disconnected at this point in time to ease the troubleshooting process.
|
|
||||||
|
|
||||||
# Where Did It All Go Wrong?
|
# Where Did It All Go Wrong?
|
||||||
|
Lucky for me the PCB pads were labeled -- even better `SPKL+` (_left_) and
|
||||||
|
`SPKR+` (_right_) were easy to find.
|
||||||
|
|
||||||
---
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
Lucky for me the PCB pads were labeled -- even better `SPKL+` (_left_) and `SPKR+` (_right_) were easy to find.
|
Outside of the bluetooth board hidden under the piece of tape, there's not a
|
||||||
|
whole lot going on in the circuit. It was my guess that the visible surface
|
||||||
|
mount QFN chip was most likely the op-amp used for the speakers. A quick Google
|
||||||
|
search of `AIWI TI` (_as shown in the photograph_) resulted
|
||||||
|
in [the following datasheet](http://www.ti.com/lit/ds/symlink/tpa6132a2.pdf)
|
||||||
|
which verified that to be the case.
|
||||||
|
|
||||||
|
<center></center>
|
||||||
|
|
||||||
Outside of the bluetooth board hidden under the piece of tape, there's not a whole lot going on in the circuit. It was my guess that the visible surface mount QFN chip was most likely the op-amp used for the speakers. A quick Google search of `AIWI TI` (_as shown in the photograph_) resulted in [the following datasheet](http://www.ti.com/lit/ds/symlink/tpa6132a2.pdf) which verified that to be the case.
|
**Bingo!** Now knowing the pinout, I could use my trusty multimeter (_a Fluke
|
||||||
|
115_) to test continuity of the circuit from the known-good and the now
|
||||||
|
known-bad speaker traces back to the `OUTL` and `OUTR` outputs of the amplifier.
|
||||||
|
|
||||||
<center</center>
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
**Bingo!** Now knowing the pinout, I could use my trusty multimeter (_a Fluke 115_) to test continuity of the circuit from the known-good and the now known-bad speaker traces back to the `OUTL` and `OUTR` outputs of the amplifier.
|
Removing the board from the housing required a bit of finesse. I didn't want to
|
||||||
|
bother desoldering the left speaker connections to make removal easier. So, with
|
||||||
|
a bit of gentle back and forth I was able to get it the PCB out and inspect
|
||||||
|
traces on the bottom side.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Removing the board from the housing required a bit of finesse. I didn't want to bother desoldering the left speaker connections to make removal easier. So, with a bit of gentle back and forth I was able to get it the PCB out and inspect traces on the bottom side.
|
|
||||||
|
|
||||||
# Something's Not Quite Right...
|
# Something's Not Quite Right...
|
||||||
|
Continuity from `SPKL+` to the QFN pin was good, yet `SPKR+` to the op-amp
|
||||||
|
showed open circuit. Visibly, everything on the PCB looked fine. There were no
|
||||||
|
apparent signs of damaged or lifted traces, nor bad soldered wires or
|
||||||
|
pins. Somehow the trace shortly after the chip was damaged in a way that
|
||||||
|
resulted in an open circuit at the point of the right speaker's solder pad.
|
||||||
|
|
||||||
---
|
After a few minutes of scratching my head and repeatedly going over the
|
||||||
|
datasheet to check for any misunderstandings on my part, I realized the cause of
|
||||||
|
the issue didn't matter so much. The objective was to fix the unit. I simply
|
||||||
|
needed to re-establish the connection for `SPKR+` to the chip.
|
||||||
|
|
||||||
Continuity from `SPKL+` to the QFN pin was good, yet `SPKR+` to the op-amp showed open circuit. Visibly, everything on the PCB looked fine. There were no apparent signs of damaged or lifted traces, nor bad soldered wires or pins. Somehow the trace shortly after the chip was damaged in a way that resulted in an open circuit at the point of the right speaker's solder pad.
|
Using the 3.5mm mini-jack's solder pads, I found continuity to be true from the
|
||||||
|
chips left and right outputs to the conveniently accessible solder pads. _A
|
||||||
|
bodge wire was in order_..
|
||||||
|
|
||||||
After a few minutes of scratching my head and repeatedly going over the datasheet to check for any misunderstandings on my part, I realized the cause of the issue didn't matter so much. The objective was to fix the unit. I simply needed to re-establish the connection for `SPKR+` to the chip.
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
Using the 3.5mm mini-jack's solder pads, I found continuity to be true from the chips left and right outputs to the conveniently accessible solder pads. _A bodge wire was in order_..
|
|
||||||
|
|
||||||
!(/img/headphone-fix/IMG_7515.jpg)
|
|
||||||
|
|
||||||
# All's Well That Ends Well
|
# All's Well That Ends Well
|
||||||
|
Again, using my trusty Fluke 115, I verified continuity from the chip's `OUTR`
|
||||||
|
pin to `SPKR+`. Lo and behold it was now closed-circuit! I was very happy to see
|
||||||
|
the expected waveform from the known-good left channel now also appearing on the
|
||||||
|
right channel.
|
||||||
|
|
||||||
---
|
{{% admonition info %}}
|
||||||
|
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
Again, using my trusty Fluke 115, I verified continuity from the chip's `OUTR` pin to `SPKR+`. Lo and behold it was now closed-circuit! I was very happy to see the expected waveform from the known-good left channel now also appearing on the right channel.
|
At this point I quickly re-soldered the wires to the speaker and enjoyed music
|
||||||
|
now coming into both ears!
|
||||||
|
|
||||||
|
|
||||||
At this point I quickly re-soldered the wires to the speaker and enjoyed music now coming into both ears!
|
|
||||||
|
|||||||
@@ -4,25 +4,40 @@ date: 2017-12-21T01:42:57-05:00
|
|||||||
categories: ["Blog"]
|
categories: ["Blog"]
|
||||||
tags: ["code"]
|
tags: ["code"]
|
||||||
---
|
---
|
||||||
After running into too many road blocks I've decided to go with the [**Tranquilpeak**](https://github.com/kakawait/hugo-tranquilpeak-theme) theme for this site. Before this, I was really looking forward to using the [**Tracks**](https://github.com/ageekymonk/hugo-tracks-theme) theme (ported from WordPress)
|
After running into too many road blocks I've decided to go with
|
||||||
<!--more-->
|
the [**Tranquilpeak**](https://github.com/kakawait/hugo-tranquilpeak-theme)
|
||||||
|
theme for this site. Before this, I was really looking forward to using
|
||||||
|
the [**Tracks**](https://github.com/ageekymonk/hugo-tracks-theme) theme (ported
|
||||||
|
from WordPress)
|
||||||
|
|
||||||
|
<!--more-->
|
||||||
|
# Disclaimer
|
||||||
|
{{% admonition warning "Out of Date" %}}
|
||||||
|
The information in this article is **out-of-date**. I am, and have been, using my
|
||||||
|
own fork of the [hugo-even-theme](https://gitlab.com/bdebyl/hugo-theme-even) on
|
||||||
|
my [GitLab](https://gitlab.com/bdebyl) profile.
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
If you want a general overview, feel free to check out the
|
||||||
|
relevant
|
||||||
|
[commit](https://github.com/bdebyl/hugo-tracks-theme/commit/86ca4963c4d0a67ddb1560197c91617e7d3e3754) on
|
||||||
|
my GitHub fork of the **Tracks** theme.
|
||||||
|
|
||||||
If you want a general overview, feel free to check out the relevant [commit](https://github.com/bdebyl/hugo-tracks-theme/commit/86ca4963c4d0a67ddb1560197c91617e7d3e3754) on my GitHub fork of the **Tracks** theme.
|
|
||||||
|
|
||||||
# Rough Start
|
# Rough Start
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
Right off the bat I noticed the navigation bar seemed a bit off, to say the least:
|
Right off the bat I noticed the navigation bar seemed a bit off, to say the least:
|
||||||
|
|
||||||
|
{{% admonition info %}}
|
||||||
<center></center>
|
<center></center>
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
The links showed as numbers and pointed to `/0`, `/1`, and `/2` respectively. These, of course, lead to 404s.
|
The links showed as numbers and pointed to `/0`, `/1`, and `/2`
|
||||||
|
respectively. These, of course, lead to 404s. It didn't seem like the intended
|
||||||
|
behavior, so I kept digging. Eventually, I found out the problem lied in the
|
||||||
<center></center>
|
usage of the `.Site.Sections` variable used in a loop to populare items in the
|
||||||
|
page header.
|
||||||
This didn't seem like the intended behavior, so I kept digging. Eventually, I found out the problem lied in the usage of the `.Site.Sections` variable used in a loop to populare items in the page header.
|
|
||||||
|
|
||||||
> **.Site.Sections**
|
> **.Site.Sections**
|
||||||
>
|
>
|
||||||
@@ -30,58 +45,73 @@ This didn't seem like the intended behavior, so I kept digging. Eventually, I fo
|
|||||||
|
|
||||||
\- [Source](https://gohugo.io/variables/site/#site-variables-list)
|
\- [Source](https://gohugo.io/variables/site/#site-variables-list)
|
||||||
|
|
||||||
|
As I'm still learning the ins and outs of Hugo, I'm not familiar enough with
|
||||||
|
what a section *should* be beyond what the documentation states. I did attempt
|
||||||
|
to find out how sections work by experimenting with directories in `content/`
|
||||||
|
and files such as `index.md` / `_index.md`. Regretfully, I was unsuccessful in
|
||||||
|
figuring out the proper structure to utilize `.Site.Sections`. I still do not
|
||||||
|
fully understanding where the `0` and `1` "sections" even originated from. In
|
||||||
|
any case, I decided the only course of action was to use something other than
|
||||||
|
sections for the behavior I wanted.
|
||||||
|
|
||||||
As I'm still learning the ins and outs of Hugo, I'm not familiar enough with what a section *should* be beyond what the documentation states. I did attempt to find out how sections work by experimenting with directories in `content/` and files such as `index.md` / `_index.md`. Regretfully, I was unsuccessful in figuring out the proper structure to utilize `.Site.Sections`. I still do not fully understanding where the `0` and `1` "sections" even originated from. In any case, I decided the only course of action was to use something other than sections for the behavior I wanted.
|
|
||||||
|
|
||||||
# The Fix
|
# The Fix
|
||||||
|
Looking at other template files in the theme's layout, I stumbled on a chunk of
|
||||||
----
|
code in `layouts/partials/headers.html` that defined the behavior of the
|
||||||
|
aforementioned "navbar" problem:
|
||||||
Looking at other template files in the theme's layout, I stumbled on a chunk of code in `layouts/partials/headers.html` that defined the behavior of the aforementioned "navbar" problem:
|
|
||||||
|
|
||||||
```html
|
```html
|
||||||
<div class="col-md-6">
|
<div class="col-md-6">
|
||||||
<div class="menu">
|
<div class="menu">
|
||||||
<a href="/">Home /</a>
|
<a href="/">Home /</a>
|
||||||
{{ range $name, $taxonomy := .Site.Sections }}
|
{{ range $name, $taxonomy := .Site.Sections }}
|
||||||
{{ if ne $name "post" }}
|
{{ if ne $name "post" }}
|
||||||
<a href="/{{ $name | urlize }}">{{ $name }} / </a>
|
<a href="/{{ $name | urlize }}">{{ $name }} / </a>
|
||||||
{{ end }}
|
{{ end }}
|
||||||
{{ end }}
|
{{ end }}
|
||||||
</div>
|
</div>
|
||||||
```
|
```
|
||||||
|
|
||||||
The original uses the `.Site.Sections` variable, which I replaced with `.Site.Params.navlinks`. **This** seemed like intended behavior as the user-defined `config.toml` nav links weren't ever utilized or populated anywhere on the site.
|
The original uses the `.Site.Sections` variable, which I replaced with
|
||||||
|
`.Site.Params.navlinks`. **This** seemed like intended behavior as the
|
||||||
|
user-defined `config.toml` nav links weren't ever utilized or populated anywhere
|
||||||
|
on the site.
|
||||||
|
|
||||||
|
{{% admonition info %}}
|
||||||
<center></center>
|
<center></center>
|
||||||
|
{{% /admonition %}}
|
||||||
|
|
||||||
I borrowed the code found in `layouts/partials/sidebar.html` (*which also never appears to be used*) to include the nav links and get my desired behavior:
|
I borrowed the code found in `layouts/partials/sidebar.html` (*which also never
|
||||||
|
appears to be used*) to include the nav links and get my desired behavior:
|
||||||
|
|
||||||
```html
|
```html
|
||||||
<div class="col-md-6">
|
<div class="col-md-6">
|
||||||
<div class="menu">
|
<div class="menu">
|
||||||
{{ $url := .Site.BaseURL }}
|
{{ $url := .Site.BaseURL }}
|
||||||
{{ range .Site.Params.navlinks }}
|
{{ range .Site.Params.navlinks }}
|
||||||
<a href="{{ $url }}{{ .url }}">{{ .name }} /</a>
|
<a href="{{ $url }}{{ .url }}">{{ .name }} /</a>
|
||||||
{{ end }}
|
{{ end }}
|
||||||
</div>
|
</div>
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
||||||
# But Wait, There's More!
|
# But Wait, There's More!
|
||||||
|
After getting more comfortable with how themes are written for Hugo, I found a
|
||||||
----
|
slew of other problems with the ported **Tracks** theme:
|
||||||
|
|
||||||
After getting more comfortable with how themes are written for Hugo, I found a slew of other problems with the ported **Tracks** theme:
|
|
||||||
|
|
||||||
* Improper HTML for `/about/` and `/contact/` resulting in a sloppy looking, inconsistent site.
|
* Improper HTML for `/about/` and `/contact/` resulting in a sloppy looking, inconsistent site.
|
||||||
* Redundant `portfolio.html`: duplicated HTML code already used in `category.html`
|
* Redundant `portfolio.html`: duplicated HTML code already used in `category.html`
|
||||||
* Completely unused:
|
* Completely unused:
|
||||||
* `layouts/partials/sidebar.html`
|
* `layouts/partials/sidebar.html`
|
||||||
* `layouts/_default/taxonomy.html`
|
* `layouts/_default/taxonomy.html`
|
||||||
* `layouts/_default/list.html`
|
* `layouts/_default/list.html`
|
||||||
* `<div class="col-md-10 category-description">` in `layouts/partials/category.html`
|
* `<div class="col-md-10 category-description">` in `layouts/partials/category.html`
|
||||||
* Missing:
|
* Missing:
|
||||||
* Pagination
|
* Pagination
|
||||||
* Syntax Highlighting
|
* Syntax Highlighting
|
||||||
|
|
||||||
At this point I decided it was no longer worth my time in trying to re-work something I wasn't very familiar with. My main objective was simply to get a portfolio website with blog functionality up and running, not to custom build or *re*-build a theme. **Tranquilpeak** offered exactly what I wanted, though not necessarily *how* I wanted them. You can't always get what you want :)
|
At this point I decided it was no longer worth my time in trying to re-work
|
||||||
|
something I wasn't very familiar with. My main objective was simply to get a
|
||||||
|
portfolio website with blog functionality up and running, not to custom build or
|
||||||
|
*re*-build a theme. **Tranquilpeak** offered exactly what I wanted, though not
|
||||||
|
necessarily *how* I wanted them. You can't always get what you want :)
|
||||||
|
|||||||
17
docker/Dockerfile
Normal file
17
docker/Dockerfile
Normal file
@@ -0,0 +1,17 @@
|
|||||||
|
FROM alpine:3.7
|
||||||
|
MAINTAINER Bastian de Byl <bastiandebyl@gmail.com>
|
||||||
|
|
||||||
|
ENV HUGO_DIR /usr/local/hugo
|
||||||
|
ENV HUGO_BIN_DIR /usr/local/bin
|
||||||
|
ENV HUGO_RELEASE_VER 0.52
|
||||||
|
|
||||||
|
RUN mkdir ${HUGO_DIR}
|
||||||
|
ADD https://github.com/gohugoio/hugo/releases/download/v${HUGO_RELEASE_VER}/hugo_${HUGO_RELEASE_VER}_Linux-64bit.tar.gz ${HUGO_DIR}
|
||||||
|
RUN find ${HUGO_DIR} -name "hugo*.tar.gz" -exec tar xzvf {} -C ${HUGO_DIR} \; -exec rm -v {} \; \
|
||||||
|
&& ln -s ${HUGO_DIR}/hugo ${HUGO_BIN_DIR}
|
||||||
|
|
||||||
|
VOLUME /src
|
||||||
|
WORKDIR /src
|
||||||
|
|
||||||
|
EXPOSE 1313
|
||||||
|
CMD hugo server --baseURL=http://localhost:1313 --bind=0.0.0.0
|
||||||
Reference in New Issue
Block a user