소개
잔재미코딩, Dave Lee
주요 경력: 쿠팡 수석 개발 매니저/Principle Product Manager, 삼성전자 개발 매니저 (경력 약 15년)
학력: 고려대 일어일문 / 연세대 컴퓨터공학 석사 (완전 짬뽕)
주요 개발 이력: 삼성페이, 이커머스 검색 서비스, RTOS 컴파일러, Linux Kernel Patch for NAS
저서: 리눅스 커널 프로그래밍, 리눅스 운영 체제의 이해와 개발, 누구나 쓱 읽고 싹 이해하는 IT 핵심 기술, 왕초보를 위한 파이썬 프로그래밍 입문서
풀스택/데이터과학 관련 무료 자료를 공유하는 사이트입니다.
IT 학습에 도움이 되는 팁/ 짧은 무료 강의를 공유하고자, 조금씩 시작하고 있습니다~
최신 현업과 IT 강의를 병행하며, 8년째 꾸준히 견고한 풀스택과 데이터과학 강의를 만들고 있습니다.
강의
전체11로드맵
전체2수강평
- Lab이 잔재미가 있는 강의 입니다.
yeonhong.min
2024.05.23
1
게시글
질문&답변
2024.05.26
brew로 mysql 설치 후 서버 실행할 때, 터미널에서 anaconda bin 참조하는 문제
안녕하세요. 답변 도우미입니다. 좋은 팁 감사합니다.~
- 0
- 2
- 23
질문&답변
2024.05.26
Database retry 관련
안녕하세요. 답변 도우미입니다. 강의를 잘 듣고 계신다니 기쁩니다! 세션 16에 대한 질문에 대해 상세히 답변 드리겠습니다. docker-compose에서 health check 기능을 통해 컨테이너의 상태를 확인하고 종속 컨테이너의 실행을 제어할 수 있습니다. 이 기능은 컨테이너가 실행 가능한 상태인지 확인하기 위해 매우 유용합니다. 그러나 특정 상황에서는 health check 기능 대신 애플리케이션 로직에서 데이터베이스 retry 기능을 구현하는 것이 더 적합할 수 있습니다. 가볍게 이야기드리면, 도커 자체는 동작 상태 체크가 가능하나, 도커 내의 특정 프로그램이 실제 연결상태가 되었느냐는 체크가 어렵습니다. 이 부분 때문에 retry 기능으로 데이터베이스가 연결가능한 상태가 될때까지 연결시도를 한 것입니다. 이 부분에 대해서 영상에서도 설명드려서, 함께 이해보시면 도움이 되실 것 같습니다. 그 외에 참고할만한 추가적인 이유는 다음과 같습니다: 1. 애플리케이션의 유연성 : - 데이터베이스 연결 시도와 같은 중요한 로직을 애플리케이션 내에서 처리하면, 데이터베이스 연결이 실패할 경우 재시도 로직을 더욱 세밀하게 제어할 수 있습니다. 예를 들어, 재시도 횟수나 재시도 간격을 애플리케이션 요구사항에 맞게 조정할 수 있습니다. 2. 플랫폼 독립성 : - health check는 Docker 환경에 종속적입니다. 하지만 애플리케이션 내에 재시도 로직을 구현하면, Docker를 사용하지 않는 환경에서도 동일한 로직을 사용할 수 있어 플랫폼에 독립적인 코드가 됩니다. 3. 애플리케이션 상태에 대한 세밀한 제어 : - health check는 주로 컨테이너의 외부 상태를 확인합니다. 하지만 애플리케이션 내부에서 재시도 로직을 구현하면 데이터베이스 연결 외에도 다양한 내부 상태를 확인하고 처리할 수 있습니다. 4. 디버깅 및 로깅 : - 애플리케이션 내에서 재시도 로직을 구현하면, 연결 실패 시 원인 분석을 위한 로그를 남길 수 있습니다. 이는 문제 해결에 큰 도움이 됩니다. 결론적으로, Docker의 health check 기능은 컨테이너 상태 확인에 유용하지만, 데이터베이스 연결과 같은 중요한 로직은 애플리케이션 내에서 제어하는 것이 더 유연하고 효과적인 경우가 많습니다. 이러한 이유로 데이터베이스 retry 기능을 애플리케이션 로직으로 구현하는 것이 일반적입니다. 감사합니다. 잔재미코딩 드림
- 0
- 2
- 78
질문&답변
2024.05.24
강의 질문입니다.
안녕하세요. 답변 도우미입니다. 우선은 ID 를 자동으로 보통 생성해주거든요. 관련 설정이 Firebase/Firestore 에서 바꿀 수는 있긴 하지만, 이를 바꾸지 않는다면, 자동 ID 생성이 맞습니다. 그래서 해당 ID 가 '' 이라면 뭔가 비정상동작이긴 하거든요. 이게 어떤 이슈때문에 이렇게 된 것인지 유추하기는 쉽지는 않은데요. 음... 비정상동작은 맞는데, 이게 왜 그런것인지 유추가 어렵네요. 혹시 데이터를 add 할 때, id 값을 직접 넣어주신 것이 아닌지 한번 관련 코드를 검토해보시면 어떠실까요? 직접 넣게 되면, 자동 ID 생성이 안되어서, id 가 '' 와 같이 들어갈 수 있습니다. 이외에 다음 사항도 참고해보시면 좋을 것 같습니다. ID 필드를 직접 설정하는지 확인 : 문서를 추가할 때 ID 필드를 직접 설정하고 있지 않은지 확인하세요. Firestore가 자동으로 생성한 ID는 add 메서드가 호출될 때 생성됩니다. Firestore 콘솔 확인 : Firestore 콘솔에서 문서의 ID가 빈 문자열( '' )로 표시되는지, 아니면 문서 내부의 필드에 빈 문자열이 저장되는지 확인합니다. 두 경우가 다릅니다. 문서의 ID는 Firestore가 자동으로 생성하며, 문서의 필드 중 하나로 ID를 저장하고자 한다면 직접 설정해야 합니다. 감사합니다.
- 0
- 2
- 61
질문&답변
2024.05.24
수업 자료에 pandas_basic 파일이 없습니다..!
안녕하세요. 답변 도우미입니다. 우선 불편을 드려 죄송합니다. 수시로 업데이트를 하다가, 바로 직전 업데이트때 해당 파일이 누락되었었습니다. 그렇지 않아도, 어제 확인하여 업로드를 하였는데요. 다시 다운받아보시면 해당 파일을 확인하실 수 있으실 것 같습니다. 혹시라도 그래도 해당 파일이 없으면, dream@fun-coding.org 로 메일보내주시면 바로 확인하겠습니다. 감사합니다.
- 0
- 1
- 41
질문&답변
2024.05.22
mysql install 문제
안녕하세요. 답변 도우미입니다. 우선 설치가 안되면, 굉장히 센서티브해질 수 있는데, 그래도 이성적으로 이야기해주셔서 감사합니다. 오랜동안 지켜봐왔을 때는 보통 이런 경우, 뭔가 알 수 없는 PC 환경 때문인 경우가 많고, 그러다보니 아무도 이 문제를 해결해줄 수 없는 상황이 꽤 있습니다. 회사 PC 등이라면 보안 처리등으로 더더욱 안될 수 있고요. 그럴 때에는 가장 확실한 방법은 그냥 다른 컴퓨터에 설치해보시는 것입니다. 그러면 깔끔하게 설치되는 경우가 많습니다. 아니면 아예 해당 PC 를 깔끔하게 초기화하고 해볼 수도 있는데, 맥 북이라 이 부분은 고민이 되실 것 같습니다. 어쨌든 뭔가 설치 및 삭제를 여러번 하셨기에 아예 PC 내부에 들어가서 보더라도, 무엇이 진짜 문제인지 알 수 없는 경우가 많고, 어쩌다 될 수는 있는데, 되도 왜 되는지 알 수없는 경우가 많은 것은 우선 이해부탁드립니다. 가볍게 여러가지 참고할만한 사안을 추가로 공유드립니다. MySQL이 "ERROR! The server quit without updating PID file" 오류를 발생시키는 경우, 여러 원인이 있을 수 있습니다. 주로 설정 문제나 파일 권한 문제일 가능성이 큽니다. 아래 몇 가지 해결 방법을 제안드립니다. ### 1. MySQL 설정 파일 확인 MySQL 설정 파일(`my.cnf` 또는 my.ini )을 확인해 보세요. 설정 파일 경로는 일반적으로 /etc/my.cnf 또는 /usr/local/mysql/my.cnf 입니다. 설정 파일에서 데이터 디렉토리 경로와 PID 파일 경로가 올바르게 설정되어 있는지 확인하세요. ```bash [mysqld] datadir=/usr/local/mysql/data socket=/tmp/mysql.sock pid-file=/usr/local/mysql/data/ mysqld.pid ``` ### 2. MySQL 데이터 디렉토리 권한 확인 MySQL 데이터 디렉토리의 소유권 및 권한을 확인하고 올바르게 설정되어 있는지 확인하세요. 다음 명령어를 사용하여 소유권을 변경할 수 있습니다. ```bash sudo chown -R mysql:mysql /usr/local/mysql/data ``` ### 3. MySQL 데이터 디렉토리 초기화 MySQL 데이터 디렉토리를 초기화해 보세요. 다음 명령어를 사용하여 초기화할 수 있습니다. ```bash sudo mysqld --initialize --user=mysql --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data ``` ### 4. MySQL 로그 파일 확인 MySQL 로그 파일(`mysqld.log` 또는 error.log )을 확인하여 구체적인 오류 메시지를 찾으세요. 로그 파일 경로는 일반적으로 /usr/local/mysql/data/mysqld.log 입니다. ```bash tail -f /usr/local/mysql/data/mysqld.log ``` ### 5. MySQL 재설치 MySQL을 완전히 제거하고 다시 설치해 보세요. 다음 명령어를 사용하여 MySQL을 제거할 수 있습니다. ```bash sudo rm -rf /usr/local/mysql sudo rm -rf /usr/local/mysql* sudo rm -rf /Library/StartupItems/MySQLCOM sudo rm -rf /Library/PreferencePanes/My* sudo rm -rf /Library/Receipts/mysql* sudo rm -rf /Library/Receipts/MySQL* sudo rm -rf /var/db/receipts/com.mysql.* ``` 그 후, Homebrew를 사용하여 MySQL을 다시 설치합니다. ```bash brew install mysql ``` ### 6. anaconda 환경 확인 Anaconda 환경 내에서 MySQL을 설치하려고 하는 경우, 경로 문제가 발생할 수 있습니다. Anaconda 환경을 비활성화하고 시스템 기본 경로에서 MySQL을 실행해 보세요. ```bash conda deactivate which mysql ``` ### 7. MySQL 서비스 시작 MySQL 서비스를 시작합니다. ```bash brew services start mysql ``` ### 8. MySQL 초기 설정 MySQL을 처음 설치한 후 초기 설정을 진행합니다. ```bash mysql_secure_installation ``` 감사합니다. 잔재미코딩 드림
- 0
- 1
- 48