Nobody:

Senior frontend Dev at my company: "microservices best thing ever"

Also him: "Relational databases gonna die"

Also him (talking to the DB team): "You're gonna dissapear, Mongo is the future"

Me: "Eh... Dude, Mongo is still a database.."

Him: "Microservices"

Send help...

Still trying to get good.

The requirements are forever shifting, and so do the applied paradigms.

I think the first layer is learning about each paradigm.

You learn 5-10 languages/technologies, get a feeling for procedural/functional/OOP programming. You mess around with some electronics engineering, write a bit of assembly. You write an ugly GTK program, an Android todo app, check how OpenGL works. You learn about relational models, about graph databases, time series storage and key value caches. You learn about networking and protocols. You void the warranty of all the devices in your house at some point. You develop preferences for languages and systems. For certain periods of time, you even become an insufferable fanboy who claims that all databases should be replaced by MongoDB, or all applications should be written in C# -- no exceptions in your mind are possible, because you found the Perfect Thing. Temporarily.

Eventually, you get to the second layer: Instead of being a champion for a single cause, you start to see patterns of applicability.

You might have grown to prefer serverless microservice architectures driven by pub/sub event busses, but realize that some MVC framework is probably more suitable for a 5-employee company. You realize that development is not just about picking the best language and best architecture -- It's about pros and cons for every situation. You start to value consistency over hard rules. You realize that even respected books about computer science can sometimes contain lies -- or represent solutions which are only applicable to "spherical cows in a vacuum".

Then you get to the third layer: Which is about orchestrating migrations between paradigms without creating a bigger mess.

Your company started with a tiny MVC webshop written in PHP. There are now 300 employees and a few million lines of code, the framework more often gets in the way than it helps, the database is terribly strained. Big rewrite? Gradual refactor? Introduce new languages within the company or stick with what people know? Educate people about paradigms which might be more suitable, but which will feel unfamiliar? What leads to a better product, someone who is experienced with PHP, or someone just learning to use Typescript?

All that theoretical knowledge about superior paradigms won't help you now -- No clean slates! You have to build a skyscraper city to replace a swamp village while keeping the economy running, together with builders who have no clue what concrete even looks like. You might think "I'll throw my superior engineering against this, no harm done if it doesn't stick", but 9 out of 10 times that will just end in a mix of concrete rubble, corpses and mud.

I think I'm somewhere between 2 and 3.

I think I have most of the important knowledge about a wide array of languages, technologies and architectures.

I think I know how to come to a conclusion about what to use in which scenario -- most of the time.

But dealing with a giant legacy mess, transforming things into something better, without creating an ugly amalgamation of old and new systems blended together into an even bigger abomination? Nah, I don't think I'm fully there yet.

I've seen several rants about dumb/useless teachers, college and the CS degree studies; today is a good day to vent out some "old" memories.

Around two semesters ago I enrolled in a Database seminar with this guy, a tall geek from the 80's with a squeaky voice, so squeaky mice could had an aneurysm if they listened to him.

Either way this guy was a mess, he said he was an awesome coder, that we were still "peasants" when it came to coding, that relational databases had nothing on him since he was an awesome freelancer and did databases every day, that we had to redo the programming course with him and with his shitty, pulled out of the ass own C++ style guide with over 64 different redacted rules.

He gave us sample code of "how it should be done" in Java...it ain't my favorite language but fuck me a fucking donkey could have written better code with his ass!! He even rewrote Java's standard input function and made it highly inefficient. He still wrote in a structural paradigm in OOP languages! And he dared to make this code reviews were he would proyect someone's code and mock it in front of the class as he took off points, sometimes going to the negative realm (3,2,1,0,-1...)

But you know what's shittier? That he actually didn't even attend, 90% of the time, it was literally this:
> Good morning class
> Checks attendance. . .
> I'll be back, I'm going to check in...
> 1 hour 45 minutes later (class was 2 hrs long) - comes back
> do you have any doubts?
> O.o no...? I'm ok.
> We're done

Not only that, he scheduled from 4 to 17 homeworks throughout the week, I did the math, that was around 354 files from everyone; of course he didn't check them, other students from higher semesters did and they gained each point taken from students making students from lower semesters get the short end of the stick.

How did I pass? He didn't understood my code or database schema and he knew he couldn't fail me as he had no ground to stand on.

Thanks for listening, if you got to the end of this long ass post and had a similar experience I'd love to read it.

Mother fucking SQL, fuck mathematicians, fuck every thing!

So let's supose we'd only need the first char of a string. Every, and I mean fucking every (php, java, javascript, ruby, python, haskell) fucking language, uses something like `substring(input, 0, 1)` as it knows the input is nothing more than a fucking array of chars, otherwise known as motherfucking String. Logically the offset for the first char is 0.

Enter SQL, there you need to put `SUBSTRING(input, 1, 1)` because fuck every one! Fucking math guys who developed relational algebra on which (most) databases are based on (I love you for it, but come on you fuckers!), Decided that the first character should be at position 1...

Fuckers

Getting real tired of having to reteach the basics of relational databases to the same 2 people. You were brought in as the expert in databases and SQL Server, I shouldn’t have to teach you about effing primary keys, secondary keys, many-to-many relationships, and how to join the damn tables in a basic query. Your 5 years of experience are obviously a waste if all you did was select * from bullshit. This is the 2nd week and 22nd you’ve asked the same damn questions. Get your crap together and study your ass off if you don’t know. Google the error messages if you don’t remember how to solve it before coming to me with the same question a 23rd and 24th time. I’m not going to get any work done if all you do is ninja up behind me with your laptop in tow and just spout off the question that could be done over IM or a quick duckduckgo/google search. Headphones in = do not disturb ya rude mother duckers 🦆.

Ok now I'm gonna tell you about my "Databases 2" exam. This is gonna be long.

I'd like to know if DB designers actually have this workflow. I'm gonna "challenge" the reader, but I'm not playing smartass. The mistakes I point out here are MY mistakes.

So, in my uni there's this course, "Databases 2" ("Databases 1" is relational algebra and theoretical stuff), which consist in one exercise: design a SQL database.

We get the description of a system. Almost a two pages pdf. Of course it could be anything. Here I'm going to pretend the project is a YouTube clone (it's one of the practice exercises).

We start designing a ER diagram that describes the system. It must be fucking accurate: e.g. if we describe a "view" as a relationship between the entities User and Video, it MUST have at least another attribute, e.g. the datetime, even if the description doesn't say it. The official reason?

"The ER relationship describes a set of couples. You can not have two elements equal, thus if you don't put any attribute, it means that any user could watch a video only once. So you must put at least something else."

Do you get my point? In this phase we're not even talking about a "database", this is an analysis phase.

Then we describe the type dictionary. So far so good, we just have to specify the type of any attribute.

And now... Constraints.
Oh my god the constraints. We have to describe every fucking constraint of our system. In FIRST ORDER LOGIC. Every entity is a set, and Entity(e) means that an element e belongs to the set Entity. "A user must leave a feedback after he saw a video" becomes like

For all u,v,dv,df,f ( User(u) and Video(v) and View(u, v, dv) and feedback(u, v, f) ) ---> dv < df

provided that dv and df are the datetimes of the view and the feedback creation (it is clear in the exercise, here seems kinda cryptic)

Of course only some of the constraints are explicitly described. This one, for example, was not in the text. If you fail to mention any "hidden" constraint, you lose a lot of points. Same thing if you not describe it correctly.

Now it's time for use cases.
You start with the usual stickman diagram. So far so good.
Then you have to describe their main functions.

In first order logic. Yes.

So, if you got the point, you may think that the following is correct to get "the average amount of feedback values on a single video" (1 to 5, like the old YT).
(let's say that feedback is a relationship with attribute between User and Video

getAv(Video v): int
Let be F = { va | feedback(v, u, va) } for any User u
Let av = (sum forall f in F) / | F |
return av

But nope, there's an error here. Can you spot it (I didn't)?

F is a set. Sets do not have duplicates! So, the F set will lose some feedback values! I can not define that as a simple set!

It has to be a set of couples, like (v, u), where v is the value and u the user; this way we can have duplicate feedback values in our set.

This concludes the analysis phase. Now, the design.

Well we just refactor everything we have done until now. Is-a relations become relationships, many-to-many relationships get an "association entity" between them, nothing new.
We write down on paper every SQL statement to build any table, entity or not. We write down every possible primary key or foreign key. The constraint that are not natively satisfied by SQL and/or foreign keys become triggers, and so on.

This exam is considered the true nightmare at our department. I just love it.

Now my question is, do actually DB designers follow this workflow? Or is this just a bloody hard training in Pai Mei style?

When used properly No-SQL databases are an incredible resource but my employer keeps hammering them in problems which could better be solved by traditional SQL databases in an attempt to be more "hip" and "cool".

This causes huge PITA in making the database work properly with the ORM we're using and waste of time since we're force to emulate basic features which are already exists in almost any SQL database (i.e. relational integrity) using No-SQL storage.

I see a trend for new devs to want to focus on JavaScript while dismissing relational databases and backend languages as boring and to rigid. A week into real jobs they want help with data and .net.

I learned basic, Visual Basic and java in high school, then one year of college studying c++. I really hate c++ and swore I would never become a programmer. After that one year of college, I spent two years out of the country with no computer usage at all. Then 4 years working at a grocery store.
Then my friend told me about an opening at his work place for a java programmer. This was 7 years since doing java and 6 years since I had programmed anything at all. But I applied and interviewed. When asked about databases, I said “I know a little Microsoft Access.” Had no idea what relational databases were, never heard of php, but by some miracle they hired me anyways. Still working for them 6 years later, now an experienced java, php, MySQL, front end developer.
Still have no idea why they saw fit to hire me.

Am I the only one who doesn't like NoSQL? I really like relational databases.

If I cannot see the light then convince me to like NoSQL. But I think I will be forced to learn it because some companies use NoSQL. Also tech stacks like MERN, MEAN, etc.

Has anyone here used MongoDB for relational databases? I am trying to use MySQL with Node but I feel like the whole thing is a mess. There are some ORMs like Knex or Sequelize for MySQL but they are pretty crap. I am thinking if I should just move onto MongoDB instead of MySQL, at the same time I feel a little dirty to store relational data in a document store :(

at one point in time, i had to work with a really junior backend team, they used javascript and neo4j as the database for an in-house developed community forum because "graph databases made sense" in the eyes of their tech lead

turns out that the team struggled quite a bit with it, and had some "unexpected complexity" problems when i asked them to add filters and sorting on the post endpoints

in the end, the "solution" they gave me was an endpoint that spewed ALL the posts so i could sort it in the front end

had they kept the same relational database they were using for the rest of the whole project, i'm quite sure it wouldn't take much to implement that (and their architecture was really performatic)

as a side project i rebuilt the whole forum in a weekend, but using postgresql as database, and it worked nicely, i even added some unit tests just for fun

gave myself a really big slap in the face after that, though

DBeaver is probably the best, most underrated UI for interacting with relational databases, that's free and universal.
It's just sad that I had to try out literally everything else, which is total crap in comparison, before I stumbled upon DBeaver.

Urgh.. the amount of things you have to know as a developer.. it can get stressful and frustrating sometimes when (in-depth) technology knowledge is demanded from you (for instance, for a job position)..
It's like being a doctor, being a lifelong student.

A few examples of what I had to know during my career:
Java, .NET, Python, PHP, JavaScript/HTML5/CSS3, Sass/Less, Node.js, ReactJS, AngularJS, Vue.js, Cordova, Ionic, Android, design patterns, SOLID, databases (design, implementation, administration, both NoSQL and relational,..), deployment tools (Octopus, Jenkins,..), VCS, CI/CD, HTTP, networking, security (OAuth2, CORS, XSS, CSRF,..), algebra, algorithms, software testing, profiling, Linux, Unix, Windows, MS Office (advanced mail filtering,..), ITIL, IT Law (licensing and its implications when choosing a product, distribution right,..), server architecture,..

Sure yeah, I know, I've studied all that at university but.. it's been too long (almost a decade now). I have to revisit that knowledge.

Relational databases

Can someone try to sell me on NoSQL? I've never seen a use case for it so I want to hear a NoSQL Fan's perspective

Fuck you, webdev.
I had to explain to a new web developer about an Oracle database and Toad. Anyone remember Toad? I still remember not too long ago, developers knew the basics of relational databases and available client tools.

Why employers strongly believe Front-End and Back-End are synonyms of Full-Stack?
They are requiring Front devs to have knowledge and experience with relational databases and Back devs to be experts in HTML and CSS, sometimes graphic design stuff too.
For God's sake just hire a Full-stack Dev

had a uni exam in databases (just closely didn't make it😒)
it didn't even have sql in it!?

questions about ER diagrams and draw a diagram, functional dependencies with given dependencies, find candidate key and what not, work on a b-tree (miserably failed😣), datalog (who the fuck cares about datalog? the least expected topic) and transaction management/serializability

whose idea was it to not include sql?? isn't it one the fundamental parts of relational databases?

I really want to switch my career from being a Full-Stack python/javascript developer to be a Data Engineer.

I've already worked with relational and non-relational databases, troubleshooted a couple of Airflow DAGs, deployed production-ready python code but now I feel kinda lost, every course I start on the Data engineering topic feels really useless since I feel like I've already worked with that technology/library, but I'm still afraid of start taking interviews.

Any good book/course or resource that I should look in?

BTW first rant in a couple of years, this brings me memories