Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.
I making activitypub server used for testing...
OK, I bought fedi.blue because I can, and I have no plans to use it for anything specific. Well, at least, I want to build an app that is compatible with both the fediverse (AP Protocol) and Bluesky (AT Protocol) ecosystem at the same time. So... if you have any ideas or suggestions, feel free to let me know! Sincerely, I want to waste money no more for domains that I won't use, so if you have any good ideas, please, please, PLEASE share them with me. You can find me at @chomu.dev초무 on Bluesky and
i feel like i've probably asked this before but has anyone written a fancy command line man page viewer to replace `man`?
(not emacs)
개발곰 @gaebalgom@hackers.pub
The developer of gaji introduces a tool designed to replace traditional YAML-based GitHub Actions with TypeScript. Inspired by experiences at the Toss Client DevOps Team, the author argues that YAML is fundamentally ill-suited for expressing complex behaviors and lacks necessary type checking, which leads to frequent runtime errors and slow development cycles. Unlike traditional linters that catch errors after they are written, gaji utilizes a Rust-based binary to automatically generate TypeScript types directly from action metadata, enabling real-time IDE autocomplete and compile-time validation. The post compares gaji with other tools like actionlint and existing TypeScript workflow libraries, highlighting its unique ability to support custom and internal actions through local code generation. While the tool remains bound by certain platform-level constraints of GitHub Actions, its implementation in complex CI/CD pipelines proves its efficiency in managing intricate workflows. This project offers a compelling solution for developers looking to transform fragile infrastructure configurations into robust, type-safe code.
Read more →Optique 0.10.0 released—the biggest update yet for this TypeScript CLI parser library.
What's new:
@optique/config package with Standard Schema validation@optique/man)This is the last pre-release before 1.0.0.
洪 民憙 (Hong Minhee) shared the below article:
Haze @nebuleto@hackers.pub
SheetKit is a high-performance Rust-based spreadsheet library designed for Node.js to address the limitations of existing Excel processing tools. Developed over a single intensive week using an architect-led workflow with coding agents, this library leverages napi-rs to provide comprehensive support for the OOXML specification, including complex features like charts, conditional formatting, and extensive formula functions. To overcome the memory overhead and garbage collection pressure typical of JavaScript-heavy Excel libraries, the architecture utilizes a specialized raw buffer FFI protocol and lazy-loading mechanisms. These optimizations allow SheetKit to handle massive datasets with a significantly reduced memory footprint, occasionally outperforming native Rust implementations in specific write scenarios due to efficient string interning within the V8 engine. The project introduces advanced capabilities such as streaming readers for forward-only processing and copy-on-write saving to bypass unnecessary re-serialization of unchanged data parts. This development represents a significant step forward in Node.js data processing, offering a robust and scalable solution for developers managing high-volume or complex spreadsheet workflows.
Read more →@hongminhee洪 民憙 (Hong Minhee) Thank you for this! 이 걸 만들어 주셔서 고맙습니다! https://github.com/dahlia/cjk-compsci-terms
개발곰 shared the below article:
Haze @nebuleto@hackers.pub
SheetKit is a high-performance Rust-based spreadsheet library designed for Node.js to address the limitations of existing Excel processing tools. Developed over a single intensive week using an architect-led workflow with coding agents, this library leverages napi-rs to provide comprehensive support for the OOXML specification, including complex features like charts, conditional formatting, and extensive formula functions. To overcome the memory overhead and garbage collection pressure typical of JavaScript-heavy Excel libraries, the architecture utilizes a specialized raw buffer FFI protocol and lazy-loading mechanisms. These optimizations allow SheetKit to handle massive datasets with a significantly reduced memory footprint, occasionally outperforming native Rust implementations in specific write scenarios due to efficient string interning within the V8 engine. The project introduces advanced capabilities such as streaming readers for forward-only processing and copy-on-write saving to bypass unnecessary re-serialization of unchanged data parts. This development represents a significant step forward in Node.js data processing, offering a robust and scalable solution for developers managing high-volume or complex spreadsheet workflows.
Read more →
Jiwon shared the below article:
Haze @nebuleto@hackers.pub
SheetKit is a high-performance Rust-based spreadsheet library designed for Node.js to address the limitations of existing Excel processing tools. Developed over a single intensive week using an architect-led workflow with coding agents, this library leverages napi-rs to provide comprehensive support for the OOXML specification, including complex features like charts, conditional formatting, and extensive formula functions. To overcome the memory overhead and garbage collection pressure typical of JavaScript-heavy Excel libraries, the architecture utilizes a specialized raw buffer FFI protocol and lazy-loading mechanisms. These optimizations allow SheetKit to handle massive datasets with a significantly reduced memory footprint, occasionally outperforming native Rust implementations in specific write scenarios due to efficient string interning within the V8 engine. The project introduces advanced capabilities such as streaming readers for forward-only processing and copy-on-write saving to bypass unnecessary re-serialization of unchanged data parts. This development represents a significant step forward in Node.js data processing, offering a robust and scalable solution for developers managing high-volume or complex spreadsheet workflows.
Read more →
Jaeyeol Lee shared the below article:
Haze @nebuleto@hackers.pub
SheetKit is a high-performance Rust-based spreadsheet library designed for Node.js to address the limitations of existing Excel processing tools. Developed over a single intensive week using an architect-led workflow with coding agents, this library leverages napi-rs to provide comprehensive support for the OOXML specification, including complex features like charts, conditional formatting, and extensive formula functions. To overcome the memory overhead and garbage collection pressure typical of JavaScript-heavy Excel libraries, the architecture utilizes a specialized raw buffer FFI protocol and lazy-loading mechanisms. These optimizations allow SheetKit to handle massive datasets with a significantly reduced memory footprint, occasionally outperforming native Rust implementations in specific write scenarios due to efficient string interning within the V8 engine. The project introduces advanced capabilities such as streaming readers for forward-only processing and copy-on-write saving to bypass unnecessary re-serialization of unchanged data parts. This development represents a significant step forward in Node.js data processing, offering a robust and scalable solution for developers managing high-volume or complex spreadsheet workflows.
Read more →Haze @nebuleto@hackers.pub
SheetKit is a high-performance Rust-based spreadsheet library designed for Node.js to address the limitations of existing Excel processing tools. Developed over a single intensive week using an architect-led workflow with coding agents, this library leverages napi-rs to provide comprehensive support for the OOXML specification, including complex features like charts, conditional formatting, and extensive formula functions. To overcome the memory overhead and garbage collection pressure typical of JavaScript-heavy Excel libraries, the architecture utilizes a specialized raw buffer FFI protocol and lazy-loading mechanisms. These optimizations allow SheetKit to handle massive datasets with a significantly reduced memory footprint, occasionally outperforming native Rust implementations in specific write scenarios due to efficient string interning within the V8 engine. The project introduces advanced capabilities such as streaming readers for forward-only processing and copy-on-write saving to bypass unnecessary re-serialization of unchanged data parts. This development represents a significant step forward in Node.js data processing, offering a robust and scalable solution for developers managing high-volume or complex spreadsheet workflows.
Read more →@hongminhee洪 民憙 (Hong Minhee) Thank you for this! 이 걸 만들어 주셔서 고맙습니다! https://github.com/dahlia/cjk-compsci-terms
We have only 4 issues left until the Fedify 2.0 milestone!
We have only 4 issues left until the Fedify 2.0 milestone!
We have only 4 issues left until the Fedify 2.0 milestone!
Welcom to the gaji,
Type-safe GitHub Actions
Write GitHub Actions workflows in TypeScript with full type safety
Welcom to the gaji,
Type-safe GitHub Actions
Write GitHub Actions workflows in TypeScript with full type safety
TypeScript 6.0 beta is now published!
This release brings
- inference improvements for functions
- updates to package.json 'imports'
- Temporal APIs
- alignments for the upcoming TypeScript 7.0
- & more!
Try it today!
https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/
TypeScript 6.0 beta is now published!
This release brings
- inference improvements for functions
- updates to package.json 'imports'
- Temporal APIs
- alignments for the upcoming TypeScript 7.0
- & more!
Try it today!
https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/
AI agent "contributes" PR to matplotlib.
PR gets rejected.
AI agent *writes and publishes blog to shame the maintainer*.
What a time to be alive.
Dear FOSS maintainers,
here’s a list of funding programs currently accepting proposals for maintenance work:
Codeberg: https://codeberg.org/mechko/awesome-maintainer-funding
GitHub: https://github.com/mechko/awesome-maintainer-funding
Thanks to everyone who helped crowdsource it! I’ll keep it updated, issues and PRs are very welcome :)
📬 Issue 78 is out!
This week's lineup:
🤖 𝑆𝑤𝑖𝑓𝑡𝑈𝐼 𝐴𝑔𝑒𝑛𝑡 𝑆𝑘𝑖𝑙𝑙
🧠 𝐻𝑜𝑤 𝑡𝑜 𝑈𝑠𝑒 𝐿𝐿𝑀 𝑎𝑠 𝑎 𝐽𝑢𝑑𝑔𝑒
🌓 𝐷𝑎𝑟𝑘 𝑀𝑜𝑑𝑒
✨ 𝐺𝑙𝑎𝑠𝑠 𝑉𝑖𝑒𝑤𝑠 𝑤𝑖𝑡ℎ 𝑔𝑙𝑎𝑠𝑠𝐸𝑓𝑓𝑒𝑐𝑡𝐼𝐷
🧭 𝑇𝑒𝑠𝑡𝑎𝑏𝑙𝑒 𝑆𝑤𝑖𝑓𝑡𝑈𝐼 𝑛𝑎𝑣𝑖𝑔𝑎𝑡𝑖𝑜𝑛
📦 𝑂𝑛-𝑑𝑒𝑚𝑎𝑛𝑑 𝑟𝑒𝑠𝑜𝑢𝑟𝑐𝑒𝑠
🎬 𝐹𝑟𝑜𝑚 𝑃𝑖𝑥𝑒𝑙 𝐶𝑎𝑝𝑡𝑢𝑟𝑒 𝑡𝑜 𝑀𝑒𝑡𝑎𝑑𝑎𝑡𝑎
🔀 𝐶𝑜𝑚𝑏𝑖𝑛𝑒 𝑂𝑝𝑒𝑟𝑎𝑡𝑜𝑟𝑠 𝐶ℎ𝑒𝑎𝑡 𝑆ℎ𝑒𝑒𝑡
🔗: https://ios-newsletter.snappmobile.io/issues/2026-02-06-issue-78.html by 
@snappmobile
Dear FOSS maintainers,
here’s a list of funding programs currently accepting proposals for maintenance work:
Codeberg: https://codeberg.org/mechko/awesome-maintainer-funding
GitHub: https://github.com/mechko/awesome-maintainer-funding
Thanks to everyone who helped crowdsource it! I’ll keep it updated, issues and PRs are very welcome :)
Hi, new followers! Seems like a good time for a re-introduction.
I'm Hong Minhee (洪 民憙), a software engineer based in Seoul. My pronouns are they/them.
I build tools for the fediverse. Fedify is an ActivityPub server framework in TypeScript, Hollo is a single-user microblogging server (what you're reading this on), and BotKit is a framework for making ActivityPub bots. I care a lot about making federation more accessible to developers, which, as my recent JSON-LD rant probably made clear, sometimes means wrestling with parts of the spec I have complicated feelings about.
I'm a free/open source software person through and through, and a socialist, which informs how I think about tech. Lately I've been thinking a lot about LLMs. My position is probably not what you'd expect from either camp: I think the problem isn't the technology itself but the enclosure of the commons. I wrote about this at length here if you're curious: Histomat of F/OSS: We should reclaim LLMs, not reject them.
Outside of software, I have a long-running interest in CJK languages and writing systems. I'm always happy to talk about Chinese characters, Korean orthography, or the weird corners of Unicode where these things intersect.
Nice to meet you all, and thanks for following.
rewritting a apkit's ActivityPub client, current async-client inherited from aiohttp.ClientSession but, that's not recommended method...
mise WARN env value contains '$' which will be expanded in a future release. Set
env_shell_expand = trueto opt in orenv_shell_expand = falseto keep current behavior and suppress this warning.
켜고 싶다면 VAR = "foo$$bar" 처럼 고쳐야 됨. VAR = '''foo$bar''' 이런거 안 됨. 난 꺼버렸음.
Does Mobilizon currently support hosting paid events that charge a participation fee? If not, is there a roadmap for a future feature update that will make this possible?
I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.
Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.
But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.
Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.
To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.
Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.
mise WARN env value contains '$' which will be expanded in a future release. Set
env_shell_expand = trueto opt in orenv_shell_expand = falseto keep current behavior and suppress this warning.
켜고 싶다면 VAR = "foo$$bar" 처럼 고쳐야 됨. VAR = '''foo$bar''' 이런거 안 됨. 난 꺼버렸음.
Recently, 
Try it at https://ap-thread-reader.fly.dev/.
Built with Fedify and released as open source: https://github.com/moreal/ap-thread-reader.
More details at https://blog.moreal.dev/2026/02/ap-thread-reader-introduction/index.en.html.
IMO about concurrent programming
An agent now builds a 200.000 lines of code C compiler from scratch that can compile the Linux kernel. In two weeks. I think at this point it's hard to argue against the tremendous productivity gains that this technology has created for my industry.
i got bored damn easily so one day i be making something and discard it once the curiosity got resolved maaaan wats wrong w me
Even on Aliexpress, Raspberry pi are so expensive compared to others i think there is no strong reason to buy them anymore we got ESP32 rllllly at least for me
More extreme… more and more !!
By the way, it should be called FediKaigi if it's held in Japan, shouldn't it?
Rome wasn't built in a day, so for now, it would be great to have a Social Web dev room at the 
@fossforall or 
@COSCUP, just like there was at 
@fosdem.
팀에 Claude Code LSP 도대체 어떻게 쓸모있냐고 여러번 핑퐁 때려봤는데 결론은 지금 정도 프로젝트의 코드베이스에서는 find/grep으로 충분하다는 것....
이런 대답까지 받았다...
notJoon
Juntai Park
Liaizon Wakest
규영
박진우
bgl gwyng
Honest take: LSP in Claude Code is a nice-to-have, not a game-changer
For most workflows, grep/glob is sufficient. Claude already navigates
codebases well with text-based search. The token window is large enough
that reading files directly works fine.
Where to focus the demo
Don't demo LSP as a standalone feature. Instead, frame it as:
1. Automatic diagnostics after edits — this is the most valuable part.
Claude edits a file → LSP catches type errors immediately → Claude
fixes them without running tsc. This is invisible to the user but saves
real time. Demo this.
2. Precision in ambiguous situations — show a case where grep returns
50+ matches for a common name like value or data, then LSP's
findReferences returns only the 3 semantically correct ones. This is
compelling visually.
3. Call hierarchy is unique — incomingCalls/outgoingCalls genuinely
can't be replicated by grep. Show tracing a function's impact through a
large file. Good for "should I change this function?" scenarios.
What NOT to emphasize
- Don't position it as a replacement for grep — it's not
- Don't show basic goToDefinition — grep does this fine
- Don't focus on the prompting experience — it's awkward (file, line,
character is unnatural)
One-liner pitch
"LSP gives Claude type-aware code understanding — it catches errors
after edits automatically and provides semantic precision when text
search isn't enough."An agent now builds a 200.000 lines of code C compiler from scratch that can compile the Linux kernel. In two weeks. I think at this point it's hard to argue against the tremendous productivity gains that this technology has created for my industry.
Redesigned my personal website (https://ji.hyeok.org) using the design from my name card! The name card itself is designed by @hongminhee洪 民憙 (Hong Minhee).
The physical name card looks like this.
What do y'all think about this? I was inspired by stage0 and live-bootstrap. So I decided to take a crack at doing bare metal RISC-V code.
What do y'all think about this? I was inspired by stage0 and live-bootstrap. So I decided to take a crack at doing bare metal RISC-V code.
If you're interested in obscure details of the microcode in the Intel 8087 floating-point chip, I have a new blog post...
https://www.righto.com/2025/12/8087-microcode-conditions.html
Happy Febuary to those who celebrate
Happy Febuary to those who celebrate
I had thought about this, but I am not sure how to handle paid RSVP. Monetization matters. We can consider attaching external link, but, I think it is not complete solution
These are ideal and fit into my mental model.
https://event-us.kr/ (korean), https://connpass.com/ (japanese)
But I don't know how to complete implement paid RSVP for fediverse. That's bottleneck
Redesigned my personal website (https://ji.hyeok.org) using the design from my name card! The name card itself is designed by @hongminhee洪 民憙 (Hong Minhee).
The physical name card looks like this.
Redesigned my personal website (https://ji.hyeok.org) using the design from my name card! The name card itself is designed by @hongminhee洪 民憙 (Hong Minhee).
Just shouted out some important things to come like working with 
@anewsocial and 
@bsky.brid.gyBridgy Fed for Bluesky and with @swf on encryption
Now we have 
@hongminhee洪 民憙 (Hong Minhee) 
presenting 
Jihyeok Seo
An Nyeong (安寧)
Perlmint
