Three weeks ago the (probably) first official Developer Walk took place in Dresden, the lovely capital of Saxony in Germany – an event that should and will be repeated.
Six months ago I made a serious mistake: I replaced my beloved MacBook Air with a MacBook Pro. In the period that followed I tried to be strong, but eventually I gave up last week. Now I am running my best hardware setup ever.
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.