본문 바로가기

728x90

테크니컬 라이팅

(353)
[마소 V.396 리뷰] 매너가 흐르는 버그리포팅 MDN에 버그리포팅 가이드라인이 있다는 걸 첨 알았네요. 글을 쓴 분에게는 죄송하지만, 이 글의 가장 큰 성과는 그것이 아닐까 싶다는 ^^ https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines Bug report writing guidelines This page assumes you'd like to contribute to the Mozilla project by collecting enough information to enter a useful bug report in Bugzilla, the Mozilla bug tracking system. developer.mozilla.org MDN 가이드라인 설명 중에 아래 ..
[마소 V.396 리뷰] 기록을 공유하는 문화 만들기 컨플루언스 위키를 성공적으로 도입한 사례 같네요. 많이 공유된 글 중에 우아한 형제 팀에서는 아예 영문 가이드 문서를 번역까지 해가면서 위키 활성화를 위해 노력을 하고 있지만 잘 안되고 있다는 이야기도 있어서~ https://woowabros.github.io/woowabros/2016/09/13/confluence_guide.html [공유] 소프트웨어 팀을 위한 컨플루언스 가이드 - 우아한형제들 기술 블로그 컨플루언스를 좀 더 효과적으로 활용할 수 있는 방안을 정리한 문서를 공유합니다. woowabros.github.io 그리고 또 최근에는 노션을 많이 사용하고 스타트업에서는 노션을 쓰는 것이 트렌드처럼 퍼져있어서, 컨플루언스 위키를 도입하려는 팀이 있는지는 모르겠습니다. 장단점이 있겠죠. 찾아보니 ..
[마소 V.396 리뷰] UI 텍스트와 오류 메시지 작성법 음. 역시 실망스러운 글입니다. "웹 기획자가 알아야 할 서비스 글쓰기의 모든 것"에 나온 내용과 크게 다르지 않습니다. (찾아보니, 이 책도 개정판이 나왔군요). https://book.naver.com/bookdb/book_detail.nhn?bid=10225605 서비스 글쓰기의 모든 것 『웹 기획자가 알아야할 서비스 글쓰기의 모든 것』는 웹 서비스나 애플리케이션 텍스트를 쓸 때 고려해야 할 기본 사항을 알려준다. 사례로 살펴보는 올바른 문법과 표현, 자주 사용하는 오류 메시지 유형, 전 세계 사용자를 대상으로 할 때 고려해야 할 점 등을 소개한다. book.naver.com 아무래도 일부를 발췌해서 편집하다 보니, 꽤 많은 내용을 담고 있지만, 눈에 잘 들어오지 않습니다. 이미 책을 읽어서 그런지..
GitBook 레가시 이전하기 얼마 전부터 사용하던 GitBook 계정을 내년에 삭제할 예정이니 새로운 곳으로 옮기라는 메일이 왔더군요. 2016년에 잠깐 외부 스터디 참여하면서 정리한 내용을 기록하기 위해 가입하고 그 이후에는 전혀 관리를 하지 않고 있었는데, 벌써 시간이 이렇게 지나버렸네요. 보통 콘텐츠를 제공하는 서비스는 크게 변경된 것이 없다면 새로운 버전으로 업데이트를 해줄텐데, 뭔가 그 사이 많이 달라진 모양입니다. 레가시(?) 사이트는 https://legacy.gitbook.com/ 로 접속합니다. 뭐 지금 보더라도 사이트는 크게 나쁘지 않습니다. 2016년의 모습은 아닐 듯 하고, 아마 새로운 서비스로 옮겨가기 전의 모습이 아닌가 싶네요. 레퍼런스도 몇 개 없던 시절이었는데, 요즘에는 job info에 GitBook ..
[마소 V.396 리뷰] 영어로 커밋 메시지 쓰기 어렵지 않아요 커밋 메시지를 그렇게 주의 깊게 보는 개발자들이 있을까 싶고, 당장 나에게 급한 일은 아니라서 이 글은 그냥 넘어갈까 했는데 뒷부분에 JIRA 제목과 내용을 작성하는 가이드가 있더군요. 예전부터 고민하던 내용이라, 이 부분은 정독(?)을 했습니다. 지라 티켓은 제목(필드명: 요약)만 봐도 무슨 내용인지 혹은 무엇을 하겠다는 것인지 알 수 있도록 작성해야 한다. 사실 다들 알지만, 쉽지 않은 일입니다. 검색 기능을 사용해서 내용 검색이 가능하지만, 내용까지 검색하게 되면 불필요한 내용들도 나와서 제목에 딱 요구사항이 드러나는 것이 가장 좋다는 생각입니다만, 그걸 제목에 담아내는 것이 쉽지 않습니다. 그래서 이러이러해야 한다라고 이야기하는 것은 쉽지만, 어떻게 해야 하는 거야~라는 정답을 알려주는 것은 쉽지..
아이콘 색상 변경하기 아~ FlatIcon 사이트에 이런 기능이 있는 줄은 몰랐네요. https://www.flaticon.com/kr/free-icon/alarm_92386# Freepik이(가) 제작한 경보개의 무료 벡터 아이콘 SVG, PSD, PNG, EPS 형식 또는 웹 폰트 형태로 이 무료 아이콘을 다운로드하세요. Flaticon은 최대의 무료 벡터 아이콘 데이터베이스입니다. www.flaticon.com 원하는 아이콘을 일단 찾고 내려받기 전에 팔레트 비슷한 버튼을 클릭하면 색을 바꾸고 내려받을 수 있습니다. 간단하게 다른 색상 아이콘이 필요한 경우 유용하게 사용할 수 있겠네요. 무료 계정이라도 아이콘이 무료인 경우에는 그냥 사용할 수 있는 듯 합니다. 크기도 바꿀 수 있는데, 기본적으로 다양한 크기 내려받기를 ..
[마소 V.396 리뷰] 문서 엔지니어링과 API 문서화 요즘 살짝 관심있는 분야라 흥미롭게 읽다가 한 문장에서 딱 마음이 걸렸습니다. ...API 레퍼런스는 이를 사용하는 개발자가 가장 많이 보는 기술 문서이며, 문서 엔지니어링을 어떻게 하느냐에 따라 작성 시간 및 출력물 모양이 크게 달라진다. 이런 이유로 전문 테크니컬 라이팅팀을 보유한 회사라면 자체 API 문서화 솔루션을 가져야 한다고 생각한다. 완전히 새로운 도구를 만들어야 한다는 것이 아니라, 이미 있는 도구를 사용하더라도 트렌드 변화에 맞춰 정확하게 전문적인 결과물을 내놓는 프로세스를 가지고 있어야 한다는 뜻이다. 구글도 그렇고 마이크로소프트도 그렇다. LINE 역시 다르지 않다... 최근 오프라인으로만 제공하던 API 레퍼런스 게시를 처리하면서 몇몇 회사들을 조사해보았는데, 글쓴이가 이야기한것처럼..
[마소 V.396 리뷰] 문송한 국문과의 보안회사 입문기 문송하지 않는 경우라 하더라도 새로운 기술의 용어에 대한 어려움은 누구나 마찬가지일겁니다. 오히려 국문학을 공부한 분들이 더 유리하지 않을까 싶네요. 때문에 이 글은 전혀 공감되는 글은 아닙니다. 물론 다른 분야의 경우에는 전문적인 학회 등에서 용어를 정의하는 활동을 참 열심히 하고 있습니다. 그에 비해 IT 분야는 너무 빠르게 새로운 표현이나 기술이 등장해서 그런지 용어 정의에 대한 활동이 쉽지 않습니다. 이런 학회보다는 커뮤니티를 중심으로 또는 책을 번역하는 과정에서 용어가 정리되는 경우가 더 많지 않을까 싶습니다. 이 글에서는 독특하면서도 이런 경험이 있다 싶은 내용이 바로 키워드 검색입니다. 맞춤법에 맞지만 뭔가 맘에 들지 않는 경우 검색 결과에 의존하게 됩니다. "결과값"과 "결괏값" 같은 경우..

반응형