“Sample code for the Sign in with Apple API. Contribute to aaronpk/sign-in-with-apple-example development by creating an account on GitHub.”
I’ve started using my new(ish) test site to build my new IndieWeb WordPress theme. It’s very early in the process, and I’m getting the markup in place first, before I go anywhere near a stylesheet – so it all looks very 1996 right now.
The lessons learned on “K” will be put into use with this theme, along with several ideas I’ve picked up along the way. I’ve already reused some of the more useful bits of K to give me a head-start, so I know that stuff like the feed and post microformats should be pretty robust (if not yet 100% complete). The main improvement I want to make over K is in flexibility – i.e. it’s not just usable by me, or locks me/the user into a particular setup.
If there is anything you would like to see in an IndieWeb WordPress theme, or any other suggestions, please file an issue in the repository. I can’t promise I’ll implement it, but at this stage, the chances are high 😉
“Keynote on the topic of open source, markets, debts, purpose, and no less than the meaning of life. Delivered at RailsConf 2019. Also available as a long read below.”
When I was getting into the industry in the mid-to-late 90s, it seemed like we were witnessing the peak of an epic battle between proprietary and free software.
This war was embodied at the proprietary end of the spectrum by Bill Gates and Microsoft. The ultimate proprietary extractors, dominators, and conquerers. And at the free-software end of the spectrum, by Richard Stallman and Free Software Foundation. The ultimate software freedom fighters.
And there’s no doubt that these two men were diametrically opposed on many of the key questions about how software should be made and distributed. But that stark contrast also had a tendency to overshadow the way in which they were strikingly similar.
If you’re a Monocle user, you might have noticed a new feature in your UI today. If you self-host, you’ll want to update your installation to the latest version. Two nice “quality of life” features have gone live, and I’m a little excited, because I helped build one of them 😁
The biggest feature I’ve been missing in Monocle over, say, Feedly, is a “mark all read” button. I follow too many busy sources to be able to keep up with everything, so I frequently mark everything as read and carry on. It helps me not get overloaded.
Aaron had raised an issue to build the feature at some point, but I wanted it, and had a spare weekend, so figured I’d make myself useful!
In all, it was surprisingly straightforward. The Microsub spec is well documented, so I knew how it needed to work. All I had to figure out was how to fit that into how Monocle already did things, and there was already a “mark read” for single entries to work from.
The UI took the longest to build, mostly because I had to figure out the Bulma frontend framework. Rosemary had already come up with some ideas on how it should work, so the hard part had pretty much been done.
And with a little bit of testing, there it was – “Mark All Read” in Monocle. I’ve been running it in my install for a little over a week now, and I hope you’ll find it as useful as I have if you’re a heavy Monocle user.
I can’t take any credit for in the slightest for the new “Show Only Unread Entries” feature – to my knowledge, that was all Aaron. It was a nice surprise to find once I updated my local install from the master branch!
I’ve been running my own instance of Aaron’s excellent Monocle microsub client for a while now. I think it’s time I take the leap and run my own instance of Aperture microsub server as well (and its associated services), just so I don’t have to rely on any services hosted elsewhere.
I just need to figure out if I need to give Aperture its’ own server, rather than run it alongside everything else on my existing VM.
I mentioned before the festive break that I was thinking about open-sourcing “K”, the custom theme I’ve been developing for this site. Since then, I’ve decided I’m going to do it, but I’m going to work to tidy things up beforehand. Some of this has already happened, some of it is yet to be done. For a bit of fun, I’m going to [try to] blog about it whenever I make some progress ?. All-in-all, I’ve identified three main themes I want to focus on before the intial public commits.
My first job is to make the theme more “generic.” As I mentioned, the theme has been very much a hacking together of what I’ve needed, as I’ve needed it. This means a lot of it isn’t as customisable as people expect a modern WordPress theme to be. For example:
- The site logo is an embeded SVG, rather than an image that can be swapped out in the WordPress Customiser.
- The sidebar was, until recently, entirely hardcoded HTML.
I’ve made some progress here – there’s now a “widget area” in the sidebar – but my custom author h-card is still mostly manual (although it does use a WordPress menu for the social profile links). I think I’m going to recreate this as a bundled widget. I could try using the IndieWeb h-card widget, but I liked having the flexibility of my manually crafted card, and the IndieWeb version doesn’t support multiple profiles at the same service.
The second main focus is going to be standards support. I want the markup to be as fully compatible with MF2 and structured data as possible. I’ve spent hours debugging this so far, and I think I have it mostly sorted. IndieWebify.me picks up everything I expect it to, and every parser/validator I’ve thrown at the different pages and types of content have come back correct to my eye. For some reason, IndieNews hasn’t liked any of my submitted posts, but that’s lower priority for now. I haven’t done much with marking up elements like comments, but the main page/blog post/author details seem to be correct.
Finally, the third focus is on the code quality and maintenance. This loops back to the customisability/flexibility theme as well. By its cobbled-together nature, “K” has been a bit… loose in the quality of the PHP code, and the frontend files were/are a nightmare to maintain. Up to now I’ve used a hacked to pieces copy of Bootstrap with a bunch of customisations on top to provide the layout framework (literally just the rules I needed, obtained through UnCSS), and a similarly cutdown set of FontAwesome icons. That’s fine for my use case – even if it has been a faff to add to the site – but it won’t work for other people.
I’ve started adding a build system for these frontend files, but it does mean I’m probably going to have to include the entirety of the minimised version of Bootstrap, and the full FontAwesome SVG sprites. Unless someone has a good suggestion? Unstyle has a CLI tool, but integrating that is probably a step beyind what’s needed for the moment. I haven’t added FontAwesome to the live site yet, but this page should be using the new style.css that’s been compiled from SCSS.
On the PHP side I’ve started making sure it conforms to at least the WordPress Coding Standards. There’s still a few files to update, but functions.php and most of the template files are done. After that I want to make sure everything is as modular as possible. I’ll need to add files to handle the various post-types, error pages, and other screens a more rounded theme would handle. I’ll also be bundling a selection of Post-Kinds templates, once I figure out how I want to display them on this site.
There are other things that will need done no doubt, but these are where I want to focus my efforts for now.
Not all of them need to be fully completed before “K” gets open-sourced, but I would feel a lot more comfortable if at least the first steps were taken along these paths. It is a little dependent on having enough free-time, but I’ve set a goal of uploading to GitHub by the end of the month.
If you have any suggestions, or other feedback, please do let me know — either as a comment below, or on your own site.
As I’ve been experimenting more with IndieWeb ideas on this site, I’ve been kicking around the idea of open sourcing the custom theme I use to power this site (currently called “K”). Part of this is from a desire to start sharing useful code again. I haven’t really put anything out there in years now. Once upon a time, long before the rise of Github, any code I wrote for myself would at least have ended up as a downloadable .zip file.
The other reason I’ve been giving myself, is to add to the pool of MF2-compatible themes available, in an effort to give people more options for deploying Indieweb sites. Right now, the Indeweb wiki only lists a handful of themes as compatible out of the box, so the more that can be added, the better it will be for growing the community.
The thing is, the theme is very much not ready for other people to lay eyes on, in its current state:
- I (currently) do a bunch of non-standard things under the hood.
- I’m also not doing a bunch of theme “best practices”. Simply because I’ve not needed to.
- I’ve not really cared much about testing in browsers beyond the ones I use day to day.
- A lot of the code has been cobbled together as and when I’ve needed it, so there are loads of “standard” features straight-up not implemented.
- There’s a tonne of things hard-coded specifically for me. Those would have to be stripped out or altered to be configurable. That’s more code I’d have to write.
- I’ve hacked up a bunch of dependencies, in the name of optimisation for my own needs. A public release would need to include the full code of these dependencies, or it’ll severely restrict anyone who wants to use the theme.
All in all, there’s quite a lot to do to make the theme usable by anyone who isn’t me. My natural instinct is to hold it back until it’s “ready” but as I’ve been typing this out, I’ve been wondering if I should just go ahead and put the code on Github anyway?
I received an email from a developer the other day, who had forked the repository for my “IIS Express Here” shell extension on GitHub [editors note – no longer available]. He had noticed there was no license information available in the project, so asked if I could either add a license, or give him written permission to adapt my code and share it to others (as is the spirit of GitHub and OSS).
To be honest, this wasn’t something I’d thought about before, and was a bit of an oversight on my part. I’d not really considered the need to add explicit licenses to my repositories. After all, the code is out there anyway – it’s open to use on GitHub, and I’ve often shared it on this blog… if someone wanted to copy the code, they could, right?
Unfortunately, this creates a grey-area, which some are naturally uncomfortable with. Can I use this code in something else? Can I modify it at all? Do I have to pay royalties if I do?
But licensing is hard, isn’t it? All the different types, with different caveats, liabilities, and legal mumbo-jumbo… well, yes, it can be hard. The good folks at GitHub have a solution: ChooseALicense.com is attempting to demystify open source licenses so you can pick the right one for your project. More than this, when you create a new repository on GitHub, the site will ask if you want to add a template license during the initialisation process:
Coming back to the developer who emailed me – I mailed him back to let him know that IIS Express Here is now licensed under the MIT license. This fits best with how I see the code and projects I share on this blog (unless noted otherwise) – free for anyone else to use, but with no warranty, so if something goes wrong then I’m not liable and it’s not my responsibility to fix it. I haven’t got around to updating all of my repos with licenses, as I’m evaluating each one in turn, based on my goals and even whether the project is going to archived.
Today I fired up TextMate to do my first bit of serious PHP coding since my stroke. I’ve been almost entirely XHTML/CSS since getting out of hospital last August, with a little light coding (ASP mostly) since then.
Probably the closest I’ve got to writing any real PHP in 8 months has been learning the basics of WordPress themes from Blog Design Solutions… To be honest, I’ve not had the same drive or determination to “Just Code It” as I once did.
I’ve been reading 37 Signals’ excellent book, Getting Real today. I’m about three quarters of the way through. I doubt I’ve ever said this about a “tech” book before, but it’s a real “page-turner”; Getting Real pulls you in and is real hard to put down once you get started. All the praise you may have heard about this book is justly deserved—it’s essential reading for developers… hell, it should probably be essential reading for anyone who has to work on just about any type of product or in a team.
While I’ve been reading Getting Real, I’ve been feeling like I want to write code again; I want to write something simple, elegant and real. I want to stop thinking about some of the ideas I’ve had over the last few month – no years – and actually do something. So I set-up a development site and database for one such idea, opened TextMate and created a new project.
It hit me like a slap in the face; I’ve forgotten how to do this. It’s like I’m back on square one… like someone sucked most of my programming ability out of my head. I can remember lots of stuff about various PHP functions, syntax and a million myriad details, but actually doing anything with any of it is another matter. I started thinking about the initial, basic class/data structure I would need and it was like the lights were on but nobody was home.
Looking on the bright-side: if I do have to relearn myslef this stuff, it means I’ll be able to do it with a clean slate and Be Real from the very outset…