Readit NewsThe external key is base64 encoded for use in URLs which results in an 11 byte string.
This hides any information about the size of the data, the creation date of customer accounts (which would be sort of visible with UUIDv7) and prevents anyone from attempting to enumerate data by changing the integer in URLs.
I thought about using UUIDs as external keys but the only compelling use case seems to be the ability to generate keys from many decoupled sources that have to be merged later.
64 bit should be enough for most things https://youtu.be/gocwRvLhDf8?si=QBheJCG21bAAV0Z7
It's similar to UUIDv7 (it leaks the creation time), but it's not an issue for me.
So I am able to have a single 64 bit key, which can easily be formatted into a small string for user-facing urls.
[^1]: https://instagram-engineering.com/sharding-ids-at-instagram-...
One question: It seems it could be troublesome to have to move / resize everything when adding a new card once a canvas is already quite busy. Is there something like auto-layout in the work, to handle these situations? (like to automatically re-layout cards and groups once adding a new item in between)
4/10/22
>Write Article
>Go Shopping
* Milk
* Cereal
>Pay Plumber
If I only paid the plumber that day and bought cereal, on the next day you'd have:
4/10/22
>Pay Plumber
>Go Shopping
* Cereal
4/11/22
>Write Article
>Go Shopping
* Milk
That's basically the whole thing. Of course there's a standard calendar app too. After a few months it gets long and you roll over into a new doc. I can always scroll to the bottom and I have a nice diary of things I accomplished. I don't know how you could improve the implementation over a google doc. The good thing about a Google Doc is if I get stuck on some todo I can brainstorm right in the doc. That's the hardest part with a to do system. Some To Dos stay on there for a while and need a lot of context, creativity and brainstorming to get done.
Recently switched to do the same on Notion, moving items in a "Worklogs" database at the end of each month (with one entry per month) to keep the Worklog size manageable. If a task gets too long I can just create a sub-page for it (or a toggle), put all the context information there, and just add a link to the TODO item.
Frankly, most orgs will not reward pro-activity, in fact you can even be punished for it, since if a problem is not yet known by stakeholders then why are you solving it.
There have been times in my career where I spotted issues from other teams on preview or staging servers and helped to fix it. Then I later got blamed (or dragged into the subject) when a similar issue occured on live which I had no association with.
It's better to just sit back and do the minimum, but do it well and professionally. Most importantly, don't make yourself too available:
> Don't respond immediately to messages and emails.
> Don't propose solutions, that you will have to own (at least partly).
> Don't answer questions outside of your responsibility space - even if you know the answer. Instead, direct people to others who should be answering those questions.
As much as I recognize this can be good advice, this comment makes me sad.
It's like "start underperforming" is the answer given to bad management problems.
Which I agree actually makes sense in a lot of companies (if pro-active efforts are not already being recognized, then it's hard to change the culture).
I also think that a lot of comments here are directed toward financial success, but many people are actually looking for meaningful ways to contribute. People for which the "re-active" approach might not be a solution.
What would be the solution for those people? How unlikely is it to actually switch to a company which recognizes employees willing to be more involved?
I seem to recall del.icio.us being a great discovery tool, as well as a great way to catalog your bookmarks (another discovery tool that was great for a while was Stumbleupon). Will be interesting to see if anyone can bring back some of that "old school" curated/personal discovery vibe, which feels like it's becoming more relevant again with the recent discussion around Google results.
- I was expecting the package to either be revoked, or to have a new `6.1.64-2` version being published with the previously good known state.
Maybe it wasn't done because it was not possible (mirrors being write-only, and maybe other complications in publishing a 6.1.64-2).
- I was expecting some guidelines to be published for affected machines. I've seen questions being asked [1], but no answers to them yet (so users are not sure if it would be safe to rollback to the previous kernel version (6.1.55-1) or not).
Maybe it's because the problem is not well understood yet, or maybe there are not enough people available to answer such questions on a weekend?
If someone can provide some context about "how these things work", it would be interesting to learn more about this.
[^1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843#33