I do pot-in-pot with 1:1 ratio of water to brown rice. We have a number of small stainless steel bowls that we set on top of the wire trivet (don't forget a small amount of water in the main pot too). I cook for ~15 minutes for most brown rice and then let the instant pot sit undisturbed for another 10-15 minutes while the pressure naturally releases, and the rice has a chance to take up any unabsorbed water.
White rice is the same deal, though I usually go a few minutes less (~12 minutes). I like to add a very small amount of some sort of oil to the inner pot with the rice.
1-to-1 ratio of dry rice to water, by volume. I typically make 3-4 cups (dry) at one time.
Multigrain setting on the Instant Pot, shortest cook time. I believe it is 20 minutes at full pressure. I do not know if the multigrain setting is on every Instant Pot.
20-30 minutes of natural steam release once the pressure cooking is complete.
Turns out soft and minimally sticky every time. Perfect for my palate. I was eating it with just butter and soy sauce for a while.
That's a great point. I definitely agree that erring on the side of modules is better. I just worry about times when the purpose of a module is not clearly defined at the outset (e.g. when it only contains one function that is only used in one other module). I have often seen that devolve into the "helper" module, where random functions collect.
I'm also not sure I buy the assertion that all code you would want to test is code you would want to export publicly. Do you have any reasoning to support that idea?
> I'm also not sure I buy the assertion that all code you would want to test is code you would want to export publicly. Do you have any reasoning to support that idea?
All code you would want to test (or, even, to have exist) is either code that is in publicly exported functions or code whose pathways can all be exercised via interaction with the publicly exported interfaces, since code pathways that are neither in publicly exported functions nor reachable through publicly exported functions is dead code.
If its not testable via the public interface, it shouldn't exist.
What if a public function is very complicated—too complicated to be considered a unit—and it calls several simpler private functions? Those helpers should be tested with their own unit tests, but shouldn't be exported.
It's not just about coverage in terms of code execution; you also want the right test “resolution”, so you can quickly find the level of abstraction where a bug is, and so you can prove correctness of the parts of a complicated function as you build it.
The other side of this, though, is that you're now coupling your tests to the implementation of your solution and not the interface you want to present. You can't simply refactor your code to improve it; you will also have to find the failing tests, remove them, and write new ones for your new private functions, all while the public behavior of your system has remained working perfectly.
That's my primary reason for not testing private functions.
My alternative is simple, and has been stated elsewhere in the thread; if a function rises to the level of complexity of really needing its own tests, then it probably should be exposed as a public function somewhere in my system. Otherwise, I haven't factored the problem properly yet.
Exactly...coupling is more detrimental than one would think. As your codebase gets larger and more developers on-board and features change, what should have been a simple refactor can turn into a nightmare as your test suite starts to give false negatives because you've changed the implementation or removed a now unused private function that your tests relied upon directly. Writing unit tests directly against private functions is a good way to ensure your team's velocity doesn't scale as well as it should.
Unit tests will serve you better when written to assert results rather than implementation details.
I think I just mean that a testable unit is a good heuristic for when a piece of code should be pulled out into a separate module. Put another way: when there's enough functionality/complexity in a given function that it needs to be tested independent of the public methods that use it, it's modularizable.
This probably isn't categorically true, but it's served me pretty well.
Good find! I can't seem to find a comment that indicates what the new limit is though. Experimentally, we were seeing processes dying at around the 1.7GB to 2GB range.
Did you find anything indicating what the expected new limit is?
sagichmal, could you elaborate on "we were able to map a fan-in-on-read stream product to a data model that could be implemented with a specific type of CRDT"? The post (which is awesome btw) glosses over exactly how Roshi is used to solve the problem presented in the first half of the post - or at least it seems that way to me as I am unfamiliar with CRDTs.
The license agreement is (copied and pasted from the download page):
Copyright 1996 by A K Peters, Ltd.
Reproduction of the downloaded version is permitted for any valid
educational purpose of an institution of learning, in which case only
the reasonable costs of reproduction may be charged. Reproduction for
profit or for any commercial purposes is strictly prohibited.
There are actually a ton of companies who are flat in and out of the industry--and I think it's fairly popular for startups to begin that way these days. I'm trying to compile a list right now and will hopefully be publishing that on our site in the near future. If you'd like me to keep you in the loop, let me know.
No, that would get all the CoffeeScripters attention. I believe it is slated though.
I much prefer raw javascript + macros. In my opinion it kind of negates some of point of coffeescript since you can implement the few key syntax improvements.
Yeah, that's a good point, but if you got all the CoffeeScripters' attention and then showed them that CoffeeScript is just one possible improved syntax...
I was speaking to one of the Sweet.js developers about this, and apparently the only obstacle is that Sweet.js doesn't have the ability to make whitespace significant. Other than that, it should be entirely possible.
> Sweet.js doesn't have the ability to make whitespace significant
Feature, not a bug? But yeah, I guess that would be an impediment to implementing CoffeeScript. I'd like to see some of the CoffeeScript syntax implemented but without whitespace dependency (so it would have to be a modified version of the syntax).
