HN Theater @HNTheaterMonth

Mvc isn’t an architecture at all. It’s just meant to be a tiny pattern for ui widgets from the 70s that people started to use as an architecture. The actual goal is to just keep a tiny piece of business logic from having a dependency on a specific input or on the view. It applied to a single button or a single input field back then.

Architecture is more about deciding what direction your dependencies go and where your hard boundaries go

https://youtu.be/o_TH-Y78tt4 (approx 27 mins in)

For some perhaps-off-topic contrarianism, what do you make of Uncle Bob railing against database-oriented architectures? [0] (He takes a good few minutes to get his point across.)

[0] https://youtu.be/o_TH-Y78tt4?t=2566

⬐ code_biologist

I think his take on databases is moronic with a dash of common sense:

He rails against a strawman where people put SQL everywhere, into views, into application logic ("mail merge" is one he mentions), and DBAs gatekeep everything.

The common sense part: no, your views shouldn't be composing SQL with string interpolation.

The moronic parts:

- He venerates application logic and regards the data model as a detail, but data models aren't details — they tend to outlive application logic.

- He holds up in-memory data structures as a platonic ideal, but doesn't address the things databases provide for you: schemas, constraints, transactional semantics and error recovery, a clear concurrency story.

⬐ ianamartin

I can't watch that at work right now. But is it pretty much this? https://blog.cleancoder.com/uncle-bob/2012/05/15/NODB.html

I've heard of him before but never really read anything much by him. Is this guy for real? He worked at one startup, got angry about a database, became a consultant, and screams about everyone being wrong about everything?

⬐ tincholio

> became a consultant

To me, he sounds more like a snake oil salesman.

⬐ MaxBarraclough

Yes he makes similar points there. A few scattered critical thoughts:

* I don't see any problem with stored procedures. They can make good sense for, say, auditing, as well as for performance.

* People describe their software systems as "Using Oracle" because it matters, not because their design is stupid. It tells me that Oracle skills are relevant, for instance.

* NoSQL is generally, in my experience, awful and chaotic, rather than liberating. Lots of good work has gone into making serious grown-up relational databases. Schemas, normal forms, constraints, rigorous work on the ACID properties. Something like MongoDB is just sloppy amateur-hour by comparison.

* In the YouTube video, he says that solid-state drives render relational databases obsolete. This strikes me as absurd. Not even ultra-fast SSD storage technologies will do that. The relational model is effective, and the associated DBMSs still well justified. Joins belong in a query language, not in imperative code. Why would you want to try managing a huge complex dataset manually?

[0] https://en.wikipedia.org/wiki/3D_XPoint

(Edit: formatting)

⬐ NotSammyHagar

Yeah, seems like he vastly overstates things. ssds are great for relational databases. They all use them.

⬐ jbergens

I think the point is that you might be able to build something else than a standard relational db and make it faster.

Something like VoltDB but there are other solutions. There used to be some blogs about their architecture and how they could avoid a couple of steps a normal RMDB needs that takes a lot of time.

https://www.voltdb.com/why-voltdb/

⬐ MaxBarraclough

> I think the point is that you might be able to build something else than a standard relational db and make it faster.

I sincerely doubt that.

For it to be useful in real world situations, you'd have to build your own highly flexible, scalable, rock-solid, high-performance data-management solution, ideally one which enables the user to use a declarative means of expressing queries.

This is, of course, a DBMS.

If you build one which imposes structure on the data, you've got either a relational DBMS, or an object DBMS, or some other kind of well-studied database solution... except you've rolled your own from scratch, without input from database experts, so it's going to be a disaster.

Unless you're someone like Microsoft, Google, or Amazon, you pretty much can't build one of those. It costs tens of millions. It takes a huge amount of testing, for obvious reasons.

I really don't see any argument for not using a mature database system for managing a typical company's data.

Of course, if we aren't talking about a full-scale database that has to cope with a huge amount of messy mission-critical data in a changing business environment, then the game changes, and sure, you might have a chance just writing something yourself.

Netflix's video-streaming CDN ('OpenConnect'), for instance, obviously isn't powered by an RDMS. They put in a huge amount of highly technical work building their own finely tuned technologies to pull data off the disk and get it to the NIC with minimal glue in between. But that's Netflix, and virtually no real companies face that kind of challenge.

Also, VoltDB looks like a streaming DB technology. Isn't that both an DBMS (rather than a means of rolling-your-own), and very niche? I don't see how it's relevant here. If it's really able to serve business needs better, then great, but it's still a complex-DBMS-as-a-product.

⬐ AtlasBarfed

Yeah, I have changed my opinion of stored procs to :

If you have a proprietary database, stored procedures are awful. AHEM ORACLE.

I'm not fully on board with all of Roberts views but this point about a framework for frameworks sake is one I agree with.

https://youtu.be/o_TH-Y78tt4 starting at around 10:30 he gets into what I was getting at.

> Whereas I'd say Laravel and it's ecosystem are far more productive and time saving than simply using just PHP.

I'm not arguing a time thing.

I'm arguing that a framework that forces its architecture onto your domain model is fundamentally broken by design. My domain should drive architecture choices and the framework should let me augment that with well worn libraries and modular patterns.

Laravels architecture works for one thing: web sites. And for that, you're better off using WordPress.

Laravel is better than older frameworks, like say, code igniter but it still fights you every step of the way if you want to step outside the box.

⬐ whycombagator

> Laravels architecture works for one thing: web sites.

From the github repo:

“Laravel is a web application framework with expressive, elegant syntax”

⬐ lugg

Web applications are not websites.

⬐ whycombagator

I want to understand your points more clearly.

> Laravels architecture works for one thing: web sites. And for that, you're better off using WordPress.

> Laravel is better than older frameworks, like say, code igniter but it still fights you every step of the way if you want to step outside the box.

Can you provide actual examples of where it "fights you every step of the way"?

> Web applications are not websites.

So can I infer that a building a web application with Laravel would be stepping "outside the box"?

If so, could you please give examples of how building a web application with Laravel "fights you every step of the way"?

I don't think there's a one-size-fits-all solution to this, since different domains require different guarantees from your storage medium. For example, if you need to combine multiple actions with a certain level of transaction safety, defining an interface for that can get tricky.

Overall, I tend to agree with Uncle Bob's "Clean Architecture" [1][2] approach when it comes to DBs, though: The DB usually (rembember that there is an exception to every rule!) has no business of being the "center" of an application. It should provide you with functionality, not dictate how your business logic works.

If you can pull out your DB and give it a sensible interface, you still might end up having a lot of inline SQL queries, but they are not littered all over your codebase; they live inside a narrow scope (a plugin, say). Also, the SQL schema and queries in this case often are quite boring -- the tricky bit is coming up with a good interface that provides all the guarantees you need to uphold (complicated transactions maybe?). And remember that you need these guarantees because of how your business domain works, not because of your DB. Perhaps you can get rid of some of them if you organize your storage (i.e. DB) in a specific way?

[1]: http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-ar... [2]: https://youtu.be/o_TH-Y78tt4?t=2565

Edit: Also note that there's no reason not to use a ORM in this way, too (if it suits you). The important part is the same: The ORM has no business dictating how your business logic should be implemented, and if you try to remove it from your core application, you will end up doing the same things. Now, if your ORM makes the implementation easier for you, go ahead and use it. But don't expect things to change if you put ORM-generated code instead of inline SQL at the center of your application.

1) Do not attempt to live code. change your code via version control, build small videos, copy and paste... whatever you do... do not try and live code

2) Read "The presentation secrets of Steve Jobs" ... its not really about Steve Jobs so much as its about how to be a great presenter.

3) building or writing a talk is significantly less important than the delivery... which means that more of your time should be spent on how to deliver the speech (recording I find is the best way to practice)

4) Pick a single thing and do it well, do not attempt to put too much into a talk or tackle something massively complex.

5) Make sure that everyone is walking away with something they can actually use. This doesn't require it be a hard skill... "Soft" or philosophical utilities are just as good

6) Have Fun and be funny... Speakers have a tendency to want to show off the size of their intellect, and the level their competency- having a speech be entertaining is way way more important.

7) DO NOT READ FROM YOUR SLIDES. know your shit. slides are supplementary

Extra Credit. Here's a collection of some fantastic technical speeches:

* https://vimeo.com/9270320 * https://www.destroyallsoftware.com/talks/wat * https://youtu.be/o_TH-Y78tt4 * https://www.youtube.com/watch?v=csyL9EC0S0c * https://youtu.be/a-BOSpxYJ9M * https://youtu.be/kb-m2fasdDY

I don't think DDD is a silver bullet; building quality software will require DDD but it will also require more.

But don't get me wrong, I always been a proponent of keeping Domain concerns in The Domain layer.

It makes much more things easier in the long run, beginners should be exposed to DDD very soon in the learning process, in my opinion.

DDD and the principle of separation of concerns always reminds of Uncle Bob screaming "DATABASE IS DETAIL!": https://www.youtube.com/watch?v=o_TH-Y78tt4&t=42m45s

  How To Design A Good API and Why it Matters [0]
  The Principles of Clean Architecture [1]
  The State of the Art in Microservices by Adrian Cockcroft [2]
  "The Mess We're In" by Joe Armstrong [3]

[0] https://www.youtube.com/watch?v=aAb7hSCtvGw

[1] https://www.youtube.com/watch?v=o_TH-Y78tt4

[2] https://www.youtube.com/watch?v=pwpxq9-uw_0

[3] https://www.youtube.com/watch?v=lKXe3HUG2l4

⬐ zerognowl

+1 for Joe Armstrong's talk. Very funny, but uncomfortably true

⬐ panic

On the subject of API design, this talk is also quite good: https://www.youtube.com/watch?v=ZQ5_u8Lgvyk