2016년 6월 25일 토요일

Windows 기본 기호 리스트


Windows 한글 자음 을 누르고 '한자키'를 클릭하면 찾을 수 있습니다.
각 기호마다 내부 링크 추가 할 예정 입니다.

자음
내용
개수
문장부호(기술 기호)
38
문장부호(괄호 기호)
23
수학 연산 기호(학술 기호)
48
여러 종류 표시 기호(단위 기호)
104
일반 기호
80
직각 도형(괘선 조각)
68
한글 원형 틀 문자(표제 기호)
57
영어, 숫자 원형 틀 문자(표제 기호)
82
아라비아 숫자, 로마 숫자
30
분수(숫자 기호)
18
한글 자모(낱자)
51
훈민정음(고어 낱자)
42
전각 알파벳(로마 문자)
52
여러 종류 그리스 문자
48
알파벳 확장 문자(라틴 문자)
27
히라가나(일본 문자)
83
가타카나(일본 문자)
86
키릴 문자(러시아 문자)
66

기술 기호
_
˝
­
˚
˙
¸
˛
¡
·
´
¿
ː
ˇ
¨
˘
괄호 기호
학술 기호
±
×
÷
단위 기호
¤
°
일반 기호
ª
º
§
괘선 조각
표제 기호
표제 기호 숫자
숫자 (아라비아, 숫자)
0
1
2
3
4
5
6
7
8
9
숫자 기호 첨자
½
²
³
¼
¾
¹
한글 낱자
한글 고어
로마 문자
그리스 문자

Α
Λ
Φ
η
ρ
Β
Μ
Χ
θ
σ
Γ
Ν
Ψ
ι
τ
Δ
Ξ
Ω
κ
υ
Ε
Ο
α
λ
φ
Ζ
Π
β
μ
χ
Η
Ρ
γ
ν
ψ
Θ
Σ
δ
ξ
ω
Ι
Τ
ε
ο
Κ
Υ
ζ
π
라틴 문자
Æ
Þ
ŀ
Ð
Ŧ
ł
ª
Ŋ
ø
Ħ
æ
œ
IJ
đ
ß
Ŀ
ð
þ
Ł
ħ
ŧ
Ø
ı
ŋ
Œ
ij
ʼn
º
ĸ
일본 문자(히라가나)
일본 문자(가타카나)

러시아 문자(키릴문자)

А
Й
У
Э
ж
р
ъ
Б
К
Ф
Ю
з
с
ы
В
Л
Х
Я
и
т
ь
Г
М
Ц
а
й
у
э
Д
Н
Ч
б
к
ф
ю
Е
О
Ш
в
л
х
я
Ё
П
Щ
г
м
ц
Ж
Р
Ъ
д
н
ч
З
С
Ы
е
о
ш
И
Т
Ь
ё
п
щ



추가 기호 정보
그 중 유용한 기호

2016년 6월 5일 일요일

자연철학에 대한 이해 - 일러스트 철학 사전


옛날 사람들은 신이 자연(세계)을 만들었다고 믿었고 신화로 자연의 성립을 이해했다.

다양한 기술이 발달하면서 삶이 풍족해졌다. 인구가 늘어났고 다른 지역과 교류가 활발해졌다.

그러다 지역에 따라 자연의 성립을 설명하는 신화가 다르다는 것을 알게 됐다.

그래서 누구나 인정할 만한 만물의 근원을 생각하게 됐다. 탈레스는 만물의 근원이 이라 했고 아낙시메스는 공기라고 했다. 이때 근원이 물인지 공기인지는 중요하지 않다. 만물의 근원을 신화로 설명하지 않고, 이성적으로 생각해 자연에서 근원을 찾으려는 새로운 사고방식이 중요하다. 이것이 자연철학의 시작이다.

「한눈에 보고 단숨에 읽는 일러스트 철학사전」 다나카 마사토


고대 철학 중 가장 초기에 나타난 자연철학을 쉽게 설명해 주었습니다.

이 책에는.. 고대 탈레스부터 현대 AI 시대의 생명윤리까지 87명의 철학자와 187개의 철학 사상을 위와 같이 정말 간략하게.. 그리고 그림까지 덧붙여서 설명해 줍니다.

묻지말고 사야하는 책! 인거 같습니다.

자연철학의 설명으로 돌아가면.. 인간의 한계를 인식하고 거대한 신이라는 존재가 있을 것이라고 생각하던 시간과.. 인간의 한계를 극복해 가면서 새롭게 알게된 사실들에 적응해 가는 과정에서 새로운 철학들이 나타났습니다.

이전에 한번 정의되고 굳세게 믿고 살았던 사실이라도 시간이 지나면 재 평가를 받아야 합니다.

인간의 지혜는 완전하지 않으므로 아집을 가지고 살지 말고, 마음을 열어놓고 살아 갔으면 합니다.


(K, E)Python Module Dependency Graphs Example(종속성 그래프 예제)


Contents
    file1~5, Console Command, Result

file1
file2

file3

file4

file5

Console Command
python py2depgraph.py file1.py | python depgraph2dot.py | dot -T png -o result.png

Note
Some built in Libraries(ex> Serial) make py2depgraph.py script error. I don't know the root cause. In that case, that library need to be commented or replace to blank library which has same name to appear in dependency graph. I made another 20 scripts related dependency graph, so this method works file.
기본 라이브러리(예를 들어 Serial)들이 py2depgraph.py 스크립트를 실행하다 에러가 발생하는 경우가 있습니다. 정확한 이유는 모르지만 처리과정에 문제가 있는 것이고, 기본 라이브러리기 때문에 아예 주석으로 바꾸어서 그림에 안나타나게 하거나, 필요 시에는 같은 이름을 가진 .py를 만들어 주면 그림에서 나타나게 할 수 있습니다. 그리고 이 예시 말고 약 20개 python script 로도 dependency graph를 그려보아서 이 방법이 잘 되는 것은 확인 하였습니다.


Result

(E, K)Unified Diagnostic Services 간단한 정리

Unified Diagnostic Services (UDS) specifies data link independent requirements of automotive diagnostic services in road vehicles.[1]
UDS is codified in ISO 14229-1:2013 and allows diagnostics to control functions on an in-vehicle Electronic Control Unit (ECU).
Typical functions ECUs control are electronic fuel injection(EFI), automatic gear box, anti-lock braking system, etc.
all connected to a serial data link embedded in a road vehicle.
The Diagnostic communication over Controller Area Network (DoCAN) is specified in ISO 15765-3[2] and ISO 14229-3.

통합 진단 서비스(UDS) 는 data link independent 한 자동차의 진단 서비스를 의미합니다.
UDS는 ISO 14229-1:2013 에 명시되어 있으며, 진단 명령이 차량의 ECU 를 제어 하게 되어 있습니다.
전형적인 ECU의 기능은 연료 분사(EFI), 자동 변속기, 잠김 방지 브레이크 장치 등이 있습니다.
모두 자동차 안의 시리얼 연결로 연결되어 으며, CAN을 통한 진단 통신(DoCAN)은 ISO 15765-3[2] and ISO 14229-3에 명시되어 있습니다.

Service 리스트
Function group
Request SID
Response SID
Service
Diagnostic and
Communications Management
$10
$50
Diagnostic Session Control
$11
$51
ECU Reset
$27
$67
Security Access
$28
$68
Communication Control
$3E
$7E
Tester Present
$83
$C3
Access Timing Parameters
$84
$C4
Secured Data Transmission
$85
$C5
Control DTC Settings
$86
$C6
Response On Event
$87
$C7
Link Control
Data Transmission
$22
$62
Read Data By Identifier
$23
$63
Read Memory By Address
$24
$64
Read Scaling Data By Identifier
$2A
$6A
Read Data By Identifier Periodic
$2C
$6C
Dynamically Define Data Identifier
$2E
$6E
Write Data By Identifier
$3D
$7D
Write Memory By Address
Stored Data Transmission
$14
$54
Clear Diagnostic Information
$19
$59
Read DTC Information
Input / Output Control
$2F
$6F
Input Output Control By Identifier
Remote Activation of Routine
$31
$71
Routine Control
Upload / Download
$34
$74
Request Download
$35
$75
Request Upload
$36
$76
Transfer Data
$37
$77
Request Transfer Exit
$38
$78
Request File Transfer

Input / Output Control
This service allows an external system intervention on internal / external signals via the diagnostic interface.
By specifying a so-called option bytes additional conditions for a request can be specified, the following values are specified:
이 서비스는 외부 시스템이 진단 인터페이스를 이용하여 내부 혹은 외부 시그널에(버스에 정의된 기본 시그널을 의미 하는 듯) 접근 하는 것을 허용한다. 소위 option byte의 추가 조건 이라고 불리는 것으로 요청을 할 수 있게 된다. 아래 값들이 정의 된다.

ReturnControlToECU: The device must get back controls of the mentioned signals.
해당 장치는 언급된 시그널들로 돌아가야 한다.
ResetToDefault: The tester prompts to reset signals to the system wide default value.
시그널 들을 초기 값으로 돌아가게 만들어야 한다.
Freeze Current State: The device shall freeze the current signal value.
현재 시그널이 가진 값들을 그대로 유지하게 한다.
ShortTermAdjustment: The device shall use the provided value for the signal
장치는 제공받은 값으로 시그널을 사용해야 한다.(짧은 기간이라는 말은 일정 기간만 이라는 뜻인지)

Remote Activation of Routine
The Control service routine services of all kinds can be performed. There are three different message types:
With the start-message, a service can be initiated. It can be defined to confirm the beginning of the execution or to notify when the service is completed.
With the Stop message, a running service can be interrupted at any time.
The third option is a message to query the results of the service.
The start and stop message parameters can be specified. This makes it possible to implement every possible project-specific service.
*. 이 Control Routine 을 사용한다는 것은 해당 작업이 시작, 정지, 결과 읽기의 기본 명령들을 실행할 만한 셩격일 때 하는 것인지.



참조: 위키피디아












































2016년 6월 4일 토요일

(E, K)Generating Python Module Dependency Graphs(종속성 그래프 생성하기)

I studied how to draw dependency graph from the website. I translated it below to understand correctly.
my own example is on another post.
python 파일들의 dependency graph를 그리기 위해서 인터넷 검색을 통해 잘 설명해 준 싸이트를 찾았고, 해 보았습니다. 아래는 이해를 제대로 하기 위해 번역해 놓은 글 입니다. 제가 직접 구현한 간단한 예제는 다른 포스트에 기록 했습니다.


Controlling physical dependencies is an important part of any software architecture. We noticed a shortage of tools for analyzing Python program when we started work on 'Tintag Explorer', and the tools described here were created as a result.
물리적인 의존관계를 파악하고 제어하는 것은 소프트웨어 구조에서 중요한 부분입니다. 우리는 Python 에서 이런 의존관계를 분석하는 툴이 부족한 것을 인지하여 Tintag Explorer 의 의존관계 분석하는 툴을 직접 만들어 보았습니다.

Below is a shrunken version of the dependency graph from several subsystems of the current development version of Tinytag Explorer; 4.3. The __main__ module is the small dark blue circle at the top. Other circles are other modules. The lines are arrows (although you cant see the arrow-heads in this shrunken version) that indicate that one module imports another. All arrows point down, unless there are cyclic imports.
아래는 Tinytag Explorer 4.3버전에 대한 의존그래프 입니다. __main__ 모듈은 위쪽에 작은 어두운 파란 동그라미 입니다. 보이는 선들은 화살표이며(비록 이 작은 그림들에서는 화살의 머리가 보이지 않아도) import 된 관계를 나타 냅니다.
모든 화살표는 아래를 향하게 됩니다. 단 cycle 관계여서 서로 import 하는게 아니라면...



We have obtained enormous value from studying automatically generated diagrams such as this. It often highlights:
우리는 자동 다이어그램 생성을 찾아 보면서 많은 것들을 얻었습니다. 이 dependency graph를 통해서 강조해서 알 수 있었던 것은.

● Ill-advised module iorts, as obtrusive diagonal lines across large distances of the diagram.
  문제가 될만한 먼 거리에 보기싫게 사선으로 연결된 관계.
● Modules that might be in the wrong package, as solitary circles on one color surrounded by those of another color.
   잘못된 패키지 안에 있는 모듈들, 예를 들어 혼자 연결되어 있는 것.
● Subsystems that are ideal for reuse in other systems because they have few dependencies. For example, the island of pink on the bottom left of the diagram above has already been reused from another project. [Hi Lawrence.... That's TSG!]
   의존 관계가 적어, 재 사용하기에 좋은 하위시스템들, 예를 들어 아래에서 왼쪽에 핑크색으로 표시된 것처럼.
● Close clusters of modules are often a suitable unit for code review.
   구분되어 져 있는 무리들은 코드 리뷰하기에 적당함

This diagram was generated from a three-step process:
이 다이어그램은 3개의 단계로 나누어 진행 되었습니다.

Step 1: Compute The Dependency Graph
Python's modulefinder module does all the heavy lifting here. modulefinder use bytecode inspection to find dependencies, and therefore is free from any side-effects that may be caused by importing the modules being studied.
파이썬의 modulefinder 모듈이 어려운 일들을 해 줍니다. modulefinder 는 바이트코드 단위에서 의존관계를 확인해 주었고, import 된 것을 확인하는 과정에서 부작용이 없도록 하였습니다.

This py2depgraph.py script will write to stdout the dependency graph raw data for the script named in its first parameter.
py2depgraph.py 스크립트 첫번째 파라미터가 된 파일에 대한 의존 관계를 간단한 text 버전으로 보여 줍니다.

Step 2: Format The Dependency Graph
In step 3 we will be passing our data into dot, part of graphviz In step 2 we need to convert the raw dependency data generated in step 1 into the correct format, and apply any presentation logic.
2번째 단계에서는 1단계에서 나온 의존관계를 그래프 그리기 알맞는 dot형태로 변경하고, 3번째 단계에서 dot 형태의 그래프를 graphviz로 보내 그림으로 보여질 수 있도록 합니다.

In simple cases you can use depgraph2dot.py as-is. It receives the raw data in standard input, and provides the generated dot file on standard output.
간단한 관계에선 depgraph2dot.py를 그대로 사용하면 됩니다. 입력값으로 기본 text 포맷을 받아들이며 dot파일의 형태로 아웃풋을 만들어 줍니다.

For the best presentation you will need a little programming. Create a subclass of the class defined in this module, override some methods that apply presentation logic, then call the main() method of one of those objects. The following aspects of the presentation can be customised:
최적으로 보여주기 위하여 약간의 프로그래밍이 필요 합니다. 여기서 만들어진 클래스에 대한 하위 클래스를 만들어서, 프레젠테이션 로직을 오버라이드 해 주고 main 함수를 부르면 됩니다. 프레젠테이션은 수정될 수도 있습니다.

1. Change which modules will be used on the diagram. By default it omits a number of very common modules such as sys that would add uninteresting clutter. It also omits packages (but not the modules within the package). The diagram above has been customized to show a group of application-specific packages.
 어떤 모듈을 그릴 것인지 선택 합니다. 정말 기본적인 모듈들 이나 package 들은 생략합니다(예를 들어 sys).  위의 다이어그램은 application 에 사용되는 것들만 보이도록 손 본 것입니다.

2. Pairs of modules that have a specially close relationship. These relationships are drawn with particularly short straight lines. By default any reference to a module whose name starts with an underscore carries this extra weight, because that usually indicates a special relationship (for example, as between random and _random)
   관계가 밀접한 모듈들은 짧은 라인으로 연결되게 됩니다. 모듈 이름에 밑줄이 그어져 잇는 것들은 특별히 중요한 것들입니다. 특별한 관계이기 때문 입니다.(예를 들어 random 과 _random)

3. Pairs of modules whose relationship should be drawn with an extra long line. This is a good way of separating subsystems - for example the module highlighted in red in the diagram above has extra space above.
   특별히 긴 라인으로 연결되어 있는 모듈들도 있습니다. 이 방법은 하위 시스템들을 구분하는 데 사용됩니다 - 빨간색으로 강조 되어 있는 부분이 그렇습니다.

4. A color. By default the color is assigned automatically with all modules in one package assigned the same color.
  색을 입힙니다. 기본 색은 자동으로 생성되며 같은 패키지것을 사용한 것은 같은 색이 됩니다.

5. A text label, by default the module name.
  텍스트를 모듈의 이름에 근거해서 생성합니다.

Step 3: Generate The Image
You need the dot tool from graphviz. This can generate most image formats. It can also generate postscript ideal for printing. If printing to a black and white printer the --mono switch to depgraph2dot.py will be helpful.
image를 만들기 위해서는 graphviz에 있는 dot 툴이 필요 합니다. 흑백의 출력이 필요하다면 --mono option 을 depgraph2dot.py 명령에 추가하면 됩니다.

Putting those three steps together gives something like:
위에 설명한 3개의 단계는 아래의 명령으로 구현 됩니다.

$ python py2depgraph.py path/to/my/script.py | python depgraph2dot.py | dot -T png -o depgraph.png
$

(Created 2004. Updated December 2009 with python 2.6 fixes)