After deciding I couldn’t get the URLs I wanted for my blog using Cloudflare Pages without some actual real honest-to-goodness rewrites I had to use GitHub Actions for the first time in anger.
An incredibly powerful platform with a misery-inducing YAML syntax. Little more to be said.
What was nice was the chance to use CatLight for the first time since reading about it a few years ago when Matthew Somerville first mentioned it. At the time he needed to write some code to make the output from GitHub Actions available, but happily this is now built-in and so whilst iterating on my YAML mistakes I was getting nice desktop notifications about it.
I don’t get the chance to write much code any more, but tooling that makes it easier to follow the process from local commit to being aware of whether your commit has worked is always a benefit.
So I wanted to parse the feed I retrieved yesterday, and now I know a bit more about how the package system works, I just search NuGet and found SimpleFeedReader
$ dnu install SimpleFeedReader
At this point Visual Studio Code prompts me that it needs to run the `restore` command, so I click the button and in theory SimpleFeedReader becomes available from my code.
In theory anyway. In practice it doesn’t look like it works in .NET Core, so I decided to try and use the System.XML.XPath package to parse the feed myself, but after a few hours of trying to include the dependencies in package.json correctly, I simply couldn’t do it and ended up going to install Visual Studio. I feel very disappointed about this – I was hoping I could treat .NET as just another language – I don’t need a specialised editor to be able to write small scripts in almost any other language, but the docs around .NET Core just aren’t there. Hopefully I will be able to use Visual Studio to work out what I was getting wrong.
After yesterday’s adventure and recent forehead-smacking, this seemed like an appropriate, and small, goal.
After some Googling I found RestSharp, which bills itself as a
Simple REST and HTTP API Client for .NET. Sounds good.
I tried to work out how to add this to my
project.json but couldn’t find any documentation on what it should like, even after I remembered about things like NuGet.
So I guessed and typed
dnu install restsharp, which seemed to fetch the right files. My
package.json didn’t seem to have updated though, so I then did a
dnu restore. This updated the package file, but might have been overkill and a timing issue in my editor.
I now have a small file which will retrieve an Atom file and dump it to screen.
Another small step tomorrow.
It’s been a few years since I last used .net so I thought I’d give it a go. It was slightly more eventful 30 minutes than I’d have liked, so I thought I’d write it up.
I started by trying to install Visual Studio, but half an hour later it was still under 50% done, and since I only wanted to be writing scripts rather than applications, I started looking for some smaller getting started guides and came across Microsoft’s guide to getting started with .NET Core. So I took a brief look at the new shape of the .NET stack, liked what I saw, and went back to the guide.
After installing the .NET Version Manager (dnvm) I had to restart PowerShell to get the changes to my PATH to take effect, and also I had to open an Administrator PowerShell window and run
set-executionpolicy remotesigned because I hit the
Running scripts is disabled on this system error message.
I was using Visual Studio Code, and at this point was also disappointed that SHIFT+ALT+F didn’t format the CSharp code for me, although it did format the JSON.
I’d closed my PowerShell window by this point, and when I opened a new one and ran
dnu restore I got an error message about it not being on my path (
The term ‘dnu’ is not recognized as the name of a cmdlet, function, script file, or operable program.). Running
dnvm upgrade seems to have fixed this and I can now run the commands from both PowerShell and Command Prompt!
My “Hello World” did at least run first time. Phew!
I should now have the infrastructure to get properly going, but this was a much rougher intro than I was hoping for.
Yesterday, with the return of my family from holiday, I forgot to make changes to any of my projects in GitHub, and broke my commit streak at 57 days.
Initially I’d aimed for making changes on 30 consecutive days, just to try and get some momentum up in making progress on a couple of fairly low-key projects that hadn’t been going anywhere, and although I did cheat a few times (GitHub counts things like opening issues on a repo as ‘activity’ and I have plenty of bugs and features!), the vast majority of my activity was real commits, and I found 30 to be quite easy.
I think this is definitely something I’ll try again, but probably in 30-day chunks (each day only tends to give me ~30 minutes free to do any coding at home!), and probably with a more well-defined plan about what I’m actually expecting myself to ship within that time.
Anyway, despite the fact that I’ve finally broken my run, I’m pleased that I managed to get so much higher than I’d originally aimed for. Onwards!
In my last appraisal at work I got asked what I thought makes a good developer. I didn’t give a very good answer, mumbling something about keeping up with current developments, reading around the subject, always trying to improve themselves, comparing yourself to other people and so on.
It turns out that in the last few weeks some people have attempted to answer this question for me.
To start with, Alistair posted Developer Essentials listing the set of skills every developer should have in order to carry out their job. That is to say, all developers. No exceptions and no excuses. I agree with the list, despite failing on a couple which are either on the list of “things I’ve forgotten” or “things I hate” (although this is no excuse, and is in fact, a reason to know them).
More recently, Jeff Atwood has highlighted The Ultimate Code Kata which highlights some of Steve Yegge’s old advice about Practicing Programming and pointing to the Code Kata (which at some point in recent history I began but never completed).
The soundbite summary of Steve’s articles comes early on:
Contrary to what you might believe, merely doing your job every day doesn’t qualify as real practice. Going to meetings isn’t practicing your people skills, and replying to mail isn’t practicing your typing. You have to set aside some time once in a while and do focused practice in order to get better at something.
This seems spot on to me. If you’re not growing as a developer, you’re not a good developer. If you’re continually content to let your skills languish until someone comes and shows you how to be better, you’re not a good developer.