DEV Community: Yuval Greenfield

I made release date db to predict when anime seasons will come out

Yuval Greenfield — Wed, 14 May 2025 05:40:23 +0000

I got the idea from the macrumors buying guide which helps you decide whether or not to buy an iphone or wait for the next generation.

But I couldn't find this data or a visualization like it anywhere for any other products. I wanted to know how this would look for a pixel phone, mario games, gta 6, one punch man seasons, etc. So this is what I came up with:

It's a simple Vue 3, Vue router, page you can see at https://github.com/ubershmekel/release-date-db. The release date data was generated by chat gpt into these yaml files: https://github.com/ubershmekel/release-date-db/blob/main/data/games/mario.yml and I have the build script generate a json file so the landing page knows which yaml files exist and to link to them.

I hope y'all like it. Do let me know if you have feedback, or ideas for what other books/games/movies/devices to track. It's at https://release-date-db.netlify.app/

Python's "batteries included" was a bad idea

Yuval Greenfield — Thu, 20 Feb 2025 07:45:26 +0000

20 years ago I thought Python was a brilliant language for including so many useful libraries in its distribution. This "batteries included" motto was well known and described in the Python about page.

But today it's clear to me that including batteries in a coding language is a deadly flaw. Because of the packaging hurdle and because of library rot. Details follow.

Why include libraries? Why have a larger standard library?

Batteries included implies that you don't need to worry about downloading or depending on external packages to get stuff done. You can just go. Yes, with Python I did many times find myself productive without worrying about downloading packages. No npm install or go get necessary.

Another important benefit of batteries included is that they make libraries more likely to be interoperable. Packages want to support standard library usage patterns and types. It's better if there's an official set and Promise so there isn't an ecosystem battle over such things.

The rotting flaw

The problem with including libraries in Python is that the language itself has to evolve carefully and slowly. But what happens when inevitably there's a new way to do something? A new and better library is created - and now the batteries you included are suboptimal this year, and a decade later your batteries are actual trash you lug around.

Backwards compatibility is critical. I don't want to fix my code once a year when the new Python version rolls out. Moving from Python 2 to 3 sucked for everyone. Even the main language designer Guido was still talking about the painful transition 10 years later.

So you can't just rip out a standard library and replace it with a new one. If you include a library in your core language distribution - you're either married to it for FOREVER, or you've come to terms with eventually causing your users great pain in updates of old code they don't remember they wrote.

Rotting examples

Python's standard library has 3 option parsing libraries: getopt, optparse, and argparse. I personally voted to include argparse because at the time I thought that was a good idea.

Python includes the urllib.request module though most folks nowadays prefer the requests library for making HTTP requests.

There are a few xml parsing libraries in the standard library I'm aware of (xml.dom.minidom, xml.sax, xml.parsers.expat, etree) but folks today often go for BeautifulSoup.

I'm sure there are many more examples.

The packaging hurdle

Aside from the eventual rot of libraries - coders that rely on included batteries are incentivized to avoid the packaging system entirely if they can. That's the whole value you get out of the batteries, right? So your helloworld app does not include a "get packages" step. But then that results in fewer developers engaging with the packaging system.

But packaging is really where every piece of software ends up. By incentivizing devs to avoid it, by causing devs to want to use the batteries, we are getting a less battle-tested, and lower quality packaging system.

Counter-argument - the JS package explosion

Almost every package you npm install today will cause thousands of files and dependencies to show up in your node_modules folder. If Python's standard library didn't have a math module then every complicated enough package would end up having to depend on all of the popular math packages transitively because each dependency might use a different one. I'm not sure how to incentivize library creators to reduce this problem.

The confusing state of Python packaging

What happens when I import abc? I honestly don't know. The package abc might be a local file (py or pyc) or folder in my $PATH, next to my script, pip-installed, or already somehow in memory.

What is import abc.xyz? Is xyz a function in the package? A sub-folder?

This isn't just confusing for the user, it's also confusing for the library builders setting up their package for distribution, and for package system authors.

Setting up a package for distribution in Python, and downloading packages is terribly complicated. I love NodeJS's npm even though it has its own flaws and competitors. Everyone agrees to use package.json and node_modules as the "virtual env". npm covers all the ground of installing code and binary dependencies on all platforms and generally just works. But with Python, pip is only one step in a longer process - you probably need a virtualenv, uv, poetry, conda, chocolatey, apt-get, winget, or something else to avoid version conflicts with other Python scripts on your system, and to install binary packages.

Part of why this packaging story is so confusing is because Python does not include it in its "helloworld". If Python did show everyone the packaging story - then it would get fixed.

Summary

A language's standard library should really just provide the bare minimum it can. The bare minimum is probably:

A packaging system
Operating system APIs
Types (numbers, strings, arrays, promises, etc)

A core language distribution should only contain what's necessary to install packages, and for packages to be compatible with each other. Leave all the rest to downloadable packages. I hope Python 4 standardizes the packaging circus on a common data structure like package.json did for NodeJS, and that most of today's standard library packages will be removed from the executable distribution and posted on PyPI.

Cheers.

A Python script to see my most watched YouTube videos

Yuval Greenfield — Fri, 22 Sep 2023 21:33:12 +0000

I use YouTube Music and I was wondering which songs I've listened to the most. You can't find that information in the YouTube Music app. But luckily, Google keeps a complete history at Google Takeout. So I can get the list of my most played songs. Here are the steps to do that.

1. Download YouTube Music takeout data

Go to https://takeout.google.com/settings/takeout and deselect all takeouts.

2. Select YouTube and configure the export

3. Deselect all YouTube content options

4. Select just "history" content option

5. Export JSON, not HTML

6. Create the export

After this step, you will be emailed a link with a zip file that has your history.

7. Unzip the file

If you're on a Mac, that's just double-clicking the zip file.

8. Place the Python code next to watch-history.json

In the new folder that was unzipped, you'll find watch-history.json inside a few folders. In my case the path was Downloads/YouTube and YouTube Music/history/watch-history.json so I developed the script at Downloads/YouTube and YouTube Music/history/top_yt.py

Python code

Paste the following into top_yt.py:

import json
from collections import Counter
from pprint import pprint

watched = Counter()
for item in json.load(open('watch-history.json')):
    if "titleUrl" not in item:
        # Watched a video that has been removed
        continue
    title = item["title"]
    url = item["titleUrl"]
    key = f"{title} @> {url}"
    watched[key] += 1

pprint(watched.most_common(20))

Running the code, seeing the result

$ python3 top_yt.py
[('Watched Here Comes The Sun (Remastered 2009) @> '
  'https://www.youtube.com/watch?v=xUNqsfFUwhY',
  334),
 ('Watched Guess Who Is Back @> https://www.youtube.com/watch?v=OZrh6U4CyCw',
  65),
 ('Watched The Rumbling (TV Size) @> '
  'https://www.youtube.com/watch?v=KHCIO7a3jSI',
  61),
 ('Watched ətˈæk 0N tάɪtn @> https://www.youtube.com/watch?v=zroFzv7sFis', 61),
 ('Watched Omokage (produced by Vaundy) @> '
  'https://www.youtube.com/watch?v=jg-uSq64Ru8',
  48),
...

For me, the top result wasn't a song I liked too much, but it was my alarm clock for almost a year. Of these songs, I recommend you check out this one: Omokage by milet, Aimer, Lilas Ikuta, Vaundy

I hope you find this script useful. Cheers.

Terraform vs Pulumi

Yuval Greenfield — Mon, 24 Jul 2023 15:47:24 +0000

On the face of it Terraform and Pulumi are the same thing. They let you write code that defines your cloud setup. When you modify that code - they will update your cloud setup accordingly.

Terraform vs Pulumi on Github

https://star-history.com/#pulumi/pulumi&hashicorp/terraform&Date

(for some reason this image is looking broken when I embed it)

https://github.com/pulumi/pulumi - Infrastructure as Code in any programming language. Build infrastructure intuitively on any cloud using familiar languages
https://github.com/hashicorp/terraform - Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.

The subtle lock-in difference

Pulumi allows you to write the code in your programming language of choice, which is going to be far more expressive. Terraform requires you use a simplistic configuration language.

A consequence of this difference is that it's easy to migrate from Terraform configuration files to Pulumi. But it's going to be extremely difficult to migrate from Pulumi to anything else.

Caveats and conclusions

I personally only used Terraform and it was a bit tricky to learn at the time. Pulumi's idea of using a more capable language to manage infrastructure intrigues me. It seems the idea is so powerful that it might be worth it to take the risk of never being able to migrate off of it. I'll post an update after I try it. Please let me know of lessons you already have from real life experiences with these two.

Github page, which version are you anyway?

Yuval Greenfield — Mon, 06 Sep 2021 21:13:06 +0000

I was working on my game and couldn't figure out which version was deployed to github pages. So I added this to my github deploy action:

- name: save version.json file
  run: >
    echo '{ "hash": "'$(git rev-parse HEAD)'" }' > dist/version.json

And now I can see the git hash of the live version at https://ubershmekel.github.io/nihongo-shooter/version.json

I could probably also include more information like a label and show it in the game. But this is good enough for my needs. I'll probably include that line in all my github page deploys. Note you may or may not need to store the version.json in a dist folder. Cheers.

I built a game with Vite

Yuval Greenfield — Thu, 29 Apr 2021 01:25:44 +0000

As part of Ludum Dare, a competition for making a game in 48 hours, I like experimenting with new tech. It's always painful to experiment while under time pressure, but it's also a great opportunity to time constrain a learning experience.

Last year I tried to use Rollup, Phaser, and TypeScript based on an existing template. When I tried to npm install an audio library (Howler) - it broke in such a way that I needed to debug a convoluted asset build configuration. I couldn't figure out how to fix it. In the end I decided to ditch the build system entirely and go pure JavaScript.

This year I tried out Vite, Phaser, and TypeScript. I was able to throw in different odd libraries and it all just worked. There were just 2 issues which were straightforward to debug:

The inlining of assets into URL encoding that Vite does was incompatible with Phaser. Luckily the relevant Vite docs popped up when I searched for the issue. After a small config change of assetsInlineLimit to zero, I was on my way.
GitHub pages are hosted in a subfolder, so I had to add base: './', to the vite.config.js as well. Perhaps this should be the default setting.

The game is pretty simple, you can play "Where is Bob" if you like. I also made a vite-phaser-typescript template if you'd like to start such a project from scratch. The main goal of this post if to just say thank you to @yyx990803 and the Vite team for such a smooth build system that mostly just worked.