태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

BitBucket 대 GitLab

구글링 2015.04.23 02:35

원문링크: https://about.gitlab.com/2015/04/15/bitbucket-vs-gitlab-com/


#의역이 난무하므로 정확한 정보는 원문을 확인하세요

#원문은 GitLab.com에서 작성하였으므로 BitBucket을 까는 글입니다.


BitBucket vs. GitLab.com


오픈소스 프로젝트가 최선인 이유는 - 특히 GibLab의 경우, 커뮤니티 때문이다. 커뮤니티가 그냥 필요한 피드백을 제공해주는 것만 아니라, 사용자가 요청한 쿨한 새로운 기능들을 보내준다는 점이다.


이 점에서 - 수많은 새 기능의 요청을 받아놓고 사용자들에게 그다지 응답하지않은 - BitBucket과 차별화된다.


당신들중 몇몇을 BitBucket에서 GibLab.com으로 이전을 고려할 확신을 주기위해, 우리는 BitBucket과 차별화된 장점을 기재해보려고 한다. 당신의 코멘트를 환영해요~





GitLab.com 과 커뮤니티 에디션(Community Edition)은 완전히 무료


반면에 BitBucket은 5명까지만 무료로 쓸수 있다. GitLab.com은 완전히 무료다. 당신만의 1000개의 저장소(repositories)를 호스트해서 100명의 동기들과 작업하고 싶다고? GibLab.com에선? 무료다.


1000명의 직원이 있는 당신만의 서버를 돌리고 싶다고? 당신만의 환경을 설정해서? 무료다.


우리는 소스코드 호스팅은 그냥 생필품이라고 생각해. 그래서 누구에게나 무료로 이용가능해야한다고 믿어.

게시판이나 지메일이나 페이스북을 통해서 일반적인 고객지원을 하는거지.

만일 당신이 이메일을 통해 고객지원을 받고싶다면 우리의 이메일 구독을 고려해봐 (주, 유료서비스임)

하지만 이거 없어도 GibLab 엔터프라이즈 에디션을 쓴다면 GibLab의 모든 기능을 다 활용할 수 있다.




GitLab의 아름다운 디자인


일단 그냥 봐

Nice design of GitLab



기여자 통계 (Contributor Statistics)


BitBucket의 기능요청 목록에 상위랭크된 기능이지? 우리는 이미 지원한지 몇년됬어

Contributor graphs

Commit graphs



저장소 그룹화 (Group your Repositories)


그룹화하면 여러개의 저장소의 사용자와 접근권한, 통합등등을 쉽게 관리할 수 있지


우리는 BitBucket의 그룹(팀)기능이 - 저장소를 체계화하고, 협엽자들간에 권한을 제한하며, 그룹 저장소를 실제로 사용하게한다기 보다 자신들의 Subscription(주, 유료서비스임)을 더 팔려고 유도한다는 점에서 - GitLab만큼 유동적이지 않다고봐. 

groups


멋진 기능으로, 당신은 GitLab안의 프로젝트들을 "별표"(Starred)쳐놓을 수 있다는 거야. 당신이 저장소를 많이 가지고 있다하더라도 손쉽게 관심사에 집중할 수 있으니까 저장소를 쉽게 체계화 할 수 있는 하나의 방법이지. 




소스코드 검색 (Source code Seaerch)


어떤 프로젝트의 소스코드를 검색하고 싶어? 프로젝트의 상단바에 아무거나 쳐봐 그럼 GibLab은 해당 저장소. 등록된 이슈들과 프로젝트안에 있는 어떠한 것이든 그 모든 컨텐츠를 검색할 거야

search



세련된 권한 관리 (Fine grained permission management)


누군가에게 이슈트래커에 접근할수없게 제한을 두고싶다고? 근데 저장소를 제한이 없어야한다고? 가능하지!


누군가에게 그룹저장소의 읽기 권한만 주고 싶다고? 쓰기권한은 안되고? 가능하지!


어떤 종류의 GibLab 동물 로고를 쓸지 토론하고 싶다고? 가능하지!




Git Hooks


GibLab 엔터프라이즈 에디션은 당신이 간단히 골라서 사용할 수 있는 pre-built Git Hooks 리스트가 있어



지속적 통합이 함께야 (Comes with a CI)


GibLab 설치를 하면 Github CI (continuous Integration)툴이 같이 설치되니까  GitLab.com 사용자들은 gi.gitlab.com에서 무료로 사용할수 있어. GibLab과 완전히 통합된 환경이어서 어느 브랜치의 빌드상태, 소스 합치는 요청(merge request) 그리고 이후 당신의 디플로이 환경을 자동으로 돌리는 것등을 쉽게 확인해볼 수 있어

GitLab CI integration




Bitbucket, GitHub 등등에서 가져오기 (Import from Bitbucket, GitHub, anywhere)


GibLab으로 시작하고싶어? 당신은 아주 쉽게 Bitbucket이나 GitHub, Gitorious등등에 있는 당신의 저장소를 가져올수 있다. batch로 한방에!

Import from anywhere




Posted by K 얼바인



바람직한 UI #1-15 로 가기



16. 링크 도배보다는 집중하게 하라


가능한 많은 유저들의 요구에 맞추기위해 좌든 우든 페이지에 링크를 많이 달기는 쉽다. 하지만 당신이 Bottom에 반응을 요구하는 의도의 서술적 페이지를 만든다면 두번 생각해라. 페이지내의 많은 링크들은 당신이 반응하길 원하는 것에 고객이 집중할수없게 만들것이다. 중요한 버튼에 도달할 누군가의 확률을 높이는 확실할 방법은 주제와 관련없는 링크를 없애는 것이다.



17. 현재 상태를 보여주려고 애써라


UI에서 이메일의 읽음/읽지않음, 또는 청구서의 결재완료/미납등과 같이 현재의 서로 다른 상황을 보여주는 요소들을 매우 자주 볼수있을 것이다. 한 아이템의 특정한 상태를 사용자에게 알려주는 것은 피드백을 제공하는 좋은 방법이다. 현재 상황를 알려주는 것은 사용자들이 무언가 액션을 취해야한다는 것 뿐아니라 이전에 취한 액션이 성공적이었는지 아닌지 쉽게 이해할수있다.




18. 그냥 흔한 버튼보다는 버튼에 혜택이 있음을 알려라


한 페이지에 보이는 두개의 간단한 버튼을 생각해보자. 하나는 "돈을 아낄수있음" 이라고 적혀있고 다른 하나는 "가입하기"라고만 써있다. 나는 첫번째 버튼이 더 많이 이용될거라는데 내 중요한 거 두개를 건다. "가입하기"는 그 안에 내포된 어떠한 가치도 없는 주제에 그 절차는 어떠한 긴 양식을 채워야하는 노력이 필요하다. 무언가 혜택을 강조하는 버튼은 더높은 회원가입을 이끌거라는 가정에 기초하며, 반대로 그 혜택은 또한 왜 사람들이 그 액션의 취해야하는지 상기시키기 위해 해당 액션 버튼 인근에 배치할수도 있다. 물논 그 흔한 버튼들이 존재할 이유는 충분하지만 어디까지나  무언가 설득할 필요없이 명확하고 반복적으로 사용되는 곳에 적합하다.



19. 연관성 없는 메뉴를 거치지않고 그 즉시 편집가능하게 하라


간혹 연관성이 없는 일반적인 액션들을 나열해두는 것보단 해당 요소들에서 바로 액션을 가능하게 만드는게 이해하기 쉽습니다. 예를 들어, 데이터의 리스트를 보여줄때, 우리는 보통 사용자에게 리스트의 해당 아이템내에서 무언가 하도록 만드려고 합니다 - 이 리스트내에서 클릭 또는 호버(마우스를 올려놓는것)를 통해 해당 아이템의 삭제, 이름변경 등과 같은 편집이 가능하게 할수 있습니다.

또 다른 즉시 편집의 흔한 예로, 한 (주소데이터와 같은) 아이템을 클릭하면 편집가능한 입력폼으로 바꾸어 주는것입니다. 이러한 상호작용을 통해 연관성이 없는 메뉴를 거쳐 동일한 일을 하는 것보다 필요한 과정을 줄이는 것이 가능합니다 (일단 해당 아이템이 이미 선택이 되어 있으므로). 물론 일반적으로 아이템을 선택할 필요가 없다면 연관성없는 메뉴를 쓰는데 전혀 지장이 없습니다.



짬짬이 진행중이나 개인적으로 요새 시간이 안나므로 혹시 이후가 궁금하신분들은

두두리이님께서 알려주신 링크로 대체합니다 두두리이(http://doodoori2.tistory.com/)님 감사합니다

https://docs.google.com/presentation/d/14KJfuZiTL1VKt5U5N0jIgdoF76_FJhjVSPvP3lJLMC8/edit#slide=id.p

개인적으로는 이렇게 친절한 문구를 안좋아라해서 시간나는대로 번역을 하나씩 늘려갈생각입니다



20. Try Exposing Fields instead of creating extra pages


When creating landing pages that convey value, it can be beneficial to show the actual form fields on the conversion page itself. Merging the sign up form with the landing page comes with a number of benefits in comparison to creating separate multi-page sign ups. First, we are cutting out extra steps from the flow in general and the task at hand takes less time. Secondly, by showing the number of form fields right there, we are also providing the customer with a sense of how long the sign up actually is. This of course is a little easier when our forms are shorter in the first place (which of course they should be if possible).


21. Try Transitions instead of showing changes instantly.


Interface elements often appear, hide, move, shift, and resize as users do their thing. As elements respond to our interactions, it sometimes is a little easier to comprehend what just happened when we sprinkle in the element of time. A built in intentional delay in the form of an animation or transition, respects cognition and gives people the required time to understand a change in size or position. Keep in mind of course that as we start increasing the duration of such transitions beyond 0.5 seconds, there will be situations where people might start feeling the pain. For those who just wish to get things done quickly, too long of a delay of course can be a burden.



22. Try Gradual Engagement instead of a hasty sign up.


 Instead of asking visitors to sign up immediately, why not ask them to first perform a task through which something of value is demonstrated. During such initial interactions the product can both show off its benefits, as well as can lend itself to personalization. Once users begin to see your product’s value and see how they can make it their own, they will then be more open to sharing with you additional information. Gradual engagement is really a way to postpone the sign up process as much as possible and still allow users to use and customize your application or product.




23. Try Fewer Borders instead of wasting attention. 


Borders compete for attention with real content. Attention of course is a precious resource since we can only grasp so much at any given time. Surely borders can be used to define a space very clearly and precisely, but they also do cost us cognitive energy as they are perceived as explicit lines. In order to define relationships between screen elements which use less attention, elements can also be just grouped together through proximity, be aligned, have distinct backgrounds, or even just share a similar typographic style. When working in abstract UI tools, it’s easy to drop a bunch of boxes everywhere. Boxes however come with a false sense of being immune from the order and unity which governs the rest of the screen. Hence pages with lots of boxes sometimes may tend to look noisy or misaligned. Sometimes it is helpful to throw in a line here and there, but do consider alternative ways of defining visual relationships that are less taxing to attention and your content will come through.



24. Try Selling Benefits instead of features.


I think this is Marketing 101. People tend to care less about features than they do about benefits. Benefits carry with them more clearly defined value. Chris Guillebeau in "The $100 Startup" writes that people really care about having more of: Love, Money, Acceptance and Free Time, while at the same time wishing for less Stress, Conflict, Hassle and Uncertainty. When showing features, and I do believe that there is still room for them occasionally, be sure to tie them back to benefits where possible.



25. Try Designing For Zero Data instead of just data heavy cases.


There are cases when you will have 0, 1, 10, 100, or 10,000+ data results which might need to be displayed somehow in various ways. The most common of these scenarios is probably the transition from first time use with zero data towards future use with a lot more data. We often forget to design for this initial case when there is still nothing to display whatsoever, and by doing so we run the risk of neglecting users. A zero data world is a cold place. When first time users look at your app and all it does is show a blank slate without any guidance then you’re probably missing out on an opportunity. Zero data states are perfect candidates for getting users across the initial hurdle of learning by showing them what to do next. Good things scale and user interfaces are no exception.



26. Try Opt-Out instead of opt-in


An opt-out strategy implies that users or customers are defaulted to take part in something without having to take any action. Alternatively, there is also the more traditional opt-in strategy that requires people to first take an action in order to take part in or receive something. There are two good reasons why opt-out works better than opt-in. First it alleviates resistance on the path of action, as the user does not have to do anything. Secondly, it’s also a form of recommendation which implies some kind of a norm - “since everyone else takes this as it is, I might also do the same”. Of course the opt-out strategy is often perceived as controversial as there are those sleazy marketers which will abuse it. One such evil is to diminish the readability of the opt-out text, while another is to use confusing text, such as double negatives. Both examples will result in users being less aware of actually signing up for something. Hence to keep the ethics in check, if you do decide to go with an opt-out approach, do make it very clear and understandable to your customers what they are being defaulted into. After all, this tactic has also been used in Europe to save lives.


27. Try Consistency instead of making people relearn.


Striving for consistency in user interface design is probably one of the most well known principles since Donald Norman’s awesome books. Having a more consistent UI or interaction is simply a great way to decrease the amount of learning someone has to go through as they use an interface or product. As we press buttons and shift sliders, we learn to expect these interaction elements to look, behave and be found in the same way repeatedly. Consistency solidifies the way we learn to interact and as soon as it is taken away, we are then forced back into learning mode all over again. Consistent interfaces can be achieved through a wide possible range of things such as: colors, directions, behaviors, positioning, size, shape, labelling and language. Before we make everything consistent however, please let’s bear in mind that keeping things inconsistent still has value. Inconsistent elements or behaviors come out into attention from the depths of our habitual subconscious - which can be a good thing when you want to have things get noticed. Try it, but know when to break it.



28. Try Smart Defaults instead of asking to do extra work.


Using smart defaults or pre-filling form fields with educated guesses removes the amount of work users have to do. This is a common technique for helping users move through forms faster by being respectful of their limited time. One of the worst things from an experience and conversion stand point is to ask people for data that they have already provided in the past, repeatedly over and over again. Try to display fields that are preloaded with values to be validated as opposed to asking for values to be retyped each time. The less work, the better.



29. Try Conventions instead of reinventing the wheel.

 

Convention is the big brother of consistency. If we keep things similar across an interface, people won’t have to obviously struggle as hard. If on the other hand, we all keep things as similar as possible across multiple interfaces, that decreases the learning curve even further. With the help of established UI conventions we learn to close screen windows in the upper right hand corner (more often than not), or expect a certain look from our settings icons. Of course there will be times when a convention no longer serves purpose and gives way to a newer pattern. When breaking away, do make sure it’s purposefully thought out and with good intention.



30.  Convention is the big brother of consistency.


 If we keep things similar Try Loss Aversion instead of emphasizing gains. We like to win, but we hate to lose. According to the rules of persuasive psychology, we are more likely to prefer avoiding losses than to acquiring gains. This can be applied to how product offerings are framed and communicated. By underlying that a product is protective of a customer’s existing well-being, wealth or social status, such strategy might be more effective than trying to provide a customer with something additional which they don’t already have. Do insurance companies sell the payout that can be gained after the accident or the protection of the things we hold dear to us?across an interface, people won’t have to obviously struggle as hard. If on the other hand, we all keep things as similar as possible across multiple interfaces, that decreases the learning curve even further. With the help of established UI conventions we learn to close screen windows in the upper right hand corner (more often than not), or expect a certain look from our settings icons. Of course there will be times when a convention no longer serves purpose and gives way to a newer pattern. When breaking away, do make sure it’s purposefully thought out and with good intention.




Posted by K 얼바인

반응형 웹디자인이 대세고 그중 단연 원탑은 부트스트랩이긴하지만 부트스트랩이 상대적으로 무거운것도 사실이므로 Customize 메뉴를 통해서 안쓰는 기능을 제거하고 compact하게 쓰려고 하는데 특히 부트스트랩 모달팝업을 대체하려고 알아보다가 정리해보았습니다.


2014년 4월 기준




Boxer (http://formstone.it/components/Boxer/demo/index.html)


모바일 프렌들리하고 iframe을 사이즈별로 잘 지원한다는것빼고 큰 메리트는 없지만 사이즈가 작고 무난함







Bootbox.js (http://bootboxjs.com/)


부트스트랩 모달이 필요하며 좀더 편하게 사용할수있게 만들어놓은 wrapper라이브러리.

아주 기본적인 모달을 손쉽게 쓰는 용도일뿐





JQuery Popup Overlay(http://vast-engineering.github.io/jquery-popup-overlay/)


가볍도 쓰기편하고 아주 잘만든 라이브러리라 메인으로 쓰려고 했는데 모바일에서 모달이 잘 안닫히는것같아 포기한 비운의 녀석






CSS Modal (http://drublic.github.io/css-modal/)


기본 테마가 좀 안이쁘지만 가장 사이즈가 작고 가벼운 놈으로 빠르다







Remodal (https://github.com/VodkaBears/Remodal)


나온지 2달밖에 안됬지만 가볍고 모바일 지원도 잘되는 쓸만한 녀석







jQuery Custombox (http://www.jqueryrain.com/?0DfA2wTl)


흠잡을데 없고 무난하나 css가 23k, js가 34k 니까 Remodal이나 CSS Modal의 8~10배 크다

기본적인 이펙트 효과를 쓰고 싶으면 괜찮을듯






가벼운걸 자랑하는 만큼 사이즈도 작고 빠름. CSS Modal보단 나을것같으므로 가장 심플하고 가벼운 모달용으로 괜츈할듯




현재까지는 Remodal이 개인적으로 제일 나아보입니다





Posted by K 얼바인

원문: http://www.jiwhiz.com/post/2012/11/Goodbye_JSP_Hello_Thymeleaf

예전에 스크랩해둔 중국아저씨 글인데 이분이 블로그를 내려서 링크가 죽었습니다. (수정) 다시 살아났네요 어쨌든 저는 이글 쓰신분과 같은 경험과 느낌으로 타임리프를 시작했습니다. 사실 이분이 이글 올린날 어쩌다 읽게되고 GWT에서 Thymeleaf로 갈아탔습니다. 그게 예전에 이글을 스크랩해둔 이유기도 하구요.

현재 이분은 Thymeleaf에서 Angularjs로 옮겨가셨고, 저도 요새 앵귤러js로 타임리프로 만든 일부 페이지를 바꾸고 있었는데요 뭐 저처럼 앵귤러와 타임리프를 같이 돌려도 상관없습니다 하지만 순수 Angular js는 SEO에 문제가 있고, 그리고 개인사이트나 블로그가 아닌 엔터프라이즈급 자바솔루션, 특히 스프링기반에서는 여전히 타임리프는 훌륭한 선택이라고 생각합니다 (성능이나 learning curve, 소스컨트롤 차원에서나 JSF/Tiles나 GXT/GWT보다 낫다고 생각합니다.).

편의상의 반말 양해부탁드리고 싶지만 사실 방문자가 거의 음슴으로 그냥 전개~


잘가 JSP, 어서와 타임리프


JSP는 뭐 사실상 자바세계에서 웹페이지 만드는 표준이지. 나는 12년전 캐나다에서 첫직장을 잡은 이후 줄곳 JSP를 써왔어. 서블릿(Servlet)+JSP로 시작해서 스트럿츠(Struts)+JSP, 이후 JSF+JSP까지 써봤어. 다른 프로젝트에서도 스프링MVC랑 역시나 익숙한 JSPX를 썼어


프리메이커(FreeMaker)나 벨로시티(velocity), 사이트메쉬(SiteMash)같은 html템플릿 엔진의 몇몇 자바 라이브러리들이 있지만 난 JSP만 썼어. 왜 귀찮게 다른거 배워? 근데 최근에 생각이 좀 바꼈어 왜냐면 JSP가 부트스트랩이랑 같이 돌리는데 아주 엿같거든


처음 부트스트랩봤을때 이건 내가 아주 오래전부터 원했던거라 충격적이었어. 내가 여태 블로그사이트를 만들지 않은 이유는, 난 그래픽 디자인에 완전 젬병이거든. 내 첫글(주, 링크가 깨져서 알수없음)을 봐, 지금은 부트스트랩을 쓴다고, 난 이제 그래픽 디자이너없이도 쿨한 웹사이트를 만들수있어.


난 바로 부트스트랩을 다운받아서 내 블로그어플에 넣었어 시작은 무지 쉬웠어 내 코드에 큰 변화는 없었으니까 그냥 CSS 클래스속성을 내 JSP파일에 넣었을 뿐인데 내 블로그 페이지들은 엄청 이뻐졌지.


근데 문제는 그다음부터야, 드랍다운 메뉴가 작동하지않는거야 나는 내가 뭔가 실수했다고 생각했는데 구글링해보니까 비슷한 이슈를 레포트한 사람들이 있더라고, 근데 그 이슈들이 내 경우와 딱 맞아떨어지진 않았어. 난 정확하게 부트스트랩이 하란대로만 했거든 jquery.js 먼저넣고 bootstrap.js파일은 그후에 넣고. 최신의 jQuery 다운받았고, 예제에 나온 그 코드 그대로 복사해다 넣었어. 근데 드랍다운 메뉴가 여전히 작동을 안하는거야 아 정말 미치겠드라고


결과적으로 내가 한거는 드랍다운 메뉴 하나 딸랑있는 메뉴바만 있는 아주 간단한 html 페이지를 만들어서 크롬에서 먼저 도는걸 확인하고 그걸 그대로 테스트 jsp파일로 복사해다가 돌려보니까 작동을 안하더라고.. 그래서 원문 html 코드라인과 서버가 만든 html 코드를 한줄한줄 비교해서 찾아냈어!!!


생성된 html 스크립트 엘리먼트는:


<script type="text/javascript" src="http://code.jquery.com/jquery-latest.js"/> 


이렇게 태그를 셀프클로징하는데 원문소스는 아래처럼 클로징 태그가 있었어:


<script type="text/javascript" src="http://code.jquery.com/jquery-latest.js"></script>

 

딱 이것만 다르더라고 


원인을 찾았으니 해결은 쉬웠어. 스크립트 엘리먼트에 코멘트를 넣어서 생성된 html이 클로징 테그를 만들게 했더니 드랍다운 메뉴가 돌더라고. 코딩이 아닌 문제해결이나 온라인 문서읽기, 검색해서 답찾는 삽질을 거쳐서 결국 해결하는 과정은 나름 재미는 있었지만 너무 많은 시간을 써야했어


어쨌든 다시 기쁘게 코딩했고, 내 어플을 CloudFoundry (주, 지금은 유료화된 vmware에 운영하는 클라우드 호스팅서비스)에 디플로이 했는데 웹사이트가 좀더 다듬어져야할것같았어 그래서 wrapbootstrap (주, 수백가지 부트스트랩 테마를 유료로 구매할수있는 사이트) 을 검색해서 이쁜 테마를 하나샀어. 이때 불행하게도 테마 패키지안에는 다른 리소스 파일들과 꼴랑 몇개의 css와 html 파일들만 있더라고 (주, 구매전엔 파일의 구성을 알수없음) 브라우저에서 잘동작하는걸 확인하고 내 어플에 복사했는데 왜 돌지를 못하니.. 이를테면 헤더 레이아웃은 오류가 있었고 사진들의 위치도 맞지않았어. 이때의 나는 문제를 찝어내기가 너무 어려웠어 왜냐면 css와 html 코드들이 너무 많았거든. 나는 밤새도록 삽질하다 결국 삽질을 멈추고 다른 해결법을 찾기로 했어


그때 스프링소스의 누군가가 JSP를 대체할만한 오픈소스 프로젝트를 언급한걸 기억해냈어 그래서 스프링소스 사이트를 가서 블로그 글 Spring MVC: from JSP and Tile to Thymeleaf 찾아냈어. 언뜻 보기에 타임리프는 아주 쿨한 프로젝트같았어 그래서 함 시도해보기로 했지.


일단 온라인 문서와 튜토리얼을 읽었는데 문서화가 아주 잘되있더군. 그래 타임리프는 JSP같은 XML/HTML 템플릿 엔진이야 근데 템플릿화하는걸 엘리먼트(element)대신 속성(Attribute)을 사용한대. 이건 예전에 썼던 JSF나 Facelet같더라고 Facelet은 JSF와 같이 써야는데 난 내 프로젝트용으로 자바EE를 건드리고 싶지않았어 이미 충분히 고통받았었으니까 말이지.


나는 웹어플리케이션 프레임워크로 SpringMVC를 선택했고 타임리프는 스프링MVC와 궁합이 아주 잘 맞았어. 타임리프는 스프링MVC와 스프링 시큐리티를 위한 dialect를 제공해주지 끝내준다고.


일단 타임리프로 jsp를 대체하려면 다음의 절차를 밟으면 되.

  • 블로그 테마 html파일을 내 프로젝트 폴더로 복사
  • 타임리프 dialect를 사용해서 디비에서 오는 동적 데이터를 마크업과 교체
  • 브라우저를 열고 html 파일이 잘도는지를 확인하고
  • 그냥 서버를 돌려서 페이지를 열어서 데이터를 가져오게하면 마크업페이지와 똑같이 보일거야

전환프로세스는 놀라울정도로 부드러워 난 내가 필요로하는 반복연산, 문자출력이나 조건문 등이 어떤 Attribute인지 단지 문서를 검색해가면서 거의 시간을 들이지않고 습득할 수 있었어. 그 다음 타임리프 attribute을 추가하는 예제를 그냥 따라했어 추가하거나 바꿔줘야하는 태그도 없었지. 그냥 브라우저 창을 두개 띄워서 하나는 원문 html, 다른 하나는 웹에서 도는 거 용으로 썼어, 매번 아주 작은 수정으로 브라우저 창을 새로고쳐서 바뀐게 있나 확인했을 뿐이야. 내가 본 차이점은 그래픽이나 레이아웃이 아니고 디비에서 가지고 온 데이터가 있냐 없냐 뿐이었어. 모든게 놀라울정도로 완벽햇어.


난 정말 원본의 그래픽 디자인에 동적인 컨탠츠를 추가하는 타임리프의 디자인방식을 좋아해. 서버의 재시작없이 수정한걸 저장하고 브라우저의 새로고침만으로 수정한걸 확인할수있는 Eclipse IDE (주, STS tc server 돌린듯) 도 고마워. 꿈은 이루어진다, 이제 JSP는 정말 작별이야




Posted by K 얼바인

개인적으로 Bootstrap을 대체할만한 CSS 프레임워크를 알아보다 정리해봤습니다.

객관성이 결여된 매우 주관적인 코멘트가 함유되어있으며 순위의 기준은 없습니다

맨아래 레퍼런스 사이트를 링크해뒀으니 더 많은 종류와 객관적 평가를 알고 싶으신분들은 참고하세요

이미지를 누르면 해당 사이트로 이동합니다.


1. Bootstrap

가장 많은 사람들이 쓰고 가장 널리 알려진 부트스트랩입니다. LESS를 사용하였으며 12컬럼 반응형 그리드 시스템, 수많은 위젯, 컴포넌트, 자바스크립트 플러그인을 지원하며 다운받을때 원하는 기능만 커스터마이즈 할수있습니다. 

두말할것없는 최고의 프레임워크이나 2013년부터 Mobile First를 내세운 새 프레임워크들에게 도전받고있으며, 너무 흔해져버린 부트스트랩 기반의 웹사이트들에 사람들의 거부감도 있는 편입니다 하지만 2013년 7월 기준 조만간 Mobile first 기준으로 업데이트될 Bootstrap3가 릴리즈되면 더욱 인기를 끌겠죠.. 다른 프레임워크들은.. 아마 안될거야..



2. Foundation


2013년 2월에 최초의 Mobile first 프레임워크라는 캐치로 릴리즈된 Foundation4. Sass와 Compass를 사용하였습니다 

사실 부트스트랩보다 더 오래된 프레임워크로 현재 부트스트랩 아성에 버티는 거의 유일한 프레임워크로 골수팬들이 많이 있습니다. 구글링해보면 CSS 프레임워크 비교보다는 부트스트랩 vs 파운데이션 뭐가 더 낫나? 이런 글이 더 많을 정도지요 핵심이 되는 그리드 시스템은 거의 대동소이합니다. 클래스 명명법이 부트스트랩 span9, 파운데이션 nine columns 이런식으로 좀 다르죠. 부트스트랩이 질렸거나 지금 당장 Mobile first시도하고 싶으시면 괜찮을것같습니다.


아래는 가장 최근의 부트스트랩과 파운데이션 릴리즈를 기준으로 비교해놓은 사이트입니다. 
이 사이트는 업데이트가 있을때마다 지속적으로 갱신하므로 계속 주시할만한 곳입니다.




3. Pure: CSS Framework

올해 2월에 혜성같이 등장한 야후의 CSS Framwork Pure 입니다. 부트스트랩같은 여타 프레임워크들이 Modernizr를 싸용하는 반면 Pure는 nomalize.css를 사용하여 기본 레이아웃에 자바스크립트를 배제한것이 특징입니다

아주 작은 사이즈의 css 파일단위로 쪼개서 레이아웃이나 버튼, 테이블같은 컴포넌트들을 원하는것만 골라 쓸수있다는 장점이 있습니다. 아직 0.2 버전의 초기단계이긴하지만 충분히 쓸만하다고 생각합니다.
영어 울렁증이 있으신분들은 야생코딩이라는 분이 한글로 번역해놓은 데모사이트[링크]를 돌리고 계시니 참고하시기 바랍니다. 야생코딩님께 무단링크해서 죄송합니다


4. Skeleton

반응형, 모바일 친화적인 개발이 가능한 작은 보일러플레이트입니다. 가벼운 960 그리드기반으로 사이트의 기초를 빠르게 설계할수있습니다. 작년까지 어느정도 인지도가 있었는데 2012년 6월이후 1년넘게 업데이트가 없어서 개인적으로는 추천하고싶지않습니다.


5. Base Framework

LESS로 개발된 12컬럼 960px 그리드 기반의 CSS 프레임워크입니다. 컴포넌트, 위젯등이 올인원 패키지로 배포됩니다.



6. Gumby Framework

SASS와 Compass로 개발된 반응형 960 그리드 기반의 프레임워크입니다 부트스트랩과 같이 버튼, 폼, 네비게이션과 같은 UI 키트를 제공해주며 다운받을때 Customize를 통해 원하는것만 취할수있습니다. 2013년 5월 버전 2가 릴리즈 되고 꾸준히 업데이트 되고있는 프레임워크입니다.



7. Responsive Grid System

이름이 반응형 그리드 시스템입니다. 공식홈에 '반응형 그리드시스템은 프레임워크가 아닙니다. 보일러플레이트도 아닙니다 반응형 웹사이트를 만드는 빠르고 쉽고 유동적인 방식입니다.' 리거 써있습니다.

개발시 커스터마이즈해서 사용해야할것같은데 예제사이트들을 보면 매우 정교하지만 그와 같이 사용하려면 미디어 쿼리같은 충분한 내공이 있어야할것같습니다.



8. Columnal

 1140px 기반의 반응형 CSS 프레임워크입니다. 스케치와 플랜짜는 용도의 그리드 시스템에 관한 PDF문서와 빠른 개발을 위한 wireframe 템플릿이 패키지에 들어있습니다. 대부분 최신 브라우저를 위한 미디어 쿼리와 IE6와 7용 다운그레이드돤 12컬럼 984 또는 960px 와이드 버젼이 제공됩니다. 이미지나 미디어의 폭이나 높이를 정의하지않아도 자동으로 줄여서 맞춰줍니다. Creative Commons Attribution-ShareAlike 3.0 United States 라이센스입니다 확인후에 사용하세요



9. InK

 부트스트랩같은 빠른 개발이 가능한 HTML, CSS Javascript UI를 위한 프론트엔트 프레임워크입니다. 부트스트랩과 비슷하게 LESS와 FontAwesome을 사용하였습니다. 하지만 Ink는 DOM 조작, 편리한 통신단, 페이지 효과등을 위한 InK JS Core라 부르는 코어 자바스크립은 엔진을 가지고 있습니다.


10. blueprint

블루프린트는 견고한 기틀을 제공해주는 CSS 프레임워크입니다. 사용이 쉽고 민감한 타이포그래피, 유용한 플러그인, 프린트용 스타일시트등을 제공해줍니다. 2011년 이후 업데이트가 없으므로 추천하지않습니다.



11. Bourbon NEAT

NEAT는 오픈소스 유동형 그리드 프레임워크입니다. Sass와 믹스인 라이브러이인 Bourbon을 사용하여 몇분안에 충분히 강력한 반응형 레이아웃을 만들어낼수있습니다. 뭔가 이거다 싶은게 없음..



12. Ingrid

인그리드는 각각의 유닛에 클래스 사용을 줄이는 것을 목표로 하고있는 가볍고 유동적인 CSS 레이아웃 시스템입니다. 간섭이 적고 반응형 레이아웃을 재설계하기 쉬우며 확장성과 커스터마이징도 쉽다고 합니다. 예제가 거의 없어 별로 쉬워보이지 않습니다.



13. Susy

Compass CSS 프레임워크의 플러그으로 자신만의 그리드 프레임워크를 만들수있습니다.  Static, Fluid 그리고 Magic 세가지 서로 다른 타입의 그리드를 만들수있습니다. 홈페이지에 있는 튜토리얼은 허접하기 그지없어서 화가 날 지경인데 여기 잘 정리해놓은 튜토리얼 사이트가 있으니 관심있으신 분들은 참고하세요



14. YAML

2005년부터 지금까지 계속 개발되고있는 반응형 모듈화 CSS 프로임워크입니다. 잘 구성된 HTML5, CSS3 파일들과 4.6kb밖에 안되는 풋프린트, 독립적인 컨트롤이 가능한 그리드 컬럼 폭, 홈. 반응형의 유동성, 고정폭, 내장그리드. 하나의 완전한 웹사이트를 위한 완전한 세트의 구성들은 모든게 확장하나는건 둘째치고 개인홈에 링크달고 무료로 쓰던가 상업용으로는 돈내고 써야합니다. 왜죠?


15. Less Framework 4

유동적인 다중컬럼 웹사이트 레이아웃을 만들수 있는 CSS 프레임워크입니다. 24px 행간에 최적화된 8컬럼 그리드와 그리드의 수직리듬과 평행하는 황금비율에 기초한 타이포그래피 세트를 포함하고있습니다. (하나의 그리드기준으로 4개의 레이아웃과 3개의 타이포그래피 세트)



16. Maxmert



부트스트랩처럼 보기좋고 신선하지만 더 새로운것들을 제공해주는 SASS기반의 프레임워크입니다. 그리드, 타이포그래피, 폼, 테이블, 버튼 같은 주요 UI뿐만 아니라 드랍다운 툴팁, 메뉴, 알림, 모달등의 위젯과 컴포넌트를 제공해줍니다. 

클릭이벤트에따른 자바스크립트 애니메이션 효과가 아주 참신하고 인상적입니다. 여러 유명 JQuery라이브러리들을 잘 엮어놓은것같습니다. 다만 버전 0.0.2에서 멈춰있고 활성화되어있는 커뮤니티를 찾을수없는게 흠이라면 흠같습니다.



17. Metro UI CSS

마이크로소프트에서 제공하는 메트로UI 디자인가이드를 따라 만든 독립적인 CSS 솔루션입니다. 메트로 타일즈, 알림, 버튼등 참신하지만 정교함이 떨어집니다 다만 대부분의 쓸만한 메트로 CSS가 유료인받면 부트스트랩기반의 BootMetro와 비교해봐도 오픈소스 프로젝트로서 높은 완성도를 가지고있습니다. 메트로 테마자체가 참신하지만 개인적으론 추천하고싶진않습니다.



18. Fries


아시다시피 국내상황과 반대로 해외에서 모바일 개발의 기준은 여전히 아이폰입니다. 아이폰앱부터 만들고 아이폰에서의 퍼포먼스부터 챙깁니다. 따라서 Jquery Mobile같이 아이폰에서 정상동작하나 안드로이드에서 극악의 성능이 나오는 프레임워크들이 많이 있습니다. 자바스크립트 라이브러리도 아이폰 룩을 가진 소스들이 많기때문에 Fries는 아이폰룩을 벗어내고 안드로이드UI를 골라입혔다는 차원에서 반대로 참신한게 아닐까 생각됩니다. 폰갭과의 연동성도 좋아서 안드로이드 UI기준의 모바일 웹/앱을 한번에 지원하기 좋을듯싶습니다




기타 프레임워크들:

Reference sites:




Posted by K 얼바인

원문사이트 (http://www.goodui.org)



좋은 UI란 높은 변환율과 쓰기 쉬운것. 다른말로 쓰는 사람이나 사업측면이나 모두 괜찮은것이다. 

여기 시도해볼만 실용적인 아이디어들을 리스트해두었다.



1. 멀티컬럼 대신 원컬럼 레이아웃을 써라


원컬럼 레이아웃은 당신이 생각하는 것이상의 컨트롤이 가능하다. 맨위에서 맨아래까지 더 예측가능하도록 당신의 독자들에게 가이드 해줄수있기 때문이다. 반면 멀티컬럼은 페이지의 핵심 컨텐츠에 집중하는 것을 방해할 부가적인 위험을 가지고 있다. 사람들에게 하나의 스토리와 그 끝에 그에 반응하도록 가이드하라.



2. 팔고나서 입 싹 씻지말고  선물을 줘라.


고객에게 선물을 주는것같이 상냥한 제스쳐가 그것이다. 하지만 더 깊이 들어가보면, 선물주는 것도 상호주의에 입각한 하나의 유용한 설득 전략이다. 분명한 것은 작은 감사의 티켓을 제공받은 누구가는 추후 당신의 그 친절한 호의에 되돌아올수있다.




3. UI를 나누지말고 비슷한 기능을 합쳐라


시간이 지남에 따라 원래 의도하지않았던 같은 기능으로 작동하는 여러가지 섹션이나 요소나 기능을 새로 추가하는 것은 쉽다. 이게 엔트로피의 법칙이다 - 사물은 시간흐름에 따라 무질서해진다. 당신의 고객에게 부담을 줄 다양한 방법으로 표기된 중복된 기능을 항상 경계하라. 종종 UI 파편화가 높을수록 고객들이 익숙해지기 더 어렵게 만들곤한다. 비슷한 기능을 합치는 UI 리펙토링을 고려해봐라



4. 당신 혼자 떠들지말고 소셜로 증명하라


소셜은 사용율을 높이는데 직접적으로 적용할수있는 또다른 하나의 훌륭한 전략이다.

다른사람들이 당신을 지지하고 당신의 제공하는것에 대해 이야하는 하는것은 또다른 반응을 불러오는 훌륭한 방식이다. 다른 사람들도 쓰고있다는 것을 증명하는 추천글이나 데이터를 보여줘라.



5. 한번 보여주고 땡!하지말고 계속 반응을 유도하라


반복적으로 반응유도하는것은 긴 페이지나 여러페이지로 구성된 곳에 적용하기 쉬운 전략이다.

같은 스크린안에 당신이 10군데나 무언가 계속 보여준다면 사람들은 당연히 짜증날것이다. 하지만 긴 페이지를 기준으로 삼고 페이지 상단에 높고 서서이 없애주는 아이디어라면 액션 아이템 한개쯤은 괜찮을것이다.

또는 스크롤이 맨밑에 닿았을때 사람들은 대게 잠시 다음에 뭐할지 생각할것이고 이때가 무언가를 제공할만한 잠재적 공간이 될것이다.




6. 클릭할수있는 곳과 클릭된곳의 구별하라 


색상, 색조 , 색대비와 같은 비주얼 스타일링은 신뢰성있게 사용해서 사람들이 당신의 인터페이스를 사용함에 있어서 쉽게 이해할수있게 도움이 되어야 한다: 내가 어디에 있는지, 어디로 갈수있는지.

당신의 유저들과 명확하게 교감하려면, 당신의 링크나 버튼같은 클릭가능한 액션 스타일과 선택된 요소들 (선택아이템), 일반적인 문장들이 서로 명확하게 구분되어야하며, 하나의 인터페이스로서 일관성있게 적용되어야 한다.

한 비주얼 예제로, 내가 클릭할수있는 모든 곳을 파란색으로 하고, 선택되어졌거나 가리켜진곳은 검은색으로 하는것. 적절히 적용되었을때 사람들은 더 쉽게 습득하고 더 활용되어질것이다. 이 3가지 기능을 희미하게 구분하여 사람들이 쓰기 더 어렵게 만들지 말자.



7. 동일한 선택화면을 보여주기보단 추천하라


여러개의 상품을 보여줄때 추천상품을 강조하는것은 옆구리 살짝 찔러주길 원하는 사람들에게 좋은 아이디어가 될것이다. 어느 심리학 연구에서 선택할것이 많으면 실제로 하나를 결정하는 기회를 낮춘다고 한다. 정보 과다로 인한 분석불능을 막으려면 그들중 하나를 강조하거나 하일라이팅하라




8. 확인창보다는 되돌리기(Undo)를 제공하라


당신이 하나의 액션 버튼이나 링크를 눌렀다고 상상해보라. 되돌리기는 일단 처음 선택한 행동이 처리되게 허용함으로서 기본적인 인간의 행동을 존중한다. 반면에 확인창을 띄우는 것은 그들이 알지 못했던 자신이 무엇을 했었는지 그 의도에 대해 항상 질문들 던지는 것이다. 유저가 어떤 행동을 취했을때마다 반복적으로 이 비효율적이고 못난 확인창을 보여주는 것은 비인간적인 경험이다.

가능한한 확인창으로 물어보기 보다는 되돌리기 기능을 제공함으로서 유저들이 스스로 더 컨트롤할수있다고 느낄수있게 만들어라.



9. 불특정 다수보다는 타겟층을 정하라


불특정다수를 타겟으로 삼거나 또는 타겟유저가 분명한가? 당신의 제품이나 서비스가 누구를 위한 것인가에 대해 당신은 명확히 해야한다. 당신의 고객과 양질의 비평을 받음으로서 더욱 그들과 소통이 가능하고 그들을 위한 배타적 서비스를 제공할수있을것이다. 물론 이 전략은 스스로를 한정지음으로서 잠재적 고객을 제한한다는데 위험이 있다. 그렇지만 다시 말하자면 투명성이 신뢰를 쌓는다.

(비슷한 스타일끼리 어울리는 것을 즐긴다면 MicroPersonas을 읽어보길)



10. 우유부단하기보단 돌직구를 날려라


당신은 떨리는 목소리로 불확실한 메시지를 보낼수도 있고 자신감을 가지고 당당하게 말할수도있다.

만약 당신이 '아마도', '관심있나요?', '원해요?'같은 단어를 써서 질문으로서 당신의 메세지를 마무리 진다면 대게 당신은 좀더 권위적이 될 필요가 있어보인다. 누가 아는가? 사람들에게 차세대 컨버젼 최적화가 무엇인가 이야기 할수있는 조금 더 큰 공간이 될수도 있다.


11. 유사하게 보이기보단 더 차별하라 


당신의 반응요청을 주변 요소들보다 좀더 두드러지게 만드는건 당신의 UI를 더 강하게 만들것이다.

수많은 방법들로 당신이 원하는 반응요청를 매우 쉽게 두드러지게 만들수 있다. 더 어둡게 또는 더 밝게 하거나 더 가깝게 또는 더 멀게 보이게 하거나, 결과적으로 어떤 방법을 취하든 당신의 반응요청과 페이지의 나머지부분과의 차별화는 고려되어야한다.


12. 일반적이기보다는 어디서 만든건지 보여줘라


당신의 부지불식간에 소통하는 때에나 더 개인적인 차원일때까지 당신이, 또는 당신의 제품이나 서비스가 어디에 있는지 말하라. 나라, 주, 도시가 어디인지 언급하는 것은 스스로를 소개하는 매우 인간적인 방법임에 확실하다. 어디서 만든제품인지 언급하는것 또한 더 높은 퀄리티라고 느끼게 만들 매우 좋은 기회가 될것이다. 윈윈.




13. 너무 많은것을 물어보지말고 폼을 최소화하라


사람은 노동집약적인 일에 저항하려는 본성이 있다. 폼을 채우는 일도 같다. 당신의 질문에 폼을 채우는 일은 방문자로 하여금 발길을 돌리게 만들것이다. 누구나 같은 속도로 타이핑하지 않는다. 모바일에선 더욱더 하기 싫다. 가능한 많은 필드를 없애라. 정말 많은 필드가 꼭 필요하다면 페이지나 구문을 나눠라. 폼필드가 적으면 변환하기도 더 좋다.



14. 옵션을 숨기지말고 내보여라


당신이 사용하는 풀다운 메뉴는 액션리스트가 숨겨져있어서 찾아서 보려는 노력이 요구된다.

풀다운 메뉴의 옵션을 예측할수있게 변경하라. 날짜, 시간(캘린더)이나 지역적인 칸에 새로 배워야하는 무언가를 넣지마라. 주 메뉴에 드랍다운 메뉴를 사용하는 것은 조심해야한다.



15. 다중 바닥(false bottoms) 보다는 연속성을 제공하라


다중 바닥은 변환하는데 완전 쥐약이다. 긴 페이지를 스크롤링하는 것은 훌륭하다. 그러나 방문자들에게 섹션들 사이의 어딘가를 페이지의 끝이라고 생각되지않게 주의해야한다. 만약 페이지들이 스크롤되면, 가상패턴이나 리듬을 만들어 유저가 더 아래로 읽어내려갈수있게 알려줘야한다. 부가적으로 섹션들간의 큰 갭을 주의해야한다.





바람직한 UI #16-30로 가기



Posted by K 얼바인

원문 : http://sqlrelationship.com/one-to-one-relationship/



일-대-일 관계 기초 One-to-One Relationship Basics

SQL에서 일대일 관계는 빅테이블을 Flat테이블의 성능 저하없이 작은 조각들로 나누기위해 과소평가되어 쓰이지만,  어떤 경우에 안정화된 EAV모델보다 낫다.

1:1관계의 완벽한 사용예는 아래 예와 같이 카탈로그 엔트리와 같은 기본 속성을 공유하는 엔티티와 관련있다. 그러나 이론에 들어가지않고 다음의 엔티티 관계 다이어그램을 보자:

이 컨셉의 아이디어는 모든 엔티티같에 공유되는 기본 속성들을 저장하는 테이블에 있다. 예의 카탈로그 엔트리의 경우처럼 공유된 속성들은 제품명(Product name), 개요(description) 그리고 가격(Price)이다. 제품의 특정 타입을 가르키는 속성들은 별도의 테이블에 저장되어있다. 이들 테이블간의 관계는 모든 테이블이 같은 Primary Key가지고 저장되어있다는 것이다.


구현 Implementation

위의 예에서 본것처럼, 일대일관계는 테이블같에 같은 Primary Key를 사용함으로서 간단하게 구현할수있다. 만일 엔티티 id 12345를 가지고 있는 어떤 제품이 저장되었다면 이 id는 모든 테이블에서 사용된다.

다른 Primary Key들을 사용하여 모든 테이블에 관계컬럼을 추가할수있지만 이것은 또다른 결점이 있다: SQL 구문이 더 복잡해지고 foreign key를 쓰려면 순환의존(circular dependency)이 되어버린다.





Posted by K 얼바인

(원문소스: http://www.gwtsushi.info/2010/08/initial-thoughts-on-vaadin.html)

2010년 8월 3일 화요일

Initial Thoughts on Vaadin : Not so much a GWT complement more of a replacement.

Vaadin 첫인상: GWT를 "대체"한다는 것 이상의 메리트는 없어보여
 

얼마간 Vaadin 프레임워크를 사용해보고 코맨트할 의도를 가지게 되었어. 이 툴킷 웹사이트의 플러그인과 데모들은 자신감이 배어져나왔거든. 내 마지막 포스트에 이 프레임워크를 사용해보기를 제안한 리플을 받은 후, 나는 이 충고를 받아들이고 튜토리얼을 따라해보았어.


주소록 튜토리얼은 프레임워크의 훌륭한 시작이었어. 이 데모 웹 어플리케이션은 아주 이해하기쉬웠고 아주  자유로운 표준의 코드들이었어. 내 완성된 어플리케이션을 여기서 http://thinktaxi.appspot.com 확인해보라구. 대부분 개발자들이 가지는, 그냥 어플리케이션 로직을 프로그래밍하면 프레임웍 추상화에 의해 아름답고 효율적인 표준의 코드들이 만들어지는, 완벽한 프레임워크의 꿈이 이루어져. 이건 성배찾기와 같은거라구...
물론, 내가 언젠가 바래왔던 프레임웍이 실제로 존재하고 있다는것만 빼면 말이지.

Vaadin은 "GWT 기반 위젯만들기, Vaadin 어플리케이션은 모든 Ajax를 지원하는 브라우저들을 플러그인없이 지원해."라고 광고해왔지. 이건 사실이야 그러나 튜토리얼을 마친후 나는 이것에 구체적 설명이 필요하다는걸 느꼈어.

Vaadin은 완전히 서버에서만 작동해. 컨테이너로서 GWT를 사용해서 말이지. GWT와 Vaadin의 통합은 아주 별도의 것으로 보여. 처음 문서를 속독할때 넌 Vaadin이 일반적인 GWT어플리케이션을 꾸미는데 사용되는 GWT 위젯의 일부라고 생각하게 될거야. 이 가정은 틀렸어. 하지만 나는 전적으로
 "Vaadin은 거의 완벽하게 GWT와는 다르고, GWT의 일부로 간주되어서도 안된다"는 내 가정을 Vaadin전문가가 올바르게 고쳐주길 기대하고 있다고 말하고 싶어.

그래, Vaadin은 완전히 자바코드로 작성된 후, 서버에서 작동한다고. GWT와 비교했을때, 클라이언트코드에 어떠한 자바 라이브러리도 사용가능하다는 것은 하나의 "혜택"이지.
그러나 Vaadin에 포함된 무엇을하든 서버를 경유해야한다는건 좋지않아보여. 이것은 중대한 사항이고 질문을 야기하지. 만일 모든것이 서버를 왕복해야한다면 Vaadin은 효율적일까? 또하나 단점은 너는 GWT위에서 동작하는 하나의 완전하고 새로운 아키텍쳐 시스템을 익혀야한다는거야. 만일 너의 회사의 지식기반이 Vaadin에 한정된다면 향후 너의 솔루션의 제약사항이 될수있지.

아뭄튼, 내가 싫어하는게 아니라구. 물론 나는 GWT빠돌이지만 그렇기 때문에 Vaadin을 사랑하는 사람들을 사랑할 준비가 되어있지. 어떤 어플리케이션이든 Vaadin은 좋은 솔루션을 만들어내지. 아아 내 생각엔 딱 한 회사를 위한 인트라넷정도의 작은 유탈리티 타입의 어플리케이션으로 딱 좋은것같아.
비지니스적으론 일반적인 개발과 배포의 신속함이 어플리케이션이 얼마나 성능이 좋냐보다 중요할때 괜찮은것같아. 어플리케이션의 기능은 아마 100 유저 이상 동시접속하지않을때, 그래서 어플리케이션의 로딩 트래픽이 높지않을때도 좋을거야.
나는 튜토리얼을 통해 이 어플리케이션의 복잡성과 신속함이 매우 인상적이었어. 나는 RAD (rapid application development:빠른 어플리케이션 개발)에 많은 혜택을 볼수있었어. 

요약하자면 Vaadin은 작은 규모의 비니지스 개발에 좋아, 그러나 GWT프레임웍은 아니야. 그렇게 간주되어서도 안돼
 

8 리플:

Sami said...

내생각에 너가 맞아. Vaadin은 빠른 개발속도에 집중된 서버기반 컴포넌트 프레임워크야. GWT는Richful 인터페이스를 위한 클라이언트측 코드를 만들어주지. 이건 독립실행가능한 GWT위젯으로서 새로운 Vaadin 컴포넌트를 만들때 역시 좋은것같아. 두 프레임웍의 혜택을 다 보기위해 말이지.
 
수용성 분석(scalability analysis)은 여길봐줘: http://vaadin.com/blog/-/blogs/server-side-ria-scalability

Luciano Vernaschi said...

나는 너의 생각을 공유해. 난 GWT라이브러리로서 Vaadin을 보진않아. 그러나 Vaadin이 코드를 만들어내는것은 매우 즐겁다는걸 동의한다구. 그럼에도 불구하고 순수한 GWT보다 많이 느리지만 말야..

난 Vaadin을 약간의 코드를 짜보기 위해 시도해봤어. 제품 어플리케이션을 만들어보지도 않았지.
그래도 성능이 충분히지않아서 수정이 필요한 경우를 생각해보면 GWT의 커스텀 컨포넌트를 만들기 두렵다고.
August 4, 2010 3:43 AM

Anonymous said...

Vaadin와 GWT의 관계는
1) Vaadin은 GWT를 랜더링을 구현할때 내부적으로 사용해
2) Vaadin은 GWT에 확장할수있어 - 새로운 재사용이 가능한 위젯을 구현할수있어

GWT와 Vaadin은 서로 다른것을 최적화하지: GWT는 클라이언트를 가능한 많이 움직이게 함으로서 서버의 로딩을 최소회하려고 하지. Vaadin은은 서버에 최대한 코드를 묶음으로서 개발시간을 최소화하려고 해. 대부분의 경우 서버기반 개발은 좋은 성능을 보장해줘, 그러나 어떤 상황(애니메이션, 그래픽관련..)에선 클라이언트 기반 프로그래밍이 필요해 - 이러한 상황들에서 새 Vaadin 위젯을 구현해야해 - 운좋게 이건 아주 쉽지.

Vaadin의 수용성(Scalability)의 서버기반 모델은 어플리케이션에 좌우되. 서버당 수천의 동시 접속자를 처리할수있는건 일반적인거라구. 너의 어플리케이션에 따라 이건 서버당 수백만의 일일접속자를 감당할수있어.

Mark said...

내 생각엔, Vaadin은 두가지 측면으로 GWT를 사용해: 컴포넌트 개발과 마케팅 목적

Vaadin은 스스로 생명주기를 가져.  SmartGWT나 ExtGWT와 같은 서로 다른 벤더들에 의해 만들어진 GWT를 사용하기 힘들다는 의미야.

최악의 것은 GWT가 실로 의도하고 또 좋은것인 어떠한 클라이언트 코드도 쓸 수 있는 방법이 없다는거지.
이들 데모를 보면 어플리케이션 개발자가 할수있는 것은 오직 자바스크립트 코드를 클라이언트에 보내는 것 밖에 없어. 자바스크립트 코드는 어떠한 컴포넌트도 접근할 방법이 없지 (GWT name mangling (컴퍼일러가 선언된 이름을  바꾸는것)과 생명주기가 다르기 때문에 )

모든 어플리케이션 코드는 서버에서 동작해 만일 너가 컴포넌트를 만들지않는다면, GWT와 연결할 방법이 전혀 없는거지

Anonymous said...


"비지니스적으론 일반적인 개발과 배포의 신속함이 어플리케이션이 얼마나 성능이 좋냐보다 중요할때 괜찮은것같아. 어플리케이션의 기능은 아마 100 유저 이상 동시접속하지않을때, 그래서 어플리케이션의 로딩 트래픽이 높지않을때도 좋을거야." 라고 말했지


나는 동의할수없어. 개발과 배포의 신속함은 중요해 그러나 너의 어플리케이션의 성능의 중요성은 그것보다 더 중요하지. 고객은 SLA (서비스 수준 협약서)  요구사항을 기본으로 깔고 어플리케이션을 구매한다고

Gene said...

개발의 신속함 vs 어플리케이션의 성능:

 IT 어플리케이션의 어떤한 타입를 설계할때  성능은 항상 중요한 이슈지. 우선순위 리스트에서의 이 위치는 그 어플리케이션의 타입에 다라 달라.  회사내의 IT 소프트웨어를 맞춤생산하는 비지니스의 다양함을 겪어본후, 그들의 중요한 고려사항은 언제나 그 소프트웨어를 얼마나 빨리 개발할수있냐였어. 어플리케이션의 성능에의 필요는 언제나 두번째였지, 그것이 문제가 되지않으면, Vaadin은 이 분야의 이상적인 솔루션이야. 개발속도는 인상적이지. Gmail, Hotmail이나 Salesforce와 같은 어플리케이션을 가지는 더 큰 소프트웨어 개발세계에서 성능은 가장 최우선순위에 있지. 이 어플리케이션들은 수천명이 사용하니까.
그리고 성능은 모든 디자인의 의사결정에 핵심중의 핵심이 되어야 하지

내가 생각할땐 우리는 비슷한걸 얘기하고있어 그리고 나는 어떤 소프트웨어 어플리케이션에서 요구되는  성능의 최소레벨이 있다는걸 동의해. 프레임웍에 대한 우리 선택은 어떻게 어플리케이션이 사용되는가에 기초하잖아. 나는 그것이 필요할때만 서버에 접속하는게 아닌 서버중심의 프레임웍을 선택하는걸 경계하게 되.

너의 코맨트에 감사해 그리고 이 기사는 잼있었어
Gene

그러므로 내 결론은 Vaadin은 맞춤생산하는 소프트웨어에 유용하다는거야

Sleeveen said...

나는 Vaadin에 대한 너의 생각에 동의해. 나는 최근에 큰 GWT 프로젝의 한 프레임웍을 선택해야해서 주시하고 있었어

많은 사용자가 없는 작은 어플리케이션이라면 난 빠른 개발이 이득이라고 봐. 그러나 난 네트워크 관리 어클리케이션을 만들려고 하니까 결과적으로 수백의 동시접속자가 있고 실시간 이벤트 알림같은것도 필요할거야 (comet이나 websocket등등을 읽어봐)

Vaadin은 매우 훌륭해. 그러나 너는 그 일에 적당한지 확신을 가져야할거야 
힘내셔잉!


Posted by K 얼바인
Broadleaf Commerce Vs. Apache Ofbiz
(original source by http://l154k.blogspot.com/2011/09/broadleaf-commerce-vs-apache-ofbiz.html)

일단 2~3년전 난 아파치 OFBIZ쓰는걸 포기했었어, 왜냐면 몇주 써보니까 이게 너무 복잡해서 '생산적'인것 같이 않았거든. 그러다 몇달전에 Broadleaf 커머스라는걸 알게 되었는데 무척 관심이 가더군. 스프링, 스프링MVC frontend, GWT backend, 하이버네이트, 메이븐 등의 기반인게 나랑 맞더라구.
SCM으로 git이나 github.com을 썼다면 난 이 글을 쓰지도 않았을 테지만 이사람들 backend단에 flex를 없애버린건 정말 좋았어. 이 플랫폼으로 커스텀 쇼핑카트를 만드는 원칙은 상당히 직관적이긴 하지만 역시나 경험있는 개발자가 필요할거야.

다음으로 e커머스 out of the box 솔루션(특히 미국외 비지니스)은 쉽게 말해 특별한 요구사항을 맞출수없어. 한번 둘러보라구 
 (인스톨하고 바로 쓸수있는) 수많은 PHP쇼핑카트툴들이 카트기능을 쓸수있게 해주지만, 이 솔루션들의 '보편적 기능'들의 댓가로 필요없는 단점들을 계속 안고 가야만해.
결재, 세금, 회계, 배송 같은 것들은 지역특화적이야. PHP쇼핑카트들은 아키텍쳐가 개판이거나, 모듈화가 안되어 있고, UX가 구리던가 아니면 수많은 희안한 것들 투성이지. 
Prestashop은 내가 보고 말해왔던것들중 나쁘진않았어

이제 Konakart같은 일부 오픈소스거나 shopizer나 jadasite같은 오픈소스 자바 e커머스 솔루션을 보자고. jadasite는 보기엔 옳다구나 하지만 이건 out of the box야, 쉘이나 ant스크립트 조차 없어, 메이븐도 안되.. 결재나 배송모듈을 바꿔야한다고 생각해봐, 오우 말도안돼.. 어쨋든 나는 이클립스 WTP기반의 어플리케이션은 사양이라고...

마지막으로 아파치 Ofbiz나 Broadleaf 커머스같은 솔루션은 out of the box 솔루션이 아니라 플랫폼이야 (뭐...broadleaf coffer shop 데모 페이지를 보면 이건 완전 바로 쇼핑몰 개시해도 될 수준이지만) 개발자가 커스텀 솔루션과 함께 넣어서 이것들을 활용해야해.
개발/코딩/프로그래밍이 아니라 '함께 넣는다'고 했다 이게 뭔말이냐면 예를 들자면 실제 구축된 지역에 인프라 구축하고, 거기에 가지고 있는 모듈을 바꾸고 확장하고 합친 
빈,서비스, 엔티티들을 적용하는거야
 

내 생각에 아파치 Ofbiz의 복잡성은 
완전히 익숙해진 레벨의 사람이 아니면 완전 시간낭비야, 이건 큰 문제라구! 근데 Broadleaf 커머스는, 훨씬 더 쉽더라구
문서들도 더 구체적이고 최근거야.. 내가 볼땐 이 두 플랫폼에 완전 초짜인 개발자들용이지
아파치 orbiz를 택하자면 실제 보여지는 결과보다 더 많은 삽질을 내부적으로 하게되.. 이게 완전 의욕을 꺽어버려.. 근데 Broadleaf Commerce경우는 대강 코드베이스 두시간정도 훑다보면 거의 모든 흐름을 알수있지

ofbiz를 살펴보고 결론을 내린게, 내가 필요로 하는 쇼핑카트로서는 그다지 가치가 없어. 엔티티, 서비스엔진, 워크플로우 등등과 플랫폼을 설정하는 방식이 아주 J2EE non-standard같단 말이지 난 완전 헤매버렸어 그리고는 깨달았지 아마도 이 삽질은 필연적이었다는걸.. 왜냐면 생각해봐 어떤 e커머스 플랫폼이 이렇게 거대한 기능을 갖고있냐고... 이걸로는 Broadleaf 커머스에서 했던것처럼 할수가 없어... 간단히 말해서 이 ofbiz로 뭘 좀 만들어내려면 한 몇주는 삽질해가며 배워야만해.. 그러고는 e커머스 카트 완전체를 홀로 만들어내겠지.
 

이건 10년이나 되었고 아파치재단이 뒤를 봐주고 있으니까 상대적으로 더 큰 커뮤니티가 있다는 장점이 있어. 근데 내 생각엔 이 프로젝트에 기여하고 있는 사람들이 빠른 변화를 원하지않는 회사의 직원들이기 때문에 소극적 프로그래밍을 하게 되고, 때문에 플랫폼에 도움이 될만한 급진적 요소들이 거의 없어 (적어도 이건 인상적이드라..)
이건 경험많은 Ofbiz 개발자들에겐 문제가 되지않지만 뉴비들에겐 큰 애로사항이지

난 Broadleaf 커머스의 소스기반을 살피는데 몇시간 썼는데
e커머스 카트를 위한 (webapp) 메이븐 프로젝트를 설정하려면 뭐를 해야하는가를 확실히 봤어 dependencies로 broadleaf플랫폼 라이브러리들을 넣고 컨테이너 하나 그냥 배포해봤는데 작동잘하드라고! 아마 svn 체크아웃하고 몇분안에 볼수있을거야! 데모프로젝트가 있는데 너의 새 사이트나 쇼핑몰로서 복사하거나 활용할수있어. 그냥 필요한 것을 (컨트롤러, 서비스, 엔티티, jsp, css, 전체 모듈들)을 Spring configuration이나 파일시스템을 통해 그냥 간단하게 추가하거나 합치거나 덮어쓰면 되. 이런식으로 너만의 커스텀 e커머스 카트를 만들수있어.

한가지 내가 고마워하는건 데모 사이트뿐아니라 디폴트/클래식 템플릿, 인프라셋업, 디폴트 워크플로우 그리고 모듈들을 가지고 있는 메이븐 archetype이라는 사실이야. 개발자로서 바로 배포하고 수정할수있다는거지 또는 테마 뭐 둘다 좋아 


언급할만한 다른 중요한 건 Google Web Tookit의 경험이 매우 큰 장점이 된다는거야. 이건 백엔드/ 관리자 모드를 개발하는데 필요하거든.. 또, Broadleaf 커머스는 사이트 규모를 키우거나 클라우드 서비스같은게 필요할때 클라우드 기반으로 배포가 쉬워. 마지막으로 Liferay나 WebShere같은 포틀릿과의 통합이 상대적으로 쉬운 유일한 e커머스 솔루션인것같아. 임베딩할수있다는 얘기가 아니라 Broadleaf 프레임워크를 이용해 e커머스 카트 포틀릿을 만들수있다는거야물론 통합하려면 힘들겠지만 확실한건 현재로선 이것보다 더 적합하거나 더 나은건 없어

이 소프트웨어는 주목받아 마땅할만해, 나는 Broadleaf 커머스 커뮤니티가 성장하길 바라고 지켜보려고해






Posted by K 얼바인
Drupal vs. Joomla: a frank comparison from an IBM consultant


우리는 매우 운좋게 개인프로젝트를 위해 우리의 Drupal 테마중 하나를 구입한 IBM과 컨설턴트했어. 그 테마 구입에 앞서 우리는 주로 줌라와 드루팔의 기능성과 시각적 차이에 포커스를 맞춰 약간의 토론을 벌였지.

내가 '운좋다'고 한건 두 CMS를 평가한 이 컨설턴트후에 줌라와 드루팔의 첫경험에 대한 환상적으로 자세하게 비교해놓은 이메일을 받았거든. 나는 이걸 우리의 블로그에 공개하도록 허락받았어 그래서 이 훌륭한 글이 많은 커뮤니티에서 도움되도록 말이지

난 여기에 내 생각을 많이 주입시키지 않을거야 (1) 그냥 이 글의 모든 것에 동의해 (2) 좋은 소식은 드루팔7에 촛점을 많이 맞췄다는건데 나는 드루팔 커뮤니티 역시 현재 사이트의 pre-configuring/populating을 위해 수많은 접근법을 가지고 노력하고 있는걸 알거든

편집: 우리는 줌라 유저들한테도 아주 흥미로운 의견을 얻고있어. 덧글읽는걸 잊지마!


아래는 전체메일

참고로 내 의견은 드루팔을 대략 40~50시간사용해본 의견이야 (난 줌마, DotNetNuke 아 물론 IBM의 우리 솔루션: Websphere Portal, WCM, Portlet Factory 들에 대한 경험이 있어). 나는 줌라를 쓸지 드루팔을 쓸지 결정하기전에 몇 일 더 시험해볼 계획이야.  Websphere Portal을 위한 호스팅 비용과 포틀릿 개발비용이 넘 비싸 아님 난 IBS 솔루션을 사용하고 싶어.

드루팔 대 줌라

사이트 구축 
- 유연성 & 파워 : 드루팔이 훨더 파워풀해보여 - 훨씬 더 유연해. Views, CCK, Panels들이 드루팔에 줌라를 뛰어넘는 큰 이점을 주는 것같아.  줌라는 이런 유연성이 없어. 줌라 개발자들이 유연성이 떨어지는 자신만의 패러다임으로 디자인했나봐. 줌라를 활용하면 훨씬 더 빨리 제작과 운영을 시작할 수 있겠지만 머지않아 곧 난관에 부딛칠거야

성능 
- 초기 테스트만 봤을땐 드루팔이 줌라를 안드로메다로 보내버려, 줌라의 새버전은 좋은 템플릿 제작자들을  -기업 환경에는 적합하지않은- 놀라운 가젯들로 쓸모없게 만들어 버렸어

학습 곡선 
- 줌라가 시작하기 쉬워. 무료 동영상,블로그 등등을 가지고도 드루팔은 여전히 쉽지않아.  쉬운 비지니스 / 기업 도서 / 교육 등에 큰 기회가 있어

템플릿 
줌라의 완승.  예를 들어, Joomlart , Joomlashack같은 회사들은 아주 잘되있어. Drupal 테마회사들은 아주 끔찍해,  무엇이 필요하가는 한 나라의 상위 웹사이트들의 요구사항을 흉내내는 템플릿전략이야. 번들, 모듈, 블럭등이 비지니스를 바로 시작하게 만드는 준비된 작업이야. 이를테면, 우리의 Websphere Portal 제품으로, 우리는 신뢰할만한 확고하고 전문적인 테마/스킨을 복잡/짜증없이 만들수있어. 니들은 잘 공인된 전략을 가지고 있지만 기업환경에 진짜 필요한것을 가져다주는 큰 기회를 잃고있어

너희들의 템플릿은 내가 본 중 최고야. 근데 드루팔을 가지고 시작하려는 회사가 뉴스사이트, 잡지사이트등을 보기좋게 만드려면 엄청 삽질을 해야해. Joomlart은 Teline II 템플릿을 제공하는데 특별한 설치과정을 통해 모든 샘플데이터와 컴포넌트들을 제공해줘 - 필요한건 전부 다 있어.

결과적으로 드루팔 템플릿의 가장 큰 문제는 개발자들이 평가자들이 관심을 가지는 하나의 중요한 요소를 빼먹었다는건데 바로 메뉴 시스템이야. 너네 사이트에 전문적 네비게이션 시스템이 없다면, 그냥 좀 허접한 사이트로 인식될꺼야. 다른 상위요소들- 레이아웃, 그래픽, 속도들도 중요하지만 드루팔 개발자들은 신경안쓰는것처럼 보여

코드 개발자 
내 제한적 리뷰를 기반으로, 드루팔 코더들은 훨씬 더 전문성있고 숙련되고 훈련되있어. 좋은 줌라 코더들은 드물어. 확실히 드루팔 문화로 인한 뭔가가 있나봐. 줌라 개발자들이 유능한건 확실한데 별로 능력을 발휘하는 것 같지않아.

관리자 
드루팔의 백엔드 관리 기능은 좋지 않아. 프런트 엔드, 백엔드 구분이 미미하고 애매해. 줌라가 훨더 낫다.

컨텐츠 관리 
- 드루팔의 분류법 시스템이 우수해. 줌라의 "바로입기"접근법 (콘텐츠 항목이 하나의 섹션/ 카테고리에 국한되었어) 은 좋지않지만, 줌라의 관리콘솔이 구성하고 컨텐츠 검색하기 훨씬 더 쉬워. 줌라의 위지위그 프로는 드루팔의 상응하는 옵션에 비해 더 좋아

컨텐츠 프리젠테이션 
- 드루팔의 툴이 아주 아주 좋아 - IBM툴에 내장된 기능에 근접하지는 않지만 줌라보다는 몇년앞섰어 - 난 CCK, Views를 좋아해 근데 왜 얘들이 코드기반의 일부가 아닌지 의문이야. 좀 이상해보여. 줌라에서 너가 필요의 60~80%를 충족해주는 컴포넌트를 구해야해 이를테면, iJoomla는 거대한 뉴스 컴포넌트를 가지고 있지만 드루팔의 CCk, Views등과 같은 적응성을 가질순없을거야.

Multitier 배포
 
나는 개발, 테스트, 스테이징, 개발 환경을 구현하기위한 적절한 방법에 대한 좋은 튜토리얼, 기사, 교육이 없다는게 쇼킹했어. 드루파과 줌라 커뮤티니 둘다 이문제로 고민하고 있지. 또한 기본적인 백업과 복구를 충분히 가르쳐주지 않아. 드루팔 커뮤니티는 완전 배째고있더군. 줌라는 최소한 두개의 좋은 솔루션을 가지고 있어. 내가 드루팔에게 개발사이트를 추천한다면 줌라플러그인인 Xcloner를 추천하겠어. 이 제품은 사이트와 SQL 디비의 백업과 복구를 하는데 드루팔과 잘 동작할거야.

두줄 요약

- 멋져보이는 사이트를 신속하게 만들고 싶으면 줌라를 써. 아 물론 더 느린 시스템과 경직된 컨텐츠 분류체계, 제한된 디자인/설정 옵션들을 감수할수 있다면. 
- 높은 성능, 확장성, 좋은 콘텐츠 관리 및 설계 유연성을 원하면 드루팔을 써. 근데 사이트 하나 잘 만드려면 시간/돈 꽤나 들여야할거야.



Posted by K 얼바인


티스토리 툴바