HELLO WORLD

Firebase Cloud Functions를 적용하게 되었던 배경을 이전 글에서 소개해드린 바가 있습니다. 그 글에 이어 Cloud Functions 적용기를 간단히 소개하고자 합니다. 순서는 다음과 같습니다. 1. Cloud Functions 개발 환경 구축 2. Cloud Functions 코드 작성 3. Deploy 좀더 상세한 내용을 원하시면 하기 링크를 참고하시기 바랍니다. (본 글에서 다루는 내용보다 상세한 내용을 담고 있습니다.) https://firebase.google.com/docs/functions/get-started https://firebase.google.com/docs/functions/database-events 1. Cloud Functions 개발 환경 구축 먼저 Cloud Functions을 시작하기 위해서는 별도 개발 환경을 구축해야 합니다. Cloud Functions은 Node.js를 기반으로 동작하는 것 같습니다. 따라서 다음 단계가 선행되어야 합니다. Node.js 설치 (v6.11.1 recommend) npm 설치 Firebase CLI 설치 Node.js와 npm을 설치했다면 다음 명령어로 Firebase CLI를 설치할 수 있습니다. npm install -g firebase-tools Firebase CLI까지 설치가 되었다면 이제 Firebase Cloud Functions 프로젝트를 생성해야 합니다. 제가 개발 중인 프로젝트는 Android 모바일 어플리케이션이었습니다. 하지만 지금 작성하고자 하는 코드는 Android 앱이 아닌 Google Cloud 서버에 로드되어 동작할 코드이기 때문에 별도 프로젝트를 생성해야 합니다. 1.1 먼저 다음 명령어를 통해 Firebase tool 사용을 위한 인증을 완료합니다. firebase login 1.2 원하는 경로에 원하는 이름으로 Directory를 생성하고, 다음 명령어로 초기화합니다.

현재 Firebase의 다양한 기능들을 적용하여 모바일 어플리케이션을 개발하고 있습니다. 아시다시피 Firebase는 인증, 데이터베이스, 스토리지와 같은 여러 핵심적인 서버 기능들을 제공하고 있죠. 덕분에 Client 코드만으로도 충분히 Serverless한 서비스를 개발하고 있습니다. 개발을 하면서 Firebase 위력에 하루 하루 감탄/감사(?)하고 있죠. 그런데 지금 제가 진행하고 있는 프로젝트에서는 위 기능들만으로는 조금 부족했습니다. Firebase Realtime Database는 Json을 베이스로 하기 때문에 기본적으로 일반 관계형 데이터베이스와는 다른 DB 설계를 생각해야 했고요. 이로 인해 데이터 정합성 문제가 발생했습니다. 결론적으로는 Firebase Cloud Function을 통해 해결할 수 있었고 본 글은 Cloud Function의 적용 사례를 소개하는 글입니다. 우선 본 장에서는 Firebase를 사용하면서 어떤 문제 상황을 마주했고, 이를 해결하기 위해 선행적으로 어떤 대안들을 생각했었는지, 그리고 결국에는 왜 Cloud Function을 최종 대안으로 선택했는지 소개하고자 합니다. 일반적으로 관계형 데이터베이스에서는 데이터 중복 저장은 가급적 피해야하고, 이를 달성하기 위해 정규화라는 개념이 적용됩니다. 하지만 Firebase Realtime Database는 관계형 데이터베이스가 아닌 Mongo DB와 같은 Document Store입니다. 우선 제 입장에서 이런 구조는 익숙하지 않은 형태의 데이터베이스였고, 처음 이것을 접했을 때에는 가급적 관계형 데이터베이스와 유사하게 데이터 구조를 가져가려고 노력했습니다. 하지만 이는 생각처럼 쉽지 않았고, 결국 성능을 위해 일부 데이터를 중복 저장하기로 결정했습니다. [이해를 돕기 위한 예제 소개] 본 글에서는 우리가 직면한 문제를 소개하기 위해 User, Group의 예를 사용합니다. User: 사용자의 정보를 담은 객체 G

한 아이의 천재적 재능이 낭비되고 있다는 소식을 접하게 되었다. http://baobao.hot-blogger.com/bbs/board.php?bo_table=blog&wr_id=3419 #_adtep 우림이는 초등학교 때부터 빼어난 그림 실력으로 주목을 받았다. 관련 전문가들은 모두 그 아이의 재능을 인정하였음은 물론 장래가 기대되는 유망주였다. 그랬던 우림이는 5년이 흘러 이제 고등학생이 되어 있었다. 5년이란 세월동안 아마도 자신 만의 확고한 세계관과 보다 정교한 실력으로 훨씬 더 멋진 작품을 만들어 왔을 것이라고 기대되었다. 그러나. 아이의 재능은 그다지 발휘되지 못하였다. 실력보다는 마음이 죽어있었다. 고등학생인 그는 여느 다른 또래 아이들과 마찬가지로 입시 준비를 하고 있었고, 미대를 가기 위해 입시 미술 학원을 다니고 있었다. 우림이는 그림을 더이상 그리기 싫어했다. 그 천재적 재능을 낭비하고 있었다. 그 원인은 부모의 잘못된 가이드에 있었다. 부모는 우림이에게 미대를 가게끔 가이드, 강제하였다. 부모의 생각은 단순했다. "자기가 좋아하는 그림만 그리면 아무 것도 아니다." "미대를 가야한다." 1. 부모는 전문가가 아니며, 우림이의 그림에 대해 평가할 수 있는 실력을 갖추고 있지 않다. 우림이의 그림은 전문가들이 이미 인정한 그림이다. 부모는 어떤 근거로  "자기가 좋아하는 그림만 그리면 아무 것도 아니다"  라고 평가할 수 있는가? 제 3자로서 내가 보이게 지극히 부모의 판단 미스이다. 비유하자면 우림이의 그림 세계는 무한한 바다지만 이를 바라보는 부모는 동네 우물 수준이다. 동네 우물이 바다를 이해할 수는 없는 노릇이다. 부모라고, 나이가 많다고, 좀더 오래 살고 현실을 더 안다고 그림 마저 더 잘 안다고 할 수 없다. 2. 대학을 가야만 한다는 고정 관념과 사회 시스템

본 글은 '기적의 아빠육아'  도서 리뷰입니다. 저는 오는 (2017년) 9월 말에 아빠가 될 예정인, 예비 아빠입니다. [이 책을 읽기 전에는......] 육아란 상당한 고통이 수반되는 일종의 무일푼 노동이란 인식이 있었습니다. 주변 직장 선배들의 이야기를 들어봐도 직장 퇴근 -  육아 출근... 애가 생기면 자유 시간이란 향후 10년(?)은 생각도 하지 말라고 하니 청천벽력이 아닐 수 없습니다. [하지만 이 책을 읽고 난 지금은......] 육아라는 것을 그렇게 하나의 노동과 무자유라는 부정적인 것으로 치부해 버린 제 생각이 얼마나 짧은 것인지 반성하게 됩니다. 육아는 한낱 노동이 아닙니다. 하나의 소중한 생명을 바르게 기르는 아주 중요한 교육 과정입니다. 고액 과외? 조기 어학 연수? 초호화 어린이집? 그런 것과 비교할 수 없을 정도로 중요한 교육 과정입니다. [육아는 경험이 아닙니다, 육아도 교육이 필요합니다.] 육아가 중요하다는 것을 알고는 있습니다.  그런데 과연  구체적인 육아법을 알고 아이를 키우나요? 예비 아빠인 저 역시 육아에 대해 별 생각이 없었습니다. 그냥 정직하고, 바르고, 건강하게 키우면 된다고 생각만 할 뿐 거기에는  그 이상의 구체적인 무언가는 없죠. 그런데   바로 그 구체적인 무언가를 이 책은 제시합니다. [저는 이 책을 아빠들만의 책은 아니라고 생각합니다.] 필시 책 제목은 해외 선진국과는 달리 육아는 여성의 몫이라고 생각하는  우리의 그릇된 관념을 파고든 마케팅 전략이 아닐까 생각합니다. 저 역시 이 책을 읽고 아내에게도 일독을 권했으니까요. [이 책은 육아가 쉬워지는 육아 꿀팁 가이드 북이 아닙니다.] 읽고 나면 자유 시간이 생기고, 직장 퇴근, 가정 출근의 패러다임이 바뀐다거나, 육아가 쉬워지거나 하지 않습니다. 만약 그런 육아

본 글은 Android Settings 페이지를 참고로 작성되었습니다. Android Application을 만들다 보면 설정 화면이 필요합니다. 어떻게 할 수 있을 까요? 간단히 SettingsActivity를 생성하고  여기에 필요에 따라 EditText, ListView, Button, CheckBox 등의 View를 그려주면 됩니다. 그리고 각 View Event를 구현하고 변경된 값을 File, SharedPreference, 혹은 Database 등에 저장해주면 됩니다. 그런데 Android에서는 좀더 스마트한 방법을 제공해주고 있습니다. 바로 Preference  입니다. 설정 화면을 만들기 위해 위와 같이 View를 직접 그리는 대신, Preference와 그 SubClass들을 XML에 정의하여 만들 수 있습니다. 일반적으로 설정 화면은 ListView로 보여지는데요. 이때 각 List 하나의 항목 당 하나의 설정 값을 저장/변경/관리하게 됩니다. 그리고 앞서 언급한 Preference 객체가 바로 이 하나의 설정 항목에 해당됩니다. 즉 5개의 설정을 관리할 수 있는 설정 화면을 위해서는 5개의 Preference 객체가 필요하다는 거죠. Preference에는 대표적으로 다음과 같은 SubClass들이 있습니다. CheckBoxPreference EditTextPreference ListPreference 각 이름을 보시면 어떤 설정 메뉴를 만들 수 있는지 알 수 있을 겁니다. Preference는 key-value 쌍으로 설정 값을 저장하며, 그 저장 값은 SharedPreference에 저장됩니다. 사용자가 설정 값을 변경하면 시스템은 그 값을 SharedPreference에 업데이트하므로 설정 값을 저장하기 위해 개발자가 직접 SharedPreference에 접근할 필요는 없습니다. 오직 설정 값을 읽어 적합한 UI를 그리거나 데이터를 보여주기 위해서만

전 네스프레소 커피 머신을 사용하고 있습니다. 이제 한 2년 정도된 것 같네요. 처음엔 "이니시아 레드" 제품을 이용했었고, 처음으로 구매하여 사용했던 네스프레소 이니시아 C40 제품 최근에는 "U C50" 제품으로 바꿔 이용하고 있습니다. 최근 선물받아 이용하게 된 네스프레소 유 C50 제품 네스프레소 커피 머신을 이용하고 나서 커피를 마시는게 쉬워졌죠. 카페에 가서 커피를 마시기 위해 적게는 2천원, 크게는 6~7천원 지불하는데, 이제는 집에서 6~800원으로 해결한다고 생각하니 참 뿌듯했죠. 그런데 사실은...... 마냥 좋기만 했던 것은 아닙니다. 네스프레소의 아쉬운 점 1 한 2년을 먹다 보니 다른 커피를 먹고 싶어도 방법이 없었던 거죠. 네스프레소는 이미 굉장히 다양한 커피 캡슐을 판매하고 있지만 그것만으로는 채울 수 없는 공허함? 자주 가는 카페에서 판매하는 원두 가루로 집에서도 커피를 내어 먹고 싶다는 생각. 네스프레소 머신 사용자로서 저는 "아냐 네스프레소가 더 맛있어, 네스프레소 마시면 된다고!" 라며 스스로를 위로했던...... 네스프레소의 아쉬운 점 2 몇개월에 걸쳐 먹다 보면 어느 새 폐 캡슐들로 가득한 재활용 수거 봉투를 발견하게 되죠. 처음엔 주문하면서 수거를 요청했는데, 집에 제가 늘 있는 것도 아니다 보니 수거가 안되더라고요. 결국 쓰레기 봉투에 버려졌죠. 항상 보면서 아깝다 생각했습니다. 그 작은 커피 한 잔 먹겠다고 저렇게 캡슐을 하나씩 버려야 하다니. 그러던 작년 가을 쯤이었나요? Indiegogo 라는 크라우드 펀딩 사이트에서 어느 한 제품이 제 눈길을 사로 잡았습니다. 바로 이 WAYCAP 이라는 제품인데요.