c# 서버에서 코루틴과 await을 사용시 장단점
코루틴 만 사용하면 빠름
await 코루틴 같이 사용하면 느림 50 cpu
await 만 사용하면 14 cpu
ai
싱글쓰레드처럼 처리하기 위해선 코루틴이 좋아보임이지만 결과값 리턴 하는 경우 좀 지저분해짐
c# 서버에서 코루틴과 await을 사용시 장단점
코루틴 만 사용하면 빠름
await 코루틴 같이 사용하면 느림 50 cpu
await 만 사용하면 14 cpu
ai
싱글쓰레드처럼 처리하기 위해선 코루틴이 좋아보임이지만 결과값 리턴 하는 경우 좀 지저분해짐
마이크로소프트 엑셀을 사용합시다.
- 단순하게 만듭니다.
Feature, Task, Priority, Orig Est(처음 추정시간), Curr Est(현재 추정시간), Elapsed(경과시간), Remain (= Curr Est - Elapsed)
- 과업을 세부적으로 나누십시오.
이는 일정이 제대로 돌아가게 만드는 가장 중요한 요소입니다.
과업은 날짜 단위가 아니라 시간 단위로 측정할 수 있어야만 합니다.
(제 경험으로는 날짜 단위나, 한술 더 떠서 주 단위로 예측한 일정은 현실성이 없습니다.)
...
경험적인 규칙에 따르면, 각 과업은 적게는 2시간에서 많게는 16시간 이내에 처리할 수 있어야 합니다.
일정 중에 40시간(1주일)이 넘어가는 과업이 있으면, 충분히 쪼개지 않았다고 봐야 합니다.
- 초기 예측과 현재 예측을 동시에 유지하십시오.
시간이 지남에 따라 과업이 예상보다 더 길어지거나 더 짧아질 경우 필요에 따라 현재 예측 Curr Est열을 갱신할 수 있습니다.
이런 방법은 실수를 통해 과업을 얼마나 제대로 예측하는지 배우는 최선의 방법입니다.
몰라도 괜찮습니다.
끊임없이 배우고 이렇게 배운 지식을 토대로 지속적으로 일정을 갱신하다 보면, 언젠가는 일정이 제대로 맞아떨어질 것입니다.
평범한 프로그래머는 1년 정도만 경험하면 훌륭하게 일정을 작성하더군요.
- 경과(Elapsed)열은 매일 갱신하십시오.
코드작성 시간을 1분 1초까지 측정할 필요는 없습니다.
퇴근하기 직전이나 책상 밑에 들어가서 잠들기 직전에, 당신이 8시간 동안 일했다고(정말일까요?) 시치미 뚝 떼면서 당신이
작업했던 과업이 무엇인지 생각한 다음에 해당하는 경과 열에 8시간을 쪼개어 기록합니다.
이렇게 하면 남아있는 시간 필드는 엑셀이 자동으로 계산해줍니다.
동시에, 현실을 반영하기 위해 해당 과업을 위한 현재 예측 Curr Est 열도 갱신하십시오.
일정을 갱신하는 데는 2분도 채 걸리지 않을 것입니다.
- 일정에 휴가나 휴일 같은 항목을 넣으십시오.
- 일정에 디버깅 시간을 넣으십시오!
- 일정에 여유 기간을 두십시오
- 관리자가 프로그래머에게 일정을 단축하도록 절대 강요하지 못하게 하십시오
수많은 풋내기 소프트웨어 관리자들이, 멋지게 '빠듯한' 일정(하지만 매우 비현실적인)을 잡아서 더 빨리 일을 처리하도록
프로그래머에게 '동기를 부여할'수 있다고 자만합니다. 저는 이런 동기부여 방식은 멍청한 짓이라고 생각합니다.
저는 일정보다 조금이라도 늦어지면, 우울해지고 침체되거나 일할 맛이 안 납니다. 일정보다 앞서가면, 기분이 좋아지고
생산성도 높아집니다.
관리자가 일정을 단축하라고 요구하면, 이렇게 하십시오.
우선 일정표에서 '내 예측 My Estimate'이라고 이름 붙인 새로운 열을 만드십시오
그리고 여기에 자신이 생각하는 예측 값을 적으시면 됩니다.
관리자가 현재예측 Cuur Est 열로 하고 싶은 일을 혼자 실컷 하게 내버려 두십시오.
즉 관리자가 예측한 사항을 무시하란 말이지요.
프로젝트가 끝날 때쯤, 누가 현실에 더 가깝게 예측했는지 살펴보시기 바랍니다.
- 일정은 장난감 블록과도 같습니다.
장난감 블록이 산더미처럼 있는데 상자 안에 다 넣을 수는 없다면, 둘 중 하나를 선택해야 합니다.
...
일정을 짜놓지 않았다면, 프로그래머는 쉽고/재미있는 기능부터 먼저 구현할 것입니다.
그리고 나면 시간이 부족해지니까, 유용하고/중요한 기능을 구현하기 위한 일정을 늦출 수밖에 없습니다.
일정을 미리 짜놓았다면, 작업을 시작하기도 전에 무엇을 잘라내야 할지 알 수 있습니다.
따라서 쉽고/재미있는 기능은 쳐내고 더 유용하고/중요한 기능부터 구현하겠죠.
잘라내야 할 기능을 선택할 수밖에 없는 상황에서, 기능을 검토해서 가지 치는 과정을 거침으로써, 더 좋은 기능으로
무장한 강력하고 우수한 제품을 더 빨리 출시하게 됩니다.
- 엑셀에 대해 꼭 알아둬야 할 사항
1) 공유목록
: 모든 사람이 함께 파일을 열어서 동시에 편집할 수 있도록 허용.
2) 자동필터
: 일정을 필터링하는 훌륭한 방법을 제공하므로, 예를 들어 당신에게만 할당된 기능 전부를 볼 수 있습니다.
3) 피벗 테이블
: 요약과 교차집계표를 보는 훌륭한 방법을 제공.
...
피벗 테이블은 엑셀을 수백만 배 더 강력하게 만들어주기 때문에 이 기능을 확실히 배워 잘 사용하시기 바랍니다.
4) WORKDAY 함수
: 간단한 일정에서 쉽게 달력 날짜를 계산하는 데 필요한 모든 기능을 제공.
"조엘 온 소프트웨어", 조엘 스폴스키
[출처] [일정관리] "조엘 온 소프트웨어"|작성자 영재
인증(authentication) 사용자가 누구인지 식별
인가(authorization) 사용자가 무엇을 할수 있는지를 결정
암호화(encryption) 누설과 위조로 부터 데이터를 보호
감사(auditing) 사용자가 무엇을 했는지,하려했는지를 추척
쿼터(quotas) 자원을 얼마나 많이 사용할수 있는지 조절
--------------
클라이언트 진정성 - 클라이언트 인증
서버 진정성 - 실제 브로커 연결인지 검즘
기밀성 - 메시지 전달간 암호화
무결성 - 내용물 변조여부
접근제어 - 권한확인
감사가능성 - 감사용 기록
가용성 - 몇몇사용자의 대역폭 독차지을 막기위한 쿼터와 제한
기원 1년부터 표시 가능
그 이전은 별도 자료형을 사용할것
다른 언어의 경우 처리가 다르므로 기원전 표시의 경우 확인이 필요
1. db로 데이터 관리 단점
버젼관리가 힘들다.
수정이력을 추적하기 힘들다.
수정사항을 즉시 테스트하기 힘들다.
다양한 버젼을 만들어서 테스트 하기 힘들다.
db서버 구축이 필요하고 데이터 컨버팅이 매번 필요하다.
2. 유니티로 데이터 관리사 장점 (버젼관리 시스템 과 같이 사용필수)
버젼관리가 쉽다.
수정이력을 추적할수 있다.
수정사항을 즉시 테스트할수 있다.
다양한 버젼을 만들어서 테스트할수 있다.
별도 서버 구축이 필요없다.
Scriptable Object로 리소스 생성하기
Scriptable Object로 리소스 생성하여 관리
https://postiveground.com/etc/%EC%9C%A0%EB%8B%88%ED%8B%B0-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%A0%80%EC%9E%A5-%EB%B0%A9%EB%B2%95-scriptable-object%EB%A1%9C-%EB%A6%AC%EC%86%8C%EC%8A%A4-%EC%83%9D%EC%84%B1%ED%95%98%EA%B8%B0/
간단한 설정파일 json 파일로 만들어서 처리
https://wergia.tistory.com/164
대규모 수치 데이터 csv로 만들어서 처리
https://wergia.tistory.com/164