• Visual Studio 2022 vs. 2019: Should You Upgrade Now? Explained, MUO - 번역글
  • 서문
  • Visual Studio 역사: 지금까진, 대부분 좋았다
  • VS 2022에서 가장 중요한 개선사항
  • VS 2022 버전의 다른 신규 사항들
    • 개선된 코드 자동 완성 (Code-Completion) 기능
    • 더 강력해진 디버깅 역량
    • 개선된 프로그래밍 인터페이스
    • 개선된 접근성
    • C++ 최신 빌드에 대한 개선된 지원
    • 개선된 Windows App 개발
  • VS 2022 로 지금 업그레이드 해야할까?
• SETUPTOOlS의 “Development Mode” 번역
• 번역 - Sytax highlight with Rouge in Jekyll, frankindev.com
  • Overview
  • Install Rouge
  • Theme and colour
  • Implement
  • Example
  • Alternative Themes
  • Conclusion
• Sass
  • 참고할 링크
  • Documentation 개요
  • Sass Basics
    • Preprocessing
    • Variables
    • Nesting
    • Partials
    • Modules
    • Mixins

Visual Studio 2022 vs. 2019: Should You Upgrade Now? Explained, MUO - 번역글

• Visual Studio 2022는 몇가지 매우 멋진 변경과 함께 찾아왔다.
  • 당신이 만일 VS 2019를 사용하고 있다면, 업그레이드 해야할까? 아니면 기다려야 할까?
• SEP 02, 2021 by Nancy Jo Melucci
• 제목에 원문 링크

서문

• 2021년 초에 Microsoft는 Visual Studio 2022 preview 버전을 야생의 programming world에 풀어놓았다
• 이것은 좋은 뉴스다
  • 매우 인기있는 IDE지만, DevOps 생태계의 빠른 발전속도를 감안할 때 조정또는 정밀 검사가 필요했기 때문이다
• VS 2019가 모든 레벨의 개발자에게 호감을 얻긴 했지만, 발전이 필요없는 IDE란 존재하기 않는다
  • VS 2022가 그만큼 좋은가?
  • 얼리 어답터가 되어 최신판으로 업그레이드 할 가치가 있는가?
• 여기 알아야 할 것들이 있다.

Visual Studio 역사: 지금까진, 대부분 좋았다

• VS 2019와 VS Code는 초심자에겐 사용자 친화적인 것으로 홍보해왔지만, 고급 사용자들로부터도 지속적인 찬사를 받아왔다
• 예를 들면, Azure, Git/GitHub, Live share, Xamarin 과의 통합이라든가, 쉬운 cloud 기반 storage, 실시간 협업과 cross-platform 개발 등의 기능이 호평을 받았다
• VS 2022는, VS 2019나 VS Code 만큼 좋고 상당히 매력적인 몇가지 개선 사항을 제공한다

VS 2022에서 가장 중요한 개선사항

• VS 2022 주요 개선사항중 하나는 VS 2019에서 지속적으로 불만이 제기된 - 즉(namely), intense demand on memory 입니다
• 대량의 computing power를 요구하는 복잡한 어플리케이션을 개발하는 개발자에게 이 개선사항은 대단한 이점을 약속한다
• 이것은 상업용 또는 산업용 프로젝트에서 일하는 개발자의 (일반적인) 주요 관심사이다
• 이 글을 쓰는 시점에는 프리뷰 버전은 production application에는 license 되지 않았다

VS 2022 버전의 다른 신규 사항들

• Microsoft online documentation의 VS 2022 로드맵 페이지 에서 주장하는 내용
  • 이번 최신 배포를 작업하는 팀이 다음과 같은 주제를 염두에 두었다
  • “개인및 팀 생산성, 모던 개발및 지속적인 혁신”
• 매우 좋은 소리처럼 들리지만, 이 언급이 VS 2022를 사용하면서 실제로 어떻게 반영된다는 것일까?
• VS 2022 는 아래와 같은 추가적인 개선사항을 약속한다

개선된 코드 자동 완성 (Code-Completion) 기능

더 강력해진 디버깅 역량

개선된 프로그래밍 인터페이스

개선된 접근성

C++ 최신 빌드에 대한 개선된 지원

개선된 Windows App 개발

VS 2022 로 지금 업그레이드 해야할까?

• 대답은 당신이 지금 당장 VS를 어떻게 사용하고 있는지에 달려있다
• 안타깝게도, VS 2022 Preview 버전은 글쓰는 시점(2021-09-02)에서는 제품 개발에 사용할 수는 없다
• 주로 containerized application으로 작업하는 사람들은 preview 버전으로 시도해보기 전에 약속된 추가 개선사항이 적용될 때까지 기다리길 원할 것이다
• 능숙한 솔로 개발자는 VS 2022에서 제공되는 개선 사항의 이점을 누릴수 있고,
  • 정식버전이 배포되기전에 신규로 개선되는 기능에 익숙해지길 원할것이다
• 업그레이드 하기로 결정했다면, VS 2022 Preview 이용하는 몇가지 옵션방법이 있다
  • 가장 쉬운 방법은 현재 사용중인 VS 2019와 나란히 VS 2022를 설치하는 것이다
    • 로컬 머신에 설치하기 싫다면 cloud-based 버전를 시도해볼 수도 있다.
    • 아니면 command-line에서 작업할 수도있다

SETUPTOOlS의 “Development Mode” 번역

• 사족, 번역 기록은 남기는 것은 사실 세심히 읽었음을 기록으로 남기기 위함이다.
  • 이렇게 남기지 않으면 대충 읽기 때문에..
  • 때문에 번역이 애매한 단어는 그냥 영어로 그대로 두자
  • 오르막 길을 오를때는 목표점은 보지말고 그냥 내 발을 어느 위치에 둘 지만 생각하자
  • 첫번째 발위치가 익숙해지면 그제서야 두번째 발 위치를 생각할 여유가 생길것이다. Bootstrapping..

• 원본 : Development Mode, setuptools.pypa.io

• 일반적인 환경에서, distutils는, “raw”나 “unbuilt” form이 아닌, 당신의 프로젝트의 distribution 을 빌드할 것으로 가정한다
  • 하지만, 만약 당신이 distutils를 distribution에 사용하려고 한다면, 당신은 당신의 프로젝트를 개발 기간동안 변경할 때마다 매번 rebuild 하거나 reinstall해야 할 것이다
• 당신이 두 개의 관련된 프로젝트를 동시에 개발할 필요가 있을 때, 때때로 distutils가 문제가 될 때도 있습니다.
  • 양쪽의 프로젝트 패키지를 같은 디렉토리에 넣고 실행해야할 필요가 있는데, revision control 목적으로 두 프로젝트간 분리를 유지할 필요가 있을 수 있다
  • 이 문제를 어떻게 해결할 수 있을까?
• Setuptools를 사용하면, 파일을 복사하지 않고 common directory나 staging area 에서 사용할 프로젝트를 배포(deploy)할 수 있다
  • 따라서, 각 프로젝트의 코드를 그 프로젝트의 체크아웃 디렉토리에서 편집할 수 있으며
  • 프로젝트의 C extenstion이나 유사하게 컴파일된 파일을 변경할때만 빌드 명령을 실행하면 된다
  • 심지어 당신이 원한다면 다른 프로젝트의 checkout directory에 당신의 프로젝트를 배포할 수도 있다
    • 이 방식은 공통의 독립적인 stagin area나 site-packages directory를 이용하는 것과는 반대인 경우다
• 이것을 이용하려면, setup.py develop 명령을 이용해라.
  • setup.py install과 매우 유사하게 동작하지만, 이 명령은 실제로 아무것도 설치하지 않는다
  • 대신, development directory에 특별한 .egg-link 파일을 생성하는데, 이 파일은 당신의 프로젝트 소스코드에 연결된다
  • 그리고, 당신의 development directory가 Python의 site-packages directory라면, (이 명령은) 당신 프로젝트의 소스 코드를 include하도록 easy-install.pth 파일도 업데이트 하므로 해당 Python 설치를 사용하는 모든 프로그램의 sys.path에서 사용할수 있도록 한다
• 게다가, develop 명령은, 모든 install_requires 패키지가 sys.path에서 사용가능 한것이 확인된후에, 당신의 in-development 스크립트를 실행할 wrapper 스크립트를 target script directory에 생성한다
• 당신은 같은 프로젝트를 다중 staging 영역들에 배포할수 있다. 즉, 같은 machine에 당신이 개발을 진행중인 같은 프로젝트를 공유하는 다중 프로젝트 있을 경우에 이용한다
• 당신이 주어진 개발 task를 완료했다면, 프로젝트 소스를 staging area로 부터 제거할 수 있다.
  • setup.py develop --uninstall을 이용하라
  • 대상 staging area가 default가 아니라면 원하는 staging area를 선택해야 한다
• develop 명령의 정확한 behavior 조정을 위한 몇가지 옵션이 있다; 자세한 사항은 아래 develop 명령 section을 확인하라
• 아래와 같은 방식으로, non-setuptools 프로젝트에 setuptools 명령을 적용할수있다.

  
  1
  
  > python -c "import setuptools; with open('setup.py') as f: exec(compile(f.read(), 'setup.py', 'exec'))" develop
  
  

• 다시 말하면, 단순하게 일반적인 setup 명령과 옵션들을 따옴표안에 나열하면 된다

번역 - Sytax highlight with Rouge in Jekyll, frankindev.com

• 부제 : better styling the code blocks
• updated: 2021.02.06

Overview

• Jekyll 3 이후로 Rouge가 default code highlighter 이고
  • 100% Ruby로 구현된 100개의 언어를 지원하는 code highlighter
  • Python 계열 syntax highlighter인 Pygments의 stylesheets와 호환되어 Pygments themes를 사용가능

Install Rouge

Theme and colour

Implement

Example

Alternative Themes

Conclusion

Sass

• 위키작성시 사용하는 fenced code block의 syntax highlighting이 생각하는 대로 나오지 않는 것을 발견했다
• Jekyll은 Code snippet highlighting에 Rouge Ruby Gem를 사용한다
• rouge에서 사용하는 syntax highlight 설정이 _sass 폴더의 _syntax.scss 내의 .highlight 설정에 관련이 있다는 것을 알아내었다
• 그러니까, sass를 한 번 알아보자

참고할 링크

• jekyll > assets > Sass
• Sass Documentation, sass-lang.com
  • Sass Tutorial, sass-lang.com

Documentation 개요

• Sass는 CSS로 컴파일되는 stylesheet 언어이다
• fully CSS 호환되는 구문으로 variables, nested rules, mixins, functions 등등을 사용할 수 있다
• Sass 는 큰 스타일시트를 잘 정리하는데 도움을 준다
  • 또한 프로젝트 내부및 프로젝트 간에 디자인을 쉽게 공유할 수 있게 해준다

Sass Basics

• Sass를 사용하기전에 , 당신의 프로젝트에 먼저 설정을 해야 한다
• 이곳에서 그냥 브라우징만 해도 되지만, 일단 Sass 를 먼저 설치하는 것을 권장한다
• 셋업하는 방법을 알고 싶다면 이 페이지로 가라

Preprocessing

• CSS는 점점 더 커지고 복잡해진다.
• 자체 문법만으로는 한계가 있으며..
  • nesting, mixins, inheritance등 다른 niftygoodies가 필요해진다
• 전처리된 Sass 파일은 normal CSS로 저장된다
• Sass를 이용하는 가장 직접적인 방법은 terminal을 이용하는 것이다
  • Sass를 설치한 후 sass command로 Sass 파일을 CSS 파일로 컴파일할 수 있다
  • 디렉토리나 파일을 지정해 --watch 플래그를 써서 변경 즉시 자동 컴파일 되도록 할 수 있다
    • 아래 두 번째 예에서 colon 앞쪽은 input 폴더, 뒷쪽은 output 폴더이다

      
      1
      2
      
      > sass --watch input.scss output.css
      > sass --watch app/sass:public/stylesheets
      
      

Variables

• 변수를 “스타일시트에서 재사용 하려는 정보를 저장하는 방법”이라고 생각해라
• colors, font stacks등 당신이 생각하는 어떤 CSS 값이라도 저장해놓고 재사용할 수 있다
• Sass 는 변수를 만들기 위해 $ 심볼을 사용한다

1
2
3
4
5
6
7
8

/* sass file */
$font-stack: Helvetica, sans-serif;
$primary-color: #333;

body {
  font: 100% $font-stack;
  color: $primary-color;
}

1
2
3
4
5

/* css file */
body {
  font: 100% Helvetica, sans-serif;
  color: #333;
}

• 위의 Sass 파일이 처리되면
  • $font-stack과 $primary-color를 받아서 일반적인 CSS 형태로 값을 대체하여 출력한다
• 이 기능은 brand color 작업으로 사이트에 통일성을 주고자 할 때 유용하다

Nesting

Partials

• 부품 Sass 파일을 만들 수 있다
  • little snippets of css 가 포함된다
  • 다른 Sass file에 포함되도록 할 수 있다
• 이 특성은 CSS를 모듈화 하는데 좋고, 유지보수를 쉽게 만들어 준다
• 사용법
  • partial은 파일접두사로 _ 를 사용하는 Sass file 이다
  • 예를 들면, _partial.scss와 같이 이름지을 수 있다
  • _가 붙어 있으면 Sass 컴파일러가 partial임 인식하여 별도의 CSS file로 생성하지 않는다
  • Sass partial은 @use 규칙으로 사용된다

Modules

• 다른 섹션과 달리 호환성 표시가 있다
  • Dart Sass 는 1.23.0 부터 지원
  • LiSass , Ruby Sass 는 지원하지 않음
  • 오직 Dart Sass만이 @use를 지원한다
  • 다른 implementation 사용자들은 @import rule을 사용할 것
• 모든 Sass 코드를 하나의 파일에 작성할 필요가 없다
  • @use rule을 이용해 원하는 만큼 분리하여 작성할 수 있다
  • 이 rule은 다른 Sass 파일을 module로 로드한다
    • 즉, variables, mixins, functions등을 Sass 파일에서 참조할 때
    • 파일명에 기반한 namespace로 이용할 수 있다

Mixins

• CSS의 어떤 것들을 모두 써주기 귀찮다. 특별히 CSS3와 많은 vendor prefixes가 존재할 때 특히 그렇다
• mixin을 사용하면 사이트 전체에서 재사용하려는 CSS declarations 그룹을 만들 수 있다
• 이것을 당산이 Sass를 매우 DRY( Don’t Repeat Yourself)하게 유지되도록 돕는다
• 당신은 심지어 값을 넘겨 mixin을 매우 flexible하게 할수도 있다
• 여기 예제가 있다

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

  /* sass file */
  @mixin theme($theme: DarkGray) {
    background: $theme;
    box-shadow: 0 0 1px rgba($theme, .25);
    color: #fff;
  }
  
  .info {
    @include theme;
  }
  .alert {
    @include theme($theme: DarkRed);
  }
  .success {
    @include theme($theme: DarkGreen);
  }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

  /* css file */
  .info {
    background: DarkGray;
    box-shadow: 0 0 1px rgba(169, 169, 169, 0.25);
    color: #fff;
  }
  .alert {
    background: DarkRed;
    box-shadow: 0 0 1px rgba(130, 0, 0, 0.25);
    color: #fff;
  }
  .success {
    background: DarkGreen;
    box-shadow: 0 0 1px rgba(0, 100, 0, 0.25);
    color: #fff;
  }

• mixin을 사용하려면..
  • @mixin directive를 사용하고 이름을 부여하라
• 우리의 mixin에게 theme이란 이름을 지었다
  • 또한 $theme 변수를 넘겨주어 원하는 설정을 넘길수 있도록 하였다
• mixin을 생성한 다음에는 다음과 같이 사용할 수 있다
  • @include로 시작하고 mixin 이름이 뒤에오는 CSS declaration으로 사용할 수 있다