登場人物を分類し、振る舞いを分解して、機能を考える（企画職の人に教えてもらったこと） - $shibayu36->blog;
本職の企画の人が優れた機能案を出してくる理由がわからなくて、どうやってやってるんですかと雑談した。新たな発見があったので、雑なメモだけ残しておく。*1 その人の企画の流れ 企画の流れは、以下の3ステップで行っているらしい。 1. 登場人物を分類する 2. 登場人物ごとの振る舞いを分解する 3. 様々な振る舞いを照らし合わせて、機能・UIを絞り込んでいく 「1. 登場人物を分類する」は、機能に関わる人物をツリー構造に分類していき、分類をした結果から、その機能を使うメインターゲットを決めるフェーズらしい。 例えば、ブログユーザーをブログの作者と読者に、さらに作者を毎日更新する人とそうでない人に、みたいにどんどん分解していく。すると、機能のメインターゲットが浮かんでくる。 「2. 登場人物ごとの振る舞いを分解する」では、メインターゲットを中心に、どのような振る舞いをするかを考えるフェーズらしい。
乱数の性質とセッショントークンの作成 - $shibayu36->blog;
ユーザアカウントのログイン機能とか作ってると、何らかの形でセッション用のトークンを作成する機会がある。今まではこれは適当にランダムな値を利用していればいいんでしょと思っていたのだけど、ちょっと違ったのでメモ。 乱数の性質 http://akademeia.info/index.php?%CD%F0%BF%F4によると、乱数には三つの性質がある。 無作為性：統計的な偏りがなく、でたらめな数列になっているという性質。 予測不可能性：過去の数列から次の数を予測できないという性質。 再現不可能性：同じ数列を再現できないという性質。再現するためには、数列そのものを保存しておくしかない。 この時、少なくとも無作為性のみ満たされていると弱い擬似乱数、無作為性と予測不可能性が満たされていると強い擬似乱数、全てが満たされていれば真の乱数と呼ばれる。ソフトウェアだけでは、真の乱数を作ることができず、真の乱数に
git revertで複数コミットを巻き戻す方法 - $shibayu36->blog;
今日git revertを使っていて、少しわかりづらかったのでメモ。実はこのこと昔に書いていたんだよね。http://d.hatena.ne.jp/shiba_yu36/20100221/1266680669 さて、次のコマンドを打つと、単一のコミットを巻き戻す内容のコミットがなされます。このコマンドを打った瞬間にコミットされてしまうので、複数のコミットを巻き戻すコミットを作れません。 git revert (コミット名) しかし、git revertには-nオプションというものがあり、これを使えば複数コミットを巻き戻すコミットを作れます。-nオプションのヘルプを見ると n, --no-commit Usually the command automatically creates a commit with a commit log message stating which commi
pecoで最近更新されたブランチにcheckoutする - $shibayu36->blog;
昔、最近commitされたブランチをanythingライクに絞り込んでcheckoutする、というものをzawの時もpercolの時も実装していた。 zawを使って最近更新したブランチをチェックアウトする - $shibayu36->blog; ターミナル版anything的なpercolをzawの代わりに試してみた - $shibayu36->blog; 最近はpecoを使うようになったので、ほぼコピペで再実装した。 設定方法 git-recent-branches.zshのようなファイルを用意し、peco-git-recent-branchesとpeco-git-recent-all-branchesを実装する。 function peco-git-recent-branches () { local selected_branch=$(git for-each-ref --forma
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
MySQLをさらに理解するために読んだ記事まとめ - $shibayu36->blog;
最近MySQLの勉強をしていました。実践ハイパフォーマンスMySQLを読むべきという話を聞いていたのですが、かなり網羅的に書かれていて、今の知識ではどれが重要なのかわからない状態でした。そこで色々調べてみて、参考になる記事をいくつか見つけたので、少しまとめてみようと思います。 今回まとめた記事を読んで、大体以下のことが理解できました。 インデックスの使われ方とその構造(MyISAMとInnoDB) EXPLAINの詳しい使い方、見方 InnoDBの特性 ALTER TABLEの特性 レプリ遅延 まず最初に Webエンジニアのための データベース技術[実践]入門 (Software Design plus)posted with amazlet at 12.06.02松信 嘉範 技術評論社 売り上げランキング: 9767 Amazon.co.jp で詳細を見る 松信さんの書いた「Webエンジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
