fabiosussetto

let's see your side projects then, no?

Haha, indeed, missed opportunity :)

"It would culminate the ancient human quest for knowledge, which began when the first of our ancestors asked, "Why?""

I'm always baffled when I read these kind of quotes, especially coming from such smart people. Do they just forget that our theories are models of reality? I personally believe that there are no wave functions or vibrating membranes out there, as there are no "triangles". These are just names for our mental models on which we map reality the best we can. Fitting models are very useful, but they certainly don't answer the big "Why?" and are doomed to be superseded by more accurate ones, when progress is made. Is it just me thinking this?

I think there's often an underlying confusion between different tools and what they are supposed to do.

An ORM - as the acronym says - is helpful to map database records to objects in the system. The meaning of the acronym already says that an ORM is not really designed for scenarios like aggregations and reporting. Within those contexts, you don't normally reason in terms of list of "objects" and "relationships" between them.

A "SQL builder" gives you a nice programming interface to build and manipulate SQL statements. Manually building complicated SQL strings is tedious, error prone and it makes it hard to reuse the same queries. With a SQL builder instead you can easily add dynamic conditions, joins etc, based on the logic of your application. Think of building a filterable Rest API that needs to support custom fields and operators passed through the URL querystring: concatenating strings would be hard to scale in terms of complexity. Some people prefers to use templates instead of SQL builder to add conditions, dynamic values, select fields etc. I personally find that this approach is like a crippled version of a proper SQL builder interface. I prefer to use the expressiveness of a real programming language instead of some (awkward?) template engine syntax.

I think the confusion between these two different tools is caused by the fact that in some popular frameworks as Django or Rails you just get to use the ORM, even if behind the scenes the ORM uses some internal query builder.

Other ORMs like SQLAlchemy instead gives you both tools. You can indeed use SQLAlchemy as a ORM and you can also use it directly as a SQL builder when the ORM abstraction doesn't really work.

Normally, if someone tells me that it's better to write SQL queries by concatenating strings, I'd ask them how they'd build a webpage that filters products in the catalog with a series of filters specified by the user (by price, by title, by reviews, sorting, etc.). Try and build that concatenating raw SQL bits, without making a huge mess.

Also, the "just learn SQL" may apply to ORMs, but certainly not to a SQL builder.

How's that modified modernizerjs script ended up in there? I mean, it must have been included directly from the BA website? I also wonder how can BA be so sure about the dates this was stealing payment data, since this was apparently a frontend attack. Maybe they somehow know when that js script had been modified?

So for now the Ethereum promise to have a distributed network where I don't need to trust any man in the middle is really not possible yet on mobile devices?