At first glance, it may sound absurd. Here we have technical debt, a purely engineering problem, as technical as it can get, and another area, HR, dealing with psychology and emotions, put into one sentence. Is it possible that they are closely related? Let’s take it apart and see.

Exploring technical debt

What is technical debt, anyway? A tongue-in-cheek definition is that it is code written by someone else. But there is more to it – it is code written years ago, possibly by someone who has left the company. Also, every major piece of software is written incrementally over many years. Even if it started with a very detailed, well-thought-through design, there inevitably came plenty of modifications and additions which the original design could not easily accommodate.

Your predecessors sometimes had to cut corners and bend over backwards to achieve desired results in an acceptable amount of time. Then they moved on, someone else took over and so on.

What you now have is a tangled mess, mixing coding styles, techniques and design patterns, with an extra addition of ad-hoc solutions and hacks. You see a docstring like “temporary solution, TODO: clean up”, you run git blame and it is seven years old. It happens to everybody.

The business behind technical debt

Technical debt is a business issue. You can read about it in more detail in our previous post .

Source: Medium

The daily tasks of most developers are fixing bugs and implementing new features in existing code. The more messy and convoluted the code is, the more time it takes every time one has to read it and reason about it. And it is real money: according to McKinsey Report , this burden amounts to 20%-40% of an average business’ technology stack. Engineers are estimated to spend up to 50% of their time struggling with it.

So what can businesses do to get their code in check? Here are some suggestions:

• Taking a step back
• Reassessing the architecture and techniques
• Making more informed choices
• Rewriting parts of the code to make it consistent and understandable, removing unused code and duplications

Unfortunately, this is very rarely done, since it does not bring any visible improvements to the product – clients are not interested in code quality, they want software that does its job. Improving the code costs real money, while the increase in developer productivity is impossible to quantify.

Technical debt also has another property – it is annoying. And this brings us nicely to the second topic.

Happy HR, Happier devs

What is HR about? In part, it is about the well-being of employees. Every employer wants good people to stay in the company. The most valuable employee is someone who likes their job and feels good about the place. HR departments go to great lengths to achieve this.

But, you can buy new chairs and phones, decorate the office, buy pizza, organise board games evenings – all this is mostly wasted if the following morning your devs show up in their workplace only to say “Oh no, not this old cruft again”, embellishing that statement with a substantial amount of profanities.

Now I tell you this: Nothing makes developers happier than allowing them to address their pain points. Ask them what they hate the most about the codebase and let them improve it, the way they choose to, at their own pace. They will be delighted.

You may ask how I know. Firstly, I’m a dev myself. Secondly, I’m fortunate enough to be currently working for a company that took the steps and did exactly that:

Step 1: Set up a small “tech debt” team

Step 2: Collected improvement proposals from all developers

Step 3: Documented them

Step 4: Defined priorities

Currently, the technical debt team or the proposers themselves are gradually putting these proposals into action, one by one. The code is getting better. We are becoming more productive. And if we’re happy, isn’t HR?

Calling upon the compassionate and proactive HR professionals out there: talk to your CTOs, tell them you all are after the same thing – you want these frustrated, burned-out coders happy, enthusiastic and more productive, and that you have an idea of how to achieve this.

Chances are they will be interested.

The post Technical debt and HR – what do they have in common? appeared first on Erlang Solutions .

The ejabberd Docs website did just get a major rework: new content management system, reorganized navigation, improved markdown, and several improvements!

Brief documentation timeline

ejabberd started in November 2002 (see a timeline in the ejabberd turns 20 blog post). And the first documentation was published in January 2003, using LaTeX, see Ejabberd Installation and Operation Guide . That was one single file, hosted in the ejabberd CVS source code repository, and was available as a single HTML file and a PDF.

As the project grew and got more content, in 2015 the documentation was converted from LaTeX to Markdown , moved from ejabberd repository to a dedicated docs.ejabberd.im git repository, and published using a Go HTTP server in docs.ejabberd.im , see an archived ejabberd Docs site .

New ejabberd Docs site

Now the ejabberd documentation has moved to MkDocs+Material, and this brings several changes and improvements:

Site and Web Server:

• Replaced Go site with MkDocs
• Material theme for great features and visual appeal, including light/dark color schemes
• Still written in Markdown, but now using several MkDocs, Material and Python-Markdown extensions
• The online site is built by GitHub Actions and hosted in Pages, with smaller
  automatic deployment time
• Offline reading: the ejabberd Docs site can be downloaded as a PDF or zipped HTML, see the links in home page

Navigation

• Major navigation reorganization, keeping URLs intact so old links still work (only Install got some relevant URL changes)
• Install section is split into several sections: Containers, Binaries, Compile, …
• Reorganized the Archive section, and now it includes the corresponding Upgrade notes
• Several markdown files from the ejabberd and docker-ejabberd repositories are now incorporated here

Content

• Many markdown visual improvements, specially in code snippets
• Options and commands that were modified in the last release will show a mark, see for example API Reference
• Version annotations are shown after the corresponding title, see for example sql_flags
• Modules can have version annotations, see for example mod_matrix_gw
• Links to modules, options and API now use the real name with _ character instead of - (compare old #auth-opts with #auth_opts ). The old links are still supported, no broken links.
• Listen Modules section is now better organized
• New experimental ejabberd Developer Livebook

So, please check the revamped ejabberd Docs site, and head to docs.ejabberd.im git repository to report problems and propose improvements.

We are happy to announce the release of Smack 4.4.8, our XMPP-client library for JVMs and Android. For a high-level overview of what’s changed in Smack 4.4.8, check out Smack’s changelog

Smack 4.4.8 contains mostly small fixes. However, we fixed one nasty bug in Smack’s reactor causing an, potentially endless, busy loop. Smack’s new connection infrastrucutre makes heavy use of the reactor, that enables tausands of connections being served by only a handful of threads.

As always, this Smack patchlevel release is API compatible within the same major-minor version series (4.4) and all Smack releases are available via Maven Central .

We would like to use this occasion to point at that Smack now ships with a NOTICE file. Please note that this adds some requirements when using Smack as per the Apache License 2.0 . The content of Smack’s NOTICE file can conveniently be retrieved using Smack.getNoticeStream() .

1 post - 1 participant

Read full topic

Looking to learn more about the basics of RabbitMQ? This powerful message broker plays a key role in modern, distributed systems.

This post will break down its fundamentals and highlight its importance in the world of modern, distributed systems.

An introduction to RabbitMQ

RabbitMQ emerged from the need to create a scalable, robust messaging system that was able to handle high volumes of communications between applications, all while maintaining both data and performance.

It is now a popular open-source messaging broker, with queue software written in Erlang. One of its key strengths is its ability to support and adhere to Application Programming Interface (API) protocols, for example, AMQP, HTTP AND STOMP.

What are APIs you ask?

They define the rules and conventions that allow for the interaction and communication of different software. For developers, APIs are the go-between that allows them to access a software or services functionality, without the need for a full understanding of the ins and outs of that particular system.

In turn, these protocols offer a standard method of transmitting commands and data. The result? Seamless integration and interoperability between different systems.

Let’s circle back to one previously mentioned protocol, the Advanced Message Queuing Protocol or AMQP. This protocol was made to ensure that messages are reliably delivered between applications, no matter where the platform it is running on is located. AMQP has precise rules for the delivery, formatting and confirmation of messages. This ensures that every message sent through an AMQP-based system, like RabbitMQ, reaches its intended location.

Here’s an illustration better explaining the AMQP system:

Source: The Heart of RabbitMQ

What is RabbitMQ used for?

Developers use RabbitMQ to efficiently process high-throughput and reliable background jobs and facilitate the integration and communication between applications. It is also great at managing complex routing to consumers by integrating various applications and services.

RabbitMQ is also a great solution for web servers that require a rapid-request response. It also effectively distributes workloads between workers, handling over 20,000 messages per second. It can manage background jobs and longer-running tasks, for example, PDF conversion and file scanning.

How does RabbitMQ work?

Think of RabbitMQ as a middleman. It collects messages from a producer (publisher) and passes them on to receivers (consumers). Using a messaging queue, it then holds messages until the consumers can process them.

Here’s a better overview of these core systems:

Source: RabbitMQ tutorials

Key features of RabbitMQ

As one of the most powerful and flexible messaging systems, RabbitMQ offers several key features, including:

Security: Various security features in RabbitMQ are designed to protect systems from unauthorised access and potential data breaches. With authentication and authorisation support, administrators can control which users or applications have access to certain queues or exchanges. It also supports SSL/TLS encryption , to ensure clear communication between brokers and clients.

Reliability: Reliable message delivery by supporting features, such as message acknowledgement and persistent message storage.

Scalable and fault-tolerant: RabbitMQ provides features for building scalable and fault-tolerant messaging systems. It also supports clustering, whereby adding more nodes to the cluster allows the system to handle higher message volumes. It’s then able to distribute the workload across multiple nodes, making for efficient utilisation of resources. In the case of a node failure, other nodes in the cluster can continue to handle messages without interruption.

Extended features: RabbitMQ is not limited to the AMQP protocol, but is very versatile and can support a host of others, such as MQTT and STOMP.

Enterprise and the Cloud : RabbitMQ is lightweight and easy to deploy on the public as well as private clouds using pluggable authentication authorisation.

Tools and Plugins: RabbitMQ offers a host of tools and plugins , ideal for integration and wider support.

Common use cases for RabbitMQ

We’ve already highlighted the versatility of RabbitMQ in modern distributed systems. With its robust features and flexible architecture, here are some most common use cases:

Legacy applications: RabbitMQ integrates with legacy systems by using available or custom plugins. You can connect consumer apps to legacy apps for example, connecting JMS apps using the Java Message Service (JMS) plug-in and JMS client library.

Distributed systems: RabbitMQ serves as a messaging infrastructure in distributed systems. It fosters asynchronous communication between different components, facilitating the scalability and decoupling of the system.

IoT applications: When used in Internet of Things (IoT) applications, RabbitMQ can handle the exchange of messages between devices and backend systems, allowing for reliable and efficient communication, control and real-time monitoring of IoT devices.

Chat applications: For real-time communication in chat applications, RabbitMQ manages messaging exchanges between users, facilitating group chat and instant messaging functionalities.

Task/job queues: RabbitMQ manages task queues and distributes work across multiple workers. This means that tasks are processed efficiently and at scale, reducing bottlenecks and utilising resources.

Event-driven architectures: RabbitMQ is great for carrying out event-driven architectures.

It allows various system components to respond to events and seamlessly interact with each other.
Microservices communication: A common use of RabbitMQ is enabling asynchronous and reliable communication between microservices. Messages are delivered, even if some services are unavailable.

To conclude

As businesses seek to adopt distributed architectures and microservices-based applications, RabbitMQ remains a go-to choice for improved adaptability and seamless integration across systems. If you’d like to discuss how RabbitMQ can improve your applications, get in touch with the Erlang Solutions team.

The post A Guide to RabbitMQ appeared first on Erlang Solutions .

Harrier is our Military Messaging client. It provides a modern, secure web UI that supports SMTP, STANAG 4406 and ACP 127. Harrier allows authorised users to access role-based mailboxes and respond as a role within an organisation rather than as an individual.

You can find out more about Harrier here .

Server Administration and Monitoring

Harrier 4.0 adds a Web interface for server administrators to configure Harrier. Key points:

• Secure bootstrap
• Sensible defaulting of parameters to facilitate startup
• Per domain and global configuration options
• Security features, including TLS, HSM, S/MIME and Security Labels/Security Policy
• Full configuration of all Harrier options and capabilities

In addition to configuration, the Web user interface provides a monitoring capability to show server activity and key operational parameters.

UI Enhancements

A number of improvements made to the Harrier UI including:

• Variable size compose windows, retaining user preferences and stacking multiple windows
• HTML Message editing:
  • Font bold/italic/underline/colour
  • Lists and Bullets
  • Reply to HTML messages
• Undo and redo in message editor
• Organizations in from selection has configurable default and alphabetic sort.
• Active role shown on browser tab. Facilitates working with multiple roles in different tabs.
• Extended message search capabilities to include:
  • Filter by precedence
  • Free text search in choice of: body; subject; SIC; action; info; from

Security Enhancements

The following security enhancements added:

• Per domain S/MIME signing policy (never/if possible/always). Model is administrator choice rather than user selection.
• Policy control of using S/MIME header signing.
• Policy choice to alert users to unsigned messages.
• Policy choice to allow encryption.
• Policy choice of encryption by enveloping or triple warp.
• Message Decrypt on initial access. The primary goal of S/MIME encryption is end to end protection. Some clients leave messages encrypted, which can lead to problems over time if keys become unavailable or are changed. Decryption prevents these issues. Note that for triple wrap, the inner signature is retained.
  

Other Enhancements

• Server option to force user confirmation of message send (audit logged). Important in some scenarios to confirm message responsibility.
• Option to configure multiple address books in different directories.
• Revalidation of recipients before message release.
• Timezone option to be Zulu or Local.