391 karma · joined July 11, 2014
> [...] Monica is an old code base now. Old in the sense that it’s 7 years old and it has been touched by hundred of contributors. There are some concepts in the code that we let through, because we either didn’t know any better back then or because we didn’t want to piss off contributors, that we don’t want anymore. The project has way too many dependencies, and maintaining the code has become harder than it was before. Changing something is riskier, and takes more time. Also, we’ve seen how people use Monica, what they want to do with it, and the current code limits us way too much if we want to support what people want to use Monica for. Finally, Monica is still a side project for us. We are extremely passionate about it, and we want to also have fun building it. And the current version wasn’t that fun.
> History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (encapsulation). Because subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this. It was the novel element introduced by Liskov and Wing. A violation of this constraint can be exemplified by defining a mutable point as a subtype of an immutable point. This is a violation of the history constraint, because in the history of the immutable point, the state is always the same after creation, so it cannot include the history of a mutable point in general. Fields added to the subtype may however be safely modified because they are not observable through the supertype methods. Thus, one can define a circle with immutable center and mutable radius as a subtype of an immutable point without violating the history constraint.
[1]: https://en.wikipedia.org/wiki/Liskov_substitution_principle#...
At the bottom of the product page [1] they have an explosion graphic rendering which looks like (assuming it is somewhat correct) the sensor is below other chips and moved away from them. The sensor also seems to be shielded by having a separate area of it's own in the plastic enclosure.
I haven't tested them yet but I think they should do fine, by the criteria of the article.
-
[1]: https://www.aqara.com/us/temperature_humidity_sensor.html
I think the author would probably consider 'green energy' to also be a 'slightly incorrect' example because it doesn't actually refer to the color green. I guess it would be correct if the antonym of green energy were also named after a color.
There are some strange builtin entries from Windows. Like why do I have the option to "play" a jpeg on any Bluetooth headsets that are paired with my laptop? I just found out that besides "open with" and "send to" there is a third way to open a file using "share" to share a file with an app.
The most useless entry is probably from AMD Radeon software. Two entries on the very top of the context menu on every folder. I would understand if it appeared in the menu of the Desktop folder, but not on every single folder no matter how deep in the file structure.
[1]: https://shapez.io/
> As a backup, you either have some kind of spare keys in safe storage or reliable access to someone who can restore your access after having identified you.
I have two Yubikeys, but I don't consider the second one as "spare" that has to be locked away. I carry one USB-C/NFC key on my key chain. The other is a USB-A Yubikey nano, which is always at home in my desktop's monitor USB port so I can reach it very easily. By using both regularly, I'm more likely notice if one key gets broken or lost.
> * in some case you could generate the key beforehand on a computer, and then load it on a stick (unsure about yubikeys though). You should still revoke your key anyway once your stick is lost - as you should assume it could be found and used, sometimes needing only a touch operation rather than a PIN.
You can do that with yubikeys. You can copy the same secrets to a different key or store them somewhere safe. I considered doing this, but in the end all services that I use allowed to add two keys which seems like the better option. My reasoning was that if I have two identical keys A/B and I loose key A, I would have to immediately invalidate key B too - but before I can do that I would need to:
1. get a replacement key C 2. setup new secrets for key C and store them 3. then log into every service to add the key C and remove key A/B 4. reset key B to use the same secrets as key B
Up until point 3 (which my take a while until I get key C, unless I would always have a third key lying around) all accounts are vulnerable. On the other hand if I have two separate keys with different secrets, I can just remove the lost key from all services and deal with the replacement key later.
A big part of the client is for browsing through music/album/playlists/artists. Of course you could search for music outside of Spotify but it's really convenient to have it integrated in the client. There's also a social media part (definitely bloat, I have disabled it) and more hidden features like being able to control the client from other Spotify clients (e.g. on my phone) which I use all the time.
300 MB is not great but it's low enough that I don't really care.
"Modular Architecture" is more broad in my opinion and rather a description of internal structure. A "modular monolith" for example is modular but doesn't necessarily have a "core" nor is it required to be extensible with plugins by users.
What makes you think that? I just skimmed the draft and it seems to use a sensible whitelist as default. Developers can allow or deny additional elements/attributes as they like.
That being said, my first impression from the article was quite the opposite of yours. I thought it was great news for CoenraadS. He developed something so useful, that it was integrated into the core. That's impressive! The plugin is obsolete now, but in this case it looks like "mission accomplished".
Of course this move would look different in other app/extension ecosystems where extensions are monetized and/or not open source.
There's a lot tooling in the Eclipse modelling ecosystem which could be easily used for this. Storing XML-based models in git is no problem and there's tooling for diffing and merging models via a GUI or programmatically. Combined with the fact that xtext DSLs use EMF models to represent ASTs, it wouldn't be too hard to glue together an AST-based a diff/merge tool for an xtext DSL.
"where the random chance takes place" could easily be interpreted as where the random number is _used_ and not where it has been created. Creating random numbers is not "chance" per se (in this context). Using random numbers to e.g. determining a winner would be the chance in my opinion.
On the other hand I was unpleasantly surprised with the taste of tap water in the UK.
I totally agree but for me that means using a debugger and make full use of its features.
> But if you missed the moment, you have start again from the beginning
As already mentioned in another comment, "drop frame" is a standard Java debugger feature. You can easily go back to the start of any method and go though everything again (side effects of already executed code can give some trouble though).
> Or maybe you're looking at the wrong part entirely at this stage, and just wasting time.
You have the same issue when printing in the wrong parts. Of course you can plaster the code with lots of print statements to see which gets executed. But you can do the same with breakpoints and see where the debugger stops.
> With print debugging you write a bit of code to test a hypothesis. Then you run it, and you keep running it, and especially if it's an UI program you play with the UI and see how the values change during that run.
I really like conditional breakpoints for this. You write a condition for a state that interests you. Then play around in the UI until it stops for that condition and you can easily inspect the complete state at that moment. This is quite useful for debugging methods that are executed very often. Trigger breakpoint (which disable all other breakpoints until they are triggered) are also useful in those situations without requiring any code.
> Once you do know where the problem is, and if it's not apparent what the problem is (most problems are pretty trivial once located), that's IMO the time to break out the debugger and slowly step through it. But the vast majority of problems are faster to solve through rapid iterative exploration with prints in my experience [...]
I can just say that I usually locate issued way faster with a debugger. "rapid iterative exploration" could also kind of describe my workflow using breakpoints. Maybe it actually less about the tool and more about your approach for locating issues in the code.
[1]: https://posteo.de/en/ [2]: https://posteo.de/en/help/which-domains-are-available-to-use...
> Why bother answering, when answers must be accepted by the poster and poster does not even know they should accept an answer in the end?
There is no obligation to accept answers. Often the accepted answer isn't the best answer anyway.
WB also supports linking to the very latest version. If the archive is updated frequently enough I would say it is reasonable to link to that if you use WB just as a mirror. In some cases I've seen error pages being archived after the original page has been moved or removed though but that is probably just a technical issue caused by some website misconfiguration or bad error handling.
Anyway the German Wikipedia page about Goldhüte [1] says the ritual significance was attributed because there are tomb paintings depicting similar hats being worn in some religious/cultic context.
Which worked out great, because otherwise most answers would have been specific to OP's emotions and interests and probably wouldn't be that useful to other people.
Questions like this don't get upvoted because of the effort put into them. They get upvoted because of the answers they attract. I'm fine with that if it means I get to read some interesting answers.
- draw.io and graphviz have similar use cases (otherwise it wouldn't have been mentioned)
- Both have VS code plugins
- graphviz is a more structured language
- graphviz is more mature
- graphviz can be used from command line
Maybe there is some better, specialized software for this, but I would worry that it would be so niche or technical that no relative would know how to open the files when needed. Using some more common format would have an advantage here.