Uh Oh! It appears you're not connected to the internet!
Sorry! We currently have more users than we can cope with. You can either wait until a space becomes available or come back later. We will be upgrading our servers to cope with this soon!
You got the boot! Click to connect back up...
Please contact an administrator, You are not authorised to login via this IP address
Already have an account?
Click here to login
Don't have an account?
Click here to sign up
Go check your email!
Oops! We don't know your email address, We can't send you a new password! Contact an Admin
Set Profile Picture
Select An Image
Confirm End Of Friendship
Chat To Us
Prefer to chat anonymously?
Read all about it, See what the good people at Project Peach have to say
Wouldn't it be great if you knew that your client's webapp was alive, well and kicking 24/7?
A Healthy Webapp
A Healthy Webapp
A healthy webapp is a happy customer! Wouldn't it be great if you knew that your client's webapp was alive, well and kicking 24/7? We know and report just about every type of error right down to the line of offending code direct into our mechanics inbox.
Finding Bugs in Software, a Huge Waste of Resource!
As experienced software engineers, who've worked in some of the world's largest software companies, we know what saps our time and energy. Bugs, little defects in our software both old and newly introduced. Historically it comes via a bug report ultimately from a human user, some are quite detailed, some are pretty vague BUT all need to be reproduced in order to fix them. Trust me here, there are thousand of engineers who spend their entire careers doing this task. It drains precious time from a team who could be more productive creating new features. This was a big, big area that we wanted to improve with our live architecture. We've done it! In our world bugs come to us automatically. So how have we managed to improve things when others have failed and keep failing?
Installing and Updating Software on a Device
"It's working on my machine" cries the software developer. "Well it sure ain't working here on my machine" screams the user! Impasse. It's impossible to recreate the computer environment of the user on another machine, sure they're similar, but there could be major differences in the core operating system from different versions or different conflicting installed software. It's an impossible situation. The moment that you start installing software on a user's device your heading for a maintenance nightmare. So what makes us different? Simple. We don't install software locally on a device, it's up in the cloud and there's just one running webapp for all users. It's a little more complex than this but that's the essence. All our users connect to a single running webapp in the cloud. The only installation and updates are done by our engineers on a single machine with a consistent operating system environment. If we have a webapp bug, all our users have the bug. We fix it in one place, quickly and efficiently, best of all we have no distribution to device headaches.
We are the First to Know if there's a Problem?
We wanted to know before our users if there's a problem with our live webapps. Nothing more embarrasing than your client phoning you up. Remember we're not perfect as coders, we're really experienced but we all make mistakes. With coding it's very, very easy to screw up! So, wouldn't it be great if we were somehow told if our own software detects an issue. It would be even better if we knew the exact issue and amazing if we knew exactly where in the code. It'd be almost like having CCTV for programming. Imagine the time savings of seeing your live code going wrong on a monitor. It sets us off in the right direction with less guessing and more knowing. It would be good to alert our mechanic users too! We've an amazing, centralised alert dashboard built into Project Peach and live notifications on alerts. So if a user creates an issue using a live webapp then we know straight away, we fix it and update the cloud hosted webapp. Normally the user is unaware of any issue. It's like our live customers also help us fix bugs simply by using our software on their day to day business. In this way our live webapps improve over time. So all that is quite general but what do we actually monitor in realtime?
What if our Cloud Hosted Live Webapp Encounters an Error?
Our webapps, the bit in the cloud, are native code c++ industrial strength, powerful applications. They are designed to run 365/24/7 for months on end. It would be really useful to know if there's any wobbling going on or if there are any exceptions (errors). We try to catch all possible errors and recover if possible, as in self heal, but also report the error with as much detail as possible to our coders. We actually excelled here! We've our own in-built debugger module that gives us the exact line of code, the source file and the call stack (who called the code). This is everything a software developer needs to start to track a bug. CCTV for live release code. A message is dispatched to a mechanic who is sent the full error report. That's our bug reporting. The end user who stumbled across the bug is NOT involved, it's simply caught by our smart live webapps and passed on in realtime into our bug system. So if we've added a new feature or changed a bit of code in an update, we soon know if we've goofed. Remember too. We use this in our own testing, before this release ever hits the streets. It's as useful pre-release as it is post-release.
What about Database Errors?
As you've probably guessed most of our live webapps use an underlying database to store customer information, order history, product information and so on. We need to save information to the database and retrieve information from the database. To do this we use a language called SQL (Structured Query Language), it's not important to understand this other than it's used to ask questions about the data, "Give me all the products starting with 'Tr'". As a user by using our webapps you're actually generating questions to retrieve data in our server software. So it's important for us as developers to know if our SQL statements are being properly formed, returning the correct data and without errors. It's another big source of bugs in software, bad SQL statements. So we've added CCTV again to this area. Errors are reported to our mechanic users via the same automated process outlined above. It's not just about failure though. We report slow running SQL statements too. Remember some of these can be quite complex and potentially slow. If it's slow we want to know. Our database access is of course multithreaded and concurrent, our SQL queries run at the same time for enhanced performance and happier customers. We monitor right down to this level. We want to know before our customer that something is going wrong. Again this is really useful in our own developer testing too. We aren't working blind like most, we have the fullest information possible and it makes our maintenance more efficient.
What about the 2AM Catastrophe?
So. What about the errors that we don't catch and can't foresee? They're going to happen at the worst possible moment and we love our offline time and sleep. So we created a watchdog up there in the cloud. It's a sort of safety net, sitting there just waiting and monitoring. We have the concept of a heartbeat between this watchdog and all our running webapps in the cloud. It checks regularly for a webapp pulse and whether clients can connect and exchange messages. Is it alive and communicating now. What if there's no response? Simple, we kill the webapp if necessary and restart it automatically. We do of course let our mechanics know that this has happened. The webapp starts and continue it's journey into the night and best of all you and we continue to sleep.
What about Hosting Problems?
So we've got all of this error logging for every aspect of our webapps. Using the complex information we collect it tells us reams about our hosting. Hosting is where our live webapps run. We know if the server is running slowly. We know if the network connection to our server is running slowly and we log it. We can tell the quality of our or if you prefer your own hosting from the statistics that we collect. We can tell our hosting they've got problems often before they know that they have themselves. We simply have more information and better notification to our mechanics.
Human Testing for Bitcoin
When we first set off on our coding revolution in 2012 we decided that the best possible way to test a product is to throw it into the wild. Inexperienced and novice users have a way of finding bugs that experienced testers rarely find. They find new pathways and don't use the old well trodden roads. So we created Cash Clamber, we offer bitcoin (an electronic currency) for playing head to head online games. Indirectly our busy gaming webapp is human testing our core framework to the maximum. It's running 365/24/7 and is always busy with users. All our newest code makes it's way here first! Remember we centrally collect all errors and fix. Impressed, human testing for bitcoin! How well is your current software tested? But don't take our word for it, why not head over there now and help us test our framework by having fun!
We Know Everything
So that's how we proactively fix bugs. They come to us, often silently to the user, and we fix them. We know what's happened in such detail that it makes it very easy for us to fix. As our clients use our webapps they are actually helping us improve our code over time. Every customer helps us refine our software to perfection. Want a better way of software development? We've fixed what is wrong, made our development lives easier and make better software in the process. Doesn't come much better than that. Mission accomplished.
Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.