“OMG!!!! WHY??!!” said everyone I told about my decision to swap back to a Windows machine from Mac.
In a later post I’ll talk about the implication of my choice of hardware (and software). But for this post I wanted to talk about why I decided to swap ecosystems.
As a test consultant I’ve been using a Mac for the past few years. However quite often I work at places where my colleagues use PCs which oftentimes means a Windows machine. And I’ve noticed is that it is much more difficult to set up your local development environment on a Windows machine. At times the tooling wasn’t compatible across platforms.
When things don’t work out for our fellow Windows users we would try to help them out but eventually give up if we can’t get it working. Ever hear someone say “You should just get a Mac.” or “You should use Ubuntu.”? Because of corporate policies this is likely not possible.
It recently dawned on me that as a consultant I should not just live in the siloed and safe Mac environment and actually learn how to work on platforms my colleagues use as well. This would actually allow me to advice and give guidance on how to set up a Windows machine to do development/testing work on.
At the end of the day it doesn’t make sense to ask your employer to change systems because you don’t know how to use it. Personally I believe that even though testing is my specialisation and learning test tools is important. It is equally important to be able to help set up these tools on your employer’s environments. Otherwise you may struggle to deliver at a high level.
The first ever NWEWT (North West Exploratory Workshop on Testing) conference happened last weekend (1st to 3rd of April) in Liverpool. I want to start off by saying Thank You to Duncan and Emma for doing a stellar job of organising the event. I definitely felt privileged to be part of the conference.
It was my first time at a peer conference and I didn’t know what to expect and was a bit anxious about the whole thing. But the whole thing got off to a great start with dinner on Friday night which most of the attendees of the conference attended. For my starter I had ordered soup and was served an empty bowl (Yes…a bowl of soup without the soup.). On hindsight I realised this was an apt metaphor of how little I knew compared to my peers. The dinner was a good way to meet everyone and get to know a bit about them before the conference started in earnest.
The topic of the conference was Regression Testing. We were meant to present our experiences and thoughts on regressions testing. Over the course of the next two days we would hear talks from almost all the attendees and have discussions about what was presented. It was very interesting to find that a few of the talks mentioned that although they started thinking they were doing “regression testing”, they realised soon after that they weren’t actually testing for regression of their system. They were just testing. This definitely matched my experience as well. In fact since earlier this year I’ve stopped using the term after I heard someone pointed out that “regression” meant returning to a former state. In my mind that meant the definition of regression testing would be to test if the system under test had returned to a former state. In my current context that would be virtually impossible.
The other big takeaway for me was that we should focus on risk during testing. Although this seems obvious it is something I often need reminding of. @nortern_tester talked about using the FIBLOTS mnemonic to help identify risks. @Arborosa also mentioned that continuous testing involved continuously assessing your risks.
Anomaly Detection is also something I will be doing some research on after @DanAshby04 mentioned it like a million times. I think he’s trying popularise it as the next testing catch phrase.
NWEWT has also sparked off a new wave of enthusiasm to run a LEWT (London Exploratory Workshop on Testing) which I hope I’ll be invited to.
Apart from learning about testing I also rode my bike (motorcycle not bicycle) up to Liverpool. A round trip of 488 miles. 5 and a half hours up and 5 hours on the way back. It is the longest ride I’ve ever done and will constitute more than 10% of my annual mileage. The 5 hours back went by very quickly as I spent most of it reflecting on the conference. Most of the 5 and a half hours going up was spent wondering if I would get blown off the road by the crazy wind.
I just came back from LetsTest 2015 in Runö. For those that don’t know what LetsTest is, its a Context Driven Testing conference with a focus on workshops rather than lecture style presentations. Another thing that makes LetsTest different from most conferences is that accommodation and food is included. This really puts you in an environment to learn and socialise with your peers. The venue is in an idyllic location and some of the workshops are actually run outdoors.
Okay, so you have a json file somewhere, that was already created by someone else, by another project or just due to quantum fluctuation… doesn’t matter, what you want is to read that file, read the json, add another property to that json and then write the entire json back to the file.
Of course it’s not that complicated and can be done in so many ways. I saw a lot of projects that were doing this by simply manipulating the string. This is certainly not recommended since it’s pretty easy to screw up the integrity of that json object.
Instead let’s see one of the easiest and safest way to do it:
Today we are going to see how you can download a zip file, unzip the contents, browse the contents and inspect any file. On top of that, for a more practical example, we are going to parse a json file and deserialise its content into a java object:
This is not a Spring MVC tutorial. I think there are plenty of those on the internet. I just want to show you how you can enable MVC support and create an API for your app.
Sometimes you might have a simple Spring app or even a JSF+Spring web app and want to expose an API. One way to do this is to use Spring MVC Controllers. It takes only 1 minute, I promise.
This is like a black hole out there… Nobody can tell you exactly the answer. But the answer is not simple at all…
Ok, first of all, there’s a pretty big difference between how the size is calculated for GitHub.com and for GitHub Enterprise.
The short answer is that the size shown doesn’t match the repo’s size after clone. The size shown is as close as possible to the .git folder present in your repo.
Amazon Web Services (AWS) offers a whole bunch of services that enables us to deploy and host services, store process data, scales these services etc. It involves dealing with load balances, security, operating systems etc. In short it’s not exactly quick and easy. So Amazon released Elastic Beanstalk to help make deployment, versioning and scaling and general management of these services easier.
From a testing point of view AWS can be a good place to host your Jenkins instance, create a test environment and even run your tests. And Elastic Beanstalk is an easy way to set this up. Below I’ll walk through how to deploy a basic Docker application on Elastic Beanstalk.
I’ve been using git at work for the past few years and absolutely love it. I also use it for my home projects. In all cases I use Github to hosts the remote copies/versions of my projects. Github is a great service but when you have a free account (as I do for personal projects) your project will be public. However recently when I had some personal projects I didn’t necessarily want/care to make public as they were largely PoC or Hello World type projects but I still wanted to use version control. So I decided to set up my own remote git repository. This turned out to be not as I expected.