테크니컬 라이팅 (355) 썸네일형 리스트형 2025년 1월 테크니컬 라이팅 이런 저런 소식 어쩌다 보니 24년 12월 이런 저런 소식은 그냥 지나가버렸습니다. 혹시라도 기다리셨던 분들께 죄송스러운 마음입니다. 다만, 딱히 새로운 소식도 없어서~ 1월 3일Microsoft refuses a documentation fix because AI might not understand text in tableshttps://pivot-to-ai.com/2024/12/17/microsoft-refuses-a-documentation-fix-because-ai-might-not-understand-text-in-tables/제목은 살짝 낚시 같은데, 맥락은 다르지 않습니다.사건은 마이크로소프트에서 운영하는 WSL 문서 저장소에 문서에 대한 수정 요청이 들어옵니다(24년 9월 15일). 원래 문서 내에 .w.. WTD 애틀랜틱 2024 - 라이트닝 토크 둘째날 Erich Studer: Make developers your friends with codemermaid.js 같은 도구를 사용할 때는 자동화와 연계해서 사용해야 한다는 이야기입니다. 보통은 문서화 솔루션에 통합되어 관리되기 때문에 별도로 mermaid 관련 코드를 관리할 필요가 없긴 한데, 개별적으로 작업한다면 그렇다는 이야기가 아닌가 싶네요. 뭐 딱히 새로운 이야기는 아닙니다.https://youtu.be/8CpAJf-PKn4?si=8f7XfKCN0vKAjT4y Erin White: Killing Serial Killer Cliches학부에서 범죄 심리학을 공부하고 정보과학으로 학위를 받았습니다. 독특한 커리어네요. 창작물에서 연쇄살인범 캐릭터를 효과적으로 만드는 팁을 이야기합니다. 음. 개인적으.. WTD 애틀랜틱 2024 - 라이트닝 토크 첫째날 Abi Sutherland: A Documentation Carol: Scrooge has tech writing lessons for us all 스크루지 이야기를 통해 기술 문서를 작성할 때에 명심해야 할 몇 가지 사항을 이야기합니다. - 오래된 시스템(과거의 유령), 미래의 시스템(미래의 유령)을 따라가지 말고 현재의 시스템을 문서화하세요. - 동료(말리의 유령)의 말에 귀를 기울이고 기존에 만들어진 템플릿을 활용하세요. - 사용자(크래칫 가족)에게 실제로 필요한 것이 무엇인지 알아보고 우선순위를 정하세요. - 커뮤니티를 통해 서로 협력하고 지원하세요.https://youtu.be/DewfY-ult8M?si=clPNXDDTxYlNwAP4 Ariel Kaiser: You just spilled a .. WTD 애틀랜틱 2024 - 테크니컬 라이터에게 언어학이 필요한 이유 테크니컬 라이터가 언어학을 알아야 하는 이유 중 하나는 스타일 가이드를 좀 더 적극적으로 적용할 수 있습니다. 단지 이미 있는 가이드를 찾아보고 적용하는 것이 아니라 이런 가이드가 왜 정해졌고 어떤 규칙에 의해 적용되는지를 알 수 있다는 겁니다. 그럼 혹 스타일 가이드에서 누락된(또는 적용하기 애매한) 항목이 있더라도 이를 확인하고 어떻게 적용해야 할지 알 수 있으며 스타일 가이드에 추가할 수 있다는 것이죠. 수동태를 쓰면 안 된다는 규칙도 상황에 따라서는 수동태가 적절한 경우가 있는데 스타일 가이드에서는 이런 점을 언급하고 있지는 않습니다. 보통은 수동태 예시를 보여주고 이걸 능동태로 바꾸어버리죠. 결론은 스타일 가이드라는 틀에 너무 갇혀 있지 말고 좀 더 깊은 지식을 기반으로 이해하고 사용하자는 것.. 지메일에서 발견한 신기한 기능 메일을 작성하다가 빨간 줄이 그어지길래 뭐 오타구나하고 보았는데 아무리 봐도 오타가 아니더라구요. 지메일에서 추천하는 텍스트가 뭐야 하고 보니 괄호 안에 나열된 항목이 중복되었다는 것이었습니다. 입력한 텍스트는 minheight, maxwidth, minheight 였는데 마지막에는 maxheight를 쓰려는 것을 잘못 쓴 것이었죠. 일반적으로 오타만 확인하는 것이라면 마지막 단어를 체크하지 못할 텐데 지메일은 괄호 안에는 어떤 목록을 나열하려는 의도라는 것을 파악하고 중복된 항목이 없거나 패턴에 따라 다음 단어의 순서를 예측하는 것 같습니다. 근데 똑같은 단어를 메일 쓰기를 열어 그냥 입력하면 이런 추천이 나오지 않습니다. 단순히 괄호만 보는 건 아닌것 같구요. 본문의 전체 맥락을 확인하고 리뷰를 하.. WTD 애틀랜틱 2024 - 테크니컬 라이팅을 처음 접하는 이들을 위한 가이드 테크니컬 라이팅을 처음 접하는 이들을 위한 강의입니다. WTD 세션으로 적절한지는 모르겠네요(아마 대부분 비용을 들여 이 행사에 참여하는 분들은 테크니컬 라이팅이 뭔지 어느 정도는 알고 있으니깐요). 그럼에도 영상을 통해 접하는 분들이 있다면 의미가 있겠네요. 많은 오해 중 하나가 테크니컬 라이터는 글만 쓰는 것이라고 오해를 합니다. 하지만 테크니컬 라이팅을 테크니컬 커뮤니케이션이라고도 하는 것처럼 골방에서 글만 쓰는 것은 아닙니다. 개발자나 관련 담당자들과 끊임없이 커뮤니케이션을 해야 합니다(그렇다고 직접적으로 대화를 해야 한다는 것은 아닙니다. 이메일이나 메신저 같은 수단 또는 문서 그 자체로도 커뮤니케이션을 진행할 수는 있습니다). 여러 팀과의 협업을 이야기하면서 상당 부분 너무나 협조적인 동료가 .. WTD 애틀랜틱 2024 - UX팀과 같이 일하기 아웃시스템즈(OutSystems)에서 콘텐츠 개발자로 일하는 2명의 발표자가 함께 합니다. 한 명은 인도, 한 명은 스페인에서 일하고 있습니다. 2021년까지 아웃시스템즈의 문서화는 신규 기능이 나오면 이를 정리하고 문서화했습니다. 전체적인 개요에 대한 정리가 필요했지만 신규 기능을 다루는 것만으로도 벅찬 상태였습니다. 때문에 사용자들은 개별적인 기능은 알 수 있었지만 자신의 목표를 적절한 방법으로 달성하는 정보를 넓은 시각에서 바라볼 수 없었습니다. 그래서 콘텐츠팀에서는 점진적으로 문서를 사용자 중심으로 개선할 계획을 세우고 이를 진행했습니다. 문서화 계획을 세우고 진행하는 과정은 일반적인 과정과 크게 다르지 않습니다. 콘텐츠를 만드는 과정에서 UX팀과 협력해 각 과업마다 user journey를 만들.. RDB와 NoSQL 이야기 옛날 옛적, 데이터 마을에는 두 명의 강력한 수호자가 살고 있었습니다. 그들의 이름은 RDB와 NoSQL이었죠. 이 둘은 모두 왕국의 데이터를 안전하게 지키고 관리하는 임무를 맡고 있었지만, 서로 다른 방식으로 일을 처리했습니다. RDB는 질서를 사랑하는 수호자였습니다. 그는 모든 것을 깔끔하게 정리하는 것을 좋아했죠. "모든 데이터는 정확한 자리에 있어야 해!"라고 말하곤 했습니다. 그의 세계관에서는 모든 것이 표로 나뉘어 있었고, 각 데이터는 미리 정해진 규칙에 따라 저장되었습니다. "이건 엄격한 규칙이지만, 그래야만 모든 것이 완벽하게 맞아떨어지지!" RDB는 항상 이렇게 말하며, 데이터를 정확하게 관리했습니다. 그는 데이터를 서로 연결하고, 복잡한 관계를 만들어내는 데도 능숙했죠. 그래서 사람들이.. 이전 1 2 3 4 ··· 45 다음
