올챙이시절 기록소

일단 파일 부터 구합니다 XenServer DownLoad 실습환경으로는 Oracle Virtual Box가 설치되어 있어야 합니다 * Oracle Virtual Box 내 설정사항에 대해서는 따로 설명하지 않습니다 여기 이하부터는 실서버에 설치하는 것과 동일하다 인스톨 첫 화면 엔터를 한 번 쳐줍니다 조금 시간이 걸립니다 키보드 세팅 US로 설정합니다 중요한 데이터는 백업하라고 합니다 없으므로 OK 정책 동의 - Accept EULA 엔터 오라클 가상머신에서 실행하기 때문에 나타나는 경고문 ( 실서버 설치에는 나타나지 않았던 걸로 기억 ) 하드디스크 선택 하나만 있으면 문제가 없습니다 thin provisioning 꼭 체크! ( 1TB 하드지만 10TB 처럼 쓸 수도 있다 ) * 2개 이상인 경우는 ..

Xen을 쉽게 설명하면 1대 컴퓨터를 여러 대처럼 사용하는 기술이다. 핵심은 "하이퍼바이저, 반가상화" 이다 꼭 알아두자. ( Open Source 란 것도 ) Xen은 하이퍼바이저다 Xen은 반가상화 기술이다 * 하이퍼바이저 : 호스트 컴퓨터에서 다수의 운영 체제(operating system)를 동시에 실행하기 위한 논리적 플랫폼(platform) * 전가상화 vs 반가상화 Open Source 기술이며 무료로 쓸 수 있다 ( 유료회원은 자동 업그레이드 및 각종 지원을 받을 수 있긴하다 ) 때는 호랑이가 담배피던 시절 Test 환경으로 Desktop 5대가 있었다 한 대는 윈도우, 세 대는 리눅스 마지막 한 대는 레드마인용 9명의 팀원이 공용으로 같이 쓰다보니 엉망이었다 ( 결함의 원인을 다른 제품 ..

형상관리에는 여러가지 활동이 있는데 그 중 형상항목 식별에 대한 내용이다. SW 개발활동에 산출물 중 어떤 것을 관리할지 선택하는 활동이 "형상항목 식별"이다 * MFO SCM 정책문서중 발췌 ( 지금은 더 관리대상이 많아지고 제외되거나 내부적으로 책임소재가 옮겨간 것들이 있다 ) 시작하는 단계에서는 제품의 소스코드를 관리하자 그 후 빌드스크립트, 메뉴얼, 기획스펙, 디자인스펙 등 관리대상의 저변을 넓혀가면 좋을 것이다 * 필요한 산출물이 없는경우는 담당자에게 요구를 하고 관련 관리방법이나 체제는 만들고 보완해 나가자

아래는 누가봐도 설치파일 Windows에 구동되는 프로그램은 설치가 쉽다 next 버튼 계속 누르다보면 설치완료 ( 설치가 어려우면 고객이 사용치 않으므로 설치의 편의성은 중요하다 ) 이런 Installer 파일을 만들려면 특별한 도구를 사용해야한다. 바로 Inno setup 설치가 쉽다하여 설치파일 만들기가 쉽겠는가 뒤에서 보이지 않는 노력이 있는 것이다~ 그 노력이 무엇인고 하면 파스칼이란 언어를 사용하여 코딩을 해야한다 (때문에 진입장벽이 있다) ( 자세한 사용법은 아래를 참조하자 - 설명할 명분이 없다 명분이 ) ref : http://www.jrsoftware.org/ishelp/ 설치부터~ Inno setup은 설치파일 구하기도 쉽고 과정도 next 버튼만 누르면 끝이다 여기까지만 알아보자. ..

삼국통일의 원을 세우는 유비의 마음으로 버전정책을 수립하게 되었다. 제품은 여러가지 컴포넌트로 구성되어 있고 마찬가지로 각 컴포넌트도 고유한 버전을 가져야 한다. 타산 지석의 기지를 발휘하여 오라클센세는 어떻게 하나 확인 해보았다. 다른 제품과 비교해 보진 않았지만, 역시 최고 존엄이라 생각한다. SQL> select comp_name, version from dba_registry; COMP_NAME VERSION-------------------------------------------------- --------------------OWB 11.2.0.4.0Oracle Application Express 3.2.1.00.12Oracle Enterprise Manager 11.2.0.4.0OLAP ..

소프트웨어 QA업무를 하다보면 프로세스의 결함도 보게된다 ( 기획팀은 없지만 행사 기획팀은 있다 ) 그러다보니 기획에 대한 내용은 신화와 같이 구비전승되며, 개발자가 1등급 국어 추리능력으로 기획자의 의도를 파악한 뒤 구현한다 "버그다" 얘기를 하러가면 스펙입니다 한마디에 깨갱 그 놈의 스펙이 뭐길래?! 스펙을 주세요 누구나 이렇게 말 할 수 있지만 "잘" 쓰여진 스펙은 받기 어렵다. * ref : 소프트웨어 스펙은 왜 쓰기 어려운가 * 바쁘다고 스펙자체를 못 받는 경우도... : 요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다. 그래서 UI Spec에 대해서 어떻게 요구하면 되는가? 스토리보드를 받아야 되는 것이구나라고 생각이 귀결했다. * 기획 관련 용어 & Tools : ref. 한 번쯤 들어봤..

2016년 5월, 형상관리정책을 (열심히) 만들었다 브랜치는 아무렇게나 막쓰고 있던 시점이라 깔끔하게 포기하고! Tag 만으로 다 할 수 있는 시스템을 만들고 위와 같이 규칙을 만들었다. 개발자가 Tag를 달아서 QA에게 보낼 때, 1차적으로 정규표현식으로 거른다. grep -E "${CONF_ITEM}\_[0-9]{6}[\.][0-9]{2}" 이제 오타는 완벽히 거른다 생각했지만! 한 순간의 착각이다 ( 170918.01 -> 270918.01) 이와 같이 날짜를 잘못 기입해서 tag를 달아 보내는 경우가 있다 현 빌드시스템의 로직상에는 이러한 tag값이 굉장히 문제가 된다. ( * 알림도 개판으로 가고, DB에 저장도 안되고 ... ) 따라서 복구작업이 필요하다. 먼저, 문제가 되는 태그를 지워줍니다..

Text가 들어간 문서에 완성이란 글자를 달기가 참 어려운 것 같습니다. 흔한 디자이너 1 ( 디자이너의 완성하고픈 욕망과, 빡침이 엿보인다. ) 흔한 학부생 1( 논문 버전네이밍..! 그나마 나은 듯 ?) 좀 잘하는 기획자 1 ( 최고의 버전네이밍 - 멋지군요. 한수 배웁니다. ) 어떻게 하면 버전을 효율적으로 관리 할 수 있을까? 리서치를 해보면 Git란 단어를 종종 보게 됩니다 Git은 버전관리도구입니다~ ( * 정확히는 형상관리 도구이구요~ ) 뭐하는 녀석인가 한 번 봅시다! "git checkout mfobuild_170918.01" 명령어를 입력하니 파일의 내용이 훅 바꼈습니다! ( 소스코드가 해당 시점으로 변경되었습니다~ 170125.01 -> 170918.01 )( * 개인적으로 자주 사용..

다 잘하고 싶다..!