ngomez's comments

ngomez | 1 year ago | on: uBlock Origin is no longer available on the Chrome Store

I've been trying uBO Lite myself for a few months, and anyone who uses YouTube will absolutely notice that it's worse at blocking. Lite tends to delay playback at the start of a video for as long as the blocked ads would've been, making the site feel slower, and once in a while an ad will slip past the blocker anyway.

ngomez | 2 years ago | on: Mustafa Suleyman of Inflection AI Joins Microsoft

Not the whole thing: a lot of the Windows org chart is still under Rajesh Jha in Experiences + Devices, or scattered around Azure with Scott Guthrie. But they've already been pushing Windows Copilot and Bing Ads and widgets, so I imagine the plan is more of the same.

ngomez | 5 years ago | on: An update on our security incident

>if a Twitter user was logged in with a dongle but the attacker had access via social engeneered remote desktop access a dongle still could mean access to private data

It depends on the dongle. YubiKeys and similar devices require the user to physically touch/tap it to enable U2F auth, and it automatically powers down after a timeout to prevent remote desktop attacks.

I would hope Twitter already had this kind of setup, but their blog posts about this are all targeted at a more general audience, so I doubt we'll get that kind of detail anytime soon.

ngomez | 6 years ago | on: Apple Is Locking iPhone Batteries to Discourage Repair

What's stopping Apple from selling the parts that they manufacture to third parties, though? If anything this is an argument for right to repair laws, not for manufacturers to further restrict how consumers can use their devices. The Massachusetts right to repair laws for vehicles already provided a good framework for such an electronics repair law.

ngomez | 7 years ago | on: Microsoft acquires Github

Can you point to an example of telemetry that Windows is collecting that isn't documented and shown?

ngomez | 8 years ago | on: Why we still can't stop plagiarism in undergraduate computer science

I'm also a TA for the class mentioned in this article. We teach Git and have a submission system where students submit patches based on skeleton code; students are required to make at least five commits. We still have a significant number of students who copy code, and while it does help with picking up on that kind of behavior those students also don't seem to care about the increased cost and will pad their commits anyway.

ngomez | 8 years ago | on: Why we still can't stop plagiarism in undergraduate computer science

The issue of incentivizing students to guess-and-check when providing the test scripts upfront is, IMO, fixed by making the students write the tests themselves. This paper explains it pretty well:

https://www.cs.tufts.edu/~nr/cs257/archive/stephen-edwards/a...

Essentially the students would write a test suite and the grading framework would grade based on

1) Code coverage when running the student's test cases against an instructor's reference solution

2) Correctness of output: running student's test cases on student's code and comparing with output from running those test cases on the reference solution

3) Number of test cases passed in student's test suite

Also from the paper:

"All three measures are taken on a 0%–100% scale, and the three components are simply multiplied together. As a result, the score in each dimension becomes a “cap” for the overall score—it is not possible for a student to do poorly in one dimension but do well overall. Also, the effect of the multiplication is that a student cannot accept so-so scores across the board. Instead, near-perfect performance in at least two dimensions should become the expected norm for students."

Students still get the benefit of knowing their grade when they submit, and as an added bonus students get more hands-on experience with test-driven development. Having the students write the tests themselves also increases the cost of mutating code until it just works.

ngomez | 9 years ago | on: XCalibur – the microSD in the stone

The interesting thing is that dd wouldn't even give us an error, but the write speeds were abysmal. Toward the end of the hackathon, we noticed that blocks would be corrupted here and there, while leaving other pieces of data (even entire MP3 files) intact.

I think we ended up pointing to issues with the SD card's bus as the most likely cause for the behavior we saw, but we weren't even certain about this.

page 1