image of cheesy meatballs

Cheesy Meatballs

These cheesy meatballs were an absolute hit. Not only do they get the taste buds going, they also smell amazing whilst they cook.
For those of you doing keto, there is less than 1g of carbohydrate in this motherload, so you can snaffle till the cows come home.

For other diets, replace the mince with lower fat content and possibly consider replacing the cheese unless you are using it as some sort of healthy addition. You know your own diet regime so far be it for me to lecture you.

This recipe will make 22 meatballs in total if you make them like I did. enough to feed the family.

To make these cheesy meatballs you will need:

  • 500g lean beef mince (I used 20% fat mince)
  • 1/2 block vintage cheddar (to your own taste)
  • 1 yellow onion
  • 2tbsp garlic granules
  • 1 knorr rich beef stock pot
  • 2 eggs
  • 2tbsp mixed herbs
  • 2tbsp butter
  • salt to taste

Step 1:

You will need to deal with this huge chunk of mince. take its meat-nappy off and split it into two 250g chunks. You will be getting your hands muchos sticky in this recipe so take off any rings or loose nail varnish before you begin.

Step 2:

place one of the chunks of mince into a food processor. crack in one egg, 1tbsp of garlic granules, 1 tbsp of mixed herbs, and half a stock pot then blend it together until it’s all a similar consistency.
The aim here is to make the mince smooth as the air pockets are what cause them to fall apart in the frying pan.
When done, return it to a large mixing bowl.

Step 3:

Repeat step 2 with the other half of the mince, the other egg, the remaining garlic and mixed herbs and stock pot.
Place this second mixture in the same bowl as the first. We’re going to mix them together soon.

Step 4:

halve and peel the onion. If you have a grater attachment on your food processor then this is a brilliant time to use it. If not, a regular grater will do the trick.
Remember to take regular breaks if the dreaded onion tears start flowing. Fresh air helps, as does sniffing some tea (apparently?).
You may also grate some cheese into this if you wish. I took a 1cm strip of the end of my block of cheese and grated that in. This is personal preference more than anything.

Step 5:

Chop 22x 1cm cubes of cheese. These will go into the centre of the meatballs. Pop them to one side until step 7.

Step 6:

Take all of the lovely grated cheese and onion-ness (or just onion-ness if you forewent the cheesy goodness) and pop it into the bowl with your mince.
Now is where we get really messy. You can use a wooden spoon but it is much better just to get your hands in and mix together everything by hand. Spend a good few minutes working in the onion and cheese, making sure it is thoroughly distributed.
Doing it by hand allows you to feel where the cheese and onion have got to and notice any bland bits of mixture that has none in.

Step 7:

Now, have a plate or two (dependent upon plate size) handy because here is where we make our final product, ready to cook.
Take yourself a scoop of mixture and mould it into the palm of your hand. it should be only as big as your palm, no bigger, and about 1/2cm thick. Right now it could make a very nice beefburger!
Next, take cube of cheese and press it dead centre into your palm. Fold the corners of your patty in around and over to cover the cheese.

Then, you need to roll this into a ball between both palms. Make sure that any spaces or gaps are filled in by using the tip of your index finger to smooth over the mixture. It should be moist (I’m sorry, i know some people hate that word but it does apply here) enough to smooth over with ease.

Once you are happy with the size, shape and composition of your balls (ooer missus!) then place it on a plate and move onto the next one until there’s no more mixture left.

Step 8:

Melt 2 tablespoons of butter in a frying pan (other fats or fat replacements will do but butter is the best for searing) on high heat.
Place as many meatballs into the frying pan as you can and turn the heat down to medium.
The fat from the meat should add to the butter in the pan and create a lovely shallow-fry. Add some salt if you wish, but bear in mind that the stock pot we put in adds quite a bit of flavour. Don’t make them too salty.

Turn them regularly so that they don’t burn on one side. If you’ve made them lovely and spherical, they should just sit at whatever angle you turn them to.

Repeat this until done, then repeat the whole of this step with as many as you have left over uncooked.

At this point, you could freeze the uncooked ones and save them for another day, But beware, defrosting them adds more water to the mixture and you won’t get such a nice outcome after you defrost them.

Step 9:

When they have all done cooking, you can start to dig in. Be it with pasta, quinoa, Cauli Rice, passata, whatever you want.


I hope that you have enjoyed this recipe. If you do happen to share it, I would love some credit for it.
And remember, hot things burn you. Sharp things cut you. always be careful in the kitchen.

Thanks peeps!

Laravel End to End – Part 1: Tools and Environments

Good morning, good afternoon, good evening and goodnight to you. Thank you for joining me for the second part of this blog series, in which I am going to be talking mostly about tools and environments.

For me, there are several key bits of kit you need as a developer. These tools, I have found, can either help or hinder your work – But if you find the right ones and get into a groove with them, you are generally onto a more productive day.
The tools I would usually list are below:

  • A Laptop
  • An IDE
  • A Version Control System
  • An API Tool
  • A Local Development Environment
  • A Testing Environment
  • A Live Environment
  • A JSON Interpreter
  • Lots and Lots of Coffee!

Let’s start from the top and work our way down the list. I will give you my opinion and way of working, but in all seriousness you are welcome to choose and adapt these methods and tools all you want. We are, after all, each uniquely individual and there is not right set of tools as far as I am aware.


Yep, a laptop. Be that a Windows based machine, a linux box or a Mac. Laptops are more portable than desktops, obviously, and therefore when you’re being stressed out in one room by an irritating noise or incessant chat you can slink off to a dark corner and lock yourself away like a hermit. (Or maybe that’s just me?).

Laptops also help you to work in places where your creativity is at its peak. So, on a train journey is my peak creativity point.


This is a tricky one and depends a lot on what you want to spend for a license. If you’re getting paid for your design work, then I would suggest going in for a more premium IDE. They tend to have more support, more features, more plugins and generally better code completion (although some freebies have excellent plugins – Here’s looking at you VS Code).

The IDE I choose to use is PHPStorm because it is just so damn versatile. It is £7.99 per month, which doesn’t erode my profits too much – plus, because it’s a personal license I can use it across several machines if I want to, for any project I choose.
PHPStorm offers a really intuitive interface, giving you keyboard commands for most anything you will ever need to do. It is also based solely around PHP and therefore builds in a lot of the core standards for PHP out of the box (PSR1/2 Compliance is just a tickbox away).

There are, however, more choices than just PHPStorm for code editing. You may choose from anything from NetBeans, Aptana, Eclipse, ZendStudio, and even Microsoft Visual Studio Code. This is your personal choice, but I would highky recommend PHPStorm for its sheer amount of built-in features.

A Version Control System

So, for me working as part of a team, it has been a stark contrast to the version control I was used to as a singleton developer. Previously, I had one master branch and one develop branch. I would make my changes to the develop branch and then merge into the master branch for deployment.
This has changed somewhat in that now the develop is the main branch we pull from as a team as it incorporates all of the latest changes, but we create task-related branches. So if I wanted to create a customer search piece of functionality, I would branch from Develop and call it ‘feature/customer_search’. This means that it is a new feature.

Every company does version control differently, but as a general rule of thumb I use Github and Atlassian Bitbucket. These two use the popular Git functionality and therefore comes very easily to the experienced developer.

In terms of tools, I would suggest getting something called Sourcetree for Windows, which will connect you to your Atlassian Bitbucket repositories. With regard the github repos, I generally download github for Desktop, which allows me to directly manipulate the repository from a GUI.

An API Tool

This is what we will need to use to start probing APIs for their responses. These tools are infinitely valuable and can mean the difference between three hours bug hunting and a five minute fix.

Personally, I use Postman. This can be use to define requests and read responses directly. The benefit of this is that you can see immediately what is being returned by each endpoint for the given request body.



This, again, is a wide open topic. I know a lot of developers who use Docker and swear by it for virtualising containers without the overhead of the entire virtualised OS.

Personally, I like to replicate exactly the environment that my code will be working on in a live environment, so that I can see any discrepancies whilst I am developing.

On my local environment I virtualise the Homestead environment, which is the Laravel default requirements bundled up in one package as a single machine specification.

I run Vagrant to manage my images and distros, and I use Virtualbox to virtualise the environment I am going to be developing in.

I usually run a local environment on my machine using vagrant/virtualbox, and a dev/test server on an actual Ubuntu machine. This means that I can see the performance and the look and feel of the website much better than on a virtualised environment.

Finally, I run a live server. Until recently, this used to be always with 1&1, but since they were taken over by Ionos their service and support appears to have gone down the drain and so I have gone DevOps on it and begun a server infrastructure on AWS. This can be tricky to set up at first but the benefits of a speedy server far outweigh the effort needed to set it up.

A JSON Interpreter

This can be a lifesaver in terms of reviewing output in debug and log files. You will often find that the output from each request comes in the form of a JSON Response – This tool helps to make that JSON Response human-readable.

For this task I use a small application called JSON Lint. The small package comes as an extension to Google Chrome and gives you the ability to parse JSON code and really see what is going on.

JSON Lint Interpreter

Lots of Coffee

I would suggest that you get yourself a coffee machine because once you’re in the flow of things you’ll barely want to look away from your screen.

Coffee truly is the elixir of life for coders, but if you really can’t stand coffee then you may like Jasmine Green Tea instead. The choice is yours.


So now that you have your setup ready and you have had a chance to play around with your new found tools, we can start to really dig into the core of Laravel 5.7

I hope you’ve enjoyed this read. If so, then please continue to look out for the rest of my series and join me as I go through Laravel – End to End.

Ciao for now!

Laravel – End to End

Well hello there, Friend. Thanks for dropping by and looking at my blog.

My name is Kayleigh, and I am a web developer! I have been in my current job as a Full-Stack PHP Developer for a popular Boiler Company in the UK for almost a year using Laravel full time. Before that, I have used other MVCs and technologies such as CakePHP, CodeIgniter 2, Concrete5 and even straight PHP to create my own websites and web apps.

This is the first in a series of posts I am producing called Laravel End to End. The purpose of these posts is threefold :-

  • Firstly, I need somewhere to gather my thoughts as I consolidate my understanding and knowledge from the first year of Laravel. This helps me to deeply embed the learning I have done over the past 12 months.
  • Secondly, It will help me to uncover gaps in my knowledge and pose questions about better ways of doing things – A self-critical analysis of my own work if you will.
  • Thirdly, I hope that this will be a resource that others will be able to come to when they are in a similar position to me, still feeling slightly like an imposter in the sheep pen, and needing some reassurance that they’re on the right track.

I will be following the Laravel Certification Exam Preparation Curriculum in my posts, and I expect that as I go along I will find things that I either do not grasp or haven’t even used yet.

A snippet of the Laravel Certification Curriculum

I’m going to be brave and turn on moderated comments on these posts too so that I can have your feedback and hopefully get some of your marvelous experience woven into my own understanding.

I will assume a basic knowledge of HTML, CSS, Javascript, PHP, Linux/Windows Shell Commands and other tools. If you’re not comfortable with these then there are a lot of resources out there for you to look at – This just isn’t a good one to start off with.

So, without further ado, let’s cut the waffle and dive straight in. My next post will be around tools and environments.

Bye for now!