Skip to main content

Creating something concrete with Scala

Since I attended a course on functional programming with Scala at Coursera (see previous posts) I've been having a idea to make something concrete with Scala. Having only minimal experience with Scala I decided to try something simple with well known Scala libraries.

The project


First I'll try to create a simple todo application that saves all the data to a some database (maria, redis, mongo) and the tasks are managed via REST-service.

Once I've done that I have two ideas what to do after that. I'll either try to create some sort of UI that uses the REST-service or I'll extend the simple todo application to a Kanban board type of application and try to create the UI after that.

I haven't decided with what I'll be creating the UI since I'm not that familiar with current frontend technologies so that'll be decided later.

First try


At first I tried to create a REST-service with spray but that didn't work. Maybe it's just me but to me the spray documentation was incomplete, I also tried out sprays examples from github and had them running via sbt but not with Scala IDE. The examples ran with sbt but when I tried to create my own REST implementation based on the examples the service never responded. Trying to make this simple service to respond to me with no luck for several hours I decided that I'm not going to use spray.

Second try


This is still on my todo list but next I'll try create the REST-service with Play 2 hopefully with better results.

Impressions now


Trying to create something with a new language and new libraries can be difficult and in case of Scala and spray it seems to be true. Though this isn't true to all languages, I remember a project where we created a REST-service with Grails with absolutely no experience with Groovy or Grails and that was a walk in the park compared to my experiences so far with Scala and spray.
Labels:

Popular posts from this blog

Simple code: Naming things

There are two hard things in programming and naming is one them. If you don't believe me ask Martin Fowler https://www.martinfowler.com/bliki/TwoHardThings.html . In this post I'll be covering some general conventions for naming things to improve readability and understandabilty of the code. There are lots of things that need a name in programming. Starting from higher abstractions to lower we need to name a project, API or library, we probably need to name the source code repository, when we get to the code we need to name our modules or packages, we give names to classes, objects, interfaces and in those we name our functions or methods and within those we name our variables. Overall a lot of things to name. TLDR; Basic rule There's a single basic convention to follow to achiveve better, more descriptive naming of things. Give it a meaningful name i.e. don't use shorthands like gen or single letter variables like a, x, z instead tell what it represents, what it does...
Read more

Simple code extra: Readability examples

Seven ways to write the same code snippet  Here are eight ways to write the exactly same code. Some are easier to read than others and all are a variation of a code I've seen in a real code base. My personal favorite is #7, what's yours?  #1 One liner DAO.filter { it.name == "foo" }.map { it.company }.toSet() #2 two lines, three operations DAO.filter { it.name == "foo" }   .map { it.company }.toSet() #3 Evaluation on it's own line DAO.filter {   it.name == "foo" }.map { it.company }.toSet() #4 Each operation and evaluation on their own lines DAO.filter {   it.name == "foo" }.map { it.company } .toSet() #5 All function calls and evaluation on their own lines DAO   .filter {     it.name == "foo"   }.map { it.company }   .toSet() #6 Everything on it's own line DAO   .filter {     it.name == "foo"   }   .map { it.company }   .toSet() #7 All function calls on their own lines DAO   .filter {  i...
Read more

Simple code: Version control commits

Currently the most popular version control system is git and I'll be writing this based on git and it's functionalities and capabilities. Git is often seen as a way to enable distributed programming i.e. multiple programmers can work on the same code repository quite easily without disturbing each others work (much). In addition to that just like other VCS's it's also a log of work but to my experience that part is often unfortunately neglected. What I will be focusing this time is the log part because I think it deserves more attention. Why to create a meaningful log? The git log should consist from small meaningful changesets where each commit addresses a single problem. By dividing the log to small commits it enables resilient way of working. Being resilient enables simple and fast procedures to rollbacks, reviews, tags, branching etc. Lets say that a developer is implementing a REST API. The API needs a web layer that receives the HTTP requests, it probably has some...
Read more