西村マサヤ @masayaquality 今日、違う部署の新卒から「わかりやすい文章を書く方法を教えて欲しい」と言われたので、このリストを送ったのだけど、ほんとこの20個意識するだけでだいぶ変わると思うな。 新卒や学生はぜひ実践してみてほしい。 pic.twitter.com/JrUgbpmD53
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 (作業成果物の欠陥と改善の機会を探すレビュー) 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考: あなたのおっしゃるレビューってどのことかし
メンバーの一部がスムーズに情報共有できるチケットを書けず 苦戦しており、相談を受けた時に色々言った内容を 書き起こしたもの。 荒いけど誰かの参考になるかもしれないので共有。 2019/09/07 宣伝追記 技術書典サークル参加します。 チーム運営どう考えて何をやったかまとめた本とセキュリティの 入門書を頒布するので気になった方は是非。 https://techbookfest.org/event/tbf07/circle/5671044488626176 書いた人の環境 業務ツールとしてチャット、Redmine、Wikiを使用。 チャットで会話して相談・整理・調整する。 タスク、課題はチケット化して管理。 ナレッジはWikiに書いて共有。 業務内容はシステム開発と運用保守でソフトウェア開発ではない。 Redmineはタスク・課題管理に使用。 以下、メンバーに伝えたことを清書したもの。 前提
と思っている話です。もはやタイトルでぜんぶ言ってしまった。 せっかくなのでもう少し続けます。 2020/05/03追記:第二弾?書きました この本がまだ初稿になる前、共著者のみなさんと執筆真っ最中の頃に何度か打ち合わせがあったのですが、そこで「書籍的な文章を書き慣れてない人って、"という"と"こと/もの"を多用しがちなので、この2つを抑えるだけでも文章がシュッとするんですよ」とお話したら思ったより反応があったので、これは需要があるんじゃないかと感じたのがきっかけです。 ここから先は具体例を交えて解説していきます。 さすがに他人様のテキストを使うのは気が引けるので自分が書いた記事を例に挙げます。……でも自分はこのテクニックを使うようにしているので、該当する記事がなかなかないんですよねぇ……と思ったらあった! (よりによってこれか……せっかくなので皆さんスタァライトを観ましょう!) 記事中では
役立つコードレビュー(CR)のコツは、学校では習いません。アルゴリズム、データ構造、プログラム言語の基礎は習っても、確実に役に立つフィードバックを返す方法をじっくりと教えてくれる人はいないでしょう。 コードレビューは優れたソフトウェアを作り出すには欠かせないプロセスです。レビューを通したコードは、そうでないコードよりも 質が高く、バグが少ない 傾向があります。健全なコードレビュー文化には、副次的な利点もあります。たとえば、 バス因子 を押しとどめる、新メンバーのトレーニングに最適なツールになる、など。また、コードレビューは優れた知識共有の手段でもあります。 前提 まずは、この記事のポイントの前提を提示する必要があるでしょう。それは以下のとおりです。 信頼のおける環境で作業をしている。あるいは、あなたとチームは、あなたの信頼性を高めることを目指して作業している。 コードではないシナリオでフィ
個人的に大切にしていることを書いていきます。少しSREの話が出てきますが、私がSREチームだから出しているだけで、基本的にSREに関係の無い分野でも使えるはずです。 前提となる心がけまず前提となる心がけについて書きます。 エンジニアは恐いと思われている人は自分と関わりの少ない人のことを恐いと思いがちです。 システムはほとんどの人にとってブラックボックスです。そしてシステムを担当しているエンジニアのことも、ほとんどの人にとって未知の存在です。関わりが少ないからこそ、ほとんどの人にとってエンジニアは恐い存在です。 ビジネスをやっていく上で、エンジニアとのやりとりは非常に重要です。そのエンジニアと他の社員のやりとりがしにくい状況だとお互いにストレスが溜まり、不健全な組織となっていきます。 これを解消する一つの手として、例えばチャンネル名が z- から始まるチャンネルは雑談していいというようなルー
先日投稿した以下のエントリで、「使い方がわからない」という意見を多く頂いた。 mugi1.hateblo.jp マルチカーソル自体の操作方法は調べれば出てくるし、事例だけ紹介しとけばええやろ、と思っていたのだが、いきなり応用のサンプルを貼りすぎてわけがわからなかったらしい。申し訳ない。 せっかくなので、基礎から含め、どういったキー入力で上記のような操作を実現しているのかを紹介したいと思う。 🔥実践!マルチカーソル / 入門編 なおmac環境です。Windowsやその他環境の方は気合で調べてください。 また、言い訳臭くて申し訳ないが、私は普段はSublime Text Keymap and Settings Importerを使っており、SublimeTextっぽいキーバインドに変えて編集している。 一旦無効にしたうえでVSCodeデフォルトの状態で一通り調べて書いたつもりだが、もし違って
Misoca+弥生+ALTOA Advent Calendar 2018の10日目のエントリです。 グッと来るタイトルにしようと思った結果、意味不明になってしまったのは自覚している。許してほしい。 ※解説編について 何やってるかわからんという声を多数頂いたため、解説編を書いた。 よかったら併せてご覧ください。 マルチカーソルを使わないVSCodeはただのVSCodeだ!〜解説編〜 - memo.md 🤔 マルチカーソル? さて、VSCodeではカーソルを複数作ることができる。 vscode-doc-jp.github.io 簡単な動作例 これはVSCodeに限った機能ではなく、SublimeText, Atom, JetBrains製IDEなどでも似たようなことができる。 昔にSublimeTextを使い始めたころから愛用している機能で、私はこれが無いと生きていけない体になっている。 意
ここでは、最強のMarkdownエディタTyporaについて紹介する。 機能に関しては随時更新予定。 ざっくり概要 Typoraを使ってMarkdown書いているときの様子は以下のような感じになる。 後述するが、記述したその場でスタイリングしていく仕組みなので、「プレビュー表示」という概念がない。 そのため、目線を行ったり来たりさせる必要がない。 例えば、 上記のように#記号に続いて文字入力を行い、Enterキーで改行すると.... このように、自動的にその場でMarkdownの見出し表示になってくれる。 Typoraのいいところ 記述したその場でスタイリングしていく仕組み そのため、2つの画面を目で行ったり来たりする必要がない 操作が極めて直感的 高機能であるにも関わらず、インターフェースがとてもシンプル 数式・画像の挿入、表の作成など、通常のエディタだと苦戦するような操作も非常に簡単に
今日はプログラミングの生産性に対して気づきがあったのでシェアしてみたい。 なぜ米国の人は生産性が高いのだろう プログラミングの生産性に関しては以前から興味がありいくつかのポストで考えたことをシェアしてきた。私は職業柄、いろんな国でいろんな人々とプログラミングを一緒にする機会が多い。その時に頻繁に感じるのは、平均的に言うと、アメリカの人プログラマが生産性が高い確率が高くて、しかもコードもきれいだという傾向にある。アメリカでお客さんと一緒にコードを書くと、お客さん自体が物凄く良く知っているし、実行力もある。アメリカの次と言うことでいうと、英語がネイティブの国もそれに近く、フランスなどの言語が近いところが続く感じなので、英語が物凄く影響すると思っていたし、実際すると思う。そのあたりの話はこちらのポストに書いてみた。 simplearchitect.hatenablog.com 定義での理解と、例
別プロダクトの社内勉強会で「ブログ」をテーマに発表して欲しいと依頼があり,「ブログを書く技術」というタイトルで発表をしてきた.今回,改めて「僕がなぜブログを書くのか?」というモチベーションの部分を整理することができたので非常に良かった.なお,再演もできるので,もし「うちでも発表して欲しい!」という話があれば(なさそう),気軽にご連絡を頂ければと! 発表資料 伝えたかったこと 前にツイートした内容にも関連していて,やはり「続けること」が難しいという人が多いように思う.だからこそ「習慣化」を意識するべきでは?という問題提起をしたかった.また,ブログにこだわっているわけではなく,あくまで「アウトプットの形の一例として」ブログが良いのではないかという話をした.発表中に余談なども多くしたため,発表資料だけでは伝わらない部分もあるかもしれない. 「どうしたらブログ続けられるんですか」って相談よく受ける
2017 - 02 - 26 ●15年間の学びを格言・雑学とともに。書く習慣を身に着けるコツ。 書く習慣コーチング(日刊) はじめに おはようございます。書く習慣コーチングのカクノシンです。 記事のはじめに、私が人生を変えるときに役に立った 格言と雑学をいくつか紹介して今日の記事について 書きたいと思います。 格言には、自分を変えていく中で勇気をもらいましたし、 雑学は人とのコミュニケーションをとるときに参考にしてきました。 今日の格言 ・目的を見つけよ。手段は後からついてくる。 -ガンジーー ・今からやっておかないと3年後の成果はないかもしれない。 -吉岡秀人ー ・怒ると、その相手よりも自分を傷つけてしまうものよ 。 -オプラ・ウィンフリーー ・一日一日を確かに努力して身につけたものが、 君たちの生涯の財産になります。 -坂本金八ー ・最近勝ち組とか負け組みとか流行っているけど、 スター
とにかく書くのが苦手、そして心をつかむ文章を書きたい人向け レビュープラス さんから本が届きましたので早速書いていきたいと思います。 全九章なのですがご紹介していきたいと思います。 一章:なぜ文章を書くのが苦手なのか? 二章:テーマに迷わないから早く書ける! 三章:ネタ集めに迷わないから早く書ける! 四章:組み立て方に迷わないから早く書ける! 五章:速く書き続けるには? 六章:書き出しで迷わないから早くかける! 七章:「?!」をちりばめ、心をつかむ文章にする! 八章:最終チェックで心をつかむ文章にする! 九章:「速く」「面白い」文章を書く習慣作り レビュー! この全九章を読むと解るのはとにかくブログを書くのが遅い人というのは「全体的なイメージができていない」という事。「一瞬で心をつかむ文章術」に書いてある方法を使えば確かにブログを書くのは速くなると思いました。 四章に書いてある「序論→本論
はじめに 先日、とある知りあいのRubyプログラマからこんな相談を受けました。(内容はちょっとボカしてます) 社内のコードレビューでもっときれいなコードを書けるようになった方がいい、と言われました。 「きれいなコードを書けるようになれ」と言われても、具体的にどうすればいいかわかりません。 伊藤さんのアドバイスを聞きたいです。 この内容だけだとどんな問題があるのかわからないので、実際に指摘を受けたRailsアプリのコードを見せてもらいましたが、確かに「もうちょっと頑張りましょう」と思うような点がチラホラありました。 ただ、具体的にどうすればいいの、という答えは一言では言えません。 というわけで、今回のエントリではこの悩みを解決するのに参考になりそうな話をあれこれ書いてみようと思います。 (その前に)もくじ かなり長い記事になってしまったので、先に目次を載せておきます。 はじめに (その前に)
うまい文章が書きたい。書き方を調べると様々な法則があるようだ。ポイント、ルール、問題点、コツ、ヒント、基本、原則などをまとめてみた。 1.文章を書くのが苦手な人もわかりやすい文章を書ける10のポイント 文章を書くのが苦手な人もわかりやすい文章を書ける10のポイント | 株式会社LIG 主語と述語は正しい関係か 助詞の使い方は適切か 長すぎず、短すぎず 読み手の視点に立っているか それっぽいことを適当に書かない 言葉が足りているか 誤字脱字や表記揺れのない、正しい言葉づかいを コンテクストがあるか 戦略があるか 声に出して読んだとして、違和感がないか 2.読みにくい文章にありがちな、7つの問題点 読みにくい文章にありがちな、7つの問題点 - エディターズダイアリー | ジセダイ 省略してはいけないものを省略している 主述転倒がやたらに多い 誤字脱字や表記揺れが多い 繰り返しが多い 似た表現が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く