현재 빅데이터 학습을 위한 전초 단계로 '빅데이터'를 만드는 작업을 진행 중이다.

개인의 자격으로 거대 규모의 데이터를 만들어내기란 여간 어려운 것이 아니다.

때문에 일단 의미 있는 분석이 가능한 데이터를 어느 정도 선까지 모으는 것을 목표로 하고 있다.

현재 목표로 하고 있는 것은 대략 100Gb선이다.


그래서 선택한 것이 트위터의 트윗들이다.


특정 키워드로 검색을 했을 경우 검색되는 트윗들을 모아보기로 한 것이다.

이를 분석하면 검색어로 사용된 특정 단어에 대한 분석이 어느정도 가능하지 않겠냐는 판단에서 내린 결정이다.


그래서 Twitter API를 이용하여 작업을 진행 중인데

처음엔 시행착오가 좀 있었다.


우선 기존에 사용해본 적이 있는 REST API 중 search API를 이용하여 데이터 수집을 진행하였다.

그런데 REST API는 한계가 있었다. 기존에 축적된 모든 트위터의 데이터가 대상이 아닌 것이었다.

6~7회 시도를 해 본 결과 대략 1주일치 분량의 데이터를 얻을 수 있었을 뿐 그 이전의 데이터는

가져올 수가 없었다. 1주일 분의 데이터라 해도 약 60~70Mb 정도의 파일 크기가 된다.

게다가 특정 날짜까지의 데이터를 불러오는 옵션이 있는데 계속해서 데이터를 축적하기 위해서는

매일 한 번 정도는 이 날짜를 가장 최근 날짜로 변경을 해야 하고 그렇게 쌓인 파일에는 중복되는

데이터가 거의 대부분이라는 문제가 있었다.


그래서 구글링을 한 결과 REST API 말고 Streaming API라는 것이 있다는 것을 알았다.

REST API가 배치성이라면 Streaming API는 리얼타임이다. 즉 실시간으로 올라오는

트윗 데이터들을 네트워크가 끊기기 전까지 지속적으로 가져오는 것이다. 


타임라인의 데이터를 가져오는 것은 Public stream이라고 하고 여기에는 3가지 옵션이 있다.

각각은 다음과 같다.



이 중 firehose는 상업적 용도로써 이를 이용하기 위해서는 Twitter사와 계약을 맺어야 하고
또 이용료 또한 엄청 비싸다고 한다. 대부분 데이터 리셀러들이 이용을 하고 있는 듯하다.

결국 개인이 사용 가능한 것은 filter나 sample인데 이 API들을 이용해서 가져올 수 있는 데이터의 양은
firehose의 1% 수준이라고 한다.

결국 filter API를 이용해서 데이터를 가져오기로 하고 filter API가 구현된 PHP 소스를 입수하여
데이터 수집을 시작하였다.

그런데 여기도 문제가 있었으니...
리얼타임인데다가 특정 키워드에 대한 내용만 가져오는 것이다보니 데이터 수집 속도가 매우 느리다.
REST API의 search를 이용할 경우 약 하루 하고 반나절 정도면 60~70Mb정도의 데이터가 쌓이는 반면
Streaming API의 filter를 사용하였더니 3일하고도 16시간 정도 지난 현재 겨우 19Mb 정도의 데이터가 쌓였을 뿐이다. 이래가지고 어느세월에 100Gb를 만드나...ㅠ.ㅠ

업친데 덥친 격으로 오늘 아침에 확인을 해보니 어제 오후 6시경부터 401 Unauthorized 에러가 발생을 하여
데이터 수집이 멈춘 상태였다. 다시 실행을 해보아도 계속 401 에러만 발생을 한다.

역시 구글링을 통해 확인한 결과 트위터 서버와의 시간이 안맞아서 생기는 문제란다.
우선 다음 명령어를 터미널에 입력하는 것으로 해결은 되었다.

mazdah$ sudo ntpdate ntp.ubuntu.com

일단 다시 재가동은 되었지만 어느 세월에 충분한 데이터를 쌓을지가 여전히 문제다...
그냥 매일 search를 돌려서 재가공을 해야 하는 것이 더 빠를 것 같도 하고...

그저 현재는 다른 작업도 밀려있으니 잠시 더 기다려 볼 뿐이다...

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2013/02/06 16:30 


기존 방식의 OAuth와 Twitter API를 이용하여 트위터 서비스를 제공하다가

이번에 iOS 5.0부터 iOS에 통합된 Twitter 프레임워크를 이용해보기로 하였다.

대체로 수정에 어려움은 없었고 전체적인 코드도 매우 깔끔해져서 좋았다.
하지만 한가지 문제가 발생을 했는데...

바로 DM(Direct Message) 목록을 보여주는 화면에서 권한이 없다는 응답과 함께
DM 목록이 보여지지 않는 것이었다.

구글링을 통해 확인한 결과 Twitter 개발자 페이지에서 다음 내용을 찾을 수 있었다.

What about Direct Messages?

The Twitter framework cannot read or delete Direct Messages but it can send them. If your application requires the ability to read or delete Direct Messages, you must follow the traditional OAuth web flow to obtain the user’s permission. You should then use the returned access token and secret for future calls that require DM read permission.

문서 링크 : https://dev.twitter.com/docs/ios

즉, Twitter 프에임워크에서는 DM 목록을 불러오거나 DM을 삭제할 수 없으며 이 기능을
사용하고자 하면 기존 OAuth방식을 따라야 한다는 것이다.

조금 골치아파진 것이 DM 리스트 기능 하나 때문에 Twitter 프레임워크를 못쓰거나 아니면
Twitter 프레임워크과 기존 Twitter API를 함께 사용해야 한다는 것이다.

애초 목적은 앱 내에서 트위터 로그인을 하도록 된 부분을 없애고자 한 것이었는데...
이 상태라면 DM 목록 보기 기능을 빼지 않는 한 목적을 이룰 방법이 없어진다...ㅠ.ㅠ
애플, 트위터...누가 나쁜거냐...-.-

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2012/04/24 11:35


트위터 사용자의 프로필을 가져와서 앱 화면에 뿌려 줄 일이 생겼다.

당근 Twitter의 개발자 페이지로 들어가 API를 검색해보았다.
제일 먼저 눈에 띈 것은

GET users/profile_image/:screen_name

그런데 아무리 이 API를 사용을 해봐도 response값이 계속 null만 나온다.
구글링을 통해 몇가지 변형을 사용해봐도 여전히 응답은 null...
URL을 브라우저에 직접 치면 이미지가 잘만 뜨는데...ㅠ.ㅠ

한참 삽질을 하다가 다시 살펴본 트위터 문서...

This resource does not return JSON or XML, but instead returns a 302 redirect to the actual image resource.

This method should only be used by application developers to lookup or check the profile image URL for a user. This method must not be used as the image source URL presented to users of your application.

이 API는 json이나 xml타입의 응답을 돌려주는 것이 아니란다.
실제 이미지로의 리다이렉션을 리턴한다네. 그리고 그 아래 내용은 이 API는 그냥
사용자에게 프로필 이미지가 있는지 확인하는 차원에서 사용하고 앱에 이미지를
출력하는 용도로는 사용하지 말란다...제길쓴!

결국 아래 API로 처리했다. 그리고 이 것이 맞는 방법인 듯싶다.

GET users/lookup


블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2011/05/31 15:58 


구글 날씨 API는 현재 서비스 종료되었습니다!


내가 구글에게 뭐 해준 것은 없지만

이렇게 갑자기 통보도 없이 바꿔버리면 유료로 제공하는 내 앱은
어쩌란 말이냐...ㅠ.ㅠ

그냥 허접한 구글 아이콘 사용하기 실어서 URL링크하면 될 것을
좀더 멋진 아이콘을 구해다가 이름만 갖게 해서 사용했더니 아이콘 이름이 바뀌어서
날씨 이미지가 안뜬다...ㅠ.ㅠ

일단 임시 방편으로 알려진 이미지 이름을 찾아서 이름만 다른 동일한 이미지를
별도로 추가했다.

http://blog.rockettheme.com/forum/index.php?f=202&p=661808&rb_v=viewtopic

  1. "weather_thunderstorms-40" =>"thunderstorm",
  2.                 "weather_partlycloudy-40" =>"partly_cloudy",
  3.                 "weather_sunny-40" =>"sunny",
  4.                 "weather_overcast-40" =>"unknown",
  5.                 "weather_mostlycloudy-40" =>"mostly_cloudy",
  6.                 "weather_rain-40" =>"rain",
  7.                 "weather_scatteredthunderstorms-40" =>"chance_of_storm",
  8.                 "weather_scatteredshowers-40" =>"chance_of_rain",
  9.                 "weather_snowflurries-40" =>"flurries",
  10.                 "weather_haze-40" =>"haze",
  11.                 "weather_smoke-40" =>"smoke",
  12.                 "weather_fog-40" =>"fog",
  13.                 "weather_dust-40" =>"dust",
  14.                 "weather_icy-40" =>"icy",
  15.                 "weather_snow-40" =>"snow",
  16.                 "weather_sleet-40" =>"sleet",
  17.                 "weather_cloudy-40" =>"cloudy",
  18.                 "weather_drizzle-40" =>"unknown",
  19.                 "weather_windy-40" =>"unknown",
  20.                 "weather_heavyrain-40" =>"unknown"
  21.                 "weather_heavysnow-40" =>"unknown"

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2010/04/17 08:08 



클래스 이름 : NSIndexPath

부모클래스 : NSObject

Framework : Foundation

관련 샘플들 : BonjourWeb, CoreDataBooks, iPhoneCoreDataRecipes,
   TableViewSuite, TaggedLocation

클래스 개요 :

NSIndexPath 클래스는 일련의 배열 모음으로 이루어진 트리에서 특정 노드의
위치를 표현한다. 이 경로를 index path라고 부른다.

각각의 index path내에 있는 각각의 인덱스는 처음 하나의 노드로부터
점점 더 깊어지는 자식 배열의 인덱스를 차례로 표현한다. 예를들면 1.4.3.2라는
index path는 아래의 Figure 1의 내용을 의미한다.



NSIndexPath 객체들은 각각이 유일하며 공유되어있다. 만일 한 index path가
특정한 인덱스 또는 이미 존재하는 인덱스들을 포함하고 있다면 이 객체는
새로운 인스턴스가 생성되는 것이 아니라 기존의 객체가 반환된다.


블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2010/04/10 21:39 


NSSortDescriptor Class

NSSortDescriptor 인스턴스는 객체들을 비교하는데 사용하기 위한 속성들과

그 속성들을 비교하는데 사용하기 위한 메서드, 그리고 그 비교를 통해 오름차순이 되어야 하는지

내림차순이 되어야 하는지를 명시하여 객체들의 정렬을 위한 기준을 정의한다.

NSSortDescriptor의 인스턴스는 불변성을 가지고 있다.


여러분은 정렬 순서(오름차순 또는 내림차순)와 비교를 수행할 selector(선택적으로 지정 가능)와 같은

비교될 속성들의 키를 명시함으로써 NSSortDescriptor의 인스턴스를 생성할 수 있다.

인자가 3개인 생성자의 경우 caseInsensitiveCompare:나 localizedCompare:와 같은

비교 selector를 명시할 수 있다. 만일 정렬되어야 하는 객체들로부터 sort descriptor의 비교 selector로

응답이 없을 경우에는 예외가 발생하게 된다.


 주의 : 많은 NSSortDescriptor의 메서드들에 대한 설명을 보면 "property key"를 언급하고 있다.

간단하게 말하면 property key는 객체의 attribute나 관계를 나타내는 속성에 대한 id 역할을 하는 문자열(키)를

말하는 것이다. 여러분은 Cocoa Fundamentals Guide 와 Key-Value Coding Programming Guide

있는 "Object Modeling"을 통해 이 용어에 대한 논의 사항을 확인할 수 있을 것이다.


sort discriptors를 사용하게 되는 상황은 여러가지가 있는데 예를들면


- 배열을 정렬할 때 (배열은 NSArray나 NSMutableArray의 인스턴스이며

  sortedArrayUsingDescriptors:나 sortUsingDescriptors:를 보면 된다)

- 두 개의 객체를 직접 비교할 경우(compareObject:toObject를 보라)

- 테이블 뷰의 요소들이 어떻게 정렬되어야 하는지 명시하고자 할 경우

   (sortDiscriptors를 보라)

- 배열 컨트롤러에 의해 관리되는 요소들이 어떻게 정렬되어야 하는지

   명시하고자 할 경우(sortDiscriptors를 보라)

- 호출되는 요청으로부터 반환된 객체들의 정렬순서를 명시하기 위해 코어 데이터를

   사용하고자 할 경우(sortDiscriptors를 보라)


[원문] iPhone Dev Center : NSSortDescriptor Class Reference

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

최초 작성일 : 2010/03/28 08:16 


UINavigationController

부모클래스 : UIViewController, UIResponder, NSObject

관련 샘플들 : CoreDataBook, TableSearch, TableViewSuite, TaggedLocations, WorldCities

개요 : 계층적 구조를 갖는 데이터의 네비게이션 관리에 특화된 뷰 컨트롤러. subclassing은 고려되지 않은 대신

애플리케이션의 유저인터페이스를 통해 개발자가 다루고자 하는 컨텐츠에서 계층적 속성을 나타내고자 할 때

이미 구현되어있는 인스턴스를 그냥 사용하면 된다.

이 클래스는 컨텐츠간의 이동을 효율적이고 쉽게 표현할 수 있도록 해준다.


화면에는 일반적으로 데이터의 계층적 구조를 모방한 네비게이션 인터페이스가 보여진다.

계층적 구조 각각의 단계에서 그 단계의 데이터를 화면에 출력할 수 있도록

적절한 화면(뷰 컨트롤러에서 관리되는)을 제공해야 한다.

아래 그림은 아이폰 시뮬레이터에 설치된 네비게이션 인터펭이스를 구현한

애플리케이션의 예이다.


첫번째 화면은 선택버튼을 포함함 애플리케이션의 리스트가 보여진다.

하나의 애플리케이션을 선택하면 애플리케이션 설정을 위한 개별 설정 항목들과

설정 항목들의 그룹이 나타난다. 여기서 다시 하나의 항목을 선택하면

또다른 하위 설정 목록들이 보여지는 식이다.

최초의 Root 뷰를 제외한 나머지 뷰의 네비게이션 컨트롤러는 계층 구조의

이전 단계로 돌아갈 수 있는 back 버튼이 생기게 된다.





이러한 네비게이션 컨트롤러 객체는 현재 보여지고 있는 화면들을 네비게이션 스택을 이용해 관리한다.

이 스택의 제일 밑에는 Root 컨트롤러가 있게 되고 가장 위에는 현재 화면에 출력되고 있는 뷰 컨트롤러가

위치한다.


애플리케이션 실행시에 스택의 상태를 변경시키기 위해 네비게이션 컨트롤러 객체의 함수를 사용할 수 있다.

가장 일반적인 작동은 새로운 뷰 컨트롤러를  pushViewController:animated:함수를 사용하여

스택에 밀어넣는(push) 것이다.


새로운 뷰 컨트롤러를 스택에 넣게 되면 뷰 컨트롤러는 화면에 보여지게 되고 네비게이션 컨트롤들은

이러한 변화를 반영하여 업데이트 된다. 보통 사용자가 다음 단계의 정보를 보기 위하여 항목을 선택한데 대한

응답으로 뷰 컨트롤들을 스택에 넣게 된다.


생략…


Navigation Controller Views

UINavigationController 클래스는 UIViewController를 상속받고 있기 때문에 view 속성을 통해 그 자체의 뷰에

접근할 수 있다. 네비게이션 인터페이스를 배치할 때 어떠한 형태의 뷰 구조를 생성하든 가장 하부에는 이

뷰를 배치해야 한다. 예를 들어 네비게이션 인터페이스 자체를 배치한다고 할 때 윈도우의 메인 서브 뷰로 만들어야

한다. 네비게이션 인터페이스를 탭 바 인터페이스 내에 배치할 경우에는 적절한 탭 안에 네비게이션 컨트롤러의 뷰를

Root 뷰로 배치해야 한다.


네비게이션 컨틀러의 뷰는 네비게이션 바, 선택적인 툴 바, Custom Content 등 몇몇 다른 뷰를 포함하고 있는 컨테이너이다.

아래 그림은 이 뷰들이 어떻게 전체적인 네비게이션 인터페이스를 구성하고 있는지 보여준다. 네비게이션 바나 툴 바의 내요이

바뀌더라도 뷰들 자체는 변하지 않는다. 단지 Custom Content만 뷰 컨트롤러를 반영하기 위해 바뀌고 네비게이션 스택의

가장 위에 들어간다.





주의 : 커스텀 뷰가 사용할 수 있는 공간의 크기는 (다른 네비게이션 뷰의 크기에 의존해)다양할 수 있기 때문에

반드시 커스텀 뷰들의  autoresizingMask 속성을 지정하여 유연한 높이와 넓이 값을 갖도록 해야 한다.

뷰가 화면에 출력되기 전에 네비게이션 컨트롤러는 자동으로 가능한 공간에 맞춰 위치와 크기를 정하게 된다.


생략…

블로그 이미지

마즈다

이미 마흔을 넘어섰지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^