いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
企画書・提案書を書くならおさえておきたい！プレゼン資料お勧めの「フォントサイズ」 ｜プレゼンデザイン
プレゼン資料のデザインで、たびたびトピックにあがるものといえば「フォント」。当サイトでも過去に取り上げている内容ですが、今回は少し切り口を変え「フォントサイズ」についてご紹介します。というのも世間ではこの点、結構あいまいに扱われているような気がするんですよね。。 最適なフォントサイズは 「資料の利用シーン」によって変わる ときどきネットで「プレゼン資料のフォントサイズは○○pt以上がお勧め」といった記事をみかけるのですが、もうちょっと補足しても良いんじゃないかな？というのが筆者の意見です。なぜならプレゼン資料に適したフォントサイズは「その資料が、どういう条件で利用されるか」によって変わるから。 恐らく多くの指南書・ノウハウ記事がイメージしているのは「講演資料」です。しかし、プレゼン資料の利用シーンは講演以外にもいろいろあるわけで。そこで当記事では、社会人ならきっと誰もが接する「企画書」や「
脱GitHub初心者を目指す人のREADMEマークダウン使いこなし術 | ゆっくりと…
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 （マークアップ） されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown （略して GFM） という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 （もちろん GitHub 初心者です！） の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ （レンダリング） を気にして
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
Scala上級者になるために読んでおくべき海外blogまとめ - xuwei-k's blog
上級者というより、基本的には 「べつにbetter javaとして使うならば必ずしもScalaでそこまでやらなくてもいいのに、関数型の濃い話が書いてあったりする」やつです。*1というか、自分が勉強したくても一回読んだだけじゃよくわからなくて、読み直したいもののメモです。独断と偏見で選んだので、他にもあるかもしれませんがとりあえず 1. http://apocalisp.wordpress.com/ Scalazのcommiterの人です。 type level programming のシリーズ *2とかyuroyoroさんが一部訳していたりしましたね。このシリーズ順を追ってけっこう網羅的に説明されてて素晴らしいので是非読みましょう！もちろんこのシリーズ以外にも面白そうなものありますが https://twitter.com/#!/runarorama https://github.com
Facebook開発者向けドキュメントの日本語訳とTips
2015年04月05日18:15 by oklahomer Graph API v2.3 からは access_token の返され方が変わります カテゴリ 4/25 から開催された F8 2015 で、Graph API v2.3 が紹介されました。Graph API を扱う上で影響が大きいと思われるものをここでは紹介します。詳細は公式 Changelog や Upgrade Guide を参照してください。 /oauth/access_token のレスポンス変更 これまでは URL エンコードされたクエリ文字列が以下の様な形式で返されていました。 access_token=foobar&expires=5183814 今後は以下のように JSON オブジェクトが返されるようになり、項目も若干変わります。 expires が expires_in に変わっている点も要注意です。 {"a
シゴタノ！ — わかりやすい文章を書く上で最低限おさえておきたい読点の二大原則
By: Alex Ziv – CC BY 2.0 「わかりやすい」と言われるような文章を書きたいものです。 とはいえ、単に「わかりやすい文章」というだけでは具体的に何をどう改善すればいいのかがイマイチ「わかりにくい」。 そこで、今回は読点（テン）の打ち方に絞って「わかりやすい文章」に一歩、近づくことにします。参考図書は、現代国語や小論文が苦手だった学生時代の僕に文章を書くことの楽しさと深遠さを教えてくれた以下の一冊。 「血まみれ」になったのはどっち？ 、（テン）や。（マル）や「（カギ）のような符号は、わかりやすい文章を書く上でたいへん重要な役割を占めている。とくにこの場合、論理的に正確な文章という意味でのわかりやすさと深い関係をもつ。（p.74) ということで、テンの役割の重要性を示すために挙げられているのが次の例。 渡辺刑事は血まみれになって逃げ出した賊を追いかけた。 渡辺刑事は、血まみ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
逆引き辞典