키워드 XOR 비트연산 Observation 블로그 스크립트 정리, git hook 내용 XOR 연산 LeetCode에 어제에 이어서 XOR 연산 문제가 나왔다. 일반적인 사칙연산과 다른 특징들을 사용해야하는 문제들이었다. 가장 큰 특징은 비트 연산은 비트 수가 고정되어 있어서 연산의 결과가 엄청나게 많은 경우의 수를 만들지 않는다. 예를 들어서, 곱셉의 경우에는 $10^3$ 미만의 두 수를 곱하면 최대 999 * 999 = 약 100만이 되어서 거의 7자리수의 경우의 수가 되는데, 비트연산은 더 이상 자리수의 확장이 일어나지 않는다. ...
키워드 Codeforces 가입 로컬 LLM opencode에 연결하고 ACP로 Xcode에 연동하기 SwiftUI WWDC 세션, 특히 View Value와 View Identity 내용 PS 풀기, Codeforces 가입 LeetCode에서만 문제를 푸는게 조금 시야가 좁아지나 싶어서, Codeforces에 가입했다. Swift 지원이 없지만, PS 문제를 풀 때 특정 언어에 종속되지 않으려고 꾸준히 Swift, Python, C++를 돌아가면서 풀고 있으니 큰 문제는 없다. 가장 풀이 수가 많은 문제 하나를 풀었다. 매일 LeetCode 오늘의 문제를 푸는 것이 루틴 중 하나인데, Codeforces, 삼성 SW Expert Academy 등 온라인 저지 사이트 여럿 돌아다니면서 풀어보려 한다. BOJ가 사라진 이후로 LeetCode 의존이 꽤 심해졌는데, 다양하게 풀어봐야겠다. ...
키워드 단조 스택 Hugo Flat Post -> Page Bundle 블로그 스크립트는 어떤 언어로? Xcode 프로젝트명 바꾸기 SwiftUI Identity 내용 LeetCode 1081, Substring, Subsequence, Monotonic Stack LeetCode 1081 PS 문제를 풀면서, 처음에 Medium 문제인데 좀 해맸다, LCS 두 개를 하면서 Substring이랑 Subsequence 차이를 분명히 알았는데, Substring으로 생각하고 풀어서 스택을 써야 할 곳에 투 포인터를 썼다. 단조 스택(Monotonic Stack) 문제인데, 사실 이런 스택이 있는지 오늘 처음 알았다. 그냥 스택은 스택으로 생각했으니까, 마치 Binary Search와 Parametric Search같은 느낌인가. ...
키워드 Python 로컬 변수 스코프. Python에서 람다식 정리, Swift 인라인 클로저와 다른점. 블로그 마이그레이션 하면서 이전에 썼던 iOS 관련 글 복습 블로그에서 카테고리를 몇개를 해야하는가? 내용 Python 로컬 변수 스코프 문제 Leetcode 1291번 문제를 푸는 도중에 다음과 같이 코드를 작성했다. 로직에 오류가 있어서 통과는 못하는 코드다. class Solution: def sequentialDigits(self, low: int, high: int) -> List[int]: answer = [] seq = [] def dfs(n: int): if n > 9: return if seq: intSeq = int("".join(seq)) if high < intSeq: seq = [] # 이부분 return ... seq 변수가 sequentialDigits 함수의 로컬 변수인데, if 문 안의 seq = [] 부분 때문에 에러가 났다. ...
오늘 한 내용 Hugo 블로그에서 Mermaid를 외부 CDN 없이 렌더링하도록 변경 Mermaid가 필요한 페이지에서만 스크립트를 로드하도록 최적화 hugo --minify로 빌드 검증 배운 내용 Mermaid 코드 블록은 layouts/_markup/render-codeblock-mermaid.html에서 <pre class="mermaid">로 변환하고, layouts/_partials/extend_footer.html에서 Mermaid가 포함된 페이지에만 스크립트를 삽입하도록 구성했다. 처음에는 ESM 파일 하나만 static/에 복사했지만, 해당 파일이 내부 chunk를 추가로 참조하는 구조라 렌더링이 깨졌다. 브라우저가 다이어그램을 SVG로 바꾸지 못하고 원문 텍스트처럼 보여서, 의존성이 단순한 mermaid.min.js로 교체했다. 외부 CDN을 제거하는 작업도 단순히 파일을 내려받는 것으로 끝나지 않았다. 번들 파일의 의존성과 실행 방식까지 확인해야 실제 정적 사이트에서 안정적으로 동작한다는 것을 배웠다. ...
요약 오늘은 0-1 BFS를 문제에 적용해 보면서 알고리즘 선택의 중요성을 느꼈다. 또한 티스토리 블로그를 Hugo로 이전하기 위한 마이그레이션 스크립트를 작성하며 HTML을 Markdown으로 변환했다. 배운 것 0-1 BFS LeetCode 3286. Find a Safe Walk Through a Grid 사용 언어: Python, Swift 사용 알고리즘: Dijkstra, 0-1 BFS 그동안은 거리 개념이 나오면 무조건 다익스트라를 사용했는데, 처음으로 0-1 BFS를 이용해서 문제를 풀었다. 같은 문제를 Python에서는 다익스트라로 풀었고. 0-1 BFS는 Swift로 풀었다. 기존에 Swift에서 BFS를 사용할 때는 배열과 인덱스 포인터를 이용한 유사 Queue를 사용했는데, 이 방식으로는 큐의 헤드에 원소를 push하는 메소드를 구현하기 어려워서 배열을 사용했다. 문제의 제약조건이 널널해서 배열로 충분히 통과했는데, 어떻게 해야할지는 고민해봐야 할 것 같다. Linked List를 이용해서 큐를 만들면 되지만, 이게 힙와 다익스트라를 쓰는 것보다 코드를 작성하는 입장에서 효율적일지는 잘 모르겠다. ...
오늘 한 내용 AGENTS.md, AGENTS.override.md의 적용 순서 정리 전역 규칙과 프로젝트 규칙이 어떻게 병합되는지 확인 배운 내용 규칙 파일은 전역에서 프로젝트 하위 디렉토리로 내려오면서 적용된다. 같은 디렉토리에서는 AGENTS.override.md가 AGENTS.md보다 우선하고, 하위 디렉토리의 규칙이 더 구체적인 지침으로 해석된다. 결국 규칙은 전역에서 프로젝트 루트, 현재 작업 디렉토리 순서로 합쳐진다. 공통 원칙은 위쪽에 두고, 특정 모듈의 세부 규칙은 아래쪽에 두는 이유가 여기에 있다. 해결 내용 전역 원칙은 전역 규칙에, 프로젝트 공통 원칙은 루트에, 모듈별 세부 지침은 하위 디렉토리에 두는 계층을 정리했다. 더 가까운 디렉토리의 규칙이 구체적인 지침으로 적용된다는 점도 확인했다. ...
오늘 한 내용 Antigravity의 Rules, Skills, Workflows 구조 정리 dev-data-server-light의 AGENTS 규칙을 새 구조에 맞춰 마이그레이션 배운 내용 Antigravity의 핵심 구조는 다음처럼 정리할 수 있다. Rules = 행동 규칙 Skills = 특정 분야의 지식과 노하우 Workflows = 작업 절차 Rules는 항상 지켜야 할 원칙을 정의하고, Skills는 Storage 설계나 코드 리뷰처럼 특정 작업에 필요한 전문 지식을 담는다. Workflows는 계획, 구현, 테스트처럼 작업을 어떤 순서로 진행할지 정의한다. 기존 AGENTS.md를 그대로 옮기는 것이 아니라, 공통 원칙과 모듈별 규칙을 분리해야 했다. 규칙을 작게 나누면 모든 작업에 불필요한 문맥을 주입하지 않으면서도 필요한 순간에 더 구체적인 지침을 적용할 수 있다. ...
오늘 한 내용 Antigravity IDE의 에이전트, 에디터, 터미널, 브라우저 구조 살펴보기 File Storage 구현 순서와 StorageService 설계 배운 내용 Antigravity는 에디터 안에서 에이전트가 작업을 수행하고, 브라우저와 터미널을 사용해 결과를 검증하는 개발 환경이다. Agent는 기능 개발이나 버그 수정처럼 실제 작업을 담당하고, Tab은 자동완성에 가깝다. File Storage는 먼저 계약을 만들고, 그 다음 fs/promises 기반 구현체와 테스트를 추가한 뒤, Express와 분리된 Service를 얹는 순서로 진행하기로 했다. 처음부터 multipart 업로드까지 확장하지 않고, JSON과 단순한 파일 콘텐츠로 흐름을 검증하는 것도 중요한 범위 조절이었다. ...
오늘 한 내용 LeetCode 3558 풀이 DB 모듈에서 capability와 use case 분리 File Storage 모듈의 계약과 서비스 설계 배운 내용 기존에는 Route가 Database 인터페이스를 직접 사용했다. 리팩터링 후에는 Route -> DatabaseService -> RecordStore -> InMemoryRecordStore 흐름으로 바꾸었다. RecordStore는 레코드를 저장하고 꺼내는 교체 가능한 capability이고, DatabaseService는 여러 저장소 동작을 조합하는 use case다. 예를 들어 replace 이후 갱신된 레코드를 반환하거나, 삭제 결과에 따라 오류를 판단하는 흐름은 Service가 맡는다. File Storage도 같은 기준을 적용했다. 계약은 key와 Uint8Array만 사용해 작고 명시적으로 만들고, 로컬 파일 시스템이나 경로 검증은 구현체 안에 가둔다. ...