githru / githru-boot Goto Github PK

preliminary dev repo

HTML 5.71% TypeScript 86.48% CSS 3.20% JavaScript 4.56% Shell 0.04%

githru-boot's Introduction

Githru

Visual Analytics for Understanding Software Development History Through Git Metadata Analysis

Githru is an interactive visual analytics system that enables developers to effectively understand the context of development history through the interactive exploration of Git metadata. We design an interactive visual encoding idiom to represent a large Git graph in a scalable manner while preserving the topological structures in the Git graph.

To enable scalable exploration of a large Git commit graph, we propose novel techniques (graph reconstruction, clustering, and Context-Preserving Squash Merge (CSM) methods) to abstract a large-scale Git commit graph. Based on these Git commit graph abstraction techniques, Githru provides an interactive summary view to help users gain an overview of the development history and a comparison view in which users can compare different clusters of commits.

Demo

Visit our Demo page!!

References

Youngtaek Kim, Jaeyoung Kim, Hyeon Jeon, Young-Ho Kim, Hyunjoo Song, Bohyoung Kim, and Jinwook Seo, "Githru: Visual Analytics for Understanding Software Development History Through Git Metadata Analysis", IEEE VIS 2020 (VAST)

IEEE
arXiv

Apply to your repo!!

TBD

Video Preview

TBD

Citation

bibtex

@ARTICLE{kim2021tvcg,
  author={Kim, Youngtaek and Kim, Jaeyoung and Jeon, Hyeon and Kim, Young-Ho and Song, Hyunjoo and Kim, Bohyoung and Seo, Jinwook},
  journal={IEEE Transactions on Visualization and Computer Graphics}, 
  title={Githru: Visual Analytics for Understanding Software Development History Through Git Metadata Analysis}, 
  year={2021},
  volume={27},
  number={2},
  pages={656-666},
  doi={10.1109/TVCG.2020.3030414}}

Install and Run

git clone https://github.com/githru/githru.git
cd frontend
npm i
npm start

visit

githru-boot's People

Contributors

Stargazers

Watchers

githru-boot's Issues

데이터 조인 메소드 data() vs datum (D3.js)

         # data() vs datum()

datum() 작성 이유

dautm이랑 비슷한 역할을 하는 데이터 조인 메소드라하면 data 나 enter 정도가 있을 것 같은데요!
enter는 새롭게 데이터를 입힐 때 사용하는것이니 제외하면 data랑 비교가 될 것 같습니다!
일단은 path를 그려줄 때는 datum을 사용해주는게 좋다고 구글링하다가 알게되었습니다.

data() vs datum

대상 요소에 datum()은 단일 데이터/그룹을 연결해주는 것이고 data는 데이터 세트를 연결해주기 때문에,
현재 data의 구조가 array하나로 이루어져있어서 datum을 써줬습니다.
아마 현재 구조에서 data()를 써주려면은 파라미터값이
data(data)가 아니라 data([data]) 이렇게 여러 요소를 포함한 배열의 형식으로 보내주는 형태가 될 것 같습니다.
data vs data

data()를 사용해주려면 다음과 같은 코드가 될 것 같습니다!

data()를 사용했을 때 코드

svg
      .selectAll("path")
      .data([data]) // Wrap data array in another array
      .join("path")
      .transition()
      .duration(1000)
      .attr("fill", "none")
      .attr("stroke", crimeTypeColors[currentCrimeType])
      .attr("stroke-width", 1.5)
      .attr("d", line);

datum()를 사용했을 때 코드 ( 기존 )

 svg
        .append("path")
        .datum(data)
        .transition()
        .duration(1000)
        .attr("fill", "none")
        .attr("stroke", crimeTypeColors[currentCrimeType])
        .attr("stroke-width", 1.5)
        .attr("d", line);

Originally posted by @bishoe01 in #74 (comment)

Feature별 모듈 구현 실습 공지 (7/21/2022)

Feature별 모듈 구현 실습 공지 나갑니다.

팀	과제 이름	input	output	주요기능
A	crawler	Repository 이름	PR 정보(json)	GitHub의 PR 전체 List 및 PR 별 정보 가져와서 json으로 만들기
A	parser	git log 명령어를 이용하여 생성된 문자열들	githru에서 보여지는 필요정보들 (파일 별 수정/삭제된 라인 수 포함, json)	git log 명령어로 콘솔에 찍은 내용을 json으로 만들기
B	linechart	복수개의 시계열 데이터셋 (3개 이상)	D3로 생성된 Line Chart	데이터셋을 선택하면, 그에 따라 차트가 변경
B	icicle	File별 변경 라인 수 (full path)	D3로 생성된 File Icicle Tree	githru에 있는 file icicle tree 형태로 구현 (depth 4)

스펙

Typescript로 합니다.
README.md에는 본인 코드에 대한 설명(자유롭게. 설계, 요구사항, feature, 사용법 등등)을 넣습니다.
D3의 경우 TS로 짜기에 난이도가 조금 있다고 생각이 들면 우선 ts-ignore 처리하셔도 됩니다 (연습과제 때만).
데이터로 사용되는 repository나 chart data는 팀별로 통일할 수 있도록 논의하여 결정해주셔야 합니다.

혹시나 여유가 된다면

(모두) Test Case를 만들어주세요 (jest 이용).
(A팀) Crawler돌릴 때 API의 허용량을 초과하지 않으면서 계속 긁어오는 부분도 구현해보세요.
(A팀) 파싱된 log를 commit을 node로 가지는 tree 형태의 구조체로 만들어 보세요.
(B팀) async로 구현해보세요 (특히 UI/UX 쪽).
(B팀) transition을 넣어보세요.

과제 관련해서

속한 팀에서 하나를 고릅니다.
과제 2개를 하는 것보다는 코드 리뷰를 많이 하는 걸 권장합니다.
[project명] / [id] / 폴더 안에 본인의 코드를 넣어주세요.
마지막 날에 코드를 왕창 다 올리지 마시고, 쪼개서 자주 올려주세요.
Issue, Wiki 모두 자유롭게 활용가능합니다. 단 프로젝트 이름으로 말머리를 달아주세요. (예: [icicle] 적합한 색상은 무엇일까요?)

협업은

팀 혹은 과제별로 논의해서 같이 설계를 해도 되고, 개별로 해도 됩니다.
리뷰는 기본적으로 GitHub을 활용하지만, 온라인/오프라인 리뷰 형식으로 따로 하는 것도 좋습니다.
A2, B3에 속한 분들은 공지한 대로 과제 수행보다 리뷰쪽에 무게를 두시면 감사하겠습니다.

리뷰

리뷰는 팀 상관없이 모두 상호 리뷰 가능합니다.
리뷰어의 Approval이 2개 이상 있어야 PR의 Merge가 가능하게 셋팅해놓았습니다.
불필요하게 보일 수는 있겠지만, 그래도 커멘트의 서두를 칭찬으로 만들어봅시다 :-).
질문 적극 권장합니다. 토론의 장으로 번지는 것 환영합니다.

Pull Request

PR Description을 최대한 상세하게 써주세요.
Commit Message는 말머리를 가집니다 (https://www.conventionalcommits.org/en/v1.0.0/).
fix, feat, chore, refactor, 등의 header를 사용하시면 됩니다. (예-> feat: line 그리는 모듈)
개인 repo에 fork 한 다음에 main에 올려주세요. 현재 repo는 main 브랜치만 운영하겠습니다.
리뷰어를 위해서라도 가급적 적은 단위로 올려주세요. 200줄 내외를 권장(필수는 아님)합니다.
리팩토링이 아닌 새로운 feature인데 loc(line of code)가 크면, 리뷰어가 힘들어 합니다.
개발중이더라도, 올리는 코드가 build fail이 나면 안됩니다.

실습의 목적이 아래와 같음을 인지하시고, 화이팅입니다!

GitHub과 친해지기
팀원들과 친해지기
코드리뷰에 익숙해지기
Githru 맛보기

package-lock.json의 gitignore 처리에 관하여

Full context는
#2 를 참고해주세요~.

네 좋은 의견 주셨네요.
package-lock.json은 말씀처럼 version명시 및 디펜던시 트리 구조를 확인하기 위해서도 gitignore 처리하지 않는 것이 맞습니다.
사실 이부분은 특정 상황을 제외하고 명확하게 결정이 난 부분이 있습니다. 하단의 레포가 package-lock.json에 대한 부분이 없거든요.

다만 현재 레포가 모노레포가 아니지만 :id로 구분지어지는 폴더 하위에서 각각 실행이 되어야 하는 구조기 때문에 루트에서 :id폴더 하위에 노드 모듈을 사용하기 위해서 npm install을 할 일이 없다고 판단했습니다.
이에 더해서 짧은 package.json 대비 긴 package-lock.json이 diff에 남는게 부담스럽기도 했네요.

그러나 버전 픽스의 경우는 말씀처럼 package-lock.json을 포함시키지 않는 것으로 유지가 가능하지만 핀트가 어긋난 것으로 보입니다.
Tilde와 Caret Ranges를 잘 사용하는게 정답으로 보입니다.

또한 package-lock.json을 포함시키지 않더라도 CI는 clean and install, npm ci를 사용하는 파이프라인이 일반적이라..

https://docs.github.com/en/actions/using-workflows/about-workflows?learn=getting_started&learnProduct=actions#using-databases-and-service-containers

package-lock.json을 클리어하고 npm install하는 경우는 CI 환경과의 간극이 계속 커져버리는 상황에는 자유로울 수 없습니다.
그 반대로 package-lock.json을 계속 유지한 상태의 npm ci하는 경우는 write권한이 없기 때문에 같은 환경을 유지 할 수 있습니다.

npm ci를 하는 것으로 기대할 수 있는 장점은 다음과 같은 것들이 있는데요,

npm ci 가 더 빠르다.
(package-lock.json 파일을 지속적으로 버전 업데이트 한다면) CI입장에서는 npm ci를 사용하는 것으로 npm install을 사용했을 때 발생하는 package.json과 package-lock.json의 동기화 행위에서 발생할 수 있는 문제에 대해서 자유롭고 모듈상위 버전이 상위 호환성을 제공한다는 SemVer 규약을 신뢰한다는 기정 하에 같은 기능이 성능적으로 개선된 모듈을 사용할 수 있다.

2의 경우는 npm의 이상적인 목표인데 사실 그렇지 않다는 걸 많은 분들이 경험해 봤을 것 같네요.
최근에도 단편적으로 http-errors가 버전 2점대로 올라가면서 express와 충돌을 일으킨 경우도 있으니까요.

그렇다 하더라도 개인적으로는 언제나 2의 순기능을 믿고 있습니다. 😄

Originally posted by @ansrlm in #2 (comment)

Feature 구현 Guide (7/11/2023)

Feature별 모듈 구현

팀	과제 이름	input	output	주요기능
vscode	lsp	-	LSP 서버를 띄우고, 메시지를 받아서 console에 출력	LSP(Language Server Protocol)로 간단한 API 호출 뼈대 생성
engine	commit-classifier	commit message list	commit 별 분류 결과	Keyword를 이용한 commit 분류 구분 모듈 (참고자료)
engine	statistics	repo-url	author 별 PR, Review, Review Comment의 통계	author별 PR, Review 통계 수집 모듈: Octopus API 활용
view	linechart	복수개의 시계열 데이터셋 (3개 이상)	D3로 생성된 Line or Bar Chart	데이터셋을 선택하면, 그에 따라 차트가 변경

스펙

Typescript로 합니다.
README.md에는 본인 소개 및 코드에 대한 설명(자유롭게. 설계, 요구사항, feature, 사용법 등등)을 넣습니다.
D3의 경우 TS로 짜기에 난이도가 조금 있다고 생각이 들면 우선 ts-ignore 처리하셔도 됩니다 (연습과제 때만).
혹시나 여유가 된다면 Test Case를 만들어주세요 (jest 이용).

과제 관련해서

속한 팀에서 하나를 고릅니다.
과제 2개를 하는 것보다는 코드 리뷰를 많이 하는 걸 권장합니다.
[project명] / [id] / 폴더 안에 본인의 코드를 넣어주세요.
마지막 날에 코드를 왕창 다 올리지 마시고, 쪼개서 자주 올려주세요.
Issue, Wiki 모두 자유롭게 활용가능합니다. 단 프로젝트 이름으로 말머리를 달아주세요. (예: [icicle] 적합한 색상은 무엇일까요?)

그리고,

팀 혹은 과제별로 논의해서 같이 설계를 해도 되고, 개별로 해도 됩니다.
리뷰를 많이 많이 신경써주세요.
feature practice 없이 Contribution을 바로 시작해도 좋습니다. (Discord에 먼저 알려주세요!)

리뷰

리뷰는 팀 상관없이 모두 상호 리뷰 가능합니다.
리뷰어의 Approval이 2개 이상 있어야 PR의 Merge가 가능하게 셋팅해놓았습니다.
불필요하게 보일 수는 있겠지만, 그래도 커멘트의 서두를 칭찬으로 만들어봅시다 :-).
질문 적극 권장합니다. 토론의 장으로 번지는 것 환영합니다.

Pull Request

PR Description을 최대한 상세하게 써주세요.
Commit Message는 말머리를 가집니다 (https://www.conventionalcommits.org/en/v1.0.0/).
fix, feat, chore, refactor, 등의 header를 사용하시면 됩니다. (예-> feat: line 그리는 모듈)
개인 repo에 fork 한 다음에 main에 올려주세요. 현재 repo는 main 브랜치만 운영하겠습니다.
리뷰어를 위해서라도 가급적 적은 단위로 올려주세요. 200줄 내외를 권장(필수는 아님)합니다.
리팩토링이 아닌 새로운 feature인데 loc(line of code)가 크면, 리뷰어가 힘들어 합니다.
개발중이더라도, 올리는 코드가 build fail이 나면 안됩니다.

실습의 목적이 아래와 같음을 인지하시고, 화이팅입니다!

GitHub과 친해지기
팀원들과 친해지기
코드리뷰에 익숙해지기
Githru 맛보기

[etc.] Author와 Committer의 차이

작일 온라인 미팅 중 궁금한 부분이 생겨 슬쩍 찾아보다가 흥미로운 반례를 발견하여 공유합니다.

보통의 경우라면 Author와 Committer는 동일하지만,

Github GUI에서 직접 작업하여 commit한 경우는 committer가 github로 할당됩니다.

별 건 아니지만... 그래도 다른 경우를 찾기 힘든 것 같아서 공유합니다! 🤸‍♂️

혹시나 다른 경우를 찾게 되신다면 또 공유부탁드립니다.

pnpm 관련

안녕하세요! 반갑습니다 :)
말씀해주신 바와 같이 저는 이번 과제의 패키지 매니저로 npm이나 yarn 대신 pnpm을 사용하였습니다. 만일 본 프로젝트를 실행하고자 하는 분들이 계시다면 (1) pnpm i로 프로젝트에 사용되는 dependencies 및 devDependencies 를 설치하고 (2) pnpm dev로 실행해주시면 됩니다! pnpm의 명령어는 기본적으로 다른 패키지 매니저와 크게 다르지 않은 편이라 사용에 별다른 어려움은 없으실 거라 생각합니다 :)

혹시나 pnpm에 대해 간단히 소개받고(?) 싶은 분들이 있을까 하여 이번 질문을 기회삼아 다음과 같이 정리해 보았습니다: pnpm은 비교적 최근에 나온 패키지 매니저이며, 가장 자주 사용되고 있는 패키지 매니저인 npm이나 yarn보다 속도가 빠르고, (여러 프로젝트에서 사용될 수 있는) 동일한 버전의 dependencies를 중복 저장하지 않아 디스크 공간을 절약하고 효율성을 극대화한다는 점에서 두드러집니다.

pnpm의 제약 사항으로 공식문서에서 언급하는 부분은 다음과 같습니다. pnpm은 npm-shrinkwrap.json package-lock.json yarn.lock과 같이 다른 패키지 매니저를 사용할시 생성되는 lockfile을 기본적으로 무시합니다. 하지만 pnpm import를 사용하여 기존 lockfile을 pnpm-lock.yaml으로 새롭게 생성하고 사용할 수 있습니다. yarn에도 npm의 lockfile인 package-lock.json 파일을 yarn.lock으로 변환하는 yarn import가 있는 것과 비슷한 느낌입니다

참고로 pnpm에 대한 부분은 아니지만, 제가 구성한 개발환경을 사용하는 분이 계시다면- Vite에서 환경변수를 사용하실 경우 process.env 대신 import.meta.env를 써야 하며 변수명은 VITE_로 시작해야 한다는 점을 유의사항으로 전해드립니다! 저도 Vite와 pnpm을 이용한 프로젝트 구성은 처음인데, 이번 과제를 진행하며 기존 기술과 어떻게 다른지 살펴보고 그 경험을 공유해보겠습니다. 좋은 질문 감사합니다👍

Originally posted by @hyeda1103 in #7 (comment)

type이랑 implementation 변수 이름 앞에 T나 I에 대해서 어떻게 생각하는지 같이 얘기해보면 좋겠네요!

type이랑 implementation 변수 이름 앞에 T나 I에 대해서 어떻게 생각하는지 같이 얘기해보면 좋겠네요!
개인적으로는 prefix를 안 붙이거나 꼭 필요한 경우 Implementation이라고 suffix를 붙입니다.
(태생이 java 쪽이라서 그럴 수도 있...)

Originally posted by @ytaek in #18 (comment)