Let me start with some repitiones of my last article. First of all, the qualitiy of the talks was just as high as on day one. Second of all, I still don’t guarantee 100 % exactness in my summaries.
Final warning: This article has just over 4000 words. Therefore, you should either take your time reading it or just select the summaries that interest you the most.
Laurent Bugnion – An overview of the Xamarin programming platforms
- Twitter: https://twitter.com/LBugnion
Laurent gave a quick overview of Xamarin, the framework for developing one app for the three major platforms iOS, Android and Windows Phone (more or less) simultaneously. Xamarin has its roots in the time of Mono (which, by the way, is Spanish for monkey), Monotouch and Mono for Android. Some of the same people of that time are still on board. Xamarin has a few basic principles:
- Coding is done in the .NET implementations in C# or F#.
- It thereby takes advantage of the .NET ecosystem of tools, libraries and so on.
- It is possible to add native iOS or Android components.
- It is possible to access native iOS / Android code.
- It is possible to build native executables.
For the actual developing there is Xamarin for Visual Studio on Windows and Visual Studio for Mac on macOS. For debugging purposes it has the required simulators built in. Laurent presented the power of Xamarin during a demo in which he added a button and a label to a UI and incremented a counter, displayed in the label through, clicking the button. For sharing business logic, which does form the largest part of the overall code base, Xamarin has what is called Portable Class Libraries. Those are written and tested once and then used for all platforms. For the UI there are two options. One is to develop native UIs for the specific platform within Xamarin. The other is Xamarin forms, with which UIs will not have the device specific look and feel, but instead look the same on all platforms. Developers have to decide which to use. The forms were also presented with a short demo. Finally, Laurent mentioned the Xamarin Test Cloud for testing your app on actual devices and the Xamarin University for acquiring deeper knowledge on Xamarin.
Dennis Pilarinos – Putting together the best CI workflow for mobile apps
- Twitter: https://twitter.com/dennispilarinos
Another more product-based talk was given by Dennis from buddybuild, which is advertised as “A continuous integration, continuous deployment, and user feedback platform for iOS and Android development teams.” on their website. The first part of the talk was a large demo of buddybuild itself, which was too detailed to repeat it here. It seemed like a promising tool for Continuous Integration purposes and for quickly and painlessly uploading your new releases to the App Store or PlayStore. Dennis concluded his talk by showing some statistics from buddybuild. For example, 95% of the code used in projects built by buddybuild are cloud-hosted, of which most are from github and bitbucket. Other statistics were on the used devices, or iOS versions.
Niels van Hoorn – Prototype Everything
Sergei Gleyzer – Machine Learning
- Working group at CERN: http://iml.web.cern.ch/
One of the highlights of the conference was the next sofa talk. The guest was Sergei Gleyzer, a well-renowned particle physicist from CERN, who is working with the (and the results of the) Large Hadron Collider. As before, I will give a short summary of the questions asked and the answers given.
- How accurate is the science in theTV show The Big Bang Theory? Sergei said he mostly pays attention to what’s on the white boards and sees that most of it is very current research and that it is actually accurate. All in all he loves and enjoys the show.
- Are you smarter than Sheldon? “Probably not,” he answered with a smile on his face. But he mentioned that there is basically everything of CERNin the show like a theoretical physicist, an astrophysicist, an engineer and so on, which he very much likes about the show.
- What is a particle physicist or particle physics? It is the science of trying to understand how building blocks in matter work all the way down to molecules, atoms and quarks. It tries to answer the question “Can you build everything out of those building blocks?” Physicists today have what is called the Standard Model which explains many but by far not all questions; most of the universe is still not understood.
- What is machine learning? It is the science that deals with algorithms that get better with training and experience, e.g., for identifying faces, extracting features, and the likes.
- Are the tools, languages, and frameworks you use specific to CERN or are there general ones? “Physicists like to do things themselves,” he answered with a smile on his face. Actually there is a machine learning group at CERN with about 500 people in it. This gives them the manpower to make a lot of software themselves. But of course, they would not reinvent the wheel, so they sometimes do use existing tools.
- Machine learning plus particle physics equals … ? He did not directly answer the question but instead first stated the challenge the people at CERN are faced with: To find a good way to find new types of physics. For example, a short time ago, the Higgs boson was proven to exist, which was not possible with earlier technology. Stated differently, the challenge is to find a few “needles in gazillion of haystacks.” He said that almost 99% of the data generated bycollisions in the LHC are thrown away. So, ultimately, the challenge is to filter interesting data and at the same time find new stuff.
- Is it more important to make faster decisions or to keep more data? He would love to keep more data, because they are probably throwing away some Noble Prizes every now and then. Therefore, the aim is to do more decision making online, which enforces the need for real-time classification in the machine learning algorithms.
- How far is that away? He did not really give an estimate (or maybe I just missed it), but as an encouraging statement he pointed out that in case of pure machine learning in the last five to ten years there was a vast improvement in compute power.
- From the science that was valid about 300 years ago maybe two per cent is still regarded as valid. Will the percentage of science that will stay valid in 100 years be higher than that? Again, he gave a rather evasive answer by stating that humans are an observant species and that we find everything new each day.
- This is not an answer to a question, Sergei just suddenly remembered that 3 is a very important number in particle physics. Every particle, e.g., quark or electron, has two brothers which are the same except in mass. The answer as to why it is exactly 3 is unknown.
- How is machine learning affecting the world in the coming years? It is already happening these days. It is obvious when seeing how smartphones have changed the way we behave. And he is certain that we’ll get used to those things easily, e.g., by self-driving cars. He thinks it’ll appear in every area, especially when there are real-time algorithms.
- Where should people start for getting into machine learning? He stated that you don’t need a PhD or other degree for learning or applying machine learning, all you need is desire, since there are great books out there.
- What is the answer to life, the universe and everything? No, he did not answer “42.” But when looking at how things evolved in general, and regarding our limited time on earth, the purpose of life, to him at least, is continuing it.
Jens Ravens – Server Side Swift
With Swift Apple really seems to have hit a sweet spot. Many people are adopting it for their apps. But since it was published as open source and Apple opened the whole change process to the public community it got really wide-spread interest. Therefore, it does not come as a surprise that it is even used for server side implementations. Jens Ravens elaborated on that topic in his talk. He started by giving his two main advantages of using Swift on the server:
- Swift is fast, due to being compiled instead of interpreted.
- Overall developer happiness, because people can stay in their cozy environment and even share code between server and client.
He also pointed out that the second reason is actually more important. While it is true that a faster execution time leads to less server costs this is actually not relevant, since in a typical company (he even presented numbers from his employer nerdgeschoss) only about 2% of the budget are spent on server costs. On the other hand about one third of the budget is spent on salaries. Therefore, in his opinion, it is more relevant to increase developer happiness and thus productivity. He continued with a (very) short introduction on, as he put it, “http, the internet and everything else,” by describing how a browser handles requests and responses. He backed up his explanations with some basic Swift Protocols to describe what was happening. He further stated that it is advantageous to abstract server implementations from pure request handling and mentioned two APIs for that purpose, namely the open swift standards and the Swift server APIs and presented the Model-View-Controller-Router-Storage (MVC-RS) design pattern for structuring web applications in Swift as an evolution of the well known MVC pattern. Jens concluded his talk by naming Vapor and IBM Kitura as the current state of server side Swift.
Marcel Weiher – High Performance Architecture
Everyone likes speed, right? Marcel is one who thinks of speed in terms of an application’s architecture, which he defines as the “large(st) scale structure of a software system, components and connections” and named examples like call/return, pipe/filter, and events. Marcel went on by quoting one of the most popular sentences in software development: “premature optimization is the root of all evil.” Only to reveal to the audience that this quote is greatly misused because it is often not put in the right context. When seeing the whole sentence this actually means that there are parts where you actually should optimize. Also it is more important to make your code and architecture optimizable for later times. He continued by showing how easily a very common architectural principle, namely call/return, can be mistreated to cause a crash of the application or even the machine it is running on. He showed another example that leads to a memory overflow. The essential problem is that each call stops the execution until the return value is provided and for this in a call tree each level must include all partial returns from the level below. In the mentioned example it is actually better to user a buffer and write to that buffer. Marcel then went on to an architectural layering and said that even if all the layers themselves might be fully optimized, the whole system can still be improved by orders of magnitude with a hexagonal achritecture under the phrase ‘model first.’ To emphasize this, he presented results he generated (with his team) on the station data of the Berlin public transport system. He described how, by using bucket search, the data, i.e., the model layer in the layering architecture, can be restructured, to yield smaller files sizes, faster file creation and better query times. The latter ones were actually enhanced by a factor of, roughly, 8000.
Benedikt Terhechte – Protocols with Associated Types: When to use them and how to avoid their pitfalls
Protocol-oriented programming is one of the buzz words in Swift programming at the moment. Therefore, it seems only logical that someone has to warn the community about how not to use them. Benedikt started by giving a first example, a protocol named Bookmarkable that extends the Equatable protocol inherent in Swift. That simple piece of code actually does not compile with a confusing error message. The problem in that case is the Self in the == method of the Equatable protocol as this introduces an associated type. With associated types, protocols are actually unfinished types, since structs or classes implementing the protocol might have different, incompatible types for the associated type. That can be dealt with in one of two ways. Either the implementing type makes an explicit declaration with the typealias keyword or through an implicit declaration by simply consistently using the needed types in the correct places. Associated types are also cause of confusion when it comes to generics. Benedikt asked the audience why there is a difference between structs and classes on the one hand and protocols on the other hand. The reason is actually quite simple. When using generics as usual in protocols, the implementing types have to include the generics in the function signatures. Thus, if the generics are changed in the protocol, the whole code base must be re-checked and changed. He next stated the problem of when you want to extend an associated type but just want a protocol, like in the first example when you want a type / protocol to extend Equatable, and presented several solutions. The first solution is to make the value equatable. The second proposed solution is to make the implementing type equatable. As a third option he proposed to define an associated protocol that is shadowed by a normal protocol. And finally you can make use of type erasure. Benedikt then presented a way to leverage associated types to ensure that an associated type is of a specific type. E.g., when in a protocol you have “associatedtype V: <SomeOtherProtocol>” then in the implementation you can write “typealias V = <SomeTypeImplementingSomeOtherProtocol>”. He concluded his presentation by a demo of ReSwift. This can be used in UIs to store the application’s state in one struct and let UI elements update the state and then the UI is updated according to the changed state. He showed how that can be done with associated protocols.
Adrian Kosmaczewski – Developer’s Guide to Migrate Across Galaxies
- Medium: https://medium.com/@akosma
- Slides: https://speakerdeck.com/akosma/developer-guide-to-migrate-accross-galaxies
- Twitter: https://twitter.com/akosma
This was probably the most comical of all the talks I have attended. Adrian presented a followup to his talk of last year about how to be a developer after 40 years. The core aspect of that talk was ‘galaxies.’ He thinks that every new technology creates a new galaxy, maybe even containing black holes. In his talk he presented six of his galaxies, all centered around one or several programming languages or techniques he encountered in his life. For example, he stated how it is very often the case that newer versions of a software are not able to read files created with some older versions. The talk was so fast paced and so much to take in that I can not repeat all the presented galaxies in detail here. At the end he tried to make people aware of the fact that in the industry things have to change, not only on a technical level but also on a human level, since there ist still sexual harassment and racism everywhere. He, for example, being Swiss, was once not accepted by a Swiss company due to his polish name. He then jokingly said to the audience that he was very willing to show those people his photos from the Swiss army. You should really see the video of his talk.
Martijn Walraven – Strong typing from the server to the UI with GraphQL
After that came a more technical talk. Martijn presented GraphQL, a mechanism first developed at Facebook after their bad HTML 5 mobile app in 2012 with the question “what would an ideal api for mobile apps look like?” in mind. They came up with GraphQL, which essentially is a data query language. Martijn started with the example of web service responses to fetch all the GitHub repositories of his company Apollo. First of all, that would yield a very large response on its own (he presented the text scrolling through the screen and mentioned the scrolling would continue for a minute). Secondly, if he then wanted to know the main contributors of each repository, he would then have to use the entries in first response to generate more requests for which he had to wait and which would also be large. This is where GraphQL came into play. GraphQL uses schemas as a strongly typed and self documenting contract between client and server. The server exposes the schema to the clients for them being able to build their queries. Responses are sent in JSON and queries actually look a lot similar to JSON. He demonstrated that by showing GraphiQL, an interactive query editor, to make the above mentioned queries on GitHub. Further advantages of GraphQL are that it can be used to mutate data on the server by query operations extended by the keyword mutation, and that no versioning of the API is needed when changes are introduced. Then came some code snippets on code for the server side implementation, so-called resolver functions for parsing and responding to queries, and for the client side, i.e., for the generation of requests. Martijn closed his talk with a quick demo of an Xcode integration that allows a query preview that’s connected to the displayed code through the schema.
Meghan Kane – Getting Started with Machine Learning in your iOS apps
- Twitter: https://twitter.com/meghafon
- Website: http://meghaphone.com/
- Slides: https://speakerdeck.com/meghaphone/getting-started-with-machine-learning-in-your-ios-apps
Megahn tried to bring the audience closer to machine learning for use in iOS apps. First, she defined machine learning as the field of study that gives computers the ability to learn without being explicitly programmed (e.g., for image classification, face detection, handwriting recognition). With regards to apps, machine learning enables, in her opinion, a more personal user experience. In order to find out how much the experience is affected, she proposed to find key performance indicators of the app, formulate a hypothesis on how machine learning impacts those KPIs, and then conduct experiments scientifically and measure performance before and after the introduction of machine learning. She continued with a very basic crash course on neural networks, having input layers, hidden layers and output layers. Each layer consists of several synapses, each having a weight. Input values are stepped through the layers and recalculated with the weights to give a final outcome. The weights in the network are the model that has to be trained beforehand and can then be used in the inference step to predict outputs for unknown inputs. She also stated that in an iOS device one can only perform inference, since the training step is too computationally demanding. Instead one should use pre-trained models and proposed the use of Tensorflow or VGGNet. She also stated that Apple offers APIs for convolutional neural networks, namely BNNS and MPSCNN. Finally, she also stated why you should do inference on the iOS device in the first place, since you could just let some server do it. Her points on that were data privacy on the one hand and free, as in no monetary cost, computing power of the devices.
Cesare Rocchi – The Power of Part-Time
Finally, the conference came to an end with this talk. Cesare started off with a quick summary of his life, how he got a Commodore at the age of 13, then never touched a computer again until the age of 21, when he came in contact with a modern PC and discovered the internet through Altavista and ICQ. Then he studied something very different: Philosophy. Or so it appeared. He actually got kind of forced into programming since all his wonderful theories had to be proven somehow. He started with Common Lisp and later went on to a mixture of Java and Flash. After his PhD he started as a freelance consultant, which earned him good money and led him to think he ‘had it all figured out.’ Until he became a father of two children. He used that as an example of any other kind of event in life that you can not ignore and that you have to adjust to. He continued his freelance activities but it seemed different. Then came along a podcast by some Stefan Sagmeier who thought of retiremetn in a different way. Instead of spending a contiguous retirement he spent a whole year off every seven years. Born was the power of part-time. Since then Cesare works 4 hours each day and the rest of the working day he is afk. His major drawbacks are that his beloved ideas.txt grows ever larger and that he has less time to learn. On the other hand he sees several advantages.
- He has more time for himself and his family and friends, he can live the moment.
- He is more focused on his work.
- He can do stuff more elegantly.
- He can actually ask himself if he can avoid implementing a feature.
He also discovered what he calls the power of small. Instead of following the mantra of ‘grow, grow, grow’ he sees several benefits of working in a small company:
- Small market: Big companies usually don’t target small markets, therefore there usually is less competition and one can talk to real customers.
- Small team: You can move faster and have less bureaucracy, therefore you are less often stuck with decisions.
- Small launch: Questions like ‘what if the backend doesn’t scale?’ are obsolete in Cesare’s opinion, since nowadays there are service where you just use a slider to increase capacity. So he asked, why not use soft launch and release to friends first and then widen the audience.
He concluded his talk with some of his tricks for staying focused, namely:
- Set a time limit and break down task into small tasks.
- Limit the set of features.
- Plant water lilies that get potential customers closer to your product by, e.g., engaging in communities and gaining their trust.
Again, I have to point out that AppBuilders 2017 was a very nice conference at which I learned a lot. I hope you enjoyed reading my articles on the conference. Feel free to spread them on your channels. If you’d like to support me further, you could download by shopping list app. It’s called Shoptimizer and it’s amazing! Oh, and thank you for reading through all of this, it is much appreciated.