This year I’ve started working with Amazon Web Services (AWS) and most notably AWS Lambda. It’s awesome what Amazon is providing here! It’s cheap, easy to start with when using SAM – Serverless Application Model and easy to integrate with other services. But there are also downsides (which were also discussed a lot on HN). Just to name a few: a) logging is a mess, b) debugging is not possible at all or c) CPU power only comes with more memory. Though I can’t change b) and c), I could do something for a). Furthermore it was also a pain for me to update the Lambda code quickly, because I am using CloudFormation. A CloudFormation update takes a lot of time and summed up to 2:30 min for every update in my case – not acceptable for just changing one line of code. Therefore I decided to write some small CLI tools to overcome the logging problem and code updates with AWS Lambda.
A few years ago, Amazon Web Services (AWS) launched it’s new service AWS Lambda. Since its start the service is generating more and more interest for the whole world of serverless computing. I’ve also started using it this year and today I want to share 5 things with you what I think is important when developing such functions.
Recently I was facing a difficult situation: me and my team we’re working on a feature (using Feature Branch Model) and I wanted to rebase my code to the changes on another branch. Nothing special so far. But the problem was that there were several conflicts because we’ve changed code at similar lines. After finishing the rebase and making a push force to the upstream, I’ve realised that I’ve made a small mistake when resolving the conflicts. Well, the problem was that I’ve selected the wrong changes which should be applied. But reverting by just checking out my old changes and doing the rebase again was obviously no option. Therefore I want to share my experience with you in this blog post and give you a process how to revert such rebasing errors.
This summer I’ve discoverd the website IndieHackers.com which interviews “hackers” who’ve started their own businesses (or side-projects) and earn money from it. It’s really inspiring how many ideas people have and how they have realised their passion projects. Also quite nice is the fact that they have to share how much money they earn. So you as a reader can see the relation between the effort the hackers have invested in their project and which outcome it produces. Today I’d like to share three of these hacker projects which have inspired me the most. All projects have in common that they’re automating a process in a remarkable way which is quite interesting to see.
Recently I had to work with OSM data at University and we had to provide the data by visualising them with JMapViewer. It’s a small project which supports you to connect your OSM data with a Java Swing application. For example this is useful for user interactions when calculating routes with OSM data. So I started investigating the project and found their documentation: http://wiki.openstreetmap.org/wiki/JMapViewer It just gives a quick overview of the project, but no nice starting guide. Therefore I want to provide such a (short) tutorial here.
Recently I was building a private hobby project where I wanted to use Heroku to deploy some Microservices and get some experience with it. Since I’m a Java enthusiast, I wanted to use a Multi-Module Maven project to also share some classes to the different microservices. So my mission was to deploy each submodule to a different Heroku app (I know this is completely against the nature of Microservices to code them all in the same language and have them in one big project like a Monolith – but I have my reasons). Getting started with Heroku was quite simple, because they have a very nice guide to setup and run your first app in the cloud. Unfortunately Heroku only supports one Procfile per project, therefore it’s not so easy to deploy multiple submodules to it. But there is way: You can use Config Variables. Let’s see step by step how to use this!
JIRA is a great issue tracking software by Atlassian and it offers many features to keep your bugs and tasks organised. However, if you’re using it for a while and your project grows bigger and bigger, it can get quite difficult to stay updated on your issues. What I mean is you can’t keep track of all new issues by yourself. Especially if you have a public JIRA instance where all of your customers can add issues. So let’s see what JIRA offers to you in order to support your wish to get the newest issues of your project. Continue reading
Some time ago I had to test a web app where a popup was triggered if the user hovers over a specific link. This is not as easy as testing if an element contains a specific text. But it’s possible using Selenium Actions. These class provides methods to perform some custom gestures on a page, like moving to an element. Here is an example how to do this: Continue reading
Since I’m working with Atlassian Confluence addons, I always have the problem that I need to start a local Confluence standalone instance in a specific version. This is often annoying, because you always have to download the zip file, unzip it and adjust some settings files (of course you can use the Atlassian Plugin SDK, but this has some drawbacks if you want to reproduce bugs). For example you have to add a home directory where Confluence stores the application data or add a line to be able to debug the Confluence addon you’re developing. The way I did it was very error prone, because I had to follow a few steps manually. Then a few weeks ago I got the idea to create a script for it. The problem was/is: I don’t like native bash/shell scripts that much. So what’s the alternative? I decided to create a NodeJS module using some external libs and provide a command line tool. Make sure to check out the project and test it: confluence-starter Bitbucket Repository.
With the confluence-starter CLI you can select a Confluence version which will be downloaded, unzipped and prepared in terms of developer settings like (debug) port, application context path, batching, minification, etc. and it will be started automatically:
# Downloads, unzips, prepares and starts Confluence instance on default port 1990
$ conf-starter start 5.9.6
You can also set some other settings by adding optional parameters to the command or list the already downloaded versions:
# add optional parameters: port, context path and debug port
$ conf-starter start 5.9.6 -p 1991 -c /conf -d 5005
# list already downloaded versions
$ conf-starter list
# clear home directory of a downloaded version
$ conf-starter clean 5.9.6
If you have any problems, please raise an issue in the repository. The next step is to push it to NPM and also create a GUI for it, so wait for an update! 🙂