pkg update

近所の河津桜を撮って来ました

Nikon Z8+NIKKOR Z 35mm f/1.2 S

https://youtu.be/iijvpe0r1EY?si=MU_f78-oD8ORY1v5

간사이 여행 일정을 생각하는 분이 있다면 꼭 시청을 권하는 영상.

간사이 여행에서 가장 중점을 둘 도시는 단연 교토입니다. 오사카를 뺄 수는 있어도 교토를 그럴 수는 없습니다. 구경하기도 놀기에도.

교토에 숙소를 잡고 오사카를 당일치기 하는 편이 낫습니다. 교토 숙소들이 조금 비싸긴 하지만요...

스타벅스 아아를 맛있다고 생각한 적이 없었는데, 너무 맛있게 마신 적이 있었습니다.

그건 텁텁한 터키쉬 커피랑 케밥만 먹다가 이스탄불 공항에서 들이킬 때였죠. 🤣

야, 내 인생에 스벅 아아를 그렇게 맛있게 마시게 될지는 몰랐죠. ㅋㅋㅋ

속초여행갔다가 호텔캔슬당하고 오열한 일본인 유튜버

https://bbs.ruliweb.com/community/board/300143/read/69969268

얼마전 일본인 유튜버가 부대찌개 먹으려다 1인은 안된다고 한거랑
이번에 비싸게 받으려고 호텔측이 예약취소 해버린거랑...

한국 관광이 왜 잘 안되는지를 확실히 보여주는구만.

@heka 말씀대로 루머 그대로인데, 실 제품은 조작계가 그리 나빠보이지는 않지만... 쓸 일은 없겠지요. 😓 + 렌즈 셔터인데 1/4000까지 지원하는 점은 좋아 보이네요. ㅎㅎ

국립국제교육원에서 운영하는 특수외국어교육진흥사업으로 '특수외국어 배우기' 프로그램 수강신청이 차주 월요일(3/24)에 열려요.
전공자가 아닌 이상, 일반 학원에서는 배우기 어려운 외국어를 무료로 배울 수 있고, 온라인 강의로 진행되니 관심 있으신 분들은 한 번 보시는 걸 추천해봅니다.

■ 수강 대상: 초(5,6학년)중고학생(학교 밖 청소년 포함) 및 일반인
■ 개설 강좌: 25개 특수외국어* 대상 130개 강좌 개설
* 그리스어, 네덜란드어, 라오스어, 마인어(말레이시아어&인도네시아어), 몽골어, 미얀마어, 이란어, 이탈리아어, 체코어, 카자흐어, 크로아티아어, 크메르어, 태국어, 터키어, 포르투갈어&브라질어, 폴란드어, 헝가리어, 힌디어
■ 수간 기간: 2025. 4. 21(월) ~ 6. 15.(일) ※강좌별 수강 기간 상이
■ 운영 주체: 특수외국어 전문교육기관*
* 단국대(4개어, 12개 강좌), 부산외국어대학교(10개어, 31개 강좌), 한국외국어대학교(21개어, 87개 강좌)
■ 수업 방법: 실시간 온라인 화상강의(ZOOM 및 WEBEX 활용)
■ 신청 기간: 2025. 3. 24(월) 10:00 ~ 3. 28(금) 17:00

기타 자세한 내용은 아래 링크 참고하세요.
2025년 상반기 특수외국어 배워보기 수강신청 안내(유의사항 안내)
https://cfl.niied.go.kr/notice/board?idx=5184
2025년 상반기 특수외국어 배워보기 프로그램 강좌 목록(25개 언어, 130개 강좌_3.19수정)
https://cfl.niied.go.kr/notice/board?idx=5186

작년 기준으로 인기 있는 강좌(베트남어, 태국어, 이탈리아어, 그리스어 등)은 정시 딱 맞춰서 들어가도 금방 다 차있고, 신청 열리는 당일이면 모든 강의가 마감되었던 것 같습니다.

흐어... 유튜브가 청소 크리에이처들의 청소 기법 영상 리스트를 추천한다...

치우고 살라는 잔소리를, 유튜브, 너마저!

ㅋㅋㅋㅋ 😇

@heka 필름 시절부터 중형 쓰던 분들에게는 혁신적;일 테지만 아무래도 패션/자랑용 아이템으로 팔릴 가능성이 높긴 하죠. 디지털 세대에게는 말씀대로 활용하기 어려운 카메라이긴 합니다. 쓸만한 시나리오가 좁은데 가격이 비싸니...;

#東京カメラ部
#tokyocameraclub

#東京カメラ部
#tokyocameraclub

이제 슬슬 일본은 벚꽃 철인가... 요즘 한국 날씨가 추워서 전혀 감이 안 오고 있었네. ㅎㅎㅎ;

후지 GFX 100 RF는 분명 좋은 카메라겠지만, 돈 이전에 물량이나 있을지 모르겠다.

그래! 난 물량이 없어서 못 사는 거야! 조작계도 맘에 안 들어!! ㅋㅋㅋ😂

비잔티움과 그리스도교 박물관 본관.

전시관은 지하에 있고 이 건물은 동로마제국 시절의 대표작이라고. 전시물은 양도 적고 꼭 볼 정도로 대단하지는 않지만 입장료가 싸고 본관 건물과 부속 정원 구경하는 재미가 있다. 기독교인이라고 꼭 들를 정도는 아니라는 말. 😓

#photo #photography #사진 #写真 #Athens

아테네 키클라데스 예술 박물관 출구의 계단.

전시도 좋았지만 현대적이고 우아한 건물과 공간이 인상 깊었던 곳이었다. 유명하지는 않고 입장료에 비해 작지만 아테네에서 시간이 남는다면 한 번 가볼만한 곳.

하지만 키클라데스 조각상들 중 최고작은 고대사 박물관에 있습니다. 😓

#photo #photography #사진 #写真

이番(번)에 @lqez 님의 《우리의 코드를 찾아서》에 出演(출연)하여 #페디버스, #ActivityPub, #Fedify, #Hollo 等(등)에 關(관)해 이야기를 나눴습니다. Fedify와 Hollo의 開發(개발) 祕話(비화) 같은 게 궁금하시다면 한 番(번) 보셔도 재밌을지도 모르겠습니다. ㅎㅎㅎ

https://www.youtube.com/watch?v=sqxR8zscSDo

#연합우주 #fediverse #fedidev

맥북 사면서 붙인 애플케어 만료되었다.. 이젠 조심해서 써야 해..

하 지 만 내 가 처 몰 랐 던 사 실
마 지 막 은 가 히 설 명 할 수 없 습 니 다
첫 번 째
화 재 보 험 에 8 대 문 화 용 품 수 리 비 용 특 약 을 걸 면
보 증 기 한 끝 난 컴 퓨 터 수 리 비 용 이
백 만 원 까 지 보 장 됩 니 다

한국 여행을 꽤 다녀본 편인데, 자국민 기준으로 식사는 그럭저럭 괜찮은데 문제는 교통과 숙박.

대도시 아니라면 승용차 없이 대중교통으로는 사실상 일정 잡기가 어려운 수준이고, 숙박은 질이 가격에 상관없이 들쑥날쑥함. 비싼 숙소가 질을 담보하지 않음... 고급 호텔이라면서 침대부터가 싸구려인 곳이 널려 있음. 싼 곳은 곰팡이 냄새만 안 나도 실패는 안 했구나 하는 수준.

그래서 한국 여행은 결국 1박 정도만 자차로 명소 보고 밥 먹고 오는 정도로만 하게 되고, 그 이상 예산을 들일 거면 외국 여행을 보게 된다...

난 지금도 왠만한 문서 작업도 emacs로 하지만, 남에게 이걸 권할 거냐, 하면... 흠.

근데 한번쯤은 써 보는 경험은 좋다고 생각함. 자동화와 프로그래밍의 기본 개념을 잡기에 좋은 에디터니까.

라이트룸이 인터넷 동호회 표준 사진을 뽑아준다면, 캡쳐원은 어디 잡지에서 본 듯한 사진으로 나온다. 물론 둘 다 색 프로필과 커브를 만져두면 되는데, 그럴 거면 굳이 이런 비싼 SW는 필요 없지. ㅋㅋㅋ 😇

캡쳐 원, 정말 좋은 SW지만 이거 쓰면 카메라의 색, 노출 특징이 중화되어서 다 (유명한) 어디서 본 듯한, 웰 메이드 사진이 되어 버리는군. 자동이 너무 좋아서 굳이 손 댈 생각이 없어지는 문제가 있네. 여러모로 프로용. ㅋㅋㅋ;

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의 마이그레이션에도 두 가지 중요한 장점이 있습니다:

1. TypeScript 기반 마이그레이션: Kysely의 마이그레이션 스크립트는 TypeScript로 작성되기 때문에, 마이그레이션 로직에 애플리케이션 로직을 통합할 수 있습니다. 예를 들어, S3와 같은 오브젝트 스토리지의 데이터도 함께 마이그레이트하는 복잡한 시나리오를 구현할 수 있습니다. 반면 Drizzle ORM은 SQL 기반 마이그레이션이므로 이러한 통합이 불가능합니다.

2. 양방향 마이그레이션: 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도 여러 강점이 있습니다:

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

또한 앞서 언급했듯이, 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 도구나 언어를 사용해보셨다면 의견을 공유해주세요!

news.hada.io/topic?id=19791
github.com/suitenumerique/docs

노션 / Outline 대체제...인데
프랑스 정부 + 독일 정부 의 오픈소스
(??!?!?!)

django, typescript

- DINUM (프랑스 정부 공공기관)
- ZenDiS (독일 정부가 전적으로 소유한 GmbH)

패션이 중요한 카메라니 그에 대한 대응도 해 줘야겠지... 근데 그럴거면 하이브리드 뷰파인더도 좀 넣어주지. ㅎㅎ

후지 GFX100 RF는 굉장히 클래식한 카메라가 될 거 같은데, 어차피 그거 5천불 주고 살 고객들은 오히려 좋아할지도... 하지만 크롭 레버를 다는 건 결국 jpeg 머신으로 쓰라는 건데, 흠.

사진들 정리하고 배포용 리사이즈 만드는 스크립트들도 배포할까... 쓸모 있는 사람이 있으려나. 흠.

프로필 사진을 변경하고 헤더 사진도 걸었습니다. ㅎㅎ

프로톤 VPN이 RAM 전용 서버를 사용하지 않는 이유 - https://blog.native.cat/post/48

혐한단체의 얼간이들이 일본에 잘 정착해 살고 있는 재일동포들의 면전에서 “너희 나라로 돌아가”라는 막말을 던질 때, 일본 내 양심세력과 함께 다 같이 분노했던 우리였다. 하지만 지금은 우리 중 누군가가 화교를 상대로 똑같이 하고 있다. 2025-03-15 05:56 www.lawtimes.co.kr/opinion/2063...

중국인이 뭐 어때서