1,676 karma · joined October 17, 2009
The code will not look pretty but it will be very fast.
The point of view is usually also wrong, they focus on the method call flow while they should think about protecting access to shared data.
1. Avoid abstraction as much as possible, convoluted flow control and reduce useless objects creation
2. Learn how to manage concurrency correctly, focus on the data being accessed by multiple thread and focus on sequential access
3. Don't use bloated frameworks (all of them)
4. Consider rewriting common libraries following the principles above and with only the functionalities you actually need.
Easy 10x improvement, try it.
Not for clients with a commercial license, and there are many.
In addition to the limitation to classfiles built for Java8, it sadly has a hard time decompiling new language features even if compiled for a Java8 target. And then there is the well known bug that decompiling full jars in bulk does not get you the same output you see in the UI but orders of magnitude worse... jd was great until it lasted, helped me solve a lot of issues with verdors over the years.
I like a lot of things about it and used it extensively instead of the inferior REST alternative, but I recommend to be aware of the limitations/nuisances. Not all issues will be simply solved looking at stackoverflow.
Did they improve the initial steps to get up and running too?
(I remember it took hours to clone all the subprojects and most of the times something failed along the way, even worse than downloading the Android sources)
Note: God bless the Oscilloscope, essential for these projects.
The course is well structured, teaching the basics you'll need for those boards that doesn't usually have an OS and requires a ~40$ components kit that include a Texas Instruments board. Quite fun if you follow along and do all the exercises.
[1] https://www.edx.org/course/embedded-systems-shape-the-world-... , https://www.edx.org/course/embedded-systems-shape-the-world-...
? Why not add a RFID reader (relatively cheap) to the scale and then add tags on the coffee bags to be able to log the consumption for multiple types?
You could even be able to identify the weight of multiple objects (tracking what's on the scale and how the weight changes when it's removed and when it's put back) on a bigger(longer?) scale.
And you could sell kits with tags that people could slap on their own containers and register multiple custom items.
I agree, "autonomous dash button" is a nice way to present it, but if it was capable of detecting what's on it, it would become more or less a "sentient dash button", way better ;)
European HNers with an established company, you should look into this, getting a grant is not as hard as it seems and there are companies that can help you prepare your proposal (even for free, check you local government programs)
[1] https://en.wikipedia.org/wiki/Framework_Programmes_for_Resea...
I'm now at chapter 12, and imho, there are a few things that could be improved to make it even better (e.g. a bit more details on what the code in the later chapters does, redundant explanations that could be removed to add something else, other explanations that are a bit too succinct, etc...).
As a side note, I wrote a similar post in Swift: https://www.uraimo.com/2017/02/05/building-a-lisp-from-scrat...