1. Twitter API 찾기.

특정 Tweet을 Retweet 한사람을 조회 하는 API

https://dev.twitter.com/docs/api/1/get/statuses/%3Aid/retweeted_by

/statuses/:id/retweeted_by

* 주의 할점은 한번에 100명 까지만 조회 하기 때문에, parameter 중에 page 를 이용하여 추가 조회를 해야합니다.


2. Python 에서 Twitter API 호출하여, 20명 추출하기.

제가 분석할 tweet의 id 가 '194985314832490496' 임으로 호출 url 은 아래와 같이 됩니다. 

https://api.twitter.com/1/statuses/194985314832490496/retweeted_by.json

해당 json 은 Dictionary 의 array 로 되어 있습니다. 제가 필요 한건 리트윗 하신분의 id 임으로 'screen_name' 속성만 가져오면 될것 같습니다.

아래는 'Visual JSON'이라는 어플로 호출해본 결과 입니다.



# -*- coding:utf-8 -*-
import httplib
import urllib
import csv 
import codecs
import json
import random

tweet_id='194985314832490496'

def getJson(page):
    conn = httplib.HTTPConnection('api.twitter.com')
    conn.request("GET","/1/statuses/%s/retweeted_by.json?count=100&page=%s"%(tweet_id,page))
    response = conn.getresponse()
    data = response.read()
    encoding=response.getheader('content-type').split('charset=')[-1]
    conn.close()
    jsonData = json.loads(data)
    return jsonData

if __name__=='__main__':
    entries = []
    page=1
    while(1) :
        jsonData = getJson(page)

        for jsonItem in jsonData :
            entries.append(jsonItem['screen_name'])

        if len(jsonData) < 100:
            break

    random.shuffle(entries)
    winners = entries[0:20]
                                                                                                                                                                
    print winners

위의 코드는 해당 tweet의 screen_name 목록을 만들고 shuffle을 한후, 상위 20명만을 뽑아내는 코드 입니다.




http://www.mobclix.com/appstore
http://majicjungle.com/majicrank.html
http://applyzer.com
http://148apps.biz/app-store-metrics/
http://topappcharts.com/
http://www.yappler.com/Apple-iPhone-App-Store-Stats/
 

1. mobclix


한번 써볼려고 하니 :( 정검중이군요.

2. majicjungle.com



 매직 정글은 앱으로 보여주는군요

3. applyzer.com

 

find ./ -name "Thumbs*" -print0 | xargs -0 ls


-print 0 on "find" 

"It prints the pathname of the current file to standard output, followed by an ASCII NUL character" 

-0 on "xargs"

"Change xargs to expect NUL (``\0'') characters as separators, instead of spaces and newlines.
  This is expected to be used in concert with the -print0 function in find(1)." 


xargs 와 find 를 조합하라고, -0 와 -print0 를 조합해서 사용하라고, man page에 소상히 적어 두었군요 :)

 

A. Bracket을 같은 줄에 쓰는 스타일 - Java 개발자들이 선호
 

if {
}


 
B. Bracket을 개행한후에 쓰는 스타일 - C 개발자들이 선호

if
{
}



다녔던 회사들중에
C 로 개발하던 회사에서는 Coding Convention 으로 B Style이 표준이었고,
Java로 개발하던 회사는 A Style이 표준이었습니다.

사실 왜 C 개발자들이 B Style을 선호하는지에 대한 별다른 생각이 없어서,
Java로 개발하는 회사로 이적한후 A Style을 따르고,
C로 개발할때도, A-Style로 하도록 습관을 고쳤습니다.

그러다 문득..

if ( a== 1) {
}
else {
}


같은 코드가 있을때 Debuggin 위해 else 조건문만 항상 실행하려고 하니 
B Style에서는

#if 0
if (a  ==1) 
{
}
else
#endif 
{



이렇게만 해주면되는것을

 A Style에서는 조건을 항상 거짓으로 변경하거나
개행한후에 #if 0 를 해주어야 하더군요..
정말 별건 아니지만, ㅋㅋㅋ
B Style로 돌아 갈까 심각하게 고민중입니다 ㅎ

혹시 A Style이 가지고 있는 장점이 있을까요? :)

 

  1. 신규하 2011.09.28 17:23 신고

    저랑 비슷한 고민을 하시는 분의 글을 보니 반갑네요 ^^;
    저두 c하다가 자바하다가.. 하면서..
    이래저래... 귀찮았는데..
    c 개열의 프로그램을 짤때는 b 스타일로 짜고,
    자바를 짤때는 a스타일로 짜고 있습니다.
    자바를 짤때 a를 쓰는 이유는 이클립스가 자동으로 코드 정리 할 때 저렇게 해 버리더라구요 -_-;;
    반쯤 농담입니다만, 자바를 짜면서는 b스타일로 짜다가..
    저장하기 전에 자동 정리를 해서 저장합니다.

    개인적으로는 코드 읽기나 정리 할때는 b스타일이 좋은데,
    제 생각에는 자바의 언어적 특성 때문에 저런 스타일을 선호 하는게 아닌가 싶네요..

    • taehoon.Koo 2011.09.28 17:55 신고

      eclipse 가 A Style 로 정리하는건,
      Code Formatter 만 살짝 변경해주면 되는것이긴 한데요 ㅎ

      여튼 같은걸로 고민해본 사람이 있다니...

      저도 반갑습니다 ! ㅎㅎ


개인적으로 읽을 책들을 정리하고, 
왜 읽는가를 생각하면서 읽기 위해 정리해봅니다.

그외에 책을 추천해주시면 너무나들 감사하겠습니다 :)

1. 디자인과 인간심리



소프트웨어 개발자가 디자인에 대한 이해가 필요 할까요?

그럼요 ! 소프트웨어는 혼자 만드는 게 아니니까요.
그래픽 디자이너, UX 설계자 등과의 원만한 커뮤니케이션을 위해 그들의 일에 대한 이해가 필요 하다고 생각되어 읽기 시작했습니다.

아이러니 하게도 

" 이책은 한번에 3장 이상 읽기가 힘드니, 책 디자인에서 인간심리를 전혀 고려하지 않은 셈이죠 ;ㅂ; "
 
2. 실전 코드로 배우는 실용주의 디자인 패턴


읽어본 디자인 패턴책이, Head First , GOF 두권 정도 인데,
디자인 패턴에 대한 깊은 성찰을 위해,
여러 사람이 쓴 책을 읽어 보고 싶다는 생각이 들어, 집어 들었습니다.


아자 아자 아자 부디, 책을 읽는 것을 넘어, 서평을 쓸 정도의 부지런함이 생기길 바라며..
시작합니다 :)
 
 
  1. kyungtaek 2011.10.05 17:23

    디자인과 인간심리는 저도 예전에 읽어봤습니다.
    정말 한 챕터를 넘기기가 힘든 책으로 기억하네요 ;_;


온라인 눈쇼핑을 좋아라 하는 저입니다 :)

오늘 눈여겨 보게 된 상품은 "모니터 메모보드" 입니다. 


<출처 : 상상날개(http://www.sgsgwg.com) >

그러다 문득 이런 생각이 들었습니다.

Scrum DashBoard용 화이트보드를 항상 갖고 싶었는데, 저걸 이용하면 더 편하지 않을까 하는 생각말입니다. !!

아래와 같이 말이죠 :)


개당 가격도 현실적인 수준이라 아마 조만간 해보지 않을까 싶습니다.

문제는 제가 모니터 3개가 붙어 있는 시스템이라, 어떻게 잘 적용할지가 관건입니다 ㅎㅎ 

파이썬 Python 3 프로그래밍
http://kangcom.com/sub/view.asp?sku=200906160008&mcd=571  

내가 존경해 마지 않는 형이, 극찬한 Python. 수박 겉이라도 좀 핧아 보고자..

잘 팔리는 아이폰 앱 개발: 기획에서 마케팅까지 아이폰 비즈니스의 모든 것
http://kangcom.com/sub/view.asp?topid=5&sku=201103180002 

Seven Languages in Seven Weeks  
 

http://kangcom.com/sub/view.asp?sku=2010F0862392   

심심할땐 심실풀이 땅콩

소프트웨어 아키텍트가 알아야 할 97가지 
http://kangcom.com/sub/view.asp?sku=201104010001&mcd=571 

뭐 이정도 인데,,, 언제 보나 - _-  

Snow Leopard에는 고맙게도, svn ( client , admin) 과 Apache가 기본설치 되어 있다.

만약 /var/svn/repo 로 svn repository가 있다고 가정하고 Apache로 연동하는법을 살펴 보겠다.

  1 LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
  2 
  3 <Location /svn>
  4     DAV svn
  5     SVNParentPath /var/svn/
  6 </Location>

svn.conf 파일을 /etc/apaches2/other 에 생성한한다.

apache를 재시작하면 svn.conf 파일이 알아서 로드 된다.  재시작하는 Command는 아래와 같다. 

sudo /usr/sbin/apachectl restart


http://localhost/svn/repo 로 접속하면 된다 ^^





Daily Build라는 개념을 처음 알게 된건, 아마도,
2007년 언젠가, "조엘 온 소프트웨어"라는 책을 읽으면서 였을 껍니다.

1년차 개발자로써, "조엘 테스트" 항목에 있으니까, 그저 좋은 건가 보다 하면서,
다니고 있던 회사에 도입을 극구 주장했었습니다.

지금 생각해 보면 참 우스은 일이죠. 뭐가 어떻게 좋은건지도 제대로 이해하지 못하면서,
좋은가 보다 하면서 도입하자고 했으니 말입니다.

최근에, 이 Daily Build 라는 녀석에 대해서 다시 한번 생각해봤습니다.

" 이거 정말 필요한거야 ? " 라는 생각말입니다.

결론부터 말씀드리면,

"평생 혼자서만 개발할꺼라면 필요 없다."
그러나, 그런일은 거의 없겠죠? ^^

"소프트웨어 개발" 에 "협업"이라는 키워드가 추가되면, "Daily Build"가 힘을 발휘합니다.

우리가 협업을 하고 있다고 가정해봅시다.
거기다가, 우리의 프로젝트는 "국제적인" 프로젝트라서,
내가 퇴근하고나서야, 일을 시작하는 나라에 사는 사람과 협업을 하고 있습니다.

나는 퇴근하기전에 작업물을 Commit하고 갔는데,
재수가 없게도, Build가 깨져버렸습니다. 물론 Daily Build를 하고 있지 않으니, 나는 알턱이 없죠.

저 멀리 아주 먼 나라에서 같이 일하는 개발자는 기쁜 마음으로 출근했지만,
이런 우라질, 소스 컴파일 이 안됩니다.ㅜㅜ

그 사람은 자기가 잘 알지도 못하는 코드를 분석해가며, (거기다가 욕을 해가면서 ... )
수정하고 나서야, 자기 일을 시작하게 됩니다.

다음 날 출근한 저는 내 코드를 잘 알지도 모하는 녀석이, 기괴한 방법으로 수정했음을 발견합니다.
아.. 나는 Refactoring을 해야 겠군요 ;ㅂ;

만약, 여기에 Daily Build를 하고 있었다면 어땠을까요?

나는 퇴근하기전 Daily Build가 깨진것을 확인하고,
수정을 해놓고 나서야 퇴근합니다.

그럼 외쿡인 개발자가, 잘 알지도 모르는 소스를 분석할일도, 수정할일도 없었을테고,
내 소스를 그 사람이 자기 멋대로 수정할 일도 없었겠죠.

바로 이것입니다.

Daily Build는 빌드가 깨지는 일을 방지합니다.
CI Server를 통해 자동화 된 테스트 까지 "정상적"으로 수행시키도록 프로젝트를 꾸려가면,
S/W 가 Compilable 한 상태 뿐 아니라, "Runnable"한 상태를 유지하도록 도와줍니다.

사실 Daily Build라는 말을 사용했지만,
Commit Build, Integration Build 등등 다른 말로 표현되고 있는 "Build 자동화"에 대한 이야기입니다.

약간의 극단적인 예를 들긴했지만, 같은 사무실에 동시간대에 일하는 사람들도,
이런 자동 빌드가 없는 경우 , 빈도는 조금 적을 수 있겠지만, 여전히 같은 문제가 발생합니다.

"나는 Build 자동화를 무조건 도입해야 한다 !" 라고 생각하지 않습니다.

모바일 앱 개발 같은 경우, 혼자서 작업하는 경우도 분명히 많습니다.
그런 경우 Build 자동화는 사실 큰 의미가 없습니다.

당신의 프로젝트가 혼자서 하는게 아니라면,
"나는 무조건 빌드자동화를 도입해야 한다" 고 생각합니다.




SRP


S/W 공학에서 특정 Module을 Design할때, 특정 모듈이 단 하나의 책임만을 가져야 한다는 원칙을 의미한다. 


SRP에서 말하는 책임은 "변화의 주체"이다. 


Module을 변화시킬수 있는 주체는 단 하나여야만 하는것이다.


이 원칙을 지키게 되면, Module의 분리가 일어남으로 거시적인 관점에서의 S/W Artchitecture의 복잡도가 상승하는 것처럼

보일 수도 있다. 


그러나, 특정 모듈의 Task가 단순해짐으로써, 개발효율 , 그리고 유지보수성이 증대하게 된다. 

거기다가 사실은 S/W Architecture의 복잡도 역시 줄어 들게 된다


내가 추구하는 간결함과 미니멀리즘에 잘 부합하는 내가 명심하는 원칙중 하나이다. 

+ Recent posts