「形式手法ってなんだろう」について
- はじめに
- セッションの成り立ちという名の言い訳
- 補足（という名のいいわry）
- 感想
- 最後に
はじめに
久しぶり、私のブログよ・・・ってほど放置してたわけですが、セッションの言い訳記事を書くっていっちゃったので今回のwacate2019冬セッション「形式手法ってなんだろう」について書きます。きっとクリスマスイブだからだれも気が付かない・・・はずだ！
書くとは言ったものの、Twitterでも書いた通り、今回技術的にも精神的にも本当に限界だったため、補足的なものはあまり書けないのです。
ですので、成り立ちという名の言い訳と、自分がセッションやってみての感想がメインになります 。ご了承ください。
続きを読むラムダ式を使ってFizzBuzzしてみる
ラムダ式が嫌いです。
おおよそ７年前くらいから苦手意識をひきずっています。
こんなお年頃になってもラムダ式が使えません。
というわけで、そろそろどうにかせねばとラムダ式でFizzBizzを書いてみようと思いました。
・・・これであってるのかな？真っ当なのかな？さっぱりわからぬ。
ていうか最初のFuncとかこんなに長いなら普通にメソッドに書き出せばいいじゃんみたいな気もする。
using System;
using System.Linq;
namespace FizzBizzWithLambda
{
class Program
{
static void Main(string[] args)
{
Func<int, string> func = n =>
{
if (n%15==0)
{
return "FizzBuzz";
}
if (n%3==0)
{
return "Fizz";
}
if (n%5==0)
{
return "Buzz";
}
return n.ToString();
};
Enumerable.Range(1,100).ToList().ForEach(i => Console.WriteLine(func(i)));
Console.WriteLine("おわり");
}
}
}
ちなみにGithubにも上げてみたけど、Githubもイマイチやっぱりよくわからない。。 まあ、練習なのできにしないでください。
追記：全部つづりがまちがってたもうだめだ。orz
【WACATE2017冬】ユーザビリティテストをやってみよう
久しぶりにブログを開いた。
最初のセッションはちゃんとブログ書いてたんだな覚えてなかったよ。
まあ、いいです。
「【WACATE2017冬】ユーザビリティテストをやってみよう」のセッションをやってみての雑感を書いてみます。
- セッション資料
※github使ったことないので、間違ってたら教えてください。
※ソースコードはもしかしたら予告なく消すかもしれません。
- 伝わらなかったかもしれないけど伝えたい点
- タスクは手順（小井土さんセッションでいうところの「レシピ」）ではユーザーに対する「操作指示」になってしまうのでうまいテストになりません。物語風（小井土さんセッションでいうところの「ガイド」）にして、ユーザーがいつもどおりの作業をやってくれる様を観察することに意味があるんです。
- こんな感じでユーザーテストやっても、わかってるところがわかるだけと思ってませんか？いやいや、実際やってみると面白いくらいでますし、わかってたところでも、実際の影響度がわかるのでとても有意義です。また逆に、テスト中いかにも使いづらそうだったのに見た目がいいと「使いやすくなりました！！」（満足度だけは大幅向上）みたいに言われることがあったりしてとっても興味深いです。だまされたとおもってやってみるといいと思います。
- ダメだったところ
- 初めて60分セッションやったわけですが、どうみても90分セッション用ワークですありがとうございました。というか、90分でも無理だったかもしれません。だいぶ削ったんですが、それでもだめでした。ただひたすら反省ですな。
- 上に関連、タスク設計で手順を書いてしまっている参加者の方が結構いらっしゃった。もっとタスク設計を丁寧に説明するとか、ワーク中に説明スライドをだしておくとか、もっと工夫の余地があった。ていうかこの事態を予測できなかった自分にびっくりだ。ある意味おもしろい。
- 参加申込サイトを作りこみすぎた。あんまり普通に作ってしまうとワークにならないんじゃないかと思っていろいろ小細工した結果、やりすぎた。無駄にワークの時間がのびた。参加承認サイトのほうはいい感じのうざさで作れたと思う。
- よかったところ
- 参加者質問への受け答えスキルはさすがに少しずつ上がっている・・・気がする。
- アプリケーション作成と公開・実機ワーク・もちろんユーザーテスト等々今回の自分の瞬間到達速度は半端なかった（と思う）。加速した！（こっぱずかしくてあんまり使いたくないけど）。とてもいつになく勉強したし、実際に身になったと思う。つらかった。つらかったけど。
- 結論
- 本当に加速（こっぱずかしくてあんまり使いたくないけど）したいなら、参加者よりも実行委員になったほうがいいと思う。
- その他
- もう一回やりたい。これ準備めっちゃ時間かかったんだよ？！！！。いやいやほんとに。もったいない。悔しい。ビブミーアチャンス。
- 公開したソースには既知バグがありますが、あえてそのままとしています。
・・・眠くなったので以上！！！！
【WACATE2014冬】初セッションやってみた
ずいぶんと、ずいぶんと久しぶりにブログを更新します。
この間いろいろございました。
まず匿名アカウントではなくなりました。
WACATEの実行委員会に入らせていただくことになりetcetc・・・。
まあそんなこんなで初セッションをWACATEで行わせてもらいました。
↓資料です。
はじめよう！レビューのいろは
ピアレビューの話です。
基本的なピアレビューの勘所と手順をまとめ、実際にワークで体験してもらおうという取り組みでした。
以下感想です。
- ダメだった点
- 予稿集をサーバにあげるのが遅かった。申し訳ありませんでした。。。
- 今回進行役・レビューアー・ドキュメント作成者になりきってレビューをやってもらうというワークをしたわけですが、一部から指摘があったとおり、レビューアー（次郎くん）に対する役割カードを作っとくべきでした。ドキュメント作成者を攻撃しない形で制御をかけておくべきでした。
- 一部完成版が間違っているとの指摘をうけ、こっそり直しております。すみません。ありがとうございました。
- 反省しない点
- ワークの作成物・・・ひどい設計書を書くのは簡単でした。わざと午前3時から2時間弱で書き上げました。少し眠ったあとに読み返してあまりのひどさにショックをうけましたが、結局そのまま使いました。反省してません。
- 良かった点
- 初セッションやってよかったです。とても勉強になりました。本で読んだこと・わかってるつもりになっていることって今までたくさんあるわけですが、実は全然自分の中で定着しているものになってなかったと思います。今回人に伝える形にする過程でようやく自分の中に定着させることができた気がします。というより、こういうことをきちんとやることこそが「勉強」なのかなって思いました。
- その他
- セッションは練習命。実行委員会の皆様に前回も言われましたが本当に命。
- セッション担当者以上にセッションの補佐はスキルが必要だなぁとぼんやり思ったのでもっと精進します。
本当に皆様に支えられて今回のセッションを行うことができました。
ありがとうございました！
また、本当に今回実行委員会の皆様にはご迷惑をおかけしました。
セッションのレビューはもちろん、ワークの配布物の段取りをつけてくださったりなんなりなんなりと・・・。
本当に申し訳ありませんでした。
また、セッションの準備やら咳き込んでるやらで裏方が思うようにできなくて申し訳ありませんでした。
（まだ時折咳き込んでます。薬の卒業は早くて4月だそうです（笑））
今後も今回のことを踏まえてもっと精進します。
何卒よろしくお願いいたします。
【9月29日開催】Devlove社内勉強会×勉強会「続けようみんな この歩みを」に参加しました！
自分達で学びの場を！というコンセプトで開催されている社内勉強会×勉強会の第4回目
私はこの勉強会に出るのは初めてでした。
勉強会の構成は「講演１→講演２→振り返り」って感じでした。詳細は下記のような感じです。
講演1「気の合う人達と社外で社内勉強会」
@mogemoguさんの講演。@mogemoguさんは現在、会社の同期の気の合うメンバで社内勉強会を行っているということ。
『にゃるご』勉強会
- 内容：テーマ自由。発表したいことを発表する感じ
- メンバ：同期の気があうメンバ（転職者も含む）
- 時間・周期：月1回
- 勉強会の場所：社外
- 特徴：時間は自由、幹事は持ち回り。MLはgoogleグループ、サイトはGoogleサイト（社内のしくみを使っていない）
会社等の制約を受けないような形で、同期でこじんまりと勉強会を行っている状況を説明
→いきなりきっちりした勉強会を開くんじゃなくて、気の合う人達とスモールスタートでやったらいいんじゃないだろうか。
講演2「Take Action！」
@heroweenさんの講演。@heroweenさんは現在、２つの社内勉強会を行っているとのこと。
ちなみに@heroweenさんの会社はとっても勉強会に理解があるそうです。
読書会
- 内容：アジャイル開発関連の本を読む。（事前に読んでおいて、実際には議論を行う）
- メンバー：社内の人。１２人
- 時間・周期：始業から２０分間
- 場所：社内
- 特徴：司会記録は持ち回り。進行は司会次第。１冊終わるごとに振り返り(kpt)
- 内容：ymfony2の勉強会
- メンバ：基本社内の人。３〜８人（社外からも）
- 時間・周期：週末の業後２時間程度
- 場所：社内
- 特徴：基本的に自由な感じでやる。終わったら飲み会
前の会社での社内勉強会を実施しようとして失敗した経緯を説明。
→失敗しても行動したことで良い経験になったし、前の会社に対して未練もなくなった。
また、社外で勉強会に参加していたことが現在の会社に転職し、社内勉強会を開けるようになったことを紹介。
失敗するしないじゃなくてとにかく行動を起こしましょうということ。
ふりかえり(PicoDialog)
グループに分かれて、社内勉強会についてのディスカッションを行いました。
「何のために勉強会を開くか」によって、社内勉強会への考え方（最低限の人数とか）が変わるのだなぁと感じました。
ちなみに私の職場はいろいろと社内勉強会が上長命令で開かれるような感じの職場です。しかし、技術・意識をみんなで共有するとか、そういった感じの勉強会は少なく、またボトムアップ形式の勉強会がやりにくい雰囲気なのが現状なので、まあ、まずはこそーりと@mogemoguさん形式で始められたらなぁと思います。・・・できるかな？；
