drewfish

I was at Yahoo when they did a big email redesign, and the new design didn't work for 1/2 their users. Digging deeper, they found that email users kinda fall into 2 camps: filers and pilers. Filers carefully organize their data so they can quickly navigate to their target. Pilers just collect stuff in a big pile and use search to find their target.

Sounds like you're a filer (I am too). Sounds like emdash is kind of a mix of filing and piling.

Took some effort to refine a websearch: https://stackoverflow.com/questions/2158516/delay-before-o-o...

I don't know about "hero" use cases, but I use actors (state machine responding to events in a queue) quite a bit when making hobby Arduino devices. It allows me to have a "button" device that can work with both the hardware pin interrupt controller and a clock to generate "click" and "hold" events, to pass to other actors in the system. I also will also use an actor to manage an I2C device, so that that actor can detect errors and restart the device to recover from errors. You could do either of those things without actors, but doing so has made it easier for me to compartmentalize my code and organize how data flows and states change.

I think it was their thread/process scheduler. It had a section of priorities which got hard realtime scheduling, then lower priority stuff got more "traditional" scheduling. (Alas, I don't know too much about thread/process scheduling so the details elude me.) That way the playback threads (and also other UI threads such as the window system) got the timeslices they needed.

I'm in the middle of building a 1000sf home with some friends. It'll probably be about 80k for the house (including various permits). We hired contactors for: plans (including engineering calcs), concrete slab finishing (our floor, did the forms & rebar ourselves), trusses (required by code), plumbing, and drywall. I just got back from putting tile in the bathrooms :) We had a retired electrician friend who guided us but did that ourselves, otherwise we probably would have hired one. We're in the countryside so also needed a well and septic system (not part of the 80k).

It's been a tremendous amount of work but is otherwise rather doable. The internet/youtube has been very helpful (like Neo downloading how to kungfu). Another surprise is how helpful the building inspectors have been. They're usually dealing with cranky contractors who want to do the minimum, and we've been very eager for their advice on how to make things last since we'll be living there.

It's been notably more expensive (maybe 15-20%) than we expected, mainly do to the modern building practices and materials which are either required by code or just a good idea.

You'll probably need to research what the particle size(s) is(are) for cigarette smoke, but this detects a bunch of different sizes: https://www.sparkfun.com/products/15103

I have some code to read from this, it's not too hard. PM me if you're interested in my code. (I can open source it.)

Depends on what you mean by "very low consumption". For one project I used a SparkFun SAMD21 Mini Breakout[0], and with the RTCZero[1] library was pretty easily able to get it down to 0.3mA when sleeping and averaging 1.3mA overall. (OK, I had to desolder the power LED which was eating 3mA.) I've since switched over to using Adafruit Feather M0 boards for most stuff, which is basically the same thing.

[0] https://www.sparkfun.com/products/13664 [1] https://www.arduino.cc/en/Reference/RTC

edit: Oh sorry I missed the "with wifi" in your post. One nice thing about the ESP8266 is that lots of people use it -- hopefully that means you can find details on how to run it in low power modes.

Good points, I pretty much agree with everything you said. "NoDamnGoodForUs" is a little strong, more like "AlmostButThisOneUseCaseNeedsALittleMore" :)

Interestingly, that embedded device I made wound up being MVC without explicitly intending so -- the statecharts were the controllers. The only conditional transitions had to do with code reuse, where a single implementation lead to slightly different transitions depending on how it was configured.

In the article the author states:

  From this, we get that accounts should certainly behave like state machines.
  And from that, it’s reasonable that other pieces of code ought to be able to
  dynamically inspect an account’s current state, as well as its complete graph
  of states and transitions. That’s as much a part of its public interface as
  any particular method.

I disagree with this a bit. I think that the state transitions are not part of the public interface -- they're an implementation detail of the SM. The public interface of a SM are its states and the events it responds too. It's up to the SM to decide when to do the transitions. (The _author_ of the SM would be very interested in it's transition graph/conditions of course.)

For example, reviewing a bunch of the javascript SM libraries I see a few have the SM define a "transition table". This works for simple SM but makes it difficult to conditionally transition. Perhaps we want our bank account SM to automatically transition to the "hold" state if the balance goes below zero. With a fixed (i.e. as configuration) transition table we can't do this (or we have to fight against the SM library, or the SM library has to be more complicated).

I guess I'm fairly influenced by this book: https://www.amazon.com/Practical-UML-Statecharts-Event-Drive... I found that approach worked very well when I used it to implement a fairly sophisticated UI on an embedded device. It was easy to rationalize about, easy to read in the code, and easy to maintain (add/move states). Seems like something similar in javascript would be nice, except doing things in a javascript way.

As someone who works at a large company, $10k is in no way "a drop in the bucket". Sales teams might have a budget to wine-and-dine clients, but as a developer I have pretty much zero budget and every expense has to be justified.

This is probably true of any publicly traded company (as mine is) which has a legal obligation to shareholders to be careful that all expenses are worth it.

My understanding is that licensezero is essentially doing what you propose, but also addresses practicalities such as how/where to send payments, tools (for licensees) to aid auditing, flexibility in pricing (and changing the pricing as time goes by).

I see it more in storytelling terms: the existing hell, the seed of hope, the promised land, the hero's path, the hero made real. It's not so much about the consistency of the storyline itself but instead the emotions which develop in the audience as the story is told.

While I think the steps in the article make emotional sense, I didn't think Elon's powerwall presentation was all that well done. For example the "seed of hope" came across more as a "seed of desperation." He didn't really explain why we're now _able_ to make progress, in a way we haven't been able to in the past. (The audience at Elon's presentation also seemed rather irrationally exuberant, excited for some reason other than presentation itself.)

There are a few NPM libraries (make-plural, cldr, probably others) which will help you write those pluralization functions. The CLDR data does get updated from time to time, so it's nice to rely on another package to trace those changes.

Yeah, for a simple plural that can be a bit longer. In other languages, though, the pluralization rules get rather complicated[1]. (For example, Arabic has both complicated pluralization rules -and- a lot of people who speak it.)

The strength of the ICU message format, in my mind, is that the messages can be "nested" so that the translation can be customized for multiple concerns (plural, gender, whatever).

Also, with the integrations (dust, handlebars, react) the details of translation and display of data lives in the message format and/or template. This is the "view layer", and means that your controller/code isn't littered with a bunch of calls to a translation library.

[1] http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/la...

Hmmm... after very quickly looking at Globalize, I'd say there are two things about formatjs.io that I see as main differences:

* Integrations with Handlebars, Dust, and React hopefully make formatjs.io easy to use (since people are already using one of these).

* Focus on the ICU message format, which is fairly simple yet fairly expressive. (Professional translators should hopefully be familiar with this syntax, and it's actually fairly straightforward for us engineers to use.)

One thing that looks interesting (to me) about Globalize is the way the latest/freshest CLDR data is loaded.

You have to provide your own translations.