In my previous post I talked about the general setting of the AppBuilders conference. With this and the next article I will give a more detailed description of the two conference days. For each talk I attended I will give a short summary.
The conference started at 08:50 am on Monday, April 24th with the registration, which went smoothly due to the three lines for speakers and participants. Interestingly, the line for family names starting with A – L was about four times as long as the line for family names starting with M – Z. Good for me, though, since mine starts with an S. The registration itself was done within less than a minute, just a quick scan of the QR code on the phone, handing over the conference badge and a goodie bag (with a t-shirt!) and that was it. There was even breakfast for the attendees.
The quality of the talks was, in general, very high. There was not one talk (of the ones I saw) that failed to deliver its message or bore the audience to sleep. I have seen far worse in the conferences that I’ve attended so far, so congratulations to all the speakers for their efforts. I know that it is not easy to talk in front of so many people. There was no Q&A after the talks since, as the organizers pointed out, the conference was supposed to be more personal and people should just address the speakers during the breaks.
In the evening of that day was a cocktail party at some place in Lausanne. Unfortunately, I could not be there, so I can’t tell anything about it from my own experience. But from what I heard, it went really well.
A hint in advance: It might be that not all of the summaries are absolutely correct since it is kind of difficult to listen to a talk and make meaningful notes at the same time. Still, I gave my best and hope the readers will get a good impression of the talks, even though. Also, the length or detail of the summaries do in no way reflect the qualitiy of the talks. For me some talks are just easier to summarize than others.
Final warning: This article has almost 3500 words. Therefore, you should either take your time reading it or just select the summaries that interest you the most.
Felix Krause – Scaling open source communities
Felix Krause is the initial developer of fastlane, a tool collection intended to rid the developer of all the tedious tasks attached to developing apps, like creating localized screenshots. The talk itself was not technical at all it was more aimed at giving a list of best practices he and his team gathered during the years in which fastlane grew from a single developer no user library to an industry standard. He listed the four key steps he experienced.
- Make your code available to the public, e.g., by uploading it on Github.
- Initially people might not be interested in your code or might not even find it. But eventually someone will find it and if it is good and useful, people will start using your code.
- If more and more users gather around your library, it might become a sort of standard, gaining even more interest on the way.
- Hyper popularity. This is the phase when your development is talked about by ‘everyone.’ This might, on the other hand also result in people starting to talk bad about your work.
Felix continued by presenting the difficulties that arise when working on a project that grows ever larger in a short time. For example, you are more concerned with handling pull request, feature requests and handling the peoples’ comments instead of actually improving the code. Therefore, one key aspect is to save as much of your precious time as possible. For example, the folks at fastlane introduced a bot that (among other activities) corrects incomplete bug reports or automatically closes tickets that were not handled or commented on for a while.
Martin Odersky – The future of Functional Programming
- Website: http://lampwww.epfl.ch/~odersky/
This was one of three sofa talks, as I liked to call them. The organizers called them ‘stories.’ The difference was that there were no slides. Instead Martin and a moderator, Steve Scott, each sat on an armchair and played a question and answer game. First, Martin introduced himself as the one bringing Scala and Java Generics to life, then they talked about some aspects of functional programming, the differences to object-oriented programming and the difficulties that can arise like multiple inheritance. Which is a subject tried, for example, by C++ but not with a wide-range success. But, as Martin pointed out, he does not know about any Scala developer having difficulties with multiple inheritance due to their use of what he called an ‘intermediate super.’ The reader might look that up for more details. One interesting aspect that was tried out in this sofa talk was the introduction of sli.do, a platform where people can ask and vote for questions for a speaker. These were later integrated into the talk by Steve. I guess, this was their take at a‘personal’ Q&A. 😉
John Sundell – Swift scripting in practice
In programming there are always tasks that are repetitive, error-prone or just plain boring. Why bother doing them yourself when the computer can do them faster and more reliably? That’s where scripts come into play. But why use Swift, a language that was designed for implementing great apps? Well, according to John, there are four main reasons:
- Swift is awesome.
- There is less context switching when you stick to just one language.
- Swift offers powerful tools, that the developer is already accustomed to.
- Developers can use their app code in their scripts.
While I agree with all those reasons I still wonder: Is that not true for almost all programming languages? Anyways, at that point the talk had to be paused and rescheduled because the projector constantly turned itself off during the presentation. The talk was repeated in the early afternoon. John went through some examples to finally arrive at the presentation of a library he developed, named Marathon. This makes it easy to create Swift packages for your scripts. He demonstrated it by writing a script that generates Playgrounds in Xcode.
Maxim Zaks – Talk Binary to Me
- Twitter: https://twitter.com/icex33
- Slides: https://www.slideshare.net/maximzaks/talk-binary-to-me
- Medium: https://medium.com/@icex33
With today’s computing power, developers are tempted to think that it’s not neccessary to pay too much attention on performance and efficiency in their applications. Well, Maxim proved differently. Speaking about himself, he stated that he likes ‘to count bytes.’ I guess, what he wanted to tell the audience in general was to be aware of 1) efficiency issues (with regards to time and space) when using libraries for data serialisation and 2) a trade-off between human readability and efficiency. He emphasised those points by comparing standard JSON to some other libraries, especially colfer, flatbuffers, and flexbuffers. His favourite seemed to be colfer, as it produces the smallest files in the shortest amount of time. He investigated them in three use cases:
- Machine to machine communication.
- State persistence.
- Representation of configurations or data dumps.
He then compared space and time efficiency of those libraries.
Roy Marmelstein – Silver Bullets in Swift
The starting point of this talk was the experience of probably most conference attendees around the world: You see the presentation of a library, framework or programming paradigm, thinking ‘I did it all wrong the whole time,’ coming back to the company and starting to implement. That he calls a silver bullet: The solution to all your problems. But later you would probably realize it wasn’t as easy as you first thought. In particular, he thought it would be great if we could shorten the time between the peak of inflated interest (the moment you hear about your new solution at the conference) and the plateau of productivity (the phase at work after you found out about the difficulties with your solution). In particular, he mentioned three hypes in the Swift environment he sees at the moment:
- Protocol oriented programming with the claim composition over inheritance.
- Functional, reactive programming as in RxSwift, where the app is regarded as a function of state.
- Swift itself, with the claim Objective-C without the C.
For each hype he mused on a ‘story time,’ i.e., a real life experience on one of those hypes from friends or colleagues. He summarized his talk with his main message: Don’t just follow trends blindly or too enthused, but find their limitations and be careful. Look for solutions to your own problems and try them out in a confined environment first, e.g., in hackathons or side projects. He closed with a quote of Steve Jobs: Stay hungry, stay foolish.
Ash Furrow – Comparative Asynchronous Programming
In line with the other mostly high-level talks was the subject presented by Ash Furrow. As the title suggests, this was not a presentation of a single framework or programming paradigm, but an overview of some features or abstractions of the term Asynchronous Programming with Swift. In his terms asynchronous programming is the execution of code in a different order than it was written in. He emphasized that one should be aware of the trade-off between synchronous and thus probably blocking code and asynchronous, non-blocking code, since neither of those is the single best solution. Or Silver Bullet in Roy Marmelstein’s words. The list of implementations of asynchronous programming possible with Swift include:
- NSOperationQueue / DRBOperationTree as layer on top of Grand Central Dispatch.
- Target / Action.
- Callbacks, Completion Handlers.
- Promises & Futures.
- Functional reactive programming, like RxSwift.
- Actor Model.
Well, according to Ash, Actor Model would be overkill in iOS. The reader might investigate further on the specific subjects. He also listed abstractions not possible in Swift, namely:
- Async / Await
- Coroutines and Generator Functions
Lorica Claesson – Animations for a better user experience
- Twitter: https://twitter.com/lorica
This was my first talk in the Android track of the conference, but luckily it did not focus on Android but presented general guidelines for animations on both mobile platforms. Lorica first introduced one reason why animations are helpful: Change Blindness. This is an effect where people cannot spot a difference in two images, when they are separated by a short display of, for example, a black screen. This is averted when using an animation to transition between the images. As an example she showed two bar charts with three bars each at different values and a loading indicator shown between the display of the two bar charts. When showing the charts this way, the changes were not easy to spot. But when one chart bar stays on scren, the loading indicator is shown in the bottom and there is an animation towards the new chart bar, the changes can be easily recognized. She then came to her two main subjects: Functional animations and Delightful details. Both are supposed to enhance the user experience. She stated several purposes for functional animations, including reinforcing the view hierarchy, and a representation of the app’s state. For delightful details she mentioned, for example, the perceived reliability, emphasized by showing the pictures of two equal cars, one shiny and clean the other bumped and rusty accompanied by the question which car the audience would rather trust. A further example was a loading spinner animation. Finally, she encouraged the audience to delight their users, for example, by using animations in unexpected places or by using non standard animations.
Laura Kalbag – Privacy
After Lorica’s talk I switched rooms again to attend the talk on Privacy by Laura Kalbag. It was another sofa talk / story, supported by questions posted on sli.do. This is a brief summary of the questions and answers (and no, those are not direct quotes).
- How would you define privacy? Privacy is about being able to control what to share and what not to share with other people. We have reached a state where cheap or free services are seen as a given, but people are mostly not aware of the fact that they themselves are the product sold.
- We are all nice developers here, why should we care what those people at Facebook, Google and so on make? To answer that, Laura first mentioned a current example of ‘bad developers’ by mentioning Uber installing a unique device id on iPhones when installing their app that even persists when the app is deleted, using that id to track people. People making technology can not only be about making shiny things, but we have to think about the implications.
- Is it the same problem if people do not think about consequences than when people do it explicitly? In short: Yes, absolutely. This was followed by a presentation of The Ethical Design Manifesto from https://ind.ie/ and an elaboration on some aspects of the manifesto.
- Are we going to have to accept to pay for services or is there another way? In her opintion the tide is turning to change. As an example she mentioned the US border control who want travelers to name their social accounts when entering the country. She thinks that people become more aware of the subject. In her opintion soon it will be a good business decision to make a difference by stating that the business respects and protects the users’ privacy.
- Do we need more political regulations to protect user privacy and can that be helpful? The change has to come from two directions. Regulations only will not work. On the other hand ind.ie is currently building a content blocker and for the future are aiming at building a platform for protecting data.
- No question, just a statement: Ads are not the problem, tracking is the problem.
- What is the first thing you look for when using a (new) free service? Is it free because it is a demo, is it freemium, does it have in-app purchases?
- What is your biggest fear? That people building the technologies will stop caring and build them regardless of the effects.
- How do I explain this to my 90 year old grandma? If it is free then you are the product, so be careful. Especially when sharing something in public that appears to be private. Even if the content might be encrypted, the metadata can tell a lot about you as a person. So, be aware that that is not actually private and the business tries to convince you that is what private means.
Andreas Vourkos – App retention, engagement and everything between
- Slides: https://speakerdeck.com/vourkosa/app-retention-engagement-and-everything-between
- Twitter: https://twitter.com/vourkosa
We all know that the mobile app environment is harshly competitive and that users are very spoiled by lots of great (free) apps. They do not want to waste time on apps and get to know them easily. In this scenario it is particularly hard to keep people engaged by an app. Andreas proposed incorporating gamification, which describes implementing some elements from game design into the app. Mostly this would mean adding achievements, but it can go much further as Andreas pointed out. He proposed several aspects, which are shortly summarised here:
- Make the users think they are a part of the app through the following aspects: a) Customization. Users should be able to easily tailor the app to their needs, e.g., by a settings screen or a theme selection. b) Personalization: The app should adjust itself to the user’s needs according to the use of the app like in Spotify’s music selection. c) Allow users to save things for later use and track the user’s progress. d) Allow feedback from the users. e) Introduce a collection, like in Pokemon Go, where you have to collect all the available Pokemon.
- Use social mechanisms to turn users into active ‘tribe members:’ a) Let users show other users what they have achieved, like in runtastic, where it is possible to share efforts to Facebook. b) Allow users to ask friends or other users for help. c) Get rewards for asking others to join the community. d) Use referrals to bring other people in. e) Motivate several people to each reach a common goal, e.g., all users in a group must run 12km. f) Allow reactions to other user’s content. g) Let users compete with each other. h) Let them see what their friends are doing.
- Use scarcity to drive engagement in mobile apps: a) Offer only a limited number of some item, e.g., in Pokemon Go some pokemon are rare and not everyone will find them. b) Give privileges only to some users as in stackoverflow, where users have to be an active community member to earn respect and therefore privileges. c) Make special offers on specific dates and timeframes with a first come first serve basis.
- Leverage freedom and creativity to impact retention in mobile apps and give rewards for creativity.
- Have a story that people will follow: a) Make people feel they contribute to a noble cause, e.g., by collecting items for saving trees. b) In the words of Steve Jobs: Show to the world that the community around your product is filled with people with values, given by passion to make a difference in the world. c) Build around an established idea. As an example he mentioned an app he created for a local football team. He said that the app was not great but popular nonetheless because people liked that club. d) Create a story like in games.
- Gain app engagement and retention through the progress of feelings: a) Make users feel smart, e.g., by a clean design. He emphasized that point by comparing the start pages of Google vs. Altavista. b) Make the onboarding experience smooth by easing the user into the app’s workflow. c) Give people a feeling of progression, for example, by the use of progress bars. And let users start from point 1 not 0, nobody wants to be a zero. d) Make the users feel special, e.g., by awarding trophies.
- Use a certain unpredictability and variety of rewards: a) He mentioned an experiment someone conducted with mice where they had to push a lever to get food. In the beginning the mice pushed it wildly but after a time they get bored and only pushed it when they were actually hungry. But when the reward for pushing the lever changed the mice would push the lever frantically in excitement. b) Kinder Überraschung / Kinder Surprise. c) Make the user feel that maybe they can win next time as in a casino where they might spin a wheel ‘just one more time.’ d) Make use of the like effect on social media.
Anastasiia Voitova – Keys from the castle: ancient art of managing keys and trust
- Slides: https://speakerdeck.com/vixentael/keys-from-the-castle-ancient-art-of-managing-keys-and-trust
- Twitter: https://twitter.com/vixentael
- Medium: https://medium.com/@vixentael
This was the last talk of the day for me. The starting point were questions like ‘Where does trust start’, “What do we need trust for?”, and “How does it work?”. Anastasiia then turned to her key subject: Keys as the carrier for trust in secure systems. She pointed out that not only the data must be protected by keys but that the keys are chunks of data, too, and therefore also must be protected, since they are subject to threats like data tempering or man in the middle attacks. That, in turn, raised the question how keys can be trusted and secure, yet be incorporated into a properly functioning system. For this, she mentioned the following aspects:
- Key generation: When and where should it happen? As close to the actual use or the storage as possible.
- Key exchange: Use a private / public key pair.
- Key storage: Protect keys in a key vault, never together with the data they protect.
- Key access: Keys should be protected from unauthorized access, but be easy to access legitimately.
- Key rotation / key lifecycle: Build support for changing algorithms and keys when needed.
- Key revocation: Make sure that compromised or outdated keys don’t work.
She then shortly mentioned key management in iOS pointing out the following:
- On-channel exchange, SSL pinning, SSL pre-keying.
- Mediated exchange through a public key infrastructure, e.g., keybase.io.
- Trusted channel exchange.
Lastly she stated that you should not store keys, but if you do, you should consider the following options to secure them:
- Obfuscate keys: Store keys as hex, replace characters, rename .cert to .mp3, combine them from separate pieces. To her, all of those are just boring.
- Encrypt keys during development, store the encrypted keys and only decrypt them before actually using them.
- Put fake keys in honepots, e.g., in the plist file or static strings.