y.st./source/pages/en/weblog/2016/01-January/25.xhtml

<?php
/**
 * <https://y.st./>
 * Copyright © 2016 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'title' => 'Walking in tomorrow to try again to get health care',
	'body' => <<<END
<p>
	This morning, I looked into government-sponsored health care again, as they still have not gotten back to me.
	I sent in my application last month, and now this month is almost over.
	It seems that there are places that I can go to get help in person.
	I was planning to walk in today, but I took too long getting ready.
	The place that can help is several hours away from home and I foolishly wanted to set up my music library on my mobile before leaving.
	I will have to go in tomorrow instead.
</p>
<p>
	After deciding on a new file organization scheme for my music library, I knew that I would either have to find a way to use Ex Falso&apos;s conditional syntax more effectively or I would need to do a lot of the sorting by hand.
	I found a page in the <a href="https://quodlibet.readthedocs.org/en/latest/guide/renaming_files.html">Quod Libet</a> manual explaining that Ex Falso&apos;s conditionals do not only have an <code>if</code> syntax, but also an optional <code>else</code> syntax, which is exactly what I needed.
	My new file-renaming string is <code>~/Muziko/\\\\NEW\\\\/&lt;albumartist|&lt;albumartist&gt;|\\\\&gt;/&lt;albumartist&gt;\\\\&lt;album&gt;/&lt;title|&lt;albumartist&gt;\\\\&lt;album&gt;\\\\&lt;title&gt;|&lt;title&gt;&gt;</code>.
</p>
<p>
	Instead of going downtown, I spent most of the day working with regular expressions.
	After further reading of <a href="https://tools.ietf.org/html/rfc3986">$a[RFC] 3986</a>, I decided that I do in fact want to build my $a[URI] parser to be strict.
	Names are very important to me, especially globally-unique names, and in many ways, that is what $a[URI]s are.
	I do not want to support invalid names.
	Once I had that decided, I thought that I could modify the regular expression listed in $a[RFC] 3986, both combining it with another regular expression that I built today and giving it new features that would enforce validity and break the &quot;authority&quot; component down into its &quot;userdata&quot;, &quot;host&quot;, and &quot;port&quot; components.
	However, once I got to the part about enforcing path validity, I saw that my approach would not only produce an ugly and unreadable regular expression, it would also be highly difficult.
	My regular expression would need to branch in a confusing way near the beginning, due to the fact that the characters that are allowed to make up the beginning of a path heavily depend on the presence, or lack of presence, of the authority and scheme components.
	There are five different regular expressions that can determine the validity of a path based on this presence or lack of presence, and they would need to somehow bee hooked into the parts of the main expression that matches the scheme and authority.
	Such a simple view does not work.
	I will need a multi-step approach after all, so most of the code I wrote today is no good.
	My new understanding of the situation should help me write something very usable though.
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
END
);