Serious in GUI design? Interface Builder is not good for designers?

Well, if you are a hardcore programmer, probably Interface Builder on Mac or the integrated resource editor for Visual Studio can be good enough. But there are certain times to define how things work in advance, or those tools are not easy for GUI designers to use.
Then… it’s time you need a GUI prototyping tool.

There have been many, but nowadays, these two commercial S/W programs appear on Google.

• Sketch
• Flinto

We can use trial versions to see how they work.

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에서부터 슬금 슬금 없어지기 시작했다는거)

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+)

• Twitter : Authentication & Authorization
• Facebook : Advanced Guide for Log-in, especially, Manually build a login flow
• Google+ : Google Accounts Authentication & Authorization

 

Finally.. it’s coming!!!!! Beyond Compare for Mac!!!

This is my favorite compare & merge tool since early 1990’s.It had the most intelligent comparison algorithm allowing shifted code block matching. It showed differences within a line also.

Now, finally it is coming to Mac.
Don’t need to rely on Apple’s merge tool, which can’t handle sophisticated situation or any other comparison tool available on Mac!

Let’s try!

http://www.scootersoftware.com/support.php?zz=kb_mac