HN user

nertzy

280 karma

Full stack developer. Rubyist. Electronic musician.

https://nertzy.com

Posts8
Comments91
View on HN

TLDR implies you didn’t read - therefore you don’t know if it’s slop.

But seriously it does read well like normal thoughtful human writing, so I am on the side of it not being “AI slop” while also noting that you didn’t claim it was.

The editor treats edits from Claude Code as a first class citizen. You can easily review, approve, rollback, etc. Claude's changes in a curated experience that is much faster than digging around in diffs or needing to approve each edit as it is proposed.

https://zed.dev/agentic

I am still a Yahoo! pinger as well.

  ~  ping yahoo.com
  PING yahoo.com (74.6.231.20): 56 data bytes
  64 bytes from 74.6.231.20: icmp_seq=0 ttl=50 time=42.366 ms
  ^C
  --- yahoo.com ping statistics ---
  1 packets transmitted, 1 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 42.366/42.366/42.366/0.000 ms

Isn’t it because you can generate the same content two different times and hash it and come to the same ETag value?

Using UUID here wouldn’t help here because you don’t want different identifiers for the same content. Time-based UUID versions would negate the point of ETag, and otherwise if you use UUIDv8 and simply put a hash value in there, all you’re doing is reducing the bit depth of the hash and changing its formatting, for limited benefit.

This is the only correct answer. I interviewed dozens of people this way over more than a decade. Hiring was never difficult to get right.

Bonus: we self-selected for people who don’t like to pair. We paired 100% of the time.

Bug Thread 2 years ago

My favorite was when I was in college. I spent a long time trying to figure out how to get my WiFi card for my school-issued laptop working in Linux. Someone else posted a fix (with a full explanation of what to do!) and I followed it and it worked!

Then I look at the username and it’s my classmate from down the hall in the same dorm.

And I’m pretty sure I actually did end up in a beach house with them at some point.

I used to work on a software development team with James Somers and I can attest that he is both a great writer and able to handle criticism, valid or otherwise. I think he would appreciate the debates he is generating.

"The lingering uncertainty in the social control of risky technology is how to control the institutional forces that generate competition and scarcity and the powerful leaders who, in response, establish goals and allocate resources, using and abusing high-risk technical systems".

Seems to me that the relationship between Boeing and its various 737 MAX customers could be seen in a very similar light. Abusing high-risk technical systems as a tool to extract resources to cover for artificial scarcity in budgets or market expectations.

Great to see Olin getting some attention.

I was one of the 30 student Partners they talk about and I can't even begin to enumerate how many wonderful experiences I've had. After graduating, transitioning to work for a small software startup was quite natural.

Also, it is interesting to note that several Y Combinator teams have been made up of Olin students. (Flagr and Thinkature come to mind)

Franklin W. Olin College of Engineering in Needham, Mass. (alma mater of a handful of YC team members) has taken several of these ideas to heart.

http://www.olin.edu

No tenure, collaboration with nearby institutions to share courses, encouragement for all community members to contribute to developing and changing all aspects of the college at any time, and no separated academic departments. The list goes on and on.

It's a great place for entrepreneurially-minded students to find an atmosphere that allows them to build up their skills without having to settle for university-level bureaucracy.

I had the pleasure of taking a course on synchronization with Prof. Allen Downey at Olin College. He made the topic very understandable, and even added student problem examples to this text! I wrote the "Faneuil Hall problem".

Prof. Downey has a great knack for making complex CS topics seem very simple.

"I recently had an e-mail from a Windows developer in the Ruby community who pointed out how opaque many Ruby projects are regarding Windows."

I guess my response to that would be that Microsoft is quite opaque regarding Ruby. By being such a closed system, Windows doesn't do anything to help developers improve Ruby library compatibility.

Compare this to Apple. Apple builds Ruby into its operating system, contributes patches upstream, and is even supporting the development of MacRuby, which more tightly integrates Ruby into the Mac OS X operating system.

So the opaqueness goes both ways in my opinion.

Due to this, I am very impressed that Ruby even has the level of support in Windows that it currently enjoys. I would say that Windows hackers should keep up the good work and submit substantive patches as often as possible.

I understand your sentiment but frankly I disagree.

Your first paragraph presents a straw man. Sure, in extreme cases, reproducing a bug is not mandatory. Again, the author does not claim that reproducing a bug is mandatory, but rather that it is a useful practice.

It is not a virtue to try to base your work on the least amount of information.

You say that "when the hard problems come you will be ready". But really when the hard problems come you will look at them assuming that the logged information is enough to solve them. No programmer can know ahead of time what information to log, so by purposefully blindfolding yourself from experiencing the bug directly, you might miss the bigger picture.

Indeed, I can't think of a reasonable logging mechanism that the author could have thought of ahead of time that would have helped with this particular bug. Emphasis on "reasonable".

I think you're reading it a bit too extremely.

His point is that you always try to reproduce the bug before you assume you understand it.

His comments don't say anything about what to do if you're unable to reproduce. He's just suggesting in which order he thinks you should take certain actions.

It's altogether too easy to jump straight to a patch, submit it, and miss the forest for the trees because you never actually went through the use flow and realized you were patching a symptom, not the underlying problem.

LinkedIn lets you decide whether or not to have a public-facing profile. That profile is fully indexable by search engines. You can choose to turn it off.

Nothing to see here. Move along.

There is a reason that the common login process has evolved into what it is today.

While I wouldn't want to discourage trying new things, it's definitely worth it to read the other comments on this page and then decide if the convenience you'd be providing on login is more important than the prevented headaches when a user hits an edge case that is no longer covered.

My point is not to tell you "no, don't do it" because your particular site might be different enough from the usual site that this approach could work. Although I guess that is probably unlikely.