진실의 방

내 첫 프로젝트인 위벅스 미션2에서 궁금증이 생겼던 것을 한 번 해결해 봤다. 아래는 코드와 더불어 의문의 쟁점이다. 안녕하세요 제가 지금 위벅스 미션 2를 진행중인데, 현재 기능 구현은 되는 상태입니다만, 의문이 드는 점이 있어 질문드려 봅니다.해당 코드에서 지금 l

\-> 그냥 봤을 때는 잘 정렬된 것처럼 보인다... 하지만, 밑에 보이는가? 3째 줄부터 뭔가 어긋나기 시작했다... 처음 구상을 전혀 안한 것은 아니다!!!! 구상이 이렇게 될 줄 몰랐을 뿐.... 문제는 코드에 있었다. 현재 코드를 보면, 커피 이미지들을 div로

드디어 플렉스 신 민호님의 강의를 듣고나서, 이제 다시 나도 전체적인 구상을 다시 시작했다. 이미지 전체를 박스로 묶고 각 이미지에 박스 컨테이너 디브로 묶고 랩을 줘 봤다. 위의 코드처럼 디브 클래스 coffee menu로 주고, 전체 이미지를 묶고, 그 안에서

지난 편에 이어 이제 마지막 회차다. 전에 1편에서 분명 이미지 후버에도 마진으로 조정한 것들이 영향을 미쳤다고 했다.

여러분 안녕하세요~ 간만에 포스팅이라 좀 어색하네요... 이번에는 제가 플젝을 하면서 느낀 새로운 고찰에 대해 얘기해 보는 진실의 방 시리즈를 연재해 보려고 합니다. 바로 이번 주제는 플렉스 그리드입니다. 자~ 자~ 제가 이번에 왜? 어쩌다가? 플렉스 그리드를 다시 살

저번 편에서 발단에 대해 설명 드렸다. 이번 편부터는 본격 그리드에 대한 고찰에 대한 시간이다. 그래서 기존html에서는 플렉스 랩을 통해 이미지 파일을 배치 시켰었다. 이렇게 하나의 컨테이너 안에 이미지를 배치시키고 각각의 이미지 컨테이너 안에서

지난 시간에 이어 이번에는 본격적으로 그리드가 무엇이며 우리가 왜 쓰는 지에 대한 이해를 해 볼 예정이다. 그 이후 내가 해당 프로젝트를 하면서 그리드를 어떻게 사용했는 지 플렉스와 직접 구현된 것의 차이를 살펴보도록 하겠다.

자~ 이전 편에 이어 이번 편은 어떻게 그리드를 적용시켰는 지 직접 보여드리겠다. css의 레이아웃은 어떤 것보다 화면 구성이 중요하다는 것을 깨달았기에... 이번에도 역시 레이아웃 구성 작업부터 실시했다. 먼저 그리드의 구성 속성인 격자 속성에 따라, 본질적으로 그리

이번 시간에는 목 데이터와 우리가 흔히 사용하는 맵 메서드의 고찰을 한 번 해볼까 합니다. 저 역시 이번 프로젝트에서 미션 0번까지 마친 후에 다시 미션 1을 진행하면서 이 부분에 대한 어려움과 여러 가지 시도와 실패가 있었기에 그에 대해 한 번 적어보고자 한다. >

지난 테스트를 통해 굉장히 우숩게 생각한 깃과 깃허브에서 부족함을 많이 느꼇다.... 그래서 원래 다 만든 것들을 여러 번 지우기를 반복. 이대로는 안 되겠다 싶어 깃과 깃허브의 내용을 정리해 둔다. 내용의 순서는 기본적인 깃과 깃허브의 정의 및 진행 방법 그리고 중간

필자는 금요일에 깃 테스트를 보면서 뭐 별거 있겟나 싶었다. 하지만, 깃 테스트를 통해 내가 얼마나 깃에 대해 무지했는 지 다시 한 번 느낄 수 있었다. 다음 내용은 내가 깃 테스트를 보면서 마주한 에러와 그에 대한 해결책 위주로 담았다. 이로 인해 느낀 바와 더불어

다시 간만에 돌아온 진실의 방 시리즈. 이번에는 필자가 mysql에서 테이블을 만들고, 데이터를 삽입하면서 겪었던 문제에 대해 이야기해 보고자 한다. 사실 백엔드를 하면서 직접 db를 터미널 상에서 표로 만들 수 있다는 사실에 정말 신기하고 재밌었다. 하지만, 하나씩

필자는 데이터 삽입까지 저렇게 잘 헤나가고 있었다. 그런데... 문제가 생기고 만다. 아래는 필자가 실제 미션을 진행하면서 겪은 문제다. 오잉? 왜? 갑자기 아이디 값이 저렇게 되었나? 아.... 안돼!!!!! 내 테이블을 돌려 놓아라ㅜㅜ 과연 어떻게 된 일일까? 사

이번 포스팅은 백엔드 개발자라면 한 번은 겪는 db 데이터 날림에 대한 얘기가 되겠다. 필자 역시, 갓 프리즈마라는 것을 배우고 이제 마이그레이션을 시작한 시점에 벌어진 일이기에... 매우 당황했지만, 그 다음날부터 갖은 시도와 노력으로 이럴 때 어떻게 스스로 대처할

이런.... 이런..... 그렇다... 필자는 그렇게 db 데이터 날림의 시련이 또 찾아올 줄은 몰랐다. 하지만, 역시나 그런 오류는 반복되고, 언젠가는 다시 마주할 것이었다. 물론 이렇게 빨리 찾아올 줄은 몰랐지만... 다음 날, 새로운 db에 데이터를 비워둔 채로

자~ 이제 드디어 마이그레이션의 최종화다. 필자는 데이터를 이전 화에서처럼 잘 넣었고, 이제 본격적으로 스퍼트를 나서고 있었다. 그런데....하필이면, 다시 그 녀석을 마주했다. √ Drift detected: Your database schema is not in s

저번 포스팅에서 언급했듯 아쉬움이 남았던 부분을 해소하기 위해 프론트와 진짜로 백의 통신을 시도했다. 먼저, 어떤 통신을 할 지 고민했다.기존 백엔드 단에서 포스트맨을 통해 회원가입을 했으니, 이번에는 로그인을 해봣다.그런데, 단 2주만에 프론트 단에서 배운 패치 함수

그렇다. 또 찾아왔다. 에러 ㅋㅋㅋ사실 지난 번까지만 해도 통신에는 문제가 없어 보였다. 하지만, 변수가 하나 발생하고 만 것. 분명 가입된 db의 아이디로 로그인 시도를 했는데...그랬다. 로그인이 안 되었다. 그래서 개발자 도구를 열어보니, 저렇게 쫘악 찍찍 빨간

이건 마치 ET의 한 장면이었던 순간같이 느껴졌다. 기존에는 프론트 단에서만, 혹은 백엔드 단에서만 분리되어 작업했었다. 하지만, 이제는 내가 직접 만든 프론트 화면에서 통신 요청을 보내 내가 만든 서버와 연결시켜 데이터를 받아온다는 것이....진짜 되는 구나?!

3탄 포스팅에서 비밀번호가 인풋 창에서 한글 설정에 대한 의문이 남았었다. 그래서 이 부분을 위코드 커뮤니티에 올려 봤다. 그래서 이번 포스팅은 그 질문에 대한 내용과 답변으로 어떤 건설적인 내용들이 오고 갔는 지에 대해 한 번 적어보고자 한다. 이번에는 제가 기존에

우리의 첫 프로젝트의 힘든 첫 여정이 시작되었던 어제. 생각보다 빨리 끝날줄 알았던 초기셋팅.... 하지만

필자는 지금 팀 프로젝트 진행 중에 새로운 깃의 늪 속으로 빠져있다. 그래서 이제는 깃에는 탄의 개념을 안 붙이겠다 ㅋㅋㅋ 그냥 마치 위의 게임과 같은 느낌이라고 보면 되겠다. 끝이 없는 계단의 끝을 향해 하나씩 올라가는 느낌... 물론 끝은 있겠지만, 러닝 커브

필자가 1차 프로젝트 프론트 코드 작성 중 발견한 무지함에 대해 풀어보고 싶어, 컴퓨터 자판에 손을 올렸다. 그렇다. 이 말 너무 와 닿는다. 마치 나를 두고 하는 말인가 싶을 정도로... 필자는 일단 상품 리스트 페이지 ui를 만드는 과정에 임했다. 생각보다 빨리 백

드디어. 3주 간 우리 팀의 노력이 담긴 최종 결과물을 세상에 공개하는 시간이다. 처음 배포를 하다보니, 여러 시행 착오를 참 많이 겪기도 했다. 이번에는 그때 겪었던 이야기들을 한 번 적어보겠다. 사실 aws 셋팅하는 것에는 큰 어려움은 없었다. 멘토분들이 가이드 해

이번 2편은 1편에 이어, 예고했듯이 백엔드 단에서 문제 해결을 중점으로 기술하겠다. 이전 편에서 npm run distribute 시에 아래와 같은 오류가 발생한다고 했다. 이번에는 생각보다는 그렇게 어렵지 않게 해결할 수 있었다. 이전 시리즈에서 언급했듯이 필자와

이번 3편은 배포 가이드에 추가된 일부 내용과 더불어, 필자의 최종 배포 소감으로 간단히 마무리 짓겠다. 01) front repo 💡 백엔드 API 엔드포인트에 대한 설정을 해줍니다. 현재는 localhost:8000이 들어가있지만 추후에 ec2의 ip 및 포트