git-schemlexとddl-makerを使ったDB migrationの紹介 / git-schemalex and ddl-maker migration #golangtokyo
皆さんはじめまして。ゲストとして呼ばれた、secondlife です。Tateno Culture といった形で以前森田さんが書いていたが、あれは Tateno Culture というよりは Hatena Culture の話だと思っています。なので、今回はインフォーマルな文章という主題とはずれるかもしれませんが、自分はなぜそんな感じの文章を書いていたのか、というのを当時のはてな時代を振り返り書いてみようと思います。 はてな社に居た当時、これが皆さんの想定するインフォーマルな文章かはさておき、さまざまな社内向け文章を社内の全員、とは言わないまでも、7-8割の人がけっこう書いていた。 自分もしょっちゅう書いていたのだけど、なぜ書いていたのかを今更考えると、それはひとえに『楽しかったから』だった。 なぜ楽しかったのか 当時は2006年頭、自分は15人目の社員として会社にジョインした。入社すると
この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである
こんにちは、Developer Contentチームのmochikoです。LINE株式会社でテクニカルライターとして働いています。今日は「テクニカルライター」というお仕事と、LINEにあるテクニカルライティングの専門チームについてお話しします。 テクニカルライターという職種があります テクニカルライターって何をしてるの？何を書くの？ ドキュメントはどうやって書いてるの？ どんなメンバーで仕事をしてるの？ ドキュメントを書く以外にこんなこともしているよ でもドキュメントを書くだけだと技術力が下がらない？ どんな人がテクニカルライターに向いてるの？ テクニカルライターという職種があります 私はもともとウェブ制作会社のインフラエンジニアでした。とある技術書を書いたことをきっかけに「テクニカルライターとして一緒に働きませんか？」と声をかけてもらい、LINEへ転職するに至ったのですが、実はお誘いをい
会社でScrapboxを使っている。チームごとやプロジェクトごと、話題や趣味ごとにプロジェクトを作っていて、うちのチームは1年3ヶ月くらい使って3000ページほどに達している。 どんどん書いていたのだけど、最近、どこに何があるかわからなくなってきていた。同僚に、ここの仕様はどうでしたっけ、って何度も聞いてしまうことがあったので、これはまずいと思ってちょっと整理していた。 表記揺れを直す One Fact in One Placeということで、どんどんページをマージしていった。ページを同名にリネームするとマージボタンが出現して押すだけなので楽。 よくみるとスペースの有無によって同じ話題のページが2ページに分かれていたり、略称と正式名称と、「(正式名称)まとめ」の3つにわかれたりしていた。情報を探しているときにはどんどんマージしたりしないので、今回マージするぞと見返せてよかった。 サポート担当
なぜ Day One は Markdown を捨てたのか Day One が Markdown をやめて WYSIWYG に移行した話は前書いた。 Day One がクソになった Day One 、このブログでも度々言及していて、 Markdown で日記が書けて便利だったんだけど、最近のバージョンアップ（ Mac は 2.8 以降 、 iOS は 3.0 以降）でプレー... portalshit.net 自分が知っている範囲でアンチ Markdown 勢は Scrapbox くらいしか思い浮かばず、 GitHub や Trello などのグローバル勢に加え、 Qiita やはてなブログなど日本国内向けのサービスでも当然のように Markdown が共通言語として使われているのに、その Markdown を捨てて WYSIWYG 化する1という戦略は疑問だった。 ひとむかし前の WYSI
有用な文書を作るために心掛けたいこと この記事は rogy Advent Calendar 2018 の21日目の記事 (#LATECH) です。 前日の記事は STM32でマウスとキーボードを作る – 東京工業大学 ロボット技術研究会公式ブログ でした。 文書を“作る” この記事を読む皆様は、少なからず日頃から文章を書くことがあるかと思います。 文章を書き公開しようというとき、「良い文章の書き方」はいろいろなところで目にしますし、必要とあらば勉強することもあるでしょう。 しかし、文章そのものではなく「良い文書の作り方」を意識したことはありますか？ どんなに良い文章であっても、駄目な性質を多く持つ文書として公開されると、その価値は暴落します[0]。 本記事では、内容はさておき「良い文書」を作ろうというとき私が心掛けていることなどを紹介します。 良い文書とは 私の考える良い文書とは何なのか、
業務でドキュメントを作成するケースは多々ある 例：仕様書・設計書・提案書・メール・障害票．．． ここでは各ドキュメント共通してありがちなアンチパターンをまとめてみました。 1. 表記がバイト表示・マイクロ秒表示 プログラムが出した数値をありのままに表示するパターン ファイルサイズが100MB, 1GBあろうと、バイト表示にする 桁数が多い数値に、桁区切り（,）を入れない 時間を何でもマイクロ秒・ミリ秒にする（1/100万秒までの精度が必要？体感で分かる？） 桁数が多い＝精度が高い＝良い文書、ではなく、見る人が必要とする精度に切り上げることが重要（売上で１円単位まで出すことが無いのと同様） 悪い例 No ファイル名 ファイルサイズ(byte) 処理時間(秒)
StackOverflowが新サービス「Documentation」を開始。サンプルコードを中心に技術解説、質問されなくとも有用な情報を共同で作成 StackOverflowは、エンジニア向けのQ&Aサイトとしてよく知られています。誰かが質問をすると、その答えを知っている人が回答する。質問をよりよくするために書き換えることもできるし、質問や答えの有用さを評価することもできて良い質問や良い答えはポイントが上がるなど、サイト全体のコミュニティの質が保たれるような仕組みを備えているのが特長です。 そのStackOverflowが、新サービス「Stack Overflow Documentation」（以下Documentation）をベータ版として公開しました（英語版StackOverflowにて。日本語版StackOverflowにはまだのようです）。すでにさまざまなトピックのドキュメントがあ
Vimwiki is a personal wiki for Vim – interlinked, plain text files written in a markup language With Vimwiki you can organize notes and ideas and quickly create links between them manage todo-lists write a diary Features three markup syntaxes supported: Vimwiki's own syntax, Markdown, MediaWiki export everything to HTML link to other wiki pages and external files search through all wiki pages outl
Tracには「wiki」しかなかったのに、Redmineでは他に「フォーラム」なる仕組みも用意されていてややこしい。目的に応じて使い分けよ、とは確かに一つのアドバイスだとは思うけど、初めて使う人にそんなことを言っても通じないだろう。そんな訳である程度の指針や具体例が必要になるわけだが、今のところ、次のように使い分けている。 フォーラム 一度掲載したら変更しない文書用。具体的には、メールの共有保管場所だ。一度送ったメールはもう2度と変わらない（変えようが無い）し、スレッドごとにまとめて掲載できるので、後からの参照も容易だ。これで、チーム内に「情報共有」と称した無駄なメールの展開を減らせるようになる。 Wiki 何度も情報を更新する文書用に使っている。具体的には、チーム内の作業手順や障害の発生例と対策事例、ツールの手順や仕様書の類だ。これは一度書いたら終わりというものでも無いし、その履歴が実は
overlasting.net 2020 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
