#backend

Answer: Hello @circumference-pie!

Buckle up y’all, it’s story time again!

First: nobody who works at Tumblr right now was a part of the work of planning the default queue implementation, which was more than ten years ago. So the full story behind “Why does it work that way?” has unfortunately been lost to the sands of time. All we can do is tell you how it works today and surmise some reasons why. The queue is actually a very clever system and part of how it works explains some of why it works the way it does. Also, there have been attempts to do what you ask—we still have “Queue 2.0” available in your Tumblr Labs settings, which tries to get closer to how you expect things to work.

Anyway! How the queue works today is not actually a queue in the traditional sense. There is no single list of posts that are in “your queue”. Instead, when you “Add to queue” after creating a post, we’re actually scheduling it to post at a future time, as if you had used the “Schedule post” option instead. We’re just calculating that time on your behalf when you use “Add to queue”, based on your settings, and how many other scheduled posts you have already. We use a secondary “index” model, called “ScheduledPost”, to keep track of posts you have scheduled on your blog. We do mark the ones that are a part of “your queue”, but the data model doesn’t keep one list of your “queue” per se.

You can see this in action on your blog, hiding in plain sight. If you add a bunch of posts to your queue, and then schedule a post for a specific future date, you’ll see both in your blog’s “queue” list, side by side. Because technically to us, they’re the same thing: queued posts are really just another kind of scheduled post, relying on the same always-running service to publish scheduled posts across all of Tumblr. Here’s a fun fact: we typically have about ~14.5 million future posts to publish from this list at any given time and are publishing hundreds of these scheduled posts every second.

So when you’re adding a new post to your queue, what we’re doing behind the scenes is starting at the beginning of your “day”, and creating time slots based on your queue settings. If a time slot is already filled, we move on to the next one. That’s why the default queue scheduler works how you describe—we’re trying to fill those “slots” based on the start of the day, rather than trying to divide the calendar day evenly. This just makes it much simpler for us to understand, scale, and predict when our “peaks” will be. At peak times, the publish-scheduled-posts service is publishing tens of thousands of posts in a manner of seconds. We did rewrite that post-publishing part of this architecture a few years ago to improve its efficiency and solve a lot of “lost post” bugs, but we didn’t change how “Add to queue” works.

However, the Queue 2.0 project available in Labs was an attempt to change the queue system to work as you expect—instead of starting at [beginning of day] and creating enough slots to fit [number of slots] every [number of hours], it tries to divide the calendar day into [number of slots] and fit the result back to the original algorithm’s mapping of the day. We never productionized this alternative approach, because it has a few bugs that some blogs hit in extreme cases, and we’ve never had time to fully fix them. It also can cause a bit of weirdness when time zones diverge, like with daylight savings time. Also, a lot of people prefer the default algorithm, and we haven’t thought of a nice way to transition everyone from one to the other. So for now, both options exist, and you can choose which algorithm for queue-slot-generating you want to use. We hope that makes sense! 

While complicated, it is a great example of a system built by engineers to make sense and be scalable and predictable. But sometimes these kinds of systems, while clever, aren’t very intuitive to understand without digging into how they work.

a queue that is sorted by priority,

histogram that counts all the values ​​in each "bucket,"

object-oriented Tic-Tac-Toe, with classes Game, Board, and Players who had to compete against each other until a winner was determined

I was so scraed that i had a whole ass anxiety attack 2 days before but now that i've done it, it was alright. I was allowed to google things and i chose Java as my language as it is the one i am most familiar with. We will see about the talk i will have with my instructor but let's not think about that now.

So I'm fucking around in the network section of Firefox's developer's tools because I'm taking a Django course and I'm looking at the instructor's samples as part of a lecture and I spot this little thing:

and I'm like ????? Sir what are you doing in my browser???

The instructor of this course likes making little references all the time (for example he often uses "42" as a value because of Hitchhiker's), so my first thought was that he is also a Terry Pratchett fan and added him as a value in his sample code, but what is "x-clacks-overhead"?

Well, let me share with you what I found on the X-Clacks-Overhead website:

In Sir Terry's novel "Going Postal", the story explains that the inventor of the Clacks - a man named Robert Dearheart, lost his only son in a suspicious workplace accident, and in order to keep the memory of his son alive, he transmitted his son's name as a special operational signal through the Clacks to forever preserve his memory

[...]

As a way to preserve the memory of Sir Terry Pratchett, the users of the SubReddit for the Discworld series came up with the idea behind the X-Clacks-Overhead HTTP Header. It allows web authors to silently commemorate someone through the use of a non-invasive header that can be transmitted from server to server, or server to client without operational interference.

[...]

At the time of writing, Mozilla.org (makers of the Firefox web browser), the makers of Debian (a popular Linux Operation System), and Xml.com (a major repository of standards information) are examples of some of the backbones of the Internet who transmit the Signal "GNU Terry Pratchett".

It's not that the instructor is making a hidden little reference to Terry Pratchett. It's so much more than that. And I think it's beautiful :')

Okay so the authentication for spotify is hard for me to understand and requires user authentication, then making a token request that while expire in an hour. So i focused on what I did know how to do and what I had access to token wise. The Spotify developer home page has a temporary access token for demos. I took that token and made a function to make get request to the API and two functions for top tracks and top artists. Then made some functions to print them in my terminal. Here is what my end product looked like in the terminal.

The data for tracks is proving to just show a years worth of listening even though I specified long_term in my get request.

Here is my code:

I tried just doing track.artist but Spotify handles that as multiple artists so I had to handle them as such.

Next Steps: Tackling the user authentication and token requests and including it in this code.