I'm not a guy you are likely to meet at a classical tech conference. I don't like to waste my time with marketing bullshit and presentations of unprepared speakers. But I do like to meet like-minded people, good conversations, and some Schnitzel and beer.
One of the rather annoying things of developing native iOS apps has always been a relatively common task: Displaying data with a varying size in UITableViews. Since iOS 8 it is easier than ever before – once you know the trick.
Some features of your app may only be useful if the device of your user is currently connected to the internet, so you can make API calls, load images or do some other stuff.
Everyone is talking about that Zuckerberg mantra "Move fast and break things" – but let's face it: It is much easier said than done.
One of the huge benefits of using Xamarin for developing cross-platform applications is clearly C#. But that often leads to bad coding practices which can put your app in jeopardy.
I consider continuous delivery a cool thing, particularly but not only in mobile app projects. It's nice to have the client see and touch new features as soon as they're ready. But sometimes it could be useful to disable those features. This is when Feature Toggles come into play.
Many people in the startup industry are talking about the ‘MVP’ – the Minimum Viable Product. But that term is useless unless you figure out what viable means to your customers.
While developing native mobile applications for iOS you generally have two options for creating (reusable) visual elements: writing them by hand or designing them visually with the Xcode Interface Builder.
People talking about Test Driven Development often split into two camps: fundamentalists, preaching no line of code should be written without a test, and deniers, refusing to use TDD at all.
I once read a nice quote which nails it and which read as follows: “It’s not the tools you use that have to be cutting-edge, it is the product you build.”