Thoughts about software development

Everybody has their favorite when it comes to cars, sports or jeans and the same goes for work tools. Some prefer OS X over Linux or Maven over Gradle and don't even get me started on browser wars. I've had my share of trying out different tools to choose the ones I want to use but every now and then I change some of my tools. This time I'm telling what my day to day tools currently are and why I changed one of them. The solid foundation When I get to choose my tools there's one solid foundation that works as a base for all other tools. This has been my number one choice for over ten years with a little variety over time. Linux. No question about it, I've used for years, I know my way around it and it offers everything I need in work and at home. The variety comes from different distributions and desktop environments although those have also been very stable for the past four or five years, Debian has the stability I want and XFCE offers everything I need fr...

I've been working as a part of international team for about six months now. By international team I don't mean that the team is located in two or more locations but that the team consists of people of different nationalities and therefore different languages. I thought I'd write down my thoughts on how that's working out. The team  About half of the team are from Finland and half from India. As the mother tongue of the team members varies the teams common language is english and it works out just fine most of the time. The language barrier does bring it's own challenges, here's a few that I have noticed or been informed of. Challenge with conversations Mostly out team struggles when it comes to ad-hoc conversations on implementation details or architectural decisions when we, the finnish team members, start to talk about it, in finnish, and thus leaving half of the team out of opportunity to join the conversation just because were talking in finnish an...

It's been a while since my last post but I have a good excuse. I've been in a new customer project (well new for me) for two months now and have absorbed a lot of new information on the technology stack and the project itself. This time I'll be sharing a short post about sharing code and how it can help the one who's sharing the code. I'll be giving a real life example of how it happened to me. My story Back when I was implementing first version of my simple-todo REST-service I used Scala and Play framework for the service and specs2 for testing the implementation. Since then I've done a few other implementations of the service but I've continued to use specs2 as a testing framework. I wrote about my implementation and shared the post through various services and as a result someone forked my work and gave me some pointers on how I could improve my tests. That someone was Eric Torreborre  the man behind specs2 framework. I didn't take his ref...

Previously I got my first version of simple todo rest service working with scala and play framework and had some ideas what to do next. Since then I've implemented a second version of the rest service, this time backed by MongoDB . I also managed to create a simple web application as a user interface for the service. TL;DR; https://github.com/jorilytter/simple-todo/tree/mongodb-integration https://github.com/jorilytter/simple-todo-ui MongoDB with scala This was a idea that I had earlier and the actual implementation was pretty straightforward with the help of salat library. Integrating salat with play framework required me to implement a custom context but salat documentation already provided this solution so it was just a matter of reading the documentation. Other issue that I faced was with reading and writing json documents but that's where play's documentation provided the needed answers after some initial searches with google. Like before the implem...

As I mentioned in my previous post I tried to create a simple REST service with Scala and spray.io , but that turned out to be unbelievably difficult. A second try with Scala and REST turned out to be successful. Play to the rescue When my experiment with spray.io didn't work out I had an idea to try out Play 2 as a base to my REST service. Working with Play 2 was a walk in the park compared to spray.io even though not entirely painless but much easier and less frustrating. Starting out with Play 2 was really quick thanks to a good documentation and examples that are up to date. Basically I just ran the command play new appName and started coding. So far I have REST service and a in-memory implementation of todo tasks with some unit tests. REST service is all Play 2 with routes and a single application class. The current service layer implementation is a single class with tasks in a mutable Map where a individual task is a case class, so just some basic Scala code. I r...

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...