코틀린에서 컬렉션 만들기 코틀린은 자신만의 컬렉션 기능을 제공하지 않는다. 표준 자바 컬렉션을 활용하면 자바 코드와 상호작용하기가 훨씬 쉽다. 코틀린에서는 자바보다 더 많은 기능을 쓸 수 있다. 함수를 호출하기 쉽게 만들기 이름 붙인 인자 코틀린으로 작성한 함수를 호출할 때는 함수에 전달하는 인자 중 일부의 이름을 명시할 수 있다. 호출 시 인자 중 어느 하나라도 이름을 명시하고 나면 혼동을 막기 위해 그 뒤에 오는 모든 인자는 이름을 꼭 명시해야 한다. 자바로 작성한 코드를 호출할 때는 이름 붙인 인자를 사용할 수 없다....

프로세스의 개요 프로세스의 개념 프로그램: 저장장치에 저장되어 있는 정적인 상태. 프로세스: 실행을 위해 메모리에 올라온 동적인 상태. 컴퓨터 시스템의 작업 단위로 태스크라고도 부른다. 프로그램에서 프로세스로 전환 프로그램을 실행시키면 프로그램을 메모리의 적당한 위치로 가져온다. 그와 동시에 프로세스를 처리하는 데 필요한 다양한 정보가 들어있는 프로세스 제어 블록(Process Control Block, PCB)을 만든다. 프로세스 제어 블록에는 있는 다양한 정보 중 대표적인 적인 것은 세가지다. 프로세스 구분자(Process IDentification, PID): 메모리의 프로세스를 구분하는 구분자다. 메모리 관련 정보: 프로세스가 메모리의 어디에 저장되어 있는지 위치 정보가 담겨있다....

아래는 소프트웨어 팀이 얼마나 업무를 잘 수행하고 있는지 판단하는 조엘의 비공식적인 평가테스트 방법이다. 소스코드 관리시스템을 사용하고 있습니까? 소스코드 관리시스템을 사용하지 않으면, 다른 프로그래머가 무엇을 했는지 알 길이 없으며, 실수르 쉽게 되돌릴 수 없다. 한방에 빌드를 만들어낼 수 있습니까? 빌드 프로세스가 한 단계로 끝나지 않을 경우, 실수하기가 쉽다. 출시 날짜가 가까워질 수록 ‘마지막’ 버그를 수정하고 최종 EXE 파일을 생성하는 사이클을 짧게 유지해야 한다. 일일 빌드를 하고 있습니까? 빌드가 꺠진 문제성 코드를 우연히 체크인하는 경우, 다른 직원을 작업을 진행할 수 없게된다....

knowledge를 반복해서 사용하지 말라 프로젝트에세 이미 있던 코드를 복사해서 붙여넣고 있다면, 무언가가 잘못된 것이다. knowledge knowledge: 의도적인 정보 프로젝트를 진행할 때 정의한 모든 것 알고리즘의 작동 방식, UI의 형태, 우리가 원하는 결과 등 knowledge는 코드, 설정, 템플릿 등으로 표현할 수 있다. 프로그램에서 중요한 knowledge 두 가지 로직: 프로그램이 어떤 식으로 동작하는지와 프로그램이 어떻게 보이는지 공통 알고리즘: 원하는 동작을 하기 위한 알고리즘 비즈니스 로직은 시간이 지나면서 계속해서 변하지만, 공통 알고리즘은 한 번 정의된 이후에는 크게 변하지 않는다....

마이크로소프트가 장기간 살아남은 이유는 치명적이고도 아둔한 실수를 저지르지 않았기 때문이다. 실수 중 대다수는 기술관련 지식이 없는 비즈니스 쪽 사람이 기술적인 기본 사실을 이해하지 못하기 때문에 발생한다. 프로그래머를 조타수로 두지 않는 소프트웨어 회사는 결코 성공할 수 없다. 그러나 프로그래머가 저지른 실수 또한 많다. 소프트웨어 비즈니스에서 성공하려면 프로그래밍에 해박한 동시에 비즈니스도 이해하고 좋아하는 관리층이 있어야한다.

측정 역기능: 지식 노동자의 효율을 측정하려 들면 모든 질서가 급격히 붕괴돼버린다. 직원을 완전히 통제할 수 없을 떄 측정 역기능이 필연적으로 발생핟나.

편집 시간: 2022년 1월 31일 오후 5:52 코드 Algorithm/2798.py at main · Junroot/Algorithm 풀이 N이 100보다 작기 때문에 O(n^3)이어도 문제가 없다는 것을 알 수 있다. 모든 경우의 수를 다 구해본 뒤 M을 넘지 않는 최대값을 찾으면 된다.

편집 시간: 2022년 1월 31일 오후 5:59 코드 Algorithm/2751.py at main · Junroot/Algorithm 풀이 N이 최대 1,000,000 이기 때문에 최대 O(nlogn) 까지만 허용된다. python에서 기본적으로 제공해주는 정렬 함수는 머지 소트이므로 사용할 수 있다.

프로그래밍 작업을 더 쉽게 만들어 준다는 추상화 작업을 마쳤더라도 위대한 프로그래머가 되기 위해 알아야 하는 지식이 날로 늘어나고 있다. 허술한 추상화는 우리가 하키 스틱처럼 생긴 학습 곡선에 따라 살아가는 사실을 의미한다. 일주일만 배우면 활용하는데 필요한 90%를 배울 수 있다. 하지만 나머지 10%는 몇 년이 걸려야 겨우 따라잡을 수 있다. 한 세계에서만 살아본 사람이 다른 세상에 존재하는 복잡성에 대한 이야기를 들을 떄마다, 자신이 속한 세계는 복잡하지 않다는 생각이 든다. 소프트웨어 제작과정에서 의존할 언어 클래스, API, 플랫폼 등에 대해 몇년간 옹골진 경험이 있는 아키텍트를 한 명이라도 확보하지 못했다면 새로운 프로젝트를 시작하지 마십시오....

편집 시간: 2022년 2월 12일 오후 9:54 코드 Algorithm/2630.py at main · Junroot/Algorithm 풀이 네 구역으로 나누어서 각 구역에 대한 흰색과 파란색 색종이의 개수를 반환하는 분할 정복을 하면된다. 만약 현재 전체구역이 같은 색이면 이게 한개의 색종이가 된다.

편집 시간: 2022년 4월 2일 오후 5:07 코드 Algorithm/2623.py at main · Junroot/Algorithm 풀이 단순 위상 정렬문제다. 위상 정렬을 사용해서 순서를 결정하고, 모든 노드를 한번씩 방문하기 전에 끝난다면, 순환이 발생한 것이다.

편집 시간: 2022년 1월 31일 오후 6:06 코드 Algorithm/2609.py at main · Junroot/Algorithm 풀이 유클리드 호제법을 사용하면 쉽게 해결할 수 있다.

편집 시간: 2022년 2월 9일 오후 6:29 코드 Algorithm/2606.py at main · Junroot/Algorithm 풀이 bfs또는 dfs로 연결되어 있는 컴퓨터를 확인하면 된다.

추상화: 아랫부분에서 일어나는 아주 복잡한 어떤 작요을 간소화하는 방법 수많은 컴퓨터 프로그래밍은 추상화 요소를 포함하고 있다. 허술한 추상화의 법칙: 모든 쓸 만한 추상화에는 어딘가 구멍이 존재한다. 허술한 추상화의 법칙은 추상화가 의미하는 바와는 달리 우리 삶을 정말로 단순화시키지 못한다는 사실을 의미하기 떄문에 문제가 된다. 무언가를 추상화하는 듯이 보이는 코드생성 도구는 구멍이 있으며, 이런 구멍을 제대로 메워주는 유일한 해결책은 추상화 동작원리와 추상화 대상을 배우는 방법뿐이다. 추상화는 그저 일하는 시간을 절약해주지만, 배우는 시간을 절약해주지는 못한다....

고객은 자신이 원하는 내용이 뭔지 모른다. 고객이 자신이 원하는 내용이 뭔지를 알아내길 기대하지 마라. 멋진 사용자 인터페이스는 실제 프로그래밍 작업의 10%를 차지할 뿐이고, 나머지 90%의 작업은 보이지 않는 물밑에 가라앉아 있다. 프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘 못 만들어진 화면을 보여주면, 사람들의 전체 프로그램의 90%가 잘못됐다고 생각한다. 프로그래머가 아닌 사람에게 아름다운 사용자 인터페이스로 100% 무장한 화면을 보여주면, 프로그램이 거의 다 끝났다고 생각할 것이다. 멋지고 산뜻하게 다듬었으나 분량이 네 페이지인 웹 사이트를 운영하는 닷컴은, 3700여년에 이르는 자료로 무미건조하게 꾸며놓았지만 실용적인 사이트보다 훨씬 더 높은 평가를 받을 것이다....

편집 시간: 2022년 4월 7일 오후 6:48 코드 Algorithm/2473.py at main · Junroot/Algorithm 풀이 용액의 수가 최대 5000개이므로 O(N^2)으로 해결될거라고 생각했다. 기존 용액 문제에서 투 포인터로 O(n)만에 해결했으니 투 포인터를 사용하면서 한 번 더 n개를 루프돌아도 되겠다는 생각이 들었다. 그래서 용액 하나를 고정시키고 용액의 산성도가 0개 가까운 정도를 투 포인터를 이용해서 구했다.

편집 시간: 2022년 2월 24일 오후 3:25 코드 Algorithm/2407.py at main · Junroot/Algorithm 풀이 n에 대한 팩토리얼을 계산하면서, n보다 작은 값의 팩토리얼 값들을 배열에 저장해두면 O(n)으로 해결이 가능하다.

프로그래머가 항상 코드를 버리고 새로 시작하기를 원하는 미묘한 이유가 있다. 예전 코드가 엉망진창이라는 생각 떄문이다. 예전 코드가 엉망진창이라는 생각은 다음과 같이 기본적이며 근원적인 프로그래밍 법칙때문에 생긴다. “코드 쓰는 작업보다 읽는 작업이 더 어렵다” 함수가 점점 길어지고 비대해지는 이유는 버그 수정 때문이다. 코드를 버리고 새로 시작하면, 여기에 속한 노하우도 모두 버려야 한다. 이미 존재하는 코드를 다시 작성하느라 쓸데없이 많은 돈을 낭비하는 셈이다. 프로그래머가 작성한 코드를 완전히 엉망진창이라고 말할 때, 이와 관련해서 잘못된 이유가 세가지 있다....

직렬처리 방식은 평균적으로 결과값이 더 빨리 나온다. 과업 전환이 오래 걸릴수록, 멀티태스킹을 위해 지불해야 하는 대가도 커진다. 프로그래머의 과업 전환 시간이 오래 걸린다. 프로그램은 머리 속에 엄청나게 복잡한 내용을 한꺼번에 유지해야만 하는 일이기 때문에 이런 일이 벌어질 수 밖에 없다. 개발자 한명에게 한 가지 일을 던져주면 훌륭하게 처리하지만, 한 사람에게 두 가지 일을 한꺼번에 주면 그다지 매끄럽게 처리하지 못한다.

오답 여부: o 편집 시간: 2022년 2월 24일 오후 4:04 코드 Algorithm/2263.py at main · Junroot/Algorithm 풀이 포스트오더로부터 부모 노드를 찾고 인오더로부터 왼쪽 자식 노드와 오른쪽 자식 노드를 찾는 것은 쉽게 찾아냈다. 하지만 인오더와 포스트오더의 인덱스를 계산하는데 어려움을 겪었다. 굳이 문자열을 변형하지 않고 인오더의 인덱스와 포스트오더의 인덱스를 함수의 파라미터로 넘기면 헷갈리지 않는다는 것을 다른 사람 풀이를 참고해서 알게되었다.