2021년 3월 30일 화요일

Apple M1에서 Android Room 빌드하기

 intelliJ 2021.1 EAP 혹은 안드로이드 스튜디오 4.1.3 Rosetta2를 사용한 환경에서


Android Room을 사용한 프로젝트를 빌드하면 

다음과 같은 오류로 빌드가 되지 않는다.

Caused by: java.lang.ExceptionInInitializerError
	at androidx.room.processor.DatabaseProcessor.doProcess(DatabaseProcessor.kt:82)
	at androidx.room.processor.DatabaseProcessor.process(DatabaseProcessor.kt:57)
	at androidx.room.RoomProcessor$DatabaseProcessingStep.process(RoomProcessor.kt:134)
	at com.google.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:330)
	at com.google.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:181)
	at org.jetbrains.kotlin.kapt3.base.incremental.IncrementalProcessor.process(incrementalProcessors.kt)
	at org.jetbrains.kotlin.kapt3.base.ProcessorWrapper.process(annotationProcessing.kt:161)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:802)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:713)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1043)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1184)
	at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
	at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1068)
	at org.jetbrains.kotlin.kapt3.base.AnnotationProcessingKt.doAnnotationProcessing(annotationProcessing.kt:78)
	... 30 more
Caused by: java.lang.Exception: No native library is found for os.name=Mac and os.arch=aarch64. path=/org/sqlite/native/Mac/aarch64
	at org.sqlite.SQLiteJDBCLoader.loadSQLiteNativeLibrary(SQLiteJDBCLoader.java:333)
	at org.sqlite.SQLiteJDBCLoader.initialize(SQLiteJDBCLoader.java:64)
	at androidx.room.verifier.DatabaseVerifier.<clinit>(DatabaseVerifier.kt:68)
	... 45 more


Room 프로젝트가 참조하고 있는 sqlite 라이브러리가 m1용 아니라서 생긴다.


implementation ("androidx.room:room-runtime:$room_version") {
    exclude(group:'org.xerial')
}
kapt ("androidx.room:room-compiler:$room_version") {
    exclude(group:'org.xerial')
}
implementation ("androidx.room:room-rxjava2:$room_version") {
    exclude(group:'org.xerial')
}
testImplementation ("androidx.room:room-testing:$room_version") {
   exclude(group:'org.xerial')
}
implementation 'org.xerial:sqlite-jdbc:3.34.0'


요렇게 수정해주면 빌드가 된다.



2020년 8월 30일 일요일

Firebase Crashlytics dSYM 업로드 하기

https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports-fabric-sdk?hl=ko
위 공식문서에는 아래와 같이 Build Phase에 스크립트를 추가하라고 한다.

"${PODS_ROOT}/Fabric/upload-symbols" -gsp "${PROJECT_DIR}/GoogleService-Info.plist" -p ios "${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"

그런데 Fabric Crashlyrics는 공식적으로 Firebase Crashlytics가 되었다.
그러므로 위 스크립트는 제대로 동작하지 않는다.

Fabric 경로는 아래와 같이 FirebaseCrashlytics로 수정해주자.

"${PODS_ROOT}/FirebaseCrashlytics/run"
"${PODS_ROOT}/FirebaseCrashlytics/upload-symbols" -gsp "${PROJECT_DIR}/GoogleService-Info.plist" -p ios "${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"


제대로 실행되지 않는다면 GoogleService-Info.plist 경로를 확인해서 수정해주면 된다.

2020년 7월 15일 수요일

Windows10 환경에서 Elastic Beanstalk 배포가 되지 않는 문제


아주 골머리를 썩게 만든 문제가 있었다.

윈도우에서 bat 스크립트로 elastic beanstalk 배포를 위해 zip으로 묶어서 eb deploy를 하면 도무지 성공하지를 못하는 것이다.

During an aborted deployment, some instances may have deployed the new application version. To ensure all instances are running the same version, re-deploy the appropriate application version.

이런 오류 메시지만 남기고서.

이게 풀리지 않는 문제였는데, 의외로 쉽게 해결했다.

eb log를 확인했을때

[ERROR] An error occurred during execution of command [app-deploy] - [StageJavaApplication]. Stop running the command. Error: Command /bin/sh -c /usr/bin/unzip -q -o /opt/elasticbeanstalk/deployment/app_source_bundle -d /tmp/extracted_app_source_bundle failed with error exit status 1. Stderr:warning:  /opt/elasticbeanstalk/deployment/app_source_bundle appears to use backslashes as path separators
 

이런 메시지가 보인다.

use backslashes as path separators

...

윈도우에서 path 구분자로 사용하는 backslash가 문제였다.
그리고 이건 PowerShell의 archive의 버그란다.

https://superuser.com/questions/1382839/zip-files-expand-with-backslashes-on-linux-no-subdirectories

그냥 다른 압축 프로그램으로 묶어서 올리니까 잘된다.

후. 내 시간.

2020년 6월 18일 목요일

맥북프로 2017 키보드 서비스 프로그램 당첨


Capslock 위치에 있는 한/영키로 키 전환을 하다보면
분명히 눌렀는데 한/영 전환이 안되는 문제가 생겼다.

눌렀는데 왜 이래? 하다가 상태바를 자세히 보니 한->A->한 으로 바뀌는게 아닌가?
한번 눌렀는데 두번 반응?

혹시 이거 나비식 키보드 맛이 가는 그 문제인가?

대충 둘러보니 맞는 분위기다.
바로 지니어스 바 예약하고 애플 가로수길 방문을 했다.


코로나 때문에 입장하기 전에 여러가지 체크를 한다.
하지만 예약을 했기 때문에 다른 줄로 입장 ㅎ


맥불프로 2017 점검 중
맥불프로 2017 점검 중


맥북 세션이 좀 늦어질거라는 안내와는 달리 빠르게 접수 진행이 되었다.

한/영키 눌렀을때 증상을 체크하고는 바로 접수.
외관 검사도 다 통과.

다행히 하루안에 수리 마칠 수 있다고 한다.

빈 파우치를 들고 내부를 둘러봤다.


맥북16인치 키감 좋더라.



대충 봐도 눈에 띄는 건 이 두 녀석이다.

영롱한 XDR 디스플레이

맥프로치즈강판


영상 편집자도 아닌 그냥 개발자 1로서 이런거 사볼 일이 있을까 ㅋㅋ
돈 있으면 하나 사보고 싶기도 하고.


XDR 디스플레이는 6K 32인치임에도 불구하고 옆에 전시되어 있던 27인치 아이맥 프로 대비 그렇게 커 보이지 않는다. 얇아진 베젤 덕분일까.



2020년 3월 12일 목요일

2020년 3월 8일 일요일

BigQuery에서 analytics 데이터 조회시에 event_param.key로 조회하는 방법

SELECT *
FROM analytics_152426080.events_20190626 e CROSS JOIN
     UNNEST(event_params) ep
WHERE e.event_name = 'details_viewtime' AND
      ep.key = 'time_ms';


`cross join`과 `unnest`를 이용해서 할 수 있다.


2020년 2월 13일 목요일

NSSM으로 dotnet Service 등록하기

# .bat 파일을 만들자

dotnet MYAPP.dll



# nssm install MYAPP

Application > Path를 위에서 만든 bat 파일로,
Startup directory를 dotnet dll 및 파일들이 있는 경로로 설정해준다.

이후 [Install Service] 선택


# nssm start MYAPP

하면 작업관리자에서 실행된 것을 확인할 수 있다.

2019년 12월 5일 목요일

만들게 싶은게 있었는데

리서치를 괜히 해봤나 싶다.

만들고 싶은게 있었는데 역시... 비슷한게 이미 있다.
차별화... 이런거 하기에는 굳이 그러고 싶지는 않은데.

비는 영역이 하나 있기는 한데 뭐랄까...
음...

힝 ㅠㅠ

2019년 11월 9일 토요일

XCode ERROR ITMS-90534: Invalid Toolchain

stackoverflow에 검색해봐도 그렇고
역사와 전통이 있는 문제다.

Xcode를 업데이트 해야 해결된다.

그런데 간혹 문제는 릴리즈 되지 않은 GM버전을 사용해야 해결된다거나
(2019. 11. 5 이후 Xcode 11.2 Build deprecated)
하는 것.

휴.

2019년 6월 28일 금요일

c# dotnet core 소감


c# dotnet core,
entity framework core 등으로 프로젝트를 진행 중에 소감.

# 발전된 언어 스펙

Task, async, await 등의 조합은 비동기 코드도 간단하게 작성할 수 있게 해준다.

지역변수 할당에 사용하는 var도 간단한 코드에 한몫을 담당한다.

LINQ, 전통적인 linq 표현보다는 fluent interface 표현이 조금 더 익숙하긴 하지만 강력한 툴이다.

object initializer도 편리하다.
물론 유지보수 측면을 생각하면 factory method pattern이 갖는 장점이 더 많겠지만
굳이 builder를 따로 만들지 않아도 된다.

# entity framework(이하 ef)

ef code first migration을 사용하고 있는데,
조금 번거롭긴 해도(?) DDL을 직접하지 않아도 되고
staging 관리도 괜찮은 것 같다.

# Dotnet Core

CLI에서 dotnet run으로 platform에 상관없이 실행할 수 있다는 건 큰 장점이다.

# IDE
visual studio가 강력한 도구인것은 분명한데
rider가 좀 더 편한것 같다. ㅋㅋ


# Spring boot(java)와 비교한다면...

각 언어별로 장점들은 서로 모방해서 닮아가려는 측면이 있으니,
생태계 측면에서 본다면 비슷한것 같다. maven repository vs nuget?

다만 DI는 spring이 좀 더 편한 것 같다.

asp dotnet에서는 직접 instance를 만들어서 등록해줘야 하니까.
대신에 singleton, transient, scope등 생명주기를 좀 더 세밀하게 제어할 수 있는 장점은 있다.

2019년 4월 8일 월요일

ReactNative 선택시 주의할 점

ReactNative를 도입을 검토중이라면 반드시 아래 사항을 점검해야 한다.

1. iOS 개발자가 있는가?

iOS 모듈을 빌드할 때 반드시 여러가지 문제가 생긴다. 이걸 해결하려면 xcode 기반 iOS 프로젝트를 개발해본 경험이 있어야 한다.


2. android 개발자가 있는가?

androis 모듈을 빌드할 때  반드시 여러가지 문제가 생긴다. 이걸 해결하려면 gradle 빌드시에 일어나는 문제를 해결해본 경험이 있어야 한다.


1, 2에서 결국 iOS, android 경험이 필요해진다.

개발 과정 중에 일어나는 여러 가지 이슈를 해결하는 것이라면 보람이라도 있다.
적어도 issue들은 처리될 것이 아닌가?

그러나 개발환경에 관련된 문제가 지속적으로 일어나면

후...
진짜
싫다

2018년 6월 15일 금요일

I AM GROOT! I AM GROOT! I AM GROOT!

I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!
I AM GROOT! I AM GROOT! I AM GROOT!

2018년 5월 24일 목요일

요즘 느끼는 것들

일보다
출퇴근이 힘들다.

신기술 익히는 것 보다
수학적 논리 세우고 검증하는게 어렵다.

후우.

2018년 4월 24일 화요일

AWS summit 2018 참석 후기

4월 18, 19일 양일간 aws summit에 다녀왔다.


후기 끗

첫번째날은 주로 AWS 서비스 전반에 대해,
두번째날은 AI, ML쪽 내용이었다.

여튼 이제는 AWS를 사용하지 않는 기업을 찾는게 빠르지 않을까 싶다.
그만큼 클라이언트들의 요구사항도 많아질 것이고, 그걸 대응해서 새로운 서비스를 분기해 내고 있었다.

첫째 날 강연 중에는 KMS와 kubernetes, 두번째 날은 ML 전반... 뭐 결론은 `SageMaker 쓰세요. 짱 편할껄요?`


DeepLens도 이건 사봐야 할거 같고


DeepLens는 아직 Pre-Order 중이긴 하다.

PS. AWS 서비스들은 비싼데 싼거 같다.


EDIT:

부스에서 받은 것들중에 가장 애착이 가는 것은
AWS 머그컵이랑 GitHub 옥토캣 캐릭터 스티커,  mongodb 나뭇잎 스티커였다.
-.-

불이 안들어와 ㅠㅠ...



2018년 4월 16일 월요일

SpringBoot 1.5.x -> 2.0 migration check point

# datasource

*  connection pool이 hikari cp로 바뀌어서 application.yml의 구조를 변경해야 한다.
* validation-query를 지워도 connection lost가 되지 않는거 같다.
@ConfigurationProperties prefix역시 변경
* `DataSourceBuiler`의 package가 바뀐다.

# JPARepository

* `findById`의 리턴값이 `Optional` 바뀐다. 이건 좋네

그외 JDK 8환경에서는 그렇게 차이가 없는거 같다.

2018년 4월 13일 금요일

이 놈의 버그는...


분명히 테스트 다 했다고 생각했는데
확인한거 같은데?



심사에 올리면 발견될까

2018년 4월 7일 토요일

나는 어떤 개발자인가? 어떤 개발자가 될 것인가?


예전에 이런 이야기를 들은적이 있다.

"개발을 잘하고 싶어요, 돈을 잘 벌고 싶어요?"

2개가 같은 이야기가 아닌가?

당시에는 그렇게 생각했다.
개발을 잘하면 몸값이 높아지고(?) 연봉이 높아지면 돈 잘벌게 되는게 아닌가?

그러나 당시 어떤 기술을 쓰냐에 좀 더 관심이 있었던 나는 그 이상의 생각은 하지 못했다.

이는 결국,

요는 교체 가능한 기술인력이 되고 싶은가?
교체 불가능한 부가가치를 만들어 낼 수 있는가?

에 대한 문제였다.


나는 어떤 길로 걸어갈 것인가.

2018년 2월 20일 화요일

react native로 진행하던 프로젝트를 엎으면서


몇달 열심히 파던 react native 프로젝트를 엎었다.

react native가 적당한 UI에 적당히 API 호출하는 앱이면 참 괜찮을거 같다.
그런데 하드웨어를 접근해야 하는 문제면 좀 복잡해지더라.

ruby 같은 언어가 그랬듯, 만들어진 범위내에서는 참 깔끔하고 생산성이 높은데
그 이상의 `특별한` 요구사항이 있을 때

일단은 react native 코드에서 문제를 한번 해결해야 하고
android에서 한번 해결해야 하고
ios에서 한번 해결해야 한다 -_-;

이게 정말 피곤했다.
갑자기 빌드 문제에 막혀 일주일 정도 날렸을 때는 정말 ㅋㅋㅋ

결국 왜 갑자기 그 브랜치가 망했는지 이유조차 모르겠다 ㅋㅋ

ES5, ES6같은건 문제 축에서도 속하지 않는다 ㅋㅋ

node_modules를 날렸다가 다시 설치한게 몇번이며,
react-native eject를 몇번 시도했던가.

xcode에도 익숙해야 편하고
android에도 익숙해야 편하고
javascript에도 익숙해야 편하다?