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.
Thanks! I never use arrows in insert mode so that's an easy choice for me, but removing 'nocompatible' from my vimrc does nothing and setting 'compatible' instead has side effects like not showing what mode I'm in. Not sure I need it, but I'm also wondering what other side effects I'll run into. The help file mentions a ton of things that I frankly don't care enough to comb through. The only thing I randomly spotted (and knew what it meant without digging deeper) is that this also breaks backspace in insert mode. Overall it makes vim feel quite a lot like vi.
Instead, setting nocompatible and timeoutlen=1 (1ms I guess? Help file doesn't say) works fine in my terminal, I guess because it's not over any sort of network connection. I'll give this a go and see if I run into any issues when using these escape-based features (afaik I use those only rarely) over the network.
Woah, I just looked at the Vim help page for 'timeoutlen' and the fact that it's in milliseconds is only mentioned below, under 'ttimeoutlen'. The Neovim help page specifies that it's in milliseconds.
I think that the Stack Overflow answer was just saying that the default depends on 'compatible'; not that the recommended solution is to go back to 'compatible'.
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.
Isnt giving near real time priority scheduling to audio/video how Windows handles things those days? I think I read that somewhere last week under Linux kernel scheduler behaviour response discussion.
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.
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.
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.
Conditional transitions, before- and after- actions, state entry conditions/validations, ... There are all sorts of places to go that have been proven fertile for developing robust software.
But you know... In one essay (two if you count its predecessor)... You have to draw the line somewhere. The goal is not to present a unified theory of modelling domain objects with state, nor is it to introduce some code that should be copied and pasted into a production pull request.
The simple goal is to provoke a conversation.
And if the outcome of that conversation for some people is, "We need conditional transitions, so the exact thing articulated in the essay is NoDamnGoodForUs," then I am actually quite satisfied that I've done my job as a blogger.
And if I can address your specific point--which I hope you understand that I agree with, even if it disagrees with that one paragraph--there are multiple approaches, and I think that if we really were modelling bank accounts as domain object with .deposit or .withdraw methods, we could do just as you suggest and bake a conditional transition to a Held state.
But we could also ask if the bank account is responsible for making that decision? In some architectures, we might say that this is burdening it with too much responsibility. I actually mulled this over with the following use case, which I decided to cut from the essay:
Consider a "suspicious deposit," or maybe a "suspicious transaction pattern," like a series of deposits and immediate withdrawals. PayPal is notorious for freezing accounts that violate some set of hidden rules.
Should the .deposit and .withdraw methods know about this and sometimes transition to "held?" One could argue this is not the account's responsibility, especially if some aspects of what makes a transaction suspicious involve things outside of the balance, like how long the customer has been with the institution.
Of course, there could be a line of code that calls a "Transaction Evaluator" thingummy from within the .deposit and .withdraw methods, or even a .validate method that always checks for this kind of thing after any action.
Or... Maybe this is a lot more like an MVC architecture, and the responsibility for checking the transaction falls to the controller, not the account model. So the controller calls .deposit or .withdraw, and the controller checks for suspicious transactions (or for negative balances), and the controller calls .placeHold on the account if necessary (and possibly on ALL accounts for the customer).
I'm not suggesting that this is superior to your suggestion, but it was something I thought about, and in some application architectures, I think what I just described is the way to do it. In others, what you described is the way to do it.
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.
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).
>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.
My idea was mostly meant for stuff in the category of Nginx, OpenLDAP, Postgres, Mongo, Elm, and co -- stuff that's used as the backbone of projects or services.
So, not just what some random developer in a big company might ask for their personal use. So, not something that some developer would need to justify for their use, but something that has to be accounted for when planning for a new project ("We'll make it in the Foo framework, which costs $10K/year for a company of our size").
If that was adopted, in the end, it would be a budget item like anything else. If they can pay $$$ to IBM and Oracle, not to mention the untold millions made by widget makers, chart libs, and the like, then they can pay a measly 10K to a project they rely on.
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.)
Sounds like you're a filer (I am too). Sounds like emdash is kind of a mix of filing and piling.