プロジェクト管理ツールで課題を依頼形式で書くのはやめたほうがいい - Qiita
件名: xxx機能追加のお願い 内容: Aさん xxx機能の開発をお願いします。 仕様は以下の通りです。 - xxxの時にはxxxになるようにしてください。 - xxxはxxx機能を参考にしてください。 ここまで極端な例は稀ですが、「xxxをお願いします」と書かれた課題は結構見かけます。 依頼形式で書くことの問題点 課題を依頼形式で書くことが多いプロジェクトでは、以下のような問題が発生することがあります。 担当が決まるまでタスクが管理されない 人に依頼するタスク以外が管理されない 着手中のタスクしか管理されない 残タスクがわからない 依頼者以外が課題を編集しづらい 担当が決まるまでタスクが管理されない 依頼形式の課題は担当者に依頼する形で書かれるので、担当者が決まってから登録されます。 逆に言うと、担当者が決まるまでは課題が登録されないことになります。 つまり、プロジェクトでやるべきタスク
わかりやすいドキュメントを書くには 〜 全体像を把握できることが重要 - Qiita
はじめに エンジニアなら誰でもたくさんのドキュメントを読むことになります。 その中にはわかりにくいドキュメントも少なからずあると思います。 自分はわかりにくいドキュメントは「全体像が掴みにくい」ことが多いと感じています。 そこで、ここではわかりやすいドキュメントを書くための方法を「全体像を把握できるようにする」という視点でまとめてみました。 また、最後に具体例としてQiita APIドキュメントでわかりにくい点の指摘と改善をしてみました。 ここで扱うドキュメントの種類 ここでは仕様書やリファレンスマニュアルといった類のドキュメントを想定しています。 Qiitaの投稿やブログの記事といったものでも共通する部分は多いのですが、これらには他にも重要な要素があると思うので、ここでは扱いません。 わかりにくいドキュメント=全体像が掴めないものが多い 先ず、わかりにくいドキュメントとはどんなものでしょ
Scalaでのメソッド呼び出しの書き方一覧と推奨される書き方 - Qiita
先ずは非推奨な書き方も含めて呼び出せる全ての形式をコードに書いてみる。 ////でコメントアウトしてある行は使用できない形式になる。 class Hoge { //引数リストがないメソッド def f1 = 1 //引数がないメソッド def f2() = 1 //引数が１つのメソッド def f3(x: Int) = x * 2 //引数が複数のメソッド def f4(x: Int, y: Int) = x * y } //引数リストがないメソッド ////hoge.f1() ////hoge f1() hoge.f1 //> res0: Int = 1 hoge f1 //> res1: Int = 1 //空行は伊達じゃないよ //引数がないメソッド hoge.f2() //> res2: Int = 1 hoge.f2 //> res3: Int = 1 hoge f2() //>
React.js使ってQiitaトレンド作ってみた - Qiita
2017/03/01 WebサービスとしてリニューアルしてHerokuで公開しました。 QiiTrend QiitaトレンドをリニューアルしてQiiTrendを作った - Qiita データ取得方法を変更したので、長期間のデータが高速に取得できるようになりました。 サーバーサイドでデータをキャッシュしているので、一度表示したデータは次回から高速に表示できるようになりました。 Qiitaの検索オプションがそのまま使えるようになり、タグ以外の検索もできるようになりました。 以下、2015/04/06の内容 最近話題になってるReact.jsを使ってクライアントサイドだけで動く簡単なアプリを作ってみた。 ソース https://gist.github.com/tag1216/819ded0722cedf75996f デモ http://bl.ocks.org/tag1216/raw/819ded
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
