Ben Crowder

Blog: #web

29 posts :: tag feed :: about the blog :: archive

Links #4


Reply via email or via office hours

I’m going to try batching links into groups of five from now on, since solitary links often feel a little too insubstantial for a post. Links often won’t be related.

Links #1:


Reply via email or via office hours

While not all of these are actually one-liners, Una Kravets’s Ten modern layouts in one line of CSS has some neat tricks I hadn’t seen before. (I’m realizing I really need to brush up on modern CSS. It’s been a few years and lots of things have changed in that time.)


Reply via email or via office hours

I recently came across Maggie Appleton’s article on digital gardens. Oh my goodness, this is delightful. I’m sure some small part of it is just nostalgia for the old days of the web, but the idea seems good and solid nonetheless. I love digital gardens. (See Mike Caulfield’s The Garden and the Stream and Swyx’s Digital Garden Terms of Service for more in this vein.)

Exploring some of these gardens led me to the idea of learning in public (also see Gift Egwuenu’s Learning in Public talk). Very closely related to digital gardens, of course, but a different angle to look at it from. It also nicely parallels the working in public idea I posted about recently.

I’m looking forward to adopting more of these practices myself. Not sure yet exactly what form that will take, but at the moment I’m thinking it’ll probably be the notes system I mentioned. While that would be doable with the website engine I have now, it wouldn’t be very ergonomic, so I’m probably going to retool. (And by probably I mean almost certainly, because I am an inveterate toolmaker at heart. I’ve written out plans for a new version of Slash, my blog engine, that will easily support notes as well as blog posts and web pages. More on that soon.)


Reply via email or via office hours

Bubble Pursuit

For my graphics class earlier this year I had to write a small game. Ended up making Bubble Pursuit:

bubble-pursuit.jpg

Super simple game, written in JavaScript using Three.js. I used Tiled for the map. A fun little project.


Reply via email or via office hours

Mozilla just announced their Pyodide project, built with WebAssembly and emscripten:

Pyodide gives you a full, standard Python interpreter that runs entirely in the browser, with full access to the browser’s Web APIs.

WebAssembly has a lot of potential. I’m excited to see where it goes.


Reply via email or via office hours

Just came across Frank Chimero’s essay Everything Easy Is Hard Again, on the rapid state of change on the web, technology-wise. It’s really good. While I don’t completely agree with everything he says, I do think there’s unnecessary complexity that could be pared down a bit.

Also, Kottke’s Blogging Is Most Certainly Not Dead post was a good reminder to blog.


Reply via email or via office hours

I enjoyed Kenneth Ormandy’s essay on efficient web type circa 1556.


Reply via email or via office hours

Unicode Inspector

I’ve lately had the need to find what the code points are for some Unicode text, so I wrote a little web app:

Basically, you type in text and it tells you what the Unicode hex codes are. Pretty simple. There’s a live version on GitHub.

Nerdy notes

  • I’m using punycode.js to do the conversion.
  • I haven’t yet tested it with anything above U+FFFF.
  • Firefox shows the dotted circle for combining marks, but Chrome sadly doesn’t. (Which is why I used Firefox for the screenshot.)
  • At some point I’d like to add more information about the characters — Unicode name, classification, link to chart, etc.

Reply via email or via office hours

Genealogy notebook proof of concept

Ever since seeing the IPython notebook, I’ve been thinking about how its notebook idea would be great for genealogical research. So I put together a (very rough) proof of concept:

Some notes:

  1. A text-based query interface (the queries are in purple) to get information from a database. I don’t know that the best query language would be natural language like this — it’s more just to get the idea across — but the important thing is being able to easily do these types of queries against the genealogical information you’ve stored, enabling all sorts of analysis. “Who in my tree is born more than nine months after their father died?” “Who got married when they were younger than 12 years old?” “Who are all the children who died when they were younger than eight years old?” And so on.
  2. Interleaving queries, their results, and other text (using Markdown, of course). This is the core notebook idea. Or you can look at it as an annotated transcript of a query session. Rather than just having a list of queries and their results, you sort of embed them in between your writing about the research. (Similar to literate programming.) For me, writing things out helps me to see what I think and wrap my head around the research.
  3. There’s a lot of room for data visualization here. I’ve only shown pedigree charts and some basic tables, but it’d be easy enough to have a query return any other type of chart — bar, pie, fan, you name it. Including interactive things like the family analysis tool.
  4. I didn’t include this in the mockup (because I, uh, just barely thought of it), but you could extend the query language to support hypotheticals. “Show me what William Crowder’s family would look like if he and Sarah got married in 1820” or “From now on, pretend Samuel Shinn was born in 1860.” And then following queries would act as if that were true. It’s nice to be able to establish a few suppositions and then see what the ramifications would be, whether they’re plausible, etc. Or to compare two different hypotheses.
  5. Which brings us to the purpose of all this: to have a good place to do the rough, messy side of genealogical research. Thinking through things, seeing what comes of it, and keeping a record of the journey, basically.
  6. Since the information in the database would be subject to change (as you do more research), it would probably be good to cache the results. Or maybe highlight the queries whose results have changed when you reload a notebook. Personally, I lean more towards caching, so that the notebook accurately represents the database at the time it was written (making it a valuable historical record of your research), but you could also look at it as a living document that updates automatically when the background data is updated.

Anyway, the proof of concept is just a static HTML page. I’m not planning to do anything more with it, but I wanted to get the idea out there.


Reply via email or via office hours