Love the idea and execution. The spinning record was fun and gave me something to watch while racking my brain. Have you considered adding an “I have no idea” button? I ended up just typing random movies, but having the UI guide the user in some way when they honestly can’t think of a likely movie would be thoughtful.
Totally agree with this, it would be really nice to be able to request clues without submitting an invalid guess. It could still count towards one of your four guesses but I think from a UX perspective it's nicer to be able to admit ignorance than being forced to guess incorrectly.
For instances of this that the system knows about, you could add a response that says, “technically correct but not what I’m looking for.” Similar to how one would do it in real life.
Eh, it’s not usable as an inbox. It doesn’t exist on iOS. It still groups by channel, and if you read anything or click into something then you lose it (dealbreaker for me).
Whereas with my email inbox (which works the same on desktop or phone), I can read the messages without losing them. I can read all the new messages, work on the ones that are most important and earliest, and only when I’ve dealt with them do I archive them and remove them from the list. That way I can always look at my inbox to see what needs to be done (not what I’ve yet to read).
> In 2017, we launched AWS DeepLens to make AI & ML more accessible to developers of all skill levels. With your help, our portfolio of products and services has grown to include new tools for developers to get hands on with AI & ML - including AWS DeepRacer, Amazon SageMaker Studio Lab, Amazon Rekognition, AWS Panorama, and more. Today, we are letting you know that we are retiring AWS DeepLens.
> What this means for you:
> Starting January 31, 2024, you will no longer be able to access AWS DeepLens through the AWS management console, manage DeepLens devices, or access any projects you have created. Until then, you can continue to work on projects and export those you would like to keep by using the step-by-step guide in the AWS DeepLens FAQ. We encourage you to recycle your AWS DeepLens device through the Amazon Recycling Program– Amazon will cover the costs associated with shipping and recycling.
If the layoffs affecting much of Amazon's device division is any indication of broader trends then I wonder if we will soon be under a tsunami of bricked devices as the cloud counterparts are retired. The detritus from software shutting down has historically had minimal impact in the real world. Doing the same with millions of IoT devices seems like such a waste.
The assumption you're looking for is there but relatively inconspicuous. He mentioned a M/M/1/∞ queue but then didn't go into the details about the M/M/1 part. From the Wikipedia page[0]:
> an M/M/1 queue represents the queue length in a system having a single server, where arrivals are determined by a Poisson process...
So the arrival times are not arriving at any fixed rate, but according to a Poisson distribution. In the article he did reference this fact right before the first plot:
> (For the wonks: I used a Poisson arrival process and exponentially distributed processing times)
And then finally, he answered this question more directly in the comments to the article:
> What’s to prevent the system from bouncing between “1 task in processor & 1 task in queue” and “1 task in processor & 2 tasks in queue” while maintaining 100% utilization?
> Nothing! That could totally happen in a queueing system. However, the arrival process would need to be tuned quite precisely to the processing rate. You would need to watch the status of the processor and, when a task finishes, only then insert a new task into the queue. But this implies a shell game: if you always have a task ready to put into the queue when it needs to be padded back out, then isn’t that task in a sense already “queued”?
> Instead, in queueing theory we usually assume a random arrival process: sometimes a minute may pass between arrivals into the queue; sometimes only a second. So the system can’t bounce for arbitrarily long between 1-in-queue and 2-in-queue states. Eventually, one of two things will randomly occur:
> 1. From the 1-in-queue state, the active task finishes processing before a new task arrives, bringing queue size to 0.
> 2. From the 2-in-queue state, a new task arrives in the queue before the active task finishes, causing the queue size to grow to 3.
Of course I know what was missing. My comment was more about making the implicit more explicit. I am not the only one who immediately thought of the above as a counter-example to the bold text (repeated twice) in the article.
> What’s to prevent the system from bouncing between “1 task in processor & 1 task in queue” and “1 task in processor & 2 tasks in queue” while maintaining 100% utilization?
> Nothing! That could totally happen in a queueing system. However, the arrival process would need to be tuned quite precisely to the processing rate. You would need to watch the status of the processor and, when a task finishes, only then insert a new task into the queue. But this implies a shell game: if you always have a task ready to put into the queue when it needs to be padded back out, then isn’t that task in a sense already “queued”?
> Instead, in queueing theory we usually assume a random arrival process: sometimes a minute may pass between arrivals into the queue; sometimes only a second. So the system can’t bounce for arbitrarily long between 1-in-queue and 2-in-queue states. Eventually, one of two things will randomly occur:
> 1. From the 1-in-queue state, the active task finishes processing before a new task arrives, bringing queue size to 0.
> 2. From the 2-in-queue state, a new task arrives in the queue before the active task finishes, causing the queue size to grow to 3.
Very fun. I like the timer and move limit to add a bit more pressure, but agree with other commenters that it may not always be desirable. My suggestion is to have different modes. A practice mode to learn the mechanics, a “strategic” mode where you can turn off the timer and/or move limit, and a competitive mode when you’re ready to tackle the day’s puzzle.
