davepeck

MineSet, their data mining and visualization package.

I was there near the end. First, as a summer intern in 1998, and then in 1999 as a full time engineer on what is now Google's Mountain View campus. SGI had always been a dream company for me. I'd first learned about them in high school; now, right out of college, I'd somehow managed to land a dream job.

SGI's hardware was cutting-edge and exotic. IRIX was killer (sorry Solaris). Cray was a subdivision. My coworkers used emacs, too. They put an O2 on my desk!

The dream didn't last long. Major layoffs hit just a few months after I started full time. I wrote about the experience here: https://davepeck.org/2009/02/11/the-luckiest-bad-luck/

To me this is a valuable write-up because it (a) clearly describes paper cuts accumulated when building with unfamiliar tech and (b) showcases how much nonsense developers are willing to tolerate in the name of "new" or maybe "speed".

Some of the paper cuts described include:

- Inexplicable interaction between the data layer and a hosting service's environment variable

- Migrations that don't work reliably

- Cron jobs that don't work reliably

- Inexplicable caching behavior for serverless functions, requiring an obtuse workaround

- An auth library that makes it hard to... get the ID of the logged-in user, apparently

I dunno, I suppose I'm happy to stick with boring old tech.

Yeah, I started poking at Vite to see how much work it would take to build an island-architecture-for-preact tool on top of it. It looks doable.

Out of curiosity, when you're building a mostly static site that might want occasional islands of interactivity, what do you reach for instead?

I dig Astro and use it to build my blog and several other tiny mostly-static sites. I'm not sure that the hosted database service fills a need I have but, in general, supported SQL integration seems like a useful addition.

As an aside: there are days when I wish I could avoid using the Astro component model entirely, do everything in Preact (or whatever), and still use the `client:*` directives when appropriate. I realize this is easier said than done and also probably not a reasonable thing for Astro itself to try and target -- but moving between Astro components and framework components always has just enough friction that it's something I think I'd enjoy using.

Hackers love to question the truth but refuse to countenance bullshit.

The downvotes here seem to be catching bullshit quite well!

Fun stuff!

The underlying `swtl` library is itself pretty interesting.

Note the use of `delayed(...)` in the blog's example code: a promise in a tagged template.

SWTL's `html` allows for this (I think the blog's example follows the simple case here https://github.com/thepassle/swtl/blob/main/html.js#L23). And SWTL's `render` method races the promises (https://github.com/thepassle/swtl/blob/main/render.js#L120) outward.

I'd recommend that you start by learning React without Django.

You can make a little tic-tac-toe game that runs in your browser using just React -- no need for Django, provided you don't want to save the state of the game to a database or something.

If I wanted to start today, I'd make sure I had Node 20.x installed, and then run `npm create vite@latest`. I'd name my project `tictac`, then select both `React` and `TypeScript`. I'd follow the instructions I get and visit the running React app in my browser at http://localhost:5173/.

From there, you can edit `src/App.tsx`. Make a tiny change, save it, and your browser will update immediately. I'd probably build my whole tic tac toe game right there in that single file.

TypeScript is optional but it's useful to learn and won't add too much complexity for this particular project (you can mostly ignore it if you like).

Once you have some basic comfort with these tools, the next question will be: okay, how can you make the code you just wrote talk to a Django server? A simple answer might be: have your code call out to the Django server by making a fetch() call. You'll have to figure out where, exactly, fetch() calls belong in React-using code. And you’ll want to have your Django server return some JSON (from a view) that your javascript code does something with. For this to work on your development machine, you'll run both the Vite server and the Django server at the same time. (npm run dev; python manage.py runserver).

A really tiny Django view should do just fine to start -- your goal is just to make sure the data sent by the Django server is received by your javascript code. After that, you can start to get fancy. You do not need Django Rest Framework, Ninja, or any other extension to Django on day one -- plain old Django is quite capable of sending and receiving JSON data. (Someday later, you might consider one of those add-ons, but I'd stick with the basics first.)

See also Nadia Eghbal's (IMHO definitive) work on the economics and sociology of open source software, "Working In Public": https://press.stripe.com/working-in-public

I choose between Django and Litestar these days.

I wish I had a hard and fast rule for the choice, but it's something like:

- Litestar if I know with certainty (a) the thing I'm building is and always will be a tiny service and (b) I probably won't have to evolve the backing data schema much. Wrap an ML model? Litestar. Have a small database I want to expose via API, read-mostly? Litestar.

- Django if I know (a) I'm going to be building on this over a longer timeframe, (b) I have complex user/group auth needs, (c) my data schema will likely go through substantial evolution, or (d) I will need an admin UI in the early goings, either for the managing team or for customer support.

I have plenty of SQLAlchemy+Alembic+Litestar backends but I vastly prefer the creature comforts of Django's ORM + migrations; it hits that 80% sweet spot so very well. SQLalchemy is both raw power and, often, far too much friction.

I used to choose between Django and Flask, but Litestar -- while still young -- seems to capture most of the key things I liked about core Flask but in a more modern package. (Maybe Quart, aka async Flask, will ultimately win the day; not sure.)

It's not targeted at the use case, but I wonder if Datasette will replace my need for the Django admin UI at least in some limited set of cases.

These days, most of my front-ends are React+Typescript+Vite.

(FWIW I personally avoid FastAPI entirely. I appreciate the impact it had getting the python community to think about (a) async (b) proper use of type hints in the web context and (c) the need for OpenAPI support, etc. but there are a lot of footguns and so many issues still opened that its (amazing, lovely) single maintainer probably won't get to. SQLModel -- aka the merging of Pydantic + SQLAlchemy ORM models -- is an even bigger trap, IMO.)

I always think of Tom & Ray's in Damascus, MD as being the most legit Maryland fried chicken I've had. Granted, it's also the only place I'd ever heard the term until today. :-)

(I gather T&R recently changed ownership so I don't really know what its current status is or whether its fried chicken is precisely as legendary as this 90s kid remembers.)

I like Neal.fun's "Internet Artifacts" page on the Morris worm -- it presents the full code in an amusing form. https://neal.fun/internet-artifacts/morris-worm/

This assertion is not supported by the text of Biden’s Executive Order. There are a number of requirements placed on various government agencies to come up with safety evaluation frameworks, to make initial evaluations related to open weight models, and to provide recommendations back to the President within 270 days. But there’s nothing whatsoever that I can find that outlaws open weight models. There’s also little reason to think that “outlaw them” would be amongst the recommendations ultimately provided to the executive.

(I can imagine recommendations that benefit incumbents by, for instance, placing such high burden on government adoption of open weight models that OpenAI is a much more attractive purchase. But that’s not the same as what you’re talking about.)

I dunno, the EO seems pretty easy to read. Am I missing something in the text?

https://www.whitehouse.gov/briefing-room/presidential-action...

Absolutely love my 14” M2 pro and use it daily for coding. Perfect size/weight for the backpack, and endless battery at the local coffee shop.

> The key here is that none of these depend on the language model injecting factual information into its output.

This feels like an under-appreciated insight. There are lots of valuable (and in some cases previously difficult, expensive, or impossible) linguistic manipulations that fall under this lower-risk end of spectrum.

Thanks, that's helpful.

Amazon famously built the company with OBIDOS, a monolith; these days, backend microservices abound — as do what we’re calling here microfrontends, although my understanding is at AMZN they are granular not just to market-specific domains or route prefixes, but sometimes also to pre-defined sections of a final rendered page. Would love to hear from AMZN engineers that work on such things.

"Microfrontends" is a new term for me. Are there specific frameworks that embody the concept (and if so, where on GitHub would I look)? Is it more of a broad architectural pattern?

At least today, my experience is that Pyright is faster, flags more issues, provides better error messages, and (alas for Mypy) has fewer bugs. I hope this will change over time as Mypy matures, but there you have it.

When using Pyright in large Django projects, it's helpful to add explicit type annotations in a number of places (like reverse relations in Models) but I've found this tends to improve the clarity of the resulting code anyway.

Back in the early 2000s, when I was a wee new SDE at Microsoft, there was a shared whiteboard down the hall from my office on which someone had scrawled:

"STRONG TYPING IS SO 90s!"

That missive stayed on the board for over a year. I still think about it from time to time and remember that the tech world's pendulum is always in motion.

Today? I adore TypeScript and I'm pretty excited about the PEP 695 QOL improvements to type annotations in Python 3.12. Where types and tools are concerned, we're in a much better place today than when Nirvana was still the next big thing.

But I won't be surprised at all if in another decade I see "STRONG TYPING IS SO 20s" marked on some corporate whiteboard in Redmond. :-)

Serious practitioners are permitted to have fun and/or use goofy memes.

Thanks for Distill. The approach you took (specialized URL routes and custom management commands) is simple and elegant.

Explosion is an old school machine learning company by the people who built the spaCy natural language library. They’re serious practitioners whose work predates the “hype-train” you’re concerned about.

The blog post might be worth a gander.

Lots of interesting links; thanks!

Here in Seattle, Rover (a $1B+ market cap company) also uses Django extensively. As do lots of interesting local startups.

It’s a good one.

Simon Willison calls it the “baked data pattern” — where a read-only copy of your data is checked into your repo alongside your code. [1]

(And, just to tie the threads together, that’s the same Simon who wrote the OP we’re all commenting on, and who is also the co-creator of Django and more recently of the very handy Datasette!)

[1] https://simonwillison.net/2021/Jul/28/baked-data/

This is great and showcases Django's talent for basic CRUD apps with handy admin interfaces.

One catch: I like to deploy static sites to GitHub Pages. It turns out the Django ecosystem has an answer for that in the form of Django Distill [1]. Distill adds a new management command that generates static content by repeatedly invoking your views.

I've used Distill to build quite a few static sites. It's great to be able to deploy to Pages but use Django's admin UI locally. Typically, for these sites, I check in my 'production' SQLite database directly to my git repo.

(Combine this pattern with GitHub actions and you can do a lot with a little. For instance, here's a toy I built to summarize upcoming Seattle city council meetings [2].)

[1] https://github.com/meeb/django-distill

[2] https://scc.frontseat.org/ -- source at https://github.com/front-seat/engage

This is neat, thanks. I was looking at your HN OPML file on GitHub [0] and noticed that the `xmlURL` and `htmlURL` attributes are the same for each entry; the `htmlURL` currently points to the feed rather than the site. Do you happen to have the original HTML URLs available? Would be nice to have both.

(Secondarily, I'm guessing some of the `type` attributes should probably be "atom" rather than "rss"?)

[0] https://github.com/outcoldman/hackernews-personal-blogs/blob...

See also https://www.typewolf.com -- a long-running and popular curated look at trends in web typography

At this rate, in its first 24 hours Threads will probably accumulate more user accounts than Mastodon has in its 7 year history. (~13.2M at the moment: https://mastodon.social/@mastodonusercount)

https://davepeck.org/ and you can confirm I’m an old by the first post date

My impression is that when fly.io has been discussed in the recent past on HN, the conversation tends to be less about databases and more about Heroku alternatives. (?)

Out of curiosity, how _does_ fly.io see itself in relation to Heroku?