Swift? F-Script!!!

참.. 이게 노장 취급 당하는 세상이 오다니. http://www.fscript.org/
요새 Cocoa 한다는 사람들 모르는 사람들 많다. javaScript어쩌고 하면서도…

F-Script야 말로, 코코아 함수를 그대로 쓸 수 있는 스크립트 언어.

빠른 프로토 타이핑용으로 각광을 받고자 노력했지만, 솔직히 내 생각으론 프로토 타이핑 용으로 그다지 장점이 없음.
왜냐하면 이미 Obj-C에 Cocoa가 충분히 깔끔해서 빠르게 만들 수 있거든. 이 F-Script를 좀 애플이 후원해주고 했으면 충분히 더 클 수도 있었겠지만, 대놓고 애플 의존적이란 게 문제. 루비 같은 경우는 그런게 없잖아.
더군다나 당시는 iPhone도 없었고, 말그대로 MS의 시장 점유율이 산같이 보이던 때지.
그러다가 어느날 키노트에서 Steve Jobs가 OS 시장 점유율 표를 가지고 나왔지.
PC 시장에선 Windows가 압도적, 맥은 조금.
근데 산업 전체를 놓고 OS 점유율을 보면 Windows는 사실 극히 일부분을 차지할 뿐이었던 것이지.
우리가 사용하는 제품들, 알게 모르게 이런 저런 OS가 들어간게 많거든.
그걸 embedded OS라고 부르지.

근데 스티브 잡스가 전화기 OS에 관심을 보인 것이고, 전화기 사용자는 당연히 그 숫자상으로 컴퓨터 사용자 수, 혹은 컴퓨터 구입자 수보다 많은거라. 그래서 그 시장을 빠르게 잡으면 (이미 MS는 진출해 있었지만, 죽을 쑤고 있었고 방향을 잡지 못해 갈팡 질팡하던 때라)  MS를 잡을 수 있다는 생각이었던 것이지. 그리고 그 생각은 적중하지.
그때의 MS와 Apple의 입장과 지금을 보면 정말 천양지차…

아무튼 애플이 그렇게 조그만 위치를 차지할 때라, 애플 환경에서만 사용하는 스크립트 언어? 아무리 잘 만들어졌어도 그다지 의미가 없는거라. 맥을 서버 시장에서 많이 쓰면, 거기서 자동화하기 위해서라도 배운다지만..
그리고 어차피 shell script, perl, python등이 잘 하고 있는데 뭐.

그러다가 python-Cocoa 바인딩도 나오고, 나름 잘 나가고 있던게 Ruby-Cocoa
Xcode 3때 애플 자체에서 Ruby를 지원했지만 얼마 안가 손 놨지 (도대체 왜!)
근데 그때에 비하면 요새 Ruby도 많이 식은 거 같네. Ruby Rails 책 쏟아지곤 했는데.
물론 오픈 소스 커뮤니티에선 계속 지원했지만, 뭐랄까 식탁에 올라가기 전까진 각광 받던 반찬이 일단 식탁에 올라갔다가 내려 가니 거들떠 보지도 않는 그런 분위기? 실제로 그 반찬이 맛이 없어진 것도 아닌데 말이야.

사실 Swift를 보면서 성공할까 싶은게 바로 이 F-Script의 행적을 봐왔기 때문이야.
언어로써 성공하려면 특정 플랫폼에서만 되면 안되. Obj-C는 운이 좋았던 것이고..
마친 iOS로 시장이 팍 관심을 받으니 Only-One 언어인 Obj-C가 올라간거고. (사실 HTML/JavaScript일 뻔 했지. WebOS.. iOS 만들던 팀에서 개발자의 관심을 끌려면 사람들이 더 많이 사용하고 뜨거운 감자를 써야한다고 해서 HTML/JavaScript로 만들던 거니까.

근데 Swfit는 왠지 C/C++/Obj-C의 반열이 아니라 Ruby/Python/Perl의 반열 같은 느낌이 든단 말이야.
아니 사실은 Pascal의 부활 같기도 하지만. 사실 많은 부분이 Pascal 닮았지.

솔직히 LLVM이 Obj-C라고 지원을 Swift보다 못할 이유는 없다고 봐.
누구는 디스패치가 느리다고 하는데, 그건 개선하면 되잖아. 물론 개선이 쉽지는 않을 수도 있지만, 아예 새로운 언어를 만드는 놈들이 뭐.. (물론 때론 새로 만드는게 있는거 고치는 것보다 어렵다는 것도 알아. 아. 귓속에 반론을 제기하는 미국 놈들, 한국 애들 목소리가 들린다) 어차피 Obj-C는 상당히 C에 얇게 덧붙인 거잖아. 아. 아.. 그래. 요샌 많은 기능을 넣어서 물론 복잡해지긴 했어. 하지만 C++만큼 복잡해?
그런거 아니잖아.

솔직히 Swift는 기술적인 것보단 (없지는 않지만) 전략적인 포석이란 생각이 더 들어.

하지만 내 이거 하나 말하지.
어떤 컴퓨터 기술 회사가, 자기거에서만 도는 언어를 만들었을때, 항상 실패했어.
아니면 거의 회사를 들어 먹는 상태까지 갔던가. IBM의 PL/1, 결국은 나름 성공은 했지만 MS의 CLI 구조로 .NET을 이거 저거에 다 쓰게 하겠다는 거. Xamarin 빼고 다른 플랫폼에서 CLI 기반으로 제공하는 거 봤나?
Visual Basic은 C#이 잡아 먹었으니 쎔쎔. C++/CLI는 과연 실질적으로 누가 쓰나?
이전에 Panavision에선 SI/IS하는 프로그래머들이 (프로그래머지만 SI/IS랑 S/W Engineer라고 부르는 사람들이랑은 다르잖아) .NET은 무조건 C#인 줄 아는 그런 사람들도 있는데..

컴이 빨라졌고, Sun처럼 Run Everywhere를 표방하지만 실제 구현은 일단 지네 윈도우즈/Intel 아키텍쳐에 최적화 시켜서 Java처럼 느린 느낌이 아니라 빠르다는 느낌을 주기 위한 전략적 행동을 했던.. 그래서 성공한 C#/.NET 외에..
뭐가 성공했나?
이젠 그 .NET도 포기한다는 소리가 있던데. 그래서 실제 보면 아직도 Visual C++ 6.0이나 2008에 머물러 있는 회사들도 많아. MFC 없이 그냥 Win32만으로 버티는데도 꽤 있는 것으로 알고.. .NET으로 나갔다가 나름 trendy했던 회사들도 (사실 난 .NET을 좋아해. Cocoa 닮았고 잘 만들긴 했어) 그 후론 멈칫한 것 같지들?
물론 이젠 Web이 대세다.. 이런 소리들 하지만..

암튼.. 간만에 썰 풀었네. 결국 삼천포로.

Xcode 6.x에선 기본으로 Frameworks 혹은 Libraries 서브 그룹이 생기지 않습니다.

새 Xcode나 Obj-C 컴파일러가 나오거나 하면, 은근스레 바뀌는 것이 있다.

Outlet을 retain/assign 혹은 strong/weak 어떤 것으로 하느냐 (iOS/Mac)은 Mac에서만해도 벌써 여러번 바뀌었다. 근데 문서화가 안되다보니 사람들이 잘 모르고 지나가는 것 같다. 특히나 미국애들과 말하려면 이런 것 때문에 힘들다. 지네가 모르는 것을 남이 모른다고 생각하니…

오늘은 Xcode 6.0.x에서 바뀐 거..
이전 부터 슬금 슬금 Frameworks나 Libraries 그룹의 이름이 바뀌던가 간혹 없던가 싶더니, 요번엔 아예 없어졌다.
물론 타겟의 Build Phases에서 넣으면 좌측의 Project Navigator에 링크된 라이브러리가 뜨긴 하지만, 그들만의 그룹에 들어가진 않는다. 왜 일까?

하긴 Xcode는 Project Builder 때부터 사람들을 헷갈리게 많이 했다.
프로젝트 세팅과 타겟 세팅이 똑같이 생긴 것도 헷갈려했고 (지금 일하는 회사에서도, 더럽게들 아는 척은 하는데 이 둘을 구별을 잘 안하고 쓴다. 지금은 충분히 구별가능하고 프로젝트 세팅을 애용하면 아주 편한데), Build Phases의 Link Binary with Libraries에 넣느냐, 아니면 Build Settings의 Link 섹션의 해당 엔트리에 넣으냐…
전자는 좀 착 눈에 띄어서 좋고, 후자는 Unix 스럽게 쓸 수 있다. 물론 전자로 해도, 실제 링크시에 사용되는 환경 변수는 후자에 한 것과 같게 되지만…
때론 후자가 편할 수도 있다. 왜냐하면 후자를 쓰면 Debug build냐 Release 빌드냐에 따라 다른 것을 링크할 수가 있다. 즉 Debug build엔 Debug 용으로 빌드된 라이브러리들을 링크하고, Release 빌드엔 역시 그런 라이브러리를 링크할 수 있다.
이건 문서화 안된 거지만 그동안은, 다른 프로젝트가 만든 라이브러리 Product를 시각적으로 Drag & Drop을 하면, Debug/Release 빌드 신경 안쓰고 지가 연결해 주곤 했지만, 다른 툴 체인을 이용했던가, 라이브러리들은 유닉스틱하게 makefile이나 configure, 혹은 CMake등을 이용해서 빌드해주고 링크할 때, 후자가 유용하긴 하다.

암튼..
Frameworks 그룹이 사라진게 아쉽다. 왜 이렇게 했을까? 그거 참 좋았는데.

물론 하나 문제를 알고 있는게 있다.
Xcode는 사실 무엇을 프로젝트에 넣는지 그다지 제한적이지 않다.
그래서 Frameworks에 어떤 Framework를 만드는 프로젝트 자체를 넣을 수도 있다. 안되는 건 아니다. 하지만 생각해 보자. 그게 뭔 짓인가? 그럼 깔끔해야할, 탁 봐서, 아 이 프로젝트는 어떤 라이브러리들을 쓰는구나 대번에 알 수 있어야 할 그 부분이 굉장히 복잡해지고 지저분해진다.

Xcode는 예전에 Workspace라고 부르지 않고 Project file이라고 불렀을 때부터, 프로젝트가 프로젝트를 포함할 수 있었다. 그리고 만약 한 프로젝트 파일 내에서 여러 프로젝트 파일을 포함할 때, 그 각각의 프로덕트 즉 build 되어서 나온 것을 다른 서브 프로젝트가 의존하는, 즉 사용하는 라이브러리로 넣을 수있었다. (물론 지금도 가능하다) 즉 그렇게 함으로써 한 프로젝트 내의 app sub project는 library sub project에 의존성을 갖게 된다. 그래서 app을 빌드하면 혹 그 라이브러리가 빌드되어 있지 않으면 먼저 그 라이브러리를 빌드하고 그 후에 그 앱을 빌드한다. 물론 지금도 이렇게 사용 가능하고, Target Dependency가 그 관계를 명확하게 해 줄 때 사용될 수 있다.

근데 문제는 그 Frameworks 서브 그룹 내에 한 프로젝트 전체를 때려 넣는 것 사람들이 있다.
일전에 일하던 회사에서 러시아쪽 사람들이, 내가 분명 스크린 샷까지 넣어서 보여 줬는데도 그짓을 했고, 오히려 나더러 뭐라고 그런다. 되는데 뭐가 잘못이냐는.
되고 말고가 문제가 아니라, 얼마나 관리성이 좋느냐의 문제인거다.

한국애들도 요샌 그렇지만 서양애들은 자기 방어는 필사적으로 한다. 근데 가만보면 회사내에서 그런 놈들이 자기가 남에게 뭘 알려줘야 할땐 굉장히 비싸게 군다.
한국 사람들은 버릇이 없거나, 아니면 완전 수능 세대들부터 그런거 같은데, 서양애들은 교육과정이 좀 그딴 식인지 러시아건 미국이건 영국이건 상관없이 그런다. (인도도 여기에 포함된다.)
아 짜증나.

암튼. Xcode 6에선 그렇다.
(Xcode 5에서부터 슬금 슬금 없어지기 시작했다는거)

드디어 outlet의 reference 스타일이 통일화 되는구나!!!

Mac OS X 하나만 있었을 땐, 아주 신경 쓸 정도는 아니었는데, iOS가 나온 후, 두 플랫폼에서 outlet을 정의할 때, outlet 스타일이 달라서 애 먹었다. 에베레스트 산 하나만 알고 있을 땐 헷갈리지 않다가 에레베스트 산이란 말을 들으면서 에베레스트인지 에레베스트인지 헷갈렸던 것처럼…

그래로 하나 믿을 만한 건, Interface Builder 모듈이 기본으로 정의해 주는 weak/strong, 혹은 assign/retain 등의 레퍼런스였다. 근데 내 기억에 그마저도 어떤 베타 버젼에선 엉망으로 섞였었다.
어차피 weak reference가 안되는 혹은 retain으로만 해야 하는 인터페이스들이 있어, 항상 해당 문서를 북마크하고 참조해야만 하지만, 그래도 이는 헷갈린다.

그런데 ARC가 나온 후, 통일의 기미는 보였지만, 회사에서 하는 프로젝트는 내가 시작한 게 아니라면 예전의 코드를 가지고 있고, 심지어 최근 본 코드는 한 파일이 두 타겟에 속했는데, 하나는 ARC를 지원하고 다른 하나는 지원하지 않았다. 이뤈! 아무튼 실제 상황은 이처럼 딱히 이상적이지 않기에, 여전히 기억하고 있어야 한다.

Transitioning to ARC Release Notes에서..

The patterns for declaring outlets in iOS and OS X change with ARC and become consistent across both platforms. The pattern you should typically adopt is: outlets should be weak, except for those from File’s Owner to top-level objects in a nib file (or a storyboard scene) which should be strong.

그리고 Resource Programming Guide의 Managing the Lifetimes of Objects from Nib Files 를 참고하자.
북마크 해 놓으면 좋다.

그래도 이제, Swift도 나오고 해서, 점점 스타일의 통일화는 가시화되는 것 같다.

Connecting to Facebook with the C++ REST SDK

It’s very difficult to find C/C++ library to use for Windows, Mac ( and others ). There are some open sources, but they are kind of old and not updated. One of probably good thing is..  a module in MoSync library, but I worry about their license.

However, I found one on Microsoft Team blog about how to use “C++ REST SDK” for Facebook.

Connecting to Facebook with the C++ REST

The SDK is not made specifically for Facebook. It’s rather general.
So, people can access Facebook by doing things for themselves with the SDK.
( It’s like to use cURL for Twitter, although there is an existing library called twitcurl. )

Anyway, I wonder about login process with that. So, let’s read it.
The library itself can be obtained here.

Converting Unicode code point to surrogate representation

Although I looked up Unicode official web site, it was not possible to find how to convert Unicode code point to 4 bytes representation Emoticon uses. What’s weird about Emoticons are :

  • Unicode emoticon area is just smaller set of emoticons people think of
  • Some emoticons use Unicode code point, but some uses 4 bytes of Unicode sequence ( is there a name for this? )
  • Is there a rule to convert code point to the 4 bytes of sequence and to UTF-8?
    • There are some rule between code point and UTF-8

@gluebyte sent me a URL for a web site, which I found at work also but didn’t know there was conversion rule between code point and the 4 bytes of Unicode escape sequence. ( This is called surrogate code. So, it’s different from normal Unicode code point escape sequence. )

Actually, as for Unicode terminology, terminology is more difficult than what they mean.

Text Rendering : GDI, GDI+, etc

Why text appears different when drawn with GDIPlus versus GDI

The wonders of text rendering and GDI

OAuth 2 using curl

Trying out OAuth2 via CURL from h[y]tech blog.

It’s good to know that. As a long time user and developer for Unix, I have know cURL. It’s high-level program/library for various protocols and it’s sort of known that it can do everything.
However, buying tech book…? I don’t remember when is my last time such books. Nowadays I rely on Web. (although pedagogy style or explanation styles are not good especially blogs and web site created here in USA. usually Japanese ( of course ) or Korean ( if any ) writing style/books/posts on web are better for more concise and better explanation.

But.. anyway… Today I found very useful blog post on “How to do OAuth 2 with cURL”
Step by step and easy to understand one. It’s good because I don’t need to read MAN pages or documents on Web thoroughly. At least it can be good starting point to get some idea etc. Only when more information is needed, those more official document can be looked up.

More background information is located here : OAuth2: The Resource Owner Password Flow
Official document on OAuth is here : The OAuth 2.0 Authorization Framework

draft-ietf-oauth-v2-31


Of course, these SNS requires OAuth. (1.1 or 2.0+)

 

Follow

Get every new post delivered to your Inbox.

Join 48 other followers

%d bloggers like this: