Coming soon in #BotKit 0.2.0: Native #quote post support!

We're excited to share a preview of the upcoming quoting features in BotKit 0.2.0. This update will make it easier for your bots to engage with quoted content across the fediverse.

The quoting feature set includes:

• Detecting when someone quotes your bot's posts with the new Bot.onQuote event handler
• Accessing quoted content through the Message.quoteTarget property
• Creating quote posts using the quoteTarget option in Session.publish() and Message.reply() methods

Here's a quick example of how you can use the quote detection:

bot.onQuote = async (session, quote) => {
  // The quote parameter is a Message object representing the post that quoted your bot
  await quote.reply(text`Thanks for quoting my post, ${quote.actor}!`);
  
  // You can access the original quoted message
  const originalPost = quote.quoteTarget;
  console.log(`Original message: ${originalPost?.text}`);
};

And creating quote posts is just as simple:

// Quote in a new post
await session.publish(
  text`I'm quoting this interesting message!`,
  { quoteTarget: someMessage }
);

// Or quote in a reply
await message.reply(
  text`Interesting point! I'm quoting another relevant post here.`,
  { quoteTarget: anotherMessage }
);

Remember that quoting behavior may vary across different #ActivityPub implementations—some platforms like Misskey display quotes prominently, while others like Mastodon might implement them differently.

Want to try these features right now? You can install the development version from JSR:

deno add jsr:@fedify/botkit@0.2.0-dev.90+d6ab4bdc

We're looking forward to seeing how you use these quoting capabilities in your bots!

#fedidev

프롬프트를 구조화할때 XML 태그를 사용하는 것이 좋은 이유

https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags

친구가 외국 반도체회사에 다니는데 이름만 들으면 다 아는 세계에서 손꼽히는 회사다. 1년 전쯤에, 친구가 자기 팀에서 예전부터 쓰고있는 시뮬레이션 코드가 너무 복잡해서 리팩토링 하고 싶다고 나를 찾아왔다. 한 2, 3000줄 되는 Numpy 코드였다.

나는 시뮬레이션의 의미 자체는 전혀 이해를 못하니(이래서 보안문제도 익스큐즈 할수 있었을 것이다), 그냥 코드의 모양만 보고 이상한 부분을 조금씩 고쳐나갔다. 그... 전형적인 물리학자들의 실험실 코드였다(코드를 못짜는건 이해를 하는데, 거기에 대해 한치의 부끄러움도 느끼지 않는다는 점이 뒷목을 잡게 만든다). Numpy 함수도 제대로 활용을 못해놨길래, 나도 Numpy 잘 못쓰지만 대충 이런 함수가 아마 있겠지... 하고 검색해서 찾아내서 교체하고 이런걸 반복했다.

이것저것 고친 다음에 잘돌아가나 한번 실행을 해봤는데, 이럴수가. 시뮬레이션이 1000배 빨라졌다. 아니 뭐, 한 2배 3배 빨라졌으면 내 솜씨라고 자부할텐데, 1000배 빨라진거는 그냥 원래 코드가 똥통이었다고 해석할수 밖에 없다. 구라안치고 정말 1000배다. 1000배의 성능향상의 보답으로 나는 교촌치킨웨지콤보세트를 현장에서 받아먹었다.

그 이후에 어떤 일이 있었냐. 기존 시뮬레이션 코드로는 하루에 시뮬레이션을 2, 3번정도밖에 돌리지 못했는데, 1000배 빨라지고 나니까 결과가 수십초만에 나오니 하루에 수백번 돌릴수 있게 된것이다(내가 고친 코드가 전부는 아니어서 1000배 향상은 아닌데, 가장 큰 병목이긴 해서 결국 100배 이상이라는 듯). 그때부터 100배 많아진 데이터를 처리하기 위한 인프라가 필요해졌다. 그래서 거기 개발팀이 데이터베이스와 데이터 파이프라인 구축을 시작하게 되었다고 한다. 그 팀에서는 일종의 특이점이 시작된것이다;;

결론: 교촌치킨웨지콤보 세트는 개맛있었다.

Continuing our emoji reaction feature announcement, we're also introducing two new event handlers—Bot.onReact and Bot.onUnreact—that let your bot respond when users react to posts:

// When someone adds an emoji reaction to a post
bot.onReact = async (session, reaction) => {
  // Only respond when the reaction is to your bot's post
  if (reaction.message.actor.id?.href === session.actorId.href) {
    console.log(`${reaction.actor.preferredUsername} reacted with ${reaction.emoji}`);
    
    // You can respond differently based on the emoji
    if (reaction.emoji === "❤️") {
      await session.publish(
        text`Thanks for the love, ${reaction.actor}!`,
        { visibility: "direct" }
      );
    }
  }
};

// When someone removes their emoji reaction
bot.onUnreact = async (session, reaction) => {
  if (reaction.message.actor.id?.href === session.actorId.href) {
    console.log(`${reaction.actor.preferredUsername} removed their ${reaction.emoji} reaction`);
    
    // Optional: respond to reaction removal
    await session.publish(
      text`I noticed you removed your ${reaction.emoji} reaction, ${reaction.actor}.`,
      { visibility: "direct" }
    );
  }
};

These event handlers open up interesting interaction possibilities—your bot can now track popular reactions, respond to specific emoji feedback, or create interactive experiences based on reactions.

Want to try these features now? You can install the development version from JSR today:

deno add jsr:@fedify/botkit@0.2.0-dev.86+cdbb52a2

The full documentation for these features will be available when BotKit 0.2.0 is officially released!

ttps://github.com/malkoG/pitch-connect/

일단 fedify를 응용한 프로젝트 하나 도즈어어언!!!!!

We're excited to introduce emoji reactions in the upcoming #BotKit 0.2.0 release!

With the new Message.react() method, your bot can now react to messages using standard Unicode #emojis:

await message.react(emoji`👍`);

#Custom_emoji support is also included, allowing your bot to react with server-specific emojis:

const emojis = bot.addCustomEmojis({
  // Use a remote image URL:
  yesBlob: {
    url: "https://cdn3.emoji.gg/emojis/68238-yesblob.png",
    mediaType: "image/png",
  },
  // Use a local image file:
  noBlob: {
    file: `${import.meta.dirname}/emojis/no_blob.png`,
    mediaType: "image/webp",
  },
});

await message.react(emojis.yesBlob);

Reactions can be removed using the AuthorizedReaction.unreact() method:

const reaction = await message.react(emoji`❤️`);
await reaction.unreact();

Want to try these features now? You can install the development version from JSR today:

deno add jsr:@fedify/botkit@0.2.0-dev.84+c997c6a6

We're looking forward to seeing how your bots express themselves with this new feature!

#emoji_reaction #fedidev #ActivityPub

We're excited to announce that #BotKit 0.2.0 will introduce custom emoji support! This feature allows your bots to express themselves with more personality and engagement.

What's included:

• Add custom emojis to your bot with Bot.addCustomEmojis()
• Use emoji in messages with the customEmoji() function
• Support for both local image files and remote URLs as emoji sources
• Full integration with BotKit's text formatting system

Simple example:

// Define custom emojis
const emojis = bot.addCustomEmojis({
  botkit: { file: "./botkit.png", type: "image/png" },
  fedify: { url: "https://fedify.dev/logo.png", type: "image/png" }
});

// Use in messages
await session.publish(
  text`Hello world! ${customEmoji(emojis.botkit)}`
);

Want to try it early? You can install the development version from JSR today:

deno add jsr:@fedify/botkit@0.2.0-dev.82+8a0438e6

#ActivityPub #fedidev #custom_emoji

터미널에 대해 궁금한 점이 생겨 자료를 찾다 보니 Windows Console Team에서 연재한 시리즈물을 발견했는데, 그 내용이 참 유익했다.

Windows Command-Line Series:

1. Backgrounder
2. The Evolution of the Windows Command-Line
3. Inside the Windows Console
4. Introducing the Windows Pseudo Console (ConPTY)
5. Unicode and UTF-8 Output Text Buffer

콘솔 앱이 터미널과 입출력을 주고 받는 것을 공기처럼 당연하다고 생각했는데, 그 과정에는 커서 이동이나 개행 등과 같은 제어 문자를 렌더링하거나 SIGINT 같은 시그널을 발생시켜주는 처리가 존재했다. 터미널과 콘솔 앱이 서로 분리된 구조가 과거 물리 터미널로부터 비롯된 것도 흥미로웠고 말이다. 사실 이해 못 한 부분이 아직 많아서 다음에 또 읽어볼 생각이다.

암호학에 나오는 Alice와 Bob을 가은이와 나은이로 번역하는 생각

As someone who has developed several #ActivityPub software implementations (Fedify, Hollo, BotKit, and Hackers' Pub), I believe one of the most frustrating features to implement in the #fediverse is #custom_emoji.

The challenges are numerous:

First, there's no standardization. ActivityPub specifications don't define how custom emoji should work, leading to inconsistent implementations across different servers like Mastodon and Misskey.

Rendering is particularly problematic. Emojis must display properly across different contexts (in text, as reactions, in emoji pickers) while maintaining quality at various sizes. Animated emojis add another layer of complexity.

Perhaps most concerning is the poor #accessibility. Most implementations simply use the emoji code (like :party_blob:) as the alt text, which provides no meaningful information to screen reader users (in particular, non-English speakers) about what the emoji actually depicts or means.

What really dampens my motivation to implement this feature is knowing I'm investing significant effort into something that ultimately creates accessibility barriers. It's disheartening to work hard on a feature that excludes part of the community.

#fedidev

@ayoAyo Ayco @hongminhee洪 民憙 (Hong Minhee) It can be so helpful during design! Some people do it first-first. At Astro with our RFC process, minimal "docs" are updated as the feature is developed.

For Astro's new experimental Fonts API, we held not only an open API bash, but an API *docs* bash! After 2 hours looking at the draft docs ("Oh, it works like this? Oh, you expect people to do this? Oh, this is what it takes to explain how to use it?")... some design changes were implemented for sure, and everyone wins!

파이썬에 kanren이라고 논리형 DSL이 있구나.

Side quest sneak peek: a browser extension that visualizes (Service Worker) Cache Storage for web sites.

Decided to build this after seeing how difficult it is too see what's stored in Service Worker cache. They can (accidentally) take up quite a lot of storage space.

Repo: https://github.com/cheeaun/stakataka
Not released yet, under review in Chrome Web Store.

#WebDev #FrontEnd #BrowserExtension #ServiceWorker

Sometimes I'm quite amazed by my own code 😳

The RTL work last year was quite insane https://mastodon.social/@cheeaun/112932794480750449

#PhanpySocialDev #JavaScript #RTL

I've been considering what to add in the next version of BotKit (v0.2.0) and wanted to share my current plans. After reviewing feedback and examining the #ActivityPub ecosystem, I've identified three key features that would significantly enhance the framework's capabilities:

1. Custom emoji support. This would allow bots to use server-defined custom emojis in their messages, making communication more expressive and allowing better integration with instance culture.

2. Emoji reactions. I plan to implement both sending and receiving emoji reactions to messages. This provides a lightweight interaction model that many users prefer for simple acknowledgments or responses. This would manifest as new event handlers (like Bot.onReaction) and methods (like Message.react()).

3. Quote posts. The ability to reference other posts with commentary is an important discourse feature in the fediverse. Supporting both sending quotes and detecting when bot posts have been quoted would enable more sophisticated conversational patterns.

These additions should make #BotKit more capable while maintaining its simple, developer-friendly API. I expect implementation to involve extending the Message class and adding new Text processing capabilities, all while keeping backward compatibility with existing bots. Having built both Hollo and Hackers' Pub, I already have deep familiarity with how various ActivityPub implementations handle these features across the fediverse. I welcome any community feedback on priorities or implementation details before I begin coding.

#fedidev

#mood

리누스 토발즈의 ‘깃(Git)’ 20주년 소회 “별일 아니었다”

byline.network/2025/04/17-440

“나는 그냥 내게 필요해서 ‘깃’을 만들었다. 만들고 4개월만에 흥미를 잃었다. 20년 중...

ちなみにLinuxではDebian系がamd64、RedHat系がx86_64の表記を好むらしい
Microsoftはx64表記になることが多い
https://onoredekaiketsu.com/x86-64-x64-amd64-what-is-the-difference-between-these/

설정이나 명세를 튜링완전한 언어로 기술하면 안되지 않나, 튜링완전한 언어는 프로그램을 짤때 써야하지 않나란 의견이 있는데, 난 오히려 반대라고 생각한다.

설정/명세를 기술한 코드는 그걸 평가해서 어떤 값을 한번 구하면 끝이고, 임의의 입력에 대해 종료함을 보장할 필요가 없다. 그리고 그 코드의 실행은 서비스 단에서 이루어지는게 아니고, 서비스를 만들고 운영하는 과정에서 이루어지기 때문에 종료되지 않는것에 대해 훨씬 안전하다.

반대로, 실제로 돌아가는 프로그램(말이 좀 이상하지만 excuse부탁드림)이야말로 튜링완전한 언어로 짜면 안된다. 우리가 튜링완전한 언어로 개발하는 이유는 우리가 만드는 프로그램을 기술하는데 필요한 자유도가 얼만큼인지 모르고 작업해야하기 때문에 그렇다. 종료하지않는 엉터리 코드를 짤 가능성을 받아들이면서도, 당장 뭔가 만들긴해야하니까 그런 선택을 하는 것이다.

즉 튜링완전성은 메타프로그래밍을 할때만 허용되는것이 (적어도 이론적으론) 정당하다고 생각한다.

RE: https://hackers.pub/@bgl/019647a2-cd0c-7311-97ce-95b59e5a0696

패스키 쓴 이후 나의 해커펍생 달라졌다-

로그인 자체도 안 풀리고 바로 들어오면 된당 며칠 써보니 매우 편하다

あ、あと。来週頭に公開予定の「しゅいろ」さんのMisskey連載もあるよ。 https://gihyo.jp/list/group/Misskey-Webテクノロジー最前線#rt:/article/2023/02/misskey-01 日本語で申し訳ないけど🙏 @hongminhee洪 民憙 (Hong Minhee)

내가 무슨 쿠버네티스를 쓰고 멀티 AZ 분산을 하고 로드밸런서를 붙이고 수평확장을 하고 매니지드디비를 쓰면 뭐하냐

클라우드프로바이더가 네트워크를 날려먹는데!!!!!!!!!! 아니 그러고도 그걸 감지를 못 해서 내가 티켓을 보낼 때 까지도 모르고 심지어 보낸 직후에도 모르고 몇 번 핑퐁을 해서야 상황파악하고 그 이후로도 해결에 4시간 걸린거 실화냐????????????

Mastodonとかは`content`と`contentMap`に同一の内容を入れていて、この場合は圧縮が効きやすいだろうとはいえ、やはりもう少しどうにかならなかったのかとは思ってしまう

`contentMap`タームについては、例えば日本語で1万文字程度の記事を7言語くらいに訳し分けるとして、本当にそれらを全て単一のオブジェクトに突っ込みたいのか？　という感想がある

가장 선호하는 JetBrains IDE가 AI 시대에 뒤쳐지고 있어서 안타까웠는데 AI assistant 와 Junie 업데이트로 이제 좀 쓸만해진 것 같다.

여전히 부족한 점이 많기는 하다.
Agent는 느리고, 현재 상태에 대한 가시성이 없어 계속 기다려야할지 중단하고 새로운 세션을 열어야 할지에 대한 판단이 안선다.

prompt를 별도 관리할 수 있게 한 점은 훌륭하나 포맷이나 디렉토리를 유저가 선택할 수 있게 했더라면 더욱 유용했을 것이다. 나는 prompt가 다른 에이전트와 공유 가능하길 원한다.

vscode copilot처럼 Claude로부터 mcp 서버 설정을 불러올 수 있다. 하지만 역시 현재 상태 가시성이 없어 제대로 mcp 서버와 인터랙션이 되고 있는지 확인하기 어렵다.

그럼에도 불구하고 Cursor 나 Copilot에 충분히 대항할만한 업데이트라 생각한다. 앞으로를 응원한다!
https://www.jetbrains.com/ko-kr/junie/

同じ理由でfedify lookup -a https://www.threads.net/@usernameコマンドで正常に照会が出来ない。一方fedify lookup -a @username@threads.netコマンドは正常に動作。

ThreadsのアカウントがMisskey系からの検索がめちゃくちゃ難しいの、もしかしてアカウントのページ（https://www.threads.net/@アカウント）にtype="application/activity+json"なJSONファイルを用意していないから？

例えばこのアカウントだとhttps://c.osumiakari.jp/@oageoというページには<link rel="alternate" href="https://c.osumiakari.jp/users/9go1hrsqih" type="application/activity+json">が入っており、https://c.osumiakari.jp/@oageoを貼り付けるだけで外からでも簡単にアカウントの参照が出来るようになっている（はず）

Mastodonとかでも同様なんだけどThreadsには無さそう

Pleromaにも無いんだけど、Pleromaの場合は表示されているインスタンスのアドレス/user/ユーザー名でよしなに解決されるから問題ない。しかしThreadsにおいてはhttps://threads.net/ap/users/数字なので、解決されなさそう

어제 출시된 o3가 코딩스타일은 별론데 디버깅을 매우 잘한다고 한다.

위 계정은 HVM 만드는 사람의 것인데, 나는 새 모델이 나올때마다 저 사람이 하는 벤치마크를 체크한다. 사실 구체적으로 뭐하는지는 잘 모르는데,

1. 충분히 어려운 과제로 테스트한다는 점
2. 진짜로 자기가 할일을 대체할수 있는지 확인할만큼 밀어붙인다는점
3. 결과를 세세하게 공유한다는 점

에서 참고할만하다.

오늘의 오픈소스 기여. Yarn은 참 잘 만든 소트웨어인 것 같다. 엉망진창인 자바스크립트 생태계를 공격적으로 수정해왔다는 점에서 정말 대단한데... 근데 그 생태계가 자정할수록 맞지 않는 부분이 계속 생기는 듯. https://github.com/toss/yarn-plugin-catalogs/pull/6

JetBrains IDE도 AI 적용 : 코딩 에이전트, 똑똑한 보조, 무료 티어 포함
------------------------------
- JetBrains는 *AI Assistant와 코딩 에이전트 Junie* 를 포함한 모든 AI 도구를 *하나의 구독 시스템* 에 통합하고 *무료 요금제(AI Free tier)* 를 제공함
- Junie는 *Anthropic Claude, OpenAI 모델 기반의 강력한 AI 코딩 파트너* 로, JetBrains IDE 사용자 모두에게 공개됨
- 새롭게 개선된 AI Assistant는…
------------------------------
https://news.hada.io/topic?id=20377&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

openai에서 코딩할때 도움주는 cli 를 만들었어요. 이름이 codex임당. claude code랑 같은 컨셉인데... 누가누가 잘하나 한번 써봐야겠어요. https://github.com/openai/codex

와! 해커스펍! 모바일 글쓰기 프리뷰 기능!

Sockets connect machines; files connect processes; TVars connect threads.^[1]

#556 - fep-044f: Switch from FEP-e232 object links to bespoke `quote` and `quoteAuthorization` attributes - fediverse/fep - Codeberg.org
https://codeberg.org/fediverse/fep/pulls/556

reflex-frp 등 FRP 라이브러리들을 쓰면서 배운점은, fire-and-forget이 유용한 패턴이고 많은 코드를 fire-and-forget 방식으로 짤수있음에도 우리는 평소에 그걸 포착하지 못하고 fire-and-remember(but don't use after?) 방식으로 짜고 있다는 것이다. 그리고 더 중요한건, fire-and-forget를 primitive로 삼기에는 fire-and-forget이 안 통하는 순간에 곤란한 점이 많다는 것이다. 그래서 actor 'framework'란 접근에 대해서는 흐린눈을 하고 보게된다.

CVE가 2025년 4월 16일부터 종료된다고 합니다. https://www.csoonline.com/article/3963190/cve-program-faces-swift-end-after-dhs-fails-to-renew-contract-leaving-security-flaw-tracking-in-limbo.html

해커즈 퍼브의 favicon 이야기가 나왔을 때 잠깐 생각나는 대로 대충 낙서해 본 것이 있습니다. (말 그대로 대충 낙서입니다. 이대로 쓰자는 뜻은 아닙니다. 너무 진지하게 받아들이지는 마시고, 브레인스토밍 정도로 생각해 주시길...)

• 퍼브 간판의 일반적인 형상을 가져왔습니다.
• 마실 것을 파는 장소의 간판 같은 느낌을 유지하면서, 정확히 어떤 음료인지는 의도적으로 알 수 없게 했습니다. ("퍼브"는 맥주를 주력으로 하는 장소라는 인식이 있는 것 같습니다만, 법적·의료적·종교적 여러 가지 이유로 알코올을 음용할 수 없는 사람들이 세상에는 아주 많기 때문에, 일부러 "맥주"의 이미지를 배제했습니다. 해커즈 퍼브는 술 안/못 마시는 사람도 편하게 올 수 있는 장소가 되는 것이, 행동 강령의 취지에도 부합한다는 생각이었습니다.)
• 간판 부분은 잘 보시면 "퍼브"라는 한글 표기에서 "ㅍ"와 "ㅂ"를 담고 있습니다. 가로대와 간판이 이어지는 부분이 "ㅍ"의 형상이고, 물잔이 "ㅂ"의 형상입니다. 물론 해커즈 퍼브는 한국어 전용 커뮤니티도 아니고 한글 전용 커뮤니티는 더더욱 아닙니다. 한글이 꼭 들어가야 할 이유는 없습니다. 하지만 반대로 한글을 안 쓸 이유도 없지 않은가? 뭔가를 모티브로 쓰긴 써야 하는데 그게 한글일 수도 있는 것 아닌가? 그래서 넣어 봤습니다. 😅
• "Hacker's Pub"를 구성하는 글자들을 그대로 집어넣는 것을 일부러 피했습니다. 우선, 아이콘은 "Hackers' Pub"이라는 텍스트와 병치될 가능성이 높은데, 그렇다면 "H"나 "P"가 들어 있는 것은 중복이 되고 정보 전달의 낭비가 됩니다. 그리고, favicon 으로 쓰일 가능성이 높은데, 다른 사이트들에도 알파벳을 형상화한 아이콘이 많습니다. 추상적 형상으로서 다른 아이콘들과 겹칠 여지가 적을수록 식별자로서의 기능과 효용이 극대화될 것이라는 생각이었습니다. (물론, 엄밀히 따지면, 이 아이콘도 전체 형상에는 알파벳 "h"의 구조가 숨어 있고, 그것을 의도하긴 했습니다만, 가장 먼저 눈에 들어오는 특징은 아니죠.)

여태 모나드 가르칠때 그냥 do notation부터 알려주고 알아서 써보라고했는데 절반정도는 잘 따라왔다. 문법적으로 <-를 넣어야할 위치만 아는 상태에서도 코드를 웬만큼 짰다. 즉, next token prediction은 휴먼에게도 좋은 학습 방법이다.

RE: https://hackers.pub/@xt/01963d1e-e20c-77c5-a395-69c592137fb3

다들 모나드 괴담을 한번씩 보셔야합니다

DAG 꾸미기: 패키지 매니저의 디펜던시 그래프에서 쓸데없는 패키지를 정리하는 행위

저도 두 가지 쟁점 모두 동의하는 편입니다. 그리고, 별개의 이야기입니다만, $ 를 가르칠 때에는 그냥 문법이라고 가르치는 게 학습자의 이해와 응용이 압도적으로 빠르고 좋았습니다.

"이건 여기서부터 뒤로는 다 괄호로 감싸겠다는 뜻이라고 생각하세요."

이러면 한 방에 설명이 끝나고, 필요성이나 편리성에 대해서도 알아서들 납득하는 것이죠. 연산자 우선순위나 좌결합 우결합 등은 그게 되고 나서 얘기하고요. 그러면 "아, 이게 그래서 이렇게 되는 거였군요?" 하면서, 훨씬 쉽게 이해합니다. 이걸 거꾸로 좌결합 우결합 어쩌고부터 가르치려고 하면 다들 꾸벅꾸벅 졸아요... ㅋㅋ ㅠㅠ

(결국 "모나드란 무엇인가"부터 배우면/가르치면 안 된다는 주장과 같은 맥락입니다.)

RE: https://hackers.pub/@bgl/01963c3b-98fa-7432-a62f-0d2dfc0691bf

@xtjuxtapose https://xtendo.org/ko/monad 아주 멋진 자료군요

feedly를 잘 쓰고 있지만 ghost pro의 activityPub 인터그레이션 사용 감각도 괜찮아서, 이걸 충분히 많은 블로그와 웹툰(xkcd도 rss feed를 발행한다) 등이 적용한다면, 연합우주를 좀 더 적극적으로 쓸 수도 있을 것 같다.

앞으로 이런 글을 찌끄릴려구요. 기고도 환영입니다.

https://a11ykr.github.io/stories/accessibility-is-important/

@hongminhee洪 民憙 (Hong Minhee) @curry박준규 저도 Lisp을 첨에 봤을땐 감탄했는데요. 지금 보면 그냥 파서짜기 싫었나보다 정도의 생각이 듭니다ㅋㅋ

하스켈에서 $가 infix operator가 아니라 문법 요소여야 한다는 얘기에는 동의하는 사람들이 꽤 있다. 근데 1 + $ 2 + 3도 1 + (2 + 3)으로 변환되어야 한다고 하면 다들 싫어한다ㅋㅋ 근데 나는 저것도 좋다고 본다.

하스켈 언어 서버HLS 2.10.0.0에 go to implementation 기능이 생겼네요. .cabal 파일 지원도 많이 들어갔다 합니다.

RN에 새 런타임이 옛날거보다 오히려 느리다는 이슈를 제보했는데, 솔직히 좀 황당하다. 그냥 대기업이 오픈 소스 메인테인을 못한다...는 아니다. 난 단순히 잡버그/미구현기능 많은거는 망치가 부족한가보다 정도로 이해한다.

근데 요 이슈는 RN 메인테이너 쪽에서 지난 1+년간 새 런타임으로의 마이그레이션을 적극적으로 권유했는데, 이런 기본적인 문제가 파악안되고 있었던거면 흠... 저 정도 규모의 프로젝트를 운영하는게 어떤지 잘 몰라서 뭔가 더이상 말을 얹기는 어렵겠지만, 쨋든 설명이 더 필요하다 느낀다.

@ailrunAilrun (UTC-5/-4) @lionhairdino @kodingwarriorJaeyeol Lee @bglbgl gwyng 지나가다 보고 아이디어가 넘 좋아서 살포시...