January 15, 2017April 18, 2017 Miłosz Piechocki

C# in Depth: book notes

pobrane I just finished reading this must-read position for C# developers. I believe that it’s very easy to learn a programming
language to an extent that is sufficient for creating software. Because of that, one can easily lose motivation to dig deeper and gain better understanding of the language. C# in Depth is a proof of why one shouldn’t stop at this point. There is a lot to learn by looking at the details of a language, how it evolved and how some of it’s features are implemented.

I think the book is fantastic. I loved the author’s writing style which is very precise (very little hand waving) but not boring at the same time. It feels that he’s giving you just the right amount of detail.

December 27, 2016April 18, 2017 Miłosz Piechocki

Building serverless web application with Angular 2, Webtask and Firebase

Recently I’ve been playing a lot with my pet project Tradux. It is a simple trading platform simulator which I built as an exercise in Redux, event sourcing and serverless architectures. I’ve decided to share some of the knowledge I learned in the form of this tutorial.

We’re going to build (guess what?) a TODO app. The client (in Angular 2) will be calling a Webtask whenever an event occurs (task created or task marked as done). The Webtask will update the data in the Firebase Database which will be then synchronized to the client.

November 22, 2016April 18, 2017 Miłosz Piechocki

ngPoland – Angular Conference 2016

Today I attendend ngPoland – the first international conference devoted to Angular in Central Europe. I’ve had some really good time there and decided to share some of the amazing things I learned about.

First of all, I was surprised to learn how good some of the speakers were at catching people attention and making sure that everyone stays awake. The conference was pretty intense (I counted 15 talks) so it was quite a challange. It was inspiring to see how got can one become at public speaking and working with large audiences.

October 17, 2016December 1, 2016 Miłosz Piechocki

“Scalability Rules: 50 Principles for Scaling Web Sites” review

Recently I decided to get into the habit of reading IT books regularly. To start with, I wanted read something about building scalable architectures. I did a quick research on Amazon and chose Scalability Rules: 50 Principles for Scaling Web Sites by Martin L. Abbott, Michael T. Fisher. Based on comments and reviews, it was supposed to be more on the technical side. I was slightly disappointed in this aspect. However, I think this is still a worthy read.

The book is divided into 13 chapters. Each of the chapters contains several rules. What stroke me is that these rules are very diverse. We’ve got some very, very general advice that could be applied to any kind of software development (e.g. Don’t overengineer, Learn aggressively, Be competent). We’ve got stuff for CTOs or IT directors in large corporations (e.g. Have at least 3 data centers, Don’t rely on QA to find mistakes). There are also some specific, technical rules – what I was after in the first place. I’m not convinced mixing these very different kinds of knowledge makes sense since they are probably targeted to different audiences (which is even acknowledge by the authors in the first chapter).

July 9, 2016April 18, 2017 Miłosz Piechocki

Slick vs Anorm – choosing a DB framework for your Scala application

Scala doesn’t offer many DB access libraries. Slick and Anorm seem to be the most popular – both being available in the Play framework. Despite both serving the same purpose, they present completely different approaches. In this post I’d like to present some arguments that might help when choosing between these two.

What is Slick?

Slick is a Functional Relational Mapper. You might be familiar with Object Relational Mappers such as Hibernate. Slick embraces Scala’s functional elements and offers an alternative. Slick authors claim that the gap between relational data and functional programming is much smaller than between object-oriented programming.

July 3, 2016April 18, 2017 Miłosz Piechocki

SBT: how to build and deploy a simple SBT plugin?

Few weeks ago when I was working on my pet project, I wanted to make it an SBT plugin. Since I had to spend some time studying SBT docs, I decided to write a short tutorial explaining how to write and deploy a SBT plugin.

Make sure your project can be built with SBT

First of all, your project needs to be buildable with SBT. This can be achieved simply – any project that follows the specific structure can be built with SBT. additionally, we are going to need a build.sbt file with the following contents at the top-level:

lazy val root = (project in file(".")).
  settings(
    name := "my-sbt-plugin",
    version := "0.2.0",
    organization := "com.github.miloszpp",
    scalaVersion := "2.10.6",
    sbtPlugin := true,
    sbtVersion := "0.13.11"
  )

lazy val root = (project in file(".")).

settings(

name := "my-sbt-plugin",

version := "0.2.0",

organization := "com.github.miloszpp",

scalaVersion := "2.10.6",

sbtPlugin := true,

sbtVersion := "0.13.11"

)

Note that we are using Scala version 2.10 despite that at the time of writing 2.11 is available. That’s because SBT 0.13 is build against Scala 2.10. You need to make sure that you are using matching versions, otherwise you might get compile errors.

June 23, 2016April 18, 2017 Miłosz Piechocki

Scala-ts: Scala to TypeScript code generator

I have started using TypeScript a few weeks ago at work. It turns out to be a great language which lets you avoid many problems caused by JavaScript’s dynamic typing, facilitates code readibility and code refactoring and does that at relatively small cost thanks to modern, concise syntax.

Currently we are using TypeScript for writing the frontend part of a web application which communicates with backend in Scala. The backend part exposes a REST API. One of the drawbacks of such desing is the need for writing Data Transfer Objects definitions for both backend and frontend and making sure that they match each other (in terms of JSON serialization).

May 1, 2016April 18, 2017 Miłosz Piechocki

Issues with asynchronous IO in web applications

Building servers with non-blocking IO has been quite popular these days. Tests have shown that it does actually improve scalability of web applications. However, my experience show that it comes at a cost. In this post I am going to discuss some negative aspects of writing asynchronous code based on Scala’s Futures.

Stacktraces

Debugging exceptions in asynchronous programs is a pain. When issuing an asynchronous IO operation you provide a callback that should be executed when the operation returns. In most implementations, this callback might be executed on any thread (not necessarly the same thread that invoked the operation). Since call stack is local to the thread, the stacktrace that you get when handling an exception is not very informative. It will not trace back to the servlet so you may have hard time figuring out where what actually happened.

Exception in thread "main" java.lang.IllegalArgumentException
	at HelloScala$$anonfun$1.apply(HelloScala.scala:28)
	at HelloScala$$anonfun$1.apply(HelloScala.scala:28)
	at scala.concurrent.impl.Future$PromiseCompletingRunnable.liftedTree1$1(Future.scala:24)
	at scala.concurrent.impl.Future$PromiseCompletingRunnable.run(Future.scala:24)
	at scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:121)
	at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
	at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
	at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
	at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

Exception in thread "main" java.lang.IllegalArgumentException

at HelloScala$$anonfun$1.apply(HelloScala.scala:28)

at scala.concurrent.impl.Future$PromiseCompletingRunnable.liftedTree1$1(Future.scala:24)

at scala.concurrent.impl.Future$PromiseCompletingRunnable.run(Future.scala:24)

at scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:121)

at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)

at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)

at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)

at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

April 2, 2016April 18, 2017 Miłosz Piechocki

Using Automapper to improve performance of Entity Framework

Entity Framework is an ORM technology widely used in the .NET world. It’s very convenient to use and lets you forget about SQL… well, at least until you hit performance issues.

Looking at the web applications I worked on, database access usually turned out to be the first thing to improve when optimizing application performance.

Navigation properties

The main goal of Entity Framework is to map an object graph to a relational database. Tables are mapped to classes. Relationships between tables are represented with navigation properties.

March 17, 2016April 18, 2017 Miłosz Piechocki

Asynchronous programming in Scala vs C#

In one of my recent post I compared two different approaches that authors of Scala and C# chose to solve the same problem. This post is based on the same idea but the problem being solved is asynchronous programming.

What’s asynchronous programming?

Let me explain by giving you an example. If you have ever used a web framework you might have been wondering how it handles multiple concurrent requests from different users. The traditional approach is to spawn a new thread (or get one from a thread pool) for every request that comes in and release it once the request is served.

Code with style!

Exploring .NET, JavaScript and Angular