OK 괜찮아, 동네 개발자형

Learn for free:

HTML: http://html.com
CSS: http://web.dev/learn/css
JavaScript: http://javascript.info
React: http://reactplay.io
API: http://rapidapi.com/learn

Python: http://learnpython.org
SQL: http://w3schools.com/sql
Git: http://git-scm.com/book
Vue: http://learnvue.co
JavaScript: http://javascriptquiz.com

Nextjs: http://nextjs.org/learn
PHP: http://phptherightway.com
GO: http://learn-golang.org
Open Source: http://markodenic.com/make-your-first-open-source-contribution/
AI: http://elementsofai.com

ML: http://freecodecamp.org/learn/machine-learning-with-python
Web3: http://learnweb3.io
Blockchain: http://cryptozombies.io
Flexbox: http://flexboxfroggy.com
SEO: http://markodenic.com/category/seo

Rust: http://rust-lang.org/learn
Design Patterns: https://refactoring.guru

from: https://twitter.com/denicmarko/status/1611312353500332032

리액트에서 클래스 방식과 함수 방식으로 이전하는 가운데 중요한 훅으로 useEffect가 있습니다. 클래스 라이프사이클 중에 componentDidMount() 뿐만 아니라 componentDidUpdate()까지 useEffect 훅에 포함되어 있어서 onLoad 상황 뿐만 아니라 화면이 바뀔 때마다 useEffect가 동작하게 됩니다. 이는 계속되는 무한 루프를 발동시킬 수 있기 때문에 사용에 주의해야 합니다.

이에 관련된 유트브 영상도 많이 있어 공유합니다.

https://www.youtube.com/results?search_query=useeffect+infinite+loop 

마크다운 포맷의 파일은 개발할 때 많이 사용됩니다.

확장자는 md 입니다. 대표적인 파일이 README.md 입니다. GitHub에서도 이 파일은 렌더링해서 보여주고 있습니다.

HTML은 모두 아실 겁니다. HyperText Markup Language

이게, 태그(마크)가 많아서, 글쓰기에 필요한 것만으로 줄여서 Mark Down 이라고 명명.

Daring Fireball이 제가 처음 본 글이었습니다. http://daringfireball.net/projects/markdown/syntax#philosophy

저도 md로 문서를 많이 쓰고, 커밋하지만, 자주 사용하는 것은 10개도 안 될 정도입니다.

# : 제목
## : h2
### : h3

`code` : code 또는 명령어

```
multi
lines
```

[링크 제목](https://...) : 링크

 : 이미지

마크다운의 치트키는 기존 html 태그 모두 사용 가능하다는 것도 빼놓을 수는 없습니다.

번역체로 공유합니다.
from: https://dev.to/eoeboh/open-source-101-for-beginners-30af

===

여러 셰프가 주방에서 맛있는 식사를 조리하고 수석 셰프가 이 식사를 감독한다고 상상해 보세요. 누구나 더 많은 재료나 음식을 추가하고, 나쁜 맛을 바로잡고, 식사 요리에 대한 더 나은 아이디어를 제안함으로써 식사를 수정할 수 있습니다.

이 설정에서 누구든지 먼저 식사의 정확한 샘플을 채취하고 수정한 다음 감독 셰프에게 샘플을 제출하여 잠재적으로 실제 식사에 추가할 수 있도록 식사에 기여할 수 있습니다.
그러나 식사에 포함될 모든 샘플은 수석 셰프와 몇 명의 추가 감독 셰프의 승인을 받아야 합니다.

위 상황은 소프트웨어 개발에서 오픈 소스의 개념을 정의합니다.

• 식사는 구축 또는 유지 관리 중인 제품 또는 소프트웨어를 나타냅니다.
• 헤드 셰프는 프로젝트의 소유자 또는 작성자를 나타냅니다.
• 감독 셰프는 프로젝트의 관리자 입니다.
• 기여자는 당신과 나를 포함하여 누구나 될 수 있습니다.

이제 비교 가능한 실제 일러스트레이션이 있지만 실제로 오픈 소스 프로젝트란 무엇입니까?

오픈 소스 프로젝트란 무엇입니까?

간단히 말해서 오픈 소스 프로젝트는 대중에게 공개되어 누구나 검사, 사용, 수정 및 배포가 가능한 소스 코드가 포함된 소프트웨어로 정의할 수 있습니다.

이제 오픈 소스가 무엇인지 이해했습니다. 오픈 소스 환경에서 사용되는 용어와 그 의미를 살펴보겠습니다.

오픈 소스 용어

이 시점에서 할당된 역할과 일반적인 오픈 소스 프로젝트에서 사용되는 용어를 살펴보겠습니다.

오픈 소스 프로젝트에서의 역할

1. 작성자: 프로젝트 작성자입니다. 프로젝트는 저자가 설정하고 감독합니다. 그들은 프로젝트 유지를 돕기 위해 다른 기여자에게 새로운 역할을 할당하는 것과 같은 작업을 수행할 수 있는 권한이 있습니다.
2. 관리자: 프로젝트를 이끌고 프로젝트의 목표 또는 비전이 달성되도록 하는 책임이 있습니다.
   그들은 일반적으로 검토, 풀 리퀘스트 승인/거부, 문제 할당, 프로젝트 행동 강령 유지, 잠재적인 개선에 대한 토론 주도 등의 권한을 가집니다.
3. 기여자: 이들은 오픈 소스 프로젝트에서 기능을 추가하거나 버그를 수정하고 열린 문제와 토론을 하는 사람들입니다. 그들은 이러한 작업을 수행할 때 규정된 지침을 따릅니다.
4. 커뮤니티 회원: 오픈 소스 프로젝트를 사용하고 유지 관리하는 사람들입니다. 귀중한 피드백을 제공하고, 버그를 보고하고, 프로젝트에 기능을 제안합니다. 커뮤니티는 오픈 소스 프로젝트를 주도하는 것이며 기술 및 비기술 인력으로 구성됩니다.

오픈 소스 용어

• ReadMe 파일: 오픈 소스 프로젝트를 소개하고 설명하는 텍스트 파일입니다. readme 파일에는 프로젝트에 기여하는 방법에 대한 지침, 프로젝트 행동 강령, 지금까지 기여자 목록, 프로젝트 라이선스 등과 같은 항목이 포함되어 있습니다.
  오픈 소스 readme 파일의 좋은 예는 ReactPlay의 readme 입니다.
• 기여(Contributing) 지침: 여기에는 개발 환경 설정, 필요한 종속성 설치, 끌어오기 요청 방법 등을 포함하여 해당 프로젝트에 기여하는 방법에 대한 단계별 설명이 포함됩니다. 기여를 시작하려면 프로젝트의 기여 지침을 확인하는 것이 중요합니다.
• 행동 강령(Code of Conduct): 일반적인 오픈 소스 프로젝트에는 행동 강령이 포함되어 있으며, 이는 프로젝트 참여자 간에 규칙, 규정 및 예상되는 행동을 설정하는 문서로 가장 잘 설명됩니다. 행동 강령을 시행하면 프로젝트 내에서 포용적인 커뮤니티를 육성하는 데 도움이 됩니다.
• 이슈: 이슈는 기능을 제안하고, 버그를 보고하고, 토론을 주최하기 위해 열리는 티켓입니다. 일반적으로 기여자가 작업을 시작하기 전에 먼저 이슈를 설명하는 항목을 열어야 합니다(또는 기존 이슈를 확인). 그런 다음 유지 관리자는 일반적으로 이슈를 기여자에게 할당합니다.
  또한 이슈에는 난이도, 진행 상태 및 사용 가능 여부를 설명하는 레이블이 함께 표시될 수 있습니다.
• 풀 리퀘스트: 풀 리퀘스트는 검토가 필요한 변경 사항에 대해 다른 사람에게 알릴 수 있는 작업입니다. 따라서 기여자가 풀 리퀴스트를 열면 관리자와 다른 기여자가 제안된 변경 사항을 검토하고 논의하고 수정 사항이 있으면 논의하고 만족스러운 경우 풀 리퀘스트가 기본 소스 코드에 병합됩니다.
• 라이선스: 모든 오픈 소스 프로젝트에는 라이선스가 필요합니다. 오픈 소스 라이선스가 없으면 소스 코드는 GitHub에 공개적으로 게시된 경우에도 다른 사람이 사용할 수 없습니다.
  라이선스는 소프트웨어로 수행할 수 있는 작업과 수행할 수 없는 작업을 설명합니다. 널리 사용되는 오픈 소스 라이선스의 예로는 MIT , Apache 라이선스 , Mozilla Public License 등이 있습니다.

오픈 소스를 시작하는 방법

첫째, 오픈 소스 기여는 코딩 기술만 있는 사람들에게만 국한되지 않는다는 점에 주목하고 싶습니다. 실제로 대부분의 오픈 소스 프로젝트에는 문서 작성, 오타 수정, UI/UX 디자인, 심지어 언어 번역이 필요합니다.

기여할 새로운 오픈 소스 프로젝트를 검색할 때 주의해야 할 특정 작업이 있습니다.

• 라이선스를 확인하십시오. 프로젝트에 MIT와 같은 허용 가능한 라이선스가 있으면 소스 코드를 자유롭게 수정하고 기여할 수 있음을 의미합니다.
• 프로젝트에서 어떤 기술 스택이 사용되고 있는지 확인하십시오. 예를 들어 Python만 사용한다면 오픈 소스 Python 프로젝트에 기여하고 싶을 것입니다. Swift 또는 C#을 기반으로 하는 프로젝트는 적합하지 않습니다.
• 프로젝트 커뮤니티가 얼마나 포용적이고 친근한지 관찰하십시오. 초보 기여자는 말할 것도 없고 새로운 기여자를 환영하지 않는 일부 오픈 소스 프로젝트가 있습니다. 이러한 프로젝트는 첫 번째 오픈 소스 기여를 검색할 때 피하는 것이 가장 좋습니다.
• 프로젝트에 좋은 readme 파일과 기여 지침이 있는지 확인하십시오.
• 리포지토리의 활동 수를 확인하십시오. 마지막 커밋이 언제였습니까? 토론은 얼마나 자주 수행됩니까?
• 메인테이너가 열린 이슈 또는 풀 리퀘스트에 응답하는 시간을 확인합니다. 관리자가 응답하는 데 너무 오래 걸리는 프로젝트는 시작하기에 적합하지 않을 수 있습니다.

대부분의 활성 오픈 소스 프로젝트에는 프로젝트 토론, 커뮤니티 호출이 자세히 이루어지는 Discord 또는 Slack 채널이 있습니다. 채널에 가입하고 새로운 기여자로 자신을 소개하는 것은 특히 비코딩 기여자를 위해 프로젝트에 참여하는 좋은 단계입니다.

활성 Discord/Slack 채널은 그러한 프로젝트가 환영하고 포용적이라는 좋은 표시입니다. 디자이너, 기술 작가, 프로젝트 관리자와 같은 비코딩 기여자의 경우 채널은 참여, 공유 및 기여를 전달하는 가장 좋은 방법입니다.

기여할 오픈 소스 프로젝트를 찾는 방법

기여할 첫 번째 오픈 소스 프로젝트를 찾는 데 도움이 되는 사이트는 다음과 같습니다.

• Up For Grabs
• First Timers Only
• 24 Pull Requests
• Open Source Friday
• Hacktoberfest
• Good First Issues

오픈 소스의 모범 사례

오픈 소스에서 삽질하는 것은 훌륭한 단계이지만 훨씬 더 나은 방법으로 작업을 수행하는 방법을 아는 것은 모든 프로젝트에 귀중한 기여자가 될 것입니다. 참고해야 할 몇 가지 모범 사례는 다음과 같습니다.

• 좋은 사람 기술과 의사 소통
• 새로운 이슈를 열기 전에 유사한 이슈에 대한 기존의 열린 이슈를 확인하십시오.
• 이슈에 대한 이슈를 생성하고 작업을 시작하고 풀 리퀘스트를 제출하기 전에 할당을 기다립니다.
• 모든 이슈에는 복잡성 또는 난이도 수준을 나타내는 레이블이 있어야 합니다.
• 이슈가 할당되는 즉시 최대한 빨리 작업을 시작하고 풀 리퀘스트를 제출하세요.
• 항상 프로젝트 관리자가 설정한 기여 지침을 따릅니다.
• 이미 다른 기여자에게 할당된 이슈에 대한 작업을 피하십시오.
• 작업할 수 있을 만큼 자신 있는 이슈를 항상 맡습니다.
• 풀 리퀘스트를 제출하기 전에 모든 충돌을 해결하십시오.
• 설명적인 커밋 메시지 작성
• 한 번에 1~3개 프로젝트 사이의 몇 가지 오픈 소스 프로젝트에만 집중하십시오.

인기 있는 오픈 소스 프로젝트

GitHub에서 인기 있는 많은 오픈 소스 프로젝트를 이 링크 에서 찾을 수 있습니다 .

결론

오픈 소스는 기술적 배경이나 기술 수준에 관계없이 모든 사람을 위한 것입니다. 또한 오픈 소스는 기술 향상, 필요한 경험 제공, 팀워크 및 협업 기술 향상, 네트워크 성장 및 잠재적인 일자리 확보와 같은 많은 이점을 제공합니다.

from: https://dev.to/eoeboh/open-source-101-for-beginners-30af

1946년 ENIAC(Electronic Numerical Integrator And Calculator)이 만들어지면서, 컴퓨터가 세상을 바꾸기 시작했습니다.

이렇게 생겼죠. 컴퓨터 한 대의 부피가 매우 큽니다.

이런 컴퓨터를 움직이는 방법이 프로그램입니다. 컴퓨터가 하는 일이 세상을 계산하는 것이기 때문에 프로그래밍이 쉽지 않습니다. 세상이 쉽지 않기 때문입니다.

인터넷이 1990년에 시작되면서 네트워킹으로 인한 컴퓨터의 발전은 가속되었고, 이커머스, 온라인 게임, SNS 등으로 세상은 점점 사이버 세상으로 이주하는 것이 트렌드가 되었습니다. 오프라인에서 만나서 해야했던 일들이 온라인으로 가능하게 변하고 있는 것입니다.

세상이 단순하지 않기 때문에, 세상을 사이버 세상으로 옮기는 작업은 쉽지 않다고 생각합니다. 그래도 많은 프로그램들이 세상에 영향을 주고 있고, 이런 일을 하는 것은 의미가 있습니다.

1. 클린 코드(Clean Code): 누구나 읽기 좋고 깨끗한 코드를 짜고 싶어 합니다. 하지만, 시간적인 제약, 조직의 룰, 개인의 취향에 따라 클린 코드를 짜는 것이 이상적인 가치가 되어 버렸습니다. 그래도 세상이 많이 좋아진 덕에 클린 코드 가이드를 쉽게 접할 수 있습니다. SonarLint(https://www.sonarlint.org) 플러그인을 설치하면 개발 도구에서 어떤 점을 수정해야 할 지 가이드를 볼 수 있습니다.

2. 다독 다작 다상량(多讀 多作 多商量): 에디슨이 말한 "99%의 노력과 1%의 영감으로 천재"의 습성은 쉽지 않은 명언입니다. 동양에서는 운70% 기30%라고 조금 상반되는 숫자를 얘기합니다. 그래서 30% 만이라도 사기를 올릴 필요가 있다고 생각합니다. 구글, 스택오버플로우, GitHub Copilot, ChatGPT가 코딩에 필수(?)인 세상이지만, 인터넷이 끊긴 상황에서도 짜고 싶은 코드를 짜는 실력이 필요합니다. 그것이 진정한 프로그래머의 실력이 아닐까 라고 생각합니다. 오픈 소스에서 중요한 것은 코드를 보고 맥락을 이해한 다음에 코드를 수정하는 일입니다. 많이 읽고, 많이 짜보고, 많이 회고하는 작업은 코드를 짤 때 매우 좋은 습관입니다.

3. 팀 개발 가이드(Team Dev Guide): 한반두와 손흥민의 차이점은 개인과 팀입니다. 자기 중심으로 프로젝트를 진행할 것인가, 팀과 협력하며 할 것인가의 차이입니다. 함께 일하면 궁합(이라고 쓰고 손발이 맞아야 라고 읽음)이 잘 맞아야 스트레스를 덜 받습니다. 프로젝트 개발 가이드가 제공이 되고, 팀원들의 기호에 따라 수정하면서 공감대를 형성하면, 사소한 것(이라고 할 수도 있지만 민감한 스타일)에 킹받지 않고 개발이 가능합니다. 

2023년 새해 복 많이 받으시길 바랍니다.

MVC 패턴은 웹 개발자라면 다 알고 있는 패턴입니다.

아이폰, 안드로이드폰이 등장하면서 Data는 서버가, 화면은 네이티브 앱이 책임지는 구도로 변했습니다.

웹페이지를 만들어 내던 서버 사이드 렌더링 작업을 바꾸면 어떨까 하는 생각에 등장한 것이

서버에서 보내주는 JSON 데이터를 이용하는 자바스크립트앱을 만들자 

이렇게 태어난 기술이 Angular, React, Vue, Svelte입니다.

리액트 관련 속성과외 자료 공유합니다.

https://bit.ly/okreact2022 

올 상반기 발표 자료입니다. 이클립스 기반으로 되어 있습니다.
https://bit.ly/oktdd2022 

* 개발환경 세팅
* Getting Started TDD
* TDD Concept
* TDD Misunderstood
* Test 단계와 유형
* assert 종류
* 리팩터링
* Maven