'분류 전체보기' 카테고리의 글 목록 (20 Page)

Programming log

이전에 안드로이드 공부하면서 만든 어플 2014.07.22
리눅스 강제 코어 남기기 2014.07.21
New Programming Jargon 2014.07.14
다중패턴검색 알고리즘 2014.07.14
갤럭시 s5 vs 엑스페리아 z2 카메라 비교 (2014-06-18) 2014.06.19

이전에 안드로이드 공부하면서 만든 어플

중년 플머 김씨 2014. 7. 22. 01:03

2014. 7. 22. 01:03

예전 일본에서 한 2~3주 정도 짬짬히 만들어 본 안드로이드 프로그램입니다.

(이미지 저작권 피하려고, 개인적으로 찍은 사진과, 위키의 타로카드 이미지를 사용했었죠 ㅠㅠ)

오랫만에 기억나서 https://play.google.com/apps/publish 로 그동안 통계를 다시 봤는데... 아직 몇몇 분들이 설치해주셔 있군요..

(설치해서 쓰고 있는지, 그냥 설치된채로 버려진 폰인지는... 잘.. ㅠㅠ)

아쉽게도 지금 제 현업은 서버프로그래머라, 그냥 옛날에 안드로이드 공부 했다는거에 의의를 두고 있는 작품입니다.

일본에서 밤 12시에 퇴근해서, 이후 새벽 3시까지 저거 혼자 만들면서 즐거워 한 기억이 있네요 (출근이 10시까지였던게..)

개발 당시 안드로이드 2.3이 주류 였고, (위의 오른쪽 사진 보시면 ㅠㅠ)

NDK나 그런거 없이 순수 Java 안드로이드 API 작성했었습니다.

아마 지금 화면으로 보면 앵크가 깨지고 난리 나지 않았을까 하네요.
하지만 Java , 안드로이드로 뭔가 하나 냈다는거에 의의 두는 앱이였습니다.

평가를 읽어보니 가슴이 아프더군요...
그런데... 저걸 공부하기 위해서, 안드로이드 API 익힐겸 만든거라....퀄리티는 제가 생각해도 많이 떨어져요 ㅠㅠ

저작자표시 비영리 변경금지

'모바일 프로그래밍 > 안드로이드' 카테고리의 다른 글

안드로이드 종료하는 방법 (0)	2011.07.07

리눅스 강제 코어 남기기

중년 플머 김씨 2014. 7. 21. 11:56

2014. 7. 21. 11:56

리눅스에서 프로세스 강제로 죽이면서 코어 남기려면

core 가 생성되게 셋팅하시고(ulimit -c 참고)
kill -SIGSEGV pid 로 강제 시그널을 날려서 core을 남기게 할 수 있습니다.

저작자표시 비영리 변경금지

'리눅스 서버에 대해서' 카테고리의 다른 글

putty 한글 텍스트 붙여넣기 에러 해결하기 (0)	2022.07.12
메모리 보호하는 컴파일러 옵션들... (0)	2014.06.18
[gcc] mudflap - 포인터 접근 검사 (0)	2014.06.18
병렬 프로그래밍 페러다임 (0)	2014.06.18
OpenMP를 이용한 병렬 프로그래밍 (0)	2014.06.18

New Programming Jargon

중년 플머 김씨 2014. 7. 14. 19:36

2014. 7. 14. 19:36

출처 : http://blog.codinghorror.com/new-programming-jargon/

http://www.mimul.com/pebble/default/2012/09/11/1347354933116.html

이 포스트는 Stack Overflow에서 "New programming jargon you coined?"라는 질문을 하고 이에 답한 것들중에 투표를 통해 30개 선별된 것에 대한 설명을 정리한 것입니다.
살펴보니 재미있는 것이 많습니다. 우리나라도 한번 커뮤니티나 페이스북에서 공론화하면 좋을듯 합니다.
아래는 Stack Overflow를 기반으로 해 Coding Horror에서 정리한 포스트("Coding Horror : New Programming Jargon")를 제멋대로 의역해봤습니다. 오역이 있으면 댓글로 의견 부탁드립니다.

1. Yoda Conditions

변수와 상수를 비교할 때는 상수를 왼쪽에 변수를 오른쪽에. 스타워즈의 요다가 "The sky is blue" 대신에 "if blue is the sky" 혹은 "The man is tall" 대신에 "if tall is the man"라고 말하는 것에서 옴.

2. Pokemon Exception Handling

모든 예외는 다 잡아야 한다.

try {
}
catch (Exception ex) {
   // Gotcha!
}

3. Egyptian Brackets

줄 끝에서 중괄호를 여는 스타일. 이집트인 그림 손의 위치가 출처임.

if (a == b) {
    printf("hello");
}

4. Smug Report

시스템 디자인을 설계한 자신보다 더 많은 것을 알고 있다고 생각하는 사용자가 제출한 버그. 관련 단어로 Drug Report, Chug Report, Shrug Report.

5. A Duck

관리에 관심을 끌기 위함이 아니라, 제품의 다른 관점에서 불필요한 변화를 피해기 위해서, 특별한 이유없이 추가된 기능. 결국 그 기능은 없어지게 된다.
아티스트가 어떤 애니메이션(배틀 체스의 여왕 애니메이션) 제작에 참여했을때 변화, 즉 일한 티를 내려고 한 혁신적인 솔루션은 다른 애니메이션에 영향을 주지 않는 선에서 오리 캐릭터를 추가하는 것이었다. 그런데 결국 프로듀서가 리뷰를 하고 나서 "오리를 제거하라"고 한마디를 남겼다.

6. Refuctoring

잘 설계된 코드가 적용되었더라도 작게라도 이것 저것 뒤적거리면 나자신 이외에는 아무도 유지보수 할수 없는 코드가 된다.

7. Stringly Typed

올바른 코드 규칙(강한 타입)을 가지고 코딩을 하면 되는데, 함수의 파라미터를 적절한 타입을 사용하는 것이 아니라 문자열을 나열하는 식으로 코딩을 해, 코드는 이해할 수 없게 되고 심지어 에러를 유발하게 된다.

8. Heisenbug

버그에 대해 연구를(찾을려면) 시작하면 그 특성이 변하거나 사라지는 버그. 출처는 불확정성 원리를 만든 하이젠 베르크에서 옴.

9. Doctype Decoration

웹 디자이너가 doctype 선언문을 추가했지만 유효한 마크업을 작성하려고 신경쓰지 마라.

<!DOCTYPE html>
<BLINK>Now on sale!</BLINK>

10. Jimmy

Jimmy는 우둔한 신입 프로그래머의 이름. 잘 설계된 프레임워크 코드를 참조할 때 "Jimmy 방지"라는 용어를 언급한다.

11. Higgs-Bugson

이벤트 로그 및 모호하고 입증되지 않는 사용자의 보고에 의해 약간의 가능성에 기초한 가상 버그들이 예측한다. 그러나 개발 컴퓨터에서 재현하기가 어렵다.(힉스 입자처럼)

12. Nopping

NOP는 어셈블리의 no operation의미로, 실제 아무 의미없는 명령이지만, 아무것도 안하는 것은 아니다.(NOP)

13. Unicorny

초기 계획 단계이기 때문에, 마치 공상하는 상태처럼 설명되지 않는 기능.

14. Baklava Code

터키의 얇은층이 많은 과자. 너무 많은 레이어를 가진 코드.

15. Hindenbug

Hindenbug호 폭발 사고의 비극인 데이터 손실로 인한 버그(데이터 레이어에서 발생하는 버그). Counterbug와 Bloombug가 관련 있음.

16. Fear Driven Development

몇몇을 해고하거나 일정을 앞당기거나, 자원을 빼는 등이 관리자가 압력으로 행사하는 것.

17. Hydra Code

불사신의 히드라처럼 고칠 수없는 코드. 하나 버그를 고치면 새로운 2개의 버그가 발생한다. 고쳐도 고쳐도 새로운 문제가 나온다.

18. Common Law Feature

잘못하고 있는 것에도 불구하고, 사양의 일부가 되어 버린 버그.

19. Loch Ness Monster Bug

재현 가능성이 없고, 목격자가 1명 밖에 없는 정체 불명의 버그.

20. Ninja Comments

보이지 않는 댓글, 비밀 댓글이나 의견이 없는 것. 즉, 코멘트가 없다.

21. Smurf Naming Convention

모든 클래스에 동일한 프리픽스가 붙어있다. 예로 사용자가 버튼을 클릭하면 SmurfAccountView가 SmurfAccountDTO를 SmurfAccountController에게 전달한다.

22. Protoduction

프로토타입인 채로 세상에 나온 것.

23. Rubber Ducking

문제를 해결하기 위해서 누군가에게 가서 대화와 듣기를 통해 해답을 얻을 수 있다는 생각에 해결책을 찾기 위해 오리 장난감에게 말을 건내는 것.

24. Banana Banana Banana

나중에 채워넣기 위해 임시적으로 적어 놓는 문구. IDE의 경고를 피하기 위해 우선 임시로 적는다.

/// <summary>
/// banana banana banana
/// </summary>
public CustomerValidationResponse Validate()

25. Bicrement

변수에 1을 더하는 대신 2를 더한다.

26. Reality 101 Failure

요구하는대로 움직이고 있지만, 배포될 때 문제가 오해로 밝혀져 쓸모 없는 코드가 되는 것.

27. Mad Girlfriend Bug

분명 이상한 일이 일어나고 있는데도 불구하고 소프트웨어는 문제없다라는 메세지만 남긴다.

28. Megamoth

MEGA MOnolithic meTHod(2천라인 이상의 코드). 두개의 화면에 걸쳐 있는 거대한 객체(소스).

29. Hooker Code

애플리케이션 다운 등을 종종 유발하는 코드.

30. Jenga Code

한 블록 변경하면 전체가 붕괴 할 것 같은 코드.

저작자표시 비영리 변경금지

'프로그램 설계' 카테고리의 다른 글

Subversion 패턴 무시 (0)	2014.08.10
UML - 기본편 ( 기본 표기 형식 및 관계 표현법 ) (0)	2014.06.18
Web에서 그릴 수 있는 (Sequence Diagram) 툴 (0)	2013.04.16
Visual Svn post-commit 에 관해서 (0)	2012.07.31
마인드 맵을 활용하자 (0)	2007.11.11