TIL

TIL은 (Today I Learned 의 약자이다)

TIL은 (Today I Learned 의 약자이다)

HTML

<pre></pre>

HTML에 입력한대로 화면에 표시한다

<br> 이나 &nbsp를 사용하지 않아도 되서 편리하다

문자모양 태그

다양한 문자태그를 사용한다

	<p><b> b 태그는 굵은 글꼴</b></p>
	<p><i> i 태그는 기울임 꼴</i></p>
	<p><em> em 태그는 강조로 표시</em></p>
	<p><small> small 은 작은 글씨</small></p>
	<p><mark> 음영으로  표시</mark></p>
	<p><strong> 강력하게 강조</strong></p>
	<p>X<sub>2</sub>와 Y<sup>2</sup></p>
	<p>ins는 <ins>밑줄</ins></p>
	<p><del>취소선</del></p>

특수문자표기법

https://entitycode.com/ 를 참조하자

<p></p>, <div></div>, <span></span>, <hr></hr>태그

Input 타입

전화 번호 등 유저 인풋을 받을때 쓰는 태그

<input type="text" name="tel" pattern="[0-1]{3}-[0-9]{4}-[0-9]{4}"
						title="###-####-####" placeholder="전화번호를 입력하시오" id="phone">
<input type="text" name="name" placeholder="이름을 입력하시오"
						required="required" autofocus="autofocus" id="name">

HTML5 태그

JavaScript

메인 교재 : https://addyosmani.com/resources/essentialjsdesignpatterns/book/#whatisapattern

What is pattern?

패턴 자체는 솔루션이 아니다. 하지만 디자이너를 돕는다.

패턴이 제공해야 하는 장점들

• 패턴의 재사용은 애플리케이션 개발 중중 커다란 문제를 일으킬 수 있는 작은 문제들을 방지하는데 도움을 준다.
  • 이미 입증된 패턴을 사용함으로, 코드의 구조적 문제에 대해 적게 걱정하고 품질에 집중. 왜냐면 패턴은 구조적이고 정돈된 방법을 사용해서 깨끗
• 패턴은 하나의 문제에 묶일 필요 없는 일반화된 해결책을 줌
  • 즉 디자인 패턴은 우리 코드의 품질을 향상 시킨다.
• 특정 패턴들은 사실 반복을 줄임으로서 코드의 사이즈를 줄인다.
  • 코드를 더 DRY하게 만든다고 알려져 있음
• 패턴은 개발자의 단어에 더한다(?), 커뮤니케이션이 원활하다
  • 공통 패턴 사용으로 커뮤니케이션이 원활하단 소리 하고 싶은듯
• 자주 사용되는 패턴들은 여러 사용자의 집합적인 경험을 피드백 받아 발전 할 수 있다.

우리는 이미 패턴을 사용하고 있다.

---

calss = "foo"에 증분을 더하고 싶다고 생각해봐라.

1. 문서의 모든 요소를 선택한다. -> "foo" 만 필터한다
2. querySelectorAll()
3. getElementsByClassName()

3번이 제일 빠르다. 하지만 현실은 2,3 번이 안되면 1번을 써야한다.

jQuery의 추상화는 이런 걱정을 안해도 됨. Facade pattern

결론 : jQueyr Selector 와 querySelectorAll()은 같은 역할을 하지만 효율성이 다르다.

패턴성 테스트, 시제품 패턴(?) 그리고 3가지 룰("Pattern"-ity Testing, Proto-Patterns & The Rule Of Three)

좋아보인다고 다 패턴이 되는것이 아니다. 테스트와 철저한 검증이 필요하다.

By Alexander 패턴은 과정이자 "것"이 되어야 한다. 정의가 목적에 맞지 않는다(명확하지 않다?). 왜냐면 다음과 같이 말했기 때문. "무언가를 만들어야 하는 것은 프로세스이다.". 이것이 왜 패턴이 눈에 보이는 구졸르 그리려 하는지 말해주는 부분이다.

디자인 패턴을 연구할 때, "프로토 패턴"이라는 용어를 접하는 것은 불규칙하지 않다. 이게 뭐야? 음, 아직 "패턴"-아이티 테스트를 통과했다고 알려져 있지 않은 패턴은 보통 프로토 패턴이라고 불린다. 프로토 패턴은 커뮤니티에 공유할 가치가 있는 특정 해결책을 수립한 사람의 작업에서 비롯될 수 있지만, 아직 올라온지 얼마 되지 않아 심하게 조사받을 기회가 없었을 수도 있다.

또는 패턴을 공유하는 개인은 "Pattern"-ity 프로세스를 거치는 데 시간이나 관심이 없을 수 있으며 대신 자신의 프로토 패턴에 대한 간략한 설명을 공개할 수 있다. 이러한 유형의 패턴에 대한 간략한 설명 또는 스니펫을 패틀릿이라고 한다.

-> 프로토 패턴은 프로토 패턴과, 패틀릿 상태가 있다. 패틀릿이란 공유는 했지만 게시자가 시간이 없거나 관심이 없어 그저 올려놓은 상태인 것.

-> 프로토 패턴 다음이 패턴화

적격 패턴을 완전히 문서화하는 데 관련된 작업은 상당히 어려울 수 있다. 설계 패턴 분야에서 가장 초기의 몇 가지 작업을 돌이켜 보면, 패턴이 다음과 같은 경우에 "좋은" 것으로 간주될 수 있다.

• 특정 문제를 해결:패턴은 원칙이나 전략만을 포착하는 것이 아니다. 그들은 해결책을 찾아야 한다. 이것은 좋은 패턴에 가장 필수적인 재료 중 하나이다.
• 그 문제의 해결책은 명백할 수 없다(추상화 될 수 있어야 한다): 우리는 문제 해결 기법이 흔히 잘 알려진 첫 번째 원칙에서 도출하려고 시도한다는 것을 발견할 수 있다. 최고의 설계 패턴은 일반적으로 문제에 대한 해결책을 간접적으로 제공한다. 이는 설계와 관련된 가장 어려운 문제에 필요한 접근방식으로 간주된다.
• 설명된 개념은 증명되어야 한다: 설계 패턴은 설명한 대로 작동한다는 증거가 필요하며, 이 증거가 없으면 설계를 심각하게 고려할 수 없다. 만약 어떤 패턴이 매우 투기적인(speculative in nature) 것이라면, 용감한 자만이 그것을 사용하려고 시도할 수 있다.
• 관계를 설명해야 한다. 어떤 경우에는 패턴이 모듈의 유형을 설명하는 것으로 보일 수 있다. 구현이 이러한 방식으로 나타날 수 있지만, 패턴에 대한 공식적인 설명은 코드와의 관계를 설명하는 훨씬 더 깊은 시스템 구조와 메커니즘을 설명해야 한다.

가이드라인을 충족하지 못하는 프로토타입은 배울 가치가 없다고 생각하는 것에 대해 용서받을 수 있을지 모르지만, 이것은 사실과 거리가 멀다. 많은 프로토타입 패턴은 사실 꽤 괜찮다. 나는 모든 프로토 패턴이 볼 가치가 있다고 말하는 것은 아니지만, 도처에 미래의 프로젝트에서 우리를 도울 수 있는 유용한 것들이 꽤 있다. 위의 목록을 염두에 두고 최선의 판단을 내리면 선택 과정에서도 문제가 없을 것이다.

패턴이 유효하기 위한 추가 요구사항 중 하나는 패턴이 일부 반복적인 현상을 보인다는 것이다. 이것은 흔히 적어도 3가지 핵심 영역에서 적격성을 가질 수 있는 것으로, 3가지 규칙이라고 한다. 이 규칙을 사용하여 반복을 표시하려면 다음을 시연해야 한다.

1. 목적의 적합성 - 어떻게 그 패턴이 성공적이라고 생각되는가?
2. 유용성 - 왜 그 패턴이 성공적인 것으로 간주되는가?
3. 적용성 - 설계는 적용성이 넓기 때문에 패턴이 될 만한 가치가 있는가? 만약 그렇다면, 이것은 설명될 필요가 있다. 패턴을 검토하거나 정의할 때는 위 사항을 염두에 두는 것이 중요하다.

JAVA

20201103

AWS 활용. 1년은 무료.

프로젝트는 잘 운용.

소스파일은 깃허브

오늘 할 것

1. Linux 설치 및 Clinet
2. Google FCM 설치 운영

장비에 여러가지 쏴 보는 것.

http로 데이터를 쏘고, 받아보는 형식

여러대의 IoT 장비와 클라이언트를 서버로 올리는 것

팀원 사이에 소통.

오후에는 serial 통신.(구닥다리??)

물리적인 장치와 IoT 통신은 여전히 serial 통신

실제 IoT는 화면이 없다. 우리는 화면을 가지고 있다.

패드와 IoT 장비의 통신은 TCP/IP. FCM을 이용해서 서버에 요청올린다(시동걸기 등)

실질적으로 한 것을 잘 포장하는게 중요. 잘 정리.

팀별 AWS(1~2). 터미널로 실행. 속도문제가 있으니, 모두다 깔지는 말 것.

일정

RFP 작성 및 시스템 흐름도

중간 프로젝트와 마지막 프로젝트의 연계.

네트워크 만드는 것을 잘 해놓아야 나중에 마지막 프로젝트 시 시간을 확보할 수 있음.

마주댈 수 없는 환경에서 전략적인 접근이 필요하다.

13:00 캔 장비.

IoT와 CAN 장비

프로토타이핑 할때 많이 사용된다.

캔 버스 + ECU(에어컨, 브레이크, 공기압 등등) + 클러스터

ECU(CPU + RAM 등이 하나로)

캔 프로토콜 : 통신규약

IoT 장비는 캔 버스에 연결되어 신호를 수신, 보냄의 역할을 한다.

라떼팬더를 자동차에 붙인다.

장비중 하나에 신호가 생기면 모든 ECU에 정보가 공유된다.

CAN? -> 가상의 환경을 구축함.

IoT - CAN - CAN - IoT

보낸다 ->받는다 ->보낸다 ->받는다 ->서버로 보낸다

테스트 후에 자동차로 붙인다.

테스트 계획

PC - CAN - CAN - PC

한쪽은 IoT 장비, 다른 한쪽은 자동차라고 가정하고 한다.

메세지 포멧이 정해져있음. id, data, ...

캔 통신

캔 프로 설치 및 실행

카페 참조