Over on my development blog, I've been writing about my recent project, Bulba (a static site generator that powers said blog).
Specifically, I wrote about how I write code, track features, and release new versions. So if you're interested in reading about that, Bulba in general, or just want to see what sort of website Bulba is currently capable generating, check out my development blog.
Apple today announced Self Service Repair, which will allow customers who are comfortable with completing their own repairs access to Apple genuine parts and tools. Available first for the iPhone 12 and iPhone 13 lineups, and soon to be followed by Mac computers featuring M1 chips, Self Service Repair will be available early next year in the US and expand to additional countries throughout 2022. Customers join more than 5,000 Apple Authorised Service Providers (AASPs) and 2,800 Independent Repair Providers who have access to these parts, tools, and manuals.The initial phase of the program will focus on the most commonly serviced modules, such as the iPhone display, battery, and camera. The ability for additional repairs will be available later next year.
My immediate reaction on Twitter to this was that I thought that this is a good idea, and benefits both Apple and consumers. Because this will surely be good for Apple's reputation, and they'll now gain more control of the iPhone parts market. And that means for consumers, they will have access to official parts that they can trust, and also be able to perform repairs themselves.
I'm not too sure Apple are doing this purely for the benefit of consumers though. I'm starting to wonder if they're introducing this program so that they have a counterargument to the right to repair people.
Matt Birchler also shared his opinions on the new program:
I'm super curious to see how this is received by people on both sides of the right to repair argument. Will people who support right to repair see this as a win or an empty gesture distracting from their real concerns? Will people who have argued against right to repair because it would mean bulky products be annoyed because this shows that's not really the case?
Even though I'm sure that Apple will be very restrictive to what parts they sell, and what they "allow" you to repair. I would find it incredibly amusing if Apple find a way to support reasonably priced repairs for batteries, screens, cases, etc. Because right now, the only manufacturers I see that are even thinking about this kind of stuff are making big phones that look ugly. And the excuse that "it's repairable" won't hold up as much.
David Imel has made a fantastic video on Google's Material You design language and how it aims to focus on feel rather than just function. And how its imperfection, constructed from customisability, and personal touches are what makes it good.
Ever since Material You was announced, I've been a fan. I'm not sure if I could pick a winner between Material You and the design language Apple have used in iOS and iPadOS because I think they are born from different perspectives, and both have their own pros and cons.
The best way I can articulate the design differences, is that Apple's design feels clean and precise, while Material You looks much more personal. Both are valid choices, but they're still different, and I think that's great. Because more choice can only be a good thing.
I’ve noticed myself using the command line a lot more recently, at home, and work, so I thought I’d share a few of the little tools and handy commands that I use on a day to day basis.
Note: I use ZSH as my shell, with oh my zsh, so they may differ slightly if you’re using something different.
The most helpful commands that I use have to be aliases for the most minor commands. But because they’re used so often, it saves so much time.
The majority of them are for two things - moving to common directories, and launching applications.
Here are a few examples of directories I have set up with aliases:
That’s just a small snippet, but usually, I have most projects set up with a very small alias. But even if I don’t have one set up for each project, I’ve got one that puts me at the root of my developer folder anyway.
As for applications, I’ve got a few that I use a lot:
xcodeproj in the current directoryxcworkspace in the current directoryBeing a developer, I use Git quite a lot. And that is where oh my zsh comes in handy, as it comes with a huge number of aliases for common Git commands. Here’s a great cheatsheet.
Here are the ones I use the most, and also what the full command is:
gco: git checkout - checkout branchgaa: git add --all - adds all changes in the current directorygc -m "": git commit -v -m "" - commits the current changes with a messagegp: git push - pushes commits to the configured remote repogf: git fetch- fetches branches and tags from the configured remote repoI’m aware that those are pretty minor commands, but they’re so much easier when they’re just one two or three letters.
Also, oh my zsh does come with an alias for committing changes with a message, but it’s gcmsg and that’s longer than just using gc with the -m option.
The most used Git command I use though has to be a little ZSH function I made myself:
function gacp {
gaa; gc -m $1; gp
}
It stands for “git add commit push”, and as you can probably tell, it adds and commits the following changes, with the supplied message, and pushes it to the remote repository.
Most of the time I’m doing stuff like this:
gacp "JIRA-123 fix tests"
Woops!
I don’t use these a lot, but I do have a few aliases to update various websites. They basically use the scp command (secure copy) to transfer files from a local directory to a remote server. Guide.
This isn’t exactly what I have, but they all follow this rough syntax:
scp -r /Users/chris/website user@123.123.123.213:../var/www/
This will recursively upload the contents of a local directory to a remote server. I use this whenever I update changes to my blog theme.
Whether I’m working on a mobile app or REST API at work, I’m usually testing various requests throughout the day. And while I sometimes use a tool like Postman, especially when I’m building a collection for QA testers, I do find it a bit cumbersome sometimes. So that means I end up resorting back to the terminal.
I’ve seen a tool called httpie which does seem to be quite good, but I’ve found curl to be good enough for my uses.
Tip: If you’re stuck with the syntax and don’t have time to wade through documentation, I’d recommend using a tool like Postman to build the request, and you can then export the curl request.
Most of the time I’m just performing GET requests, so the syntax is simply:
curl https://dev.chrishannah.me/feed.json
If you need just the headers of the response there’s the -I option, and if I want both the headers and body it’s a lowercase -i.
Usually, I’m using the command line because I want to test quite quickly, and with slight tweaks, so I find making the command as short as possible helps with this.
The first one for me is to use environment variables. So for example I’ll use one for the base URL of the API, and usually a few for any variables that need to be in the path, especially if these are user account numbers, as it makes it a lot easier to quickly test different scenarios.
This means that a request like this:
curl https://company.com/api/account/2a3e4832-14e6-430d-8c34-748f4626e864/transactions
Can be made a lot shorter by using two environment variables:
export base=https://company.com/api
export account=2a3e4832-14e6-430d-8c34-748f4626e864/transactions
Which means it can look like this:
curl $base/account/$account/transactions
The biggest benefit I find is that allows you to edit the command much easier.
Another tip I have for curl is that if you have a bunch of headers that you need to use, then it helps to have these stored in a file.
You can do this by using the -H command followed by @ and then the filename. For example, this command will read the headers from a file named headers.txt:
curl https://website.com -H @headers.txt
The header file needs to be in this format:
Key: Value
So something like this would work:
Content-Type: application/json
Authorization: Bearer [token]
This is especially handy for me as most of our APIs at work require various authorisation tokens that can be quite large.
You can also use other options to use files for storing the body of the request, but I’ve not had much experience of that, so I’ll have to defer to google.
This goes hand-in-hand with making HTTP requests, in that the responses are usually JSON. For that I use the JSON processor, jq.
Most of the time, I’m just using it to “beautify” data from a curl request, so I pass through the response to jq by piping the output from curl to jq like so:
curl https://dev.chrishannah.me/feed.json | jq
What that does is take the response from the curl request and output a pretty printed version of it.
But you can also use jq to parse the JSON response and pick out certain fields.
So for example, a request to my blogs JSON feed at https://dev.chrishannah.me/feed.json will return a fair bit of JSON data. Something like this:
{
"version": "https://jsonfeed.org/version/1",
"title": "Chris Hannah's Dev Blog",
"home_page_url": "https://dev.chrishannah.me/",
"feed_url": "https://dev.chrishannah.me/feed.json",
"description": "A devlog by Chris Hannah",
"author": {
"name": "Chris Hannah",
"url": "https://chrishannah.me"
},
"items": [
{ ... }
]
}
But say I only wanted to read the author object, I’d just need to use this command:
curl https://dev.chrishannah.me/feed.json | jq '.author'
Which will return just this:
{
"name": "Chris Hannah",
"url": "https://chrishannah.me"
}
There’s a lot more it can do as well, and I’d recommend checking out these examples.
I’m sure there are tons of other resources that go into far more detail on what you can do with the command line. But I thought I’d share a few things that I use it for, just in case it might prompt others to find some ways to save themselves time!
Two announcements. Firstly, I’m building a static site generator. And secondly, that I’m using said generator to power a new blog of mine.
That’s the name. My new side-project, which is a static site generator, built using Node.js, that can transform a few Markdown files into a static site. It’s still early days now, but it’s already got paginated index pages, archive, about page, JSON feed, and of course, a page for every blog post.
I’m in no way a Node.js or JavaScript programmer, so I can’t always be certain that my code is the best. (Nor can I say that it’s the worst). But I think it will be a fun project to work on, and maybe in the future other people can use it.
You can find Bulba on GitHub and NPM.
To both demonstrate the features of my new tool, and to also share the progress of it’s development, I’m using Bulba to power a new development blog. It’s got a pretty nice url as well: dev.chrishannah.me .
Right now, I’m using it for Bulba specific updates, but I can imagine that in the future I may use it to write about other projects I work on too.
Earlier today, I published a post, “Introduction to Bulba”, on my new blog, where I introduce Bulba in detail, showing how it works, what features are currently implemented, and also what I’m working on next.
It’s getting close to the time where I think companies will be asking more and more of their employees to migrated back to office life. This has made me wonder what I personally expect will happen in regard to my own situation, and also what I’m hoping for, and willing to settle for.
Back in February this year, I wrote a post entailing reasons why I didn’t want to return to the office. I’d say that my feelings haven’t changed in that regard. But at the same time, there are aspects of office life that I wouldn’t mind getting back. Although I’m not sure how realistic those actually are.
As for my current work situation, I’m still working from home full-time, having started back in March 2019. The company I work for have started talking about flexible working in the future, although these plans were pushed back recently, as it was planned to be in action around September. But, it did seem that at that point, the balance was seemingly going to be a pretty even split of working at home and in the office.
Right now, my office is open for people to go in and has been for a few months. Except, it’s not open as usual (as you might expect). Instead, only half of our floors are open in the building, and are at a maximum 50% capacity, along with no one having an assigned desk.
If you want to go into the office, you need to book a slot online, and in the morning you have to get your personal items from a locker, pick up a fresh mouse and keyboard, and take everything to your desk.
Once you’re set up at your desk, that’s it for the rest of the day. Because most likely your teammates aren’t even in the building, let alone sat anywhere near you. So you’re basically remote-working from the office. Especially as meetings will continue to require a video call.
That situation is precisely why I haven’t returned to the office at all. Because the value I see in being in an office is the fact that your team is sat together, you can have quick discussions, a meeting can happen in person around a whiteboard, and you can generally socialise with other colleagues. But right now, none of these benefits are possible. And I’m starting to think that while I am open to returning to the office unless most people are more-or-less working from the office full-time, it’s not going to be the same.
For example, my ideal balance is that I work from the office 1 or 2 days a week and the rest from home. But what happens when each member of the team does the same and chooses different days to come in?
If a majority of the team are working most of the time from home, then is it reasonable to expect a permanent desk? Because if not, then you could be spread out all over the office. This means back to everyone sat at a desk connecting to a video call. So you may as well be sat at home.
Because of those reasons, I think a more realistic balance is that most people work 3 or more days in the office if we are to expect a return to normal. Otherwise, I’m not too sure what the benefits of returning would be.
What I think will happen is that some people will choose to go back, pretty much full-time, but it will depend on their role. For example, people on the phone all day might prefer to be in the office, whereas developers like myself will probably choose to stay at home. So I’m a bit pessimistic whether office life will ever actually be normal for me again.
Instead, I think that while companies are offering either flexible or completely remote working, then others will be pressured into doing the same thing. And to be honest, if the company I work at weren’t flexible in letting me work from home enough, then I’d probably look to move somewhere else.
I guess there’s only one way to find out, and that will be to simply wait. But I’m curious to see what will happen to office working over the long-term. And if it will have any effect on house prices, office locations, and cities in general, if they aren’t receiving the same level of footfall as they were before the pandemic.
I have far too many Zoom calls at work, and I always hate the process of finding the calendar event, and then copying the Zoom code or link. Especially as it's never always in the correct place.
So I was seaching for an app that could make this experience better, and I found MeetingBar. It's a menu bar app that shows a list of the days meetings, and you can just click on one of them to join the associated video call.
It's massively customisable, and supports Zoom, Google Meet, Teams, and a few more. One thing I plan on looking at deeper is the custom regex for meeting links, as there are a few odd meetings in my calendar with rather oddly formatted meeting codes.
Following his portraits of acrobatic birds performing a series of stunts, photographer Mark Harvey turns his focus to the larger, more powerful creatures of the avian species. The new collection, titled Raptors In Flight, centers on birds of prey and their graceful movements while on the hunt. Whether framing a barn owl diving to the ground or a harris hawk splaying its wings, each of the images highlights the raptors’ unique physical features, making the individual details of their feathers, curved beaks, and eyes visible.
Mark's photos are absolutely stunning. My favourite is definitely the Golden Eagle above. His Instagram seems to be full of great photos too.
The makers of Mailbrew have crafted yet another great product. This time it's a tool called Feeds Mage, that scans your Twitter follows and unearthes any blogs, newsletters, YouTube channels, etc. that might have previously gone unnoticed. And then from there, you can even create a regular email digest from these sources.
I ran this on my own Twitter account, and it found 149 feeds in total. Some were YouTube channels that I already subscribe to, or blogs that I already subscribe to via RSS feeds. But I did manage to find 11 more blogs that I've now added to my RSS reader!
Note: These are raw thoughts and not a PhD thesis, and therefore should be treated as such.
In my opinion, social media networks like Twitter, Instagram, and to some extent other microblogging platforms, are underutilised and I think we could gain so much more from using them.
In short, I think that social networks are more enjoyable for everyone when people share everyday life, opinions, ideas, life updates, progress, and real experiences.
I’ve noticed a few things that I think are misconceptions on how we should treat social media:
While I don’t believe I’m the messiah brought to Earth to fix every problem with social networks, there are a few things that I think we forget when it comes to using them:
It’s always seemed fascinating to me how we all seem to understand that social media doesn’t represent real life, but we still get caught up in it. It’s like we’re all wilful subscribers to an alternate reality, where we get triggered by purposefully emotive headlines, opinions that differ from our own, and from people that we do not know.
But imagine if we used social networks to share our real-life experiences. We all have them. We can all see the distinction between what happens in real life and what appears on social media.
I think that is where Micro.blog has felt different to platforms like Twitter for me. In a sense, it feels slower, but at the same time, it feels like you are connecting with real people. Whereas when I use Twitter, most of the time it feels like I’m interacting with an online account rather than the person behind it.
I’ve definitely fallen into the trap before, where I’ve used Twitter as a place to share perfect photos, links to my blog posts, and anything else that can bring external validation. But I think I’m going to try and just use it like a normal person for a while, and see how it goes. Nothing I do is perfect, and it won’t ever become perfect. So the only thing I’d ask is that if you do see me on Twitter, please treat my public posts as coming from a real person, not someone simply out to cause havoc.