Graphinder – Monthly Progress Report – March


I’ve come to think of this project as a simple way of having fun, coding and maybe learning a new thing if possible in a such range of time. I’ve ended up much profitable (in many terms) though.
I’d like to discuss progress on a project, but also progress on myself, as Daj Sie Poznac was (I think) meant to deliver both.

Current state of project in numbers

Feature progress: 5/10 features from roadmap met.

  • Porting current solution with Simulated Annealing and Genetic algorithms working on Minimal Vertex Cover problem from initial, console application to library.
  • Further decoupling for future IoC in ASP.NET MVC project.
  • Implementing missing unit tests for part of the code.
  • Reporting problem solving progress once upon a time.
  • Parallelizing problem solving.

Github repository status:

  • Commits: 121
  • Average commit time: 10 P.M. – 2 A.M.
  • Days with no commit: 7d

Related Trello tasks:

  • Done: 20 tasks
  • Refactoring backlog: 7 tasks
  • Feature backlog: 10 tasks
  • Feature icelog: 3 tasks

Things I’ve learned

Wow. So.. I’ve wanted to start with the fact that I’ve never wrote anything that should (and by the time, everything should) scale horizontally. I wrote a WebAPI, I wrote ASP.NET MVC twice, I wrote WPF application twice but they always went with linear, vertical structure from front-end to database.

First of all, during recent month of working on Daj Sie Poznac project, I’ve used up my free time between coding, working and spending time with family for reading. And by reading I mean LOTS OF READING.
I’ve focused mainly on microservices concept in current software development. Besides reading tons of articles where most of them made sense and some of them didn’t, I’ve taken a lot of knowledge (and what’s important: clarification) through talking with one of the Daj Sie Poznac competitors, that is Michal Franc (current Lead Developer @ JustGiving).

Also, I’ve learned immensely lot about Actor model, that is strongly promoted by Akka and it’s .NET port Akka.Net. Although my interest currently flows slightly towards Microsoft Orleans solution, I highly doubt I won’t try out both of them as proof-of-concept in Graphinder project.

Last, but not least – Reactive extensions aka System.Reactive aka Rx.Net. A super powerful tool for introducing reactive programming into your current application. I’ve already used it a lot via UniRx implementation for Unity3D in Regalia – Of Men And Monarchs, but now I can see how little I knew using it until now. I’ve also already implemented some of the features using System.Reactive in Graphinder, ie. async yielding from IEnumerable, but I will cover it up soon in separate post.

Discipline I’ve enforced

Even though it’s a side-project for Daj Sie Poznac (and I hope, further on!), I’ve ended up with leaving my comfort zone and forcing myself to introduce an everyday discipline on:

  • How often do I write code for project? I did my best to make sure it’s at least 3-4 times a week + some documentation writing/project organization
  • How often do I write posts? This requirement of project made me think of reserving time for my thoughts to be persisted at last. I’ve also went over 2-posts-a-week schedule and even found some time to write posts covering other programming issue I’ve had on my work project.
  • How far can I go with spaghetti or unreasonable code in my project? Well that’s always a tricky one but I’ve made sure that every decision I make to my project composition, is thought over twice and maybe even discussed with other Daj Sie Poznac participants on Slack. I guess I just don’t feel that MVP idea is an excuse of bad design at all. That change also made myself more cautious and disciplined about how I wrote my code at work
  • Do I feel comfortable with TODO in my code? I’ve made myself come back to this little annotations many developers tend to leave around their code. I’ve used to accept that many of them will be left behind but I try to arrange my project schedule, so that there is a room for reasonable refactoring

Graphinder – Code review yourself


Few words of self reflection

After working a little on my side projects, I’ve found myself lacking a lot of code reviews. Or any sort of reflection on one’s code.
Often side projects are meant to be fun and focused on teaching oneself some new technology, new concept or just on simple proof of concept. Or made just for fun. But doesn’t mean it’s meant to resemble Swiss cheese. It’s quite the opposite.
Side project is where your code should shine.
Even if you tend to work in less Agile workflow (while (Waterfall) { fail++; }), you are mostly exposed to some sort of comments on your code. Sometimes somebody will come over to you with a bag of questions about your code. Sometimes you’ll find out you’d write it other way round. Alright, more than sometimes. But that’s not the point.
The point is that you have some sort of feedback.

Code review yourself

To fight back and to strive for better quality of code, I’ve forced myself to do annual Self Code Review.
You’d ask – how the hell? You’ll mostly lack feedback, because you’re the one, who gave birth to this little monster meant to be reviewed.
That’s actually not entirely true though.

Thinking over through many possibilities I’ve decided to go with behavior that would be closest to my natural way of reading the code.

Few steps to consider:

  • First of all, find an hour once a – let’s say – two weeks
  • Start from the point where you’re now in development. Let’s say, I’m in middle of Controller and View for one of my IAlgorithm in Graphinder. Let’s go down the whole pipeline, down to the very backend.
  • Now, let’s start going up, to middle end, to front end. Attempt to understand any method/property/field you’re going through in a process just by looking on a docs summary, method/property/field name or looking inside the body of each. Do you understand what it does or what it describes? Do you think it’s error-proof? If yes, that’s great – proceed. If not, you should do a quick reflection here.
  • Reflect on what is missing here. A quick docs summary? Maybe decomposition is necessary? Maybe you highly doubt it wont’ explode if you pass IDestroyerOfWorlds as param here? Or maybe name of the functionality is ambiguous? Or maybe it just doesn’t belong here and breaks SRP?
  • Decide on action that comes next: shall I document it properly now? Maybe. Should I refactor it now? Time is your judge. Should I postpone it then? It depends.
  • I believe that attempt to make code perfect at once tends to build up a lot of work and stops the progress of the project itself.
    While I also believe, that every project should work in a first place and then look beautiful, compromise is not an easy choice here.
    My advice would be to choose what you urgently need to fix (make it up to 2-3 pieces of code at most) and do it at once.
  • If you encounter the bug, always attempt to fix it before going back to writing new code. But that’s basics. That’s what should always be done when you find out bug.
  • Make sure, that every other thing that you’ve left behind is marked for future fixes. Make a goddamn //TODO {stuff we mostly don't come back to}. Acknowledge the fact, that some sort of refactor is needed here. Do yourself a favor and put it in some Scrum/Kanban/whatever board. I use Trello and love it. And I’m only user of my board. And I don’t care – as long as my workflow is being somehow organized.
  • Never trust code you see. Test it! It applies to every piece of code. Yours is the one you should probably trust the least. :)

Alrighty. We’ve got a few things we should go through here to make a few steps into direction of perfection.
But that’s only once a two weeks. Wouldn’t it be impossible to actually review all of that? Of course it would.
However, such approach made me behave a little differently when approaching my own code (and others’ too) at work (and everywhere else).
Whenever I come back to code written by myself or someone else, I try to reflect for a second or two on it.
I no longer feel afraid to put a big, bad //TODO in someone’s code and even put a card on a board with a task of making things right.
Of course mostly I bash my own code with wall of TODO‘s but I also tend to acknowledge others what smells just not right. Kindly, of course. Making enemies in our team is a bad idea from the very start, isn’t it? :)

As for growing up pile of TODO in your project, I’ll soon write a article about my upcoming TODO session.
Depending on how it goes. ;)

Other news

I’ve decided to introduce Continuous Integration for this project.
You can notice current status of last build every article’s menu, just below the logo. CI is provided by great amazing guys from AppVeyor @ https://ci.appveyor.com/. If you’re writing an app in C# and write unit tests (if you don’t then @&#!^#!&*^#!&* – do so!), you should definitely give it a try. It’s G-R-E-A-T.

Graphinder – Project Introduction


Quick introduction

Ahoy!
My name is Michał and I’d like to welcome you to my half-zombie/half-hyperactive programming blog that covers mostly anything connected with Microsoft technologies. If you want to contact me or know anything more about me, please navigate to ‘About me’ section on your left. Thanks!
Going next to Daj Sie Poznac 2016, I’d like to elaborate a little about the topic of the project I’m going to develop throughout upcoming 3 months.
First of all I’d like to offer my deepest condolences to all of you who might find my written language boring and/or chaotic. I hope you’d get used to it quickly!
And.. as for the starters, let’s talk a little bit about what babble you’d be going through.
You’ll definitely see lots of graphs. And by lots I mean LOTS.
Origins of this project are not quite distant, as they belong to one of my school projects for artificial intelligence classes from recent semester. To be precise, it’ll try to leverage optimization algorithms operating on graphs and move them from boring command-line* space to some kick-ass web app with lots of front-end sugar and so on.
Let’s split the topic into few sections to add some readability to this TLDR.

* I’m joking ofc. I freakin’ love console apps.


Project organization

Starting with organization side…
I’m going to put a section just below the logo for quick navigation throughout the topics inside the project, in case you’re interested in jumping around on your lecture. This functionality will be available in every article so you’re welcome to give it a shot.
GitHub link for the project will also be provided below the logo, in case you want to go straight to the code.
As for the other tools and means of work organization, I’ve decided to go for good old Trello board for my current tasks, found bugs, backlog and icelog.

Trello for Graphinder:

https://trello.com/b/g6Rm8Cdm/graphinder

Why this topic?

I’ve decided to go for algorithmic project, because I’ve always struggled with anything revolving around them and throughout recent year or two I actually found myself enjoying writing and doodling in them.
However, please don’t be mistaken that those algorithms will be the most efficent and the most sophisticated ones because they won’t be. Hell, I’m even about to bring down Azure Service Fabric, provided I’ll have some time left for actual micro-service decomposition.
While quite boring from the surface, it should be fun for all of you to read some (I hope) interesting stuff I’m gonna share.
Basic implementation of Graphinder so far involves Minimum Vertex Cover problem and two algorithms, attempting to solve it, ie. Simulated Annealing and simple Genetic algorithm.

Current state of project

Currently I’ve finished two algorithms (Genetic and Simulated Annealing) along with Minimum Vertex Cover problem implementation. I’m currently thinking through some decoupling ideas for Genetic algorithm, that’s why only part of it is available in GitHub repository right now. Most of currently committed stuff is loosely covered with basic unit tests and more tests are coming soon. Actually, you’ll probably see at least one article about my struggle and thoughts that came up during unit testing so far (and probably more of it coming with growing amount of components).

Technologies

Ahhh… technologies!
Frameworks, libraries, APIs and services!
To be honest I almost gave up on this project trying to stop myself from doing I can do anything project to something more, more narrowed.
If you didn’t came up with description of my project on devstyle.pl so far, I’m about to write everything in C#, mostly ASP.NET MVC 5 (6?), SignalR (I have no idea what I’m doing), Entity Framework, xUnit (+ NSubstitute) for backend, and pure JS with AJAX or one of major JS frameworks for front-end along with D3.js for graphs visual representation.
If only time allows, I’ll also attempt to decompose application backend into smaller micro-services, mostly for solution-finding (high processor cost, needs to move elsewhere) and authentication/authorization in some sort of WebAPI (I guess?) implementations.
You’ll probably see some reactive programming around as I’ve got used to it working for a quite time now in game development in Unity3D, so if you’re not really into webdev nor graphs, maybe that will catch your attention?

Logo

Have you seen this sexy, shiny, new logo for the project?
Which logo? What do you mean by ‘which logo’?
Hey, don’t go away, hey wha-…
Alright, just joking. Hope you like it as I thought of coming with something for the challenge anyway.
Either way, let me know what do you think ’bout the project!

Wow, 66 revisions of this post so far. When did it happen anyway…