일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- virtualenv
- 아이디어팩토리
- 스포츠코치
- 위즈네트
- virtualenvwrapper
- LED
- 샤오미
- 무브나우
- 미니 화이트
- 워크샵
- 온오프믹스
- psycopg2
- nginx
- berkeley db
- 스마트 러닝화
- 탱크램팩토리
- UserCreatioForm
- IOT
- ted
- Python
- help_text
- AWS EC2
- 데이터 이전
- django
- windows
- 마이크로소프트
- restful
- uWSGI
- 미밴드 1S
- PostgreSQL
- Today
- Total
목록토막지식 (9)
NERD WORLD
DRF로 RESTful API를 개발하고 있다. DRF에서 웹 브라우저 클라이언트에 대해서는 API를 테스트해볼 수 있는 UI를 제공해준다. DRF가 제공하는 Generic API View와 Serializer를 잘 활용한 경우에는 혜택이 더 있다. request body에 들어갈 쌍들의 key 값에 대한 value를 입력하는 HTML Form을 자동으로 생성해서 브라우저로 렌더링 해준다. 활용하지 못한 경우에는 request body를 raw data로 작성하면 된다. 전자의 경우에는 더 편리하게 테스트해볼 수 있는 DRF Docs 패키지도 존재한다. 이번에 개발하는 API는 1차적으로 목표하는 클라이언트는 안드로이드/iOS 네이티브 앱이므로 브라우저 테스트로는 부적절하다. 그러므로 예상되는 클라이언트..
NEXTERS 9기에서 예니오팀에 속해서 개발중이다. 다른 회원 한분과 함께 DRF(Django REST Framework)를 활용해서 안드로이드/iOS 앱을 위한 RESTFul API를 개발하고 있다. 그동안 Git/GitHub을 이용했을때는, 제대로 협업하기 보다는 혼자서 개발하면서 이력 기록, 코드 백업 정도의 목적으로만 사용해왔다. 이번에 둘이서 함께 개발하게 되면서, 이번 기회에 Git/GitHub에서 협업하는 방법을 몸에 체득시켜볼 계획이다. Git을 사용해서 함께 협업하는 방식(Workflow)은 다양하다. 그중에서 우리팀은 Gitflow Workflow를 선택했다. 대략적인 flow는 아래와 같다. 여기에 덧붙여, 로컬 환경에서 각자가 개발할 목적으로 branch를 생성할때는 issue 기..
데이터베이스 강좌의 프로젝트1을 진행할때, Berkeley DB Java API를 사용했었다. 그때는 pair를 저장할때, 둘 다 String type만 가능한줄 알고 그렇게 사용했었다. 하지만 Berkeley DB의 소개글을 읽다보니, byte array로 변환될 수 있다면 그 어떤 data type도 Berkeley DB에 읽고 쓸 수 있다는 것을 깨닫게 되었다. 예를 들어, Java가 제공하는 HashMap type도 의 data가 될 수 있는 것이었다. 이를 해당 학기때 깨달았더라면 얼마나 좋았을까 하는 생각이 들었다. 그 당시의 나는 그만큼이나 상상력과 행동력이 부족했구나 하는 것을 또 한번 깨닫는다. 아래의 링크들을 참고해서, Berkeley DB에 pair를 저장하고 불러와서 콘솔창에 출력하..
"Django REST Framework(DRF)"로 "RESTful API"를 설계하고 있다. 클라이언트 중립적으로 개발하는것이 맞겠지만, 현재 함께 개발되고있는 유일한 클라이언트는 "네이티브 안드로이드 앱"이기 때문에 아무래도 그쪽으로 신경을 쓰게 된다. 이전까지 Django를 사용할때는, PC 브라우저만을 대상으로 했었다. 그러니 "Django Form"을 사용했고, 이 글의 제목인 "Authentication"이나 "Authorization"에 대해서 깊이 생각해본적이 없었다. Django가 제공하는 로그인/로그아웃 View를 사용하면 그만이었기 때문이다. 그나마 내가 건드렸던건 Sign up에 쓰이는 UserCreationForm, Sign in에 쓰이는 AuthenticationForm 정도였..
Elastic IP를 지정하는 것은 아래의 책 내용을 참고했다."아마존 웹 서비스를 다루는 기술", 6장 AWS Route 53을 사용해서 보유중인 도메인을 EC2 인스턴스와 연동하는 것은 아래 포스트를 참고했다."EC2 인스턴스에 도메인 연결(Route 53)" NS, SOA, A, CNAME 레코드에 대해서는 추가적인 학습이 필요할 것이다. 위닝 전적기록 웹
"객체지향의 사실과 오해" 라는 책을 읽고 있다. 중요한 내용 중 하나가 Encapsulation이다. Interface와 Implementation을 엄격히 분리하는것이, 객체지향적인 설계를 돕고, Encapsulation이 분리를 가능하게 한다. 그러나 Python에서는 C++이나 Java와 달리, public/private의 개념이 없기에 의아했다. 그래서 찾아보니, 아래 아티클이 이를 아주 명쾌하게 설명해주고 있다. Private, Protected, and Public in Python
계기: 위즈네트 4월 아카데미 강의들 중 "Facebook을 통한 디바이스 컨트롤 (SSL, RTOS, HTTP를 한방에)" 강좌가 있었다. IoT 시스템을 구현하려면 보안이 중요하니 SSL/TLS를 필히 구현해야한다. 강사님께서 이를 위해 2개월간 C언어로 SSL/TLS 부분을 수행하는 코드를 작성하셨고, 이를 활용해서 진행된 수업이었다. 웹에서 보안에 대한 이슈들은 문외한이었으므로 이번 기회에 정리해보고 싶었다. 주의사항: 작성자가 창작하 지식은 하나도 없음. 아래 참고에 적은 두개의 링크에 기술된 지식을 이해하고, 이해를 다질겸 간단히 정리해본것에 불과함. 대칭키(symmetric key)P라는 키(key)로 암호화하면, 그 P로 복호화하는 기법이다. 이때 이 암호화/복호화에 둘 다 쓰이는 키를 대..
배경: 위즈네트 아카데미에서 강의를 수강하는데 종종 "포트-포워딩"이라는 단어가 언급되었다. NAT와 헷갈리지 말라는 맥락이었다. 두 개념을 정확히 모르니, 한번 정리해보게 되었다. NAT(Network Address Translation)IPv4 주소는 4bytes = 32bit의 주소다. 그러므로 표현가능한 총 가짓수는 2^32 = 약 42억개. 요새 IoT까지 화두가 되면서 인터넷 연결 가능한 기기들의 개수가 기하급수적으로 늘어났음을 감안한다면, IPv4 주소를 모두 할당할 수 없었을 것이다. 즉, 모든 기기들이 자신만의 공인 IP 주소를 가질 수 없게 된 것이다.그래서 나온 방법이 NAT이다. 이름 그대로 Network Address를 Translation하는 작업이다. Network Addres..
학교에서 "데이터 통신망의 기초"라는 강의를 들었음에도, 최근에 개념이 헷갈리는 상황을 맞이하여 정리해본다.아래 블로그 포스트가 공인/사설/유동/고정 ip 주소에 대해 훌륭하게 정리하였다. 그러므로 굳이 따로 설명할 필요는 없어보인다. GOTOCLOUD 블로그의 게시글집 밖에서 공유기에 접속할 때, 많은 경우에 기본 게이트웨이가 192.168.1.xxx 주소로 떴었다. 그런 경우에는 C 클래스의 사설 IP 주소 대역을 사용한다고 얘기할 수 있겠다. 우리 집은 기본 게이트웨이가 172.30.1.254로 뜨니 아마 KT에서는 B 클래스의 공인 IP 주소를 부여받은 것이 아닐까 싶다.글의 주제는 아니지만, 내친김에 우리집 KT Olleh 공유기의 설정을 어떻게 바꿀 수 있을지 알아보았다. 이 역시 아래 블로그..