smith3015 의 기술 블로그

 로딩 화면에 보통 이미지를 추가하여 작성을 한다. 이때 이미지가 표출이 되지 않는 경우가 발생한다. 방법은 관련 파일을 지우고 다시 하면 된다. Xcode 에서 Preference - Locations -DerivedData 에서 작은 화살표 모양을 클릭하면 관련 폴더가 보인다. 여기서 Derrived Data 폴더를 클릭하여 들어간다. 여러가지 실행되었던 폴더가 보일 것이다. 이걸 다 지운다. 어차피 다시 실행하면 생기니 걱정하지 말자. 그리고 맥을 재부팅한다. 맥이 재부팅 되는 동안 테스트 폰도 마찬가지로 앱을 삭제하고 재부팅을 한다. 관련 컈시파일이 이미지를 잘 보여주지 못해서 발생하는 문제로 보인다. 모두 초기화가 되면 처음부터 다시 캐시파일이 생성되므로 되는거 같다.

 아이폰 앱을 먼저 만들고 안드로이드 앱을 만들었습니다. web server는 node express, database는 mongodb, server는 네이버클라우드 1년 무료를 신청하여 마이크로 서버에 위의 환경을 구축하였습니다. 도메인은 가비아에 신청하여 1년 결제를 하였고 SSL 은 letsencrypt 에 연동하여 매월 갱신되도록 설정하였습니다. haproxy 를 설치하여 서버에 접근하는 트래픽을 분산하도록 설정하였습니다. 가령 예를 들어 topScore api 를 호출하는 건수가 많아지면 하나의 node express 로 처리하는게 버거울꺼 같아서 같은 서비스를 포트별로 분기하는 방식으로 설정하였어요. 그 트래픽 분기는 haproxy 가 하는 것이고요. 이게 서버 성능을 100%까지 끌어올리는데 꽤 역할을 합니다. 일단 서버측 모듈은 이런식으로 대충 구성이 되어 클라이언트인 앱 개발을 시작하였습니다. 아이폰 앱을 스위프트로 스토리보드를 사용하여 만들었습니다. 화면 구성을 하고 기능들을 입혀 가면서 서버 모듈과 테스트도 하여 완성시켜 나갔습니다. 아이폰 앱을 심사를 올리고 안드로이드 개발에 나섰습니다. 아이폰의 ViewController 를 안드로이드의 Activity 로 변환하는 느낌으로 개발을 하였습니다. 안드로이드는 자바로 구성하였는데 저 같은 경우는 아이폰에서 안드로이드를 더하는 느낌으로 개발하므로 코틀린은 자료가 없어서 힘들었고 자바는 자료가 많아 개발하기가 너 나은 느낌이었습니다. 둘 다 앱이 심사에 통과되어 스토어에 올라 갔는데 다운로드 수가 늘지 않습니다. 디자인이 문제 인거 같아 아는 디자이너를 수배하여 디자인 시안을 받아서 적용하였습니다. 이 작업이 만만치가 않더군요. 나중에 금전적인 여유가 있으면 개발 전에 디자인을 받아서 작업하는 좋겠다는 생각이 들더군요. 디자인을 적용하니 이제야 어구를 갖춘 어선이 되었구나 하는 느낌이었습니다. 만선을 기대하여 출항하는 배처럼...., 다운로드 수가 많아지길 바라며 스토어에 올렸는데.......

 몽고디비의 ObjectId 에서 날짜를 추출하여 사용하는 방법이다. 아이폰을 위한 스위프트 함수로 작성하였다. func ObjectIdToDate(id: String ) -> Date {     var resultDate = Date ()     let endIdx: String . Index = id. index (id. startIndex , offsetBy: 7)     let hex = id[id. startIndex... endIdx]     if let offset = UInt32 (hex, radix: 16) {         resultDate = Date (timeIntervalSince1970: TimeInterval (offset))     }     return resultDate } 안드로이드를 위한 자바로 작성한 코드이다. public Date ObjectIdToDate (String id) { String hex = id.substring( 0 , 8 ) ; Long x = Long. parseLong (hex , 16 ) * 1000 ; return new Date(x) ; } 문자열 중 앞의 8자리가 유닉스 타임의 숫자이다. 서버에서 몽고디비의 _id 값을 Hex 코드로 내려 준다면 당황하지 말고 변환하여 사용하자. 앞의 4바이트가 시간이므로 이를 변환하면 된다. unix epoch 이란 1970.1.1 부터 지나온 시간을 말한다. 대부분 서버에서 이 시간을 사용한다.

Ubuntu Server 에 Node 를 설치하고 Express 를 사용하여 서비스를 할 예정이다. 데이터베이스는 MongoDB 로 구성되어 있다. Mongoose 를 이용하여 서비스를 구성하려고 하는데 매뉴얼 대로 해도 조회가 되지 않는다. 매뉴얼이 자세하지 않는거 같다. 많은 검색 후에 컬렉션을 설정해야 한다고 하여 했더니 조회가 되었다. var mongoose = require ( 'mongoose' ); var db = mongoose . connection ; db . on ( 'error' , console . error ); db . once ( 'open' , function () { console . log ( 'Connected to mongo server' ); }); mongoose . connect ( 'mongodb://user:password@host:port/dbname' , { useNewUrlParser : true , useUnifiedTopology : true }); var Schema = mongoose . Schema ; var cannonBeeSchema = new Schema ({ _id : Schema . Types . ObjectId , version : String , os : String , locale : String , uuid : String , count : String }); cannonBeeSchema . set ( 'collection' , 'cannonBee' ); var cannonBee = mongoose . model ( 'cannonBee' , cannonBeeSchema ); cannonBee . findOne ({}, function ( err , data ) { if ( err ) return conso...

 미 정보국에서 작성된 파일이라고 떠 도는 이미지이다. 실제로 이런 사람들이 조직에 대단히 많다. 그것도 고위직급에 많이 존재한다. 이글을 추적해보니 보다 세세하게 많은 내용이 있다. 내가 그동안 경험 했던 곳의 관리자는 대부분 이랬다. 아닌 사람을 찾기가 힘들 정도이다. 원문은 이곳에 있다. http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/OSS_Simple_Sabotage_Manual.pdf 주변에 공작원이 많은가 보다. 자생적 공작원이라고 해야 하나.... 조직이 굴러 가는게 신기할 정도이니....

  예전 레미콘 회사에 다닐 때 일이다. 주로 아파트 공사 현장에 갔었다. 이때만 해도 LH 만 규정대로 진행했었다. 물론 레미콘 회사 입장에서는 일이 많이 힘들었다. 우리끼리 아파트는 LH에 입주해야 한다고 말했었다. 그렇게 규정을 지키고 상식을 지키는 사람들이 그립다. 조직에서 규정과 상식 그리고 양심에 따라 일을 하다보면 미운 털이 박히는거 같다. 그렇게 조금씩 조금씩 조직을 좀 먹어 이제는 커다란 구멍으로 다가오는게 아닌가 싶다. 이제는 규정과 상식을 지키는 사람들이 바보 되는 세상이 되어 버린게 아닌가? 암만 망해가는 나라에도 충신은 열 이상 나온다고 하지 않았던가? 전문가들이 왜 있는가? 그저 직급이 높다고 아무것도 모르면서 업체들이 하는 말을 듣고 진실을 외치는 하위직급 전문가의 말을 외면해서 작금의 사태가 발생한게 아닌가. 그저 안타까울 뿐이다.

하루에 데이터가 약 140만건 정도 쌓이는 서비스 이었다. 처음엔 몽고디비 하나로만 이를 처리하였다. 데이터 쌓이는 것은 잘 쌓였다. 웹 모듈에서 모바일에서 전송하는 데이터를 받아서 몽고디비에 쌓는 로직으로 구성했다. 갑자기 로그 파일 생성에 욕심이 생겨서 이를 추가해보았다. 하지만 서버에 로그 파일 생성하는 부분에서 의외로 오류가 많이 발생하였다. 웹 모듈이 죽는 상태가 많이 발생하였다. crontab 에 웹 모듈 실행여부를 체크하여 프로세스가 죽어 있으면 다시 실행시키는 스크립트를 생성해서 돌렸으나 작동되지 않았다. 스크립트는 복잡한 로직은 작동이 되지 않는거 같았다. 이런 내용을 실행하는 프로그램을 작성해서 돌렸다. 이렇게 몇달 운영하다 보니 매우 비효율적이란 생각이 들었다. 웹 모듈에서 자체 제공하는 로그를 이용하기로 하고 이렇게 구성했더니 로그는 훨씬 원활하게 돌아갔다. 진작에 웹 모듈에서 제공하는 로그를 사용할 껄 그랬다. 몽고디비에서 쌓이는 데이터를 가지고 대시보드를 작성하기 위한 서비스를 개발했다. 이때 문제가 발생했다. 디비에 계속 쌓이는 모듈에 데이터를 검색할 때마다 부하를 주어서 데이터 누락이 발생했다. 몽고디비 자체가 성능을 위해서 데이터 정합성을 포기하도록 설계되었다는 것이다. 문제를 해결하기 위해서는 상태 모니터링용은 관계형 데이터베이스를 사용하기로 했다. 마이에스큐엘을 설치하고 웹 모듈에서 상태 모니터링용 데이터는 마이에스큐엘에 저장하도록 분기 하였다. 대시보드용 서비스는 마이에스큐엘에서 데이터를 가져와 보여주었다. 오래된 데이터에서 이력을 보는데는 몽고디비에서 바로 검색해도 성능 저하는 없었다. 컬렉션을 날짜별로 저장되도록 구성하였는데 현재 저장되는 컬렉션에서 검색을 할 경우 성능저하가 발생하였다. 현재 저장되고 있는 않는 어제나 지난 날의 컬렉션의 자룔 검색하면 성능저하는 발생되지 않았다. 결국 데이터베이스는 두개로 운영되었다. 관계형 데이터베이스는 현황용 데이터를 저장하고  몽고디비는 저장용 데이터를 저장하도록 설계하였다...