- If you have a mist humidifier (humidity produced not by evaporating the water but by stirring it up, IE ultrasonic). Use distilled water only, or, get a really great demineralizing filter (it won't be convenient or cheap). Tap water has mineral content, and your mist humidifier happily converts this mineral content into the same sort of particulate matter that irritates your lungs from smoke. Except inside and all night long. Seriously, don't do it. "But it kills bacteria" THAT'S GREAT BUT CAR EXHAUST ALSO DOES NOT CONTAIN LIVE BACTERIA. Using distilled water here is not about protecting the humidifier, it's about protecting your lungs! My PM (particulate matter) sensor in the top floor of our house can tell if a tiny mist humidifier/diffuser is being run on a different floor with tap water.
- If you have a boiling humidifier, this is much better, and, be conservative. All tap water has VOCs (volatile organic compounds) in it (as seen in a city water report, IE my city's is here). When you boil the water, these organic compounds are released into the air. VOCs crowd out the availability of oxygen and can make it more difficult to breath, much like it is difficult to breath in a room that is heavily saturated by CO2.
- Be careful about cooking meats indoors. If you're not ventilating well (because it's cold outside), put it outside. Especially slow-cooked meats. Meats release TONS of VOCs (all that delicious smell!); in the winter, a running crockpot will make matters worse by reducing the frequency of your HVAC system turning on, further reducing air circulation. No exaggeration, one crockpot cooking a corned beef for several hours put our VOC levels in to near-hazardous levels, to the point that several household members were feeling light-headed. The windows were closed because it is winter, and the heater wasn't running because the crockpot was warming the house.
Here's a graph of the data showing the incident (the crockpot running, the point at which breathing difficulties are experienced, our back door opening to ventilate the house, etc. can all be clearly seen in the data):
(click to zoom)
- Be careful about which oils you use when cooking. Pay attention to smoking points. If cooking things in a fry pan, err on the side of lower temperatures (but not too low as to not kill the bacteria!). Even if you run the hood-range over your stove, if your oil is smoking (and you won't be able to see it with your eyes until it gets really bad), then count on your house being full of pollution for several hours or so.
- What looks like a little bit of smoke can be a real hazard if not ventilated well. If you blow out a few candles in a closed, unventilated room, it will raise the PM2.5 levels in the air to the same levels that would be considered hazardous outdoors.
- PM2.5 and smaller particles are hazardous for your health because they are too small for your mainline defenses, since the cilia in lungs cannot deal with them. So, your immune system has to deal with it. And how? Inflammatory reactions. Inflammation in your lungs over an extended period of time will lead to tissue damage. The kind of tissue damage, I think, that leads to statistically increased rates of lung and cardiovascular disease in more polluted areas.
Wednesday, March 20, 2019
Sunday, December 18, 2016
However, after comparing between the 2015 model and this latest one, the CPU performance seems surprisingly bad.
Here are the specs for the two laptops I've tested:
- 2.8 ghz i7 (quad core; burst 4.0 ghz; Haswell)
- 16 GB 1600 MHz DDR3 RAM
- 2.7 ghz i7 (quad core; burst 3.6 ghz; Skylake)
- 16 GB 2133 MHz LPDDR3 RAM
A good portion of my day includes compiling Scala code, a language which, due to it's extensive feature set, can take a little longer to compile. As such I'm inclined to care about how well the hardware I'm using performs this task. In a somewhat informal test, I compiled the Marathon code 4 times, from scratch, each time completely clearing the compile cache (and not re-downloading dependencies). On average, the compile times were as follows:
- MacBook Pro 2015 : 2m18s
- MacBook Pro 2016 : 2m33s
This represents about a 12% reduction in performance from the 2015 to the 2016 model. The base clock speed is 4% slower, and the burst clock speed is 10% slower. The RAM in the 2016 model is significantly faster. So, to see this bit of a hit on performance was a surprise to me. In related news, clock speeds don't mean anything anymore.
On the positive side, the touch ID, touch bar, brighter screen, smaller form, new speakers, etc. are fantastic. It’s a very well designed device and it's a joy to use. When I'm browsing the web or performing other non-CPU-intensive tasks, the newer 2016 MacBook Pro is up to the task and has no noticeable performance issues. But, when measuring CPU intensive tasks, alone, it's strange how poorly it performs compares to it’s predecessor. It makes me wonder if maybe there is a software issue, or the MacBook Pro I received is defective, or, perhaps, they made some compromises to how CPU overclocking is handled because the new form factor introduced additional heat distribution constraints.
At any rate, if you regularly run CPU intensive tasks as a part of your day, then you may wish to pass on the new MacBook Pro, for now.
--- UPDATE ---When I first wrote this post, I was consistently seeing a 27% decrease in speed. However, when I came back to run watch the clock speeds throughout the process, I wasn't able to reproduce those numbers. I've updated the post as such. I'm a little confused as to why it was performing so much worse earlier, but am also relieved.
I ran the Intel Power Gadget to monitor clock-speeds throughout the compile process. It looks like the newer MacBook Pro 2106 runs cooler and use SIGNIFICANTLY less power, which is what you'd expect from the new Skylake processors. Also, it appears to be bursting much less aggressively than the 2015 model, which explains perhaps the larger performance gap.
Sunday, July 19, 2015
- The source element was processed by the sink.
- The element was eliminated by a
mapConcat -> 0, or
- In the case an element was split into multiple sub-elements via
mapConcat, all resulting sub-elements were completed.
- In the case many elements were grouped together via
groupedWithin, etc., the resulting group completed.
- In the case an element is broadcast over
nchannels, then similarly, all resulting copies of the element were handled, and their downstream results.
Error signaling is important, too. If an element fails in any give stage of the stream, then the error should be propagated up through the acknowledgement channel.
My original implementation of this idea was to simply create a stream whose contents were always a tuple of a
Promise and the element. Then, it would be the responsibility of the programmer working with the stream to handle acknowledgements. However, this approach ran counter to the philosophy of "model valid states using the type system"; it was too easy to make a mistake and not fork a promise, collect promises together, or altogether not acknowledge the promise (because it was carelessly filtered from the stream). Also, mixing the concern of acknowledgement with the concern of processing the stream produced some tremendously difficult-to-read code, even with a special helper. An example:
As you can see, it reads awful. And, worse, it's still incredibly error prone.
I wrestled with this: is acknowledgment needed? Without acknowledgement, then there is no hope for retrying messages that failed because of simple chaos. If the process crashes, or the stream is not brought down gracefully, then the messages in-flight are lost. In most cases, this is probably acceptable. But, in others, it's not. I wanted to see if I could do better.
At first, I decided it would be best to create a new class of stream components, based on Akka Streams, called
AckedSink. The justification is as follows:
- The requirement of automatic message acknowledgement necessarily implies a reduced set of out-of-the-box operations at your disposal. For example, it is inherently impossible, from the outside, to correlate messages emitted via
transformoperations with the upstream elements that went into producing that output.
- It would be too easy to accidentally hook an
AckedStreamto a normal Akka Streams
Sink, or a normal Akka Streams
Flow. This would result in leaky acknowledgement. Without a separate class of streams, the compiler would not know to yell at you for making this mistake.
- Modeling message acknowledgement from head-to-tail provides similar watertight properties as does
Future. A Scala
Future, when constructed via a thunk, must complete, or must error. The only way to make a
Futurenot complete is to complete it with another Future that doesn't complete (one that was created via a
Promise), or actually have it run forever (in which case, never completing is the appropriate course of action). Because you cannot run an
AckedFlowuntil it's connected into an
AckedSink, and all stream operations are restricted to those that can guarantee watertight acknowledgement, it is impossible to have an element be processed and not acknowledged (or, "nacked" due to an error). Of course, this is operating on the assumption that
AckedSinkdo their job correctly.
Here is the above code modified to use
All of the original functionality was retained, and the code is much simpler, easier to read. Naturally, the complexity is pushed elsewhere (to AckedStream), but that's just good separation of concerns.
FanOut / FanIn Graphs
AckedSink are a good start; but how do we handle the more complex
n-1 element routing scenarios provided by Akka Streams FlowGraph? There is a lot of rich functionality here, allowing composable disconnected stream fragments to be assembled into a closed graph.
Again, I considered, "do we press this pattern onward? Or, do we opt for generic types? Are we pressing it too far and creating too much complexity?" I was divided: proceeding seemed risky, and I could end up with significant lost time and, afterward, a terrible mess of complexity worse the original problem. I convinced myself it was worth it for the following reasons:
- The provided Akka Stream Broadcast component is incompatible with message acknowledgement; combining an AckedSource with this component would be an error.
- Combining an
AckedSourceto an Akka
Sinkis also an error.
- In an Akka FlowGraph, when you combine a
Flow, you get a FlowGraph.Implicits
FlowOpsand provides stream manipulation operations that are incompatible with an acknowledged Flow; using them is error-prone.
Continuing to use the delegator pattern, I've created an implementation of
AckedFlowGraph that supports a subset of the features. Here's some code using it:
As of this writing, the
AckedStream is contained within the
akka-stream integration, and can be found here, with examples found in the tests. The code is general enough that I will likely end up extracting it into its own library, although I presently have no need for it outside of the context of using
Some of this code may make some generalists frown. I consistently fought, along the way, a feeling inside that I was creating too many types. However, because of the aforementioned reasons, I feel the complexity is warranted because, fundamentally, acknowledged streams are different from non-acknowledged streams: their operations have different behavior, their supported operation lists don't overlap completely, and haphazardly intermixing acknowledged streams and non-acknowledged streams will cause issues.
Wednesday, May 29, 2013
- Seems to be an okay argument. If the soil is heavily contaminated with pesticides, only GMO seeds will survive the soil conditions, and farmers will be forced to switch to a new plot of land (or find a way to remove the soil contaminant). Glyphosate, an enzyme inhibitor, breaks down in the environment and has a half-life of 3 to 130 days; 75%-99.99% will be removed in just over a years time, 97%-99.99999999% (or so) in about two years.
- Okay argument, but see #1 re: half-life of glyphosate. (if this were entirely true, I don't think I would need to spray for weeds every year).
- True... _BUT_: Mono-cropping has been used in traditional agricultural for hundreds of years. That doesn't make it a good practice, it just doesn't make it exclusively true for GMO agriculture.
- Weak. As I understand it, Monsanto is not using this technology (currently? or are they?). However, if they did, terminator seed makes a genetic sequence inherently unfit. Nature will select against it. So the effects wouldn't last and it certainly won't wipe a species of crop off the planet (although, admittedly, this position is not specifically taken by Rawforbeaty's grim-reaper-backed info-graphic).
- Weak / misguided. Again this is an entirely different problem and is not unique to GMO crops.
In a time, long long ago (long before Monsanto came around and destroyed all the planet), some human cell screwed up while copying DNA and changed a genetic sequence. The so-affected sequence contained the blueprint for producing a rather-necessary digestive enzyme; for short, we'll call it "very long-chain acyl-CoA dehydrogenase". Lucky for the offspring, he happened to receive two copies of this blue-print (redundancy is king!), so his body was still able to make the functioning enzyme. He lived a happy, normal life, and passed the faulty recessive trait on to his offspring. After a while, the recessive trait made its rounds until it started happening that both parents contained the recessive trait. For some reason, said parent's children would die shortly after birth with a 1/4 chance. Clueless as to what caused the death, 3/4 children would turn out fine and continue to propagate the gene.
Fast-forward to the near present. Meet my nephew: born into this world to WONDERFUL parents that both happen to carry the recessive genetic trait. My nephew is awesome! I love this little guy. He got two copies of the recessive trait and has a genetic disease known as VLCAD.
Thanks to advances in scientific medicine, medical screening promptly detected the disease and medical intervention saved his life. Thanks to understanding of the condition, he will live a healthy life! This is so awesome, because, like I said, my little nephew is a REALLY COOL KID. Thanks to advances in scientific medicine, we can all be screened for this recessive trait and know the chances of our children being born with a genetic disease. This is REALLY COOL!
 Certain situations only. (that's called honesty!)
Saturday, October 27, 2012
For some time friends of mine have recommended to me the Anki flash card system; Anki is an implementation of the Spaced Repetition Learning System: a system of learning based on common-sense principles such as showing at greater frequency cards with which the learner struggles, and less frequently those that have been mastered.
Using this system, it seems that my daughter gets a well-balanced mix of words she's already mastered, words she's learning, and brand new words, and in the end that seems to help keep her in the optimal state of flow while learning ! This is corroborated by her being excited to do the flash cards each evening.
After using this system 15 minutes a day, in just ONE WEEK my daughter has mastered all 100 of the sight words her teacher had assigned! I am so proud of her!
If you'd like to learn more about the Anki system:
It runs on all the OS's and devices, including iOS, Mac OS, Android, and the web. (the developer seems to fund his efforts through iOS sales, as that is the only platform for which he charges, and notably, a charge I was happy to pay.)
-  - Flow is the"... mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity" [Wikipedia]. One of the requirements to reach "flow" is an optimal balance between challenge and ability.