▲
GN⁺ 2025-04-23 | parent | ★ favorite | on: Atuin Desktop: 실행 가능한 Runbooks(blog.atuin.sh)
Hacker News 의견

  • Emacs에 관심 있는 사람들을 위해 org-babel을 사용하여 비슷한 작업을 할 수 있음

  • 약 7년 전에 이 아이디어를 시도했음: https://nurtch.com/

    • 이 아이디어는 많은 가치가 있음
    • JupyterCon Paris 2023에서 관련 발표를 진행했음: https://www.youtube.com/watch?v=TUYY2kHrTzs
    • 문서에 실행 가능한 코드가 포함되면 PR 검토 워크플로우를 문서에도 적용하고 싶어함
    • 이는 위키 편집보다 팀의 더 많은 투자가 필요함
    • 행운을 빔

  • 로컬 우선이라면 이미 부패의 대상임. 모든 것을 컨테이너에서 실행하지 않는 한 로컬은 중요하지 않음

    • 실행북을 기록하고 싶다면 여러 방법으로 가능함. 텍스트 파일, Confluence 문서, 화면 녹화, 셸 스크립트 등
    • 사람들은 이미 그렇게 하지 않으며, UI가 더 화려하다고 해서 갑자기 더 많이 하지는 않을 것임
    • 개인적으로는 시스템을 특정 상태로 만들기 위해 코드(또는 문서)를 작성하고 싶지 않음
    • 수동으로 상태를 만들고 도구를 사용해 상태를 덤프한 후 나중에 도구를 다시 실행해 그 상태를 생성(또는 강제)하고 싶음
    • 컴퓨터가 그 상태에 도달하는 방법을 코드로 작성하고 싶지 않음
    • "선언적 구성"을 작성하고 싶지 않음. 이는 단지 다른 이름의 코드일 뿐임
    • 수동으로 작업을 수행하고 스냅샷을 찍고 재생하고 싶음
    • 이 작업이 모든 시스템에서 어디서나 작동하기를 원함. 명령을 위한 Bash 셸 모니터링에 의존하지 않고 상태를 덤프하고 나중에 상태를 재적용하기를 원함

  • AWS에 있을 때 우리 팀을 위해 원했던 것이 바로 이것임

    • 자동화하기에는 약간 위험한 운영의 많은 버전이 있음
    • 이를 통해 점진적으로 구축할 수 있는 경로를 제공함
    • 축하함

  • 로컬 Jupyter 노트북과 어떻게 다른지 궁금함

    • .ipynb에서 ! 또는 %를 사용하여 이 작업을 수행할 수 없는지 궁금함
    • 진심으로 묻는 질문임. 이 회사나 CLI 제품에 익숙하지 않음

  • 흥미로워 보임

    • 최근 Jupyter 노트북을 대체하기 위해 marimo.io를 사용하기 시작했음
    • 여러 가지 훌륭한 개선 사항이 있으며, 이 방향으로의 움직임처럼 보임

  • 출시를 축하함

    • Atuin을 조금 따라왔으며, 이 실행북 기능의 대상이 아니지만, 사람들이 재미있는 새로운 것을 만드는 것을 보는 것이 좋음

  • 우리 팀은 polyglot 노트북을 사용했음: https://marketplace.visualstudio.com/items/…

    • C#을 주요 언어로 사용하여 nuget 패키지로 공유된 코드를 사용해 실행북을 가질 수 있었음
    • 이는 프로덕션에서 실행되는 다른 코드처럼 자체 API 및 애플리케이션과 상호 작용할 수 있게 해줌
    • 검토하기에 최상의 경험은 아니었지만 우리에게는 효과적이었음

  • 이는 runme.dev와 매우 유사해 보임: https://runme.dev

  • 이 점을 이해하지 못하겠음. 내가 놓치고 있는 부분을 설명해 줄 수 있는지 궁금함

    • 간단한 셸 스크립트 대신 이것을 왜 사용해야 하는지 궁금함