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?

Slowly working it up now, actually.

An annually updated, unbiased, multiple source application that engineers can use to check salary offers vs their skills, to make sure they don't get shortchanged. Intended to work for the entire planet (that we have data for).

I just got this in the mail. Must have bought the MEAP and forgot about it!

Super cool....

But mostly completely terrifying.

It’s like the book of everything I don’t know.

A really fun story to read. Makes me think of my own work shenanigans. Good to know Uber is just as fallible!

https://mobile.twitter.com/stantwin...

Github 101 (many of these things pertain to other places, but Github is what I'll focus on)

- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.

- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.

- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".

- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.

- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.

- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....

- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.

- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.

- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.

- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.

- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).

- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.

- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)

I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!

Whenever I have my mac crash and corrupt its OS, I just get a backup harddrive and it copies itself FLAWESSLY. I have all my programs, settings, settings in programs and files.

When Windows crashes, and I use the recovery tool, I LOOSE EVERYTHING. The only thing I get to keep are my files, and they most of the time have permission issues after a restore.

Windows is like the toddler that stares out to void of existance and can't do anything but drool on their shirt, while its parents say he's highly gifted.

Fuck me we're able to choose between only a few OS'es that my clients know and allow me to work on but things like this just make me want to go be a chicken farmer or something.

Anyone draw out the logic of a process by hand before coding much?

I've been doing that more and more, and it's handy but ... it's also kinda tedious making them on paper or even just in the VS Code extensions I've tried.

I'd really like a way to bust out quick flow charts in VSCode and there's a Draw.io add on and it's ok but lotta fidgeting with flow chats and dragging stuff.

It doesn't have to be pretty and it doesn't have to be super feature rich.... just want to quick bust out a series of steps flow chart style or ... hell any way fast and visual like.

Anyone use anything they really like?

I was asked what are the disadvantages of using RESTful over SOAP, I couldn’t think of any - maybe having to access a legacy system? Any ideas?

To be a good developer, you must thrive in chaos, and have an insatiable desire to turn it into order.

All user input, both work tasks and actual application input, is pure fucking chaos.

The only way to turn that input into anything usable, is to interpret, structure and categorize it, to describe the rules for transformation as adequately as you can.

Sometimes companies create semi-helpful roles to assist you with this process. Often, these people are so unaware of the delicacy of the existing chaos, that any decision they make just ripples out in waves leaving nearly irreparable confusion and destruction in its path.

So applications themselves also slowly wear down into chaos under pressure of chaotic steak-holders which never seem to be able to choose between peppercorn or bernaise sauce for their steaks.

Features are added, data is migrated between formats, rules become unclear. Is ketchup even fucking valid, as a steak sauce?

The only way to preserve an application long term, is refactoring chaos into order.

But... the ocean of chaos will never end.

You must learn to swim in it.

All you can hope to do is create little pools of clarity where new creative ideas can freely spawn.

Ideas which will no doubt end up polluting their own environment, but that's a problem for tomorrow.

So you must learn to deal with the infinite stream of perplexed reactions from those who can't attach screenshots to issue reports.

You must deflect dragging conversations from those who never quite manage to translate gut feeling into rational sentences.

You must learn to deal with the fact that in reality there are no true microservice backends. There are no clean React frontends. There are no normalized databases. Full test coverage, well-executed retrospectives, finished sprints -- they are all as real as spherical cows in a vacuum.

There is no such thing as clean code.

There is only "relatively cleaner code", and even then there are arguments as to why it would be "subjectively relatively cleaner code".

Every repository, every product, every team and every company is an amalgamation of half-implemented ideals, well-intended tug of war games, and brilliantly shattered dreams.

You will encounter fragmented shards of perfect APIs, miles of tangled barbed documentation, beheaded validator classes, bloody mangled corpses of analytical dashboards, crumbled concrete databases.

You must be able to breathe in those thick toxic clouds of rotting technical and procedural debt, look at your reflection in the locker room mirror while you struggle yourself into a hazmat suit, and think:

"Fuck yes, I was born for this job".

Why the hell are companies going to AWS and Azure instead of GCP??? I mean for Azure I understand compliance is a little easier with HIPAA and similar things but seriously.

GCP is so transparent about everything and it's simple for everyone.

Everyday i used to spend an hour in the morning reading emails.

Until i made a script that reads all mails, parses to urgent/priorities/meetings etc. Then shows me a dashboard of everything. 1 hr turned to 20mins max.

Then i made a chatbot out of it and now i just talk to it everytime and gives me the rundown.

Gave me so much time to code instead of reading fucking emails.