I think the argument is more that this tool by virtue of being easily accessible creates more malicious actors. Similar to how most people wouldn't steal a locked bike, but a larger portion would steal an unlocked one. It isn't that much harder to steal a locked bike vs an unlocked one, but the threshold is just a tiny bit higher so more people will attempt it. Conversely this tool lowers the threshold for stalking, so more people, who otherwise wouldn't, will use it maliciously. That isn't the fault of the tool or its developers, but it is something to be aware of when building any tool. When you release it, it may get abused by people for bad purposes.
I built something related to this for our webapp. Most of the text in the app is in a language specific "key to text" map that is loaded at runtime. I made a bookmarklet that switched the language into a debug mode where the keys mapped to a "<file>:<language-variants>:<Key>". You could switch to this "mode" with a simple keypress. User then highlighted the key they wanted to change, pressed another key-combo and was presented with the different translations and could change them (and switch back to normal mode for a preview). Lastly they could generate a PR with the changes they wanted and a Dev could make sure the strings worked (e.g. validating they had not removed a needed placeholder etc). All in all pretty nifty tool.
I agree, but I think you need hope in order to be happy. I.e. happiness is the combination of high hopes and low expectations.
Without high hopes you could just be anticipating things to get worse which tends to lead to anxiety and just a general glum outlook on life. Hoping things will be better tomorrow, but expecting things to get worse is a subtle but important mindset shift.
If all else is equal, then additional dependencies are a bad thing. Otherwise the only reason to not depend on everything would be code size... And if it's a compiled language with even just a minimum of optimizations then even that wouldn't be an issue.
Wouldn't the fact that if they are ok with you working on FOSS protect you? If you have the source you are free to modify it to you hearts content, right?
Would creating a GPL or BSD licensed project and then contribute to that work (in case the employer allows work on FOSS)? Then one would presumably be free to start a business using that software after quitting. Also if it's BSD licensed there's nothing preventing one from close sourcing the stuff after quitting. Of course the code would potentially already be out in the world and used if it's in a public repo...
IIRC RNA is made up mostly of the same nucleic acids as DNA. T (something something) is replaced by Uracil. The main difference is that DNA is double stranded whereas RNA is single stranded. Since mRNA uses three acids to represent one of the amino acids that make up the proteins it encodes, and there is a finite amount of amino acids, this means no new proteins are encoded if you add more "letters" to DNA/RNA.
Possibly the RNA could have some secondary function in the folding of the protein or as a complex inside it...
One thing I think is missing from the current html spec is having a src attribute on select tags. Would be nice to be able to not have to define the options directly on a page and instead serve them up dynamically. Not a big problem off course, but it seems like something that is missing.
That you hold a certain value is logically true as long as you actually hold that value. There is no belief necessary in that case. _Why_ you believe it, i.e. the justification for that belief would need to be empirically grounded if I understand the article correctly. That seems a tall order.
Further, isn't even the scientific method at its core also based on certain beliefs about the world for which there is no empirical basis? Not that that would make it any less valuable as a tool for understanding the world.
The crux of the matter is what should constitute sufficient evidence. Is the same level of evidence required for all beliefs? What about things for which there are no evidence, eg value judgements - I believe fairness is more important than freedom (or vice versa). Seems like an impossible standard to need evidence for everything.
For learning purposes I created quic[0]. I wanted to strip it down to the bare minimum for running something in a "container". I got as far as having it use a preexisting network namespace. The networking part felt like a major piece of work (setting up the network in bash was tedious) so I figured I'd call it a day and leave it as is. Lots of fun and learned a lot about containers/namespaces in the process.
That depends on the tooling used. One way for linters and static analysers is to only run them on files touched by commits. For test coverage (if that is important) you can use something similar to detect the coverage for those relevant files. It really depends on your setup though.
What I usually aim for is that all new code/commits conforms to style and other requirements like having tests etc. Usually it is possible to configure tools to only flag something as a bad build when the new code doesn't conform to those qualities.
However, this means that as soon as you start mucking about in the legacy code, that code need to be covered by tests and formatted to pass any style checks and linters. That is not an insignificant amount of work so plan accordingly.
Also, I find it useful to remember that even if the code is not to my liking (for whatever reason) it might be consistent. I.e. maybe it uses some coding style I am unfamiliar with and I would rather it used another it is often detrimental to start changing it to be more inline with my preferences. Consistently poor code is often easier to reason about than code that is a mix of different preferences and patterns. This also goes for when thinking about introducing new technology to an existing code base (see the lava flow antipattern).
An organisation always has some kind of culture. If it is "defined" (I interpret that as something being written down) or not doesn't really matter. Whatever is defined in that sense is not really the culture of that organisation. You can define your culture in any way you want with whatever value statements you desire an organisation to embody, but most likely those will not reflect the actual culture in the org.
That's not to say that trying to be explicit with the culture you want in an organisation is bad. It is just recognising that the words are not the culture. The people, the way they interact and the atmosphere in the company and what drives it is what creates the company culture.
> Have we really not understood OO at all so that we have to reinvent it all the time?
We haven't. I think the popular OO languages shows this. In both Java and .Net the focus is on classes, not on messages passed between objects. But class hierarchies are not essential for message passing. Classes are mainly a way of decomposing an application into manageable logical parts of interacting chunks. Looking at how many language features center around classes and class hierarchies (interfaces, abstract classes, generics, inheritance etc) as opposed to how many facilitates different forms of interactions between objects (you basically have method calls and arguably async/await) it seems clear to me that these languages are more "class oriented" than object oriented...
https://javalin.io/news/javalin-5.0.0-stable.html