Tag: software

Cum a apărut worklog.ro: un tool intern care a devenit produs

La bitGloss nu ne-am propus niciodată să construim un produs doar ca să avem un produs.

worklog.ro a apărut dintr-o nevoie foarte practică: să ne organizăm mai bine munca, să urmărim timpul investit în proiecte și să putem genera rapoarte fără să ne adaptăm permanent după limitările altor aplicații.

Și, ca multe produse bune, a început ca un tool intern.

Problema pe care încercam să o rezolvăm

În teorie, problema era deja rezolvată.

Existau și există multe produse mature pentru time tracking și project management. Am folosit și noi astfel de soluții. JIRA era prezent în ecosistem, iar o perioadă am folosit și YouTrack instalat pe infrastructura proprie.

Dar apăreau constant mici probleme:

  • unele fluxuri de lucru nu se potriveau modului nostru de lucru;
  • raportarea nu era suficient de flexibilă pentru ce aveam nevoie la acel moment;
  • modelul de cost nu era întotdeauna convenabil;
  • trebuia să combinăm mai multe unelte pentru ceva ce, în esență, voiam să fie un proces unitar.

Nimic dramatic.

Doar suficient de multă fricțiune încât să ne întrebăm: dacă tot adaptăm procesele după tool, de ce să nu construim exact ce ne trebuie?

Așa a apărut prima versiune worklog.

Prima versiune: strict pentru noi

Inițial nu exista intenția să devină produs.

Aveam nevoie de ceva simplu:

  • logare de ore;
  • organizare pe proiecte;
  • generare de rapoarte;
  • administrarea accesului pentru echipă.

Frontend-ul inițial a fost construit în ClojureScript.

A funcționat bine și ne-a permis să iterăm rapid. Dar pe măsură ce aplicația a crescut și utilizarea a devenit zilnică, am început să observăm un lucru important: frontend-ul era întreținut de o singură persoană.

În acel context, viteza de dezvoltare conta, dar controlul calității conta și mai mult.

Așa am decis să migrăm frontend-ul către Elm.

Motivul nu a fost „tehnologie nouă” sau dorința de rescriere. Motivul a fost unul foarte pragmatic: Elm mută foarte multe categorii de erori în etapa de compilare. În practică, asta înseamnă mai puține bug-uri care ajung în producție și mai puțin efort de validare manuală.

Pentru o aplicație întreținută eficient de o echipă mică, asta s-a dovedit o alegere foarte bună.

Câțiva ani de utilizare reală

Nu există test mai bun pentru un produs decât să depinzi de el.

Ani la rând am folosit worklog exclusiv intern.

Fiecare neajuns ieșea imediat la suprafață.

Dacă un raport dura prea mult să fie generat, îl simțeam.
Dacă lipsea o funcționalitate, apărea rapid în backlog.
Dacă ceva era greoi, nimeni nu evita problema.

În perioada aceea am trecut prin mai multe iterații și am rafinat produsul continuu.

Momentul în care am renunțat la Excel

Până în 2021, facturarea noastră se făcea încă prin Excel.

Funcționa.

Dar doar în sensul că orice proces manual „funcționează” până când devine suficient de enervant.

Generarea facturilor era repetitivă, predispusă la greșeli și consuma timp inutil.

În 2021 am generat prima factură direct din worklog.

A fost unul dintre momentele în care am realizat că produsul începe să rezolve mai mult decât problema inițială de time tracking.

Pur și simplu era mai simplu.

Legislația a schimbat direcția produsului

Între timp, cadrul fiscal din România s-a schimbat.

A apărut necesitatea integrării cu SPV și e-Factura.

În loc să tratăm asta ca pe încă un tool separat, am ales să integrăm fluxul direct în platformă.

Astfel, worklog a început să lege natural:

ore lucrate → raportare → facturare → transmitere.

Când ne-am dat seama că nu suntem singurii cu problema asta

După ani de utilizare internă, a devenit clar că modelul nostru nu era deloc unic.

Existau mulți oameni și multe firme care funcționau similar:

  • freelanceri;
  • PFA-uri;
  • SRL-uri mici;
  • agenții;
  • echipe care facturează la oră;
  • firme care lucrează atât cu clienți români, cât și internaționali.

Toți aveau nevoie de aceleași lucruri:

  • time tracking;
  • rapoarte;
  • facturare;
  • integrare cu cerințele fiscale;
  • administrare fără complexitatea unei platforme enterprise.

Atunci am decis să deschidem worklog.ro și către exterior.

Nu ca idee de startup.

Ci ca produs validat deja prin ani de utilizare internă.

Funcționalități care au apărut din utilizare reală

Pe parcurs am adăugat funcționalități care au rezolvat probleme concrete:

Integrare GitHub
Posibilitatea de a loga ore pornind de la commit-uri extrase direct din GitHub.

Integrare JIRA
Logarea timpului pornind de la tichetele existente.

Arhitectură multi-tenant
Fiecare cont are:

  • un administrator;
  • unul sau mai mulți utilizatori;
  • proiecte separate.

Administratorul este și el utilizator — poate loga ore ca oricine altcineva — dar are responsabilități suplimentare:

  • generare facturi;
  • management proiecte;
  • management utilizatori;
  • asocieri între utilizatori și proiecte;
  • controlul accesului în diferitele module.

Modelul a fost construit după cum funcționează firme reale, nu după cum arată un demo.

De ce publicăm povestea asta

Există multe produse care promit multe.

Noi preferăm altă abordare.

worklog.ro nu a fost construit pentru a intra pe o piață.

A fost construit pentru că aveam nevoie de el.

Faptul că astăzi este disponibil și pentru alții este doar continuarea firească a unei aplicații pe care am folosit-o ani întregi înainte să o prezentăm public.

Is Your Tech Stack Appropriate or Are You Just Trying to Be Fancy?

When a software project starts struggling, the first instinct is often to blame the code.

But in many cases, the real problem sits one level higher: the architecture and technology choices themselves.

We’ve seen systems built around microservices long before they had enough scale to justify them. We’ve seen multiple frontend frameworks living in the same application. We’ve seen message queues, event buses, service meshes, and orchestration layers solving problems that didn’t actually exist.

The result is predictable: development slows down, debugging becomes harder, onboarding takes longer, and every new feature costs more than it should.

The challenge is that it’s difficult to evaluate an architecture from diagrams and presentations alone.

We Don’t Start With Opinions

Before we assess your technology stack, we need to understand it.

That’s why we don’t begin with a slide deck full of recommendations. We start by working inside your system.

We fix bugs. We implement features. We deal with the same constraints your team deals with every day.

This hands-on involvement gives us a realistic understanding of how your application behaves in production, how your development process works, and where complexity is helping versus hurting.

Only after we’ve worked within your codebase do we form conclusions.

The Questions We Try to Answer

Is your Spring microservices architecture genuinely supporting your scale and organizational needs?

Or would a simpler modular monolith allow your team to move faster?

Are those message queues providing real business value?

Or are they introducing operational complexity that could be replaced by straightforward API communication?

Do you actually need multiple frontend frameworks?

Or are they creating fragmentation, duplicated knowledge, and inconsistent user experiences?

Most importantly:

What complexity is essential, and what complexity is self-inflicted?

An Honest Technical Assessment

After gaining real experience with your system, we’ll give you a straightforward assessment.

If the current architecture makes sense, we’ll tell you.

If parts of it are over-engineered, we’ll explain exactly why.

We’ll identify components that can be consolidated, technologies that can be removed, and areas where complexity can be reduced without sacrificing business capabilities.

Our recommendations are practical and grounded in experience with your codebase—not architectural fashion trends.

Simplicity Is Often a Competitive Advantage

Technology teams rarely suffer because they have too little complexity.

More often, they suffer because complexity accumulates faster than business value.

Every service, framework, integration point, and infrastructure component carries a maintenance cost. Over time, those costs compound.

The best architecture is rarely the most sophisticated one.

It’s the one that solves today’s problems while remaining easy to understand, maintain, and evolve tomorrow.

That’s what we help our clients achieve.

Not more technology.

The right amount of technology.

Every architecture decision has a cost.

If you’d like an honest assessment based on real hands-on work – not diagrams – we’d love to hear about your project.

bitgloss.ro

How We Stopped a Legacy JBoss System from Slowing Down Delivery

At bitGloss, we often work with systems that businesses still depend on heavily, but that very few teams still fully understand.

One common pattern we encounter is enterprise infrastructure that was designed for a very different era of software engineering: large application servers, highly abstracted deployment models, and operational complexity that slowly becomes impossible to justify.

Recently, we helped a client modernize an aging distributed JBoss environment running on AWS.

The Problem: Enterprise Complexity Without Enterprise Benefits

The client’s platform relied on a clustered JBoss architecture that had gradually turned into a maintenance bottleneck.

The environment:

  • Complex XML-based server configuration
  • Custom classloader hierarchies
  • Specialized deployment descriptors
  • Distributed session replication setup
  • Cluster coordination management
  • JBoss-specific operational knowledge

In theory, these application server capabilities offered flexibility and scalability. In practice, most of the advanced enterprise features were barely used.

What remained was mostly operational overhead.

Deployments were slow and fragile. Memory usage was unnecessarily high. Troubleshooting required specialized knowledge that fewer engineers still possess today. Even simple upgrades became risky because the platform depended on behaviors tightly coupled to the JBoss runtime.

The infrastructure had effectively become legacy middleware.

The Real Cost of Legacy Middleware

This is a pattern we see frequently in older enterprise systems.

The issue usually isn’t that the application itself is obsolete. Often, the business logic is still valuable and stable.

The real problem is the operational surface area surrounding it.

Older enterprise stacks tend to accumulate:

  • Vendor-specific deployment models
  • Overengineered runtime abstractions
  • Fragile configuration layers
  • Tooling that fewer engineers understand each year
  • Infrastructure dependencies that slow down delivery

Over time, the organization ends up spending more effort maintaining the platform than improving the product.

The Migration Strategy

Rather than attempting a risky full rewrite, we focused on reducing infrastructure complexity while preserving application behavior.

We migrated the platform from JBoss to lightweight Tomcat instances.

The migration included:

  • Refactoring deployment descriptors to standard servlet specifications
  • Eliminating complex EAR packaging
  • Simplifying deployments to standard WAR artifacts
  • Removing unnecessary application server dependencies
  • Reducing runtime-specific configuration requirements

The goal was not simply “moving servers.”

The goal was operational simplification.

The Outcome

The results were immediate and measurable:

  • Deployment times reduced by 75%
  • Memory footprint reduced by 40%
  • Operational troubleshooting became dramatically simpler
  • Infrastructure became easier to automate and maintain
  • The client was no longer dependent on increasingly rare JBoss expertise

Most importantly, the operations team could stop fighting middleware and focus again on delivering business value.

Legacy Modernization Does Not Always Mean Rewriting Everything

Many organizations assume modernization requires rebuilding entire systems from scratch.

In reality, some of the highest-impact improvements come from simplifying the infrastructure layers around existing applications.

Replacing heavyweight legacy middleware with lightweight, standardized components can significantly reduce operational risk, infrastructure cost, and maintenance burden — without disrupting core business functionality.

That is often where the fastest return on investment exists.

At bitGloss, we specialize in exactly these kinds of legacy modernization projects: untangling complex systems, reducing operational friction, and helping businesses regain control over infrastructure that has become difficult to evolve.

Is Your Website Going Down Right When You Need It Most?

There are few things more damaging to a business than an application that becomes unresponsive exactly when traffic peaks. Not during quiet hours, not in the middle of the night — but during a product launch, a marketing campaign, or the busiest trading period of the year. The timing feels cruel, but it’s not a coincidence. Peak load is precisely when hidden architectural problems surface.

This is the story of one such system, and what was actually causing it to fail.

The architecture that looked fine on paper

The infrastructure in question was built on Azure and, by most measures, looked solid. Redis was in place as a caching layer to reduce database pressure. The database itself was properly indexed. Servers had comfortable headroom on both CPU and memory — no resource exhaustion, no obvious bottlenecks. On a quiet afternoon, everything worked beautifully. Response times sat around 200ms, well within acceptable range.

Then peak traffic would arrive. Response times would climb from 200ms to 2 seconds, then 5, then 10. Eventually the application would stop responding altogether. And then, as traffic subsided, it would recover on its own — as if nothing had happened.

This pattern is particularly disorienting for engineering teams. The system heals itself, so there’s no crash to investigate, no error log with a clear smoking gun. Just a recurring window of failure that’s hard to reproduce and even harder to explain.

Why the obvious suspects weren’t guilty

The natural instinct when an application slows under load is to look at the most visible resources: CPU, memory, database query times. All of them were fine. Redis, the caching layer specifically designed to handle this kind of load, was responding in microseconds. The database wasn’t under unusual pressure. The servers weren’t breaking a sweat.

This is where many investigations stall. If the database is fine, Redis is fine, and the servers have headroom — what’s left?

The answer was in a place most teams don’t think to look: thread pool metrics and connection pool utilization.

The actual problem: threads waiting for nothing

Modern web applications handle concurrent requests using thread pools — a fixed set of worker threads that process incoming requests. When a request comes in, it gets assigned to an available thread. If all threads are busy, the request waits in a queue.

The application was running with default thread pool settings. Those defaults are reasonable for low-to-moderate traffic, but they set a relatively low ceiling on how many threads are available at any given moment. Under normal load, there were always enough threads to go around. Under peak load, every thread was occupied — not doing heavy work, but waiting. Waiting to make a call to Redis. Waiting for a Redis response that would arrive in microseconds.

Here’s the paradox: Redis was fast. The problem wasn’t Redis performance. The problem was that the threads making Redis calls were blocking while they waited, even for those microseconds, and there weren’t enough of them to keep up with the incoming request volume. Requests piled up in the queue. Response times climbed. Eventually the queue filled and the application became unresponsive.

The infrastructure was fine. The bottleneck was a configuration default that nobody had revisited since the system was first deployed.

What the fix looked like

The solution involved three targeted changes, none of which required re-architecting the system.

Thread pool reconfiguration. We analyzed the expected concurrent load and pre-allocated a sufficient number of worker threads to handle peak traffic without queuing. This meant the application could process many more simultaneous requests without threads blocking each other.

Proper connection pooling for Redis. Related to the thread problem was how connections to Redis were being managed. Without a proper connection pool, the application was creating and tearing down Redis connections more frequently than necessary, adding latency and overhead to every cache interaction. A well-configured connection pool meant connections were reused efficiently, and Redis calls became as fast as they should have been all along.

Monitoring for thread pool utilization. Perhaps as importantly as fixing the immediate problem, we added visibility into thread pool metrics going forward. CPU and memory graphs are standard in most monitoring setups. Thread pool saturation almost never is — which is exactly why this problem had gone undetected for so long. If thread pool utilization starts climbing toward its ceiling, the team now knows before users feel it.

The results

Response times stabilized at under 300ms even during peak traffic periods. The infrastructure was able to handle five times the previous concurrent load without degradation. The underlying hardware, the database, and Redis itself didn’t change. Only the configuration did.

What this means for your team

If your application behaves well under normal conditions but degrades or fails under peak load, the problem is almost certainly not the thing you’re measuring most. CPU and memory are easy to monitor, so teams watch them closely. Thread pools, connection pools, and queue depths are harder to instrument, so they go unmonitored — and that’s precisely where these failure modes hide.

Before reaching for more servers or a bigger cache layer, it’s worth asking: do we actually know what’s happening inside our application at the thread level during peak load? In most cases, the answer is no. And in many cases, that’s where the answer is.

Infrastructure problems are rarely about infrastructure. They’re about configuration, visibility, and knowing where to look.

At Bitgloss, we help engineering teams find the real cause of performance failures — not just the obvious suspects. If your application is struggling under load, get in touch.

Is Your Database Slow? Probably Not.

Nine times out of ten, when an engineering team starts complaining about “slow database performance,” the database itself is perfectly fine. The real culprit is almost always hiding somewhere else — in the way queries are written, in how the application accesses data, or in decisions that made sense at the time but were never revisited as the system grew.

This distinction matters more than it might seem. If you assume the database is the problem, you start looking at hardware upgrades, migration to a “faster” database engine, or expensive infrastructure changes. All of that costs time and money — and probably none of it will fix the actual issue.

The symptom everyone misreads

A slow application feels like a slow database. A page that takes five seconds to load, a report that times out, an API endpoint that keeps failing under load — these all point fingers at the database layer. But the database is usually just doing exactly what it was asked to do. The problem is what it was asked to do.

We’ve seen queries that took literal minutes to complete, not because the server was underpowered, but because they were missing proper indexes, performing full table scans on millions of rows, or doing complex joins in the wrong order. In one real case, a reporting query was joining five tables with no indexes on any of the join columns — and then passing the entire result set back to the application to be filtered in code. The database was faithfully returning millions of rows that would eventually be narrowed down to a few hundred. It was working extremely hard to accomplish something that should have been trivial.

What’s actually going wrong

There are a handful of patterns that cause the vast majority of database performance problems:

Missing indexes on join and filter columns. When a query runs a WHERE clause or a JOIN on a column with no index, the database has no choice but to scan the entire table to find matching rows. On a table with a few thousand rows, this is fast enough that nobody notices. On a table with a few million rows, it becomes a bottleneck that grows worse every week as data accumulates.

Filtering in application code instead of in the database. This happens when developers pull a large dataset and then loop through it in the application to find what they need. The database does more work than necessary, more data travels across the network, and the application spends time on logic the database could handle in a fraction of a second.

N+1 query patterns. This is one of the most common and most damaging patterns, especially in applications that use ORMs. Instead of fetching related data in a single query, the application fires one query to get a list of records, then fires a separate query for each record to get its related data. Fetch a list of 200 orders? That’s 201 database queries. At scale, this silently destroys performance.

Joins ordered by convenience rather than efficiency. The order in which tables are joined can dramatically affect how much work the database needs to do. Starting a join with a large, unfiltered table and narrowing down later means the database is carrying a heavy load through most of the operation. Reordering joins so that the most selective conditions are applied early can cut execution time significantly.

What a proper fix looks like

When we analyzed the execution plans on the slow queries described above, the path forward became clear quickly. Execution plans show you exactly how the database is processing a query — which indexes it’s using (or not using), how many rows it’s scanning at each step, and where the time is actually being spent. Most teams never look at them.

The changes we made were not dramatic. We added indexes strategically on the columns used in WHERE clauses and JOIN conditions. We rewrote the join order to match the actual selectivity of each table. We moved filtering logic from application code into proper WHERE clauses. And we replaced N+1 patterns with proper JOINs or batch fetches.

The results were. Queries that previously took two to three minutes now complete in under 100 milliseconds. The database hardware didn’t change. The database engine didn’t change. Only the way the queries were written changed.

What this means for your team

If your application is feeling sluggish and the database is getting the blame, the first step is not to panic and not to reach for the infrastructure budget. The first step is to look at what your application is actually asking the database to do.

Pull the slowest queries from your logs. Look at their execution plans. Check whether the columns you’re filtering and joining on have indexes. Look for N+1 patterns in your ORM queries. These are not exotic problems — they are extremely common, and they are fixable without rewriting your application or migrating to a new database.

The database is rarely the bottleneck. It’s just being asked to do things inefficiently.

At bitGloss, we help engineering teams diagnose and fix exactly these kinds of problems — turning slow, expensive queries into fast, predictable ones without unnecessary infrastructure changes. If your application is struggling with database performance, get in touch.

Artificial Intelligence: A misleading name for powerful tools

This article is a follow-up of my 2019 article on the same topic, but updated in the light of today’s AI hype.

Like I mentioned then, when I first experimented with neural networks years ago, I was struck by how little “intelligence” there actually was in them. They did exactly what I coded them to do—no more, no less. Today’s systems may look more impressive, but the principle hasn’t changed: these are tools, not minds.

The Problem With the Word “Intelligence”

Humans don’t even have a precise definition of their own intelligence or consciousness. If we can’t define those terms for ourselves, it makes no sense to claim that we’ve created them in machines.

What we can say is that current AI systems don’t exhibit the qualities most people intuitively link with intelligence: self-awareness, understanding, intent, or meaning. They generate outputs by compressing patterns in data, not by reasoning or knowing.

To call that “intelligence” is to confuse statistical mimicry with cognition.

What AI Actually Does

Modern AI systems, especially large language models and generative tools, are best understood as:

• Pattern machines. They excel at finding correlations in vast amounts of data.

• Automation engines. They can handle repetitive, data-heavy tasks quickly and consistently.

• Amplifiers. They extend human capability, but only within boundaries set by training data and design.

This is powerful, but it is not thought.

The 2025 Reality Check

• Scale isn’t sentience. More data and bigger models don’t bring us closer to human-like understanding.

• Usefulness ≠ understanding. A tool can be highly practical without being intelligent.

• The real risks are human. Bias, misuse, privacy abuse—these are problems in how people deploy the systems, not evidence of AI “deciding” anything.

Why the Distinction Matters

If we keep pretending AI is a kind of mind, we risk treating its outputs as if they were grounded in meaning or truth. They aren’t. They’re grounded in probabilities.

AI is not intelligent because we don’t even know what that word would mean in this context. What we do know is that these systems are fundamentally different from human thought: they calculate, predict, and generate—but they do not understand.

Conclusion

The danger isn’t that AI will “wake up.” The danger is that humans will forget what it actually is: computation dressed up in human-like outputs. Powerful, yes. Useful, yes. But never a mind.