Tuesday, October 7, 2014

Weapon of choice

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 from a desktop.

Crafting tool


I've used various IDE's over the years for JVM languages and web development. There's one that I haven't tried, IDEA, even though I've heard good things about it.

My choice has been Eclipse and it's variations and plugins for several years now for a few reasons. I know how to work with it, it's open source and therefore free and because it's free (and I'm greedy) I can have the same programming interface at work and at home.

In my current work project all other developers are using IDEA and I'm alone with Eclipse but it hasn't caused any problems at any point. All IDE's have their cons and pros so there's no silver bullet in whatever you choose just choose the one that gives you greatest benefit.

Visual aid


I've done a lot of work with different types of technical web services and a lot of those services are being used from web applications. The browser plays a big part as visual tool and as a debugger to verify that everything works correctly from end to end in addition to the fact that just about everything works via browser nowadays. I've tried all the major candidates and for a few years I've used Google Chrome, until the last stable release. I already had some issues with a few previous releases of Chrome and even used the beta version for a while but finally I got tired of trying to figure out the problems that seemed to just accumulate after each release.

I looked into my toolbox and decided to try out Iceweasel, the Debian fork of Firefox, and still had some issues. After Iceweasel I tried vanilla Firefox and haven't looked back since. Firefox isn't new to me. I've used it for years and switched to Chrome a few years back because it's performance was better and rendering was somewhat nicer to my eye. Now, a few years later, Firefox has risen from the ashes and is my #1 choice for the time being.

I think I'm the only developer in our team who's using Firefox... I'm starting to see pattern here.

Tuesday, September 16, 2014

Quick thoughts of working in a multilingual team

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 and they have no idea what we're talking about.
This could be resolved by speaking only english when the topic is work related but to me that feels unnatural. Because it feels unnatural to speak english to another finnish speaking person it's probably why it's also so hard to remember that we should be speaking english.

Challenge of understanding


Another thing that happens occasionally is misunderstanding. Everybody is speaking english that no one speaks for a mother tongue sometimes leads to situation where a message might get misunderstood at the start or along the way as it passes from person to person.
It's not a huge problem as we tend to keep our individual tasks small but it does create some extra work in a form of refactoring or rewriting code. This does happen also when people have the same mother tongue but not as often.

Conclusion


Overall I don't see big problems working in a multilingual team but this is my first time as it probably is for some of the other team members also but it does bring some challenges. Hopefully we'll get better at it over time.
At least the next time I join a multilingual team I'll have a better idea what to expect and hopefully some solutions on how to over come or reduce the challenges.

Sunday, May 18, 2014

Sharing to help myself

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 refactoring as is but I did take some of them to good use. Later on I have looked at Eric's refactoring and our discussion a few times just so I don't forget that there's still good suggestions that I haven't taken in use.

So what's the big deal?


The point is that I shared my code, I shared my blog post and as a result someone decided to help me improve my code. He decided to share his expertise with me just because I gave him the opportunity by sharing my code and idea and he didn't want anything in return. That's got to be one of the best things you can get just by sharing something you've created.

So by sharing I got help before I even asked for it.

Saturday, March 15, 2014

a walk in the dark side

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 implementation is shared at my github account https://github.com/jorilytter/simple-todo/tree/mongodb-integration.


Walking in the dark side


It's been a long time since I've done anything related to user interfaces let alone created one from the scratch. I had decided that my todo application will have a user interface and it will be done with something out of my comfort zone.

The idea had been in my head for a while. I've seen and heard how modern javascript frameworks can do pretty nice things and easily interact with rest services. I asked my colleagues what was the hip javascript framework for interacting with rest services and got to work.

The choice was AngularJS as I was told that rest integration with it would be easy to implement. Sure the implementation was easy after series of trial and error and the fact that AngularJS is evolving fast also means that Q&A found in various blogs or at stackoverflow were partly outdated even if they were just a few months old.

I don't believe my implementation follows the best practices but with my lack of expertise with javascript I'm just happy I got it working.

This is also shared at my github account https://github.com/jorilytter/simple-todo-ui. If you feel the need to comment please be gentle, as I said this is way off my comfort zone.

In the end I'm happy that I went out of my comfort zone and actually managed to get something that works and I'm definitely going to do it again.

Saturday, February 8, 2014

Second try with Scala and REST

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 really like Play 2 so far but I'm a bit concerned of how much dependencies Play 2 brings with it as default. Currently I have 92 jars in referenced libraries of my project, all from default initialization of play application. Sure some of these are test library dependencies but still that's a lot of libraries.

Unit testing Scala code


Play 2 automatically includes as a dependency the specs2 library that's a unit and acceptance testing library for Scala. I had never used specs2 and the bdd style definition of tests was a bit odd to me but I decided to give it a try.

After a few initial wtf's I got the hang of it pretty quickly and was able create some basic unit tests for my service implementation. I've only scratched the surface with specs2 but it seems to do the job and has quick learning curve and so far the provided documentation has been enough to get me going.

What's next


Next step in my adventures in the world of Scala will be to try use some real data storage to persist the todo applications data. I think I'll try out with MongoDB and after that some other very different alternatives like Redis and MariaDB. 


Code shared publicly


As I use code and examples provided by others I too am sharing my code and putting it publicly reviewed by others. It's all shared through my github account at https://github.com/jorilytter/simple-todo, feel free take a look.

Saturday, January 25, 2014

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.