Today I decided to reorganize my GitHub repository. In the past, I added a lot of learning projects there and as time passed by, it was growing considerably. Since I currently have some work-related projects there, I thought it deserved some reorganization.
My idea was to consolidate some of the larger projects I had into a single repository where each component is a sub-module of the project. This was a rather natural choice because most of those projects are written in Java and use Maven, therefore being very easy to refactor into a module-based project layout.
One requirement I had was that I wanted to retain the commit history. After looking at some solutions involving git’s submodule or subtree features, I found one that was fairly simple. The process couldn’t be simpler: you have to add the projects as remote to your new project and run a couple of commands to merge, move and commit the files.
Additionally, since my projects usually follow the same standard, it was quite simple to automate. After running the initial steps to configure the new (consolidated) repository, I was able to run the mass import using the following command line:
formodule in$(echo"project1 project2");dogit merge-m"Merged $module master for repository reorganization"$module/master;mkdir$module;(forfile in$(echo"README.md pom.xml src test");do[[-e$file]]&&git mv$file$module/;done);git status;git commit-m"UPD: moved $module old files from a separate repo to a separate module".;done
I was even able to import the old branches for each of the sub-components I wanted to merge.
Just sharing some messaging tools I have been working with recently.
The first one is this performance test tool: msg-perf-tool. There’s no secret here: you run the tool and it does its best to bring your messaging system to its knees (though this may not be the correct way how to test it … check the testing tips on the Github page). For now it supports only AMQP, but Stomp and MQTT support is on the way. You can find rpms for RHEL/Centos (6 and 7) and Fedora (22, 23 and 24) for i686 and x86_64 on my Copr profile here.
The second one is a web page that can display the performance data stored on an ElasticSearch database and present it in a beautiful way. I call it messaging performance center. Here’s how it looks like:
Some bits are still in progress, but it’s functional.
Lastly, there’s litestomp. A C implementation of the Simple (or Streaming) Text Oriented Messaging Protocol. It was built on top of what-seems-to-be the now defunct libstomp project. There’s a couple of bugfixes, a simpler and higher level API for ease of use. Still a work in progress, but you can download the current rpms for RHEL/Centos (6 and 7) and Fedora (22, 23 and 24) for i686 and x86_64 from my Copr project page on this link.
For the most part of my professional life I worked as an IT Specialist in Brazil. An IT specialist is a professional that designs, develops, employs or maintains information technology systems. It is a pretty broad term that may encompass several different different job roles (from database administrators to software engineers to production support analysts). In my case, I was engaged with 2 primary activities: software development and application architecture.
All of that changed 3 months when I left my IT Specialist job in Brazil and moved to Czech Republic to work as a Software Quality Engineer (aka Quality Engineer) for Middleware Messaging products. Since then, a few friends had come to me to ask: a) what I am doing, b) what exactly a Quality Engineer does and c) do you write code. With that said, I think I have answered question ‘a’. Since question ‘a’ is already answered, let me explain what is a Software Quality Engineer (SQE) and it does.
A SQE is a specialized type of engineer that works on all phases of development to design, develop and execute tools, process and strategies to ensure that software products meet or exceed desired levels of quality (with quality being defined as the degree of excellence of an item or product).
A SQE usually:
Design, develop and maintain tools to perform automated testing
Develop and maintain automated test cases
Elaborate and implement Continuous Integration (CI) and Continuous Delivery (CD) strategies including its infrastructure and support tools
Help to investigate and verify security issues
Elaborate and execute test plans
Define and implement software quality metrics and design, develop and maintain tools to collect them
Review product documentation
Whether an SQE writes code depends on what type of products it works with. For example, in my case I work with tools for messaging and enterprise application integration, therefore I tend to write code quite frequently, as most of these products are used by software developers, IT specialists and IT architects to integrate disparate systems.
Ever hoped for an easy way to run embed brokers and simulate a full cycle JMS messaging cycle? Well, this pet project of mine may be useful for you (or, at least, give you an idea for an implementation). It works on top of JUnit, by providing a JUnit test runner, a JMS provider, a set of JMS-related annotations that will inject object instances and additional utility classes to simplify dealing with JMS. At the moment it works only with ActiveMQ, but adding additional providers should be fairly easy.
Here’s example of the a test class that sends and receives data through an embeddable ActiveMQ broker: