Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yagni Exceptions (2021)

lukeplant.me.uk

Post reply on HN
Print view View original

131–140 of 214 posts

Re: Yagni Exceptions (2021)

#131

Post by sethammons »

pindab0ter wrote: post #119

“Good logging” is mentioned here. Can somebody recommend a good write-up of what good logging consists of?

I've wanted to do that for a while. Look into structured logging. I want/need machines to analyze my logs, and that requires key value pairs. I put any dynamic text in its own field. "error for user 42, remote api timed out" -> level: error, userid: 42, message: api timeout, http_request: , timestamp: , time_duration_ms: 30000, ... (but as json).

Now I can see what users are affected by which errors however often. Alerts are now trivial to implement. They key is being able to debug an issue after the fact. I like to include a copy-pastable curl call when I can so I can manually reproduce an issue easily as an example

Re: Yagni Exceptions (2021)

#132

Post by Izkata »

iLoveOncall wrote: post #52
matsemann wrote: post #13

* Having all user-facing strings in a common place. It doesn't take much effort, but makes it so much easier in the future when you suddenly either need internationalization/translation (both tech side making the switch, but also gathering all the strings to send to some translator), or it's requested that these be managed by a cms of some sort instead of hardcoded all over the place.

I haven't worked with a lot of i18n systems, but on the contrary I have found them to be a huge amount of work. I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plu…

> I have used the Angular one and the Laravel one, and both are a chore to use, because they interrupt your flow. If I'm writing the view of my component, I don't want to have to switch to another file, think of a key that identifies that text well enough and then translate the text, thinking of potential plurals and others. I just want to write my damn text.

In django (python), the key is just the English text (with optional extra context), and if it doesn't find a translation for the target language it dumps that text back out. You don't need to go anywhere else until actually doing the translating.

Re: Yagni Exceptions (2021)

#133

Post by matsemann »

iLoveOncall wrote: post #120
matsemann wrote: post #96

Earlier quoted context omitted.

YAGNI ;) You can skip all those things the first time. You don't need to have a separate file or anything. Just have a stupid function returning its input or whatever. The important part is having an entry-point, and an easy way to find all relevant uses in the future. You could then later, when i18n is needed, write a script finding those usages and automatically extract them. That's what I've done once before. And…

> The important part is having an entry-point, and an easy way to find all relevant uses in the future. You already have it, it's everything that's in between {{ }} and > </.

Do you want to translate numbers between ><? What about alt-texts not in those tags? Things passed as props multiple layers? What about strings coming from backend? Do you read some things from the environment?

Re: Yagni Exceptions (2021)

#134

Post by tmorton »

samatman wrote: post #78

This is very nearly off topic, but "Ain't" is the correct conjugation to pair with "Gonna". This form comes from Britain and is preserved in some dialects of American English, but "Aren't Gonna" is a partial hypercorrection; if we want acrolect, we must go all the way to "Aren't Going To". "You gonna be at the thing this weekend?" "Nah man I aren't gonna" wrong For the Commonweath, to whom this is no longer part of t…

We're not gonna need it!

No, we ain't gonna need it!

We're not gonna need it anymore!

Re: Yagni Exceptions (2021)

#135

Post by [deleted] »

wruza wrote: post #57
motogpjimbo wrote: post #39

Earlier quoted context omitted.

This sounds like you're opening yourself up to situations where you have rows in data_journal that have status='Loading' but which have started_loading_at=NULL, in violation of your data model. Your premise is slightly flawed in that your second example isn't actually difficult to write or understand as you claim. However, it could be argued that if the logic for selecting "loading" rows is repeated in multiple place…

that have status='Loading' but which have started_loading_at=NULL, in violation of your data model Why not CHECK() it then? Or make ‘status’ GENERATED STORED or do a similar thing on triggers. The way that you suggested is also good, but it creates two names, one for update, another for select, which may confuse orms or developers.

[deleted]

Re: Yagni Exceptions (2021)

#136

Post by jakelazaroff »

dkarl wrote: post #123

Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…

Can't agree with you there. I've never seen a situation in which it was necessary to recover "optimistically" soft-deleted data. I have seen multiple situations in which soft-deleted data was accidentally included in live queries.

Re: Yagni Exceptions (2021)

#137

Post by pindab0ter »

RickHull wrote: post #112
grey_earthling wrote: post #85

Earlier quoted context omitted.

“You aren't gonna need it” is ordinary colloquial British English. “I aren't…” is not.

You're not gonna need it I'm not gonna need it You aren't gonna need it I amn't gonna need it You ain't gonna need it I ain't gonna need it

You'ren't gonna need it.

Re: Yagni Exceptions (2021)

#138

Post by pindab0ter »

dkarl wrote: post #123

Rarely do I read something so specific about software development that I agree with 100%. One thing I would add: soft deletes in relational databases. There's a really good chance that eventually you'll need it for customer support, for debugging, or to fix nasty performance issues caused by cascading deletes. For some types of businesses, I wonder if "right to be forgotten" should be designed in from the beginning a…

For compliance reasons, you can always hard delete data. It's also not a terrible idea to hard delete data that has been soft deleted x time ago.

Re: Yagni Exceptions (2021)

#139

Post by [deleted] »

number6 wrote: post #17
orthoxerox wrote: post #15

> More generally, instead of a boolean flag, e.g. completed, a nullable timestamp of when the state was entered, completed_at, can be much more useful. In my experience, the timestamps should almost always be entered in addition to the flag. select * from data_journal where status = 'Loading' is much easier to write and understand than select * from data_journal where started_loading_at is not null and finished_loadi…

If you have to answer: "does it usually take so long or is something broken?" The Timestamps would be handy. Oh and you can estimate an average for the execution time; investigate performance degradation or improvements

[deleted]

Re: Yagni Exceptions (2021)

#140

Post by pindab0ter »

sethammons wrote: post #131
pindab0ter wrote: post #119

“Good logging” is mentioned here. Can somebody recommend a good write-up of what good logging consists of?

I've wanted to do that for a while. Look into structured logging. I want/need machines to analyze my logs, and that requires key value pairs. I put any dynamic text in its own field. "error for user 42, remote api timed out" -> level: error, userid: 42, message: api timeout, http_request: , timestamp: , time_duration_ms: 30000, ... (but as json). Now I can see what users are affected by which errors however often. Al…

This is great. We use Sentry for our projects, which serves the same purpose.

I was wondering if using info statements in certain places are seen as a good practice, for example.

Post reply on HN