Yesterday I realized that I write more about refactoring than implementation. To stay consistent today’s post is about…refactoring. Well, maybe not only about it, but mainly. In the previous week I finished following tasks:
- [F-4] Handling request result (response code, message)
- [F-8] Encapsulate logic from aksesi-gesture.js into a class
- [F-9] Secure initialization
- [P-1] Forwarding requests to an authentication endpoint
The 8th version of Java introduced a few really cool features. My favorites are streams and, connected with them, lambda expressions. In this article, I’ll show you some examples of refactoring existing code into the more modern version. All of the examples, except the 1st one, were inspired by the Aksesi Proxy source code.
Almost all of us use GitHub on a daily basis. We usually work with it in two ways. Firstly, as a version control system which helps us to develop applications. Secondly, as a library of projects written by other programmers. Sometimes we use their code in our applications. Today I want to show you that GitHub is a multidimensional tool and can be used for things not necessarily connected with coding.
At the beginning of this week, I took part in the lecture about fast coding with IntelliJ. Its main goal was to show participants that they can speed up development with tools which are available in IntelliJ IDEA. This event inspired me to write a post about my experience with working with different IDEs, especially IntelliJ.
Today’s post is a brief summary what has changed in recent days. Especially, at the weekend. As I explained in the previous post, I changed my workflow. Now I’m working in the task-oriented flow, with branching system on the GIT. Not only can you follow it with the Github repository but also with the Trello board.
I like working when I have any kind of schedule or just list of things that I’m expected to do. This is why I decided to spend some time on planning Akesi’s development. I had a feeling that the application had been developed in chaos because I didn’t have any plan. After each of posts, I was making a decision what I should implement in the upcoming days. I think that it is one of the reasons why I’m providing new features so slow.
It took me almost one month to recognize where is the problem and how I should solve it. The reason was obvious – lack of a plan. The solution is a little bit harder to implement.
Recently I spent some time thinking about the Aksesi project. I have made some decisions that I’m going to cover in the next post. The very first thing on my list was to remove all of the TODOs from the code and refactor awful parts. In this post, I’m going to show you what I’ve changed in last few days.
If you are following my blog then it is obvious for you that I’m programmer. Not all of you know that I’m also an amateur runner. I have been running for almost 5 years of which 3 years of racing (except 2016). I have run a lot of 10km races, several half-marathons, and a few marathons. In this posts, I’m going to show you where I have found a connection between running and programming, and how they affect each other.
In the “At the red-green-refactor carousel – implementing conversion unit” post I described how I have developed basic functionalities for conversion unit. I also mentioned that there is no Spring Framework integration and why I decided to implement CU in that way. In the following post, I’m going to show you this mystic integration process.
It’s been a week since the last post. In the following one, I’m going to summarize you what I’ve changed it the Aksesi since then. I decided to refactor some parts of the frontend application. Moreover, I managed to simplify installation and configuration process. The major part of integration is done “in the background” and a user does not have to care about it.