What is Hackers' Pub?

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.

레몬그린🍋 @starterdroid@serafuku.moe

3/17/2025, 5:02:30 AM

Public

그래도 저 기뻐보이죠? 헤헤

おゆうわちゃん @oyuchi@misskey.io

3/17/2025, 5:00:07 AM

Public

Shared by

（仮）

おいでよ新宝島つくったことある

CORVUSPHERE @CORVUSPHERE@todon.eu

3/17/2025, 5:00:59 AM

Public

In today's picture: Corvus edithae (known as Somali crow). #CORVUSPHERE #CorvusEdithae #SomaliCrow :crow:

Corvus edithae (known as Somali crow) standing on a grassy ground and looking straight ahead.

クロスフォリオ半公式アカウント（修行中） @xfolio@misskey.io

3/17/2025, 3:13:03 AM

Public

Shared by

GENKI

🎉本日、クロスフォリオ専用SNS「Xissmie」をリリースいたしました🎉
Xissmieのリリースにあわせて、クロスフォリオ半公式アカウント（修行中）はioでの修行を終え、Xissmieにて公式アカウントとして活動していきます :blobcat_drawing:

これまでご支援くださった皆様、本当にありがとうございました！
Xissmieは作品保護などの観点から、当面は他のMisskeyサーバーなどとの連合は予定しておりませんので、半公式アカウントのその後の様子を見たい方は、もしよろしければXissmieまで遊びに来てもらえるとうれしいです！

最後になりますが、Xからの作品取り込み祭りの時など、みなさまからいただいたご声援と勇気は一生忘れません。
本当にありがとうございました :ablobcatnodmeltcry:
今後ともクロスフォリオを何卒よろしくお願いいたします！

GENKI @nibushibu@vivaldi.net

3/17/2025, 5:00:35 AM

Public

#クロスフォリオという主にイラスト・マンガの創作者向け（？）のプラットフォームが、 #Misskey をベースにした独自の SNS を公開したとのこと。

自分の #VivaldiSocial からも xissmie.xfolio.jp のドメインのアカウントチラホラ見えるので #Fediverse にも連携しているみたい

https://xfolio.jp/information/335

おゆうわちゃん @oyuchi@misskey.io

3/17/2025, 5:00:07 AM

Public

おいでよ新宝島つくったことある

のえる @noellabo@fedibird.com

3/17/2025, 4:58:46 AM

Public

不具合なおった？

zunda @zundan@mastodon.zunda.ninja

3/17/2025, 4:56:58 AM

Public

ちゃんとした()ハンバーガー食べたくなってきたなあ

たみとほらん🇫🇷 @qns@mastodon.cloud

3/17/2025, 4:18:55 AM

Public

Shared by

zunda

さわやかのハンバーガー、いい

洪民憙 (Hong Minhee) @hongminhee@hollo.social

3/17/2025, 4:54:16 AM

Public

Shared by

박준규

最近(최근) 2年(년) 동안 TypeScript로 서버 開發(개발)을 하면서 Kysely와 Drizzle ORM을 둘 다 써봤는데, 그러면서 經驗(경험)한 것을 土臺(토대)로 둘을 比較(비교)하는 글을 써 보았습니다.

https://hackers.pub/@hongminhee/2025/drizzle-orm-vs-kysely

공백 @Blank@pointless.chat

3/17/2025, 4:55:45 AM

Public

洪民憙 (Hong Minhee) @hongminhee@hollo.social

3/17/2025, 4:54:16 AM

Public

https://hackers.pub/@hongminhee/2025/drizzle-orm-vs-kysely

洪民憙 (Hong Minhee) shared the below article:

애플리케이션 개발 측면에서 본 Drizzle ORM 대 Kysely 비교

洪民憙 (Hong Minhee) @hongminhee@hackers.pub

TypeScript로 백엔드 서버를 개발하면서 적절한 ORM 선택은 항상 중요한 결정 중 하나입니다. 최근 제 프로젝트에서 Drizzle ORM과 Kysely를 모두 사용해 볼 기회가 있었는데, 개인적으로는 Drizzle ORM이 더 편리하고 생산성이 높았던 경험을 공유하고자 합니다.

두 ORM에 대한 간략한 소개

Drizzle ORM은 TypeScript용 ORM으로, 타입 안전성과 직관적인 API를 강점으로 내세우고 있습니다. 스키마 정의부터 마이그레이션, 쿼리 빌더까지 풀스택 개발 경험을 제공합니다.

Kysely는 “타입 안전한 SQL 쿼리 빌더”로 자신을 소개하며, 타입스크립트의 타입 시스템을 활용해 쿼리 작성 시 타입 안전성을 보장합니다.

두 도구 모두 훌륭하지만, 제 개발 경험에 비추어 볼 때 Drizzle ORM이 몇 가지 측면에서 더 편리했습니다.

Drizzle ORM을 선호하게 된 이유

스키마 정의의 직관성

Drizzle ORM의 스키마 정의 방식은 매우 직관적이고 선언적입니다:

import { pgTable, serial, text, integer } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: serial('id').primaryKey(),
  name: text('name').notNull(),
  email: text('email').unique().notNull(),
  age: integer('age')
});

Drizzle ORM은 이 스키마 정의로부터 자동으로 CREATE TABLE SQL을 생성할 수 있어, 스키마와 코드가 항상 동기화되어 있습니다.

반면 Kysely는 타입 정의에 더 중점을 두고 있어 스키마와 타입 정의가 분리되는 경향이 있습니다:

interface Database {
  users: {
    id: Generated<number>;
    name: string;
    email: string;
    age: number | null;
  };
}

이 타입 정의는 TypeScript 코드에서 타입 안전성을 제공하지만, 이 타입 정의만으로는 CREATE TABLE SQL을 생성할 수 없다는 것이 결정적인 단점입니다. 실제로 테이블을 생성하려면 별도의 SQL 스크립트나 마이그레이션 코드를 작성해야 합니다. 이는 타입과 실제 데이터베이스 스키마 간의 불일치 가능성을 높입니다.

Drizzle의 접근 방식이 데이터베이스 스키마와 TypeScript 타입을 더 긴밀하게 연결해주어 개발 과정에서 혼란을 줄여주었습니다.

마이그레이션 경험

Drizzle ORM의 마이그레이션 도구(drizzle-kit)는 정말 인상적이었습니다. 스키마 변경사항을 자동으로 감지하고 SQL 마이그레이션 파일을 생성해주는 기능이 개발 워크플로우를 크게 개선했습니다:

npx drizzle-kit generate:pg

이 명령어 하나로 스키마 변경사항에 대한 마이그레이션 파일이 생성되며, 이를 검토하고 적용하는 과정이 매우 간단했습니다.

반면 Kysely의 마이그레이션은 본질적으로 수동적입니다. 개발자가 직접 마이그레이션 파일을 작성해야 하며, 스키마 변경사항을 자동으로 감지하거나 SQL을 생성해주는 기능이 없습니다:

// Kysely의 마이그레이션 예시
async function up(db: Kysely<any>): Promise<void> {
  await db.schema
    .createTable('users')
    .addColumn('id', 'serial', (col) => col.primaryKey())
    .addColumn('name', 'text', (col) => col.notNull())
    .addColumn('email', 'text', (col) => col.unique().notNull())
    .addColumn('age', 'integer')
    .execute();
}

async function down(db: Kysely<any>): Promise<void> {
  await db.schema.dropTable('users').execute();
}

이러한 수동 방식은 복잡한 스키마 변경에서 실수할 가능성이 높아지고, 특히 큰 프로젝트에서는 작업량이 상당히 증가할 수 있었습니다.

하지만 Kysely의 마이그레이션에도 두 가지 중요한 장점이 있습니다:

TypeScript 기반 마이그레이션: Kysely의 마이그레이션 스크립트는 TypeScript로 작성되기 때문에, 마이그레이션 로직에 애플리케이션 로직을 통합할 수 있습니다. 예를 들어, S3와 같은 오브젝트 스토리지의 데이터도 함께 마이그레이트하는 복잡한 시나리오를 구현할 수 있습니다. 반면 Drizzle ORM은 SQL 기반 마이그레이션이므로 이러한 통합이 불가능합니다.
양방향 마이그레이션: Kysely는 up과 down 함수를 모두 정의하여 업그레이드와 다운그레이드를 모두 지원합니다. 이는 특히 팀 협업 환경에서 중요한데, 다른 개발자의 변경사항과 충돌이 발생할 경우 롤백이 필요할 수 있기 때문입니다. Drizzle ORM은 현재 업그레이드만 지원하며, 다운그레이드 기능이 없어 협업 시 불편할 수 있습니다.

참고로, Python 생태계의 SQLAlchemy 마이그레이션 도구인 Alembic은 훨씬 더 발전된 형태의 마이그레이션을 제공합니다. Alembic은 비선형적인 마이그레이션 경로(브랜치포인트 생성 가능)를 지원하여 복잡한 팀 개발 환경에서도 유연하게 대응할 수 있습니다. 이상적으로는 JavaScript/TypeScript 생태계의 ORM도 이러한 수준의 마이그레이션 도구를 제공하는 것이 바람직합니다.

관계 설정의 용이성

Drizzle ORM에서 테이블 간 관계 설정이 매우 직관적이었습니다:

import { relations } from 'drizzle-orm';

export const usersRelations = relations(users, ({ one, many }) => ({
  profile: one(profiles, {
    fields: [users.id],
    references: [profiles.userId],
  }),
  posts: many(posts)
}));

이 방식은 데이터베이스 설계의 본질적인, 관계적인 측면을 명확하게 표현해주었습니다.

쿼리 작성의 편의성과 동일 이름 칼럼 문제 처리

두 ORM 모두 쿼리 작성을 위한 API를 제공하지만, Drizzle의 접근 방식이 더 직관적이고 관계형 모델을 활용하기 쉬웠습니다:

// Drizzle ORM - db.query 방식으로 관계 활용
const result = await db.query.posts.findMany({
  where: eq(posts.published, true),
  with: {
    user: true  // 게시물 작성자 정보를 함께 조회
  }
});

// 결과 접근이 직관적이고 타입 안전함
console.log(result[0].title);       // 게시물 제목
console.log(result[0].user.name);   // 작성자 이름 - 객체 구조로 명확하게 구분됨
console.log(result[0].user.id);     // 작성자 ID - 게시물 ID와 이름이 같아도 문제 없음

// Kysely
const result = await db
  .selectFrom('posts')
  .where('posts.published', '=', true)
  .leftJoin('users', 'posts.userId', 'users.id')
  .selectAll();

// 결과 접근 시 칼럼 이름 충돌 문제
console.log(result[0].id) // 오류: posts.id와 users.id 중 어떤 것인지 모호함
console.log(result[0].name) // 오류: 둘 다 name 칼럼이 있다면 모호함

Drizzle의 접근 방식이 테이블과 컬럼을 참조할 때 타입 안전성을 더 강력하게 보장하고, 관계를 활용한 쿼리 작성이 더 직관적이었습니다.

특히 여러 테이블 조인 시 동일한 이름의 칼럼 처리 부분에서 Drizzle ORM이 훨씬 더 편리했습니다. 이는 제 개발 경험에서 가장 중요한 차이점 중 하나였습니다.

// Drizzle ORM - 동일 이름 칼럼 처리
const result = await db.query.posts.findMany({
  with: {
    user: true  // posts.id와 users.id가 모두 있지만 자동으로 구분됨
  }
});

// 결과에 자연스럽게 접근 가능
console.log(result[0].id);        // 게시물 ID
console.log(result[0].user.id);   // 사용자 ID - 명확하게 구분됨
console.log(result[0].user.name); // 사용자 이름

// Kysely - 동일 이름 칼럼 처리를 위해 별칭 필요
const result = await db
  .selectFrom('posts')
  .leftJoin('users', 'posts.userId', 'users.id')
  .select([
    'posts.id as postId',       // 별칭 필수
    'posts.title',
    'posts.content',
    'users.id as userId',       // 별칭 필수
    'users.name as userName',   // 칼럼 이름이 같을 수 있으므로 별칭 필수
    'users.email as userEmail'  // 일관성을 위해 모든 사용자 관련 칼럼에 접두어 필요
  ]);

// 별칭을 통한 접근
console.log(result[0].postId);    // 게시물 ID
console.log(result[0].userId);    // 사용자 ID
console.log(result[0].userName);  // 사용자 이름

Drizzle ORM은 테이블과 칼럼을 객체로 참조하기 때문에, 동일한 이름의 칼럼이 있어도 자연스럽게 계층 구조로 처리되며 타입 추론도 정확하게 작동합니다. 반면 Kysely에서는 문자열 기반 접근 방식 때문에 별칭을 수동으로 지정해야 하는 경우가 많았고, 복잡한 조인에서 이런 작업이 번거로워졌습니다. 특히 여러 테이블에 같은 이름의 칼럼이 많을수록 모든 칼럼에 명시적인 별칭을 지정해야 하는 불편함이 있었습니다.

또한 Drizzle ORM은 결과 타입을 자동으로 정확하게 추론해주어 별도의 타입 지정 없이도 안전하게 결과를 사용할 수 있었습니다.

Kysely의 장점

물론 Kysely도 여러 강점이 있습니다:

더 가벼운 구조: 필요한 기능만 포함할 수 있는 모듈화된 구조
SQL에 더 가까운 접근: SQL 구문에 매우 충실한 API 설계
유연성: 복잡한 쿼리에서 때로 더 유연한 작성이 가능

또한 앞서 언급했듯이, Kysely의 TypeScript 기반 마이그레이션과 양방향(up/down) 마이그레이션 지원은 특정 상황에서 Drizzle ORM보다 우위에 있는 기능입니다.

SQLAlchemy와의 비교 및 앞으로의 기대

JavaScript/TypeScript 생태계의 ORM을 이야기하기 전에, 여러 언어 중에서도 Python의 SQLAlchemy는 특별한 위치를 차지합니다. 개인적으로 여태 사용해본 다양한 언어의 ORM 중에서 SQLAlchemy가 가장 기능이 풍부하고 강력하다고 느꼈습니다. 복잡한 쿼리 구성, 고급 관계 매핑, 트랜잭션 관리, 이벤트 시스템 등 SQLAlchemy의 기능은 정말 방대합니다.

Drizzle ORM은 JavaScript 생태계에서 매우 인상적인 발전을 이루었지만, 아직 SQLAlchemy의 경지에는 이르지 못했다고 생각합니다. 특히 다음과 같은 부분에서 SQLAlchemy의 성숙도와 기능 풍부함이 돋보입니다:

복잡한 서브쿼리와 윈도우 함수 지원
다양한 이벤트 리스너와 훅
다양한 상속 전략
복잡한 트랜잭션 관리와 세션 관리
대규모 프로젝트에서 검증된 안정성
Alembic을 통한 비선형적 마이그레이션 지원
놀라울 정도로 방대하고 상세한 문서화

결론

두 ORM 모두 훌륭한 도구이지만, 제 개발 스타일과 프로젝트 요구사항에는 Drizzle ORM이 더 잘 맞았습니다. 특히 스키마 정의의 직관성, 강력한 마이그레이션 도구, 그리고 전반적인 개발자 경험 측면에서 Drizzle ORM이 더 생산적인 개발을 가능하게 해주었습니다.

동일 이름 칼럼 처리와 같은 실질적인 문제에서 Drizzle ORM의 객체 기반 접근 방식이 가져다주는 편리함은 실제 프로젝트에서 큰 차이를 만들었습니다.

ORM 선택은 결국 프로젝트 특성과 개인 선호도에 크게 좌우됩니다. 새로운 프로젝트를 시작한다면 두 도구 모두 간단히 테스트해보고 자신의 워크플로우에 더 적합한 것을 선택하는 것이 좋겠지만, 제 경우에는 Drizzle ORM이 명확한 승자였습니다.

앞으로 Drizzle ORM이 더욱 발전하여 SQLAlchemy 수준의 풍부한 기능과 유연성을 제공하게 되길 바랍니다. JavaScript/TypeScript 생태계에도 그런 수준의 강력한 ORM이 있으면 좋겠습니다. 다행히도 Drizzle ORM은 계속해서 발전하고 있으며, 그 발전 속도를 보면 기대가 큽니다.

여러분의 경험은 어떤가요? 다른 ORM 도구나 언어를 사용해보셨다면 의견을 공유해주세요!

애플리케이션 개발 측면에서 본 Drizzle ORM 대 Kysely 비교

洪民憙 (Hong Minhee) @hongminhee@hackers.pub

두 ORM에 대한 간략한 소개

Kysely는 “타입 안전한 SQL 쿼리 빌더”로 자신을 소개하며, 타입스크립트의 타입 시스템을 활용해 쿼리 작성 시 타입 안전성을 보장합니다.

두 도구 모두 훌륭하지만, 제 개발 경험에 비추어 볼 때 Drizzle ORM이 몇 가지 측면에서 더 편리했습니다.

Drizzle ORM을 선호하게 된 이유

스키마 정의의 직관성

Drizzle ORM의 스키마 정의 방식은 매우 직관적이고 선언적입니다:

import { pgTable, serial, text, integer } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: serial('id').primaryKey(),
  name: text('name').notNull(),
  email: text('email').unique().notNull(),
  age: integer('age')
});

Drizzle ORM은 이 스키마 정의로부터 자동으로 CREATE TABLE SQL을 생성할 수 있어, 스키마와 코드가 항상 동기화되어 있습니다.

반면 Kysely는 타입 정의에 더 중점을 두고 있어 스키마와 타입 정의가 분리되는 경향이 있습니다:

interface Database {
  users: {
    id: Generated<number>;
    name: string;
    email: string;
    age: number | null;
  };
}

Drizzle의 접근 방식이 데이터베이스 스키마와 TypeScript 타입을 더 긴밀하게 연결해주어 개발 과정에서 혼란을 줄여주었습니다.

마이그레이션 경험

npx drizzle-kit generate:pg

이 명령어 하나로 스키마 변경사항에 대한 마이그레이션 파일이 생성되며, 이를 검토하고 적용하는 과정이 매우 간단했습니다.

// Kysely의 마이그레이션 예시
async function up(db: Kysely<any>): Promise<void> {
  await db.schema
    .createTable('users')
    .addColumn('id', 'serial', (col) => col.primaryKey())
    .addColumn('name', 'text', (col) => col.notNull())
    .addColumn('email', 'text', (col) => col.unique().notNull())
    .addColumn('age', 'integer')
    .execute();
}

async function down(db: Kysely<any>): Promise<void> {
  await db.schema.dropTable('users').execute();
}

이러한 수동 방식은 복잡한 스키마 변경에서 실수할 가능성이 높아지고, 특히 큰 프로젝트에서는 작업량이 상당히 증가할 수 있었습니다.

하지만 Kysely의 마이그레이션에도 두 가지 중요한 장점이 있습니다:

TypeScript 기반 마이그레이션: Kysely의 마이그레이션 스크립트는 TypeScript로 작성되기 때문에, 마이그레이션 로직에 애플리케이션 로직을 통합할 수 있습니다. 예를 들어, S3와 같은 오브젝트 스토리지의 데이터도 함께 마이그레이트하는 복잡한 시나리오를 구현할 수 있습니다. 반면 Drizzle ORM은 SQL 기반 마이그레이션이므로 이러한 통합이 불가능합니다.
양방향 마이그레이션: Kysely는 up과 down 함수를 모두 정의하여 업그레이드와 다운그레이드를 모두 지원합니다. 이는 특히 팀 협업 환경에서 중요한데, 다른 개발자의 변경사항과 충돌이 발생할 경우 롤백이 필요할 수 있기 때문입니다. Drizzle ORM은 현재 업그레이드만 지원하며, 다운그레이드 기능이 없어 협업 시 불편할 수 있습니다.

관계 설정의 용이성

Drizzle ORM에서 테이블 간 관계 설정이 매우 직관적이었습니다:

import { relations } from 'drizzle-orm';

export const usersRelations = relations(users, ({ one, many }) => ({
  profile: one(profiles, {
    fields: [users.id],
    references: [profiles.userId],
  }),
  posts: many(posts)
}));

이 방식은 데이터베이스 설계의 본질적인, 관계적인 측면을 명확하게 표현해주었습니다.

쿼리 작성의 편의성과 동일 이름 칼럼 문제 처리

두 ORM 모두 쿼리 작성을 위한 API를 제공하지만, Drizzle의 접근 방식이 더 직관적이고 관계형 모델을 활용하기 쉬웠습니다:

// Drizzle ORM - db.query 방식으로 관계 활용
const result = await db.query.posts.findMany({
  where: eq(posts.published, true),
  with: {
    user: true  // 게시물 작성자 정보를 함께 조회
  }
});

// 결과 접근이 직관적이고 타입 안전함
console.log(result[0].title);       // 게시물 제목
console.log(result[0].user.name);   // 작성자 이름 - 객체 구조로 명확하게 구분됨
console.log(result[0].user.id);     // 작성자 ID - 게시물 ID와 이름이 같아도 문제 없음

// Kysely
const result = await db
  .selectFrom('posts')
  .where('posts.published', '=', true)
  .leftJoin('users', 'posts.userId', 'users.id')
  .selectAll();

// 결과 접근 시 칼럼 이름 충돌 문제
console.log(result[0].id) // 오류: posts.id와 users.id 중 어떤 것인지 모호함
console.log(result[0].name) // 오류: 둘 다 name 칼럼이 있다면 모호함

Drizzle의 접근 방식이 테이블과 컬럼을 참조할 때 타입 안전성을 더 강력하게 보장하고, 관계를 활용한 쿼리 작성이 더 직관적이었습니다.

// Drizzle ORM - 동일 이름 칼럼 처리
const result = await db.query.posts.findMany({
  with: {
    user: true  // posts.id와 users.id가 모두 있지만 자동으로 구분됨
  }
});

// 결과에 자연스럽게 접근 가능
console.log(result[0].id);        // 게시물 ID
console.log(result[0].user.id);   // 사용자 ID - 명확하게 구분됨
console.log(result[0].user.name); // 사용자 이름

// Kysely - 동일 이름 칼럼 처리를 위해 별칭 필요
const result = await db
  .selectFrom('posts')
  .leftJoin('users', 'posts.userId', 'users.id')
  .select([
    'posts.id as postId',       // 별칭 필수
    'posts.title',
    'posts.content',
    'users.id as userId',       // 별칭 필수
    'users.name as userName',   // 칼럼 이름이 같을 수 있으므로 별칭 필수
    'users.email as userEmail'  // 일관성을 위해 모든 사용자 관련 칼럼에 접두어 필요
  ]);

// 별칭을 통한 접근
console.log(result[0].postId);    // 게시물 ID
console.log(result[0].userId);    // 사용자 ID
console.log(result[0].userName);  // 사용자 이름

또한 Drizzle ORM은 결과 타입을 자동으로 정확하게 추론해주어 별도의 타입 지정 없이도 안전하게 결과를 사용할 수 있었습니다.

Kysely의 장점

물론 Kysely도 여러 강점이 있습니다:

더 가벼운 구조: 필요한 기능만 포함할 수 있는 모듈화된 구조
SQL에 더 가까운 접근: SQL 구문에 매우 충실한 API 설계
유연성: 복잡한 쿼리에서 때로 더 유연한 작성이 가능

SQLAlchemy와의 비교 및 앞으로의 기대

복잡한 서브쿼리와 윈도우 함수 지원
다양한 이벤트 리스너와 훅
다양한 상속 전략
복잡한 트랜잭션 관리와 세션 관리
대규모 프로젝트에서 검증된 안정성
Alembic을 통한 비선형적 마이그레이션 지원
놀라울 정도로 방대하고 상세한 문서화

결론

동일 이름 칼럼 처리와 같은 실질적인 문제에서 Drizzle ORM의 객체 기반 접근 방식이 가져다주는 편리함은 실제 프로젝트에서 큰 차이를 만들었습니다.

여러분의 경험은 어떤가요? 다른 ORM 도구나 언어를 사용해보셨다면 의견을 공유해주세요!

geeknews_bot @geeknews_bot@sns.lemondouble.com

3/17/2025, 4:51:14 AM

Public

Show GN: TrenDev - 오픈소스 트렌드 모아보기
------------------------------
AI 오픈소스 repo들의 최신 트렌드와 데이터를 다양한 플랫폼(GitHub, Kaggle, Hugging Face 등)에서 통합하여 보여줍니다.

- 개발 동기:
기존의 개별 플랫폼에서는 분산되어 있는 AI 오픈소스 관련 데이터를 한눈에 확인하기 어렵다는 점에서, 여러 소스의 데이터를 한데 모아 비교하고 분석할 수 있는 통합 …
------------------------------
https://news.hada.io/topic?id=19784&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

華菜野カナ @KanaNoEveryday@misskey.io

3/17/2025, 4:50:21 AM

Public

カステラは

和菓子です

（仮） @kakkokari_gtyih@misskey.io

3/17/2025, 3:42:27 AM

Public

Shared by

（仮）

まあそもそもいまそれどころではない（水曜にまだ今開発中のアプリ2つリリース）のでそろそろ私はいったん :ai_kieru:

RE: https://misskey.io/notes/a5aywwwialol0md8

🌽NONO @curacaosugar@fedibird.com

3/17/2025, 4:45:46 AM

Public

@noellaboのえるのえるさんこんにちは！
昨日fedibirdに来たばっかりのﾉﾉと申します、
Androidアプリyuitoを使うのですが、投稿したあとで修正をしようとするとこんなメッセージか出てきたので、fedibirdの仕様なのか気になっています...！他のサーバーではよく作動したので...!

레몬그린🍋 @starterdroid@serafuku.moe

3/17/2025, 4:45:24 AM

Public

다행이다....

고양이귀 후드단 단장 Judah @Villain_jud@kitsunesoba.com

3/17/2025, 4:44:02 AM

Public

나도 가상세계로 탈출해서 여우꼬리 여우귀로 캥캥거리며 뒹굴래요..

에스나 (한국어공부중) @esna@k.lapy.link

3/17/2025, 4:43:04 AM

Public

모든 것을 모두에게 맡기기

おゆうわちゃん @oyuchi@misskey.io

3/17/2025, 1:44:37 AM

Public

Shared by

:tere:

zunda @zundan@mastodon.zunda.ninja

3/17/2025, 4:42:44 AM

Public

いいなあ！

https://open.spotify.com/track/1qZC7gWAR5blkKT1DI4niR

@cocoa_vrc@misskey.io

3/17/2025, 4:41:04 AM

Public

xissmie出てる

zunda @zundan@mastodon.zunda.ninja

3/17/2025, 3:27:39 AM

Public

@shugoShugo Maeda なるほどなるほど。Encoding::UTF_16BEやEncoding::UTF_16LEでencodeした場合にはsizeは3になるようです。UTF-16でサロゲートペアになる文字を簡単に知ることができて便利だったのですが、他の方法を探しますw

Shugo Maeda @shugo@ruby.social

3/17/2025, 4:27:08 AM

Public

Shared by

zunda

@zundanzunda Ruby 3.1以前だと"吉村家".encode("UTF-16").sizeも4になるので𠮷を2と数えているのではなくてBOMも数えているのかもしれません。コードユニット数を数えるのは.encode("UTF-16LE").bytesize / 2でよさそうな気がします

Esurio @esurio1673@c.koliosky.com

3/17/2025, 4:40:17 AM

Public

あったかーい

Esurio @esurio1673@c.koliosky.com

3/17/2025, 4:39:40 AM

Public

冷蔵庫にまだあるのよね、プリン

Esurio @esurio1673@c.koliosky.com

3/17/2025, 4:39:15 AM

Public

プリンは食事ではない

村卯 @murau@misskey.io

3/15/2025, 3:18:35 PM

Public

Shared by

イカのせっと @ikanoset@misskey.systems

3/17/2025, 4:38:14 AM

Public

お昼休みに聞いた。
リファクタリングは速度が大事(他タスクとの兼ね合い的な意味で)、普段から脳内リファクタリングを反復練習する事でリファクタ筋をつけましょう、AIがプロジェクトの割れ窓コードをそのまま持ってくるのでそれをリファクタリングする必要、など
https://open.spotify.com/episode/5hq704quKHwAvSCe7CObnW?si=vJUsMzRYTVu3YKTZeDOsJg

華菜野カナ @KanaNoEveryday@misskey.io

3/17/2025, 4:37:32 AM

Public

つい :mosburger: を布教してるだけの一般人です

geeknews_bot @geeknews_bot@sns.lemondouble.com

3/17/2025, 4:37:03 AM

Public

GN⁺: my-yt - yt-dlp 기반 개인 YouTube 프론트엔드
------------------------------
- 광고 없이 깔끔한 미니멀 유튜브 프론트엔드
- yt-dlp를 사용하여 유튜브에서 비디오를 다운로드하고, 로컬 AI 모델을 사용하여 비디오 콘텐츠 요약
- 채널 관리 및 구독 기능 제공
- 보고 싶지 않은 비디오 무시
- 백그라운드에서 비디오 재생
- 오프라인 미디어 재생
- <track> 요소와 WebVTT …
------------------------------
https://news.hada.io/topic?id=19782&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

jacky be ✍🏿📖 @jalcine@todon.eu

3/17/2025, 4:34:25 AM

Public

The overly comical nature of the founder of the Web talking about "knocking down walls" from being a paywall. The Web at its most elite form lol

https://www.ft.com/content/79d2d19a-08df-48fc-9a6f-a9dbef58f642

夜坂 @magi@minazukey.uk

3/17/2025, 4:33:58 AM

Public

Shared by

Esurio

しぶしぶ…支部をつかう！

夜坂 @magi@minazukey.uk

3/17/2025, 4:33:58 AM

Public

しぶしぶ…支部をつかう！

김성일 Sung-il Kim @sung-il-kim.com@bsky.brid.gy

3/17/2025, 4:33:46 AM

Public

이게 또 재밌는 얘긴데, 민간어원은 율리우스 카이사르가 그 수술로 태어났기 때문에 Caesarean section이라 부른다고 한다. 헌데 그것을 따르면 "제왕절개"는 오역이다. 여기서 Caesar는 로마 황제가 아니라, 왕도 황제도 아니었던 율리우스 개인을 가리키기 때문이다. 한편 자궁 절개 수술은 당시 산모에게 100% 치명적이어서 산모가 죽었거나 곧 죽을 지경이 아니면 안 했고, 율리우스 카이사르의 어머니 아우렐리아가 출산 후 한참 동안 잘 살았다는 점을 보면 민간어원은 틀린 것으로 보인다...

RE: https://bsky.app/profile/did:plc:5fi7bgxe6svztyolfjkiyctw/post/3lkipqocppk2d

（仮） @kakkokari_gtyih@misskey.io

3/17/2025, 4:32:35 AM

Public

なんか調子悪いな
頭痛い

레몬그린🍋 @starterdroid@serafuku.moe

3/17/2025, 4:28:19 AM

Public

@thx@mustard.blog상어학땡스 :spinny_cat_gay: 내가 언제 그렇게 말했어!!!!

geeknews_bot @geeknews_bot@sns.lemondouble.com

3/17/2025, 4:27:47 AM

Public

Show GN: 커스텀 웨딩 캐릭터 만들기
------------------------------
작년에 아내랑 결혼하면서 만든 오픈소스 모바일 청첩장 프로젝트를 긱뉴스에 올렸었는데요.
이번에는 아내가 결혼 관련된 새로운 프로젝트를 출시해서 1년 만에 올려봅니다.

주요 기능
- 귀여운 신랑🤵 신부👰의 커스텀 웨딩 캐릭터를 직접 만들어 볼 수 있는 서비…
------------------------------
https://news.hada.io/topic?id=19804&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

Glyph @glyph@mastodon.social

3/17/2025, 4:27:06 AM

Public

achievement unlocked: actually used the `pHYs` chunk in a PNG on purpose to properly render an image in a resolution-independent way

레몬그린🍋 @starterdroid@serafuku.moe

3/17/2025, 4:26:05 AM

Public

귀여워지는 법 좀 배우고 다녀야겠다...

Lupot (상태이상:12일 출근중) @Lupot@uri.life

3/17/2025, 4:25:30 AM

Public

[팔로잉후기]
★☆☆☆☆ 툿이 거의 우울해하는 내용이에요
★☆☆☆☆ 부스트만 하고 수제 툿은 안 써요
★☆☆☆☆ 키우는 도마뱀 공유도 잘 안 해요
★☆☆☆☆ 정신건강에 안 좋아요
★☆☆☆☆ 요즘 보기 싫어요
★☆☆☆☆ 무슨 말 하는지 이해가 안 가요
★☆☆☆☆ 이 툿도 훔쳤어요

레몬그린🍋 @starterdroid@serafuku.moe

3/17/2025, 4:24:10 AM

Public

@thx@mustard.blog상어학땡스 :spinny_cat_gay: 그러고싶다!!!!

ねずみ @kaznak@mstdn.jp

3/17/2025, 4:22:54 AM

Public

やっぱバーキンはワッパーだよな

にくはら🍻 @abagv@mstdn.beer

3/17/2025, 3:37:17 AM

Quiet public

Shared by

ねずみ

バーキンはでっけえバーガーだけ食えればいいですよ、イエティいいよイエティ

Misskey GitHub Notifier @p1.a9z.dev @repo@p1.a9z.dev

3/17/2025, 4:21:16 AM

Public

🆕 Pushed by syuilo with 1 commit:
・?[6c8f21b] fix(backend): 連合無しモードでも外部から照会可能だった問題を修正

레몬그린🍋 @starterdroid@serafuku.moe

3/17/2025, 4:20:02 AM

Public

아니... 수업시간인데 맨 앞에서 왠 40대 남성분이 자꾸 이상한 말로 떠들어요....

たみとほらん🇫🇷 @qns@mastodon.cloud

3/17/2025, 4:18:55 AM

Public

さわやかのハンバーガー、いい

のえる @noellabo@fedibird.com

3/17/2025, 4:16:06 AM

Public

分断型SNS（囲い込み型）も増えてきましたね

geeknews_bot @geeknews_bot@sns.lemondouble.com

3/17/2025, 4:15:25 AM

Public

GN⁺: 2025년의 커리어 조언
------------------------------
# 현재 시장의 변화와 영향
- 2010~2020년에 고위직에 진입했던 사람들이 현재 역할에서 재미를 덜 느끼고 있음
- 과거에는 고위직 관리자가 *채용, 유지, 동기 부여* 능력으로 평가받았음
- 현재는 *세부 사항 처리, 속도 향상, 기술 전환 대응* 능력이 더 중요해짐
- 현재의 고위직 리더들은 이러…
------------------------------
https://news.hada.io/topic?id=19785&utm_source=googlechat&utm_medium=bot&utm_campaign=1834

Syntax	Description	Examples
`"` keyword `"`	Finds the string within quotes, including spaces. Case-insensitive. (Escape quotes inside with `\"`)	`"Hackers' Pub"`
`from:` handle	Finds content written by the specified user.	`from:hongminhee` `from:hongminhee@hollo.social`
`lang:` ISO 639-1	Finds content written in the specified language.	`lang:en`
`#` tag	Finds content with the specified tag. Case-insensitive.	`#HackersPub`
condition condition	Finds content that satisfies both conditions on either side of the space (logical AND).	`"Hackers' Pub" lang:en`
condition `OR` condition	Finds content that satisfies at least one of the conditions on either side of the OR operator (logical OR).	`#HackersPub OR "Hackers' Pub" lang:en`
`(` condition `)`	Combines the operators within the parentheses first.	`(#HackersPub OR "Hackers' Pub" OR "Hackers Pub") lang:en`