I remember the times around 2000 when most websites were static. We edited them locally on our computers and then uploaded to an FTP server. There was plenty of free hosting services. Building your own site was very easy.
Popular programming languages do not natively support decimal numbers. This is because CPUs operate on binary numbers. Even though there is a new IEEE standard for decimal floating point types, CPUs still don’t support it fully. So every time we see a notation like
0.1in the code, it’s not what it seems. Our calculations might be inaccurate.
If your application allows uploading PDF files, it’s likely that you need to prepare screenshots or thumbnails for these documents – at least the first page.
The Apache Commons Lang library has a handy set of random string generators, enclosed inside the
RandomStringUtilsclass. However, these are not cryptographically secure generators by default, which can trigger warnings in platforms like Veracode (for example CWE-331: Insufficient Entropy).
If you write any application that operates on money – even a simple web shop, sooner or later you will have to send monetary amounts through API calls, SQL queries, CSV downloads, and so on. Let’s see how to avoid common mistakes which could destroy your business!
Java is very often used to develop big financial systems, yet still the JDK has little or no support for monetary arithmetics, currency conversion, formatting money for different locales etc. There’s only a Currency class which serves as a list of ISO 4217 currencies.
I have this talk about the MoneyPHP library and handling currencies in general. I often get a question: is it possible to define custom currencies in MoneyPHP? A possible use case would be loyalty cards for example, with their own scoring system.
Once upon a time, looking for new career opportunities, I considered becoming a database engineer or architect. I was pretty successful in optimizing MySQL databases growing up to 65 GB. I liked it. However I noticed almost no one was hiring MySQL database engineers – it’s too simple. Real challenges await those familiar with Oracle and big finance systems, aviation etc. So, I bought a thick book about Oracle and… never used it.
I spent two years on a project which aimed to create highly sophisticated PDF reports for teachers. These automatically generated reports contained bar chars, pie charts, line charts, a lot of tables and everything else. It worked: end users were very happy about the new reports system. But still, something keeps bothering me.
Have you heard of YAGNI? The acronym stands for “You Ain’t Gonna Need It“. The original meaning, as Extreme Programming guru Ron Jeffries said, was to “implement things when you actually need them, never when you just foresee that you need them”. But how did this principle evolve over time?
One of the most valuable tips I received why having my Java code reviewed was to change this code:
In the very first article on defensive coding we talked about avoiding mutability.
Are you tired of fixing the same bugs on and on in a huge system developed by a multitude of developers? I guess it’s time to introduce some practices of Defensive Programming. It is an approach to improve software quality by reducing number of possible bugs and mistakes and making the code more predictable and comprehensible.
Most of my day job isn’t fascinating. Yet another controller, service, test, and so on. I spent a lof of time doing repetitive tasks and slowly gaining more knowledge about the system I’m working on. However, having slow and steady pace can eventually reward you with an opportunity to make a really great improvement. It happened to me, twice.
Remote work is challenging. People working remotely need perfect communication skills and discipline because no one is watching over their shoulder. However, the real struggle starts when we try to combine office and remote employees. What problems are we going to face and how can we improve the situation?
Recently I shared my thoughts on preparing an efficient onboarding process. Unfortunately, sooner or later people quit. This is also something our dev team should prepare for.
Who’s responsible for building a development team? A team leader? Scrum master? Senior engineers? I strongly believe that every team member contributes to its work culture. I also believe that one of the best benchmarks of a team’s performance is the way new developers are introduced.
I’ve been wondering for some time if PDF is still a valid format. It’s “portable”, of course, but not in today’s meaning – it’s clearly not responsive. Like a fixed piece of paper transformed into a file. However, PDF still has many important use cases like storing invoices, reports or tickets. I spent a couple of years working on sophisticated PDF reports, and this year I even tried to test a process of generating invoices in some ad exchange system. I really wanted this system to be rock solid.
When I first saw primitive types like
booleanmixed up with classes, I was very tempted to convert all primitives into
Booleanand so on to maintain a clear coding style. But reading articles on the Internet and IntelliJ hints stopped me from doing such a stupid thing.
Like every Java developer, I had a fair amount of Null Pointer Exceptions in my career. That’s why I decided to describe real-world examples I had to fix.
When you’re an engineer, sometimes you might get an offer to take over management duties. It might be for example leading smaller projects, being a scrum master or leading a whole team of developers. When to consider such options and how to get prepared for new challenges?
…then sooner or later, you’re going to have a bad time. Bugs in your app or users’ recklessness will cause your database to be inconsistent.
How to gloriously waste three days of a 10-person development team? Send them to a wrong training led by a wrong person. As a team leader I made this mistake twice. There will be no third time.
Everyone might have their own code formatting preferences. Problems arise when a team consisting of a couple of individuals work on a common code base and every developer has different preferences. It’s hard to maintain pull requests in this situation.
You should have some tests. Why? Because developers are afraid to make changes in a code they don’t understand. This is a common problem not only with fresh employees, but with everyone who stands in front of a huge, complex, legacy system. They are afraid to add a new if not to break the other ones. They are afraid to erase code that seems obsolete.
In the previous post, I told you how tight coupling causes systems to be hard to maintain and expand with new features. Today I’m going to show you how developers often take shortcuts which then add up to the technical debt.
subscribe via RSS