Jay의 기술 블로그

원래는 각 직원 한 명당 사진 1개씩으로 정해졌지만 갑자기 한 사람당 여러 사진들을 업로드하는 기능이 있었으면 좋겠다고 한다. 자꾸 말 바꾸면 기간만 길어지고 개발진행에 방해가 될거같다고 했다. 예상은 하고 있었다. 결국 알겠다고 바꾸기로 했다. 그러면 아마존 버킷에 각 직원별로 폴더가 생겨야 할것이고 각 폴더에 동적으로 원하는 만큼의 이미지 또는 파일들이 올라가게 될 것이다. 오래 걸릴거 같다고 했는데 2시간만에 끝내버렸다. 제일 먼저 규칙을 정했다. 버킷내에 폴더 명 규칙은 Last Name + First Name + SSN Number (소셜넘버) 으로 정했다. 처음에는 그냥 소셜 넘버만으로 폴더를 만들기로했는데 생각해보니까 버킷을 열었을 때 가독성이 좀 떨어질 것 같아서 이름까지 넣기로했다. 이름..

Cache는 속도가 빠른 곳에 임시로 데이터를 저장하여 속도를 높이는 것을 뜻한다. Web cache란? 네트워크를 통해 어떤 것을 가져오는 작업은 시간과 비용이 발생하게 된다. 크기가 큰 응답은 client와 server사이에 많은 왕복이 필요하다. 그래서 많은 사용자가 사용할 경우 시기가 지연되게 된다. 그래서 이전에 가져온 resource를 cache를 했다가 재활용하는 방법이 성능 최적화에 있어서 중요하다. 웹 캐시의 종류 1. Browser Cache브라우저 또는 Http 요청을 하는 클라이언트측 application의 내부 디스크브라우저의 back button을 눌렀을 때 2. Proxy Cache프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는..

매장별로 Pos기가 있는데 손님들이 계산하면서 볼 수 있게 사진을 띄우고 싶으셨다. 이건 Cashier 가 보는 시선이다. Cashier가 물건을 하나씩 찍으면 고객이 반대편 화면에서 찍히는 가격들을 보게 된다. 이게 고객들이 보는 반대편 화면이다. 저 오른쪽에 까만 화면을 통해 고객들에게 상품을 홍보 하고 싶어했다. 그럼 고객들이 cashier가 물건을 하나씩 찍을 때 물건들의 정보를 자연스럽게 볼 수 있는 구조이다. 이건 다른 매장 pos기 사진이다. Atlanta에 7개의 multi store가 있다. 그리고 매장 별로 고객 화면에 보여지는 사이즈가 다르다. 이건 POS기 Manager 프로그램인데 여기서 Display에 띄워지는 파일들을 관리한다. 웃긴게 html하나당 image가 하나씩 mapp..

프로젝트를 하면서 드는 생각들... 제일 무서운 생각은 무너지진 않을까... 점점 건물이 높아짐에 따라 가끔씩 휘청거린다. 그럴 때마다 매우 조심스럽게 행동한다. 당연히 기본 뼈대가 튼튼해야 건물이 견고해진다. 이 사실을 인지함에도 뭔가 급한 마음에 막 빨리 쌓으려고 했다. 한 눈에 보이지 않는 코드... 정리가 되어 있지 않은 문맥들... 그래 쌓을 수는 있다. 하지만 수리할 때 문제가 생긴다. 어떤 기능이 어디에 있고 어느 부분을 고쳐야 하는지 바로 보이지가 않는다. 어제의 나와 오늘의 나는 다른 사람인 것을 예전부터 알고 있었다. 어제 분명히 어떤 feel을 받아서 정신없이 코드를 치고 돌아가는 것을 확인했다. 다음날 내가 와서 보면 그건 전혀 내가 한것처럼 느껴지지 않는다. Structure가 중..

처음 프로젝트 요구사항 중 직원들의 특이사항을 그 자리에서 바로 핸드폰으로 찍어서 올리고 싶다는 것이었다. 예를들면 그 직원이 일하는 모습 또는 특정한 문서 사진 또는 기타 필요한 사진들을 말이다. 말처럼 뚝딱 되면 얼마나 좋을까. Project Plan을 줄 때 이 부분을 제일 길게 잡았다. 까다로운 만큼 오래 걸릴것 같았다. 이미지 처리에 있어서 저장소에 실제 파일이 저장되지만 데이터베이스에는 경로와 이름 사이즈 메타데이터 등 정보를 넣어야 하기 때문이다. 사실 조금 꼬인게 처음에 얘기를 나누었을 때 말한 기간안에 이 기능을 구현하지 못할것 같다고 했었다. 그래서 데이터베이스를 설계할 때 이미지 관련해서 테이블을 만들지 않았다. 그런데 할 수 있을 것 같아서 도중에 할 수 있다고하여 기능을 구현 중이..

개발 과정에 있어서 많은 어려움들이 있었다. 에러 하나 터지면 수습하는데 얼마나 걸릴지 몰라 프로젝트 기간을 확실히 말을 하지 못했다. 원래 프로젝트는 due date을 정해놓고 에러가 터지면 그날 집에 가지 못하는 사이클을 경험했었지만 회사 자체가 야근을 싫어하고 미국에서의 work & life balance를 경험하고 싶었기 때문에 길게 잡았다. 그래도 재촉하기 떄문에 차분히 정리할 경황이 없었다. 포스팅 또한 정신이 없겠지만 중요하게 생각하는 과정과 에러해결 과정을 나열해 보겠다. 일단 Maven상에서 에러가나서 Package UI상에 빨간 엑스표시가 뜨는 문제이다. 지금은 안나오지만 저 프로젝트 그림 밑에 엑스표시가 나는 경우가 있다. 밑으로 dept를 쭉 펼치면 에러 tracking이 된다. 하..

미국에 온지 벌써 3달이 다 되어간다. 그 간 많은 일들이 있었고 힘든 일도 많았다. 생활 면부터 회사 문제까지도... 무엇보다 주위에 내 사람들이 없다는 것이 가장 힘들었다. 하소연하고 들어줄 사람이 없다는 것이 느껴본 경험이 없어서 그런지 더욱 서럽기도 하였다. 하지만 이제 괜찮다... 직속상관이 문제가 있어서 회사에 한동안 없어서 일을 시킬 사람이 없었다. 나는 회사 웹사이트 관리로 인턴을 온 것이고 시킬 사람들이 없었다. 처음에는 sns와 마케팅을 했다. 포토샵을 하면서 포스터를 만들고 업로드를 하였다. 그런데 마케팅과 경영 지식이 없어서 잘 하는지는 몰랐지만 그냥 그렇게 있었다. 직속상관이 오고 나서부터 일이 생겼다. 하지만 그는 전공자가 아니다. 나는 사장이 전공자가 아닌 회사에서 단기로 개발..

서버리스 모듈은 AWS Lambda와 Amazon Dynamo DB라는 것을 사용하여 웹 어플리케이션의 요청을 처리하는 백엔드 프로세스를 빌드한다. 이 동작은 브라우저에서 Javascript가 클라우드에서 실행되는 서비스를 호출해야 한다. 사용자가 유니콘을 요청할 때 마다 호출되는 람다 함수를 구현한다. 이 함수는 Amazon API Gateway를 사용하여 브라우저에서 호출된다. * Amazon Dynamo DB 테이블 만들기 1. AWS Management 콘솔에서, DynamoDB를 선택한다.2. Create table을 선택한다.3. Table name을 입력한다.4. Partition Key 이름을 설정하고 String 타입을 선택한다.5. Use default settings 체크박스를 선택하..

아마존에서 제공하는 Cognito는 user pool이라는 것을 만들어서 사용자의 계정을 관리한다. 고객이 새 사용자로 등록하고 이메일 주소를 확인하고 사이트에 로그인할 수 있는 웹 페이지를 배포한다. 사용자가 웹 사이트를 방문해서 사용자 계정을 등록한다. 직접 구현하지 않고 Amazon Cognito가 자신의 응용프로그램에 추가 속성을 요구하도록 할 수 있다. 사용자가 등록을 완료하면 Cognito는 확인 코드가 포함된 검증 이메일을 사용자의 이메일로 보낸다. 계정을 확인하기 위해서 사용자는 사이트로 돌아와 이메일주소와 받은 인증코드를 입력한다. 사용자가 확인한 계정이면 로그인을 할 수 있다. Javascript함수는 Amazon Cognito와 통신하고, Secure Remote Password pr..

이 모듈의 아키텍쳐는 HTML, CSS, Javascript, 이미지 및 기타 파일을 포함한 정적 웹 컨텐츠를 S3에 저장하는 것이다.결과적으로 사용자는 S3에 공개된 웹 사이트 URL을 사용하여 사이트에 액세스 한다. 사이트를 사용할 수 있게 하기 위해서 웹 서버를 실행하거나 다른 서비스를 사용할 필요가 없다. 이 URL은 엔드포인트 URL을 사용하게 된다. * S3 만들기 1. AWS Management Console에서 Service를 누른다음 S3를 선택한다.2. Create Bucket을 누른다.3. 버켓 이름은 전 세계적으로 고유한 이름으로 설정한다.4. 리전을 선택한다.5. Create * 웹 사이트의 컨텐츠 업로드 하기 S3 버킷에다가 드래그 앤 드롭으로 웹사이트 파일들을 올릴 수 있다. ..