Last year I’d created an app in Nativescript. Worked well, both Android and iOS versions. Even managed to get it into the Apple iTunes store (no mean feat in itself!).
So, this month it is time to update and change some things in the app. Small stuff but I took the occasion to update the various plugins and libraries at the same time. The old version was created with Nativescript 2.5, now Nativescript had moved on to V3.1.1. Some nice changes on the way, so worth the update.
There are a few breaking changes (helpfully listed here) but on the whole not too painful at all. Except, after getting it all working I noticed that the app was no longer refreshing when files were changed (this is while developing). According to the console, modified files were being pushed up successfully but nothing was changing on the app. I spent literally a whole day trying to work this out and here is the solution. I hope it helps someone else.
In the package.json file, there is a line:
This id now needs to appear in the app/App_Resources/Android/app.gradle build file like so:
My landlord usually sends us the tenancy agreement to sign using a service called Docusign. Docusign allows people to provide a legal signature for a document via an online website.
Within an hour of receiving the email with the link to sign the document at Docusign, I received three more emails, looking very like the first one, complete with Security Key. My partner also received these emails. Each batch of emails seemed to relate to the same (fake) name (Cameron Smith, Matthew Moore, William Collins, Kevin Moore) and the subject on all them was “Wire Transfer Ready for Signature”.
Last week a new file appeared on one of my servers. It was in an upload folder and was called indoxploi.php. I decided to play around with it and see what it does. It’s quite a thorough set of website exploits, specializing in defacing WordPress websites, but with capabilities of doing a lot more. If you find this file, delete it!
I’ve recently been trying to install OpenVZ on an Amazon EC2 instance. It’s a process fraught with peril and I’ve locked myself out of the server more than once. Here are the steps to recover control:
Find the instance X1 that is not responding, make sure it is stopped. Note which volume is attached to the instance (look in the lower section of the page, click on the ‘Root Vol’ device and note the number).
Go to the Volumes section, find the volume V1 that is attached to that instance and detach it from the instance.
If you don’t have a spare instance to spin up, then go to the AMI section and spin up a small instance of whatever-you-fancy. It’s only temporary for fixing the disk.
Stop this instance, go to the Volumes section, select the volume to fix V1 and attach it to the spare machine, usually on /dev/sdf but this may vary.
Now back to the Instances section, spin up our spare temporary instance and, when running, login through SSH
Now we have the troublesome volume, V1, attached to /dev/sdf (or /dev/xsdf more likely) and we can mount that on /mnt/ (sudo mount /dev/xsdf /mnt) and make whatever changes we need to make.
Now we unmount it (sudo umount /mnt) and back in the Amazon control panel, go to the Volumes section and detach the volume from the instance.
Next reattach it to the original instance X1 and spin that up.
Pop the champers!
You can of course avoid all this if you take a snapshot before making potentially destructive changes to the system!
Last week saw the start of the Public Beta period for Let’s Encrypt and the start of a more secure internet for all. For free. The project has been in development for at least a year, was due in the summer and has just now finally been cleared for public usage. This is something of a game changing moment but not something the public is aware of. It means that any site that wants to have that little green padlock up in the location bar can now easily install one. And given that Google (and presumably other search engines) are starting to penalise sites that are not running over HTTPS, this will become a greater issue over time. I decided to try it out on a few domains… Continue reading Let’s Encrypt and let’s go→
Once you’ve worked through a few Meteor tutorials and simple apps, there comes the time to create your very own killer app!
But where to start? There is a lot to be said for creating the app from scratch and that is definitely a valid starting point. There is still the question as to what is the best practise for file and folder layout and where to put what. I did a bit of surfing and here are some notes on what I found. [Updated 16/06/15 to include Iron Meteor]
These are some notes I’ve made while following through the Meteor tutorial (which is the simple to do list). This is more so that I can remember the overview of the basic process rather than a general set of instructions. If you want to learn Meteor, then this tutorial is an excellent, 1 hour overview of how simple it can be. Including deploying it to the cloud! Continue reading Getting started with Meteor→
I was contacted by a client last night, very concerned because, when you enter his site into Google, it comes back with a warning that ‘This site has been hacked’. And yet, when the site is viewed in the browser, there is no sign of any bad links or anything. What can be happening? Why does Google think the site is hacked?
I took a look at the site and he was correct, there was no sign of any bad links, and yet in Google there was a couple of pages of links to various pharmacy products. Which when clicked on led to a 404 page not found error. But when I asked Google for the cached version, there the links were, proudly displayed at the top of the page, bold as can be.