First of all, this is Valve, a bad company, that is notorious for only caring about profit, so it can easily abandon the project and stop supporting it. I’m not singling them out, commercial companies do that, but that’s my point: I don’t trust any of them. And I don’t trust the open source community to carry the torch, no offense.
And it needs support: it’s software based, which is my personal nightmare. A piece of hardware that is useless on its own? Horrible! That’s why I’ve been looking at mice with on-board memory.
And that’s why I’m more or less satisfied with so-called elite/pro/whatever gamepads, because they work as gamepads by themselves. If I can have a gamepad with four programmable back buttons, I’m 90% there: it’s a sweet spot between simplicity and customization.
Because customization is the greatest feature of a Steam Controller. It’s also its biggest drawback: it needs to be customized. Pads are not sticks, nor are they a mouse. They are, in my opinion, better, but only if you willing to spend time tinkering with them. A lot.
I realize that this falls into the “you want perfection but you only got good enough” category, and for some people a Steam Controller or something like it is more of an accessibility aid than it is for me.
All of this is based on my experience with the Steam Controller, which I got on day one. I liked it right away, I never had any complaints about the shape or anything like that. Steam Input (the software part, basically) was good enough to start with, and it got better over time. But after a couple of years I realized that the drawbacks outweighed the benefits: I tinkered more than I played. And in another couple of years Valve decided to rewrite the software and, at least in my opinion, made it worse.
That’s also why I don’t want a Steam Deck. It’s like those old TV combos that have a VHS or DVD player built in. One thing goes out and bye-bye the whole deal.
I also realize that the reason we are not getting Steam Controller 2 may be much simpler: a lawsuit.
Bottom line, I know myself and I like gamepads. And if there’s an interesting new one, there’s a good chance I’ll get it, even if I clearly don’t need one. But it would have to be really, really interesting, and a true successor to the Steam Controller is at the bottom of that list.
At this point, I’ve switched to Kate Editor. It’s much simpler than VS Code/Codium and similar programs, and I like that. There are ways to customize it to your liking that I’m still exploring, but one I’ve already done is add Typograf.
The description is in Russian, so the gist of it is this: Typograf (which can be a CLI application, an extension to your browser, etc.) formats the selected text, changing quotes, dashes, elipses, and stuff like that to it’s fancier form. So "Huh..." would become “Huh…”. It also puts non-breaking spaces where they belong. Pretty useful.
To be fair, Hugo already does the fancy thing with every Markdown file, but I prefer to have more control over it.
And we can use it in Kate! First, let’s install typograf-cli with npm (which is a package manager for things written in JavaScript):
npm installtypograf-cli-g
With -g installation flag, it should be in our $PATH for easy of use.
In Kate, we go Tools → External Tools → Configure → Add → Add Tool. Then fill in the text boxes as follows:
Text Box
Input
Name
Typograf
Executable
typograf
Arguments
--stdin -c/path/to/config
Input
%{Document:Selection:Text}
Output
Replace selected text
-c is for a settings file if we want to change the default behavior. It really wants a full path for some reason, so no ~/. Mine is -c/home/andrew/.config/typograf/typograf.json
At the end, it should look like this:
We can customize these to process the entire document, for example. But I just add a keyboard shortcut (Settings → Configure Keyboard Shortcuts…), and it does the magic on a selected text.
There are many ways to organize your content in Hugo, including custom taxonomies. But I wanted something simpler: a page that lists all the “things” I have written about, with links to the corresponding posts. Here is how I figured it out.
Maybe not the best or most elegant way, but it works and since Hugo is a static site generator, no one will ever know! :)
“Index” is a bit confusing in the web world, but I mean it as “an alphabetical listing of items and their location”.
Content
So on the content side, we need to add this to front mater of each post:
items:
- Name of a thing
- Name of another thing
- Etc.
If there are some pesky characters like colon, the name should be enclosed in quotes: - "Thing: Not the other thing!"
Dictionary
Then we need a list.html in layouts/map/ folder. map can be whatever we want. I won’t cover how to deal with layouts. Here is the main thing, I will go through the details after that:
{{ $mapItems := dict }} creates a dictionary named $mapItems. Dictionary is a list of things where you have a key with attached value (one or many things).
I use $mapSomething for names because I decided to call the whole thing a site map. Can be named anything.
With {{ range .Site.RegularPages }} we want to look through all the pages we have. It’s a loop that goes through them. Maybe that’s too much, there are ways to narrow it down. But if a page doesn’t have items: in its front matter, it won’t show up anyway.
Then we create three variables $mapDate, $mapLink, and $mapTitle that we are going to work with. With $mapLink and $mapTitle we are just assigning them to be (:=) link and title of our pages.
With $mapDate, we also pipe it (|) into time.Formatto look like a string of numbers, with two for each year, month, day, hours, minutes, and seconds. We will use it to make our keys look unique, so if we have two posts that share the same item, they will not override each other.
{{ with .Params.items }} limits our pages to only those that have items: in the front matter.
Then we create another loop {{ range. }}. . (dot) represents the thing we just worked with from the previous command. So, the items:.
{{ $mapItem := . }} creates another variable. These are the items.
Then, for simplicity and readability, we create our unique key with two commands. First, we join the name of the item with the date of the post:
A bit of translation: $mapItems will now be equal to previous $mapItems plus new ( dict… ), where the first thing $mapUnique is a key and a second thing ( slice… ) is a value. The fact that it is a slice just means that there are multiple things in it and we can get them out individually.
To summarize, what we do is two loops. The first one goes through our posts and gets their date, link and title. Within it, so for each post, the second loop goes through our items: and adds them to our dictionary of things, with unique key and some stuff value that we will use to render our list.
We again use a loop, this time for the dictionary we created. It’s going to sort by key, that’s why we removed those articles so the list can be sorted in a nicer way.
In this loop, we useindex to get the specific $value. They start from 0 and go as we set them with slice, post link, item, post title. Title is also unnecessary, but it will show up on hover and will be helpful if there are multiple items.
Conclusion
On my site map, I decided to split all items into multiple categories. I did it very simply, but in a way that is easy for me to work with. Instead of having just items: in front matter, I have three different things: iGames:, iCinema: and iMisc:. Then in the list.html, I repeated the second loop three times, for each of these three things ({{ with .Params.iGames }}, etc.), and each of them adds items to the corresponding dictionary ({{ $mapItemsGames := dict }}, etc.). Then I render every dictionary as its own list.
I am more than sure that there are other ways to accomplish the same thing. There are always different ways to manipulate data. Dictionary just made the most sense to me, with a key that can be used to sort things nicely and then pull things up from value to display in a way I want.
When I started with HTML and CSS, I was using Dreamweaver. It was producing pretty clean code, so many people were recommending it. After some time and the Adobe acquisition, I moved away from visual editors to plain text editors. Now, while something like Visual Studio Code is preferable, I can basically use any text editor.
Something similar seems to have happened with the command line interface. Slowly, through some other programs like Launchy and Everything (alpha with dark mode), I got the idea that text is not only sufficient, but in many cases faster, better and more robust than GUI analogues.
I use Scoop for about 95% of my installs, winget for another few percent, and I would struggle to remember what I installed any other way, especially since creating your own Scoop bucket is pretty simple – here’s mine.
I check for Windows updates with a PowerShell module, I sync files with Robocopy and Rclone, I even install games from the Epic Store with Legendary, among other things.
