프론트엔드 웹개발의 한 획을 그었고, 아직도 현재 진행중인 리액트(React.js)의 10년 역사를 80분 정도로 요약한 다큐멘터리가 나왔습니다.
페이스북이 오픈 소스로 리액트를 만들었다는 정도만 알고 있는 저에게 창립 멤버들의 활동은 잘 알지 못했습니다. 영상을 캡처해서 공유합니다. 2013년 5월 29일에 리액트의 public release 커밋이 처음으로 올라갔군요.
아래는 영상 링크입니다. 참고로 유튜브에서 C(Capture) 키를 누르면 자막이 보입니다. #개발자단축키지상주의
https://www.youtube.com/watch?v=8pDqJVdNa44
좋아하는 것이 생기면 그에 관련된 역사나 에피소드들이 매우 흥미진진해 집니다. 리액트로 삶을 꾸려가는 엔지니어들에게 좋은 영상이 되면 좋겠습니다. ✨
2016년 매일경제 기사에 있는 그림입니다. 링크
9년이 지난 지금 텔레마케터는 챗봇으로, 은행원은 은행앱으로, 뭐 이외에도 너무 많습니다. 마틴 파울러의 `리팩터링` 2판에 나온 내용 중에 이런 부분이 있습니다. 20년 전 출간된 `리팩터링` 1판 예제가 비디오 대여점이었는데, 10년 전부터 젊은 친구들이 비디오 대여점이 뭐냐고 질문하는 경우가 많아서, 2판에서는 연극 예매 시스템으로 예제를 바꿨다고 합니다.
구글 번역기, 파파고 번역기 등에 AI엔진이 붙은 2017년부터 번역가 직업이 위태하다고 했는데, ChatGPT가 정식으로 공개된 02월 13일부터 이제 안전한 직업은 학생, 어부 밖에 생각이 나지 않습니다.
`눈 떠 보니 선진국`의 저자 박태웅 한빛미디어 의장님의 의견이 참 깊게 다가왔습니다. https://youtu.be/PupcLCVfZDw?t=1051
기술의 발전은 인간 조직의 적응을 기다려 주지 않기 때문에, 어떻게 지금 조직을 현재 등장한 기술에 적응 시킬 것인지 많은 사회적 노력이 필요할 것입니다. 소프트웨어 엔지니어로 살아가는 프로그래머의 윤리학도 킹받게 중요해지는 시대라고 보입니다.
Resource from: https://github.com/kenu/ospo101/tree/main/module3
오픈 소스 프로그램 오피스(OSPO)는 오픈 소스와 관련된 조직 업무의 중앙 연결고리
OSPO는 조직에 따라 다르게 보일 수 있는 점이 강점
다양한 요구 사항을 해결하기 위해 이 구성을 형성하고 자주 변경이 가능
`일률적으로 적용되는` 조직 구성 모델은 없으며, 고도로 중앙 집중적인 대규모와 작고 분산된 조직까지 가능
기업에서 OSPO의 기능은 전략적 우위를 위해 기업 내부에서 오픈 소스 사용, 기여 및 생성을 촉진
프로그램 오피스의 책임
OSPO는 개발자와 협력하는 것 이상을 수행
성공적인 OSPO는 개발자와 해당 팀을 지원하는 정책, 프로세스 및 지침을 수립
표준 코딩 및 조직적 관행, 프로세스 및 도구 집합을 권장
창의적 개발자가 어쨌든 우회하거나 무시하게 되는 경직된 프로세스를 피하거나 제거하는데 도움
프로젝트의 보안 및 기타 측면을 위협하는 불필요한 경직된 프로세스
오픈 소스 프로그램 사무실은 비즈니스 부서가 계획에서 오픈 소스를 고려하기 시작할 때 대화에 내실과 사실을 가져오기 때문에,
고려하는 이유, 그에 따른 결과, 목표 달성을 위해 필요한 것들이 전적으로 이해될 수 있음
오픈 소스 전문가들이 대화를 구성하는 데 도움을 주므로 이해관계자들은 결정을 내리는 데 필요한 시작점과 고려해야 할 사항을 알 수 있음
발생하는 문제 또는 요구 사항을 해결하고 이해하기 위해 내부 개발자와 오픈 소스 사용자 커뮤니티 간의 중요한 연락 담당자 역할 수행
법적 문제를 지원하고 개발자를 옹호하며 회사의 오픈 소스 프로젝트를 기반으로 하는 외부 사용자의 목소리 전달
해당 정보를 제품 관리팀을 포함한 회사 내부의 다른 사람들에게 전달하여 조직에 유익한 방식으로 제품을 더욱 발전시키는 데 도움
다음:
이전 글에 이어지는 2번째 웹페이지 성능 이슈를 처리한 방법입니다.
Serve Images in next-gen formats 항목이 나와서 내용을 보니 PNG 또는 JPG를 WebP로 바꾸라는 메시지였습니다. AVIF는 또 뭔 이미지 포맷인가요. 😅
살펴보니 이미지 용량을 15~40% 정도 줄여주는 것으로 보였습니다.
WebP는 구글에서 미는 이미지라 Safafi 지원이 안되는 것으로 알고 있었는데, 16.0 버전부터 지원이 되네요. 2022/09 월 이후 업데이트한 사파리는 가능할 것으로 보입니다. 뭐, 전 세계의 점유율이 1.34%라고 하고, 또 맥에서도 크롬브라우저 사용이 좋은 편이니, 모두 WebP 로 바꾸지 않을 이유가 없습니다. 1.34%를 위해서 빠른 로딩과 네트워크 비용절약을 포기할 수는 없으니까요.
https://caniuse.com/webp
작업을 위해서 webp를 커맨드라인으로 설치하니, cwebp 커맨드라인이 추가되었습니다.
https://www.google.com/search?q=webp+command+line
🔎 webp command line: Google 검색
www.google.com
그리고 이미지 폴더를 바꾸니 이렇게 변환된 파일들이 생성이 되었습니다. 제가 커스터마이징한 shell 파일은 이 링크에서 볼 수 있습니다.
오늘 네트워크가 좋아서 그런지 성능 잘 나오네요.
After:
Yesterday:
기술이 발전하는 것을 몸소 느끼는 중입니다. 물론 우여곡절도 많았었습니다. TL;DR
♻️ all images to webp · Issue #78 · kenu/okdevtv
https://gist.github.com/tabrindle/ed9f77b4e96f4c98b49b
github.com
🆗 오늘은 여기까지입니다. 제 유튜브 채널도 구독, 좋아요, 알람 부탁합니다.
크롬개발자 도구의 Lighthouse 체크해 보았는데, Performance에 `Use HTTP/2`가 1순위로 올라와서, nginx의 ssl 설정을 바꾸는 작업을 했습니다.
Before:
After:
설정은 아주 쉬웠습니다. `443 ssl` 문구를 찾아서, `http2` 단어만 추가하면, 적용됩니다.
CloudFlare나 Apache HTTPD, 로컬 서버 등의 설정은 https://dassur.ma/things/h2setup/ 링크에 잘 설명되어 있습니다.
Lighthouse는 웹페이지 진단도구이고, 개발자도구 탭에 기본으로 보입니다.
작년에 미루어 놓은 숙제들이 많이 생겼습니다. 그 중에 하나가 마크다운만으로 파워포인트에 버금가는 프리젠테이션을 만들 수 있는 기술 `marp`입니다.
그리고 시작하시면 됩니다.
VS Code로 Git 쉽게 시작하기를 공유하려고 합니다. 내용은 다음과 같습니다.
프로그래밍에서 소스는 계속 변한다. 계속 변경하다가도, 때로는 과거의 기록이 필요할 때도 간혹 생긴다. 그래서, 소스의 이전 기록을 남기는 일은 나중에 도움이 되기도 한다. 요즘은 회사 개발팀에서 Git 사용하는 것은 개발자의 기본 소양이 되고 있다. 이 기록은 Git을 VS Code로 더 쉽게 사용하기 위한 방법을 소개하기 위해 쓰여졌다.
https://git-scm.com 사이트에서 다운로드 받아서 설치하는 법이 일반적이다.
mac에서는 `brew install git` 으로 설치할 수 있다.
linux에서는 `sudo yum install git` (Redhat 계열), `sudo apt install git` (Debian 계열) 명령으로 설치할 수 있다.
Windows에서는 이후에 CMD, PowerShell 창 대신 `Git Bash` 창을 열어서 실행하면 된다.
아래 명령어는 코드 작성자가 누구인지 표시하는 기본 설정법이다.
`git config --global user.name 아이디`
`git config --global user.email 이메일@주소`
참고로 프로젝트를 다양하게 진행할 경우, 해당 폴더에서 --global 옵션만 빼면 프로젝트마다 다르게 설정할 수 있다.
https://code.visualstudio.com/ 에서 다운로드 받아서 설치한다. VS Code는 일렉트론 기반의 TypeScript로 만들어진 웹앱이기 때문에, 윈도우, 맥, 리눅스에서 다 사용할 수 있다.
VS Code를 실행하면 왼쪽 사이드바에 있는 5번째 아이콘(블록 모양)을 클릭해서 아래 두 가지 플러그인을 설치한다.
https://github.com 에 계정을 만든다.
https://github.com/kenu/gitvscode 에 접속해서 우측 상단의 `fork` 버튼을 클릭해서 샘플 프로젝트를 복사한다.
참고로 github.com 다음은 아이디 또는 조직(organization)이 따라온다. 그 다음은 프로젝트 이름이다.
`git remote add origin https://github.com/아이디/gitvscode`
위 명령으로 GitHub와 연결이 가능하다.
소스의 용량에 비해서 라이브러리의 용량은 매우 크다. 소스가 1mb일 때 라이브러리는 10~100mb가 넘는 경우가 대부분이다. 버전 관리 시스템에 다운로드 가능한 라이브러리까지 포함하는 것은 비효율적이다. 때문에 버전 관리 시스템에는 라이브러리를 제외하고, 프로젝트 메타파일 목록만 관리하는 것이 효율적이다.
Git에는 `.gitignore` 파일에 관리에서 제외되는 목록을 사용한다. 파일명과 폴더 모두 등록하면 버전 관리 시스템에서 제외할 수 있다. *.class 처럼 와일드카드(*) 문자도 사용할 수 있다.
GitHub에서 프로젝트 생성하고 언어를 정할 때 언어별 .gitignore 목록은 최적화되어 있어서 도움이 된다.
To be continued...
image from: https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests
Introducing GitHub Pull Requests for Visual Studio Code
Introducing GitHub Pull Requests for Visual Studio Code
code.visualstudio.com
astro를 통해서 빠르고, 가볍게 웹사이트를 만들 수 있습니다. 아래 이미지는 next.js와 용량을 비교한 것입니다.
Astro는 빠르게 콘텐츠 중심의 웹사이트를 구축하기 위한 올인원 웹 프레임워크입니다.
파일 기반의 라우팅을 제공하기 때문에, Next.js의 특징을 가져왔습니다. https://docs.astro.build/en/core-concepts/routing/
![초급자를 위해 준비한 인프런 [데브옵스 · 인프라] 강의](https://okdevtv.com/images/inflearn-react-api.webp)
# Example: Static routes
src/pages/index.astro -> mysite.com/
src/pages/about.astro -> mysite.com/about
src/pages/about/index.astro -> mysite.com/about
src/pages/about/me.astro -> mysite.com/about/me
src/pages/posts/1.md -> mysite.com/posts/1Astro Islands라는 아일랜드 아키텍처를 사용하는 것이 특징적입니다.
시작은 node.js 기반에서 쉽게 시작할 수 있습니다.
npm create astro
생성된 폴더로 이동해서 `npm run dev` 로 프로젝트를 바로 실행할 수 있습니다.
https://docs.astro.build/en/getting-started/
Getting Started
A basic intro to Astro.
docs.astro.build
소개 동영상: https://www.youtube.com/watch?v=dsTXcSeAZq8
원문: https://dev.to/elliot_brenya/become-a-git-wizard-mastering-the-advanced-git-commands-3he4
"깃타스틱하고, 깃리셔스하고, 아주 깃니피센트!" (역주: fantasic, delicious, simply magnificent) 저는 강력하고 대중적인 버전 관리 시스템인 Git에 대해 이렇게 설명하고 싶습니다. 이는 코드에 마법 지팡이를 사용하여 변경 사항을 추적하고 동료 마법사(또는 개발자)와 협업할 수 있는 것과 같습니다. 이 글에서는 Git 경험을 더욱 마법처럼 만들기 위해 가장 일반적으로 사용되는 Git 주문(명령)과 몇 가지 마법 팁(베스트 프랙티스)이 포함된 포괄적인 Git 치트 시트를 제공할 예정입니다.
먼저 Git 주문을 시전하기 전에 먼저 컴퓨터에 설치해야 합니다. 걱정하지 마세요. 들리는 것만 큼 무섭지 않습니다. 공식 웹사이트(https://git-scm.com/downloads) 에서 최신 버전의 Git을 다운로드하고 지침에 따라 설치할 수 있습니다. 설치되면 터미널 또는 명령 프롬프트를 열고 Git 여정을 시작합니다.
시작하려면 'git init' 주문을 시전하여 새 저장소를 초기화해야 합니다. 이렇게 하면 현재 작업 디렉토리에 .git이라는 새 디렉토리가 생성되며, Git은 코드의 변경 사항을 추적하는 데 필요한 모든 메타데이터와 파일을 저장합니다. 코드를 위한 마법의 상자라고 생각하세요.
이제 몇 가지 기본 Git 주문을 살펴보겠습니다.
아, Git의 주문! 개발자는 이러한 주문을 기억하고 언제든지 사용할 수 있어야 합니다. 이러한 주문은 성공적인 코드 협업 및 관리의 중추입니다. 숙달해야 할 몇 가지 기본 주문을 살펴보겠습니다.
'git add' - 이 주문은 "스테이징 영역"에 새 파일이나 변경 사항을 추가합니다. 코드가 공식적으로 저장소에 합류하기 전에 대기실이라고 생각하세요. 'git add'를 사용하여 특정 파일이나 디렉토리를 추가하거나 'git add'를 사용할 수 있습니다. 현재 작업 디렉토리에 모든 변경 사항을 추가합니다.
'git commit' - 이 주문은 코드에 대한 승인의 최종 도장과 같습니다. 변경 사항을 저장소에 저장하고 나중에 참조할 수 있도록 "커밋 메시지"라는 메모를 남길 수 있습니다. 이 메시지는 커밋 중인 변경 사항에 대한 간략한 설명이어야 합니다.
'git status' - 이 주문은 저장소의 현재 상태를 보여줍니다. 추가, 수정 또는 삭제된 파일과 스테이징 영역에서 대기 중인 파일을 보여줍니다. 이 주문은 올바른 파일을 커밋하고 있는지 확인하기 위해 변경 사항을 커밋하기 전에 시전하는 데 유용합니다.
'git log' - 이 주문은 타임머신과 같습니다. 저장소의 커밋 기록을 볼 수 있습니다. 커밋 메시지 및 작성자와 함께 만들어진 모든 커밋 목록이 표시됩니다. 이 주문은 특정 커밋을 찾거나 코드의 변경 내역을 확인해야 할 때 시전하는 데 유용합니다.
'git diff' - 이 주문은 코드의 현재 버전을 마지막으로 커밋된 버전과 비교합니다. 추가, 수정 또는 삭제된 줄이 표시됩니다. 이 주문은 변경 사항을 적용하기 전에 어떤 변경 사항을 확인하고 싶을 때 시전하는 데 유용합니다.
'git branch' - 이 주문을 사용하면 Git 저장소에서 분기(branch)를 관리할 수 있습니다. 브랜치를 사용하면 동시에 여러 버전의 코드에서 작업할 수 있습니다. 이 주문을 사용하여 새 브랜치를 만들거나 기존 브랜치로 전환하거나 브랜치를 삭제할 수 있습니다.
'git merge' - 이 주문은 한 브랜치의 변경 사항을 다른 브랜치로 병합합니다. 브랜치에서 변경한 사항을 메인 브랜치에 병합하려는 경우에 유용합니다. 이 주문은 소스 브랜치의 변경 사항을 대상 브랜치로 병합합니다.
이제 기본 및 고급 Git 주문을 다루었으므로 한 단계 더 나아가 워크플로를 간소화하고 팀과의 공동 작업을 더욱 원활하게 만드는 데 도움이 되는 몇 가지 고급 Git 명령에 대해 이야기해 보겠습니다.
사용할 수 있는 가장 강력한 명령 중 하나는 'git rebase'입니다. 이 명령을 사용하면 여러 커밋을 보다 일관된 단일 커밋으로 재구성하고 결합할 수 있습니다. 이는 커밋 기록을 정리하거나 여러 커밋을 하나로 스쿼시(압축)하려는 경우에 특히 유용합니다.
또 다른 편리한 명령은 'git cherry-pick'입니다. 이 명령을 사용하면 한 브랜치에서 다른 브랜치로 특정 커밋을 선택적으로 적용할 수 있습니다. 이는 전체 브랜치를 병합하지 않고 한 브랜치에서 다른 브랜치로 특정 변경 사항을 적용하려는 경우에 특히 유용합니다.
디버깅과 관련하여 'git bisect'는 생명의 은인입니다. 코드에서 특정 버그나 문제를 가져온 커밋을 찾을 수 있습니다. 이 명령을 사용하면 코드에서 문제의 원인을 빠르게 식별하고 이전 작업 버전으로 되돌릴 수 있습니다.
때때로 우리는 실수를 하거나 생각을 바꿀 때 'git reset'이 유용합니다. 이 명령을 사용하면 커밋 실행 취소, 파일 수정 취소 또는 브랜치 포인터를 다른 커밋으로 이동할 수 있습니다. 이는 변경 사항을 실행 취소하거나 브랜치 포인터를 다른 커밋으로 이동하려는 경우에 매우 유용합니다.
마지막으로 'git reflog'가 있습니다. 이 명령을 사용하면 리포지토리에서 브랜치 및 참조 업데이트의 전체 기록을 볼 수 있습니다. 이는 리포지토리의 전체 기록을 확인하고 손실된 커밋을 복구하려는 경우 매우 유용합니다.
이러한 명령은 모든 개발자의 무기고에 있는 강력한 도구이며 이를 마스터하면 작업 흐름 및 다른 사람과의 공동 작업에서 큰 차이를 만들 수 있습니다. 그러나 다른 강력한 도구와 마찬가지로 주의해서 사용하고 그 결과를 인식하는 것이 중요합니다. 커밋하기 전에 항상 작업을 테스트하고 다시 확인하십시오. 연습이 완벽을 만든다는 사실을 기억하십시오. 두려워하지 말고 실험을 통해 작업 흐름에 가장 적합한 명령 조합을 찾으십시오. 행복한 깃팅(Git-ting)!
오픈 소스 프로그램 오피스는 회사 내에서 오픈 소스를 지원, 육성, 공유, 설명 및 성장하는 지정된 장소입니다. 이러한 오피스가 있으면 기업은 명확한 용어로 오픈 소스 전략을 수립하고 실행할 수 있으며 리더, 개발자, 마케팅 담당자 및 기타 직원에게 운영 내에서 오픈 소스를 성공시키는 데 필요한 도구를 제공할 수 있습니다.
전통적인 소프트웨어 개발과 오픈 소스 개발의 가장 큰 차이점 중 하나는 오픈 소스에서 사용되는 고도로 협업적인 특성입니다. 많은 기업에서 오픈 소스 사용에 접근할 때 필요한 철학의 변화는 쉽거나 자연스럽게 오지 않습니다.
오픈 소스 프로그램을 만드는 것은 큰 이익이 될 수 있습니다. 오픈 소스 프로그램 오피스를 만들면 회사는 오픈 소스를 직접 회사의 장기적인 비즈니스 계획과 연결하는 방법으로 사용, 최적화하고 조직화할 수 있습니다. 오픈 소스 프로그램 오피스는 회사의 오픈 소스 운영과 구조를 중심으로 하며, 필요한 모든 구성 요소를 합쳐 줄 도우미가 됩니다.
여기에는 코드 사용, 배포, 선택, 감사 및 기타 정책 설정, 개발자 교육, 법규 준수 보장, 커뮤니티 참여 촉진 및 구축이 포함될 수 있습니다. 오피스는 또한 회사 내부 및 외부의 모든 오픈 소스에 대한 옹호 및 커뮤니케이션을 제공할 수 있습니다.
궁극적으로 잘 구성된 오픈 소스 프로그램 오피스는, 전략적 이점을 위해 회사 내부에서 오픈 소스 사용, 기여 및 생성을 촉진할 수 있기 때문에 가치가 있습니다.
성공적인 오피스는 개발자와 팀을 지원하는 프로세스를 구축하여 기업의 오픈 소스 사용에 큰 이점을 줄 수 있습니다. 표준 코딩 및 조직적 관행, 프로세스 및 도구 집합을 권장합니다. 동시에 프로그램 오피스는 창의적 개발자가 어쨌든 우회하거나 무시할 수 있는, 불필요하고 경직된 프로세스를 피하거나 제거하여 프로젝트의 보안 및 기타 측면을 위협할 수 있습니다.
프로그램 오피스의 책임은 다양합니다. 여기에는 다음이 포함됩니다:
모든 회사에서 오픈 소스 프로그램 오피스의 역할은 비즈니스, 제품 및 목표에 따라 맞춤으로 구성될 것입니다. 하지만, 모든 산업 또는 단일 산업의 모든 회사에 적용되는 오픈 소스 프로그램을 구축하기 위한 광범위한 템플릿은 없습니다. 그렇게 하면 생성이 어려울 수 있지만 다른 회사에서 교훈을 배우고 조직의 요구 사항에 맞게 통합할 수 있습니다.
오픈 소스 프로그램의 또 다른 핵심 역할은 사업부가 계획에서 오픈 소스를 고려하기 시작할 때 대화에 실체와 사실을 가져와서 고려되는 이유, 결과 및 결과에 대한 완전한 이해가 있도록 하는 것입니다. 목표를 달성하기 위해 필요합니다. 이해 관계자가 결정을 내릴 때 어디서부터 시작하고 무엇을 생각해야 하는지 알 수 있도록 대화를 구성하는 것이 중요한 경우가 많습니다.
오픈 소스 프로그램 관리자는 자신의 노력에 대한 투자 대비 수익(ROI; Return Of Investement)을 입증해야 합니다. OSPO가 조직이 오픈 소스 프로그램, 프로젝트 및 기여를 평가하는 몇 가지 표준 방법을 정의하는데 어떻게 도움이 되는지 살펴보겠습니다.
측정할 대상, 성공을 정의하는 방법, 이 정보를 바탕으로 오픈 소스 프로그램 목표를 발전시키고 효율성을 입증하며 지원을 얻는 방법을 배우는 것은 모든 OSPO의 중요한 기능입니다.
설정한 목표와 추적하는 지표는 개발자 모집, 개방형 혁신을 통한 새로운 아이디어 및 기술 도입, 시장 출시 기간 단축, 개발 비용 절감, 또는 무수히 많은 다른 이유들이 있습니다.
고유한 전략에 따라 목표를 설정하고 오픈 소스 전략이 전체 비즈니스 전략과 일치하도록 경영진의 동의를 구하는 것이 중요합니다. OSPO는 조직이 이러한 항목에 대해 전략적으로 생각하는데 도움이 되는 중립적인 장소를 제공할 수 있습니다.
숙련된 OSPO 직원은 일반적으로 메트릭(체크리스트)을 작성할 때 다음을 고려합니다.
효과적인 OSPO를 구축하고 실행하는데에는 다른 많은 측면이 있습니다. 사실 너무 많아서 이 시리즈의 이후 과정 모듈에서 이에 대한 전용 섹션과 강의를 제공할 것입니다. 현재로서는 가장 중요한 고려 사항은 오픈 소스 참여의 리더십/참여 사다리를 계속 올라가면서 결국에는 어떤 형태의 OSPO가 필요하다는 것입니다.
전략 및 정책 정의와 마찬가지로 앞서 인용한 '일찍 릴리스, 자주 릴리스'라는 격언을 기억하는 것이 중요합니다. 효과적이기 위해 즉시 수백 명의 직원을 OSPO에 배치할 필요는 없습니다. 조직을 안내하는데 도움이 될 충분한 경험을 가진 오픈 소스 리더와 그들을 도울 수 있는 소규모 직원으로 시작하는 것이 일반적으로 대부분의 조직에 충분한 시작입니다.
잘 작동하는 OSPO는 작은 규모에도 불구하고 효율성을 배가시키는 방식으로 다양한 이해관계자(엔지니어링, 제품 관리, 심지어 경영진까지)를 참여시킵니다. 우리는 차후의 모듈에서 OSPO를 위한 오픈 소스 리더십을 찾고 구축하는 것에 대해 더 많이 이야기할 것입니다.
