#---------------------------------------------------------------------
# Uncomment this option if you want to customize path to IDE config folder. Make sure you're using forward slashes.
#---------------------------------------------------------------------
# idea.config.path=${user.home}/.AndroidStudio/config
idea.config.path=d:/.AndroidStudio3.5/config
#---------------------------------------------------------------------
# Uncomment this option if you want to customize path to IDE system folder. Make sure you're using forward slashes.
#---------------------------------------------------------------------
# idea.system.path=${user.home}/.AndroidStudio/system
idea.system.path=d:/.AndroidStudio3.5/system
idea.config.path=d:/.AndroidStudio3.5/config
idea.system.path=d:/.AndroidStudio3.5/system
위 2 라인이 제가 추가한 부분입니다.
원래는 user.home으로 잡혀 있던 경로들입니다. (주석# 으로 처리되어 있으면 기본으로 먹힙니다.)
c:\Users\한글유저명\.AndroidStudio3.5\
위 경로가 기본으로 설정되었던 경로이고 하위에config와system폴더가 자리잡고 있지요.
이제 두 폴더를idea.properties에 설정한 경로로 복사하면 됩니다.
그리고 Android Studio를 재실행하면 끝!! 입니다~
다만 Android Studio 업데이트시는idea.properties가 새로 설치되는 것으로 보이네요.
!!! Android 개발에 있어 많고 많은 빌드 에러 중 Windows 환경에서 종종 발생하는 에러에 대한 내용입니다 !!!!
Android Studio에서 Test Coverage를 돌릴 경우 발생하는 에러에 대해서 얘기해보려 합니다.
먼저 작성한 코드의 테스트 코드를 작성 후Run으로 동작이 잘 됨을 확인한 상태였습니다.
그 후Run ... with Coverage동작시 아래와 같은 에러가 발생하더군요.
java.lang.reflect.InvocationTargetException
FATAL ERROR in native method: processing of -javaagent failed
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:401)
Developer Edition, Enterprise Edition and Data Center Edition are priced per instance per year and based on your lines of code. You pay per instance for a maximum number of lines of code to be analyzed.
Determine your max number of LOCs on your edition of choice and see what it will cost you.
Can I get an evaluation license?
It is possible to get a free, 14 day evaluation license of any commercial edition by filling in the form you see once you select your edition.
마침 소나큐브 Docker Image도 Developer Edition을 지원을 하고는 있네요.
> docker run -d --name sonarqube_dev -p 9001:9000 sonarqube:developer-beta
Community Edition과 동시에 돌려보려 포트 설정을 요리조리 바꿔봤지만... 워낙 Docker 및 서버 문외한이라 결국 실패하였고.. 필요시마다 하나씩만 돌려보기로 합니다;;
Docker로 설치한 소나큐브 Developer Edition도 서버가 잘 돌아감을 확인하고 역시나 Andorid 소스 환경에서 자연스럽게 gradlew sonarqube를 쳐보았습니다.
!!! Android 개발에 있어 많고 많은 빌드 에러 중 Windows 환경에서 종종 발생하는 에러에 대한 내용입니다 !!!!
개인적으로 Android 개발에 있어서 Android Studio에서 Build나 Run 하는 경우가 많았는데요.
주로 툴의 UI 버튼등을 단순히 눌러서 해왔죠.
하지만 Terminal 에서 Build 가 필요할 때도 있지요.
기껏 Terminal 에서 Build 하는 명령어 등을 검색 후 실행했을때 에러가 뜬다면 참 번거럽겠죠.
그 수많은 에러 중 아래의 에러 문구시에 대한 해결책입니다.
C:\Users\?????\.gradle\caches\transforms-1\files-1.1\appcompat-v7-28.0.0.aar\50aa894a55f6ff1ab5e7586893bfabff\res\layout\abc_dialog_title_material.xml: error: file not found.
C:\Users\?????\.gradle\caches\transforms-1\files-1.1\appcompat-v7-28.0.0.aar\50aa894a55f6ff1ab5e7586893bfabff\res\drawable\abc_spinner_textfield_background_material.xml: error: file not found.
> Task :mobile:mergeDebugResources
Error: java.util.concurrent.ExecutionException: com.android.builder.internal.aapt.v2.Aapt2Exception: AAPT2 error: check logs for details
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':mobile:mergeDebugResources'.
> Error: java.util.concurrent.ExecutionException: com.android.builder.internal.aapt.v2.Aapt2Exception: AAPT2 error: check logs for details
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 18s
14 actionable tasks: 6 executed, 8 up-to-date
D:\HelloWorld>
어디가 문제일까요?
그냥 느낌적인 느낌으로 눈에 들어오는 부분이 있을 겁니다?????
C:\Users\?????\.gradle\caches\transforms-1\files-1.1\appcompat-v7-28.0.0.aar\50aa894a55f6ff1ab5e7586893bfabff\res\layout\abc_dialog_title_material.xml: error: file not found.
초청 특강 Recommendation Systems : Concepts, Techniques, and Research Results
키워드 : 추천 시스템, 머신러닝
소개 : 최근 온라인 비즈니스에서 크게 각광을 받고 있는 추천 시스템 기술에 대해서 다룹니다. 먼저, 추천 시스템의 기본 개념, 최신 기술, 응용에 대해서 설명하고, 머신 러닝 기술을 이용하여 추천 시스템을 어떻게 실현하는가에 대해서 설명합니다. 또한, 최근 제안된 무관심 아이템이라는 새로운 개념을 제시하고, 이 개념을 통하여 기존 추천 시스템의 정확도가 어떻게 개선 되는가에 대해서 다양한 관점에서 논의합니다. 또한, 추천 시스템에서 다루는 그래프 데이터를 효과적으로 저장하는 새로운 그래프 엔진 RealGraph를 소개하고, 이를 통하여 추천 시스템의 성능을 크게 개선시킬 수 있음을 설명합니다.
추천 시스템은 예전 데이터가 많은 업체만 하던 것을 작은 업체들도 시도하고 있음.
추천 기술은 몇가지 기반 기술이 있음
Content-based filtering은 내 데이터만 봄
Trust-based 는 트러스트라는 관계 데이터가 필요함. 주변인 추천 같은?
Collaborative filtering (CF)는 나와 취향이 비슷한 이웃을 찾고 내가 모르는 아이템을 얼마나 좋아하는지 예측함. Rating Matrix 사용
1단계 취향유사도 계산은 Pearson Correlation Coefficient based Collaborative Filtering(PCC) 사용
2단계 내가 얼마나 좋아할지는 Heuristic based methods 사용
일반 평균, 유사도에 따른 가중치를 주거나 각 이웃의 평균치도 고려함
위 단계가 Matrix Factorization, Tensor Factorization 이며 점차 딥러닝으로 넘어가는 중
Social network analysis, Deep Learning 등
정확도를 높이기 위해 Unrating 개념 추가
Unrating은 존재를 모르거나 알고도 관심이 없는 경우도 있음(부정적인)
기존 선호도로 쓰이던 부분을 사전/사후 선호도를 나눔.
Uninteresting item 찾는게 과제임.
기존 사용자가 좋아하는 것만 추천했지만 한양대에서는 싫어하는 것까지 고려하려 함.
작은 Interesting 그룹과 큰 Uninteresting 그룹이 필요함
깃'깔나는 Git 워크플로 알아보기
키워드 : 개발 방법론, 생산성
소개 : 주요 Git 워크 플로우의 이해 각자 상황에 적합한 Git 워크플로를 찾는 팁
Git flow
메인브랜치 : master, develop (master에 버전 태그 추가)
서포팅브랜치 : feature, release, hotfix (필요시 생성/제거)
hotfix는 마스터에서 브랜치 생성
Github flow
master 브랜치는 항상 배포 가능한 상태 유지
topic 브랜치 (Git flow의 feature) 는 기능 설명이 명확하게 작명하고 merge시 pull request 사용
topic 브랜치는 CI 빌드 통과해야 함.
배포는 merge 순간 bot을 통해 진행함.
매우 빈번하게 배포함.
Gitlab flow
Git flow는 너무 복잡, Github flow는 너무 간단하게 생각되어 나옴.
Gitlab flow - 지속적인 배포가 어려울때
master에서 production 브랜치로 머지 후 배포
Gitlab flow - 환경별 배포시
Gitlab flow - 릴리즈 소프트웨어시
Commit과 Push는 자주 할것
Merge Request or Pull Request 는 완료 전이라도 논의 및 피드백 받을 목적으로도 사용.
merge 전엔 테스트 필요
NHN Edu사례
단기간,
장기간 배포 일정(코드네임 부여)
rebase 로 정리함.
QA 수정사항은 각 프로잭트 브랜치에서 추가함.
Release 브랜치 사용안함.
배포 후 각 프로젝트 브랜치에 rebase
각 프로젝트 rebase시 conflict이 발생할 수 있고, 그 경우가 복잡할 경우 프로젝트 브랜치 재생성하고 cherry-pick 함.
hotfix 는 Pull Request 로 코드 리뷰와 테스트만 하고 배포는 직접 진행함.
업무프로세스
Pull Request 시 사내 메신저 연동
Pull Request 통과 조건을 부여하여 통과시만 merge 가능(github 설정)
- 코드 리뷰 승인시 조건
- 테스트 옵션 – Unit Test와 Sonarqube
(Sonarqube 는 테스트 결과와 별개로 패스되므로 참고만 함.)
- develop에 최신 master 적용여부 체크
Pull Request 생성시 Jenkins 빌드 및 Unit Test연동
Sonarqube 결과도 댓글로 달림
Github Pull Request + Jenkins + Sonarqube
실용적인 프런트엔드 테스트 전략
키워드 : 프런트엔드, 테스트, 아키텍처
소개 : 프런트엔드 코드는 사용자 환경과 밀접하게 연결되어 있고 복잡한 시각적 요소를 다루기 때문에 테스트를 자동화하기가 어렵습니다. 본 세션에서는 수년간 다양한 방식으로 테스트를 작성해 온 경험을 공유하며, 최신 테스트 도구를 사용해서 실용적으로 프런트엔드 코드를 테스트하는 방법을 설명합니다.
테스트는 왜 하는가?
대부분 개발자가 테스트 코드 작성 후 자동화함
그 이유는 Confidence 때문임.
백엔드의 경우 테스트는 https 요청에 대한 응답이 대부분.
프런트엔드는 마우스 키보드 등 입력과 시각적 정보 출력하고 코드로 확인하기 어려움.
입력 : DOM Event, Routing IO
출력 : Html, css 비교 등
결과 확인
\1. Html 비교
\2. 스냅샷 테스트 : 에전 테스트 결과와 파일 비교. Jest 사용
하지만 html 확인만으로는 테스트 결과에 신뢰를 줄 수 없음
구현상세테스트 vs 동작테스트로 테스트 성향을 구분.
위의 결과 확인은 구현상세테스트 성향임.
동작테스트로시각적 회귀 테스트진행함. (회귀란 기존 버전과 비교하기 떄문)
하지만 픽셀 단위 비교도 브라우저 렌더링 등에 영향을 받음
그리고 커맨드 라인에서 테스트 결과 확인이 어려움.
테스트 실행 단위별 이미지 파일 히스토리 관리 필요.
결정적으로 시각적 테스트 전문 도구(유료)
Applitools, Percy, Chromatic
시각적 테스트는 속도 문제와 테스트의 장점 중 하나인 문서화 기능을 처리하기 어려움
이로 인해 TDD 진행도 어려움.
그리고 단일 테스트에 영향 주는 요소 많음.
시각적 테스트 vs 기능적 테스트
기능 테스트시 시각적 요소 의존성 제거해야 함
JQuery의 Selector들 같은 경우가 이에 속하며, 이를 제거하기 위해 data 속성을 이용해 test-id 등을 부여할 수 있음.
build.gradle 이나 gradle-wrapper.properties 파일 내 버전을 한쪽에 맞춰서 수정
4. 최소 gradle 버전에 적합한데도 발생한 경우
예전에 직접 gradle 쪽 초기화를 하고 싶어 직접 gradle 경로에서 파일들을 삭제 하던 중 폴더만 남고 삭제가 안된 경우가 있었음. 그로 인해 gradle 있지만 동작 안하는 것으로 감지한 듯함.직접 gradle zip 파일을 받아서 해당 경로에 풀어 주고 다시 gradle sync