Daj Się Poznać 2017, The End!

      6 Comments on Daj Się Poznać 2017, The End!

That’s it guys! This is the end of Daj Się Poznać 2017, the Polish blogging contest I’m taking part in since the beginning of March. In today’s post, I’ll be doing a retrospective of the whole contest.

Wait… What happened during the last 3 months?

In two words: a lot! Those 13 weeks were amongst the busiest in my life. I

  • got more familiar with F#, WebSharper and the Web Dev world in general.
  • blogged twice a week.
  • attended the 2-day wedding of my friend and colleague Krzysiek.
  • attended several ReactJS workshops and Unity 3D Game Dev meetings.
  • participated in an intense, 3-week-long chatbot contest between all our offices here at Infusion and ultimately grabbed the 2nd place with the Wrocław team!
  • Oh and I almost forgot… I also went to work!

Continue reading →

Reproducing the D3 zoomable map example with F# and WebSharper

      1 Comment on Reproducing the D3 zoomable map example with F# and WebSharper

Today’s post will be the last one associated with DSP 2017. Almost 3 months have passed since the beginning of the blogging contest and here we are, 21 posts later! I will continue to blog after the contest ends, but probably not as frequently as of now.

Today we are going to try out the D3 extension for WebSharper. WebSharper comes with quite a lot of extensions that allow developers to use some of the most JavaScript libraries from F#. The full list of extensions is available here.

What is D3.js?

If you are not familiar with D3,js, it’s a JavaScript library that allows to create and embed awesome data visualizations into your website. You can browse the official list of examples to have an idea of the capabilities of the tool. The sample that I am going to port to WebSharper displays a map of the US and allows users to click and zoom in on the different states. You can check the JavaScript source code and try out the original sample in your browser by visiting this page.

Continue reading →

How to efficiently break your code by using exceptions?

      4 Comments on How to efficiently break your code by using exceptions?

At first I wanted to call today’s post something along the line of “Exceptions should be exceptional” or “keep your exceptions exceptional”. However a quick search on Google made me realize I was not the first to think of this catchy title.

Instead, I decided to go with “How to efficiently break your code by using exceptions?” and this made me think of a different way to present the potential negative effects of overusing exceptions in your codebase. Instead of telling you why you should be careful when using exceptions, I will focus on showing you how to use them “efficiently” in order to break your application in no time. I will be using C# for the examples below, but those could be applied to other languages supporting run-time exceptions, like Java for instance.

Continue reading →

Creating a reactive Single-Page App in F# with WebSharper UI.Next and Bootstrap – Part 2

      2 Comments on Creating a reactive Single-Page App in F# with WebSharper UI.Next and Bootstrap – Part 2

Hello again! This is the second post on our attempt to make a dynamically editable Bootstrap navbar using WebSharper’s UI.Next library. If you haven’t done so yet, I recommend you start by reading the first part here where I cover the basic of the application (reactive Single-Page App) and the different HTML files used. AS a reminder, here’s how the final application looks like:

(click on the .gif to enlarge)
Let’s jump right back where we left off and go over the F# logic.

Client.fs

I’m going to divide this file into smaller parts to make it easier to follow. Here’s the first part:

namespace UI.Next.Demo

open WebSharper
open WebSharper.UI.Next
open WebSharper.UI.Next.Client
open WebSharper.UI.Next.Html

[<JavaScript>]
module Client =
    
    type NavbarSampleTemplate = Templating.Template<"navbar_sample.html">
    type BsNavbarTemplate = Templating.Template<"bootstrap_navbar.html">

    type Tab = { Name: string; Url: string; IsActive: Var<bool> }

    let sampleTabs = [
        {Name = "First tab"; Url = "/#"; IsActive = Var.Create true }
        {Name = "Second tab"; Url = "/#"; IsActive = Var.Create false }
    ]

    let Main =
 // ... to be continued

Continue reading →

Creating a reactive Single-Page App in F# with WebSharper UI.Next and Bootstrap – Part 1

      2 Comments on Creating a reactive Single-Page App in F# with WebSharper UI.Next and Bootstrap – Part 1

Wow! That’s a lot of buzzwords we got here in that title! I’m not lying though, this is exactly what we are going to cover in today’s post. I hope you are familiar with all the terms above, but in case you’re not, let me start by explaining some of them.

Single-Page Application

Or SPA for short. A particular type of website that consists of a single HTML page that gets updated dynamically as the users interact with it. A good sign that a given website is a SPA is that it is not being refreshed every time you click on a link. This gives an experience similar to when using a desktop application. Gmail is a great example of a SPA.

Reactive Programming

Or RP for short. To keep things simple, it is a programming paradigm where you define data-sources that can be auto-magically observed. If the data-sources get updated (say, by a user or an external process), the elements that observe those data-sources will get notified and automatically react to the changes. The following pseudo-code illustrates a traditional, non-reactive approach:

var a <= 1
var b <= 2
var c <= a + b
echo c // c equals 3
a <= 2
echo c // c still equals 3

The next snippet illustrates the reactive approach however. Here c gets updated automatically every time a or b change, thus:

var a <= 1
var b <= 2
var c <= a + b
echo c // c equals 3
a <= 2
echo c // a changed, so c now equals 4!

This is obviously a very naive example and I encourage you to encourage you to do your own research about the topic and make your own opinion of it. There is a lot of information (and debates!) available online. I particularly like this presentation because it gives a global overview of different flavours of Reactive Programming.

Continue reading →

Load-testing the PizzaManager REST-like API with JMeter

      No Comments on Load-testing the PizzaManager REST-like API with JMeter

Today we are going to do something different. Today is load testing day! Today is also the day when we will be borrowing something from the enemy Java World: Apache JMeter. What is JMeter? Let me shamelessly paste here the definition from their website:

The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.

But by the way, what is load testing? To keep it simple, it’s a specific domain of testing aimed at measuring how a given system behaves when being used by a relatively large number of simultaneous users. What large number means depends entirely of the goals you want to achieve. For instance, it might be written somewhere in the specifications of your project that “the application must handle up to 100 concurrent users with a maximum response time of 1s and an average response time of 200ms”. Load testing, and tools like JMeter, can help you prove that your application just does that. And if it doesn’t, then you might want to either review your specs or get to work on that performance!

My objective for today’s post is twofold:

  • Get more familiar with load testing in general. This is something I’ve never done outside of purely academic circles (read, at school) and I would like to introduce it to my day-to-day job. I think it’s bad not to test such things but let’s be honest, performance concerns are often pushed to the far end of the backlog until, well surprise surprise, things start to get ugly. Who would have thought that several users would use your app at the same time, right?

  • Get started with JMeter. I requested it at work in the hope to finally be able to use it in my current project, so I figured I might take the beast for a ride at home first. My Java colleagues said good things about it and it is free, so why not?

That being said, let’s load test!

Continue reading →

Lambda Days 2017 – My conference round-up

      No Comments on Lambda Days 2017 – My conference round-up

Almost 3 months ago, on February 9 and 10, the 2017 edition of Lambda Days, the conference dedicated to Functional Programming, took place in Kraków, Poland. I had the chance to attend the event with 3 of my friends and colleagues (thank you Infusion for covering all the expenses!).

The least I can say is that I don’t regret it! The 2 days were packed with awesome sessions, great speakers, and a very responsive audience. Not to mention the food (honestly, that probably was the best meringue pie I’ve ever had!). You can check the full program here.

Much water has flowed under the bridge since then, but I wanted to write a post about what were my favourite sessions and why. All the conferences were recorded so we will be able to watch (or re-watch?) them if you want to. Without further due, here are my top 3 talks. Enjoy!

Continue reading →

F# vs C#: a performance comparison with BenchmarkDotNet

      3 Comments on F# vs C#: a performance comparison with BenchmarkDotNet

[EDIT – 02/05/2017] I received quite a lot of comments regarding this post about how it does not fairly reflect the differences between F# and C# and also suggesting possible performance optimizations. I want to highlight from the get-go that this was done on purpose (this is explained in the post below but was maybe not explicit enough). My goal was to compare the traditional OOP approach of C# with the more FP’ish approach of F# on a real use-case. I left out any performance optimization from both versions because the aim was not to optimize code – but rather to show how both versions compare if we write them in a simple and naive way.

Ever since I became interested in functional programming, I’ve read and heard multiple times something along the lines of “F# (or functional programming in general) is slow and that’s why you should stay with OOP languages that guarantee good performance, like Java, C# or C++”.

Because I am curious by nature, I decided to see for myself if indeed I should sacrifice F# on the altar of performance. Specifically, there are two parts of the sentence above that deserve our attention:

“F# is slow”

What does it mean for a programming language to be slow? How can we measure the slowness of a given language? In what context? On what machine, OS, or architecture? Under what conditions? This is definitely not an easy question. Let’s try to put it in a more reasonable way: Is F# so much slower than other OOP languages like C# that we should automatically refrain from using it?

This is easier to answer already. We can definitely measure if a language is slower than another and we can also judge if the difference in performance is something we can live with. This is precisely what we’ll try to do in this post.

Continue reading →

Being REST-like in WebSharper – Part 2

      1 Comment on Being REST-like in WebSharper – Part 2

Today I will take up where I left off last time and flesh out my PizzaManager REST-like API a bit. But before I start, I promised last time that I would expand a little on the topic of RESTful APIs.

Is my API really RESTful?

For a few years now, we’ve seen an increasing number of web APIs boasting to be RESTful, providing nice and readable URLs for their resources, like the ones below:

  • GET api/employee/12
  • GET api/employees/all
  • POST api/employee { “firstName”: “John”, “lastName”: “Doe” }
  • DELETE api/documents/all

Are those APIs really RESTful though? We talked very quickly last time about the Richardson Maturity Model. Basically, The model says that they are 3 levels of RESTfulness:

  • Level 1: usage of resources. This is the part about how the URIs are constructed. Instead of querying an employee with a good ol’ query string (api/getEmployee/?id=12), we design a system where each resource has its own URI: api/employee/12
  • Level 2: usage of verbs. This is the part about using different Http Verbs like GET, POST, PUT or DELETE to express the action we want to apply on a given resource. So instead of having two queries like api/getEmployee/?id=12 and api/deleteEmployee/?id=12, we can simply define one and interchange the verbs as needed: GET api/employee/12 versus DELETE api/employee/12.
  • Level 3: usage of hypermedia controls. In short, this part is about how to make your API discoverable by communicating with hypermedia links rather than just sending back some data. For instance, if you were to create a new employee using the following request: POST api/employee { “firstName”: “John”, “lastName”: “Doe” }, the response would not only contain data about the newly created resource, but also other links to manipulate it, like DELETE api/employee/johnDoe or GET api/contactInfo/johnDoe/address. This allows to explore the API as you go along, from one link to another.

The problem is that according to the inventor of REST himself, Roy Fielding, an API cannot be deemed RESTful unless it achieves all 3 levels! However, the vast majority of APIs in the wild “only” achieve level 1 and level 2, like my own API below. In fact, achieving level 3 can be a very complex task on its own. Is it really worth making the distinction? Well, since truly RESTful APIs offer a rather different way to be navigated and explored, I’d say it is rather important to state the difference, for the sake of communication and to avoid any surprise when integrating with such APIs. I’ll let you make your own opinion on the topic.

Time to go go back to our PizzaManager!

Continue reading →

Putting together the Software Dream-Team

      4 Comments on Putting together the Software Dream-Team

If you read some of my previous posts on this blog, you will find that I am equally interested in both the technical and social aspects of Software development. As I explained in my post about project failures, statistics appear to show that most problems Software professionals encounter are not in fact technical but rather social. Based on my own experience, I am very inclined to believe those figures.

On my quest to understanding how we could make and deliver better Software, I often wonder what I would do if I was given the difficult mission to assemble the ideal development team from scratch – the Software Dream-Team, if you will. I guess it’s time to put my thoughts in order and lay them on paper!

First, we need to define what such a team will be tasked to achieve. For the sake of the exercise, let’s assume that the lucky guys will be working on a product aimed at Italian restaurant businesses: A web-based pizza manager with both cloud and on-premises data hosting options. As the product itself is available under a monthly subscription business model, the team will have to deliver new features very regularly to keep customers from going to the concurrence. All this while guaranteeing good performance and stability, obviously. Seems like there’s a lot on the agenda, so we’d better pick the right guys for the job! Since we’re at it, let’s add an additional challenge to the mix. Turning the pizza manager into a successful project will certainly be a long-term endeavour and therefore we also want our team members to be happy and proud of their achievements. Customer satisfaction starts with employee satisfaction.

Who will we need in our team to make our pizza manager the killer app it deserves to be? Let’s list the usual suspects we encounter in Software projects and try to pick the ones that’ll be useful to us.

  • Business analyst (BA)
  • Project manager (PM)
  • Release manager
  • Back-end developer
  • Front-end developer
  • Tools developer
  • QA specialist (QA)
  • Test automation engineer
  • Software architect
  • Graphic designer
  • UX designer
  • Database administrator (DBA)
  • Network specialist

That’s 13 roles already. So let’s hire 13 guys and rock’n’roll, right? RIGHT!? Not really. This would most probably end in a real communication mess and this is precisely what we want to avoid. Our goal is to deliver Software, not to manage a circus.

Continue reading →