About me

Hey! I'm Dan, a tech professional from New Zealand who is based in the United Kingdom.

Work

I have run product at several very early stage (less than 10 people, pre product-market fit) startups. Beyond that I have a background in Data Science & Machine Learning from my time as a Data Analyst at New Zealand's largest online school.

Interests

I am endlessly curious, and explore many subjects in my spare time - although they mostly seem to converge around tech.

Although I am unlikely to update this frequently, recent examples include:

Projects

Rocketship

In this lockdown project I used the prompt of a digital art gallery to explore Vue.js.

Prior to being introduced to Vue my programming experience was entirely centered around data analysis - SQL and Jupyter Notebooks. My mind had been blown by the Vue 'get started' guide and I was very keen to build a proper app.

Key learnings:

  • Building a Vue site with Vite was awesome. I did find there was a pretty steep learning curve to implement passing props between components, but I got there.
  • This project also helped me to get the hang of modern CSS. I was watching a number of Kevin Powell videos at the time, and was inspired by his approach to responsive css, for example: allowing elements to breathe and fill space. Resize the page and watch the headers grow/shrink to see this in action. The layout also switches orientation based on flex-overflow rather than via a breakpoint.
  • Although it is not currently available, I also used this project to explore and implement firebase auth, which also saw me using things like the Vue router. I had an idea of introducing user generated content of some description, but that is for another lockdown..

Danielash.me

Well, you're looking at it. My goal with this site was to make a good looking portfolio page. At the same time, I wanted to explore building a site with no framework to feel around the limits of vanilla html/css/js.

I also wanted to focus on performance and accessibility, and to deploy a site using Cloudflare Pages.

Key learnings:

  • The sorts of limitations I found:
    • As my project grew, I was pretty surprised that there wasn't an obvious/simple way to import slabs of static html into my index.html just to clean up the codebase. I entered the rabbithole of web components but that seemed too complicated for what should be very simple.
    • Simultaneously, I have decided not to have show/hide sections, or separate pages simply because it seems overkill to implement the js required when I could reach for a framework. The result - a very long page. I'm probably ready for a framework..
    • I talk more about it below, but it is nice to have a framework automatically cache bust when static content changes.
  • Cloudflare Pages is a delight to use. Awesome to simply push to github and have your site available in data centres around the world, for free.
  • It has been awesome to learn more about caches and CDNs. However, I'm not totally happy with my current approach to cache busting (manually updating query params on static files), and because I don't have a build step (no framework, Cloudflare Pages simply grabs my static files), I am not yet sure how I should automatically version static files..
  • I went through a lengthy design phase before I have landed on this very simple single column design. The key lesson here is to do as much prototyping in figma as possible. Starting and abandoning half completed html/css is painful and time consuming.
  • Similarly sometimes you stumble upon the need for a new component while you're cutting some peripheral html/css - I think the right call here is to stop and prototype in figma, because the time taken in code kills a lot of opportunity for creative destruction.

Don McNewt

Don McDonald is an eccentric Wellingtonian who proliferates marginally coherent content seemingly ad hoc through a variety of local and digital media, including Twitter.

This Node.js project leveraged the Twitter & Open AI API's to generate and post similar tweets to Don MacDonald at a random cadence.

View source on Github

Key learnings:

  • This was a fun project that got my head around Node & Express. In playing around, I made some fun requests that summarised the tweets of an account, and I was interested in extending this to a service that allowed any user to use the APIs to summarise a twitter users tweets, generate tweets, and post on a users behalf.
  • Error handling. I wrote this without considering the unexpected, which meant the code broke and was also very difficult to debug. If I was to return to the project this would be a key objective.
  • I would improve my approach to scheduling. I decided it was uncool for a twitter bot to post at the same time, every day or every hour, etc.
    • To resolve this, I built a function that would post a tweet and then schedule the next tweet at a random point in future. This was prone to issues because it held the time for the next tweet in memory.
    • If the program crashed or restarted this datapoint was lost. I was running this on replit, which it turns out will frequently restart your process, so in reality this function was never able to post tweets.
    • In future I would look to either: frequently ask a probability function whether to post rather than storing a value in memory, or store the datapoint somewhere more durable.
  • To be honest, this could be reduced to a much simpler cloud function that is scheduled, runs a probability function (with some parameter to acheive the desired cadence of tweets) that if unsuccessful returns immediately, and otherwise runs the logic to generate and post a tweet.