It's true. We're finally on to BT's Superfast package! Finally our internet connection at home is fast enough to download a server backup each day without sacrificing the whole connection.
After doing a speed test this morning I have noticed that we've had a huge increase in speed. From 12Mbps all the way up to as high as 48Mbps, we're getting a much better all-round experience.
Upload isn't bad either - we're getting 8Mbps which is 16 times faster than the 0.5Mbps upload we got yesterday!
In the last few months I've not been able to put as much time into Dash as I'd hoped. However, fear not! I've recently updated Dash with some snazzy new things and some minor improvements.
First of all Dash now includes BalfPick, my own dropdown/select box - a vast improvement on those pesky ones built in to the browser. If you've not seen how BalfPick works, take a look at it on my website or take a look at my sample blog.
Secondly I've fixed the issue with the invisible scrollbar in Firefox. You see the sidebar is meant to be scrollable, but it's meant to hide the scrollbar. This caused issues on Firefox but it's now been sorted.
On top of this, I've made some general improvements to the UI - the login screen now supports the glossy/glass look that I've been testing out across Dash using the backdrop blur effect.
Finally, small performance improvements have been made since the last update so it's worth trying out this version just for that.
For a long time it's been something I've needed to implement - a new version of my select element on my website.
Some of you may already know that styling select elements isn't easy and is incredibly restrictive in all of the main browsers. I'm sick of this attitude from the developers of these browsers and I really couldn't be bothered wasting my time trying to pull off some hack that fixes that so instead I followed my technique I used to create the radio buttons and checkboxes on this website - hide the actual form component and wrap it in a label. I call this BalfPick.
BalfPick is nearly finished and it's already across my website. I've had a few issues with Windows tablets but overall it's working on Android, iOS, Mac OS X Firefox, Chrome and Safari and the Windows equivelants with click and Edge on Windows. Surprisingly, each browser acts very differently and each operating system works differently too. As well as that, click and touch events must be registered differently (I developed a rather crude but very clever method for stopping click and touch events being registered at the same time in BalfBar back in 2014 and I'm using a slightly better version of that in BalfPick now too).
BalfPick is also available as a jQuery plugin as with the rest of my Web Independently Styled Project. What makes BalfPick different is it's unique support for both a really attractive desktop dropdown and it's ability to support the native dropdown on touch devices.
I'm also planning on bringing BalfPick to Dash in the next few days because some of the dropdowns could do with this.
Take a look at an example of this on my site here https://www.jamiebalfour.scot/about/interests/gaming/warcraft3/spellcraft/.
I thought I'd share some Linux wisdom with you all. Today I'm talking about symbolic links.
Until recently I have been making my live site a direct duplicate of all content of the development site. This meant that I needed to have two copies of all static files. Uh oh. For instance, my photo gallery on my website is about 400MB in size, so that's 800MB used for the photo gallery between the development site and the live site.
Overall, the method described is expensive and isn't necessary. I have been for quite a while considering symblinking the two to avoid static content being duplicated. Alas, it has been done. I now have a new section on the web server called user_content - a place where all user content that is identical between the live and development websites will go. This not only simplifies the copying of content by no longer needing a manual copy between the development and live sites, but it also reduces the storage space that was wasted with the old design.
For example:
ln -s /www/user_content/jamiebalfour.scot/files/gallery /www/sites/jamiebalfour.scot/public/live/gallery/content
simplifies the whole process of the gallery updates on both the development and live sites.
Overall, using symbolic links has made huge differences to my web server.
In the last few hours I have brought a ton of new features to the BalfGallery project - features that make this gallery miles better than what I had with my previous gallery.
In essence, BalfGallery is formed of two of my components - a PHP scripts aptly named BalfGallery and a jQuery plugin called BalfPopup. The popup is used in multiple places on my website and replaced MagnificPopup earlier this year on my website. This was a big change and required a lot of my time to make BalfPopup actually useful. In comparison to the previous gallery, BalfGallery is lightweight, fast and it takes advantage of features of my own BalfPopup which make it really powerful.
On top of this, it integrates better into my own website by flowing with the design concepts of it. Although currently available as a jQuery plugin, it is actually written differently to the other plugins I provide and the jQuery plugin is nothing more than a wrapper.
New features to BalfPopup now include left and right arrows for images - it cleverly finds the next images using the PHP script thus saving JavaScript resources.
ZPE 1.6 will be out by the end of March and it will include a big update.
The biggest change or addition rather is that of the new FX look and feel for the GUI. Currently, in alpha stages, I am currently looking to bring a better built-in editor that will use the JavaFX package. ZPE has been neglected for some time, and I aim to stop neglecting it over the next few months.
Version 1.6 will also bring some performance improvements and bug fixes.
You'll be able to get it soon, and now that ZPE has been downloaded over 5,000 times I am happy to continue developing it.
Today I attended the Amazon AWSome conference and today I decided in the next few weeks I will move over to use AWS in more and more of my projects.
The conference was very useful because it gave me an insight into how I would use AWS but it also covered the basics of getting started and how I can migrate to the Amazon cloud service. I found the talk interesting and I found that the presenters were well informed on what they were speaking about and within the first part of the day I decided it's time to move to using it.
So what did I learn? Well, perhaps most crucially, I learned that it's not as daunting as I first imagined and that they have most of the features I currently have available from day one. I also learned that it's not going to be overly expensive to make the shift - perhaps cheaper in the long run too.
Java Applets were once cool and they still kind of are, but they're just no longer relevant in today's world of fantastic web applications.
JavaScript has much replaced these old NPAPI based plugins and it's time that ZPE did the same.
So, as of ZPE version 1.6.0, the Java applet will no longer be included at all. This reduces the file size a tiny bit and it's not about that. It's about making the ZPE package much more modern.
You may know that back before the release of the iPhone and the real mobile web, websites could be as large as 20MB in size. When the iPhone was released, it came with a web browser that could view the full web - not restricted to some WAP-based website. This was a problem for web developers at the time (I for one was not one of these until 2 years later) as it meant that users using their data allowances to view their websites would ultimately pay the price of running out of data in their given packages very quickly and would suffer slow download speeds (remember, the original iPhone didn't even have 3G, shockingly).
40% of users will leave a website if it has not loaded within three seconds which means that even though my website downloads in less than one second here in the UK, 40% of users not using 3G will leave the website. The iPhone shook it up. The main outcome of it was that websites were redeveloped with Flash removed, image files compressed, CSS and JavaScript files reduced as much as possible, the HTML content split into different files and the server-side processing sped up as much as possible. It was as though things had to go back the way to before broadband became a thing, but in reality, it was just making websites more efficient with what they had.
Pingdom's Year in Review
The main subject of this blog post is to discuss Pingdom's Year in Review for 2017. This article shows some slightly worrying statistics about how the web is becoming, again.
Perhaps the most worrying statistic is exactly what was described above being reversed - websites are becoming bigger again. See this graph from the report:
While it is true that mobile devices have faster connections thanks to 4G LTE and we now have faster broadband connections, it is still worrying. I say this because there are still many people who don't have faster than a 1Mbps download speed.
At the start of this year when I relaunched my website my main focus was on client-side performance, both in terms of JavaScript and in terms of download time. I managed to get my Pingdom result from 1.5 seconds to around 400ms making it faster than 98% of websites that Pingdom tests.
My concern was more about the data usage that it costs however for a user on a smartphone. My previous phone contract limited me to 1GB of data, and I would often get through that in a few days. My current phone contract does give me 20GB of data, but I can often see me going through about 5GB of that in a month.
As well as the amount of data being downloaded, the number of HTTP requests has gone through the roof. The graph before shows both the size of a website (yellow) and the number of requests (black) made by the website. 110 requests?! That's a lot of HTTP requests. I do get that my website is a personal website, but I do believe that the most important improvement to making a website fast and efficient is reducing the number of requests. Older browsers can only send up to 70 odd requests at once, and yes, older browsers like IE8 still have some market share and we do need to try and cater for them too.
Further down the article, and it's clear that the amount of content being downloaded into a website is increasingly getting bigger too. Particularly images and JavaScript. Now, too much of those results in a lot to download but more crucially, it means more processing, particularly in relation to JavaScript. JavaScript needs to be processed immediately when it is received and as a result, puts more strain on the computer. These days this is much less of a problem with things like the incredible V8 Engine in Google Chrome and Safari's Nitro Engine. But all that processing needs to be done anyway.
The result of all of this labour on the CPU is that we have slower websites but also we drain the battery of mobile devices much faster. Perhaps this is the main reason why websites should consider what they are doing because the batteries in our smartphones aren't all that good after all (https://9to5mac.com/2017/09/25/ios-11-battery-life-problems/).
Conclusion
My concluding remarks on this are we are not going the right way about this. Building a website should not be about making it as functional as possible whilst sacrificing speed. There has to be the balance and it appears we are not doing that at the moment.
You can read more about this in the review at https://www.pingdom.com/2017.
A2 Hosting are an amazing bunch of people. I wouldn't have learned half of what I know about setting up a server if it had not been for them so I'm very thankful to them. They offered a very good service at a very good price but they also had their problems.
When I first set up my VPS early last year I got a lot of help with setting up DNS records and so on (something I can do myself nowadays) but what I didn't get I got from a website I came across a few years ago called DigitalOcean.
I cannot tell you how many times I've googled something and found an article on DigitalOcean that explains a perfect solution to my problem. More and more I started to think it would be good to host with DigitalOcean but I stuck with A2 until about November.
In November I got hosting credit for DigitalOcean so I thought I'd give it a try and see what DigitalOcean was like, especially now since I am more competent with setting up my own server. I wrote the server_setup script that I use to configure a server, created my first Droplet and transferred a recent site backup to DigitalOcean. Boom! It worked.
Performance wise, on the front end DigitalOcean was a bit faster than A2, which to me seemed unbelievable since A2 was blazingly fast as it was.
But I mentioned A2 had problems. There weren't many of those and I think A2 are fantastic but they did have one thing lacking that something that is more tailored to system admins/developers should have and that is snapshots. When I first moved to A2 I asked if they offer snapshots but unfortunately not. DigitalOcean provides snapshots! Snapshots allow me to make backups from time to time, for instance before a big update or whatever. It also means I have a secondary, weekly backup of my server.
So all in all, I'm sad to be leaving A2 but happy to be moving to my fourth host for my fourth iteration of my website. Hello DigitalOcean!
