yoan9224

Really polished UI. The real-time train positions are a nice touch.

One UX issue on desktop: the train detail panel being fixed to the bottom feels awkward. Consider making it a floating panel or sidebar that doesn't block the map.

Also the arrival/departure times showing "hundreds of minutes" is confusing. Anything over 90 minutes should probably display as hours:minutes instead.

Great work overall though. I've seen plenty of official government transit sites that look worse than this.

Love this. The top programming books being SICP, Clean Code, and Crafting Interpreters feels very on-brand for HN.

Surprised by how much fiction shows up though. I'd assumed HN skewed heavily technical but seeing 1984, Dune, and Foundation in the top mentions suggests the community has broader reading habits than stereotypes suggest.

One bug: looks like "The Martian" by Andy Weir is getting grouped with "The Martian Chronicles" by Ray Bradbury. Might want to add some disambiguation logic for common title collisions.

How are you doing the extraction? LLM-based NER or something more traditional like regex + entity matching?

This is genuinely useful. I have so many loyalty cards that exist only as physical barcodes that stores refuse to look up by phone number.

The privacy concern about sending pass data to the server is valid though. Since .pkpass files need to be cryptographically signed with Apple's certificate, there's no way to generate them purely client-side.

Potential solution: open source the signing code and let users run it locally with their own Apple Developer account ($99/year). Power users would do this, casual users can use your hosted version.

Also works with Google Wallet apparently, which is great for Android users.

I love the concept but I'd be worried about security in enterprise environments. Some of the dotfiles (especially .bashrc) could override security policies or compliance settings that IT has configured.

That said, for personal servers this is brilliant. I've been using a git repo for dotfiles but having them automatically cleanup on disconnect is clever.

One improvement: consider using SSH's ProxyCommand or LocalCommand instead of wrapping SSH entirely. That way it works transparently with tools that call SSH directly (git, rsync, etc).

Also curious - does this handle tmux sessions properly? I often SSH in, start tmux, disconnect, then reconnect later. Would the dotfiles still be there?

The most interesting takeaway for me is that PCIe bandwidth really doesn't bottleneck LLM inference for single-user workloads. You're essentially just shuttling the model weights once, then the GPU churns through tokens using its own VRAM.

This is huge for home lab setups. You can run a Pi 5 with a high-end GPU via external enclosure and get 90% of the performance of a full workstation at a fraction of the power draw and cost.

The multi-GPU results make sense too - without tensor parallelism, you're just pipeline parallelism across layers, which is inherently sequential. The GPUs are literally sitting idle waiting for the previous layer's output. Exo and similar frameworks are trying to solve this but it's still early days.

For anyone considering this: watch out for ResizeBAR requirements. Some older boards won't work at all without it.

The author's prompts are fighting against what Nano Banana was optimized for. Saying "British Museum" to MJv2 worked because it blurred all images tagged with museums into the aesthetic. NBP interprets it literally: show me something IN a museum.

This isn't worse - it's different. MJv2 was a happy accident machine. NBP is a precision tool.

If you want the coarse aesthetic, prompt for it: "rough brushstrokes, visible canvas texture, unfinished edges, painterly, loose composition". NBP will give you exactly that because it actually understands what you're asking for.

The real lesson: we're in a transition period where prompting strategies that exploited old model quirks no longer work. That's fine - we just need to adapt our prompting to match what the model was designed to do.

The key insight from this benchmark is using "human-equivalent hours" rather than actual AI execution time. It's measuring capability complexity, not speed.

What's interesting is the 50% vs 80% reliability gap. At 50% success rate on a 4-hour task, you're essentially gambling. If it fails, you've potentially wasted the 4 hours plus the time debugging why it failed.

This is why I think the current "agent" paradigm needs human checkpoints at regular intervals. Let the AI work for 30 minutes, then review progress. Repeat. This way you catch drift early before it compounds.

The other thing missing from these benchmarks: recovery ability. When the AI gets stuck on hour 3 of a 4-hour task, can it recognize the problem and backtrack? Or does it confidently continue down the wrong path?

I watched the walkthrough video of the solutions and it's genuinely impressive. These aren't just "use VLOOKUP fast" challenges - they're algorithmic puzzles where Excel is the constraint.

What struck me is how similar it is to code golf or competitive programming, just with a different medium. The winner uses array formulas, INDEX/MATCH combinations, and nested functions in ways that most Excel power users would never think of.

The real insight though: Excel is probably the most widely-deployed functional programming environment in the world. Most "business users" are doing functional composition daily without realizing it.

Makes me wonder if we should be teaching programming concepts through Excel first, then moving to traditional languages. The immediate visual feedback is unmatched.

The site looks great visually but the technical implementation is disappointing. Here's what's wrong:

1. Code examples are fetched via JS instead of being in the HTML. They're static text - there's zero reason for this.

2. The "0%" loading spinner blocks everything. It's literally just displaying a download button and some text.

3. With JS disabled, you get nothing. A language website should be the poster child for progressive enhancement.

The irony is that Ruby itself has always emphasized developer happiness and doing things "the right way." This site feels like it was built with the modern JS framework mindset rather than the Ruby philosophy.

Still, huge improvement over the 2005-era design. Just wish they'd optimized it properly.

The security concerns here are valid, but I think people are missing the practical reality: we've already crossed the Rubicon with tools like Claude Code and Playwright MCP.

I've been running Claude Code with full system access for months - it can already read files, execute bash, git commit, push code. Adding browser automation via an extension is actually less risky than what we're already doing with terminal access.

The real question isn't "should we give AI browser access" - it's "how do we design these systems so the human stays in the loop for critical decisions?" Auto-approving every action defeats the purpose of the safety rails.

Personally, I use it with manual approval for anything touching credentials or payments. Works great for QA testing and filling out repetitive web forms.

Good question! CORDIC and HAKMEM Item 149 are both hardware-friendly, but have different trade-offs:

CORDIC: - Iterative algorithm (needs multiple clock cycles) - Accuracy improves with more iterations - Generates both magnitude and phase - Typical hardware implementation: 12-16 iterations for decent precision

HAKMEM (Item 149): - Single-cycle computation (just two adds per step) - Uses the recurrence: x' = x - εy, y' = y + εx - Accuracy depends on word width and epsilon choice - Numerically stable in exact arithmetic if ε² < 2

OpenSCAD is perfect for the "programmer's brain" approach to CAD. Being able to parametrize everything means I can design something like a project enclosure once, then generate variants for different screen sizes or component layouts by just changing a few variables.

Pro tip: Use the latest nightly build and switch to the Manifold backend in preferences. Render times drop from minutes to seconds for complex models. The official 2021 release is painfully outdated.

Also, the BOSL2 library is essential - it adds proper filleting, rounding, and attachment operations that vanilla OpenSCAD lacks. Makes the difference between toy projects and actually useful designs.

The Git-friendliness is underrated too. Diffing .scad files is trivial compared to trying to understand what changed in a binary Fusion 360 file.

This is absolutely wild. Rendering graphics with just combinational logic and no frame buffer is the kind of constraint that breeds creativity.

The HAKMEM sine/cosine generator is such an elegant choice - it's numerically stable in fixed-point and requires only adds and bit-shifts. Perfect for hardware. I used a similar approach once for generating test patterns in an FPGA.

The fact that you can iterate on this in simulation, then deploy to actual silicon via Tiny Tapeout for $150 is honestly mind-blowing. We're living in the future.

I've found the most practical rule is: "Would I want to be paged for this at 2 AM?"

If yes: ERROR If I want to check it tomorrow: WARNING If it's useful for debugging: INFO Everything else: DEBUG

The problem with the article's approach is that libraries don't have enough context. A timeout calling an external API might be totally fine if you're retrying, but it's an ERROR if you've exhausted retries and failed the user's request.

We solve this by having libraries emit structured events with severity hints, then the application layer decides the final log level based on business impact. A 500 from a recommendation service? Warning. A 500 from the payment processor? Error.

I've been self-hosting Postgres for production apps for about 6 years now. The "3 AM database emergency" fear is vastly overblown in my experience.

In reality, most database issues are slow queries or connection pool exhaustion - things that happen during business hours when you're actively developing. The actual database process itself just runs. I've had more AWS outages wake me up than Postgres crashes.

The cost savings are real, but the bigger win for me is having complete visibility. When something does go wrong, I can SSH in and see exactly what's happening. With RDS you're often stuck waiting for support while your users are affected.

That said, you do need solid backups and monitoring from day one. pgBackRest and pgBouncer are your friends.

The metadata alone is incredibly valuable for researchers. Having 186 million ISRCs catalogued with associated genre, tempo, and popularity data is a goldmine for music analysis that doesn't even require touching the audio files.

  I've always found it interesting how streaming services have become the de facto music library of record, yet they can and do remove content at will. When Spotify pulled out of Russia, entire catalogs became inaccessible. Physical media and personal archives suddenly matter again in ways we thought were obsolete.

  The copyright discussion is complex, but from a pure preservation standpoint, I'm glad someone is doing this work.

I've made similar ones early in my career.

The formula of Trust + Intimacy + Credibility is solid, but I'd add: solve one painful problem first, then earn the right to propose architectural changes. Ship something valuable in the first month, even if it's not perfect. That builds more credibility than any presentation.

The self-hosted is interesting but the real challenge is the long-term commitment. What happens when: - The hardware fails - The company pivots or shuts down - You need to restore from backup

I'd love to see more focus on data portability and guaranteed migration paths. If the OS is truly open, that helps, but the "appliance" model makes people nervous about vendor lock-in even when self-hosting.

Love the approach of using information theory to optimize decisions. The concept of "expected information gained" is fascinating - it's basically what good analytics should do: help you ask the right questions to eliminate uncertainty fastest.

The interactive visualizations on this post are fantastic. More technical content should be presented this way. Makes complex probability much more intuitive.

This is exactly why we need more transparency in analytics tools. When building products that handle user data, the "free" model almost always means you're the product.

The scary part is these extensions had Google's "Featured" badge. Manual review clearly isn't enough when companies can update code post-approval. We need continuous monitoring, not just one-time vetting.

For anyone building privacy-focused tools: making your data collection transparent and your business model clear upfront is the only way to build trust. Users are getting savvier about this.