박정연 교수님 자료

국내 의료기기 연관된 모든 사람들이 필독해야 할 문서.

미국의 의료기기 법제에 관한 분석.pdf

생각대로되는세상_ 고마운 분s.

하물며 애플도 이렇게 자세히 적는다.

키보드나 마우스는 정말 개인이 느끼는 차이가 심하기에

이 역시 지극히 개인적 느낌이겠다.

리얼포스 하이프로를 2개 사서(품절 날까봐 2개 사뒀는데 진짜 품절남) 오래도록 썼다.

본래 느낌은 바꾸고 난 바로 뒤에 써야 해서 바로 쓴다.

레이저 기감이 정말 좋기는 하지만 리얼포스에 비해 누른다는 느낌이 좀 덜하다.

좋은 말로 하면 더 부드럽다고 해야 겠다.

리얼포스 하이프로는 다른 키보드와 다르게 중간이 옴푹 파여 잘못된 키 입력 습관을

고쳐준다. 미세하게 중앙과 다른, 가장자리를 누르는 것이 하이프로에서는 어색하기에

자동으로 정타를 치게 바꾸어 주는데 2년이 넘어가면서는 해당 기능에 전혀 느낌이 없었다.

4년 넘게 리얼포스를 쓴 지금도 느낌이 없을 줄 알았는데 한동안 청축 키보드(G 뭐시기)

를 하나 사서 쓰다 보니 감각이 돌아왔었다.

레이저 역시 키캡이 아주 약간 들어가 있다.

hipro에 비할바는 아니지만 키캡을 신경 썼다는 느낌.

소리는 리얼포스와 청축 기계식 키보드 중간이다. 그래서 리얼포스 보다는 더 경쾌하다.

그래도 리얼 포스는 사무실에서 쓸 수 있을 마지막 한계 였는데, 얘는 사무실에는

못 가져갈 것 같다.

내가 이 키보드를 선택한 이유는 단하나, 녹색 LED 이기 때문이다.

다채롭게 LED가 구성되거나 누를 때 마다, 아니면 원형으로 퍼져나가는 등의

LED 키보드를 여럿 사용해봤으나

내가 가장 좋아하는 색은 녹색이기 때문에 별다른 기능없이 녹색만 나와도 좋았다.

USB와 헤드폰을 꽂을 수 있는 공간이 따로 있는데

데스크탑이 바로 옆에 있고 외장 포트가 팔 닿을 거리에 있어서 오히려 거추장 스럽지만

나름 잘 써보려고 한다.

다만 인식시킬려면 레이저 시냅스란 소프트웨어를 해당 홈페이지 들어가서 설치를 해야

먹는다.

마이크소프트트의 사이드 와인더를 쓰면서(이것은 아직 누굴 주지 못해서 집에 있다. 음량 조절 조그셔틀이 있는 거대한 기능 때문에 ㅠㅠ) 단축키 19개 정도까지 쓰다가 오히려 아예 안쓰게 되어 단축키는 안 쓸 것 같다.

쓸대없는 말만 많이 적었는데,

리얼포스 사용자라면 그냥 구입하지 말라고 하고 싶다.

레오폴드에서 나오는 리얼포스 말고, 레오폴드 자체 제품과 키감이 매우 흡사하다.

나처럼 적어도 2달에 한번은 새 키보드를 사서 써봐야 풀리는 키보드 변태가 아닌 다음에야...

리얼포스에서 인체공학용 키보드 나오면 너무너무 좋겠다 ㅠㅠ

https://razerid.razer.com/kr-kr/products 제품 홈페이지

https://support.razer.com/gaming-keyboards/razer-blackwidow-ultimate-2017/

여긴 관련 파일 받는 곳.

게이밍 모드 지원이 되는데

The Gaming Mode disables the Windows Key function to avoid accidental usage. Furthermore, you can maximize the effect of Anti-Ghosting by activating the Gaming mode function. You can also choose to disable the Alt + Tab and Alt + F4 functions by using the Gaming Mode Tab in Razer Synapse. An indicator will light up when Gaming Mode is active

요샌 전체 화면 모드로 안하고 멀티 작업을 위해 게임도 전체창 모드로 하기에 윈도우 키를 누르는게 크게 문제가 안된다. 그리고 게임 종료할 때도 Alt+F4를 자주 누르기 때문에 쓸 일은 없을 듯.

조그 셔틀이 가지고 싶어서 키보드 두개 연결함

이은미 어떤 그리움, 애인 있어요.

질렸다 너무 좋아서

주문하고 한시간 뒤에 보니 주문 취소가 되어 있었다.

취소 시각이 나오지 않아 전화해서 물어보니 3분 쯤 뒤였다.

앱이 켜져 있어서 그랬던 걸까? 알람도 오지 않았다.

주문 취소 = 해당 업체에서 1시간 30분 이상 걸릴 것 같은 경우 취소를 한다고 한다.

취소 시각을 해당 업체에 물어봤을 때 취소했을 경우 업에체서는 내역이

나오지 않는다고 한다.

아이와 함께 먹을 것을 기다리던 차라 짜증나서 수수료 때문에 일부러 취소했냐고

물어보니 예전에는 비쌌는데 요즘엔 카드 결제 수수료 정도라서 그렇지 않다고 답했다.

그만큼 내가 짜증나서 꼬치꼬치 캐묻던... 카드 결제 수수료 사실 작지 않다.

카드사의 존재로 수많은 노상 강도가 줄어 난 좋긴 하다.

배달의 민족으로 유명해진 집은 이제 주문을 거르는 것 같네.

똑같은 시각에 똑같이 카드 결제를 해 버린 경우 그냥 주문을 받던데 말이다.

배달의 민족앱의 활용처는 다른 사람들의 평점.

주문 취소가 잦은 업체의 경우 사용자가 횟수를 알 수 있게 해주면 좋겠다.

그러나 난 안다. 이런 기업은 절대 그런 정보를 사용자에게 주지 않는다.

카카오도 마찬가지 맥락이다.

그냥 자기 이익이 최우선.

두로프 같은 리더가 계속 나오진 않으니 어쩔 수 있나.

그냥 그렇게 살아야지.

이런 기사는 대부분 삭제 되었다.

돈에 굴하지 않는 민중의 소리, 뉴스타파, 오마이뉴스가 계속 가야

아이들에게 인간을 가르쳐 줄 수 있을텐데 그게 쉽지 않으니, 참 걱정이다.

다음카카오 법률 대리인 구아무개 변호사가 논란이 일고 있는 카카오톡 사이버 검열과 관련해 “뭘 사과해야 하는 건지”라는 글을 올려 물의를 빚고 있다.

구 변호사는 지난 8일 자신의 페이스북에 “카카오톡을 위한 변론”이라는 글을 올렸다. 글에는 “뭘 사과해야 하는 건지. 판사가 발부한 영장을 거부해서 공무집행 방해를 하라는 건지. 자신의 집에 영장집행이 와도 거부할 용기가 없는 중생들이면서 나약한 인터넷 사업자에 돌을 던지는 비겁자들”이라고 썼다. 이어 구 변호사는 “논의의 핵심이 아닌 곳에 정신이 팔려있는 동안 덕을 보는 세력이 있다네”라고 덧붙였다.

인터넷 등을 통해 논란이 커지자 구 변호사는 해당글을 페이스북에서 삭제했다. 구 변호사는 페이스북을 통해 “최근 진행되는 사이버 모니터링 사태에 대해 개인적인 소회를 사사로이 밝힌 글로 인해 본의 아니게 심려를 끼쳐 드리게 되어 정중한 사과를 드린다”고 사과했다. 이어 구 변호사는 “더불어 특정 회사의 공식적인 입장과는 관계가 없다”고 해명했다.

누리꾼들은 구 변호사의 글에 비판을 쏟아내고 있다. 트위터가 사용자 정보 제공 요청과 관련해 표현의 자유를 침해했다며 미국 정부를 상대로 소송을 제기했다는 소식과 비교해 다음카카오에 대한 실망이 확산되는 모양새다.

트위터 아이디 ‘@ga****ok’는 “공식 사과를 한 카카오톡이 왜 사과를 해야 하냐며 국민들을 훈계하듯 비난하고 있다. 공식 사과를 제대로 한 건지 의심스럽다”고 말했다. 트위터 아이디 ‘@bs*****o1’은 “영장집행 같은 것으로 집행되면 구 변호사가 거부하는 것이 용기라고 알려줬다고 하면 되는 것인가. 문을 걸어닫고 언론에 ‘검경이 절 감금했어요’라고 호소하면 되겠네”라고 비꼬았다. 아이디 ‘@l*****104’는 “국민을 떠난 정권은 성공할 수 없고, 물을 떠난 물고기는 살 수 없다. 고객이 떠난 카카오톡의 미래는 어떻게 될까”라고 되물었다.

다음카카오는 지난 8일 검열 논란과 관련해 공식 사과하고, 이용자 정보보호를 위해 프라이버시 모드를 도입 계획을 밝혔다.

김영동 기자 ydkim@hani.co.kr

원문보기: 

http://www.hani.co.kr/arti/society/society_general/659062.html#csidxe87d204ce664cac94214043af20f127 

최근 카카오톡이 처한 상황에 대해서는 ‘동병상련’을 느낀다고 했다. 두로프는 “러시아에서 브콘닥테(VK)를 운영할 때 비슷한 상황을 겪었기 때문에 그들(카카오톡)의 상황을 잘 이해한다”면서 “우리는 사생활 유출에 대한 모든 잠재적 공격을 막아내기 위해 강력한 암호화를 연구하고 있다”고 말했다.

두로프는 자신이 설립한 러시아 최대 소셜네트워크서비스(SNS) VK에 게시된 내용을 러시아 정부가 검열하는 데 반대해 지난해 텔레그램을 내놓았다. 지난 4월에는 러시아를 떠나 망명길에 올랐다. 최근 검찰이 카카오톡 등 국내 주요 SNS에 대한 사이버 검열 가능성을 언급한 뒤 텔레그램의 국내 가입자 수는 300만 명에 육박할 정도로 급증하고 있다.

노용택 기자 nyt@kmib.co.kr

[출처] - 국민일보 

[원본링크] - http://news.kmib.co.kr/article/view.asp?arcid=0008779429

인간관계와 사회애 대해서 불만이 있었지만 염세주의는 아니었다.

최근에는 나를 위로할 뭔가가 필요해서 해당 사상에 물들어 보려 했는데

염세주의는 따져보면 리얼리즘과 붙어 있고 인터넷 서핑을 해보니 대표 작자가 염상섭,

그런데 67세에 타계하신 듯 직장암이었다고 한다. 암에는 여러 원인이 있고 수명도

가지 각색이겠지만.

너무한 리얼리즘과 염세주의에는 빠지지 말고 적당히 취해 있자고 다짐했다.

프리한 19

늦은 시각 보고 있는데

귀납 추론(歸納推論)은 1620년에 프랜시스 베이컨이 창안한 추론 방법이다. 베이컨 모델에 따르면 경험적 사실로부터 추측 혹은 가설과 원리를 생각해내고 경험적 사실로 참/거짓을 판단하는 방법을 말한다. 편견과 선입견으로부터 벗어나 오로지 경험적 사실로부터 추론해 낸다는 것이 그 핵심이다.

- 위키피디아 발췌 https://ko.wikipedia.org/wiki/%EA%B7%80%EB%82%A9 -

아무리 악한 사람도 풍요로운 세상에 있으면 선인이 되고. 아무리 선한 사람도 악한 세상에 있으면 악인이 됩니다.

개인적 경험을 토대로 쓰는 글 들이기에 주관적일 수 밖에 없습니다.

내가 생각하는 부분은 없습니다. 말도 누군가가 만들었고 글 또한 누군가가 만들었고 나에게 형성된 모든 것이 다른 사람이 정해놓은 것입니다.

특정한 경험이 있으면 거기에서 자유롭지 못합니다. 어릴 때 물에 빠져 죽을 뻔 한 사람은 물을 무서워 하듯이.

그러나 가끔 자기 생각대로 사는 사람들을 만납니다. 그런 사람들을 '소신' 있다고 합니다.

그 소신이 자기 것인지는 완전히 알 수 없으나, 마지막까지 '사람'을 향하는 사람들을 보면 그 소신의 행방은 불문하고

존경심이 우러납니다. 마더 테레사, 프란치스코 교황, 인류를 위했던 수많은 과학자들, 이순신 같이 높임말이 필요없이 저명한 사람들이 그런 부류입니다.

주변에는 없다고 보면 됩니다. 여러 세대를 거쳐 1~2명이 나올까 말까 한 사람들 입니다. 예수님, 부처님도 그런 부류겠지요.

그래서 현실적으로 생각했을 때.

내가 생각하는 부분은 없고. 내 주변 사람 또한 그런 사람은 없다는 확신이 들었습니다.

글을 쓰는 이유는 경험이라도 많이 공유해서 더 많은 경험을 쌓자는 의미입니다.

전쟁 영화를 본 사람이 전쟁의 무서움을 알듯이.

베이비붐 세대까지, 그러니까 81년생및 80~70 까지는 높은 사회적 지위에 있더라도

넉넉치 못한 삶을 산 사람이 많다.

근래엔 많은 사람이 넉넉한 삶을 산다.

계층은 더 다양화 되었다. 그래서 더더욱 높은 지위와 경제력이 반비례 되지는 않을 것이다.

개천에서 용나는 제도도 없애고 부가 대물림 되도록 사회는 끊임없이

변화되어 왔다. 사법시험

내가 대기업 다닐 때도 가족 이야기를 많이 했다. 보통은 그러지 않는다.

부모님 살아 계셔도 친구집에 얹혀서 살아야 했던 내 과거가 딱히 부끄럽지는 않았다.

우리 부모님 세대에는 못사는 비율이 더 높아서 그렇고...

가까운 사람이 잘 살아도 그게 자랑의 대상이거나 기죽을 이유가 되지

않았다. 대기업에서는 불우한 과거의 사람을 싫어하는 것은 모두가 알고 있다.

그러나 장점이 될 때도 있고, 단점이 될 때도 있다.

"라인"이 심한 대기업에는 뭔가 하자가 있고, 족보가 없는 편이

나에겐 장점이 더 많았던 것 같다. 사실 편하게 내 이야기를 하지만, 다른 사람의

이야기를 더 많이 들을 수 있었다. 대기업 나오고 나서 초반에는 더더욱 많이 들을

수 있었다.

이제는 시간이 지날수록 주변 사람들 이야기를 들으면, 내가 하는

이야기들이 뭔가 숨겨야 하는 이야기로 변해가는 것 같아서 씁쓸하다.

어찌보면 털어놓을 상대가 점점 줄어드는 것일 수도.

그게 아니면 더 중요하게 해야할 일이 늘어나서 그럴수도 있겠다.

그래서 번호 붙이는 코스프레를 시작한 이유도 있다.

물론, 있어 보이는 것에 대해서 많이 신경쓰는 사람들 속에서 난 나름의 이미지를 추구하고

있는 것이 하나의 전략이기도 하다. 이미 있어 보이는 것은 시도를 해 봤는데

딱히 재미있지는 않았다.

선물 받은 오메가 시계가 하나 있었는데, 주변에서 부자인 줄 아는 사람이 많았다.

그래서 따로 연락하던 사람도 있었고, 몸이 호리호리 할 때 양복 입고 시계 차고 있으면

거리에서 물어오는 사람 등...

아니라고 해도 믿지를 않았다. 건물을 가지고 있냐는 등...

대기업 동기들이 입사 후 시간이 좀 지나서 보너스로 받는

돈으로 한번에 오메가 시계 3개를 살 수 있게 되자 자연스레 주변 사람 시각은 바뀌었다.

그들이 성장한 것이겠다.

당시 사촌형이 결혼 할 때 드는 돈이 8천만원이었는데(축의금은 더 들어왔지만)

BMW 7 시리즈에 전속 기사까지 딸린 삼촌이 사는 삶과 내 삶은 이미 괴리가 있었다.

대기업 사원도 한낱 회사원이 뿐이었다. 그렇다 하더라도 부자를 옆에서

쉽게 볼 수 있었기에 사실 당시에는 무엇이 다른지 몰랐고.

어느 정도 많은 풍파가 있었다고 하더라도 세배하면 30만원 이상 주시고 집 창문에서

낚시대만 드리우면 바로 고기가 낚이는 카페가 딸린 집을 사는 것은 직장인으로는

도저히 범접할 수 없는 경제적 지위였다.

시대에 맞게 부자의 개념도 바뀐다.

요즘엔 외제차를 사고 외제차를 타야 잘사는게 아니고,

파지 할머지가 외제차를 다 긁고 지나가도 쿨하게 그냥 살펴 가시라고 하는 사람이 부자.

벤츠나 BMW는 흔한 차가 되었고 롤스로이스, 벤틀리를 타야 조금 사는 사람으로(부자도

아니다) 비춰진다.

또 여전히 이런 시각이 절대적이지만도 않다. 한국도 저성장 시대로 접어들면서 실용성을

강조하고 합리적 사고를 더욱 요구한다.

재벌2세가 프라이드 타는데 자기차 앞지르기 했다고 벽돌로 사람을 찍는다거나

압구정 오렌지족이 돈다발 백팩을 매는 시대는 지나갔다. 물론, 공개되지 않을 뿐

똑같은 삶의 클레스는 존재한다. 내가 볼 때 지존파의 존재가 그런 안하무인류의

사람들이 대놓고 활동 못하게 했다고 생각한다.

어차피 사람은 죽는다. 백세시대로 우리 아래 세대들은 150년을 산다고 하고

영생 프로젝트도 진행되지만...

페이스북도 여전히 버그 많고, 애플도 개인정보 털렸고, 수많은 첨단 기술, 생명 바이오 분야의 일하는 사람들도 세상이 완벽하지 못하다는 것을 이미 알고 있어서

오지 않은 미래는 정말 오지 않을수도 있다는 생각도 가지고 있다.

어차피 사람은 죽는다.

다른 사람에게 상처받지 마라.

지워지지 않는 상처를 준 사람이라면 결국엔 복수하고.

아무는 상처라면 그 사람을 잊는 것이 맞다고 생각한다.

어차피 사람은 죽기 때문에 용서되며, 잊혀진다.

김정남 사건의 경우 역사에 남지만 나머지 비슷한 일은 역사에 남지 않는다.

모두 잊혀진다.

똑똑한 엘리트 김정남이 편하게 살려고 마음 먹었다면 얼마든지 편하게 살 수 있었을텐데

그러지 않은 것의 내막은 알 길이 없다.

김한솔 관련 이야기를 보다보면 위장 신분으로 탈북자를 더 도우려고 했을 것 같기도 하다.

옳다고 생각하는 일에 대한

믿은 결국 스스로 판단하는 것이다.

마음의 상처가 아물만한 상처인지 판단하는 것도 본인의 몫이다.

자신의 인생은 나의 것이니까

남에게 상처받지 마라.

http://www.minwon.go.kr/TouchEn/nxKey/module/TouchEn_nxKey_Installer.pkg?ver=1.0.0.47

해결 : http://faq.touchen.co.kr/nxKey/

and...

No cached version of com.android.tools.build

Uncheck "Offline work" in Android Studio 

File->Settings->Gradle->Global Gradle Settings

오래된 문서긴 하다. 파일은 첨부하였음.

그리고 다음 내용이 있어야 한다.

SRSExample-webapp (1).doc

더 이상 말이 필요없는 최고의 웹 분석 솔루션, 서치 콘솔과도 궁합이 좋다.

app: tistory

git: https://github.com/hajunho/blogsearch

env: tistory

db: yes

replicas: 1

replica size: free

branch: master

build: clean

Creating deployment [Done]

Connecting to build logs ...

Waiting in Queue [Done]

Cloning into 'code'...

fatal: could not read Username for 'https://github.com': No such device or address

Error: deploy failed.

You must remove hosting from this application before it can be deleted.

~/vapor/test/Hello(master) » vapor cloud deploy --replicas=0

app: tistory

git: https://github.com/hajunho/blogsearch

env: tistory

db: yes

Setting the replica count to 0 will take your application offline

Would you like to change the replica count?

y/n> y

What replica count?

커맨드에서 지우는 방법도 안 먹어서 (git hub 을 https로 설정하는 바람에)

웹에서 지우는데

https://docs.vapor.cloud/delete/delete-database/

절차가 복잡하다. DB 지우고 env 지우고 어플 지우고... 꼭 역순으로 지워야 한다.

지우다 보니 페이지도 깨져서 아래와 같이 보인다.

그리고 한 시간 째 이러고 있다. 엔터치면서 놀고 있음.

 TeamViewer ID: Management Console

 IP Address: 121.157.204.30

 Seongnam-si, KR

이런 내용도 포함하여!

IoT 디바이스를 만든다고 하면 사실 S/W 부분보다 H/W 성능이 조건이 더 중요할 것이다. 또, RESTAPI도 많이 이용되므로 서버 성능도 함께 고려해야 한다.

얼마나 많은 트렉젝션(소켓통신, 패킷단위, DB CRUD, ...)을 감당할 수 있는지 해당 부분에 대한 포괄적인 사용 기준을 정해서 일반 사용자는 이러이러한 만큼 쓸 것이다. 그런 사용자를 얼마만큼 포용할 수 있는가 등... 

성능 조건은 스스로를 옥죄는 항목이 될 수도 있기 때문에 최대한 루즈하게 적어야 한다. 그러나 사람 목숨과 관련된 부분이라면 루즈한 성능 조건 정의가 되려 설득력을 잃을 수도 있기 때문에 성능 요구사항은 정말 각 실무자들이 최대한 협업해서 적어야 하는 항목일 수 밖에 없다. 기업간의 하청에도 늘 꼬투리를 잡거나 잡힐 수 있는 부분이니 이 부분 관련해서 우선 대화를 많이 해야 한다. 술자리도 좋다.

If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices.

Specify the timing relationships for real time systems.

Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features here or “Functional Requirements” section.

Specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software, as a whole. 

Static numerical requirements may include:

      (a)  The number of terminals to be supported

      (b)  The number of simultaneous users to be supported

      (c)  Amount and type of information to be handled

Static numerical requirements are sometimes identified under a separate section entitled capacity.

Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions.

All of these requirements should be stated in measurable terms.

For example,

95% of the transactions shall be processed in less than 1 second

rather than,

An operator shall not have to wait for the transaction to complete.

(Note: Numerical limits applied to one specific function are normally specified as part of the processing subparagraph description of that function.)

   Throughput (작업처리량) , Concurrent Session (동시 세션), Response Time (대응시간),  Performance Dependency (성능 종속 관계), Other Performance Requirements (기타 성능 요구사항)

         External Interface Requirements (외부 인터페이스 요구사항)

여기에는 System Interface, User Interface, Hardware/Software Interface, Communication Interface, 기타 인터페이스가 포함되어야 하고 시스템 자체는 그룹화해서 표현해야 한다. 이것은 회사마다 양식이 다른데 꼭 SRS 포멧에 맞출 필요가 없다. 해당 문서를 첨부하고 첨부한 문서에 번호를 붙여(SRS-시스템이름-001) 따로 문서를 만들었다고 기입하면 된다. 그것이 power pointer 일 수도 있고 word 문서일 수도 있겠다. 모바일인 경우 User Interface는 simpli나 zeplin 일수도 있다. 기업간의 경우 주소로 대체해도 되겠으나 FDA 승인의 경우 printable 한 문서 형태여야 한다는 것이 주의점이다. 이것도 시대가 바뀌면 계속 바뀌겠지. User Case로 그린 후 첨부할 때는 동그라미(사용 사례, Use Case) 들이 사각형(시스템)안에 들어가도록 배치하고 <<시스템>> 혹은 <<하위시스템>>으로 명시한 후 아래 이름을 적어주면 된다.

졸라맨, 동그라미, 사각형, 화살표만 있는데 나름 규칙이 있으니 우선 따르고 본인이 고객을 상대하면서 변화되는 것을 반영하면 되겠다. 식약처든 FDA던 결국 요구사항에 대한 acceptance test에 대한 논의는 모두 이해 관계자들이 하게 되니까 너무 형식에 구애 받을 필요는 없다. 그러나 형식이 있는 이유는 혹시라도 생각하지 못했던 것에 대한 확인이니 되도록이면 따르는게 좋다.

If the product is independent and totally self-contained, it should be so stated here.  If the SRS defines a product that is a component of a larger system, as frequently occurs, then this subsection relates the requirements of the larger system to functionality of the software and identifies interfaces between that system and the software. 

A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful.  This is not a design or architecture picture.  It is more to provide context, especially if your system will interact with external actors.  The system you are building should be shown as a black box.  Let the design document present the internals.

This contains a detailed description of all inputs into and outputs from the software system.

It contains both content and format as follows:

·          Name of item

·          Description of purpose

·          Source of input or destination of output

·          Valid range, accuracy and/or tolerance

·          Units of measure

·          Timing

·          Relationships to other inputs/outputs

·          Screen formats/organization

·          Window formats/organization

·          Data formats

·          Command formats

·          End messages

If the external interfaces are complicated , you may write a separate ‘Interface Requirement Specification’ document for all or any of the following interfaces.

난 UML을 그릴 때 visio 나 visual studio 2015 enterprise 버전을 이용한다. Xcode에는 없는 기능이다.

https://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview-KOR/Visual-Studio-Ultimate-2012-Improving-architecture-through-modeling-KOR

이런 동영상이 있긴 하지만 사실 UML은 많이 보고 또 많이 그려보는 수 밖에 답이 없다. 그리고 USE CASE의 모든 규칙을 지킬 필요도 없다.

USECASE는 requirements analysis 단계에서 작성하는 것이고 그것은 고객과의 의사 소통을 돕기 위해 만드는 것이지 내가 아는 지식을 자랑하려고 하는 것은 아니기 때문이다. 그리고 대부분의 고객은 돈이 많은 정도와 알고 있는 IT 지식이 반비례 하는 경우가 많다. 내가 하청을 받을 때는 몰랐는데 직접 고객을 만나 대응하는 경우 우 수백억의 자산가들은 IT에 대해서 전혀 모른다. 

보통은 use case를 그리지도 않고 구두로 설명하거나 해당 기술을 설명할 때 기껏 써봐야 sequence diagram, 개발자를 데리고 나온 경우 class diagram 정도였다. 그 중에서 나이 드신 분들도 좋아하는 것은 졸라맨(Actor)이 있는 use case 이다. 졸라맨과 벤다이어그램 하나면 시스템 전체를 설명할 수 있으니 정말 좋다.

그리고 같은 시스템이라도 다양한 관점에서 표현하고 구두로 설명하다보면 고객은 이해를 하고 IT 문외한인 자신도 이해하는 쉽고 자세한 설명을 할 수 있는 사람을 고수로 본다. 돈이 많은 데에는 이유가 있고, 대부분의 IT 기업 사장들이 그러하듯, 돈만 많고 IT는 전혀 몰라... 하는 식으로 접근하면 제대로 된 일을 따기란 불가능 하다고 생각하면 된다. 예전엔 먹혔지만 요즈음엔 다들 영악해서 일을 따더라도 헐값에 처리하거나 갑자기 다른 업체로 넘어가기도 한다.

쉽게 표현해 보자.

이런 경우 use case는 requirements 단계에서 작성하는 것이 아니게 된다.

어려운 용어는 SDS 단계에서 고려하는 것이 맞다. 그리고 졸라맨(Actor)이 "어라? 저게 뭐지 하면 안된다.

다시 그리면 다음과 같다. Visual Studio 2015 Enterprise 버전에서 그렸다.

액터에 이름을 따로 붙이지 않더라도 그냥 사람으로 생각이 될 것이고(그림부터가 사람)

사람 1과 2가 상호 작용을 할 수 있는데 사람 1, 2는 대부분 같은 기능을 공유한다.

사람1의 경우 메세지를 공유할 수 있지만 사람2는 메세지를 공유 할 수 없다는 것도 알 수 있다.

똑같은 기능이라도 여러번 그릴 수 있다. 목적은 내가 잘 그리느냐 못 그리느냐는 것이 아니라 사용자의 IT 지식 수준을 맞추고 이해시키는 것이 주된 목적이다.

그래서 요구사항 정의 단계에서 가장 먼저 선행되는 것은 용어의 정의, 용어의 명확화, 커뮤니케이션 할 때 빈번하게 나올 법한 

최소 개체에 대한 학습과 same page에 있기 위한 훈련이다.

사실 개발 전단계의 워크샵이 이런 것을 논의하기 위해 가는 것인데 뭐, ... 대부분 술먹고 놀자하고 끝나버린다.

사실, 회사가 아니라 조직이다.

구글과 페이스북을 유지하는 주요 수입원은 아이러니하게도 광고 이다. 수년 전에 회사 분석용으로 자료를 작성한 적이 있었는데, 80% 이상이 광고 수입으로 나왔다.

많이 놀랐었다. 회사를 유지해주는 주수입원이 광고라니...

구글은 

세계 광고 협회에도 https://iaaglobal.org/ 에도 가입되어 있다. 

DAA 라는 것도 있다.

https://youradchoices.com/about

구글 광고가 지능적으로 노출되는 이유는 우리 컴퓨터에 남겨진 쿠키 때문이다. 쿠키는 로컬에 저장되는 웹상의 내 기록이며 쿠키를 남기지 않기 위해서는

크롬의 secret browser 기능을 이용하면 된다. cmd+shift+N 을 누르면 된다는 말. 윈도우는 아마 Ctrl+shift+N 일 것이다.

자신의 쿠키를 분석해 보려면 

http://optout.aboutads.info/?c=2&lang=EN

이 사이트를 이용하면 된다.

친구가 자꾸 페북, 구글은 일루미나티가 운영한다고 하는데, 내 생각은 좀 다르다.

광고주가 운영한다.

현실적 이야기가 무조건 1등을 해야 내가 생각하는 방향과 맞아 떨어진다고 생각을 했다.

모수 파악을 위한 최소 샘플링 개수는 아니더라도 충분히 내 생각과 맞아 떨어져서 무릎을 탁! 치게 되었다.

사회를 이루는 다수는 평범한 직장 생활을 하는 사람. 그런 평범한 사람도 강한 힘을 가질 수 있다는 나의 목표에 대한 항해도

순조롭게 나아간다. 모든 등수가 딱 내가 생각한 대로다. 소~~~름.

그나저나 수익은 0이다.

그래도 이대로 가즈아~

사실 그 동안 많은 변화가 있었는데 수없이 많은 요구사항에 미친 듯이 UI를 찍어내다 보니 결국 기존 배웠던 지식과 융합이 되고 네이밍도 그와 비슷하게 되고 있다.

class InsidePanel1 : UIView {

    lazy var leftStackView : UIStackView = {

        let ret = UIStackView()

        ret.axis = .vertical

        ret.distribution = .equalSpacing

        ret.alignment = .center

        ret.spacing = 1

        return ret

    }()

    lazy var background_view : UIView = {

        let ret = UIView()

        ret.backgroundColor = UIColor.white

        return ret

    }()

    var item1 = UILabel()

    var img1 = UILabel()

    var item2 = UILabel()

    var item3 = UILabel()

    func entry() {

        self.addSubview(leftStackView)

        leftStackView.snp.makeConstraints {

            $0.width.equalToSuperview()

            $0.height.equalToSuperview()

            $0.top.equalToSuperview()

        }

        leftStackView.translatesAutoresizingMaskIntoConstraints = false

        item1.text =

.

.

.