'Smart Mobile' 카테고리의 다른 글
모바일 앱 개발, 이젠 멀티코어로!!! (0) | 2010.09.29 |
---|---|
QOOK Open IPTV 서비스 설명회 (0) | 2010.03.08 |
스마트폰 경쟁에 비춰진 강자들의 속내는? (0) | 2010.03.03 |
모바일 앱 개발, 이젠 멀티코어로!!! (0) | 2010.09.29 |
---|---|
QOOK Open IPTV 서비스 설명회 (0) | 2010.03.08 |
스마트폰 경쟁에 비춰진 강자들의 속내는? (0) | 2010.03.03 |
bada Developer Day in Seoul (0) | 2010.03.24 |
---|---|
"바다" 어플리케이션 생명 주기 (2) | 2010.03.16 |
바다 Application UI Classes (0) | 2010.03.16 |
SK텔레콤 "T Store 아이디어&어플리케이션 공모전"에 초대합니다. (0) | 2009.09.03 |
---|---|
Google Android @ AlphaCSP's JavaEdge (0) | 2009.08.05 |
Android An Open Platform For Mobile Devices (0) | 2009.08.05 |
Google I/O 2010 (0) | 2010.01.18 |
---|---|
광고로 벌어 정승같이 돈 쓰는 "Google" (1) | 2009.08.08 |
완도갑니다. (0) | 2009.07.30 |
Eric Schmidt at IBM Business Partners Leadership Conference (0) | 2008.05.07 |
---|---|
미국과는 너무 다른 유럽의 광우병 대책 (0) | 2008.05.06 |
무료 원어민 동영상 영어 강좌를 소개합니다. (1) | 2008.05.02 |
순진한 개발자가 사내정치에서 살아남는 법 류한석 (IT 컬럼니스트) ( ZDNet Korea ) 2008/03/17 |
개발자 K씨를 재회한 것은 8년만의 일이다. 그는 나와 함께 일했던 직장에서 이직한 이후에 4번이나 더 이직을 했는데, 현재는 실직 상태에서 직장을 구하고 있었다. 솔루션을 개발하는 회사에서는 비전이 없어 그만 두었고, 대기업 계열 SI업체를 들어갔으나 개발이 아닌 관리를 시켜서 그만두었고, 포털에 들어갔는데 할 일이 별로 없고 회사 상황이 정치적이어서 그만두었다고 했다. 그리고 마지막 회사는 소위 벤처기업이었는데, 6개월이나 임금을 받지 못한 상태에서 사장이 사실상 야반도주를 해서 회사가 망했다고 했다. K씨는 자바를 정말 잘 다루던 개발자였는데, 일반적인 기준에서 볼 때 성격이 좋다고 얘기하기는 힘든 사람이었지만 그 정도면 무난하다고 할 수 있었다. 다만 여느 개발자와 마찬가지로, 타인의 욕구에 관심을 가지거나 커뮤니케이션 스킬이 뛰어난 사람은 아니었다. 다음은 그가 한 얘기이다. “회사 경영은 나하고 상관이 없다고 생각했어요. 제가 경영이나 관리 같은 것은 잘 모르고요. 회사에서 벌어지는 정치 게임은 질색이에요. 저는 그저 개발만 하고 싶었어요. 그런데 개발에 집중할 수 있는 조직이 참 없더라고요. 이제 저는 어떻게 해야 할까요?” 필자는 그날 K씨와 새벽까지 술을 마실 수 밖에 없었다. 개발자가 개발자답게 일하고 성장할 수 없는 것이 바로 한국의 현실이다. 성장을 하는 것이 아니라 사라져 가고 있다. 개발자는 어떤 사람인가? 문제를 발견하고 문제를 해결하고, 스펙에 따라(또는 창조적으로) 무언가를 만들어 내고, 오랜 시간 동안 한 자리에 앉아서 화면만을 째려보며 몰입할 수 있기에 개발자다. 그것이 그들의 특징이며 그렇게 때문에 개발을 할 수 있는 것이다. 개발자에 대해 IT업계의 다른 직종들은 어떻게 생각하고 있을까? 단편적이지만 그들의 생각을 살펴보자. 어떤 영업맨은 “저한테 저렇게 열 시간 동안 앉아 있으라고 하면 절대 그러지 못할 거 같네요. 어떻게 저럴 수 있나요?”라고 필자에게 반문하기도 했다. 어떤 마케터는 “그들은 쿠폰에 항상 도장을 찍더군요. 작은 것에 민감한 거 같아요. 시야가 좁고 자신들의 분야 외에는 거의 관심이 없는 거 같더군요. 게임이나 애니, 미드 같은 것을 좋아하고. 업계나 시장 돌아가는 상황에 대해서는 관심도 없고...”라고 얘기했다. 실제로 마케터들은 개발자와 함께 일하는 경우가 별로 없어서 그들을 잘 모른다. 원거리에서 그들을 바라볼 뿐이다. 반면에 개발자와 함께 협업하는 경우가 많은 요구분석가, 웹기획자들 중 상당수는 다음과 같은 얘기를 했다. “그들은 커뮤니케이션 스킬이 없어요. 중요한 대화에는 제대로 응하지 않다가 자신들과 상관이 있는 이슈가 나오면 발끈해요. 무조건 안 된다고만 하죠. 도무지 협상이라고는 할 줄 모르는 사람들이에요.” 혼자서 일하는 1인 개발자가 아닌 이상, 대부분의 개발자는 조직에서 협업을 해야 한다. 프로젝트 매니저와 대화해야 하고, 기획자/디자이너/동료 개발자와 협업을 해야 한다. 프로젝트에 따라서는 고객과 직접적인 커뮤니케이션을 해야 하는 경우도 있다. 그리고 사내정치를 피해갈 수 있는 개발자는 거의 없다. 직간접적으로 영향을 받을 수 밖에 없다. 그런데 한국에서 사내정치는 중소기업에서 대기업, 인터넷기업까지 만연되어 있다. 많은 개발자들이 정치를 싫어한다. 정확히 표현하면 정치가 미치는 부정적인 영향을 싫어한다고 할 수 있을 것이다. 하지만 조직이라는 것은 그 안에 있는 수많은 조직구성원들이 지위 고하에 따라 자신의 목표와 이익을 추구하는 곳이다. 그리고 그들간의 이해관계는 상충될 수 밖에 없다. 그래서 누군가는 희생자가 된다. 안타깝게도 그 대상은 대부분 개발자이다. 개발자는 현실적인 일정 하에서 보다 나은 기술을 이용하여 높은 품질의 소프트웨어를 만들고 싶어하지만, 어떤 사람들은 기술 자체나 품질은 전혀 상관없이 일자 또는 비용만이 그들의 관심사이다. 그렇다면 그것은 잘못된 것인가? 그럴 수도 있고 아닐 수도 있다. 상황에 따라 답이 다르다. 현실은 단순한 흑백논리로 설명되지는 않는다. 패배하지 않기 위해 이것만은 기억하자 사내정치에서 살아남기 위해서 개발자가 알고 있으면 유용할 세 가지 지침을 제시한다. 다음의 세가지 지침은 서로 연동된다. 1. 나의 목표와 주변의 이해관계를 파악하고 있어야 한다. 자신이 원하는 것이 돈인지 명예인지 지위인지, 아니면 개발을 통한 자아실현인지, 개인생활의 추구인지 명확히 알고 있어야 한다. 또한 나의 목표를 실현하는데 있어 가장 큰 장애물이 무엇인지 알고서 그것을 관리해야 한다. 자신의 목표와 상충되는 목표를 가진 이해관계자의 욕구를 파악하고 그것과의 타협점을 찾아야 한다. 하지만 사실, 대부분의 경우 목표를 실현하는데 있어서 가장 큰 장애물은 자기자신의 성격이다. 그렇지만 성격을 수양하는 개발자가 과연 몇 %나 될까? 아는 것과 실천은 완전히 별개의 단계이다. 2. “너와 나의 진실은 다르다”는 사실을 이해하고 있어야 한다. 자신이 믿는 것만이 정의이고 진실이라는 생각이 들 때, 숨을 세 번 크게 내쉬면서 상대편의 입장에서도 과연 그럴까 다시 한번 생각해 보기 바란다. 내가 알거나 느끼는 것을 쉽게 드러내서는 곤란하다. 대부분의 경우 그것은 설익은 판단이고 타이밍이 적절치 않은 경우가 많다. 하지만 자신의 감정을 주체하지 못하고 ‘욱’한 나머지, 준비도 안된 상태에서 회사를 그만 두어 버리고 경력을 망치는 개발자들이 많다. 퇴사 후 놀고 있는 당신을 사내정치인들은 비웃고 있다. 3. “군자에게는 실수를 해도 소인배에게는 실수를 하지 말라”는 격언을 기억하기 바란다. 이 말은 필자가 회사 생활에서 곤란을 겪는 후배들에게 숱하게 해주었던 말이다. 이 말을 처음 들었을 때의 임팩트는 상당히 크다. 군자(君子)는 점잖고 덕이 있는 사람이다. 그래서 군자는 누가 실수를 해도 그 이유를 스스로 파악하여 너그럽게 이해해준다. 하지만 소인배는 조금만 불이익을 당하거나 무시를 당했다고 느끼면 바로 삐지며, 심할 경우 끝까지 따라다니며 괴롭힌다. 그런데 사람이란 군자에게는 존경심을 갖고서 공손히 대하고 소인배는 무시한 나머지 함부로 대한다. 그것이 인지상정이다. 하지만 만일 그 소인배가 당신의 직장상사라면? 사내정치는 어느 나라에나 존재한다. 한국뿐만 아니라 미국에도 일본에도 있다. 하지만 한국에서 더욱 사내정치가 심할 수 밖에 없는 이유가 있다. 한국은 아직까지 IT업계뿐만 아니라 사회의 여러 분야에서 전문가의 개념이 불분명한 나라이다. 제대로 된 전문가가 출현하고 그 가치를 인정받는 지식사회가 되기까지 앞으로도 꽤 많은 시간이 걸릴 것이다. 한국은 아직은 선진 지식사회가 아니다. 그러므로 고급지식을 가진 사람들이 별로 없을 뿐만 아니라, 설사 있다고 하더라도 그것을 인정하지 못하며, 설사 인정한다고 할 지라도 필요로 하지 않는다. 실력을 인정하는 기준이 없으니, 사내정치가 판을 친다. 전문가를 필요로 하지 않는 사회, 자기계발이 살길 궤변으로 들릴 지 모르지만, 우리 업계에 전문가가 없는 것은 전문가를 필요로 하지 않기 때문이다. 조직 내에 사내정치인이 승진하고 인정받는 것은 조직의 상층부가 몰라서 그런 것이 아니라 그런 사람을 선호하기 때문이다. 성장은 커녕 생존을 이야기해야 하는 현실이 안타깝지만, 일단 생존해야 자기계발을 하고 경력관리를 하면서 기회를 노릴 것이 아닌가? 사내정치를 잘 할 필요는 없지만(그리고 개발자의 특성상 잘 하지도 못 할 것이다), 희생자가 되어서는 곤란하다. 이것이 바로 필자가 개발자 K씨에게 한 말이다. 개발자는 자신의 개발력과 장점을 해치지 않는 선에서, 이해관계자를 파악하고 그들의 욕구를 다루는 능력을 갖추어야 한다. 자신의 목표를 분명히 해야 하며, 감정에 치우쳐서 일을 그르치지 말아야 한다. 그러지 못한다면 결국 희생자가 될 뿐이다. 그러한 희생을 몇 번 당하다 보면, 개발업에 대한 애정이 식어버려 자기계발을 등한시하게 될 뿐만 아니라 성격까지 나빠져서 더욱 더 안 좋은 상태에 처하게 된다. 그렇게 사라져간 개발자들이 참 많다. 이런 조언을 하는 것에 대해 한편으로는 미안하게 생각한다. 언젠가 개발력만으로도 인정받을 수 있는 사회가 오면(너무 낭만적인 표현이다), 사내정치 대신 좀 더 아름다운 세상에 대해 이야기하겠지만 지금은 아니다. 정신을 똑바로 차리고 이 난세에서 생존하기 바란다. 환경을 바꿀 수 없으면 자신을 바꾸어야 하며, 자신을 진화시킨 개발자에게는 반드시 기회가 올 것이다. 세상은 장기적으로 볼 때 스스로 혁신하는 사람의 편이니까 말이다. @ |
오랜만의 인라인 로드, 22km 달렸습니다. (0) | 2008.03.20 |
---|---|
휴가의 마지막 월요일 (0) | 2008.03.17 |
일주일 휴가 더~~ (0) | 2008.03.11 |
Open source robotics toolkitsUse virtual arenas to test your robotics algorithms |
Level: Intermediate M. Tim Jones (mtj@mtjones.com), Consultant Engineer, Emulex 05 Sep 2006 Building a robot involves skills from many disciplines, including embedded firmware and hardware design, sensor selection, controls systems design, and mechanical design. But simulation environments can provide a virtual arena for testing, measuring, and visualizing robotics algorithms without the high cost (and time) of development. This article introduces you to some of the open source robotics toolkits for Linux®, demonstrates their capabilities, and helps you decide which is best for you.
The spectrum of traditional robots is large and varied, but with the advent of software agents (the virtual robot counterpart), these variations have expanded. Many of the characteristics of physical robots lend themselves to robots in the virtual domain. For example, mobility in physical robots implies some sort of locomotion, but mobile soft robots (or agents) can have mobility -- here, the ability to migrate between hosts in a network. Figure 1 shows a shallow view of autonomous robotics in the physical and virtual domains. This article focuses on software agents as a mechanism to simulate robots in synthetic environments. Figure 1. Shallow taxonomy of autonomous robots Whether you're talking about a physical robot or a virtual (soft) robot, the fundamental concepts are the same. The robot has a set of sensors used to perceive its environment, a set of effectors to manipulate its environment, and a control system that allows the robot to act in an intentional and useful way (see Figure 2). Figure 2. The fundamental elements of all robotic systems In the physical world, a fire-fighting robot could use temperature sensors, infrared (IR) sensors, a Global Positioning System (GPS) to perceive its environment, and motors and perhaps a fire extinguisher as effectors to manipulate its environment. A virtual search agent could use Web servers and HTTP interfaces to both perceive and manipulate the environment (the Internet) and a console as an effector to communicate with a user. The system shown in Figure 3 is that of a closed loop, with sensors feeding the control system that drive changes in the environment. Another way to think about this is in terms of feedback. If the control system specifies an act that changes the environment, the sensors can validate this change, feeding back the new state of the environment to the control system. An open-loop system would have to assume that the acts successfully changed the state of the environment, which can never be a good thing. Figure 3. Closing the loop with the environment When building a robot, you must consider the sensors, the effectors, and the control system as a whole. For this article, I focus on the control system and the ways in which you can simulate and validate it before spending time embedding it in a physical robot.
Simulation plays a key role in the field of robotics, because it permits experimentation that would otherwise be expensive and/or time-consuming. Simulation permits you to try ideas in dynamic, synthetic environments while collecting stimulus response data to determine the quality of the control system. Simulation also allows the evolution of robotics control systems, which depend on random permutations of the control system over many generations (as demonstrated by genetic algorithms).
One of the greatest advantages to simulation occurs in multi-robot simulations. A popular venue for these simulations is in Robot Soccer, where either through simulation or with physical robots, one team of robots competes against another in the popular world sport of soccer (making it ideal for international competition). The robots must compete cooperatively against the other robots on their team (possibly with communication) as well as competitively with the robots on the opposing team, making it a challenging test of robot behavior. But there are downsides to simulation. The real world tends to be messy and noisy, and synthetic environments are fundamentally difficult to model. Simulating a robot also tends to be difficult, as sensors in the real world can often exhibit different or unexpected characteristics. Despite the disadvantages, you can learn a lot by simulating robots in synthetic environments.
Open source toolkits for Linux Several open source toolkits are available for building robotic control systems. This article looks at mobile robot simulators, a physics modeling system, and finally, a simulator that supports embedding a simulated control system in a physical robot. The vast majority of toolkits available run on Linux, primarily because of the open source model. Open source software is a platform from which you can develop software more quickly and with less effort, so it's ideal. Linux also permits customization not possible in other operating systems (such as minimizing and extending the kernel). Links to these toolkits and more are in Resources section at the end of this article. Russell Smith's Open Dynamics Engine (ODE) is an open source physics engine with which you can simulate articulated rigid body dynamics. In this way, you can simulate the physics of real-world objects independent of a graphics library (for which you could use OpenGL). You can use the ODE to model all sort of objects in synthetic environments, such as characters in three-dimensional game environments or vehicles in driving simulations. In addition to being fast, the ODE supports collision detection for real-time simulation.
The ODE currently supports the ball-and-socket, hinge, slider, fixed, angular motor, and hinge-2 (for vehicle joints) joint types, among others. It also supports a variety of collision primitives (such as sphere and plane) and several collision spaces. The ODE is written primarily in the The source example in Listing 1 shows a simple world with Mars' gravity and a sphere that currently has some upward velocity. Given that the world has gravity, that upward velocity won't last long; eventually, the sphere reaches the apex and begins its descent. After the initialization is complete (that is, objects created in the world and their attributes set), you can simulate the physics of the world with a call to Listing 1. Simple ODE experiment of a sphere in a world with gravity
So, if you need an industrial-quality physics engine (that operates on Linux as well as other platforms) to simulate your mobile robot or unmanned aerial vehicle in realistic environments, the ODE is a superb choice. Used with the OpenGL application program interface (API), the ODE generates photo-realistic graphics with realistic physics, as well. Simbad is a three-dimensional robot simulator written in the Java® programming language (so it runs on Linux and other platforms that support the Java virtual machine, or JVM); however, the simulator includes support for Python scripting (through Jython). Simbad was designed to study artificial intelligence (AI) algorithms in the context of autonomous robotics, and it includes a rich graphical user interface (GUI) for visualization not only of the robot's actions but also from the robot's perspective. What makes Simbad interesting is that it's simple to use and allows you to create new robot behaviors quickly. But while developing for Simbad is simple, it's actually an extensible framework for robotic simulation. With the simulator, you can create or tailor an environment, and then develop your robot controller using a variety of sensors. Available sensors include a vision sensor (color monoscopic camera), range sensors (sonars and IR detectors), and bumpers for collision detection. The APIs for the sensors are clean and intuitive to use. The example in Listing 2 demonstrates the use of sonar and how to detect a hit (an object detected). Listing 2. A snippet of code demonstrating simulated sonar use
Other sensors available in Simbad follow a similar pattern, creating an intuitive set of APIs. What really makes Simbad so useful is its console for robot simulation and visualization. As Figure 4 shows, the Simbad console gives you a real-time view of the world, an inspector panel that provides robot details (including the camera), and a control panel for managing the simulation. Figure 4. The Simbad robot simulator and visualizer console Simbad also provides good documentation and tutorials to get you up and running quickly in both the Java and Python languages. And along with single-robot simulation, you can simulate multiple robots simultaneously. Overall, the Simbad simulator is a great environment for testing ideas in intelligent robotics algorithms. Simbad is available under the GPL open source license. TeamBots is a portable multi-agent robotic simulator that supports simulation of multi-agent control systems in dynamic environments with visualization. What makes TeamBots unique compared to other simulators such as Simbad is the portability of the control system. You can develop your control system and validate it on the simulator, and then test your control system in a real mobile robot (using the Nomadic Technologies Nomad 150 robot). The TeamBots API provides an abstraction layer for the control system (see Figure 5). As a result, the control system has no idea whether it's running on a simulator in a synthetic environment (TBSim) or in a mobile robot platform in a real environment (TBHard). Figure 5. The TeamBots API abstraction layer to the control system The TeamBots simulation environment is very flexible and easily allows the construction of synthetic environments with objects and other robots. It is easy to add walls, arbitrary objects, roads, and other robots running the same or different control systems. In this way, you can build predatory/prey simulations (as one example). In addition, objects need not be static. You could place objects that move around the environment or objects that can move if nudged by a robot (such as a ball). With TeamBots, you can model different types of robot simulations. For example, in 1997, Georgia Tech used TeamBots to win the American Association for Artificial Intelligence (AAAI) mobile robot competition with two simulated Nomad 150 robots foraging in a dynamic environment. The goal was for the two robots to search the environment, and then pick up and return the blue objects to the blue bin and the orange objects to the orange bin (see Figure 6). To add some complexity to the competition, the orange balls were dynamic and constantly moved around the environment. Figure 6. TeamBots simulation of foraging behavior In Figure 6, mobile robot 1 has a blue object and is moving toward the blue bin to drop it off. Robot 0 is searching. You can also use TeamBots in the development of robotic soccer players. As soccer is a sport with international appeal, it's a great platform for competition between international universities and groups. Rules for robot soccer can differ (especially when considering the varieties that exist for mobile platforms, bipedal platforms, or Sony Aibo), but all share the fundamental model of the game. In Figure 7, Robot 1 (yellow/white) is moving toward the ball in a goal attempt. Robot 0 (blue/red) is the opposing goal keeper and is positioning for a block. Robot soccer is actually quite interesting to watch, and the TeamBots distribution provides several teams that you can employ or use to experiment for new strategies. Figure 7. Demonstrating TeamBots in the SoccerBots domain TeamBots provides a Java API for soccer that allows you to concentrate on the "brain" of the player. The effector API permits turning the robot, moving at a certain speed, kicking the ball, or simply moving the ball. Sensors are built at a high level and provide APIs for determining the vector to the ball, an array of vectors to other players (team and opponents), getting the current heading, getting a vector to the opposing goal, and so on. To give you an idea of the level of the TeamBots Soccer API, check out Listing 3, which presents a very simple strategy. This strategy (derived from the SoccerBots source by Tucker Balch) simply looks for the ball, heads to it, and then kicks it (without regard to the direction of the goal). It's a random strategy but demonstrates the simplicity of the API. Listing 3. Simple soccer player snippet using the TeamBots SoccerBots API
The TeamBots distribution is a great environment for both prototyping and simulating mobile robots and also for executing them within real robots using the TBHard environment. TeamBots is open source (developed by Tucker Balch of Georgia Tech and Carnegie Mellon University) and can be used freely for educational and research purposes. The simulator was developed in the Java language and is distributed with full source code and several examples to help you get up and running quickly.
One of the most well-known mobile robot platforms for which numerous simulators have been written is called Khepera. Unfortunately, Khepera evolved into commercial software and is no longer open source. Fortunately, toolkits such as KControl are still available for developing control systems for Khepera on Linux. An interesting three-dimensional robot simulator with dynamics is available in Gazebo. Gazebo models not only standard robot sensors (such as inertial measurement units, GPS receivers, and monocular cameras) but also real-world rigid-body physics for robotic environments. Gazebo supports a plug-in model in which you can load new robot sensor models into environments dynamically. Finally, a useful robot navigation toolkit is Carmen -- the Carnegie Mellon Robot Navigation Toolkit. Carmen implements a modular architecture that provides fundamental navigation primitives such as obstacle avoidance, path planning, and mapping. As well as providing a two-dimensional simulator, Carmen supports several physical robot platforms running Linux.
Getting started building Linux-based robots isn't as difficult as you might think. In fact, some high-school science curriculums are using Linux and readily available hardware as the core for Linux-based robots. For example, you could use an old PC motherboard as the system core (or better yet, an old laptop), and boot Linux from a USB drive (which would consume significantly less power than a CD-ROM or hard/floppy drive). The onboard parallel port can be easily transformed into a multitude of devices, such as discrete inputs and outputs, or to drive a set of stepper motors. The serial port can be used to sink GPS coordinates, or with an external device, as an A/D (Analog to Digital) or D/A (Digital to Analog) converter. Finally, you can purchase inexpensive USB Web cameras to give your robot the ability of sight. But what really makes Linux shine in this environment is the ability to simplify the environment to make robot control system design accessible to anyone through higher level languages such as Python. Michael Surran of the Greater Houlton Christian Academy in Maine offered recently, for the second year, a high school robotics course that features Linux and readily available hardware. At the core of their curriculum is the use of Python. Since Python is an interpreted language, it's very easy to experiment with algorithms, without the need for lengthy compile cycles (what makes interpreted scripting languages so useful in the first place). If you're looking beyond the homebrew Linux solution, Carnegie Mellon University recently introduced the "Qwerkbot" platform from their Mobile Robot Programming Lab (MRPL), which runs the 2.6 Linux kernel. The "Qwerk" is an ARM9-based board with 8MB of flash, and 32MB of SDRAM; it includes four onboard motor controllers, 16 servo controllers, 16 digital I/Os, 8 12-bit analog inputs, and a whole lot more.
Robot simulators can greatly simplify the job of building physical robots. Through simulators, you can test ideas and strategies before putting them into hardware. Luckily, the Linux and open source communities have several options that are not only easy to use but can even support direct linkage to hardware platforms. Learn
Get products and technologies
Discuss
|
RMCP-2 에 대해 알아보자! (0) | 2007.12.05 |
---|---|
RakNet ... 이런 네트워크 라이브러리도 있군요.. (0) | 2007.11.27 |
마소에 연재되었던 OpenCV 강좌입니다. (1) | 2007.11.25 |
덥다... (0) | 2007.05.22 |
---|---|
[설문결과] 당신은 얼마나 여자 같은 남자일까? 여러분도 해보세요. (0) | 2007.05.18 |
앉아서 세계를 보다 (0) | 2007.05.15 |
P2P를 바로보는 사용자들의 자세. (0) | 2007.05.14 |
---|---|
추억.. 오래전에 야근하고 퇴근하다 찍었던 영상 (0) | 2007.05.11 |
추억... 기부스하고 팝디제이 개발하셨던 분 (0) | 2007.05.11 |
추억.. 오래전에 야근하고 퇴근하다 찍었던 영상 (0) | 2007.05.11 |
---|---|
쌍코피님이 작성하신 팝디제이 관련 게시물 (0) | 2007.05.08 |
그 간의 흔적을 찾아서... (0) | 2007.05.08 |