Whiteship's Note

[주말 코딩] 봄싹 위키

모하니?/Coding : 2010. 4. 4. 22:51



왼쪽에는 모든 위키 목록, 오른쪽에는 최근 작업한 페이지 목록.. 각 목록의 이미지를 클릭하면 하단에 설명 부분이 열립니다. 페이지 목록에서는 미리 보기 형태로 페이지를 보여주는데;; 디자인이 좀 깨지기 때문에 직접 가서 보는게 좋겠습니다. 해당 위키나 페이지로 이동하려면 이미지가 아니라 제목 주변을 클릭하시면 됩니다.

자바 코딩하는 데는 1시간도 안걸렸는데 화면 설계하고 코딩하는데 3시간 걸리네요. @_@;; 이렇게 보여줄까 저렇게 보여줄까? 이게 보기 편할까? 저게 보기 편할까? JQuery에 toggle을 어떻게 쓰더라. 옵션이 머지. accodoan을 써볼까 어쩔까.. 덩덩덩...

위키 목록은 Confluence REST API를 호출하여 가져오고, 최근 글 목록은 Confluence에서 최근 30일 내에 글 10개를 가져오도록 만들어 둔 Atom Feed를 사용해서 가져옵니다. 매번 요청할 때 마다 두 URL로 요청/파싱을 해서 그런지 느립니다. @_@;

내부 구현을 DAO를 사용하도록 바꾸는 작업은 KSUG에서 발표 할 때 해볼까 합니다.
1. 각 목록에 새로고침 버튼 추가.
2. 해당 버튼은 "관리자" 권한이 있는 사용자만 보이고 사용할 수 있음.
3. 새로고침을 누르면 WikiSpace와 WikiPage DB를 모두 비우고 새 데이터를 추가.
4. 위키 페이지 보여줌.
5. '일반' 사용자가 위키 페이지를 클릭하면 DB에 저장되어 있는 데이터를 가져옴.

이렇게 하면 아마 스프링 시큐리티, 스프링 MVC, 하이버네이트 코딩까지도 보여드릴 수 있을것 같습니다.
Comming Soon!
top

  1. Miracle 2010.04.05 16:02 PERM. MOD/DEL REPLY

    Wiki 정보를 굳이 DBMS로 관리해야할 자료인지 한번 생각해 봐야할것 같음.. ^^

    Favicon of http://whiteship.me BlogIcon 기선 2010.04.05 22:00 PERM MOD/DEL

    생각해봤는데요. 위에서 언급한 성능 문제나, 봄싹 위키 미가입자인 봄싹 가입자를 위한 서비스(즐겨찾기, 뷰 count, 비/추천 덩덩)를 생각하면 DB로 관리해야 될 것 같더라구요.

    Miracle 2010.04.06 12:04 PERM MOD/DEL

    현재 컨플런스에서 가공해준 데이터를 봄싹에서 가공해서 보여주는 방식이기 때문에 성능 문제는 캐싱 처리해서 해결 가능해보이고, 봄싹 가입자를 위한 서비스인 즐겨찾기 같은 기능은 위키 데이터와 별개로 보임. 즐겨찾기 기능은 전체 URL를 저장하는 걸로 구현해야할 듯~~

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2010.04.06 14:15 신고 PERM MOD/DEL

    글쿤요. 캐싱도 좋고 즐겨찾기 구현방식도 URL을 기준으로 하는게 일괄적으로 적용할 수 있어서 좋아보이네요.

    그런데 캐시를 위키 상태에 따라 계속 변경하는 거라차리면 만약 컨플루언스가 죽으면 위키 페이지도 같이 '멍'해지는 거죠?? DB에 저장해뒀으면 그냥 위키 페이지는 살아있고, 가장 최근 목록도 보여주면서, 이동하려고 했을 떄 "컨플루언스가 점검중"이라는 메시지만 띄울 수 있을텐데 말이죠.

    즐겨찾기 정보야 어떻게 관리하던, 해당 위키 스페이스나 페이지에 대한 관심과 호/불호 정보를 관리하려면 역시 DB에 넣는게 편하지 않을까요.. 흠..

    Miracle 2010.04.06 15:44 PERM MOD/DEL

    정보제공자(컨플)이 죽었는데.. 위키 페이지의 목록을 뿌려주는게 의미가 있을려나? ^^

    컨플 접속 불가능시 "컨플에 문제 발생"이라는 문구를 위키 페이지에 보여주는게 사용자의 클릭수를 줄일 수 있어 보임. 괜히 클릭했는데 점검중 나오는거 보다야 나을것 같구.

    다시 읽은 후에 추천/비추천은 어떻게 관리할 생각인지? 봄싹 페이지는 전체 자료를 가지고 있는게 아니라 컨플이 가지고 있는 페이지의 일부만 가지고 있으니, 추천/비추천한 자료의 신뢰성이 떨어지지 않을려나~~ ^^

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2010.04.06 16:57 신고 PERM MOD/DEL

    위키 공간 목록과 최신 글 목록을 보여주는게 아무것도 안 뜨는 것보다는 안정적이죠. 최신 글 목록에서 toggle로 글 내용도 볼 수 있으니 위키가 죽어있는 동안은 toggle로 만족할 수도 있을 겁니다.

    추천/비추천의 신뢰도라;; 아직 서비스를 완벽하게 구상한게 아닌데 이렇게 집요하게 나오시다니 당황스럽군요,

    추천/비추천, 즐겨찾기 덩덩의 서비스는 DB에 저장해 놨을 때 그 정보를 가지고 응용하는 서비스를 만들기 편할 것 같다는 예로 든 것일 뿐입니다.

    트위터를 보면.. 트위터 REST API를 사용해서 만든 수 많은 트위터 응용 사이트 들은 트위터 정보를 DB에 저장하지 않고 캐싱만 할까요? 그리고 트위터가 죽으면 그 사이트들도 전부 죽어야 되는건가요? 자기들만의 방어기제를 만들어 두는게 의미없는 짓인가요?

    저는 컨플루언스에 쌓이는 정보에 더 유용한 서비스를 붙여서 봄싹 위키에 보여줄 요량으로 그 정보들을 DB에 저장하려는 겁니다. 그러는 편이 매번 REST 요청/응답 파싱 Feed 요청/응답 파싱하는 것 보다 빠를 것 같고 응용 서비스 만들기도 편할 것 같기 떄문이죠.

    지금 당장 그런 서비스가 마땅치 않다고해서 DB를 쓰지말고 캐싱을 써야하는 건 아니지 않을까요. 캐싱으로 처리하는게 DB로 처리하는 것보다 간단했다면 모를까 저한테는 캐시 공유, 업데이트. 제거 전략을 고민하느니 DB를 사용하는게 쉽고 앞으로 만들 서비스를 생각했을 때도 데이터를 영속화하는 편이 좋아보입니다.

    흠 그래도 형은 나름대로 DB보다 캐싱을 써야하는 이유가 있어서 DB 사용을 반박하고 캐싱을 권하시는 것 같은데. 그 이유는 잘 짐작이 되지 않습니다.

    어떻게 하면 캐싱을 써서 컨플루언스 정보를 봄싹 위키와 연계하여 활성화 하고 발전 시킬 수 있을지 말씀해주시죠.

    Miracle 2010.04.07 20:13 PERM MOD/DEL

    3. 새로고침을 누르면 WikiSpace와 WikiPage DB를 모두 비우고 새 데이터를 추가.

    여기서 DB를 모두 비우게 되면, 자료를 DB로 저장할 필요가 없어 보인다는거지. 그리고 모두 비우기 때문에 캐쉬하는 방법도 완전히 지우고, 새로운 데이터로 채워 넣으면 그만이겠구.

    만일에 Wiki 목록을 계속 저장해두고, 활용할 서비스를 제공하겠다는 생각이 있으면, DB에 저장하면 되는거구.

    Favicon of http://whiteship.me BlogIcon 기선 2010.04.07 21:17 PERM MOD/DEL

    아. 그렇군요. 그 부분 때문에 휘발성 데이터를 영속화 시스템을 이용한다니까 이상하게 여기신거군요.

    생각해보니 그렇네요. 날리면 안되겠어요. ㅋㅋ

    Miracle 2010.04.07 22:48 PERM MOD/DEL

    영속화 시킬때는 중복 데이터가 들어가는 걸 막을 수 있게 PK 설정을 잘해야 할것 같음.

    Wiki가 그렇게 활발하게 업데이트되지 않을테니까..

    Favicon of http://whiteship.me BlogIcon 기선 2010.04.08 10:03 PERM MOD/DEL

    넹 페이지마다 키값이 있을꺼에요. URL에 있을텐데.. 흠냐.
    위키는 키값이 JSON으로 넘어오니까 괜찮구요.

Write a comment.




: 1 : ··· : 14 : 15 : 16 : 17 : 18 : 19 : 20 : 21 : 22 : ··· : 299 :