개발정리를 위한 개발로그, 발로그!

2015.02.01 20:28 "코드 이그나이터 관련" 포스팅 이후에 약 2년의 시간이 흘렀다.


그 이후에 내가 얻은 것 무엇이고, 잃은 것은 무엇인가

많은 생각이 든다. 


어제 친구들을 만났다. 

각자의 자리에서 열심히 하고 있구나, 의미 없는 시간을 보내지 않고 의미 있는 시간을 보냈다면 후회가 든다.


아직 늦지 않았다.

지금부터 다시 시작하면 된다.


친구들도 만나고, 이야기를 하고 나의 자리에서 최선을 다하자.


비판 보다는 긍정을,

절망 보다는 희망을,

혼자 보다는 우리를 이야기 하며 살자.


완벽해지려 하지 않고, 

집중하고 내가 잘하는 것을 잘하자.


--


영리하게 살자. 해야할 것은 언젠간 해야 한다.


-- 


영어를 잘해야 한다.

표현하지 못하면 의미가 없다.


--


오픈소스 관련해서 도움을 많이 받았다.

공유하자. 내가 얻은 것들을.


2016년 12월 10일 - 과거로부터 청산하자. 





하나씩 풀어보고자 한다.

SRM 144 DIV 1 ( 300 - Point 문제 ) 


- 문제 링크는 어떻게 하는지 몰라서 패스!


처음엔 DFS, BFS 류의 서치인줄 알았으나 생각해보니 그런 류의 문제는 아니였음

사실상 문제 속에 답이 있어서, 처음에 헛다리 안짚고 진행하면 문제가 없음


내 풀이 방법은 아래와 같음

( 암호화 전의 String을 B, 암호화 후의 String을 E라 하겠음) 

E를 통해 B를 알아내는 문제


B의 첫번째 값을 0 혹은 1로 가정하고 진행.


P[i] 번째 값은 B[i-1] + B[i] + B[i+1] , 큰 의미는 없지만 수식으로 나타내면 P[i] = B[i-1] + B[i] + B[i+1];


P[0] = B[0] ( 이 값을 0 혹은 1 로 가정 ) + B[1];

이렇게 B[1]을 구할 수 있음, P는 이미 알고 있기 때문에


이제 문제되는 부분은 B가 올바르게 구해졌는지 아닌지 체크

- P[i] - B[i-1] - B[i] = B[i+1]; -> 이렇게 구한 값이 0 혹은 1이 아니면 올바르게 추출되지 않았다고 판단하면 된다. 


어렵게 생각하면 어렵지만 정말 쉬운 문제! 




어제 작성한 코드 중에 나름 필요한 코드가 있어 이곳에 다시 업로드


안드로이드 스크린 사이즈 가져오기 ( Fullscreen size ) 

  public int [] getScreenSize(Activity context) {

        Display display = context.getWindowManager().getDefaultDisplay();
        int [] realSize = new int[2];

        if (Build.VERSION.SDK_INT >= 17){
            DisplayMetrics realMetrics = new DisplayMetrics();
            display.getRealMetrics(realMetrics);
            realSize[0] = realMetrics.widthPixels;
            realSize[1] = realMetrics.heightPixels;
        } else if (Build.VERSION.SDK_INT >= 14) {
            try {
                Method mGetRawH = Display.class.getMethod("getRawHeight");
                Method mGetRawW = Display.class.getMethod("getRawWidth");
                realSize[0] = (Integer) mGetRawW.invoke(display);
                realSize[1] = (Integer) mGetRawH.invoke(display);
            } catch (Exception e) {
                realSize[0] = display.getWidth();
                realSize[1] = display.getHeight();
            }
        } else {
            realSize[0] = display.getWidth();
            realSize[1] = display.getHeight();
        }
        return realSize;
    }


* 하단 시스템 바(System bar)가 있는 폰에서 나름 필요한 코드가 아닌가 싶음. 

* 안드로이드 버전 14 이하(4.0)에서 원활히 동작 


PHP로 Datetime 익스텐션을 만들고 있었는데, 아래에도 언급하였지만 Github에도 등록을 하는 게 나을꺼 같아, Github에 등록된 다른 라이브러리를 찾아보다 묘한 파일을 하나 발견하게 되었다.



composer.json  


거의 모든 PHP 라이브러리가 해당 파일을 포함하고 있었다. 뭔가해서 다시 구글링을 해보니 아래의 사이트를 발견!


나도 왠지 이아이를 반드시 써야할 것 같은 의무감이 들어 Getting Started를 클릭하여 하나하나씩 읽어보았다.


1. Dependency management 

- 컴포저는 프로젝트 베이스로 패키지 또는 라이브러리를 관리한다.  

- npm, bundler 에서 영감을 받았다. (개념적으로 이해하기 어려운 분들은 컴포저(composer)가 npm,bundler와 비슷한 역할을 한다고 생각하시면 될듯)

- 컴포저를 통해 특정 라이브러리의 디펜던시 문제를 해결할 수 있다. 

( 간단히 정리해보면 A라이브러리가 있고, A가 B라이브러리에 디펜던시가 있을때 개발자는 A만 INCLUDE해도 컴포져를 통해 발생할 수 있는 문제를 해결할 수 있다. 컴포져가 알아서 디펜던시가 있는 라이브러리 혹은 프로젝트를 다운받아 설치해준다.  )


2. Declaring dependencies

- 위에서 컴포저의 개념에 관해 간단히 설명했고 이제 어떻게 사용하는지 알아보자!

Sample : 

- monolog 라는 라이브러리를 사용해야 하는 경우 , 프로젝트 내에 composer.json를 생성하고 아래와 같이 파일을 생성한다.

{
    "require": {
        "monolog/monolog": "1.2.*"
    }
}

https://github.com/Seldaek/monolog

monolog/monolog <- 라이브러리 이름 

1.2.* <- 필요한 라이브러리 버전 


이렇게 composer.json 파일을 생성하고,  composer가 설치되어있다는 가정하에

php composer.phar install

쉘에서 위와 같이 입력하면 

해당 프로젝트 내에 vendor/monlog/monolog 로 관련 파일들이 추가 된다.


이제 monolog를 작업 중인 프로젝트 내에 포함하려면 

require 'vendor/autoload.php';

요렇게 기재하면 된다. 이제 해당 라이브러리를 php내에서 사용할 수 있다.


이 정도까지 알아보니, 왜 github의 php 라이브러리들이 composer.json을 작성하여 업데이트 하는지 이해가 된다. json 포맷이나 어떤식으로 디펜던시를 찾아서 처리하는지 궁금한 부분이 있지만 일단 오늘은 여기까지.


3. System Requirements 

- 컴포저는 PHP 5.3.2 이상에서 동작함!

- 컴포저는 윈도우, 리눅스, OSX에서 원활히 돌아감.



설치 방법은 굉장히 쉽기 때문에 링크로 대체! 

https://getcomposer.org/doc/00-intro.md#installation-linux-unix-osx


--


확실히 PHP는 특정 라이브러리 INCLUDE 나 REQUIRE 과정이 한번 꼬여버리면 답도 없어서 npm같은 프로그램이 있었으면 했는데, 이미 있었구나.. ㅋ


composer, 한번 잘 써 봅시다! 


주말 남는 시간을 어떻게 활용할까 고민하다가 평소에 자주 쓰는 함수들을 모아 PHP 라이브러리를 만들겠다고 결심, 기왕이면 오픈소스로 개발하는 것이 나을 꺼 같아, 깃허브에 계정을 생성하고 기존 PHP 라이브러리들을 찾아보았다.


이것 저것 보던 중에 나름의 개발룰이 있다는 것을  알게되었고, 조금 더 명확하게 알고자 여러 검색 엔진을 통해 관련 자료들을 찾아보았다. 


영어가 능숙하지 않기 때문에, 처음엔 국내 검색엔진을 통해 자료들을 찾았는데 아쉽게도 원하는 정보를 구할수가 없었다.  같은 검색어를 구글에 넣어보았더니, 어렵지 않게 원하는 정보를 찾을 수 있었다. ( 물론 해석에 시간이 소요되긴 했다. )

이런 활동 중 몇가지 느낀 점이 있어 블로그에 글을 남긴다.


1. 확실히 구글이 낫다.

 최근에 국내 포털들의 검색 품질이 많이 좋아졌다고는 하나,  전문적(?)인 지식을 검색함에 있어 구글의 활용도는 압도적이다. 확실히 더 넓고 깊은 느낌을 준다.( 거기에 개인적으로 네이버의 섹션별(블로그, 카페, 뉴스 이런형식으로 구분되는) 검색 결과 방식을 그리 선호하지 않는다. )


2. 대한민국에 아직은 "빨리" 사용하고자 하는 분들이 많다.

 사실 이 생각이 들어 이 글을 쓰게되었다. 네이버, 다음 등에서 특정 모듈, 라이브러리가 어떤 것인지 찾아보려했지만 원하는 정보는 아쉽게도 없었다. 물론 관련 검색 결과는 많이 나왔지만 대부분 이 라이브러리를 어떻게 프로젝트 내에 포함시킬수 있는지만 적혀있는 곳이 대부분 이었다. (특정함수, 메소드 사용을 위해) 

 검색된 결과를 보며, 아직은 라이브러리, 모듈을 어떻게 "빨리" "사용"하는 부분에만 집중되어 있구나 라는 생각이 절로 들었다. ( 내 검색 실력이 미숙해서 일수도 있다.)

 물론 이런 부분이 "나쁘다", "안좋다" 평가할 순 없겠지만 아쉬운 것은 사실이다.


3. 생각보다 굉장히 쓸만한 코드가 많이 올라와 있다. 하지만 거기까지...

 생각했던 몇가지 기능들을 이미 구현한 사례가 있을까 싶어 찾아보았는데 생각외로 비슷한 함수들을 제작해놓으신 분들이 많이 계셨다. ( 한국어 사이트 기반 ) 하지만 아쉬운점은 거기까지 였다는 점. 이를 조금 더 정리해서 모듈화, 라이브러리화 하였으면 이곳에서도 어쩌면 jQuery , CodeIgniter같은 글로벌 프레임웍이 나오지 않았을까 하는 아쉬움이 든다. (한국의 3D IT 문화와 빨리빨리 문화가 결합하여 이런 결과가 나온것이 아닌가 하는 생각이 들기도 한다.)


 삐딱하게 쓴 글이기는 하나, 검색을 하며 느낀 점은 확실히 있다. 나아지고 있다는 점이다. 국내 개발 환경이 열악함을 인지하고 개선하고자 하는 분들이 많이 계신것 같다.

미약하게나마 나도 도움이 되었으면 한다.


블로그를 더 열심히 운영해야하는 이유도 생겼다.


다들 화이팅!




안녕하세요, 개인 개발자(?) 입니다.

약간의 여유가 있어 

개발하고자 하는 이런 저런 것들을 정리해야하는 것이 나을 것 같아 블로그를 개설하게 되었습니다.

최선을 다해 정리해보도록 하겠습니다.


아마 주로 언급될 내용은 PHP, Javascript, CSS, C#, Android 쪽이 아닐까 합니다.

잘 부탁합니다.