zkomp

Sigh. Slackers gonna be slacking.

Why are we regressing back to the horrible world of vendor lock in and single browser sites. Chrome is the new IE6?

I can agree slightly on some of this, but it quickly miss the point completely and is not even funny or satire.

It is quite simple: just skip the people and or technologies that make you vomit in your mouth and go for the interesting parts instead.

FOSDEM is huge and there is usually something somewhere that will be interesting. PostgreSQL, Prometheus, Grafana, Firefox, (tomorrow Rust). Nothing to complain about, and it is free.

It was a good talk at fosdempgday. Well paced, funny at times, esp the part comparing booleans with mysql "booleans" and "check constraints" (spoiler neither boolean nor checked)

Too bad I'm stuck on 9.1 for the time being which lack many of these really nice features.

eeerm... Yeah, like Facebook (it's the actual name)

(best to just spell out the obvious)

This is still playing the game / i.e executing the instructions. Exactly the same instructions on same hardware that were distributed to everyone...

This is just the extreme form of the fastest way to complete the game, using the (broken) logic of the game itself.

Exactly the same situation as comparing play at home with kids to any elite world record setting play in the same game... "This world cup is not at all how I play at home ..."

I disabled most notifications but is still occasionally hit by this; more annoying imho is trying to use siri-app "suggestions", the exact moment you press it often reorganize the icons making you enter something completely unrelated!

In Stockholm, there is one journal system everyone is mandated to use, written in APL (was called Take Care but could have changed name), and completely without access control.

I believe each institution get printed access logs sent to them, which is never looked at.

Sad to see Apple drop the ball completely with all the little things.

I've seen issues with the touchbar and keyboard from all my collegues. As a long time apple user, (since forever, early 90ties) I will never buy one of these pieces of expensive shit ever. A new design with escape and functional keyboard is required to get me back...

Hmm are you sure? I've read the fractal of bad design many times.

Some issues might be "fixed" but could they fix the actual *fractal of bad design"?

Isn't it still a mix of c-style, java-style, inconcistent, left associative, horribly broken language it always was?

I always thought the bugs were anecdotal backing of the main point: php is badly designed, non programming language for non programmers, who suffer stockholm syndrome from all php abuse...

Ouch I did not know Valve had sunk so low... String matching parts of a local username alone can not ever be enough for a ban... Completely ridiculous

I don't get it either. Neither see the supposed (objective) "errors" in the language design.

Why not have both raise/rescue and throw/catch when the used are different. And why not have both methods, functions and closures? It is for different things... Why read docs when you have irb and can pretty much inspect everything you need.

All the comparisons with java... I hate it, much rather use ruby style OO than the horrible boilerplate hell that I remember from java.

Problem with ruby is not that it is not java, it is imho sometimes it is too easy and forgiving - letting you do crazy things like unintentional meta programming, and not catching errors until runtime. Other problems with ruby is complexity and the lack of clear spec (lookup what happened to the rubinius ruby spec project).

First thing I do on every new device, computer tablet or phone is disable the stupid autocorrect. I can't understand how it can be the default. Spellcheck and suggestions are fine, autocorrect absolutely not...

The more languages you need to type, the worse it becomes.

(have we come to some max nesting level here, cant reply to the child comment)

One db can be a problem, or a strenght depending on the domain; And I really dislike religious design, esp microservices.

I have less problems by avoiding ORMs (and religios microservice arch, or fundamentalist interpretations of rest)

Database handles the shared state in a heterogenous environment. We need it to be centralized to keep track of money, the apps can't do that, two independent databases cant do that either. It must be one system that guarantees concistency.

It works great, there is no downtime. The interfaces are defined, the database stands alone, updates are deployed separately.

I like data. A database is created to handle it, give you tools to query, modify, scale, secure the data.

A rest api... how and why should it be responsible for your data? It solved a different problem.

You might not even need a database I guess, and then anything goes.

I need and like my database, and have suffered trying to get along with different ORMs. SQL is so good at what it is designed to do if you just let it.

(And why just one rest api? How about 100 restapis, some microservices, some web apps, some background workers, many different languages. One database. No ORM)

I personally would write a simple plpgsql stored procedure, but I would not trust user input and only allow a defined set of colums from a defined set of tables.

you can have lots of dynamic sql but that might become a rabbithole, just as with an ORM. It sounds like a problem you shouldnt have, now throwing an ORM at such a problem... might lead to even more strange issues down the road...

The db is separate and the interfaces are defined and the test is for this interface (as part of the schema repository)

You dont need an ORM for testing your code...

But I think this varies from project to project. How many different applications, in different languages are using your db and do you tolerate downtime?

I think bussiness logic in the database has prevented disasters in the projects I have worked on. I honestly dont see how it could have been solved better...

It probably depends on the domain/problems.

My experience is with transaction heavy financial systems or similar, with web frontends, microservices sprinkled around in different languages...

The web app or java worker should be allowed to focus in its problems, the bussiness logic needs to live in one central place, which happens to be in the database accessed through thightly controled interface in the form of stored procedures.

As far as I know, in my experience. Stored procedures in postgres are good when you really use the database and care about the data, you need transactions, need to handle races and concurrency etc. Whereas ORMs break down at this point or prevent you even getting to a point when you can use your database as a database.

Why pretend your SQL database is about objects? It is not... (it is about data)

A stored procedure can act like a view or a query, or use procedural logic. Point is: your app can call it and get a concistent result, no matter what refactoring has been going on.

A direct query needs to know too much about the database (orm generated or otherwise) which prevent refactoring and couples app to database harder...

You can rename or merge tables, views functions in the database but the interface the app use (stored procedures/DAL) will stay the same and work the same way.

As for app logic... I prefer bussiness logic in the database, not the app when the data is important. Application logic stay in your application, data dependent bussiness logic stay with the data.

you solved isolation decoupled much of the db logic from app-logic and made security easier

you can deploy schema changes independently

you can change everything and the app should not notice

There are several such tools, which are specialized and thus tend to perform a better job than orms (who try to do everything)

But I would recommend writing, reviewing and deploying migrations by hand, esp for critical parts of the schema (automatic tools are almost guaranteed to get something wrong, with locking etc)

I disagree. ORMs dont bring value, they dilute value and piles abstractions upon apstractions. Your application becomes hard to maintain, database hard to refactor, queries slow.

ORMs seems nice for simplified problems but becomes a horrible mess for real problems imho...

I've worked on some rails apps, and the ORMs caused more problems than they solved...

No. You should really wind up with a DAL. Define some stored procedures for accessing and working on the data and use only stored procedures.

No need for ORM, and no inline sql logic in your application code.

But why do you need these containers of data, when you could have more direct access to both the data itself and the whole set (not individual objects, nor collections of objects)

I dont like ORMs but did struggle some years trying to use them which imho was a detour. SQL and stored procedures in plpgsql is so much better, easier to maintain, easier to reason about etc.

I disagree. It is not at all a design mistake in sql. You can have or forbid null values in tables. And you need that for many things. It is properly designed.

Rust or functional languages show you do not generally need null references, you have options instead. It is completely different.

Null in C or C++ is much more a very costly misstake. Missing data is just reality.

Data may be incomplete, the values unknown. SQL is designed for that. It is designed to handle reality. Whereas null references are not, they cause problems you do not need...

Data != reference

you can avoid the issue of allowing invalid references everywhere

you can not avoid incomplete data.

(As the other comments already said:) null references are not the same as null values.

A database sometimes needs to model this case: the value is unknown: maybe the paper file you digitized was corrupted or destroyed, or other valid reasons this value is not known.

Whereas null references can be avoided, like in rust etc.

In sweden, yeah, two things: there has been much, too much, batshit-insane anti drug/prohibitionist propaganda for decades. And the fact nations are bound by the UN Convention that mandate prohibition. Politicians are retards who rather see people die than legalize...

Smaller changes tend to be safer and should break less. The less you change at one time, the better and less bugs which are easier to spot and fix.

But if safety does not matter, or its pure crap anyway. Then refactor away.

Proper review of core components that are used and proven is hard already, refactoring such components - don't do it if avoidable - there must be a very good reason. And convenience ain't one - you'll probably get some duplication of code and double maintainance during the transition period.

Making small PR is just a way to be safe and smart, one branch with individual gradual commits that could be used separately is also a way (if they could be reviewed separatley).

"Essentially, even one or two weak reviews in a chain of reviews can break the entire consensus system with a catastrophic bug. Hopefully, this can be an object lesson in making sure critical changes are reviewed very thoroughly. Stay safe and go thank the developers that do the hard work of not just coding, but reviewing."

Amen to that. Doing a proper review for any software is so hard, so not fun and often misunderstood and unappreciated (by management).

And then when shtf you also get the blame for your "weak review".

Just want to add one thing about swagger:

please think through your API if you are to design an API, the tools will not think for you and you can fool yourself instead...

Swagger will not magically solve anything. I have seen and experienced that you can really create nonsensical but pretty and auto documented APIs using swagger in no time.

Yes absolutely: this very magic is precisely what is so horrible and imho a rabbithole of insanity. It is CORBA resurrected with XML.

In my data oriented mind, the primary thing that matters is the data that is sent, the second is other semantics like idempotency.

Neither SOAP nor XML solve or helps: there might be no wsdl bindings in your language, or they are badly implemented (true in my experience).

XML make people nest structures where it could have been flatter, SOAP even more, and annotates everything whithout a need for that.

This cost for no reason but to entertain the CORBA like pipe dream, or should I say nightmare.

We just resorted to pulling out data from xml with xpath. And more or less template the response back, no wsdl and very simple.

But why inflict this pain on your API users?