Change is required. Atlassian engineer's blog

  During the tough times of the Covid-19 pandemic, I got a request from the Atlassian community to help with a Jira performance issue. Surprisingly, the solution was simple: removing an unused custom field in the default settings improved the performance for many projects. In this article, I’ll explain how this small change made a big difference. The Problem In 2020, as everyone adjusted to remote work and more online activities, users saw a big slowdown in many system, as on-prem Jira’s performance. The cause was hard to find, causing frustration. Error Analysis After adjusting logging level for all dedicated package (still unclear why package com. was only FATAL level), and x Upon delving into the logs, it became evident that there was an overwhelming number of errors linked to a particular custom field. This field, VIM: auto (customfield_16204), was part of the Jira Misc Custom Fields (JMCF) plugin. A typical log entry looked like this: 2020–07–30 13:45:19,458+0300 http-nio-8080-exe

  Maintaining a clean and efficient Jira installation, especially in an On-Prem setup, involves meticulous data management. A common issue faced by administrators is the duplication of history records for assets in Jira, which can lead to database bloat and performance issues. Duplications often stem from situations such as stuck imports, automated processes running recursively, or incorrect manual imports. This article will guide you through the process of detecting and cleaning up duplicated records, with an emphasis on solutions contributed by the Jira community. Understanding the Issue Duplicated history records can severely impact the performance of your Jira instance. As history records accumulate, database queries slow down, and system memory usage increases disproportionately. In one notable case, duplications reached a staggering 52 million records, prompting an urgent need for cleanup. Detecting Duplicated Records Artem Tumanov, a valuable contributor to the Jira community, h

  In the intricate world of software protection and cybersecurity, VMProtect holds a prominent place. This software protection tool, known for its use of virtualization technology, is designed to obscure and secure executable files from reverse engineering and tampering. However, even the most sophisticated protection methods invite scrutiny and analysis. In this review, I explore the intriguing and innovative  VMProtect-devirtualization  project by Jonathan Salwan and evaluate how it can significantly assist in uncovering bugs and vulnerabilities in protected game software. Thread emulation by x64unpack (x64Unpack: Hybrid Emulation Unpacker used for VMProtect analysis) What Makes VMProtect Stand Out? VMProtect is widely acclaimed for its robust approach to software protection. By converting executable code into a unique virtual machine language, it ensures that the protected code is extremely difficult to interpret or modify. This layer of virtualization acts as a formidable barrier a

While most of us enjoy the casual work environment that Slack offers, including the fun avatars we upload, sometimes not everyone is on board, and some might even forget to upload their avatar. I was recently tasked with a fun and intriguing project: to identify who didn’t upload a Slack avatar or uploaded a non-human face. This was just a one-time request, but for me, it turned out to be an exciting journey into the world of face detection technologies. (All lab data is there:  https://github.com/gonchik/face_recognition_slack ) The Face Detection Showdown To get the job done, I decided to compare three different libraries:  face_recognition ,  dlib , and  opencv-python  (commonly abbreviated as cv2). Each of these libraries has its strengths, and I was curious to see which one would perform best in accurately detecting human faces in Slack avatars. face_recognition The face_recognition library is known for its simplicity and high accuracy for face detection and recognition tasks. It’

Managing your Atlassian Bamboo Remote Agents can be a breeze once you understand the initial setup and the commands needed to control the service. Let’s dive into the process of getting your agent up and running and explore how to manage it effectively. Initial Run and Setup Scripts When you run your agent for the first time, it generates control scripts to handle the installation and service management. To start the agent, use the following command, making sure to replace <Bamboo Base URL> with your Bamboo server’s base URL: java [parameters] -jar atlassian-bamboo-agent-installer- X . X - SNAPSHOT . jar < Bamboo Base URL >/agentServer/ [console] Stopping the Agent There might be times when you need to stop your remote agent. To do this, you can identify the process and force it to terminate using the following commands: ps aux | grep -i bamboo | awk '{print $2}' | xargs kill - 9 Installation Directory Move to the directory where the Bamboo agen