Leading a remote team successfully is no easy task. It requires managers to put in a conscious effort to build up the team, lead the team and each individual as well as foster a positive and collaborative culture.
This puzzle was popularised recently and caused many people (especially in my immediate family) headaches. You've probably heard about it. I explain herein how to easily come to the solution for this puzzle and give an implementation in code.
I believe it is worthwhile to make a distinction between the two. In this post, I highlight the different strategies for determining whether to build a Minimum Viable Product (MVP) or a prototype. It is a conscious decision that needs to be made during the concept phase.
Many creative people (e.g. artists and writers) I know prefer to work on their own. In the technology space, in order to take a sizeable creative idea from inception to implementation, it usually takes a team of people collaborating closely together. It is through teamwork and a clear common vision that a creative concept gradually takes shape, with input from everyone in the team who has complementary skills.
I recently finished writing a Twitter bot that helps development teams using a proprietary agile planning tool to celebrate their wins by tweeting about completed stories. This small program had me exploring the parallelisation of simple tasks using the Future monad.
In a highly-available application, it is occasionally necessary to have some processing performed in isolation within a cluster, whilst still allowing for processing to continue should the designated worker node fail. This is trivial with Akka clustering support for the Cluster Singleton pattern.
Many years ago I was walking through the office when I passed a colleague talking to our manager. I overheard him as he was putting forward the case for using Ruby - "The great thing about dynamic[ly typed] languages is that they force you to write tests", he said. Because our manager was already committed to the importance of high test coverage, the idea of putting natural pressure on developers to write tests was probably quite appealing.
You have a scala library that others might find useful. You build it with SBT and you want to publish it to an online repository so that others can use it in their projects. Wonderful!
This post explains the process of publishing your project artefacts to the Sonatype OSSRH (Open Source Software Repository Hosting) Service.