I have read some articles recently covering the merits of documenting your work days. It’s interesting that this is something that appears to be taking off. I have been doing it for over 10 years.
Why did I start? I don’t know! It started around the time I worked for my first startup. The change from working on a big team to the chaos of a tiny startup was the main reason I would imagine. I was working on so many things I needed a way to gain closure at the end of the day.
Is it beneficial? Yes! I find it helps me to clear my mind at the end of the day. I can restart the next day knowing exactly where I was. It makes me think about what I have achieved and what I still need to work on. When coding it allows me to remind myself between sessions why I have done what I have done. It also allows me to document things that have failed during the day. I may come back to some code much later on and I get to look back and find why I approached it in the way that I did.
It also comes in handy when things go wrong or are questioned. Over the years my Work Diary has come to the rescue many times. Recently a set of Git merges seemed to have gone wrong. I was able to look back to when the issues occurred and see what the main problem was. When my senior developer asked how I figured it out, I told her about my Work Diary.
I actually write my Work Diary throughout the day now and have done for some time. I find it more productive than writing it all in one go at the end of the day. I use Evernote at present and have done since it came out. I don’t actually think it’s that good anymore but have been too busy to switch. I like the decentralised approach and find the ability to search as key. I do not have any fancy templates I just use a standard bullet list of points under a date heading. I keep one note for each month and have them all grouped in one notebook, tagged.
I am quite interested in some of the approaches I have read of late. There seems to be a trend in keeping a journal in Git. Some people have gone so far as hosting their journals in a public repo.
However you decide to journal your work day, I guarantee that you find it beneficial over time.
Not a blog title I ever thought I would write but it is true. I have joined a gym. Actually, I have been going for over a month and a half. This is a massive thing for me. If I am completely honest it is something I should have done years ago. The thought of joining a gym frightened me. I have been a strict veterinarian for 20 years but my weight has always been an issue. Over the last few years as my son has got older and I get to do fewer activities with him my weight has done nothing but go up. I also noticed that I was starting to feel a bit burned out.
I tried home based exercise. I have done Yoga on and off through the years but that wasn’t going to cut it. I bought a spinning bike but in a cold dark shed, it is no fun. I also tried T 25 which was OK. That ended through injury and of all the things to injure, it was my thumb. Don’t ask!
So my son and a friend wanted to join the gym and I took him along for his induction. It was at the local sports centre and it was nothing like I’d feared for all these years. There were normal people (you know the ones without muscles) of all shapes and sizes. There was a range of ages as well with some members well into their 70’s and 80’s (who would beat me in any given task). Surprised I ended up talking to one of the staff who didn’t sell it to me at all. In fact, her pitch was underwhelming and it worked. She asked what I would want to achieve and how much time I could spare a week. I signed up a month later and have been averaging 5 or 6 workouts a week since. The funny thing is that after the first trip my fear turned into total enjoyment.
Now I am not someone that pushes their hobby’s or beliefs down everyone else’s necks. Yet, from a developers point of view, Gyms are well suited to them. You do not have to be social and it’s all about the data. I have an app which that’s hooked up to the gym machines and Google Fit. I track everything and have started to build an analytics dashboard about most of my life. The approach to self-improvement is like continuous learning that many developers follow.
Above all else, though it’s nothing to do with my physical state. The biggest improvement by far is the improvement to my mental state. I can focus for longer and I feel sharper. No matter how many hours I have been working I no longer have slow periods where I am fighting to keep going.
Automated deployments are the expected way to go these days for good reason. The approach of automating everything has long run through the development profession. Books such as the Pragmatic Programmer drum home the issue and providing the reasons why. All hosted platforms provide a mechanism for automation and you should take advantage. No matter what size your project is.
We have used standard Git (Bitbucket) deployments with Azure since our inception. We’ve never had any issues until this week when we had to handle a difference between the Production and Staging environments.
A developer deployed an HTTP Rewrite rule to the Staging environment that should only be deployed to Production. The developer had assumed that as there were some configuration specific web.configs that they were tied to the deployments. This is not the case. When you set up the automatic deployments via Bitbucket or Github you end up having a .deployment file in your repo root directory. This file provides some settings for Azure to honour. The configuration dependent web.configs actually relate to when we had our own in-house developed script to perform releases. Proof if ever there was any that cleaning up your projects as you go is key to minimising confusion (broken windows).
Anyway, I digress. After some research, a recent addition to Azure is the ability to specify the same contents that are included in the default .deployment file as App Settings on your App Services. Now, this is not ideal but it is better than finding a way to script differences within a static file. Full details can be read here.
The premise is very simple. If you have a line in your .deployment file such as
The left-hand side of the = side becomes the App Setting Key contents while the right-hand side becomes the App Setting Value contents. (The = character is not required). This allows you to tailor your deployments to a specific build configuration.
The only downside to this approach is that you end up having to apply the deployment settings per App Service. However, as you would be scripting the creation and setup of your App Services this won’t be a problem, will it?
The first obvious choice was Ubuntu which still uses Unity by default. Sorry, but try as I might I just can not get on with Unity as a desktop. After installing Ubuntu Gnome (one of the many great community editions) I was set. And then it broke. No real information it would just show a dialog about a “system crash” and the option to report it. Which I did, several times to no avail. Life’s too short …
So then I downloaded Fedora and installed it and then wondered at the tiny square window on my screen. Full Screen did not work out the box. Tldr; you have to add the kernel headers matching your kernel. Then and only then you will be able to install the VirtualBox Guest Additions. At this point, I rebooted looking forward cracking on only to find I could no longer log into the machine. Every time I entered the credentials the screen would return to the user selection screen of GDM. Life is getting shorter …
Based on Fedora I ruled out RHEL and CentOS as I couldn’t face more disappointment at this stage. So that left openSUSE which I haven’t played with since about 2005! Yet, I did remember that they had created a rolling version called Tumbleweed. So I installed it and after a 10-minute installation sat back and basked in the green glow coming from my screen. Finally, I have a working Linux VM and I followed the online instructions to get .Net installed. I cloned my repo and ran dotnet restore and dotnet run and boom. It broke! openSUSE Tumbleweed does not work for .Net Core due to library conflicts. It should work on the non-rolling version of oepnSUSE if you believe some stories. You will only find this out after a lot of Googling and reading of issue tickets in Github.
So losing the will to live I tried a final time with Ubuntu. Installed it and set up .Net, cloned my repo and a dotnet restore and a dotnet run later and I was up and running. I installed Gnome as Unity was worse than I remember it (RIP Unity anyway). I have spent the last couple of days working with it. It is about as good as working with .Net Core on Linux as I previously described before Arch broke the environment.
This really isn’t a name and shame post of non-Arch Linux distros at all. It is however, showing that a number of the beginner friendly distro’s do not work straight out of the box. Using VirtualBox is one way people first play with Linux and try it out. This stuff should be considered during the testing phases. In talking to a number of other developers they have also suffered the same issues in getting .Net Core to work on anything that Ubuntu on Linux. That’s fine but it should be better advertised. The .Net team need to find a way to better support the fast moving package infrastructure of Linux as well if .Net on Linux is to succeed.