Simple is Beautiful.

Nuphy Air60 구입 후 사용한 지 벌써 1년이 지났습니다. 그 사이에 NuPhy에서 다양한 키보드를 발매했고 그중 Halo75가 마음에 들어 구매하게 되었습니다.

1. 서론

소득공제 환급금으로 지른 키보드입니다. 이번에는 와디즈 펀딩으로 구매하게 되었습니다. 

이번 와디즈 펀딩은 엔인원 이라는 회사가 담당했나 봅니다. Halo75 이후 진행되는 Halo96과 Air75도 같은 회사에서 진행하는 걸 보니 국내 담당은 엔인원인가 봅니다.

펀딩 결제는 23년 02월 27일 진행하였고 두 달 정도 지난 23년 04월 25일 오늘 배송받았습니다. 구매 제품은 "Halo75 화이트 프레임+나이트 브리즈 스위치(리니어)"와 "Halo75 전용 화이트 아크릴 팜레스트"입니다. 총 구매 금액은 배송비까지 22만 900원입니다.

두 달간의 기다림 끝에 제품을 받아 볼 수 있었습니다.

2. 본론

이번에도 캐틱터가 그려져 있는 박스가 왔습니다. 특이한 게 공식 홈페이지 제품 설명에는 캐릭터가 공개가 안되어 있습니다. 제품을 구매하고 박스를 봐야 캐릭터가 그려져 있어요. 혹시 Halo75와 Halo96 캐릭터가 다른 지도 궁금하네요.

본품입니다. 내부에 스티커가 동봉되어 있습니다.

이전과 마찬가지로 설명서&포스터가 동봉되어 있습니다. 포스터를 뒤집으면 설명서가 있습니다.

이전제는 봉지에 담겨있던 추가 제품이 좀 더 세련되게 액세서리 키트로 변경되었습니다. 윈도, 맥 호환에 알맞게 기본 키캡은 맥용이고 윈도 키캡이 포함되어 있습니다.

키캡도 지원하는 키캡 모두 하나씩 포함되어 있습니다. 좌상단부터 나이트 브리즈, 로즈 글래시어 그 아래 좌측부터 베이비 라쿤, 베이비 캥거루입니다. 나머지 세 개는 설명할 필요가 없어 보이고 베이비 라쿤과 캥거루도 게이트론 스위치이므로 별도로 설명하지 않겠습니다.

NuPhy만의 독특한 키캡으로 나이트브리즈와 로즈글래시어가 있습니다. 저는 키압이 1g이라도 낮은 걸 선호하기 때문에 나이트 브리즈로 선택하였습니다. 테스터 스위치로 비교를 해봤는데 확실히 부드러운 느낌이 있으며 로즈 글레이셔는 키압까지 어느 정도 버티다 쑥 눌리는 기분이었습니다. 

무선 리시버가 액세서리 키트에 없어서 한참 찾았습니다. 저기 구멍에 본품에 낄 수 있게 되어있습니다. 내부는 자석으로 되어있어서 쉽게 빠지지 않습니다. 개인적으로는 2.4G 무선 연결을 선호하기 때문에 Air60를 사용할 때 별도로 들고 다녀야 하는 불편함이 있었는데 이렇게 바뀐 건 맘에 드는 변화입니다.

우측의 스위치는 기존과 동일합니다. 윈도/맥 전환, 전원 Off, 유선연결, 무선연결 전환 스위치 그리고 C타입 유선연결 포트가 있습니다. Air는 측면에 있었는데 후면으로 이동했네요. Air를 연결할 땐 ㄱ자 C타입 선이 아니면 불편했는데 후면으로 이동해 더 좋아졌다고 생각합니다.

이상이 동봉된 제품의 전부입니다. 공식 홈페이지의 스펙을 봐도 누락 없이 다 포함되어 있었습니다.

전 후면 사진입니다. 후면에는 2단 높이 조절이 가능하게 되어있습니다. 플레이트는 Air보다는 확연히 작아진 모습니다. 연결 후 라이트가 들어오는 모습입니다. 특이한 게 백라이트, 헤일로라이트, 사이드라이트 총 세 개의 라이트가 있습니다.

백라이트는 일반적이 키보드의 라이트입니다. 키캡 뒤에서 빛이 납니다. HaloLight는 키보드테두리의 라이트입니다. 하우징 테두리를 따라 라이트가 있는데 이게 변합니다. 또한 키보드 모서리(F1~Ins와 같은 겉의 라이트)의 라이트도 함께 변합니다. 사실 하우징 테두리의 라이트는 눈에 잘 안 띄는데 팜레스트와 어두운 곳에서는 확실히 존재감을 내뿜습니다.

백라이트는 끄고 헤일로 라이트만 킨 채로 팜레스트를 사용한 모습입니다. 확실히 아름답네요. 마지막으로 사이드 라이트는 이것저것 테스트 해보았으나 어떤 게 변하는지 아직 확인을 못한 상태입니다. 사실 옆에 테두리의 라이트가 사이드 라이트인 줄 아았으나 헤일로 라이트에 연동되어 있습니다. 사이드라이트는 확인한 뒤 다시 포스팅을 업데이트하겠습니다

팜레스트의 경우 추가로 언급할 내용이 많이 없습니다. 다만 일반적인 텐키리스 사이즈보다 좀 더 작게 Halo에 커스텀 된 사이즈를 가집니다. 팜레스트에는 밀림 방지 패드가 여분으로 하나 더 있습니다.

3. 비교

처음 제품을 받고 든 생각은 제품이 생각보다 높다는 것입니다. 이를 위해 다른 키보드와의 비교 사진을 찍어봤습니다.

우선 NuPhy Air60과의 비교입니다. 확연히 차이나는 모습입니다. 사진으로만 봐도 확실히 Halo가 높은 것을 확인할 수 있습니다.

높이 하면 생각나는 키크론제품과도 비교해 보았습니다.

이게 참 특이한데 키보드의 위로가면 갈수록 키크론과의 차이가 없어집니다. 즉 가장 위쪽은 키크론과 높이가 동일하다고 보면 됩니다. 근데 아래로 내려오면서 NyPhy의 높이가 더 낮아집니다. 맨 아래에 내려와선 NuPhy의 높이가 더 낮습니다.

사실 둘 다 높은 느낌이지만 이 조금의 차이만으로도 꽤나 다른 느낌이 듭니다. 키크론 키보드의 경우 함께 판매하는 팜레스트 없이는 진짜 못쓸 정도라고 느꼈지만 NuPhy는 그래도 못쓸 정돈 아니다는 느낌입니다. 물론 손바닥을 바닥에 붙인 채로 타자를 치는 건 둘 다 불가능하다고 생각하면 됩니다.

또 NuPhy가 디테일에 신경 썼다고 느끼는 부분이 바로 팜레스트의 높이입니다. 사진에서 보듯이 키크론의 팜레스트는 끝이 오히려 낮아지면서 키보드와의 높이차가 꽤나 있는 것을 확인할 수 있습니다. 반면에 NuPhy Halo의 팜레스트는 높이가 지속적으로 높아져 키보드랑 맞붙는 부분의 높이차가 1-2mm 내로 일체감이 있습니다. 이 덕에 좀 더 편안하게 사용할 수 있었습니다. 

4. 결론

확실히 이쁩니다. 그리고 어색합니다. 

사실 저는 이 전에도 흔히 단무지키보드라고 하는 Ducky One3 노란색 SF 배열을 사용했었습니다. Halo도 이와 비슷하게 특수키들이 오른쪽에 일렬로 몰려있습니다. 처음 사용할 때 PgDn키와 우측 방향키를 함께 누르고 있었고 Del키도 위치가 어색한 게 느껴집니다.

스위치의 키감이 맘에 듭니다. 키감은 온전히 개인 취향의 영역이므로 추천드리기 힘들지만 여유가 되거나 기회가 된다면 NuPhy의 커스텀 키캡을 선택하는 것을 추천드립니다. 물론 공홈에서는 둘 다 품절입니다. 인기를 반증하는 것처럼 보이네요.

블루투스, 유선. 2.4g 무선을 지원하는 점도 강점입니다. 사실 NuPhy와 싱크웨이x토체티 콜라보 키보드 말곤 세 가지 연결을 모두 지원하는 키보드는 본 적이 없을 정도입니다.

소음이 없습니다. 물론 스위치에서 나오는 특유의 타건음은 있지만 그 외 스태빌에서 나오는 소음이나 통울림이 없습니다. NuPhy에서는 두 겹의 실리콘패드로 통울림을 잡고 고스트바라는 시스템으로 스페이스에서 나는 소음을 한번 더 잡았다고 합니다. 확실히 타건음 외의 소리는 없다시피 합니다. 

메인 키보드로 추천할만한 키보드입니다. 주변인에게 여유가 있다면 이 키보드를 추천하고 싶을 정도입니다. 다만 일반적인 TKL 키보드와 사이즈와 배열이 다른 것은 감안해야 합니다.

다른 키보드 리뷰

https://smoh.tistory.com/384

https://smoh.tistory.com/465

https://smoh.tistory.com/447

DICOM 태그를 다루던 중 태그 타입에 1C라고 적혀있는 걸 보고 문득 TagType의 정확한 정의가 궁금해져서 알아본 후 작성한 글입니다.

Data Element Type

DICOM에서 태그 타입 ‘1C’는 조건적으로 필수인 타입 1이지만 비어있거나 존재하지 않을 수 있는 타입 2가 포함된 데이터 요소입니다.

다른 말로 태그 타입 ‘1C’는 데이터 요소가 필수로 DICOM 객체에 나타나야 하지만 특정 환경이나 다른 연관된 태그의 값에 따라 값을 가지고 있지 않을 수 있는 태그 타입을 가리킵니다. 만약 연관된 데이터 요소가 특정 값을 갖는다면 ‘1C’ 데이터 요소는 반드시 값을 가져야 하지만 연관된 데이터 요소가 특정한 값을 갖지 않는 다면 ‘1C’ 데이터 요소는 값을 빈값으로 갖거나 태그가 없을 수 있습니다.

DICOM 표준에서는 세 개의 데이터 요소 타입을 정의하고 있습니다:

• 타입 1: 값을 반드시 가져야 하는 필수 요소.
• 타입 2: 다른 연관된 요소에 따라 값을 가질 수도 가지지 않을 수도 있는 조건적으로 필요한 요소
• 타입 3: 값을 가질 수도 가지지 않을 수도 있는 선택적 요소.

'1C' 태그 타입은 유형 1과 유형 2의 조합으로, 특정 조건에서는 요소가 값을 가져야 하지만 다른 조건에서는 비어 있거나 존재하지 않을 수 있는 태그 타입입니다. DICOM 파일을 읽거나 쓸 때 '1C' 데이터 요소를 올바르게 처리하여 해당 요소에 대해 정의된 조건에 따라 데이터가 적절하게 해석되고 처리되도록 해야 합니다.

참조

https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_7.4.html

https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_7.4.2.html

https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_7.4.3.html

https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_7.4.5.html

DICOM 태그를 다루면서 종종 간과하는 사실 중 하나가 태그 값의 길이입니다.

DICOM 태그 값의 길이는 항상 짝수입니다. 

홀수 길이의 DICOM 태그 값에 대한 제한은 짝수 길이 값을 기반으로 하는 DICOM 데이터의 형식 및 구조 때문입니다. 

1. 길이가 짝수인 태그 값의 표준화를 통해 DICOM 데이터를 여러 시스템 및 소프트웨어 애플리케이션에서 효율적이고 일관되게 구문 분석하고 처리할 수 있습니다.

2. 모호하거나 호환되지 않는 데이터 형식으로 인해 발생할 수 있는 오류 및 상호 운용성 문제를 방지하는 데 도움이 됩니다.

3. 길이가 짝수인 태그 값을 사용하면 DICOM 데이터를 저장하고 전송하는 프로세스가 간소화됩니다.

4. 데이터를 고정 길이 필드로 보다 효율적으로 압축하고 컴퓨터에서 더 빠르게 처리할 수 있습니다.

따라서 이러한 제한은 DICOM내에서 데이터의 효율적이고 일관된 처리를 가능하게 하고 오류 및 상호 운용성 문제를 방지하는 데 도움이 됩니다.

A second operation was started on this context instance before a previous operation completed. 와 같은 문제가 발생했을 때 해결 방법에 대해 알아봅니다.

원인

A second operation was started on this context instance before a previous operation completed. This is usually caused by different threads concurrently using the same instance of DbContext. For more information on how to avoid threading issues with DbContext, see https://go.microsoft.com/fwlink/?linkid=2097913. 와 같은 Exception이 발생합니다.

찬찬히 설명을 보면 뭔가 멀티 스레딩 관련 오류인 것을 확인할 수 있습니다. 직접 MSDN 페이지에 들어가 보니 다음과 같은 설명이 쓰여있습니다.

Entity Framework Core는 동일한 DbContext 인스턴스에서 실행되는 여러 병렬 작업을 지원하지 않습니다. 여기에는 비동기 쿼리의 병렬 실행과 여러 스레드에서의 명시적 동시 사용이 모두 포함됩니다. 따라서 항상 await 비동기 호출을 즉시 수행하거나 병렬로 실행되는 작업에 대해 별도의 DbContext 인스턴스를 사용합니다.

비동기 메서드를 사용하면 EF Core는 비차단 방식으로 데이터베이스에 액세스 하는 작업을 시작할 수 있습니다. 그러나 호출자가 이러한 메서드 중 하나가 완료되는 것을 기다리지 않고 DbContext에 대해 다른 작업을 계속 수행하면 DbContext의 상태가 손상될 수 있습니다(가능성이 매우 높음).

결국 한 콘텍스트가 다른 비동기 호출에 의해 사용되면서 발생한 것으로 확인되었습니다.

수정

사실 저는 하나의 단일 콘텍스트를 통해 작업하려고 했기 때문에 DBContext를 AddSingleton으로 등록해 둔 상태였습니다.

            IHost host = Host.CreateDefaultBuilder(args)
                .ConfigureServices(services =>
                {
                    services.AddSingleton<DBManager>();
                })
                .Build();

위와 같은 설명에 따라 AddSingleton을 AddTransient로 교체해 간단하게 문제를 해결할 수 있었습니다.

            IHost host = Host.CreateDefaultBuilder(args)
                .ConfigureServices(services =>
                {
                    services.AddTransient<DBManager>();
                })
                .Build();

이제 콘텍스트를 호출하게 되면 호출마다 새로운 인스턴스가 생성되며 발생하던 문제는 해결됩니다.

RabbitMQ에서 VirtualHost(vhost)란 하나의 RabbitMQ 브로커에서 여러 개의 메시지 도메인을 사용할 수 있게 해 주는 논리적 그룹을 의미합니다. 각각의 vhost는 Queue, Exchange, Binding, 권한에 있어서 완전히 분리된 메시징 환경을 가집니다.

vhost는 다른 애플리케이션 유저 또는 부서사이의 메지싱 트래픽을 독립화하고 분리하는 기능을 제공해 줍니다. 기본적으로 RabbitMQ는 브로커 최상단에 위치해 있는 “/”라는 이름의 하나의 vhost를 생성합니다. 하지만 추가적으로 vhost를 메시징 애플리케이션의 요구사항을 충족시키기 위해 필요에 따라 생성할 수 있습니다.

각각의 vhost는 유저나 애플리케이션이 queue로부터 메시지를 소비하거나 교환하거나 발행하는 등과 같은 특정 작업을 수행할 수 있는가를 결정하는 권한들을 갖습니다. 이는 vhost 안에서 메시징 자원에 대한 정교한  컨트롤을 가능하게 합니다.

정리하자면 vhost는 하나의 브로커에서 여러 메시징 도메인을 가능하게 하는 논리적 컨테이너이며 이들 간의 분리와 메시징 트래픽을 컨트롤을 관리 유지 합니다.

EF Core에서 Postgres 사용 시 발생하는 Cannot write DateTime with Kind=UTC to PostgreSQL type 'timestamp without time zone'  에러를 해결하는 방법에 대해 알아봅니다.

현상

public class SomeClass
{
    [Column("created_on")]
    public DateTime? created_on { get; set; }
}

위와 같이 nullable DateTime 값을 수정하고자 할 때 Cannot write DateTime with Kind=UTC to PostgreSQL type 'timestamp without time zone' 오류가 발생.

수정

직접 setter를 구현해 명시적으로 DateTime.Kind를 설정합니다.

public class SomeClass{
    [Column("created_on")]
    private DateTime? _created_on
    public DateTime? created_on 
    {
        get
        {
            return this._created_on;
        }
        set 
        {
            this._created_on = DateTime.SpecifyKind(value, DateTimeKind.Utc); 
        }
    }
}

위와 같이 수정하면 정상적으로 nullable DateTime 컬럼이 수정됩니다.

컨테이너 별로 DB를 다르게 사용하는게 좋습니다.

컨테이너와 PostgreSQL을 함께 사용하는 경우 일반적으로 컨테이너별로 별도의 스키마를 사용하는 것보다 컨테이너별로 데이터베이스를 분리하는 것이 좋습니다.

각 컨테이너가 이상적으로 자체 데이터베이스 인스턴스를 포함하여 자체 독립 환경을 가져야 하기 때문입니다. 각 컨테이너에 대해 별도의 데이터베이스를 사용하면 데이터가 각 컨테이너 내에서 격리되고 안전하며 한 컨테이너의 데이터베이스에 대한 변경 사항이 다른 데이터베이스에 영향을 미치지 않도록 할 수 있습니다.

반면에 단일 데이터베이스 내에서 각 컨테이너에 대해 별도의 스키마를 사용하는 경우 두 컨테이너가 동일한 스키마에 액세스하거나 수정하려고 하면 데이터 유출 또는 충돌의 위험이 있습니다. 이로 인해 데이터 일관성 문제와 잠재적인 보안 취약성이 발생할 수 있습니다.

물론 밀접하게 관련되어 있고 데이터를 공유해야 하는 소수의 컨테이너가 있는 경우와 같이 별도의 스키마를 사용하는 것이 적합한 경우가 있을 수 있습니다. 이러한 경우 권한이 없는 사용자가 실수로 데이터를 유출하거나 수정하지 않도록 권한 및 액세스 제어를 신중하게 관리하는 것이 중요합니다.

DICOM Modality Worklist (MWL)은 의료 영상에서 환자 정보 및 검사 요청을 병원의 방사선 정보 시스템(RIS)이나 병원 정보 시스템(HIS)에서 가져와 CT, MRI, X-ray 및 초음파 등의 영상 장비에 표시하는 표준 프로토콜입니다.

HIS(병원 정보 시스템), RIS(방사선 정보 시스템) 및 EMR/EHR 솔루션은 환자 인구 통계 및 검사 일정 정보의 마스터 인덱스를 제공합니다. Modality Worklist는 환자 주문, 검사 요청 및 환자 이름, ID, 검사 유형 및 일정 정보와 같은 관련 정보 목록을 제공합니다.

Modality worklist는 필요한 환자 데이터와 검사 세부 정보를 검색하기 위해 모달리티 워크리스트에 액세스 할 수 있으며, 이를 통해 수동 입력의 필요성을 제거합니다. MWL이 없으면 양식은 환자 건강 관리 정보(PHI)를 가져와 양식에 수동으로 입력해야 합니다. 이 프로세스는 추가 수작업과 인적 오류의 위험을 초래할 수 있습니다.

DICOM Modality Worklist를 사용하면 방사선과 기술자는 올바른 환자에게 올바른 검사를 수행하고 참조 의사나 환자 치료에 참여하는 기타 의료 전문가로부터 특정 지시사항이나 특별 요청 사항을 볼 수 있습니다. 모달리티 워크리스트는 작업 흐름 및 효율성을 향상시키고 검사 지연을 줄이며 환자 안전을 향상시킬 수도 있습니다.

References:

DICOM Modality Worklist

DICOM Modality Worklist & MPPS

SSH 연결 중 Permissions for are too open. 문제가 발생했을 때 해결하는 방법에 대해 알아봅니다.

현상

KeyPair을 사용해 ssh 접속을 하는데 Permissions for are too open. 오류가 발생합니다.

수정

사용에 적절한 권한을 부여합니다. 전 Windows 환경이므로 Windows 기준으로 설명합니다.

키페어 파일을 우클릭 후 속성창을 열어 보안 탭으로 이동해 고급 버튼을 클릭합니다.

이후 위 사진과 같이 상속 사용 안함을 클릭해 "이 개체에서 상속된 사용 권한을 모두 제거합니다"를 선택합니다.

모든 상속받은 권한이 사라진것을 확인한 뒤 명시적으로 추가 버튼을 눌러 다음과 같이 사용할 유저를 직접 선택합니다.

여기서 중요한점은 "단일" 주체에 권한을 부여해야 한다는 겁니다. 만약 정확한 사용자명을 모르고 "그룹"에 권한을 부여해면 동일한 에러가 계속 발생할 수 있습니다.

만약 정확한 사용자명을 모른다면 다음과 같이 사용사를 검색해 봅시다.

이후 지금 찾이 버튼을 클릭해 정확한 유저 이름을 확인합니다.

유저를 찾았으면 다음과 같이 해당 보안 주체에게 부여할 권한을 선택합니다.

변경 내용을 확인하고 적용합니다.

이제 다시 SSH 접속 시도를 해봅니다.

정상적으로 접속이 되는 것을 확인할 수 있습니다.

윈도우 11 업그레이드 이후 Explorer에서 우클릭 시 "더 많은 옵션 표시"를 기본값으로 변경하는 방법에 대해 알아봅니다.

변경된 기본 컨텍스트 메뉴

윈도우 11로 업그레이드 되면서 많은 기본 UI들이 변경 되었습니다. 다양한 기능이 사용하기 편하게 변경 되었으나 파일 익스플로러의 컨텍스트 메뉴는 다양한 옵션을 사용하기 더 불편해 졌습니다.

항상 "더 많은 옵션 표시"로 변경하기

명령창에서 레지스트리를 건드려줘야 합니다. 먼저 명령창, 파워쉘 혹은 터미널을 열어줍니다.

이후 다음 명령어를 수행해 줍니다.

reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve

이제 변경내용을 바로 파일 익스플로러에 반영시켜주기 위해 파일 익스플로러를 재시작해 줘야 합니다. 작업관리자를 열어 다음 작업을 수행하거나 명령창에 다음 명령어를 수행합니다.

또는

 taskkill /f /im explorer.exe

이후 정상적으로 파일 익스플로러가 종료되었다면 다음과 같이 다시 시작시켜 줍니다.

또는

explorer

이후 익스플로러가 실행된 뒤 우클릭 하면 정상적으로 "더 많은 옵션 표시"가 기본값으로 적용된 것을 확인할 수 있습니다.

출처: How-To: Disable new context menu, Explorer command bar