62

Never gonna happen:

* Port our API to graphql. Or even make it just vaguely rest-compliant. Or even just vaguely consistent.
* Migrate from mysql to postgres. Or any sane database.
* Switch codebase from PHP to... well, anything else.
* Teach coworkers to not commit passwords, API keys, etc.
* Teach coworkers to write serious commit messages instead of emoji spam
* Get a silent work environment.
* Get my office to serve better snacks than fermented quinoa spinach bars and raw goat milk kale smoothies
* Find an open source IDE with good framework magic support. Jetbrains, I'll give you my left testicle if you join the light side of the force.
* Buy 2x3 equally sized displays. I'm using 6, but they're various sizes/resolutions.
* Master Rust.
* Finish building my house. I completely replaced the roof, but still have to dig out a cellar (to hide my dead coworkers).
* Repair/replace the foundation of my house (I think Rust is easier)
* Get slim and muscular.

Realistically:

* Get a comfortable salary increase, focus more on platform infrastructure, data design, coaching
* Get fat(ter). Eating, sitting, gaming, coding and sleeping are my hobbies after all.
* Save up for the inevitable mental breakdown-induced retirement.

Comments
  • 5
    houses are never ready. everytime you are finishing something you find something other that can be better.
  • 1
    every programmer knows that programs are never finished. i really meant houeses(thirdlast point)
  • 1
    Is graphql really all everyone says it is? I cringe when I think of using anything Facebook had a part in. But everyone seems to love it.
  • 2
    @deusprogrammer Rest has serious problems when working with data that's not shaped like sets of raw database rows.

    You can implement paging, and use request parameters for some filtering/selecting... but that's kind of where the standard stops.

    If you want to know "The average age of users who listen to metal and live in a 30km radius of Berlin" you either have to ask the backend dev to make a super specific, new, non-resty aggregate endpoint... or slurp through all the stacks of pages of three endpoints and reduce it on the consumer side.

    Graphql gives a bit more power to the end user to ask for intersected / constrained / aggregated results in a more efficient way.

    Of course, that's particularly useful when you're questions are not about resources, but about relations, when your questions are "graphy".

    BTW, lots of Facebook projects are MIT licensed. If you don't like that it's "theirs" — fork it. Then it's "yours". 🙃
  • 1
    That’s not true though, you can pass relatively complex queries through a REST endpoint as query parameters. And with NoSQL acting as your data layer, you can have your data fit any schema you want (even no schema what so ever). Granted the way queries are handled in graphql intrigues me a bit.
  • 0
    May I ask why you consider MySQL to be "insane"?
  • 1
    @deusprogrammer Of course you can... the problem is that when end users need very complex sets of data, implementation becomes less defined by the meager rest convention, and puts more strain on backend devs to come up with new, company-specific conventions. This often leads to inconsistent APIs, especially when a big team maintains it.

    You could of course implement graphql yourself as resty query parameters — in a sense graphql IS just a good standardized protocol and extension of rest, defining how to handle common painful things like inclusions and filters.
  • 4
    @eArshdeep

    MySQL has a lot of documented and undocumented quirks, and it's much harder to scale than most other SQL databases. Clusters don't always perform nicely, and it require a lot of query optimizations and database design efforts not needed in other databases.

    Oracle is not putting a lot of energy in fixing small inconveniences and problems, and seems to actively prevent the community from getting involved (majority of code is open source, but they decline all patches).

    If you compare MySQL to MariaDB, the former often feels like a hacky alpha version, the latter like a mature database, which is weird considering their ages.

    If you compare MySQL to Postgres, the former feels like you have installed the trial demo version of the latter.
  • 1
    @bittersweet

    Thank you for such a informing reply.
  • 1
    @dfox kinda annoying that two weeks in a row the weekly rant is polluted by years old rants. Is it possible checking the timestamp on them and not just blindly sorting them by tags?
  • 0
    @AlgoRythm I’m a little torn here. I could filter them out but I kind of like the time-capsule aspect of seeing them in week 200, if that makes sense? I’m curious to hear some more thoughts on this.
  • 0
    @dfox I don't mind seeing them, I think I mind seeing them sorted towards the top. I wanted to read week 200 rants, but when I clicked on the link, it's only week 100s for the first few.

    It's also confusing since I need to figure out which topic they're responding to. Perhaps putting the date of a rant in the preview list (before clicking read more) would help.

    Time capsule only really makes sense if the two topics are directly related. (How close was your week x prediction?)
  • 0
    @dfox i have some ideas:
    1. Some numbers are locked for old rants to prevent this. This could be problematic in this crisis.
    2. We introduce a wkf (weekly future rant) for weekly rants about the future. Since not every rant needs a wkf the number wouldnt need to be synchron with the wk number.
Add Comment