퍼블리

퍼블리, 커리어리, 위하이어

개발팀 리뷰

위 내용은 퍼블리 전 • 현 재직자의 응답 결과입니다.

기술 스택

언어

typescript

python

javascript

프론트엔드

ReactJS

Next.js

Redux

Styled-Components

백엔드

Node.js

AWS SQS

AWS SNS

데이터베이스

Redis

AWS

PostgreSQL

데브옵스

Docker

CloudWatch

bitbucket

재직자가 작성한 글

profile picture

서영

프론트엔드 개발자

VARCHAR() VS TEXT() 뭐가 다를까? ( •̀ .̫ •́ )

문자열의 데이터 타입을 지정할 때 바로 이 두 타입에 대해서 고민을 하실 것 같은데요, 저도 찾아보다가 당근 기술블로그에 정리가 된 좋은 사례를 발견하여 공유드려봅니다! :-) VARCHAR 타입 : 길이 설정에 주의해야 함 * MYSQL 서버에서는 VARCHAR 컬럼이 너무 큰 길이를 사용하면 다른 컬럼들이 사용할 수 있는 최대 공간의 크기에 영향을 받게 된다. 따라서 VARCHAR 타입의 최대 저장 길이 설정 시에 공간을 아껴서 설정해야 한다. TEXT 타입 : 길이 제한이 사라짐 * TEXT 타입은 저장 가능 길이도 훨씬 크고, 테이블 생성 시 VARCHAR처럼 최대 길이 제한을 정의하지 않아도 된다. 그런데 왜 우리가 모델링하는 대부분의 테이블에서 문자열 저장용 컬럼으로 VARCHAR를 사용할까? ಠ_ಠ * 일반적인 RDBMS에서 TEXT나 BLOB와 같은 대용량 데이터 저장 시에 저장하는 컬럼 타입을 LOB(Large Object)라고 하는데, 이들은 off-page라는 외부 공간에 저장하게 됨. 그러나, MYSQL 서버에서는 LOB 타입의 컬럼을 길이가 길어서 저장 공간이 많이 필요할 때만 Off-Page로 저장함. 이는 레코드 포멧에 따라 조금씩 다르게 작동하기도 함 VARCHAR 타입의 경우도 칼럼에 저장된 값이 크면 Off-Page로 저장함. * MYSQL은 스토리지 엔진과 Handler API 를 이용해 데이터를 주고 받는데 메모리 포인터를 통해 레코드 데이터를 주고 받음. 메모리 객체는 실제 레코드의 데이터 크기와 상관없이 최대 크기로 메모리를 할당함. 즉, VARCHAR는 최대 크기가 설정되기 때문에 메모리 공간을 미리 버퍼에 할당할 수 있음! 따라서 TEXT, BLOB은 메모리 공간이 미리 할당되지 않아서 매번 읽고 쓸 때마다 메모리가 할당되어야 함 요약해보면.. (๑•̀ㅂ•́)و✧ VARCHAR * 최대 길이가 상대적으로 큰 경우 * 테이블 데이터를 읽을 때 항상 그 컬럼이 필요한 경우 * DBMS 서버 메모리가 상대적으로 충분한 경우 TEXT * 최대 길이가 상대적으로 큰 경우 * 테이블에 길이가 긴 문자열 타입 컬럼이 많이 필요한 경우 * 테이블 데이터를 읽을 때 그 컬럼이 자주 필요하지 않은 경우 원 글은 아래 링크에서 확인 하실 수 있습니다! https://medium.com/daangn/varchar-vs-text-230a718a22a1

profile picture

서영

프론트엔드 개발자

개발자가 실생활에서 실천할 수 있는 스터디 방법 소개 🔑

개발자가 간단하게 실천할 수 있는 최신 정보 습득 방법에 대해 가져와 봤습니다! 이미 실천하고 계신 분들도 많으실 것 같네요ㅎㅎ 빠르게 변하는 산업인 만큼 지속적으로 새로운 정보를 받아들이는 것은 중요할 것 같습니다. 1. 개발자 블로그 및 뉴스레터 구독하기 iOS, aOS 공식 블로그뿐만 아니라 업계 전문가가 운영하는 블로그나 뉴스레터를 정기적으로 받아보는 것은 꾸준히 정보의 흐름을 읽을 수 있는 가장 좋은 방법입니다. 2. 소셜 미디어 및 온라인 커뮤니티에 참여하기 트위터, 레딧, 스택오브플로우와 같은 개발자 커뮤니티에 가입하는 것은 개발자들과 함께 소통하면서 성장할 수 있는 좋은 방법입니다. (커리어리도 마찬가지입니다!) 관련 해시태그를 팔로우하고, 스레드에 참여해서 좋은 정보를 실시간으로 얻어보세요! (개인적으로 일론머스크의 트윗이 재밌더군요...) 3. 컨퍼런스 및 모임 참석 온라인 및 오프라인 컨퍼런스에 주기적으로 참여하면 동료 개발자들과 네트워크를 형성하고, 최신 업계 동향을 접할 수 있습니다. wwdc, google i/o뿐만 아니라 국내 기업에서 주최하는 세션이나 컨퍼런스에 참여해 보세요! 4. 온라인 강좌를 통한 지속적 학습 코세라와 같은 유명 플랫폼에서 제공하는 온라인 강좌를 통해 지속적으로 지식을 심화해 나가는 것도 좋은 방법입니다. 최신 도구나 프레임워크를 학습하는 것은 나에게 큰 도움이 될 것입니다! 5. 출퇴근 시간에 팟캐스트 듣기 통근 시간을 이용해 팟캐스트의 힘을 활용해 보세요! Fragmented, Swift by Sundell 및 Android Developers Backstage와 같은 팟캐스트에서는 최신 모바일 개발 사례나 인터뷰 및 토론을 제공합니다! 영어 공부도 덤이고요! 이 외에 주요 CEO들이 출연하여 기술에 대해 이야기하는 ACQUIRED를 추천드립니다! 최근에는 앤비디아의 젠슨 황이 출연하기도 했죠. 6. GitHub 리포지토리 및 오픈 소스 프로젝트를 팔로우하기 GitHub만큼이나 개발자가 코드를 파보기가 좋은 데가 없죠. 도메인와 관련된 프레임워크 라이브러리 오픈소스 프로젝트의 저장소를 꾸준히 기여하고, 참여하면 코딩 기술을 업그레이드할 뿐만 아니라 새로운 코딩 표준 및 공동 개발 방식을 접할 수 있습니다. 7. 베타 릴리즈 사용해 보기 얼리어답터가 되어 운영체제, SDK 및 개발도구의 베타 릴리즈를 실험하면 누구보다 빠른 기술을 습득할 수 있습니다. 이러한 경험을 통해 앱을 조정하고, 개발 커뮤니티에 좋은 의견들을 나눠볼 수 있죠. 8. 업계 보고서 읽기 보고서를 통해 업계 최신 동향을 광범위하게 얻을 수 있습니다. 또한 시장 행동과 타깃 유저 행동에 대한 통팔력을 통해 더 큰 그림을 이해하고, 프로젝트 방향에 대한 정보를 입각한 결정을 내릴 수 있습니다. 해외 쪽 뿐만 아니라 국내 주요 기업도 리포트를 발간하고 있으니, 참고하면 좋을 것 같습니다. 9. 개인적인 개발 계획 수립 커리어적인 성장을 위해 체계적인 계획을 개발하는 것이 중요합니다. 학습을 위한 시간을 확보하고, 강좌 및 컨퍼런스와 같은 앞선 내용들에 리소스를 할당하고 정기적으로 스스로 평가하는 시간을 가져보는 것이 좋습니다. 10. 지속적인 네트워킹 네트워킹은 최신 정보를 유지하는 데에 필수적인 요소입니다 동료 개발자와 소통하고, 적극적으로 협업 기회를 찾아보는 것입니다. 멘토링 및 협업 프로젝트에 참여하는 것도 좋습니다. 본문에 대한 원글은 아래 링크에서 볼 수 있습니다. https://medium.com/gitconnected/how-to-stay-up-to-date-as-a-mobile-developer-0d6c5ef47acc

재직자가 좋아한 글

퀄리티 높은 REST API 작성하기 🎨  |  이전에 작성한 올바른 API 작성하기에 이어 높은 퀄리티의 API를 작성하는 방법에 관한 아티클을 번역을 통해 가져와 봤습니다 :-) 다음은 API의 품질과 성능을 향상시키는 매우 구체적인 조치와 관행입니다. 1) 복수 명사 사용하기 * 대부분 잘 확립되어 있는 부분이지만 규칙에 따라 잘 사용해야 합니다. * GET/book/{book_id} -> GET/books/{book_id} 2) REST API 경로 세그먼트에 따라 데이터베이스를 모델링하지 않기 * 개발자가 전체 관계형 데이터베이스 모델을 URL 구조로 구축하는 경우가 있습니다. GET /books/{book_id} 은 좋은 예시이고, /authors/{author_id}/books/{book_id} 은 좋지 않은 GET입니다. 책 ID는 전세계적으로 고유하기에 저자 ID가 책에 엑세스하기 위한 URL의 일부가 되면 안 되기 때문입니다. 만약 book_id 가 저자별로 공유한 경우 복합 URL이 적합할 수는 있죠. 3) 배열을 최상위 응답으로 반환하지 않기 * 앤드포인트의 최상위 응답은 배열이 아닌 객체여야 합니다. GET/books returns: {“data”:[{…book1…}], [{…book2…}]} 은 좋은 예시이고 GET /books returns:[{…book1…}] 은 좋지 않은 예시입니다. 배열을 반환하면 이전 버전과 호환되는 출력을 변경하기가 까다로워 권장되지 않습니다. 예를 들어 totalCount 와 같은 페이지 매김 필드를 추가하는 것이 좋습니다. 4) 데이터베이스에 숫자값을 저장하는 경우 객체 식별자는 문자열을 사용하기 * {“id”: “456”} 는 좋은 예시이고, {“id”: 456} 는 좋지 않은 예시입니다. 문자열 ID는 구현 변경에 유연하며, 향후 개발자가 다양한 방식으로 시스템을 조정하는 데에 편리합니다. 5) "NOT Found"를 사용하기 위해 404를 사용하지 않기 * 리소스를 찾을 수 없음을 나타나는 데에 사용해야 하는 HTTP 사양 주장은 중요하나, 개발자는 GET/PUT/DELETE 가 존재하지 않는 ID에 404를 반환하도록 하여 이를 문제 그대로 구현합니다. 그러나 존재하지 않는 ID에 대해 응답은 클라이언트에 2가지를 전달해야 합니다. 1) 서버가 요청을 이해했다. 2) 불행하게도 id를 찾을 수 없다. 404는 다양한 이유로 인해 발생할 수 있기 때문입니다. 6) 구조화된 오류 형식 사용하기 * 유저가 많고, 적절한 오류 형식이 없는 대규모 시스템 상에서는 자세한 오류 형식을 사용해야 합니다. 예를 들어 오류 메시지 - 오류 유형 - 원인과 같이 말이죠. 지금까지 퀄리티 높은 api를 작성하는 원칙에 대해 알아봤습니다. 해당 글에 대한 원본 글은 아래 링크에서 확인할 수 있습니다 ! https://medium.com/stackademic/creating-a-high-quality-rest-api-201819325356

좋아요 72 저장 161

thumbnail