숫자들이 모두 음수로만 이루어져 있다면 let 숫자 초기값을 0으로 설정하면 0이 제일 큰수가 되는 문제

진주님 날카로운 지적이시네요! 그럴때는 초기값을 -Infinity 로 만들면 됩니다. 음의 극한이기 때문에 어떤 수를 만나더라도 비교시 더 작은 수로 취급되기 때문입니다 :) 추가 질문이 있으시면 https://discord.gg/QqRrykr5K9 에서 해주셔도 됩니다

질문있습니다

안녕하세요. 먼저 Node.js 가 필수는 아닙니다. 백엔드 스킬 줄에서 자바가 좋으시면 Spring 을 선택하시고, 자바스크립트가 좋으시면 Node.js 를 선택하시면 됩니다. 국내 점유율은 비슷비슷합니다. 프론트도하고 백엔드도 하는게 공부 초기에는 나쁘지 않습니다 ^^ 포트폴리오 만드시기에도 좋구요. 둘 중 어느 방향으로 전문화될지는 시간이 해결해줄겁니다 ^^ 하다보면 어느쪽에 더 흥미가 있는지 스스로 알게되거든요

사용자에게 숫자를 입력받아서 돌릴 수는 없을까요?

추가로 Reference Error가 발생한 이유는 multi_table 함수가 정의되지 않았기 때문입니다. 혹시 다른 포스팅에 있는 코드를 복사해서 가져오셨나요? 그렇다면 multi_table 정의 부분까지 같이 실행 시켜보세요.

사용자에게 숫자를 입력받아서 돌릴 수는 없을까요?

진영님 안녕하세요. 입력을 받기위해 prompt 라는 함수는 잘 사용하셨습니다! inputVar 변수 안에 입력한 숫자가 들어가있을거에요. 이제 해당 변수를 구구단 함수 내에 입력으로 넣어주시면 되겠습니다! 예를 들어..... let 입력한_값 = prompt("값을 입력하세요") 구구단(입력한_값) 이렇게 되겠죠?

이미지 파일 작성 질문드립니다.

안녕하세요 gswork 님. 터미널에 입력하신 `docker build -t jp/say-my-name:1.0` 명령어 마지막에 `Dockerfile` 의 경로를 넣어주지 않아서 나오는 에러로 보이네요. `Dockerfile` 이 있는 디렉토리로 이동하신 후에 명령어 마지막에 현재 경로를 가리키는 `.` 을 넣어주세요. (아래처럼요) `docker build -t jp/say-my-name:1.0 .`

CMD, ENTRYPOINT, RUN에 대해 질문드립니다.

도커의 유용함을 느끼고 계신다니 축하드립니다. 😀 저 또한 CMD 와 RUN 의 쓰임새가 궁금한적이 있었는데요. 먼저 RUN 은 명령어를 실행하고 이미지에 새로운 레이어를 생성합니다. 이는 도커 이미지 용량 & 빌드 시간 최적화에 유용합니다. 강의에서 말씀드린대로 도커는 이미지는 레이어를 층층히 쌓아 올린 개념입니다. 이때 자주 사용되는 패키지를 RUN 명령어로 Dockerfile 에 선언 해두면 해당 패키지까지 설치한 레이어가 생기겠죠. 덕분에 같은 라이브러리를 사용하지만 다른 이미지를 빌드할때 해당 레이어를 가져와 이미지를 빌드할겁니다. 이는 레이어의 재사용성을 높여 이미지 사이즈와 빌드 시간을 줄여주겠죠. 반면 CMD 는 레이어와 아무 상관이 없습니다. 이는 도커가 실행(run) 될때 컨테이너 내부에서 기본적으로 실행하는 명령어를 선언 해두는 역할을 합니다. 질문에 작성해주신것 처럼 파이썬을 실행하거나, gcc 로 빌드한 바이너리 파일을 실행하는 일을 할 수 있겠죠. 여기서 중요한점은 우리가 CMD 명령어를 덮어쓰기(override) 가능 하다는 점인데요. 이를 위해서 docker run 명령어 인자 중에서 [command] 가 존재합니다. (사진) docker run -d busybox echo hello world 이런 식으로 말이죠 :) 따라서 마지막에 RUN 과 CMD 명령어를 바꿔서 사용해도 괜찮냐고 하셨는데, 그건 우리가 작성할 Dockerfile 이 어떻게 작동하길 원하냐에 따라 달라질것 같습니다. 😀 가령 RUN python ./your-daemon-or-script.py 라는 명령어의 결과가 레이어로 캐시가 되고, 이미지를 빌드할때 "언제나" 실행되길 원한다면 RUN 명령어로 사용 하는식으로요. 제 답변이 도움이 됐으면 좋겠습니다.

도커 배포에 관하여 질문드립니다.

네 물론입니다. 도커 데몬과 도커 이미지(애플리케이션)을 둘 다 서버에 배포 한 뒤 도커 데몬 설치 + 도커 이미지 실행 하시면 초록잎님이 말씀하시는 시나리오입니다. 하지만 여기서 중요한 점은 Wine 과 Docker 는 완전히 다른 목적을 가졌다는겁니다. Wine 은 '리눅스에서 윈도우즈 API 호출을 가능케 한다' 라는 목적을 가지고 있습니다. 때문에 윈도우즈 전용 게임(롤)을 리눅스에서 똑같이 구동 할수 있게 해주죠. 반면에 Docker 는 '리눅스 애플리케이션을 다양한 환경에서 구동 가능하게 한다' 라는 목적을 가지고 태어난 놈입니다. 이 때문에 우리가 Wine 과 Docker 에게 기대할수 있는 결과가 달라집니다. 일단 도커로 윈도우즈 전용 게임인 롤은 플레이 불가능할겁니다. 하지만 도커로 게임을 에뮬레이팅 하는 사례는 존재합니다. 예상하셨겠지만 Terminal 방식의 게임이거나, Web 게임을 구동시켜 웹브라우저로 접속해서 플레이하는 방식입니다. https://www.youtube.com/watch?v=LriUAmAkuD8 참고로 보통 도커 데몬은 대부분 클라우드 환경에 설치가 되어있습니다. ㅎㅎ 때문에 '도커 이미지만 서버에 잘 전달 하는것' 을 지속적 배포의 목표로 두죠. 도커 데몬이 설치되어있기 때문에 매니지드 컨테이너 서비스 라고 부를수 있는거고요. (AWS ECS 같은)

도커 배포에 관하여 질문드립니다.

안녕하세요 초록잎님~ 😄 🐥1. 먼저 .exe 파일로 묶는 행위는 바이너리 파일을 빌드한다 라고 볼 수 있습니다. 이는 도커의 관점에서 도커 이미지를 빌드 한 것 과 동일한 행위로 간주 할 수 있습니다. 말씀하신것처럼 소스코드를 포함해서 이미지를 빌드하면, 도커 데몬이 이 이미지를 실행(run) 할 수 있습니다. 이 덕분에 도커 데몬이 설치된 환경에서는 우리가 기대하는대로 애플리케이션이 잘 실행되는겁니다. 정리하자면 도커는 이미지를 빌드해 .exe 와 같은 실행 파일을 만들고 이를 윈도우, 리눅스 관계 없이 도커 데몬이 설치된 환경이라면 환경과 관계 없이 실행된다. 입니다. 🐥2. 클라우드 환경에서 도커는 서버들이 어떤 환경을 가지고 있는지 신경쓸 필요 없이 도커 이미지를 서버가 Docker Hub 에서 다운로드 받고, 도커 데몬이 실행(run) 하면 애플리케이션이 정상 배포됩니다. 이 절차를 자동화된 파이프라인으로 정의해서 지속적인 배포를 구축할 수 있습니다. 하지만 도커가 없는 상황에서 지속적인 배포 파이프라인을 만드려면 고려해야 할 점들이 늘어납니다. 예를 들어 우리의 애플리케이션이 A 라는 라이브러리를 사용한다고 쳐봅시다. 이때 이 A 패키지를 CentOS 환경에서 다운로드 받을 때는 apt-get a-lib 이라는 명령어가 필요하고 Amazon Linux 에서 다운로드 받을 때는 yum install a-library 라는 명령어가 필요합니다. 이 간단한 시나리오에서도 CD 파이프라인의 일관성이 깨지기 시작합니다. 하지만 애플리케이션에 필요한 모든 환경을 담아 놓은 도커 이미지를 생성하고 이를 서버에 잘 전달만 할 수 있다면 지속적 배포 절차가 안정적이며, 간소화될겁니다.

동영상 무한버퍼링...

안녕하세요. 확인해보니 제 디바이스에서는 잘 재생이 됩니다. AWWW 님의 환경을 조금 바꿔서 시도 해보실수 있나요?

이런 메시지가 뜨는데요~

죄송합니다. redis-cli 가 아닌 redis 입니다 ㅎㅎ $ brew install redis