cache invalidation is not hard indeed, but people always forget about it (so caches aren't caches aanymore, they become stale copies of things...). People tend to forget that a cache has to have a fixed size and an eviction policy.
I used C/C++ for years, and I just don't believe that the world+dog quit creational design patterns. It was just now very easy to find a database connection pool for C++ that is exactly a connection factory. Would you mind clarifying your comment that almost nobody uses factory patterns in other languages with some sense of exactness as to what is and what isn't a factory?
This is the most painful part for me. If you're trying to understand some code written in Gratuitous Object Astronautics style, it's almost universally assumed you're fully aware of why the product contains hammer factory factory factories, how factories work, and how get an actual hammer to swing.
The Gratuitous Object Astronautics culture is so accustomed to all the nonfunctional boilerplate that skilled, self-gratifying, astronauts never need to document their cleverness. This leaves casual tourists in the dark, which is a problem in any organization.
Fair point if you read it literally and assume each thread is a problem. But I assume, as it's a variation of the regex joke, 'using threads' is seen as a singular thing. Perhaps it should say 'threading?'
Satisfied, she declares the bar ready for business. The first customer comes in an orders a beer. They finish their drink, and then ask where the bathroom is.
It's very simple: you test things because we can't rely 100% on developers to create the right thing or to create it without any bugs. The same goes for automated test software. I've personally created unit tests that were failing for like 2 years but due to a bug still showed green in CI.
To go back to the joke: manual QA is infinitely more likely to find the exploding bathroom than a unit test would ;)
Automated testing is a fantastic tool, but manual QA is still very valuable.
It's not an either/or though. Used to have an assignment where we as developers would write automated tests (regression tests), while we had an experienced software tester with an excel sheet verifying things by hand. But instead of just following the sheet - which is automatable - he knew of a number of different techniques and approaches and he'd still find a lot of issues that nobody else found. For which we'd write a test to avoid it happening again.
I mean I wouldn't have minded if they wrote more automated tests themselves, but I'm also very aware that the mindset of me and developers would quickly become "it's not my responsibility to test my software".
It's weird how many bugs I regularly find in our software by actually testing things by hand, as opposed to our QA department, which does only automated testing and insists they have covered 100% use-case scenarios.
I just came up with a variation to this off the top of my head.
A QA engineer walks into a bar. She orders a beer. She walks out of the bar. She walks into the bar. She walks into the bar. She walks out of the bar. She walks out of the bar. She walks out of the bar. She orders a beer.
904 comments
[ 3.1 ms ] story [ 390 ms ] threadNaming things, cache eviction, and off by one errors
0) Cache invalidation 1) Naming things 5) Asynchronous callbacks 2) Off-by-one errors 3) Scope creep 6) Bounds checking
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery
There are only 2 hard things about programming:
- Cache invalidation
- Naming things
- Off-by-one errors
:- False
:- No.
There are 16 types of people in the world: those who understand hexadecimal and F the rest.
Those who don't understand binary
Those that think its a binary joke
Those who understand trinary
no no it is:
Those who don't understand binary
Those that think its a binary joke
Those that think its a trinary joke
Those who understand base 4
...
Human: Oh, I see you use base 4. We use base 10.
Alien: WTF is base 4? We use base 10.
Those who understand little-endian notation.
(quote from Jamie Zawinski)
Infinite Loop: see Loop, Infinite
tail recursion, n. See tail recursion.
The boy reaches over and starts going through the girls purse.
The girl says: "Hey! That's private!"
The boy replies: "But we're in the same class!"
Friends can access each other's private members in a public class.
— Your Java is slow!
— This is because it is written in C!
has Now problems. two he
Once in a long while you see one in C# or C++. But the people making fun of Java aren't comparing it with C# and C++.
[1] https://gist.github.com/nkbt/4691b1ae3e78a6141aea
This is the most painful part for me. If you're trying to understand some code written in Gratuitous Object Astronautics style, it's almost universally assumed you're fully aware of why the product contains hammer factory factory factories, how factories work, and how get an actual hammer to swing.
The Gratuitous Object Astronautics culture is so accustomed to all the nonfunctional boilerplate that skilled, self-gratifying, astronauts never need to document their cleverness. This leaves casual tourists in the dark, which is a problem in any organization.
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Yes, I'd like to hear a TCP joke.
OK, I'll tell you a TCP joke.
OK, I'll hear a TCP joke.
Are you ready to hear a TCP joke?
Yes, I am ready to hear a TCP joke.
OK, I'm about to send the TCP joke. It will last 10 seconds, it has two characters, it does not have a setting, it ends with a punchline.
OK, I'm ready to hear the TCP joke that will last 10 seconds, has two characters, does not have a setting and will end with a punchline.
I'm sorry, your connection has timed out...
Hello, would you like to hear a TCP joke?
(Credits to whoever first came up with this.)
Q: How are programmers like card machines? A: With both you have to punch the information in.
"What do we want?"
"Now!"
"When do we want it?"
"Fewer race conditions!"
Time Travel!
When do we want it?
Doesn't matter!
She orders 2 beers.
She orders 0 beers.
She orders -1 beers.
She orders a lizard.
She orders a NULLPTR.
She tries to leave without paying.
Satisfied, she declares the bar ready for business. The first customer comes in an orders a beer. They finish their drink, and then ask where the bathroom is.
The bar explodes.
To go back to the joke: manual QA is infinitely more likely to find the exploding bathroom than a unit test would ;)
Automated testing is a fantastic tool, but manual QA is still very valuable.
I mean I wouldn't have minded if they wrote more automated tests themselves, but I'm also very aware that the mindset of me and developers would quickly become "it's not my responsibility to test my software".
Personally, I find it helpful to bugger out things with pen and paper before coding it out. This is helpful and useful.
Greatness to you of you need not the analogue. Others "below you" may and can do just as well. Please do not down your nose upon such folks.
A QA engineer walks into a bar. She orders a beer. She walks out of the bar. She walks into the bar. She walks into the bar. She walks out of the bar. She walks out of the bar. She walks out of the bar. She orders a beer.
http://thecodelesscode.com/contents
10⁰: Axiomatics
10¹: Logic
10²: Mathematics
10³: Computer Science
10⁴: Software Engineering
10⁵: Group Psychology
10⁶: Politics
10⁷: Crisis Management
https://kingjamesprogramming.tumblr.com/
"2:4 And this I pray, that your love may abound yet more and more like a controlled use of shared memory."
The Church of Skynet demands sacrifice
> Depart ye; it is unclean; thou shalt burn it in the place of Tophet, because of all the machine registers
(From the Bad C Pun Contest, 1992, C/C++ User's Journal. I've never forgotten it.)