반응형

 

여기서는 STM32CubeMX 5.6.1 버전을 기준으로 할 것이다.

(어짜피 버전이 달라도 UI 또는 편의성 정도의 차이일 것이기에 크게 문제될 것은 없을 것 같다.)

 

MCU는 STM32103C8Tx(LQFP 48) 기준으로 작업할 것이다.

이것 또한 MCU가 다르다고 크게 다를 것은 없다.

 

여기서 MCU의 10번 핀을 PWM 핀으로 사용해볼 것이다.

데이타시트에 보면 확인할 수 있듯이 LQFP48에 대한 10번은 TIM2_CH1 기능을 사용할 수 있도록 되어있다.

타이머 채널들은 모두 PWM이 사용 가능하다고 보면 된다.

이제 STM32CubeMX를 실행하여 MCU의 기본적인 세팅을 해준다.(크리스탈, 디버거 설정 등)

나의 경우 8MHZ 크리스탈이 달려있고 ST-LINK를 사용할 것이기에 RCC_OSC 설정을 해주었고,

PA13, PA14쪽의 SWCLK와 SWDIO 설정도 같이 해주었다.

 

이제 10번 핀(PA0)을 PWM 핀으로 설정해보도록 하겠다 해당 핀을 클릭하면 아래와 같은 메뉴가 뜬다.

여기서 TIM2_CH1을 클릭한다.

이와 같이 노란색으로 바뀌었으며 이 상태는 핀을 사용하겠다고는 했지만 디테일한 세팅이 되어있지 않은 것이다.

위와 같이 TIM2에서 Channel1을 선택한 후 PWM Generation CH1을 선택해준다.

 

이와 같이 설정이 완료된 상태로 변경되었다.

이제 가장 중요한 설정을 할 차례다.

원하는 PWM 주파수를 만들기 위해 Prescaler와 주기 값 등을 지정해주어야 한다.

아래 파라미터 설정을 보고 설명하도록 하겠다.

 

가장 중요한 세가지 값이 있다.

Prescaler와 Counter Period로 PWM 주기를 지정하고 Pulse 값으로 Duty를 지정할 수 있다.

먼저 주기를 설정하기 위해서는 나의 타이머가 얼마의 클럭으로 돌아가는가를 알아야 한다.

 

STM32CubeMX의 Clock Configuration 탭을 확인하면 다음과 같이 클럭을 확인할 수 있다.

위와 같이 APB1 Timer clocks과 APB2 timer clocks를 확인하면 된다.

자신이 어떤 타이머를 사용할지에 따라 위, 아래의 클럭 중 어떤 것을 사용하는지가 결정된다.

이 또한 아래의 데이타시트 Clock tree에서 확인할 수 있다.

이는 MCU마다 차이가 있을 수 있으므로 반드시 Datasheet를 확인해야 한다.

TIM1은 APB2를 쓰고 TIM2,3,4는 APB1을 쓴다. 

나는 여기서 TIM2_CH1을 쓸 것이니 APB1 클럭만 신경쓰면 된다.

 

200hz의 50% Duty의 PWM 파형을 만들어보도록 하겠다.

 

Prescaler = 799

Counter Period = 49

PWM Pulse = 99 

이렇게 지정하였다.

여기서 각 값들이 800, 50, 100도 아니고 1씩 떨어져있는 것을 볼 수 있는데,

이것은 각 값들이 0부터 시작하므로 실제 적용할 값에서 -1을 해주어야 한다.

이제 위 값들이 어떻게 계산되는지 알아보도록 하겠다.

 

APB Clock 이 8Mhz였으므로, 먼저 해당 클럭이 프리스케일링된다.

8,000,000 / 800 (Prescaler) = 10,000 Hz(10Khz)

 

여기서 Counter Period에 의해 200Hz로 조정된다.

10,000 Hz / 50 (Counter Priod) = 200Hz

 

이제 200Hz 주기인 PWM의 Duty를 50% 로 지정한다.

200 / 100 (Pulse) = 2 (50% Duty)

 

CubeMX 에서의 모든 설정은 마쳤다고 볼 수 있다.

여기서 모두 값을 지정해주었지만, 얼마든지 코드 상에서 값을 수정할 수도 있다.

이제 우측 상단의 GENERATE CODE를 눌러서 코드를 생성하고 해당 코드를 불러오도록 한다.

PWM 파형을 동작시키는 코드를 작성해보겠다.

 

HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1); 한줄만 추가해주면 되므로 매우 간단하다. 

코드를 보면 유추할 수 있듯이 TIM2의 CH1의 PWM을 동작하도록 하는 코드이다.

이제 컴파일 후에 실행하여 결과를 확인해보면 정상적으로 PWM 파형이 발생하고 있을 것이다.

(참고로 Unknown Target 과 같은 컴파일 오류가 발생한다면 프로젝트 옵션에서 Target MCU 설정을 해주어야 한다.)

반응형
반응형

[2021-08-20T07:53:00,865][INFO ][org.logstash.beats.BeatsHandler][main][85cdcfd8ac49789653328fffd54627260e267cb5c24953396322a6d4da0521f2] [local: 172.11.0.3:5000, remote: 142.128.153.77:53930] Handling exception: io.netty.handler.codec.DecoderException: org.logstash.beats.InvalidFrameProtocolException: Invalid version of beats protocol: 69 (caused by: org.logstash.beats.InvalidFrameProtocolException: Invalid version of beats protocol: 69)
[2021-08-20T07:53:00,865][WARN ][io.netty.channel.DefaultChannelPipeline][main][85cdcfd8ac49789653328fffd54627260e267cb5c24953396322a6d4da0521f2] An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.handler.codec.DecoderException: org.logstash.beats.InvalidFrameProtocolException: Invalid version of beats protocol: 69
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:477) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:404) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:371) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:354) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.channel.AbstractChannelHandlerContext.access$300(AbstractChannelHandlerContext.java:61) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.channel.AbstractChannelHandlerContext$4.run(AbstractChannelHandlerContext.java:253) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-all-4.1.65.Final.jar:4.1.65.Final]
        at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: org.logstash.beats.InvalidFrameProtocolException: Invalid version of beats protocol: 69
        at org.logstash.beats.Protocol.version(Protocol.java:22) ~[logstash-input-beats-6.1.6.jar:?]
        at org.logstash.beats.BeatsParser.decode(BeatsParser.java:62) ~[logstash-input-beats-6.1.6.jar:?]
        at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:446) ~[netty-all-4.1.65.Final.jar:4.1.65.Final]
        ... 11 more
------------------------------------------------------------------------------------------------------------------------------

 

현재 로깅 시스템 구축을 위해 FileBeat로 LogStash에 로깅 데이타를 Shipping 하는 방법으로 구성해놓았다.

그런데 로그스태시쪽에서 위와 같은 오류를 뿜어내기 시작했다. 

org.logstash.beats.InvalidFrameProtocolException: Invalid version of beats protocol: 69 이런 오류와 동시에

org.logstash.beats.InvalidFrameProtocolException: Invalid version of beats protocol: 71 오류가 발생하기도 한다.

이런 경우 오류 내용에서도 알 수 있듯이 버전 호환이 잘 되지 않는 것이다.

위 문제 발생시 내가 쓰고 있는 ELK 스택의 버전은 7.14.0이었고, FileBeat의 버전은 7.4.2였는데 버전 차이로 인한

프로토콜의 차이가 발생하여 위와 같은 에러가 발생하는 것으로 추측했다.

FileBeat 버전도 최신버전인 7.14.0으로 업그레이드하고 테스트해보니 해당 문제는 사라졌다.

 

반응형
반응형

 

플러터가 2.0이 발표되면서 프로젝트 관리에 이슈가 생겼다.

안정적인 프로젝트 운영을 위해 2.0으로 업그레이드하는 것이 마땅하나,

이미 1.0으로 개발을 완료한 프로젝트를 2.0으로 업그레이드하기란 그렇게 간단하지 않기 때문이다.

게다가 플러터 1.0으로 개발된 프로젝트가 많은 상황에 플러터 버전을 2.0으로 업그레이드하는 순간

모든 프로젝트들을 플러터 2.0에 맞게 마이그레이션해주어야 하는데 보통 일이 아니다.

 

나의 경우도 계속 2.0으로 업그레이드하는 것을 미루다가 플러터의 특정한 패키지 버그 해결을 위해

플러터 2.0 업그레이드가 불가피해져서 업그레이드하기로 결정했는데 다 바꾸기엔 무리가 있으니,

해당 프로젝트 하나만 플러터 2.0으로 마이그레이션 하기로 결정하였다.

이 때 사용하는 것이 FVM(Flutter Version Management)이라는 것이다.

이 FVM을 사용하게 되면 프로젝트별로 원하는 버전을 쉽게 변경해서 사용할 수 있다.

A라는 프로젝트는 플러터 1.0, B라는 프로젝트는 플러터 2.0 이런 식으로 선택적으로 사용할 수 있게 된다.

또 B라는 프로젝트가 플러터 2.0으로 사용하고 있더라도 fvm으로 1.0으로 변경해서 사용할 수도 있다.

 

이제 FVM 사용하는 방법을 설명할 것이다.

 

1. 먼저 FVM을 활성화한다.

터미널(혹은 명령프롬프트)을 열고 아래 명령을 실행한다.

dart pub global activate fvm

(위 명령이 되지 않는다면 pub global activate fcm 이 명령으로 실행해보도록 한다.)

※ 혹시나 무언가 잘못되어서 되돌려야 하는 경우라면 pub global deactivate fvm 명령을 사용하면 된다.

 

2. 환경변수 path를 실행해준다.

윈도우10 기준으로 보통 'C:\Users\사용자이름\AppData\Local\Pub\Cache\bin' 이 경로를 설정해주면 될 것이다.

MAC일 경우는 export PATH="$PATH":"/Users/사용자이름/.pub-cache/bin" 과 같은 형태로 지정해주면 된다.

(사용자이름은 본인의 PC에 설정된 사용자이름으로 치환해서 사용한다.)

그리고 MAC에서는 터미널 실행시마다 적용될 수 있게 ~/.bashprofile 파일 내에도 위 패스에 대한 것을 적용해주도록 한다.

(zsh을 사용한다면 ~/.zshrc를 수정해야 하며 없으면 생성하여 내용을 추가하면 된다.)

 

※ 혹시나 Dart 경로(나의 경우는 C:\flutter\bin\cache\dart-sdk\bin)도 환경변수에 지정되어 있지 않다면 지정해준다.

   Dart 경로를 추가하는 이유는 fvm 활성화 후 실행할 fvm 명령이 내부적으로 dart의 pub 명령어를 실행하기 때문이다.

 

경로 지정을 해주지 않을 경우 아래와 같은 오류가 발생할 수 있으므로 참고하도록 한다.

-------------------------------------------------------------------
Installed executable fvm.
Warning: Pub installs executables into C:\Users\Master\AppData\Local\Pub\Cache\bin, which is not on your path.
You can fix that by adding that directory to your system's "Path" environment variable.
A web search for "configure windows path" will show you how.
Activated fvm 1.3.7.
-------------------------------------------------------------------

 

3. fvm help 명령을 실행해서 설치가 정상적으로 되었는지 확인한다.

이런 형태로 명령어 목록이 뜬다면 정상적으로 설치된 것이다.

 

4. 사용할 플러터 버전을 설치한다.

fvm을 사용할 경우 fvm 내부에서 플러터 버전을 별도로 관리하므로,

기존에 쓰던 플러터 버전은 아무 의미가 없다.

나의 경우 기존 플러터 버전을 1.22.5를 사용했었고, 이 버전과 최신버전 두가지 버전으로 관리할 것이다.

아래 두 명령을 실행하여 플러터 두가지 버전을 모두 설치해준다.

fvm install 1.22.5

fvm install stable (이 명령은 최신의 안정적인 플러터 버전을 설치해준다.)

 

5. 설치된 버전을 확인해본다.

fvm list 명령을 사용하여 아래와 같이 설치된 버전 목록을 확인할 수 있으며,

해당 플러터 버전들이 어느 경로에서 관리되고 있는지도 확인할 수 있다.

 

6. 내가 원하는 프로젝트에 원하는 플러터 버전을 적용한다.

터미널에서 플러터 버전을 적용할 프로젝트 경로로 이동한다.

그리고 fvm use라는 명령어를 사용하여 원하는 버전으로 변경할 수 있다.

최신버전의 플러터 버전을 사용하기 위해 아래 명령을 실행한다.

fvm use stable (다른 버전을 사용하려면 fvm use 다른버전을 입력하면 된다.)

위와 같이 표시된다면 정상적으로 버전이 변경된 것이다.

 

※ 오류 대응 방법

(1) Could not install stable 에러 발생

만약 위와 같은 에러가 뜬다면, 명령프롬프트에 관리자 권한이 필요한 것일 수 있다.

윈도우10이라면 PowerShell을 관리자 권한으로 실행해서 사용하면 정상적으로 동작할 것이다.

 

(2) FVM 업그레이드를 요하는 문구

___________________________________________________
FVM Update Available 1.3.7 → 2.2.2
Changelog: https://pub.dev/packages/fvm/changelog
Run pub global activate fvm to update
___________________________________________________

 

위와 같이 뜨는 경우는 flutter upgrade를 통해 기존에 사용하던 플러터를 최신버전으로 업그레이드하면 된다.

그리고 다시 fvm을 활성화하는 명령을 실행해주면 정상적으로 동작하게 된다.

 

7. 해당 프로젝트에 원하는 버전이 정상적으로 적용되었는지 확인한다.

fvm flutter --version 명령을 실행한다.

위와 같이 정상적으로 stable 버전이 선택된 것을 확인할 수 있다.

flutter --version 명령을 실행할 경우 fvm 외부의 플러터 버전이 보여지므로 착오하지 않도록 한다.

 

8. 안드로이드 스튜디오에서 fvm에서 설정한 버전을 사용하도록 변경한다.

아무리 fvm use로 버전 변경을 하더라도 해당 프로젝트에서 fvm 플러터 버전을 참조하도록 경로 수정을 하지 않는다면 의미가 없다.

안드로이드 스튜디오를 실행하고 File -> Setting -> Languages & Frameworks -> Flutter -> Flutter SDK Path를 프로젝트 루트에 생성된 .fvm/flutter_sdk 의 경로를 지정해주면 된다.

위와 같이 적용하고 OK 버튼을 눌러주면 모든 설정이 끝난다.

이제 해당 프로젝트를 빌드하거나 디버깅을 하게 되면 적용된 플러터 버전으로 실행할 수 있을 것이다.

다만, 적용한 플러터 버전에 맞게 프로젝트 내의 소스 코드나 패키지도 마이그레이션해야 정상적으로 실행될 것이다.

그리고 터미널에서 빌드시에 flutter build apk, flutter build ios 등의 명령들을 사용하게 되는데, 

이 때에도 fvm flutter build apk, fvm flutter build ios와 같이 적용 중인 플러터 버전으로 빌드할 수 있는 명령어로 사용해야한다.

반응형
반응형

 

오늘은 AWS에서 가장 많이 쓰는 EC2의 T계열 인스턴스의 특성을 설명한다.

EC2를 사용할 때 가장 흔하게 t2.micro 프리티어를 사용한다.

처음 사용할 때만 해도 특별한 생각 없이 사용했었는데 cpu 성능을 제공하는 방식이 조금 특별하다.

일반적으로 CPU 성능이 정해져있어서 24시간 같은 성능을 제공할 것이라 생각하지만,

T계열 인스턴스들은 기본 성능을 제공하다가, 유저들이 몰리거나 하는 등 기준 이상의 성능이 필요할 경우 버스트 기능이 동작하게 된다. 물론, 공짜는 아니고 인스턴스 사양마다 제공되는 크레딧이 다르고 그 크레딧이 남아있는 동안 버스트 기능을 사용할 수 있다.

 

기준 이하 성능 사용을 지속할 경우 크레딧이 쌓이고(한계치 있음), 그 이상의 성능을 사용할 경우 크레딧을 소모시킨다.

크레딧이 다 소모되면, 기준 이상의 성능을 발휘하지 못하고 성능은 급격히 떨어지게 된다.

이러한 특성은 평소에는 CPU사용률 저조하다가 특정 시간대에 높은 사용률을 사용해야 할 경우 매우 효율적이다.

 

그렇지 않고, 24시간 내내 부하가 존재하는 서버의 경우 m4, m5 계열의 인스턴스를 사용하는 것이 바람직하다.

이 계열의 경우는 T계열처럼 크레딧 개념을 사용하지 않고 항상 같은 성능을 제공해준다.

다만, 가격이 비싸다는 장점이 있기 때문에 자신의 서버가 어느 특성에 적합한지를 판단하여 사양을 결정하는 것이 좋다.

 

T계열 인스턴스 사용시 크레딧의 상태는 CloudWatch에서 확인할 수 있다.

추가로 무제한 모드라는 것이 존재하는데, 이는 크레딧을 모두 소모하고 난 후에도 기준 이상의 성능을 사용할 때 비용을 추가하여 기준 이상의 성능을 사용할 수 있는 모드이다.

t2 인스턴스는 무제한 모드가 기본으로 꺼져있지만, t3 인스턴스의 경우 무제한 모드가 기본으로 옵션이 켜져있으므로 참고하기 바란다.

 

프리티어를 쓰는게 아니라면 t2보다는 t3 계열 인스턴스 사용하는 것을 추천하며,(아무래도 성능 향상, 비용 절감 등의 효과가 있다)

t3 계열의 경우 t3와 t3a가 나눠지는데, 두 계열 성능은 크게 다르지 않고 가격은 t3a가 싸다.

t3는 intel cpu, t3a는 amd cpu를 쓰는데, 가성비를 따져보면 t3a가 더 나은 것으로 생각된다.

 

반응형
반응형

 

보통 페이지 이동시 Navigator의 pushNamed 혹은 push를 이용한다. 

반대로 페이지를 종료할 경우 pop 함수를 이용한다.

그런데 이러한 기능을 사용하다가 처음 페이지 혹은 앞의 특정 페이지까지 바로 이동해야 할 경우가 발생할 수 있다.

물론 pop() 함수를 여러번 사용하여 해당 문제를 해결할 수도 있지만,

push된 페이지 수가 많을 경우 그만큼 pop을 호출해야 하므로 매우 비효율적이고,

특정 액션에 따라 페이지를 진입하여 경우에 따라 pop()해야 되는 개수가 달라지는 경우는 pop()함수로 해결이 불가능하다.

이 때, popUntil() 함수를 사용하게 되면 특정 페이지까지 pop()을 호출한 것 같은 효과를 낼 수 있다.

 

Navigator.popUntil(context, ModalRoute.withName("/"));

 

위 코드는 첫 홈화면까지 pop()을 진행하는 코드이다.

다만 주의해야 할 것이 있다.

popUntil의 두번째 인수로 사용되는 것이 어떤 것을 의미하는지 알아야 한다.

위 코드에서는 "/"으로 쓰였는데 루트로 이동하는 코드이지만 이것 또한 주의할 것이 있다.

 

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Demo',
      debugShowCheckedModeBanner: false,
      onGenerateRoute: _routes(),
      home: MainScreen(),
    );
  }
}

 

위 코드는 가장 메인에 해당하는 코드인데, MaterialApp의 home 속성이 MainScreen()로 지정되어있다.

즉, 이 상황에서 여러 push가 이루어지고, Navigator.popUntil(context, ModalRoute.withName("/")); 코드가 실행되면, MainScreen() 화면까지 pop()이 이루어지게 된다.

 

그 다음 또 간과할 수 있는 문제가 있다.

홈화면이 스플래시 화면이거나 로그인 화면 등의 경우 해당 화면 액션 처리 후 pushReplacement() 를 통해 Back으로 돌아와도 해당 화면으로 돌아가지 않게 조치하는 경우가 있다.

 

Navigator.of(context).pushReplacement(MaterialPageRoute(builder: (context) => SecondScreen());

위의 코드를 사용하여 첫 홈화면 MainScreen()에서 SecondScreen()로 바뀌었다고 가정하자.

이 때 여러 push로 다른 화면들을 띄워놓고 Navigator.popUntil(context, ModalRoute.withName("/")); 코드를 실행하면 어떻게 될까?

첫 페이지는 SecondScreen()로 바뀌었으니 해당 화면까지 pop()이 되어야 할 것 같지만 SecondScreen()에 대한 라우팅 정보가 없으므로 제대로 홈까지 찾아가지 못하고 모두 pop() 처리를 해버릴 것이다.

 

Navigator.of(context).pushReplacement(MaterialPageRoute(builder: (context) => SecondScreen(), settings: RouteSettings(name: "/")));

 

위와 같이 settings 속성으로 SecondScreen() 화면이 "/" 라우팅을 가진 스크린이라는 것을 알려준다.

그렇다면 이 때부터는 popUntil로 "/"를 지정하더라도 SecondScreen()까지만 pop()을 정상적으로 처리할 것이다.

 

정리하면, popUntil을 정상적으로 사용하기 위해 어떤 페이지든 이동할 때 Routesettings 속성을 반드시 지정하도록 하자.

반응형
반응형

매우 자주 사용하는 위젯 중 하나인데, 사용하면서 한가지 문제를 발견했다.

ListView에 담긴 내용에는 텍스트, 여러 사진들, 구글 지도 등이 포함되어 있었다.

그런데 문제는 예를 들어, 사진이 보이지 않는 곳까지 스크롤을 했다가 다시 돌아오면 사진이 다시 로딩되는 경우가 발생한다.

지도의 경우도 지도가 안보이는 영역까지 스크롤했다가 빠르게 돌아오면 지도가 다시 로딩되는 경우가 발생한다.

일단 이것의 원인은 리스트뷰 위젯이 메모리 관리를 위해 보이는 부분과 일부 주변 영역에 대해서만 불러오고 표시하기 때문이다.(캐싱을 하지 않는 것이다.)

그래서 느리게 천천히 스크롤하면 해당 문제가 없는 것처럼 보인다.

이 문제를 해결하기 위해 스크롤 하여 안보이는 곳으로 이동한다해도 그 공간의 내용들을 캐싱해놓는 것이다.

다행히도 ListView에 cacheExtent라는 속성이 존재한다. 이것은 보이는 영역으로부터 얼마만큼의 주변 영역까지 캐싱해놓을지 지정하는 속성이다.

 


픽셀 값이므로 자신이 필요한 만큼 지정해서 사용하면 된다. 무조건 크게 해놓으면 해당 문제는 발생하지 않겠지만 메모리 관련하여 문제가 발생할 수 있으므로 상황에 맞게 적용하는 것이 좋을 것 같다.

 

반응형
반응형

 

EC2를 처음 세팅하고 SSH로 접속하여 date 명령을 실행해보면 시간이 한국 시간과 다르게 표시되어있다.

UTC라고 하는 세계 표준 시간을 사용하기 때문인데 한국 시간에서 9시간을 빼주면 해당 시간이 된다.

좀 더 편하게 시간을 관리하기 위해 시간을 바꾸는데, 보통 여기서 실수를 많이 할 것 같다.

 

sudo date -s "2021-04-07 20:10:36" 

위와 같이 date명령을 이용해서 날짜와 시간을 변경할 수 있지만 위와 같이 한국 시간으로 바로 변경하면 문제가 된다.

EC2 타임존이 기본적으로 UTC(세계 표준시)로 지정되어있으니, 시간 기준은 세계 표준시로 되어있고 날짜와 시간 값만 한국 시간으로 바뀌게 되는 것이다. 이렇게 되면 다른 서비스와 시간 동기를 맞출 경우 시간이 다르다고 판단하여 인증 등의 문제가 발생할 수 있다.

 

즉, 제대로 변경하기 위해서는 타임존을 한국 시간으로 변경하면 별도의 시간을 지정하지 않아도 된다.

 

sudo cat /etc/localtime

 

위 명령어로 읽어보면 UTC0라는 텍스트가 보일 것이며 이것이 UTC 기준으로 시간이 지정된다는 의미이다.

 

sudo rm /etc/localtime

sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

 

위 두 명령을 차례로 입력해준다.

기존의 UTC기준 타임존 세팅 파일을 제거하고, 서울 기준 타임존 세팅 파일을 적용하는 것이다.

 

sudo cat /etc/localtime 명령으로 확인해보면 KST-9라는 문구가 확인이 된다.

date 명령으로 바로 날짜와 시간을 확인해보면 한국 시간 기준으로 변경된 것을 확인할 수 있다.

 

반응형
반응형

Error: Credential implementation provided to initializeApp() via the "credential" property failed to fetch a valid Google OAuth2 access token with the following error: "Error fetching access token: invalid_grant (Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values in the JWT claim.)". There are two likely causes: (1) your server time is not properly synced or (2) your certificate key file has been revoked. To solve (1), re-sync the time on your server. To solve (2), make sure the key ID for your key file is still present at https://console.firebase.google.com/iam-admin/serviceaccounts/project. If not, generate a new key file at console.firebase.google.com/project/_/settings/serviceaccounts/adminsdk.  

 

AWS EC2에 노드JS 서버를 올려서 푸시 서비스를 사용하고 있는데 어느 순간 푸시를 보낼 때마다 위와 같은 메세지가 뜨면서 푸시 서비스가 제대로 작동하지 않았다. 위에 의심되는 원인이 나열되어있듯이 나의 문제는 (1)번에 해당했다. 

내가 서버의 시간을 실수로 전혀 다른 시간으로 변경하면서, 푸시를 위해 파이어베이스 인증하는 과정에서 OAUTH 토큰의 유효 시간 체크에 대한 문제가 발생한 것이었다. 이 문제는 다시 서버의 시간을 정상적으로 돌리면서 해결되었다.

위와 같은 문제가 발생했을 때 서버의 시간을 확인하여 실제 시간과 오차가 많이 발생하지 않는지 확인해보도록 한다.

 

반응형
반응형

 

IOS 앱 배포를 위해 XCODE를 통해 업로드 하던 중 다음과 같은 오류가 발생했다.

 

Error ITMS-90717: "Invalid App Store Icon. The App Store Icon in the asset catalog in 'YourApp.app' can't be transparent nor contain an alpha channel."

 

앱 아이콘에 알파 채널이 존재하니 알파 채널을 없애라는 의미이다.

 

먼저 XCode의 프로젝트 폴더에서 Runner를 선택한다.

그럼 변경된 화면에서, TARGETS -> Runner -> General 탭 -> App Icons Source 우측의 화살표 모양을 클릭한다.

 

그럼 앱에 사용되는 아이콘 목록이 뜨는데 그 아이콘 목록 중에 1024x1024에 해당하는 이미지 파일을 파인더로 연다.

그 후 내보내기를 알파를 제거하고 진행할 수 있다.

 

 

위와 같이 알파 해제 후 저장을 하여 저장된 파일을 기존 1024x1024 파일에 덮어씌우고,

다시 앱 배포를 진행하면 정상적으로 업로드가 된다.

반응형
반응형

 

플러터로 개발하면서 안드로이드쪽은 그리 문제된 적이 없는데 IOS쪽은 종종 문제가 생기곤 했다.

IOS 빌드 에러가 한두가지는 아니지만 그 중 속 썩였던 에러가 있었다.

 

하나는

Xcode's output:

ld: framework not found Flutter clang: error: linker command failed with exit code 1 (use -v to see invocation) note: Using new build systemnote: Planning buildnote: Constructing build description

 

하나는

Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_FlutterMethodChannel", referenced from: objc-class-ref in FLTPackageInfoPlugin.o "_FlutterMethodNotImplemented", referenced from: -[FLTPackageInfoPlugin handleMethodCall:result:] in FLTPackageInfoPlugin.o

 

물론 위 에러가 해결 방법은 상황에 따라 다를 수 있다.

대부분 자료를 찾아보면 아래처럼 클린 후 빌드하는 것으로 해결을 한다.

flutter clean

flutter run

그런데 나는 이것으로 해결되지 않았고

 

flutter pub cache repair라던지,

Runner.xcworkspace를 실행하여 XCode에서 빌드하는 방법 등 거의 3일간을 삽질한 것 같다.

물론 위의 방법으로 해결되는 것이 가장 좋다.

 

최후의 방법은 플러터 프로젝트에 있는 Build 폴더를 삭제하고, ios 폴더 자체도 삭제를 한다.

(단, ios폴더에 미리 세팅해놓은 코드나 Info.plist, PodFile 파일 등은 백업해놓도록 한다.)

 

모두 삭제를 했다면 아래 명령을 실행한다.

flutter create . 

이는 현재 상태에서 누락되어있는 파일들을 새로 만들어준다. 즉, ios폴더가 새로 만들어진다.

그럼 이전에 세팅했던 Info.plist , PodFile등을 상황에 맞게 세팅한 후 다시 빌드를 해주면 된다.

생각보다 매우 간단하지만, ios 빌드에서 애를 먹고 있다면 굳이 다른 것을 찾을 필요없이

깔끔하게 다시 시작하는게 최고인 것 같다.

 

무언가 빌드하면서 꼬이기 시작하면서 알 수 없는 에러들을 뱉어내는데 이 때는 flutter clean만으로도 

완전히 클린이 되지 않으므로 위와 같은 방법을 써야만 할 것이다.

 

반응형

+ Recent posts