Profile for zlatko
- Display name
- Panic In The Darkroom
- Username
- @zlatko@social.zlatko.dev
- Role
- admin
About zlatko
Fields
- website
- https://zlatko.dev
- some photos
- https://pixelfed.social/zlatko
- some more photos
- https://photos.zlatko.dev
- 52frames photos
- https://52frames.com/photographer/20340
- Gravatar
- https://gravatar.com/zladuric
Bio
According to some, I'm avant-garde ;)
I try to stick to software development and engineering topics, often related to application development, but I also shitpost random stuff, occassionally about photography, (usually not more then) react to politics or economics.
My website is https://zlatko.dev but I less completely-infrequently post a photo or two to my photo gallery https://photos.zlatko.dev.
I also used to post at https://pixelfed.social/zlatko, and https://programming.dev/u/zlatko, and I'll occassionally swipe here and there.
Stats
- Joined
- Posts
- 2319
- Followed by
- 161
- Following
- 316
Thoughts, listening on a GenAI panel:
GenAI and LLMs should be focused on use cases, not complex ideas.
I just realized my blogging setup does not pick up mdx files. And when I looked at the articles, most of them are not really good, at least not any more. To publish them, or not? That is the question.
Various levels of abstraction in these abstract photos:
euro
Since I live in Munich, of course my kids are rooting for Germany. But since I'm not that attached yet, I'm hoping for at least one goal by Scotland, just so I "win" against the boys.
Nothing wrong with a little drama for them, it's their first cup they'll be following, they should learn why it's so crazy thing :)
About tests and testing in software
Why should I write tests?
- each time I am writing code, I'm taking a stable product. With, perhaps, known and unknown defects.
- on that stable product, I'm introducing a change set
- my job, as a product engineer, is to make sure that the end result is again at least a stable product (now v2), with lower or equal amount of defects.
- therefore I also need to ensure that my change set is also long-term stable
#tests #testing #tdd #wellNotReallyTDD #softwaredevelopment #showerThoughtsOnTesting #wellNotReallyShower #didYouReadAllTheHashtagsUpToHereQuestionMark
...some tests we write to make sure the thing works, others to make sure our change is good
simple interfaces over simple implementation
Mmm, the oldest trick in the book, plug a bud in your ear and have a buddy standing outside dictating the answers. No wonder he got caught:
Me: (listening to some random progressive stuff)
Me: (notices it's on 2x speed, slows it down to 1x)
...
Also me: "Oh, this is also okay to listen."
It's incredible how people are overcomplicating Angular (and other frameworks as well). Just because there's a "smart" feature included, it doesn't mean you should use it.
One concrete example I'm currently having a problem with is implementing complex access/permissions behavior through a directive. I assume the intention was: e.g. this: <span *canAccess="null; currentUser.perms; Access.READ">Thing to access</span>. I believe it's intention is clear, the future users of this know how you can show parts of the UI only to people who are supposed to.
But that's actually false, and people do not, in fact, know how to do it. If it was a simple <span *ngIf="canRead()">, any Angular rookie knows this. By making your own custom directive, now people need to learn not just Angular, but also your DSL. It makes sense in big apps with several teams unrelated to eachother. But a lot of the time I see this kind of smart-ass code in a small team and a relatively small app. A dev learned a new trick, and used it. And now two years later, he's long gone and you have to actually go fix things, and you don't understand the intention any more.
Stick to simple, straightforward concepts in Angular, please.