<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>번역 on ElegantCoder</title><link>http://elegantcoder.com/tags/%EB%B2%88%EC%97%AD/</link><description>Recent content in 번역 on ElegantCoder</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 10 Jun 2016 05:05:00 +0000</lastBuildDate><atom:link href="http://elegantcoder.com/tags/%EB%B2%88%EC%97%AD/index.xml" rel="self" type="application/rss+xml"/><item><title>Git Merging 과 Rebase 의 상황별 사용법</title><link>http://elegantcoder.com/posts/git-merge-or-rebase/</link><pubDate>Wed, 20 May 2015 11:49:12 +0000</pubDate><guid>http://elegantcoder.com/posts/git-merge-or-rebase/</guid><description>Git 을 사용하기 시작한지가 벌써 3년이다. 한번은 문상환님하고 Git 의 Merge branch 커밋에 대해 이야기를 한 적이 있다. 대화가 진행될 수록 Rebase 와 Merge 를 머리로만 알고 있을 뿐, 제대로 이해하지 못하단 걸 알게됐다. 일종의 산파법이랄까. Git 에서 코드를 합치는 방법에 대해 탕수육의 뿌먹파와 찍먹파처럼 Rebase 파와 Merging 파가 있다. 나는 Merging 파였다. Rebase 에 […]</description></item><item><title>더 효과적인 피어 코드 리뷰를 위한 여섯가지 방법</title><link>http://elegantcoder.com/posts/effective-code-review/</link><pubDate>Thu, 07 Nov 2013 09:27:30 +0000</pubDate><guid>http://elegantcoder.com/posts/effective-code-review/</guid><description>&lt;blockquote>
&lt;p>한빛미디어에서 당신의 동료가 더 효과적으로 코드리뷰를 할 수 있게 만드는 여섯 가지 방법 라는 좋은 글을 접했습니다. 그런데 읽다보니 번역문이 이해하기 어려운 점이 많아서 원문을 다시 읽게되었고 요약하게 되었습니다.&lt;/p>
&lt;/blockquote></description></item><item><title>JS프로그램의 압축(Compression of JavaScript Program)</title><link>http://elegantcoder.com/posts/binary-compress-js/</link><pubDate>Sun, 08 May 2011 14:04:32 +0000</pubDate><guid>http://elegantcoder.com/posts/binary-compress-js/</guid><description>원문은 http://j.mp/gl4jDq 에서 보실 수 있습니다. 오역의 가능성이 있으니 원문과 비교하며 보세요~</description></item><item><title>위지윅(WYSIWYG) 에디터를 만들고자 할 때 고려할 사항</title><link>http://elegantcoder.com/posts/wysiwyg-editor-tips/</link><pubDate>Sun, 08 May 2011 13:16:04 +0000</pubDate><guid>http://elegantcoder.com/posts/wysiwyg-editor-tips/</guid><description>원문은 &lt;a href="http://bit.ly/ksonHb">http://bit.ly/ksonHb&lt;/a> 에서 보실 수 있습니다. 1. iframe docs vs. contenteditable divs 위지윅에디터를 제작하고자 할 때 iframe을 사용할 지, 어느 엘리먼트에나 존재하는 contenteditable 속성을 이용할 지 고민될 수 있습니다. 답변자는 iframe을 추천합니다. 그 이유로:  iframe내에서는 문서 타입, CSS, script 등을 이용해 완전한 제어를 할 수 있습니다. 여러 다른 페이지내에서 통일된 액션과 모습을 보여주는 데에 꼭 필요합니다. 특히 Firefox에서 contenteditable 속성을 가진 엘리먼트가 매우 버그가 많은데, 이것은 몇 년 전부터 있어왔고 아주 잘 동작하는 document의 designMode속성에 비해(pre-1.0 부터인가? 확실하지 않습니다) 이 속성이 비교적 최근에(3.0버전부터) 도입되었기 때문입니다.   2.</description></item><item><title>더 나은 SEO를 위해 알기쉬운 사이트 구조 작성하기</title><link>http://elegantcoder.com/posts/site-structure-seo/</link><pubDate>Sun, 06 Mar 2011 13:20:45 +0000</pubDate><guid>http://elegantcoder.com/posts/site-structure-seo/</guid><description>원문: Intelligent site structure for better SEO!</description></item><item><title>회원가입 프로세스를 심플하게 만드는 17가지 방법</title><link>http://elegantcoder.com/posts/signup-process/</link><pubDate>Tue, 01 Mar 2011 14:52:59 +0000</pubDate><guid>http://elegantcoder.com/posts/signup-process/</guid><description>xguru님의 이번 주 기술뉴스에 포함된  “회원가입 프로세스를 심플하게 만드는 17가지 방법” &lt;a href="http://j.mp/eeC2Qp">http://j.mp/eeC2Qp&lt;/a> 에 대한 간단한 번역입니다. 원문에는 이해가 쉽도록 이미지 등도 있으니 참고하세요~  오역의 가능성은 다분합니다 -_-   1. 이메일을 아이디로 만들어라   2. 사용자가 항상 쓰는 비밀번호를 쓸 수 있게 하라. (복잡한 규칙을 설정하지 마라. 은행, 개인정보 등 민감한 사항을 다루는 웹사이트들은 예외.)   3. 추가 정보는 우선 계정을 만든 다음에 받도록 해라.   4.</description></item></channel></rss>