That's not just shared acceptance because even if the mighty USD should crumble and fall, a US citizen will still be able to pay the taxman with a dollar bill which is in itself of great value.
A forgotten BBC programme on a desolate YouTube channel that seems even more relevant in 2021 than the day it was broadcast in 2013. Contains gems of understanding, knowledge and interesting experiments pertaining to the corona virus and COVID-19, but years before the pandemic even arrived.
I sometimes answer questions in the tech-help reddits to get a feel for the kind of IT-problems everyday users are battling with.
The amount of people asking if they can upgrade the CPU, GPU, SSD/HDD or memory in their new-ish laptops is disheartening. Most of the questions concerns the CPU og GPU where the answer is no 99.99% of the time these days. 90% of consumer grade laptops have the RAM soldered to the mainboard too now. Luckily the HDD/SSD is usually replaceable or upgradeable in case of failure, performance problems or lack of free disk space... but for how long?
From a purely ecological standpoint, the laptop producers should be forced to buy back and recycle all their shitty unupgradeable, unrepairable, made-to-fail consumer electronics. It's a shameful situation we are in.
If societies can get 99% of glas and plastic bottles recycled using bottle deposit money, we should be able to reach the same figures for consumer electronics like laptops.
IMHO lots of teachers have an absolute horrible understanding of relational databases and SQL. Myself included, until I started working at large financial institutions and read every book by Joe Celko I could lay my hands on.
E.g. using NATURAL JOINs covers about 1/3 of the use cases where students or apprentices are usually fiddling with INNER JOINs or joining relations using WHERE TableA.ID = TableB.ID, and it's syntax is much simpler.
With a well thought out schema, I personally find that NATURAL JOINs covers about 80% of my needs in that respect, and being unable to NATURAL JOIN tables is beginning to indicate well, not a "code smell" but what I would call a "schema smell".
I fully agree. Joining relations in a relational databases should absolutely be simple - and it absolutely can be:
SELECT col_x, col_y
FROM TableA
NATURAL JOIN TableB
Allthough everything in this medium article might be factually correct, it doesn't seem to me that Tomas Pueyo has any kind of relevant medical or microbiological education to base the content in this article upon. It content just seems to be just a mishmash of stuff gathered on the internet. My fear of this kind of medical bro-science writing is that it is probably doing more harm than good. Please leave this kinds of writeups to the experts. The situation is far too serious for armchair experts to be doling out advice.
Nice article, but just a headsup: The website certificate of runwes.com is only valid for the following names: www.github.com, * .github.io, * .githubusercontent.com, * .github.com, github.com, github.io, githubusercontent.com.
Everyhing is alerts and warnings when clicking the link.
1-2-3NF is super important and superficially simple. But just to give you an example with 1NF where the devil is hidden in the deails, let's have a closer look at ye good old "Address" entity. If we are to store a postal address for package delivery the columns "Address Line 1-2-3" should suffice and enable quick entry in the UI and simple printing on letters and package labels. What's not to love?
But what if you are working in a municipality and need to be able select all commercial buildings with more than five stories, or businesses situated in the basement of the building for the yearly fire inspections? Then string-searching all those randomly entered address lines will quickly become a complete nightmare - where as if the floor number was normalized and stored in its own column the query for the fire inspector's report would be a piece of cake.
This is a good example of why it's so hard to do cookie-cutter-implementaion-ready-schema-design-templates. It's also a good example of why datamodeling is important no matter underlying tech-stack this data model is going to be implemented on.
Also, I prefer modeling the app, business or process in Chen's ERD first as I think it is much better at capturing modeling details than UML and other ERD-variants.
Also, just as each object class in OOP should do only one thing, each entity should be saved just one table. Eg. that "Employee" table in the first chapter of every beginner database book with a "Manager" relation as a foreign key to itself is an absolute catastrophe and very . The moment your CEO decides you are now in a matrix-organisation, everything breaks down datamodel-wise. The Employees go into one table, the Organisational Structure type into another - they are related by foreign keys and it's not that different from good OO modeling as people say. The tables containing organisational structure should probaly also have columns with a from- and to-date and a relationship to a Department table so different departments can be organised differently throughout their lifetime.
Also, entities which have some sort of lifecycle should also be split into different tables. So there should be a table for "Prospective Employees", "Current Employees", "Resigned Employees", "Former Employees", etc. An employee's day of resignation can now be not null and go into the right table. You can always UNION these three or four tables together into one big view or materialized table, and at the same time you will avoid a massive amount of WHERE statements that each need their own indexes, picking out just the right employees from that big generic Employee table in every effing query.
Also, columns with endless NULL values are a "code smell" in a relational database. Whatever value is hiding in the few rows with values probably belong to another entity and should have been stored in another table with the name of that "thing". Eg. the employee's day of resignation again.
Also, 99% of all business datamodels can be implemented in a relational database using just tables, views and queries created in standard SQL. You will rarely if ever need user defined functions, generators, connectors, stored procedures, foreign code blobs and other exotic and vendor specific extensions.
Also, I recommend reading everything by Joe Celko.
The site excellent but is serving a TLS-certificate from: * .herokuapp.com instead of * .visualhaggard.org, so everything is big red browser warnings and the search engines will punish you guys accordingly.
Opposite view: Salary disclosure primarily destroys value for people with strong negotiating skills but who are not necessarily the best contenders for the actual job - especially when it comes to highly specialized tech jobs as many of them are introverts. It also enables work force diversity which is actually the best outcome for the company in the long run.
Salary disclosure is also a prerequisite for having a public discourse about equal pay and equal rights based on factual information. You might call that to: "gang up", but I certainly wouldn't.
Our daughters, girldfriends, mothers and sisters are all living breating people in our lives - maybe even the most important ones we have where as a company is just a thing. My own startups are just a piece of paper, a tax information number, an organizational construct, nothing more. I can create another one in 2-3 days. Close a company and if there's customer demand, another one will just spring to life and fill the gap. I might be sad and in debt for a while, but society at large will not even notice. It doesn't matter.
That's not just shared acceptance because even if the mighty USD should crumble and fall, a US citizen will still be able to pay the taxman with a dollar bill which is in itself of great value.