Browse Source

Import Posts, fix dates

Zach Oglesby 7 months ago

+ 5
- 2 View File

@@ -2,5 +2,8 @@

- [[][Zach Oglesby]]
- blog
- [[file:blog/][Oh no!]]
- [[file:blog/][Test Post]]
- [[file:blog/][Back to orgmode]]
- [[file:blog/][Reworking Docs]]
- [[file:blog/][Change pass gpg key]]
- [[file:blog/][Surface Pro 3]]
- [[file:blog/][khard ownCloud Contacts for mutt]]

+ 44
- 0
blog/ View File

@@ -0,0 +1,44 @@
#+TITLE: khard ownCloud Contacts for mutt
#+DATE: <Mon, 16 Mar 2015 21:40:35 -0400>

I use [[][ownCloud]] to store my contacts and calendar, but until recently this has not been very useful when using
mutt. My memory is not very good, and email address are hard; so I would have to either pull out my phone or open a
web browser and find a contact. The setup was less than ideal.

Then I remember that [[][vdirsyncer]], the back-end for [[][khal]] a tool I use for the caldav data also supported carddav downloads.
I went to the documentation and found that vdirsyncer was pointing people to a tool called [[][khard]] for use with the carddav data.
So I configured vdirsyncer to download my contacts and went off to get khard working.

[storage my_contacts_local]
# A storage references actual data on a remote server or on the local disk.
# Similar to repositories in OfflineIMAP.
type = filesystem
path = ~/.contacts/
fileext = .vcf

[storage my_contacts_remote]
type = carddav
url = https://my.owncloud.url/remote.php/carddav/
#username =
#password =

A [[][pip]] install (--user) later and it was ready to use. Like khal since the data is already on the
computer the configuration as simple as pointing it to the contacts.

path = ~/.contacts/contacts/
editor = /usr/bin/emacsclient
default_country = USA

All that was left at that point was to tell mutt what my =query_command= was and I had my contacts list available from within mutt.

set query_command= "khard mutt --search '%s'"

+ 12
- 0
blog/ View File

@@ -0,0 +1,12 @@
#+TITLE: Surface Pro 3
#+DATE: <Sat, 22 Aug 2015 09:31:44 -0400>

I have had a Microsoft Surface Pro 3 on my desk for about 10 months, I used it here and there for things related to work, or to play a game of Civ.
When I changed jobs, I no longer had a use for Windows and the Surface just sat at the back of my desk sad and lonely. I then started to think about how my iPad
is okay, but many times when I am out I want to do something in Emacs but can't. So I installed Arch Linux (kernel issues prevented me from getting Fedora running
quickly), and now I have a great, light mobile computer that I can do just about anything on.

Update: Now running Fedora 23 with kernel from [[][shvr]] until everything makes it into the mainline.

#+ATTR_HTML: :width 800px

+ 17
- 0
blog/ View File

@@ -0,0 +1,17 @@
#+TITLE: Change pass gpg key
#+DATE: <Fri, 08 Apr 2016 16:11:34 -0400>

I use [[][pass]] as a password manager for a lot of reasons.
One, it uses GPG to secure passwords, and two because it uses git for backups. When I started
to use the tool I created a second GPG key that I was just using for pass, but as time went
on I no longer liked that idea and wanted to move it back to my primary key to take advantage of my
[[][yubikey]]. The issue was that for the life of me I could not figure out how to do this.

It turns out that it is very simple. Just use
#+begin_src bash
pass init $NEW_KEY_ID
After that pass will re-encrypt all of your passwords with the new key. Two git commits later and all of your
passwords are now using the new key.

+ 97
- 0
blog/ View File

@@ -0,0 +1,97 @@
#+TITLE: Reworking Docs
#+DATE: <Sun, 24 Jul 2016 19:47:14 -0400>

In May of this year the docs team, with the help of some great folks from Red Hat
and the CentOS project held a [[][Documentation FAD]]. During that event we discussed a lot of important
topics including the docs team's publishing toolchain, and the barrier to entry that is

Over the course of the FAD, and after creating a lot of [[][User Stories]], the group came to the
following conclusions:
1. We need to find ways to help enable community members contribute to documentation
3. Sharing documentation with Red Hat Content Services is good for everyone
2. The current Publican setup is not meeting our needs
4. Most people dislike[fn:3] docbook

This lead us to create a complex [[][requirements matrix]] that [[][Remy]] did his best at capturing
online, leading to the conclusion that the best solution is to keep with a static publishing
toolchain that supports a less user hostile markup language.

To that end the team suggested that we use [[][Shaun McCance's]][fn:1] [[][Pintail]] for publishing, [[][AsciiDoc]]
as the markup language, and a new format for our documentation. The most common question about
all of this is "Why?" and the easy answer is that they had the best results against the
requirements, but I hope to give a little more insight into that.

** Pintail
Publican has been great for the Fedora Docs team of the years, but its real strength is in
docbook based full length docs, and that is not want the docs teams is trying to write anymore.
When coupled with the fact that the site is generated with an extremely old version of
Publican, last supported on Fedora ~18, it was time for us to move on.

Pintail, fits the build, because it is simple to use, a simple code base, and well supported by
a responsive upstream. Being written in Python means that members of the Docs Team, and the
Fedora community at large, are already able to troubleshoot and fix bugs; something that was
not easy to do with Publican. Additional, Shaun has been extremely helpful showing us the ropes
and working on feature requests that are only needed by Fedora.

Finally, the tool supports our current and future markdown languages, more on why this is
important in a bit.

** Asciidoc
[[][Markdown]] is probably the most popular markup language around right now, but for a
documentation project it is missing a lot of features and because of that many "flavors" of
markdown [[][exist]]. The issue is simple, markdown was not designed for writing documentation
it was developed so that its creator did not have to write HTML tags. This means that it
lacks support for many of the structural elements that make good documentation great. Asciidoc
was built to support everything that makes docbook great, while keeping users from endlessly
writing ~<tags>~.[fn:2]

The fact that it is a great markup language for documentation was only one part of the
reasoning, it turns out that Red Hat is starting to move more and more towards AsciiDoc as
well, and using the same markup will help the teams collaborate that much easier. So while
AsiiDoc many not be the most popular markup language on the planet, and it still may have a
learning curve for some users, it fits the needs of our documentation better than the

** New Format
Books are great, everyone reads them (or at least did in school), but they are hard to write
and harder to maintain. So we are not going to write them any more, instead smaller single page
topic based documents will be written that can be grouped into collections of a larger topic.

For example, a page may be written about disk formatting and be included in a collection about
system configuration, but that same topic could also be reused in another collection where
formatting a disk is something that needs done. This will not only help to reduce the amount
of documentation that the team needs to maintain, but it will once again allow us to share
content with Red Hat more easily.

** The Plan
All of this is a lot of work. Any one of the sections above is a lot of work, but when you
put it all together it is a great deal more. Waiting for everything to be complete would mean
that we would not see the fruits of this plan for at least a year, but in reality it would
probably be several years. Since fruit is good, as it motivates all of us to keep working,
the plan is to work on this in phases.

The [[][first phase]] will be the implementation of Pintail and a system for continuous [[][integration]]
and [[][delivery]]. This means that once the new site is ready we will begin to use it to publish the
current docbook books that are on [[][]] right now.

Once that is done, we will start the long process of rewriting documents to fit the new style,
using AsciiDoc rather than docbook, publishing new collections of topics as the team decides
that they are ready to publish. That will mean for a period of time we will have both styles of
docs on the site, but it also means that we can focus on writing new documentation without
having to also work on all of the old style docs for every release until we are done.

** Help Wanted
As mentioned before this is a big project, and we need help. Everything from design and
engineering to writing. If you want to help join us in #fedora-docs or take a look at
the [[][tracking ticket]] for phase one on Pagure.

[fn:3] Hate is probably just as accurate

[fn:2] After thinking about it [[][Sparks]] and I had the same
conversation about this at [[][FUDCon Lawrence]] in 2013.

[fn:1] He may prefer we refer to it as [[][Project Mallard's]] Pintail

+ 0
- 4
blog/ View File

@@ -1,4 +0,0 @@
#+TITLE: Oh no!
#+DATE: 2018-11-13 00:00:00

Oh no

+ 0
- 4
blog/ View File

@@ -1,4 +0,0 @@
#+TITLE: Test
#+DATE: 2018-12-26 00:00:00

This is a test

+ 9
- 0
blog/ View File

@@ -0,0 +1,9 @@
#+TITLE: Back to orgmode
#+DATE: <Fri, 28 Dec 2018 22:38:09 -0500>

I have moved my [[][blog]] back to being generated by orgmode.
This time around it I am only using org-publish, so it
is very simple. I may or may not try and add back some
IndieWeb features over time, but I am not blogging much
as of late, so it may take some time to find the motivation
for that.

img/fav.ico View File

img/haskell-logo.png View File

img/surface.png View File

img/zoglesby.jpg View File

+ 1
- 1 View File

@@ -20,7 +20,7 @@
+ [[][]] on [[][Matrix]]
+ [[][zoglesby]] on keybase
** Blog
** [[file:blog.html][Blog]]
#+INCLUDE: :lines "5-9" :only-contents t

** Projects

+ 36
- 0 View File

@@ -0,0 +1,36 @@
#!/usr/bin/env bash

if [ "$1" == "" ]; then
echo "Usage: 'Title of the Post'"
exit 1

cwd="$( cd "${BASH_SOURCE[0]%/*}" && pwd )"

# Taken from
tr '[:upper:]' '[:lower:]' | tr -cs '[:alnum:]' '-'
} <<< "$title")"

date="$(date '+%Y-%m-%d')"

longdate="$(date -R)"

if [ -f "$file" ]; then
echo "A post with that title already exists from today's date."
exit 1

echo "#+TITLE: $title" >> "$file"
echo "#+DATE: <$longdate>" >> "$file"
echo >> "$file"
echo "Created: $file"
echo "Done."

emacsclient -n $file