• 정보통신분야 기술사 훑어보기
• 정보통신분야 기술사 출제기준
• 기술사: IT경영
• 기술사: 융합 IT
• 기술사: 프로젝트관리
• 기술사: 소프트웨어 공학
• 기술사: 정보보안
• 기술사: 데이터베이스
• 기술사: 네트워크
• 기술사: 알고리즘
• 기술사: 에세이

종류​

• 정보관리기술사: Professional Engineer Information Management
  • 기존 정보처리기술사
  • 합격률 2022 5.2% 2021 8.8% 2020 7.1%
• 컴퓨터시스템응용기술사: Professional Engineer Computer System Application
  • 기존 전자계산조직응용기술사
  • 합격률 2022 12.5% 2021 11.9% 2020 18%
• 네트워크, 클라우드, 시스템 엔지니어면 컴퓨터시스템응용기술사, 나머진 정보관리기술사로.
• 기술사법으로 관리된다.

시험 관련​

출제경향​

• 60%는 거의 그대로 출제, 나머지 20%는 비슷한 유형 출제
• 총 80%가 기출 변형
• 시험관이 그때 그때마다 차출되고 해당 시점에 내고 싶은 문제를 내기 때문에 범위 예상이 힘들다.
• 기술 트랜드나 IT정책을 팔로잉하고 있어야한다.

준비물​

• 1.6mm 펜 4자루 이상: 큰 글씨 선호
  • 파일럿, 빅 볼펜이 볼펜똥이 안나옴.
  • Pilot Super Grip G
  • BIC Cristal
  • Dong-A AnyBall
  • Zebra Tapli Clip
• 모양자: 플로우차트 그리는데 필요

출제위원​

• 출제위원은 3명, 그 답안을 가지고 다른 사람 3명이 체점을 한다.
• 1교시 문제를 받자마자 교수, SI기술사, 공무원기술사일지 파악해야한다.
  • 교수: 학구적 스타일
  • SI기술사: 프로젝트를 해봤는데 이슈있는 스타일
  • 공무원기술사: 공공, 법 스타일
• 이걸 파악해서 연관된 서브노트를 쉬는 시간에 본다.
  • 평소 5년치 분석할 때에도 이런 관점에서 분석해야한다.

느낌​

• 회사에서 했었던 업무들에 대한 프레임워크들을 문서로 리뷰하는 느낌이였다.
• 이 시험은 기사처럼 암기로 되는 시험이 아니다. IT기법이 왜 그렇게 발전해왔는지, 그걸로 기업의 비지니스에 IT가 어떻게 기여했는지 산업 전반을 이해해야 답을 할 수 있다.
• 라이팅 문제처럼 에세이를 써야하고, 면접을 대비하는 것처럼 나만의 답안들을 만들어야한다.
• 장기 말에서 장기를 두는 사람을 만드는 시험이랄까.. 중인 중에서는 제일 높은 관직이지 않을까..
• 사람들을 설득하는 포지션이기에 질문에 대한 답변을 말로, 손으로, 다이어그램으로 설명할 수 있게 많이 연습해야할 것 같다.
• 손으로 작성하는게 생각보다 쉽지 않다.
• 시험의 70%가 공공 분야와 관련이 있다.
• KoreaScience의 자료가 좋다.

과정​

• 1,000 시간을 투자하면 얼추 합격한다고 한다. 9시간 투자시 4달, 보통 빨라야 6달이 걸린다.
• 토픽마다 컴포넌트 맵을 작성해야한다.
  • 정의, 필요성/목적, 배경/특징/주요 유형, 개념구성/기술구성 그림, 개념구성/기술구성 내용, 구현절차/방법론, 비교 사례/활성화/전략, 구현절차/방법론, 기대효과/발전제언
  • 토픽 이론 학습
• 서브노트를 안 쓰고 합격한 사람은 없다.
• 합격한 사람의 한 달 전 서브노트로 쓰는게 좋다.
• 한 번 포맷이 머리 속에 있으면 모든 주제에 대해 해당 포맷을 사용할 수 있다.
• 아는 걸 쓰지말고 물어본 걸 써라. 이건 목차를 잘 만들어야한다.
• 이해한 걸 중심으로 서브노트를 만들고, 1시간마다 8회 반복하면 6개월 이상 암기된다. 외우는 범위를 형광펜을 칠하며 줄여간다.
• 10가지 과목 중에 6개는 80%, 4개는 20%의 에너지로 공부해야한다. 그 중 2개는 강의할 정도로 들여다봐야한다.
• 매번 나오는 것들, 공학적인 기본기는 반드시 알아야한다. 거져주는 문제들이고, 1년에 3번 중 한 번은 이런 문제들을 잡을 기회가 온다.

국제기술사​

• 기술사상호인정 협정(MRA) 따라 가능하긴한데 미국은 1년간 미국 근무 경력 또는 비슷한 경력를 요구하여 실질적으로 전환하는 케이스는 드물다.
• 국제 기술사는 컴퓨터 관련 과를 졸업해야만 인정이 가능하다.

공부방법​

5W1H 개념, 배경, 특징, 방향 나열한 것을 묶는 연습 -> 다시 늘리는 연습 자크만 프레임워크 / 싸이클론 모델

1. 개념적 What: 무엇인가 핵심, 원리, 가치, 결어 (기술, 서비스, 절차 중 하나)
2. Why: 왜 필요한가
3. 구체적 What: 세부구성은 무엇인가 아키텍쳐, 구성도 (개념도), 구성요소 (소스, 매커니즘, 결과)
4. How: 어떻게 구현하는가 Provider, Consumer 관점, 이전에는 뭐가 있었는지
5. Who: 누가 찾고, 활용하는가
6. 결론: 향후방안, 예상 이슈, 발전 방향

예시: ML​

• 개념적 What
  • 핵심
    • 기계
    • 학습
      • 지도
      • 비지도
      • 강화
    • 데이터
  • 원리: 기계가 많은 데이터를 지도, 비지도, 강화학습을 통해 학습하여
  • 가치: 사람 대신 판단하여 의사결정을 지원하는
  • 결어: 기술
• Why
  • 비용절감
  • 자동화
  • 편의성 (의사결정)
    • 생산성 증가
    • 품질 증가
• 구체적 What
  • 아키텍쳐
    • 학습데이터 -> 지도/비지도/강화 -> 대시보드, 자동화도구
• How
  • 동작원리
  • 절차
  • 적용방법
• Who
  • 개인 Personal Assistant
  • 기업
    • 의사결정
    • 고객관리
    • 마케팅
    • 생산
  • 공공 서비스
    • 교통
    • 안전
    • 환경
• 향후방향
  • 예상이슈
    • 편향적 판단
    • 적대적 공격
    • 검증
  • 발전방향

예시: 개념도​

입력(사용자) / 프로세싱(플랫폼, 기술) / 출력(서비스)
<---------><------------------><--------->

자크만 프레임워크​

싸이클론 모델​

RTE 를 만들기 위한 비지니스 + 기술 리더의 자세로 토픽을 고민해야한다.

• Lead: 기술사
• Manage: 관리자
• Operation: 개발자

토픽별 전략​

보안 토픽​

• 리스크 -> 결과 -> 더 많은 대응책
• ISMS 목차를 외우면 대부분의 보안문제를 풀 수 있다.

거버넌스 토픽​

• 전략 -> 가치 -> 위험 -> 자원관리 -> 성과관리

융합IT 토픽​

• 원칙 문제들은 나의 의견과 응용 포인트를 결론에다가 달아줘야한다.
  • 국가: 법 제도 정비
  • 서비스제공자: 개선 포인트
  • 사용자: 자세, 기준
• IaaS / SaaS 표준 (+PaaS) / SaaS 간편 / DaaS
  • 코로나 / 재택근무 도입으로 인한 DaaS의 중요성 대두

참조​

• Gartner: The Real-Time Enterprise Cyclone Model
• ITPRO: 데이터베이스 시리즈 2023

개요​

출국장에서는 체크인, 탑승구, 출국심사, 수하물까지 네 번의 큰 기다림이 있다.

이 중 체크인은 셀프체크인이 지원되는 항공사면 빠르게 건너뛸 수 있지만 나머지는 많은 기다림이 필요하다. 스마트패스 앱을 사용하면 출국장-탑승구의 긴 줄을 건너뛸 수 있다.

단계​

집​

집에서 앱을 다운받고 여권을 등록해둔다. 아래 상태가 되면 된다.

체크인 후​

체크인 후 종이 티켓을 받으면 탑승권 등록 > 내 스마트패스 ID > 종이 탑승권의 바코드 스캔에서 바코드를 스캔하면 끝이다.

탑승구 입장​

탑승구로 들어갈 때 바닥에 보면 스마트패스 전용 라인이 있다. 거기에 앱을 인식시키고 얼굴도장 찍고 들어가면 된다. 나는 줄이 아예 없었다. 사람들이 많이 기다리는 줄 뒤에 서있지 말고 탑승구 게이트쪽을 먼저 어슬렁거려보자, 찾기 힘들다면 공항직원에게 물어보자. 스마트패스는 앞으로 가세요 라고 바로 알려준다.

후기​

30분 이상 출국장 탑승구 앞에서 기다려야하는게 보통인데, 이 시간을 놀이공원의 매직패스처럼 빠르게 건너뛸 수 있다. 빨리 들어가서 면세점을 둘러볼 수도 있고, 앉아서 쉴 수도 있으니 해외로 나갈 땐 필수인 것 같다.

김포공항에서는 생체정보 인증이 있는데, 그거는 공항애서 미리 해두면 다음 번부터 제주도 갈때 엄청 편해진다.

시제​

• 현재: 사실, 반복
• 현재진행: 동작 강조
• 과거: 과거에 끝난 것
  • was going to: 하려고 했지만 실제론 하지 않은 일
• 과거진행: 과거에 뭘 하고 있었는지 강조
• Used to: 그랬었지~ 해오곤 했었지~ 지금은 안함
• 현재완료
  • 계속 쭉 해오고 있는 것, for/since
  • 경험 해본적이 있는 것
  • 결과 과거의 행동이 현재와 관련이 있는 것, just/already/yet
• 미래
  • will: 예측, 결정한 일
  • be going to:
    • 이미 하기로 결정한 미래의 일
    • 현재 상황을 근거로 미래에 일어날 일을 예측할 때
  • 현재진행: 구체적인 계획/약속/예약
  • 현재: 미래 사실로 시간표/일정 상의 일, 주로 사물 주어
  • be about to: 막 ~하려고 하다, 매우 가까운 미래
• 미래 진행: 미래 특정한 시점에 진행되고 있을 일을 말할 때
• 미래 완료: 미래의 특정한 시점까지는 어떤 일이 완료되었을 것이라고 말할 때
  • by the time: ~할 때쯤 으로 같이 자주 쓴다.
    • By the time the meeting starts, we won't have prepared the sales report.
    • I'll have learend a lot by the time I complete this course.

현재완료​

• ever: 지금까지 (한 번이라도)
  • Have you ever baked muffins?
• never: 해본 적이 전혀 없다.
  • I've never baked muffins.
• have been: 가 본적이 있다.
  • I've been there
  • I haven't been to Paris.
• has gone: 가고 없다.
• 경험의 횟수: once, twice, three times, four times, many times.
  • 이럴 때만 times 를 복수로 씀.
• The best ~ I've ever ~: 지금까지 내가 ~ 해본 최고의 ~
  • That is the best story I've ever heard.
  • It was the best experience I've ever had.

현재완료진행​

• 과거에서 시작해서 지금도 진행 중인 일
• for, since, how long
  • since: 특정 시점 필요 (since noon, since May, since 5 o'clock)
• 과거에서 시작해서 진행되어 오다가 방금 전에 끝난일이 지금까지도 영향을 미치고 있을 때
  • Your eyes are red. Have you been crying?
• 진행으로 못 쓰는 동사들: 동작을 나타내지 않음
  • know, remember, understand, believe, agree
  • want, need, love, like, hate,
  • own, possess, belong, contain

미래​

• 시간, 조건 뒤엔 현재가 온다.
• when, while, before, after, until, if

조동사​

• Can: 동사에 강세
• Can't: Can't 에 강세
• Can I: 해도 될까요?
• Can you: 해줄래요?
  • Could: 능력/허락/가능성/추측
  • was/were able to: 특정 상황에 실제로 성공적으로 어떤 일을 해냈다.
    • Our best player didn't play, but we were able to win the game anyway.
  • have/has been able to ~: 특정 시점 이후로 쭉 할 수 있다.
• Must: 확실한 추측, 규정, 규칙
• Have to: ~해야한다
  • don't have to: 할 필요가 없다.
  • didn't have to: 할 필요가 없었다.
  • Did ~ have to
  • will/might have to
• S should R: R 하는 것이 좋겠다.
• Should I: 하는 것이 좋을까요?
  • I think ... should
  • I don't think ... should
• Would you: 해주시겠어요?
• Would you like N: N를 드릴까요?
• Would you like to R: R 하실래요?
• I would like N: N을 주세요.
• I would like to R: R를 하고 싶어요.

could​

• could belong to S.O.: ~의 것일지도 모른다.
• could R: ~할지도 모른다.
• couldn't R: ~할리 없다. (~하는 것이 사실상 불가능하다.)
• could have p.p.: ~했을지도 모른다. 할 수도 있었지만 하지 않았다.
• couldn't have p.p.: ~했을 리 없다. (사실상 불가능했음.)
  • She finished all of her work in just one day. She couldn't have done it alone.

might​

• might R: ~할지도 모른다.
• might not R: ~하지 않을지도 모른다 (그러나 ~할 가능성도 있다)
• might have p.p.: (과거에) ~했을지도 모른다.
• might not have p.p.: (과거에) ~하지 않았을지도 모른다. (했을 가능성도 있음)

should​

• should: ~하는 것이 좋겠다.
• should I/we ~?: ~하는 것이 좋을까요?
• should have p.p.: (과거에) ~했어야 했다. (그러나 하지 않았다.)
• shouldn't have p.p.: (과거에) ~하지 말았어야 했다. (그러나 했다.)
• We should attend: 참석하는 것이 좋지만 반드시 참석해야하는 건 아님
• All employees must attend: 반드시 참석해야함.

had better​

• you'd better, we'd better: ~하는 것이 좋겠다. (강한 충고)
• had better not: ~하지 않는 것이 좋겠다.
  • You'd better not sit there.
• had better: 어떤 일을하지 않으면 좋지 않은 결과가 생길 것
  • Tickets will be sold out soon. You'd better buy some today.
• should: 반드시 해야하는 건 아니지만 어떤 일을 하는 것이 좋겠다는 의견
  • You should buy those tickets. The seats are closer to the stage.

수동태와 조동사​

• will/can/must + be + p.p.

의문문​

• Which: 제한적으로 주어진 몇 가지 중 선택, 어떤~
• What: 선택 제한이 없는 경우, 무엇~ 몇~
• Where ~ from?: ~ 는 어디에서 왔나요?
• How be동사: ~ 은 어떤가요?
• How 형용사/부사: 얼마나 ~
• Be 동사 뒤에 오는 건 보어, 목적어 아님.

What​

• What ~ for?: ~은 무엇을 위한 건가요?, 뭐 때문에 ~하나요?
  • What's this button for?
  • What did you hit me for?
  • What was the cake for?
• What ~ like?: ~은 어떤가요?
  • What is your boss like?
  • What is it like?
  • What was your first date like?

동명사와 to부정사​

• ~ 는 것, ~ 기
• 주어는 동명사만
• Enjoy 는 동명사가 따라옴

동명사만 따라올 수 있는 경우​

• enjoy
• finish
• keep
• mind
• avoid
• give up
• practice
• suggest

to부정사만 따라올 수 있는 경우​

주로 미래: 기대, 소망, 계획, 제안

• want
• need
• hope
• expect
• decide
• plan
• promise
• offer
• choose
• ask
• learn
• refuse

둘 다 오는 경우​

• like
• love
• prefer
• hate
• start
• begin
• continue

의미가 달라지는 경우​

• stop
  • -ing: ~ 하는 것을 멈추다
  • to R: ~ 하려고 하던 걸 멈추다
• try
  • -ing: 시험삼아 ~ 해보다
  • to R: ~ 하려고 노력하다

사역동사​

• have/make/let + 사람 + R: ~ 가 ~ 하게 하다.
• help + 사람 + R: ~ 가 ~ 하는 것을 돕다.

to부정사​

• ~ 하기 위해 (in order to R), 추가적으로 덧붙힐 때
• N + to R: ~ 할 N

수​

U​

• a glass of water
• music
• snow
• sugar
• air
• time
• money
• news
• a cup of coffee
• a loaf of bread

예외​

단복수 같은 단어​

• a/some fish
• a/two sheep
• a/many deer

항상 복수​

두 개의 부분이 모여서 하나의 시물을 이루는 경우

• pajamas
• scissors
• jeans
• shorts
• glasses
• pants
• headphones

위의 명사의 복수형은 a pair of/two pairs of.

관사​

• a/an: 특별히 정해지지 않은 막연한 사람 또는 사물 하나
• the: 어떤 사람, 사물을 가리키는지 명확할 때, 특정 사람 또는 사물을 말할 때
  • 어떤 대상에 대해 처음 말할 때는 a/an, 반복할 때는 the
  • I got an e-mail from S.O. The e-mail was about today's meeting.

The​

필수​

• 세상에 하나 밖에 없는것: the world, the sun, the moon, the earth
• 자연환경: the sky, the sea, the ocean
• 국가/도시 등에 하나 밖에 없는 것: the army, the police, the government
• 방송, 매체: the radio, the internet
• 악기를 연주한다고 할 때 악기 이름 앞에: the guitar, the piano
• 특정 장소 갈 때
  • go to the movies
  • go to the station
  • go to the bank
  • go to the theater
  • go to the airport
  • go to the post office
• in the past, in the future
• the same, the only, the next, the last

사용 안하는 경우​

• 운동: basketball, football, tennis
• 과목: biology, history, marketing
• 식사: breakfast, lunch, dinner
• 집에 있는 경우: go home, at home
• 출퇴근: go to work, at work

비인칭 주어​

• 시간을 말할 때: It's 5 o`clock.
• 날짜를 말할 때: It's August 8.
• 요일을 말할 때: It's Friday.
• 날씨를 말할 때: It's rainy today.
• 거리를 말할 때: It's about 10 kilometers.
• 계절을 말할 때: It's almost spring.

소유격​

• I my mine
• We our ours
• You your yours
• He his his
• She her her
• They their theirs
• 소유격 뒤에 명사를 쓰지 않음.
• 관사 없음.

재귀대명사​

• by -self: 혼자, 스스로: I've lived by myself since 2015.
• Make yourself at home: 편히 쉬세요.

one​

• 앞서 말한 명사를 다시 말할 때 명사 대신 사용: one, ones
• a(n)/the + ADJ + one
• some/the + ADJ + ones
• Which one(s) ~?: 어느 것(들) ~?

한정사​

some, any​

• some, any: 사람 또는 사물의 불특정한 수나 양에 대해 말할 때 명사 앞
• some: 주로 긍정문, yes를 기대하는 권유/요청하는 의문문
• any: 주로 부정문, 의문문
• someone/somebody, anyone, something, anything, somewhere, anywhere: 누군가, 무언가, 어딘가란 의미로 정확히 알 수 없는 사람, 사물, 장소에 대해 말할 때
• someone, something: 주로 긍정문, 권유/요청하는 의문문
• anyone, anything: 주로 부정문, 의문문

no​

• ~ 이 없다
• no + N = not ~ any + N = none
  • I have no questions. = I don't have any questions.
• none: 대명사라 명사와 함께 사용하지 않음.
• no one/nobody, nothing, nowhere: 아무 ~ 도 ~ 않다.

many, much​

• many + [C] PL: 많은 ~, 긍정문, 부정문, 의문문
• much + [U]: 많은 ~, 주로 부정문, 의문문
• 둘 쓰는거 헷갈리므로 회화에서는 a lot of, lots of 활용하는 게 좋음.
• 대명사로도 사용 가능
  • She grows many.
  • There isn't much.
  • You already have a lot.

few, little​

• a few + [C] PL
• a little + [U]
• few + [C] PL: 거의 없는, 부정문
• little + [U]: 거의 없는, 부정문
• A few people came: 몇 명의 사람들이 왔어.
• Few people came: 거의 안 왔어.
• I have a little time: 약간의 시간이 있어.
• I have little time: 시간이 거의 없어.
• 대명사로도 사용 가능

all, every​

• 모든 ~
• all + [C] PL / [U]
• every + [S]
• all + day, week, month: ~ 종일, ~ 내내
• every + day, week, month: ~ 마다, 매 ~
• everyone/everybody, everything, everhwer: 모든 ~ (사람, 사물, 장소)

Both, either, neither​

• both + [C] PL: 둘 다, 두 ~ 모두
• either + [S]: 둘 중 아무 것이나 하나, 두 ~ 중 아무 것이나 하나
• neither + [S]: 둘 다 아닌, 두 ~ 모두 아닌

all of, most of, some of, none of​

• all of: 전부
• most of: 대부분
• some of: 약간
• none of: 없음
• all/most/some/none of: 특정한 대상에 대해 한정적으로 말할 때
  • the/my/these + N
  • it/us/you/them
  • all of the people --- All people
  • most ot these cars --- Most ccars
  • some of the songs --- some songs
  • none of the books --- No books
• all/most/some/no + N: 일반적인 대상에 대해 말할 때
• both/either/neither of
  • the/my/these + [C] PL
  • us/you/them

지각동사​

• 2형식, 보어(형용사) 필요
• look + ADJ: ~해 보이다
• smell + ADJ: ~한 냄새가 나다
• sound + ADJ: ~하게 들리다
• taste + ADJ: ~한 맛이 나다
• feel + ADJ: ~하게 느끼다

부사​

• 형용사 앞에서 꾸민다.
• 동사 앞 뒤에서 꾸민다.
• ly 패턴이지만 형용사인 것
  • friendly
  • lovely
  • silly
  • ugly
  • lonely
• 형용사는 사람이나 사물이 어떠한지
• 부사는 행동이나 일이 어떻게 일어나는지

형용사면서 부사인 것​

• late: It's late / I got home late.
• long: You have long hair / It doesn't take long.
• hard: He is a hard worker / The baseball team is practicing hard.
• fast: Her car is fast / She talks fast.
• early: I had an early breakfast / Nicole arrived early for her interview.

빈도부사​

• always, usually, often, sometimes, rarely, never
  • rarely, never 는 부정문
• 일반 동사 앞, be동사 뒤, 조동사 뒤, have/has 와 p.p. 사이

too​

• too + ADJ/ADV
• too + ADJ + for + S.O.: ~ 에게 너무 ~ 한
• too + ADJ + to R: ~ 하기에는 너무 ~ 한
• too many + [C] PL: 너무 많은 ~
• too much + **[U]: 너무 많은 ~
• 대명사로도 사용 가능: I spent too much last month.

enough​

• ADJ/ADV + enough: 충분히 ~ 한/ ~하게
  • ADJ + enough + for + S.O: ~ 에게 충분히 ~ 한
  • ADJ + enought + to R: ~ 하기에 충분히 ~ 한
• enough + [C] PL / [U]: 충분한 ~
  • enough + N + for + S.O: ~ 에게 충분한 ~
  • enough + N + to R: ~ 하기에 충분한 ~
• 대명사로도 사용 가능: I have enough.

so​

• so many + [C] PL
• so much + [U]
• There were so many. / I've learned so much from him.

비교​

• 일반적으로 형용사/부사 뒤에 -er
• 비교급 + than ~: ~ 보다 더 ~한 / ~ 하게
• 긴 단어 (3음절 이상): more ADJ/ADV
• 불규칙
  • good / better
  • bad / worse
  • far / farther

최상급​

• 일반적으로 형용사/부사 뒤에 -est
• 2음절 이상 앞에는 most
• 명사 없이 최상급만 사용하는 것도 가능: I'm the youngest in my family, That's the cheapest in the store.

as - as​

• as + ADJ/ADV + as: ~ 만큼 ~ 한 / ~ 하게
• not as + ADJ/ADV + as: ~만큼 ~하지 않은 / ~ 하지 않게
  • 비교 위치 바꿔서 비교급 + Than 도 가능
• as ~ as possible: 가능한 한 ~ 하게

전치사​

장소 전치사​

at​

• 직장, 학교 등: at work, at home, at school, at church, at the doctor's (office), at somebogy's (house)
• 역, 공항: at the station, at the airport
• 행사, 공연, 경기: at a party, at a concert, at a baseball game

in​

• 하늘, 대양 등 자연환경: in the world, in the sky, in the ocean
• 책, 사진 등 인쇄물: in a book, in a picture, in a newspaper
• (어떤 장소에서) ~하는 중인: in bed, in the hospital,, in prison, in jail
• in the car, in the taxi

on​

• 거리: on 2nd Avenue, on Main Street
• 층: on the first floor, on the 3rd floor
• 교통수단: on the train, on the bus, on the plane

방향 전치사​

• form
• to
• up
• down
• into
• out of
• over
• under
• through
• across
• along
• around
• on
• off: ~에서 (떨어져)
• past: 지나서, 지나친 것은
• toward: ~쪽으로

시간 전치사​

at​

• 시각: at 10:30, at noon, at 3 o'clock
• 식사: at breakfast, at lunch, at dinner
• at night

on​

• 요일: on Wednesday, on Friday night
• 평일, 주말: on weekdays, on a weekday, on weekends, on the weekend
• 날짜, 기념일: on May 21, on my birthday, on our anniversary

in​

• 월, 계절: in January, in spring, in the summer
• 세기, 연도: In the 19th century, in 2018
• 오전, 오후, 저녁: in the morning, in the evening

during​

• 언제 일어났는지를 말할 때

for​

• 얼마나 오래 계속되었는지를 말할 때
• p.p. 와 많이 씀

in​

• in + 기간: ~ 후에
• in 10 minutes, in two hours

within​

• within + 기간: ~ 이내에
• within 15 minutes, within four days

since​

• ~ 부터 (계속)
• 특정 시점부터 어떤 행동이나 상황이 계속 될 때
• p.p 와 많이 씀

by​

• (늦어도) ~ 까지
• 늦어도 정해진 시점까지 어떤 행동이나 상황이 끝난다고 할 때

until​

• ~ 까지 계속
• 특정 시점까지 어떤 행동이나 상황이 계속된다고 할 때

-ing​

• 전치사 뒤 -ing
• without saying
• about working
• be good at singing
• by showing

형용사 전치사 패턴​

• about
  • excited about
  • sorry about
  • sure about
• at
  • angry at
  • mad at
  • good at
  • suprised at
• for
  • famous for: ~으로 유명한
• from
  • different from
• in
  • interested in
• of
  • afraid of
  • full of
  • proud of
  • short of: ~이 부족한
  • tired of: ~에 질린, sick and tired
• to
  • married to: ~와 결혼한
  • simillar to: ~와 비슷한
• with
  • busy with: ~로 바쁜
  • careful with: ~을 주의하는
  • familiar with: ~에 익숙한

동사 전치사 패턴​

• about
  • know about: ~에 대해 알고 있다
  • talk about
  • think about
  • worry about
• at
  • look at
  • shout at: ~에게 소리치다
  • work at
• for
  • apply for: ~에 지원하다
  • ask for: ~을 요청하다
  • look for: ~을 찾다, ~을 구하다
  • search for: ~을 찾다
  • wait for: ~을 기다리다
• on
  • deponed on
  • spend ... on: ~에 (돈, 시간) 을 쓰다
• to
  • belong to: ~의 것이다, ~에 속하다
  • happen to: ~에게 일어나다
  • listen to
  • talk to: ~에게 말하다
  • write to: ~에게 편지를 쓰다
• 🚫
  • answer: ~에 답하다
  • call: ~에 전화하다
  • discuss: ~에 대해 논의하다
  • reach: ~에 도착하다, ~에 닿다

구동사​

• on
  • get on: ~에 타다
  • hold on: 기다리다
  • try on: ~을 입어보다, ~을 써보다
  • turn on: ~을 켜다
• out
  • eat out: 외식하다
  • get out of: ~에서 내리다
  • go out: 밖으로 나가다, 외출하다
  • hand out: ~을 나눠주다
  • take out: ~을 꺼내다, ~을 빼다
• up
  • clean up: ~을 청소하다
  • get up: 일어나다
  • wake up: 깨어나다, ~을 깨우다
  • pick up: (전화기 등)을 들다, ~을 사다
• 대명사를 목적어로 쓰는 경우는 동사와 on/off/up 등의 사이에 쓴다.
  • take if off
  • clean them up
• 나머지 경우는 두 패턴으로 사용 가능
  • turn your phone off
  • turn off your phone

접속사​

• 문장에 명사를 덧붙힐 때: 전치사
• 동사를 덧붙힐 떄: to부정사
• 문장을 덧붙힐 때: 접속사
• because + 문장, because of + 명사
• while: ~하는 동안
• when, while 다음에 미래의 일을 말할 때에는 미래 시제가 아니라 현재 시제
  • What do you want to be when you grow up?
  • It'll be warm while we are on vacation.
• before, after 뒤에 명사 또는 -ing 가능
  • before midnight.
  • before signing it.
  • after dinner?
• since: ~ 이후로 지금까지, 이래로
• until: ~할 때까지 (계속)
  • until 다음에 미래의 일을 이야기할 때는 현재 시제 사용
  • Please don't leave your seat until the bus stops.
• since, until 뒤에 명사 가능
  • since thier wedding.
  • until next Thursday.

가정​

• if 현재, will/can + R: ~하면 ~할 것이다.
  • 일어날 가능성이 있는 경우
• if 과거, would/could + R: 만약 ~한다면 ~할 텐데
  • 가능성이 없는 경우
  • 이 경우 were 를 선호함
  • If I were, If she were, If Jerry were

관계대명사​

주격​

• 뒤에 동사가 나오면 주격
• who/which/that

목적격​

• I love the food. she made it
  • I love the food which she made.
  • I love the food she made.
• 뒤에 주어 동사가 나옴
• 생략 가능 (관계대명사를 주어로 쓰지 않는한)

there​

• There + be동사: ~이 있다
• There was/were: ~이 있었다.
• There have/has been: ~가 있던 적이 있다.

4형식 동사​

• give: ~에게 ~를 주다
• make: ~에게 ~를 만들어주다
• send: ~에게 ~를 보내다
• show: ~에게 ~을 보여주다
• buy: ~에게 ~을 사주다
• teach: ~에게 ~을 가르치다
• give/send/show/teach + 사물 + to + 사람
• make/buy + 사물 + for + 사람 (정석적인 느낌)

권유​

• Let's + R: (함께) ~ 하자
• Let's not + R: ~하지 말자

감탄​

• How + ADJ
• What (a/an) + ADJ + N

말 전달​

• said that + 과거
• told 사람 that + 과거

동의​

긍정​

• too: 긍정문
  • I do too.
  • I have too.
• So + V + S: ~도 역시 ~하다.
  • So was I.
  • So did we.
  • So can his brother.

부정​

• either
  • He wasn't either.
  • I haven't either.
• Neither + V + S: ~도 역시 ~하지 않다.
  • Neither do I.
  • Neither have I.

Read replica​

• I thought it didn't exist due to the Support for Read Replicas #172 issue.
• But it is provided in the form of middleware at prisma/prisma-read-replica-middleware.
• e.g. prisma/middleware-examples/prisma-read-replica-middleware

Data sources​

• In the schema.prisma file, there can only be one datasource column.
• In case the data source changes, the migration.lock file must be deleted and the migration process must be run again.

Polymorphism​

• Support for Polymorphic Associations #1644 It seems there is no current plan to support this.
• Polymorphic relationships are necessary in normalization but it de-normalizes by adding information to the column.

Overview​

• At one point, redux-saga seemed like a cool way to solve redux's tired state management, and then a combination of atomic states seemed like the way to go.
• That's why I've mostly used recoil, but if you're using query or swr, you don't need such a complicated feature to manage local UI state.
• recoil seems to be an almost abandoned project with only bug fixes in the meta. discussion#2171
• Anyway, local UI state just needs to have a pub/sub pattern.
• The winner of the 2023 state management library seems to be zustand.
  • If you're building an event/messaging based system, it makes sense to use that library with the Flux pattern.
  • If you're building an editor with action-based behavior for all front-end features, or if you're integrating with a chat system that receives function call requests, that's one thing.
• But for a typical use case, Flux is overkill, except for cascading forms, badges, modals, etc.
• If I were developing alone, I would want to separate the backend from the frontend, separate the Local, Dev, Stage, and Prod stages, and have a DB, scheduler, queue, API, and SSR stack.

atom​

• Read first; The new wave of React state management을 보자.
• Atomic, pub/sub, and derived are possible.
• Using derived state is also rarely necessary unless you need a new state per ID. For data, query already does the job.
• Atomic design and atomic state management became a necessity.
• With many developers working asynchronously, it was important to keep track of which files were atoms and what they were for.
• We have a *.atom.ts file superfix and a *State variable name superfix.

valtio​

• Both jotai/atom and Recoil/atom manage atom-based state and propagate state.
• valtio/proxy implements the same functionality using Proxy and Reflect.
• Memory management is not the worst, as you can see from the Results for js web frameworks benchmark.
• zustand, jotai, and valtio are all open source, covered by the pmndrs community, with the same person as a contributor and maintainer.
• It just works, as his comments in valito/discussion#128 show.
• valito/issues#141 Having spent a year on Redux and Redux-saga, and two years on Mobx POC and Recoil, this comment really resonated with me.
• For the time being, I'm going to create several projects and try to use this state management library in all of them.

Programmer​

What is a programmer?

• People who like to categorize will call it a coder, developer, or engineer.
• To strangers, it may seem like a job that pays a lot of money, or that you have to pay on demand,
• To an employer, you're a mechanic.

What does this job mean to me?

• At the point where your short-term memory turns into long-term memory, you suddenly have an idea that will solve everything and you grab the keyboard.
• Throwing myself into a gradient descent and not getting out of my chair until I hear the birds in the morning.
• You want to code so badly that you can't because you're required to take a liberal arts major.

These days, I tell stories like this.

I build houses on the internet.

• Front-end? That's interior construction.
• Backend? That's tooling and gutting.
• DevOps? That's digging and rebarring.
• Security? That's keeping unknowns out of the complex.

Programming is about borrowing concepts from the real world to automate what humans do, and I feel like it took me too long to realize this.

I finally understand why so many of my professors used to tell me that the more you know, the more important the basics are. I can see why so many of my professors used to say, "The more time you have, the more important the basics are.

Programming​

Do programming skills matter in the age of GPT?

My answer is no. There comes a point where the idea of the service is more important than the technology stack. Even people who have never heard of Claude Shannon can create a service, and edge computing has made it possible to deploy that code.

You can't say, "If you go this way, it's going to fall apart at some point. You can't pour gasoline on a burning house and then say, "I told you it would happen.

The social climate is making it more so.

Technology stack​

All technology is a tradeoff.

New things always cost money. You have to look at it from the perspective of staff skill and maintenance.

I think, This is not an academy, if you want to write something new, use your personal time and show me a prototype in a week, but there are also people who think, Who am I studying for?

This is why software engineering is so important.

My utopia​

So what was it that I didn't like, I don't even know if it was bad construction. You may not know. But not being able to say it's bad construction is overloading my body.

To keep myself from stressing out, I'm going to keep a checklist of ideal features.

• Do we have a code owner feature? Have we created a culture where certain code changes can be reviewed by a per-file owner?
• What is the average number of comments in a code review?
• What is the branching strategy?
• Are unit tests run in the pipeline, and if so, what is the coverage?
• Are integration tests based on real data executed in the pipeline, and if so, what are the criteria for inclusion in the integration tests?
• Are E2E tests executed periodically, and if so, who is responsible for managing them?
• Are cases given enough time to be implemented before going to test driven?
• Do they perform chaos testing for external factors? Do they recognize the need for disaster recovery?
• How is open source managed? Is the software versioned on a specific cycle?
• Do developers manage their own Docker files and deployments, and if not, who does?
• Is there support from the systems team to configure a private network? If not, is there an environment where a VPC can be configured?
• What is being done mechanically to maintain the quality of the code, such as lint and static analysis?
• If there is a failure, is the failure publicized and a failure report created?
• Does everyone in the team have ownership of the service?
• What is the SLA for the services you represent? What is the frequency of OOM failures or top 500 failures?
• Is the SLA a standard for the HR department?
• Is the direction of the owner visible to all members?
• Are decisions made based on data? What tools are used to collect logs?
• Is the logging format standardized with Open Telemetry, and if not, what format is being managed?
• Collecting web metrics?
• Is there a foundation for A/B testing to introduce features? If not, how is the HR department involved in planning?
• Using a design system?
• Are Storybooks managed in the same repository?

Overview​

• Yarn berry was all the rage.
• I tried it and found quite a few problems, which is why I ended up choosing pnpm.

Problems​

zipfs​

• It stores all the packages and logs all the diffs. This is a major culprit for repository size. Difficult to manage images under 1GB.
• If typescript goes up, yarn berry version should go up. I want to use the latest syntax in typescript right away, but I can't keep up.
• I need to update the executable with yarn dlx @yarnpkg/sdks vscode whenever typescript, eslint, and prettier are released.
• In a project with 20+ front-end developers, this is hard to enforce.
• It is not possible to test this by making small changes to the source inside the package.

opensource​

• Monolithic tools like turbo, environments with postinstall hooks like prism, or preset configurators like create-* reference node_modules directly.
• Often it won't even run, and you'll have to wait for an open issue in each repo. I'm not writing this to analyze yarn berry's pnp script.
• In this case, I'd have to give it a nodeLinker and use it the same way I would with yarn 1, with no advantage.

workspaces​

• The yarn workspaces feature is cool, and yarnpkg/berry is a perfect example of it.
• But it's only cool if you're only developing node.js libraries. Libraries for the frontend need a bundler, and there's no reference for that.

Benchmarks​

• Benchmark scores are managed by Pnpm on a daily basis.
• Slowness is acceptable with pipeline cache and lock files enabled. It's a one-time slowdown, not a request/response slowdown, so it can be handled by probes anyway.

Conclusion​

• The plugin features in yarn berry are cool, but they add more stress to dependency management.

Overview​

• The programmers who are good at asking questions and quickly determining if the answers are right or wrong will be the ones who survive.
• Here's a list of repositories that can be used in the field, not just for development tips.

aicommits​

• Nutlope/aicommits: Automated commits.
• As soon as #32 Add support for conventional commits is resolved, I'll be using it.
• Personally, I think the following prompts should be changed, but I'm also curious about how to improve them.
• #177 feat: enable Conventional Commits standard as flag I think it's coming soon.

const promptTemplate =
  "Write an insightful but concise Git commit message in a complete sentence in present tense for the following diff without prefacing it with anything:";

• #81 Quick improvement suggestion: Reduce diff size with --ignore-all-space is also interesting.
• Since the Openai API is billed by the number of tokens, it looks like they plan to reduce the diff as much as possible.

node chatgpt​

• transitive-bullshit/chatgpt-api
• openai: docs
• I think we need to utilize completionParams appropriately.
• I checked several third parties and none of them give temperature as 1.

const completionParams = {
  temperature: 0.7,
  top_p: 1,
  frequency_penalty: 0,
  presence_penalty: 0,
};

tiktoken​

• You may need to get the exact number of tokens to use the openai API.
• You should use openai/tiktoken, but it's Python.
• dqbd/tiktoken already has a node wrapper already out there. 3.5 Turbo support

import { encoding_for_model as encodingForModel } from "@dqbd/tiktoken";

const encoder = encodingForModel("gpt-3.5-turbo");
const tokenLength = encoder.encode("YOUR_CHAT").length;

chatgpt-retrieval-plugin​

openai/chatgpt-retrieval-plugin

• ai-plugin.json in the .well-known path acts as a manifest.json
• Openapi.yaml in the same path for this endpoint specification
• There are four types of authentication: none | user_http | service_http | oauth.
• For simple services, service_http seems to be sufficient, user_http requires the customer to enter an API key, and oauth requires additional permissions such as search:read.
• It seems to use Vector DB for document similarity comparison, but there is no proper Node.js wrapper for it, so it can be implemented in Redis, but you need the Redisearch module.
  • datastore/providers/redis_datastore.py
  • services/openai.py

백년허리​

I got a herniated disc from Sumo-deadlift, and I think it would be good for many people to read this before it happens. If I had, I would have had a good posture before the disc between L5-S1 came out.

The overall content is a book review of 백년허리 to protect spinal hygiene.

Diagnosis​

• Vertebrae: Cervical, thoracic, lumbar, sacral, and coccyx
  • The cervical and lumbar vertebrae are curved forward, with cervical lordosis and lumbar lordosis.
• Disc damage is the main cause of back pain
• Discs: Nucleus pulposus, annulus fibrosus, and endplates
  • The posterior annulus fibrosus and endplates are most commonly injured
• Muscles protect the torn disc.
  • When a disc tears, the muscles tighten to protect it.
  • Low back pain is a sign of a torn disc
• Lumbar lordosis is a new posture.
• A healthy disc creates a lumbar lordosis curve, and the lumbar lordosis curve protects the disc.
• Sciatica is a typical symptom of a herniated disc and is a sign that the disc has herniated.

Treatment​

• The idea that you can cure a bad back by doing stronger back exercises is like saying that you can cure a broken arm by exercising the arm muscles.
• The hip muscles and obliques are important.
• You need to know exactly how much impact your workout will have on your back, and make sure your back can handle the strain.
• Stretches that bend at the waist are very bad exercises for lumbar lordosis
• Stiffness in the lower back when a disc injury is healing is a natural part of the process of the wound turning into scarring.
• It's essential to regain lumbar lordosis through frequent standing and extension movements.
• It is spinal hygiene to try to never re-tear a disc wound as it heals.
• Maintaining lumbar lordosis 24 hours a day
• If you suffer from sciatica when doing lumbar lordosis, you should treat the nerve root inflammation and practice good spinal hygiene.
• Leaning on a backrest or cushion is an advantage.
• The basics of spinal hygiene are maximum lumbar lordosis and extension movements.
• If it hurts to do extension movements, lie on your stomach and do them frequently, for about 5 minutes, with your elbows under your shoulders.
• Lumbar lordosis should not collapse when standing, sitting, or bending at the waist.
• Your back is most comfortable when your knees are slightly lower than your pelvis.
• There is no such thing as a bad back. Your back improves with good posture.
• Standing lumbar lordosis: place your hands on your waist and hold for 5 seconds while breathing.
• Standing Chest: Standing, lift your chest and grab your shoulder blades. No duckbills
• Walking: keep both shoulder blades together, open chest, chin up, graceful chin and proud chest.
• Sitting: knees should be lower than the pelvis. Sit with an upright chest.
  • The height of the screen should be high enough.
  • When sitting with good spinal alignment, you should be able to see the screen without bending your back and neck too much.
• The best place for a lumbar strap is between the 3rd and 4th lumbar vertebrae.
• Avoid the knees.

Prohibited positions​

• Squatting
• Sitting long
• Cross-legged
• Slouching

Overview​

Here's a list of use cases where you can get past the hype and actually use it for something useful.

Extracting regular expressions​

Creating regular expressions usually involves a lot of testing. I usually put the desired text in regexr, regex101, and match the negative/positive lookahead from memory, and use negative/positive lookbehind, but often find that negative lookbehind is not supported by different programming versions/languages.

Now I ask ChatGPT. Suppose you want to extract the package name from the package update history below.

Hello GPT.

Can you give me a regex pattern for getting to-be result?

as-is:
Orignal content


to-be:
Refined string #1
Refined string #2
...and so on.

It will get it for you.

Writing documentation with code​

If you want your code to be documented, put it in and ask it to create a README.md.

Can you write a README.md with this code?

It will get it for you.

Create an Object Validation Schema with the interface​

Let's create a Joi Schema with a TypeScript interface.

Create a Query DSL with Raw SQL​

Pass in a raw query and ask it to create a query DSL and query helper syntax.

Create a DDL with Data​

Pass in a query and ask it to generate a table schema query like the interface example above.

See​

awesome is now live. https://github.com/f/awesome-chatgpt-prompts