위상까지는 그렇고.....

한국에서는 C#이 자리잡을 곳이 없다.

게임업계에서는 Unity때문에 C#이 스크립트처럼 쓰이는 부분이라 쓰이는거지, 정통(?) C#을 사용한다고 볼수는 없다.

그나마 WFP나 UWP등의 윈도 클라이언트, 그리고 공장 자동화, 반도체 쪽에서 WPF나 Winform을 사용중이다.

서버쪽에서는 여전히 자바 엔터프라이즈 계열이 대부분이라 극단적인 자바 공화국임을 느낄수 있는게, 서버단에서 닷넷을 구하는 대기업은 거의 볼수 조차 없다.

넥슨에서 약간 서버쪽 구인을 하는것 같은데, 쿠팡은 C# 포함에서 약간 다양하게 뽑는것 같고(아마 도커 컨테이너 때문이지 않을까), 네이버, 카카오, 배민은 전부 자바나 모바일 관련만 뽑는다. 엔씨도 서버쪽은 전부 자바다.

그래서 그런지 C#은 책 찾기도 힘들다. 흔히 말하는 악순환이다.

개발자 없음 -> 책 없음 -> 기술 스택 부족 -> 기업에서 안찾음 -> 개발자 없음 -> ...

이 섹션에서 말하고 싶은건 한가지, C#은 책이 부족하다. 즉, 한글화 되는 책이 잘 없다.

그렇기 때문에 책이 나와도 금방 절판된다. 그러므로 책이 나오면 일단 괜찮다 싶으면 사고 봐라. 회사에서 책 사주는 복지가 있다면, 일단 안보더라도 책을 사라. 나중에 필요한데 나중에는 절판되서 책 안나온다. 아니면 원서를 아마존에서 배송비까지 주고 비싸게 주고 보면서 영어의 늪에서 허우적 거리면서 보게 될것이다.

아쉽지만 어쩔 수 없다. 험지에서 살아갈려면 이정도 노력은 해야지. 대신 인력풀이 그만큼 작다보니 고인물 되어서 나름 살아가기는 쉬울 수 있다.

  • EndPoint List
    • 기존에 서비스하던 API들의 목록 작성
    • 통합 및 간결화, API 리스트 정리
    • 계속 서비스해야 할 것과 숨기거나 삭제해야할 것들에 대한 API 리스트 정리
  • Error Code
    • 정리되지 않은 에러 목록 정리
    • TDD
      • TDD 코드 작성을 위한 에러코드 정리
      • TDD 중 나오는 추가되지 않은 코드들의 목록 정리
    • 고객의 예외처리를 위한 에러코드 및 메시지 정리
  • Instance
    • endpoint 별로 동작하는 클래스들의 lifecycle 관리

 

 

계속 수정중......

Reference : ASP.NET Core 애플리케이션 개발 p.355. <표 14-1> ASP.NET 서비스 컨테이너 수명 옵션

Transient 서비스가 요청될 때마다 새 인스턴스가 생성된다. 경량 서비스에 이 수명을 사용한다.
Scoped 단일 인스턴스가 HTTP 요청당 생성된다.
Singleton 단일 인스턴스가 첫 번째 서비스 요청이 발생할 때 생성된다.
Instance Singleton과 유사하지만 인스턴스가 StartUp에서 컨테이너와 함께 등록된다

등록할때 LifeCycle을 고민해야하는데, 일종의 전역으로 항상 떠있어야 하는 클래스는 Instance로 등록하고, 그 외는 알아서 맞춰서 가는게 좋을듯.

(.Net 5에서는 Instance 옵션이 없다....그럼 Singleton으로 써야한다는건데 확인필요..)

컨테이너를 사용할꺼면 위를 고려해야하고, 그게 아니면 동작마다 생성하던지.

문제는 메모리 사용 및 성능 개선에 대한 고민이 필요할때면 이를 고려해야할 듯 하다.

'개발 > Server-BackEnd' 카테고리의 다른 글

[C#] ConnectionString Password 증발현상  (0) 2021.07.08
OpenAPI - 설계  (0) 2021.02.07
VS2019-Docker-SwaggerUI 경로 문제 바로 잡아주기  (0) 2021.02.04
알람 봇  (0) 2021.01.11
API - Status  (0) 2020.12.28

vs2019에서 docker에 올릴 api를 .net 5등으로 만들어 빌드해서 실행하면 그냥 

https://localhost:0/swagger

로 나와서 일일히 다시 수정해서 확인해야할때가 있다.

그럴때는 

솔루션탐색기에서

launchSettings.json을 열어보면 아래쪽에 "Docker"쪽 설정부분이 있고,

여기서 launchUrl이 실행시 swagger가 뜨는 경로가 되는데 이부분에 Scheme가 https, ServicePort가 port number이다.

아래에 useSSL을 false로 (http로 붙겠다는 뜻)

그리고 httpPort를 특정포트(docker 옵션상의 포트로 설정하는것이 좋다. 기본은 49157인가?)

이렇게 해서 수정을 해주면 바로된 경로로 실행시 swagger가 출력된다

'개발 > Server-BackEnd' 카테고리의 다른 글

OpenAPI - 설계  (0) 2021.02.07
[asp.Net core]컨테이너 수명 옵션  (0) 2021.02.07
알람 봇  (0) 2021.01.11
API - Status  (0) 2020.12.28
API - Return 구분  (0) 2020.12.28

 종종 스타트업에 '스타 개발자'라는 사람들이 있다. 스타트업은 이게 중요한게, 투자를 받을 수 있는 근거중 하나가 되기 때문이다.

'오 여기 출신의 개발자가 일하는거면 산출물은 확실하겠군'

하는 것이 일종의 근거가 되는 셈인데, 문제는 이런 스타개발자가 되기 위한 활동을 하는데에 있다.

일종의 '네카라쿠배' 출신들 중에 그러한 개발자들이 있고, 이미 여기 공채에, 몇년 일한 사람에, 어떤 서비스를 성공적으로 이끌었다면 확실한 증거가 될 수도 있겠지.

근데 그런게 아닌 사람들이 설치고 다니는것이 문제가 된다.

핫한 스타트업 회사가 아닌 약간 어중간한 회사에서 자기가 나름 스타개발자인것처럼 행동하고, 인터뷰하고, 블로그를 하는 방식으로 포장하는 경우가 생기는데, 볼때마다 '뭐 그렇게 뛰어난 개발자라고 저러나....' 하는 생각을 할 때가 있다.

MS 계열에서는 이미 MVP라는 MS쪽에서 선정한 개발자분들이 명확한 스타개발자이다. 영어되고, 개발능력되고, MS라는 세계적인 외국계 회사에서 선정한 사람이면 뭐 다른 평가가 필요할까?

그리고 자바나, 웹쪽은 또 나름의 커뮤니티에서 활동하시는분들이 많으니 그쪽에서 나름의 설정 방법이 있을것이다.

그런데 뭘까.... 좀 애매한 회사에서 활동하면서 포장하시는분들이 종종 생기는데, 

회사에서 인터퓨 형식으로 블로깅 하고, 기술 블로그 하고, 나름의 개인적인 내역도 보여주는데, 찾아보면 개발자 경력 겨우 10년 정도 되는 사람들이 그러고 있다. 지금 기준으로 10년이면 나이가 보통 30대 중후반정도? 거기다 스타트업 대표까지 한 이력이 있기도 하다. 

스타트업 대표는 사실 큰 이력이 되질 않는다.... 차라리 사업을 하는데 스타트업 대표이력이 있다면 모를까, 아니면 다른 스타트업의 임원으로 들어가는것이 아니면 모를까... 이게 '스타개발자'라는 위치에 어떤 지대한 영향을 미칠까?

물른 실패한 경험도 경험이기 때문에 그걸 기준으로 사업을 펼처나간다면 어느정도 이해는 하겠다마는, 사업이 아닌 개발자로 일하는거면 넓은시야를 가지고 방향 설정은 하겠지, 그게 개발수준에는 많은 영향을 미칠까는 다시 생각해볼 문제가 아닐까?

그리고 네카라쿠배 출신분들은 스타트업와서 과연 잘 할수 있을까? 대기업에서 업무분담해서 나누던 일을 스타트업와서는 혼자서 3~4파트를 다 커버해야할텐데? 

AWS의 codeCommit 이나 다른 ssh로 git repository를 접근할때 소스트리에 SSH를 설정하는 부분이 있습니다.

소스트리 : 도구 -> 옵션 -> [일반] SSH 클라이언트 설정

에 가셔서 OpenSSH로 해야 CodeCommit 에서 설정하는 openssh 방식으로 인증되어 repository에 접근 및 push가 가능할 겁니다.

putty/plink로 하시면 안됩니다.

  • 서버 데본이나 배치 프로세스가 서버내에서 동작
    • 상위 서버로 메시지를 전송?
    • UDP로 비연결성으로 가능한가?
  • 일정 시간 동안 신호를 받지 못할때 
    • 메시지를 전송?
    • 슬랙 봇이나 텔레그램 등으로 메시지 전송이 가능할까?
    • 그 알람 봇이 문제가 생기면??

'개발 > Server-BackEnd' 카테고리의 다른 글

OpenAPI - 설계  (0) 2021.02.07
[asp.Net core]컨테이너 수명 옵션  (0) 2021.02.07
VS2019-Docker-SwaggerUI 경로 문제 바로 잡아주기  (0) 2021.02.04
API - Status  (0) 2020.12.28
API - Return 구분  (0) 2020.12.28
  • 현재의 API 서비스들의 상태를 보여주는 API Status Window
  • 상태분류
    • 정상/지연/응답없음(오류)/이용시간아님/...
    • 응답시간(배치를 통해 기준단위로 응답시간을 저장하여 출력)
    • 위 상태가 최종 저장된 '최종 업데이트 시간' 출력

 

'개발 > Server-BackEnd' 카테고리의 다른 글

OpenAPI - 설계  (0) 2021.02.07
[asp.Net core]컨테이너 수명 옵션  (0) 2021.02.07
VS2019-Docker-SwaggerUI 경로 문제 바로 잡아주기  (0) 2021.02.04
알람 봇  (0) 2021.01.11
API - Return 구분  (0) 2020.12.28
  • 응답코드
    • 요청에 대한 상태 : HTTP의 상태코드
    • 에러에 대한 정보 : 에러코드
      • 위 200 코드 이외의 에러에 대한 정보를 리턴
      • 코드와 (상세)메시지로 구현
        • (내부적으로 설정된)상세 코드 추가 출력
      • 에러에 대한 내부 코드 스펙이 정해져 있어야 함
        • 다른 서비스들(카카오, 네이버 등등)을 참고하여 예외상황을 미리 추가하여 구분해 놓는것이 좋음

 

'개발 > Server-BackEnd' 카테고리의 다른 글

OpenAPI - 설계  (0) 2021.02.07
[asp.Net core]컨테이너 수명 옵션  (0) 2021.02.07
VS2019-Docker-SwaggerUI 경로 문제 바로 잡아주기  (0) 2021.02.04
알람 봇  (0) 2021.01.11
API - Status  (0) 2020.12.28

만일 이미지를 어느 패널에 출력한다고 할때나,

음악파일을 출력하고자 할때,


그 파일들이 어느 폴더에 있는데 여러 종류의 컨텐츠들이 섞여있는 폴더일때는 가려서 음악파일만 출력한다던지, 이미지 파일만 출력한다던지 해야한다.


예를 들어서,

내 그림 폴더에 있는 이미지 파일들만 불러서 출력하려고 하는데, 

string strPicPath = Environment.GetFolderPath(Environment.SpecialFolder.MyPictures);

로 내 그림 폴더의 경로를 받아서

DirectoryInfo asd = new DirectoryInfo(strPicPath);

FileInfo[] arrFiles = asd.GetFiles();

m_strArrjpgPath = new string[arrFiles.Length];

int nCount = 0;

foreach(FileInfo File in arrFiles)

{

    m_strArrjpgPath[nCount++] = File.FullName;

}

이렇게 작성 한 후

윈폼.m_pnlMainBase.BackgroundImage = Image.FromFile(m_strArrjpgPath[0]);

이렇게 하면 m_strArrjpgPath[0]에는 어떤 파일이 들어가는지 아는가?


바로 "DeskTop.ini". 윈도 탐색기에서 따로 설정을 하지 않은 이상 숨김파일이라 보이지도 않을, 폴더 설정 파일이 불려지게 된다.

저렇게 바로 Image.FromFile에 경로로 들어가면 Exception이 발생하며 이미지 파일이 아닌 일반 텍스트 파일임에도 불구하고 로드를 실행하며 OutOfMemory Exception이 발생하는 예상과는 다른 예외를 뱉어낸다.


어찌됐든, 

1. 해결방법 첫번째는 위의 상황에서 Exception이 발생하니 catch로 상황을 잡아주면 되는거고(안잡아주면 에러발생으로 팝업 경고뜸)

2. 아님 try~catch로 꼭 처리 안하더라도 검증된 이미지 파일만 넘겨주면 되는것이므로 컨텐츠의 헤더를 분석하여 이미지파일인지를 확인 후 넘겨주는 방식이 있다. 

하지만 넘겨줄때마다 파일을 분석해야하는 오버헤드가 생길 수 있고, 또한 이미지 파일이더라도 이미지 출력이 안될수 있는 정말 어이없는 예외상황을 처리해야하는 try~catch가 필요하다면 결국은 try~catch 하나만으로 처리하는것이 오버헤드를 줄일 수 있는 나은 방법이 아닐까.


+ Recent posts