Pet Project February ’18

Michał Smyk
Feb 12, 2018 · 8 min read

Basic assumptions

As I was responsible for technical-related things during that event (which mostly were just A/V and electricity stuff), I wanted to make life as simple as possible for my whole technical crew (after all I was their leader, and good leader tries to make his team job as easy as he can, right?) — and so the application concept was born.

  1. During previous events most of the issues were reported to me by phone, and afterwards I would call someone from the crew to fix that issue or go there myself. This application would allow us to share information about issues between each other without any problems.
  2. When nothing was happening, we were mostly chilling in our Tech-Crew room, and nobody was looking as his phone waiting for call, but there was always at least one notebook turned on then. So one additional requirement would be to make application send notification after some update to the list of issues has occured.
  3. As most of other people that we were working with are pranksters, I had expected for them to make some ‘fun reports’ just to trick us into going somewhere for pointless reason. That’s why users shouldn’t be able to to anything about their identity, they would have it set during deployment by me.
  4. I tried to minimise dependencies on other projects and libraries wherever possible.
  5. It was supposed to go live on 9th of February 2018, and work until end of event on 11th of February 2018.

First concept

I wanted to create ASP.NET WebAPI application on server-side, and deploy WPF application on computers that were in each of the rooms.

How to contain identity information?

I wanted to hardcore information about identity in code, and just deploy in each room .exe with different identity string deployed. Then I remembered that sometimes during the event we tend to replace computers that were in rooms with our laptops, and then I would have to find the proper version of application for that room once again.

Where to host it? Azure!

On the beginning I was planning to host it on my OVH server or on one of our crew members server using Docker container. As I decided that I don’t want to bother with configuration, I decided to go another way — Azure. I never did anything using Azure before, and just started learning about it during preparations for 70–486 Microsoft ASP.NET exam that I took in January. So I though — why not, this is a good chance to test it in practice!

Hello ASP.NET Core, we haven’t seen each other in some time!

As I wasn’t working with ASP.NET Core for the last one and half year, I decided to finally finish some project in it. Most of the things changed from time I tested beta/RC versions, but it wasn’t so hard to catch-up.

Notification issues

There were also problems with notifications. As my approach for notifying my crew was to play audio sound after refreshing list of issues (which would happen using SignalR after change of issue status or creation of new issue by users), it worked on notebook without any problems. Every time someone from our crew refreshed page (or had it refreshed by SignalR) we heard “Hey Listen!” from Legend of Zelda: Ocarina of Time. I was very glad when after first day of using it first reaction for hearing that sentence for everyone from crew was to look at the application. Just what I wanted!

<audio controls autoplay> <source src=”~/Navi.mp3" type=”audio/mp3"> </audio>
<audio controls autoplay>
<source src=”~/Navi.mp3" type=”audio/mp3">

What else went wrong?

One thing that I didn’t take into consideration — some users replaced computers that were set-up in room with their own notebooks, and suddenly they couldn’t use issue raporter, as they didn’t had address/credentials to access correct account. This is something that I have to somehow manage before next usage of this app.

What went right?

I deployed it, it worked, both my crew and users used it. It took me three evenings after work to finish it. I also setup my development environments on all almost all of my devices which allows to do so, so I will probably have it easy to implement some new solutions in a future if I would only have access to some of it.

Plans for the nearest future:

I plan to write another blog post about my thoughts on passing Microsoft 70–483 and 70–486 exams. And go back to posting more often that once a year.


Smyk.IT

Blog of Software Engineer from Wrocław, Poland

Michał Smyk

Written by

.NET Software developer from Poland.

Smyk.IT

Smyk.IT

Blog of Software Engineer from Wrocław, Poland