Karzin Lab

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_기능검토(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_기능검토(1)_QRCode (Sequence Diagram)

얼마전 저는 장비관리에 QRCode 기능을 넣을 생각을 했습니다. (Project.다원 Ensemble_개발(0)_사전 준비)

어떻게 넣을까 고민을 하며 찾아본 결과 구현 가능성이 높아졌고, 제대로된 기능검토가 필요하다고 생각이 들어서 준비했습니다!

QRCode의 생성방법 두가지

QRCode를 생성하는 방법으로 크게 잡아보자면 두가지 방법이 있습니다.

첫번째는 jQuery(Front단)를 이용해 만들어버리는거고, 두번째는 java(Back단)를 이용해 만드는 방법입니다.

둘의 차이는 서버를 경유하냐 마냐의 차이가 되겠습니다.

 - 1. Web-jQuery (Front)

  -> qrcodejs - (https://github.com/davidshimjs/qrcodejs)

  -> License : MIT License

  -> 장점 : 서버를 경유하지 않아 개발자인 제가 편리, 서버가 연결되지 않아도 QRCode의 생성 가능

  -> 단점 : 유저가 클릭을 할 때마다 브라우저에서는 QRCode를 만들어내야함. 

 - 2. Java (Back)

  -> ZXing Core - (https://github.com/zxing/zxing)

  -> License : Apache 2.0

  -> 장점 : 한번 생성을 해두고 image로 만들어두면 반복된 사용이 가능, front단의 부하를 줄일 수 있음

  -> 단점 : Java단에서 구현을 해야하고(즉, 코드의 수정이 필요한 경우 서버의 배포가 필요.), 이미지를 계속해서 관리를 해주어야함. 개발자인 제가 귀찮아짐.

그렇다면 선택은?

고민은 3초정도 했고, 결과적으로 Java소스 기반의 ZXing Core를 사용할겁니다.

서버에서 QRCode를 한번 이미지로 만들어두면 계속된 재사용이 가능하고, 이미지만 뿌려주면 되다보니 구형PC든 뭐든 어디서든 바로바로 확인이 가능하기 때문에 프린팅도 금방할거라 판단되었습니다.

Front단에서 만드는 QRCode도 그닥 오랜시간은 걸리지 않겠지만, 혹시라도 구형 태블릿을 활용하시는 분들이 불편할 수 있을 것 같아서 내린 판단입니다.

그리고 Front단을 포기하게 만들게된 결정적인 사항중에 하나입니다만,

ZXing를 사용하면 저에겐 굉장한 이득이 있습니다!

바로 추후 고려중인 Android NativeApp(장비관리)에 소스를 이식 시킬 수 있다는 것이죠. (!!!!!)

이런게 바로 일석이조 아니겠습니까 (잔머리만 잘 굴리네요ㅋㅋㅋㅋ)

QRCode 생성-Sequence Diagram

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

* 위 이미지에 들어간 내용은 전부 (픽토그램 등) 직접 제작했음을 명시합니다.

우선 Exception에 대해서는 고려하지 않았습니다.

한가지 고려를 해보자면 그럴일은 없어야 하지만, DB저장까지 완료되었는데, QRCode 생성할때 Exception이 일어나면 어쩔것인가? 라는 질문에 대한 답변에는 일단 그런 경우가 생기면 안되겠지만 만일 일어난다면 QRCode는 생성하지 않게 합니다.

데이터의 저장은 완료되었으나, QRCode만 생성은 안되는 것이죠.

그럼 QRCode는 버리는것인지? 아닙니다.

추후 user가 QRCode를 확인하는 페이지에 방문을 하면 만일 QRCode가 생성이 안되어 있는 경우 생성을 하게 만드는 것이죠.

오늘은 그간 검토해본 QRCode에 대해서 파악을 해보았습니다.

시간적 여유만 된다면 Front, Back 둘다 구현은 해보고 싶네요 ㅋㅋㅋ

오늘은 불토입니다! 이제 소스나 신나게 구현해야겠습니다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

버전정보 (v1.0)

 - v1.0 2020.07.18 배포

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

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

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

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

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

Project.다원 Ensemble

Karzin

abbeea@naver.com