AWS is the biggest public cloud out there. You could do almost everything with it except for running x86 Android emulator. Things were like that in the past. It all changed on May 17 when bare metal instances became GA. New instances type allows access to the underlying hardware which means running x86 Android emulators on AWS is now possible. Now you can scale your Android tests until exceeding limits on i3.
There a lot of different services, offering automated testing on real mobile devices and/or emulators in the cloud. In this post, we will not talk about how to choose one of these services. If you are interested in choosing a service which fits you, then you can start from this article. Instead, we will talk about some issues and workarounds what you may face using AWS Device Farm. In general, such issues may be split into two categories: project specific and common ones.
My previous post about creators of Go ended with a phrase Does it mean that they were right again? I don’t know, we will see…. And now we can say for sure that they won. They were right again. If you didn’t hear it, then you should read this post. It’s about an incident from Cloudflare regarding significant vulnerability discovered in their service. But they didn’t mention the most important part, about how it was found.
I named this post after a very well-known slogan from Apple advertising. But we will not talk about Apple, we will talk about Go, the programming language that was created by exactly that type of people. The landscape of programming languages is huge. But there is something common for almost all of them. They all trying to put a lot of new features with every release. Sometimes, they broke compatibility between different versions, like Scala did or broke their community into 2 parts, like Python.
In previous post I tried to describe why I started to look into Go. Today I want to share a small example of Go power. Some time ago we had a tiny Python script for monitoring purposes that runs into CI. Setup was simple: - download script from Git repo - download and run Docker container with Python environment - run monitoring script. The whole execution time in CI was around 10 seconds.
I looked at Go in early 2015. Of course, I heard about this language earlier, but at those moments he wasn’t very interesting for me. Things changed after I joined Russian-speaking Go community in Slack (golang-ru.slack.com). I found very interesting and skilled people there. And this was the main point that forced me to look at the language. I went on golang.org and read the documentation. After that, I tried to write a small CLI tool, which used for authentication via HTTP on some internal service.
I found a nice article on twitter https://www.usenix.org/conference/osdi14/technical-sessions/presentation/yuan Some ideas from it looks very obvious, but they are important. Authors told us that “Catastrophic failures are caused by incorrect error handling”. Recently, I fall in love with Go. There are lot of different opinions about this language. One of heavily discussed points of language it’s a feature of language that forces developers to process any error in their code. Obviously, lots of people don’t like to do that.
On the first day of New Year, I moved my blog from Ghost, hosted on Digital Ocean, to static blog, hosted with Github Pages.
I already thought about that for some time and today was a great time for that.
Initially, I thought about using Hugo for generating static content, but at the end Jekyll was chosen.
In my previous post I already started talking about web application testing. Today I want to share my thoughts about it. I think that sometimes we do it wrong. Our tests often become very bloated, because we are trying to do a lot of things in it. We may try to setup test prerequisites or we need to login in our app. Other problems can occur if we try to check everything via UI or check a lot of visual stuff in our tests.