Karzin Lab

Project.다원 Ensemble_개발(8)_메뉴 디자인 변경

결국은 날잡아서 메뉴 디자인 새로 고쳤습니다.ㅋㅋㅋㅋㅋㅋ

평소부터 맘에 안들었지만,

그 왜.. 그런거 있잖아요? 꼭 공부하려고보면 책상이 더럽게 느껴져서 다 치우고 느지막하게 공부 시작하게 되는..

그런겁니다... (무슨말인지 하나도 모르겠..)

어쨌든 오늘은 메뉴 디자인을 변경했습니다.

그런 느낌.

간단하면서 깔끔하고 보기좋고 이쁜 그런 디자인. (?!?!?!?!?????)

제 눈에는 깔끔해지긴했는데 다른분들이 보기에는 어떨진 모르겠네요ㅠㅠ

새로 변경된 메뉴 디자인

(최고 관리자는 우리집 막내였다고 합니다. 저는 그저 개발자!ㅋㅋ)

이번 디자인은 버튼이라던가 그림자 효과가 보이는게 좀 있지 않나요?

사실 저는 플랫 디자인을 굉장히 좋아하는데, 이번에는 머티리얼 디자인으로 작업을 해야할 것 같아서 머티리얼 디자인으로 진행을 해봤습니다.

추후 기회가되면 따로 설명을 해볼까 하지만, 플랫 디자인은 생각보다 디자인은 정말 깔끔하지만 구별의 모호성이 가장 큰 문제라.. 사용자의 입장에서 헷갈릴 수 있다는 점이 문제죠.

이런 시스템에서는 깔끔한건 좋지만, 기능이 중요하기 때문에 어떤게 버튼인지 구분이 안되는 상황은 문제시 될 것 같아서 여러부분에서 고민을 많이 했네요.

최대한 깔끔하게 하려고 노력하긴 해봤는데, 이거저거 코딩작업해보고 비교해가면서 적용한게 이정도네요.

개인적으로 bootstrap이용하면서 최대한으로 깔끔하게 뽑은거같습니다. (이전에는 워낙 지저분하게 덕지덕지 붙여놔서..)

일단 적용은 했지만, 아직 다른 화면들의 컨텐츠는 조금 수정이 필요할 것 같네요.

참, 모바일 버전으로 보면 이런 느낌이 됩니다. (아래 참조)

위는 컨텐츠, 아래는 메뉴를 눌렀을때네요.

참고로..

기존에는 이랬지요.. (링크)

ㅋㅋㅋ 촌스러웠지요..

그리고 귀찮아서 구현하지는 않았었지만, 메뉴에서 Ensemble Navigation이라 보이는 부분에는 원래 유저 정보를 넣을 생각이었습니다.

그래서 위를 조금 비워둔 상태였구요 (이눔의 귀차니즘..)

이 부분은 설계서에는 없을건데, 그 이유가 로그인 관련쪽을 설계하면서 넣을 예정이었거든요. (업데이트 형식으로)

어차피 해야할거 미리 넣어서 진행하자 싶어서 넣어두었습니다. ㅋㅋ

추가로 아직 컨텐츠까지는 디자인을 변경하지 않아서 아직 해야할 일이 많이 남아있네요 (아래 이미지 참조)

뭐.. 이 부분은 DB연동하면서 어차피 이거저거 테스트하면서 변경될건 변경되고 할테니

차차 진행해야겠습니다.

또 어떻게하면 깔끔하고 이쁜 디자인으로 할지 고민도 좀 해보구요 ㅋㅋ

정~~~말 별거아녔는데 시간잡아먹었네요.

왜 그렇게 딱 맞아떨어지는 디자인이 바로바로 안나오는지..

애초에 저는 디자이너는 아니고 취미로 그림 그리거나 디자인하는 정도(중학생까지 미술과외를 받았건만..)라서

정말 디자인 잘하시는 분들이 보면 굉장히 별루일 것 같네요. (ㅠ,ㅠ)

그래도 좋은점이라면 혼자 디자인과 개발을 하다보니 그냥 맘에 안드는거 있으면 훅훅 바꿔버리는 ㅋㅋㅋㅋ

보통이라면 디자인 <-> 개발 커뮤니케이션이 중요하기도하고 그로인해 걸리는 시간적인 코스트도 많이 있을 법 한데 그런 부분이 확실히 사라지니까 너무 좋습니다. (설마 제가 저와 커뮤니케이션하지는 않을테니까요ㅋㅋ)

누군가 창작의 고통은 아프다더만..

창작을 해서그런지 눈이 침침하고 무릎이 아프네요. (그건 아마 비가와서 그렇....)

다음주부터는 DB연동으로 넘어갈 것 같네요. (뭔가 일주일씩 역할이 나뉘는 느낌)

좋습니다. 좋습니다..

오늘도 고생 많으셨고, 굿밤되시기 바랍니다!

(어! 8월 1일에 게시하려했는데, 개발에 빠져있다가 2일이 되어버렸네요. 흑흑.. 별수 없죠 뭐..)

버전정보 (v1.0)

 - v1.0 2020.08.02 배포

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_개발(7)_장비 상세 화면 개발

흠.. 오늘로써 설계 문서에 맞춰서 일.단.은. 화면단의 개발은 끝났습니다.

이제 버그 수정과 디자인이 썩 맘에 들지않아 더 깔끔하게 다듬어주는 작업이 남아있기는 한데, 이건 천천히 작업하는걸로 하고, 내일부터는 이제 DB 데이터와 연동하는 작업을 들어가볼까합니다. 

근데 벌써 1시 41분이네;; 오늘도 빠르게! 보여드리고 넘어가도록 하죠!

Wireframe & 화면설계서 (링크)

Wireframe (장비관리-장비상세_tab1)

화면설계서 (장비관리-장비상세_tab1)

개발 화면 (장비관리-장비상세_tab1)

아직 DB연동이 안되어 있어 세세한 데이터의 정보까지는 처리하지 않았습니다.

이 부분 확인하시어 일단은 프레임만 보시면 될 것 같습니다!

Wireframe (장비관리-장비상세_tab2)

화면설계서 (장비관리-장비상세_tab2)

개발 화면 (장비관리-장비상세_tab2)

흠흠.. Modal도 그렇고 좀 다듬어야할게 한둘이 아니네요.

2시까지 마무리작업을 생각했으니, 오늘은 일단 여기까지~

아무래도 문제는 디자인!

좀 더 공을 들이면 깔끔하게 뽑을 수 있을 거 같습니다.

(일단 지저분한 저 파란색 테마는 좀 빼도록 하고, 테두리랑에서도 파란색을 제거를 ㅡㅡ,, <- 참고로 저는 파란색 엄청 싫어합니다. 빨강x검정이 진리...지만 여기서 그런짓했다가는 싸대기맞을듯싶네요 ㅋㅋㅋㅋㅋㅋㅋ)

디자인은 차츰차츰 해소해나가야죠. 어차피 틀은 어느정도 잡아뒀다고 생각해서 디자인 쯤이야..^^

(??????????? 어디서 나오는 자신감인가.. 난 졸려죽겠.....)

빠르게 작성했다고 생각했는데 벌써 1시 56분...ㅋ 내일(? 이아니라 오늘)을 위해서 얼른 취침하러 가봐야겠습니다!

아! 그러고보니 오늘도 비가 많이 온다고 하는 모양이니 조심하시고, 침수피해 없으시기 바라겠습니다.

비도 맞으면 감기걸릴 수 있으니 꼭 우산 챙기셔서 건강도 조심하시구요!!

그럼 오늘도 고생많으셨습니다~~

버전정보 (v1.0)

 - v1.0 2020.07.31 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_개발(6)_장비 목록 화면 개발

오늘따라 엄청 졸리네요;; 이제 목요일 들어가서 그런가..? 잘 모르겠네요;; 

음.. 오늘도 커피 5잔정도 마신거같은데 이러네요;;ㄷㄷㄷ

간만에(올해 설날 이후로 간만에 길게 쉰거같은데..) 휴식기간을 가지다가 다시 업무와 프로젝트 그리고 공부를 또 열심히(?????) 병행하는게 몸이 못따라오는건지.. 어쩐건지..;;

일단은 버그 생각 않고 장비목록 화면만 빠르게 뽑아내고 좀 쉬어야지 싶어서 빠르게 진행했습니다.

아마 추후에 고쳐야할게 많을 듯 싶네요...ㅠㅠ

그냥 어떻게 진행되었는지만 화면 뽑아낸것만 보여주고 바로 취침하러가겠슴다 ㅠ;

wireframe & 화면설계서 (링크)

Wireframe

화면설계서

장비목록 화면 개발 내역

대충 만들어서 그런가 만들고나서 이거저거 눌러보니 벌써부터 보이는 버그가..

일단 필요한 화면 얼른얼른 쳐내고 DB와 연동하는 작업 진행하면서 다듬어가야겠네요 에궁..

(그나저나 디자인이 파랗파랗한게 영 맘에 안드네.. 날잡고 디자인도 그냥 다시 잡아줘야겠네요 ㅋㅋㅋㅋㅋㅋㅋㅋ)

일단은 아까 맨 위에 써놓은 것처럼 오늘은 정말 너무 너무 피곤해서 먼저 자러가보겠습니다;;; (ㅠㅅㅠ)

오늘도 고생많으셨습니다.~

버전정보 (v1.0)

 - v1.0 2020.07.30 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_기능검토(3)_Thymeleaf Layout Dialect

간만에 개발을 진행하면서 아쉬운 부분이 있어 검색을 통해 추가한 Thymeleaf Layout Dialect에 대해서 설명을 해볼까 합니다.

사실 이전에 Template Engine 자체를 Thymeleaf를 사용하겠다고 개발정보에 떡하니 작성은 했으나, Thymeleaf Layout Dialect에서의 조금 다른 layout기능이 필요하여 dependency에 추가를 해주었습니다.

오늘은 이 기능을 살짝 맛보기 수준으로 설명을 하고 계속해서 개발을 진행하면서 괜찮은 정보가 있다면 공유를 하도록 하겠습니다.

기능 검토 - Issue

우선 사건의 발단(?)은 이랬습니다.

위의 이미지를 보시는것처럼 저는 Common적인 요소를 어떻게하면 더 편리하게(?) 활용을 할 수 있을까?

재활용이 용이할까? 라는 생각으로 시작을 하게 되었습니다.

사실 이러한 기능은 Thymeleaf에서도 지원을 안하는건 아닙니다.

다만, 조금 더 소스의 길이가 길어질 뿐 (그리고 그만큼 개발자인 저도 귀찮아질 뿐...) 사용에는 큰 지장은 없었습니다.

그럼에도 불구하고 저는 더 나은 방법을 찾고 싶었고, 그에 대한 해답으로 제시한 것이 Thymeleaf Layout Dialect 였습니다.

우선 기존에는 어떤 느낌이었는지를 그림으로 보여드리겠습니다.

기존에 사용하던 방식을 나타낸 그림

위와 같이 기존에 사용하던 방식은 top과 left의 메뉴를 일일이 화면에 replace를 해주어야 했습니다.

사실 하나씩 replace를 해주면 금방끝나는거겠지만, 화면이 계속해서 늘어남에 따라 replace해주어야하는 양도 그만큼 늘어날 것이고, 화면이 더 늘어나기 전에 해결을 해둠으로써 저의 잠자는 시간을 지키기위해 좀 더 편리함을 추구 하기 위해 검색을 해보았습니다.

변경된 방식을 나타낸 그림

검색의 결과, 저는 위 그림처럼 contents를 기존의 layout의 특정영역(즉 기존 layout의 contents영역)에 바꿔치기를 해주는 방식을 찾아냈습니다.

이게 바로 Thymeleaf Layout Dialect이었고, 간편하게 dependency만 추가해주면 정말 편리하게 사용할 수 있었습니다.

(사실 dependency추가 안해놓고 왜 안되냐고 삽질하면서 20분 날려먹은건 비밀입니다..)

장단점

이 방식의 최대의 장점은 기존의 layout의 틀만 잡아놓고, 변경을 해둘 contents의 부분만 잘 잡아놔주면, 개발자는 해당 contents만 작업을 해주면, 미리 layout에 잡아놓은 common적인 요소들은 그냥 기본적으로 딸려온다는 점이죠.

그만큼 소스작업에 있어서도 굉장한 편리성이 느껴집니다.

대신 단점은 contents만이 아니라 common요소에 대한 커스텀이 필요할 때에는 common요소에 대해서 단일화면에서만 사용하기 위한 용도로는 수정이 불가하다는 점이 있습니다.

이럴때에는 기존에 사용하던 Thymeleaf의 replace나 include기능을 사용해 커스텀을 이용해주면 되겠지만 말이죠.

Thymeleaf Layout Dialect의 License

mvnrepository를 이용하면 License의 정보를 쉽게 파악할 수 있는데요,

Thymeleaf Layout Dialet의 License는 Thymeleaf와 동일한 Apache 2.0입니다.

큰 문제없이 사용이 가능할것으로 보여 License만 체크 후 바로 dependency에 추가했습니다 ㅋㅋㅋ

으헉.. 벌써 2시 7분이네요!

내일을 위해서 얼른 자야겠네요ㅠㅠ

공부는 즐거운데 시간은 항상 왜 이렇게 빨리지나가는지 아쉽기만합니다 ㅠㅠㅠ

버전정보 (v1.0)

 - v1.0 2020.07.29 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_개발(5)_장비 등록 화면 개발

휴식을 갖기 전에 열심히 베이스를 깔아놔서 그런지 화면 개발은 화면 하나당 하루(대략 1~2시간 정도)정도 잡으면 될 것 같네요. (휴일이었으면 하루면 다 만들 듯..)

일단 기능적인 요소를 제거하고 front와 back단 조금 잡아주는 부분까지만을 1~2시간 정도로 잡고 있습니다. 사실 하나 완성되면 그 이후는 더 금방 끝날것도 같지만..

오늘은 그런 의미에서 개발 진척된 부분 가지고 나와봤습니다!

우선 개발 진행되고 있는 장비 등록을 보여드리기 전에! 잊으셨을 수 있으니, Wireframe과 화면설계서를 한번 보여드리고 진척사항을 설명하도록 하겠습니다.

여기서는 설계단의 자세한 설명은 생략하고 이미지만 보여드릴 예정입니다.

혹시라도 설계관련 자세한 사항은 아래 링크를 통해 장비등록의 Wireframe과 화면설계서를 보시는걸 추천드립니다.

Wireframe & 화면설계서 (링크)

Wireframe

화면설계서 - PC 버전

화면설계서 - Mobile 버전

설계서를 토대로 개발 진행된 사항 - PC 버전

어찌보면 Prototype이라고 하기에는 아쉬운 수준의 미완성적인 개발된 내역입니다.

처음 몇몇 Component들 잡아주는 부분이 시간이 걸렸을 뿐이지, 아마 이후부터는 개발에 좀 더 속도가 붙지 않을까 싶습니다.

일단 input box 안에 들어간 내용들은 직접 입력해본 내용물입니다.

화면설계서와 비슷하게 만드려고 노력은 했지만, 역시나 디자인이 조금 아쉽기는 하네요.

이 디자인은 조금씩 다듬어가면서 계속해서 업그레이드 해나갈 예정이니 지금은 아쉽더라도 기능을 붙여가면서 조금씩 만져봐야겠습니다 ㅋㅋ

설계서를 토대로 개발 진행된 사항 - Mobile 버전

모바일에서는 지금은 이러한 화면을 보여주고는 있는데, 해당부분은 실제 테스트를 통해서 변경될 수 있는 부분이 많이 있을 듯 합니다.

아무래도 사용하면서 불편한 부분들도 몇몇 보일텐데 그러한 부분들은 점차 해결해나가야할 것 같습니다.

음! 그러고보니 모바일버전에서 메뉴를 누르게되면 어떤 느낌인지 궁금하실 수 있는데 이 부분은 아래와 같은 느낌입니다! 퍼런색으로 다 칠해놨더니 조금 아쉬운 부분이 많아서 ㅋㅋㅋㅋ 심심할때마다 디자인은 계속 변경해봐야겠습니다 ㅋㅋㅋ

첫 화면이 드디어 뽑히게 되어 아마 이후 화면들은 금방금방 뽑아낼 수 있을 것 같습니다. (칼국수!?_)

그만큼 첫 화면이 중요한게 아무래도 틀이 잡혀가는데 시간이 생각보다 많이 들어서.. 역시 시작이 조금 걸릴뿐이지 이후는 별다른 기능의 Component들만 아니라면 금방금방 뽑혀 나올 것 같습니다.

화면만 대충이라도 나와주면 DB연동작업(특히 Back-end단)이 한창 시작될 것 같네요.

뭐.. Component 중에서도 제가 좀 손을 봐야하는 부분이 몇몇 있기는 한데.. 이것저것 하나씩 잡고 진행하다보면 어느정도 작업이 마무리 되어가지않을까 생각합니다.

일단 오늘은 이정도에서 마무리하고, 기능검토 게시글도 같이 작성중이던게 있어서 그 부분까지만 작성하고 취침하러 가봐야겠네요 ㅋㅋㅋ

오늘도 고생 많으셨습니다~

버전정보 (v1.0)

 - v1.0 2020.07.29 배포

* 본 게시글의 이미지에 들어간 글씨체는 네이버 나눔 글씨체인 나눔스퀘어 Bold를 사용했습니다.

* 본 게시글의 이미지는 전부 (이미지 내의 픽토그램 등) 직접 제작했음을 명시합니다.

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_개발(4)_메뉴 제작

으 항상 코딩하다보면 시간을 확인을 못하네요 ㅠㅠ

벌써 2시 20분입니다!!!

때문에 빠르게 게시글 작성하고 넘어가겠습니다!

(사실 그닥 보여줄만한게 없습..)

음.. 아무래도 메뉴는 그렇게 어려운부분은 아니라서 자작할 필요성을 느껴서 시작했습니다.

그리 오래걸리진 않았습니다.

다만, 일이 있어서 ㅠㅠ

후딱 보고 가시죠!

 - 메뉴가 닫혀있을 때

* 해당화면은 하위 요소가 존재하는 경우를 나타냅니다.

 - 메뉴가 열려있을 때

* 해당화면은 하위 요소가 존재하는 경우를 나타냅니다.

아직은 디자인이 심플하기만하고 지향하는건 다 못보여주지만,

일단 간단하게 만들어놓고 개발진행하면서 기능과 함께 차근차근 변경할 예정입니다!

별거아닌데 iOS 막힌부분 푸느라고 늦어졌습..

어쨌든 빨리 자야겠네요 ㅠㅠ

맨날 자는 시간이긴하지만..;;

+ 앞으로는 매일같이 ~되었다보다는 중간중간에 정산해서 올리도록하겠습니다. 아무래도 back단은 개발을 진행하더라도 눈에 보이지 않는 부분들인 경우가 많다보니 꼭 필요한 경우나, 문제가 있을때 해결방법등을 공유해볼까합니다!

버전정보 (v1.1)

 - v1.0 2020.07.21 배포

 - v1.1 2020.07.22 내용 추가

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_기능검토(2)_Protocol Buffers

오늘은 피곤해서 좀 쉬려했는데, 아무래도 또 머리를 안굴리니 심심하기도하고, '조금이라도 글쓰면서 공부나하자' 라는생각에 컴퓨터를 켰습니다. ㅎㅎ;;;;;

오늘은 컨디션 고려해서 개발은 진행하지 않았고, 그냥 기능검토나 살짝 해볼까 합니다.

예~전 프로젝트 진행중에 잠시마나마 Google Protocol Buffers를 사용한적이 있었습니다.

이때 많은량의 데이터처리를 할때 패킷을 조금이나마 줄여 좀 더 빠른 속도 낼 수 있었던걸로 알고 있는데, (오래전기억이라 가물가물) 지금 사용할 장비관리쪽에서는 패킷이 많을리는 없겠지만, 추후 제가 생각하는 기능 중 이 Protocol Buffers가 있으면 좋을 것 같아서 미리 구현을 해둘까 합니다.

우선 Protocol Buffers가 무엇인지에 대해서 시작하도록 하겠습니다.

Protocol Buffers?

프로토콜 버퍼(Protocol Buffers)는 구조화된 데이터를 직렬화하는 방식이다. 유선이나 데이터 저장을 목적으로 서로 통신할 프로그램을 개발할 때 유용하다. (출처 : 위키백과 _ 링크)

위 설명을 토대로 조금 덧붙여보자면 Rest API 등의 통신시 전달할 VO(Value-Object)의 직렬화를 통해 더 적고(패킷), 빠르고(속도), 심플하게 통신을 할 수 있는 용도로 사용할 수 있다고 생각하면 될 것 같습니다. (제가 생각하기로는)

프로세스적인 측면에서는 일단 심플하게나마 정리를 해두자면 아마도.. (Rest API 기준 - back->front)

대략 이런 느낌이었을 겁니다. (오래되서 찾아보기는 했으나, 간략화된 순서도라던가는 보이지않아 제 기억을 토대로 작성했습니다. 혹시 더 좋은 자료나, 틀린부분 있으면 지적해주시면 수정토록하겠습니다.)

front->back은 반대로 생각하시면 될 것 같습니다.[ json->proto->전송->proto의 vo변환->vo ] 이런 느낌.

Protocol Buffers의 License

저는 이런 기술들을 도입함에 있어 License의 체크는 가장 중요합니다.

일개 개발자가 여러 기술들 사용해서 프로그램을 만드는건 좋지만, License가 위반되어 사용하기 힘든경우가 발생하면.. 슬프잖아요..?ㅠㅠ

우선 Protocol Buffers의 License는 BSD입니다.

저는 GPL License의 경우 조금 사용하기 꺼려하다보니 GPL은 기피하는 현상이 있지만,

Protocol Buffers는 GPL보다 좀 더 개방적인 License다보니.. 사용함에 있어서도 크게 문제 없으리라 판단이 되었습니다.

(뭐.. 제가 지금 개발중인 해당 시스템에는 GPL License는 없다보니.. MariaDB Connector가 LGPL정도..?)

Protocol Buffers를 사용함으로써 얻는 이점?

중점은 이거입니다. 패킷이 적어지고 빨라지고 심플해져서 좋은데 왜 쓸거냐? 도입하는 이유가 뭐냐?

음.. 사실 이유로서는 바로 위에서 언급한 패킷이 적어지고 빨라지고 심플해지는걸로도 충분하리라 생각합니다.

다만, 제가 추후 장비관리쪽에 재미있는 기능을 하나 붙이려고 생각중인데, 그 기능을 사용하기 위해서는 Protocol Buffers의 도입이 필수라고 생각했습니다. (이는 모바일 어플의 연동과는 전혀 다른 기능입니다.)

아마 생각하건데 추가적인 이점도 존재하리라 봅니다.

보안적으로 좀 더 나은 방향으로 제시해주지 않을까 싶네요.

데이터를 직렬화를 함으로써 아마 사람이 보기는 힘든 형태의 패킷 데이터를 전송하지 않을까 합니다. (이부분은 나중에 연동작업하면서 까볼수 있으면 까봐야겠네요. (???))

또 한가지 흥미로운 부분은 Protocol Buffers를 사용함으로 인해 통신에 있어 송수신 측의 언어적 제약이 많이 사라지게 됩니다.

이게 무슨말이냐 하면 Proto3의 지원 언어목록만 봐도 C++, 자바, 파이썬, Go, 루비, Objective-C, C#을 지원하다보니,

이정도면 뭐.. 제가 추후 제작할 어플만 생각하더라도 Server단에서 Android, iOS로의 통신이 좀 더 쉬워지지 않을까 합니다.

좀더 쉽게말하자면 Server(Java) -데이터 전송-> iOS / Android의 형식이 쉬워질거라는 생각입니다. (아마 개발하면 또 달라질 수 있겠지만..)

마지막으로는 사용자에게 조금이나마 편리한 기능을 생각하고 있는 만큼 이 기능 저 기능 사용해서 좀 더 나은 서비스가 이루어진다면 그걸로 충분하다고 생각하기 때문에 괜찮은 기술이라면 한번 도입해서 사용하게끔 만들어주고싶습니다.

Protocol Buffers를 사용함으로써 생기는 단점?

흠.. 장점이 있다면 단점 또한 존재하겠죠?

단점은 뭐.. 아무래도 개발자인 제가 귀찮아질.... (하.하.하.)

사실 그렇게 꼭 필요하다 싶은 기능까지는 아니지만,

도입해서 나쁠것도 없고 나름 재밌는 공부도 될 듯 싶어서 나름 즐거워 하고 있습니다. (진지)

그나저나 문제는 템플릿을 밑바닥부터 해야하다보니 아무래도 시간이 걸릴 것 같다는 점이네요.

그냥 공짜템플릿 어디서 구해볼까 싶기는 하지만.. 아무래도 라이센스가 복잡하다보니..ㅠㅠ

그리고 이왕하는거 공들여서 깔끔하게 만들어봐야죠!

오늘은 이제 12시가 지났으니 월요일이네요. (내일이라고 하려다가 시간을 보니 마침 12시가 지났..)

많이들 피곤하시겠지만, 활기찬 한주가 되기를 바랍니다!

그럼 오늘도 화이팅!

Ref

https://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C_%EB%B2%84%ED%8D%BC

버전정보 (v1.0)

 - v1.0 2020.07.20 배포

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com

Project.다원 Ensemble_개발(3)_템플릿 제작 진행

음.. 어제 좀 피곤했던일이 있어서 많은 진척은 없지만, 템플릿을 깔짝 손봤습니다.

아무래도 Bootstrap 기반으로 만들다보니 Bootstrap의 느낌이 나네요. (그런 느낌?!)

1. Front단 - 템플릿 제작 진행 중

 - PC에서 봤을 때

 - Mobile에서 봤을 때

아마 메뉴부분은 저번에 만든 Wireframe을 기반으로 만들어보겠지만, 아마도 조금씩 변동사항은 생길것같네요.

메뉴 구성 Wireframe 부분은 아래 게시판으로 이동하시면 볼 수 있습니다. (링크)

아무래도 밑바닥부터 개발을 디자인과 병행하여 진행을 하다보니 여기서 시간이 좀 걸리지않을까 싶습니다.ㅠㅠ

2. Back단 - Class 골격 잡기 진행 중

현재 VO Class는 다 만들어진 상태이고,

Controller / RestController의 구조잡기가 한창입니다.

아마 DB연동하는 부분의 Class(Service, Mapper)는 조금 나중에 진행이 될 듯 합니다.

VO객체는 뭐.. Getter/Setter 만들어 주는거 말고는..

요즘 잠을 더 줄였더니 엄청 피곤하네요;;;

어제 불토라고 늦게까지 코딩이랑 공부랑 조금했더니 아마 그게 문제가 된 듯 합니다 ㅋㅋㅋ;;;;;

개발하는 내내 피곤한 상태라서 아마 내일은 조금 쉬고올까 합니다.

(간만에 컴퓨터 안하는 날?!)

오늘은 이르지만 좀 일찍 잠을 청해야겠습니다.

다음 시간에는 제가 RestController 부분에 넣어보고 싶은 기능이 있어 기능검토좀 들어가볼까 합니다.

속도면을 조금 올려줄 수 있을 방법같은데 어떨지 모르겠네요.

버전정보 (v1.0)

 - v1.0 2020.07.19 배포

* 저작권에 위반될 수 있는 컨텐츠(이미지, 동영상 등)나 게시글은 삭제되거나 수정될 수 있습니다.

* 문제의 여지가 될 수 있는 컨텐츠의 경우 댓글 달아 주시면 빠른 시일 내에 조치하도록 하겠습니다.

* Karzin은 항상 공부중입니다. 설명이 틀리거나 잘못된 부분이 있다면 의견내주시는대로 수정하도록 하겠습니다.

Project.다원은 개인(karzin)이 기획, 분석, 설계, 디자인, 개발, 유지보수 등

모든 부분을 혼자 맡아 진행하는 개인 프로젝트입니다.

Project.다원 Ensemble

Karzin

abbeea@naver.com