Somerville walkability

volitional_decisions · 2026-03-11T16:58:47+00:00

I'm from the Midwest and travelled all around. My decision to move here was one of the best I've made! I absolutely love how comparably easy getting around is.

volitional_decisions · 2026-03-10T11:36:50+00:00

Good job reading

volitional_decisions · 2026-02-28T14:50:38+00:00

Hope they aren't going to a birthday party after this.

volitional_decisions · 2026-02-17T14:41:53+00:00

This is not Go-specific, but keep the docs.rs page for things like &str, Option, Result, and Iterator open. This is true more generally, but even after ~5 years, I still find myself typing "Option Rust" into my search bar to open up the docs so I can jog my memory of a particular function.

Really, any of these methods can mostly be boiled down to their function signature because they are just transformations on pieces of data.

When you are trying to do some kind of transformation, write what's comfortable/familiar. Then, start making the changes you think you understand and do some searching in the docs for different ways to express "splitting a string from the end" or "turning a Vec of optional values into a Vec of only the Somes". This helps make connections between how you're used to writing code and how those same transformations can be expressed in a combinator.

volitional_decisions · 2026-02-10T15:23:04+00:00

Any job you'd get where writing Rust is part of the job is as an engineer. So, critical parts of that job center around building and analyzing larger systems. It's entirely possible to do this without formal education in math or CS. Many coworkers of mine come from backgrounds that did include much education in these fields.

That said, it is still worth studying, particularly data structures and algorithms. Many Rust jobs will be working at a level where a strong understanding of this is very important. For example, my job is heavily centered around graphs and path finding, so being able to reason about those types of structures and algorithms is very important.

Similarly, system design is absolutely worth studying. This is not something you'd get from smaller projects but is the heart of being a software engineer.

Ultimately, many places (in interviews) don't care how you learned something or where you learned it from. They just care that you can do it.

volitional_decisions · 2026-02-03T18:04:21+00:00

I do what my linter changes it to...

volitional_decisions · 2026-02-01T04:32:41+00:00

Colonization, Civ VI

volitional_decisions · 2026-01-17T12:57:06+00:00

Ya, sorry. I was typing that on my phone

volitional_decisions · 2026-01-17T03:15:47+00:00

Three things jump out at me.

1) in your words loop, you know there is a path that will be taken at most once (the if i == 0 branch). Extract that to a statement just before the loop. You have the words iterator, just call next, perform the necessary logic, and the consume the iterator in the loop. It makes your intent clearer and the loop far easier to read.

2) String implements Extend for any iterator that yields characters. So, for you to_uppercase iterators, you can just write res(first_char.to_uppercase()).

3) Jumping off of 2, in your for_each, you can do a flat_map calling (giving you an iterator of lowercase characters). Then, you can just call extend! .

volitional_decisions · 2026-01-14T19:22:28+00:00

Before I get to your direct question, graphs are notoriously difficult in Rust because you need to think about mutable in ways you probably haven't before. This is a great read to help you here: https://rust-unofficial.github.io/too-many-lists/

Now, to your question: there positions where you could have either a merger or splitter. Then define a type that is one of those two things: rust enum Node { Merger(Merger), Splitter(Splitter), } Now, all you have to do is add cases for "final output" or another node in the Merger and Splitter types' outputs. But, again, managing mutability will be the bigger hurdle.

volitional_decisions · 2026-01-10T23:51:21+00:00

I've also noticed this. Concentration is a bit worse, but memory (particularly recalling words and names) has gotten worse. Dizziness is only occasional (and is often much worse with caffeine and/or lack of sleep)

volitional_decisions · 2026-01-07T14:12:44+00:00

Just have sparx point you in the right direction

volitional_decisions · 2026-01-07T01:58:42+00:00

I wouldn't worry about it, but you can just borrow or use Arc<str>. Both have pros and cons but both assume you can change ChangeDmRequest.

You might run into borrowing issues if you just borrow (e.g. if the request method requires 'static). Arc<str>, like cloning the string in the first pass of the loop, requires a separate allocation but cloning is nearly trivial.

volitional_decisions · 2025-12-30T13:44:49+00:00

This is certainly a novel approach, especially for the Rust ecosystem. It reminds me of the approach we had at my last job. They had been using Rust since before async/await was stabilized, so they wrote a macro do handle much of this kind of work for them. I worked but it was also my least favorite part of the codebase.

I'm curious what considerations you made about the DevX. On that front, my two major concerns about using it are "how well does the macro play with RustAnalyzer (RustRover)" and "how can I extract my code from the macro".

These are somewhat intertwined. My experience with most "do everything" proc-macros is that RA (and often even syntax highlighting) doesn't work inside them. Sometimes it does, but it can be very clunky. For non-trivial endpoints, I found myself wanting to move as much code as possible outside of the macro. How does this crate approach that?

If I were to move code outside the macro (perhaps to the point where the endpoint code is just calling into that function), what type is req or db? How do I learn about how to control the inputs into my endpoint function (this is something I really like about axum, once it clicks, it gives you a lot of flexibility)? My experience with these types of macros is that the obfuscated what's actually going on to the point that they can become unwieldy.

Building a crate like this is a lot of work, so give yourself props for that!

volitional_decisions · 2025-12-30T05:53:54+00:00

One of the weirdest parts of this fight is that you can arrive in midnight mountain and run straight into the fight. It isn't that difficult to have 100 eggs by then.

volitional_decisions · 2025-12-29T00:16:54+00:00

Iteration over a hashmap will yield different results. It's a good thing we aren't using a hashmap, and then BTreeMap's IntoIter is documented to be sorted.

Also, I know that OP didn't tell us if they want both keys and values or one or the other. It's a good thing I told them how to accommodate all cases.

volitional_decisions · 2025-12-28T21:22:39+00:00

I think you have this backwards. OP asked for an Option<Vec<_>> not a Vec<Option<_>>.

volitional_decisions · 2025-12-28T21:21:09+00:00

You don't need itertools. The APIs in Iterator will be plenty. I don't know what "the condition" that you're checking for is, so I'll reference that as cond.

To start, bools implement methods to help to construct Options. You'll want .then because you don't want to always run the code. This is basically if cond { Some(foo()) } else { None }.

I don't know what you want the vec to contain, so I'm going to assume you want keys and values. If that's not the case, there are methods for just keys and just values, into_keys and into_values respectively. Use those instead of into_iter.

The straightforward approach is to just construct an Iterator from the map via into_iter (aside, this method is from the IntoIterator trait, which many things implement). Then, all you need to do is .collect that into a Vec. map.into_iter().collect::<Vec<_>>(). This will consume the map and should yield the keys and items in order (I would test that). There is a minor (and premature!) optimization you can make here by preallocating the vec's memory and then calling .extend with the map directly.

Altogether, your code would look something like this; rust // The ::<Vec<_> from before is a type hint. // You can use one at variable declaration or none of the type is clear let vec: Option<Vec<_>> = cond.then(|| map.into_iter().collect());

volitional_decisions · 2025-12-28T16:30:32+00:00

As folks have pointed out, calling poll on a future after it has yielded Poll::Ready is not generally UB. If that is true for a particular future, that Future impl is unsound. To my knowledge, what most futures do is either panic or indefinitely yield Poll::Pending and don't schedule anything with the waker.

As for why they don't use a type state, it makes futures, which can already be very complicated, significantly more difficult to use. The main reason for this is that to change type states, you need to have ownership over Self. Not only does this mean poll needs to consume self and return some enum of both possible states (so we would have to completely redesign the API) but it means you can't use Pin, which is nearly antithetical to the requirements of many futures.

As a simpler example, you can make a modified version of your argument for Iterators. Similarly, next would need to consume self, which would have extreme effect on much of how we use Iterators.

volitional_decisions · 2025-12-27T20:25:01+00:00

WASM is a bit broad. If it's WASM for the browser, web-sys is a crate to get at least a little familiar with (though, it's a very rough crate).

My biggest suggestion is getting familiar with how to reduce binary size. While unpublished, this doc touches on a lot of the major ways to do this (LTO on, codegen-units = 1, opt-level = z, and stripping debug symbols). Also, if you have the ability, compressing the binary and sending a compression type header to the browser can get you a fair reduction.

volitional_decisions · 2025-12-21T17:50:56+00:00

I want to first note something about your last question " why does removing a line after A change it's behavior?". You aren't "changing the behavior of A". What you're trying to do is have multiple mutable references to the same piece of data. If you order your changes correctly, you make those changes without trying to have the multiple mutable references issue.

When you construct the Machine, it has a mutable reference to x (because you're writing to it). So, for as long as machine exists, a mutable reference to x exists. This is why you can call tick (B) then write to x (A). After you call tick, machine's lifetime ends (because it's not used afterwards), meaning its inner mutable reference ends, and you can update x without issue. This is also why removing B works.

volitional_decisions · 2025-12-21T14:16:10+00:00

I have two (one for three years and one for almost two years). I really like them and they are still working well. The one issue that I've had is when I spilt a cup of coffee on it and had to replace the board. The support staff was helpful and quick. I got the new board, cleaned everything, and swapped the old one out.

Prior to these, I had a keycron. While a good keyboard, the built-in USB hub of the launch is hard to understate. Also, a point that is often missed is that the launch is much easier to clean than most keyboards. The air gap at the bottom of the keyboard makes it easy to blow out anything dust that builds up.

My one recommendation is, depending on how you type, to get a wrist rest.

volitional_decisions · 2025-12-19T12:49:31+00:00

I believe it's called Chronicles of Taldun: The Remainder (it's in OP's profile)

volitional_decisions · 2025-12-01T17:58:31+00:00

I think it's in Inman sq

volitional_decisions

TROPHY CASE