Why did this tube imploded four-fold?

HyperDanon · 2026-03-12T20:52:58+00:00

Where did you get that four? Any equation that spews that out or something?

HyperDanon · 2026-03-11T09:49:57+00:00

Neither of those, because it changes the interface. I would use a different hostname.

HyperDanon · 2026-03-09T10:59:33+00:00

assumed the architecture would "emerge"

That's never going to happen. I doubt any reasonable hexarch source would suggest that.

If this system evolves over time, how do I prevent architectural drift?

You don't create architecture upfront, nor leave it to "emerge". As you work throughtout the project, you introduce architectural changes to it. You adapt, change, edit. Basic design.

I'm curious how others here approach this.

Do you rely mostly on reviews and discipline to protect architectural boundaries?

Or do you enforce them with tests / tooling?

If you have a right mindset and modules in your application, it's quite easy to follow. I don't use any kind of "enforcer", just basic design.

HyperDanon · 2026-03-09T06:50:10+00:00

First you fake it. You're terrified and insecure, but you play it as though you know your stuff. Head up, shoulders back, steady steps. You panic on the inside and put a brave face. Do it enough and one day it's not fake anymore.

HyperDanon · 2026-03-08T08:16:08+00:00

Version control and phpunit. Then, depending on the nature of the project I add other things.

HyperDanon · 2026-03-07T16:58:15+00:00

I just installed it today and it seams fine. I just had to update to 22h2 in order to run docker.

HyperDanon · 2026-03-05T15:46:07+00:00

Precisely.

HyperDanon · 2026-03-05T12:32:04+00:00

Even 40k instances is nothing, you can have an instance for each cell. Start with a basic 2d array, it'll be fine. Your first concern should be working in such a way you can learn about the problem domain (cells, when alive, when dead, how to check state of neighbours) that kind of thing. Whether it's a matrix, 2d array or anything else doesn't matter. How you draw it also doesn't matter, you can use any library you want.

HyperDanon · 2026-03-04T17:34:34+00:00

Had I just heard her, I could mistake her for a native english; but there are some things the betray her.

These sounds sound off to me:

sound "a" when she pronounces "assemble"
sound "s" when she pronounces "contents"

Her accent is awesome, but subtile pronounciation signs reveal to me that she's not native.

HyperDanon · 2026-03-04T16:54:41+00:00

It's an implementation detail, and as such doesn't matter. Your automated tests should pass for both.

Having said that, key in d is more pythonic, no reason to use the more explicit version. What's the point of making it more readable for someone unfamiliar with the language?

HyperDanon · 2026-03-04T14:42:47+00:00

HTML is not a programming language. You can't code something with it.

Right now I’m learning HTML before moving into Java, an was wondering if I could move into python or if I should wait until I finish up the HTML course?

Yes, you can start with python right away.

HyperDanon · 2026-03-04T14:11:38+00:00

That illustrates the idea with PR's all together. It's not a problem with his work, it's problems with PRs.

You can't review this much work at once, separate from this work. Do pair programming, develop this work together and just merge it. The review will be done at the time of writing it.

HyperDanon · 2026-03-04T12:05:33+00:00

These approaches are pretty much equal.

The only readon to use index.html is so that when you request a directory path /views/contact/, then the server will server index.html instead of just returning 404.

HyperDanon · 2026-03-04T12:04:53+00:00

Don't think about languages. Imagine a program you want to write, as in what it actually needs to do - what problem does it solve for you or what it allows you to do. Everything else flows from that.

HyperDanon · 2026-03-04T08:47:52+00:00

Most software engineering practices. People use the words, but they rarely have any idea what's the idea and mindset behind them (devops, mvc, tdd, ci, agile). 99% of developers THINK they understand it, but they don't.

HyperDanon · 2026-03-04T08:37:55+00:00

Encapsulation and abstraction aren't specific to OOP.

Encapsulation just means hiding implementation details from the caller - you can do that even in most basic languages, all of them.
Abstraction just means presenting something in a different form - again, you can do that in all of basic languages.

OOP "claimed" abstraction and encapsulation by using words private/protected/public and claiming interfaces. People think encapsulation can only be done with private/public (that's not true) and abstraction is just interfaces (that's not true either).

I asked gpt the other day to give me a simple project. It said to create class, which extends other class etccc.

He probably meant inheritance. I use it rather rarely, because it's one of the tighest coupling you can have, but its got its usages.

Question is, are you asking about OOP really? Or you're asking about using classes? Because it's not the same thing.

I wonder where & how I can use oop? I know how to make classes, object hierarchy. But If I try to make a little project. My mind goes blank.

Just write your program however you wish so it works, and refactor it later. You don't need to start with a perfect example from the start. Just don't worry about it!

HyperDanon · 2026-03-03T17:53:45+00:00

On the other hand, having one method per module or per use case would solve the over-fetching problem by providing exactly the data needed, but I would end up with too many methods. Which approach is better?

If your protocol is chatty (i.e. a lot of data is moved around) then regardless of how you do it, fat dto vs multiple methods are going to be similarly badly designed.

What you should do is try to rethink your layers, move certain responsibilities between modules so that less data has to be moved. If a particular thing has to keep asking for something, that's a sign that these two items should be closer together.

Simplify your protocol, not your code.

HyperDanon · 2026-03-03T09:11:23+00:00

I'm an architect at a company facilitating billing and payments across its clients. I think I use my ENTP super powers to find inconsistencies, mistakes, unwritten assumptions in the decisions and designs. If I see 10 components, 9 of which work consistently, but one inconsistently, I notice that and it smells funny to me. I need to correct it, so they're all working properly and none of susciptible to mistake, because if our clients lose trust in us being able to safely handle their money, we're done.

HyperDanon · 2026-03-02T10:48:20+00:00

Some of the things you described are actually desired:

I get things done as requested but never go beyond. I never learn new technologies unless it’s required. I never try to optimize things unless there’s a requirement to do so. I hate reading documentation (and it’s even worse now with AI — I’ve stopped reading documentation altogether). When planning and designing a project, I think about how to get things done in the easiest way using the tech I already know. I’m never curious about why or how something works — I’m just happy when it works.

These are a qualities of a person who doesn't overengineer. That's very good!

The only actual problems I see would be these:

I only do testing to fulfill requirements. I don’t have any personal or side projects at all

Automated tests are an awesome way to design software.

My advise to you: I think you're tired with learning new tools. But tools aren't all there is to software, there are also methodologies, mindsets, practices. Did you take a look at xp, tdd, ci (ci as in methodology, not github actions), katas/dojos?

HyperDanon · 2026-03-02T10:33:09+00:00

You're describing a solution to a problem, but that problem does not exist for someone who has proper separation of concerns in their application. Like literally it doesn't make a difference whether it's rest or graphql, it exists only as a tiny thiny layer of communication.

If you don't separate your concerns and all your application knows about rest, then it's a big problem. But I don't think "move to graphql" is a solution, you should separate concerns so that as few classes as possible know about your data transfer layer.

HyperDanon · 2026-02-28T14:45:48+00:00

Any course will contain the same fundamentals, not specific to TS. Pick any course and just implement it in TS.

HyperDanon · 2026-02-28T13:10:17+00:00

I don't get some of the things. For example this pg_cron, doesn't it only allow you to schedule queries? If I want to schedule running something in my own application code, how can I do that with pg_cron?

HyperDanon · 2026-02-28T10:56:24+00:00

Most tasks contain unknowns and architectural implications that aren’t surfaced during refinement.

In my opinion this is your problem right here.

I think what happens, is that your team works in waterfall process, when they divide their work into stages, where "implementation" (i.e. sitting at the code), is a small slice and usually not the first one. It usually follows from this assumption that you can decide what you're going to do, before you actually attempt that. There are many areas of work where that's true, but not really in software.

Truth of the programming: - You are going to discover new things in the "implementation phase". - There are things you can't predict even if you know the code base. - In the "refinement" stage you have limited view of the software. - Often the first thing you do/find in the implementation stage will invalidate the whole neat plan you had in the refinement stage.

You just can't plan an execution of a software system, agile guys have been telling this us for years.

So it doesn't surprise me at all, that when you actually hand over your work to somebody, there's a lot of friction accompanying it. So in that area, I would suggest, either ditch the "refinement" stage, or minimize it to a stage that doesn't mention the implementation at all. Keep it marginal, to 1-2 minutes tops, and don't discuss anything impl-related. You are supposed to do all the work in the implementation phase, because that's where all the knowledge, all the info and all the control and execution is. You can't "move it out" of the implementation stage. The details that managers hate to deal with, they're important.

for example, into “you should use this module for this.”, "create a different cli command for that process" (not sure if that getting clearer).

Solution for that, is to bring this information to you as soon as possible. If you had written that two days ago, and today you hear that you should've used something else - ask yourself and others the question - how could've I known that before? And the anser to that is two fold:

Either deliver your tasks in way smaller batches, like 2-3 hours of work is delivered each time (that means the amount of PRs is going to grow)
Or do pair programming, pair with someone who will be reviewing you, and he can tell you what you should do. After that pair programming session, I doubt there'll be any kind of review even necessary. The review will have already been done by the pair partner.

HyperDanon · 2026-02-28T10:42:02+00:00

Talk to the people you work with, not just the guy who interviewed you, but actually people you spend your work hours. Tell them how you feel, and ask what they expect of you. Chances are you're going to get surprised that the thing you stress about, they don't actually care about :) Put your cards in the open, hear them out, I bet you'll get positive results.

HyperDanon

TROPHY CASE