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

Ask HN: As a developer what are your aha moments?

news.ycombinator.com

Post reply on HN
Print view View original

151–160 of 189 posts

Re: Ask HN: As a developer what are your aha moments?

#151

Post by machello13 »

neurostimulant wrote: post #146
quickthrower2 wrote: post #94

Earlier quoted context omitted.

With bare metal, are you not just paying more for staffing to maintain it? Bare metal as cheaper sounds suspicious. Bare metal as essential maybe if you are doing something like 3D graphics processing or mining or “big data”.

> With bare metal, are you not just paying more for staffing to maintain it? People always say this as an argument against bare metal servers, but aren't you still have that staffing cost even if you're using a cloud provider? Cloud servers are more reliable than bare metals, but certainly not 100% sla yet. Shit happen regardless of using cloud or bare metal and we'll have to prepare for it regardless whatever type o…

> People always say this as an argument against bare metal servers, but aren't you still have that staffing cost even if you're using a cloud provider?

I think their point is that it may not be cheaper if you account for staffing cost. Also, especially as a lone developer or a small team, it may be worth it to pay for someone else to manage the metal instead of doing it yourself.

Re: Ask HN: As a developer what are your aha moments?

#152

Post by attil-io »

ChicagoDave wrote: post #71

1. Polymorphism 2. Vendors are often pushing bad architecture 3. Architects often push things for the wrong reasons 4. Companies often push risk to their vendors, avoiding collaboration, inherently increasing risk 5. ORM's hide business logic, preventing a company from understanding its business and adapting to change 6. Relational Databases are an operational anti-pattern 7. Graph databases are excellent tools for c…

> 6. Relational Databases are an operational anti-pattern

Could you please expand on this? What is wrong with Relational Databases and what would be the "correct" pattern?

Re: Ask HN: As a developer what are your aha moments?

#154

Post by sktguha »

02020202 wrote: post #84

Not AHA moments, but some pointers: - most tech is stupid simple, like retard levels of simple, with incredibly complex description - SOA is stupid and monlith is always the way to go(maybe with handful simple microservices) - microservices are not SOA - event sourcing is almost never a good idea - raw bytes over the wire or in storage are not as complex and mysterious as you might think - compiled languages are not…

>event sourcing is almost never a good idea

Wait isn't event sourcing the fundamental principle of redux ? And redux is the most popular UI state manager library out there. and why you feel event sourcing is not a good idea ?

Re: Ask HN: As a developer what are your aha moments?

#155

Post by quixoticaxolotl »

sktguha wrote: post #154
02020202 wrote: post #84

Not AHA moments, but some pointers: - most tech is stupid simple, like retard levels of simple, with incredibly complex description - SOA is stupid and monlith is always the way to go(maybe with handful simple microservices) - microservices are not SOA - event sourcing is almost never a good idea - raw bytes over the wire or in storage are not as complex and mysterious as you might think - compiled languages are not…

>event sourcing is almost never a good idea Wait isn't event sourcing the fundamental principle of redux ? And redux is the most popular UI state manager library out there. and why you feel event sourcing is not a good idea ?

Think he means event sourcing in a distributed transaction context, not a front-end context: https://microservices.io/patterns/data/event-sourcing.html

Re: Ask HN: As a developer what are your aha moments?

#156

Post by arwhatever »

jdmoreira wrote: post #10

1. When I realized programming was hard That’s it. For a long time I thought I was good at programming and I kept making the same mistakes over and over. All nighters, leet coding, runtime hacks, etc... And then one day it struck me. It’s hard and my mind can’t keep up with yesterday’s cowboy coding. Slowly I started putting defense mechanisms everywhere - good type systems, immutability, compile type instead of runt…

Paraphrased famous CS quote from somewhere: "The sooner you acknowledge that you cannot fit the entire thing into your head, the sooner you can start factoring that acknowledgment into your design."

Re: Ask HN: As a developer what are your aha moments?

#157

Post by ChicagoDave »

attil-io wrote: post #152
ChicagoDave wrote: post #71

1. Polymorphism 2. Vendors are often pushing bad architecture 3. Architects often push things for the wrong reasons 4. Companies often push risk to their vendors, avoiding collaboration, inherently increasing risk 5. ORM's hide business logic, preventing a company from understanding its business and adapting to change 6. Relational Databases are an operational anti-pattern 7. Graph databases are excellent tools for c…

> 6. Relational Databases are an operational anti-pattern Could you please expand on this? What is wrong with Relational Databases and what would be the "correct" pattern?

The keyword in my statement is _operational_. Relational databases are excellent for analytics and reporting. But in an operational system with well-defined boundaries, it's more than likely that only portions of the larger system are required for any transactional behavior. In a modern architecture, you could simply write all transactions to an event store (write only) and use CQRS and a relational cache store for reads.

Another aspect of all of this is the misconception that we should design systems based on a relational data model. This only leads you through the whole impedance mismatch of ORM's and how you serialize/deserialize your bounded contexts or objects. We should not do this at all. We should design systems on those bound contexts and determine the data store accordingly. Operationally, a Document Database or Event Store is going to be the best tool.

We can fire change events at a data warehouse to store data in a relational manner for analytics and reporting, but none of that is necessary for our operational system.

In your operational system, if you need any sort of complex join, you've already created a poor design.

I will say this. This did not occur to me until I'd gone through the process of developing a complex system using Domain-Driven Design. Until you've done that, the old patterns will remain like concrete.

Re: Ask HN: As a developer what are your aha moments?

#158

Post by zamubafoo »

ChicagoDave wrote: post #157
attil-io wrote: post #152

Earlier quoted context omitted.

> 6. Relational Databases are an operational anti-pattern Could you please expand on this? What is wrong with Relational Databases and what would be the "correct" pattern?

The keyword in my statement is _operational_. Relational databases are excellent for analytics and reporting. But in an operational system with well-defined boundaries, it's more than likely that only portions of the larger system are required for any transactional behavior. In a modern architecture, you could simply write all transactions to an event store (write only) and use CQRS and a relational cache store for r…

If I'm reading this correctly, then it's not relational databases/relational data models that are the problem, but instead the normalization across bounded contexts within a problem domain?

Re: Ask HN: As a developer what are your aha moments?

#159

Post by tmaly »

haroldegibbons wrote: post #59

My "aha" moment was realizing most of my ideas and most apps out there are complete garbage. Not needed. Damaging, even. 99.9% of all of it. For example, most "cutting edge" web apps are better off as PHP monoliths. Facebook was a PHP file for a long time. But most apps in general should never make it past being shell scripts, which are better off staying as spreadsheets or better - text files which are better off as…

Truth! Low tech or no tech is much easier to deal with if you are forced to.
Post reply on HN