https://www.kmooc.kr/view/course/detail/10480?tm=20240204081326 K-MOOC 분야별 강좌 K-MOOC에서 분야별로 트렌디한 강좌를 학습해보세요. www.kmooc.kr 안녕하세요! 오늘은 경희대학교 K-MOOC 신규강좌인 '소프트웨어 설계와 파이썬' 강좌에 대해 소개해드리려고 합니다! 앞으로 7주 동안 이 강좌에 대해 포스팅하려고 하니 많은 수강부탁드려요:) 첫 주차는 기본적인 강좌 설명을 드리려고 합니다! 1. 강좌 소개 이 강좌는 '어떻게 프로그램을 만들까?', '내가 생각하는 아이디어를 어떻게 프로그램으로 구성할 수 있을까?'와 같은 생각을 하고 계신 분들께 추천해드리는 강좌예요! 소프트웨어 설계 방법을 설명하고, 파이썬으로 코딩함으로서, 자신의 아..

안녕하세요! 오늘은 경희대학교에서 새로 개설한 K-MOOC 신규 강좌들을 소개해드리려고 합니다! 새로 개설된 강좌는 개별강좌 6개, 묶음강좌 2개로 총 8개입니다! 여기서 묶음강좌란, 특정 분야를 보다 심도있는 학습기회를 제공하기 위해 복수의 강좌로 구성된 커리큘럼입니다. 묶음강좌도 개별강좌와 똑같은 방식으로 수강신청하여 수강하시면 됩니다. 1. 개별강좌 책임교수 경희대학교 김학민 교수님 강좌소개 국경 간 전자상거래와 무역벤처창업의 기회를 탐색하는 과목입니다. 이 과정을 통해 글로벌 시장에서 비즈니스를 구축하는 데 필요한 지식과 기술로 활용하실 수 있습니다. 학습목표 학습목표는 다음과 같습니다. * 무역벤처기업가의 사고방식과 혁신에 대해 이해할 수 있다. * 변화하는 시대..

프로젝트를 진행하면서 국가별 도시 이름 데이터를 가져오는 API가 필요했다. 여러 API들을 사용해보고 countriesnow API를 선택했는데, 여러 API들을 사용해보면서 느낀점을 정리해보려고 한다. 1. REST Countreis API https://restcountries.com/v3.1/all 국가별 정보들을 제공하는 API로 API key를 따로 발급받을 필요가 없다는 큰 장점이 있다. 하지만, 내가 원하는 국가별 지역 데이터들을 제공하지는 않았다. 국가의 여러 정보들을 원한다면 쓰기 좋을 것 같다. 2. OpenCage Geocoding API https://opencagedata.com/ OpenCage - Easy, Open, Worldwide, Affordable Geocoding ..

개요 프로젝트를 하면, 항상 프론트만 플젝 제일 마지막 순간까지 개발을 하고 있다.. 기획, 디자인이 완료되면 백엔드가 먼저 개발을 시작하고, API 개발이 끝난 뒤 프론트엔드 개발이 들어가면 좋겠지만, 현실은 백엔드와 프론트엔드가 동시에 시작하는 게 대부분이다. 그래서 프론트에서는 백엔드가 준 API 명세서를 보고 Mock Data를 만들어서 데이터를 띄울 준비를 해놓는다. 하지만 이런 식으로 하면, API 개발이 끝난 뒤, 또 마지막까지 외롭게 개발을 해야한다..ㅠㅠ 이번에 방학 UMC 프로젝트를 시작하면서 프론트엔드에서 MSW를 사용해보자는 얘기가 나왔다. MSW만 제대로 구축해놓으면, API 연결을 미리 해놓는 것과 똑같아서 나중에 또 개발을 하지 않아도 된다고 한다. 이번 플젝에서는 백엔드보다 ..

개요 프로젝트에서 글쓰기 기능이 있어서 텍스트 에디터를 찾아보다 TOAST UI Editor를 알게 됐다. NHN에서 만든 건데 다른 에디터들에 비해 완전 쉽고 옵션도 편하게 설정할 수 있어서 강추한다~! TOAST UI에는 텍스트 에디터 말고도 다른 컴포넌트들도 많아서 앞으로 자주 사용하게 될 것 같다. 사용법 1. 설치 npm install --save @toast-ui/react-editor 2. Editor import '@toast-ui/editor/dist/toastui-editor.css'; import { Editor } from '@toast-ui/react-editor'; const SignatureWritePage = () => { return ( ); }; export default..

개요 진행하고 있는 프로젝트에서 Git flow 방식으로 협업하기로 했다! 원래는 세미 git flow..?ㅎ느낌으로 협업했었는데 이번에는 제대로 해보려고 한다. 원래 하던 방식! 사실 Git flow가 보통 다들 프로젝트를 하는 방식과 크게 다르지는 않다. 원래 내가 하던 방식을 말하자면, main은 안 건드리고 develop을 판다.기능마다 issue를 파서 각 이슈 별 브랜치를 만들고, 작업이 끝나면 develop 브랜치로 merge한다. main 브랜치는 배포용으로 사용하는 브랜치기 때문에 개발이 끝나면 develop을 main에 merge해서 배포한다. 내가 하는 사이드 프로젝트에서는 이렇게만 해도 아무런 문제가 없지만, 회사에는 QA팀도 있고, 엄청난 이슈가 생길 수도 있기 때문에 Git fl..