When we write unit tests we start replacing our objects with all kind of fakes. We call this process mocking. We do it because we want to test our logic in isolation. Sometimes this mocking gets weird. We’ll get there, bear with me. Continue reading
We’ve been working in a small team. There were only two developers. Both of us were at mid-senior level. The other developer had five years experience and I had ten. We trusted each other for doing good work. Which meant, we trusted each not to do stupid things. Continue reading
I’ve been working for twelve years in roles that involve programming. Still, I don’t know what is software development about. I have an opinion though. Here it is.
Software development is not about developing software. Okay, we do develop software. But this isn’t the point. Continue reading
This post is an answer to Foltis comment. He claimed that it’s dangerous to generate and run SQL in the production. We should execute SQL in production carefully. I think he is right about that.
Wait! Why is it important to run SQL carefully? More importantly, how to run SQL carefully? It’s not about typing
SELECT slowly, is it? Continue reading
Sometimes we need to parse length-encoded records. A length-encoded record is just a
String. The receiver must know where he can find the specific data elements.
Say for instance, the first two characters describe the record type, then the next eight characters represent a date, and then the next forty characters contain the name of something.
We write really ugly code to parse this kind of data. Do we really have to? Continue reading
I recently saw new way to access the database. Every database access was a stored process call. Those stored procedures were quite simple most of the time. They executed one command, like a
SELECT or an
UPDATE. I was wondering, why complicate things this much? Why not use an object-relation mapping software like Hibernate, so you don’t need to write SQL at all?
Those were two different questions. Let’s answer them one by one. Continue reading
Recently we had a problem: some of our views somehow lost their privileges. As a quickfix I wanted to recreate them. Luckily, we had to
GRANT the same privileges for these views. Unfortunately, we had tons of tables.
What now? I already hinted in the title: let’s generate them!
The Pragmatic Programmers argue that we should program defensively. Basically, they suggest that if your program arrives in an unexpected state then it should stop working instead of doing stupid things.
Others argue to write fault-tolerant code. Say for instance, if you’re creating a financial report from some hundred thousands transaction, you don’t want it to abort just because three transactions were abnormal. You’ll want to send the daily report as usual, and handle the exceptions manually. Continue reading
Recently I was working on a Primary Key Violation error. This error was part of a bigger process. This was a well-written process, so it rolled back everything after this error. Although it’s cool for the application, it’s horrible for debugging. I didn’t know what records caused this error.
I had a few hunches, but that’s all. I released a fix based on one of these hunches, but it didn’t work, So I decided, I needed data.
I must confess. Sometimes I can see fixes that make a chill go down on my spine. And it’s the wrong kind of chill. It’s the chill that tells me that something is wrong.
What kind of something am I talking about? Usually it goes like this: a coworker explains “So, we filter these messages with these predicates, because based on the business rules…”. And then, a chill goes down on my spine. It’s the wrong kind of chill.
Why is it wrong? Is it wrong to write business logic into our code? It depends. It’s a programming blog, so the answer is always, “it depends”.
Bear with me. Continue reading