To make it easy for you to get started with GitLab, here's a list of recommended next steps.
지난학기 시스템 프로그래밍 실습에 대해 수강하였었다. 시스템 프로그래밍 실습에서 라즈베리파이 실습을 진행하였는데 이때 비슷한 마이크로 컨트롤러인 아두이노에 대한 내용이 자주 생각이 났었다. 라즈베리파이의 경우 전공 필수 수업으로 다룰 수 있으나 라즈베리 파이의 경우 기기가 비싸 항상 회로를 연결할때마다 혹시 합선이 되어 기기가 고장나면 어떡하지라는 생각을 하였다.
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)!
아두이노를 더 잘 사용했다면 자신감 있게 회로를 구성할 수 잇지 않았을까 라는 생각을 하였고 아두이노에 대해 기초적인 내용을 잘 안다 센서에 대한 기본적인 지식을 습득하고 회로에 대한 지식을 습ㅂ득하면 좋을것 같아 만들게 되었다.
## Add your files
## 프로젝트 과정에서 고려한 점
### 시뮬레이션
-[ ] [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
-[ ] [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:
평소 아두이노를 사용할때 직접 보드와 점퍼케이블, 센서를 이용하여 회로를 작성하였다. 그러나 이번 튜토리얼을 만들때 케이블을 연결하고 센서를 연결하는 과정을 하나하나 보여주기 어려울것 같아 어떻게 하면 좋을지 생각하게 되었다.
아두이노를 실행할 수 있는 시뮬레이터를 찾아보던 중 AUTODESK사의 Tinkercad라는 사이트를 알게되어 시뮬레이터로 시연을 하면 좋을것 같다고 생각하였다.
다양한 센서, 모터, 마이크로 컨트롤러 가 존재하기 때문에 혹시나 실물 컨트롤러가 없어도 간단한 시뮬레이션을 위해서 사용하기 좋았다.
라이브러리를 설치하고 활용하는 과정을 자세히 적어야 할지 고민되었다. 라이브러리를 통한다면 더 다양한 실습이 가능하고 실제 시제품에서 활용할만한 센서를 다양하게 사용가능하다.
하지만 기본적인 튜토리얼상 ide의 구성요소와 간단한 실습을 진행하게 되면 시간이 부족할것 같아 간단히 설치 방법에 대해서만 설명을 적었다.
설명을 작성한 이유는 실제 학원에서 센서를 활용할때 라이브러리 설치 방법을 헷갈린 경우가 많았고 사용자 라이브러리의 경우 설치를 잘 못하는 모습은 본적이 있어 추가하면 좋을것이라 생각하였다.
## Integrate with your tools
### 아두이노 문법
사실 아두이노 문법은 정말 다양한 문법, 함수들이 존재한다. 그러나 기본적인 `if``for`와 같은 c문법의 경우 설명해줄 필요가 없다고 느꼈고 대신 `pinMode`, `digitalWrite`와 같이 이후 실습에 꼭 필요하고 자주 쓰이는 요소만 설명할수 있도록 하였다.
-[ ] [Set up project integrations](https://git.ajou.ac.kr/yujinlee/foss-2024-2-final/-/settings/integrations)
## Collaborate with your team
-[ ] [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.
## 느낀점
프로젝트를 하면서 내가 알던 아두이노에 대해 더 자세하게 찾아보고 문법에 대해 설명하고 시뮬레이션으로 회로도를 그려보면서 두렵지 않게 회로를 그려볼 수 있었다.
시뮬레이션에서 처음 회로를 그렸을 때 led가 터지는 액션이 발생했는데 만약 실제로 연결한 과정에서 led에 불이 들어오지 않았다면 당황했을것 같다. 시뮬레이션을 통해서 한번 코드를 확인하고 회로를점검하는 과정을 통해 앞으로도 이 시뮬레이션으로 회로를 한번 점검하는 습관을 들일 수 있을것 같다.
