How to create your own Lint rule

When you are part of a multi-team project in Android, it becomes relatively hard to have a common understanding of how components should be used. This is where Android Lint can help you! In this blog we will show you how you can write your own Lint rules and test them. As an example, we create a sample Lint Detector, which is used to detect whether you have excluded the "secret data" in your application from the Android Authobackup introduced in Android Marshmallow.

Read more →

It’s 2017: Test automation is not optional when building mobile apps!

Note: although this post focusses on mobile app development using Xamarin it also applies to other native mobile apps built in Swift, Java or even web apps. it’s 2017! whatever you are building get started with Test Automation!

As a consultant working for Xpirit i get to see a lot of different customers which I help with my expertise in building mobile applications to improve their mobile apps. Something I noticed in the previous year is that continuous delivery is a hot topic and companies and teams focus on deploying apps automatically to their testers through hockeyapp or even to the stores in beta and / or production.

In agile scenario’s (and come on who isn’t doing that currently? Every company or project I visit is saying they are agile or doing Scrum although some only do dailies and call that scrum ) In the current world it is really important to be able to release often because you want to be able to adapt to customer needs which are almost always changing and evolving.

Read more →

Matching strings in Scala

Over December I had a lot of fun doing the Advent of Code coding challenges with some colleagues.

Many of those, such as day 21, require interpreting some kind of string input. While normally I'd probably marshall those strings into case classes before processing, in this case that seemed like overkill: a quick pattern-match should be sufficient.

It turns out there's a couple of ways to approach that, which is also a good excuse to look under the hood and see which Scala concepts they're built on.

Read more →

A Guide to Generating Boring Code with Node

Writing boring code is not fun. Especially if that code is just a derivative of some data. You should generate it instead! A great example is to generate your HTTP client code from an API definition. This is actually very easy to do with a recent node version and requires almost no extra dependencies. In this post I will show you how to take a JSON schema definition and generate some validation logic from that.

Read more

An alternative AngularJS test runner

When building an Angular application, we usually stick to the suggested or auto-generated solution of unit testing; the Karma test runner and server, the Jasmine testing framework, and PhantomJS as the environment to run it all in.

In this blog post I'll explain how this is rather silly, and will provide an alternative and lightweight approach to writing and running unit tests. It will depend on having a certain way of defining your Angular components, and may not be a full 1:1 drop-in replacement, but I can say with a certainty that it'll make your tests faster, the overhead of running them a lot smaller, and improve the quality of tests by having less to worry about.

Read more →

Cypress - Dealing with flaky tests

Test automation is all about feedback. Feedback that gives you quality updates about the features your team has built. A continuous green build is always the goal because this should give you the confidence you need to go to production. Unfortunately, I’m more used to a “traffic light build”, a build which passes and fails intermittently, mainly because of flaky tests. That is one of the worst things about end to end testing in my opinion.

Why on earth do we still put software into production when we can’t trust our test automation?! Well, that's because we retry the build a couple of times until we have a lucky hit: the build is green and we’re ready to go to production. Although this is a solution, it still feels like a pretty silly thing to do.

Another option, which has my preference, is refactoring those tests until they actually work. The annoying part about this is that you don’t know what’s going on, and most of the time it is impossible to reproduce the failures. Reproducing them takes a lot of time debugging, analysing and mostly guessing where the problem is.

What if we could actually see what’s going on?

Read more →

Fix “App may slow down your iPhone” popup for Xamarin apps

For a while now (september 2015)  Apple requires apps that are submitted to iTunes to be 64 bit. When building your app for the simulator this isn’t required because app doesn’t go through the Apple screening. Since iOS 10.1 update however Apple added a little popup that checks if an app supports X64 and otherwise will show you a popup telling: “[App name] may slow down your iPhone”. It will only show the error message once and is meant for old apps which are added to the store before september 2015 and are still on peoples phones/tablets who need to update to X64.

Popup message: [App name] may slow down your iPhone

Screen Shot 2016-11-08 at 22.09.46

The fix is quite easy. just set the iOS build to support X64 also when building for the simulator.

Xamarin Studio

in Xamarin Studio go to properties of your iOS project. by rightclicking your iOS project. -> iOS Build tab  -> make sure that Supported Architecture for each configuration contains X86_64 or i386 + x86_64

Screen Shot 2016-11-08 at 22.08.58

Visual Studio

in Visual Studio right click your iOS project and select properties. -> go to iOS Build -> Advance tab ->make sure that Supported Architecture for each configuration contains X86_64 or i386 + x86_64

Screen Shot 2016-11-08 at 21.45.38

 

Although this is a small issue i got some questions by new developers what this message meant. so hopefully this blogposts helps those who were questioning why this message is showing up all of a sudden.

Happy coding!

Geert van der Cruijsen

The post Fix “App may slow down your iPhone” popup for Xamarin apps appeared first on Mobile First Cloud First.

Robots bring business and IT together

Maybe you’ve already read the diary of one of our mBots, if not I encourage you to do so first! So, what was this day all about? How did we come to organise this and what did the participants learn?

Changing teams

As companies decide to adopt a more agile way of working, they also start to form multidisciplinary scrum teams. However, there still is a big challenge. When you work with several disciplines in your scrum team, you are exposed to the risk that you still create mini-handovers. First the business analyst will make the design, the developer(s) will build it, the testers will test it and if you’re lucky the business is happy in the end. Team members tend to keep doing what they’ve always been doing. Nothing really changed! Of course, we cannot realistically expect that the business suddenly starts programming, but it would be great if they know the difficulties that developers cope with. It works the same the other way around. We need to learn from each other and bring our work closer together.Read more →

The Purpose Alignment Model

When scaling Agile/Scrum, we invariably run into the alignment vs. autonomy problem. In short, you cannot have autonomous, self-directing teams if they have no clue what direction they should go. Or, even shorter, alignment breeds autonomy.

But how do we create alignment? And what tools can we use to quickly evaluate whether or not what we want to do is part of the mission? Niel Nickolaisen, chief technology officer at OC Tanner, created the purpose alignment model. I use it with innovation labs in large enterprises to determine what aspects of innovation to keep, and what to leave to others.

Read more →