GIT 에서 관리중인 소스를 나만을 위한 변경 적용하기 (커밋은 안되게 하기) .gitignore -> git update-index –skip-worktree / git update-index –assume-unchanged

https://dev.to/nishina555/how-to-ignore-files-already-managed-with-git-locally-19oo#:~:text=git%20update%2Dindex%20%2D%2Dassume%2Dunchanged,-When%20to%20use&text=%2D%2Dassume%2Dunchanged%20is%20the,(or%20should%20not%20change).

를 참고 했다.

예를 들어서 어떤 프로젝트를 clone 후에 나만의 OS 환경에 맞게 소스를 수정해야만 하는 경우가 있다. 설정 파일의 위치나 불필요한 라이브러리 로딩을 생략하거나. 협업을 하는 경우 대부분의 로컬 개발자를 위한 소스는 분기 코드를 넣어서 서로 유용하게 공유하지만 쌩뚱맞은 실험이나 나만을 위한 설정을 커밋은 안 하고 유지하고 싶은 경우가 있다. 또는 나만의 비밀기능(?) 소스에 반영은 안하는 나만의 패스워드가 될 수 있겠다.

.gitignore 나 .git/config/exclude 는 managed 되고 있지 않은 소스 (커밋되지 않은) 신규 소스나 컴파일된 소스등 관리를 안 할 소스들에 대해서 변경건으로 감지 하지 말라고 하는 설정이다. 그래서 이번 경우에는 해당하지 않는다.

2가지 방법이 있다.

git update-index –skip-worktree
git update-index –assume-unchanged

2가지를 쓸 수 있다.

git update-index –skip-worktree path/file1 path/file2
git update-index –assume-unchanged path/file1 path/file2

2가지 다 스페이스로 구분된 파일 목록을 받아들일 수 있다.

git 이 “관리중인” 파일 목록은 git ls-files 로 볼 수 있는데 -v 를 붙이게 되면 어떤 방식으로 관리 하는지 나온다. skip 된 것은 S, unchanged 인것로 치라는 것은 h 가 헤더로 나온다.

차이점

비교skip-worktreeassume-unchanged
상황나만 변경 하는 부분
커밋되서는 안되는 변경 사항
변경을 하지 말아야 하는 파일들
변경이 되지 않았으면 하는 파일들
변경하지 않아도 되는 파일들
목적내가 수정은 했지만 다른 사람은 몰랐으면 하는 파일들웹서버 이미지 파일등, 내가 관심 없는 파일들, 업데이트가 되지 않아도 되는 파일들
부가상황업데이트 속도가 빨라진다.
누가 바꿔도 내 파일은 바뀌지 않는다.
기타Eclipse context menu 에서 지원

autohotkey 로 “onenote for windows 10” 실행하기 (UWP 프로그램 실행 경로 확인)

authohotkey 로 여러 프로그램을 실행하는데

run, ~~~.exe

경로를 단순히 실행하면 된다. 그런데 onenote for windows 10 의 실행경로는 도저히 알 수 없다.

앱별 기본값 설정 에서 UWP 앱에 대한 run 프로토콜을 확인할 수 있다.

확장자와 URL 에 따라서 onenote 가 실행되도록 정의 하고 있다.

나도 몰랐는데 시작 > 실행에 onenote 프로토콜이 이미 몇개 보인다.

https://stackoverflow.com/questions/40320037/launch-onenote-uwp-using-autohotkey 에 따르면 onenote 실행과 quick note는 다음의 명령으로 처리 가능하다.

# 실행
Run, onenote-cmd://
# 퀵노트
Run, onenote-cmd://quicknote?onOpen=typing

onenoteCLI 도 있다고 한다.

윈도우에서 전원 및 절전 설정을 재택근무용으로 세팅하기기

재택근무를 하면서 집 PC를 개인용에서 업무용으로 분리할 필요가 생겼다.

집 컴퓨터에 경우 공부를 하거나 영화를 보거나 게임을 하거나.. 대부분 완전히 집중해서 하거나 간혹하기 때문에 전원 옵션을 좀 타이트하게 주는 편이다. 2~3분만 안 만지면 꺼지도록 말이다.

그런데 코로나로 인해 집에서 업무를 하다보니 생각하면서 할 일이 많아지면서 컴퓨터가 꺼지지 말고 그냥 켜져 있어야 하는 시간이 많아졌다. 그래서 업무시간 중에는 전원 설정이 자동으로 바뀌면 좋겠다고 생각했다.

powercfg 를 통해 해당 시간을 조절할 수 있다.

매일 아침 9시에는 아래의 스크립트를 돌린다.

 powercfg /change monitor-timeout-ac 10
 powercfg /change standby-timeout-ac 45  

저녁에는 스케쥴을 원복한다.

powercfg /change monitor-timeout-ac 2
powercfg /change standbyA-timeout-ac 3

이 방법은 노트북을 사용할 때도 좋겠다는 생각이 든다. 평소에는 배터리 관리를 위해서 노트북을 켤 때 자동으로 짧은 시간으로 효율을 가져가게 하고 특별히 한번은 꺼지지 않기를 바라는 시간에는 길게 가져가는 스크립트를 호출하면 된다. 단 배터리 위에서의 설정은 배터리 시의 설정으로 해야 한다.

powercfg /change monitor-timeout-dc 2
powercfg /change standby-timeout-dc 3 

적절히 batch 파일을 만들어 로그인 시에는 무조건 tight 가 실행되도록 하고 이번에는 좀 long term 으로 가고 싶을 경우 윈도우 – loose 를 타이핑 하여 windows 10 이 잘 검색해서 실행 할 수 있도록 하였다.

빅데이터 세상으로 떠나는 간결한 안내서 NoSQL

기본개념

  • 1 왜 NoSQL인가?
    • 클러스터
    • 자유로운 필드 추가
    • 다중 저장소
      • 폴리글랏 프로그래밍 = 폴리글랏 Persistence
  • 2 집학적 데이터 모델
    • 집합 (agregate) – 복잡한 레코드의 모형
    • 원자적 업데이트
  • 3 데이터 모델 상세
    • 3.3. 스키마 없는 데이터베이스
      • 어떤 스키마를 만들지 미리 생각하는 것은 어렵다.
      • 데이터베이스에 스키마가 없을 뿐이지 그것을 사용하는 App 에는 결구 스키마가 정의 되어야 한다.
      • DB 에 제약이 없어 App 의 스키마 사용 부분을 중앙 통제 해야 한다.
        • DB 와의 상호작용을 웹서비스로 통합
      • 스키마 전환의 비용은 높다.
        • 집합 구조 비용은 낮으나 경계 구조 비용이 높다.
  • 3.4.  구체화 뷰 (Materized View)
    • 고객 안에 주문을 넣었는데 주문별로 또는 상품별로 보고 싶은 통계성 쿼리
    •  오라클에 있는 그 view 를 NoSQL 에서는 좀 더 본격적으로 쓴다.
  • 3.5. 데이터 접근을 위한 모델링 한글
  •  4 분산 모델
    • 리플레케이션 – 복제
      • 마스터-슬레이브
        • 읽기 복원력
      • 피어2피어
        • 쓰기
    • 샤딩 – 키 부분 파티셔닝
      • 다른 데이터
    • 단일서버
      • 그래프 DB – 관계
        • 지역별로 나눌 수는 있지만..
  • 5 일관성
    • CAP 정리
    • 비관적 동시성
      • Lock 사용 – deadlock 유발
    • 낙관적 방법
      • 충돌에 대한 적절한 대응
    • 비일관성 window
      • 2개 이상의 노드에 읽기 결과가 다른 경우
    • 버전 스템프
      • Guid – 어느게 새것인지 모름
      • Timestamp – time 에 대한 동기화 이슈
      • 카운터
        • Node 별 버전벡터
    • ACID (for RDB) -> BASE (for noSQL)
      • Basically Available
      • Soft State
      • Eventual consistency
  • 6 맵-리듀스

적용

DB 별 적절한 사용처

  • 8 키-값 데이터베이스
    • 레디스 주키를 이용한 접속
    • 세션, 사용자 프로파일, 설정, 장바구니 저장
    • 비추 – 데이터간 관계가 있을 때, 다중 연산 트렌젝션
  • 9 문서 DB
    • 몽고 DB
    • 데이터 복제가 자유로움, 서버 추가 삭제가 쉬움, 고가용성,
    • 추천 – 이벤트 로깅, 다양한 형태의 컨텐츠 저장, 웹 분석
    • 비추 – 연산이 복잡한 트렌젝션, 변화하는 집합 구조
      • RDB join 보다 조회 쿼리의 변경이 더 어려움
  • 10 칼럼 패밀리
    • 카산드라, H베이스
    • 표준 칼럼 – 컬럼 – 값
    • 슈퍼 칼럼 – 컬럼 – 컬럼의 맵을 값으로
  • 11 그래프 db
    • 네오4j
    • 관계 incoming / outgoing 에 대한 속성
    • 되도록 단일 node
    • 추천 – 라우팅, 디스패치, 위치기반, 추천엔진
    • 비추 – 각 엔티티를 업데이트 해야 하는 경우
  • 12 스키마 전환
    • 12.1 스키마 변경
      • noSQL은 도메인 설계에 주력할 수 있다.
    • 12.3 noSQL 데이터 저장소에서의 스키마 변경
      • RDB는 DB 먼저 변경,
      • Nosql은 DB 먼저 변경할 필요는 없다. 점증적 전환 또는 데이터에 버전을 담아 적절한 컨버팅 코드와 최신 버전으로의 집합 저장을 준비해야 한다.
    • 13 다중 저장소 지속성
    • 13.1 이종 데이터 저장소의 필요성
      • Polyglot persistence
    • 13.2 다중 데이터 저장소 사용
      • 세션, 장바구니 – keyvalue DB
      • 완료된 주문 – RDB
      • 고객 추천 – 그래프DB
    • 13.3 서비스를 통한 데이터 접근
      • 각 apps 가 여러 종류의 DB를 직접 핸들링 하는 것을 지양
      • 서비스로 감싸서 API 로 제공
    • 13.4 더 좋은 기능을 위한 확장
      • Ehcache 등 기존 레거시는 그대로 두고 캐시등 확장 가능
    • 13.6 다중 저장소 지속성 사용 시 고려사항
      • DBA 의 기술 스택
      • 기업에서의 고려사항
        • 업그레이드, 드라이버, 감사, 보안
        • ETL, BI 툴이 소스 시스템으로 지원하는지
    • 13.7 배포 복잡성
      • 개발 / 테스트 / QA 환경 구축
      • noSQL 은 대부분 쉽다. 압출풀고 curl 로 테스트
  • 14 NoSQL 을 넘어
    • 14.1 파일 시스템
      • 개인 문서 저장으로 널리 사용되는 DB!
      • 분산 파일 시스템 하둡
        • 대규모 클러스터링 분산 시스템
        • 빅데이터 분석에서 적극 활용 중
    • 14.1 이벤트 소싱
      • 모든 상태의 변화를 포착.
      • Historical database
      • 이벤트 로그로 데이터 재구성 가능
      • 처음부터 구성하기 어려우니 스냅샷 만들어
        • 그 이전 이벤트 로그 삭제 가능.
        • 이벤트를 수기 작성하여 다른 시나리고 대비 가능
  • 15 데이터베이스 선정
    • 15.1 프로그램 생산성
      • 관계형 DB의 불만, 집단으로 수집하고 표시하는 정보를 RDB 에 맞게 변환해야.
      • 현시대의 들쑥날쑥한 신규 필드들
      • RDB noSQL 어느것이 효율적인지 단정지을 수 없고  작업자의 의견에 귀 기울여야
    • 15.2 데이터 접근 성능
      • 수평 확장에 유리
      • 클라우드 컴퓨팅을 이용한 테스트 클러스터 구현 후 제대로된 테스트 필요
    • 15.3 관계형 데이터베이스 계속 사용하기
      • 개부분의 경우 현재 DB도 좋음.
    • 15.4 위험 분산
      • 데이터 매퍼, 리포지토리 패턴으로 DB 교체 가능성 열어둘 것.

Deployment projects (of Bamboo)

bamboo 의 Deployment projects 에 대한 문서를 번역해 본다.

What are deployment projects?

A deployment project in Bamboo is a container for holding the software project you are deploying: releases that have been built and tested, and the environments to which releases are deployed. Teams typically have QA, staging and production environments. 

Bamboo 의 deployment project 는 니가 배포하려는 개발 프로젝트, 니가 빌드하고 테스트한 releases, 그리고 releases 들이 배포될 environments 에 대한 container 이다.

Why use deployment projects?

Continuous Integration was not designed for Continuous Delivery. Continuous Integration is designed to keep developers informed about the state of the latest code changes.

CI는 CD를 위해 디자인 되지 않았다. CI는 개발자에게 마지막 코드 변경에 대한 상태 안내를 한다.

In Continuous Integration, historical build results (along with information such as issue and commits) are de-emphasized as more changes are made, since only the latest build is important to the developer.

CI 에서는 많은 변화에 비해서 빌드 결과 히스토리는 덜 중요하다. 개발자에게는 최신의 빌드만이 중요하기 때문이다.

Using a traditional Continuous Integration server for Continuous Delivery is less than ideal because:

기존에 CD를 지원하는 CI 서버는 좀 이상적이지 않다. 왜냐면..

  • Deployed builds are difficult to find – Builds that were deployed only a few days ago are de-emphasized by the system. While this is good for a Continuous Integration workflow, the behavior makes it difficult for team members to identify which builds have been deployed and when, versus which have not. Teams can work around this with a system that uses labeling but it’s not immediately obvious how it should work unless team members are trained to use it correctly.
    배포된 빌드는 찾기가 어렵다. – 몇일전에 배포된 builds는 시스템이 덜 강조한다. (추적이 어려워 진다는 뜻인 듯). CI 측면에서는 좋은 반면, 이것은 어떤 빌드가 언제 배포 되었으며 어떤 빌드는 배포 되지 않았는지 알기 어렵게 한다. 라벨링을 매기는 등으로 수동처리(?) 할 수 있지만 직관적이지는 않다.
  • Difficult to find what changes were made between deployments – Build results report commit and issue data between a specific build result and the one immediately before it. There can be many build results between two different deployments. Often the entire history has to be navigated between the two deployments to build a complete view of the changes between them. Sometimes, even other tools have to be used, such as version control systems.
    배포와 배포 사이에 어떤 변경이 만들어 졌는지 찾기 어렵다. – build 결과는 커밋과 이슈들의 특정 빌드과 그 직전 빌드의 차이를 알려준다. 그런대 2개의 배포 사이에는 더 많은 빌드가 있을 수 있다. 종종 VCS 등을 별도의 툴을 사용해 2개의 배포 사이의 모든 변경을 추적해야만 한다.
  • Difficult to know what was deployed, and when and where it was deployed – Builds do not have visibility of where code is deployed or what was previously deployed to an environment.
  • 무엇이 배포 되었는지 언제 어디서 배포 되었는지 찾기 어렵다. Builds 는 어디애 배포되었는지 알기 어렵고 직전 배포는 어디에 되었는지도 알기 어렵다.
  • Lack of insight into the QA process – Given a list of deployment candidates, builds offer no clear way (other than commenting or labeling) for QA to ‘sign off’ on a tested release or mark a release as broken or un-releasable.
    QA 프로세스를 위한 통찰력이 부족하다.
  • Poor control over who can deploy – While it can be controlled by permissions who can run, view or edit a build, they do not give enough fine grained control over which people in the team can deploy to production or other sensitive environments. In essence, if someone has permission to run the build they can deploy the software any time they wish.
    배포 권한 설정이 어려움 – 누가 배포 하고 배포 했음을 볼 수 있는지

To solve these issues Bamboo provides the following concepts:
이런저런 이유로 Bamboo 가 아랫것들을 제공한다.

  • Deployment project – Represents the software you are deploying (such as a web application), the releases of the software deployed and the environments that they will be deployed to throughout the lifecycle.
    Deployment project – 니가 배포 하고 있는 것 그 자체, 배포된 것들와 배포될 환경
  • Environment – Represents the servers or groups of servers where the software release has been deployed to, and the tasks that are needed for the deployment to work smoothly. Example environments could be named Development, QA, Staging or Production. Environments have permissions that allow fine grained control of who can deploy, edit or view an environment and record the full history of releases deployed to it.
    Environment  – 배포될 서버 그룹, 배포가 원활하게 진행되기 위해 필요한 작업들. 배포 환경은 Dev, QA, STG, PROD 가 될 수 있다. Environments 각 환경별로 배포 하기/보기 권한을 나눌 수 있다.
  • Release – Identifies a snapshot of artifacts and its associated data such as commits, Jira issues and the builds that were used to test it. As a release contains the information of the difference between itself and the release beforehand, it’s very easy to see the changes between releases or to show the difference between the software deployed on two different environments. Releases also track what environments they have been deployed to.
    Release – 특정 시점의 artifacts 스냅샷 그 자체 관련된 커밋과 이슈들. 릴리즈간의 차이점을 확인 하기 쉽게 해준다.

How do deployment projects work?

Consider the following diagram:
아래 그림 한번 봐봐라

Continuous Delivery is the practice where all changes made to a software project are automatically built, tested and made ready for deployment to users. In practice, once the project has been built and tested it is ‘staged’ somewhere where it can be manually verified and then made available to users.

Unlike Continuous Deployment (the process where code changes are automatically built, tested and deployed without human intervention), typically there is a decision made by a human being to whether or not the software is of sufficient quality or if it is the correct time for the business to make the software available to its users.

Continuous Delivery 와 Deployment 의 차이로, 배포 직전까지만 하느냐 배포까지 자동화 하느냐 용어 나누기를 하는 듯.

Artifacts

Create and test deployable artifacts with build plans. Ensure any artifacts you wish to deploy with Bamboo are flagged as “shared” to make them available to the deployment instructions of the environment.

build plans 으로 배포 가능한 artifacts 를 만들고 테스트 한다. Bamboo 통해서 배포되길 원하면 shared 설정이 되어야 한다.

Releases

Any artifact that has been successfully tested can be used to create a release; you can create as many releases as you like. Bamboo will add other metadata such as related commits and Jira issues to each release which enable reporting and tracking as it moves through your environments.

테스트된 artifact 라면 release 가 만들어지는데 사용될 수 있다. (테스트 끝난 artifact) Bamboo 는 release 에 Jira 이슈나 커밋을 관련짓는 메타를 만든다.

Environments

Environments in Bamboo reflect the development, testing and production environments in your IT infrastructure – hostnames and authentication credentials for each environment reside at the task level inside your deployment jobs. At any point in time, you will be able to see which release is running in each environment, which release it replaced, when it was deployed and who deployed it. You will also be able to see any associated Jira issues.

Bamboo 에서 Environments 는 당신네 개발, 테스팅, 운영환경을 말한다. hostname 각 배포를 위한 인증 키등. environments 별로 어떤 release 가 돌고 있는지 무엇이 교체될 것인지 언제 누가 배포 했는지 볼 수 있다.

NC 를 이용해서 네트워크 IP PORT 잘 되는지 체크 하는 방법 (telnet 안녕)

어느정도 보안이 관리되는 회사에서 서버를 열고 접속 하려고 하면, 접속하려는 PC 에서 접속이 안되는 경우가 많다.

그런데 이게 서버가 안 떠 있는 것인지 서버의 인바운드가 아직 안 열린건지 아니면 중간에 프록시라도 있으면 프록시가 안된건지 구간별로 포트 체크하는 방법이 깔끔하지 않다.

nc 를 이용하면 이러한 네트워크 연결 구간별 테스트를 깔끔하게 할 수 있다.

nc는 “서버”가 되기도 하고 “클라이언트” 가 되기도 한다. 그래서, 네트워크 관리자 입장에서는 아직 그 서버가 구동되어 있지 않더라도 가상의 서버을 열어 포트가 열려 있기는 한지 테스트 할 수 있다.

여기서는 10.1.1.1 서버가 8080 포트를 클라이언트에게 열어줘야 하는 경우를 예로 들어본다.

가상의 서버 열기

nc -lk 8080

이 명령어로 간단히 포트를 열 수 있다. nc 는 netcat 인데 프로그램이 설치 되어 있지 않다면 yum install nc 등으로 간단히 설치 할 수 있다.

클라이언트의 접속 테스트

보통의 경우 windows 에서는 telnet 10.1.1.1 8080 등으로 8080 포트가 열려 있는지를 테스트 할 수 있으나 nc for windows 등을 구해 놓으면 여러모로 편리하다.

nc -zv 10.1.1.1 8080 

왜냐면 nc 는 1개 이상의 포트를 스캐닝 하는 기능도 가지고 있다.

nc -zv 10.1.1.1 22-80

22번 포트부터 80포트까지 스캔

windows 10 에서 sendtokindle 을 설치해도 프린터 목록에 안 나올 때

kindle 로 인쇄시켜주는 앱. pdf 를 드래그 해도 되고 인쇄하면서 프린터를 send to kindle 로 선택해도 된다.

send to kindle app 은 send to onenote 와 비슷하게 윈도우에 설치하는 S/W 프린터이다. 해당 프린터로 인쇄를 하면 내 kindle 에 자동으로 저장되는 일종의 cloud printer 다.

언젠가부터 이 앱을 설치해도 프린터 목록에 안 나오는데 이는 send to kindle app의 호환성 때문으로 보인다.

send to kindle 앱의 호환성 개선

C:\Program Files (x86)\Amazon\SendToKindle

에서 sendtokindle.exe 의 호환성을 검사한다.

문제 해결사를 실행하면 해결이 된다. 이것에 되는 것은 처음으로 경험했다!!!

프린터를 수동으로 추가

이후 프린터가 보이는 것을 볼 수 있다.

설치가 완료되면 프린터를 선택할 수 있다.