This year I’ve attended Principles of Reactive Programming course. It wasn’t easy one, at least for me.

I mean, first two weeks driven by Martin were clear and straightforward. Even first Erik’s week about Future was approachable. The rest -rxScala with it’s Observables and actor model with Akka was rather hard and required a lot of work. My conclusion: akka isn’t easy concept (contrary to all akka guides saying it is) maybe it’s easier to debug when things go bad comparing to standard java locking/synchronisation model but for designing it requires a lot of time and hard work to acquire that way of thinking.
Except videos on course pages I red other helpful materials like:

  1. Learning Concurrent Programming in Scala book by Aleksandar Prokopec
  2. The Neophyte’s Guide to Scala

and two cheet sheets dedicated for this course

  1. by sjuvekar
  2. by dnvriend

And good akka tutorials

  1. Concurrency and Fault Tolerance Made Easy: An Akka Tutorial with Examples by Diego Castorina
  2. Reactive twitter app with akka by Jan Machacek
  3. Implementing the Reactive Manifesto with Akka by Adam Warski – video

Maybe someday that materials would help you.

Posted

[Title might be misleading because you need to make somewhere that merge but let it your github/stash/bitbucket etc. do it for you]

Problem: When starting your adventure with git did you feel like not knowing what is going on and ending with deleting the repo and cloning once again? I wish to help you and show how to work with git without removal&clone again.

The idea comes from Advance Git video. If you want TL;DR carry on with reading.

Once upon a time my dear friend told me how to work with git. Since then I’m happy git user and then I saw above video confirming that way of work. Before that I was blandly merging, pushing, forcing and always left in conflict state. There are some rules worth remembering in this workflow style.
1. rebase only
2. always work on a branch, even if your projects doesn’t require it

That’s it. Have a pleasant life!

The first one keeps your history clean – one straight line, because while rebasing to any branch you “plug out” your commits, rewrite new commits (from branch you rebase against) and apply your commits on top of that!

 

My typical work flow with git:

  1. git clone [repo]
  2. git checkout -b dev – always work on a branch, let it be dev
  3. git add . & git commit -m "whatever" – commit changes, I prefer `git cola` for previewing and commiting my changes
  4. git push origin dev – if you want to make an pull request you need to push your changes to remote repo
  5. git checkout master – switch to master
  6. git pull --rebase – pull new commits to master, let your local master branch be always a copy of that remote
  7. git checkout dev – switch to dev
  8. git rebase master – apply changes from master to your branch, conflicts may appear here, but after resolving you are synchronized with current master
  9. git push origin dev:master – this pushes your commits from your local branch dev to remote master, instead of merge, or when working with PR let it github do merge
  10. git branch -D dev – delete branch, repeat the process

By “resolving conflicts” I mean edit that conflicted files manually and applying with `git add` them and git rebase –continue. After 8 step you can push your changes to remote repo and it will be easily merged into master, or locally you can switch to master and merge your dev branch as well.

Shortcut for steps 5-8:

  1. git fetch origin
  2. git rebase origin master – being on dev branch

Useful tools:

  1. for moving commits between branches use git cherry-pick

Squashing

I like squashing because it makes feature come in one commit, but this is quite controversial, most prefer to make a lot of smaller commits claiming that it will be easier to revert or spot a bug.

  1. after a few hours of work you’ve got 2 commits, go and squash them
    git rebase -i HEAD~2
  2. manage two steps
    1. you’ve been shown a history in reversed order so you mark `pick` first commit and mark `s` or `squash` the rest, save & quit
    2. on second screen you delete or comment out commit messages and leave just one
  3. you could refresh your master branch by pulling changes like in step 2., after that please get back to git checkout MyDevPolygon
  4. rebase your changes to master by git rebase -i master
  5. you will be shown your squashed commit ready for commits, if git tells you about any conflicts, you will have to resolve them but only once!

Sometimes people are working on branches to which they merge changes from master (acquiring new design)… in the end they go back with their work to master.

In this common case you might need to apply one of following scenarios:

  1. BEST: always keeping your changes on top – rebasing to master while working on feature branch
  2. when you messed smth up and git asks you to resolve same conflicts over and over go and use
    git rerere
  3. at the end squash your changes two one clean commit

I love this article git team workflow merge or rebase

Posted

I’ve been in Luxembourg on AWS training for developers. It was free. The agenda

Day 1: Getting Started

  • Working with the AWS code library, SDKs, and IDE toolkits
  • Introduction to AWS security features
  • Service object models and baseline concepts for working with Amazon Simple Storage Service (S3) and Amazon DynamoDB

Day 2: Working with AWS Services

  • Service object models and baseline concepts for working with the Amazon Simple Queue Service (SQS) and the Amazon Simple Notification Service (SNS)
  • Applying AWS security features

Day 3: Application Development and Deployment Best Practices

  • Application deployment using AWS Elastic Beanstalk
  • Best practices for working with AWS services

Maybe worth taking away was this security feature of giving and EC2 instance a ROLE, what would keep your source code clean of any secret credentials. (I still don’t know how to inject credentials into app without keeping them in source repository – automatically add credentials to system envs howto?)

Every module was ended with lab where we had to implement a solution for given AWS service. Everything was prepared very nicely.

The main drawback of this training was luck of lunch. I don’t know if this is common practise on west but in mine part of Europe it’s not. It seems just rude to me. We are paying high bills for their services and they can’t afford lunch on trainings?

Posted

This year – 2014 I had an opportunity to attend a few polish java related conference like: geecon.org, confitura.pl and warsjawa workshops.

From geecon I remember amazing talk but guys from plumbr.eu (amazing tools btw. I will definitely give it a try after I end with newrelic) – there are many videos on vimeo from this one. Although confitura was professionally organised as always I really don’t remember anything?

The best of all was the first day of warsjawa workshops. I’ve attended botsh Venkat Subramaniam’s workshop about concurrency (actors, stm – amazing book of Venkat) and groovy metaprograming. He is amazing. His voice is clear, he is being understood, he doesn’t mumble and he explains every detail. I could listen to his audiobooks recorded by himself.

This year I’ve also been on atmosphere conference organised by my previous employer. As I like people working there this conference this year was unfortunately unsuccessful. (I won entrance ticket on geecon). The tickets in normal order were too expensive ( 250 euro ) and talks were less professional comparing to geecon’s (except the guy from prezi about theirs continuos delivery).

 

Posted

Do you develop or maintain java web application and want to have your main system not polluted by any Apache tomcat server?

Or maybe you are digging in some legacy code with old java and on you main system is the newest shiny java 8 and you don’t want to switch every time? Go and use virtual box with vagrant. On hanskoff.github.io pages I put a post on how to automatically install and configure Apache tomcat server with one bash command.

Posted