To make it easy for you to get started with GitLab, here's a list of recommended next steps.
(2) Google Vision API
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)!
(3) Google Translation API
## Add your files
2. Google Cloud API 사용을 위한 설정
3. Google Vision API와 Translation API를 활용한 이미지-텍스트 추출 API 구현 설명
4. Postman을 활용한 API 작동 테스트
5. 요약 및 추가사항
-[ ] [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:
```
평소 외부 API를 이용하여 개발을 해보고 싶다는 생각을 갖고 있던 중에 캡스톤 디자인 성과 발표회를 구경하며 OCR 기술이라는 것을 알게 되었다. 식재료를 구매한 영수증을 카메라로 비추면 OCR 기술을 이용해서 구매한 재료의 이름과 구매 날짜, 가격 등을 자동으로 인식하여 문자화 할 수 있다는 점이 사용자 관점에서 보았을 때 편리하고 혁신적인 기능이 될 수 있겠다는 생각을 하였다. 이 후, OCR 기술에 대해 더 조사하던 중에 Google의 Vision API가 진입 장벽이 낮고, 무료로 사용해볼 수 있다는 점에서 매력적으로 다가왔다. 하지만, 인증을 위해 JSON 인증 키 파일을 생성하고, 환경 변수를 설정하는 등의 과정이 다소 복잡하게 느껴졌고 다른 사람들도 같은 어려움을 겪을 것이라는 생각이 들었다. 따라서 Google Vision API를 다른 사람들에게 소개함과 동시에 사용에 어려움을 겪지 않았으면 하는 마음에서 이 주제를 선정하게 되었다. 또한, Vision API를 사용하면서 인식 결과가 영어로만 나온다는 점이 아쉽게 느껴졌다. 따라서 인식 결과를 한국어로 번역 하는 기능까지 갖추어졌으면 하는 마음으로 Translation API를를 주제에 포함시켜 하나의 온전한 기능을 하는 API를 개발하기로 결정하였다.
-[ ] [Set up project integrations](https://git.ajou.ac.kr/sumin1212/foss2023-1_final/-/settings/integrations)
##개발하면서 발생했던 문제점
## Collaborate with your team
처음에는 JSON 인증 파일과 환경 변수를 통한 인증 방식이 아닌 프로그램 코드 내에서 인증을 하는 또 다른 방식을 시도하였다. 하지만 계속해서 인증 실패로 인한 오류가 발생하였고, 오랜 시간 실패를 겪은 뒤에 현재의 방법으로 돌아와 인증을 성공할 수 있었다. 또한, Google Cloud SDK를 설치하는 과정에서 노트북의 사양 문제로 인해 5시간 동안 설치를 기다려야 하는 상황이 발생하기도 하였다. 개발을 진행하는 과정에서는 build.gradle에 dependency를 추가할 때, vision api와 translate api의 버전이 계속해서 인식되지 않고 주입이 되지 않는 문제를 겪었다. 여러 번의 시도를 거쳐 조합이 가능한 버전으로 새롭게 dependency를 추가해보며 결국 현재의 버전으로 성공할 수 있었다. 간단한 API를 개발하는 것이라 백엔드 코드를 짜는 것에 있어서는 크게 어려움을 겪지 않았으나, 외부 API를 불러와 데이터를 원하는 대로 가공하고 사용해야 한다는 점이 낯설게 느껴졌다. 하지만 낯선 코드더라도 반복해서 보고 로직을 이해하려고 시도하다 보니 각 메서드 코드가 어떻게 돌아가야 하는지 최종적으로는 이해할 수 있었다.
-[ ] [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)
-[ ] [Automatically merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
## Test and Deploy
오픈소스 sw 입문 수업을 통해, 기말 프로젝트를 통해 내가 기존에 알고 있던 것 보다 훨씬 다양한 오픈소스 기반 프로그램, 오픈소스 기반 소프트웨어가 존재하고 있다는 사실을 알수 있었다. 기존에 올라온 영상을 통해서도 새로운 분야에 대한 다양한 지식을 많이 얻어갈 수 있었다. 주제를 선정하고 직접 설정해보고 사용해보고 코드를 작성하 어려움과 동시에 뿌듯함을 느낄 수 있었다. Google Vision API를 조금 더 심화된 기능으로써 이용해보고 싶다는 생각을 하였으며, Google Vision API와 Google Translation API 외에도 Google에서 지원하는 다른 API도 공부해보고 사용해보고 싶다는 생각이 들었다.
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!). Thank you 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.
