예전 일이지만, Windows CI장비에서 수상하게도 git 작업이 타임아웃이 나는 문제가 있었다. 장비에 접속해서 확인해보니 false.exe가 영-원히 켜져 있는 상태로 멈춰 있었바. 아니... 그냥 exit code 설정하고 끝나는 프로그램이 왜...

대충 그동안의 경험으로 서버 장비라고 안그래도 gnu 싫어하는 백신이 더 심하게 하는가보다 싶었고, https://github.com/uutils/coreutils 에서 false를 빌드해다가 갈아치우니까 문제가 완전히 사라졌다.

진짜 뭐가 맘에 안들어서 그러는지 모르겠다...

시작되었다... 오퍼레이션 지옥이...

고장난 테스트를 다 고쳤다. 하지만 CI에서 돌리기는 요원한데... 독점 소프트웨어 + GUI의 지옥의 콜라보... 분명 cli를 지원하는데 cli에서 GUI를 통해 실행되는 명령을 똑같이 실행해도 에러가 난단 말이지...

The federated and networked oekaki board, Oeee Cafe, now support emoji reactions from the fediverse! You also get notifications from the fediverse as well.

This made me very nostalgic. Travis CI was one of those truly industry changing things. It was one of those moments where the before state of running your own Jenkins instance to have some CI for your projects suddenly just felt wildly silly

https://mastodon.social/@bagder/115387989401380555

On this day twelve years ago, in 2013, #curl got its first ever CI jobs. On Travis CI.

Before that we only ran post-merge tests on a set of volunteers' machines.

Today, we have around 230 separate CI jobs and we have tripled the number of test cases since then.

아주 조악하긴 하지만 순수 C# 기반의 VNC 서버 초기 구현체를 만들어봤습니다. VNC 서버가 멀쩡히 있는데 왜 또 만들었냐하면, 대개 VNC 서버들이 GPL 라이선스나 상용 라이선스인 경우가 많아서 불만이었기 때문이었습니다.

Github Copilot + Anthropic Claude 4.5 + Visual Studio 2026으로 개발을 진행해봤습니다. 대개 VNC 서버들이 GPL 라이선스를 쓰고 있어서, 라이선스 전염같은 독소 조항이 없는 안전한 구현체도 필요하지 않겠는가 생각하여 1.5일 정도만에 뽑아내어본 결과물입니다.

추가로 이번에 작업해보면서 Code가 아닌 정식 IDE 기반으로 AI 코드 어시스턴트를 효과적으로 활용하기 위한 사용법도 몇 가지 알게 된 것이 있습니다.

AI 코드 어시스턴트에게 stdout이나 stderr이 아닌 다른 채널 (System.Diagnostics)에 로그를 남기도록 지시하고, 그 로그만 따로 모아서 발생하는 문제에 대한 트러블슈팅을 부탁하는 식으로 VNC와 RDP의 복잡한 내부 구현을 다듬어가면서 완성할 수 있었습니다.

매우 실험적인 과정이었지만, 의외로 꽤 괜찮은 결과물이 나와서 공유해봅니다! 기회가 되면 계속 발전시켜보도록 하겠습니다.

https://forum.dotnetdev.kr/t/github-copilot-vs-2026-1-5-c-vnc/13886

제 집필서 표지가 나왔어요. 설레네요. 두근두근.

연합우주 소프트웨어(#cosmoslide)에 기여를 하고 있는데, fedify를 쓰는데 인메모리 큐를 쓰고 있는 게 조금 신경쓰인다...

My GitHub notifications now look like this every few days 😅

Random bots keep creating repos (not forked) and one of the commits mention me.

Original repo and commit here: https://github.com/matiassingers/awesome-readme/commit/4130eb071cf649d2c1c2b3451aae5baa3a119d17 (Jan 2015) — I don't remember why I was mentioned 🤷‍♂️

No way to block/mute. I can't bother to report every single account and repo.

Threads에서 연합우주 글을 재공유(repost)할 수 있는 날이 온다면, 그것도 그거대로 특이점이 될 것 같음. "Threads에서 구독이 가능한 블로그 서비스"

아무도 도전하지 않는다면, 1분기에 Hackers Pub 안드로이드 앱 만드는걸 도전해봐야겠다. 플레이스토어는 모르겠고, F-droid 마켓에는 올려보는 경험을 해보고 싶음...!!

게임을 하든 프로그램을 설치하든 무조건 설정부터 건드리는 사람

p.s. 현재 한국어 IME 이슈가 있어서 제보해둔 상태 https://github.com/zed-industries/zed/issues/40335

와우 코딩테스트 mock interview 했는데 개털림 ㅋㅋㅋ 심지어 풀었던 건데 못 풀고 난리도 아니었음...1) 누군가 내가 코드하는 걸 보고 있다 2) 그 코드하는 걸 내가 설명해야한다 3) 시간 제한이 있다 4) 여러가지 티키타카하면서 주고 받아야한다 이 4가지가 한꺼번에 팍 오니깐 와우 가장 기본적인 것들도 어버버버 하고 패닉와서 나 왤케 멍청하지 하면서 그냥 별 생각없이 풀 때랑은 차원이 다르다는 걸 깨달았습니다..

Zed의 윈도 버전이 드디어 공식 출시되었다. https://zed.dev/blog/zed-for-windows-is-here

공식 버전 출시 전까지는 deevus/zed-windows-builds 저장소 것을 쓰고 있었는데, 2주 전부터 베타 신청한 사람들에게 클로즈 베타를 쓸 수 있도록 링크를 보내주더니 드디어 정식 출시가 되었다. Private alpha 때부터 가벼운 반응 빠른 텍스트 에디터로, 또 개인 프로젝트용으로 잘 사용하고 있던 터라 감개가 무량하다.

Rust로 만들어져 윈도에서도 가볍고 빠릿빠릿하며, LLM 에이전트나 WSL 지원도 물론 완벽히 잘 된다!

이제 arm64 윈도용 빌드도 내 줬으면 🥺

한국의 함수형 프로그래밍 컨퍼런스 LiftIO 2025가 슬슬 열린다고 한다.

• liftIO 2025 연사 신청 링크: (https://forms.gle/RsmowMdtNxH1Pchc6)
• 컨퍼런스 신청 링크(https://event-us.kr/liftioconf/event/114005)

函數型(함수형) 프로그래밍 컨퍼런스인 liftIO 2025에 參加(참가) 申請(신청)했다. Optique로 發表(발표)하려고 演士(연사)도 申請(신청)했는데 될지 모르겠네…

https://github.com/malkoG/malkoG/blob/master/resume.typ

여러분도 typst 쓰세요. 저처럼 이력서 깔끔하게 뽑힘... 소스코드로 버전관리도 가능하고, LLM이 또 코드를 기막히게 잘 말아줌...

SSH.NET은 SSH 연결과 명령어 송수신을 닷넷에서 프로그래밍 방식으로 처리할 수 있도록 도와주는 라이브러리로, 이 라이브러리를 이용하면 리눅스 명령어 사용을 코드 레벨로 가져와서 프로그래밍할 수 있습니다.

예를 들어 특정 컨테이너의 상세 정보를 docker inspect 명령으로 조회하는 것으로, docker inspect의 출력 자체가 JSON으로 들어오기 때문에 이것을 곧바로 System.Text.Json의 JsonDocument로 받을 수 있다는 것입니다.

https://forum.dotnetdev.kr/t/ssh-net/13882

이력서 완성했다...!! https://github.com/malkoG/malkoG/blob/master/resume.pdf

요새 코딩을 잘 못하구 간간히 리트코드나 풀고 있는데,

• 리트코드를 웹에서 풀다가 불편해서
• 리트코드를 로컬에서 편하게 풀고 싶어서 emacs 플러그인을 짜는데
• emacs 플러그인을 편하게 짜고 싶어서 emacs 테스트 플러그인을 짜는 중...

https://github.com/nyeong/org-test/

그 소프트웨어를 사용할 권리를 먼저 줘야하는거 아닙니까

한글과 컴퓨터로 졸논을 왜 작성해야합니까?

So, these days, I'm always trying to find and follow the conf.d tradition. The rationale of this tradition looks like:

• /etc/somepackage/somepackage.conf is where the default configuration is.
• /etc/somepackage/conf.d/ is where the overrides are; this is where you put your user conf.

Normally somepackage.conf is managed by the package manager. When the package gets upgraded (shipping a new version of somepackage.conf), and there are local changes, the package manager will ask you: To overwrite with the maintainer's version or to keep yours.

This question is often difficult to answer, especially if you can't, for the life of you, remember what the heck that package is about. Even "show diff" sometimes fails to help. You have to resort to searching.

Keeping your confs under conf.d helps you avoid this altogether. It also helps you separate them, selectively include/exclude some of them to a system, and prioritize them (the 00-my.conf and 99-my.conf pattern).

But that makes me wonder: If all of my user conf will stay inside conf.d, why bother? Why have /etc/somepackage/somepackage.conf at all? Why is it under /etc anyway? Legacy. /etc/resolv.conf is the first example to come to mind. Different apps fight over the control of this file, so sometimes you encounter advice like sudo chattr +i to prevent any change. Absurd, but it works!

So today I briefly wondered if there's any ongoing effort or a new clever solution to address this. Well, there's NixOS which nullifies quite a bit of my point. I've always liked its idea since like 15 years ago. But is there anything else, anything new, for my existing (less exciting) systems?

…I asked ChatGPT 5-Thinking about this, and its answer was mostly expected. The only thing that amused me was the discovery of etckeeper. OK that looks interesting.

Hashnode 게시글을 불러오는 API를 기반으로 자기만의 정적 사이트 생성기 템플릿 굽는 분들이 계시길래, Hackers Pub도 이런게 되어야 하지 않나 싶었다. 실제로 graphql API를 까봤는데, 이론상으로 불가능하지는 않아서 도즈언 했는데 생각보다 잘 나온다..... Astro에다가 Hashnode API 연결한 예시를 베이스로 해서, hackerspub 버전으로 바꿔달라고 claude code한테 프롬프트 넣어줬더니 진짜 그냥 해줌.

자동으로 돌아가지 않는 테스트 코드는 역시 끔찍하다

Quick update on our release schedule! While we initially planned for Fedify 2.0 to follow version 1.9, we've decided to release Fedify 1.10 next instead. A few features originally slated for 1.9 need more time to mature, and we want to ensure Fedify 2.0 gets the careful attention it deserves for its breaking changes. This means you'll get incremental improvements sooner with 1.10—including our new RFC 6570 URI Template implementation for better expansion and pattern matching—while we continue preparing the more substantial architectural changes for 2.0 in parallel. Rest assured, this doesn't change our long-term roadmap; it just gives us more flexibility to deliver features when they're ready rather than holding them back for a major release.

emacs 개발자들은 LLM 시대에 빛을볼 중요한 선견지명을 가지고 있었는데

1. 텍스트 에디터는 범용 인터페이스다(반 OS가 되어버린 emacs)
2. RAG할 지식데이터베이스를 만들고 관리할수 있어야한다(org-mode).

근데 이걸 알고도 한푼도 못벌었다ㅋㅋㅋ 열매는 cursor와 notion에게로...

I currently making requets-based synchronous ActivityPub client for apkit...

Ok? I did a lot haha. Ive been focusing on this Sep and last days of Oct, as a consequence, the midterm and lots assignments await me?

Fedify 1.9.0: Security enhancements, improved DX, and expanded framework support

We are excited to announce Fedify 1.9.0, a mega release that brings major security enhancements, improved developer experience, and expanded framework support. Released on October 14, 2025, this version represents months of collaborative effort, particularly from the participants of Korea's OSSCA (Open Source Contribution Academy).

This release would not have been possible without the dedicated contributions from OSSCA participants: Jiwon Kwon (@z9mb1wwj), Hyeonseo Kim (@gaebalgom개발곰), Chanhaeng Lee (@2chanhaeng초무), Hyunchae Kim (@r4bb1t톡기), and An Subin (@nyeongAn Nyeong (安寧)). Their collective efforts have significantly enhanced Fedify's capabilities and made it more robust for the fediverse community.

Origin-based security model

Fedify 1.9.0 implements FEP-fe34, an origin-based security model that protects against content spoofing attacks and ensures secure federation practices. This critical security enhancement enforces same-origin policy for ActivityPub objects and their properties, preventing malicious actors from impersonating content from other servers.

The security model introduces a crossOrigin option in Activity Vocabulary property accessors (get*() methods) with three security levels:

// Default behavior: logs warning and returns null for cross-origin content
const actor = await activity.getActor({ crossOrigin: "ignore" });

// Strict mode: throws error for cross-origin content
const object = await activity.getObject({ crossOrigin: "throw" });

// Trust mode: bypasses security checks (use with caution)
const attachment = await note.getAttachment({ crossOrigin: "trust" });

Embedded objects are automatically validated against their parent object's origin. When an embedded object has a different origin, Fedify performs automatic remote fetches to ensure content integrity. This transparent security layer protects your application without requiring significant code changes.

For more details about the security model and its implications, see the origin-based security model documentation.

Enhanced activity idempotency

Activity idempotency handling has been significantly improved with the new withIdempotency() method. This addresses a critical issue where activities with the same ID sent to different inboxes were incorrectly deduplicated globally instead of per-inbox.

federation
  .setInboxListeners("/inbox/{identifier}", "/inbox")
  .withIdempotency("per-inbox")  // New idempotency strategy
  .on(Follow, async (ctx, follow) => {
    // Each inbox processes activities independently
  });

The available strategies are:

• "per-origin": Current default for backward compatibility
• "per-inbox": Recommended strategy (will become default in Fedify 2.0)
• Custom strategy function for advanced use cases

This enhancement ensures that shared inbox implementations work correctly while preventing duplicate processing within individual inboxes. For more information, see the activity idempotency documentation.

Relative URL resolution

Fedify now intelligently handles ActivityPub objects containing relative URLs, automatically resolving them by inferring the base URL from the object's @id or document URL. This improvement significantly enhances interoperability with ActivityPub servers that use relative URLs in properties like icon.url and image.url.

// Previously required manual baseUrl specification
const actor = await Actor.fromJsonLd(jsonLd, { baseUrl: new URL("https://example.com") });

// Now automatically infers base URL from object's @id
const actor = await Actor.fromJsonLd(jsonLd);

This change, contributed by Jiwon Kwon (@z9mb1wwj), eliminates a common source of federation failures when encountering relative URLs from other servers.

Full RFC 6570 URI template support

TypeScript support now covers all RFC 6570 URI Template expression types in dispatcher path parameters. While the runtime already supported these expressions, TypeScript types previously only recognized simple string expansion.

// Now fully supported in TypeScript
federation.setActorDispatcher("/{+identifier}", async (ctx, identifier) => {
  // Reserved string expansion — recommended for URI identifiers
});

The complete set of supported expression types includes:

• {identifier}: Simple string expansion
• {+identifier}: Reserved string expansion (recommended for URIs)
• {#identifier}: Fragment expansion
• {.identifier}: Label expansion
• {/identifier}: Path segments
• {;identifier}: Path-style parameters
• {?identifier}: Query component
• {&identifier}: Query continuation

This was contributed by Jiwon Kwon (@z9mb1wwj). For comprehensive information about URI templates, see the URI template documentation.

WebFinger customization

Fedify now supports customizing WebFinger responses through the new setWebFingerLinksDispatcher() method, addressing a long-standing community request:

federation.setWebFingerLinksDispatcher(async (ctx, actor) => {
  return [
    {
      rel: "http://webfinger.net/rel/profile-page",
      type: "text/html",
      href: actor.url?.href,
    },
    {
      rel: "http://ostatus.org/schema/1.0/subscribe",
      template: "https://example.com/follow?uri={uri}",
    },
  ];
});

This feature was contributed by Hyeonseo Kim (@gaebalgom개발곰), and enables applications to add custom links to WebFinger responses, improving compatibility with various fediverse implementations. Learn more in the WebFinger customization documentation.

New integration packages

Fastify support

Fedify now officially supports Fastify through the new @fedify/fastify package:

import Fastify from "fastify";
import { fedifyPlugin } from "@fedify/fastify";

const fastify = Fastify({ logger: true });
await fastify.register(fedifyPlugin, {
  federation,
  contextDataFactory: () => ({ /* your context data */ }),
});

This integration was contributed by An Subin (@nyeongAn Nyeong (安寧)). It supports both ESM and CommonJS, making it accessible to all Node.js projects. See the Fastify integration guide for details.

Koa support

Koa applications can now integrate Fedify through the @fedify/koa package:

import Koa from "koa";
import { createMiddleware } from "@fedify/koa";

const app = new Koa();
app.use(createMiddleware(federation, (ctx) => ({
  user: ctx.state.user,
  // Pass Koa context data to Fedify
})));

The integration supports both Koa v2.x and v3.x. Learn more in the Koa integration documentation.

Next.js integration

The new @fedify/next package brings first-class Next.js support to Fedify:

// app/api/ap/[...path]/route.ts
import { federation } from "@/federation";
import { fedifyHandler } from "@fedify/next";

export const { GET, POST } = fedifyHandler(federation);

This integration was contributed by Chanhaeng Lee (@2chanhaeng초무). It works seamlessly with Next.js App Router. Check out the Next.js integration guide for complete setup instructions.

CommonJS support

All npm packages now support both ESM and CommonJS module formats, resolving compatibility issues with various Node.js applications and eliminating the need for the experimental --experimental-require-module flag. This particularly benefits NestJS users and other CommonJS-based applications.

FEP-5711 collection inverse properties

Fedify now implements FEP-5711, adding inverse properties to collections that provide essential context about collection ownership:

const collection = new Collection({
  likesOf: note,  // This collection contains likes of this note
  followersOf: actor,  // This collection contains followers of this actor
  // … and more inverse properties
});

This feature was contributed by Jiwon Kwon (@z9mb1wwj). The complete set of inverse properties includes likesOf, sharesOf, repliesOf, inboxOf, outboxOf, followersOf, followingOf, and likedOf. These properties improve data consistency and enable better interoperability across the fediverse.

CLI enhancements

NodeInfo visualization

The new fedify nodeinfo command provides a visual way to explore NodeInfo data from fediverse instances. This replaces the deprecated fedify node command and offers improved parsing of non-semantic version strings. Try it with:

fedify nodeinfo https://comam.es/snac/

This was contributed by Hyeonseo Kim (@gaebalgom개발곰). The command now correctly handles various version formats and provides a cleaner visualization of instance capabilities. See the CLI documentation for more options.

Enhanced lookup with timeout

The fedify lookup command now supports a timeout option to prevent hanging on slow or unresponsive servers:

fedify lookup --timeout 10 https://example.com/users/alice

This enhancement, contributed by Hyunchae Kim (@r4bb1t톡기), ensures reliable operation even when dealing with problematic remote servers.

Package modularization

Several modules have been separated into dedicated packages to improve modularity and reduce bundle sizes. While the old import paths remain for backward compatibility, we recommend migrating to the new packages:

• @fedify/cfworkers replaces @fedify/fedify/x/cfworkers
• @fedify/denokv replaces @fedify/fedify/x/denokv
• @fedify/hono replaces @fedify/fedify/x/hono
• @fedify/sveltekit replaces @fedify/fedify/x/sveltekit

This modularization was contributed by Chanhaeng Lee (@2chanhaeng초무). The old import paths are deprecated and will be removed in version 2.0.0.

Acknowledgments

This release represents an extraordinary collaborative effort, particularly from the OSSCA participants who contributed numerous features and improvements. Their dedication and hard work have made Fedify 1.9.0 the most significant release to date.

Special thanks to all contributors who helped shape this release, including those who provided feedback, reported issues, and tested pre-release versions. The fediverse community's support continues to drive Fedify's evolution.

For the complete list of changes, bug fixes, and improvements, please refer to the CHANGES.md file in the repository.

Every time I try to publish a package to #JSR (JavaScript Registry), it frequently gets stuck in the “processing” state, so I'm seriously considering whether I should stop publishing my TypeScript packages there altogether. 🤔

쓰고 있는 스택과 관심 있는 스택

심지어 Children 노드 가질 수 있는 블럭의 children 도 다 그렇게 되어 있음
이건 ㄹㅇ 광기다,,,

Notion 패키지 타입 봤다가 블럭 타입 하나에 모든 경우가 하드 코딩 되어 있는 것을 보고 저는 그만 정신을 잃고 말았습니다

딩코하다가 열 받을 때 나는 가끔 리눅스 커널 소스 코드에 버전별로 주석으로 담긴 욕의 빈도를 정리한 그래프를 보면서 위안을 얻곤 한다 (물론 다른 단어도 볼 수 있음)

Helix, gitui, alacritty는 다 windows배포를 하는데, zellij만 공식 미지원 상태라 빌드도 깨져 있다. Helix는 내부에서 터미널을 지원하지 않기 때문에 zellij를 같이 써야 좋겠는데, 아쉽다.

@hongminhee洪 民憙 (Hong Minhee) @robin microformats2 모양이긴 합니다

content에서 멘션 a의 class를 u-url mention으로 주는건 어딘가에 표준화가 된건가요 아니면 그냥 마스토돈을 따르는건가요???

연휴이후 첫 출근, 한글이름 정렬이 안된다는 오류를 받아서, order by name 을 빼먹었을 리 없다고 생각하면서, 오류를 추적했는데,

• 코드는 당연히 order by 가 적용되어 있었고,

결과적으로 문제는 PostgreSQL에서 한글 ORDER BY 정렬 문제 해결하기 COLLATE 이슈와 동일한 현상이었다.

(내부 docker postgre:17.4 와 AWS RDS PostgreSQL 17.2 모두) 기본값 en_US.UTF-8 이 적용되어 있었고, 한글 정렬순서가 올바르게 나오지 않았다.

SELECT datname, datcollate, datctype
FROM pg_database
WHERE datname = current_database();

|datname |datcollate |datctype   |
|--------|-----------|-----------|
|postgres|en_US.UTF-8|en_US.UTF-8|

ko_KR.UTF-8 로 새 로케일 지정해서 데이터베이스 새로 만들고, 덤프 백업 & 복원처리를 진행해서 해결은 완료했는데, 간단하게 COLLATE "C" 로도 한글정렬문제를 해결 할 수 있겠다 싶었는데, ChatGPT와 이것저것 논의해본 결과(?) 문자코드순 정렬이라서 사전식 정렬과는 다소 차이가 있어서 완전한 해결책은 아닌 듯 싶다. (비슷하게나마 해결은 되지만)

데이터베이스를 새롭게 만드는 게 어려우면, 특정 컬럼에만 COLLATE 를 지정해서 변경할 수 있다.

ALTER TABLE 테이블명
ALTER COLUMN 컬럼명 TYPE 데이터타입 COLLATE "C";

서비스가 아직 한국어와 영어만 지원해서, 별다른 고민없이 ko_KR.UTF-8로 처리하기는 했는데, 일본어나 중국어까지 지원하면 결국 Collation을 C 로 해야하는 것은 아닌가 싶은 생각도 들고, ko_KR.UTF-8에서 일본어,중국어도 다 잘 정렬되지 않을까 싶은 생각도 들고, 혹은 정렬이 중요한 포인트라면 언어별로 컬럼을 파야할 것인가 하는 고민은 있는데, 일단은(?) 나중에 다시 고민하기로 했다.

소스코드 뜯어보고 그 뒤에 담긴 원리 덕질하는 거가 딩코할 때 제일 재밌어

해커스펍에서 글 쓸 때 자동으로 언어감지 하는 거 이거 원리랑 구현이 어떻게 되어있는 거지 신기하다...오 이건가 혹시?

Core function은 tinyld 라이브러리에서 나오는 것 같은데 소스코드 보니깐 엔그램 썼구나...! 그래 맞아 길어봐야 몇 문장일 거고 사실 최초 몇 단어 혹은 몇 자, 그리고 어떤 문자인지에 따라 (CJKV 같은 계열엔 더욱 더 명확할 거임) 바로바로 detection 하면 되는 걸테니 굳이 복잡시리한 거 안 써도 됨...내 최애 언어모델 엔그램 🥹 (다른 건 LSTM 🥹)

이거 프로젝트 여러개 셋업하니까 귀찮아서 리포 하나 만들었습니다.

새 에디터 찾다가 helix 고르고는 zellij, alacritty 까지 쓰고, gitui도 다시 꺼내보고 있돠.

해커스펍을 쓰고 있으면서도 정작 연합우주랑 액티비티펍 프로토콜에 대해선 큰 그림조차 사실 감이 잘 안 왔는데(...) 워드프레스에서 작년에 연합우주랑 액티비티펍 관련해서 영상들을 몇 개 올려서 보고 있는데 한방에 팍 이해가 되어서 재밌게 보고 있다. 액티비티펍 공동창시자인 Evan Prodromou랑 찍은 것도 있는데 왜 액티비티펍을 만들었는지에 대한 동기도 설명해줘서 좋았음..

Hackers' Public이 어떤 모임이었는지 궁금한 분이 계시다면.... 여기 에서 어떤 느낌의 행사인지 알 수 있습니다

11월 중순~11월 말 사이에 해커스펍 오프라인 밋업 Hackers' Public 두번째 모임을 진행하려고 하는데 "눈물없이 듣기 어려운 프론트엔드의 심연" 특집입니다...... 11월 1일~11월 8일 사이에 모집 공고 올릴듯????? 아직은 오피셜한 공지는 아니지만 정보만 슬쩍 흘려봅니다,,,