-
Can someone with cognitive science back me up on my gut feeling? Everyone has a hard time learning new skills and everyone uses search engines occasionally, but going to these lengths to cheat actually impair learning.
Unless you count learning how to use the cheat sheet as a valuable skill.
-
-
Absolutely right! And I was feeling guilty while creating cheat.sh. That is why we have developed some countermeasures. If we manage to implement this, cheat.sh will have the most important feature of any real cheat sheet: it will help not really to cheat, but to learn too.
Thank you for this your comment. That is actually the comment that made me register here. This is a very very deep and important thought. Thank you
-
-
The stuff usually found on cheat sheets is “How do I reverse a list in Python?” and not some insanely advanced skill.
Usually the answer is something inefficient and misleading, when it should be “Mu! You do not.” - and even then it’s not a hard thing to learn.
Learning how to deal with your language’s and framework’s etc reference manuals, now that’s a worthwhile skill. A gift that keeps on giving.
-
But it could potentially also grow the cargo-cult culture of programming: those who don’t understand the language and don’t care, but copy and paste snippets together and bash on it until they reach some definition of success. The snippets are helpful reminders for those familiar with the deep details, but could be uninformative and relatively context-free crutches that only hobble newer programmers from understanding why that particular snippet needed to be different to be the right answer to their actual problem, in the context of the code they’re actually working on.
-
The snippets are helpful reminders for those familiar with the deep details
Yep.
Sometimes I use snippets for complex operations that I don’t really care about.
I think this is a great example. https://stackoverflow.com/questions/39799999/parsing-a-soap-message-using-xpath-in-java
Let it suffice to say that I need that for some reason, and it’s not performance critical, and I fully understand that I’m going to get really deep call stacks and great gooey gobs of complex objects in memory during runtime. I can picture some approximation of it in my mind. (I use rectangular prisms, nested like Russian dolls, in primary colors, megabytes upon megabytes of them, and the tiny little strings that are actually useful data are glowing, everything else is dusty-translucent.)
I’m also going to literally println a CSV file on the other end, throw it in a Scheduled Task (no, I didn’t say cronjob), and move on to a more important project.
Using the snippet is the right choice for this part of this project. All I need are those little (glowing) strings.
-
-
-
-
nickpsecurity
4 months ago
|
link
| on:
How a new data center in Singapore is helping people access Wikipedia around the globe
“Privacy is essential” for our users. So, we deployed a new datacenter in a police state whose level of surveillance rivals that of the NSA that inspired it. Well, I guess it’s true so long as they or cheap admins aren’t in your threat model.
On the non-privacy side, it’s good they boosted speed for people on that side of the world.
-
The privacy link here was more about running our own edge infrastructure at all, as opposed to farming it out to various third parties and/or cloud services.
Our core datacenters are already located in the US on the NSA’s home turf, so it seems a little off to complain that our SG deployment changes our risk level significantly by emulating the US in these regards. SG was on an extremely short list of reasonable deployment sites in the region which made sense for us in light of various technical concerns, legal risks, and political issues.
The NSA and similar actors are clearly a part of our threat model, as witnessed by the fact that we have an ongoing legal battle with them over these very issues: https://blog.wikimedia.org/2017/06/23/wikimedia-v-nsa-present-future/ .
-
I think systemd had some really noble aims, and it has succeeded in many of them, which is at least partly why it’s so successful. There are, however, I think a couple of under-represented negative points, more from my point of view as a developer of unix daemon software than from the end-user view:
There are some great ideas in systemd, and great accomplishments. The problems tend to boil down to lack of listening to all of their audiences, lack of open design processes, and lack of even the barest attempt to establish newer/better cross-platform standards and portability. I wouldn’t ask that they spent 10 years trying to update POSIX or something, but even attempting to get some community consensus on the directions and APIs involved among the *BSDs might’ve been a start.
Those are valid points. On the other hand…
… it depends on what “job” you’re doing. Look at what psutil must do to inspect process info (even some very basic queries) for the different BSDs. Cross-platform is not easy, and there are big gaps in POSIX.