행복한디벨로퍼

자바스크립트로 날짜 처리를 하다가 처음 알게 된 사실이 있어 포스팅 해본다.

var date = new Date();
//Fri Sep 25 2020 17:08:38 GMT+0900 (대한민국 표준시) {}

var month = date.getMonth() 
// 당연히 month 는 9일거라고 예상하지만....8이나온다.

이유는 다음과 같다.

Definition and Usage
The getMonth() method returns the month (from 0 to 11) for the specified date, according to local time.
Note: January is 0, February is 1, and so on.

ref : www.w3schools.com/jsref/jsref_getmonth.asp

위의 문서를 보면 알겠지만 자바스크립트에서 getMonth는 0~11까지의 값을 반환한다.

다시말해 1월이면 0을 반환하고 2월이면 1을 반환하며 12월이면 11을 반환한다.

따라서 getMonth()로 달을 뽑아 사용할 때는 date.getMonth() + 1을 해주어야 정확한 값이 된다.

for passing Parent pass data to child, child component shoud set props and binding name 

Parents html

if (selectedId == i) is not exist, when click button, all modal will be open

 <tr v-for="(item, i) in adList">
     <td>{{ item.id }}</td>
     <td>{{ item.adName }}</td>
     <td><button type="button" class="btn btn-primary" @click="createAdParameterModal(item, i)">파라미터확인</button>
         <modal-ad-param-info v-if="selectedId == i && showAdParameterModal" :item="item" v-on:close="closeAdParameterModal"></modal-ad-param-info>
     </td>
</tr>

Method

        createAdParameterModal : function(index) {
            this.selectedId = index;
            this.showAdParameterModal = true;
        },

Modal(modal-ad-param-info) props : item (in html code binding name)

let createAdParameterModalTpml = `
    <div class="modal_wrapper requestRanking">
       <div class="modal_body">
            <div class="modal_contents">
                <div>
                    <span v-for="datasource in item.dataSourceNames">{{ datasource }}<br></span>
                </div>
                <button class="btn btn-outline-danger" @click="closeModal">닫기</button>
            </div>
       </div>
    </div>
`;

export default {
    template: createAdParameterModalTpml,
    props: ['item'],
    methods: {
        closeModal: function () {
            this.$emit('close');
        }
    }
};

vue.js(vuejs) v-for안에서 modal창 띄우다가....삽질을 너무 마니해서 기록해본다.

유튜브(Youtube)에서 맛집, 음식점을 찾아 식당을 리뷰하고 다니는 유튜버들이 다녀온 곳을 쉽게 찾아가려면?

항상 유튜브(Youtube)에서 맛집 컨텐츠들을 보고 '저기는 꼭 가봐야 겠다'고 생각하고 담에 생각나서 가려니 어떤 채널인지도 가물가물하고 언제 내가 구독하는 맛집 유튜버들의 컨텐츠들을 다 뒤져서 그곳을 찾아내나....한 경험이 있을 것이다....(나만 맨날 먹을거 보고 있고 그러진 않겠지...)

무튼 그런 사람들을 위한 서비스인 Moobe(Map of Youtube)를 소개하려고 한다.

1. 전체 UI (https://moobe.co.kr/)

일단 젤 왼쪽을 보면 Moobe서비스에 등록된 맛집 유튜버들의 채널 목록이 보인다. 

2. 맛집 유튜버 채널 리스트

채널들을 클릭하면 해당 채널의 데이터들만 지도에 뿌려지게 된다. (채널을 클릭하기 전까지는 전체데이터이다.)

현재 등록된 맛집 유튜버들의 리스트는 다음과 같다.

1. 야식이(구독자 98.9만명) => 곧 100만명이 눈 앞이다. 일단 잘드시기도 잘드시는데 정말 이 분 컨텐츠를 볼 때면 야식이님의 인성에 감탄할 수 밖에 없는 그런 채널이다. 말을 많이 하시진 않지만 보다보면 편안함이 느껴진다. (보셔보면 느낄 것이다.)

2. 상해기(구독자 41.5만명) => 1년 만에 구독자가 41만명으로 훅 급상승하며 먹방계의 샛별로 떠올랐다. 현재는 '뒷광고' 이슈로 '죄송합니다'의 컨텐츠를 마지막으로 영상이 올라오고 있지 않은 상태다. 원래 헬스(피트니스)를 하시던 분으로 유튜브를 하기 전부터 인스타를 통해 알고 있었다. 내가 느끼기에 성품자체는 나쁘다고 생각되지 않는다. 다만 갑작스런 상승세로 광고료에 눈이 멀어 시청자들을 기만한 행위에  대해서는 단연코 잘못되었다고 생각한다. 충분한 공백기를 가지고 더 좋은 컨텐츠와 처음 유튜브를 시작하던 그 마음가짐으로 시청자들에게 보답하길 바래본다. 

3. 하얀트리(구독자 62.3만명) => 연예인 서인국씨를 닮은(지극히 개인적인 생각이다) 식당탐험가 유튜버이다. 식당을 찾아가는 방법부터 맛에 대한 친절한 묘사를 하며 꾸준한 상승세를 유지해왔다. 컨텐츠가 자극적이지 않으며 객관적으로 맛을 평가해주시는 분이라는 생각이 든다.

4. 맛객리우(구독자 11.5만명) => 컨텐츠들을 보다보면 알겠지만 고급식당이나 스시 오마카세에 대한 정보들을 많이 다루고 있다. 이에 구독자들이 유튜브의 수익으로 금액이 충당되는지 매우 궁금해하는 채널이기도 하다. 스시를 좋아하신다면 이 분 채널을 참고하도록 하자.

5. 최자로드(구독자 71.6만명) => 다듀의 멤버 최자가 운영하는 유튜브 채널이다. 가수로서의 이미지와는 다른 먹방유튜버로써의 친근한 이미지로 맛집들을 소개해주는 채널이다.

6. 정육왕 MeatCreator(구독자 43만명) => 채널명 답게 주로 고기 관련 식당을 다니며 맛있는 고깃집을 알려주는 아주 유익한 채널이다. 정말 고기좋아하는 사람이라면....무조건 구독해야한다.... 인상에서 풍겨져 나오는 이미지도 굉장히 선한 느낌을 주고 고기에 대한 지식을 많이 가지고 있어 고기에 대한 다양한 정보도 얻을 수 있는 채널이다.

7. 김사원세끼(구독자 안나와있음) => 이 분은 찐탱 맛집, 전통을 자랑하는 집, 화려한 가게들 속 숨어있는 맛집들을 주로 찾아다니시는 유튜버이다. 정말 컨텐츠들을 보다보면 소주 맥주가🍻 절로 땡기는 분위기의 맛집들을 방문하신다. 오랜 벗과 오늘 맛있는 음식을 먹으며 찐하게 한 잔 하고 싶다면 이 분의 채널을 주목하길 바란다.

3. 컨텐츠 세부화면

컨텐츠를 클릭해서 보면 동영상이 나오고 오른쪽 지도에는 해당 유튜브 컨텐츠 식당에 해당하는 위치가 지도에 표시되게 된다.

유튜브에서 달린 댓글들중 '좋아요'가 가장 많이 달린 TOP10에 대한 댓글 보기도 제공한다.

4. 구글 로그인 제공

화면의 맨 오른쪽 위를 보면 '로그인'버튼이 있다. 구글 OAuth를 제공하고 있고 구글 아이디만 있다면 누구든 로그인 할 수 있다. 로그인을 할 경우 내가 원하는 컨텐츠 들만 모아 볼 수 있으며 컨텐츠에 댓글을 작성할 수 있다.

컨텐츠를 클릭하고 들어가면 컨텐츠 위에 별표 모양이 있는데 클릭하면 노랗게 변하고 즐겨찾기에 추가 된다. 즐겨찾기 된 컨텐츠들은 우측 상단의 별표 모양을 클릭하여 확인할 수 있다.

별모양을 클릭하면 다음과 같은 페이지로 이동한다.

즐겨찾기한 컨텐츠는 지도에서는 다음과 같이 표기된다.

5. 검색기능을 제공, 현 지도에서 찾기 기능 제공 (음식점이름, 컨텐츠 제목, 태그)

찾고 싶은 음식의 종류나 음식점이름을 통해 쉽게 검색하여 컨텐츠를 찾을 수 있다.

6. 내 위치를 통해 가까운 음식점을 찾을 수 있다.

지도의 왼쪽 상단에 내 위치를 클릭하면 내 위치로 이동하게 되고 주변의 유튜버들이 다녀간 음식점들을 쉽게 찾을 수 있다.

무브(Moobe)에서 현재 제공하는 서비스는 이정도 이다.

채널의 구독자분들이 본인이 좋아하는 유튜버들이 다녀온 곳을 쉽게 찾아 가는데 도움이 될 것 같다.

한 번 사용해보고 추가되었으면 좋을 만한 채널이 있다면 추천 부탁드리겠다🙏

#맛집검색 #맛집추천 #유튜버맛집

Impala 쿼리를 통해 정확하진 않더라도 대략적인 distinct한 모수를 추정하고 싶을 때 사용할 수 있는 함수가 있어 간단히 확인한겸 옮겨 적어본다. 보통 추정에서 많이 사용되는 하이퍼로그로그와 비슷한 기능을 IMPALA에서도 제공하고 있다. 물론 적은 리소스를 가지고 효율적으로 추정만 하기에 정확한 모수를 알고 싶은경우는 패스하도록 한다. 차이는 대략 1.9%정도 났다. (일반적으로 3%정도 차이가 난다고 생각하면 된다.)

27억건의 데이터를 기준으로 ndv의 성능을 체크해보겠다.

+------------+
| count(uid) |
+------------+
| 2725811026 |
+------------+

ndv 함수를 활용해 distinct한 uid가 몇개나 있는지 확인 select ndv(uid)

+----------+
| ndv(uid) |
+----------+
| 73056968 |
+----------+
Fetched 1 row(s) in 14.59s

일반적인 쿼리를 통한 정확한 모수 확인 select count(distinct uid)

+---------------------+
| count(distinct uid) |
+---------------------+
| 74537396            |
+---------------------+
Fetched 1 row(s) in 148.32s

시간차이는 대략 10배 정도 빨랐으며 모수의 차이는 1.9%(1,480,428)정도 발생하였다.

대략적인 추정 모수만 빠르게 알고자하는 경우 사용하면 유용할 것 같다.

1. 안정적이고 완벽한 코드를 짜는 것도 중요하지만 때로는 시간과 타협해서 돌아가는 코드를 짜는 것만으로 만족해야 할 때가 있다.

이 문구를 읽고 너무 공감이가서 정말 속이 다 시원했다. 물론 내가 짠 코드를 최대한 우아하게 짜고 싶고 각 종 패턴들까지 적용은 아니더라고 누가봐도 읽기 쉽고 잘짰다는 소리를 들을 수 있길 원한다. 하지만 보통 실무에서 이렇게 여유롭게 코드를 리팩토링 할 수 있는 여유가 보통은 없을 것이다. 그러면 가끔 실무에서 손을 뗀 사람들 혹은 소위 아가리어터들(입으로만 떠드는)은 얘기한다. 그 짧은 시간 안에 코드를 잘짜는게 실력이다'라고 하기도 한다. 이게 반은 맞고 반은 틀린 말이다. 물론 그 짧은 시간안에서도 뇌의 CPU가 300%돌아가며 최적의 코드를 짜내는 사람도 분명 있긴 있을 것이다(이런분들이 저런 얘길 하면 아무말도 안한다...그저 존경의 대상일뿐)

하지만 보통은 울며겨자먹기 식으로 급하게 패치를 해야 하는 경우나 기능개발에 비해 일정이 너무나도 짧아 본인이 만들어 놓은 코드를 리팩토링 한 번 제대로 못한 채 테스트만 통과한 상태로 나가는 경우도 비일비재하다. 전에는 경력 많으신 관리직분들의 얘기나 혹은 개발 관련 글들을 읽고 생각했었다. '아 내가 아직 많이 부족해서 그래.. 짧은 시간안에서도 SOLID(객체지향설계)원칙을 지키는 코드를 짜내고야 말겠다고!' 풉🙊 

시간과 타협해 버그 없이 돌아가는 코드를 짜내는 것만으로도 훌륭하다고 생각한다. 하지만 제일 중요한 것은 거기서 끝나면 안된다. 바쁠때는 어쩔 수 없더라도 좋은 개발자가 되기 위해서는 시간을 내든 여유 시간이 생겼든, 뒤로 돌아와 '시간과 타협해 돌아가게 만든 코드를 리팩토링 하는거!' 정말 중요하다고 생각한다. 이 때 우리는 좀 더 발전할 수 있다.

2. 우리는 개발자이다. 맘만 먹으면 생각하고 있는 동작을 얼마든지 만들 수 있는 능력을 가진 대단하면서도 신기한 사람들이다.

나도 정말 그렇게 생각한다. 우리는 무에서 유를 창출해내고 있는 사람들이며 내 머릿속 생각을 실제 서비스로 혹은 시스템으로 만들 수 있는 연금술사 같은 사람들이다. 이 문구는 내가 개발자로서의 삶을 살아가고 있는 지금의 모습에 감사함을 느끼게 해주었다. 하지만 제일 중요한 것은 '맘만 먹지말자'는 것이다. 다이어트도 그렇고 신년 계획도 그렇고 맘만먹는 것과 행동하는 것은 다르다. 우리에게 주어진 감사한 능력을 맘껏 발휘해 나만의 서비스를 만들고 운영해보자.

3. Stack Overflow Driven Development (SODD) 라는 말이 있듯이 개발은 사실 엄청난 성능과 최적의 알고리즘을 요하는게 아니라면 개발자 간의 경쟁력은 일반적인 개발실력 이외엔 시간과 경험의 차이인것 같다.

이 말인 즉슨 보통 '개발과 구글링과는 뗄레야 뗄 수 없는 존재이기 때문에 굳이 엄청난 알고리즘 지식들을 머릿속에 넣고 있는게 중요하지 않다'라고 생각된다. 일반적인 서비스를 개발하는 영역에서는 사실상 학부시절 배웠던 DFS(깊이우선탐색)이나 BFS(너비우선탐색)과 같은 기초로 여겨왔던 알고리즘 조차 쓸일이 거의 없다. 실제로 필요하다고 해도 해당 부분을 처음부터 끝까지 직접 개발하는 일은 더더욱 드물다. 보통은 나보다 머리가 똑똑한 사람들이 라이브러리 형태로 왠만한 언어로 다 만들어놓았고 우리는 잘 검색해 믿음직스러운 코드를 가져다가 테스트해보고 커스터마이징 하여 사용하는 수준일 것이다.

그렇기에 알고리즘을 많이 알고 있다는 것이 그렇게 중요한 요소로 생각되진 않는다. 취업준비생들 혹은 구글과 같이 알고리즘에 대한 것을 많이 물어보는 기업에 취업하고 싶다면 필수로 공부가 필요하긴 하다. 하지만 연차가 쌓여가면서 얻는 경험은 단순히 공부한다고 배울 수 있는게 아니다. 항상 어른들이 말씀하실 때 모든건 때가 있듯 각 개발연차마다 배워야 할, 배울 수 있는 것들의 시기라는게 있다고 생각한다.

그렇기에 지금 내가 하는 일에 대해 항상 단순 워커 모드로 기능 개발만 하고 끝낼 것이 아니라 영향 가는 부분에 어떤 문제가 발생할 수 있는지 추가적인 기능으로는 어떤 것들이 필요할지 등 확장시켜 생각해보는 것이 중요할 것 같다. 더 나아가서는 이러한 부분을 직접 구현해보고 문서화 시켜서 사람들에게 설명해보는 연습도 한다면 금상첨화일 것 같다.

긴 글 읽어주셔서 감사합니다🙏 

안녕하세요.

저는 현재 판교에서 데이터 엔지니어로 일하고 있는 개발자1(Beom)입니다. 이번 포스팅에서는 같은 회사에 다니고 있는 동기인 개발자2(Gary)와 약 1년여간 진행했던 토이프로젝트에 대해서 회고해보려고 합니다. 

먼저 간략히 1년간 어떤 토이프로젝트를 진행했는지에 간단히 설명하도록 하겠습니다. 저희가 만든 서비스는 Moobe(무브)라는 서비스로 유튜버들이 다녀간 장소들을 맵(MAP)화 시켜주는 서비스입니다. 먹방 컨텐츠를 보며 한 번씩은 '나도 저기 꼭 가봐야겠다!'라고 생각한적 없으신가요? 그럴때 도움이 될만한 서비스입니다.

백문이불여일견이라고 한 번 직접 보고 오시죠!!!

https://moobe.co.kr/

대충 감이 오시나요???

저희가 1년 동안 토이프로젝트로 개발한 무브(Moobe)는 Map of Youtube의 약어이자 Move(움직이다) 와의 비슷한 발음을 통해 '유튜버들이 다녀온 곳으로 이동하다'라는 느낌을 줄 수 있는 중의적 의미를 내포하고 있습니다. 맛집 찾을 때 자주 사용해 주시면 감사하겠습니다😃

그럼 오늘 포스팅을 남기는 본 목적으로 돌아와 1년 동안 개발을 어떻게 진행해왔는지 Moobe서비스는 어떻게 만들어 졌는지에 대해 이야기해보도록 하겠습니다.

때는 바야흐로....2019년 8월 7일...

동기 몇 명이 모여있는 방에 개리의 위와 같은 발언에서 시작되었습니다. 다른 동료들은 별관심을 보이지 않았지만 이전 토이프로젝트를 한 번 진행해보고 또 다른 토이프로젝트를 물색하고 있던 찰나였기에 '한 번 들어나 볼까?' 하는 마음으로 ✋손을 들어봅니다.  (혹시 개인적으로 진행했던 이전 프로젝트가 궁금하시다면 2018 개발자 Life 회고 참고해주세요_)

이렇게 둘의 프로젝트는 시작되었고 '쇠뿔도 단김에 빼라'는 말이 있지 않겠습니까? 개리의 아이디어와 저의 추진력이 합쳐지며 바로 작업에 돌입하게 되었습니다.

Again..사실 개리와의 토이프로젝트는 처음이 아니였습니다. 기존 한 번 시도했었던...........프롲ㅌ 있었습니다. 넘어가겠습니다.

기왕하는거 제대로 하고 싶어 서비스 개발에 대한 기획문서를 작성했습니다. 서비스 기획 배경과 컨셉 그리고 1차 구현 목표들을 PPT로 만들어 보았습니다. 대충대충 하고 싶지 않았습니다. 이 프로젝트는 '진지'했으니까요

다음에 기회가 되면 처음 시작이되었던 기획 문서와 PPT도 공개해보도록 하겠습니다.

그렇게 저희는 개발스펙을 정하기 시작했습니다. 일단 저와 개리는 현재 막 7년 차에 접어든 개발자로 신입당시에 웹개발 직무로 시작하였습니다. 지금도 물론 웹개발을 하고 있긴하지만 데이터쪽과 오픈소스를 다루고 있습니다. (뭐 크게 궁금하시진 않을테니 넘어갈게요.)

1. 토이프로젝트의 목적 (익숙한 기술을 조심하라)

일단 토이프로젝트의 목적 자체가 머릿속의 아이디어를 취미삼아 개발하는데 목적이 있을 수 있습니다. 이러한 경우 익숙한 기술로 빨리 만드는 것도 중요하지만 회사 업무에서 다루지 않는 언어나 프레임워크를 학습하며 적용해보는 것도 큰 도움이 될 수 있습니다.

그래서 프론트(Front)쪽은 처음 Vue.js를 사용해 볼까 하였지만 이미 개리는 Vue.js를 사용하고 있었고 React를 사용하는게 어떻겠냐고 물었습니다. 이에 저는 아주 명쾌히 대답해주었습니다. 

"그래 그럼 너가 리액트로 프론트를 해라^^" 라고  😊

그리고 저는 백엔드(Backend) 쪽을 맡기로 하였습니다. 

정리해보자면

Front : React & Redux + Javascript +Kakao MAP  

Backend : SpirngBoot + Java + JPA + MYSQL + Google Oauth

2.  소스코드 관리의 꽃 GIT

저희는 협업을 위한 툴로 Git을 사용하였고 개발하기전 모든 기능 개발에 대한 Issue를 발행하고 각자가 맡은 기능들은 해당 feature에 개발한 후 검토하고 Merge하는 방식으로 진행하였습니다. 개리는 프론트 쪽을 진행하였고 저는 백엔드 쪽을 진행하였기에 각자가 맡은 Feature을 Merge할 때에 크게 충돌이 나거나 하는 문제는 발생하지 않았습니다.  약 1년 동안 84개의 Issue를 등록하였고 그 중 82개가 Closed된 상태입니다.

지금에 와서 보니 뿌듯뿌듯🍀하네요...

이슈를 만들 때 커스텀 라벨(label)도 만들어 사용하였습니다. 해당 이슈가 기존 기능을 보완하는 이슈인지 새로운 기능을 개발하는 이슈인지 라벨만 보고도 알 수 있습니다.

저희는 Git에서 무료로 제공하는 private repo를 사용하고 있습니다.

위에서 보시다 시피 첫 커밋은 8월 11일⭐️ 입니다.  시간 진짜 빠르다......

3. 악당(마음속 악당)이 너무 많다.

프로젝트를 1달도 아니고 2달도 아니고 6달도 아니고 1년😱 동안 진행하다 보니 서로가 손을 놓고 지냈던 적도 있었습니다. 그 이유야 다양하겠지만 사실 저의 경우는 귀찮음이 제일 컸습니다...아니 회사 일도 하고 운동도 해야되고 개인 공부도 하고 포스팅도 해야하는데 프로젝트까지 해야한다고 생각하니 가끔은 가슴이 너무 먹먹했습니다....너무 해야할게 많다보니 빨리 빨리 움직여서 하면 좋으련만.....그 반대였습니다...그냥 회사 일 끝나면 그냥 쉬고 싶은건 저뿐만이 아니겠죠...? 물론 개리도 저와 같은 생각과 감정을 겪었을 것이라고 생각합니다. 그렇게 저희는 서로가 두 세 달을 별다른 진척없이 보내기도 하였습니다.

하지만 함께 꾸는 명확한 목표가 있었기에 서로가 서로를 일으켜 세워주곤 하였습니다. 매주 한 번씩은 만나 서로 개발하기로 했던 기능들에 대해 리뷰하는 시간을 가지려 노력했고 한 주 마다 스스로가 해야할 기능에 대한 목표를 설정하였습니다. 

지금에와서 드는 생각은 이건 분명히 혼자 진행했다면 중간에 때려치고도 남았을 것이라는 겁니다ㅎㅎ 유독 한 문구가 떠오르네요  '멀리가려면 함께 가라' 

마치며

쓰다보니 길이 너무 길어질 것 같아 이번 포스팅은 여기서 마무리 해보려고 합니다.

1년 길다면 길고 짧다면 짧은 시간 동안 (짧지는 않았음...) 같이 개발하며 귀찮아서 손을 놓고 싶었던 적도 있었습니다. 하지만 그럼에도 여기까지 올 수 있었던 데에는 같은 곳을 바라보며 함께 해주는 동료가 있었기 때문이라고 생각합니다.

함께 토이프로젝트를 시작했을 때 1차 목표에 이르기 까지 1년이라는 시간이 걸렸습니다. 빠르진 않았지만 완성도 있는 서비스를 만드는데 집중하였습니다. 이제부터가 진짜 시작이라고 생각합니다. 아직 많이 부족한 시스템이지만 이 글을 보시는 분들께서 방문해주시고 피드백 주신다면 앞으로 서비스가 커나가는데 정말 많은 힘이 될 것 같습니다. 

 2편에서는 시스템을 개발하면서 겪었던 이슈들에 대해서 다뤄 보도록 하겠습니다.

긴 글 읽어주셔서 감사합니다.🙏

아래와 같은 데이터에서 선생님별 학생리스트가 아닌 1-1 matching된 multi row로 만들 때 보통 lateral view explode()를 사용한다. 하지만 주의할게 explode() udf는 아래와 같이 array형태나 mpa as a parameter형태만 지원한다.

table : class

$ SELECT teacher, id from  class LATERAL VIEW explode(student_id_list) ids AS id where adid='teacher1';

위처럼 lateral view explode 을 실행하면 아래처럼 muliti row 형태로 변환된다.

하지만 student_id_list가 String 형태로 되어있다면?

위에서 언급한 것 처럼 explode()는 array형태나 map as a parameter형태의 데이터에만 지원되기 때문에 다음과 같이 처리해준다.

$ SELECT teacher, id from  class LATERAL VIEW explode(student_id_list, ',') ids AS id where adid='teacher1';

이렇게 해주면 explode를 String format에서도 사용할 수 있다. 

결과는 동일하다.

Solution

$ yum -y install gcc-c++

Solution

$ yum -y install gcc