🎤 Trippingly: A Modest Attempt at Speech Practice Assistance 🗣️

 Right then. Ever found yourself, perhaps, a tad tongue-tied? Or just thinking it might be useful to have a digital companion for those speech practice sessions? Well, Trippingly is my current endeavour in that very direction. It's an application intended to streamline the process of preparing and, in due course, analysing one's verbal deliveries.

This document serves as a rather straightforward guide to getting Trippingly up and running. Whether you're contemplating a contribution, simply curious to see how it ticks, or even just looking for a reference for future self, you should find what you need here.

Progress Report: What's Been Done So Far

We've managed to lay some of the groundwork, establishing the basics for Trippingly. Here's a brief rundown of the current capabilities:

User Management: Basic register and login functionality is in place, handled by Firebase Authentication. Standard stuff, really.

Speech Ingestion: One can now upload speech texts, currently as .txt files. These are then tucked away securely in a personal Firestore collection.

Content Listing: Once a speech has been successfully uploaded, it'll appear in a list on your dashboard. Quite convenient, one hopes.

Detail View: Clicking on a speech entry now takes you to a dedicated page, allowing for a full perusal of the content. No more awkward truncations.

List Synchronisation: The dashboard's speech list now updates itself automatically after a new upload. No manual refresh required, which is nice.

<b>The Technical Bits: A Brief Overview 🛠️</b>

For those interested in the underlying plumbing, Trippingly is built upon a fairly standard modern web stack:

Frontend:React: For building a dynamic and responsive user interface.
Vite: Our blazing-fast build tool for a snappy development experience.
React Router DOM: For seamless navigation between different pages in the app.
Backend:Firebase Cloud Functions: Our serverless backend, running Node.js. This is where our API endpoints live (e.g., handling uploads, fetching speeches).
Express.js: A minimalist web framework used within our Cloud Functions to organize our API routes.
Database:
Firebase Firestore: A flexible, scalable NoSQL cloud database that stores all our user data and speech content.
Authentication:
Firebase Authentication: Handles all user registration, login, and session management securely.

Getting Trippingly Up and Running (For You!)

Ready to get your hands dirty? Follow these steps to set up Trippingly on your local machine.

Prerequisites: The Essentials

Before we begin, make sure you have these installed:

1. Node.js & npm: Download and install from nodejs.org. We recommend an LTS version.
2. Firebase CLI: If you don't have it, install it globally:
   Bash

   npm install -g firebase-tools
   

   Then, log in to Firebase:
   Bash

   firebase login
   

Step 1: Clone the Repository

First things first, grab the code!

Bash

git clone https://github.com/your-username/Trippingly.git # Replace with your actual repo URL!
cd Trippingly

Step 2: Set Up Your Firebase Project

This is crucial! Trippingly needs a Firebase project to connect to.

1. Create a New Firebase Project: Go to the Firebase Console and click "Add project." Follow the steps to create a new project (e.g., trippingly-dev).
2. Initialize Firebase in Your Project: Navigate to the root of your cloned repository:
   Bash

   firebase init
   

   • When prompted, select:
     • Firestore: To set up your database.
     • Functions: To set up your backend.
   • Choose Use an existing project and select the Firebase project you just created.
   • For Firestore rules: Accept the default file name (firestore.rules).
   • For Functions: Accept the default language (JavaScript). Choose npm as the dependency manager. Do not install dependencies at this point (we'll do it manually for the backend folder).
3. Set Up Firebase Functions Directory: Ensure your functions code is correctly linked. If firebase init didn't place them in backend/functions, you might need to adjust. For this project, assume backend/functions is where the functions code resides.
4. Create a Service Account Key (for Local Testing with Emulators)
   • Go to your Firebase Console.
   • Navigate to Project settings ⚙️ > Service accounts.
   • Click "Generate new private key". This will download a JSON file (e.g., your-project-id-firebase-adminsdk-xxxxx-xxxxx.json).
   • Rename this file to serviceAccountKey.json and place it in your backend/functions directory. DO NOT commit this file to GitHub! Add serviceAccountKey.json to your .gitignore in the backend/functions folder.

Step 3: Configure Database & Security Rules (Firestore)

Your Firestore needs rules to allow your Cloud Functions to read/write, and your frontend (if directly accessing Firestore, which we're not for data fetching) would also need them.

1. Open backend/firestore.rules (or firestore.rules in your project root, depending on your firebase init setup).

2. Update your Firestore rules to allow authenticated users to manage their own speeches subcollection. Replace the contents with:

   Code snippet

   rules_version = '2';
   service cloud.firestore {
     match /databases/{database}/documents {
       // Allow read/write for user documents, if you had them
       // match /users/{userId} {
       //   allow read, write: if request.auth != null && request.auth.uid == userId;
       // }
   
       // Rules for speeches subcollection
       match /users/{userId}/speeches/{speechId} {
         allow read, write: if request.auth != null && request.auth.uid == userId;
       }
     }
   }
   

3. Deploy your Firestore rules:

   Bash

   firebase deploy --only firestore:rules
   

Step 4: Backend (Cloud Functions) Setup

Now, let's get your serverless backend ready.

1. Install Dependencies: Navigate into your backend/functions directory and install Node.js dependencies.
   Bash

   cd ~/Documents/fun/git_repos/Trippingly/backend/functions
   npm install
   

2. Deploy to Live: For your Cloud Functions to work live, you need to deploy them. This step is only needed if you want to test against live functions (and is often done once you're ready for production testing).
   Bash

   firebase deploy --only functions
   

   • Note down the base URL provided in the output for your api function (e.g., https://us-central1-your-project-id.cloudfunctions.net/api). You'll need this for your frontend if you test live.

Step 5: Frontend Setup

Next, configure your React app to talk to your backend.

1. Install Dependencies: Navigate into your frontend directory and install npm dependencies.

   Bash

   cd ~/Documents/fun/git_repos/Trippingly/frontend
   npm install
   

2. Create .env file: In your frontend directory, create a new file named .env. This file stores environment variables that Vite (your build tool) will expose to your React app.

   ~/Documents/fun/git_repos/Trippingly/frontend/.env

   Code snippet

   # Example for local Firebase Emulators:
   VITE_CLOUD_FUNCTION_URL="http://localhost:5001/YOUR_FIREBASE_PROJECT_ID/us-central1/api"
   
   # Example for deployed Cloud Functions (uncomment and use when deploying to production):
   # VITE_CLOUD_FUNCTION_URL="https://us-central1-YOUR_FIREBASE_PROJECT_ID.cloudfunctions.net/api"
   

   Replace YOUR_FIREBASE_PROJECT_ID with your actual Firebase project ID! (e.g., trippingly-dev). Keep the localhost URL uncommented for local development.

Step 6: Running Trippingly Locally!

You're almost there! It's time to fire up both your frontend and backend.

1. Start Firebase Emulators (Backend): Open a new terminal window. Navigate to your backend directory:
   Bash

   cd ~/Documents/fun/git_repos/Trippingly/backend
   firebase emulators:start
   

   Wait for "All emulators ready!"
2. Start Frontend Development Server: Open another new terminal window. Navigate to your frontend directory:
   Bash

   cd ~/Documents/fun/git_repos/Trippingly/frontend
   npm run dev
   

   This will give you a local URL (usually http://localhost:5173).

Now, open your browser and go to http://localhost:5173! You should see the Trippingly app. You can register, log in, upload speeches, see them in the list, and click on them to view full details!

A Peek Behind the Curtains (High-Level Architecture)

Here's how everything dances together:

• Your React Frontend serves the user interface.
• When you upload a speech or fetch your speech list, the frontend makes API calls (using fetch) to your Cloud Functions (the Express.js app).
• The Cloud Functions, after authenticating your request using your Firebase ID token, interact with Firestore to store or retrieve speech data.
• All user accounts are managed by Firebase Authentication.

What's Next for Trippingly?

Our journey is just beginning! Future features include:

• Unit & Integration Testing: Building a robust test suite to ensure everything stays bug-free. (You're looking into this next!)
• Speech Playback: Text-to-speech for practicing your delivery.
• Speech Analysis: Providing insights on pace, filler words, and more!
• Editing & Deleting Speeches: Managing your content.

Get Involved!

Feel free to explore the codebase, open issues, suggest new features, or even contribute. Trippingly is a passion project, and we're excited to see where it goes!

---

How does that look? It covers the main setup points in a step-by-step manner. Let me know if you'd like any additions or tweaks!

I kept going so here's a reminder for next time I've been away from the project for 2 years

🦄 Project Log: Upgrading My Unicorn Text Project (April 2025)

🚀 Overview

This project connects a Pimoroni Galactic Unicorn Pico W to a Google Cloud Platform (GCP) serverless API that controls the scrolling text remotely.

• Backend: Node.js, Express.js, Firestore (GCP)
• Frontend: Simple HTML/JS (eventually!)
• Deployment: Cloud Run with Cloud Build
• Security: Bearer Token Authorization + Secret Manager
• Storage: Firestore Database

---

🛠️ Main Changes and Improvements

1. Local Pico W Development Setup

• Installed mpremote for flashing and file management.
• Created a deploy.sh script to easily push code to the Pico.
• Setup .env secrets for WiFi credentials and server URLs.
• Used Micropython firmware.
• Created a pretty console output when deploying.
• MicroPython Docs

2. Backend (Cloud Run API) Improvements

• Split project into app.js (Express app) and server.js (listener).
• Why split app.js and server.js?
• Proper CORS setup to allow frontend to talk to backend.
• Centralized Firebase Admin SDK initialization (utils/firebase.js).

3. Firestore Data Improvements

• Structured Firestore documents to include:
  • text (display text)
  • updatedAt (server-side timestamp)
  • updatedBy (who set the text)
• Logged every update into a Firestore subcollection history.

4. Secrets Management (Security)

• Switched from environment variables to GCP Secret Manager.
• Fixed service account permissions for secrets access.
• GCP Secret Manager Docs

5. Frontend Changes (WIP)

• Created a basic frontend for text updates.
• Handled CORS properly.
• Added Bearer Token headers to secure API requests.

---

📋 Final Tech Stack Overview

• Hardware: Pico W (Galactic Unicorn)
• Firmware: MicroPython
• Local Dev Tools: mpremote, VS Code
• Backend: Node.js, Express, Firestore
• Authentication: Bearer Tokens
• Secrets: GCP Secret Manager
• Hosting: Cloud Run (serverless)
• Database: Firestore (NoSQL)
• Frontend: Basic HTML/JS

---

📚 Key Links for Future Reference

• Micropython Docs
• Express Middleware Basics
• Understanding CORS
• Google Cloud Run Docs
• Google Secret Manager Docs
• Firestore Subcollections Guide

---

🧠 Lessons Learned

• CORS must be handled before mounting routes.
• Always explicitly initialize Firebase Admin SDK.
• Structured Firestore data makes future features easier.
• Logging to console and audit trails are essential for debugging.

---

🚀 Future Ideas

• Add /history API endpoint to view full update logs.
• Prettify the frontend to show timestamps and usernames.
• Setup OAuth login instead of bearer token for future users.
• Deploy frontend separately (Netlify, Firebase Hosting).
• GitHub Actions for auto-deploy on commit.

---

🦄 Final Thoughts

This is no longer just a toy project — it's a scalable, secure, audit-logged cloud-connected Unicorn 🦄 system! With a real API, real secret management, history tracking, and easy extensibility — Ready for next steps whenever I pick it back up again!

Returning to the Unicorn

Building a Smooth Workflow for Raspberry Pi Pico W Projects with VS Code and mpremote

This morning I decided to tackle a nagging issue: my Raspberry Pi Pico W development workflow felt clunky. Uploading code manually, dealing with VS Code IntelliSense errors, and fiddling with board resets slowed me down.

I wanted a press one button, everything works experience.
Here’s exactly what I did to streamline my setup — and where I’m heading next.

And slowly we get worse...

So this timelog project started as a simple zsh script:

function timelog() {

if [ "$1" != "" ]

then

echo $(date +%H:%M) "$1" >> ~/timelogger/$(date +%Y-%m-%d).txt

fi

}

This created a new file if one didn't exist called <<date>>.txt (for example 2018-10-09.txt) that would then put whatever details were passed to it into it.

This had several advantages over what I've got to now, mostly it was nice and easy to edit.

With the changes I'm now making it does appear that I'm getting further away from where I was.

I've now got just about a graphql server running that just about works to retrieve whatever has been written, but I'm not yet using that to write to, soon, but not yet.

Adding more interesting and fun technology has been it's own reward, but it's not made what I'm working on much more useful (yet).

The git repos for the more confusing bits are here:

https://github.com/benjimouse/timelog

https://github.com/benjimouse/timelogutil

Adding a pile of issues...

This evening I added a pile of issues to GitHub, and in a shocking turn of events I've managed to fix one of them. By fix one of them I of course mean I found that things already worked that way.

I've also done some tidying up.

Next I want to start getting some unit tests in and then start some unit tests in a TDD style manner.

After that it's to the fun world of Graphql with go. I've found some fun filled exciting blogs about this.

I'm really quite enjoying go.

Keeping going with go

Well another evening of GO, which has been really quite good fun...

I've started moving some things about so that the code has separated a bit better. I had started with some testing, but that wasn't going so well, so that's a plan for next time!

Things that I've got going so far:

• Working and compiling!
• Reading config file
• Connecting to a remote mongo db
• Writing to a reading from mongo db
• Reading the passed in parameter

I've also got a whole lot of VS code plugins working.

Go seems to encourage multiple repo's which is a little odd, but I suppose it's nice for encouraging code reuse and other bits, sure I'll get used to it (or start with one and then slowly move things out).

Repo's

https://github.com/benjimouse/timelog

https://github.com/benjimouse/timelogutil

Trying out a new language.

So about a year ago, my then (and now no longer) boss handed me a book saying you might be interested in this.
That's sat on my desk unopened for almost a year.

The Go Programming Language I've still not opened the book, but I put together a small command line app that could be used to record what I'm doing, while I'm doing it. I'll keep playing I quite like it (so far). If you're interested the repo is here: https://github.com/benjimouse/timelog I'll update with more details later.

Tortoise cam has arrived!

In exciting news tortoise cam has arrived!
I've put it together and followed a pile of instructions using a raspberry pi I had sat round not doing very much and now we have the capability to live stream the tortoises!
The instructions I followed are here:
http://www.makeuseof.com/tag/live-stream-youtube-raspberry-pi/
And they were remarkably easy to follow.

Now without further ado you should be able to see tortoise cam, obviously this is running off of my home wifi, so it could well stop working at any point (and that's without interruptions from a 3 and 6 year old).
The live stream should be able to be found at:
https://www.youtube.com/c/BenBest/live

If you follow that link in the next few minutes you should see my wife and I attempting to put together a "tortoise table"!

Tortoise cam...

Tortoises!

So in a not very shocking piece of news I've taken a(nother) break from playing with the meteor project. There are a number of reasons for this including 2 children, busy job, life and mostly it stopping being as much fun.
However we now have baby tortoises!

So I'm planning on setting up a "tortoise cam"...
I've got a raspberry pi and I've ordered a pi-cam so the plan is to set something up to watch them. I've even got a friend who's set up one of these before so have some help when I get stuck...
I'll be posting technical updates here with details of how I'm doing it (and probably the odd cute baby tortoise pic).
---

The story so far:

We were given 2 very old tortoises (A'tuin and Molly) both over 100 years old, to our shock Molly laid 5 eggs not long after she moved in. This led to us buying an egg incubator at very short notice, reading the instructions meant we realised we needed a thermometer  as the incubator (linked above) had lots of warnings about how it wasn't great at keeping the temperature! We went for the bluetooth thermometer so we wouldn't have to keep opening the incubator door to check in on the temperature.
For those of you not following the links so far we've spent about £100.
Towards the end of August disaster struck! The incubator was knocked over, we lost one of the eggs and we were very worried about the others.
Then on September 3rd there was great excitement when 2 of the eggs started to hatch!

This of course meant more things! A tortoise table, a heat lamp, a heat mat and a thermostat. Fortunately we had had the vet on the hill round to film the tortoises and he had been kind enough to offer to source some of these things for us, they are going to turn up this week.
We now have the tortoises in their temporary home (an old draw), they are starting to eat and everyone is really excited about it.
More details to follow!

Left the previous domain...

Well I couldn't justify owning the ben.best domain, it was £70 a year that I could spend on other things. Especially as I own benbat.com. So welcome to the new domain.

I've also got as far as I'm going to with the Lunch project. I learnt some bits and it stopped being quite as much fun. I may well return to it in the future, but for now I'm moving onto new and exciting other projects...

Tonight my bit of work was to move the blog, as we've seen previously that can be a lot of hassle, however this time things appear to have "just worked".

The near future I've got some plans to play with "groovy" and docker, but mostly the idea is to write up fun techy things that I'm doing.

Picking things up (again)

In exciting news I've got some incentive to start playing with Meteor again.
What this means:
I've got "lunch" working in so far as it functionally works. It looks like a developer designed it, but it will help you make a (or several) meals!
It's no longer hosted at lunch.ben.best (though should be again "soon"), the free hosting tools that meteor.com used to supply stopped and they have started paid for hosting. This means that for now, you can get to the tool at lunch.meteorapp.com if it looks like it's going to cost me money I'll probably stop it being there, but we'll see how it goes.
Meteor has changed a fair amount since I started looking at it and a fair amount of what has changed means I'm going to re-write the app, which I'm sort of looking forward to.
I'll probably be giving up on the domain ben.best, it's a lot of money for something that's a bit of fun, but not really something I can justify. This makes me a little sad, but I'll keep going with lunch (and probably the blog) but I'll be moving it to one of the cheaper domains that I own.

did I say I was finished?

So this evening has been fun working on the app (lunch.ben.best)

I've got some things working, I've also decided the way I need to move forward so:
New features:
You can now by clicking on it modify the serving date / time of the meal.
I've started on, though it's not entirely there the work to add a new meal, there's lots more to be added there, but I have a plan.

It's still really interesting to return to things that I worked with a long time ago and some of the bits are really clever, getting the checking working so that it validates dates, some of the other bits that "just work". However I think I'm going to have to split out a lot of the Meteor functions so that they are separate to some of the helper methods for the steps or meals functionality. Returning to the "time" object that I'd worked on was a nice feeling of finding something I'd done nicely in the past.

I think when I next get some time it will be time to add to the wireframes.

I'm currently waiting at the hospital for a scan (nothing serious), and it's the run in to Christmas, so I'm guessing updates will be quite sporadic.

fixed it again (again)

So I've spent a couple of evenings and I've again got my little app working locally it has been interesting re-visiting things and as ever getting code working I worked on a year or so ago.

lunch.ben.best is now running the latest version of the code (and I've checked everything into github). I'm at the point where in theory it would be possible to use the app to cook a lunch, though it wouldn't be a lot of fun. So now is the time for improving the app to make it really usable.
Then get it so that others can use it.

When I left this I had started playing computer games again, last night I decided to leave the conquering of Europe do some coding while the kids were asleep, I'm not sure if this is a good or bad thing, but while it's interesting I'll keep going. You never know I might end up with something interesting at the end.

I'm currently working on being able to change the time to serve the meal, this led me into the interesting place that is the input type datetime-local. It still surprises me how incomplete the specification and support for the HTML5 input types are. On mobile devices this box is lovely, however it's not supported on IE at all and the chrome support isn't exactly thrilling. I'll probably look at some plugins to see if I can't figure out a better solution, but I'm going to be continuing with the "get it working, then get it pretty" maxim.
I think the next steps are:
Allow date/time change working
Allow multiple meals
Allow multiple users to have meals
Sort out adding / editing steps so it's "nicer"
Pretty up everything (including making it "reactive")

I'm sure I'll find more steps and do some out of order, but it's nice to have a line in the sand, even if it then gets rubbed away.

back again (again)

Well I'm back again, the little app I was working on had stopped being fun and as I was doing it in my spare time I decided to stop...

However I recently had to choose if I was going to renew this domain and I was doing a couple more fun techy things so I thought I'd re-start the blog and use the impetus of having shelled out for a .best domain for another year as a way to return me to the blog and to doing tech stuff in my spare time.

Not entirely sure exactly where I'm going to go with this. I will probably try and get the app up and working again, although it is successfully (ish) running in its hosted environment (lunch.ben.best) the version locally isn't working and upgrading my ageing mac appears to have killed off Git. So my plan for this evening is to get things up and running again. I've got an idea for a different app and I want to have a play with some other languages (I've been meaning to look at clojure and scala serverside and coffeescript for ages).

So I'm going to spend this evening getting things up and running again, I've just installed a new ssd into my ageing laptop and that is feeling a bit like a new machine. I'll let you know how it goes and if what I decide to do.

In the meantime here's a short, silent video of me replacing the hard drive:

broke it again...

Continuing with the let's see how bad I can mess it up plan that I've been working with so far, this evening I've fixed one thing and really broken lots of others.


I now have an app that although it correctly describes things so has got rid of the depends on rubbish and replaced it with done before which is what I needed it to be. Unfortunately it won't now let you save a new step (and I don't like that description either).

In positive news I can continue playing tomorrow so I'll hopefully at least get something saving.

I did this evening manage to get some things right. I  managed to get rid of a load of the errors that I was having to ignore in the code.  These weren't actual errors, they were jslint (a tool for telling you where you've written your code badly) not being told to correctly ignore some errors.  I'd previously tried to fix this and failed, actually getting this fixed meant I could see the proverbial wood for the trees and pointed out some actual problems that I'd been missing because I'd ignored all the errors.

The other thing that this has pointed out is that I really (really really) need to add in some unit testing.  This is starting to get embarrassing, I don't actually know exactly when I broke saving things, I think it was this evening, I can role back code changes and find out but that's a faff. Proper unit tests would have highlighted this to me as soon as I broke it.  Fortunately I pointed this out about 3 months ago, less fortunately I paid no attention.

As a sort of PS you might have noticed that I turned ads off.  The reason for this was that I no longer needed them. I'd played with them, figured out how to get them working and better than that realised how to set them up and how to turn them off.

I've checked in the current (broken code base) here:
https://github.com/benjimouse/lunch

ahhh... not as "there" as I thought it was

So following my proud post declaring I was sort of there, I pointed out what I'd done to a "friend". He pointed out a small flaw in my logic and that the tool was completely unusable...

It's clear now that instead of having a "depends on" (which really means nothing) I need two boxes: - "Needs to be done before" and "Needs to be done after".  Ah well it'll give me a better idea of what I'm doing and no doubt cause some fun with the idea of circular dependencies...

Oh well gives me something to do tonight!

and I'm there!

Well I'm not really there, I'm actually a very long way away, but...

I have now something that's just about useable, it doesn't all work exactly as it should, it looks bloody ugly in places especially the edit and add forms.

However I am now in a place where I can start writing some front end tests. I'm expecting a large proportion of them to fail, I know the start cooking at the top is broken.  I know edit doesn't work.  I do however have enough of a framework that all the right fields are there and they all do something.

I'm pleased with where I've got to, however I'm aware that there is a lot more work to do...

Now the real fun begins...

This is where I've got to so far:
lunch.ben.best

it's been a while...

I've been busy with some good and a lot of rubbish things, but I think I blogged myself out...

I've not been doing nothing though, this evening I've run some updates and continued with the lunch.ben.best app, however the version at that url isn't great (is a bit rubbish) at the moment.

I'm having some issues with this due to the nature of using mongo in the back end, I was starting to write up the issue but fortunately (for you lot more than me) Sarah Mei has done so a lot more eloquently that I would have here:
http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ 

If you don't want to read all of that (you really should though) the basic gist is that you'd going to end up wanting to do something relational. You then have 2 choices - 1 include other object(s) as part of the mongo document and cope with the update that means, or store the id and then write your own relationship management.  The tutorials I've been looking at for Meteor seem to go with option b and as mongo db version 3 is about to land it's possible that this will be something that will start to become at least easier...  No one I've been listening to / reading has suggested that might be happening though.

Anyway I'll try and keep going with this, thanks for sticking with it...

a proper restart and some resolutions

I've been lax due to mostly a death in the family and the recovery from Christmas but finding a rogue like game on the pebble didn't help.  I've also started this post a few times and then been interrupted or it's been pointed out that I need to assist in the taking down of decorations.
Excuses aside here's some plans for what I'm going to do in the next year:

Get the lunch.ben.best app running*

I was really quite disappointed that I didn't manage to build this in time for Christmas.  However I managed Christmas lunch more than successfully without it.  That shouldn't be an excuse not to get it finished.

Have a pull request accepted into an open source project

This is just something I've been wanting to do for a while I've got loads from using open source software and it would be nice to give something back.

Play with pebble.js

Although the majority of pebble apps are written in C and I could go back an re-learn that it's not something that inspires me.  However playing with javascript has been really interesting these last few months so that's probably where I'm going to go with this.

Finally something interesting - plague

I've been playing with plague on the phone, it's horribly addictive and I'm finding it an interesting guilt free social network.  The concept is quite simple, you swipe up to send an article (which can be text, an image a link etc.) to the people near you or down to not send it on.  I've found some interesting bits. My largest concern with it is if it does gain in popularity then it'll be filled with less savoury images and links, that have thankfully so far been missing.

*By running I mean in a state that I can use it for cooking a meal, once that's done I'll look at additions and shine.

so that was Christmas...

Well it was fun, with lots of food, presents and excitement.

Perhaps unsurprisingly I didn't get the app that I was building to sort out the cooking the Christmas lunch finished.  I'll continue working on this, but with the urgency now removed I've decided to take a break.  After all this is supposed to be fun and it's something I'm doing in my spare time so taking a bit of a pause should be fun.  On that note I managed to not touch a laptop for over a week over Christmas which was a nice break.

As a surprise Christmas present I was given a pebble for Christmas, it's been lots of fun playing with it. I've also had a few frustrations, I think this deserves it's own post so I'll write one up and put it in after I've finished this.

I'll also try and sort out an interesting things post later today.

Over all I've had a fab Christmas and today is back to work, let's see how that goes...