0

The Berlin Calling

It’s with an excited gaze and a grin that doesn’t seem to go away that I write this text, sitting in a small bar fit with wooden pallets for chairs, overlooking the Spree river. I am, no, we are, in Berlin; and it’s neither sightseeing nor a meeting, we came to stay!

As with every emerging tech company, one of the biggest challenges we have to face is scaling. And scaling a company isn’t as simple as growing the team, user base and customer array. Its doing so while maintaining the quality of our products and continue to deliver polished and innovative software solutions that push the industry’s standards forward.

This sustainable growth, however, would only be possible by further strengthening our ties to the international tech scene. MobiLab is no stranger to hosting and participating in meetups, workshops, hackathons, and even maintaining a growing open-source presence, but that would only take us so far. And since our strong technical know-how and creative thinking are not mere strengths for us, they are rather the founding pillars of our philosophy, we felt as an outlier in the small city of Cologne. Thus, it became apparent that our geographic position was the biggest bottleneck in the scaling of the company. Staying connected to the tech scene was no longer enough, we needed to be there.

The question then became not why, but where. There are few countries in Europe, if any, offering as many distinct technological hubs as Germany, each with their own disruptive startups shaping the industry of tomorrow. Hamburg, Munich and Berlin are just a few of the cities with a growing presence in the software industry and with a growing number of developers and entrepreneurs. Each of these cities have their advantages and disadvantages, some are closer to customers, others are focused in key industries for which we are actively working on. But it ultimately came down to a cultural fit. With a team from over 10 different countries and a strong focus on innovation and experimentation of processes and solutions, there really was only one place that we felt was right – Berlin.

In retrospect the decision to open an office here was obvious, painfully so because it meant we would have to split the amazing team we worked so hard to build. But all good things come to an end. Besides, the timing was perfect, considering we had two core members ready to move here for totally different reasons: me, for the undeniable opportunity for adventure and Utku, whose personal life mandated.

Within a month we had found an office space, right in the heart of Kreuzberg, perhaps the most iconic district of Berlin. Another month and a half and we both had found apartments and an iOS developer in Berlin was hired. And just like that, the time had come and we were past the point of no return.

You hear a lot about Berlin. Blogs, friends, news, it seems that everyone has an opinion and they often paint it as a grey city filled with cold, pretentious people; “unforgiving” was a term used by a fellow Portuguese expat. I expected a city filled with serious faces and unapproachable people. My experience so far proved to be the exact opposite. Never in Germany did I feel more welcomed or more integrated. English comes naturally to everyone I talked to, from the kiosk owner to the restaurant menus – being different isn’t frowned upon but celebrated. The skies are grey, but the color is in the people and places and their incredible diversity. It’s only been about two weeks since we moved, but every day it becomes more clear that this was the right decision.

The journey, however, has only just begun. Getting office space and apartments here was just the very first step for the Berlin branch. The next challenge will be establishing a team and its processes, operating functionally independent from the Cologne branch. Until then, we plan to do as much as possible to integrate in the Berlin startup community, be sure to find us at your nearest tech meetup!

João and Utku are both engineers and the Berlin Branch Managers. If you are interested in joining the Berlin team, and want to know us better, just pass by or apply to this e-mail.

0

MobiLab Solutions Partners up With Rancher Labs

With an effort to deliver highly-available and well maintained container clusters, MobiLab Solutions decided to become part of Rancher Partnership Network program. MobiLab Solutions started using Rancher’s products several years ago, for managing various container clusters used across projects.

The status of partnership resulted as a joint effort between Rancher and MobiLab to spread the knowledge and expertise with handling complex deployments and scaling strategies. MobiLab will continue with getting two of its team members certified for Rancher Labs products and hosting educational workshops on the company’s premise in Cologne.

rancher

One of the workshops that are part of Rancher Rodeo is going to be held on September 22nd at MobiLab Solutions’ office in Cologne. It’s a half-day, free and interactive workshop targeting people who are already familiar with Docker, and who are planning to use the knowledge for managing their container environments.

Stay tuned for a technical overview of some Docker functionalities that we used.

0

Creating and Releasing Butler – Client For Jenkins

jenkins-logo.png

Prelude

Not long ago, we released Butler – Client For Jenkins, a new mobile Jenkins client for the iPhone, supporting 3D Touch and many other features designed to make using Jenkins on mobile devices a smoother, more enjoyable and more productive experience.

Butler is an open source project and we are always happy for contributions of any kind.

This post will go into detail about the motivation behind creating Butler, the features that we decided to implement as well as challenges that presented themselves while creating this application.

Motivation

We at MobiLab have used Jenkins for Continuous Integration for a long time before moving over to Travis for various reasons. It is this history with the tool, that lead us to create Jenkins for Android and that again lead us to create Butler.

We saw creating Jenkins for Android as a way to give back to the community that provided us with amazing tools. The same goes for Butler. This time, however, with open sourcing the complete application, we went a step further.

Jenkins for Android has been a great success. Many people are using the app and enjoying the experience we deliver. We did not feel as if the same level of quality for Jenkins applications existed on the iOS app store yet. Therefore, we decided to create it ourselves, even if it meant building a whole new application from the ground up.

Features

With Butler, we aimed to create a feature rich mobile application that supports every major Jenkins feature that is actually needed on mobile platforms. Those include but are not limited to:

  • Full support for viewing your Jobs, Builds, Test Cases, Folders and more
  • Triggering Builds with and without parameters
  • Full 3D touch support
  • Add Jobs and Builds to your favorites to keep an eye on them
  • Today Widget for even faster access to your favorites
  • Connecting to Jenkins instances over http and https
  • Fully open source!

Challenges

Along the way of creating Butler, I had to overcome a few challenges both concerning environmental factors (the Jenkins API) as well as concerning the iOS ecosystem. Listing all of those small challenges would not only be a long endeavor but also quite boring. The following are therefore two examples that I deem to be more interesting and worthwhile than the others.

Understanding the Jenkins API

Unfortunately, the Jenkins API documentation is not exactly complete. Many calls lack information about the concrete data points that are returned and as a result of some of the plugins that the mobile application was supposed to support, the effect of those on the returned data had to be considered, too. Fortunately, we were able to extrapolate a lot from Jenkins for Android, only having to translate from Java to Swift along the way.

Understanding an API that has little to no documentation can be a daunting task. However, most questions about the general structure of the API could be cleared up looking at the Jenkins for Android sources and questions that went into more detail could be answered or at least approximated by simply having a look into the returned JSON-data.

What turned out to be especially challenging were the API differences between versions of Jenkins. Some versions return an array of test result child cases while others return an array of test result suites. There are quite a few of these undocumented differences that can only be circumvented by intensive testing using different Jenkins instances. Furthermore, triggering builds on jobs is a task that has multiple different facets, too. The procedure of triggering a build is different when there are parameters that need to be provided vs when CSRF protection is enabled vs when both are en- or disabled. Again, through trying out a lot of variations, this part of the application could be brought to work.

If you have concrete questions about how to use the Jenkins API, simply send us an email. I will try to answer your questions as far as I can. Perhaps, there will be a blog post about precisely that topic in the future.

Creating the Today Extension

One of the application’s key features is the Today Widget that provides the user with up-to-date information about his or her favorite Builds and Jobs. For that purpose, both the persisted Job and Build as well as the account information have to be shared between the main application and the app extension.

On iOS, this can be done easily with App Groups and Keychain Sharing. Butler therefore persists its favorites data as well as general information about the various accounts that are saved to a shared container between the app extension and the main application. Then, the information that should be kept securely (e.g. passwords) are written into a shared keychain. That way, both parts of the application can use the same data. To then share the same Model and Service classes between extension and main app, a runtime flag was introduced that determined the exact location of the files and the exact way to decode those.

Conclusion and What’s next for Butler

So far, creating Butler has been a valuable experience for me and I am excited to see what kinds of features the community would like to see in this project.

It is my goal to make Butler an application that is both easy and enjoyable to use and also as capable as possible. To achieve that goal, feedback from the community would be greatly appreciated. Simply send us an email at jenkinsios@mobilabsolutions.com.

As many other open source projects, we are very happy about contributions of any kind. If you are interested, the code is hosted on GitHub here.

Robert is a junior iOS developer at MobiLab and is in charge of developing Butler. When he is not working, he attends school in a nearby city to Cologne. To get in touch with him, simply send him an email here.

Do you want to create amazing mobile experiences, too? Find more information here!