One step closer to native coding on Android platform?

There is a native ‘activity’ class. So, using it, it’s said that it’s possible to develop native ‘activity’ code.

Take a look and read doc about it!

Visual Studio 2015 – What’s new?

So, finally MS looks to wake up from its long hibernation.
This time they are very aggressive and I believe Apple and Google ( not as much as Apple ) should get alarmed.

VS 2015 has many good things, however, as many of us know by now, it contains open source version of .NET. I didn’t check which .NET it’s referring, but mostly it looks to contain APIs for server-side functionality at this moment.
Also, it embraced Xamarin, which is Mono-based Android/iOS cross platform development solution.
if MS gets involved in development of Mono more actively, Apple should get notified about it.

So, please try to read and see what’s new about VS 2015!

Raspberry Pi can be powered from other USB host through its USB ports not its power port!

I just found interesting property of Raspberry Pi.

We know that a USB device can use power from a host machine, aka computers. In other words, a USB mouse or a USB HDD can be powered from a computer.
The host machine, i.e. computer, is supposed to be plugged to a power outlet.

The Raspberry Pi has a dedicated power port. I have connected a power  adapter to a wall outlet or a USB power cable to a powered USB hub, etc.

What I found is that…. if the powered USB hub is connected to a Raspberry Pi’s USB port not its power port, Raspberry Pi can GET power from the USB hub and was able to be booted.

Probably it’s because it drains very little electricity and probably people may want to make a device with a RPi as a kind of independent device. For example, let’s say you make an intelligent HDD ( or SAN ) using RPi as its brain and package the HDD and RPi in a same box. Then, the small intelligent HDD can be hooked up to your network while it’s connected to your USB hub or other device which is to propel USB devices.

I didn’t expect such use case, but they prepared the RPi for such occasion by design!

객체 소유를 strong으로 할 것이냐 weak으로 할 것이냐? 그 새로운 시작

이미 이 주제에 대해선 몇번 언급을 했다. 그리고 항상 헷갈리고.

더군다나 OS X에선 특정 인터페이스는 strong이나 assign으로만 해야 하는 것도 있고. (ARC가 활성화 되었어도, assign으로!)

OS X에서 iOS 프로그래밍까지 더 하기 시작했을 때, 둘 사이에 이게 달라 무지하게 헷갈렸다. 더군다나 Xcode의 Interface Builder 모듈도 종종 버그도 있고 해서, 그 놈이 기본으로 설정해 주는 것을 믿기도 힘들고.

그래도 다행스러웠던 점은, 애플이 iOS와 Mac OS X간의 차이를 해소하려 했다는 것이다.
이제 스토리보드가 Mac에도 사용되기 시작함으로써, 그 내재된 구조적 차이는 해소되어 가는 것 같다.

자. 이 문제를 갱신해 보자. 요번엔 애플의 문서에 무엇이 top object인지 좀 더 명확한 정의가 내려져 있다. (정말 이전엔 헷갈렸다. 알고 있다가도 또 보면 모르겠고.)

When your program loads a nib file, Cocoa recreates the entire graph of objects you created in Xcode. This object graph includes all of the windows, views, controls, cells, menus, and custom objects found in the nib file. The top-level objects are the subset of these objects that do not have a parent object. The top-level objects typically include only the windows, menubars, and custom controller objects that you add to the nib file. (Objects such as File’s Owner, First Responder, and Application are placeholder objects and not considered top-level objects.)

Resource Programming  Guide : Nib Files
From a practical perspective, in iOS and OS X outlets should be defined as declared properties. Outlets should generally be weak, except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene) which should be strong. Outlets that you create should therefore typically be weak, because:

Xcode 6.1이 가져온 큰 변화 (Integration of iOS & Mac OS X for programmers )

놀랍게도 내가 보기엔 Swift가 아니다.

Xcode 6.1이 가져온 큰 변화는 드디어 Mac에서도 iOS의 View Controller를 쓸 수 있다는 것.
이렇게 함으로써 주가 되는 뷰들을 각각의 xib에 넣고 관리하게끔 유도한다. (물론 그 xib들을 storyboard로 관계 맺어주는 것이지. 사실 storyboard의 등장은 xib를 없앤게 아니다. 스토리보드 파일을 열어보면 그 답이 나온다.)
당연히 덩치가 큰 프로그램은 메모리 사용량 관리에서 더 좋아질테고. 이렇게 함으로써 사실상 Mac과 iOS의 가장 큰 차이점이 없어지게 되었다. 물론 프레임워크의 차이야 조금은 있지만, 그건 마치 다른 버젼의 프레임웍 같은 느낌이고.. 사용 패턴등에 대해선 차이가 없다.

자. 이제 맥에서도 NSView가 NSWindow의 상위에 놓일지는 의문이다. 그렇게 되면 프로그래밍적으로 iOS와 OS X의 통합이 될거다.
NS*대신 UI*를 사용할텐데, 어느 쪽으로 통합될까? 혹 UI*는 아닐까? NS는 NextStep의 흔적이니까.

그래도 난 NS가 좋다. 왠지 UI*는 뭐랄까.. 히피같은 느낌?

그리고 iOS에선 Core Foundation 혹은 그 레벨에 준하는 것들을 Foundation보다 더 많이 사용하는데 (UIColor vs. CGColor) 앞으로 iOS 이전의 프레임워크처럼 CF*에 해당하는 해당하는 것에 대응하는 UI*를 빨리 빨리 만들어 주었으면 하는 바램이다.

tcpdump packet dump를 좀 더 예쁘게 보여주는 프로그램

http://tcpick.sourceforge.net/

근데 뭐.. 어차피 Wireshark를 이용하면..

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이 대세다.. 이런 소리들 하지만..

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

Follow

Get every new post delivered to your Inbox.

Join 43 other followers

%d bloggers like this: