drewfish · HackerTrans

पिछला वर्षdiscuss

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.

drewfish

5 वर्ष पहलेdiscuss

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

drewfish

5 वर्ष पहलेdiscuss

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.

drewfish

7 वर्ष पहलेdiscuss

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.

drewfish

7 वर्ष पहलेdiscuss

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.

drewfish

7 वर्ष पहलेdiscuss

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.)

drewfish

7 वर्ष पहलेdiscuss

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.

drewfish

8 वर्ष पहलेdiscuss

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.

drewfish

8 वर्ष पहलेdiscuss

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.

drewfish

9 वर्ष पहलेdiscuss

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).

comments