mntmoss

66 ms·

271.
by mntmoss 8y ago
The main downside of using any of the smaller/cheaper devices is in the I/O capabilities, which manifest both in the software and the hardware. With the hardware it's pretty obvious - a lot of Chromebooks are like phones and
272.
by mntmoss 8y ago
Dense code that benefits from dense variables(which describes a lot of "pure algorithms" work) I often approach by aliasing the variables to shorter ones. It's all in the same body so the context is not especially hard to los
273.
by mntmoss 8y ago
The other day I started thinking about the state of transit in the SF area and found a few articles from the past few years that presented a rather different picture from the hyperbolic Uberized/company bus/e-scooter/Hyperlo
274.
by mntmoss 8y ago
A practice I've become interested in but don't have an opportunity to engage with(doing the solo ISV thing) is "mob programming", since it confronts a few axes of the toxic-developer problem: * There is some built-in div
275.
by mntmoss 8y ago
You can treat it as a multiplexing operation. The first y[i] is computed normally. y[i+1], y[i+2] etc. are computed with a parallel form, up to as many cores as is optimal. Normally cores will wait for data, finish it very quickly, and then
276.
by mntmoss 8y ago
What your actions are missing is a closed feedback loop. You have a few reject signals("must have x/y/z feature") but you will benefit from thinking like a game designer and developing more of them to qualify your decisi
277.
by mntmoss 8y ago
On a physical level, unbounded deadlines and unlimited resource constraints don't exist, so I've learned to distrust anything that assumes "it scales forever". It's just a lot simpler to plan a static capacity targe
278.
by mntmoss 8y ago
I would position D on a spectrum between Go and Rust. Go is roughly where you would end up if you trimmed down D to its bare bones: a pretty fast GC language with a native runtime that can do some memory manipulation if needed, where the fo