[서평] SwiftUI 기반의 iOS 프로그래밍, Swift 개발자(진)를 위한 백과사전

안녕하세요 ! 오랜만에 또 블로그에 글을 쓰게 되었습니다. 오늘은 개발자를 향해 하루하루 야금야금 나아가고 있는 제게 큰 도움이 될 예정인 책을 하나 소개하려 합니다. - 핵심만 골라 배우는 SwiftUI 기반의 iOS 프로그래밍 - 닐 스미스 지음, 황반석 옮김 / Jpub 이 책은 iOS 앱 개발에 대한 포괄적인 안내서로, Swift 언어를 통해 iOS 애플리케이션을 만드는 데 필요한 핵심 기술을 제공합니다. 이 책은 초보자부터 중급 및 고급 개발자까지 모두를 대상으로 하며, iOS 앱 개발을 위한 기초부터 고급 주제까지 다루고 있습니다. 굉장히 세련된 표지를 갖고 있습니다. 직관적으로 iOS 개발을 알려주는 책임을 알 수 있고, 600쪽이 넘는 상당히 두꺼운 책입니다. 그럼 지..

• format_list_bulleted READERS AREA
• · 2023. 10. 1.
• textsms

[운영체제] 8. 멀티플 프로세스 시스템

CPU와 메모리는 버스로 연결. a : 가장 기본적인 형태. CPU가 많아질수록 병목이 생김 b : 슈퍼컴퓨터 -> 컴퓨팅모드(메모리+CPU합체)가 따로 존재 -> 인터커넥트라는 빠른 버스로 서로 연결 c : 분산 시스템 -> 분리되어 인터넷으로 연결 : 클라우드 컴퓨팅 환경 -> 데이터 복사시 여러번 복사하니 오버헤드가 클 수 있음 우리는 a,b형태에 집중. a는 메모리 접근시간 거의 동일하지만 b는 로컬이냐 원격이냐에따라 차이. 어떻게 관리할 지, 스케쥴링 할 지 중요해짐 UMA : cpu에서 메모리 접근 속도가 동일 NUMA : 로컬메모리 접근 속도랑 원격지 메모리 접근 속도랑 다르다. a : cpu가 많아질수록 하나의 메모리에 접근하니 병목 발생. b : CPU에 캐시가 있음 : cash cohe..

• format_list_bulleted UOS@운영체제
• · 2023. 6. 15.
• textsms

[운영체제] 6. 데드락

Preemtable : 사용 도중 자원을 다른 프로세스에게 줄 수 있는 자원 / 메모리, CPU Nonpreemtable : 실행도중 다른 프로세스에게 줄 수 없는 리소스 -> 데드락 발생 -> 안걸리게 할 수 있다. b : 자원이 2개라면 down : 1,2 요청하고 -> 쓰고 -> 2,1 순으로 해제 리소스 1에서부터 경쟁 -> 이긴 프로세스가 2까지 가져가서 작업, 진 프로세스는 sleep -> 이후 해제하면 진 애가 a가 1받고 이제 2 받아야 하는데 b가 2를 이미 받았다면 -> 둘 다 sleep : 이 상황이 deadlock ->그럴수도, 그러지 않을 수도 있음. 즉 잠재적으로 일어날 가능성이 있다. 데드락 상황 : 집합에 있는 각 프로세스가 다른 프로세스가 발생시킬 수 있는 이벤트를 기다림...

• format_list_bulleted UOS@운영체제
• · 2023. 6. 14.
• textsms

[운영체제] 5. I/O(입출력) - 2

디스크에서 최적화 하는 알고리즘. lotation delay와 transfer time은 줄이기 힘듦. 거의 고정, 에러 체킹은 컨트롤러에서 하니까 빼고. 실제 dominent(지배적인)한 sector는 seek time이 i/o time에 영향을 끼침 -> seek time을 줄여야 함. work conserving : 해야할 일이 있을 때 계속 하는 것. ex) CPU non-work conserving : 디스크는 해야할 일이 있어도 기다리는게 이득일 수 있음. request order : 읽어야 할 트랙 번호. FIFO: 온 순서대로 처리 -> 공정하지만, (헤드 이동 거리)시크타임은 커짐 SSTF: 헤드 이동거리가 가장 짧은 요청 선택하여 처리 -> 시크타임이 짧아지나, starvation 발생..

• format_list_bulleted UOS@운영체제
• · 2023. 6. 14.
• textsms

[운영체제] 5. I/O(입출력) - 1

I/O 장치는 굉장히 많고 장치마다 특성이 다르다 -> 운영체제는 크게 두가지로 나눠서 관리 1. 블록 디바이스 - 빠름 -> 읽기쓰기가 블록 단위 -> 블록마다 주소 부여 - 오퍼레이션 : 읽기/쓰기, 탐색 등 2. 캐릭터 디바이스 - 입출력하는 펜/키보드/마우스 등의 장치 : 입출력 단위가 문자 -> 주소가 아닌 입출력 순서대로 처리. 이런 형태에 따라 드라이버 작성 규칙이 정해져 있음. 운영체제의 일부인 디바이스 드라이버가 컨트롤러를 작동시켜 입출력을 수행 - 프로세스에서 전송한 데이터를 컨트롤러를 통해 디바이스에 전송(버스를 통해 비트스트림으로) -> 비트스트림을 블록장치라면 블록 단위로 변환. 깨지는걸 방지하기 위해 ECC 코드를 추가로 붙여서 전송 -> 오퍼레이션 : 컨트롤 레지스터에 기록된 ..

• format_list_bulleted UOS@운영체제
• · 2023. 6. 14.
• textsms

[운영체제] 4. 파일시스템 2

디렉토리 구현. a 윈도우즈 : 엔트리에 파일이름 + 속성정보, 엔트리 단위 저장. -> 아래 이미지 보면, First block number가 파일의 시작 데이터가 저장되어있는 블록번호를 저장한 것. 가운데 리저브드 영역도 이후 확장되면서 사용됨. b 유닉스 : 파일이름, 아이노드번호 -> 아이노드에 속성정보와 인덱싱 정보 저장. -> 파일 이름이 8+3이라 너무 짧아. 그래서 255바이트까지 확장 -> 엔트리가 커질 수 있어야 하여 가변 구조가 됨. a : 디렉토리 안에 엔트리를 표현. 한 덩어리가 하나의 엔트리. -> 파일1의 엔트리 길이 + 속성 + 파일 이름(4바이트씩 커짐, x는 null)+ 안쓰는 부분 회색. 이렇게 하다보니 안쓰여지는 공간이 존재. 그래서 b를 제시 b : 파일1의 이름 위..

• format_list_bulleted UOS@운영체제
• · 2023. 6. 10.
• textsms

[운영체제] 4. 파일시스템

long-term information storage(저장장치)의 특징 1. 굉장히 크다 -> 큰 파일들을 저장할 수 있어야 함 2. 프로세스는 실행중에 파일을 오픈해서 읽거나 저장하는데 이 데이터가 잘 유지되고 있어야 함(비휘발성) 3. 여러 프로로세스가 동시에 접근할 수 있어야 함(선택적) 파일 시스템은 디스크를 고정된 크기의 block들이 순서대로 나열된 것으로 생각(BUT 실제로 원판이 순서대로 나열되어있지 않음.) 0번부터 n-1번까지 순서대로 읽는 장치로 생각하여 블록에 대한 read/write를 지원해줌. 따라서 내부에는 컨트롤러가 존재(ex.하드디스크 컨트롤러 != 운영체제 컨트롤러) -> 운영체제, 호스트에서 요청한 블록번호를 원판의 위치로 변환하고 데이터를 read/write함. -> ..

• format_list_bulleted UOS@운영체제
• · 2023. 6. 10.
• textsms