본문 바로가기

분류 전체보기

 (65)
Mobile Card Game on WIPI 소프트웨어 공학 학기 과제로 모바일게임을 만들었다. 총 5명의 조원이 함께해서 작업을 했다. 조 이름은 iKnow, 프로젝트의 이름은 짝궁이었다. 짝궁은 같은 그림을 맞추는 게임의 특성을 살려 지은 이름이었다. 게임을 하다보면 생각보다 쉽지 않은 것을 알 수 있는데, 그림을 아주 미세하게 다르게해서 난이도를 높이도록 의도했기 때문이었다. 개발 및 실행 환경은 자바(Java) 1.3, 아로마 위피 에뮬레이터(Aroma WIPI Emulator) 1.1.1.7 이었다.
Haptic Game Framework 푸시 푸시(Push Push)를 대체할 햅틱 게임(Haptic Game)을 만들어 보기 위해 시작한 과제였다. 게임을 쉽게 만들어서 올려보기 위하여 애니메이션 저작 및 재생 환경인 플래시(Flash)를 선택했다. 플래시는 디자이너에게 친숙한 도구였기 때문에 게임 캐릭터만 의뢰하면 쉽게 게임을 만들 수 있을 것 같아서 선택했다. 또한 여러 운영환경(Cross-platform)을 지원하는 장점도 고려요소 였다.제일 먼저 도전한 부분은 햅틱 장치(촉각 장치, Haptic Device)와 플래시 플레이어(Flash Player/Runtime)를 연결하는 부분이었다. 포스 피드백(Force Feedback)장치와 플래시를 연결하기 위해서는 먼저 OS와 장치를 연결하기 위한 프레임워크(Framework)를 결정해야..
Pilot.Core 학부 졸업작품으로 만든 프로그램이다. 이름은 Pilot.Core였다. 이름을 이렇게 붙인 이유는 비행기 시뮬레이터를 만들어 보려고 시작했기 때문이었다. 처음엔 조종사를 의미하는 파일럿이라고 했으나, 기본 기능만 있는 엔진까지밖에 만들지 못했고, 그래서 코어를 뒤에 붙였다. 그리고 마이크로소프트의 닷넷(.Net) 이름처럼 만들고 싶어서 가운데에 점을 추가했다. 본 어플리케이션을 간단히 설명하면 아주 기초적인 3D 게임이라고 할 수 있다. 조이스틱을 움직이면서 가상공간을 날아다니는 프로그램이다. 졸업작품을 위해 컴퓨터 그래픽과 게임엔진, 가상현실에 대해 배우면서 구현했기 했기 때문에 부족한 기능들이 너무 많았다. 많이 힘들었지만, 그래도 고생해서 만들었던 프로그램이어서 특별히 기억에 남았다. 소스코드 및 이..
Stress Test 성능 검증(Performance Test) 방법 중 하나인 스트레스 검증(Stress Test)에 대한 이야기를 해보려고 한다. 시스템의 성능을 가늠하고 측정하는 방법에는 여러 가지가 있을 수 있지만, 대표적으로 많이 활용하는 3가지는 부하 검증(Load Test), 스트레스 검증(Stress Test), 내구성 검증(Endurance Test)이 있다. 클라우드 환경이 널리 퍼지면서 확장성 검증(Scalability Test)도 성능 검증의 범주에 포함되고 있다.내 주변의 통계는 늘 틀린다는 것을 알고있지만, 실무에서 많은 소프트웨어 개발자들을 만나다보면 시간부족을 이유로 검증 과정을 대충 넘기는 것을 자주 볼 수 있었고, 테스트에 대해 잘 모르는 개발자들도 의외로 많았다. 성능 검증과 성능 분석을 혼..
Atomic 원자(Atom)는 물질의 화학반응을 통해 더 쪼갤 수 없는 단위를 말한다. 현대 물리학의 관점에서 볼 때 원자는 원자핵과 전자로 이루어져 있으며, 원자핵은 중성자와 양성자로 구성된다. 또 핵반응을 통해서는 더 작은 단위로 나뉜다. 원자의 정의에 따라 원자의 특성(Atomic)은 더 이상 나누어 질 수 없는 최소 단위라는 의미를 갖는다. 갑작스럽게 원자 이야기를 꺼낸 이유는 객체지향의 원리를 설명하기에 효과적이기 때문이다. 간단한 원자의 원리를 생각해 보면 좋겠다. 우리는 물을 구성하는 화학물질이 산소와 수소라는 것을 잘 알고 있다. 그리고 화학식으로는 H2O라고 표현하는 것을 잘 알고 있다. 이 것은 2개의 수소 원자와 1개의 산소 원자의 화학적 결합을 의미한다. 그래서 물을 전기분해하면 산소와 수소를 ..
Code Review, Thumbs-up 단체 채팅에서 '봉'을 달라고 부탁하는 경우를 자주 봤다. 여기서 말하는 '봉'이란 리뷰 승인과 동의를 표현하는 엄지척의 애칭이다. 이러한 '봉' 요청 몇 번은 애교로 넘어갈 수 있었지만, 시간이 흐를수록 '봉'을 받아야 다음으로 넘어간다는 암묵적인 인식이 퍼져가는 것을 느낄 수 있었다. 때로는 '봉'을 못받아서 다음 업무를 수행하지 못한다는 말도 들었다. 이러한 방식은 건전한 코드 리뷰를 방해한다. 리뷰와 승인을 받는 과정이 왜곡되기 때문이다. '봉'만 얻으면 다음 단계로 진행할 수 있다는 생각은 다음과 같은 몇 가지 문제를 만든다. 첫째, '봉'만 요청하면 된다는 문화가 정착되면, 형식에 치중하게 만들어서 '봉'을 남발하게되고 결국 최종 코드의 품질을 떨어트린다. 시간이 촉박하다는 이유만으로 리뷰 승..
GitHub Workflow 버전 관리 체계(Version Control System)를 사용하는 것이 어떤 장점을 가질 수 있는 지 그리고 여러가지 도구 중에서 깃(Git)이 어떤 특징과 장점을 가지는 지 살펴봤다. 이번에는 실제 깃을 어떻게 사용하면 좋을 지에 대한 이야기를 하려고 한다. 깃헙 또는 깃허브(GitHub)이라고 부르는 서비스가 있는데, 전 세계의 개발자들이 공동 작업을 위해 자주 사용하고 있다. 깃헙은 소스코드 버전을 관리하는 깃과 협업 문서 도구인 위키(Wiki), 사용자 접근제어 등을 제공하는 프로젝트 통합관리 도구로써 유명하다. 그러면 깃헙을 이용해서 어떻게 공동작업을 진행하는 지 그 절차에 대해 살펴보기로 한다. 깃헙을 이용할 때 크게 두 가지 방법이 있다. 마스터 브랜치(Master Branch)에서 새로..
Asynchronous Code Review 코드 리뷰(Code Review)는 생각보다 어려운 일이다. 사람들끼리 대화를 주고 받아도 협업이 잘 안되는데 글로 공유하면서 협업을 잘 할 수 있을 지 미지수다. 아마도 회의실에 모여서 그림을 그리며 설명하는 편이 훨씬 더 생산적일 것이다. 깃허브(GitHub)에 코드 말고 그림을 한 껏 올려서 리뷰를 한다면 모를까 소스 코드(Source Code)와 댓글로 이루어진 리뷰 과정을 보면 협업을 위한 코드리뷰의 장점에 대해 회의감이 드는 것은 당연하다. 아마도 코드 리뷰의 목적에 대해 이야기한 것을 읽고 공감하는 사람도 있겠지만, 피부에 닿지 않고 멀게 느껴지는 사람도 꽤 많이 있었을 것이다. 그래서 코드 리뷰를 접근하는 방법에 대해 생각해보고 실천해 보면 좋겠다고 생각해서 숙제 검사 이야기와 형식적인 규..

티스토리툴바