2019년 Python 개발자 설문조사에서 확인된 5가지 흥미로운 사실

지난 5월, Python Software Foundation(PSF)에서 2019년 Python 개발자 설문조사의 결과를 발표했습니다. 이 조사는 2019년 가을에 진행되었으며 150여 개국의 24,000명 Python 개발자로부터 응답을 수집했습니다. Python 개발자 설문조사는 PSF에서 승인한 공식 문서로서, Python 세계의 현 상황을 파악하기 위한 참고 자료로 사용됩니다.

서론은 여기까지로 하고, 지금부터 설문조사에서 밝혀진 몇가지 흥미로운 사실을 살펴보겠습니다!

1. JavaScript는 여전히 가장 인기 있는 ‘제2의 언어’…

JavaScript는 Python 개발자 사이에서 여전히 인기 있는 ‘제2의 언어’라는 사실에는 변함이 없지만 이 수치는 2018년 대비 8% 감소하였습니다. ‘Python과 함께 사용되는 다른 언어의 사용 현황’은 아래에서 결과를 확인할 수 있습니다.

Python과 함께 사용되는 다른 언어의 사용 현황

2. Python은 정말 유연한 언어…

‘Python을 어떤 용도로 사용하시나요?’라는 질문에서 2년 연속으로 응답자의 59%가 &#8216데이터 분석’을 선택했습니다. JavaScript를 선택한 사람들이 감소한 데 이어(위의 1번 결과 참고) ‘웹 개발을 옵션으로 선택한 응답자의 수도 2018년 대비 4% 줄었습니다.

이 일련의 질문에서 밝혀진 흥미로운 사실은 사용자가 Python을 사용하는 목적으로 평균 3.9가지를 다양하게 선택했으며 이는 이 언어의 주요 특징 중 하나인 유연성을 입증한다는 것입니다. 아래에는 ‘Python을 어떤 용도로 사용하시나요?’라는 질문에 대한 분포 비율이 나와 있습니다.

Python을 어떤 용도로 사용하시나요

3. Python 2는 거의 사장되었지만 여전히 생존…

Python 2는 더 이상 공식적으로 유지관리되지 않으며 예상대로 응답자의 대다수는 Python 3을 사용하고 있습니다. 재미 있는 사실은 Python 2가 2018년 대비 6% 떨어지긴 했지만 여전히 응답자의 10%가 사용하며 0% 보다는 여전히 멀다는 것입니다.

Python 버전

AWS는 Python 개발자 사이에서 55%의 상대적 시장 점유율을 유지했지만 Google과 Microsoft는 시장 점유율을 각각 3%와 4% 각각 증가시켜(2018년 대비) 간격을 좁혔습니다.

상위 클라우드 플랫폼

클라우드에서 코드를 실행하는 방식은 2018년과 달라졌습니다. 가장 인기 있는 선택지는 컨테이너로, 가상 머신을 선택한 수를 넘어섰습니다. 아래는 ‘프로덕션 환경의 클라우드에서 코드를 어떻게 실행하시나요?’라는 질문에 대한 분포 비율입니다.

클라우드에서 코드를 어떻게 실행하시나요?

PyCharm은 4년 연속으로 Python 개발자가 개발 컨텍스트(웹 개발 또는 데이터 과학)와 관계없이 사용되는 주요 IDE입니다. Python을 기본 언어로 선택한 사용자들이 사용하는 Python IDE의 분포 비율은 아래에서 확인하세요.

에디터 및 IDE

 

 

Python 에코시스템은 매년 진화하고 변화합니다. JetBrains는 PSF와 협력하여 우리가 정말 좋아하는 이 놀라운 프로그래밍 언어를 폭넓게 이해하는 일이 언제나 즐겁습니다.

2019년 공식 Python 개발자 설문조사 페이지에서 전체 결과를 확인하세요. 올해는 익명 데이터를 다운로드할 수 있으므로 Python 및 데이터 과학 기술을 사용하여 데이터를 직접 탐색해 보세요!

직접 데이터를 확인하기로 하셨다면, 여러분이 추가적으로 발견한 사실도 알려주세요!

이 글은 Roberto Pesce가 작성한5 takeaways from the Python Developer Survey 2019를 번역한 글입니다.

Posted in PyCharm | Tagged , , , , | Leave a comment

YouTrack에 이제 지식 베이스가 포함됩니다!

이 글은 한국어, 영어, 프랑스어, 러시아어, 중국어, 일본어, 브라질 포르투갈어, 스페인어로 읽으실 수 있습니다.

release2020_2_blog.001

지식 베이스가 기본 제공되는 YouTrack 2020.2가 출시되었다는 기쁜 소식을 알려 드립니다! 이제 공개 지식 베이스를 구축하고 작업 및 프로젝트와 함께 YouTrack 내에 내부 문서를 보관할 수 있습니다. YouTrack을 사용하면 팀의 집단 지식을 한 곳에 모을 수 있습니다.

프로젝트 관리자를 위한 다른 개선 사항으로는 필드 유형을 변환하고 프로젝트의 기본 가시성 그룹을 설정하는 기능이 있습니다.

팀 간 협업을 개선하기 위해 태그, 저장된 검색, 애자일 보드, 보고서를 공유 할 수 있는 새로운 옵션이 추가되었습니다.

이슈 작업 시 향상된 사용자 경험을 위해 개인 작업 영역 및 이슈 목록 보기를 구성하는 새로운 기능과 “Clone issue as draft”(이슈를 초안으로서 복제) 액션이 추가되었습니다.

애자일 보드를 갓 시작하는 모든 사용자를 위해 프로세스를 단순화하고 보드를 만드는 데 필요한 단계를 최소화했습니다.

자세히 알고 싶으신가요? 그렇다면 이 글을 계속 읽어주세요. YouTrack 2020.2에서 준비된 모든 멋진 기능들을 안내해 드리겠습니다.

Continue reading

Posted in YouTrack | Tagged , , , | Leave a comment

MPS 2020.1이 출시되었습니다!

기쁜 마음으로 MPS 2020.1 버전 출시를 알립니다. 이번 릴리스는 여러 하위 시스템에서 가져온 다양한 기능 및 개선 사항을 제공합니다. 아래 글을 통해 상세한 내용을 확인해 보세요.


MPS 2020.1 다운로드

 

목록 위치에 따라 다른 구분 기호 사용

기수 (0,n) 또는 (1,n)이 포함된 노드를 편집할 때 구분 기호 쿼리 함수를 구현하여 값 사이에 사용자 지정 구분 기호를 제공할 수 있습니다. 이 기능은 쿼리 함수(prevNode 및 nextNode)에 더 많은 인수를 전달해 그 성능을 확장하여 값의 각 페어에 사용자 지정 구분 기호를 제공할 수 있게 해줍니다. 다음 스크린샷에서 “and” 및 “,”는 구분 기호입니다. 데모 시청하기.

구분 기호

Light patterns

패턴 언어를 사용하면 구조 패턴을 정의하고 노드를 해당 패턴에 일치시킬 수 있습니다. 패턴 언어는 패턴이 허용 대상 노드와 유사하게 보이도록 일반 개념 에디터를 사용합니다. 그러나 개념 구조와 정확히 일치하지 않는 일부 복잡한 에디터의 경우 필요한 구조를 문자 그대로 설명하는 light patterns(패턴 빌더)를 사용하는 것이 더 편할 수 있습니다. 자세한 정보를 문서에서 확인하시거나 데모를 시청하세요.

lightPatterns

기존 텍스트 위에 입력

Type over existing text(기존 텍스트 위에 입력)은 프로젝션 에디터를 텍스트 에디터와 비슷하게 사용할 수 있도록 하는 새로운 기능입니다. 사용자가 텍스트 셀에 입력할 때 방금 입력한 문자가 커서 위치에 이미 있으면 기존 문자를 덮어쓰는 것처럼 커서가 움직입니다. 이 기능은 키 입력을 정상적으로 처리할 수 없어서 무시하거나(예: 상수 셀에서) 셀 내용을 무효화할 경우에만 트리거됩니다. 데모 시청하기.

이 기능은 기본적으로 켜져 있으며 Settings(설정) / Editor(에디터) / General(일반) 탭에서 끌 수 있습니다.

툴팁

mbeddr 플랫폼의 툴팁 에디터 확장 프로그램이 MPS에 추가되었습니다. 또한 mbeddr 언어에 마이그레이션도 제공됩니다. 데모 시청하기.

툴팁1586943437422

Java 언어에서 영감을 얻은 BaseLanguage 개선 사항

이제 BaseLanguage에 try-with-resources 문, 여러 예외 포착, 지역 변수 유형 추론, default 및 private 인터페이스 메소드가 포함됩니다. 특정 Java 언어 수준이 필요한 빌드 프로세스와의 호환성을 제공하려면, 각 솔루션을 구성하여 해당 수준과 호환되지 않는 언어 기능을 사용 금지시키면 됩니다.

j.m.baseLanguage.varVariable이 필요한 지역 변수 유형 추론 기능을 제외하면, 이러한 기능에는 추가적 언어 가져오기가 필요하지 않습니다. 마이그레이션 가이드 또는 데모를 시청하세요.

불필요한 언어 확장자 제거

기존에는 언어 에디터가 다른 언어의 개념에 대한 에디터 구성 요소를 제공할 때 MPS에서 ‘extends’ 종속 요소를 필요로 했습니다. 하지만 이러한 종속 요소에 항상 언어 간 상관관계가 반영되는 것은 아니었으며 종종 광범위한 언어 계층 구조 처리 작업이 요구되곤 했습니다. 가령, j.m.lang.core의 INamedConcept을 예시로 생각해 보세요. 모든 MPS 언어는 j.m.lang.core를 확장합니다. 그렇기에 INamedConcept 에디터 개념이 사용될 경우엔 사용 가능한 모든 언어의 에디터 특징이 고려되는 것입니다.

2020.1 버전의 경우 생성기가 다른 언어용 에디터 확장 프로그램을 탐지하여 종속 요소를 명시적으로 표시하는 각 코드를 생성합니다. 그러므로 언어 설계자는 언어 사이의 특정한 종속 요소를 따로 신경 쓸 필요가 없습니다. 또한 편집기 확장 기능 활성화 시 언어 모듈 간의 ‘extends’ 종속 요소를 사용하지 않아도 됩니다.

Java 스텁 모델 내 Javadoc 주석

Java 스텁 모델을 사용하는 MPS 세계에선 Java 라이브러리가 활용됩니다. 이러한 모델은 .class 정보에서 빌드되므로 javadocs와 같은 문서를 포함하지 않습니다.

2020.1 버전의 경우 새로운 메커니즘을 통해 라이브러리 소스와 라이브러리 .jar 등을 보유한 zip 파일을 지정합니다. 또한 MPS는 소스에서 javadoc을 추출하여 클래스 파일에서 추출된 정보와 함께 표시합니다. 이 기능은 MPS 내부에서 Java 라이브러리를 사용하고 라이브러리 javadoc에 액세스할 때 편리합니다. 외부 위치로 전환하고 검색을 수행하고 읽는것 대신, MPS 내부에서 바로 관련 코드 및 문서를 간편하게 탐색할 수 있습니다. 또한 자체 API의 필수적 부분이 Java 스텁으로 제공되므로 MPS 자체에도 중요한 기능입니다. 데모 시청하기.

손상된 에디터의 오류 탐지

언어의 에디터 측 내에 있는 코드에서 예외를 던지면 해당 언어로 작성된 모델의 해당 셀에 대한 기본 에디터가 표시됩니다. 2020.1부터는 이러한 종류의 손상된 셀이 에디터에서 열리면 Messages(메시지) 도구 창에 오류가 표시됩니다. 이 오류에서 스택 추적을 얻으면 문제 셀로 이동할 수 있습니다. 데모 시청하기.

BaseLanguage 내 여러 줄 주석

SingleLineComment의 기능이 약간 향상되고 새로운 MultiLineComment 개념이 BaseLanguage에 도입되어 Java와 같은 방식으로 /* … */ 심볼로 구분된 주석이 지원됩니다.마이그레이션 가이드 또는 데모를 시청하세요.

변환/교체 메뉴: 이름 지정된 메뉴와 기본 메뉴 병합

이 개선을 통해 이름 지정된 에디터 메뉴(SubstituteMenu_Named) 및 기본 에디터 메뉴(SubstituteMenu_Default)에 대한 사용자 지정 개념을 제거하여 Transformation(변환) 및 Substitution(교체) 메뉴를 간소화했습니다. 두 개념은 해당 개념의 상위 개념(SubstituteMenu)으로 병합되었으며 메뉴 유형은 메뉴 에디터에서 선택됩니다. Transformation 메뉴에도 동일한 리팩토링이 적용되었습니다. 마이그레이션 가이드 또는 데모를 시청하세요.

 

기타 개선 사항

JetBrains Mono를 기본 글꼴로 사용

MPS는 이제 새로운 JetBrains Mono 글꼴(Preferences(환경 설정)/Settings(설정) | Editor(에디터) | Font(글꼴))을 기본 글꼴로 사용합니다. 이 개발자 친화적인 새로운 글꼴에 대한 모든 세부 정보는 웹사이트에서 확인하세요.

MPS에 마켓플레이스 지원

이제 JetBrains 플러그인 마켓플레이스를 MPS에서도 이용할 수 있습니다. 이에 따라 플러그인을 상용화할 수도 있어 다양한 새로운 기회가 열립니다.

모달이 아닌 커밋 인터페이스

보다 간결한 커밋 작업 흐름을 위해 커밋과 관련된 모든 작업을 처리하는 새로운 커밋 도구 창을 개발했습니다. 이 창에서는 수정된 파일과 Diff 목록을 처리할 방법이 다양하게 제공되어, 변경 준비 완료 시 커밋에 변경 내용을 추가하고 커밋 메시지를 반복적으로 구성하며 스테이징된 변경 내용을 어떤 커밋에 포함할지 선택할 수 있습니다.

기본적으로 활성화된 기능이 아니므로 한 번 사용해 보고 싶으신 경우 Preferences(환경 설정)/Settings(설정) | Version Control(버전 관리) | Commit(커밋)에서 “Use non-modal commit interface”(모달이 아닌 커밋 인터페이스 사용)를 선택하세요.

Zen 모드

이 새로운 모드에는 Full Screen(전체 화면) 모드와 Distraction Free(집중력 분산 방지) 모드가 결합되어 있어 사용자가 코드에 집중할 수 있습니다. Zen 모드를 사용하려면 View(뷰) | Appearance(꾸미기) | Enter Zen Mode(Zen 모드 시작)으로 이동하세요.

IDE에서 Git 설치

수동으로 Git을 사전 설치할 필요가 없습니다. 기존 Git 저장소를 복제하면 IDE가 컴퓨터에서 Git 실행 파일을 찾고, 찾을 수 없는 경우 해당 파일을 다운로드하여 설치하도록 제안합니다.

Config 파일 경로

MPS 2020.1에서는 Config 파일 경로가 변경되었습니다. 자세히 보기.

 

마이그레이션 가이드도 잊지 말고 확인하세요. 커뮤니티를 통해 보고된 버그의 방대한 목록도 수정되었습니다. 새 버그를 발견하셨거나 추가되면 좋을 유용한 기능을 제안하시려면 해당 내용을 이슈 트래커에 추가해 주세요.

건강 유의하시고 좋은 하루 보내시길 바랍니다!

Your JetBrains MPS team

The Drive to Develop

blog_footer_bw@2x

이 게시물은 Oscar Rodriguez가 작성한MPS 2020.1 has been released!를 번역한 글입니다.

Posted in MPS | Tagged , | Leave a comment

JetBrains가 사랑하는 Java의 25가지 특징

JetBrains는 모든 프로그래밍 언어와 모든 개발자를 사랑합니다. 이번 달 2020년 5월에는 Java가 25주년을 맞습니다! 그래서 특별히 Java에 초점을 맞춰 JetBrains가 사랑하는 Java 및 JVM의 25가지 특징을 살펴보려 합니다.

DSGN-9341_25ThingsAboutJava

이전 버전과의 호환성

Java는 25년 전의 코드를 최신 버전의 Java에서도 실행할 수 있다는 점에서 거의 독보적입니다. 언어 개발자는 이전 버전과의 호환성을 매우 중요하게 생각하기에 수많은 조직에서 몇년이 지난 코드라도 JVM에서 실행된다는 점을 고려해 Java를 기본 개발 플랫폼으로 적극 수용했습니다.

성숙도

오랜 시간이 지난 만큼 이점도 많습니다. 지난 25년 동안 개발자들은 다양한 업계 및 비즈니스 유형과 다양한 플랫폼에서 Java로 애플리케이션을 작성해왔습니다. 또한, 25년 동안 개발자들은 학교, 대학, 부트캠프, 직장에서 Java를 배워 왔습니다. 이를 통해 시간의 흐름에 따라 경험에서 지식을 축적하고 계속 성장하는 거대한 에코시스템이 형성되었습니다. Java 및 Java로 해결 가능한 문제에 관해서는 공급업체와 비영리단체, 개인들이 자세히 문서화하고 지원하고 있습니다. 무엇보다 우리 같은 개발자에게 매우 중요한 이점은 Java가 성숙하고 폭넓게 채택되면서 Java로 코딩하려는 개발자에게 수많은 일거리가 생긴다는 것입니다!

지속적 개선

이전 버전과의 호환성 및 성숙도와 대비되는 특징은 플랫폼과 언어의 발전입니다. Java는 2017년(Java 9)부터 6개월마다 새로운 버전이 출시되어 꾸준히 변경되고 개선되어 왔습니다. 테스트 버전 기능을 결합하여 새로운 구문을 실험하고 개발자로부터 피드백을 받은 다음, Java 사용자들을 위한 실용화된 새로운 기능을 표준화합니다.

균형성

Java는 이전 버전과의 호환성과 미래 사이에서 까다로운 균형을 맞춰야 합니다. 이전 버전과의 호환성을 평가하고 6개월마다 출시하는 현재의 접근 방식은 3년마다 출시되는 장기적 지원과 결합되어 균형을 적절히 맞추고 있는 듯 보입니다. Java는 제거될 예정인 사용 중단 기능에 대한 경고를 제공하고 없어질 수 있는 항목의 대체 기능을 마련하여 발전합니다.

높은 안정성을 원하는 사람은 장기적 지원 릴리스를 계속 사용하면 됩니다. 업그레이드 시기가 되었을 때 위험을 줄이려면 6개월마다 출시되는 릴리스를 정기적으로 테스트할 수도 있습니다. 6개월마다 업그레이드하는 것이 좋은 사람은 릴리스가 나올 때마다 최신 Java 버전으로 업데이트하면 됩니다. 새로운 구문이 표준화되기 전에 사용해 보고 싶은 개발자는 테스트 버전 기능을 활성화할 수 있으며, 최대한 빨리 체험해 보고 싶은 개발자는 새 구문이 출시되기 전에 얼리 액세스 릴리스 버전을 사용해 볼 수 있습니다. 최신 Java 버전을 사용하는 팀은 실제로 모든 이점을 누릴 수 있습니다.

표준

표준은 언어 기능만큼 개발자의 흥미를 끌지는 않지만 Java, Java EE, Jakarta EE 및 개발자가 마주치게 되는 일반적인 사용 사례에 대한 표준이 있으면 개발자의 삶이 더 편해집니다. JDBC를 사용하여 데이터베이스와 통신하는 방법을 이해한다는 것은 데이터베이스 드라이버가 구현되는 방식에 신경 쓸 필요가 없으며 데이터베이스와 상호작용하는 방식이 항상 동일하다는 것을 의미합니다. JCP는 Java 표준을 파악하는 데 사용되는 프로세스 중 하나입니다.

Java 언어 사양은 Java 언어의 형태와 컴파일러의 작동 방식을 설명합니다. 여기에는 JVM 또는 하드웨어에 관계없이 애플리케이션의 작동 방식을 예측하는 데 도움이 되는 Java 메모리 모델이 포함되어 있습니다. Java 가상 머신 사양은 JVM에 관한 하위 수준 세부 정보를 설명합니다. 이러한 사양을 통해 서로 다른 제공업체에서 배포한 JDK가 다양한 플랫폼에서 실행되고 지정된 예측 가능한 방식으로 작동하도록 만들 수 있습니다. 그 결과 우리는…

작성은 한 번만, 실행은 어디서나

WORA는 Java의 기반이 된 원래 아이디어 중 하나로, 오늘날에는 너무나 당연시되어 이 개념이 얼마나 혁신적이었는지 깨닫지 못할 정도입니다. 2002년 제가 몸 담았던 매우 큰 조직에서는 이전 기술 스택에서 Java로 전환했습니다. 수많은 다른 하드웨어가 이미 있는 상황에서 애플리케이션용 특정 하드웨어를 구매하지 않고 새로운 Java 애플리케이션을 실행할 수 있다는 것이 모든 개발을 Java로 옮긴 주요 이유 중 하나였습니다. 클라우드의 시대이기도 한 오늘날 이 사례는 관련성이 별로 없어 보일 수 있지만 WORA의 작동이 항상 보이는 게 아니라고 해서 여전히 그 이점을 활용하지 않는 것은 아닙니다. 그리고 당연한 말이지만 IntelliJ IDEA(또는 NetBeans)를 사용하는 경우 데스크톱에서 WORA를 활용하게 됩니다.

성능

Java에 익숙하지 않은 사람들에게 놀라운 특징이지만 Java는 성능이 매우 높은 언어입니다. 25년 동안 성능이 개선되어온 성숙한 플랫폼으로서, 다양한 성능 프로파일을 가진 수많은 가비지 컬렉터가 있으며 JVM은 실제 프로덕션 사용 사례에서 대부분의 인간 개발자가 할 수 있는 것보다 훨씬 더 효과적으로 런타임 시 코드를 최적화합니다. 예를 들어 Java는 트랜잭션의 지연 시간이 짧아야 하고 성능이 예측 가능해야 하는 금융업계에서 널리 사용됩니다.

메모리 관리 및 가비지 컬렉션

자동 가비지 컬렉션은 25년이 지난 지금, 일반적으로 당연하게 여기게 된 또 다른 기능입니다. 사용자는 애플리케이션에서 메모리를 할당하는 방법이나 메모리 여유 공간을 확보하는 방법에 대해 고민할 필요가 없습니다. 각 JVM에는 하나 이상의 서로 다른 GC 알고리즘이 있으므로 애플리케이션의 내부 상태에 크게 신경 쓸 필요 없이 애플리케이션에서 잘 작동하는 알고리즘 선택하고 애플리케이션의 비즈니스 로직을 작성할 수 있습니다.

관찰 가능성 및 관리

애플리케이션이 실행되는 동안 진행 중인 작업을 확인하고 싶은 경우 사용할 수 있는 도구가 매우 많이 있습니다. 특히 Java Flight RecorderMission Control이 OpenJDK에 포함되어(Java 11 이후) 대부분의 도구가 무료입니다. JMX와 같은 도구를 사용하면 애플리케이션을 동적으로 관리할 수도 있습니다.

Java 가상 머신(JVM)

지금까지 언급한 수많은 기능은 JVM의 특징이지만, JVM은 Java 언어 자체는 별개의 것이라는 사실을 특히 명확히 하고 싶습니다. 이미 다루었던 기능 중 몇가지(WORA, 런타임 최적화, 성능, 제공업체 선택 등)를 포함하여 JVM이 사랑받는 이유는 다양하지만, 이러한 기능 대부분은 표준과 사양 덕에 구현된 것입니다. 또한 JVM이 Java 언어와 별개의 것이라는 사실도 중요합니다. 이는 다양한 언어를 이 플랫폼에 구축할 수 있고, 방금 언급된 JVM의 뛰어난 기능을 모두 활용하는 동시에 다양한 유형의 구문과 언어 기능을 제공할 수 있다는 뜻이기 때문입니다.

기타 JVM 언어

Java 6과 8 사이의 조용한 시대(Java 7에는 훌륭한 기능이 있지만, Java 개발자에게는 큰 릴리스처럼 느껴지지 않았습니다)에 Java가 살아남고 심지어 발전했던 이유 중 하나는 기타 JVM 언어 덕분입니다. 물론 JetBrains가 가장 좋아하는 언어는 Kotlin이지만, JVM은 Groovy, Scala, Clojure, JRuby와 같은 다른 인기 언어 및 기타 수많은 재구현 언어 또는 새로운 언어가 사용되는 플랫폼입니다. 대부분의 경우 이러한 언어와 기본 Java 간의 상호 운용성은 다양성을 수용하고 활용할 수 있도록 도와줍니다.

라이브러리/프레임워크

가장 매력적인 특징 중 하나는 수많은 라이브러리와 프레임워크를 선택할 수 있고 그중 다수가 오픈 소스이며 무료로 사용할 수 있다는 것입니다. 특히 SpringSpring Boot와 같은 인기 프레임워크를 사용하면 소규모 서비스에서 대규모의 복잡한 엔터프라이즈 애플리케이션에 이르기까지 모든 것을 쉽게 작성할 수 있습니다. 표준이 있으면 많은 경우 다른 컨텍스트에서 비슷한 항목을 사용할 때 라이브러리를 이해하고 사용하는 것이 어렵지 않습니다. Java가 성숙되었고 해당 커뮤니티가 오픈 소스를 조기에 채택한 만큼, 대개 표준 관련 문제에 대한 해결책이 마련되어 있으므로 처음부터 연구를 시작할 필요가 없습니다. 또한 이러한 해결책 중 대부분이 오랫동안 사용되어 왔기 때문에 충분히 테스트되고 이해하기 쉬우며 문서로 잘 정리되어 있습니다.

빌드 도구 및 종속 요소 관리

불쌍한 개발자(저요!)가 실행하려는 코드에 필요한 클래스가 일부 들어 있는 알 수 없는 JAR 파일을 인터넷에서 검색해야 했던 시절은 오래전에 끝났습니다. 특히 Maven과 Gradle을 사용하면 애플리케이션을 간편하게 빌드하고 배포할 수 있을 뿐만 아니라 필요한 모든 종속 요소를 포함하여 표준 방식으로 프로젝트를 쉽게 설정할 수 있습니다. 또한 새로운 프로젝트든 기존 프로젝트든 코딩을 쉽게 시작할 수 있습니다. Maven Central이나 Bintray와 같은 공용 저장소를 사용하면 라이브러리를 검색하고 게시할 수도 있습니다.

JUnit 및 자동화된 테스트

JUnit1997년에 제작되어 Java만큼 오래되었습니다! Java 세계에서 가장 일반적인 자동화된 테스트 프레임워크로서, IntelliJ IDEA에서는 새로운 Java 프로젝트에는 테스트 프레임워크가 필요하다는 고려 하에 JUnit 및 TestNG를 모두 함께 제공합니다. 모든 언어에 대한 최신 테스트 프레임워크 역시 지금은 당연하게 여겨지는 JUnit의 아이디어를 기반으로 합니다. Java 커뮤니티의 자동화된 테스트 문화는 이 하나의 라이브러리 덕분에 성장했습니다.

IDE

여기는 IntelliJ IDEA 블로그라는 사실을 절대 잊어서는 안 되겠죠! Java의 방대함 때문에 IDE가 필요하다고 생각하든, 실제로 Java가 정적 유형 때문에 IDE를 크게 활용할 수 있다고 생각하든 관계없이 Java 개발자가 IDE를 좋아한다는 것은 사실입니다(저희도 여러분을 좋아하고요!). 개발자가 IDE(IntelliJ IDEA, Eclipse 또는 NetBeans이든)를 효과적으로 사용하는 방법을 배우면 코드 완성, 코드 생성, 테스트 실행, 디버그, 탐색기타 수많은 기능을 이용해 생산성을 크게 향상할 수 있습니다. Java 개발자는 IDE가 제공하는 이점을 일반적으로 매우 좋아합니다.

Community

Java 커뮤니티는 거대하고 성숙되었으며 활기차고 친절한 커뮤니티입니다. 전 세계 여러 도시에 Java 사용자 그룹이 있으며 물리적 모임에 갈 수 없는 경우 참여할 수 있는 가상 Java 사용자 그룹도 있습니다. Java Champion은 Java 및 JVM 개발자에게 유용하거나 흥미로운 정보를 공유하는 것으로 알려진 유명한 Java 세계의 기술 리더입니다. Java에는 JDK 자체를 포함하여 OpenJDK를 통한 거대한 오픈 소스 커뮤니티가 있습니다. Java 커뮤니티는 학습, 교육, 지속적인 향상에 가치를 두고 표준 및 ‘모범 사례’에 관심을 가지며 실제 환경에서 이를 적용하는 방법에 관해 실용적으로 접근합니다.

개발팀

물론 커뮤니티도 사람들로 구성되어 있지만 개발자에게 자신이 가장 중요하게 생각하는 Java 관련 요소에 관해 질문하면 대부분이 자신에게 영향을 미친 Java 세계의 개인을 꼽습니다. 이러한 개인들에는 동료 및 교사부터 Brian Goetz, Angie Jones, Georges Saab, Mala Gupta, Venkat Subramaniam과 같은 사람들까지 다양하게 있습니다. 어떤 이들은 를 언급하기도 합니다. 개인적으로 저는 대학에서 Java를 배운 후 일자리가 많았기 때문에 Java 세계에 들어왔지만, 여기에 계속 머문 이유는 이곳의 사람들을 사랑하고 이들로부터 얻은 도움과 지원에 감사했기 때문입니다.

Javadoc 및 문서

Java는 Javadoc을 통해 API 문서를 언어의 핵심 부분으로 만듭니다. 세 가지 다른 유형의 주석(Javadoc, 블록 및 줄)은 개발자가 남긴 주석의 말의 종류가 무엇인지 명확하게 나타냅니다. Javadoc은 특히 메소드를 호출하거나 클래스 또는 패키지를 사용하는 다른 개발자에게 유용한 문서를 남기도록 개발자에게 권장합니다. 개발자가 라이브러리나 코드에 대한 자세한 튜토리얼 정보를 찾을 수 없는 경우에도, 보통은 올바른 방향을 지시해주는 Javadoc이 있습니다.

또한 Java 에코시스템은 일반적으로 개발자에게 양질의 문서를 기대하고 제공하는 것으로 보입니다. 향후 오픈 소스 프로젝트의 커미터가 되려는 이들은 Javadoc 주석 또는 기타 문서의 pull 요청을 제출하도록 권장받고 전 세계의 개발자들은 특정 문제에 관한 해결책을 구하기 위해 블로그나 StackOverflow에서 질문 및 답변합니다.

오픈 소스

Java 커뮤니티는 오픈 소스를 조기에 수용했을 뿐만 아니라 이제 JDK 자체도 OpenJDK를 통해 오픈 소스로 제공됩니다. 오픈 소스를 사용하면 개인뿐만 아니라 여러 공급업체도 쉽게 참여하고 협업할 수 있습니다. Java 자체의 코드를 볼 수 있다는 것도 매력적입니다. 오픈 소스 코드는 복잡한 문제에 관해 이미 열심히 작업하고 고민하며 해결해온 이들로부터 우리 같은 개발자가 배울 수있는 좋은 기회를 제공합니다.

무료

Java 플랫폼과 Java 에코시스템에서 가장 많이 사용되는 도구는 개발자가(또는 종종 영리단체도) 사용할 때 돈을 지불할 필요가 없습니다. Oracle이 Java 11에서 라이선스 및 지원을 변경한 후에도 Oracle 및 기타 많은 공급업체는 프로덕션에서 무료로 언어를 사용하는 방법을 계속 제공했습니다. 이 글에서 이미 언급된 오픈 소스 프로젝트, 빌드 도구 및 IDE는 모두 무료이거나 무료 옵션이 있습니다. 이는 예산을 계속 고려하며 소프트웨어를 개발해야 하는 모든 규모의 조직이나 코딩을 시작하는 개발자에게 Java가 매력적인 이유이기도 합니다.

객체 지향적

물론 객체 지향 프로그래밍은 유일한 선택지는 아니며 모든 패러다임에는 각각의 장단점이 있습니다. Java는 처음부터 객체 지향적 언어로 설계되었기에 객체 지향의 수많은 설계 패턴 예시와 기타 코딩 모범 사례가 Java로 시연됩니다. 따라서 객체 지향적 프로그래밍 언어를 원한다면 Java를 사용해봐야 할 언어 목록 중 우선적으로 고려해야 할 것입니다.

발전과 적응

Java는 과거에도 그랬고, 지금 역시 객체 지향적 프로그래밍 언어입니다. 그러나 한편으로 람다 식, 불변 데이터 구조와 같은 함수 프로그래밍의 일부 개념을 성공적으로 도입하여 객체 지향적 패러다임 내에서 원활하게 작동하도록 만들었습니다. 유형 추론(예: var)을 사용하면 정적 유형 언어의 이점을 얻을 수 있지만 상용구는 적습니다. 컴퓨터 과학은 여전히 ​​젊은 분야이지만, 점차 지식을 쌓으면 학습한 내용을 기존 도구에 적용할 수 있습니다. Java(언어 및 전체 에코시스템)는 새로운 트렌드와 새로운 ‘모범 사례’에 따라, 또한 실제 환경에서 어떻게 작동하는지 확인한 결과를 바탕으로 지속적으로 발전하고 있습니다.

Java는 또한 다른 JVM 언어의 구문과 아이디어를 활용하여 기존 Java 환경에 적합한 것과 적합하지 않을 수 있는 것이 무엇인지 파악합니다. JCPOpenJDK와 같이 Java가 발전하고 성장하기 위해 사용하는 프로세스와 도구조차도 이러한 끊임없는 발전 과정에서 적합성을 유지하도록 적응시키고 있습니다. 이러한 발전과 적응은 Java가 맞추어야 할 조심스러운 균형의 일부입니다.

가독성에 중점

Java 코드는 Java 프로그래머가 아닌 사람도 읽을 수 있는 경우가 많습니다. 이 언어는 과하게 간결하기보다 장황하게 표현되므로 읽을 때 의미를 추론하기가 더 쉽습니다. Java 언어 개발자는 예기치 않은 사용자 지정 동작에 놀라지 않는 것이 중요하다고 생각하기 때문에 연산자 오버로드와 같은 기능을 구현하지 않았습니다. 언어와 프레임워크에서는 ‘마법 같은 동작’을 기피하는 경향이 있습니다. 일부 프레임워크에서는 개발자가 따로 명령하지 않아도 구성보다 관습(Convention over configuration) 같은 것을 사용해 작업을 수행하지만 가령 AOP(관점 지향 프로그래밍) 수행 시 어노테이션을 추가하는 것을 삼가하고 문서 및 정적 분석 검사에 어노테이션을 사용하려는 움직임이 확연히 있습니다. 커뮤니티와 에코시스템은 표준과 ‘모범 사례’를 선호하는 편이므로 Java 코드는 종종 매우 다른 프로젝트에서도 비슷한 종류의 규칙을 따릅니다.

언어 기능

지금까지 Java에 관해 좋아하는 23가지를 다루었지만 기능은 단 하나도 언급하지 않았습니다! 솔직히 기능을 25가지로 한정하는 것은 매우 어려워 보였고, Java에 관해 우리가 좋아하는 수많은 특징이 항상 구문이나 기능에 관한 것만은 아니기 때문입니다. 그래서 좋아하는 기능에 관해서는 개발자의 목소리로 직접 들려 드리려고 합니다.

  • Collections API: 오랫동안 사용하며 도움을 많이 받았어요!
  • 편리한 컬렉션용 factory 메소드: 수정 불가능한 컬렉션을 훨씬 간편하게 만들 수 있어요.
  • Streams API: Collections API의 훌륭한 추가 기능으로, Java 8 이후에도 계속 발전하고 있어서 좋았습니다. 병렬 스트림으로 최신 하드웨어를 활용할 수 있는 방법이 생겼어요.
  • 람다 식: Streams API에서 특히 유용하지만 그 자체로도 매우 쓸모가 많아요.
  • Optional: 메소드가 무언가를 제공하지 않을 수 있음을 표현하는 좋은 방법이에요(NullPointerException으로부터 보호해야 할 필요가 없어져요!). Java 8부터 Optional에 대한 개선 사항을 확인할 수 있는 것도 정말 좋아요.
  • java.time: 날짜 및 시간 작업을 위한 최신 API는 반가운 개선 사항이죠.
  • 검사된 예외: 사람들은 검사된 예외파와 런타임 예외파로 나뉘지만 적어도 검사된 예외를 사용하려는 사람들에게는 검사된 예외가 제공되죠.
  • 어노테이션: 어노테이션은 (다른 기능도 있겠지만) 컴파일러가 확인할 수 있는 문서나 대규모 작업을 수행하는 프레임워크에 대한 메모 같은 역할을 해요.
  • JShell: 드디어 REPL에서 Java로 작업할 수 있게 되었어요.
  • var: 유형 추론을 현명하게 사용하면 코드 노이즈를 줄일 수 있어요.
  • 액세스 한정자모듈성: Java를 사용하면 어떤 코드가 어떤 필드, 메소드, 클래스, 모듈에 액세스할 수 있는지 쉽게(Java 9부터는 훨씬 더 쉽게) 명시화할 수 있어요.
  • Switch 식: 이제 switch 식을 사용해도 덜 지저분해 보이네요!
  • Helpful NullPointerExceptions: 좋은 NullPointerException을 마다할 사람이 누가 있을까요? 이제 예외에서 무엇이 null인지에 관해 훨씬 유용한 정보를 개발자에게 제공해줘요.
  • 테스트 버전 기능: 테스트 버전 기능이 정말 좋아요! 레코드, instanceof의 패턴 일치, 텍스트 블록 기능을 보고 진짜 신났어요.

미래

새로운 기능은 6개월마다 출시되며 보통 각각의 장기적 지원 릴리스는 해당 릴리스에서 실행되는 모든 애플리케이션에 대해 기본적으로 더 나은 성능을 제공합니다. Java 15(2020년 9월)에는 숨겨진 클래스, 텍스트 블록(더 이상 테스트 버전으로 제공되지 않음), 업데이트된 레코드 테스트 버전, instanceof에 대한 패턴 일치, 봉인된 클래스의 테스트 버전이 포함될 예정입니다.

Project Loom에서 고안 중인 사용하기 쉽고 가벼운 동시 실행, Project Valhalla의 인라인 유형, Project Amber에서 작업 중인 람다의 잔여 요소(leftovers) 등의 다양한 언어 변경 사항, Project Panama에서 지원하는 외부 API에 대한 간편한 액세스, Project Leydon에서 준비 중인 시작 시간 단축, 가비지 컬렉터에 대한 다양한 개선 사항 등, 향후 출시되기를 기대하는 기능이 많습니다.

Java의 미래는 밝습니다!

이 게시물은 Trisha Gee가 작성한 25 Things We Love About Java를 번역한 글입니다.

Posted in IntelliJ IDEA | Tagged , , , , | Leave a comment

Kotlin Heroes 4 대회가 곧 시작됩니다

제4회 Kotlin Heroes 대회가 5월 29일에 열립니다! 5월 29일, 14:35 UTC(한국 표준시 기준 23:35)에 시작하는 대회를 일정에 미리 추가해주세요. 대회 등록을 원한시면, Codeforces 웹사이트의 등록 페이지로 바로 이동해주세요. Kotlin Heroes 대회와 관련한 상세한 내용이 궁금하시다면 아래의 블로그 게시물을 읽어주세요.

2000х1000 블로그

Kotlin Heroes 소개 및 참여해야 하는 이유

Kotlin Heroes는 JetBrains 및 Codeforces가 함께 주관하는 프로젝트입니다. JetBrains는 프로그래밍 언어 Kotlin의 개발사이며 Codeforces는 가장 인기 있는 프로그래밍 대회 플랫폼을 제공합니다.

Kotlin Heroes 참가자들의 주요 목표는 제한된 시간 내에 가능한 많은 문제를 올바르게 해결하는 것입니다.

대회의 상세한 정보 및 규칙은 다음과 같습니다.

  • 평균적으로 대회 참가자는 약 700여명에 이릅니다.
  • 제4회 Kotlin Heroes 대회는 2시간 30분 동안 진행됩니다.
  • 참가자에게 제시되는 문제 개수는 7-10개입니다.
  • 쉬운 문제부터 어려운 문제까지 난이도는 다양하게 구성되어 있습니다.
  • 참가자는 문제를 해결할 때, 오직 Kotlin 언어만을 사용할 수 있습니다.
  • 올바르게 해결한 문제 개수에 따라 참가자 순위가 결정됩니다.

상품이 걸려 있습니다!
1등에서 3등까지 참가자는 각각 $512, $256, $128 상당의 상품을 받게 됩니다. 상위 50명의 참가자에겐 Kotlin Heroes 티셔츠를 받게 됩니다. 마지막으로, 하나 이상의 문제를 해결한 모든 참가자를 대상으로 추첨을 하여, 50명에게 한정판 Kotlin Heroes 티셔츠를 드립니다.

green_2_tee

대회 참가를 즐기는 프로그래머에게 Kotlin Heroes는 어떤 도움이 되나요?

  • 대회 참가를 즐기는 프로그래머들은 Kotlin 언어의 기술과 기능을 습득할 수 있습니다.
  • ICPC의 다음 단계에 대비하는 좋은 기회입니다.
  • 혁신적이며 빠르고 강력한 언어를 사용하여 프로그래밍 대회에서 목표를 성취할 수 있습니다.

참여 자격 및 준비 사항

대회 참가를 즐기는 프로그래머들이 Kotlin Heroes에 큰 관심을 보이지만, 참가 자격에 경력이나 직업적 배경의 제한은 없습니다. 누구나 참여할 수 있습니다. 필요한 유일한 단계는 Codeforces 플랫폼에 등록하는 것입니다.

Kotlin Heroes 대회에 참가하세요!

초보자: Kotlin을 사용한 기간 또는 전반적 프로그래밍 경력이 짧더라도 괜찮습니다. Kotlin Heroes는 기술을 연습하고 언어에 대한 감각을 익힐 수 있는 좋은 행사입니다.

숙련된 엔지니어: Kotlin Heroes는 기술을 연마할 수 있는 새로운 장을 제공합니다. 알고리즘과 데이터 구조에 대한 이해를 테스트할 기회가 필요하거나 경쟁적인 환경에서 문제에 대한 최적의 솔루션을 찾는 것을 즐긴다면 Kotlin Heroes가 적합한 대회입니다.

대회 참가를 즐기는 프로그래머: 어려운 문제에 대한 도전은 강력한 새 도구를 활용해 볼 기회를 선사합니다. 또한 프로그래밍 대회 시즌에 대비하면서 기술을 연마할 수 있는 행사이기도 합니다.

대회를 준비하려면 Kotlin 경쟁 프로그래밍에 대한 튜토리얼을 확인하세요. 또한 Codeforces에서는 Kotlin Heroes 대회 9일 전부터 연습 대회(Kotlin Heroes: Practice 4)도 제공합니다. 모든 솔루션이 공개되므로 본인이 아직 문제를 해결하지 못했더라도 솔루션을 볼 수 있습니다. Kotlin을 사용해 문제 해결 능력을 갈고 닦을 수 있는 다양한 방법을 찾고 있다면 대회의 기출 문제를 살펴보는 것도 추천해 드립니다.

이 글은 Alina Dolgikh가 작성한 Kotlin Heroes 4: the Next Round is Almost Here를 번역한 글입니다.

Posted in Kotlin | Tagged , , , | Leave a comment

GoLand에서 Kubernetes 사용하기

Docker, Docker Compose 또는 Kubernetes를 사용하여 Go 서비스를 실행하는 방법에 관한 시리즈 중 마지막 글입니다. 여기에서는 Kubernetes 클러스터를 사용할 때 실행 및 디버그하는 방법을 집중적으로 다룰 것입니다.

Kubernetes 클러스터 설치 및 구성 방법은 다루지 않지만 이 작업은 kubeadm, minikube, microk8s와 같은 다양한 도구를 사용하여 수행할 수 있습니다. Windows를 사용하는 경우 Windows용 Docker Desktop내장된Kubernetes 지원이 함께 제공됩니다. Raspberry Pi 4와 같이 ARM 칩 기반 플랫폼을 대신 사용하려는 경우 k3s 등을 사용하여 시작할 수 있습니다.

또한 Kubernetes 플러그인은 IDE에서 번들로 제공되지 않으므로 시작하기 전에 설치해야 합니다. 설치하려면 Settings(설정)/Preferences(환경 설정) | Plugins(플러그인) | Marketplace(마켓플레이스)로 이동하여 Kubernetes을 검색하면 됩니다.

IDE를 통해 Kubernetes에서 서비스 실행

지금까지 이 시리즈 글을 읽으셨다면 모든 코드가 다운로드 및 사용 가능하도록 제공된다는 사실을 알고 계실 겁니다. 마찬가지로 여기에서도 Kubernetes를 사용하기 위한 코드가 제공됩니다. 먼저 Kubernetes 브랜치부터 시작해 보겠습니다.

여기에서는 db.yamlweb.yaml이라는 두 가지 파일을 찾을 수 있습니다. 이 파일은 Kubernetes 클러스터에서 GoLand 애플리케이션을 시작하는 데 필요한 모든 정의를 포함합니다. 또한 이 파일에서는 편의상 Kubernetes가 IDE와 동일한 시스템에서 실행되고 있다고 가정합니다.

db.yaml을 열어봅시다.

참고: 이 예시를 시작하기 전에 호스트에서 init.sql 파일의 위치를 변경해야 합니다. 이는 path: /d/GoLandProjects/dockerdev를 이전에 프로젝트를 복제한 위치 경로로 바꾸면 해결됩니다.

이 작업이 완료되면 파일 상단의 에디터 여백에 있는 녹색 화살표를 사용하여 Kubernetes에 데이터베이스를 배포할 수 있습니다.

데이터베이스를 배포하면 StatefulSet이 생성되고 포드 내에서 데이터베이스가 실행됩니다. 그리고 Services(서비스) 도구 창이 나타나고 리소스를 만드는 데 사용되는 명령어와 해당 명령어의 출력이 표시됩니다.

Kubernetes 클러스터 개요

Kubernetes 클러스터에는 Pods, Deployments, Stateful Sets, Daemon Sets, Jobs, Cron Jobs, Replica Sets, Replication Controllers 등이 실행되는 Workloads 정보가 표시됩니다.

GoLand에서 Kubernetes ReplicaSet 실행하기

또한 서비스인그레스 지점에 관한 네트워크 정보도 클러스터에서 확인할 수 있습니다.

Kubernetes 서비스 및 인그레스 지점

Configuration(구성) 섹션에는 Namespaces, Nodes, Cluster Roles, Roles, Config Maps, Secrets 실행에 관한 정보 등 현재 네임스페이스 또는 클러스터에 대한 모든 구성 정보가 포함됩니다.

Kubernetes 구성 옵션

마지막으로 Storage(스토리지) 섹션에는 현재 구성의 Persistent Volumes, Persistent Volume Claims, Storage Classes가 표시됩니다.

Kubernetes 스토리지 옵션

IDE를 통해 Kubernetes 클러스터에서 Go 애플리케이션 실행

동일한 Kubernetes 클러스터에서 Go 애플리케이션을 실행하여 그 작동 방식을 살펴보겠습니다.

애플리케이션을 실행하려면 먼저 해당 애플리케이션이 포함된 Docker 컨테이너를 빌드해야 합니다. 예시 저장소에는 build Dockerfile이라는 실행 구성이 포함되어 있으며 클러스터 내부에서 컨테이너를 사용하려면 이 실행 구성을 먼저 실행해야 합니다.

이미 짐작하셨겠지만, 그 다음에는 이전에 db.yaml 파일에서 사용했던 녹색 화살표를 이번에는 web.yaml 파일에서 동일하게 사용하여 Kubernetes 내에서 Go 애플리케이션을 실행할 수 있습니다.

GoLand로 Kubernetes에서 Go 서비스 실행

프로 팁: HTTP 요청 파일 접근 방식을 사용해 IDE의 요청을 실행하여 서비스가 작동 중인지 확인할 수 있습니다.

IDE에서 HTTP 요청 실행

Kubernetes 서비스 디버그

GoLand를 사용하여 Kubernetes 서비스를 디버깅하려면 web.yaml 파일을 약간 변경해야 합니다. 이러한 변경 내용은 저장소의 kubernetes-debug 브랜치에서 확인할 수 있습니다.

변경 내용은 일반 Docker 컨테이너디버그하기 위해 변경한 것과 매우 유사하게 적용해야 합니다.

먼저 Dockerfile을 조정한 다음, Run(실행) | Run…(실행…) | ‘build Dockerfile'(Dockerfile 빌드) 구성을 사용하여 빌드해야 합니다.

그런 다음, Run | Debug…(디버그…) | Kubernetes Service(Kubernetes 서비스)를 사용하면 Go Remote(Go 원격) 디버그 구성이 실행됩니다.

Kubernetes에서 실행되는 Go 서비스 디버그

그러면 디버거가 익숙한 디버그 방식대로 작동할 것입니다.

이것으로 Docker, Docker Compose, Kubernetes을 사용하여 Go 마이크로서비스를 실행 및 디버그하는 방법에 관한 시리즈를 마치겠습니다.

이 글에서는 서비스를 일반적인 방법으로 시작하지 않고 디버그할 수 있도록 Kubernetes 플러그인을 사용해 배포 파일을 편집하는 방법에 관해 설명했습니다.
의견이 있으시면 아래의 댓글 섹션, 이슈 트래커 또는 @GoLandIDE 트윗을 통해 공유해 주세요.

이 게시물은 Florin Pățan이 작성한 Using Kubernetes from GoLand를 번역한 글입니다.

Posted in GoLand | Tagged , , | Leave a comment

라이브 템플릿을 사용해서 보다 빠르게 코드를 작성하세요

코드 데모를 준비하거나 일상적으로 코드 작성할 때 라이브 템플릿을 활용하면 코딩 속도를 현저히 높일 수 있습니다. 몇 가지 문자를 입력하면 더 긴 코드로 확장됩니다.

이 블로그에서는 라이브 템플릿이 필요한 이유와 사용 방법을 설명해드릴 예정입니다. 또한 새 템플릿을 생성하고 팀원들과 공유하는 법도 확인해 보세요. 그럼 단순 템플릿부터 시작하겠습니다.



단순 템플릿

단순 템플릿에는 오직 고정된 텍스트만이 포함됩니다. 단순 템플릿을 확장하면 텍스트가 자동으로 소스 코드에 삽입되어 줄임말을 대체합니다.

main 메소드를 코드에 추가하려는 상황을 가정해보겠습니다. 이때 ‘main’을 입력한 후 탭 키를 누르거나 엔터 키를 누르면 main 메소드로 대체할 수 있습니다. 또한 public static void main의 머리글자를 딴 ‘psvm’을 입력해도 같은 결과가 나옵니다. ‘main’ 및 ‘psvm’ 템플릿은 IntelliJ IDEA에서 지원되는 단순 라이브 템플릿입니다. 저는 더 기억하기 쉬운 ‘main’을 자주 사용하는 편입니다.

콘솔에 값을 출력하려면 ‘sout’를 입력해 System.out.println 코드로 확장하세요. 이 흥미로운 라이브 템플릿은 ‘soutv’, ‘soutp’, ‘soutm’ 등의 다양한 버전으로 지원됩니다(이번 섹션에 포함된 gif를 통해 다양한 버전을 확인하실 수 있습니다).

또한 필드나 변수를 정의하는 데 라이브 템플릿을 활용할 수도 있습니다. 예를 들어, ‘psfi’를 입력하면 public static final int 필드 코드가 생성됩니다.

하지만 이것은 라이브 템플릿에서 할 수 있는 다양한 작업 중 시작에 불과합니다.

매개변수화된 라이브 템플릿

매개변수화된 템플릿에는 입력을 허용하는 변수가 포함됩니다. 매개변수화된 템플릿을 확장할 경우 변수는 사용자가 직접 지정하거나 IntelliJ IDEA에서 자동으로 계산한 입력 필드로 대체됩니다.

for 루프를 숫자 1-10에 대해 반복하여 삽입하려는 상황을 가정해 보겠습니다. 모든 루프 세부 사항을 일일이 입력하는 대신 ‘fori’를 입력하여 for 루프로 확장할 수 있습니다. 루프 변수 이름을 수정하고 싶지 않다면 엔터 키를 눌러 다음 자리표시자로 이동하면 됩니다.

‘for’을 입력하면 ‘for’, ‘fori’, ‘foreach’와 같은 for 루프의 다양한 버전이 표시됩니다. 각 템플릿의 측면에는 간단한 설명이 함께 제시되므로 내게 가장 적합한 옵션을 선택하는 데 유용합니다.

또 자주 사용되는 다른 제어문에는 if 문이 있습니다. ‘if’를 입력하고 탭 키를 누르면 IntelliJ IDEA가 전체 괄호 집합을 자동으로 추가합니다. 개인적으로 가장 좋아하는 기능 중 하나는 누락된 괄호를 추가하는 Complete Current Statement(현재 구문 완성) 명령어입니다. if 문의 변형 버전인 ‘ifn’를 활용하면 IntelliJ IDEA에서 null이 아닌 변수를 검사하는 코드가 생성됩니다.

줄임말을 입력할 때 다양한 라이브 템플릿이 표시되는 것을 보셨나요? 그렇지만 표시되는 옵션이 라이브 템플릿, 메소드 또는 키워드 중 어디에 해당하는지 어떻게 구별할 수 있을까요? 가령, c를 입력할 경우 clone(), char, class, ‘cxf’ 등의 여러 옵션이 표시됩니다. 메소드 이름 다음에는 괄호가 추가되며 키워드의 경우 설명이 따로 없습니다. ‘cxf’와 같은 라이브 템플릿에는 설명이 포함되지만 괄호가 추가로 붙지는 않습니다.

둘러싸기 라이브 템플릿


둘러싸기 라이브 템플릿을 활용하면 선택한 블록 코드를 다른 코드로 감쌀 수 있습니다. Ctrl+Alt+J(Windows/Linux) 또는 ⌥⌘J(MacOS) 키를 누르면 Select Template(템플릿 선택) 팝업이 표시됩니다. 이때 둘러싸기 라이브 템플릿을 선택하여 태그 쌍으로 코드를 감싸고 코드 조각을 수정하거나 누락된 코드를 추가할 수 있습니다.

모든 기존 라이브 템플릿 보기

IntelliJ IDEA에는 수많은 라이브 템플릿이 정의되어 있습니다. 이 내용에 관심이 있다면, 모든 라이브 템플릿을 살펴보고 사용 방법을 학습해 보세요.

모든 라이브 템플릿을 확인하려면 Ctrl+Alt+S(Windows) 또는 ⌘Comma(macOS)를 사용하여 Settings(설정) 대화상자를 열어주세요. 그리고 라이브 템플릿을 검색하세요. 라이브 템플릿은 반복, Kotlin, Maven과 같이 언어별 또는 기능별로 그룹 지정되어 있습니다.

일부 목록을 클릭하여 해당 템플릿의 줄임말을 사용 시 어떤 코드가 입력되는지 확인할 수 있습니다. 여러 템플릿을 살펴보는 과정은 직접 코드를 작성할 때도 도움이 됩니다.

자주 사용되는 ‘sout’ 템플릿의 세부 사항을 확인해보겠습니다. 이 템플릿을 사용할 때 커서가 괄호 안에 배치된다는 점을 기억하고 계실겁니다. END 변수가 커서의 위치를 지정합니다.

기존 라이브 템플릿 복사

기존 라이브 템플릿의 줄임말과, 삽입되는 관련 코드를 복사하고 편집해 새 라이브 템플릿을 생성할 수 있습니다.

예를 들어, Surround with Callable(호출 요소로 감싸기) 템플릿을 수정해 익명 클래스 대신 람다식에서 선택한 코드를 감싸도록 만들어 보겠습니다.

Settings(설정)로 이동하여 Surround with Callable 옵션을 선택하고 Duplicates(복제) 아이콘을 클릭하세요. 이 템플릿의 이름을 CWithLambdas로 변경한 후 설명도 ‘람다를 활용하는 호출 요소로 감싸기’로 바꿔줍니다. 다음으로 템플릿 텍스트가 람다를 활용하도록 변경합니다.

이제 이 템플릿을 코드에 적용하는 옵션이 지원됩니다.

새 라이브 템플릿 생성

기존 템플릿 수정만으로는 부족하다면 처음부터 새로운 라이브 템플릿을 생성할 수도 있습니다.

가령, 테스트 메소드를 코드에 빈번히 삽입해야 하는 경우를 가정해 보세요. 새 라이브 템플릿을 생성해 이 작업을 더욱 수월하게 실행할 수 있습니다.

Settings(설정) | Live Templates(라이브 템플릿)으로 이동하여 +(추가) 아이콘을 클릭합니다. 라이브 템플릿 또는 템플릿 그룹 생성을 선택할 수 있습니다. IntelliJ IDEA의 라이브 템플릿은 언어별 혹은 기능별로 그룹화되어 있습니다. 테스트와 관련한 다수의 라이브 템플릿을 생성하실 계획이라면 TDD(테스트 기반 개발) 등의 그룹을 구성하는 것도 가능합니다.

새 라이브 템플릿을 생성하려면 줄임말, 설명 및 템플릿 텍스트에 값을 추가해야 합니다. 또한 템플릿 텍스트의 변수를 정의하고 기본 값이나 다른 세부 사항 등을 지정하는 방식으로 변수를 구성할 수 있습니다. 마지막 단계는 주석, 선언, 표현식, 스마트 유형 완성, 구문 또는 문자열과 같은 라이브 템플릿의 컨텍스트를 정의하는 것입니다. 라이브 템플릿이 모든 곳이 아닌 필요한 곳에만 표시되도록 지정하려면 꼭 필요한 단계입니다.

라이브 템플릿 공유

나만의 라이브 템플릿을 새롭게 생성하면 팀원들과 공유하고 싶으실 수도 있습니다. 그런 경우 IntelliJ IDEA에서 이 설정을 파일로 내보내는 것이 가능합니다. 라이브 템플릿만 내보내려면 다른 옵션은 선택 해제하세요. 파일을 내보낸 후 팀원이 가져오기 설정을 활용해 해당 파일을 가져올 수 있습니다(단, 업데이트된 설정을 확인하려면 IntelliJ IDEA 재시작이 필요할 수도 있습니다). 실제로 라이브 템플릿을 공유하는 과정을 확인하려면 이 블로그 상단에 있는 스크린캐스트를 시청해주세요.

요약

강력하고 활용도가 높은 기능인 라이브 템플릿을 사용해서 생산성을 향상시켜보세요.

라이브 템플릿은 수동 입력 시간을 단축하여 코딩 속도를 개선합니다. 또한 IntelliJ IDEA에서 사전 정의된 라이브 템플릿을 사용하고 편집하거나 나만의 템플릿을 생성할 수도 있습니다. 다양한 수준의 사용자 지정 옵션도 제공됩니다. 직접 생성한 라이브 템플릿을 팀원들과 공유해 팀의 생산성도 함께 높여보세요.

Happy developing!

이 게시물은 Mala Gupta가 작성한 Write Code Faster Using Live Templates를 번역한 글입니다.

Posted in IntelliJ IDEA | Tagged , , , , , , , | Leave a comment

Kotlin 1.4-M2 미리 살펴보기: 표준 라이브러리 개선 사항

Kotlin 1.1.4 작업이 계속 진행되는 가운데 다음 테스트 버전인 1.4-M2가 곧 출시됩니다. 지금부터 이번 테스트 버전의 일부 개선 사항을 공개하려 합니다. 이 글에서는 표준 라이브러리의 변경 내용에 관해 알려 드리겠습니다.

1.4-M2의 표준 라이브러리에서 구현된 핵심 개선 사항 중 몇가지는 다음과 같습니다.

Kotlin 1.4-M2는 아직 출시되지 않았지만 조기 버전이 Kotlin playground에 추가되어 있으므로 이 글에서 확인한 모든 기능을 사용해볼 수 있습니다. 이 글의 코드 샘플은 새 버전에서도 실행됩니다.

새 버전을 사용해보고 싶으시다면, Kotlin 블로그 뉴스레터를 구독하면 출시일에 바로 소식을 받아볼 수 있습니다.

 

공통 라이브러리 확장

Android 및 iOS 또는 JVM 및 JS 등 다양한 플랫폼에서 공유되는 ‘공통’ 코드로 된 표준 라이브러리를 사용할 수 있습니다. 공통 라이브러리는 점차 확대하여 누락된 기능을 추가하고 이동할 예정입니다.

Kotlin/JVM에서 이전 appendln의 구현은 시스템별 줄 구분 기호를 추가했었습니다(UNIX 시스템에서는 \n, Windows에서는 \r\n). 그러나 공통 코드에 관해 논의할 것이면 운영 체제와 기반 플랫폼에 관계없이 동일한 동작을 보장하는 것이 중요하다고 생각합니다. 이것이 새로운 appendLine 함수를 위해 appendln을 더 이상 사용하지 않는 이유입니다. 이 함수는 항상 단일 \n 문자로 줄을 종료합니다.

JVM에서 플랫폼 고유의 구분 기호가 필요한 경우 System.lineSeparator()를 계속 사용할 수도 있습니다.

이제 공통 코드에서 사용되는 다른 함수를 통해, 지정된 스택 추적의 문자열 표현을 사용할 수 있습니다. Throwable.stackTraceToString() 확장은 스택 추적과 함께 이 throwable에 관한 자세한 설명을 반환하고 Throwable.printStackTrace()는 이 설명을 표준 오류 출력으로 인쇄합니다.

또한 공통 코드에서는 Throwable.addSuppressed() 함수로예외를 전달하기 위해 억제된 예외를 지정할 수 있으며 Throwable.suppressedExceptions 속성으로 전체 억제 예외 목록을반환할 수 있습니다.

새로운 배열 함수

다양한 컨테이너 유형으로 작업할 때 일관된 환경을 이용할 수 있도록 배열에 대한 새로운 확장 함수를 추가했습니다.

  • shuffle() – 배열 요소를 임의의 순서로 넣습니다.
  • onEach() – 각 배열 요소에 대해 지정된 액션을 수행하고 배열 자체를 반환합니다.

이러한 함수는 목록을 사용하는 사람들에게 친숙한 것으로, 배열에서도 같은 방식으로 작동합니다.

배열 하위 범위를 정렬하는 새로운 함수도 추가했습니다. 이전에는 매개변수가 fromIndextoIndexsort()가 있었으며 이는 JVM 전용이었습니다. 이제는 공통으로 사용할 수 있고 reverse()sortDescending()의 하위 범위 버전인 2개의 새로운 관련 함수가 생겼습니다. 각 함수는 이름에서 자명하게 파악되는 방식으로 2개의 색인을 취하여 해당 범위 사이의 요소를 재정렬합니다(fromIndex는 포함하지만 toIndex는 제외).

  • 배열 하위 범위에 대한 reverse()는 하위 범위의 요소 순서를 반대로 바꿉니다.
  • 배열 하위 범위에 대한 sortDescending()은 하위 범위의 요소를 내림차순으로 정렬합니다.

Collections API 내 새로운 함수

1.4-M2는 실제 사례에 더 효과적으로 대응할 수 있도록 표준 라이브러리의 Collections API 확장을 계속 하고 있습니다.

  • 새로운 집합 생성 함수 setOfNotNull()은 제공된 인수 중 null이 아닌 모든 항목으로 구성된 집합을 만듭니다.
  • 이제 shuffled()를 시퀀스에도 사용할 수 있습니다.
  • onEachIndexed()reduceIndexedOrNull()이 각각 onEach()reduceOrNull()의 대응 항목으로 추가되었습니다. 아시다시피 컬렉션 처리 함수의 이름에서 색인되었다는 것은적용된 작업에 요소 색인이 매개변수로 있음을 의미합니다.
  • runningFold()runningReduce()scan()scanReduce()의 동의어로 도입되었습니다. 이러한 이름은 관련 함수 fold()reduce()와 더 일치합니다. scan()은 이 작업에서 일반적으로 알려진 이름이므로 나중에 runningFold()와 함께 제공될 예정입니다. 그러나 실험적인 scanReduce()는 더 이상 사용되지 않으며 곧 제거될 것입니다.

기존 API 개선

Kotlin 1.4는 주요 ‘기능’ 릴리스이므로 언어에 새로운 기능을 추가하고 표준 라이브러리에 새로운 함수 또는 인터페이스를 추가할 수 있습니다. 새로운 실험적 선언은 부가적인 릴리스(예: 1.3.70)에서만 추가합니다. Kotlin 1.3.70을 사용하여 코드를 작성하지만 실험적 선언을 사용하지 않으면 작성한 코드가 Kotlin 1.3.40을 사용하는 동료에게도 올바르게 컴파일됩니다.

기능 릴리스는 부가적 릴리스와 동일한 엄격한 규칙을 준수할 필요가 없습니다.
따라서 새 기능 또는 API를 사용하는 경우 1.3 버전의 Kotlin 컴파일러는 Kotlin 1.4로 작성된 코드를 컴파일하지 못할 수 있습니다. 이를 개선하기 위해 API에 일부 변경 내용을 도입하게 되었습니다. 이전 버전용으로 작성된 코드가 이전처럼 계속 컴파일되고 작동할 수 있도록 이전 버전과의 호환성을 주의 깊게 관찰하려고 합니다.

Kotlin 1.4에서는 null을 허용하도록 몇가지 함수 규칙을 완화했습니다.

Kotlin 1.3은 String.toBoolean()의 리시버가 null 가능하도록 허용하지 않기 때문에 이 코드를 컴파일하지 않습니다. Kotlin 1.4는 리시버를 null 가능 문자열인 String?.toBoolean()으로 변경합니다. 이에 따라 이전에 작성된 모든 코드는 Kotlin 1.4에서 계속 컴파일되고 작동합니다.

동일한 논리가 contentEquals, contentHashCode, contentToString 함수의 Array 리시버에도 적용되어 이 리시버도 null 가능해졌습니다. 또한, String.format()은 로컬라이제이션이 적용되지 않은 경우 nulllocale 인수로 허용합니다.

DoubleFloat에 정의된 다음 상수는 이제 ‘진짜’ 상수입니다.

이제 이러한 상수가 const 변수로 정의되어 어노테이션 인수로 사용할 수 있습니다.

SIZE_BITSSIZE_BYTESDoubleFloat의 새로운 상수이므로 2진 형식으로 유형의 인스턴스를 나타내는 데 사용되는 비트 및 바이트 수를 포함합니다.

Kotlin/JS에서 Float.MAX_VALUEFloat.MIN_VALUE 값도 변경되었습니다. 이전에 이 값은 Kotlin/JS에서 FloatDouble과 본질적으로 동일하므로 JavaScript Number.MAX/MIN_VALUE 또는 Double.MAX/MIN_VALUE와 동일했습니다. 이제 이러한 Float 범위의 상수는 모든 플랫폼에서 동일합니다.

vararg가 사용되는 maxOf() 및 minOf()

표준 라이브러리의 maxOf()minOf() 함수는 두 값 중 더 큰 값과 작은 값을 찾습니다. 1.4-M1부터 maxOf()minOf()인수의 가변 숫자(vararg)를 허용하므로 숫자 또는 기타 비교 가능한 항목 집합에서 해당 함수를사용할 수 있습니다.

속성 위임 개선 사항

Kotlin에서 위임된 속성은 인터페이스가 아닌 규칙을 통해 작동합니다. 따라서 위임으로 사용하려는 유형은 필요한 인터페이스를 구현하는 대신 연산자 함수를 정의해야 합니다. 이는 특정 인터페이스에 구속되지 않기 때문에 유연성을 제공하지만 많은 실제 사용 사례에서는 여전히 인터페이스를 사용하는 것이 좋습니다.

Kotlin 1.4에서는 이러한 보완 인터페이스를 더욱 효과적으로 사용할 수 있도록 새로운 PropertyDelegateProvider 인터페이스를 도입하였습니다.
또한 ReadWritePropertyReadOnlyProperty를 상속합니다. 자세한 내용은 계속 읽으면서 확인해 주세요.

Delegate 표현식

사용자 지정 클래스 또는 익명 객체로 위임을 구현하는 경우 속성 위임을 정의할 때 ReadWritePropertyReadOnlyProperty 인터페이스를 편리하게 사용할 수 있습니다.

1.4부터는 ReadWritePropertyReadOnlyProperty를 상속합니다. 이에 따라 delegate 표현식을 더 유연하게 사용하여 작업할 수 있게 되었습니다. 이 예시에서는 ReadOnlyProperty가 필요할 때마다 myDelegate() 호출을 전달할 수 있습니다.

여기서는 읽기 전용 목록이 변경 불가능한 목록이 아니듯이 Kotlin의 ‘읽기 전용’이 ‘불변’과 동일하지 않다는 점을 강조하고 싶습니다. ‘읽기 전용’이란 ‘이 인터페이스는 해당 객체에 대한 읽기 전용 액세스만 제공’한다는 것을 의미합니다.

위임 제공

위임을 제공하는 메커니즘을 사용하면 속성 구현이 위임되는 “delegate” 객체를 생성하는 논리를 확장할 수 있습니다. 작동 방식에 대한 자세한 내용은 문서에서 확인할 수 있습니다. 1.4에서는 이 메커니즘을 좀 더 편리하게 이용할 수 있도록 새로운 PropertyDelegateProvider 인터페이스를 추가했습니다. 이는 추가로 클래스를 만들고 싶지 않고 위의 myDelegate() 예시에 나온 것과 유사한 익명 객체 사용을 선호하는 경우에 사용할 수 있습니다.

다른 속성에 위임

1.4부터 속성은 해당 getter와 setter를 다른 속성에 바로 위임할 수 있습니다. 예를 들어 이는 이전 버전과 호환되는 방식으로 속성의 이름을 바꾸려는 경우 유용할 수 있습니다. 새 속성을 삽입하고 @Deprecated 어노테이션을 이전 속성에 추가한 다음, 구현을 위임하세요.

앞에서 설명한 컴파일된 위임 속성의 최적화는 이 경우에 사용할 수 있습니다. 위임 연산자 구현은 위임되는 속성(oldName)에 대한 정보를 사용하지 않으므로 컴파일러가 해당 정보를 사용하여 KProperty 인스턴스를 생성할 필요가 없습니다. 향후에는 위임(newName)에 대한 추가 KMutableProperty 인스턴스도 생성할 필요가 없을 수 있습니다.

체험 방법

이상 설명된 모든 변경 내용은 Kotlin 1.4-M2 테스트버전의 일부이지만 play.kotl.in에서 온라인으로 체험해 볼 수 있습니다. 단, 설정에서 1.4-M2 버전을 선택해야 하는 점을 잊지 말아주세요.

사전 릴리스 노트

이전 버전과의 호환성은 사전 릴리스 버전에는 적용되지 않습니다. 기능 및 API는 사용자의 피드백에 따라 후속 릴리스에서 변경될 수 있습니다.

의견을 공유해 주세요

이슈 트래커에 버그를 리포트해주신 모든 분께 감사드립니다. 그 다음 Kotlin 릴리스에서 문제가 해결되기를 기다리실 필요가 없도록 최종 릴리스 전에 최선을 다하여 모든 중요한 문제를 해결하겠습니다.

궁금한 점이 있거나 토론에 참여하고 싶거나 새로운 테스트 버전 빌드에 관한알림을 받고 싶으신 경우 Kotlin Slack의 #eap 채널에 언제든지 참여할 수 있습니다(여기에서 초대받기).

Let’s Kotlin!

이 게시물은 Pavel Semyonov가 작성한 First Look at Kotlin 1.4-M2: Standard Library Improvements를 번역한 글입니다.

Posted in Kotlin | Tagged , , , , | Leave a comment

CLion 2020.1: IDE 전반의 다양한 개선 사항 및 CUDA와 임베디드 프로젝트 사용 혜택

우선 모두 안전하게 지내시길 바란다는 인사를 전합니다! 사실 요즘처럼 중요한 소식이 많은 시기에 업무에 집중하기 쉽지 않습니다. 그럼에도 저희 팀은 최선을 다해 가장 자신 있는 일을 해 왔습니다. 바로 개발자의 생산성을 높이는 훌륭한 도구를 제작하는 일이죠. 그리하여 새로운 CLion 2020.1 릴리스를 소개합니다!

CLion 2020.1 릴리스

새 버전으로 업데이트를 하려면 Toolbox App, Ubuntu의 스냅 패키지, 웹사이트 또는 2019.3(2019.3.5) 최신 빌드의 패치 업데이트를 사용하면 됩니다.

CLion 2020.1 다운로드

아래 내용에서 주요 개선 사항을 간략히 살펴보실 수 있습니다. 특정 세부 정보에 관심이 있으시면 다음을 읽어주세요.

CUDA 프로젝트

본질적으로 CUDA C 및 C++는 몇 가지 확장프로그램을 더한 C/C++입니다. 이제 CLion 2020.1 버전에서 CUDA 코드를 적절히 처리할 수 있습니다. 저희 팀은 CLion 언어 엔진에서 CUDA 코드를 올바르게 분석하도록 학습시키는 데 많은 노력을 투입하여 코드 분석 시 적색 코드와 긍정오류(오탐)를 제거하였습니다. 또한 이번 개선에는 CUDA 코드에서도 작동하는 코드 탐색, 코드 문서 및 기타 코딩 지원이 포함됩니다. 마지막으로 코드 완성 기능에 커널 호출의 대괄호 완성 기능도 추가되었습니다.
CUDA 코드 완성

(테스트에서는 GitHub의 ClaraGenomicsAnalysis 프로젝트를 사용했습니다.)

그뿐 아니라 CLion은 CUDA 파일 확장자인 .cu/.cuh도 지원합니다. 이제 신규 C/C++ 파일 생성 시 해당 확장자를 선택할 수 있습니다. 또한 CLion은 새롭게 생성된 파일에 CMake 대상을 추가하도록 제안합니다. 이제 다음의 선택 가능한 옵션 목록에 CUDA 대상(0>cuda_add_executable / cuda_add_library으로 생성된 대상) 이 추가됩니다.
CUDA 새 파일

마지막으로, CLion에서 신규 CUDA 프로젝트를 시작하는 기능이 추가되어, 새 프로젝트 마법사를 통해 CMake 및 main.cu 샘플 파일을 생성할 수 있습니다. CLion에서 CUDA 프로젝트로 작업하는 방법은 온라인 도움말을 참조하세요.

임베디드 개발

CLion 임베디드 개발을 지속적으로 개선해 왔으며 이번 릴리스에서도 두 가지 중요 개선 사항을 추가했습니다. 첫 번째는 IAR 컴파일러 지원입니다. 이제 CLion에서 컴파일러 정보를 적절히 수집하므로 임베디드 프로젝트에서 컴파일러를 성공적으로 사용할 수 있습니다. IAR 컴파일러 사용에 도움이 될 몇 가지 팁을 소개합니다.

  • MinGW 필요 CLion의 IAR 툴체인 설정에서 MinGW 환경을 사용하고 해당 필드의 IAR 컴파일러로 경로를 제공합니다.
  • IAR 임베디드 작업 환경에서 CMake를 활용하는 방법을 다음 노트에서 확인해 보세요.

IAR 컴파일러
이 자리를 빌어 IAR Systems AB의 지원 및 파트너 라이선스에 다시 한번 감사를 표합니다. 앞으로도 지속적인 협업을 기대해주세요. 다음 목표는 이 툴체인과 통합을 추가로 살펴보는 것입니다.

두 번째 개선 사항은 CLion 플러그인 PlatformIO입니다. PlatformIO는 차세대 에코시스템으로 Arduino와 같은 임베디드 개발 프로젝트를 빠르게 시작하는 데 매우 유용합니다. 새 프로젝트 마법사로 해당 프로젝트 유형을 선택하면 이 플러그인이 PlatformIO CMake 기반의 프로젝트를 생성하여 배경에서 적절한 PlatformIO 명령어를 호출합니다.
PlatformIO plugin
CLion은 이와 같은 프로젝트 작업 시 자동으로 디버그 및 업로드용 구성을 생성합니다. 또한 PIO 통합 디버거 사용을 위해 PlatformIO 디버그 구성을 생성할 수도 있습니다. 자세한 내용은 공식 문서를 참조하세요.

Windows 프로젝트

Windows에서 CLion을 사용하는 개발자가 점점 늘어나는 추세입니다. 사실 통계를 살펴보면 Windows는 JetBrains 사용자가 주로 사용하는 플랫폼입니다. 그렇기에 Windows 커뮤니티에서 가장 많은 요청이 있는 기능에 집중하고 있습니다.

Clang은 GCC 다음으로 인기 있는 컴파일러입니다(출처: 2019년도 개발자 에코시스템 현황 연구) 물론 Windows의 선두 주자는 Microsoft Visual Studio 컴파일러지만 Clang-cl 역시 폭넓게 사용되고 있습니다. LLVM 웹사이트에서 설치하거나 Visual Studio 도구와 함께 설치 가능합니다. 이제 CLion에서도 사용해 보세요!
Clang-cl 지원

Windows 개발자를 위한 다른 희소식은 바로 Visual Studio C++ 툴체인으로 JetBrains에서 개발한 LLDB 기반 디버거가 이제 해당 툴체인의 기본 디버거로 지원된다는 점입니다. 별도 설정 없이 바로 사용하실 수 있습니다! 상단 스크린샷에서 Visual Studio 툴체인으로 미리 선택된 옵션을 확인하세요. 단, 해당 디버거는 일반 LLDB 빌드가 아니며, JetBrains 팀에서 개발하여 Native Visualizer를 처리할 수 있는 디버거입니다(Native Visualizer 지원을 활성화하려면 Settings(설정) | Build, Execution, Deployment(빌드, 실행 배포) | Debugger Data Views(디버거 데이터 뷰) | Enable NatVis renderers for LLDB(LLDB용 NatVis 렌더러 활성화)로 이동하세요.

다음의 짤막한 데모도 확인해 보세요.

Clang 기반 도구 업데이트

또 다른 중요 개선 사항은 저희 팀이 가능한 범위 내에서 Clangd 기반 언어 엔진으로 이전하는 것입니다. 그 이유는 두 가지인데요, 첫 번째 이유는 보다 정확한 언어 기능을 개발하여 언어 표준의 최근 업데이트를 빠르게 따라잡기 위함입니다. 두 번째로, 언어 제약이 없는 액션의 기능을 향상하고자 합니다(Clang에서 항상 가능한 것은 아니지만 더욱 다양한 기능을 지속적으로 시험할 예정입니다).

CLion 2020.1 버전에서는 데이터 흐름 분석(DFA) 기능이 Clangd로 완전히 이전되었습니다. DFA는 무엇이며 왜 유용할까요? DFA 검사는 코드 내 데이터 흐름을 분서한 후 분석 결과를 기반으로 잠재적 문제를 탐지합니다. 예를 들어 DFA는 항상 false/true인 조건문, 무한 루프, 누락된 반환문, 무한 재귀 등을 파악할 수 있습니다.
DFA
이러한 기능은 대다수의 컴파일러에서 지원되지 않는 기능입니다. 물론 DFA 작업은 매우 정확한 코드 구문 분석 및 문제 해결이 요구되며 이는 상당한 시간이 소요되는 작업입니다. 특히 기본 문제 해결 작업의 속도가 느릴 때 더 많은 시간이 소요될 테고요. 그렇기에 Clangd으로의 이전은 분석 검사 기능을 개선하는 과정이라 볼 수 있습니다.

이전 CLion 버전에서 Clangd 기반 코드 완성 제공자가 도입되었지만 당시에는 CLion 자체 제공자와 결합을 통해서만 작동하였습니다. 2020.1 버전을 개발하는 동안 수십개의 관련 문제를 수정하고 누락된 코드 완성 기능을 추가하여 Clang에 의해 제공되는 코드 완성을 개선했습니다. 그 결과, 기본적으로 CLion 코드 완성 기능의 단독 공급자로 Clang을 사용하는 모드를 사용할 수 있게 되었습니다. 이로 인해 우선 순위 지정 및 정렬과 관련된 일부 문제가 해결되었습니다.

여러 C++ 프로젝트에서 ClangFormat 및 Clang-Tidy는 표준 도구로 사용되며 그 구성 파일은 프로젝트 저장소에 커밋되는 경우가 많습니다. 하지만 CLion에서 이러한 도구들의 통합이 도구 자동 전환을 지원하지는 않았습니다. 불편 사항을 지적해주신 사용자 여러분께 진심으로 감사의 말씀을 전합니다! 이제 CLion에서는 다음 기능이 지원됩니다.

  1. 프로젝트 루트에서 .clang-format 구성 파일을 탐지하고 ClangFormat으로 자동 전환(현재로서는 프로젝트 설정별 IDE 전환만이 지원됩니다).
  2. .clang-tidy 구성 파일을 탐지하고 이 구성파일을 위해 IDE 설정의 Clang-Tidy 사용을 자동으로 해제

이 기능의 도입으로 두 가지 Clang 도구를 훨씬 편리하게 사용하실 수 있길 바랍니다!

다음의 짤막한 데모도 확인해 보세요.

리팩토링, 서식 지정 도구, 문서 및 에디터 개선 사항

CLion은 유용한 리팩토링을 다양하게 제공합니다. 그중 Change Signature(시그니처 변경)(Windows 및 Linux: Ctrl+F6, macOS: ⌘F6)는 가장 인기 있는 리팩토링 중 하나입니다. 이 리팩토링은 함수 이름 및 반환 유형 변경과 매개변수 추가, 제거 및 재배열 기능을 지원합니다. 함수 수동 업데이트에 비해 이 리팩토링은 함수 시그니처 변경 시 진가를 발휘합니다. CLion에서 해당 함수의 사용 위치를 모두 검색하고 모든 호출, 구현, 재정의 기록을 업데이트하여 변경 사항이 반영되도록 안전하게 시그니처를 변경합니다.

새 매개변수가 추가될 때 함수 사용 위치는 어떻게 처리되는지 궁금하실 수도 있습니다. 기존 CLion 버전에서는 코드를 컴파일 가능한 상태로 유지하기 위해 기본 유형 값을 해당 사용 위치에 인수(숫자에는 0, 포인터에는 nullptr)로 추가했습니다. 한편 CLion 2020.1 버전의 경우 리팩토링 대화상자에서 업데이트된 모든 함수 사용 위치의 값 중 대체할 값을 직접 지정할 수 있습니다.
시그너처 변경

또한, 대화상자의 새로운 기본 값 필드에서 코드 완성 기능도 지원됩니다! 해당 필드를 공백으로 두면 기존 동작이 적용되며 해당 유형의 기본 값이 사용됩니다.

이번 릴리스는 업데이트된 서식 지정 도구를 선보입니다. 이제 구조체 멤버 필드 및 클래스 멤버 필드의 이름 지정을 별도로 설정할 수 있습니다. 그뿐 아니라 코드 접기가 #pragma region#pragma endregion에서 지원됩니다.

에디터 업데이트 사항은 다음과 같습니다.

  • 문서 미리보기 및 함수 시그니처, 추론 유형, 매크로 치환 관련 정보가 표시되는 포괄적 문서 미리보기 도구인 빠른 문서 보기 기능이 이제 마우스로 가리키는 것만으로 지원됩니다.
  • 에디터 기본 글꼴로 JetBrains에서 개발한 새로운 오픈 소스 글꼴인 JetBrains Mono가 제공됩니다.
  • 새로운 기본 light 테마인 IntelliJ Light를 살펴보세요. 이제 모든 운영 체제에서 표준 테마로 지원됩니다.
  • 한 번에 여러 개의 터미널 세션을 사용해야 할 경우 터미널을 수직 혹은 수평으로 분할하여 다수의 세션을 나란히 실행할 수 있습니다.
    터미널 분할

다음의 짤막한 데모도 확인해 보세요.

실행/디버그 구성

실행/디버그 구성은 CLion에서 애플리케이션 실행 및 디버그를 통해 애플리케이션 시작을 지원합니다. 이번 릴리스에 몇 가지 주요 업데이트가 추가되었습니다.

  • 원격 GDB 서버임베디드 GDB 서버 구성이 사용자 지정 대상에서도 작동합니다. 따라서 로컬 시스템에서 실행 중인 CLion 인스턴스의 원격 호스트 또는 마이크로 컨트롤러에서 애플리케이션을 디버그할 수 있으며, 이는 CMake 기반 프로젝트뿐 아니라 모든 사용자 지정 애플리케이션(컴파일 데이터베이스 포함)에서도 지원됩니다.
  • 이제 CLion에서 Google Test 대상 1.8.1 버전 및 상위 버전을 적절히 인식하며 자동으로 실행/디버그 구성을 생성합니다(즉, CLion에 내장된 테스트 러너에서 테스트를 실행할 수 있습니다).

CLion 2020.1 버전의 경우 실행/디버그 구성에 매크로 및 경로 변수가 추가되었습니다.

  • 매크로는 사전 정의되었으며, 실행/디버그 구성 대화상자의 + 기호를 클릭하면 열리는 대화상자에서 사용 가능한 매크로 목록을 확인할 수 있습니다. 단, 매크로는 현재 CMake, 사용자 지정 빌드 및 Gradle Native 애플리케이션에서만 지원됩니다.
  • 경로 변수는 Settings/Preferences(설정/환경 설정) | Appearance & Behavior(모양 및 동작) | Path Variables(경로 변수)에서 구성할 수 있습니다. 일반적인 사용 사례는 프로젝트에서 광범위하게 사용되지만 프로젝트 디렉토리 외부에 위치한 라이브러리 경로 변수를 생성하는 것입니다.

Prompt/FilePrompt 매크로는 구성에 새롭게 추가된 Redirect input from(다음에서 입력 리디렉션) 필드와 결합하여 사용하면 더욱 유용합니다. 해당 필드를 통해 입력 항목을 파일에서 애플리케이션 stdin으로 리디렉션할 수 있으며 애플리케이션을 시작할 때마다 FilePrompt 매크로가 파일 선택 대화상자를 호출합니다.
입력 리디렉션

다음의 짤막한 데모도 확인해 보세요.

IntelliJ 플랫폼 업데이트

언제나처럼 VCS 및 기타 IntelliJ 플랫폼 개선 사항IntelliJ Rust 플러그인 업데이트도 CLion의 이번 릴리스에 포함되어있습니다. IntelliJ Rust 플러그인에 대한 블로그 포스트도 게시될 예정이니 새로운 소식을 기다려 주세요!

Makefile 지원 진행 상황?

우와! 혹시 CLion에서 Makefile 지원이 추가될 예정이라는 루머를 들으셨나요?! 루머의 출처가 어디든 그 내용은 사실입니다. 현재 저희 팀은 CLion에 추가할 Makefile 프로젝트 분석기 프로토타입 개발을 마쳤으며 개발 접근법 및 현재 진행 상황에 대한 블로그 게시물도 게시했습니다. 또한 사용자 여러분의 지지를 바탕으로 프로토타입 테스트를 위한 프로젝트 목록도 구성했습니다.

현재 해당 목록에는 약 40여 개의 프로젝트가 포함되어 있으며 그중 절반 이상에 대한 검사가 완료되었습니다(CPython, 일부 임베디드 프로젝트, Nano, Nodejs, PostgreSQL). 대부분 프로젝트는 원활히 작동했지만 프로토타입이 검사에 실패한 프로젝트도 여전히 남아 있습니다(실패 원인에는 libtool과 같은 래퍼가 포함됩니다). GCC, FreeBSD, Wine 및 Perl 등이 실패한 프로젝트에 해당합니다. 한편, 도전적인 몇몇 사용자는 개인 프로젝트에서 프로토타입을 직접 테스트하고 귀중한 피드백을 남겨주셨습니다! 모든 피드백에 감사드립니다.

이 작업은 계속 진행되며, 프토토타입은 2020.2 EAP에서 공개될 예정입니다. 그동안 이 프로젝트를 지원하고 싶다면 이 게시물을 확인해 주세요.

이상입니다! CLion 2020.1 버전을 사용해 보세요. 현재 구독 중이라면 오늘 업데이트하세요. 또는 30일 무료 평가판을 통해 새 기능을 살펴보실 수도 있습니다!

CLion 2020.1 다운로드

CLion 팀
JetBrains
The Drive to Develop

이 게시물은 Anastasia Kazakova가 작성한 CLion 2020.1: Dozens of Improvements Across the IDE, and Benefits for CUDA and Embedded Projects를 번역한 글입니다

Posted in CLion | Tagged , , , | Leave a comment

AppCode 2020.1 출시: 순수 Swift 프로젝트 및 복합 프로젝트에서 코딩 지원 속도 향상, 색인 생성 중 실행되는 코드 완성 기능, 문서 주석 생성, Swift 유형 계층 구조 뷰 등!

올해 첫 업데이트인 AppCode 2020.1 출시를 환영해 주세요!

스플래시

AppCode 2020.1 다운로드

성능

2020.1 버전에서는 AppCode 기능을 다음과 같은 방식으로 대폭 개선하였습니다:

  • 이제 프로젝트를 처음 열 때 연결 심볼이 빌드 및 캐싱됩니다. 즉, 초기 캐싱에는 더 긴 시간이 소요될 수 있지만 완료되면 모든 코딩 지원 액션(코드 완성 및 탐색 포함)이 이전보다 훨씬 빠르게 작동합니다. 또한 하위 프로젝트가 열리는 속도도 개선되었습니다.성능
  • 동일한 파일에서 선언된 매개변수, 지역 변수, 전역 변수에 대한 코드 완성 기능 최적화로 코드 완성 팝업의 작동 속도가 향상되었습니다.
  • Swift 파일이 열릴 때 “Loading(로드 중)”이라는 표시기가 중단되는 불편한 문제를 수정했습니다(해당 문제는 2진 표현식 파싱과 관련된 문제였습니다).

이번 변경 사항이 프로젝트 개발 속도 향상에 도움이 되길 바랍니다. 다음 릴리스에서도 성능 개선에 초점을 맞춘 업데이트를 지속적으로 선보일 예정입니다.

색인 생성 중 실행되는 코드 완성

대규모 프로젝트의 경우 색인 생성과 캐싱 작업을 처음으로 수행할 때 오랜 시간이 소요될 수 있습니다. 기존 AppCode 2019.2 버전에서 색인 생성 중 프로젝트 빌드, 실행, 디버그 및 테스트 기능이 도입되었고, 이번 릴리스에서는 코드 완성 기능이 추가되었습니다.

색인 생성 중 실행되는 코드 완성

현재 구현의 경우 코드 완성 결과를 제공하는 데 SourceKit가 사용됩니다. 이때 유일한 한계는 렌더링하는 매개변수 자리표시자가 부족하다는 점과 를 사용하여 다음 자리표시자로 이동하는 것과 같은 관련 기능의 부재였습니다. 따라서 이제 매개변수 자리표시자가 일반 텍스트로 삽입됩니다.

언어 지원

이제 Swift 언어의 다음 변경 사항이 지원됩니다.

  • SE-0110 및 SE-0155 업데이트(enum 케이스에서 기본 인수).
  • SE-0266: enum 유형에 대한 종합적인 Comparable 적합성.
  • 단일 튜플 매개변수 함수(OC-16842)에 대한 함수 유형 할당가능성 업데이트.

문서 주석

Objective-C/C/C++에서 /** 또는 /*!를 입력하는 것만으로 문서 주석 생성이 가능합니다. 이제 드디어 Swift 마크다운 문서에도 같은 액션이 구현되었습니다. ///를 입력하고 를 눌러 실행하세요.

문서 주석 생성

또한 AppCode는 Quick Documentation(빠른 문서)(F1) 팝업에서 마크다운 문서를 올바르게 표시합니다.

문서 렌더링

유형 계층 구조

Type Hierarchy(유형 계층 구조) 뷰(⌃H)는 객체의 계층 구조를 검사하는 데 유용합니다. 그렇기에 이번 Swift 릴리스에서 해당 기능을 추가하였습니다.

계층 구조 뷰

Structure(구조) 뷰

Swift의 Structure(구조) 뷰에 알파벳순, 유형별, 가시성별로 정렬하는 3가지 정렬 모드가 추가되었습니다.

구조 뷰

검사 및 인텐션

AppCode 2019.3에서 다양한 Swift 인텐션을 구현하여 생산성 향상에 도움을 드리고자 했습니다. AppCode 2020.1에는 유용한 신규 코딩 지원 액션이 추가되었습니다.

  • ifguard 인텐션으로 교체:if를 guard로 교체
  • 불필요한 괄호 검사:불필요한 괄호 제거
  • 불필요한 튜플 줄 바꿈 검사:불필요한 튜플 줄 바꿈 제거

빠른 유형 정의

코드에서 초점을 떼는 일 없이 변수, 필드, 메소드 및 기타 심볼의 유형 정의를 파악할 수 있습니다. 캐럿을 필요한 심볼의 위치에 놓고 ⇧⌘A | Quick Type Definition(빠른 유형 정의)을 선택하세요:

빠른 유형 정의

Touch Bar

오래 전 AppCode에서 성능 문제로 Touch Bar 지원이 중단되었습니다. 이번 릴리스에서는 해당 문제를 해결하여 Touch Bar 기능을 다시 사용할 수 있습니다.

LightEdit 모드

새로운 LightEdit 모드에서는 전체 프로젝트를 생성하거나 로드하지 않고도 텍스트 에디터 같은 에디터에서 파일을 빠르게 수정할 수 있습니다. LightEdit 모드를 사용하여 명령줄, IDE의 시작 화면 또는 OS 시스템 파일 관리자에서 파일을 여세요.

Zen 모드

AppCode UI에 지원되는 추가 모드에 대해 들어보셨을 겁니다. 예를 들어 큰 화면에서 IDE를 표시하는 데 최적화된 Presentation Mode(프레젠테이션 모드)(⇧⌘A | Presentation Mode)나 코딩에만 집중할 수 있도록 간결한 인터페이스를 제공하는 Distraction Free Mode(집중력 분산 방지 모드)등이 있습니다. 이번 릴리스에는 전체 화면으로 표시된 집중력 분산 방지 모드인 Zen 모드가 추가되었습니다.

JetBrains Mono

JetBrains Mono는 개발자를 위해 JetBrains가 특별히 제작한 무료 오픈 소스 서체로, 이제 모든 JetBrains IDE에서 기본 글꼴로 제공됩니다.

이상 입니다! JetBrains 웹사이트에서 모든 새로운 기능을 자세히 살펴보고 30일 무료 평가판을 시작하여 실제로 사용해 보세요!

AppCode 2020.1 다운로드

AppCode 팀
JetBrains
The Drive to Develop

이 게시물은 Stanislav Dombrovsky가 작성한 AppCode 2020.1 Is Here with Faster Code Assistance for Pure Swift and Mixed Projects, Completion During Indexing, Documentation Comments Generation, Type Hierarchy View for Swift, and More!를 번역한 글입니다.

Posted in AppCode | Tagged , , , | Leave a comment