11월, 2023의 게시물 표시

Streptosquarus Shape Count

이미지
  A bacteria called streptosquarus comes in very peculiar shapes. The streptosquarus is flat with no perceived thickness. (It is essentially two-dimensional.) It is composed of an integer number of unit squares. In addition, all the squares in the streptosquarus must be touching at least one other square of the bacteria along edges.  Write a program that takes a positive integer from the user and returns the number of possible different streptosquarus shapes of that size. Notice that there is only one streptosquarus of sizes one and two, but there are two of size three, five of size four, and 12 of size five. 모든 가능한 스트렙토스쿼러스의 형태를 생성하고, 회전과 대칭에 의한 중복을 제거하여 유일한 형태의 수를 계산해야 합니다. 회전과 대칭을 확인하는 로직을 추가하여 중복을 제거하는 것이 핵심입니다. 이 알고리즘은 크기가 커질수록 매우 느려질 수 있으므로, 크기가 5를 초과하는 경우에는 실행 시간을 고려해야 합니다. from collections import deque def generate_streptosquarus(n): if n == 1 : return 1 # All possible moves from a square moves = [( 0 , 1 ), ( 1 , 0 ), ( 0 , - 1 ), (- 1 , 0 )] #...

플러터 함수 호출 앞에 const 붙이는게 된 이유

이미지
위의 플러터 앱 진입점에 있는 main() 함수에서, 예전에는 안 붙이던 MyApp() 앞에 const 가 붙게 되었습니다.  runApp( const MyApp());  이거나 const MyApp({super.key}); 이 곳에 const 는 왜 붙이게 되었는가? Flutter에서 const 키워드를 사용하는 것은 최적화와 관련된 중요한 부분입니다. const 키워드를 사용하여 위젯을 선언하면, Flutter는 그 위젯을 위젯 트리에 한 번만 생성하고, 다시 빌드할 필요가 없는 경우 재사용합니다. 이것은 특히 상태가 변하지 않는(static) 위젯에 유용합니다. 이전 버전의 Flutter에서는 const의 사용이 필수적이지 않았습니다. 하지만, Flutter의 성능을 향상시키고, 앱의 메모리 사용량을 줄이기 위해 const 키워드의 사용이 점점 더 권장되었습니다. const를 사용하는 주요 이점은 메모리 효율성: const로 생성된 객체는 컴파일 시간에 생성되며, 런타임에는 같은 객체를 재사용합니다. 이는 메모리 사용량을 줄이는 데 도움이 됩니다. 성능 향상: const 위젯은 상태가 변하지 않으므로, Flutter 프레임워크가 위젯을 다시 빌드할 필요가 없습니다. 이는 렌더링 성능을 향상시키는 데 도움이 됩니다. 코드 가독성: const를 사용하면 해당 객체가 변경 불가능하다는 것을 명확하게 알 수 있으며, 이는 코드의 가독성과 유지 보수성을 향상시킵니다. 예를 들어, runApp(const MyApp());에서 const MyApp()은 MyApp 위젯이 상태를 가지지 않고, 그 인스턴스가 변경될 필요가 없음을 나타냅니다. 마찬가지로, const MyApp({super.key});는 MyApp의 생성자가 항상 동일한 인스턴스를 반환하도록 보장합니다. 이러한 최적화는 특히 대규모 앱 또는 복잡한 UI를 가진 앱에서 더욱 중요해집니다. 따라서 최신 Flutter 개발에서는 const의 사용이 더욱 강조되고 있습니다....

UGREEN 1-IN 2-OUT Bidirectional HDMI Switcher 4K 60Hz

이미지
오늘 사용해 본 제품은 UGREEN 의 Bidirectional HDMI Switcher 4K 60Hz 제품입니다.  Bidirectional 이기 때문에 2 in 1 Out, HDMI Splitter 로 쓰거나 1 in 2 Out HDMI Selector 로 쓸수 있습니다. 액스박스와 플레이스테이션에 1개 모니터가 있을 때 하고싶은 게임기를 모니터에 연결하는 것으로 쓸 수 있고요.  한개의 컴퓨터 출력을 오늘은 왼쪽 모니터, 내일은 오른쪽 모니터에서 보고 싶을 때 이럴 때 사용할 수 있는 것이죠. 저는 한쪽은 맥에 한쪽은 윈도에 연결해서 한개의 모니터로 출력하는데 쓰려고 샀습니다. 전환 속도는 그렇게 빠르지 않아서 라이브 방송에서 쓸만하지는 않겠네요. 캐나다 아마존 현재 가격은 19불입니다. 슬라임의 간단 리뷰 였습니다.

Phaser JS game framework

Phaser는 HTML5 게임 프레임워크 입니다: 이는 캔버스 및 WebGL을 사용하여 데스크탑과 모바일 브라우저에서 동작하는 2D 게임을 만드는 데 사용됩니다. Phaser는 개방적이고 활발한 커뮤니티와 함께, 매우 포괄적인 문서와 예제를 제공하고 있어 개발자들이 쉽게 게임을 개발할 수 있도록 돕습니다. Phaser를 사용하는 개발자는 JavaScript 또는 TypeScript를 사용하여 게임을 작성할 수 있으며, 프레임워크는 물리 엔진, 스프라이트, 입출력, 사운드 및 음악, 상태 관리 등 게임 개발에 필요한 다양한 기능들을 제공합니다. Phaser의 주요 특징은 다음과 같습니다: Canvas와 WebGL 렌더링 : Phaser는 자동으로 브라우저가 지원하는 가장 적합한 렌더링 방식을 선택합니다. 다양한 게임 오브젝트 지원 : 텍스트, 스프라이트, 타일맵, 파티클 시스템 등 다양한 게임 오브젝트를 지원합니다. 물리 엔진 통합 : Arcade Physics, P2JS, Ninja Physics 등 여러 물리 엔진을 통합하여 사용할 수 있습니다. 입출력 : 키보드, 마우스, 터치 스크린을 위한 강력한 입력 지원을 제공합니다. 애니메이션 : 스프라이트 애니메이션을 쉽게 추가하고 관리할 수 있습니다. 상태 관리 : 게임의 다양한 상태를 관리할 수 있는 시스템을 제공합니다. 자산 관리 : 이미지, 오디오 파일, JSON 데이터 등의 자산을 로드하고 관리하는 로더 시스템을 가지고 있습니다. 모바일 지원 : 모바일 브라우저에 최적화되어 있으며, 반응형 게임을 만들 수 있습니다. Phaser는 대표적인 오픈 소스 게임 프레임워크로, 개인 프로젝트부터 상업적인 게임 개발에 이르기까지 다양한 목적으로 사용됩니다.

ZeroMQ (0MQ, ZMQ)

  ZeroMQ (또는 0MQ, ZMQ)는 고성능 비동기 메시징 라이브러리로, 소켓 프로그래밍을 단순화하여 메시지 큐의 기능을 더 쉽고 유연하게 사용할 수 있게 해줍니다. ZeroMQ를 사용하면 다양한 메시징 패턴을 통해 분산된 시스템과 서비스 간에 데이터를 교환할 수 있습니다. 이 라이브러리는 다양한 프로그래밍 언어로 구현되어 있어, 여러 언어로 작성된 시스템 간에도 통신이 가능합니다. ZeroMQ는 기존의 메시지 지향 미들웨어(MOM) 시스템과는 달리 브로커가 없는 아키텍처를 제공합니다. 이는 메시지를 라우팅하거나 큐잉하는 중앙 서버가 없다는 것을 의미합니다. 대신, ZeroMQ 소켓을 사용하여 직접적으로 클라이언트와 서버, 혹은 노드 간에 통신할 수 있습니다. 이는 시스템의 복잡성을 줄이고 성능을 향상시키는 데 도움을 줍니다. ZeroMQ는 다음과 같은 여러 통신 패턴을 지원합니다: 요청-응답(Request-Reply) : 클라이언트-서버 패턴을 구현하며, 하나의 요청에 하나의 응답을 보냅니다. 발행-구독(Publish-Subscribe) : 메시지를 발행하고 여러 구독자가 메시지를 수신할 수 있는 패턴입니다. 파이프라인(Push-Pull) : 작업 분배자와 작업자 노드 간의 작업 부하 분산을 위한 패턴입니다. 독점적 페어(Exclusive Pair) : 두 노드 간의 전용 연결을 위한 패턴입니다. ZeroMQ는 높은 확장성과 성능을 가지고 있으며, 분산 컴퓨팅, 마이크로서비스 아키텍처, 비동기 태스크 큐, 리얼타임 데이터 전송 등 다양한 분야에서 사용됩니다. 그것의 비동기 I/O 모델과 비블로킹 방식의 소켓 연산은 효율적인 리소스 사용과 빠른 데이터 처리를 가능하게 합니다. ZeroMQ는 복잡한 네트워크 프로토콜과 통신 패턴을 추상화하여 개발자가 메시징 시스템을 더 쉽게 구축할 수 있도록 돕습니다. 이로 인해 개발자는 네트워크의 세세한 부분에 대해 걱정하지 않고도, 메시지 교환 로직에 더 집중할 수 있습니다.

RxJS (Reactive Extensions for JavaScript)

RxJS (Reactive Extensions for JavaScript)는 비동기 및 이벤트 기반 프로그램을 위한 라이브러리입니다. 이는 반응형 프로그래밍 패러다임을 따르며, 데이터 스트림과 변화를 쉽게 생성, 구성, 변환, 관리하고 조작할 수 있는 방법을 제공합니다. RxJS는 옵저버블(Observables)이라는 핵심 개념을 중심으로 구축되어 있습니다. 옵저버블은 데이터 스트림을 비동기적으로 전달하는 객체로, 시간이 지남에 따라 여러 값을 방출할 수 있습니다. 개발자들은 이 옵저버블을 구독하여 데이터 스트림에 있는 값이나 이벤트가 발생할 때마다 반응할 수 있습니다. RxJS는 다양한 유형의 비동기 이벤트를 처리할 수 있게 해주는 방대한 연산자 세트를 제공합니다. 이 연산자들은 필터링, 프로젝션, 변환, 집계 등의 작업을 수행할 수 있어, 복잡한 비동기 코드를 더 선언적이고 관리하기 쉬운 방식으로 작성할 수 있게 도와줍니다. 예를 들어, HTTP 요청, DOM 이벤트, 타이머 등 다양한 소스로부터 생성된 비동기 데이터 스트림을 RxJS를 사용하여 쉽게 다룰 수 있습니다. 이를 통해 개발자는 비동기 코드의 복잡성을 줄이고, 데이터 스트림을 통해 발생하는 다양한 시나리오를 쉽게 조작하고, 여러 데이터 스트림을 결합하고, 에러 처리를 보다 우아하게 할 수 있습니다. RxJS는 프론트엔드 개발, 특히 Angular 프레임워크에서 널리 사용되며, Angular의 HTTP 클라이언트 및 이벤트 처리와 같은 비동기 작업을 처리하는 데 있어 중심적인 역할을 합니다. 하지만 그 사용범위는 Angular에 국한되지 않으며, 모든 JavaScript 환경에서 유용하게 사용될 수 있습니다.

CapacitorJS

  CapacitorJS 는 웹 기술을 활용하여 iOS, Android 및 웹 플랫폼을 위한 크로스 플랫폼 앱을 개발할 수 있도록 해주는 오픈 소스 프레임워크입니다. Capacitor를 사용하면 HTML, CSS 및 JavaScript/TypeScript 같은 웹 기술을 사용하여 하나의 코드베이스로 다양한 플랫폼에 배포할 수 있는 애플리케이션을 만들 수 있습니다. Capacitor는 Ionic 팀에 의해 개발되었으며, 특히 Ionic 프레임워크와 함께 사용하기 위해 설계되었습니다. 그러나 Ionic과 독립적으로 어떤 웹 프레임워크나 라이브러리와도 함께 사용될 수 있습니다. 이는 웹 뷰를 기반으로 작동하지만, 네이티브 기능에 접근할 수 있는 API를 제공하여 웹 앱이 마치 네이티브 앱처럼 느껴지게 합니다. CapacitorJS는 네이티브 코드와의 통합을 용이하게 하고, 플러그인 시스템을 통해 네이티브 기능을 확장할 수 있는 기능을 제공합니다. 또한, 개발자들이 필요에 따라 자체 네이티브 코드를 쉽게 추가할 수 있도록 설계되었습니다. 이를 통해 웹 앱이 카메라, GPS, 파일 시스템 등의 네이티브 기능을 사용할 수 있게 합니다.

Publish/Subscribe (Pub/Sub) 패턴

Publish/Subscribe (Pub/Sub) 패턴은 메시징 패턴 중 하나로, 메시지를 보내는 출판자(publisher)와 메시지를 받는 구독자(subscriber)가 직접적인 연결 없이 메시지를 교환할 수 있는 방식입니다. 이 패턴은 분산 시스템, 이벤트 주도 아키텍처, 메시지 큐 시스템 등에서 널리 사용됩니다. 기본 개념 Publisher : 메시지를 발행하는 주체로, 특정 토픽에 대한 정보를 보냅니다. 발행자는 메시지를 받을 구독자가 누구인지, 또는 메시지가 어떻게 전달되는지에 대해서는 알지 못합니다. Subscriber : 메시지를 구독하는 주체로, 관심 있는 토픽을 구독하고 해당 토픽에 대한 메시지가 발행될 때마다 그 메시지를 받습니다. Message : 특정 데이터 또는 정보를 담고 있는 패킷으로, 특정 토픽에 대한 정보를 포함할 수 있습니다. Topic : 메시지를 분류하기 위한 범주 또는 채널입니다. 구독자는 하나 이상의 토픽을 구독할 수 있으며, 발행자는 하나의 토픽에 대해 메시지를 발행할 수 있습니다. Broker or Message Queue : 발행자와 구독자 사이의 중개자 역할을 합니다. 메시지의 라우팅, 버퍼링, 전달 등을 담당합니다. 구독자와 발행자 사이를 연결하고, 구독자가 오프라인일 때는 메시지를 저장해 둘 수도 있습니다. 장점 탈중앙화 : 구독자와 발행자 간에는 직접적인 연결이 없어, 각자의 처리량과 성능에 영향을 주지 않습니다. 확장성 : 새로운 발행자나 구독자를 시스템에 추가하는 것이 비교적 쉽습니다. 유연성 : 구독자는 필요한 메시지만 선택적으로 받을 수 있으며, 발행자는 구독자의 존재를 신경 쓰지 않고 메시지를 발행할 수 있습니다. 비동기 처리 : 구독자는 메시지를 자신의 처리 속도에 맞추어 처리할 수 있으며, 메시지는 중간에 버퍼링 될 수 있습니다. 단점 메시지 보장 : 일부 Pub/Sub 시스템에서는 메시지가 항상 전달되리라는 것을 100% 보장하지 않습니다 (At-least-once, At-most-once, E...