This attitude is both hateful and harmful to our profession. It is not ok and I wish more of our peers would step up to tell you that this is not acceptable.
You are also making wildly inaccurate statements to justify your abuse and I hate to think that other readers might accept them uncritically. We have been actively pushing women out of computer science for the past 30 years (and doing a fine job or excluding and ignoring the contributions of other minority groups in the process). Suggesting that men "were" dominant and misrepresenting the direction of this change in willful ignorance of history at best.
I know relying to trolls is not particularly effective and other users have called this out for being hateful but I don't want to see us accept either the premises or the tone presented here.
Unless you are a minority in the field in which case your success apparently requires tolerating disproportionate abuse from your socially inept peers. Hardly the meritocratic environment we like to imagine here.
If students are being harassed and driven away from a subject by their peers I don't think the out of date curriculum is the most significant problem in that classroom.
This is a high-school, so pubescent boys making disparaging remarks and teachers unable to control class are both expected and completely mundane. Certainly they wouldn't make it into a USENIX blog post, and I don't think anybody would infer from these events that "tech is sexist".
So the curriculum was the best reason I could figure why this is on USENIX.
(I certainly don't want to excuse the shortcomings of this particular teacher, and there are many, but I think the system is setup for failure)
> While designed to make things easier for newcomers...
The idea that Rails was designed to be accessible to newcomers seems to be pervasive but I don't think that has every been a top priority for the project. The framework is described as "optimized for programmer happiness and sustainable productivity". It's great if this also leads to a design which is approachable for newcomers but I think it is a mistake to judge features as if that was the intent.
Caution is a good attitude to have when working on critical code with non-obvious modes of failure.
However I agree with davidw; this "dont' touch it" or "we're not smart enough" attitude is tiresome. Couldn't we instead admit that this is a difficult problem which requires some engineering rigor to solve well and talk about how we can address such problems like professionals instead of hiding from them?
Most people don't actually want to do their own surgery. Even if you put a scalpel in someone's hands, and gave them all the anesthesia, they still wouldn't be tempted to remove someone's appendix after reading an eHow article about it.
The same isn't true of crypto. People know both intellectually and viscerally that they shouldn't be doing their own surgeries. But they only have an intellectual understanding that crypto is unsafe.
A big part of that is because the harm caused by crypto mistakes are often an externality to the developer.
Oddly I don't see any mention in the article or linked paper of financial aid as a contributing factor to these decisions.
I recall my college social circle being intently aware of GPA requirements for continued merit based financial aid. Planning course schedules to try to keep quarterly grades above our individual cutoffs was a common practice. That same pressure influenced willingness to pursue minors, preparation for masters programs, or double majors. Students in danger of losing their financing absolutely considered which related majors they might transfer into which might offer better odds of a successful degree.
Sadly I think this lead to several students who literally could not afford to risk pursuing their preferred subjects.
Damn right! When I was in college everyone knew that despite Commonwealth College (the honors program) offering merit scholarships, you didn't want to join if you were in STEM.
Why? Because they imposed a minimum GPA requirement (which started at 3.2/4.0 and went up over the years), also additional coursework requirements (you had to take a certain number of "honors courses") and a thesis requirement.
Now, maintaining good grades and doing an undergrad thesis isn't that bad. Maintaining good grades and doing an undergrad thesis while also filling your honors coursework when your department's cooperation with the honors program is in its infancy and the honors college thinks only humanities subjects should count for the Special Honors Sequence, THAT was the problem. Please note that yes, you had to do a Special Honors Sequence and an Honors Gen Ed.
The result was predictable: people would try to "dodge out" by doing the easiest Honors courses they could get, because Honors courses usually had nothing to do with your actual degree focus.
Thus, I have been through a seminar about a neurologist working on African baboons, and another one about Judaic bioethics. My honors thesis had to be classified as an Independent Study, along with much of the undergrad research work I did, and without that stuff I would never have filled my honors requirements without screwing over my Computer Science requirements.
The "merit aid" bureaucrats are often not only complete idiots, but operating on a basic assumption that Merit Means Humanities.
I was briefly a user of LastPass until that service lost every credential set I had added to it. I tried a KeePass store in DropBox for a while but the poor cross platform support and mobile support got me to try 1Password. For what little it's worth I've been very happy with 1Password so far; superior UX, cross platform support, and control of my own backups.
I found it to be possible but difficult to get KeePass running on every machine I want a password store on. When I last used it running the KeePass itself under Mono was an annoying install process, slow to launch, and far from a native UX. Sorting through unofficial contributed ports to find working smart phone apps (and trusting yet another party to manage access to my password store) was also less than ideal.
I'm sure it is possible to get KeePass working smoothly but I'm also happy to have paid for what feels like a better solution to me.
I've talked to folks from Simperium before and think that they have a good idea but I remain skeptical of their approach . In particular their Core Data syncing strategy.
As I understand it Simperium observes changes to the Core Data models you specify, maps those changes to operation transforms, and distributes the transforms across whichever clients have subscribed to the service. That's great if all your app needs is simple data replication to multiple clients. Unfortunately operational transforms are not necessarily snapshots of database transactions and conflict resolution strategies do not guarantee a valid database.
Saving a Core Data transaction on one client may generate multiple operations which are replayed interleaved with operations from other clients. Conflict resolution is then performed between operations rather than transactions. Simperium can probably take steps to minimize that case but as long as I can construct transactions which cannot be expressed as a single operation this will happen.
Worse a client can apply operations without conflicts only to find that its models no longer pass its own validation rules. For example two clients can each add a child object to a "has one" association. Both "create" operations can be applied without conflict but the parent object no longer passes the application's validation rules.
This doesn't make operational transform based synchronization untenable but it does imply a new set of constraints on how applications should model their data in order to successfully apply operations from other clients. That may not be a popular sales pitch but I'm reluctant to feed structured data through a service that doesn't at least discuss the model and its constraints in some detail. Otherwise I fear such a service is another iCloud like trap which will eventually (though perhaps less frequently) hit catastrophic edge cases from which there is little hope of recovery.
> Saving a Core Data transaction on one client may generate multiple operations which are replayed interleaved with operations from other clients.
Interesting; I've implemented OT myself, and this is not a fundamental failing of the concept: in fact, even fairly simple implementations like ShareJS do not succumb to this fate (the easy way to model it is that you end up with larger macro-operations that are capable of transforming eachother's components, while still having to be played back one macro-op at a time; you also just stop playback while a transaction is in progress). I am totally willing to believe that Simperium's implementation (which I believe thinks about the separate objects as separately transformable documents) may have issues here, though.
> Worse a client can apply operations without conflicts only to find that its models no longer pass its own validation rules.
This is certainly true, but is endemic to the entire idea of offline synchronization and has nothing to do with operational transforms: you simply can't do this without accepting "a new set of constraints on how applications should model their data in order to successfully apply operations from other clients"; this is clear from CAP (as rather than become unavailable when the network is offline/partitioned, we have to lose some consistency).
> That may not be a popular sales pitch but I'm reluctant to feed structured data through a service that doesn't at least discuss the model and its constraints in some detail.
This is totally fair. (I can entirely appreciate it as well, as it reminds me of all of my complaints regarding how seldom you would hear companies like Parse and StackMob attempt to drill in how important security should be while using their services, at best leaving it as an appendix in their documentation. I believe they have at least been getting somewhat better about this since my talk on the subject at last year's 360|iDev.)
You are also making wildly inaccurate statements to justify your abuse and I hate to think that other readers might accept them uncritically. We have been actively pushing women out of computer science for the past 30 years (and doing a fine job or excluding and ignoring the contributions of other minority groups in the process). Suggesting that men "were" dominant and misrepresenting the direction of this change in willful ignorance of history at best.
I know relying to trolls is not particularly effective and other users have called this out for being hateful but I don't want to see us accept either the premises or the tone presented here.