이 구조적 테스는 black box testing 기술의 대체를 의미하지는 않는다. 

이것은 일종의 White box 또는 code-based testing의 일 부분이라고 할 수 있다.

5.1 The structured testing criterion.

5.4 Structured testing example

□ 분사구문 만드는법

분사구문은 어렵게 생각할 것이 아니라, 

그냥 단순히 부사절이 부사구로 간단하게 변화되어 표현하는 방식이라고 생각하면 됩니다.

위와 같이 분사 구문 만드는법에 보는 봐와 같이 분사구문이리고 부르는 것은 그 부사구가 분사로 

시작되는 문형 구조를 같고 있기 때문입니다.

즉 이렇게 표현할 수가 있습니다.

분사구문 = 분사구 = 부사구

Given의 사용법

분사구문 give의 뜻이 주다 라면 "주어진", "고려된" 으로 해석할 수 있다.

given이 가정형이라면 "~이 주어졌을 때"로 볼 수도 있다.

동격의 that은 명사절 접속사로써의 that이다.

관계대명사 that은 제한적 용법으로 쓰일때의 that이다.

** 자세한 설명 **

목차 : 1. 개념차이 / 2. 구조차이 / 3. 선행사차이 / 4. which로 바꾸기 및 생략여부 / 5. 문법차이

1. 개념 차이

(1) 관계사 that

자! '꽃'과 '빨간 꽃'의 차이는 무언가요?

빨간이란 형용사 수식어가 옴으로써, 범위가 줄어드는 효과가 생깁니다.

꽃 주세요.. 라는 것보다.. 빨간 꽃 주세요 라고 말하면,

점원이 보여줄 수 있는 꽃의 범위가 한정이 됩니다.

그런데, 관계사 that은 형용사절을 이끕니다.

따라서 선행사 뒤에 관계사 that절이 붙어 수식을 하면 범위가 한정되는 느낌이 생깁니다.

item vs item that I want 는 어떤 차이가 있을까요?

그냥 item은 범위가 넓은데,

내가 원하는 item은 범위가 좁겠죠?

(2) 동격의 that

They have the belief that economy will soon get better.

위의 문장을 읽다보면, 아래와 같은 느낌이 납니다.

그들은 믿음이 있는데.. 그 믿음이란 무엇이냐면 바로 다음에 나오는 내용과 같다~~

그들은 믿음이 있는데.. 그 믿음이란 바로 '경제가 금방 좋아진다는 것' 이다.

믿음이란 바로 다음 내용과 같다, 믿음이란 바로 ~~ 이다 에서 수학 기호 =(등호)가 연상되지 않나요?

이 등호의 역할을 that이 하고 있는 것입니다.

belief = economy will soon get better

그래서 동격의 that이라고 합니다.

2. 구조 차이

많은 분들이 알고 있을텐데요~

관계대명사 that절은 불완전한 구조이고,

동격 that절은 완전한 구조입니다.

그렇다면 불완전한 구조란 무엇이고, 완전한 구조란 무엇이냐??

이 것을 이해하려면 문장의 다섯 형식을 모두 잘 알고 있어야 합니다.

기본적으로 문장 구성 요소로서 어떤 것들이 필요한지 알아야.. 거기서 뭐가 빠졌는지 안 빠졌는지 보이고,

그래야 완전한지 불완전한지 판단이 가능하겠죠?

완전 구조, 불완전 구조 구분에 대해서는 다음에 다시 포스팅을 하겠습니다.

일단, that I want는 want의 목적어가 없는 불완전한 구조입니다. 따라서 that은 관계대명사로 판단하며,

that economy will get better는 완전한 구조입니다. 따라서 that은 동격의 that으로 판단합니다.

3. 선행사 차이

관계사 that절의 선행사는 별다른 특징이 없습니다.

그런데 동격 that절의 선행사는 idea, fact, opinion, belief, thought 등등이 자주 옵니다.

아이디어란 무엇이냐면.. 의견이란 무엇이냐면.. 이런 식으로 =(등호)의 느낌이 이어지기에 딱 좋기 때문입니다.

그런데 그렇다고 해서 idea, fact, opinion, belief, thought 뒤에 무조건 동격의 that이 오는 것은 아니니 주의하시고,

일단 idea, fact, opinion, belief, thought 다음에 that이 있다면 동격의 that일 가능성이 크다고 생각만 하시고, 

그 다음 that절의 구조도 살피세요.

4. which로 바꾸기 및 생략 여부

관계대명사 that은

선행사가 사람이라면 who, 사물이라면 which로 바꿀 수 있으며,

that S V 처럼 목적격이라면, that의 생략도 가능합니다.

하지만

동격 that은

who, which 등으로 바꿀 수 없으며, 생략도 불가능합니다.

5. 문법 차이

사실, 영어 활용면에선 중요한 지식은 아닙니다.

문법 학자들이 그렇게 분류한다는 정도로만 알아두세요.

관계사 that절은 형용사절

동격 that의 품사는 접속사, 동격 that절은 명사절

5. DISTRIBUTED OBJECTS AND REMOTE INVOCATION

이 장에서는 분산 객체간의 Remote method invocation에 의한 커뮤니케이션을 소개 한다. Remote method invocation을 받을 수 있는 이러한 객체들은 Remote 객체들에 의해서 호출되어 질수 있으며 remote interface로 구현 되어 질 수 있다. Invoker와 invoked object들의 실패에 독립적이기 때문에 RMI들은 local call들과 다른 의미를 기진다. RMI는 아주 local invocation들과 비슷해 보이지만, 그러나 Total Transparecny는 다르다. Marshalling과 unmarshalling을 위한 코드는 자동으로 interface compiler에 의해서 remote interface의 definition으로부터 생성 되어 진다.

5.1. Introduction

Middleware: Software that provides a programming model above the basic building blocks of processes and message passing is called middleware.

Location transparency: RPC에서 client의 호출은 그것이 같은 process인지 다른 process인지 알 수 없다. 마찬가지로, Client는 server의 location을 알 필요가 없다. 이와 비슷하게 RMI에서도 그것의 invocation이 local인지 또는 location의 위치에 대해서 알 필요가 없다. 분산 환경에서의 event-based 프로그램에서도 이와 마찬가지로 발생된 이벤트의 위치를 알 필요가 없다.

Communication protocols: protocol들은 middleware의 추상화를 transport 프로토콜과 독립적으로 지원 한다. For example, request-reply protocol은 UDP 또는 TCP위에서 구현 되어질 수 있다.

Computer hardware: 이것은 message들을 marshaling하고 unmarshalling 할 때 사용되어 진다. 이것은 하드웨어 아키텍쳐 이기 때문에 감춰져 있다. 에를들면, byte ordering이 있다.

Operating Systems: 높은 레벨의 추상화는 underlying operating system과 독립적으로 middleware에 의해서 제공 된다.

Use of several programming languages: 몇몇 middleware는 분산 어플리케이션이 하나 이상의 programming 언어를 사용할 수 있도록 디자인 되었다. 특히 CORBA는 하나 이상의 언어로 작성되었다. 특히 server의 구성 언어가 다르다. 이러한 것이 가능한 이유는 Interface definition language 또는 IDL이 정의되어 있기 때문이다. IDL은 다음 장에서 논한다.

5.1.1 Interfaces

모듈 사이의 인터렉션을 위해서 명시적으로 interface가 각각의 모듈에 정의가 되어 있다. 모듈의 interface는 procedure들과 variable들로 구성되어 진다. 이것은 다른 모듈로들로부터 접근이 가능하다. Interface를 통해서 접근 가능한 정보를 제외하고 기본적으로 module은 모든 정보를 숨긴다.

Interfaces in distributed system: 분산 프로그램에서 모듈들은 separate process들에서 실행 될 수 있다. 하나의 process에 있는 module에서 다른 process의 모듈로의 직접적인 변수 접근은 가능하지가 않다. 따라서 RPC거나 RMI로 intended 되어 진다. variable들에 대한 direct access를 정의 할 수는 없다. 하지만 CORBA IDL는 interface에서 attribute를 정의할 수 있다. 이것은 룰을 깨트리는것 처럼 보인다. 하지만 attribute들은 직접적으로 접근되어 지지 않는다. 하지만 getter와 setter procedure가 자동으로 interface에 추가되어 이것을 통해서 제어 된다.

Parameter-passing 매커니즘은 하나의 예로 call by value 와 call by referece가 있지만, 이것은 local에서만 적합하고 caller와 procedure가 다른 process들에 있을 경우에는 적합하지 않다. Input 이나 output 혹은 둘다는 분산환경에서의 모듈 인터페이스에 있는 procedure 또는 moethod에 명세되어져 있다.

 분산 환경에서의 remote module에서의 또 다른 특징은 pointer를 사용할 수 없다는 것이다. 따라서 pointer를 이용해서는 결과값을 받아오기 힘들다.

   다음 두개의 패러그램에서는 original client –server에서 사용되는 RPC와 분산 object model에서 사용되는 RMI에서의 interface에 대해서 논한다.

Service interfaces: 클라이언트 서버 모델에서 각각의 서버는 프로지서들의 셋을 제공한다. 이것은 클라이언트에 의해서 사용되어 질수있다. For example, 파일 서버는 파일을 읽고 쓸수 있는 procedure들을 제공 한다. service interface라는 텀은 정의된 input output 아규먼트들로 각각의 프로시저들을 사용할 수 있는 것들을 말한다.

Remote interfaces: Distributed object model에서 remote interface는 object들의 method들로 정의된다. 그것은 invocation이 가능하다 다른 프로세서들에서의 오브젝트들에 의해서, 정의된 input output을에 의해서. 이것이 metohod들과의 큰 차이점은 야규먼트와 결과가 오브젝트를 통과할수 있다는 것이다. 더구나, reference들 또한 그냥 통과댈수 있다. 이것은 포인터 충돌을 발생시키지 않는다. 이것은 상세한 메모리 위치를 참조한다. 

remote interface나 service interface 모두 직접적으로 변수에 접근 하는 것은 아니다. 그것은 object variable들의 인스턴스에 직접적으로 접근 하는 것이 된다. 

Interface definition languages: RMI 매커니즘은 통합되었다 실제적인 프로그래밍 랭기지에, interface 정의를 위해서 충분히 설명이 되어 있다면, Input and output 파라메터들을 랭기지가 가지는 기본적인 사용 파라메터로 일대일 맵핑 시킬 수 있다. Java RMI의 RMI에 대한 예제이며, 이 게념에 객체지향 개념을 추가한 것이다. 이 방법 분산 어플리케이션의 모든 부분에 대해서 같은 랭기지쥐로  사용할때 유용하다. 그것은 local과 remote invocation시 하나의 랭기지로 작성을 할 수 있기 때문에 프로그래머에게 편리함을 재공 한다. 

  하지만, 많은 많은 존재하는 유용한 서비스들은 C++ 그리고 다른 언어로들로 작성되어져 있다.

5.2 Communication between distributed objects

콤마(,)는 전세계 어느 글에서든 나오는 문장 부호입니다.
하지만 영어에서 콤마는 여러 규칙이 있어서 제대로 알고 쓰지 않으면 큰일납니다.

1. 콤마는 문장에서 이어지는 단어들에 쓰이고 마지막 단어에는 쓰이지 않습니다. 

- You are so cleaver, nice, and handsome.

이 문장에서 cleaver, nice, and handsome 이렇게 이어지는데요.
대부분은 nice 와 and 사이에 콤마를 찍지 않습니다. 
그러나 마지막 handsome빼고는 다 찍어야 한답니다. 

그러나 이어지는 단어가 두개라면 찍지 않아도 됩니다.

- I am smart and funny.

2. 콤마는 두 문장이 접속사때문에 연결 될 때 접속사 앞에 씁니다.

- She is nice, and she is hot.

She is nice와  she is hot 은 서로 따로 쓸 수 있는 문장이기 때문에 서로 연결시키려고

and, or, but 를 쓸 때 그 앞에 콤마가 필요합니다.

그러나 

- Mike drinks coffee and eats bread.
위 문장같은 경우, and 앞에 콤마가 쓰이지 않습니다.
그럼 eats 앞에는 주어가 없기 때문입니다.

3. 콤마는 한 문장을 시작하는 종속절 뒤에 사용합니다.

- While she was sleeping, I went outside.

(종속절: 주어와 동사를 가지고 있지만 혼자서 문장이 되지는 못하는 절)

4. 콤마는 문장을 시작하는 긴 구에 쓰입니다.

- Even though the game was not fun, I did not stop playing it.

6. 콤마는 접속 부사를 분리하기 위해 사용합니다.

접속 부사란 however, nevertheless, still, then 등에 해당하는 단어들 입니다.

- It was a beautiful day. However, she was sad.

7. 콤마는 다른 사람에게 직접적으로 내용을 전달할때 전달받는 사람을 분리하기 위해 사용합니다.

- Tom, are you going home?

http://minjang.egloos.com/1148299 

http://iptime.co.kr/bbs/view.php?id=faq_setup&no=525 

공유기 설정은 위의 것을 참조 한다.

1 먼저 USB로 디바이스를 인식한다
2 adb tcpip 명령어로 tcp로 접속할 것을 셋팅한다.
3 adb connect 명령어로 바로 접속한다.
4 adb 명령어를 사용한다. 몽키를 돌리든 시스템을 죽이던 install을 하던 맘대로!!!!!!! USB 없이!!

Adb connect your_ip:port

디바이스의 wifi가 접속되어 있는 상태어야 하고 ip는 디바이스의 ip이다.

Port는 5555 가 기본이고.. adb tcpip 명령어를 통해 port를 바꿀수 있다.

출처: http://sailerya.tistory.com/13 

Android Debugging - ADB over Network

참고 사이트: http://geekyogi.tumblr.com/post/24456172929/android-debugging-adb-over-network 

Android.mk variables

These are the variables that you'll commonly see in Android.mk files, listed alphabetically.

But first, a note on variable naming:

    LOCAL_ - These variables are set per-module. They are cleared by the include $(CLEAR_VARS) line, so you can rely on them being empty after including that file. Most of the variables you'll use in most modules are LOCAL_ variables.

    PRIVATE_ - These variables are make-target-specific variables. That means they're only usable within the commands for that module. It also means that they're unlikely to change behind your back from modules that are included after yours. This link to the make documentation describes more about target-specific variables. Please note that there are a couple of these laying around the tree that aren't prefixed with PRIVATE_. It is safe, and they will be fixed as they are discovered. Sorry for the confusion.

    INTERNAL_ - These variables are critical to functioning of the build system, so you shouldn't create variables named like this, and you probably shouldn't be messing with these variables in your makefiles.

    HOST_ and TARGET_ - These contain the directories and definitions that are specific to either the host or the target builds. Do not set variables that start with HOST_ or TARGET_ in your makefiles.

    BUILD_ and CLEAR_VARS - These contain the names of well-defined template makefiles to include. Some examples are CLEAR_VARS and BUILD_HOST_PACKAGE.

    Any other name is fair-game for you to use in your Android.mk. However, remember that this is a non-recursive build system, so it is possible that your variable will be changed by another Android.mk included later, and be different when the commands for your rule / module are executed.

LOCAL_ASSET_FILES

In Android.mk files that include $(BUILD_PACKAGE) set this to the set of files you want built into your app. Usually:

LOCAL_ASSET_FILES += $(call find-subdir-assets)

This will probably change when we switch to ant for the apps' build system.

LOCAL_CC

If you want to use a different C compiler for this module, set LOCAL_CC to the path to the compiler. If LOCAL_CC is blank, the appropriate default compiler is used.

LOCAL_CXX

If you want to use a different C++ compiler for this module, set LOCAL_CXX to the path to the compiler. If LOCAL_CXX is blank, the appropriate default compiler is used.

LOCAL_CFLAGS

If you have additional flags to pass into the C or C++ compiler, add them here. For example:

LOCAL_CFLAGS += -DLIBUTILS_NATIVE=1

LOCAL_CPPFLAGS

If you have additional flags to pass into only the C++ compiler, add them here. For example:

LOCAL_CPPFLAGS += -ffriend-injection

LOCAL_CPPFLAGS is guaranteed to be after LOCAL_CFLAGS on the compile line, so you can use it to override flags listed in LOCAL_CFLAGS.

LOCAL_CPP_EXTENSION

If your C++ files end in something other than ".cpp", you can specify the custom extension here. For example:

LOCAL_CPP_EXTENSION := .cc

Note that all C++ files for a given module must have the same extension; it is not currently possible to mix different extensions.

LOCAL_NO_DEFAULT_COMPILER_FLAGS

Normally, the compile line for C and C++ files includes global include paths and global cflags. If LOCAL_NO_DEFAULT_COMPILER_FLAGS is non-empty, none of the default includes or flags will be used when compiling C and C++ files in this module. LOCAL_C_INCLUDES, LOCAL_CFLAGS, and LOCAL_CPPFLAGS will still be used in this case, as will any DEBUG_CFLAGS that are defined for the module.

LOCAL_COPY_HEADERS

This will be going away.

The set of files to copy to the install include tree. You must also supply LOCAL_COPY_HEADERS_TO.

This is going away because copying headers messes up the error messages, and may lead to people editing those headers instead of the correct ones. It also makes it easier to do bad layering in the system, which we want to avoid. We also aren't doing a C/C++ SDK, so there is no ultimate requirement to copy any headers.

LOCAL_COPY_HEADERS_TO

This will be going away.

The directory within "include" to copy the headers listed in LOCAL_COPY_HEADERS to.

This is going away because copying headers messes up the error messages, and may lead to people editing those headers instead of the correct ones. It also makes it easier to do bad layering in the system, which we want to avoid. We also aren't doing a C/C++ SDK, so there is no ultimate requirement to copy any headers.

LOCAL_C_INCLUDES

Additional directories to instruct the C/C++ compilers to look for header files in. These paths are rooted at the top of the tree. Use LOCAL_PATH if you have subdirectories of your own that you want in the include paths. For example:

LOCAL_C_INCLUDES += extlibs/zlib-1.2.3

LOCAL_C_INCLUDES += $(LOCAL_PATH)/src

You should not add subdirectories of include to LOCAL_C_INCLUDES, instead you should reference those files in the #include statement with their subdirectories. For example:

#include <utils/KeyedVector.h>

not #include <KeyedVector.h>

There are some components that are doing this wrong, and should be cleaned up.

LOCAL_MODULE_TAGS

Set LOCAL_MODULE_TAGS to any number of whitespace-separated tags. If the tag list is empty or contains droid, the module will get installed as part of a make droid. Modules with the tagshell_$(TARGET_SHELL) will also be installed. Otherwise, it will only get installed by running make <your-module> or with the make all pseudotarget.

LOCAL_REQUIRED_MODULES

Set LOCAL_REQUIRED_MODULES to any number of whitespace-separated module names, like "libblah" or "Email". If this module is installed, all of the modules that it requires will be installed as well. This can be used to, e.g., ensure that necessary shared libraries or providers are installed when a given app is installed.

LOCAL_FORCE_STATIC_EXECUTABLE

If your executable should be linked statically, set LOCAL_FORCE_STATIC_EXECUTABLE:=true. There is a very short list of libraries that we have in static form (currently only libc). This is really only used for executables in /sbin on the root filesystem.

LOCAL_GENERATED_SOURCES

Files that you add to LOCAL_GENERATED_SOURCES will be automatically generated and then linked in when your module is built. See the Custom Tools template makefile for an example.

LOCAL_JAVACFLAGS

If you have additional flags to pass into the javac compiler, add them here. For example:

LOCAL_JAVACFLAGS += -Xlint:deprecation

LOCAL_JAVA_LIBRARIES

When linking Java apps and libraries, LOCAL_JAVA_LIBRARIES specifies which sets of java classes to include. Currently there are two of these: core and framework. In most cases, it will look like this:

LOCAL_JAVA_LIBRARIES := core framework

Note that setting LOCAL_JAVA_LIBRARIES is not necessary (and is not allowed) when building an APK with "include $(BUILD_PACKAGE)". The appropriate libraries will be included automatically.

LOCAL_LDFLAGS

You can pass additional flags to the linker by setting LOCAL_LDFLAGS. Keep in mind that the order of parameters is very important to ld, so test whatever you do on all platforms.

LOCAL_LDLIBS

LOCAL_LDLIBS allows you to specify additional libraries that are not part of the build for your executable or library. Specify the libraries you want in -lxxx format; they're passed directly to the link line. However, keep in mind that there will be no dependency generated for these libraries. It's most useful in simulator builds where you want to use a library preinstalled on the host. The linker (ld) is a particularly fussy beast, so it's sometimes necessary to pass other flags here if you're doing something sneaky. Some examples:

LOCAL_LDLIBS += -lcurses -lpthread

LOCAL_LDLIBS += -Wl,-z,origin

LOCAL_NO_MANIFEST

If your package doesn't have a manifest (AndroidManifest.xml), then set LOCAL_NO_MANIFEST:=true. The common resources package does this.

LOCAL_PACKAGE_NAME

LOCAL_PACKAGE_NAME is the name of an app. For example, Dialer, Contacts, etc. This will probably change or go away when we switch to an ant-based build system for the apps.

LOCAL_PATH

The directory your Android.mk file is in. You can set it by putting the following as the first line in your Android.mk:

LOCAL_PATH := $(my-dir)

The my-dir macro uses the MAKEFILE_LIST variable, so you must call it before you include any other makefiles. Also, consider that any subdirectories you inlcude might reset LOCAL_PATH, so do your own stuff before you include them. This also means that if you try to write several include lines that reference LOCAL_PATH, it won't work, because those included makefiles might reset LOCAL_PATH.

LOCAL_POST_PROCESS_COMMAND

For host executables, you can specify a command to run on the module after it's been linked. You might have to go through some contortions to get variables right because of early or late variable evaluation:

module := $(HOST_OUT_EXECUTABLES)/$(LOCAL_MODULE)

LOCAL_POST_PROCESS_COMMAND := /Developer/Tools/Rez -d __DARWIN__ -t APPL\

       -d __WXMAC__ -o $(module) Carbon.r

LOCAL_PREBUILT_EXECUTABLES

When including $(BUILD_PREBUILT) or $(BUILD_HOST_PREBUILT), set these to executables that you want copied. They're located automatically into the right bin directory.

LOCAL_PREBUILT_LIBS

When including $(BUILD_PREBUILT) or $(BUILD_HOST_PREBUILT), set these to libraries that you want copied. They're located automatically into the right lib directory.

LOCAL_SHARED_LIBRARIES

These are the libraries you directly link against. You don't need to pass transitively included libraries. Specify the name without the suffix:

LOCAL_SHARED_LIBRARIES := \

    libutils \

    libui \

    libaudio \

    libexpat \

    libsgl

LOCAL_SRC_FILES

The build system looks at LOCAL_SRC_FILES to know what source files to compile -- .cpp .c .y .l .java. For lex and yacc files, it knows how to correctly do the intermediate .h and .c/.cpp files automatically. If the files are in a subdirectory of the one containing the Android.mk, prefix them with the directory name:

LOCAL_SRC_FILES := \

    file1.cpp \

    dir/file2.cpp

LOCAL_STATIC_LIBRARIES

These are the static libraries that you want to include in your module. Mostly, we use shared libraries, but there are a couple of places, like executables in sbin and host executables where we use static libraries instead.

LOCAL_STATIC_LIBRARIES := \

    libutils \

    libtinyxml

LOCAL_MODULE

LOCAL_MODULE is the name of what's supposed to be generated from your Android.mk. For exmample, for libkjs, the LOCAL_MODULE is "libkjs" (the build system adds the appropriate suffix -- .so .dylib .dll). For app modules, use LOCAL_PACKAGE_NAME instead of LOCAL_MODULE. We're planning on switching to ant for the apps, so this might become moot.

LOCAL_MODULE_PATH

Instructs the build system to put the module somewhere other than what's normal for its type. If you override this, make sure you also set LOCAL_UNSTRIPPED_PATH if it's an executable or a shared library so the unstripped binary has somewhere to go. An error will occur if you forget to.

See Putting modules elsewhere for more.

LOCAL_UNSTRIPPED_PATH

Instructs the build system to put the unstripped version of the module somewhere other than what's normal for its type. Usually, you override this because you overrodeLOCAL_MODULE_PATH for an executable or a shared library. If you overrode LOCAL_MODULE_PATH, but not LOCAL_UNSTRIPPED_PATH, an error will occur.

See Putting modules elsewhere for more.

LOCAL_WHOLE_STATIC_LIBRARIES

These are the static libraries that you want to include in your module without allowing the linker to remove dead code from them. This is mostly useful if you want to add a static library to a shared library and have the static library's content exposed from the shared library.

LOCAL_WHOLE_STATIC_LIBRARIES := \

    libsqlite3_android

LOCAL_YACCFLAGS

Any flags to pass to invocations of yacc for your module. A known limitation here is that the flags will be the same for all invocations of YACC for your module. This can be fixed. If you ever need it to be, just ask.

LOCAL_YACCFLAGS := -p kjsyy

Implementation Details

You should never have to touch anything in the config directory unless you're adding a new platform, new tools, or adding new features to the build system. In general, please consult with the build system owner(s) (android-build-team) before you go mucking around in here. That said, here are some notes on what's going on under the hood.

Environment Setup / buildspec.mk Versioning

In order to make easier for people when the build system changes, when it is necessary to make changes to buildspec.mk or to rerun the environment setup scripts, they contain a version number in the variable BUILD_ENV_SEQUENCE_NUMBER. If this variable does not match what the build system expects, it fails printing an error message explaining what happened. If you make a change that requires an update, you need to update two places so this message will be printed.

    In config/envsetup.make, increment the CORRECT_BUILD_ENV_SEQUENCE_NUMBER definition.

    In buildspec.mk.default, update the BUILD_ENV_SEQUENCE_DUMBER definition to match the one in config/envsetup.make

The scripts automatically get the value from the build system, so they will trigger the warning as well.

Additional makefile variables

You probably shouldn't use these variables. Please consult android-build-team before using them. These are mostly there for workarounds for other issues, or things that aren't completely done right.

LOCAL_ADDITIONAL_DEPENDENCIES

If your module needs to depend on anything else that isn't actually built in to it, you can add those make targets to LOCAL_ADDITIONAL_DEPENDENCIES. Usually this is a workaround for some other dependency that isn't created automatically.

LOCAL_BUILT_MODULE

When a module is built, the module is created in an intermediate directory then copied to its final location. LOCAL_BUILT_MODULE is the full path to the intermediate file. See LOCAL_INSTALLED_MODULE for the path to the final installed location of the module.

LOCAL_HOST

Set by the host_xxx.make includes to tell base_rules.make and the other includes that we're building for the host. Kenneth did this as part of openbinder, and I would like to clean it up so the rules, includes and definitions aren't duplicated for host and target.

LOCAL_INSTALLED_MODULE

The fully qualified path name of the final location of the module. See LOCAL_BUILT_MODULE for the location of the intermediate file that the make rules should actually be constructing.

LOCAL_REPLACE_VARS

Used in some stuff remaining from the openbinder for building scripts with particular values set,

LOCAL_SCRIPTS

Used in some stuff remaining from the openbinder build system that we might find handy some day.

LOCAL_MODULE_CLASS

Which kind of module this is. This variable is used to construct other variable names used to locate the modules. See base_rules.make and envsetup.make.

LOCAL_MODULE_NAME

Set to the leaf name of the LOCAL_BUILT_MODULE. I'm not sure, but it looks like it's just used in the WHO_AM_I variable to identify in the pretty printing what's being built.

LOCAL_MODULE_SUFFIX

The suffix that will be appended to LOCAL_MODULE to form LOCAL_MODULE_NAME. For example, .so, .a, .dylib.

LOCAL_STRIP_MODULE

Calculated in base_rules.make to determine if this module should actually be stripped or not, based on whether LOCAL_STRIPPABLE_MODULE is set, and whether the combo is configured to ever strip modules. With Iliyan's stripping tool, this might change.

LOCAL_STRIPPABLE_MODULE

Set by the include makefiles if that type of module is strippable. Executables and shared libraries are.

LOCAL_SYSTEM_SHARED_LIBRARIES

Used while building the base libraries: libc, libm, libdl. Usually it should be set to "none," as it is in $(CLEAR_VARS). When building these libraries, it's set to the ones they link against. For example, libc, libstdc++ and libdl don't link against anything, and libm links against libc. Normally, when the value is none, these libraries are automatically linked in to execu

시간이 중요하다.

결국 경과시간과 CPU시간은 다르다.

CPU 시간 = CPI * 명령어 수 * CPU 클럭 이다.

컴퓨터의 성능을 비교하는 기준으로 MIPS를 사용하는데는 세 가지 문제가 있다.

1) MIPS는 단순히 명령어를 실행하는 속도를 나타낼 뿐이지, 그 명령어 하나가 얼마나 많은 일을 수행하는지는 반영하지 못한다. 

명령어의 집합이 다르면 명령어 개수가 달라지기 때문에 단순히 MIPS 값으로만 성능을 비교할 수는 없다.

2) 같은 컴퓨터에서도 어떤 프로그램을 실행하느냐에 따라 MIPS값은 달라진다. 그러므로 컴퓨터의 MIPS 값은 하나가 아니다.

3) MIPS가 컴퓨터 성능과 정반대로 나타나는 경우가 있다는 것이다.(FALSE)가 존재한다.

인스트럭션을 많이 실행한다고해서 실행시간이 빨라지는것은 아니기 때문이다.

실행시간이 20 초인게 350MIPS

실행시간이 30초인게 400MIPS

위와 같을 수 있다.

즉

인스트럭션은 아래의 것이 훨씬더 많이 실행하지만, 그래봐야 느리다는것이다.

근본적인 이유는 instruction은 모두 실행시간이 다 다르다. pipeline stall이나 cache miss와 같은 이유에서, 또한 MIPS는 프로그램마다 다르게 측정 되기 때문이다.

따라서 2개의 컴파일러를 비교할때 결국 다르고, 컴파일러가 다르면 같은 컴퓨터에서라도 제대로 측정이 안된다.

요점 정리

성능을 종합하는 측도라면 반드시 실행시간을 반영 해야 한다. 가중 산술평균은 실행 시간을 잘 반영하는 성능 측도이다. 각 프로그램의 실행시간이 다르더라도 가중치를 사용하면 모든 프로그램이 같은 비율로 반영되게 할 수 있다.

참고사이트: Wikipedia

Cyanogen Mode Full Update Guide Site

<CWM 모드를 Nexus-one에 설치하는 방법이 나와 있다.>

http://wiki.cyanogenmod.org/wiki/Nexus_One:_Full_Update_Guide 

<cyanogen mod 7을 받아서 nexus one으로 compile 하는 방법>

http://wiki.cyanogenmod.org/wiki/Nexus_One:_Compile_CyanogenMod_(Linux) 

http://dlwpals001.blog.me/60154562600

위 방법을 모두 충실히 따라 해야한다.

RomManager도 설치를 해야 한다. 그래야 build option에 passion이 나온다.

extract.sh를 꼭 실행해서 .so 파일을 모두 추출 해야 한다.

< compile시 문제가 생긴다. 카메라 공유 라이브러리 관련해서 >

참조사이트: http://forum.cyanogenmod.org/topic/35075-qundefined-reference-to-opencamerahardware-on-cm7/

핵심 수정사항

The provided solution to set "USE_CAMERA_STUB := false" in device/htc/passion/BoardConfig.mt did not work for me. However I found the config-file device/htc/passion-common/BoardConfigCommon.mk which contains an option BOARD_USE_FROYO_LIBCAMERA which was set to true. So I assume it expected an outdated libcamera (from FroYo release), but my libcamera.so was already updated and on GIngerbread level. So setting this option tofalse, running make clean and re-starting the build succeeded!

Confirmed.
I had the same problem in my ViewSonic.

Solved by:
cd home/lior/android/system/device/malata/smb-common/
gedit BoardConfigCommon.mk 
And setting:
BOARD_USE_FROYO_LIBCAMERA to false

위와 같이 3군대를 false로 변경하면 정상적으로 컴파일이 이루워 지게 된다.

self

클래스에서 유효 범위가 생성되지 않는 점은 파이썬이나 C++나 자바와 다른 점 중 하나이다.

C++나 자바를 써본 적이 있으면 파이썬의 self 매개변수를 this 포인터와 같다고 생각하면 된다.

파이썬에서는 변수를 명시적으로 선언할 수 있는 방법(즉, C에서 int x나 flot y 같은 선언)이 없기 때문에 self를 써주어야 한다. 그렇지 않으면 메서드에서 변수에 값을 대입할 때 이 값이 지역 변수에 대입되어야 하는 지 인스턴스 속성에 저장되어야 하는지 알 수 있는 방법이 없다. self를 직접 써줌으로써 이 문제를 해결한다. Self에 저장되는 값은 모두 인스턴스의 일부가 되고 나머지는 모두 지역 변수에 저장 된다.

3장 타입과 객체

파이썬은 특이하게도 세미콜론(;) 따위의 것들을 사용하지 않는다.

따라서 줄 바꾸기를 매우 잘 해주어야 구문해석이 정확하게 진행되어 진다.

문서화 문자열

def fact(n):

"This function computes a factorial"

if (n <= 1): return 1

else: return n * fact(n-1)

fact.__doc__ 하면

This function computes a factorial"가 출력 된다.

우선 파이썬에서 한글을 쓰기 위해서는

#coding: euc-kr

위 문법을 맨위에 삽입해 준다.

문자열

+연산은 오로지 문자열만 연결한다.

수리 계산은 init(), float() 함수로 반드시 변환해야 한다.

z = init(x) + init(y)

str()

print시 문자열 변환 함수: str()는 3.4입력시 3.4가 나온다.

repr()

print는 문자열 변환 함수: repr()는 3.4입력시 3.39999가 나온다.

format()

foramt은 정해진 ofrmat으로 출력을 한다.

format(x,"0.5f ")

리스트(List)

names = ["a", "b", "c", "d"]

a = names[2]

names.append("Paula") # 리스트 가운데의 항목을 교체 한다.

b = names[0:2]

리스트 연결시 플러스(+)연산자를 사용 한다.

빈 리스트 생성

names = []

names = list()

튜플(tuple)

stock = ('GOOG', 100, 490.10)

stock = 'GOOG', 100 ,490.10

튜플과 리스트의 가장 큰 차이점은 한번 정의되면 수정 되어질 수 없다는 것이다.

하지만 성능 최적화를 위해서는 튜플을 사용하는것이 더 좋다.

왜냐하면 튜플은 수정이 되지 않기 때문에 over memory alloacate를 하지 않는다.

List와 Tuple의 코드상에서 구분하는 방법은 대괄호와 소괄호의 차이점으로 구별 한다

튜플과 리스트를 함께 사용하는 예제)

집합(set)

집합은 객체들의 순서 없는 모음을 담는데 사용된다. 집합은 다음과 같이 set()함수에 일련의 항목들을 넘겨 주어 생성 한다.

s = set ([3,5,9,10])

리스트나 튜플과는 달리, 집합은 순서가 없기 때문에 숫자로 색인될 수 없다. 게다가, 집합은 요소가 중복되는 일이 없다.

즉, t = set("Hello")

set(['H','e','l','o']) 이와 같이 l이 한번만 나타나게 되는 것이다.

집합 연산자를 사용 할 수 있다.

또한 집합에 아이템이 추가될수도 삭제될 수도 있다.

add()

update()

remove()

사전(dictionary)

사전은 키로 색인되는 객체들을 담는 연관 배열 혹은 해시 테이블이다.

다음과 같이 값들을 중괄호({})로 둘러싸서 사전을 생성 한다.

stock = {

"name" : "GOOG",

"shares" : 100,

"price" : 490.10

}

키로 접근해서 자료를 꺼내오거나 갱신 한다.

객체 추가 및 수정은

stock["shares"] = 75

stock["date"] = "June 7, 2007"

주로 문자열이 키로 사용되지만, 숫자나 튜플 같은 다른 파이썬 객체도 키로 사용될 수 있다.

사전은 이름 있는 필드들로 구성되는 객체를 정의하는 데 유용하게 쓰인다.

하지만, 사전은 순서 구분 없는 데이터를 빠르게 검색하기 위한 용도의 컨테이너로도 사용 된다.

빈사전을 만드는 방법

prices = {}

prices = dict()

사전에 어떻게 키가 들어있는지 확인 하는 방법

1) 방법 in 연산자의 활용

if "SCOX" in prices:

p = prices["SCOX"]

else:

p = 0.0

2) 방법

p = prices.get("SCOX",0.0)

사전의 키 목록을 얻고 싶으면 사전을 리스트로 변환하면 된다.

syms = list(prices)

# syms에는 "AAPL", 등..이 연속해서 저장되어진다.

del prices["MSFT"]

사전은 파이썬의 꽃이다. 따라서 이것을 잘 사용하는것이 좋다.

반복과 루프

for를 이용해서 가장 간단하게 루프를 도는 형태는 간단히 문자열, 리스트, 튜플 같은 순서열의 모든 구성요소에 대해 루프를 도는 것이다. 다음은 한 예이다.

함수

다음 예처럼 함수는 def문을 사용해 생성한다.

특이한점

리턴이 2개 이상일 수 있다.

return (a,b)

a,b = func()

인자의 초기 값이 있을 수 있다.

저역 변수를 수정 할 때에는 global이라는 keyword를 사용 한다.

생성기

함수는 단일 값을 변환하는 대신, yield문을 사용해 일련의 결과 값을 생성할 수도 있다.

yield를 사용하는 함수를 생성기(generator)라고 부른다. 생성기 함수를 호출하면, next() 메서드를 호출 하면 일련의 결과를 반환하게 된다.

생성기는 처리 파이프라인, 스트림, 데이터 흐름에 기반한 프로그램을 작성할 때 강력한 위력을 발휘 한다. 예를 들어, 다음 생성기 함수는 로그 파일을 검토하는 데 흔히 사용되는 유닉스의 tail -f 명령의 동작을 흉내낸다.

리눅스 명령어중 grep을 흉내낸 파이썬 코드이다.

리눅스 명령어 "tail -f | grep python"를 구현 하겠다.

즉 2개의 generatior를 연결 시켜서 리눅스의 파이프라인을 구현한 간단한 예이다.

코루틴

보통 함수는 입력으로 주어진 인수에 대해서 한 번만 실행된다. 하지만, 일련의 입력을 처리하도록 함수를 작성할 수도 있다. 이런 종류의 함수를 coroutine이라고 한다.

yield는 그냥 쓰면 generator이지만, ()를 양 옆에 달게 되면 coroutine이 된다.

 코루틴은 send()로 값이 도착할 때까지 멈춰 있는다.

send()가 호출되면, 코루틴 안에서 yield 표현식을 만날 때까지 계속되고, 그 순간 함수가 다시 멈춘다.

앞의 예에서 보았듯이, 이 과정은 close()가 호출될 때까지 이어진다.

코루틴은 프로그램의 한 곳에서 생성된 데이터를 다른 곳에서 소비하는 생성자 소비자 모델이 기반한 병행 프로그램을 작성할 때 유용하게 쓰인다. 이 모델에서 코루틴은 데이터 소비자의 역할을 수행한다. 다음은 생성기와 코루틴을 결합하는 예이다.

객체와 클래스

객체에 정의된 메서드를 살펴 보고 싶을 경우

dir(object)를 하면 알 수 있다.

이렇게해서 메서드를 확인할 경우 __메서드__ 와 같이 이중 언더바로 시작하고 끝나는 특수한 메서드들을 볼 수 있다.

C++ / java 프로그래밍에서 쓰는 정적 메서드 또한 사용 할 수 있다.

@staticmethod

예외

try이와 except문으로 예외를 잡아서 처리 할 수 있다.

IOError가 발생하면, 에러의 원인에 대한 내용이 e에 담기고 except 블록으로 제어가 넘어간다.

모듈

프로그램 크기가 커지면 손쉬운 관리를 위해 프로그램을 여러 파일로 나누고 싶어 질 것이다.

파이썬에서는 정의들을 파일에 넣어 다른 프로그램이나 스크립트에 Import할 수 있는 모듈의 형태로 사용할 수 있다.

모듈을 생성하려면 관련문장과 정의들을 모듈과 동일한 이름을 가지는 파일에 넣으면 된다.

도움

위와 같이 입력하면 해당함수의 사용법을 알 수 있다.

□ 원격 저장소를 이용하여 작업하기

이번에는 원격 저장소의 프로젝트와 상호작용하는 방법을 다루게 될 것이다.

어떠한 형태의 원격 저장소가 있는가?

어떻게 원격 저장소 복사본을 생성하는가?

어떻게 원격 저장소의 변경 사항을 가져와 최신 상태로 유지하는가?

어떻게 자신의 변경 사항을 푸싱하여 원격 저장소에 공유하는가?

어떻게 원격 브랜치와 작업하는가?

어떻게 새로운 원격 저장소를 추가 하는가?

□ 네트워크 프로토콜

Git는 SSH, git, HTTP/HTTPS 이렇게 3개의 프로토콜로 원격 저장소와 통신을 하게 된다.

□ SSH(Secure Shell)

git@github.com/tswicegood/mysite-chp6.git

git는 사용자 명이다.

github.com은 서버이름이다.

맨마지막은 저장소의 경로를 의미한다.

□ git

속도를 위해서 설계되어진 전용 프로토콜이다.

주로 read only로 저장소를 공유할 때 사용 한다.

하지만 네트워크 9418번 port를 사용하기 때문에 방화벽으로 인해서 막히는 현상이 자주 발생 한다.

git://github.com/tswicegood/mysite-chp6.git

SSH와 가장큰 차이점은 git가 사용자 아이디가 아니라, 그냥 git 프로토콜을 나타내는 접두어 git일 뿐이라는 것이다. 즉 임의의 사용자의 접근을 허용한다는 의미이다. 따라서 읽기전용만 된다는 것이다.

□ HTTP/HTTPS

최후의 수단이다. 따라서 느리고, 네트워크에 부담도 많이 준다.

하지만 방화벽 문제는 거의 발생시키지 않는다. well-known port를 사용하기 때문이다.

http[s]://github.com/tswicegood/mysite-chp6.git

□ 원격 저장소 복제하기

git clone [저장소 주소]

복제 명령어 clone을 통해서 생성된 복사본은 git init으로 직접 생성한 저장소처럼 동작 한다.

□ 변경이력을 최신으로 만들기

방법 1) 아직 미완성

git fetch // branch의 이력을 최신으로 업데이트한다.

fetch를 실행하면 지역 저장소의 원격 브랜치가 갱신된다. 즉 -r이나 -a를 해서 보면 목록이 갱신된것을 볼 수 있다. 하지만 이때, 지역 브랜치에 가져온 원격 브랜치의 변경 사항들은 merge 되지 않는다. 즉 변강사항들이 반영되지 않는다는 말이다.

git branch -r // r option은 remote branch의 목록을 보는것이다.

아직 불안전한 방법이다.

방법 2) 완성된 방법

그러닌까 pull은 원격저장소의 내용을 현재 branch로 합병 시켜버린다.

만약 원격 저장소의 이름이 origin/next라고하면

git pull origin next 이렇게해야한다.

'/'를 쓰면 안된다.

pull을 반영 시킬 현재 브랜치를 설절하고 싶다면 <참조>를 이용한다.

즉, git pull이란 아래의 명령어를 사용한 효과와 동일하다.

□ 변경 사항 푸싱하기

매개 변수 없이 실행하면, origin 저장소에 푸싱한다고 생간한다. 또한 지역 저장소의 현재 브랜치를 원격의 같은 이름의 브랜치에 푸싱한다고 여긴다. 이때, 원격 저장소에 같은 이름의 브랜치가 존재해야한다.

사용 형태는 pull과 비슷하다. pull을 이해했다면 모든것을 반대로만 생각해주면 쉽게 사용 할 수 있다.

android source code를 작업하려고 할 때 어쩔수 없이 Repo와 Git를 이용해야할 것이다.

즉, 안드로이드의 경우 많은 프로젝트들이 합쳐진 형태이다. 따라서 git가 1개만 쓰인것이 아니라. 매우 많이 쓰인것이다. 따라서 이러한 서로 흐터져 있는 저장소의 코드를 받아오기위해서 repo를 이용하게 된다.

repo의 정채는 그냥 git 명령어를 조합해서 실행하는 Pthyon 프로그램이다.

이렇게 Android Open source Project를 모두 다운 받은 다음에는 git와 repo를 사용해서 소스코드를 관리해야한다. 여기서 중요한것은 git은 각각의 프로젝트에 맞게 설정되어 있다는 것이다

무슨 말이냐하면

system, build .. 이런 각각의 디렉터리가 프로젝트가 된다.

필자의 경우 모든 프로젝트를 git 하나로 관리해보려고 했으나, 속도문제도 있고, commit이 잘 안되는 문제가 발생 했다.

그래서 그냥 기존에 있는 git의 구조를 사용하기로 했다. 이 글을 보는 사람도 그렇게 할 것을 추천 드린다.

그런 의미에서 구글에서 설명한 Version Corntorl 문서를 정리해 보도록 한다.

대부분의 경우에 대해서 Repo 대신에 Git를 사용할 수 있다. 또한 복잡한 Command들에 대해서는 Repo와 Git를 혼용해서 사용할 수 있다.

하지만 basic한 작업에 대해서는Repo만을 사용하는 것이 당신의 작업을 보다 간단하게 만들 것이다.

Git : open-source-version-control을 위한 시스템으로 이것은 아주 큰 프로젝트를 관리하기 위해서디자인 되어졌다.

우리는 Android context에 대해서 git의 local opertion들을 사용한다. 예를 들면, branching, commits, diffs, edits이다.

android project를 셋업 하는데의 하나의 도전적 과제는안드로이드 프로젝트를 어떻게 쉽게 배포하는가 이다. 이것을 위해서GIT를 선택 했다.

Repo : 이것은 repository management tool이며, 이것은 GIT위에서 개발 되었다.

Repo는 많은 Git Repository들을 통합했다. 즉, Android project는 여러 개발 프로젝트가 통합된 것이기 때문에 서로 다른 Git Repository가 사용되어져 왔다.

그리고 repo를 통해서 우리의 Revision Contro System으로 upload 되어 진다.

이것은 필요에 따라 Git repositroies들을 통합한다. 개발 작업 흐름과 같은것들을 자동으로 관리할 수 있다.

Repo는 Git를 대신하는것이 아니다. 그것은 단지 GIT를 이용해서 Android 프로젝트를 좀 더 쉽게 관리하기 위해서 만들어진 것이다.

repo 명령어들은 Pythonscript들을 실행하는 것이다.

Repo command를 이용해서download file을 multiple 저장소에서 할 수 있다.

Gerrit : 이것은 git를 사용하는 프로젝트에대한 웹 기반의 코드 리뷰 시스템이다. Gerrit는 권한히있는 사용자가 submit 변경 Git를 통해서 집중화 하는 것을 장려한다. 이것은 코드 리뷰가 통과한경우 자동으로 병합되어 진다. 게다가 Gerrit는 뭐 뭐가 변경 되었는지 브라우저를 통해서 귑게 알 수 있게 한다.

Basic Workflow

저장소화 인터렉팅 하는 기본적인 패턴은 다음과 같다.

1) repo start 명령어를 이용해서 새로운 branch를 생성한다.

2) file을 추가하거나 수정을 한다.

3) git add를 사용해서 변화를 스테이징 한다.

4) git commit을 이용해서 스테이징된 것을 commit 한다.

5) repo upload를 통해서 변화된 정보를 server로 보낸다.

Task reference

Synchronizing your client

원격 저장소와 클라이언트 작업 디렉터리를 모든  Project들에 대해서 동기화 시킨다.

>repo sync

선택적인 프로젝트만 동기화 시킨다.

>repo sync project_name

Creating topic branches

언제든지 로컬 작업 공간에 변화를 주고자 할 때 새로운 이슈를 저장하고 있는 Branch를 생성한다.

 이렇게 생성된 각각의 branch들은 고립되어져 있다.

> repo start BRANCH_Name

새로 생성한 branch를 확인 하는 방법

>repo status

브랜치에 특별한 프로젝트의 내용을 담을 수도 있다.

> git start BRANCH_NAME Project

특정 브랜치로 이동하는 방법

> git checkout BRANCH_NAME

현재 존재하는 Branch들을 확인 한다.

> git branch or repo branches

Note: A bug might be causing repo sync to reset the local topic branch. If git branch shows * (no branch) after you run repo sync, then run git checkout again.

Stating files

commit하기전에 스테이징 작업을 해야한다.

즉 어떤 버퍼에 커밋할 파일을 등록 해주는 작업이다. 불필요해 보이지만 꼭 필요한 작업이다.

>git add

파라메터로는 파일 또는 디렉터리를 받는다.

그리고 스테이징 되어진 파일은 삭제될 수도 있고 수정 될 수도 있다.

Viewing client status

작업 공간에서의 파일들의 상태를 볼 수 있다.

> repo status

커밋 되지 않은 파일과 HEAD의 파일을 비교해서 차이점을 보여 준다.

repo diff

cd ~/WORKING_DIRECTORY/PROJECT

git diff --cached

이것은 즉, 안드로이드 플랫폼 소를 몽땅 다 받으면 그 하나하나의 디렉터리가 프로젝트가 된다.

즉, 그 디렉터리 안에가면 .git가 또 있다.

--cached 옵션은 스테이징 영역과 저장소의 차이점을 보여 준다.

그냥 git diff하면 작업트리와 스테이징 영역과의 차이점을 보여준다.

저장소(HEAD) // 스테이징 // 작업트리

이렇게 3개의 구조로 되어 있을 것이다.

committing changes

commit 이라는 것은 revision control system에서 아주 기초적인 명령이다.

git에서 commit은 간단하게 실행 할 수 있다.

> git commit

만약 do not add a log message가 나온다면 commit은 거부 된것이다.

새로 추가되어저야할 파일은 스테이징 한다음 commit을 해야 한다.

Uploading changes to Gerrit

업로딩 이전에 가장 최신 버전의 revision들로 업데이트 하자.

>repo sync

그다음 실행한다.

repo upload

이 변화 모록들은 이 때까지 commit을 헀었던 것들이다.

review server로 업로드할 branch를 선택 하여야 할 것이다.

□ Recovering sync conflicts

만약 repo sync가 충돌 현상을 보인다면

status code =U, 즉 파일들이 합병되지 않는 상태를 보이는 것이다.

충돌 지역의 수정이 절대적으로 필요 하다.

일단 관련 프로젝트 디렉터리로 가서 변경을 해야하는데,

그 곳에 있는 git의 기능을 최대한 활용 하자.

즉 파일을 추가하고

commit을 하고

rebase --continue를 한다. 예제는 다음과 같다.

> git add .

> git commit

> git rebase --continue

rebase가 완료되면 repo sync를 다시 한다.

□ Cleaning up your client files

변경된 부분을 통합해 준다.

repo sync

안전하게 추가된 branch들을 제거 한다.

repo prune

□ Deleting a client

> rm -rf

□ Git and Repo cheatsheet 

□ Repo command reference

repo 명령어 사용의 기본적인 패턴은 아래와 같다.

일단 Repo가 설치되어 있다면 도움말 명령어를 실행 할 수 있다.

repo의 많은 명령어들은 Project 이름을 아규먼트로 받고 있다.

이것은 특별한 project의 이름 일 수도 있고, 아니면 로컬 디텍터리의 프로젝트 경로를 입력해도 된다.

repo의 커맨드 종류

abandon

branch

branches

checkout

cherry-pick

diff

download

grep

init

repo를 현재 디렉터리에 설치 한다. git 저장소를 위한 repo 소스코드와 Standard Android Manifest.files를 담고 있는 .repo를 현재 디렉터리에 생성 한다.

The

Options:

• -u: specify a URL from which to retrieve a manifest repository. The common manifest can be found at https://android.googlesource.com/platform/manifest

• -m: select a manifest file within the repository. If no manifest name is selected, the default is default.xml.

• -b: specify a revision, i.e., a particular manifest-branch.

Note: For all remaining Repo commands, the current working directory must either be the parent directory of .repo/ or a subdirectory of the parent directory.

prune

rebase

smartsync

stage

start

status

sync

Downloads new changes and updates the working files in your local environment. If you run repo sync without any arguments, it will synchronize the files for all the projects.

When you run repo sync, this is what happens:

• If the project has never been synchronized, then repo sync is equivalent to git clone. All branches in the remote repository are copied to the local project directory.

• If the project has already been synchronized once, then repo sync is equivalent to:

where BRANCH is the currently checked-out branch in the local project directory. If the local branch is not tracking a branch in the remote repository, then no synchronization will occur for the project.

After a successful repo sync, the code in specified projects will be up to date with the code in the remote repository.

Options:

• -d: switch specified projects back to the manifest revision. Helpful if the project is currently on a topic branch, but the manifest revision is temporarily needed.

• -s: sync to a known good build as specified by the manifest-server element in the current manifest.

• -f: proceed with syncing other projects even if a project fails to sync.

upload

□ Git 이력 이용하기

이력을 보는 방법은 git이다.

-p 옵션은 코드가 변경된 부분까지 보여 주는 것이다.

-1 옵션은 변견이력의 수를 표시해 주는 것이다.

□ 리비전 범위 지정하기

변경이력을 확일 때 범위를 지정해서 해당 기간에 맞는 변경 이력만을 찾아 주는 기능이다.

점(.)과 하이픈(-)를 사용해서도 날짜를 입력 할 수 있다.

예) "오래된-리비전..최신-리비전"의 형식으로 범위를 지정할 수도 있다.

이 밖에도 많은 조합 들이 존재 한다.

□ 버전 간의 차이점 자세히 보기

그냥 git difff를 사용할 경우 작업 복사본과 저장소 간의 차이를 볼 수 있게 된다.

태그를 하나만 지정할 경우 비교 대상은 무조건 HEAD가 된다.

□ 누구의 책임인지 찾기

git blame은 파일의 각 줄앞에 커밋명, 커밋한 사람, 시간 정보를 추가해서 보여 준다.

다음은 hello.html 파일에 대한 git blame 출력의 처음 두줄이다.

^(캐럿)이 문작 존재하는 것은 해당 커밋이 저장소에서 첫 번째 임을 의미한다.

정보시스템 개론 시험문제 Pool

A-1.

A-1-1). System을 정의하시오.

A-1-2). 시스템공학과 소프트웨어공학의 차이점을 라이프사이클을 중심으로 설명하라.(이상)

시스템공학

A-1-3). 객체지향과 구조적 방법론의 차이점을 시스템 관점에서 설명하시오.

A-2. 소프트웨어 개발에 사용되는 대표적인 패러다임 4가지를 설명하고 각 패러다임의 단계별 활동을 설명하시오.

A-3. 나선형 모델(spiral model)의 각 진행 과정에 대하여 설명하고, 프로토타입 기법과의 차이점을 설명하시오.

A-4. 객체지향 질문

(a) 객체를 정의하고 객체지향을 설명하시오.

(b) 객체지향과 구조적 기법의 차이를 설명하시오.

(c) 개발 방법이 통합 기술이라는 이유를 설명하고 통합과정을 기술하시오.

(d) 객체지향 개발 방법이 하향식 접근 방법을 택하는지 또는 상향식 접근 방법을 택하는지 (또는 혼합형인지) 그 이유를 들어 설명하시오.

A-5. 일정에 쫓기거나 눈 앞의 이익으로 인해 기술적 부채(technical debt)를 진 경험이 있으면 기술하시오. 또한 기술적 부채로 인하여 추후 새로운 기능을 개발하는데 어려움이 발생한 경험을 말하고 해결하려고 노력한 경험에 대하여 기술하시오.

A-6. 리팩토링(Refactoring)을 정의하고 기술적 부채(technical debt)와의 연관성을 설명하시오.

A-7. 애자일 기법이 프로토타입이나 나선형 모델과 다른 점을 설명하시오.

요구사항 분석

B-1. 분석과 설계 질문

(a) 분석과 설계의 차이점 기술.

(b) 소프트웨어 요구사항 분석과 개발 업무의 차이점을 설명하시오.

(c) 요구사항 분석에 요구되는 능력을 기술하시오.

(d) 소프트웨어 요구사항을 분석하는 사람(직업군)을 일컷는 단어 .

B-2. 시스템 분석가가 진행하는 주요한 임무는 무엇이며 이러한 임무를 수행함에 있어서 소요되는 자질은 무엇인가?

B-3. 요구사항을 분석하는 모델링 작업 중에 빠져서는 안 될 중요한 요소는 도표를 사용해야 한다는 점이다. 모델링을 정의하고 모델링의 기본요소에 대해 기술하시오.

B-4. 소프트웨어 시스템을 바라보는 3가지 관점에 대해 설명하고, 현금자동인출기를 예로 3가지 관점에서 모델링하시오.

B-8. 현금자동인출기(ATM)를 다음 순서에 의해 모델링 하시오.

(1) 문제설명서 (5줄 이내)

ATM은 은행직원의 도움없이 고객이 입금, 출금, 조회, 이체와 같은 은행 거래를 할 수 있게 해주는 장치이다.

ATM은 현금카드를 받아들여 고객이 가지고 있는 계좌를 바탕으로 위에서 언급한 네 가지 은행 거래중 하나를 수행 한다.

ATM은 은행 소속되어 있으며 고객의 계좌는 은행에서 관리 한다.

□ 한국의 악성코드 변천사

많은 사람들이 리눅스 바이러스가 없다고 믿고 있는데, 그것은 사실이 아니다.

안철수연구소 조시행 연구소장의 강연 말씀으로는 바이러스라는것은 만들려고하면 어느 플랫폼이서든지 만들어 질 수 있는것이다. 그것이 리눅스고 윈도우고는 상관 없는 것이다.

컴퓨터좀 한다는 사람들도 이런 사실과 다른 정보를 믿고 있다고 한다.

□ 악성 코드의 변천사

□ 앞으로 나올 Virus의 전망

• 모바일, x64
• 부트킷, 사회공학 기법

APT 형태의 보안 위협 대응 방안

사내 모든 파일의 움직임에 대한 '가시성' 확보와 '실시간 행위 분석'

- 네트워크 관제와 내부 관제가 통합된 Convergence 관제 요구

- 클라우드 기반의 보안 기술 연구

소장님의 말에 의하면 대부분의 보안회사들이 해커들은 고용을 할 수도 있으나, 크래커나 바이러스 제작자들은 고용하지 않는다고 한다.

그 이유는 실제로 보안기술과 바이러스 제작 기술은 많이 틀리며 그다지 도움이 되지 않는다고한다.

설사 도움이 된다고 해도 일단 한번 윤리의식에 문제가 있는 사람은 채용하진 않는다.

가장 큰 이유로 백신 프로그램은 완벽하지 않다. 따라서 모든 백신 프로그램에는 헛점이 있다. 이런 헛점은 한번 공개가 되면 맊이 어렵다. 따라서 윤리의식에 문제가 있는 사람은 보안 회사로서 그다지 큰 매력을 가지지 못한다는 것이다.

따라서 영화에서 처럼 바이러스제작자가 보안회사에 거액의 스카웃 비용으로 고용되는 일들은 잘 잃어나지 않는다.

□ 국내외 시장변화 및 NHN의 개발 Practice    

□ 세계시장의 변화

A.     스마트폰
- 전체 36%, 휴대폰 사용자중 44%
- 2년 사이에 스마트폰 사용자의 변화=> 26% 사용자 증가
- 빠른 속도록 변화하고 있음을 확인 할 수 있다.
- 미국 스마트폰 OS: 안드로이드 44%, iOS 29%, Rim Blackberry 17%
- 스마트 폰을 통한 가장 많은 접속 사이트: 공통 Google, facebook.
- 마켓 다운 로드 수 변화: 안드로이드 시장의 급성장. iOS은 제자리, 이외는 후퇴중

B.      Cloud의 사용화
-Cloud 클라우드 컴퓨팅 회사에 사용한 만큼 가격을 지불하는 정책
- Cloud 서비스를 통해서 다양한 형태의 서비스가 제공 되고있다.(Iaas, Paas,SaaS)
- 개인의 99%, 전산센터의 95%는 idle상태이다.
- facebook: 8억 사용자 3억 5천 모바일 사용자, 하루 2억 5천개 사진 업그레이드, 70개국어 이상 언어 지원

□ 한국 시장의 변화

A.     인터넷 인구의 포화è 사용연령의 증가 진행
스마트폰을 사용하는 인구 증가 è PC인터넷 대체, 인터넷 접근 확장

B.   40대 이상 인터넷 이용자 급증: 전체 인터넷 이용자중 36% (즉, 이제는 더 이상 인터넷이 젊은 세대들의 전유물이 아니다.)

C.  스마트폰의 PC와는 다른 인터넷 이용시간을 가지고 있다. 즉, Mobile은 이동성과 휴대성이라는 고유의 가치를 기반으로 인터넷 접근 범위를 확장시킴과 동시에, PC 인터넷 이용시간을 대체하는 현상을 나타낸다.

□ Cloud Computing의 상용화

• IaaS: infra as a service: hardware를 설치 할 필요없이 사용한 대로 계산하는 방식, 이용자는 단지 기타 software는 본인이 빅접 설치하여 사용한다.

• PaaS: Platform as a service: hardware에서 부터 Dev tools까지 제공된다. 이용 회사는 Application만 개발하면 된다.

• SaaS: Software as a service: Hardware에서 Application 제공

□ NHN의 소프트웨어 품질 관리

A.     기존 방식(폭포수 개발 방식의 문제점 발견)
- 문제점 해결(코드 완성도, 단계적 빌드 반복 점진 개발)
- 리펙토링(코드 이해도 증가)및 테스트 자동화 실행

B.      생산 지원 인프라 BTS(Bug Tracking System): 빠른 피드백 가능
BDS(Build & Deployment System), 다양한 환경으로 릴리즈 빌드 및 배포 수행.
마틴 파울러: 컴퓨터가 이해할 수 있는 코드는 어느 바보나 짤 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 짠다.

반복 점질 개발의 구성 요소

• SVN: Source code control system
• BTS: bug tracking test
• Refactoring(리팩토링): 프로그램 전체 동작은 그대로 유지하면서, 프로그램의 논리적 구조만을 개선하는 것을 지칭한다.
• 테스트 자동화: 대부분의 결함은 코드를 작성할 때 발생한다. 이러한 결함은 개발 시간이 지날수록 수정에 많은 비용을 발생 시킨다. 따라서 개발자가 코드를 작성할 때 부터 매번 스스로 결함을 검사하는 것이 바람직하다고 볼 수 있다. 이러한 매커니즘을 제공하기 위해서 나온 것이 테스트 자동화 이다.

□ Quality Practice: 리팩토링 및 테스트 자동화

C.      오픈 소스의 사용 및 개발
- 운영비 절감, 사회적 기여

□ 특허의 중요성 및 IT분야 주요 특허 분쟁 사례

특허법 제1조 [특허의 목적]

: 발명을 보호 장려하고, 그 이용을 도모함으로써 기술발전을 촉진하여 산업발전에 이바지함

국지 주의란: 특허를 등록받은 국가에 한해 제한적으로 효력 발생.

반드시 해당 국가에 특허 출원을 해야한다.(미국, 유럽, 일본, 중국 등)

국제 출원의 종류

□ 특허권의 발생

□ 특허 분쟁 발생 및 대응 전략

□ 사례 분석

특허 풀(Pool): 특허권자들이 자신들의 특허를 공동 라이센싱을 목적으로 결상한 단체(MPEG LA, 3G3P, LLC 등)

특허권자들을 대신하여 특허권자 간에 사용계약(cross-licensing), 제3자에 대한 특허사용계약, 특허료징수 및 배분

표준특허: MPEG, 3GPP, 3GPP2 등의 표준 규격을 기술적으로 구현하는 과정에서 필수적으로 실시되는 특허

"표준을 지배하는 자가 세상을 지배한다." = Winner Takes All

디자인 보호법: 물품의 외간 디자인을 보호하여 디자인 창작을 장려하고 산업 발전을 도모, 창작된 디자인 보호가 아니라 디자인이 적용된 물품을 보호, 존속기간은 20년

□ FRAND 원칙 (Fair, Reasonable & Non-Discriminatory)

□ 관련 도서

No Patent No Future

특허색약