Quick thoughts after Daj Sie Poznac 2016 finals

So we’re past ‘Daj sie poznac 2016’ finals and I feel a lot more pumped for further activities than I thought I would be. Competition was great but the finals were even greater. The amount of positive energy and interesting, really diverse topics that were presented made me really happy that I could be part of it. Kudos to the winner of competition, Piotr Gankiewicz and his Warden. Amazing project.
As for my current developer activity in web, Graphinder will currently be on hold, yet I’ve decided to try some new stuff and write my very first JavaScript library. You’ll also see me maybe not much more frequently but definitely in much more places around the web.


More of me in web

I feel quite guilty that I did not do my best to promote Graphinder and my blog per se in recent competition, therefore you’ll see me more and more in web. I’ve decided to share more and ‘attend’ more. As for a nearby future, you’ll hear me in upcoming episode of DevReview hosted by Dariusz Pawlukiewicz @ Forever F[r]ame. I hope you’ll like it!


New project: Selectibles.js

When working with plain ASP.NET MVC I’ve found it to be pain in the ass to use libraries like Select2 and Selectize.
They were often incompatible with jQuery (which I’m not a biggest fan tbh) versions I’ve used and I needed to juggle with them around just to make things (at least) work. What’s more I felt that even when they had many options, doing stuff my way was quite… dodgy.

Therefore, here it comes. My attempt for selectable controls for web.
I’m going to start with basic functionalities that will mimic Select2 from it greater days (ie. when I had 0 problems working with it).
Then, I’ll probably move on to some other controls that would be cool to have but optional to bundle (!).
I would also like to make sure the library does not need jQuery at all. It’s about time for web to move on I guess.

If you want to follow up with the project, it will build up on GitHub:

Graphinder – Quick summary and what next


As Daj Się Poznać 2016 is over, I’d like to share what I have learned, what is current state of Graphinder and what will come next for this project (as it’s not over yet!).


What I’ve learned

Technologies and design concepts

I’ve experimented with many concepts, frameworks and libraries that I wanted to potentially use in my project. Some of them have been already incorporated in project, some of them will be incorporated in nearby future and some of them were left out as decisions had to be made.
I was quite new to Reactive Extensions that I’ve already used in my project and will use even more in nearby future. As I’ve moved on to a very new approach for me – that is – microservices design, I’ve also learned a lot about Actor Model and frameworks based on it, ie. Akka.NET and Microsoft Orleans. As Orleans got my love for now, it will be used in Gateway.Api soon.
Finally, I’ve reached a place in my self development where I feel confident enough to embrace Test Driven Development, that I’ve also embraced during this project.

Soft skills and self development

Although it seems it wasn’t a case for every competitor in Daj sie poznac, I felt obliged to share my progress on both blog and Github.
I’ve enforced a week discipline and managed to both post twice a week and commit multiple times a week to the project.
What I’ve also learned is that none of us is bulletproof and creating a project after hours is a tough task from both social, family and physical point of view. Sometimes, I had to let go to get some rest, charge batteries and spend time with family but overall, I think the result came out great. 😉

Skills I have refreshed

As a developer with experience in ASP.NET stack but working currently in game developement in Unity3D environment, I’ve also managed to refresh some of the web stack skills, mainly ASP.NET WebAPI skillset, some of the web design concepts and Azure deployment and configuration concepts for web applications.


Current state of project

What has been completed

I’ve managed to complete two algorithms (Simulated Annealing and Genetic Algorithm) that work on one optimization problem (Minimum Vertex Cover), reporting reactively with Rx.Net on every progress update.
Completed solution finding gets persisted using Entity Framework to Sql Server, where I’ve embraced CQRS approach of commands and queries instead of Repository pattern.
There’s also basic mechanism for registering, connecting and delegating work to solution finding Web API instances in Algorithms service context from Gateway, yet there’s still much work to come.

What’s still to come

Well, actually the front end of application is.. well.. still to come. 😓
Also gateway is not fully functional (misses few administration and business concepts) and Orleans silo is waiting for deployment and configuration for progress report to SignalR hubs.

As for the rest, well… Let the code defend itself:


What’s next?

The project will be on hold until holidays will come. I’ve been quite busy with other projects and everyday life, so both gateway fixes and frontend implementation will need to wait. All I can promise is that project will not end with Daj sie poznac and it will go on as my playground for improving both architecture design and coding skills for upcoming future.


And, in the end, congratulations to all of the competitors that made it to the end. Good luck! 👍

Graphinder – Resources planning on Azure


As promised in previous post about application architecture, I’d like to share few words on my (moment of hesitation here) journey with resource planning on Azure. We’ll play around with network configuration for our environment, define application and development endpoints and juggle with possible service plans to meet our needs.
Oh, I’d like to mention that I’m gonna show things in old (https://manage.windowsazure.com) Azure portal as not everything is possible in new one (shame, because I love the direction MSFT is push it). ☁️


Network planning on Azure

Since we want to run quite a few microservices around with possibly lowest overhead possible (authenticating between services left out too if possible), planning a virtual network for our environment would be a good place to start.
Let’s think of a simple network that would suit our needs:

Azure network diagram

Our points of interests here would be:

  • Virtual machines – hosts for our applications; even if we’re running App Service on Azure, it’s still a virtual machine so I won’t differentiate here
  • Endpoints – actual ports opened either internally in virtual network or outside, through VM public address
  • VPN gateway – point of accessing virtual network and operating inside of it while connecting from outside


Creating virtual network

As I’ve had lot of trouble with configuring VPN gateway on new portal, I will show most of deployment on old portal located @ https://manage.windowsazure.com.
Let’s choose ‘Networks’ from left-hand menu, then create New from bottom menu and go with Custom Create.
Name the network, choose the region and on a next screen make sure to mark Configure a point-to-site VPN:

Point-to-Site VPN

Few next screens will guide you with VPN configuration that is quite straightforward, so I won’t go through it.
In case you have trouble, Cheryl McGuire got this covered on MSFT article Configure a Point-to-Site VPN connection to a VNet using the classic portal.

Provisioning of network along with VPN gateway may take up to 1h (was my case), so you need to have patience. 😥


Creating virtual machines

Whether its Windows Server or Linux machine you’re aiming to deploy on Azure, it’s important to put it in a virtual network we’ve created.
Since its impossible to do this later on, make sure you did not skip this part. On a Create a virtual machine -> Virtual machine configuration part, there is a dropdown for selecting a region for your virtual machine:

Virtual Machine to Virtual network

It’s easy to miss that you need to actually choose previously created virtual network here, so that VM would belong to it.
On a same screen you will also have a possibility to define endpoints for your virtual machine. You can leave them as they are for now and define/change them later from either new or old Azure portal.

Example endpoints generated by Azure wizard:
endpoints


Watching out the cost

When deploying your environment to Azure, you need to take into account costs of VM and VPN gateway, as they would hurt the most.
Both virtual machine and gateway will be charged for amount of time it is enabled, no matter if you’re using it or not.
As for virtual machines, you can actually stop them, so they become deallocated and you won’t be charged
As for VPN gateway, there is no such an option and you are forced to delete it if not in use.
You might want to use a public port for RDP access to your machines if that’s fine for you tough.