Profile img

Jiyu (robin)

@jiyu@hackers.pub · 43 following · 55 followers

Github
@robin-maki
2
1
1
2
0
5

AI와 함께 오라클 클라우드에 terraform으로 쿠버네티스 클러스터 올리기 해서 결국 성공했다... 맨날 콘솔로 만들땐 실패했었는데 역시 오라클은 자체서비스 믿지말고 무조건 외부서비스를 사용해야 한다는 생각이 더 강해졌다...

5
2

최근에 잔뜩 오라클 클라우드를 욕하고 다니긴 했지만 계속 고민해봤는데 비용문제가 제일 커서 쓰는게 맞을 거 같다... 뭔가 오라클라우드의 단점을 쿠버네티스로 상쇄할 수 있을 거 같음 (자체 오토스케일링 등을 안 쓰고 쿠버네티스로 하기 등등)

4
1

클라우드플레어가 원래 캐시를 하는 CDN이다 보니(근거없음) 터널을 주로 로컬 디버깅 용도로 사용하면 각종 캐시 문제에 맞닥뜨리긴 하는데 그치만 무료면서 커스텀 도메인 연결이 되는 터널링 서비스를 이거 말고는 못 찾았어요

2
0
0
1
17
0
0
4
9
3
2
7
9
2
1
1

Jiyu (robin) shared the below article:

자기소개

@roo_37@hackers.pub

연합우주에 첫 발을 내딛는 루/Roo입니다. SI 1년차 풀스택 웹 개발자로서 웹 개발 전반과 UI/UX, 접근성을 학습하며, DB와 데이터 엔지니어링에도 관심을 두고 있습니다. AI Vibe Coding, 설명 가능한 AI, AI 윤리와 같은 주제에도 흥미를 느끼며, Technical Writing, 번역, 다국어 처리에도 참여합니다. 취미로는 마작(작혼, 일번가, 천봉), 야구(삼성라이온즈), 닌텐도(피크민, 포켓몬), 만화/애니메이션 감상, 언어 공부(듀오링고 1880일), 별 보기, 풍경 사진 촬영, 동물 사랑 등이 있습니다. MBTI는 INFJ-T이며, 불안장애 및 우울증 치료 중입니다. 개발 이야기 외에 다양한 취미와 일상 이야기는 트위터(@Roo_star_)에서 만나볼 수 있습니다.

Read more →
5

Actor의 uri 도메인과 웹핑거 핸들 도메인을 다르게 설정할 수 있는가?? (실행시켜본 건 아니고 코드만 봤을때) 마스토돈 - 일단 uri 도메인으로 웹핑거 쿼리를 때린 후 uri가 일치하면 된다 (그래서 여러 서버들이 uri 도메인을 같이 쓰는건 어려울듯...) 미스키 - 무조건 uri 도메인으로 넣어버리는 듯 하다...

2

Actor의 uri 도메인과 웹핑거 핸들 도메인을 다르게 설정할 수 있는가?? (실행시켜본 건 아니고 코드만 봤을때) 마스토돈 - 일단 uri 도메인으로 웹핑거 쿼리를 때린 후 uri가 일치하면 된다 (그래서 여러 서버들이 uri 도메인을 같이 쓰는건 어려울듯...) 미스키 - 무조건 uri 도메인으로 넣어버리는 듯 하다...

1

혹시 나중에 pothos-drizzle을 쓸지도 모르는 미래의 나에게... 쓰지마... 2주전에도 오늘도 삽질했어... 지금 케이스가 pothos-drizzle로 해결하기엔 너무 복잡하다는걸 명심해...

1

오늘 알게 된 사실: SchemaBuilder의 옵션에 relay.node(s)QueryOptions.resolve로 node 쿼리를 직접 만들 수 있다... 진작에 알았으면 그냥 pothos-drizzle 썼을탠데... 이미 relation 짰던 거 다 날렸는데......

1

한번 pothos-drizzle을 도입해보고 있는데요... drizzleNode로 오브젝트를 정의하면 node 쿼리 결과를 무조건 플러그인에게 맡겨야 하나요...? where를 추가로 건다거나 특정 노드는 필터링한다거나 그런 방법은 (그냥 node로 정의하기 빼고) 없나요...?

오늘 알게 된 사실: SchemaBuilder의 옵션에 relay.node(s)QueryOptions.resolve로 node 쿼리를 직접 만들 수 있다... 진작에 알았으면 그냥 pothos-drizzle 썼을탠데... 이미 relation 짰던 거 다 날렸는데......

1
7

쿼리도 뮤테이션도 프래그먼트도 내부스토어관리도 만들었다... 이제 개인용도 정도로는 사용할만 하지 않을까??? 그치만 relay-compiler 의존성을 버리고 싶다... 얘가 svelte 파일은 무시하고 쿼리도 무슨 리액트에나 맞는 이상한 네이밍 강요하고 수정해보려 해도 RIIR 당해서 플러그인 시스템도 사라지고 참별로다... 역시 페이스북이 만든 모든건 웹 생태계를 자기 중심에 맞추기 위한 음모다... (아무말)

2

일단 첫번째 목표였던 SvelteKit SSR에 맞게 load 함수에서 쿼리하게 만드는덴 성공했다... 이제 캐시 업데이트와 relay-compiler를 때려서 svelte 파일도 컴파일하도록 만들기와 그외등등이 남았다...

쿼리도 뮤테이션도 프래그먼트도 내부스토어관리도 만들었다... 이제 개인용도 정도로는 사용할만 하지 않을까??? 그치만 relay-compiler 의존성을 버리고 싶다... 얘가 svelte 파일은 무시하고 쿼리도 무슨 리액트에나 맞는 이상한 네이밍 강요하고 수정해보려 해도 RIIR 당해서 플러그인 시스템도 사라지고 참별로다... 역시 페이스북이 만든 모든건 웹 생태계를 자기 중심에 맞추기 위한 음모다... (아무말)

2

일단 첫번째 목표였던 SvelteKit SSR에 맞게 load 함수에서 쿼리하게 만드는덴 성공했다... 이제 캐시 업데이트와 relay-compiler를 때려서 svelte 파일도 컴파일하도록 만들기와 그외등등이 남았다...

3
2
5

한번 pothos-drizzle을 도입해보고 있는데요... drizzleNode로 오브젝트를 정의하면 node 쿼리 결과를 무조건 플러그인에게 맡겨야 하나요...? where를 추가로 건다거나 특정 노드는 필터링한다거나 그런 방법은 (그냥 node로 정의하기 빼고) 없나요...?

2
2

오늘의 서커스 내용 세션의 정보를 가져오는데 세션의 앱은 ApplicationGrants를 받아야 하고 세션의 프로필 ID는 ApplicationGrantProfiles으로 프로필별 승인을 받거나 전체 프로필 승인(ApplicationGrantProfiles.profileId == null)을 받야아 가져올 수 있는데 세션의 프로필을 헤더로 오버라이드할 수 있고 오버라이드된 프로필 역시 위 조건을 지키는 경우만 리턴되게 하는 쿼리를 짰어요

const headerProfileId = c.req.header('X-Actor-Profile-Id');
    const session = await db
      .select({
        id: Sessions.id,
        applicationId: Sessions.applicationId,
        accountId: Sessions.accountId,
        scopes: Sessions.scopes,
        languages: Accounts.languages,
        profileId: Profiles.id,
      })
      .from(Sessions)
      .innerJoin(Accounts, eq(Sessions.accountId, Accounts.id))
      .innerJoin(ApplicationGrants, eq(Sessions.applicationId, ApplicationGrants.applicationId))
      .leftJoin(
        ApplicationGrantProfiles,
        eq(ApplicationGrants.id, ApplicationGrantProfiles.applicationGrantId),
      )
      .leftJoin(
        Profiles,
        and(
          eq(Profiles.id, headerProfileId ?? Sessions.profileId),
          eq(Profiles.state, ProfileState.ACTIVE),
          isNotNull(ApplicationGrantProfiles.id),
          or(
            eq(ApplicationGrantProfiles.profileId, Profiles.id),
            isNull(ApplicationGrantProfiles.profileId),
          ),
        ),
      )
      .where(eq(Sessions.token, accessToken))
      .limit(1)
      .then(first);
1

오늘의 서커스 내용 세션의 정보를 가져오는데 세션의 앱은 ApplicationGrants를 받아야 하고 세션의 프로필 ID는 ApplicationGrantProfiles으로 프로필별 승인을 받거나 전체 프로필 승인(ApplicationGrantProfiles.profileId == null)을 받야아 가져올 수 있는데 세션의 프로필을 헤더로 오버라이드할 수 있고 오버라이드된 프로필 역시 위 조건을 지키는 경우만 리턴되게 하는 쿼리를 짰어요

const headerProfileId = c.req.header('X-Actor-Profile-Id');
    const session = await db
      .select({
        id: Sessions.id,
        applicationId: Sessions.applicationId,
        accountId: Sessions.accountId,
        scopes: Sessions.scopes,
        languages: Accounts.languages,
        profileId: Profiles.id,
      })
      .from(Sessions)
      .innerJoin(Accounts, eq(Sessions.accountId, Accounts.id))
      .innerJoin(ApplicationGrants, eq(Sessions.applicationId, ApplicationGrants.applicationId))
      .leftJoin(
        ApplicationGrantProfiles,
        eq(ApplicationGrants.id, ApplicationGrantProfiles.applicationGrantId),
      )
      .leftJoin(
        Profiles,
        and(
          eq(Profiles.id, headerProfileId ?? Sessions.profileId),
          eq(Profiles.state, ProfileState.ACTIVE),
          isNotNull(ApplicationGrantProfiles.id),
          or(
            eq(ApplicationGrantProfiles.profileId, Profiles.id),
            isNull(ApplicationGrantProfiles.profileId),
          ),
        ),
      )
      .where(eq(Sessions.token, accessToken))
      .limit(1)
      .then(first);
3
2

@robin_makirobin 정확히 말하자면... 해커스펍의 3개 글은 AP에서 conversation을 노출하지 않았음에도 마스토돈 DB상에서 똑같은 conversation id를 부여받았지만 마스토돈에서 쓴 답글은 DB상에서도 새로운 conversation이 되었다!!

지금까지 내린 결론은... conversation은 아무래도 ostatus 시절 표준이기도 했고 딱히 필수는 아닌 것 같다... 가 결론 그치만 (DB상에) 있으면 답글 트리 가져오기 최적화에는 좋을 것 같다

0

@robin_makirobin 정확히 말하자면... 해커스펍의 3개 글은 AP에서 conversation을 노출하지 않았음에도 마스토돈 DB상에서 똑같은 conversation id를 부여받았지만 마스토돈에서 쓴 답글은 DB상에서도 새로운 conversation이 되었다!!

0
2
2
2

지금 생각해보면? 커맨드키를 누른다고 다운되지 않는 노트북이 굿북이다 나쁜북못된북흉악한북!! 그치만 코드를 날려먹진 않았으니 용서해주지

2
4