# Open Source Software 도구를 교육하는 동영상 콘텐츠 제작 [SWTT] 보고서
## 주제: D3.js 튜토리얼 및 공공 데이터를 이용한 실습
## 1. 아이템 선정 동기
d3.js는 데이터 시각화 라이브러리로, 웹에서 복잡한 데이터를 효과적으로 시각화하는 데 매우 유용하다. 다양한 데이터 시각화 기술을 이해하고 활용할 수 있는 능력을 키우기 위해 d3.js를 선택하게 되었다. 특히, 실습을 통해 직접 코드 작성을 해보며 d3.js의 강력한 기능과 유연성을 체험해보고자 했으며, 다른 사람들에게도 공유를 하고자 했다.
또한, d3.js에 관한 자료들이 영어 위주였기 때문에, 한국어로 된 초보자 강의 영상이 있었으면 좋겠다고 생각했다.
## Getting started
## 2. 개발 과정에서 발생했던 문제점 및 해결 방법
### 문제점 1 : d3.js의 복잡한 문법
d3.js의 문법이 매우 유연하고 강력하지만, 처음 접하는 사람에게는 다소 복잡하게 느껴질 수 있다. 특히, 데이터 바인딩과 SVG 요소의 속성을 동적으로 설정하는 부분에서 어려움을 겪었다.
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
해결 방법:
d3.js의 공식 문서와 다양한 튜토리얼을 참고하여 기초 개념을 확립한 후, 예제 코드를 따라 작성해보면서 이해를 높였다. 또한, d3.js의 메서드 체이닝 방식에 익숙해지기 위해 다양한 실습을 통해 반복 학습을 하였다.
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
### 문제점 2: SVG 요소의 위치 및 크기 설정
SVG 요소를 정확하게 위치시키고 크기를 조정하는 것이 처음에는 어려웠다. 특히, x, y 좌표와 width, height 속성을 적절하게 설정하는 것이 중요했다.
## Add your files
해결 방법:
SVG 좌표계를 이해하고, 각 요소의 속성을 설정할 때 상대적 위치와 크기를 계산하는 연습을 했다. 또한, 브라우저의 개발자 도구를 활용하여 실시간으로 요소의 위치와 크기를 조정해보며 결과를 확인했다.
-[ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
## 3. 동영상 제작 과정
-[ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
### 1. D3.js 소개 및 SVG 설명 및 실습
-`svgtest.html`
-**내용:** D3.js 소개와 SVG 기본 요소인 rect, circle, line, polygon 등을 설명하고 실습.
-**학습 목표:** D3.js와 SVG의 기본 개념을 이해하고, 간단한 SVG 요소를 활용하여 기본 도형을 그려보는 것을 목표로 하했다.
-**내용:** 데이터 배열을 바인딩하고, 각 데이터 요소에 대해 rect 요소를 추가하여 그래프를 구성. 각 막대는 데이터 값에 따라 위치와 크기가 결정됨을 설명하고 실습
git branch -M main
-**학습 목표:** 데이터 바인딩과 rect 요소를 활용하여 막대 그래프를 구현하는 방법을 익히고, 데이터 시각화의 기본 개념을 이해하는 것을 목표로 했다.
git push -uf origin main
```
## Integrate with your tools
### 3. 산포도 그래프 구현 실습
-`scatter.html`
-**내용:** 데이터 배열을 바인딩하고, 각 데이터 요소에 대해 circle 요소를 추가하여 그래프를 구성. 각 점은 데이터 값에 따라 위치가 결정됩니다. x축과 y축을 설정하여 데이터의 범위를 시각적 표현함을 설명하고 실습
-**학습 목표:** 산포도 그래프를 구현하는 방법과 축 설정 방법을 익히고, 데이터를 시각적으로 표현하는 방법을 이해하는 것을 목표로 했다.
-[ ] [Set up project integrations](https://git.ajou.ac.kr/tinon1004/foss-2024-1-final/-/settings/integrations)
### 4. 공공데이터 이용한 막대 그래프 구현 및 지도 svg 사용 실습
-`car.html`, `map.html`
-**내용:** 공공 데이터를 활용하여 지역별 전기차 수를 막대 그래프와 지도로 시각화.
-**학습 목표:** 공공 데이터를 활용하여 실제 데이터를 시각화하는 방법을 익히고, 다양한 SVG 요소를 활용하여 지도를 표현하는 방법을 이해하는 것을 목표로 했다.
## Collaborate with your team
## 4. 참고 자료
- D3.js 공식 문서: https://d3js.org/
- 다양한 D3.js 튜토리얼과 예제 코드
-[ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
-[ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
-[ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
Use the built-in continuous integration in GitLab.
-[ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
-[ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
-[ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
-[ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
-[ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
***
# Editing this README
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
## Suggestions for a good README
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
## Name
Choose a self-explaining name for your project.
## Description
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
## Badges
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
## Visuals
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
## Installation
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
## Usage
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
## Support
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
## Roadmap
If you have ideas for releases in the future, it is a good idea to list them in the README.
## Contributing
State if you are open to contributions and what your requirements are for accepting them.
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
## Authors and acknowledgment
Show your appreciation to those who have contributed to the project.
## License
For open source projects, say how it is licensed.
## Project status
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
