From 30d90545bfff6db5ec497105898ffce394efd091 Mon Sep 17 00:00:00 2001 From: Bastian de Byl Date: Wed, 24 Jul 2019 13:36:57 -0400 Subject: [PATCH] Updated changes to reflect new static layout --- Makefile | 48 ++++++++++++++++++++++--------- config.yaml | 3 +- content/about.md | 2 +- content/post/aperture-study.md | 20 ++++++------- content/post/headphone-fix.md | 16 +++++------ content/post/humble-beginnings.md | 4 +-- content/post/thinkpad_usb_fix.md | 14 ++++----- 7 files changed, 64 insertions(+), 43 deletions(-) diff --git a/Makefile b/Makefile index 3d96d8d..f442192 100644 --- a/Makefile +++ b/Makefile @@ -3,31 +3,51 @@ # - image and container names # - path to web root (in /tmp directory) WEBSITE=bdebyl.net +STATIC_DIR=static -DOCKER_IMAGE_NAME=bdebyl/hugo -DOCKER_IMAGE_TAG=0.2 -DOCKER_IMAGE=$(DOCKER_IMAGE_NAME):$(DOCKER_IMAGE_TAG) +HUGO_IMAGE_NAME=bdebyl/hugo +HUGO_IMAGE_TAG=0.4 +HUGO_IMAGE=$(HUGO_IMAGE_NAME):$(HUGO_IMAGE_TAG) + +AWS_IMAGE_NAME=bdebyl/awscli +AWS_IMAGE_TAG=0.2 +AWS_IMAGE=$(AWS_IMAGE_NAME):$(AWS_IMAGE_TAG) # Container Variables RUN_USER=--user $(shell id -u $$USER):$(shell id -g $$USER) RUN_VOL=-v $(shell pwd):/src +AWS_ENV=-e "AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}" -e "AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}" -e "AWS_DEFAULT_REGION=${AWS_DEFAULT_REGION}" +S3_CMD=s3 sync --acl "public-read" --sse "AES256" public/ s3://${WEBSITE} DOCKER_PORT=-p 1313:1313/tcp DOCKER_RUN=docker run -it --rm ${RUN_USER} ${RUN_VOL} # Look up CloudFront distribution ID based on website alias -DISTRIBUTION_ID=$(shell aws cloudfront list-distributions \ - --query 'DistributionList.Items[].{id:Id,a:Aliases.Items}[?contains(a,`$(WEBSITE)`)].id' \ +DISTRIBUTION_ID=$(shell docker run --rm ${AWS_ENV} ${AWS_IMAGE} cloudfront list-distributions \ + --query 'DistributionList.Items[].{id:Id,a:Aliases.Items}[?contains(a,`${WEBSITE}`)].id' \ --output text) -build: - $(DOCKER_RUN) ${DOCKER_IMAGE} +dist: + @echo ${DISTRIBUTION_ID} -run: - $(DOCKER_RUN) ${DOCKER_PORT} ${DOCKER_IMAGE} server --bind=0.0.0.0 -D +static: + s3fs -o use_path_request_style bdebyl.static ${STATIC_DIR} + +unmount: + fusermount -u ${STATIC_DIR} + +build: + $(DOCKER_RUN) ${HUGO_IMAGE} + +_run: static + -$(DOCKER_RUN) ${DOCKER_PORT} ${HUGO_IMAGE} server --bind=0.0.0.0 +run: _run unmount + +version: + $(DOCKER_RUN) ${HUGO_IMAGE} version new: - $(DOCKER_RUN) ${DOCKER_IMAGE} new post/$(shell read -p "Post Name (i.e. my_post.md): " pn; echo $$pn) + $(DOCKER_RUN) ${HUGO_IMAGE} new post/$(shell read -p "Post Name (i.e. my_post.md): " pn; echo $$pn) thumbnails: @./make-thumbs.sh @@ -38,12 +58,12 @@ clean: deploy: clean build @# Upload files to S3 - aws s3 sync --acl "public-read" --sse "AES256" public/ s3://$(WEBSITE) + @$(DOCKER_RUN) ${AWS_ENV} ${AWS_IMAGE} ${S3_CMD} cache: @# Invalidate caches - aws cloudfront create-invalidation --distribution-id ${DISTRIBUTION_ID} --paths '/*' + @cloudfront create-invalidation --distribution-id ${DISTRIBUTION_ID} --paths '/*' # Default target for make (<=3.80) -.PHONY: build run deploy -default: run +.PHONY: static unmount build _run run version new thumbnails clean deploy cache +default: build diff --git a/config.yaml b/config.yaml index 3f7be34..10522eb 100644 --- a/config.yaml +++ b/config.yaml @@ -8,6 +8,7 @@ copyright: "" # default: author.name googleAnalytics: "" # UA-XXXXXXXX-X preserveTaxonomyNames: true enableRobotsTXT: true +buildDrafts: true # https://gohugo.io/content-management/syntax-highlighting/ pygmentsOptions: "" @@ -44,7 +45,7 @@ menu: params: since: "2017" - logoImage: "/img/pubfpr.png" + logoImage: "/static/img/pubfpr.png" logoTitle: "bdebyl" keywords: ["bastian", "de byl", "bdebyl", "bastian de byl"] description: "A random assortment of my personal projects." diff --git a/content/about.md b/content/about.md index 37855a8..242fe2c 100644 --- a/content/about.md +++ b/content/about.md @@ -19,7 +19,7 @@ fingerprint QR-code. Feel free to scan it using the [OpenKeychain](https://www.openkeychain.org/) app! I'll provide it here in-case you are on a mobile device, and my full public key:
-![OpenPGP v4 Fingerprint](/img/pubfpr-lrg.png) +![OpenPGP v4 Fingerprint](/static/img/pubfpr-lrg.png) `70A4 AA02 555D BD55 9189 B4E0 F32B E05E ADAA 54FC`[^2]
diff --git a/content/post/aperture-study.md b/content/post/aperture-study.md index 37ea55f..5c26f30 100644 --- a/content/post/aperture-study.md +++ b/content/post/aperture-study.md @@ -38,7 +38,7 @@ lost at that target distance of 1 meter. 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. -{{< thumb src="/img/aperture-study/f17-f40-comp.jpg" sub="f/1.7 vs. f/4.0" >}} +{{< thumb src="/static/img/aperture-study/f17-f40-comp.jpg" sub="f/1.7 vs. f/4.0" >}} --- @@ -47,7 +47,7 @@ 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 -{{< thumb src="/img/aperture-study/f17-f28-comp.jpg" sub="f/1.7 vs f/2.8" >}} +{{< thumb src="/static/img/aperture-study/f17-f28-comp.jpg" sub="f/1.7 vs f/2.8" >}} --- @@ -57,7 +57,7 @@ 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. -{{< thumb src="/img/aperture-study/f28-f40-comp.jpg" sub="f/2.8 vs. f/4.0" >}} +{{< thumb src="/static/img/aperture-study/f28-f40-comp.jpg" sub="f/2.8 vs. f/4.0" >}} --- @@ -66,11 +66,11 @@ Below is the entire collection of all the photos taken of the subject at increasing aperture steps. {{< thumbgallery >}} - {{< thumb src="/img/aperture-study/f17.jpg" sub="f/1.7" >}} - {{< thumb src="/img/aperture-study/f20.jpg" sub="f/2.0" >}} - {{< thumb src="/img/aperture-study/f22.jpg" sub="f/2.2" >}} - {{< thumb src="/img/aperture-study/f25.jpg" sub="f/2.5" >}} - {{< thumb src="/img/aperture-study/f28.jpg" sub="f/2.8" >}} - {{< thumb src="/img/aperture-study/f32.jpg" sub="f/3.2" >}} - {{< thumb src="/img/aperture-study/f40.jpg" sub="f/4.0" >}} + {{< thumb src="/static/img/aperture-study/f17.jpg" sub="f/1.7" >}} + {{< thumb src="/static/img/aperture-study/f20.jpg" sub="f/2.0" >}} + {{< thumb src="/static/img/aperture-study/f22.jpg" sub="f/2.2" >}} + {{< thumb src="/static/img/aperture-study/f25.jpg" sub="f/2.5" >}} + {{< thumb src="/static/img/aperture-study/f28.jpg" sub="f/2.8" >}} + {{< thumb src="/static/img/aperture-study/f32.jpg" sub="f/3.2" >}} + {{< thumb src="/static/img/aperture-study/f40.jpg" sub="f/4.0" >}} {{< /thumbgallery >}} diff --git a/content/post/headphone-fix.md b/content/post/headphone-fix.md index e81efd1..3e30ff0 100644 --- a/content/post/headphone-fix.md +++ b/content/post/headphone-fix.md @@ -17,7 +17,7 @@ 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. -{{< thumb src="/img/headphone-fix/IMG_7505.jpg" >}} +{{< thumb src="/static/img/headphone-fix/IMG_7505.jpg" >}} # Okay, Maybe Turn It On @@ -30,8 +30,8 @@ right speaker put out no sound._ I checked the known-good left speaker using my wanted to find out what to expect when troubleshooting the right channel. {{< thumbgallery >}} - {{< thumb src="/img/headphone-fix/IMG_7506.jpg" sub="Left Speaker" >}} - {{< thumb src="/img/headphone-fix/IMG_7511.jpg" sub="Right Speaker" >}} + {{< thumb src="/static/img/headphone-fix/IMG_7506.jpg" sub="Left Speaker" >}} + {{< thumb src="/static/img/headphone-fix/IMG_7511.jpg" sub="Right Speaker" >}} {{< /thumbgallery >}} Knowing what to expect on the oscilloscope, I hooked up the probe to the right, @@ -44,7 +44,7 @@ disconnected at this point in time to ease the troubleshooting process. Lucky for me the PCB pads were labeled -- even better `SPKL+` (_left_) and `SPKR+` (_right_) were easy to find. -{{< thumb src="/img/headphone-fix/IMG_7507.jpg" >}} +{{< thumb src="/static/img/headphone-fix/IMG_7507.jpg" >}} 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 @@ -53,13 +53,13 @@ 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. -
![Hello](/img/headphone-fix/TPA6132A2.png)
+
![Hello](/static/img/headphone-fix/TPA6132A2.png)
**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. -{{< thumb src="/img/headphone-fix/IMG_7514.jpg" >}} +{{< thumb src="/static/img/headphone-fix/IMG_7514.jpg" >}} 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 @@ -83,7 +83,7 @@ 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_.. -{{< thumb src="/img/headphone-fix/IMG_7515.jpg" sub="Note the bodge wire" >}} +{{< thumb src="/static/img/headphone-fix/IMG_7515.jpg" sub="Note the bodge wire" >}} # All's Well That Ends Well @@ -92,7 +92,7 @@ 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. -{{< thumb src="/img/headphone-fix/IMG_7516.jpg" >}} +{{< thumb src="/static/img/headphone-fix/IMG_7516.jpg" >}} At this point I quickly re-soldered the wires to the speaker and enjoyed music now coming into both ears! diff --git a/content/post/humble-beginnings.md b/content/post/humble-beginnings.md index 59c0a44..7433f6b 100644 --- a/content/post/humble-beginnings.md +++ b/content/post/humble-beginnings.md @@ -30,7 +30,7 @@ my GitHub fork of the **Tracks** theme. # Rough Start Right off the bat I noticed the navigation bar seemed a bit off, to say the least: -
![Problem Navbar](/img/humble-beginnings/header-problem.png)
+
![Problem Navbar](/static/img/humble-beginnings/header-problem.png)
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 @@ -76,7 +76,7 @@ The original uses the `.Site.Sections` variable, which I replaced with user-defined `config.toml` nav links weren't ever utilized or populated anywhere on the site. -
![Nav Links from Tracks Theme config](/img/humble-beginnings/tracks-config.png)
+
![Nav Links from Tracks Theme config](/static/img/humble-beginnings/tracks-config.png)
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: diff --git a/content/post/thinkpad_usb_fix.md b/content/post/thinkpad_usb_fix.md index 068a177..9f3ba60 100644 --- a/content/post/thinkpad_usb_fix.md +++ b/content/post/thinkpad_usb_fix.md @@ -11,7 +11,7 @@ missing, along with 3 out of 4 pins having been completely broken off. Needless to say this required fixing. -{{< thumb src="/img/thinkpad-usb-fix/DSC04781.jpg" sub="Final result" >}} +{{< thumb src="/static/img/thinkpad-usb-fix/DSC04781.jpg" sub="Final result" >}} # Damage Assessment @@ -19,7 +19,7 @@ The first step was to look at the PCB to assess how this could be, if at all, replaced. From the outside you could see the damage done. Note the single pin left and lack of the inner pad (_bolster?_). -{{< thumb src="/img/thinkpad-usb-fix/DSC04722.jpg" sub="One pin remains" >}} +{{< thumb src="/static/img/thinkpad-usb-fix/DSC04722.jpg" sub="One pin remains" >}} # Measure Twice @@ -28,8 +28,8 @@ needed to have the relevant dimensions in comparing to receptacle part drawings of those available for sale. {{< thumbgallery >}} - {{< thumb src="/img/thinkpad-usb-fix/DSC04714.jpg" >}} - {{< thumb src="/img/thinkpad-usb-fix/DSC04718.jpg" >}} + {{< thumb src="/static/img/thinkpad-usb-fix/DSC04714.jpg" >}} + {{< thumb src="/static/img/thinkpad-usb-fix/DSC04718.jpg" >}} {{< /thumbgallery >}} Using generic, non-branded digital calipers I was able to get the following @@ -66,7 +66,7 @@ unbranded digital caliper. Those values are nearly spot-on. The part was ordered, and arrived quickly at my doorstep. Stacked on top of each other the two receptacles matched up just as I had hoped.. **Fantastic!** -{{< thumb src="/img/thinkpad-usb-fix/DSC04773.jpg" >}} +{{< thumb src="/static/img/thinkpad-usb-fix/DSC04773.jpg" >}} # It's not over yet Initial attempts at desoldering the existing (_broken_) receptacle proved @@ -91,7 +91,7 @@ the modification "process"_. Cutting and bending the pins, I was able to get it soldered on (poorly). There wasn't much wiggle room for cleaning up the bodged-in replacement; this will have to do. -{{< thumb src="/img/thinkpad-usb-fix/DSC04774.jpg" >}} +{{< thumb src="/static/img/thinkpad-usb-fix/DSC04774.jpg" >}} The part was essentially soldered as a wholly surface mount part, which it is not. This could have future issues due to a lack of solder-terminated strain @@ -107,7 +107,7 @@ motherboard from correctly fitting. This was quickly solved by using a Dremel with a low-grit sanding drum and removing material off of the receptacle. The result was acceptable, and provided a tight fitment into the laptop case. -{{< thumb src="/img/thinkpad-usb-fix/DSC04775.jpg" sub="End of the journey" >}} +{{< thumb src="/static/img/thinkpad-usb-fix/DSC04775.jpg" sub="End of the journey" >}} [^1]: [Molex Part No. 482580002](https://www.molex.com/molex/products/datasheet.jsp?part=active/0482580002_IO_CONNECTORS.xml&channel=Products) [^2]: [Digi-Key Part No. WM7087CT-ND](https://www.digikey.com/products/en?keywords=WM7087CT-ND)