안녕하세요 연구실에서 자체적으로 실험기기와 컴퓨터랑 통신을 진행하는 중인데, 하나가 해결이 안 되어서 너무 답답해서 고수님들께 자문을 구하려고 합니다. Rs232 rtu 모드를 지원한다고 한 OS-20 overhead stirrer과 통신을 진행 중 입니다. 이 친구의 통신 규격과 방식은 아래 그림 3개와 같습니다. 이중 stirrer control 부분을 제가 참조해서 저 command를 hex 방식으로 입력하였는데 도무지 안되는 겁니다. 그런데 웃긴게 이 회사에서 지원하는 공식 통신프로그램을 사용하면 작동이 잘 되더군요. Instruction overview에서 나온 규칙은 다음과 같습니다. Command 구조는 Prefix Instruction_code Data_frame Checksum로 되어 있고 입력의 prefix는 0xfe로 시작하며 responce는 0xfd로 시작합니다. 모든 바이트 사이에는 50ms delay가 존재해야하며 Dataframe은 큰 수 자리부터 전송합니다. ex) 1000rpm을 data frame에 입력하려고 할 시 Hex값이 03E8이니까 앞에 두 자리를 0x03에 해당하고 뒤에 두 자리를 0xE8로 해당시킵니다. Null은 0x00입니다. Checksum 방식은 0xfe,0xfd인 prefix를 제외하고 나머지를 전부 더한 값으로 0xnn 이런식으로 표현됩니다. 신기하게도 16진수의 2자리를 넘어가도 뒤에 2 자리만 붙이면 된다고 하더군요. ex) 0xfe 0xb1 0x03 0xe8 0x00 checksum인데 0xfe를 제외하고 다 더하면 019c이지만 0x9c만 입력하면 되는 형식입니다. 그래서 이 규칙대로 코드를 짜서 통신을 해 보았는데, 아무리 해도 안되어서 너무 답답합니다. 심지어 제가 잘못했는지 확인하려고 시리얼 통신 sniffer을 사용하여서 공식 프로그램에서는 어떻게 통신이 되나 뜯어보았습니다. 결과는 아래 사진과 같습니다. 제가 python으로 작성한 코드는 아래와 같습니다. import serial import time ser = serial.Serial( port='COM7', # Update with your actual port baudrate=9600, parity=serial.PARITY_NONE, # No parity stopbits=serial.STOPBITS_ONE, # 1 stop bit bytesize=serial.EIGHTBITS # 8 data bits ) def send_hex_string(hex_string): # Convert the hex string to bytes byte_data = bytes.fromhex(hex_string) # Send the bytes over the serial port ser.write(byte_data) def send_hex_string_with_delay(hex_string, delay_ms=50): for i in range(0, len(hex_string), 2): # Extract each pair of characters and convert to bytes hex_pair = hex_string[i:i + 2] byte_data = bytes.fromhex(hex_pair) # Send the bytes over the serial port ser.write(byte_data) # Wait for the specified delay time.sleep(delay_ms / 1000.0) command = 'feb103e8009c' send_hex_string_with_delay(command) ser.close() 또한 파이썬에서의 결과를 시리얼 전송으로 보면 다음과 같습니다. 입력은 제대로 되는데 기기에는 반응이 제대로 나오지 않네요... 제가 잘못하고 빠뜨린 점이 있을까요? 읽어주셔서 정말 감사드립니다.
몇주전에 MSA 후속 강의에 대해 문의드렸습니다. 이벤트 소싱, 보상 트랜잭션 등 후속 강의 계획이 있으신건가요? 계획이 있고, 로드맵을 알려주시면 기다릴텐데.. 아무 소식이 없이 계속 미루어지고 있습니다. 저와 같이 해당 강의를 이미 들으셨던 분, 새로 들으시는 분들 모두가 궁금해하고 듣고싶은 강의라고 생각됩니다. 후속 강의가 없다면, 해당 강의의 내용만으로는 사실 실무에서는 사용하기 어렵다고 생각됩니다. axon framework 를 별도로 공부해서 어떻게 할지 감은 오지만, 그래도 강사님이 실무에서 사용했던 방법을 공유받고 싶은 마음입니다. 꼭 좀 계획을 공유부탁드립니다. 혹시라도 후속 강의에 대한 계획이 없는거여도 말씀 좀 부탁드립니다.
안녕하세요~ 강의를 듣다가 제가 뭔가 잘못한건지 actuator에 refresh가 동작하지 않아 질문글을 남깁니다. 강의 2-10번 DB 비밀번호 암호화까지 문제 없이 잘 진행하다 재가동 없이 설정파일 갱신하는 부분을 진행하는데 item-service에서 build.gradle에 의존성 추가하고 bootstrap.yml에 설정 옵션 추가했는데 config-server 설정 파일 변경 후 postman 에서 refresh 요청을 날려도 response body 에는 [] 빈 배열만 찍히고 별다른 문구가 없고 변경된 설정이 적용되지 않더라고요 강의를 봐도 크게 설정하는 부분이 많은건 아니어서 잘 적용된 것 같은데 작동하지 않는 원인이 콘솔에 찍히지 않아서 헤메고 있습니다. build.gradle 의존성과 bootstrap.yml 에 설정 추가하고 config-server 실행시키고 item-service 실행시킨 후 설정 파일에 변경점을 주고 localhost:5000 번으로 /actuator/refresh 요청을 날렸습니다. 그리고 물품등록 요청을 보내서 200코드 성공했는데 별도의 logs 폴더에 api-local2.log는 생기지 않았습니다. 강의와 다르게 한건 인텔리제이로 프로젝트 구성한 것과 스프링부트 마이너 버전만 달라서 크게 문제가 있지는 않을 것 같은데.. 2-10 강의까지 해본 깃 주소도 올려봅니다. https://github.com/doyoun8813/Microservice
mariadb가 아닌 oracle로 진행을 해보고 있는데 mariadb의 auto_increment 대신 oracle로 seq를 만들어 자동 증가하게 했습니다. 이렇게 적용을 하니 connector 에서 이런 오류를 주는데 오라클로 할 때는 설정이 많이 다른지 질문드립니다!!! ERROR [my-oracle-connect|task-0] WorkerSourceTask{id=my-oracle-connect-0} Task threw an uncaught and unrecoverable exception. Task is being killed and will not recover until manually restarted (org.apache.kafka.connect.runtime.WorkerTask:196) org.apache.kafka.connect.errors.ConnectException: Scale of Decimal value for incrementing column must be 0 at io.confluent.connect.jdbc.source.TimestampIncrementingCriteria.extractDecimalId(TimestampIncrementingCriteria.java:283) at io.confluent.connect.jdbc.source.TimestampIncrementingCriteria.extractOffsetIncrementedId(TimestampIncrementingCriteria.java:268) at io.confluent.connect.jdbc.source.TimestampIncrementingCriteria.extractValues(TimestampIncrementingCriteria.java:208) at io.confluent.connect.jdbc.source.TimestampIncrementingTableQuerier.extractRecord(TimestampIncrementingTableQuerier.java:230) at io.confluent.connect.jdbc.source.JdbcSourceTask.poll(JdbcSourceTask.java:418) at org.apache.kafka.connect.runtime.AbstractWorkerSourceTask.poll(AbstractWorkerSourceTask.java:452) at org.apache.kafka.connect.runtime.AbstractWorkerSourceTask.execute(AbstractWorkerSourceTask.java:346) at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:189) at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:244) at org.apache.kafka.connect.runtime.AbstractWorkerSourceTask.run(AbstractWorkerSourceTask.java:72) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) [2023-12-06 19:56:27,342] INFO [my-oracle-connect|task-0] Stopping JDBC source task (io.confluent.connect.jdbc.source.JdbcSourceTask:354) [2023-12-06 19:56:27,342] INFO [my-oracle-connect|task-0] Closing resources for JDBC source task (io.confluent.connect.jdbc.source.JdbcSourceTask:366) [2023-12-06 19:56:27,342] INFO [my-oracle-connect|task-0] [Producer clientId=connector-producer-my-oracle-connect-0] Closing the Kafka producer with timeoutMillis = 30000 ms. (org.apache.kafka.clients.producer.KafkaProducer:1297) [2023-12-06 19:56:27,344] INFO [my-oracle-connect|task-0] Metrics scheduler closed (org.apache.kafka.common.metrics.Metrics:693) [2023-12-06 19:56:27,344] INFO [my-oracle-connect|task-0] Closing reporter org.apache.kafka.common.metrics.JmxReporter (org.apache.kafka.common.metrics.Metrics:697) [2023-12-06 19:56:27,344] INFO [my-oracle-connect|task-0] Metrics reporters closed (org.apache.kafka.common.metrics.Metrics:703) [2023-12-06 19:56:27,344] INFO [my-oracle-connect|task-0] App info kafka.producer for connector-producer-my-oracle-connect-0 unregistered (org.apache.kafka.common.utils.AppInfoParser:83) { "name": "my-oracle-connect", "config" : { "connector.class" : "io.confluent.connect.jdbc.JdbcSourceConnector", "connection.url":"jdbc:oracle:thin:@localhost:1521:orcl", "connection.user":"test", "connection.password":"test", "mode": "incrementing", "incrementing.column.name":"ID", "table.whitelist":"USERS", "topic.prefix" : "my_oracle_", "tasks.max" : "1" } }
특정 비즈니스 문제를 설명하는 거대한 도메인에 서브 도메인으로 핵심, 지원, 범용이 있다는 것은 알겠는데요. 그럼 바운디드 컨텍스트는 각각의 서브 도메인과 1:1로 동등한 관계로 매칭이 되는걸까요? 아니면 각각의 서브 도메인 안에 바운디드 컨텍스트가 있고 바운디드 컨텍스트의 갯수는 1개가 아니라 여러개가 될 수 있을까요? 또 아니면 바운디드 컨텍스트 안에 서브 도메인이 들어가고 바운디드 컨텍스트 안에 여러개의 서브 도메인이 있을 수 있을까요? 마지막으로 서브 도메인안에 또 작은 도메인들이 있을 수 있을까요??
이전까지는 도커 서비스를 잘 수행이 됐었습니다. 이번 강의에서 docker-compose.yaml파일을 수정 후 서비스를 내렸다가 다시 올리려고 하니 사진처럼 해당 로그까지만 찍힌 후에 더 이상 진행이 되지 않고 있습니다. 계속 기다려봐도 상태가 그대로인 것을 보아하니 어딘가 문제가 생긴 것 같습니다. yaml파일은 올려주신 파일과 비교해봤을 때 오타나 다른 문제는 없는 것 같습니다. 원래의 docker-compose.yaml로 교체하면 잘 실행이 되는 상태입니다. 뭐가 문제일까요?
앱에서 DDD를 적용해보려고하는데 어려움이 있어 질문드립니다. 앱단에서 어플리케이션 레이어의 서비스는 어떻게든 식별해서 진행이되는데 어그리게잇, 엔티티, 값 객체에서 막막하게 느껴집니다. 막막하게 느껴지는 이유는 결국 데이터를 최종적으로 받아서 저장하는 로직들은 서버단에서 처리를 할 텐데요. 이런 경우에 결국 앱에서는 임시로 데이터를 들고 있는 자료구조 혹은 vo라고 느껴지고 있습니다. 아니면 앱이라는 환경속에서 어그리게잇, 엔티티, 값 객체를 뽑는 것도 생각을 했는데 아직 머리속으로 구조가 잡히지 않고 어떤 방향으로 가는게 좋은지 확신이 들지 않는데요. 어떻게 나아가야할지 좋은 의견 부탁드립니다.
이전 단일 표본 검정에서 정규성 검증을 진행할 때 willcoxon 코드를 알려주실 때stats.wilcoxon(df[’무게‘]-120, alternative=’less’)와 같이 알려주셨는데 이번 대응표본 검정에서 정규성 검증을 진행할 때 willcoxon는 stats.wilcoxon(df[‘after’] ,df[‘before’], alternative = ‘greater’)와 같이 알려주셨습니다.또한 강의에서도 after와 before의 값을 빼서 넣은 값인 df['diff']를 그대로 사용해도 된다고 말씀하셨습니다.그래서 아래 사진과 같이 임의로 df[‘after’] - df[‘before’]를 넣어서 실행해봤는데 결과값이 똑같이 나왔습니다. 그럼 단일 표본 검정에서 알려주신대로 df[’무게‘]-120와 같이 df[‘after’] - df[‘before’]로 생각하고 넣어줘도 무방한 것인가요?
Foo님 안녕하세요. '섹션3 - 어떤 예외를 recordExceptions로 지정할까?'를 수강하던 중 궁금증이 생겨 질문드립니다. <서론> recordExceptions은 '실패라고 간주하여 시스템을 회복시키기 위해 트래픽을 차단할 필요가 있는 상황'에 던져지는 예외로 이해했습니다. 그래서 어떤 상황에서 recordExceptions을 적용해야 할지가 매우 중요할 거라고 생각이 듭니다. 즉 트래픽을 차단할 필요가 있다면 recordExceptions을 던져야 하고 그렇지 않다면 던지지 않아야 할 것입니다. 보통은 트래픽이 많이 몰려서 예외가 발생될 때(ex OutOfMemoryError, RejectedExecutionException) recordExceptions를 적용할 거라고 생각됩니다. <본론> 그런데 트래픽이 많이 몰리지 않을 때에도 recordExceptions를 적용해야 하는 경우가 있을 것 같습니다. 한번 오류가 발생한 api 호출은 그 이후에 여러 번 호출해도 똑같은 오류가 발생될 가능성이 매우 높을 것 같기 때문입니다. (트래픽이 별로 없는 상황에서도) 그렇다면.. '모든' 외부 api 호출들에 recordExceptions를 다 적용해야 하는 건가? 라는 궁금증이 듭니다. 혹은, 생각을 반대로 전환해서, recordExceptions를 적용하지 않아도 되는 api 호출들을 구분해야 하고 나머지는 모두 recordExceptions를 적용하는 것이 맞는 건가? 라는 생각도 듭니다. 즉 어떤 기준으로 recordExceptions를 적용해야 가장 적절한 건지 궁금합니다.