'all'에 해당되는 글 33건
- 2010.03.22 Android 에서 MySQL 을 사용하지 않는 이유! 2
- 2010.03.18 C#에서 Managed Gesture API 이용.
- 2010.01.27 Android - HttpClient 로 서버 접속이 되지 않을 때!
- 2009.12.29 모피 입지 맙시다.
- 2009.05.22 You say you are the big cheese, i don't think so.
- 2009.03.27 Designing with an Agile Attitude
- 2009.03.10 "Professional 소프트웨어 개발" 을 읽었다.
- 2009.02.26 “이젠 장난감도 최첨단!”…2009 장난감 박람회를 빛낸 제품 9선
- 2008.11.27 귀여운 고양이 발짓 1
- 2008.11.13 Mintpad?! 디지털 포스트잇!
출처: http://groups.google.com/group/android-developers/browse_thread/thread/f1763b9a0c63653e
I would very explicitly NOT develop a MySQL App on the Android.
안드로이드에서 MySQL 개발을 하지 마십시오.
While you could perhaps get the JDBC driver to run on Android, this is the wrong approach from a architectural standpoint.
Android에서 돌리기 위해 JDBC 드라이버를 얻어야 할텐데요, 설계적 관점에서 이는 잘못된 접근 방식입니다.
You won't get the performance, scalability, maintainability, reliability, nor security characteristics you'd like.
수행성, 가용성, 관리성, 신뢰성, 보안성.. 그 어느것 하나 제대로 되지 않을겁니다.
Instead, expose your client-side functionality in a web service.
대신, 웹 서비스를 통해 클라이언트 쪽 기능을 하게 할 수는 있습니다.
For most purposes, I'd suggest a RESTfull web service, but SOAP is also an option.
대부분은, RESTfull 방식의 웹 서비스를 추천하지만 SOAP 또한 방법 중 하나죠.
JSON is often a good alternative to XML -- especially if you will be interacting with this service via a browser.
JSON은 XML을 훌륭하게 대체해 줍니다. 특히 브라우저를 통해 서비스 통신을 하게 된다면 말이죠.
If you put SQL in your client, you are basically screwed.
SQL을 클라이언트에 넣었다면, 근본적으로 완전 망하는겁니다.
You will NEVER be able to alter your schema, or introduce some non-DB processing, or split the data between databases, or make any of a host of other changes, because some people may never upgrade their apps.
스키마 변환이라든가 non-DB prosessing, DB 간 데이터 분리, 어떤 변화를 가지는 host 생성, 등은 절대 불가능 하겠죠. 왜냐하면 일부 유저는 프로그램 업데이트를 하지 않으니까요.
Well, OK, you can say "screw them", and change it anyway, but they'll ding you in the marketplace ratings.
뭐, 망하면 망할테라지라고 해버리고 어떻게든 바꿔버린다면, 뭐 시장 결과는 뻔하겠죠.
Especially in a mobile app, you want a looser coupling.
특히 모바일 app에서는 느슨한 커플링이 필요합니다.
With a web service, you can simultaneously provide multiple versions of the same service (perhaps distinguished only by a revision indicator).
웹서비스를 통해서라면, 같은 서비스를 여러 버전으로 하여 지속적으로 제공해 줄 수 있습니다. (아마 revision indicator를 통해야만 하겠죠.)
You can do server-side caching to take a load off your database. You could even move to a different database entirely.
또 데이터베이스 서버측의 로드를 줄여줄 수도 있습니다. 데이터베이스 전체를 다 바꿔버릴수도 있구요.
Also, connection failures will be frequent. With MySQL, you'd have to pay considerable attention to recovering from connection failures.
또한, 연결 실패가 빈번하게 일어날텐데, MySQL을 쓰면 연결 실패를 복구하는것에 대해 아주 신중하게 고려해야만 하죠.
With a web service, a single call may fail, but because the communication itself is stateless (if designed well), you can just retry that one failing call.
웹서비스를 이용한다면, 단일 호출이 실패하더라도 설계가 잘 되있는한 통신 자체는 stateless(?)이기 때문에 그냥 실패한 호출을 재시도하기만 하면 되죠.
You do have to think carefully about transaction boundaries, and try to accomplish more with a single call, rather than beginning a transaction, doing a bunch of stuff, and the committing.
트랜젝션 바운더리에 대해서도 신중해야 할텐데 하나 이상의 호출을 수행해야 한다면, 그냥 트랜젝션의 시작부터 모든 일들을 한꺼번에 수행하고 마지막에 committing만 하면 되죠.
That's a good thing -- you'll get much better performance, because the round-trip time through the mobile network will be poor.
이건 매우 좋은겁니다 -- 수행성이 훨씬 나아지죠. 왜냐하면 모바일 네트워크를 통해 데이터가 왔다갔다 하는건 엄청난 시간이 걸리는 작업이니까요.
You'll also be rewarded with much superior reliability -- a single MAKE-ALL-THESE-CHANGES call happens in a shorter period of time, and is much less likely to fail due to the network than a series of BEGIN-EDIT-EDIT-EDIT-EDIT-COMMIT operations.
그리고 훨씬 나은 보안성을 얻을 수 있구요. 한번으로 여러 호출을 한꺼번에 수행하는것은 시간도 더 짧게 들고 네트워크를 통한 호출 실패를 확 줄여줍니다.
All in all, there's very good reason why nobody uses MySQL on Android, and it has nothing to do with limitations on Android.
이 모든것들이 아무도 Android 에서 MySQL 을 쓰지 않는 이유가 되겠죠. 안드로이드의 한계와는 아무 상관이 없습니다.
The same arguments actually apply to ANY client-side use of MySQL, it's just that they get even stronger on a mobile platform.
MySQL 을 사용하는 어떠한 클라이언트 라도 동일한 논쟁이 발생합니다. 단지 모바일 플랫폼 상에서는 더욱 강력하게 발생할 뿐이죠.
흠... 이건 정말이지.. 안드로이드 위에서의 MySQL 이야기가 아니라, 네트워킹을 통해 db access 를 하는 모든 클라이언트-서버 시스템의 문제가 아닐까 하는데 -_-;;;; 결국 걍 RESTfull 방식으로 데이터 전송 하라는 거잖아.;; 그거 몰라서 안하는게 아니고 걍 클라이언트 내부적으로 데이터 관리를 용이하기 위해 쓰는 DB 라면 이야기가 달라지는거 아닌가... 내가 잘못 이해하고 있는건가....
어짜피 내부적으로만 쓰는거면 (당연히 차후 데이터 스키마를 바꾸게 된다거나 할일이 없어야겠지!) MySQL 에서 서버측 라이브러리를 제공하니 이를 링크해서 쓰게 되는건데..... 쩝. -_-
아, 물론.;; 안드로이드에서 제공하는 SQLite 를 쓰는게 베스트이지만 지금 제가 이 작업을 하는 이유가 안드로이드와 임베디드 리눅스, 윈도우 CE 모두에서 돌아가는 DB 조사를 하고 있는 중이기 때문에.;;;; 수행성과는 상관없이 말입니다.
*추신-막번역입니다 오역부분 댓글주시면 수정하겠습니다. 감사.
안녕하세요,
applying this patch should fix the problem.
--- GestureRecognizer.cs 2009-08-26 11:53:24.000000000 -0000
+++ GestureRecognizer.cs 2010-02-26 09:46:33.000000000 -0000
@@ -30,12 +30,13 @@
private static readonly object EndEvent = new object();
private static readonly object SelectEvent = new object();
private static readonly object DoubleSelectEvent = new object();
private static readonly object HoldEvent = new object();
private static readonly object PanEvent = new object();
private static readonly object ScrollEvent = new object();
+ private WndProcHook wndProcHook = null;
private Control targetControl;
///
/// Initializes a new instance of the GestureRecognizer class
///
@@ -36,27 +37,31 @@
private Control targetControl;
///
/// Initializes a new instance of the GestureRecognizer class
///
{
if (value != this.targetControl)
{
if (this.targetControl != null)
{
// remove the WndProc hook for the previous targetControl
- Hook.RemoveHook(this.targetControl, WndProc);
+ if (wndProcHook != null)
+ {
+ Hook.RemoveHook(this.targetControl, wndProcHook);
+ }
this.targetControl = null;
}
if (value != null)
{
// add the WndProc hook for the current targetControl
this.targetControl = value;
- Hook.AddHook(this.targetControl, WndProc);
+ wndProcHook = new WndProcHook(WndProc);
+ Hook.AddHook(this.targetControl, wndProcHook);
}
}
}
안녕하세요 화성에서온 강 마인부입니다.
낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄 낄
play 누르면 말도 함. 꽤 훌륭하다. 위젯으로 igoogle 등에 끼워넣을수도 있다는거~
Rebecca J. Wirfs-Brock
Attitude is a little thing that makes a big difference. —Winston Churchill
Good software designers share many traits, habits, practices, and values, whether they work on agile teams or not. Many designers value design simplicity, communication, teamwork, and responsiveness to stakeholder needs. So what distinguishes agile design from other design processes? Do successful designers working on agile projects need radically different techniques and skills?
Agile Design Supports Existing Values
As a reviewer of experience reports at several agile conferences for the past five years, I’ve vicariously experienced the joys, struggles, and triumphs of several successful design teams. Most didn’t ignore their corporate culture or existing design context even though they shifted priorities and added many new practices. Adopting agile development seems to go hand in hand with articulating what you value, then finding ways to improve on what you already do well. Jon Spence, a principal engineer at a medicalinstrumentation company, sums up his initial attraction to agile development (“There Has to Be a Better Way,” Proc. 2005 Agile Conf., IEEE Press, 2005, pp. 272–278): There’s nothing wrong with plan-driven, waterfall-based, document-centric approaches. They’re just not suited to controlling complex activities like software development. We needed to adopt agile software development because it’s the best technique for the activities we’re trying to manage and control. After studying literature, talking to agile thought leaders, and thinking about how agile practices might fit in his company’s development process, Jon and a handful of colleagues launched an agile initiative. They proposed adopting new practices that seemed radically different from their current ones:
forming s • mall development teams;
• giving each team freedom to adapt its development process;
• emphasizing simple design—designing only for current, not speculative, needs;
• developing in short, two-week iterations; and
• reflecting at the end of each iteration.
They followed test-first development on all new and changed, nontrivial, non-GUI code. They refactored code to maintain simple design only when that code had unit tests in place. Initial reactions to their proposal were largely supportive. Yet some wondered about how pair programming might impact productivity and whether it would disrupt the status quo of solo development. Management viewed refactoring as having the potential for gold plating. So, they proceeded with the understanding that these practices would get a fair trial and were subject to change as they learned and applied them. In addition to having project management support, Jon asserts, “it was equally important to have friends and allies in management, both immediate management
and upper management.” Jon’s team came from a culture that values measuring productivity and making
process improvements. So, as part of adopting agile practices, they closely monitored the amount of rework, the speed with which they completed tasks, and how effectively they worked through their feature backlog. As a result, they decided to reduce teams from 12 members to four to six members, add a team of system engineers to support the product manager in defining product features and functionality, and adjust their planning meetings to improve intrateam communication.
Agile Design Improves through Reflection
Frequent checkpoints let designers learn and refine their software and how they work. Marilyn Lamoreux, a colleague of Jon’s, has recounted how she introduced end-of-iteration reflection meetings into their project (“Improving Agile Team Learning by Improving Team Reflections,” Proc. 2005 Agile Conf., IEEE Press, 2005,
pp. 139–144). Initially, some developers believed that meetings weren’t “real work” no matter what the meetings’ agendas were. A common belief was that effective meetings should have a detailed agenda and result in actions, decisions, and to-do lists. Her first attempts at conducting reflections were only moderately successful. After investigating, Marilyn decided to introduce Conversation Café (http://tinyurl.com/4kxmcv), a technique that combines simple ground rules and a talking token to guide conversation. The first time she tried it, Marilyn was stunned by how successful it was. She was able to instigate a thought-provoking design discussion about why some code had errors and how to improve it. Marilyn speculates that this technique worked because it “taught our teams some of the conversational practices that open minds and hearts to new ideas.” Even following this technique, teams still occasionally have unproductive reflection meetings. Marilyn says, “Learning to reflect is a process that takes persistence, practice, feedback, and adaptation.” And, I
might add, determined efforts to seek out and experiment with ways to make a particular practice effective.
Agile Happens One Step at a Time
Agile design and development practices don’t have to happen all at once to be successful. David Kane reports on how he incrementally introduced agile development techniques into a team that designs software used by US National Cancer Institute scientists and researchers (“Introducing Agile Development into Bioinformatics: An Experience Report,” Proc. 2003 Agile Development Conf., IEEE Press, 2003, pp. 132–139). David’s team already worked collaboratively on development and had ready access to experimental biologists in a lab across the hall. The team wanted to adopt agile methods, but they also needed to continue to make releases while they learned new techniques. They had varying degrees of knowledge about agile methods and needed time to develop their skills.
One of the first things David did was get their code base under better configuration management. Shortly afterward, he introduced the team to automated testing. As their test case coverage grew, they started refactoring portions of ugly code, cleaning up the design and removing unnecessary complexity and coupling. It wasn’t until more than a year and a half into agile adoption that they introduced code reviews and
one-day-a-week pair programming. They wanted code reviews to complement their existing practices and help share knowledge among team members. Each iteration, one developer would pick two to six classes to review from those he or she created or modified.
Others would review the code well before the end of the iteration, giving enough time for revision. They found reviewing and discussing code let them raise design and implementation issues that occurred across larger portions of their code.
Agility Comes with an Attitude
Developing complex software can be difficult no matter how good designers get at architecture, tooling, or technology. Although agile techniques and practices vary, successful agile designers I know are passionate about producing high-quality incremental design solutions. They aim to design and implement solutions for the
current problems at hand simply and efficiently. They adopt practices, tooling, and technology that enable them to produce results. They prefer to connect their design work to real, not presumed, needs and aren’t satisfied with being only headsdown problem solvers or coders. They expect to give and take criticism and ask
clarifying questions of teammates and other project stakeholders. And they take care not to ignore details that could derail design quality or put their project at risk.
So what does it take to be an effective designer in an agile development environment?
Although I don’t find agile development to require drastically different design or technical skills, it does demand
teamwork and cooperation. Agile designers need to sharpen their communication and collaboration skills as well as their technical practices. They should value collaboration and collective understanding as much as good design and development practices.
It’s a matter of attitude more than any specific technique or process.
Developing complex software can be difficult no matter how good designers get at architecture, tooling, or technology.
출판사: 인사이트
읽으면서, 내가 스스로 소프트웨어 개발자 라고 말하기에는 챙피할 수준이라는 것과 동시에, 무언가 깨달은 것만 같은 느낌에 흥분감이 밀려왔다.
정말 많은 내용을 - 실제 개발보다는 개발 원칙과 개념적인것을 다루고 있지만 - 담고 있는 책의 내용 중 일부 내가 크게 동화된 내용을 옮겨적고자 한다. 후일에도 두고두고 보면서 "나는 소프트웨어 개발 전문가 입니다." 라고 말할 수 있는 수준이 될 때까지 노력해 볼 생각이다.
물론 내가 감명 받은 내용만을 부분적으로 적을것이므로 책의 다른 생략 된 부분에 대해서는 직접 책을 읽어야 할 것이다.
my note 1. 프로세스 기반 개발 vs 책임 기반 개발
저자는 책에서, 실무에서 개발의 방법에는 크게 두가지 부류로 나누어 볼 수 있다고 한다. 첫째는 책임 기반 개발이고, 둘째는 프로세스 기반 개발이다.
책임 기반 개발: 쉽게 말해 영웅중심개발이다. 천재 프로그래머를(영웅) 프로젝트에 투입하는 것이다. 이러한 구조는 영웅 혹은 영웅들에게 커다란 동기를 부여하여 잠재력을 유도하는데에 목적을 둔다. (보통 영웅개발자들은 회사를 위해서가 아니고 나와 나의 자존심을 위해 개발을 하는 경우가 대부분이니까. 영웅들은 돈인나 삶의 질적 가치보다는 그들의 명예를 지키고 그에 따른 희열을 맛보기 위해 개발을 한다. 24시간을 프로젝트에 전념하며 매달리기도 한다.)
프로세스 기반 개발: 잘짜여진 계획과 프로세스 그리고 S/W 공학 기법을 사용하여 개발하는 방법이다. 모든 팀원이 골고루 역할 분배를 받으며, 프로세스에 따라 체계적으로 개발해 나간다. 이런 형태의 개발에서 영웅의 존재는 팀웍을 방해하는 굉장한 방해물이 될 것이다. 영웅들은 제멋대로 자신의 방식을 과시하면서 프로세스를 무시하고 개발하기 때문에! 뭐, 프로세스 기반 개발이 영웅기반 개발보다 세련되 보일 수는 있겠지만, 소규모 프로젝트에서는 불필요한 문서 작업과 회의량만을 늘릴 뿐이다.
어찌됬든 두 방법 모두 실무에서 쓰이고 있고 성공적인 프로젝트 사례도 많다. 허나~! 문제는 이런 방법을 어설프게 따라하려고 했을때 발생한다. 저자는 이것을 각각 이렇게 정의한다.
책임 사칭 조직: 책임 기반 개발을 어설프게 따라하는 조직. 일명. 착취조직!! 똑똑히 일하는 것보다는 열심히 일하는 것을 중시한다. 결과(긴 근무시간)과 원인(높은 동기부여)를 혼동하는 것이다. 친구들의 푸념을 들으면서 이런 조직을 종종 보는데, 이렇게 명확히 정의를 내리고 보니 문제점을 확연히 알겠다.
프로세스 사칭 조직: 관료조직! 프로세스의 형태를 본질보다 중요시하는 조직이다. 쓸데없는 산출물만을 끊임없이 만들어내면서 자신들은 지금 무척 세련되게 잘 해나가고 있다고 착각하는 조직이다. 음.. 일종의.. 세모모양 구멍에 네모모양 블럭을 억지로 끼워 넣는 기분이랄까? 네모모양 블럭은 네모모양 구멍에 넣어야지!
보면서 나는 박장대소를 하며 엄청난 공감을 하게 되는 씁쓸한 현실을 마주해야 했다.
my note 2. 화물 숭배 소프트웨어 공학.
본문에 삽입된 재미있는 이야기를 옮겨두겠다.
예전에 남태평양 어떤 섬에는 화물 숭배라는 종교를 믿는 사람들이 있었다. 당시에 섬 하늘에는 전쟁 물자를 수송하는 비행기들이 많이 다녔고, 섬 사람들은 비행기를 신의 전령이라 믿었다. 그들은 언젠가 신이 자신들에게도 비행기에 엄청난 물자를 실어 보내줄 것이라고 생각했다. 그래서 비행기가 섬으로 착륙할 수 있도록 활주로 비슷한 것을 만들기 시작했고, 활주로 좌우에는 유도등처럼 불을 피워 놓았다. 또 사람이 들어와 앉을 수 있도록 관제탐 같은 통나무 집도 만들었고, 대나무를 깎아 안테나처럼 달아 놓았다. 그 안에서 나뭇가지를 헤드셋처럼 묶고 앉아, 비행기가 착륙하기만을 하염없이 기다렸다. 그들은 이전에 다른 곳에서 본 진짜 활주로의 모습을 재현했다. 적어도 그 형태만큼은 완벽했다. 그러나 비행기는 오지 않았다. 나는 섬 사람들이 "과학적인 연구의 형태와 지침"을 따르기 때문에, 이것을 화물 숭배 과학이라 부른다. 그들은 뭔가 중요한 것을 잊고 있음이 분명했다. 왜냐하면 비행기가 한 대도 오지 않았기 때문이다. -리차드 파인만.
저자는 앞의 책임 사칭 조직과 프로세스 사칭 조직을 "화물 숭배 소프트웨어 공학" 이라고 칭했다. 프로젝트의 성공을 위한 통찰 없이 그 형태만 흉내내는 꼴이, 비행기가 한대도 오지 않는 활주로를 만든 섬 주민과 같기 때문이다.
이런 화물 숭배 소프트웨어 엔지니어는 현재에 안주하며 자신의 방식을 정당화 한다는 것이다. 일 자체가 말도 안됨에도 "우린 원래 이렇게 해 왔는걸" 이라고 말하면서 말이다.
무언가 조금 찔리지 않는가?
my note 3. 소프트웨어 공학 vs 소프트웨어 과학
책에서 이 부분을 읽으면서, 대학을 다니면서 가졌던 모호한 질문을 시원하고 깔끔하게 이해할 수 있었다. 시작은 공학과 과학의 차이점에서부터이다. (저자는, 일반적으로 생각하는 공학과 과학의 차이와 S/W에서의 공학과 과학의 차이가 크게 다르지 않다고 말한다.)
공학은 무엇인가? 공학은, 현재 만드는 제품과 관련된 모든 분야의 지식을 습득해야 한다. 또한 최종 소비자와 관련이 있기 때문에 많은 제약사항을 숙지하고 있어야 한다. 반면 과학은? 과학은, 특정 전문 지식만을 연구해도 된다. 다른 과학자와 관련이 있기에 큰 통제가 따르지 않는다.
단원의 마지막에, 공학과 과학의 차이에 대해 극단적이지만 명료하게 이렇게 정의한다.
" 공학을 전공한 학생은 학업을 마친 후 즉시 작업 현장에 투입 될 준비를 한다. 그리고 과학을 전공한 학생은 연구를 계속할 준비를 한다."
깔끔하지 않은가? 왜 소프트웨어를 전공했다는 학생들이 실무에서 샌님처럼 굴까? 그것은, 학교에서 충분한 공학 수업을 거치지 않았기 때문이다. 많은 학교들이 소프트웨어 공학을 가르친다면서 소프트웨어 과학을 가르치고, 반대로, 소프트웨어 과학을 가르친다면서 공학을 가르치고 있다. 그 두가지의 혼란선상에서, 누구나 이런생각 해보지 않았는가? "개발을 하려면, 많은 언어와 기술을 알아야 하는거야? 아니면.. 하나만 끝까지 파고들면되는거야?"
뭐 대답은 둘 다 아니다. 언어나 기술에 대한것을 아는 것이 당연히 좋겠지만, 내가 소프트웨어 공학자(즉 개발자?) 를 하기로 한 이상, 언어나 기술등 과학과 밀접한 것보다는 수많은 원칙과 다양한 분야를 섭렵하는 것이 맞다. 그럼 얼마나 다양하게??? 이 책은 어디까지 날 깨우쳐주려는건지!! 저자는 그 부분도 친절히 범위를 정의해 주었다 -ㅂ- gogo my note 4.
my note 4. 소프트웨어 엔지니어가 반드시 갖춰야 할 지식 영역.
일단, 이것은 저자가 멋대로 만든것이 아니며, SWEBOK (ACM과 IEEE에서 관리하는 소프트웨어공학 지식체계 프로젝트.) 에서 정의한 것이다. 고로 수많은 경험이 축적된 개발자들의 머리에서 뽑아낸 매우 신빙성 있는 것이라 할 수 있다. 총 10가지이다.
- 소프트웨어 요구사항: 나에겐 아주 귀찮은 존재 영역. -_-
- 소프트웨어 설계: 나 잘났다고 뻐기는 영역이지만 사실은 매우 아마추어 수준. -_-;;
- 소프트웨어 구축: 나의 지식 영역의 50%는 여기에 집중되어 있다.
- 소프트웨어 테스팅: 필요성은 알지만 가볍게 무시하는 수준. -_-
- 소프트웨어 유지보수: 필요성은 알지만 할 줄도 모르고 하기도 귀찮다 -_-;;;
- 소프트웨어 형상관리: 그나마 요근래 맛만 살짝 본 영역.
- 소프트웨어 품질: 테스팅도 안하는데. 품질에 신경쓰겠는가? -ㅂ- 완전무시수준.
- 소프트웨어 공학 관리: 그렇저렇 하는 수준.
- 소프트웨어 툴과 방법론: 소프트웨어 구축을 뺀 나의 남은 지식 영역이 여기에 포함된다.-ㅂ-;;
- 소프트웨어 프로세스: 알만큼 알고 필요성도 알기에 하고는 있지만 귀찮아 하는 수준. -_-
위에서 색이 진할수록 나의 지식영역이 집중포화 되있다고 볼 수 있다. 이야... 영양의 불균형이 지나치게 드러난다. 아마 관련 전공 학사 학위자는 대부분 나와 비슷하지 않을까 한다. 이 부분에서.. 조금은 내 자신이 창피하다. -_- 사실 소프트웨어 설계니 구축이니.. 방법론도, 그냥 아는 것이 많다뿐, 별로 어떻게해야 '잘' 하는 것인지 아직도 모호하다. 다양한 프로젝트에 대한 경험을 쌓아야 하는 문제겠지만 말이다.
my note 5. 소프트웨어 의식 향상
지식을 갖췄다고 해서 다가 아니다. 개발자로서의 의식자체를 업그레이드 해야한다. 저자는 아래와 같은 3단계로 나누고 있다.
의식 1 - 개척자 정신. 소프트웨어로 치면, 야생마.. 프리마돈나.. 수준? 개발자의 자만심과 관련된 의식이라고 한다. 자기 멋대로 막무가내로 개발하지만 어쨋든 결과는 나온다. 가끔은 꽤 성공적일때도 있어서 자신을 천재로 착각하기도 한다. 그럼과 동시에 다른 사람의 의견에 배타적으로 변하고 지식에 닫혀 있다.
의식 2 - 양복쟁이. 일종의 규칙 중시자이다. 이럴때 이렇게 저럴땐 저렇게. 의식 1 상태에서 한계를 깨닫고(당연히 그렇겠지..-_-) 팀 단위 개발을 하기 시작하는 단계라고 한다. 이 단계에서는 방법론을 중시하기 때문에 자칫 잘못하면 프로세스 사칭 팀으로 전락할 수도 있다고 본다.
의식 3 - 계몽 독립 정신! 마지막 단계이다. 원칙에 초점을 맞춘다. 예를들자면, 소프트웨어의 결합도를 낮추고 응집도를 높여야 한다는 원칙을 위해 수많은 디자인 패턴들이 쏟아져 나오는 것을 생각할 수 있겠다. 의식 2 에서는 이것을 반대로 여겨, 디자인 패턴을 써야만 결합도를 낮출수 있다고 착각한다.(물론 사실이지만, 디자인 패턴은 optional 한 것이지 mandatory 한 것은 아니다) 의식 3에서는 결합도를 낮추는 것에 집중하는 것이지, 디자인패턴에 구애받지 않는다.
나는 의식 2에 머물러 있는듯 하다. 그리고 슬픈 것은 의식 1에서 의식2로 넘어온지 얼마 안된것 같은 느낌을 받는다. 나아갈 길이 멀다.
이번 주 뉴욕에서 개최된 아메리칸 세계 장난감 박람회 (American International Toy Fair)에는 제디(Jedi) 훈련 기기, 공중 부양 마법 지방이, 그리고 사용자들에게 장난감이 직접 힌트를 줄 수 있도록 고안된 터치형 루비큐브 등이 우리를 기다리고 있었다.
장난감 산업 협회 주최 하에 19일까지 계속됐던 이번 박람회에서는 총 1,500여 개의 참가자들이 가지각색의 장난감 및 오락 관련 제품들을 전시했다. 이와 동시에 일반인에게는 공개되지 않은 장난감 바이어들만을 위한 박람회도 함께 열렸는데, 여기서 선보여진 최신 제품들은 올 연말에 정식으로 판매될 것으로 보인다.
이번 해에는 두 가지의 테마가 박람회를 뜨겁게 달구었다. 하나는 저가형 장난감. 30달러 이하의 가격으로 책정된 장난감이 대세를 이루었다. 나머지 하나는 (물론 당연한 이야기겠지만) 최신 기술이 가미된 장난감이었다. 요즘에는 어린이들도 자신들이 가지고 노는 장난감들에 특수 칩이 부착되어 있기를 바라곤 한다. 아래는 이번 장난감 박람회에서 찾아볼 수 있었던 몇몇 최신 기술이 가미된 장난감들을 소개한 것이다.
올빗휠 스케이트(Orbitwheel Skates)
올빗휠(Orbigwheel)을 개발한 인벤티스트(Inventist)는 희한하게 생긴 이 스케이트가 스케이트보드, 또는 롤러블레이드보다 훨씬 더 타기 쉽게 고안된 것이라고 주장했다. 이를 움직이기 위해서는 우선 발바닥을 스케이트에 댄 상태에서 몸과 엉덩이를 좌우로 흔들어 주어야 한다. 올빗휠의 실제 시연 동영상을 보고 싶다면, 인벤티스트의 유튜브 시연 영상을 보면 된다. 이것을 타고 하프 파이프를 왔다갔다하며 묘기를 부릴 젊은 스포츠 마니아들을 상상보자. 아마 필자는 무서워 벌벌 떨 것 같다.
루비큐브의 새로운 변신
필자는 예전부터 루비큐브를 한 번도 제대로 깨본 적이 없다. 포기의 연속이었다. 그러나 이제는 다시 시도해볼 수 있을 것만 같다. 테크노 소스(Techno Source) 에서 새로이 개발한 터치큐브(Touch Cube)가 있기 때문이다. 이 회사는 루비큐브 측면에 터치 패드를 삽입하는 혁신을 단행했다. 이제는 예전처럼 큐브를 이리저리 비틀지 않고, 움직이고 싶은 열에 손가락을 갖다 대고 밀기만 하면 된다. 이 새로운 루비큐브, 그리고 필자의 알량한 도전 정신 덕분에 필자는 또 다시 상당한 시간을 새로운 루비큐브를 푸느라 힘든 시간을 보냈다. 다만 예전처럼 아예 답이 없지는 않았기 때문에 조금 더 재미있게 즐길 수 있었던 것 같다. 터치큐브는 사용자가 막힐 경우 그 상황에서 적합한 힌트들을 제공해 주기 때문이다. 터치큐브는 이번 가을 출시될 예정이고 가격은 150달러로 책정될 것으로 보인다.
소형 수소 자동차
보스턴에 사는 필자로선 집과 직장을 오갈 정도의 능력이 되는 수소 자동자가 하나 정도만 있으면 좋겠다는 생각을 한다. 그러나 아쉽게도 지금 당장 필자가 구매할 수 있는 수소 자동차는 템스 앤 코스모스(Thames and Kosmos)에서 개발한 조그마한 물로 가는 자동차가 한계인 듯 하다. 조그마한 연료 전지가 탑재된 이 장난감 차는 템스 앤 코스모스가 이번 전시회에 출품한 11가지 과학용 장난감 세트 중 하나다. 교육용 장난감을 전문적으로 개발하는 이 업체는 풍력 발전, 우주 탐험, 유전자 및 DNA, 그리고 고고학에 대해 설명하는 장난감들을 선보인 바 있다.
크레욜라(Crayola)의 3D 사이드워크 분필
사이드워크 분필은 사실 그리 새로운 것이 아니다. 그러나 크레욜라는 이 전통적인 낙서용 장난감에 새로운 도전을 가미했다. 크레욜라의 3D 사이드워크 분필은 낙서를 실제로 생동하는 3차원의 그림으로 승화시켜준다. 다만 이 낙서를 3D로 보기 위해서는 특수 안경을 착용해야 한다. 이 3D 사이드워크 분필은 현재 온라인과 브릭 앤 몰탈(brick and mortar) 매장에서 판매 중이다. 기본형 세트는 8달러, 그리고 조금 더 많은 종류의 분필이 들어있는 디럭스 세트는 50달러에 판매되고 있다.
이렉터 스파이키 박스(Erector Spykee Vox) 로봇
흔히 이렉터 브랜드 하면 우리의 아버지들이 사용하는 도구들을 생각하기 쉽다. 그러나 최근 이렉터 브랜드를 보유한 메카노(Meccano)는 이번 박람회를 통해 새로운 장난감용 이렉터 로봇을 선보였다. 스파이키 박스라 불리는 이 로봇은 3가지 용도로 사용될 수 있다. 우선 아이팟에 들어있는 노래들을 재생시킬 수 있고, 음성 명령에 반응하도록 만들 수 있으며, TV의 채널을 사용자 임의대로 대신 돌리도록 설정해놓을 수 있다.
스타워즈 포스 트레이너, 제다이 기사들을 훈련시키다
엉클 밀턴스 토이(Uncle Milton’s Toys)라는 이름의 기업이 스타워즈 팬들을 위한 새롭고 신선한 장난감을 개발했다. 스타워즈 포스 트레이너가 바로 그 것. 포스 트레이너는 뇌파를 측정하는 헤드셋을 이용한다. 헤드셋으로부터 측정된 뇌파는 포스 트레이너 베이스에 부착된 선풍기에 의해 공기 바람으로 실시간 전환되고 이 바람은 장난감 안의 공을 위 아래로 움직인다. 포스 트레이너는 이 업체가 지속적으로 출시하던 스타워즈 과학 장난감 세트 라인 중 하나다. 이 밖에 이들이 개발한 스타워즈 관련 장난감에는 다스 베이더의 로봇 팔, 제다이 망원경, 제다이 투영기, 그리고 무스타파 화산 세트 등이 있다. 스타워즈 과학 장난감 세트는 올해 말 전까지는 출시되지 않을 계획이다. 포스 트레이너의 가격은 100달러 정도로 예상되고 있다.
펀플라이 스틱(FunFly Stick), 공중 부양을 현실로
유니테크(Unitech)의 펀플라이 스틱은 사실 이들이 이미 출시한 바 있는 제품이다. 그러나 아직까지도 충분히 사람들의 시선을 사로잡을 만큼 충분히 신기한 제품이기에 이번 박람회에서도 여지없이 그 빛을 발했다. 펀플라이 스틱은 자기장을 이용해 특수 금속을 공중에 띄우는 방식으로 작동된다. 실제로 한 번 이 장난감이 시연되는 것을 보면 그 광경에 매료될 수 밖에 없다. (동영상을 보려면 이 곳을 클릭하라) 펀플라이 스틱은 27달러 정도의 가격에 구매할 수 있다.
디지털 블루(Digital Blue)의 레고 장난감
이제 레고(Lego)가 자랑하는 레고 블록들을 가지고 노는 것을 식상하게 느끼는 어린이, 또는 사람이 있다면, 이번 전시회에 출품된 일련의 제품들을 도전해보라고 강력하게 권하고 싶다. 바야흐로 레고를 통해 디지털 음악을 듣고 디지털 사진을 찍을 수 있는 시대가 도래했기 때문이다. 장난감 메이커 레고는 디지털 블루(Digital Blue)와 제휴를 맺고 장난감용 전자 제품들을 개발하기 시작했다. 이에는 붐박스 라디오, 디지털 카메라, 그리고 MP3까지 포함되어 있다. 디지털 블루 측에 따르면 이 모든 제품들이 2009년 말까지는 시중에 출시될 것으로 알려졌다. 정확한 가격은 아직 책정되지 않은 상태.
클루(Clue)의 재발견
하스브로(Hasbro)에서 개발한 전통 보드 게임 중 하나인 클루(Clue)를 좋아한다면 이번 전시회에서 선보여진 클루: 시크릿 앤 스파이즈(Clue: Secrets & Spies) 에디션을 도전해보길 권한다. 이 게임에서 각각의 참가자들은 범죄자 집단의 세계에 침투해서 흉악한 블랙 요원을 납치하고 이들 집단의 세계 정복 야욕을 막는 임무에 투입된 국제 스파이 역할을 부여 받는다. 이 게임의 특징은 휴대폰 기능이 게임에 활용된다는 점이다. 참가자들은 휴대폰 문자 메시지를 통해 게임 진행 상의 힌트를 얻을 수 있다. 힌트를 얻기 위해서는 설명서에 나와 있는 대로 플럼 요원, 스칼렛 요원, 머스터드 요원 등에게 문자 메시지를 보내야 한다. 이들에게 문자를 보내면 매 8분 마다 블랙 요원에 관한 정보들이 휴대폰 문자 메시지로 수신되는 것을 경험할 수 있다. 클루: 시크릿 냉 스파이스 에디션은 올해 중 출시될 예정인데, 가격은 25달러 정도로 책정될 예정이다. editor@idg.co.kr
기사입력 : 2009.02.20 13:33 Tom Spring
인간적으로 이건... ㅠ ㅠ 진짜... 지나치게 귀엽잖아.... 흐윽.... 눈물이 나 ;ㅂ;
오. 귀엽다. 처음 봤을때 딱 MIT MediaLab 에서 만든 Shiftable 생각나더라. (음.. shiftable 블로깅 했다고 생각했는데 블로깅 내역이 없네. 아래는 Shiftable 동영상이다.)
Shiftable 은 작은 블럭들간의 인터렉션을 즐기는 일종의 Digtal Toy 라고 할 수 있겠다. 보면서 우와 재미있다 나도 하나 가지고 싶어 - 하고 있었는데, MIT 대학생들의 프로젝트 성 물건이기에 상용화는 되어 있지 않아 그럴 방도는 없었다.
헌데 지나가다가 Mintpad 라는 제품을 발견. 물론, Shiftable 의 주요 컨셉인, 블럭간 물리적 인터렉션 기능(맞대고 있으면 두 블럭간 색상이 동기화 된다든지 하는)은 없지만, 한손에 잡는 작은 크기라는점, 매우 단순한 하드웨어 인터페이스 라는점, 그리고 그 기능들이 말그대로 '전문기기' 가 아닌 '보조문구' 수준의 단순하다는 점, tangible interface를 일부 '흉내내고' 있다는 점... 등등. mintpad 가 내밀고 있는 많은 컨셉들이 shiftable 과 상당부 오버랩 된다.
기능을 요약하면 아래와 같다.
- 메모
- 포스트잇과 같은 컨셉으로 터치패드 스케칭. mintpad 끼리 메모 전송이 가능하기 때문에 1:1 챗도 가능하다는 이야기가 된다. 무선랜 없이 30m 이내의 교실이면 주고 받을 수 있다하니.... 이젠 간편한 치팅을. (-_-응?)
- 인터넷/블로깅
- 와이파이가 연결된 어디서든 인터넷 풀브라우징 지원!!! 오!!!!! 간단한 블로깅 기능도 있어서 블로그에 글 등록하고 보는것도 가능하단다.
- 멀티미디어
- 뭐 음악 감상 동영상 감상 되고, 사진 되고.. e-book 되고.. 녹음되고.. 이정도야 뭐 왠만한 포터블 기기의 기본기능이지 이제는.
- 카메라
- 130만 화소짜리 카메라가 달려잇덴다 ;ㅂ; 아놔... 예전에 zire71 쓰던때의 추억이 떠오르는군.. ㅠ ㅠ 화소는 떨어져도 진정한 똑딱이!!! 개인적으로 무척 마음에 드는 기능이다.
- 스케쥴링 및 명함관리
- 스케쥴 입력 가능 하고 명함 입력 가능. 간단하 pda 수준의 기능을 제공해 주는건가? 스케쥴링 기능은 정말 대 환영이지만. ㅎㅎㅎ.
- 사파이어
- PC에 별다른 설치 없이도 꼽기만 하면 어느 컴퓨터에서든 실행된다는 매우 마음에 드는 매니징 프로그램!! 사실 디지털 카메라니, mp3니, pmp 니.. 기타등등 pc 에는 온갖 씽크로 관련 매니징 소프트웨어깔리는데 정말 짜증. -_- 개인적 취향으로는 사파이어가 매우 마음에 든다.
가격은 대략 \199,000 (이정도면 아주 적당하다고 생각한다.)
하지만 아직 사용기나 기타등등을 읽어보면, 회의적인 시각도 있고.. (물론 그렇겠지. ㅎㅎ) 기능상의 의문을 제기하는 부분도 없잖아 있으므로 좀 더 신중할 필요가 있다......... (라고 쓰고 있지만 마음속은 이미 결재중이다 OTL)
요즘은 펌웨어 업그레이드 시대이므로 현재 미흡해보이는 많은 부분은 충분히 개선의 여지가 있다고 생각한다. ㅎㅎㅎㅎㅎ. 예를 들면 쉬프터블의 경우 흔들만 이미지가 흐려지거나하는 리액션이 있다. 민트패드의 경우 작성중이던 데이터가 저장된다고 한다. 뭐, '흔든다' 라는 tangible interface 가 기능과 전혀 의미적 유사성이 없다고 볼수 있다. -_- (흔들면 저장되다니.;; ) 하지만 Fun 컨셉에 추후의 펌웨어 업그레이드를 강조하는 걸로 봐서는 해당 기능을 사용한 추가적인 Funware 를 만들겠다는 생각이 엿보인다. (쉬프터블처럼 기울이면 화면이 넘어가거나 하면 좋을텐데 ㅋ)
Prev
