[{"content":"Overview I was recently looking to quickly add notifications in an internal tool. Nothing fancy, just a simple toast message I could easily pop up when necessary. Usually this is something like “I didn’t load the resource you wanted to look at because it isn’t available”.\nThere are a ton of ways to plumb notifications in, but I wanted to write the minimal amount of code possible. Polling, SSE, websockets are all options – and I plan to dig into those at some point! I already knew about the Flask flashing system so I opted to start there and build something out using HTMX hx-swap-oob.\nThe basic flow is this:\nDuring a request, call flash(<some_message>) to generate a notification While processing the response, either the normal template will render the messages OR we will add the messages to the rendered HTML before sending it back to the browser Initialize any new toast elements that show up in the DOM Message Flashing This part is pretty simple. During request handling, use the flash function to record a message. The message is added to the session cookie and can be retrieved during template rendering. This is fine for my current use case where I just want to give simple feedback on user actions, not a full blown notification subsystem!\nSimple, Contrived Example:\nfrom flask import flash from uuid import uuid4 from my_app import app # Just an example so we can pretend to define a route @app.route('\/message') def message(): # THIS IS ALL IT TAKES flash(f'Random message: {str(uuid4())}') # NO REALLY ^^ this becomes a notification for the current user! return 'ok' HTML Rendering I have hx-boost set on the <body> tag in my base template. There are some elements that are added directly to the document body by 3rd part JS, and these need to be left alone when navigating. So I already have hx-target and hx-select in place in my base template. Since I want to attach new messages to any HTMX request, I can’t rely on my base template.\nInstead, I created a new template for my notifications. This template is included in my base template, outside my main content. This allows me to render any notifications during a normal page load, but it will be ignored during an HTMX request.\n{% set category_icon_map = { "error": "fa-exclamation-triangle", "info": "fa-info-circle", } %} <div id="alerts" class="toast-container position-absolute top-0 end-0 p-3" style="z-index: 100;" hx-swap-oob="afterbegin"> {% with messages = get_flashed_messages(with_categories=True) %} {% for category, message in messages %} <div class="toast align-items-center bg-secondary text-white bg-gradient border-0" role="alert" aria-live="assertive" aria-atomic="true"> <div class="d-flex"> <div class="toast-body"> <span class="fa fa-s {{ category_icon_map[category] }} fa-lg me-1"><\/span> <span class="fw-normal"> {{ message }} <\/span> <\/div> <button type="button" class="btn-close btn-close-white me-2 m-auto" data-bs-dismiss="toast" aria-label="Close"><\/button> <\/div> <\/div> {% endfor %} {% endwith %} <\/div> Yeah yeah ignore the bootstrap stuff ;)\nNow that I have notifications being in a standalone template, I can render this template in isolation. This is where hx-swap-oob comes in: I can add a Flask after_request handler to render this template and add it to the response. Since the rendered HTML is at the top level of whatever response is provided, HTMX will see the hx-swap-oob attribute and go update the appropriate element wherever it actually exists in the DOM based on the id. I am using "afterbegin" to append new notifications to the ones already present.\nThe handler is pretty simple (and probably needs refined):\n@app.after_request def render_messages(response: Response) -> Response: if request.headers.get("HX-Request") and response.data.find(b"div id=\\"alerts\\"") == -1: messages = render_template("includes\/alerts.jinja2") response.data = response.data + messages.encode("utf-8") return response Voila, now I can call flash(<some_message>) during a request and it automatically shows up whether during a normal request or an HTMX request.\nNotification Display Not too tricky, and an area I’d like to improve on. That said… it works and I’ve spent more time on this post than on the actual implementation :P\n\/\/ Normal page load $('.toast').map(function (index, element) { if (element.classList.contains('hide')) { return; } let toast = new bootstrap.Toast(element); toast.show(); setTimeout(function () { element.remove(); }, 15 * 1000); }); \/\/ HTMX requests htmx.onLoad(function (content) { [content].map(el => { if (el.classList.contains('toast')) { let toast = new bootstrap.Toast(el); toast.show(); setTimeout(function () { el.remove(); }, 15 * 1000); } }); }); Basically, on a normal page load find any elements with a toast class and init the Toast. On an HTMX request, just inspect the new content and do the same. This way we don’t get old toasts popping up again :D\nEnd There you have it, stupid simple toast notifications without extra tools\/processes\/etc. This is definitely not an ideal state, but it works reasonably well now and I can tackle a more elegant solution later. Probably.\n","permalink":"https:\/\/blog.jesseops.net\/posts\/htmx-flask-notifications\/","summary":"Overview I was recently looking to quickly add notifications in an internal tool. Nothing fancy, just a simple toast message I could easily pop up when necessary. Usually this is something like “I didn’t load the resource you wanted to look at because it isn’t available”.\nThere are a ton of ways to plumb notifications in, but I wanted to write the minimal amount of code possible. Polling, SSE, websockets are all options – and I plan to dig into those at some point!","title":"Notifications using Flask & HTMX"},{"content":"My usual method for setting up a new computer is to install Syncthing and add all my main synchronized folders, then rsync any specific dotfiles (.vimrc, .gitconfig, etc) to the new system.\nIt’s never super clean, but this does speed me up enough to get moving quickly. I’ve considered setting up a more global $HOME sync folder with a ton of excludes, but I want to be a bit more intentional about updating my system configuration.\nI decided to just use a private GitHub repo to store these dotfiles, taking a lot of care to avoid committing any secrets (I like to assume that anything I store on someone else’s computer will eventually be public).\nThis turned out to be so much easier than I expected, just a simple alias to override the $GIT_DIR and a custom exclude file to make sure I only add very specific files to this repo.\ngit init --bare $HOME\/.cfg echo "*" >> $HOME\/.cfg\/info\/exclude alias dotfile="git --git-dir=$HOME\/.cfg\/ --work-tree=$HOME" I have the above alias added to my .zshrc (so bonus: it is automatically sync’d!) and can do all the normal git commands by calling dotfile:\ndotfile remote add origin git@github.com:private\/repo.git dotfile add .gitconfig dotfile add .zshrc ... # etc dotfile commit -m 'add my dotfiles' dotfile push -u github main Now, to setup a new machine, I need to setup my dotfile repo in my home directory. Just as before when I initialized a bare git repo with a custom GIT_DIR, I need to clone my repo on the new system with the bare flag and pointing to the same .cfg directory for consistency. You can test this non-destructively by creating a temporary folder and referencing it instead of $HOME in the commands below:\n⚠️ This will overrwrite any tracked files in $HOME ⚠️\ngit clone --bare git@github.com:private\/repo.git $HOME\/.cfg git --git-dir=$HOME\/.cfg --work-tree=$HOME checkout -f Now I can do things like manage OS-specific entries and files via branches, or try out major changes without worrying about leaving myself in a broken state on this machine or another one.\n","permalink":"https:\/\/blog.jesseops.net\/posts\/manage-dotfiles\/","summary":"My usual method for setting up a new computer is to install Syncthing and add all my main synchronized folders, then rsync any specific dotfiles (.vimrc, .gitconfig, etc) to the new system.\nIt’s never super clean, but this does speed me up enough to get moving quickly. I’ve considered setting up a more global $HOME sync folder with a ton of excludes, but I want to be a bit more intentional about updating my system configuration.","title":"Managing Dotfiles"},{"content":"Here’s a simple way to expose an Ingress controller running in a private network to the public. My use case is for adhoc standup of Kubernetes clusters via K3d on my computer while testing automation (eg, self managed ArgoCD) so that I can validate cert-manager & external-dns.\nI purposefully kept the tools required to a minimum - this is proof of concept stage more than anything. The concepts aren’t new, but so far I haven’t see this exact solution shared. Not that there isn’t prior art in the space: see InletsPRO or ngrok. Both are paid tools - which is a good thing, pay people for good tools!\nMy use-case can be met with simpler tooling though:\n1 VPS w\/ public IP (DigitalOcean is a great option at $5\/mo) An SSH client sidecar attached to an Ingress controller Pod That’s it! I don’t have this polished up, but it is working on my home cluster right now.\nGenerate SSH Key Use key-based authentication. Just do it.\n\u276f ssh-keygen -t ed25519 -f .\/digitalocean.clusteraccess -C "remote port forward DO to private ingress" Don’t create a passphrase. Copy the digitalocean.clusteraccess.pub file generated and use it when creating the VPS.\nConfigure VPS Again, this isn’t polished - ideally I’d have a simple command here using doctl to create the perfect droplet with the appropriate sshd_config. Suck it up, we’re using the cloud console:\nLogin or create a DigitalOcean account - if it’s a new account you can get $5 credit by getting an invite from someone (drop me a line on Twitter). You don’t need anything crazy, just a basic droplet in a reasonably close zone. Under Authentication choose New SSH Key. Paste in the .pub key you copied in the previous step.\nOnce your droplet is created, grab the public IP address and login:\n\u276f ssh root@161.35.225.155 -i .\/digitalocean.clusteraccess We need to modify the sshd config to enable GatewayPorts. This will permit listening on the public interface so our SSH port forwarding will have the desired result. Edit \/etc\/ssh\/sshd_config using your favorite editor, vim. Uncomment or add the GatewayPorts entry and set it to yes. Then reload ssh: service ssh restart.\nValidate it works Run an http server on your system. I already had mkdocs running on localhost:8000, but you could as easily do the following:\n\u276f echo "<b>hello world<\/b>" > index.html \u276f python3 -m http.server 8080 Serving HTTP on 0.0.0.0 port 8080 (http:\/\/0.0.0.0:8080\/) ... 127.0.0.1 - - [10\/Jul\/2021 08:59:45] "GET \/ HTTP\/1.1" 200 - Use whatever port you like, I overrode the default 8000 to 8080 because… mkdocs was running.\nNow, test your SSH forwarding:\n\u276f ssh root@161.35.225.155 -i .\/digitalocean.clusteraccess -R 80:'*':8000 You should now be able to curl 161.35.225.155:\n\u276f curl 161.35.225.155 <b>hello world<\/b> Patch Ingress Controller Here’s the really fun part, and it’s going to depend heavily on how you deployed your Ingress controller. If you like, you could easily just edit the Deployment object directly. I use helmfile so I opted to use the built-in Kustomize support to patch it in.\nI created a ConfigMap in my ingress controller namespace:\n⚠️ this is just for the proof of concept, this should really go into a secret!\napiVersion: v1 kind: ConfigMap metadata: name: digitalocean-externalip-key data: ssh_key: | -----BEGIN OPENSSH PRIVATE KEY----- ********************************************************************** ********************************************************************** *************************itsasecretyo********************************* ********************************************************************** ********************************************************************** *****= -----END OPENSSH PRIVATE KEY----- And then patched my Ingress controller deployment (note, this is a helmfile specific example):\n- name: ingress-nginx-external namespace: nginx-system chart: nginx-stable\/nginx-ingress labels: repo: nginx-stable chart: nginx-ingress component: ingress domain: external version: ~0.9.3 values: - controller: defaultTLS.secret: nginx-system\/default-{{ .Environment.Values | get "external_domain" "unknown" }}-tls wildcardTLS.secret: nginx-system\/default-{{ .Environment.Values | get "external_domain" "unknown" }}-tls ingressClass: nginx-external service: annotations: metallb.universe.tf\/address-pool: k8s-services strategicMergePatches: - apiVersion: apps\/v1 kind: Deployment metadata: name: ingress-nginx-external-nginx-ingress namespace: nginx-system spec: template: spec: containers: - name: ssh-sidecar image: gfleury\/ssh-client command: ["ssh"] args: - "-i" - "\/etc\/sshkeys\/ssh_key" - "-o" - "UserKnownHostsFile=\/dev\/null" - "-o" - "StrictHostKeyChecking=no" - "-N" - "-R" - "80:0.0.0.0:80" - "-R" - "443:0.0.0.0:443" - "-o ExitOnForwardFailure=yes" - "root@xxx.xxx.xxx.xx" volumeMounts: - name: sshkey-volume mountPath: \/etc\/sshkeys volumes: - name: sshkey-volume configMap: name: digitalocean-externalip-key defaultMode: 256 You’ll note the extra options in the SSH command. First, I want both 80 and 443 available. Since I’m not running interactively, I’d prefer to skip the host key checking. Finally, if the port forwarding fails I want to retry. So the SSH command will exit causing the container to be restarted. Nifty huh? You can verify by tailing the logs of the ssh-sidecar container, or connecting to :80 on the public IP. You should get an nginx 404.\nCreate an Ingress Ok, almost done! Now to create an Ingress. I like using httpbin as a test application.\nRun httpbin & create a Kubernetes service:\n\u276f kubectl -n default run httpbin --image=kennethreitz\/httpbin:latest --port=80 --expose=true And apply this ingress:\n⚠️ This assumes you have cert-manager already setup, otherwise drop the cert-manager & tls items\napiVersion: networking.k8s.io\/v1 kind: Ingress metadata: annotations: cert-manager.io\/cluster-issuer: letsencrypt name: httpbin namespace: default spec: ingressClassName: nginx-external rules: - host: httpbin.somedomain.tld http: paths: - backend: service: name: httpbin port: number: 80 path: \/ pathType: Prefix tls: - hosts: - httpbin.somedomain.tld secretName: httpbin-tls I created the appropriate DNS record on my domain, but if you’re not using cert-manager you could as easily just add a host entry.\nLet’s test:\ncurl -X GET "https:\/\/httpbin.somedomain.tld\/base64\/ZHVkZSwgdGhpcyBpcyBhYnNvbHV0ZWx5IGFtYXppbmcu" -H "accept: text\/html" Next Steps & Acknowledgements This could definitely use polishing up. I added a firewall to my DigitalOcean droplet to allow port 80\/443 from anywhere but only accept 22 connections from my home IP. The whole VPS configuration is a simple Terraform or doctl automation. The SSH key should go in a secret, and this solution only works with a single Ingress controller instance at a time. But for a quick hack this works nicely!\nI modified my ssh-sidecar config from the one found here. Thanks for the great example gfleury!\n","permalink":"https:\/\/blog.jesseops.net\/posts\/simple-externalip-for-home-kubernetes-ingress\/","summary":"Here’s a simple way to expose an Ingress controller running in a private network to the public. My\nuse case is for adhoc standup of Kubernetes clusters via K3d on my computer while testing automation\n(eg, self managed ArgoCD) so that I can validate cert-manager & external-dns.<\/p>","title":"Simple External IP for Home Kubernetes Ingress"},{"content":"I’m sure you’ve never had to do a search for “fix author git multiple commits”. Right? Well, I’m not going to talk about how to do that fix (ugh it’s a pain…). What I DO have to share is a way to hopefully avoid that mess in the future without any crazy arcane incantations or embracing tedious per-repository authorship edits.\nGlobal Config A little background – Git supports multiple layers of configuration at system, global, repository, and of course, CLI levels. The nearest config entry wins (system takes lowest priority with CLI highest).\nIt’s pretty common to simply run “git config –global user.email “me@myself.i” and call it a day. This command updates your global SSH config (located at ~\/.gitconfig on Linux) with your preferred email address.\nThat works if you always use the same email regardless of repository. But if you prefer to keep (for example) personal projects separate from open source contributions, this gets to be a pain as you need to override at least the email config entry per repository.\nOverride Config Just like my trick to use a different SSH key for some repositories, we can use built-in git config directives to make this work. Specifically, includeIf permits including config files based on some conditional.\nI always check my repositories out under ~\/code, and further group related repos together (eg, ~\/code\/work\/{this,that,another}_repo) in subdirectories. It’s pretty simple to check if the current repo is in a specific subdirectory using gitdir. So I just add a .gitconfig to the subdirectory and in my global config add a conditional include for that subdirectory. See below for an example!\nOne additional trick that I use in tandem with my SSH configuration is to rewrite the git remote URL. This allows me to clone exactly as I normally would, but rewrite the URL with something specific to that project. From there my SSH config handles rewriting it back when actually interacting with the git remote.\nTurns out I was missing a really simple way to avoid this URL hack: the core.sshCommand config entry. This is a ton simpler and doesn’t confuse other tools.\nExample Here are my config files, lightly edited:\nUser configuration [user] name = "Jesse Roberts" email = "*****@**********.***" [core] editor = vim [init] defaultBranch = main [rebase] autoStash = true [push] default = upstream [includeIf "gitdir:~\/code\/work\/"] path = "~\/code\/work\/.gitconfig" Subdirectory configuration overrides [user] email = work@workplace.tld name = "Jesse Roberts" [core] sshCommand = ssh -i ~\/.ssh\/<my-work-ssh-key> ","permalink":"https:\/\/blog.jesseops.net\/posts\/override-git-config-multiple-repositories\/","summary":"
I’m sure you’ve never had to do a search for “fix author git multiple commits”<\/em>. Right? Well, I’m\nnot going to talk about how to do that fix (ugh it’s a pain…). What I DO have to share is a way to\nhopefully avoid that mess in the future without any crazy arcane incantations or embracing tedious\nper-repository authorship edits.<\/p>","title":"Override Git Config For Multiple Repositories"},{"content":"Port forwarding is amazingly useful. If you’ve never used this feature before, the tl;dr is you can bind a port on your local system to a port on a remote system. This allows you to interact with a service as if it were running on your computer (eg, connect to a database that is firewalled off).\nssh can also perform “dynamic” port forwarding. This creates a SOCKS http proxy through the remote host. Any tool that respects the https_proxy environment variable can access services on (or access the internet through) the remote server.\nExample: accessing remote Kubernetes API I run k3d on my desktop as a local kubernetes “cluster”. Sometimes I want to sit on the couch and keep working on a project. It’s easy enough to use either method to get access working as if I were sitting at my desk!\n⚠️ k3d binds to 0.0.0.0 on a random port by default. I prefer to set it to 127.0.0.1 and a known port, making simple port binding more predictable.\nDynamic (socks proxy) Easy to setup, but requires https_proxy environment variable to be set. Not all applications work out of the box.\n# Starting out on my laptop, can't access kubernetes API \u276f kubectl --context k3d-blog-example get node The connection to the server 127.0.0.1:6550 was refused - did you specify the right host or port? \u276f screen -S k3d-tunnel ... # Inside screen window \u276f ssh -NnD 127.0.0.1:9001 $user@$desktop ... # `Ctrl+a d` to detach from screen [detached from 53775.k3d-tunnel] \u276f kubectl --context k3d-blog-example get node The connection to the server 127.0.0.1:6550 was refused - did you specify the right host or port? # THAT'S MORE LIKE IT \u276f https_proxy=socks5:\/\/127.0.0.1:9001 kubectl --context k3d-blog-example get node NAME STATUS ROLES AGE VERSION k3d-blog-example-server-0 Ready control-plane,master 111s v1.20.6+k3s1 Local port binding A little more basic, but this binds the desired port locally – effectively behaving as if the service was truly on my local system. The downside is I need to bind a new port for every service I wish to access (e.g., 8080 & 8443 to access the loadbalancer service of my local cluster).\n# Starting out on my laptop, can't access kubernetes API \u276f kubectl --context k3d-blog-example get node The connection to the server 127.0.0.1:6550 was refused - did you specify the right host or port? \u276f screen -S k3d-tunnel ... # Inside screen window \u276f ssh -NnT -L 6550:localhost:6550 $user@$desktop ... # `Ctrl+a d` to detach from screen [detached from 53775.k3d-tunnel] \u276f https_proxy=socks5:\/\/127.0.0.1:9001 kubectl --context k3d-blog-example get node NAME STATUS ROLES AGE VERSION k3d-blog-example-server-0 Ready control-plane,master 1m v1.20.6+k3s1 ","permalink":"https:\/\/blog.jesseops.net\/posts\/access-remote-services-via-ssh\/","summary":"Port forwarding is amazingly useful. If you’ve never used this feature before, the tl;dr is you can\nbind a port on your local<\/em> system to a port on a remote<\/em> system. This allows you to interact with\na service as if it were running on your computer (eg, connect to a database that is firewalled off).<\/p>","title":"Access Remote Services Over SSH"},{"content":"While managing servers directly via SSH is mostly an anti-pattern these days (there’s always that red-headed stepchild of a host that runs those cron entries you’re just not sure if you can delete), I still use it heavily. Here are some tips and usage patterns I’ve integrated into my workflow – and I’m sure I have barely scratched the surface!\nKeep config in sync across workstations I really like to keep my configuration in sync across devices (and backed up!). I use syncthing to accomplish this. I have all my machines (NAS, desktop, laptop{0…?}, phone, work machine) all setup to sync. This is crazy helpful to avoid losing keys and keep consistent configuration.\nI recommend using the .stignore file to avoid synchronizing certain files (eg, work keys\/config, known_hosts, authorized_keys). This is configured per-device!\n\/\/ avoid sync conflicts with known hosts known_hosts \/\/ I prefer to directly manage which machines I can ssh into via my key authorized_keys* \/\/ skip synchronizing work keys\/conf **work** Let your config files do the work Entropy is great isn’t it? What was once a pretty simple id_rsa you setup when first cloning a git repo or configuring a raspberry pi has proliferated into a folder full of keys as you migrated between computers and setup a homelab and forgot old passphrases. How to keep track of which key to use on which servers? And forget keeping track of usernames…\nLuckily, your ssh config can remember all of that!\n✅ Tip ✅\nOn Linux, the global ssh config is located at \/etc\/ssh\/ssh_config. It’s a great place to start familiaring yourself with the available options and to learn how ssh prioritizes them. You can also man ssh_config.\nI keep my ssh config split up into appropriate files. This enables selective syncing and makes it much easier to manage over time.\nBase config – ~\/.ssh\/config I use this mostly to load in my application or environment specific configs, as well as to set some global Host settings:\n# Apply to all hosts unless overridden by more explicit match Host * # Only use identities (eg, keys) explicitly defined via CLI or ssh config # This avoids extra work trying invalid keys IdentitiesOnly yes # Check if remote server is alive, terminate session after 90s if not ServerAliveInterval 30 ServerAliveCountMax 3 # Automatically add keys to ssh-agent AddKeysToAgent yes # Include my env or account specific options Include config.d\/*.conf Home config – ~\/.ssh\/config.d\/$HOMENETWORK.conf This is for things like my NAS, other personal computers, etc.\nHost $DESKTOP # match exactly my desktop name # Specify my home username & personal ssh key User jesseops IdentityFile ~\/.ssh\/jesseops # Override IP to get around VPN issues capturing DNS lookups Hostname 192.168.x.x Host *.localnet # Match any host on my localnet User $AUTOMATIONUSER ForwardAgent yes # Let me jump from one host to another IdentityFile ~\/.ssh\/localnet_infra Git config – ~\/.ssh\/confid.\/git.conf # git specific keys! Host github.com IdentityFile ~\/.ssh\/github Host bitbucket.org IdentityFile ~\/.ssh\/bitbucket Work config – ~\/.ssh\/config.d\/work{,_git}.conf Here I keep track of customizations for $current_job and can exclude it from synchronizing to my personal machines.\n# NOTE: I now use the _proper_ way, ie the core.sshCommand gitconfig entry instead # of hacky URL rules. Much easier. # Neat little trick in combination with my git config that allows me to override # the keys I use to access github\/bitbucket (useful for public hosted organizations) # Host github.com-work # HostName github.com # IdentityFile ~\/.ssh\/work # Specify multiple hostname patterns Host *.workdomain *.workdevdomain IdentityFile ~\/.ssh\/work User $USERID # Add a bastion for accessing eg cloud hosted systems Host work-bastion HostName $bastionip User ec2-user IdentityFile ~\/.ssh\/bastion-key StrictHostKeyChecking no # not secure _but_ for ephemeral instances the host key changes often UserKnownHostsFile=\/dev\/null # Lets just skip tracking host keys anyway # Access host via bastion Host someinternal.cloud HostName $internalip User ec2-user # May not be available in your ssh version, check out # https:\/\/superuser.com\/questions\/1253960\/replace-proxyjump-in-ssh-config ProxyJump work-bastion # exactly what it sounds like ","permalink":"https:\/\/blog.jesseops.net\/posts\/ssh-config\/","summary":"While managing servers directly via SSH is mostly<\/em> an anti-pattern these days (there’s always that\nred-headed stepchild of a host that runs those cron<\/code> entries you’re just not sure<\/em> if you can\ndelete), I still use it heavily. Here are some tips and usage patterns I’ve integrated into my\nworkflow – and I’m sure I have barely scratched the surface!<\/p>","title":"SSH Configuration Tips"},{"content":"Hi there! This is the first – alternatively, last if you’re reading archives – post on this blog.\nI’ve started this blog as a journal of sorts, documenting projects I’m working on and saving notes about things I’ve learned to refer back to later. Some of these maybe be useful to you. If so, feel free to drop me a line by twitter or email.\n","permalink":"https:\/\/blog.jesseops.net\/posts\/hello-world\/","summary":"Hi there! This is the first – alternatively, last if you’re reading archives – post on this blog.\nI’ve started this blog as a journal of sorts, documenting projects I’m working on and saving notes about things I’ve learned to refer back to later. Some of these maybe be useful to you. If so, feel free to drop me a line by twitter or email.","title":"Hello World"}]