엘키의 주절 주절

많은 분들이 이사다시피 저는 서버 프로그래머입니다만, 습작이나 오픈 소스로 공개한 SDK등에서 간단한 게임들을 공개해온적이 있습니다. 기본적인 클라이언트 작업 이해도는 있는 편이지만, 실무에서 클라이언트 코딩을 해온 기간은 짧은편이지요. (렌더링을 제외한 로직 구현이나 네트워크 코드를 주로 작성해왔죠. UI와 인게임 코딩은 습작에서 해온게 대다수입니다.) 그런 제가 대략 8개월여간의 유니티를 통한 개발 경험에 대해서 정리해보고자 합니다. 1. 씬과 메타 파일로 인하여, 동시 작업이 어렵다.- 4.x대까지의 유니티는 동시 작업이 불가능한 수준으로 보면 된다. 같은 파일에 대한 동시 작업은 피하는게 좋다. 이를 위한 소통 비용이 반드시 필요한 수준.- 이런 문제로 인하여, 구조상으로 결합도를 낮추려는 노력을..

명언가장 큰 약점은 약점을 보일 것에 대한 두려움이다 - 보쉬에우리는 종종 뭔가 나아지게 하려다가 괜찮은 것 마저 망친다 - 리어왕 지식에 대한 투자가 언제나 최고의 이윤을 낸다 - 벤자민 프랭클린 당신이 가진 생각이 딱 하나밖에 없다면 그것만큼 위험한 것은 없다 - 에밀 사르티에 언어의 한계가 곧 자기 세계의 한계다 - 루트비히 비트겐슈타인 진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다. 과거를 기억하지 못하는 사람은 과거를 반복할 운명이다 - 조지 산타야나 참으로 고통스러운 일입니다. 자신이 겪는 어려움을 보고는 알게 되죠. 다른 누가 만든 게 아니고 바로 자신이 문제를 만들었다는 걸. 소포클래스(아이아스) 상식과 정직만큼 사람을 놀라게 하는 것은 없다 - 랄프 왈도 에머슨 자기 비난에는..

https://nssm.cc/ nssm-2.24.zip rails 서비스화에 사용한 배치 파일 예제입니다. 아주 간단해요.윈도우 서버의 경우 권한 문제에 빠질 수 있는데, 이 경우 아래 링크처럼 대처하세요.http://elky.tistory.com/561 pushd %~dp0@echo off %cd%\nssm.exe install %1 C:\RailsInstaller\Ruby2.1.0\bin\rails.bat "s -p 8000 -e production"%cd%\nssm.exe set %1 AppDirectory %cd% pushd %~dp0@echo off net start %1 pushd %~dp0@echo off net stop %1 pushd %~dp0@echo off net stop %1 nss..

콘솔 프로그램을 service로 등록해주는 instsrv, srvany의 wrapping batch 파일입니다. 사용법은 install.bat "서비스명" "실행파일경로" "인자" uninstall.bat "서비스명" 입니다.

script/rails 파일이 존재하는지와 내용을 확인 해볼 것. 해당 파일에 #!/usr/bin/env ruby.exeAPP_PATH = File.expand_path('../../config/application', __FILE__)require_relative '../config/boot'require 'rails/commands' 위와 같은 정보가 있는데, 이 정보들을 바탕으로 서버를 구동 시키려 하기 때문.

버그는 프로그래머의 숙명이다. 그 섬세하게 만들려한 IOS, OS X에도 버그는 종종 있으며, 사실 많은 사람이 M$라 부르지만 나의 경우는 매우 감사하고 있는 MS의 경우에도 버그는 많다. 구글도 예외는 아니고. (구글 apps 초창기 패치할 때 마다 언어 관련, IME 관련 문제를 겪게 했던 일은 나름 유명한 일화다.) 이러한 회사는 분명히 업계의 엘리트가 모여있을 텐데 어째서 이렇게 버그가 나오는걸까? 어찌보면, 버그는 당연한 숙명이다. 하나의 어플리케이션을 작성하기 위해, 잘 작성된 위지윅 툴을 사용하더라도, 버그가 없다고 단정 지을 수 없다. 하물며, 코드가 들어가고, 각종 코드를 재사용하고, 다른 코드를 얹는 과정에서는 복잡도와 결합도는 증가하고, 당연히 버그가 생길 여지도 많아진다. 자 그렇..

꽤나 많은 상황에서 우리는 기존 코드를 분석해야 한다. 빌드업이라 불리는 프로젝트에 필요한 기능들을 만져나가는 과정에서도 우리는 라이브러리나, 오픈소스 코드등을 통해서 기존 코드를 분석해나가야 한다. 물론 이 과정은 섬세하게 만져나갈 여지가 있고, 그간의 결합도를 조절해나갈 여지가 있으므로 상대적으로 코드 분석의 여지가 적다. 심지어 사용하는 라이브러리들이 익숙하거나, generic하게 구현되어있다면 더더욱이 쉽고. 사실 가장 곤욕스러운 과정은 프로젝트 dependency 한 코드를 분석하게 될 때이다. 이 과정에서, 코드간의 결합도를 낮출려고 노력해온 흔적이 있는 경우는 그래도 상대적으로 쉬운 편에 속한다. 예를 들어 패킷으로만 다른 티어와 통신을하고, 패킷 핸들링 코드가 명확하다면 기존 코드가 난해하..

내가 코드를 작성할 때 신경쓰는 코딩 규약들을 정리해본다. 소유권 객체의 소유 주체는 (생성과 소멸의 관리 주체는) 하나로 규정한다. 객체의 생성,소멸 스레드도 하나로 규정한다. 다른 클래스에서 호출되어야만 하는 메소드를 만들지 말라. Has a 관계가 명확하다면, 이 관계를 혼란 시킬 수 있는 메소드는 절대 만들지 마라. 진입점 진입 점은 명확하게. 한곳으로 관리하자. 만약 다양한 진입 점이 있을 수 밖에 없다면, 다른 각각의 진입 점에서 왔음을 알 수 있게 하라. 중복 중복을 허용하지 말라. 단일 규칙 두 가지 이상의 규칙을 허용하지 말라. 새로운 규칙을 도입하고 싶다면, 기존 규칙대로 작성된 전부를 고쳐라. 두 가지 이상의 규율이 존재하는 것은, 코드 작성/분석 등 모든 과정에서 해가 된다. 전치 ..