이 블로그 검색

2014년 12월 29일 월요일

AngularJS : Seoul Dust Dashboard

Displaying current density of particulate matter(PM10) in seoul using AngularJS, Express.js


앵귤러 보름만하면 나도 프론트엔드 웹개발자? ^^




서울시 대기환경 정보 사이트에서 주기적으로 데이터를 긁어와서  표와 챠트로 보여주게 하는 간단한 Web App을 만들어 보았다. 개발 하면서도 매우 재미 있었다.^^

2014년 12월 26일 금요일

AngularJS : Best practice, 'dot rule'


AngularJS 에서 model을 UI 에 바인딩 시키는 경우, 이른바 'dot rule' 이라고 하는 idiom 이 있다.

"ng-model을 사용 시 dot(.) 이 존재해야 한다. 그렇지 않다면 잘못하고 있는것이다"
"Whenever you have ng-model there’s gotta be a dot in there somewhere. If you don’t have a dot, you’re doing it wrong."

AngularJS Best Practices 에 나오는 내용이고 간단한 예제를 보이면서 설명하고 있다.
이 동영상에 나오는 예제와 동일한 맥락의 다음 예제를 살펴보자.

firefox 에서 JS Bin 이 제대로 표시가 안되는 경우엔 IE, chrome 을 사용해본다.

2014년 12월 24일 수요일

AngularJS : Controller들간 데이터 공유, $broadcast/$on or service?

AngularJS sharing data between controllers : $broadcast/$on or service?

예를 들어 A, B, C 컨트롤러간에 데이터를 공유해야 하는 경우가 있다라고 가정 해보자.
즉, A 컨트롤러가 변경시키는 어떠한 데이터를 다른 컨트롤러들에서 추적해서 화면등에 갱신이 필요한 경우라면 어떤 방법이 좋을까..
이러한 Controller들간의 데이터를 공유하는 방법에 대한 내용을 인터넷을 찾아보면
$broadcast, $on을 사용해서 구현한 경우를 자주 볼수 있다.
그런데 이곳저곳 살펴보고 내린 나름의 결론은 서비스를 사용하는것이 정석이란 것이다.
서비스의 본래 목적은 어플리케이션의 비지니스 로직을 담기 위한 장소이지만,  singleton의 특징을 활용, 이 서비스에 데이터를 보관하고 컨트롤러에서 inject하면 각 컨트롤러에서 동일한 데이터를 참조하게 할수 있는것이다.

firefox 에서 JS Bin 이 제대로 표시가 안되는 경우엔 IE, chrome 을 사용해본다.

2014년 12월 23일 화요일

AngularJS : Binding Primitive, Reference Type

AngularJS의 2 way-data binding 사용에 시행착오를 겪은 부분이 있어서 글로 남겨본다.

directive, expression 등을 사용하여 binding하는 경우 $watch가 생성되어 model의 변경을 감시하게 된다. 다음 예제를 한번 살펴보자.

예제1) 정상적으로 동작하지 않는 경우
버튼을 눌러봐도 값이 변경되지 않는다.

2014년 12월 9일 화요일

AngularJS 게시판

AngularJS(1.3.6)+ Express + mongojs 이용한 간단한 게시판

앵귤러 보름만 해보면 나도 프론트엔드 웹개발자^^

https://github.com/jeremyko/AngularJsBulletinBoard_PlainStyle
일반적인 형식
최근 Web front end 계의 대세라는 AngularJS에 흥미가 생겨서, 간단 게시판을 한번 만들어 보았다. Express app의 기본구조에 AngularJS의 처리를 추가한 형태이다. Express 는 일종의 Rest API 역활로서 mongodb의 데이터를 전송해주는 역활을 한다.

https://github.com/jeremyko/simple_angularjs_bulletin_board
accordion 스타일

2014년 11월 3일 월요일

Effective Object-C 2.0

며칠전 강컴으로 구입한 책이다. 책을 사서 처음 부터 읽지 않고 관심있는 부분부터 보는 습관인데, 지금까지 2개의 아이템만을 읽었을 뿐인데 번역의 질이 실망스럽다. 처음부터 완전 엉망은 아니지만, 100% 번역을 믿고 읽을 수준은 아니라서, 이런책이 원서보다 더 읽기 힘든책이다. 그리고 단지 2개의 아이템을 읽었을 뿐인데 편집상의 심각한 오류도 보인다. 도저히 무슨 내용인지 몰라 고민하다가 인터넷으로 원서내용을 볼수 있는 사이트를 알게돼서 직접 비교해보았다.

item 6 


41 페이지
'보통은 원자성은 필요없다. 더높은 레벨의 쓰레드 안정성을 보장하지 않기 때문이다'

Usually, atomicity is not required anyway, since it does not ensure thread safety, which usually requires a deeper level of locking.
--> 원자성이 스레드 안전을 보장 하는것은 아니기에 이를 사용할 일은 별로 없다. 일반적으로, 쓰레드 안전을 위해서는 몇 단계의 잠금이 요구되기 마련이다.
('더 높은' 이라는 말은 아주 이해하기 애매함)

2014년 10월 2일 목요일

_UIViewServiceInterfaceErrorDomain Code=3

Xcode 6.0.1 IOS8 simulator 에서 MFMailComposeViewController 클래스를 이용한 메일 전송시 다음과 같은 에러 발생됨.

viewServiceDidTerminateWithError: Error Domain=_UIViewServiceInterfaceErrorDomain Code=3 "The operation couldn’t be completed. (_UIViewServiceInterfaceErrorDomain error 3.)" UserInfo=0x7fcb9ca007a0 {Message=Service Connection Interrupted}
2014-10-02 22:10:41.518 PushUpCounter[1241:22189] <MFMailComposeRemoteViewController: 0x7fcb9c86aa70> timed out waiting for fence barrier from com.apple.MailCompositionService


이게 IOS8 시뮬에서만 발생되는 버그인데, 실제 device로 테스트 시에는 정상 동작한다.
애플이 좀 급하게 IOS8 SDK를 내놓은 모양이네 ..^^

2014년 9월 18일 목요일

ios8 업데이트

어제 애플이 ios8 업데이트를 배포했다고 바로 이런 메일이 도착.
음..버그를 잡아야되는데...
이번엔 개발자 등록도 연장 안했는데.. 좀 고민되네...
도의적 책임을 지고 끝까지 A/S를 하느냐 마느냐...

20141009 업데이트
오늘 1.3.1 업데이트가 스토어에 올라감.

2014년 9월 4일 목요일

내가 본 거지같은 소스들 - sizeof 와 구조체 패딩

지금까지 일한곳들에 존재하는, 거지 같은 소스들을 유지, 보수하면서 느낀점들을 정리한다.  

sizeof 와 구조체 패딩

결론만 먼저 얘기하면, 구조체 크기를 임의로 가정해서 이 수치를 가지고 연산하지 말라는 것이다. 구조체를  다룰때 네트워크 연동등이 아니라면, 일반적으로 패딩 바이트에 대해 신경 쓸일은 없다. 그런데 네트워크 연동이 아니더라도 구조체 크기를 임의로 판단, offset 으로 멤버에 접근을 시도하면 문제가 될수 있다는 것을 아래에서 보여주고 있다.


먼저, 다음과 같은 형태의 데이터를 빈번하게 파일에 쓰는 경우를 생각해보자.



#define MAX_DATA_SIZE  2048

typedef struct __FileBlock
{
    char     strData1 [2];
    int      nNumber1  ; //4byte
    int      nNumber2  ; //4byte
    int      nNumber3  ; //4byte
    char     strData2 [50];
    char     strData3 [MAX_DATA_SIZE];
} ItemFileBlock;


그리고 이 구조체 변수에 값을 채우고 파일에 그대로 저장하는 경우를 위한 함수를 하나 작성했다,

bool SaveDataToFile(ItemFileBlock* pstFileBlock)
{
    //m_clsFile 는 파일 I/O 를 담당하는 객체
    //구조체를 sizeof(ItemFileBlock) 크기만큼 파일에 저장.
    if( !m_clsFile.WriteRecord((char*)pstFileBlock, sizeof(ItemFileBlock)))
    {
        return false;
    }     
    return true;
}


그리고 이함수를 이용해서 데이터를 저장.

ItemFileBlock stFileBlock;
//이제 stFileBlock 의 항목을 채운다. 
//.....

//pData3 는 이미 사용자의 정보를 가르키고 있는 포인터 이다.
memcpy(&stFileBlock.strData3, pData3, MAX_DATA_SIZE); //흠 복사 할 게 좀 많네  

//함수 호출
if(!SaveDataToFile(&stFileBlock)){
    ....
}


여기까지는 좋다. 뭐 그냥 파일에 구조체 크기만큼 저장하는거니까 이걸로 OK.

그런데 이 개발자는 strData3 항목에 계속 데이터를 복사하는게 마음에 걸린 모양이다. 이미 이 항목에 저장할 데이터의 포인터(pData3)를 가지고 있어서, 굳이 복사를 안해도 될것 같아 성능 향상(실제로 성능이 향상될거 같지는 않다. file I/O가 추가됬으니 - -)을 목적으로 SaveDataToFile 함수를 다음처럼 수정했다.


//이젠 strData3에 저장될 데이터를 포인터로 받는다.
bool SaveDataToFile(ItemFileBlock* pstFileBlock, char* pData3)
{
    //2번에 나눠 파일에 저장. 한번은 strData3 이전 데이터
    // !!! sizeof(ItemFileBlock)-MAX_DATA_SIZE 이것은 ?!
    if( !m_clsFile.WriteRecord((char*)pstFileBlock, 
                              sizeof(ItemFileBlock)-MAX_DATA_SIZE) )
    {
        return false;
    }
    
    //strrData3은 여기서 저장된다  
    if( !m_clsFile.WriteRecord((char*)pData3, MAX_DATA_SIZE)) {
        return false;
    }

    return true;
} 

//그리고 실제 호출시에는 다음처럼 strData3에 불필요한(?) 복사를 생략하여, 
//값을 채우지 않는다.
ItemFileBlock stFileBlock;
//stFileBlock 의 항목을 채운다. 
.....
.....
//memcpy(&stFileBlock.strData3, 사용자의정보, MAX_DATA_SIZE); //생략!

//함수 호출
if(!SaveDataToFile(&stFileBlock, pData3)){
    ....
}



sizeof(ItemFileBlock)-MAX_DATA_SIZE
 
구조체 크기에서 MAX_DATA_SIZE 만큼 빼면 strData3 항목의 시작위치가 될것이라는 가정..

이렇게 구조체의 선언만 보고, 임의로 구조체 크기를 가정하고 거기에 offset연산까지 적용해서 어떤 구조체 멤버에 접근하려는 시도가 문제되는 부분이다. 원래 작성자의 의도는 구조체의 strData3 이전 데이터를 먼저 파일로 저장후, 이어서 실제 사용자 데이터 부분을 저장하려던 것이었다. 불필요한 복사를 생략하고, 이미 구해진 데이터의 포인터를 활용해보자는 목적이었는데, 문제는 sizeof(ItemFileBlock) 이 돌려주는 길이는 컴파일러에 의해 암묵적으로 삽입된 패딩 바이트를 포함하고 있다는 것이다.

offsetof 매크로를 이용, 각 구조체 멤버의 offset 위치를 구해보자. 


#define MAX_DATA_SIZE  2048
typedef struct __FileBlock
{
    char     strData1 [2];
    int      nNumber1  ; //4byte
    int      nNumber2  ; //4byte
    int      nNumber3  ; //4byte
    char     strData2 [50];
    char     strData3 [MAX_DATA_SIZE];
} ItemFileBlock;

void testFunc()
{
    printf("sizeof(ItemFileBlock)[%d]\n",sizeof(ItemFileBlock));
    printf( "offsetof(strData1)  =%d\n",offsetof(struct __FileBlock, strData1 ));
    printf( "offsetof(nNumber1)  =%d\n",offsetof(struct __FileBlock, nNumber1 ));
    printf( "offsetof(nNumber2)  =%d\n",offsetof(struct __FileBlock, nNumber2 ));
    printf( "offsetof(nNumber3)  =%d\n",offsetof(struct __FileBlock, nNumber3 ));
    printf( "offsetof(strData2)  =%d\n",offsetof(struct __FileBlock, strData2 ));
    printf( "offsetof(strData3)  =%d\n",offsetof(struct __FileBlock, strData3 ));
}

//실행 결과
sizeof(ItemFileBlock)[2116]
offsetof(__FileBlock,strData1)  =0
offsetof(__FileBlock,nNumber1)  =4
offsetof(__FileBlock,nNumber2)  =8
offsetof(__FileBlock,nNumber3)  =12
offsetof(__FileBlock,strData2)  =16
offsetof(__FileBlock,strData3)  =66

즉 다음처럼 패딩 바이트가 삽입됨을 알수있다.

typedef struct __FileBlock
{
    char     strData1 [2]; //offset 0
    char     padding  [2]; //offset 2 
    int      nNumber1  ;   //offset 4     
    int      nNumber2  ;   //offset 8    
    int      nNumber3  ;   //offset 12    
    char     strData2 [50];//offset 16    
    char     strData3 [MAX_DATA_SIZE]; //offset 66
    char     padding  [2]; //offset 2114
} ItemFileBlock;


sizeof(ItemFileBlock) 는 모든 구조체 멤버의 실제 길이를 합한 길이 2112 가 아니고, 
컴파일러에 의해 삽입된 패딩 바이트를 포함한 2116을 리턴한다.
그래서 sizeof(ItemFileBlock)  - MAX_DATA_SIZE 이값은 2116-2048 = 68이 되버린다.

이것이 왜 문제가 되는가? 
위 파일 저장 함수에서 2번에 걸쳐 저장을 할때, 처음 쓰기에서는 68 바이트를 저장하고있다. 이렇게 되면 실제 저장되어야할 길이 66 바이트보다 2 바이트를 초과해서 쓴 꼴이 된다. 그리고 2번째 파일 쓰기에서는 2바이트가 밀린 상태로 나머지 strData3을 쓰게 된다. 이런식으로 2번에 걸쳐 파일에 저장시, 실제 파일에 저장되는 구조체의 데이터는, 구조체를 한번에 저장할때와 다른 모습으로 비정상으로 저장된다. 

 
* 정상적으로 구조체가 저장된 경우 

|---------strData1~2----|---------------strData3--------------|---padding----|
          66 bytes                      2048 bytes                2 bytes
* 비정상적으로 구조체가 저장된 경우 
|---------strData1~2--------------------|---------------strData3-------------| 
          68 bytes                                      2048 bytes

이처럼 잘못 저장된 데이터를 다시 파일에서 읽어들이는 경우는 어떨까? 
파일에서 읽어 이를 구조체로 변경하는 경우, strData3 데이터 시작부분이 2 byte가 밀려 있으리란것을 예상할수 있다 (실제로 당하니 멘붕. 데이터를 분명 썼는데 읽으면 안보임 - -).  이것을 해결하기 위해서는 구조체 pack 혹은 명시적으로 패딩 바이트를 삽입하는 방법등이 있는데 그것은 생략한다. 구조체는 일반적인 방법(멤버 참조)으로 쓰는 경우는 문제 없다. 하지만 위에서처럼 offset 으로 멤버의 위치를 유추하려는 시도를 할때는 반드시 암묵적 패딩 바이트를 고려해야만 한다.
  

2014년 5월 15일 목요일

g++ std::thread -pthread option?

std::thread 를 이용한 프로그램을 리눅스 환경에서 g++ 을 이용, 컴파일 하는경우 -pthread 옵션이 필요하다. 
다음과 같은 샘플 프로그램이 있다고 해보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//std_thread_test.cpp
#include <thread>
#include <iostream>

void thread_func()
{
    std::cout<<"hello, I am a thread!"<<std::endl;
}

int main()
{
    std::thread t(thread_func);
    t.join();
}

컴파일시에 다음처럼 -pthread 옵션을 설정해야한다.

g++ -std=c++11 -pthread -o std_thread_test std_thread_test.cpp

옵션을 주지 않는 경우엔 컴파일은 되지만 실행시 core dump가 발생한다.
사용된 g++의 버전은 g++ 4.8.2 으로 c++11 의 기능을 대부분 지원한다.
그렇다면 의문점이 생긴다. c++11 을 지원한다는 g++에 왜 -pthread 란 옵션이 필요한가?
언어 차원에서 지원된다는데 왜 pthread 라이브러리 이런게 보이는건지..?

좀 생각해보니 spec과 구현의 문제라는걸 알게 되었다.
c++11 의 thread specification 을 g++에서는 기존의 pthread 라이브러리를 사용해서 구현한것일뿐이다.(이건 사기?). 
이건 g++ -v 을 실행해보면 확인할수 있다.


Thread model로 posix 를 사용한다 (좀 허무)


2014년 2월 2일 일요일

export_to_sqlite3 : simple command line based utility for exporting oracle or mysql to sqlite3

https://github.com/jeremyko/export_to_sqlite3

This is simple command line based utility for exporting oracle/mysql to sqlite3.

Usage :

export_to_sqlite SQLITE_FILE DB_TYPE DB_USER DB_PASSWD IP PORT DB_NAME

ex : from oracle 
    export_to_sqlite mydb.sqlite ORACLE  scott  tiger  192.168.1.225 1521 orcl

ex : from Mysql
     export_to_sqlite mydb.sqlite MYSQL   user  passwd   192.168.1.204 3306 PCN


auto generated scripts :

sqlite_schema_script.sql ==> sqlite table schema generation script.

sqlite_fill_script.sql           ==> sqlite table insert script.