AWS Account setup

We deploy each of our environment (Live, QA, Dev etc.) in a separate account, which serve as member accounts to a root account in an organisational setup, where only users are configured in the root account.

In the member accounts we define roles like developer , that users from the root account can assume in these member accounts. The developer role has only the permissions it needs so developers get their job done. In addition we have the administrator role. This gives us the flexibility of only adding users to the root account and what they can do is handled via the roles in the member account — through permissions on role level.

In addition to roles all our apps are deployed in these member accounts. This is where the action is.

All apps are deployed and managed by ECS and we could have opted to just create a separate ECS cluster for each environment and work in one account only, but there is always additional stuff that may interfere with each other without you knowing. In the beginning of your cloud journey on AWS Security Groups are a bit of a magic box that take you time to understand and analysis in case of failures. Same is true for Application Load Balancer and Target Groups. So we wanted to keep all of this separate on all environments and the only real way of doing this, is through different accounts.

ECS as the hosting infrastructure

When thinking about hosting the applications there are a few options on AWS:

• EKS — managed Kubernetes
• self managed Kubernetes hosted via Kops
• ECS
• Beanstalk
• plain EC2 instances

All of them have their pros and cons for certain scenarios. We have chosen to go down the ECS route. The reasons for us were the simplicity that ECS brings to the table. The concepts are very close to docker. ECS even runs on docker. EKS from a feature perspective is very rich, but also opinionated. It brings its own concepts and implementations and as a user you need to understand them. That was too much for us in a migration scenario to chew on top.

Our opinionated and by all means uncomplete take on Kubernetes and ECS is the following.

ECS and AWS infrastructure

After all this talking let’s dive into how it actually looks like for us. All our EC2 instances that we use for our applications, run inside a Private Subnet. We run in one Region with multiple Availability Zones (AZs). All apps are always deployed in multiple AZs. Communication to the outside happens through the NAT Gateway and Internet Gateway, which both reside in the Public Subnet.

Service Registry, Discovery and Load Balancing

There is service-to-service communication. A challenge in such a scenario is that a calling service needs to know the physical address (IP + Port) of the receiving service at runtime. Considering service instances come and go and with it, its physical addresses, it is advisable to externalise the Service Discovery and Resolution. Each ECS Service has a specific DNS entry in Route 53 that points to a specific route in our internal Application Load Balancer (ALB). Route 53 resolves the DNS of the Application Load Balancer. The ALB balances the load between different instances of the same service.

This setup gives us the ability to just use a fix service name in the Spring Rest Template, which is the same across environments. When an ECS Service instance dies, this instance gets automatically removed from the ALB Target Group and the opposite when spawned.

A message from the past: In our pre-AWS times (we were on a CloudFoundry environment) we used Eureka for Service Discovery and Registry and Ribbon for client-side load-balancing from Netflix. Initially we tried using the Netflix stack, but ended up with a challenge: the Eureka server need to be reachable from your service with a fixed URL, which brings you back to the point of how to create a URL that is somehow static for one service in your environment. So while looking into solutions of making this work, we discovered we could just apply the same approach for every service and get rid of the Eureka Server all together.

Infrastructure as code

The entire infrastructure is scripted in CloudFormation across all accounts and therefore environments. Every change to any piece needs to be scripted, code reviewed through pull requests and successfully run in a deployment pipeline. Sounds tedious and long, the opposite is true.

Infrastructure is not a monolith. There are cross-cutting components like VPC and AZs, but there are also application specific infrastructure parts in the name of ECS Service, Route53 entries and ALB Listener Routes. We split into common and application-specific parts. The common infrastructure lives in its own git repository and has a dedicated pipeline to deploy it. Every app has an app-specific CloudFormation stack, which gets deployed during the application deployment. Usually we deploy an infrastructure change before we deploy the app that may rely on this infrastructure. Pro tip: make small changes to the infrastructure with CloudFormation. Big changes take long.

In the future we will extract roles and permissions into its own git repository to deploy it in isolation. We ran into a few issues where we weren’t able to rollback successfully after a failed infrastructure deployment, because the permissions got removed before the infrastructure components got removed again and we ended in a deadlock.

A word on carbon emissions

Data Centers take a big share in the world wide energy consumption — currently 2% of the world's electricity. This puts data centers at the current energy consumption levels of the aviation industry and projected to exceed aviation by a factor of 4-5 by 2024. Comparisons of different cloud provider should therefore include its carbon emissions also. For AWS this depends on the region you run in. We run in the 100% sustainable region Frankfurt.

How does your AWS deployment look like? Do you use ECS, EKS, beanstalk or something else? How do you deploy your infrastructure as code? Through multiple pipelines or just one? How do you solve Service Registry and Discovery?

This blog post is part of the collaboration of Netlight Munich and eeMobility in the emerging field of electric charging. Together, we build a system to enable corporate fleets to use renewable energy and pioneer in the field of smart charging.

Spring Boot Java Microservices on AWS ECS to charge your electric car | Part 2 was originally published in Make It New on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our team is going through a tough and fun period at the moment. The team is a scrum team at ee-mobility that works together with netlight consultants. We migrate from a CloudFoundry environment, where a dedicated team managed for us all the infrastructure components and we were able to focus for the last 2 years on just putting out feature after feature. Now our childhood is over and we tap into the period of adolescence. So now we are migrating all of our services to AWS to run them all ourselves.

But let’s backup a bit and allow me to give you some context what we are building and why we are building it the way we did.

Why are we writing this blog post?

During the preparation of the move we talked to people, read blog post after blog post, asked questions on stack overflow and github. What surprised us the most was the vast variety of different solutions. There wasn’t a “This is how you do it. Full stop.” We haven’t gotten anything super special that makes our solution difficult to migrate. We found a world of EKS, Fargate, Beanstalk, EC2, ECS, Docker Swarm, Jenkins, Bitbucket pipelines, Kops and many more. The team was overwhelmed. So this post is for YOU, mighty reader that looks for some inspiration on what, why and how we picked our stack.

What is our technology stack?

We have roughly 15 microservices that together forms a distributed application. Every application is a Spring Boot 1.5 Java 8 application. We use gradle and jenkins.

What is the domain?

Our platform allows our customers to charge their electric cars on charging stations. It is like a subscription service where we provide access to these stations for a monthly fee.

A big bunch of stations are directly connected to our backend via Rest and Websocket and constantly sends data and commands. In addition there is a React App to support back office tasks like Customer Service, Operations of stations and contract management.

Our customers interact with the solution through a Swift iOS or Kotlin Android app. We have more or less three features that we focus on:

• you charge your car at home,
• at a station at your work, which your employer provides and
• on public charging stations.

Domain Driven Design

From an architecture perspective we made heavy use of Domain Driven Design as a toolset for our application and service design. It helps both for designing the inners of an application (think class design, domain, root aggregates, transaction boundaries and design, repository, service patterns) as well as the entire distributed application (think ubiquitous language, bounded context) so called strategic design.

One service per bounded context

A gut feeling in the early days made us decide to favour many small services rather than few bigger ones. 2 years later we have roughly 15 services, where each service is also a separate deployment unit. Each service encapsulates one bounded context.

Our domain seemed very diverse in the beginning and talking to our domain experts made us belief we had to deliver functionality in many different areas very early, e.g. from directly connecting to charging stations, over contract management to payment and reporting; hence we favoured smaller services that are faster redeployed after a change, easy to understand and the different domains have no opportunity to tangle too much together. Good fences make good neighbours. Different git repositories are really good fences! Requiring this extra HTTP call, makes a developer think twice if this domain entity is part of this bounded context or the other.

A Bounded Context is a boundary for the meaning of a specific domain. In our industry the Charging Station is a very fundamental and central piece that can be found to some extend in many Domain Models in our application, but each Domain defines the meaning of a Charging Station for itself.

We introduced Domain Sketching Workshops right from the beginning. Today you would probably call them Event Storming workshops. The entire (!) team comes together, draws on a whiteboard what the domain entities are and to which bounded context they belong. We are also never afraid of changing a bounded context and moving entities from one domain to another.

Our system has among others, the following Bounded Contexts

Example from the real world

Once the system has reached the point of multiple Bounded Contexts, one challenge arrives, which is not talked about so much and patterns and practices haven’t been shared enough in my perspective: repeating entities in different domains or one concept from the real world has implication on multiple domains.

In a monolith system the core entities tend to grow into enormous classes and ecosystems around them. Change is difficult, feature complexity is high, but creating it in the first place is relative simple, because everything that belongs to the customer domain gets put next to the customer.

A concrete example we struggled with, is the concept of a charging process. The charging process as a concept exists for the driver that sees his current charging process in the app, the Chargepoint Operator uses it to manage the interactions with the physical station and in terms of account and billing it represents the amount and time of a specific charge process. So two domains (Chargepoint Operator and Customer) are involved and know of this concept; both with a different angle on the same underlying concept. There are many ways to handle this, but first it is important to understand that both Bounded Context need to implement their interpretation of the concept. For a young team this may feel repetitive and is hostile to the solution. In this case we even named the concept ‘Session’ in both Domains. Which I, in hindsight, would advise against. Try to find a name that exactly describe what it does or what it is for; avoid general vacuous terms. It leads to conversations like “Do you mean the session in the Customer or in the Chargepoint?”

Ubiquitous language

In the domain of electric charging there isn’t a universal ubiquitous language yet; it is not mature enough. It starts at a simple entity: the thing you use to charge your car; this wall box, charging unit, charge pole, charging station, charging spot, controller, you name it. Every application and backend we integrated brought their own language. Domain experts use their favourite word too. We set out to defend our very own language! But first we had to define it, so we started with Domain and Bounded Context sessions on the whiteboard until we agreed on a language. For us these are charging stations that have multiple spots just to give you one example.

Example from the real world

With that said how do you defend this language inside your software? How do you make sure that another language from another application doesn’t creep into your system and pollutes it when you consume it. Again good fences make good neighbours we added a service in between that does nothing else, but translating from the language of the consumed api/application and our platform. We called them adapters and they are separate services in our landscape that each live in their own git repository and get deployed as independent deployment units. This may sound over engineered and unnecessary, but so far we are happy with the solution. We successfully defended our language!

The Chargepoint domain uses the term Charging Station, which can have multiple spots and each spot has a different plug.

An external service uses the word Chargepoint for a single spot, which has specific ConnectorTypes and doesn’t know about the physical concept of a charging station. The adapter serves as a Anti-corruption layer to our Chargepoint domain.

Domain entities, working with an ORMapper and what objects do you expose in your RestController?

By now you probably get the feeling that our team is a little obsessed with design principles and that we like to stick to them. Here is another one for your reading pleasure. We have at least 3 different object types; the objects that are retrieved from the database via hibernate are DataAccessObjects, the Domain is obviously built around Domain Entities, Events and Services and the data structure exposed via RestControllers are DataTransferObjects. Mapping happens via ModelMapper and the translation is most of the time straight forward without much logic. We do this, because we didn’t want to have huge classes that are full of ORMapper and JSON Serialisation annotation in one file. It helps to keep the API stable. A change in the storing structure for example should not have any impact on the API, even though it means repetitive mapping at run time and more code written during development, but complexity in this activity is low.

After this introduction into our domain, design activities and design choices, in another post we’ll share more of our journey towards AWS ECS. Stay tuned.

We are interested in your domain driven design challenges and eureka moments. Please share them with us in the comments below.

This blog post is part of the collaboration of Netlight Munich and eeMobility in the emerging field of electric charging. Together, we build a system to enable corporate fleets to use renewable energy and pioneer in the field of smart charging.

Electric charging powered by microservices in the cloud was originally published in Make It New on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’m a Manager at Netlight and barely know what that actually means. We don’t have a command and control hierarchy, which would make things easier to understand and fit in. I would know that everyone in my team would listen to me, try to understand what I want to achieve and try to do it. My boss would probably be a Senior Manager and I’d be responsible for my entire team and their deliveries. This is not my world. I have no team, I have no boss, I’m not responsible for anything in particular, but for a lot in general. In contrast I’m a mentor for some of my colleagues, I interview new potential Netlighter, I take responsibility for certain delivery teams, I mentor and coach colleagues to drive change at Netlight in general. I work at a self-managed organisation.

In the round here in Hälsingegatan in Stockholm, we begin by introducing ourself on stage. I feel the anxiety. Am I good enough to be part of this group? The coaches make me take the mask off and I hope the real me is not too disappointing for the group. We do speech training, improvisation exercises and finally a few speeches in the spotlight on stage. We are supposed to be authentic, fail often, be vulnerable. All of this requires trust in the group, which everyone builds up during the course. We talk about our own personality traits from Myers-Brigg; how we can benefit from them and how they stay in our way in other scenarios. Everyone in the group is different.

Fast forward one year, we are in Stockholm, this time in Birger Jarlsgatan at our office. The group is again together after spending two days in Munich with a Oktoberfest visit and a long weekend including a ski trip in Oslo over the course of 2017. My personal goal for 2017 was to be 100 percent at Netlight; not in a workaholic way of working 80hours a week, but rather being authentic and the true me without a professional mask. It has to do with anxiety, not being good enough, social pressure of not fitting in. It creates stress and effort to be someone else at work — even if it is only the last 10 percent.

Over the last 12 months I got to know all the others quite well and we shared many successes and failures at work and at home, all the struggles we have and all the changes we are working on. I explain how I got distant from the organisation when I focused on one assignment, how this frustrated me over a longer period of time and how happy I became when I got closer again. I’m thankful that we spent so much time together, that I was able to see that many others share my anxiety and fear as well, that it is quite normal even in an environment like consulting where the right answers and results are asked for. This is a big learning for me personally.

I’m a Manager at Netlight and I’m not alone. We take decisions in the entire organisation by the help of the advice process which focuses a lot on listening, trusting in others to ask for advice, leaning in and coaching and mentoring everyone around you — no matter where you are in the organisation. Sometimes it is a bumpy ride to become better in this, but I love the responsibility and freedom to apply common sense through empathy and trust from others in me.

Did you like the idea?

Let us know by clapping on the 👏 below. It will make us feel all warm and fuzzy!

I don’t have all the answers and why I’m not afraid was originally published in Make It New on Medium, where people are continuing the conversation by highlighting and responding to this story.

I love talking to people, sharing knowledge and experiences, and basically just having a great time. The time I spend at meetups, user groups and conferences getting to know other people in similar and completely different situations as I am in at the moment, makes me happy. It’s like a hobby and I’m grateful that my job goes so nicely hand in hand with this hobby.

After the explosion of meetups in recent years I got super excited. Meetups changed my view on the communities around me; it made them visible to me. Before we had a few rather static user groups, but now we have the flourishing meetups all over the place. I loved them so much, a couple of people and me decided in 2013 to kick off one ourselves — The Munich Windows Phone App Creators. A community for everyone interested in Windows Phone and the whole app ecosystem around it. We had apps in the store ourself and wanted to find likeminded people to share experiences, getting better at building apps, and ultimately of course ruling the world.

Well, it turns out, the topic was a bit narrow, we met regularly, but ran out of topics to talk about after 1 year. Some of the drive was gone, because we couldn’t attract more people to drive the meetup and secondly because we ourself lost a bit the interest too, me anyway.

It’s now a a couple of months, since I buried the meetup finally after months of hibernation and it feels great! The funeral was silent and no complain about the funeral ceremony has made it my way.

Why did I kill it? Honestly, because I feel responsible for a community and all the members and I wasn’t able to drive it anymore. Of course it’s nice for my ego to see that I’m the organizer. My interest is gone and I’m focusing on other topics these days. In my opinion that is a good thing and we should do this more often. I see so many overlapping meetups in the same area and meetups with just no meetups happening in 12 months. It makes me sad. The communities get fragmented, which leads to meetups having too little attraction and eventually die. Communities are networks and networks need to have a critical mass to generate value for every participant. Communities live and breath from active participation and a sense of steadiness in terms of regular meetings. When communities compete over members and speakers all communities suffer.

In the Munich area is another meetup, which focus on Mobile Development and another focusing on .net and Microsoft technologies and another on Xamarin. All great candidates for my community members to wander off to; including myself.

Take away: Bury communities, when they are dead. It will actually help the other communities to get more traction and value for their members.

Originally published at www.dersteve.com on March 9, 2016.

The funeral of my community was lovely was originally published in der Steve on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 1: How hard it is to switch to Universal Apps

In this post I’ll cover the following topics

• We’ll start from scratch!
• Adding MVVMLight
• Folder structure
• ViewModelLocator
• MainView + MainViewModel
• ExpenseDetailsView + ExpenseDetailsViewModel
• Navigation
• IoC setup in dedicated App class

Start from scratch

The starting point after looking at what I had — a Windows Phone app called traXs with all the different components and aspects — was to see how to create a universal app and what is needed. I won’t get into How-to create a universal app. There are enough resources out there that show you how to create a new UA project in Visual Studio.

There is no migration button. That is something that feels wired at first. You would expect some sort of clear upgrade path to universal apps, but there isn’t. So you need to create a completely new project/solution in visual studio and step by step migrate all the different pieces over to the new project. That was for me a bit of a downer, but after a couple of days that put me into a great position: now is the time to change every design and architecture mistake I did during the last years.

First of all I wanted to get the Main page up and running with as little information as possible. Keep it simple. At the moment no need for persisting data, because I realised there are various options available for persisting data in Universal Apps (UA) and I wanted to keep my current speed and not dig into one topic too deep and get lost.

Architecture + adding mvvmlight

For the first page we need the View, ViewModel and Model design/architecture/pattern in place first. I really like the approach of separating the concerns of a view, the model and a dedicated viewmodel tailored for each view.

I want to stick with mvvmlight — as a library to lay out the ground and make that design model a lot easier to use — because I used it before and it was always nice to me. Just go to the nuget package manager and search for mvvmlight from Laurent Bugnion (@LBugnion). The first thing I noticed was that you need to add the package for both projects (the phone and win8) in order to be able to use the library in the shared project. I’ll come back later why I need to use it there. Only when you reference it in both projects you can use it in the shared one.

Folder structure

I could talk for hours about how to structure your application, but let me show an early snapshot of the folder structure. For some people that says more than 1000 words.

In the shared project I place all my ViewModels and Models (in the Repository folder). The Views are platform specific as there is so much size and features differences, therefore they are in the platform projects — see the MainPage.xaml and ExpenseDetails.xaml in the Windows Phone project.

ViewModelLocator

The ViewModelLocator is to some extend the connection between the View and the ViewModel. For now I keep it super simple, I only want to display the MainView and navigate from that view to the details page of a particular expense when the user clicks on an expense item in the list.

The following wireframe includes both screens. On the left the MainView with a list of expenses and on the right the details view for one individual expense.

In this scenario I have exactly one instance of the MainViewModel (MVM) and one of the ExpenseDetailsViewModel (EDVM). When the user taps on an expense the MainViewlModel sends a message (more on that later) to the ExpenseDetailsViewModel — containing the tapped on Expense-Entity object — informing the ExpenseDetailsViewModel about the expense to display. The MainView has its DataContext set to the MainViewModel property of the ViewModelLocator and the ExpenseDetailsView has its DataContext set to the ExpenseDetailsViewModel.

Here is the ViewModelLocator implementation.

It’s just a matter of setting up the ViewModelLocator as a static resource like this in the App.xaml file in the Shared Project.

And here is the final piece that connects the View with the ViewModel through the ViewModelLocator. That is pretty similar to the Windows Phone approach except in which projects these components now sit.

Navigation

I rushed over one important part of our current setup: the navigation between the MainView and the ExpenseDetailsView. Earlier I mentioned we “send a message to the EDVM from the MVM”. That is pretty much what happens. The message contains the selected expense object — as a complete object and not just the id or any other identifier. Sending a message is a concept mvvmlight brings to the table. It has some apis that allows you to broadcast messages, register for certain messages and receive them. In our case the setup is as follows:

• The ExpenseDetailsViewModel registers to receiver a message with the ‘ExpenseDetails’ token and associates an action (or method) that takes care of updating the properties on the EDVM accordingly.
• When the user taps an expense item a command in the MainViewModel gets triggered that sends a message to the MessageBroker with the ‘ExpenseDetails’ token and the expense item.
• In the MainViewlModel Command we navigate to the EDVM page.
• The MessageBroker, that comes with mvvmlight routes the message to all registered recipients and executes all associated actions.
• The action inside EDVM gets executed and updates it’s state accordingly to the selected expense item.

Message Registration

To register for all messages for the given token ‘ExpenseDetails’ in the EDVM do the following inside the constructor. It already contains the action to handle the update.

Send message and navigate

Sending a message involves the mvvmlight apis for the MessageBroker. You give a token and an object as the message. The token is used to limit to number of receiver to only these want to get the message.

The Navigation is a bit bit complicated with the 3 projects for me at the moment. Maybe I find a better approach along the way of migrating the app, but for now I’ll stick to the approach of having a dedicated NavigationService implementation of the INavigationService interface for each platform (Windows and Windows Phone). Since the ViewModels where the navigation happens sits inside the shared project we only talk to the INavigationService interface. How the correct implementation gets pulled into the ViewModel will be covered later in the post. Stay tuned!

Action in receiving EDVM

The action that receives the messages and is responsible for updating the state of the EDVM does only as little as that.

i => this.Item = i

This sets the Item to the provided, selected item. All the bindings in the ExpenseDetailsView work with the this.Item property.

NavigationService

The NavigationService abstracts all navigation logic away and give us the freedom of handling and invoking the underlying platform apis for navigation differently per platform. The INavigationService is inside the shared project and each implementation sits inside the platform projects.

The implementation for the Windows Phone platform looks as follows and is in the Windws Phone project.

The whole workflow looks like this. My artistic capabilities are very limited as you can see.

MV = MainView
MVM = MainViewModel
MB = MessageBroker from mvvmlight
EVM = ExpenseDetailsViewModel
EDV = ExpenseDetailsView

IoC setup in dedicated App class

We are already using the IoC container from mvvmlight inside the ViewModelLocator and inside the MainViewModel we use the NavigationService property that looks like this:

public INavigationService NavigationService { get; set; }

and gets instantiated like this in the MVM constructor:

this.NavigationService = SimpleIoc.Default.GetInstance<INavigationService>();

The question is now how and where do we setup the IoC container to know how to constructor an instance of an implementation, which is platform specific?

The answer is simple: the App class! But hang on, the App class is platform agnostic meaning it sits inside the shared project and doesn’t know about platform specifics. Therefore we add a partial App class inside the platform specific project, implement an Init() method make all IoC setup, which is platform specific there like this.

In the App class inside the shared project add that line to the constructor:

At the moment I haven’t added any Windows specific App class therefore I used pre-compiler statements to only make the call when compiling for Windows Phone.

Originally published at www.dersteve.com on September 2, 2014.

How hard it is to switch to Universal Apps #2 was originally published in der Steve on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before we had files being linked from different projects, which I already disliked when I started developing asp.net back in 2002. It never really worked and when it worked it was for hope than believe from my side. We also have Portable Class Libraries (PCL), which I believe will be part of the journey going forward. Especially when you talk about frameworks and libraries — not so much though in the context of the application development itself.

Universal Apps say they solve some of the issues people are having at the moment, when they want to build Windows and Windows Phone apps with the promised benefit being able to ship the exact same products for XBox somehow. I’m pretty sure there will also be a path to WPF somewhere in the future, but that’s just my hope at the moment.

Long story short, I started with Windows Phone 7 development back in 2012, switched to Windows Phone 8 only lately and am now looking at ways to enhance the customer experience, increase the development process and if feasible bring the app to the Windows store as well. Universal Apps seem to be a nice fit for these requirements, although most of my motivation is driven by pure excitement of bringing the app to the Windows Store, where I see most of the opportunities right now. But that’s a whole other discussion we should have in a future post. My app is called traXs and you can find it in the Windows Phone Store.

I’ll try to sketch out my current state as I’ll walk you through the whole migration process in the upcoming posts on the topic.

Where are we and which frameworks do we use?

• Windows Phone 8
• Microsoft Ad Control — display an ad
• Telerik UI Controls for Windows Phone — a long list of controls
• Google Analytics Tracker for Windows Phone 8 from Maarten Balliauw
• MVVMlight Toolkit
• Coding4Fun Toolkit — Bindable Application Bar
• Silverlight Toolkit for Windows Phone — ContextMenu on list items

• SQL CE Database
• Camera Capture Task
• MarketplaceDetail and MarketplaceReview Task
• ValueConverter that uses CultureInfo

Architecture of the App

• Repositories including a DataContext for Linq functionalities to work against the SQL CE database
• Model / Entities with DataAnnotations that depend heavily on SQL CE datacontext
• ServiceLayer that orchestrate Repositories and other Services, like integration with Foursquare, GeolocationAPI, Exporting to Skydrive etc.
• ViewModels, which retrieve Entities from the Repository and convert entities to viewmodels, which in turn rely heavily on the mvvmlight framework, since they all inherit from ViewModelBase.

You see I have a real app that is tied to specific frameworks, libraries, platform features and a certain architecture style. All the frameworks need not only to be updated to newer versions, but to use completely rewritten frameworks and libraries. For some I’ll find new versions compatible with universal apps; for some I’ll find platform features that’ll offer the same functionality; and for some I’ll need to either find replacements or implement them myself.

In the next post I’ll start the “migration” and walk through how much it is a migration vs a complete rewrite. Just as a cliffhanger: it leans more toward a rewrite, but more on that next week.

Originally published at www.dersteve.com on August 26, 2014.

How hard it is to switch to Universal Apps #1 was originally published in der Steve on Medium, where people are continuing the conversation by highlighting and responding to this story.

Giving an answer to that question was always hard for me. Is it because my employers paid for dedicated external coaches coming into the company to talk about a specific topic — which I hate and don’t believe in by the way? No. Is it because I spend all my nights and weekends on the computer reading about and trying out every new pickanoun.js? [1] Are you kidding? Not at all. When I’m off, I’m off. Do I go to many conferences? My last conference was TechEd New Zealand in Auckland in 2008. That’s 6 years ago.

Last week I made a calculation and got the answer: Most of it comes from using my time efficient when commuting and listening to podcasts, where I learn about new stuff.

That’s an (incomplete) list of subscribed podcasts:

• .Net Rocks with Richard Campbell and Carl Franklin
• Hanselminutes with Scott Hanselman
• Ted Talks
• The Stack Exchange Podcast with Joel Spolsky
• Herding Code with Scott Allen (and more)
• Run as Radio with Richard Campbell
• The Tablet Show with R. Campbell and C. Franklin

In summer 2008 I started listening to podcasts while commuting in Auckland to my office. One-way was about 30min.

If you make the calculation, I listened to almost all .Net Rocks, Hanselminutes and Tablet Show Podcasts since the beginning of 2008 and let’s say half of RunAsRadio.

• .Net Rocks since 2008: 700 episodes á 60min = 700hs
• The Table Show: 130 episodes á 30min = 65hs
• Hanselminutes since 2008: 320 episodes á 30min = 160hs
• RunAsRadio since 2008: 300 episodes á 30min = 150hs

That is an astonishing 1075hs or 134 working days in 6 years, which accounts for 22 days per year. I got 180hs of training every year for free just because I use my ‘dead time’ consciously.

[1] Credit goes to Scott Hanselman for this term.

Originally published at www.dersteve.com on August 10, 2014.

Wow, now I know how to stay up to date with all the new stuff! was originally published in der Steve on Medium, where people are continuing the conversation by highlighting and responding to this story.

In September 2013 we had a meetup, where some of us shared their experience with building an app, putting it into the store, take care of customer, interact with users, maintain a solid number of good reviews, tried different ways of monetization and improved their apps with endless new versions.

Here are some of the apps, which are built by the Munich community!

Simple Timesheet

Keep track of your work schedule with Simple Timesheet. The tool provides an easy to use interface for entering your worked hours on multiple projects.

Till decided to go with 2 dedicated apps; a free and a ‘pro’ — paid app. The decision date back to the time of Windows Phone 7, when Windows Phone did not support in-app purchases yet. It was the only way, back than, to get a solid and broad base without making people pay up-front. That has changed and you can now add in-app purchases to enable users to pay for certain features they want to use. That is the way to go forward for Till. The overhead of 2 apps is just to much and you also share reviews between 2 apps, leaving each app with only half the reviews it could get.

Find the app in the store

Fahr in München

The app for public transportation in the Munich area including S-Bahn, U-Bahn, Bus and Tram. The design is beautifull and the UX intuitive to use. It is decorated with the official logo of the public transport in Munich. However it was created by @leitning as a personal project in his spare time.

The beginning was a bit rough for @leitning as there was no official api to talk to in order to get the information he needed for the app to work. At some point it even seemed as he had to remove the app from the store, since it’s not an official app. All those problems are solved now, the officials are working now closely with him.

The lessons learned from this project, in my point of view is, to keep trying even in areas where you think there must be someone building this already. In my opinion it’s the best app for public transport in Munich across all platforms. I’m not alone. There are 610 reviewers for the German version of the app, which gave the app an average rating of 4,5 stars. That is pretty awesome.

Find the app in the store

WPArea.de

By far one of the most used, downloaded and reviewed app in the German store and in my very own list here.

You could say it’s an app for a news site wparea.de You could say it’s an experiment that took off. You could say it’s going to ruin the web page as it bypasses all traffic to the app instead of the news site. You could say it’s what keeps the site alive and people so addictive to it.

It’s all of the above. However it’s also a great story to tell.

It started out as a project at uni and turned into something that even produces some pennies even though they are super tiny and don’t even cover server costs or lunch.

The app itself now let user read the stories of the site, has nice live tile to display latest news and notification for new stories coming in. To cover costs a bit, there are ads in the app as well as an in-app purchase to remove all ads for ever.

Find the app in the store

track my life

How much time do I spend at Work? How long do I stay there in the end? Where do I spend most of my time?

Track my Life answers these and many more questions for you.

Find the app in the store

traXs — Expenses *

traXs is a fast and comprehensive expense tracking app. Nothing more, nothing less. It tries to stay focused. Keep the user interface super simple and listen to customer.

The app provides various communication channels between the user and me, so I can react if something goes wrong or people are looking for features thay can’t find.

Find the app in the store

* Disclaimer: I’m biased because I built traXs.

Originally published at www.dersteve.com on March 24, 2014.

Made in Munich with Love — Windows Phone Apps made in Munich was originally published in der Steve on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the beginning of 2013 I was already heavily involded in the Windows Phone Platform. At Avanade, my employer at the time, I was part of a worldwide mobility export team, had my own app in the store, had developed apps professionaly, was talking a lot about the platform at community meetups and evangalised at each and every event. While meeting people I figured out a common pattern:

• Nobody was making any money with their app
• Everybody is a developer
• Everybody moans about their lack of design skills
• Each and every app had a horrible design
• Nobody had a monetization strategy

Disclaimer: my apps fullfilled all of the above — at the time

It was time to change something and I was not alone.

There seem to be a reasonable amount of passionated developers in Munich willing to invest time and effort to build great apps for the Windows Phone platform.

Bring people together and magic will happen

There was a common pattern been repeated every time I sat down with someone, be at in person or on the web:

• I always learned something
• Got inspired and worked even more motivated
• All my apps improved a lot
• It was hard to admit my lack of experience in specific areas (business strategy, design, app marketing, just to name a few)

At the beginning of 2013 I wasn’t alone anymore. I met @leitning and @alexderekrein. We all decided it was time to bring people together, to achieve together and to learn together. These were — and still are — our main drivers for motiviation.

Babysteps in the beginning

The first year can be summarized shortly:

• A couple of skype calls
• Create a meetup.com group
• Invite people and talk to people about the group
• Meet regularly — every month

Yet another group of xyz developers? Nah!

There is a very active and rather large .net user group here in Munich. We want to form a distinct and focused group of people, who wants to create apps. This includes people with great business ideas, knowledge about app marketing, mobile strategies, designer and developer. The community wants a stage to talk about all of these, and not only development related topics.

Where are we now?

It’s the beginning of 2014, almost 1 year after we first talked about a group of Windows Phone App Creators and we had 4 meetups, 45 App Creators are part of the commmunity and we have a couple of very good apps being developed by people of the community. A lot of experience is been shared.

I’m really looking forward what 2014 brings us. Be part of it and join the group! Give something to get something back. It’s amazing how much you gain by participating in the community. You can shape 2014 and the community.

Make 2014 be your year!

@derSteve

Originally published at www.dersteve.com on January 13, 2014.

2013 — What a year for the Munich Windows Phone Community #MucWPDev was originally published in der Steve on Medium, where people are continuing the conversation by highlighting and responding to this story.

On iOS it all looks a bit brighter. “Notification marker” are displayed regardless of the icon size, although we have to admit there is only one size on iOS anyway. On the other hand that makes the story easier. A consumer does not need to know that an app can only show some sort of news/notification/update when it is pinned as a tile to the home screen. Do you get the idea? On iOS you can always tell by looking at the App Store icon if there are updates available. On Windows Phone you need to have the Marketplace App pinned to the home screen.

‘How can we fix that?’ you may ask.

We can improve the discoverability of available updates for actual users of your app through actions a developer can take when the app starts. All it needs is to check somehow if a newer version of the app is available, preferably when the app starts. If a newer version is available the user should be asked if he wants to go straight to the marketplace to obtain the update.
One place to check for the latest version is a plain text file stored somewhere on the interwebs that holds the current version number to check against. You may ask where to store that file. Well the easiest and cheapest way is a Windows Azure Web Site. Remember you get up to 10 web sites for free. A perfect place to store just a single txt file.

Setup a Web Site on Windows Azure

Sign up for a pay-as-you-go subscription on Windows Azure. That plan allows you to create 10 web sites for free. As this web site will only contain a single file, we don’t need any database setup.

On the details –> dashboard page for that just created web site, you’ll find the ftp hostname. For most users that use that tool for the first time, it is usually necessary to reset the deployment credentials in order to create a deployment / ftp user. Just click on the “Reset deployment credentials” and choose a username and password. Those are not related to your azure account.
In order to upload a file to the web site, open your ftp tool of choice (I use filezilla), enter the ftp hostname as server and your deployment / ftp user and password accordingly. Create a version.txt file that contains just the latest version number of your app and put that under root in order to access it under [yourwebsitename].azurewebsites.net/version.txt. Try in a browser to see if the file is reachable.

Check for the latest version from your app

As you’ve now setup an accessible file that contains just the latest version number as plain text, it’s time to check from your application to see if the currently running app is the latest version. To make things easy enough, I’ve created a component called “UpdateReminder” that you can use in your app that does exactly that. It’s open source and on GitHub. For ease of use I’ve created a nuget Package that you can pull into your app from nuget by the name WPUpdateReminder.
What it basically does, is retrieving a file from a specified location on the web and check whether the content is the same as a provided string. If they differ it’ll ask the user to go straight to the app page in the marketplace to update the app or dismiss the dialog. To avoid to have too much traffic on the site and bothering the user too much, you can specify after how many app usages it rechecks for a new version.

The setup is a peace of cake and only requires a couple of lines of code in your Main page.

Take aways

• Code to look at and grab on GitHub
• Grab the package from nuget and use in your app today

Originally published at www.dersteve.com on March 13, 2013.

Checking for a new version from your Windows Phone 8 App with Azure Web Sites was originally published in der Steve on Medium, where people are continuing the conversation by highlighting and responding to this story.