白蔵 盈太/Nirone @「実は、拙者は。」5月双葉文庫で発売予定 @Via_Nirone7 小説の文章力っていうと、「素敵な比喩」「独自性のある文体」みたいなのをつい想像しがちなのだが、推敲の時に私が編集さんから受ける指摘なんて十中八九こんな感じで、実はそんなのは不要で「起こっていることを正確に全部言葉で書き表す」というのが一番の文章力なんじゃないかと最近は思っている。 pic.twitter.com/9YI6MEK0XK 2021-12-03 21:47:14 白蔵 盈太/Nirone @「実は、拙者は。」5/16双葉文庫で発売予定 @Via_Nirone7 しろくら えいたと読みます。 12歳息子と9歳娘に翻弄されつつ小説を書く46歳。既刊作：「わたしのイクメンブログ」(Nirone名義・漫画化)「あの日、松の廊下で」「義経じゃないほうの源平合戦」「桶狭間で死ぬ義元」「関ヶ原より熱
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
『GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』という書籍を最近出版したので紹介します。本書ではGitHub Actionsの実装と、CI/CDの設計・運用を体系的に学べます。一粒で二度美味しい書籍です。筆者個人としては「実践Terraform」以来、4年半ぶりの商業出版になります。 gihyo.jp どんな本？ GitHub利用者にとって、もっとも導入が容易なCI/CD向けのソリューションはGitHub Actionsです。GitHub Actionsの活用事例は多く、検索すればたくさん情報が出てきます。ただ断片的な情報には事欠かない反面、体系的に学習する方法は意外とありません。CI/CD自体がソフトウェア開発の主役になることもまずないため、なんとなく運用している人が大半でしょう。そこで執筆したのが『GitHub CI/
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ちょっと書きたくなったので書くんじゃーい！ この文章を読み終わった時、読者がそれなりわかめ品質な文章を出力できるようになり、どこかに寄稿した時に全面リテイクを食らったりしないようになることを目指します。 mhidaka が 0歩目を書いてくれました！ 背景 筆者は普通のエンジニアです。その辺の開発とかしてる会社に勤めています。技術系の原稿も書きます。 原稿書きでご飯食べてるわけではありません(晩ご飯が豪華になることは稀にあります)。 今まで有能なレビューワー(muなんとかさんとか)編集さんとか(某社の安藤さんとか)とかとかに鍛えていただ
だから、いかに書くかなんて考えたことはなくて、いかに書かないかばかりを考えている。小説を書き始めた頃に、これに気づき、以来ずっと、どこまで削れるか、というチャレンジを続けている。 http://blog.mf-davinci.com/mori_log/archives/2008/03/post_1754.php 非常に興味深い文章。 結城の場合はどうだろう。結城が文章や本を書く流れはこうだ。 複雑・難解だけれど興味深い現象や事象がある。 その「原典」や解説文があるけれど読みにくい／分かりにくい。良さが伝わらない。→いらいらもやもや。 書きたい、と思う。 勉強しながら、少しずつ何かを書く。 いくら長くてもいいから、全部を説明しきる（書くこともあれば、書かないこともある）。 読者にわかってもらえるトピック、さらに学ぶための核になるトピックを選ぶ。 適切な比喩、適切な物語を何とか見つけ出す（書き
eXtreme Programmingの12のプラクティスを、自分の本を書く過程と対比させてみました。 とても一致するところと、一致しないところがあります。 12のプラクティスの項目と解説文はXP FAQのページから引用させていただきました （問題がありましたらご連絡ください）。 XP FAQのページ 計画ゲーム(The Planning Game) XP:ビジネス優先度と技術的見積により次回リリースの範囲を早急に決める。現実が計画と変わったら、計画を更新する。 結城:レビューアへの原稿送付の時期は、おおよそのところは前もってレビューアに提示するが、実際には書かれた段階でリリースする。 小規模リリース(Small Releases) XP:シンプルなシステムを早急に生産に投入する、それから新バージョンを非常に短いサイクルでリリースしていく。 結城:目次をレビューアに送付する。それから各章を
目次 2005年8月31日 - Perl版の「メモ化(memoization), 再帰関数定義関数, 最小不動点」 / スマトラ沖地震・津波 / 2005年8月30日 - Windowsで、手早くPerl6で遊ぶ / 他の人から学べない「何か」 / 2005年8月29日 - ミルズの外科手術チーム / 2005年8月27日 - POPFile / 2005年8月26日 - 今日も仕事 / 2005年8月25日 - 今日も仕事 / 2005年8月24日 - 今日も仕事 / 人月はなぜ神話か / 2005年8月23日 - 説明文を書く2つのフェーズ / 秋は勉強の季節 / 2005年8月22日 - 仕事 / プログラマのダイエット / 2005年8月21日 - ジェネリクス・クイズ(2) / 2005年8月19日 - ジェネリクス・クイズ(1) / テストが困難な性質 / 2005年8月18日
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
