読者です 読者をやめる 読者になる 読者になる

kazurof weblog

技術ネタのメモを並べます

第7回日曜数学会で発表してきました。

第7回日曜数学会で発表してきました。(もう1週間経ってしまいましたが、、、)

facebookのリンク

https://www.facebook.com/events/858311494303516/

togetter

togetter.com

発表スライド

www.slideshare.net

準備に使ったソース

github.com

振り返りよろしく、思ったことを並べていきます。

ニコ動での発表動画まだみてませんが、5分は多少超えたとは言え、概ね狙い通りのプレゼンが出来たと自画自賛しております。そして、とても楽しかったです。 26ページ目(比を修正した数が、連続する数の積で表せることを示したページ)に行くちょっと前に、 客席から感嘆の声が聞こえてきたあたりで、「この発表は成功!」と内心感動しておりました。 時間制限がキツイことはわかっていたので必然早口気味になったのですが、聴衆の皆さんついてきてくれたかなと。

keep

  1. 黒曜石(指輪型スライド送りリモコン)が活用できた。スライド操作を手早くできた。
  2. 発表しないスライドをそこそこ適切に選べた。(とおもう。)
    • 質疑応答で飛ばしたスライドを使って回答できたので、結果発表に使えた。(ラッキー!)
  3. ネタ準備は十分できた。(長すぎたぐらい)
  4. 発表前に、パワーポイントのIMEをオフにすることを忘れなかった。(忘れると黒曜石のBLACKOUTボタンがIMEに拾われてハマる。しかも発表最中に。)

problem

  1. 発表時間少し5分超えた。(色々やむを得ないのでそれほど重大でないと認識)
  2. 黒曜石の操作が目立っていた様子。(ニコ生コメントで突っ込まれた。本当は目立つべきではない)
  3. 質疑応答時、プレゼン開始・終了の切り替えで、プロジェクターへの信号が一瞬止まる挙動が見えた。時間がもったいないので避けたい。
  4. 発表しないスライド・縮められるスライドがもしかしたらあったかもしれない。

try

  1. 黒曜石のBLACKOUTボタンを活用したプレゼン。(スライドではなく、発表者に集中してもらう。)
  2. プロジェクターへ接続した時は画面を複製するモードにする。(信号連続してくれるかも?)

その他雑感

この問題を考えていて同時に思ったことは、行列の並びを見せて、次の行列や一般項を求めるような問題はあまりみたことがなかったなということです。 普通の数列クイズはそれなりに見たことあるのですけど。数学の問題やパズルとしては手軽でないので単に避けられているだけかもしれませんね。

ついでに他の方の発表なのですが、話について来れた発表とそうでない発表がきっちり別れた感じでした。正直に言うと、解析系のネタはさっぱりでした。ソフトウェアエンジニアをやっていると、考える分野が離散数学寄りになったり、「コードが書けるか?動くか?」を重視する、、、というのは我ながら言い訳かもしれません。自分で勝手にやってる分には好きなことをやればよいのですが、やはり数学の主戦場は解析なのではないかと。式を自由に操れないとなぁと思った次第です。(数学ガールの「僕」が、趣味は式変形って言ってたのは、実に正道なのだなとか)

さてこの問題ですが、 @mattyuu123 さんが、一般解を提示しています。

追って、解説記事が書かれることでしょう。期待して待て!


(毎度毎度の〆ながら)やっぱりまた面白いネタを思いついたらどこかでなにかしら登壇したいなと思います。発表ネタ考えて準備するのは大変ですが、プレゼン発表面白いです。

第十六回 #渋谷java で、LT発表してきました。

第十六回 #渋谷java で、LT発表してきました。

shibuya-java.connpass.com

togetter.com

発表内容は、「JUnit 5 M1 をやってみよう」です。最近出たJUnit 5 M1 を触って見ました系の内容です。Qiitaのスライドモードを使ってみました。

qiita.com

振り返りよろしく、思ったことを並べていきます。

急すぎた。というのが準備含めた全体的な感触でした。M1のリリースに気がついたのが7月8日。渋谷javaのLT枠が空いているのに気がついたのが大体当日の1週間前で、下書きを始めたのが、18日。 他の個人的スケジュールを考えるとついうっかり限界に挑戦してしまったような感じでした。でも見送ったら2度目はないし、誰かがやらなきゃなとも思ったので勝手に思い込んでやってみた次第です。

内容は単に機能の差分を並べるだけでなく、最低限の価値を出せたかなと思います。Ruleのようなフィールドを使うような拡張はやめる方針でありますと。他にもネタはあるようですが、どうにも手が回らなかった。

あと、今回Qiitaのプレゼンモードを使いましたが、フォントサイズが大きくなりすぎて発表やりにくい感じでした。(つい焦ってスライド1枚飛ばしてしまったような)これなら普通にスライド書いたほうが良いなあと。あるいはフォントサイズ調整ぐらいはできても良い気がしますが。(スライド全体に渡るフォントサイズ調整として)

リポジトリを見ると、もうM2 が出ています。リリース間隔縮んでる感じですね。これからはじわじわバグ潰しと新機能(従前、Ruleでやっていた機能をExtendWithへ移植するとか?)の提供があるような気がします。 プロジェクトのアナウンスでは2016年の終わりまでにはGAをリリースしたいらしいので、今後はチラチラと見ていこうかなと。

でもやっぱり毎度ながら、また面白いネタを思いついたら登壇したいなと思います。発表ネタ考えて準備するのは大変ですが、プレゼン発表面白いです。

第十五回 #渋谷java で、LT発表してきました。

第十五回 #渋谷java で、LT発表してきました。

shibuya-java.connpass.com

発表内容は、「nextProbablePrime() について」です。おそらく素数を取得するこのメソッドは、どこまで正しい素数を返すのかを調べたという発表です。

www.slideshare.net

今回の検証に使ったソースをgithubに上げています。興味のある方どうぞ。

github.com

振り返りよろしく、思ったことを並べていきます。

とりあえず、問題を立ててその原因を探って答えを出すというストーリーを粗々ながらでも立てることができたのは良かったと思いました。 ロジックを追ってもなかなか十分追いきれなくて、このままだと単に処理の流れを追うだけになっていたかもしれなかったです。けれども丁寧ではないながら、ゴールを立てて到達できたと勝手に自負しています。

もっと時間があれば、カーマイケル数と非自明な1の平方根の話と、計算量や失敗する確率の根拠まで丁寧に話せたかもしれません。そうすれば、エラトステネスの篩の話はまるっと捨てる事ができたかもしれません。リュカレーマーテストについても処理概要と目的と、このプレゼンの趣旨には直接関係ないことを言えたほうが良かったかもしれません。

未消化のところもあってリュカレーマーテストが何のためにやっているのかさっぱり読めませんでした。試しに適当な値を入れてリュカレーマーテストのメソッドを動かしたら、9とか25とかで、処理に長時間かかるようになることを見つけて、多分そこには何か見落としがあるのだろうけれど、何なのかわかりませんでした。

聴衆の反響としては、ハッシュタグ上の反響はそれなりにあった*1ので、それは良かったと捉えておきます。具体的に手を動かして出てきた具体的な結果はそれなりに印象持ってもらえるのかなと。内容完璧ではなくても、出さないことには何も無くなってしまうので。能力限界で出さないぐらいなら、能力限界で品質悪いほうがまだ良いと思っています。

前回の登壇からまるっと2年経ってますが、また面白いネタを思いついたら登壇したいなと思います。発表ネタ考えて準備するのは大変ですが、プレゼン発表面白いです。

*1:追々togetterされるかな?

引き継ぎ作業の小ネタ

前置き

この4ヶ月半ほど、いわゆる情報システム部門に居ました。 そして人が交代することになり、仕事の引き継ぎをしました。 要は現在の仕事を次の人に説明するわけです。 それで、効率的な説明の方法が思いついたような気がしたのでここで晒します。

想定読者

  • 仕事の引き継ぎをする必要がある人。
    • 特にいわゆる情シスの人。
  • 仕事の全体像を把握する枠組みに興味がある人。

仕事の分類とその引継

ここでは、以下の様に仕事をグループ分けしたいと思います。

f:id:kazurof:20150528001648p:plain

言いたいことは大体この図で言えている気もしますが、個別の説明を続けます。

縦軸に作業が決まっているかいないか、横軸に周期的に発生するかしないかで分類します。 それぞれのエリアに名前を付けます。内容をイメージできるような名前がいいですね。

  • 定型・定期
    • 「刺身たんぽぽ」
  • 非定型・定期
    • 「年中行事」
  • 定型・臨時
    • 「早さ命」
  • 非定型・臨時
    • 「変化ヲ抱擁セヨ」
    • このサブエリアとして、「一期一会」「今そこにあるお仕事」。

「刺身たんぽぽ」エリア

一定の周期で、一定の作業を行う仕事です。 スケジューリングや作業見積もりが立てやすい比較的簡単な作業のエリアです。 環境が自動化を許せば人間がやらなくても良くなるかもしれません。 慣れてくれば退屈してしまうでしょう。長く続けても成長は望めない仕事のエリアです。

具体的には以下のとおりです。

  • システムデータのバックアップ
  • ログデータの処理
  • 月次、週次の事務手続き
  • 利用者部門にやってもらう定期的作業のリマインドのアナウンス

引き継ぎ方

単純にやり方を説明すればよいです。特に難しいことは無いでしょう。

「年中行事」エリア

いつやるべきかわかっているが、内容はその都度検討するエリアです。 スケジュールは立てやすいですが、予め作業内容や量を見積もるのはしにくいです。

情報システム部門というのは、管理部門に属することが多いと思いますが、 管理部門での作業(行事)の手伝いなどがこのエリアに入ります。

具体的には、週次会議、月例会議の手伝い。新人研修のテキスト執筆と講師。 上場企業なら株主総会、決算説明会など。 場合によっては懇親会とかBBQとかボウリング大会とか社内イベントの手伝いも入るかもしれません。

また、24/365な自社サービスをやっている場合は、システム保守作業を 定期的にやっているかもしれません。それもこのエリアに入ります。 いつやるかは予めスケジュールされますが、何をやるかはその都度計画する作業です。

引き継ぎ方

大スケジュール表を示して、何時どんな行事があるのか示せればよいです。 仕事内容についてはその都度検討するでしょう。あなたがその検討会議に入る必要はありません。 引継期間中にその行事があるのならば、一緒にやってもよいでしょう。

「早さ命」エリア

何をするかは既に定型化されているが、いつすべきかは予想がつかない作業のエリアです。 作業量はわかりますが、いつ必要が発生するかはわかりません。 「速さ」ではありません。「早さ」です。スピードが速いのではなく納期が早いことが価値です。

具体例についてです。情報システム部門は何らかの社内システムを管理していると思います。 そのユーザ登録管理がこのエリアに該当します。 人事異動・組織変更から発生することも多いでしょう。

また、利用者部門のPC管理もこのエリアに入るでしょう。 入社したので購入することや、退社したのでとりあえず情シスがプールしておいて必要時に利用してもらう、といった管理が考えられます。

引き継ぎ方

このエリアについてはも、それぞれ手順を教えれば良いです。 現在あなたが対応途中のものはあなたが実行し、新たに作業依頼が来るものについては次の人にやらせればよいです。

「変化ヲ抱擁セヨ」エリア

いつ何が来るかわからない作業のエリアです。 急に発生する課題・問題に対して、すぐその場で状況理解と優先度と重要度の判断をし、 必要ならば実行計画策定と実行が求められます。

事前に発生を想定して対応を考えることは却ってやらないほうが良い作業のエリアです。 そもそもできませんから。「こんな事もあろうかと」なんていうのは実際上は歩留まりが悪いものです。

具体的には以下の様な作業が入ります。

  • 即対応必要なセキュリティ対策作業。
  • PC利用トラブルのサポート。
    • ネットワークとかプリンタとか
  • 社内システム関連作業
    • トラブル対応
    • 設定の調査や変更依頼対応
    • 機能追加/拡張の依頼。機能作り込み依頼の対応。
  • 外部の急な意思決定変更。
  • 誰かが握りこんでいた納期間近の作業の対応。

また、以下の様な作業も入ります。

  • 現在あなたが進めている作業。
    • 作業の全容は発生時期含めて不明なはずです。
    • 「今ここにある作業」エリアとします。
  • 今後発生することは無いと考えられるような作業。
    • 一度しか起こらない作業です。定型とは言い難いです。
    • 「一期一会」エリアとします。

引き継ぎについて

まずは以下の3点です。

  • 過去の事例を軽く紹介。
  • 管理している社内システムついて必要な範囲で伝達。
  • 今後、どのような作業が発生しそうか軽く紹介。

内容の詳細について詳しく説明する必要は必ずしもありません。 また似たような作業は来るかもしれませんが、同じような作業が来るかはわからないのです。

「一期一会」エリアについては、作業の名前だけ紹介し、 事例として文書や資料や手順を残しておけば十分です。 発生しないと思ったけど実際は発生した時に役立てれば良いのです。

「今そこにあるお仕事」エリアは状況を見て考えなくてはなりません。 現在進行している作業は状況の変化もろとも引継ぐ必要があるのでその分大変になります。 状況が込み入っていて、あと少し完了させられるものはあえて引き継がずにあなたが完了させるのも手です。引き継ぐならば、進めながら引き継ぐ事になります。作業をある程度進めておいて、細かい状況を伝えなくても良いようにしておくと引継が楽になります。

まとめ

作業を4つのエリアに分けて、それぞれどうするかを述べました。 定型的作業をまず伝えて、状況を見ながら非定型作業を進めるのがよいでしょう。 何かのお役に立てばよいかと。

おまけの考察

いわゆる5W1Hのうち、What とWhen を軸としてまとめるかたちになりました。 そういう意味では

  • Who
    • 誰がやるか。平社員か、幹部社員か。
  • Why
    • どんな理由か。外部的な理由か、内部的な理由か。

なども軸として考えても良いかもしれません。一人情シスの場合、Who軸は無意味かもですが。 Where については、現場かリモートかで分けても良いかもしれません。

おまけの感想

これを考えている間、いわゆるアジャイル開発のことも考えていました。 リリースとフィードバックの速度を上げて、 状況や意思決定の変化に追随しながらシステムを開発するということで、 なかなかやはり高度で難しいのだなと思った次第です。

POH lite でリポビタンD100ml×50本のセットが当選してしまいました。

f:id:kazurof:20140912222332j:plain

タイトルの通りで他の参加された方には全く申し訳ないのですが、POH lite でリポビタンD100ml×50本のセットが当選してしまいました。おおおおおお。*1

f:id:kazurof:20140913215845j:plain

ステッカーもついてきました。むおおおおおお。

天才火消しエンジニア霧島「もしPMおじさんが丸投げを覚えたら」|paizaオンラインハッカソンLite

で、このまま何もしないのもどうかと思われたので、もう一つネタを振ってみたいと思います。もっと変わった面白い解き方はないものかと日頃考えているのであります。


POH lite ではいろいろな言語が使えます。Beta版も含めて20言語あってなかなかすごい感じですね。 私としてはここにない新しい言語で解いてみようと考えました。AWKです。

AWK - Wikipedia

言語には流行り廃りがありますのでご存知ない方もいらっしゃるかと思います。簡単に説明すると、「比較的言語仕様の小さなプログラミング言語の中でも、速攻性、柔軟性、機能性において最右翼に属する逸品」です。*2

プログラム

sample code for https://paiza.jp/poh/kirishima wit ...

実行結果

kazurofさんの採点結果[100点] 完璧ぃぃ!|paizaオンラインハッカソンLite

実行時間は 0.08 秒から3.45 秒 の範囲です。Test case 7 以外ではJavaScript over Java(以前やったPOH lite を JavaScript (Nashone)でやってみた。 - kazurof weblog)よりも速いのが興味深いですね。合計時間ではAWKの方が速いということになります。

やってみた感想など

AWKはその標準入力の扱いに特徴がありますので、それを活かす方向にしてみました。具体的には以前のようにソースコード中に値を展開するのではなく、Javaが受け取った標準入力の内容をそのままAWKに渡す形です。言語ごとに特徴がありますのでそれを活かせたかなと。

あと、配列の扱いが微妙に癖があるので、(連想配列だったり長さを取れなかったり)そこもちょこちょこと修正しました。

paizaでコードを書いた人は今までにたくさんいると思いますが、AWKで書いた人は私が初めて(多分)ではないのかと一人自己満足に浸っております。えっへん。

同時に、AWKで書くとかこんな馬鹿馬鹿しいことをする人は私が最後なんじゃないかなあと思っています。寂しくなんてありません。ええちっともありませんとも。

でもこれ、本当はやばいのではないかとも思います。実行環境上のawkとか/bin/sh とか動いちゃうわけですよ。私は uname -a とか ls / とかやって怖くなってきたのでもうやめておきました。ファイルシステムを見に行ったら中を開けるかもしれないし、もしかしたら霧島京子壁紙の.aiファイルもあるかもしれない。本採用の候補となっていたファイルとか、絵師さんの習作で作ったあんな画像やこんな画像もあるかもしれない。

いやいやいやいや。やばいやばいやばい。

で、一応念のため運営事務局さんに確認したら、「ブログ投稿は問題ないが、今後は動作保証しかねる。」ということでした。今は動くかもしれませんが、そのうち動かなくなるかもしれません。

というわけで、今リポビタンDを美味しく頂いているところです。さすがに今後も当選するとは思えませんがまたチャンスがあったら参加してみようと思います。 私からは以上です。

f:id:kazurof:20140913233941j:plain

*1:箱が少し開いているのはうちの子(4歳女)が中を確認したいとわがままを言ったから私の帰宅を待たずに開けたんだそうです。ちなみに配達時は嫁の母もいたらしく、嫁「もらってけば?」嫁母「いーよいーよいーよ」という会話があったそうです。おとうさんが頑張って懸賞を当ててもところがどっこいこのような脅威に晒されるのが現実です・・!これが現実・・!

*2:ここから引用 

AWKを256倍使うための本 (Ascii 256倍)

AWKを256倍使うための本 (Ascii 256倍)

 

読書メモ「パブリックスピーカーの告白」

「パブリックスピーカーの告白」を読みました。 プレゼン発表をする人へのノウハウやガイドを提供する本です。 簡単に言うと小ネタの山といった印象です。

以下、超ざっくりとした概要を並べます。

1章

発表での細かいミスは気にしない。聴衆は細かいところまで気にしない。

2章

緊張を下げるためのいろんなアイデア。 人前で話すの怖いとか緊張するっていうのは自然なこと。

3章

私はそんなにたくさんお金稼いでいません。リスクもあります。発表準備もあります。だからいぢめないで。

4章

会場について。「会場をエネルギーで満たしたい。」 たとえ無駄でも聴衆のためのアクションは試みるだけでも有効。 聴衆にとって言ってほしいことを言う。聴衆が問題にすることを話す。

発表者と聴衆の関係。できるならよくしたい。限界もあるけれど。

5章

ちゃんと考えてスライドを準備しましょう。 「マイクを食べた」とは話す内容が発表者にとっても明確で無いと聴衆が気がつくこと。*1

良い準備をするために必要なこといくつか。 聴衆が求めているのは洞察。タイトルの付け方。内容練り上げ方。(こうすればマイクを食わずに住む)

アウトラインを押さえて論点を明確にしましょう。

6章

聴衆の注意を引くことについて。人間の注意は長く続かない。 聴衆を前にした時にするべきことと気をつけること。

7章

テレビでしゃべるということ。どんな偉い人でも小さな歯車扱い。 私達はいつも演技している。誰と会っていてもそれなりに演技している。プレゼンをすることが特別ではない。

テレビの場合聴衆は眼前に居ない。そこをなんとかするのは能力。なんとかするのはとても大変。めちゃくちゃ大変。プロンプターで自然にしゃべるのもまた大変。

8章

フィードバックについて。 有益なフィードバックはなかなかもらえない。ヘボいプレゼンでも儀礼的にやり過ごされる。 教える力を上げるために聴衆を楽しませるということ。本題から外れたとしても。

受講アンケートの良くないところと本当のフィードバックをもらうコツ。 聴衆の興味があることを言わなくてはならない。

フィードバックとして自分のプレゼンを撮影して見ること*2

9章

教えることについて。教えることはほとんど不可能。そもそも難しい。 1対1なら有効。3個の要点。

  1. 活発で面白いものとする。
  2. 生徒の興味を掻き立てる洞察を示す。
  3. 生徒の1と2の反応に対応する。

つまり、 1. 手を動かしてもらう。演習  2. 興味を持たせる。 3. フィードバックをもらって学ぶ。その場ででも改善する。

10章

段落毎小見出し付きの小ネタ集。散文のような形で多種多様なネタを流していく。まとまりや掴みどころはなさげ。

バックステージノート

実際的な小ネタを多数並べられている。話が具体的なのでとっつきやすい。

感想など

私のようなたまにプレゼンをやるようなエンジニアには内容は充実しすぎかも知れません。予備知識として持つには十分すぎるほどです。 *3

プレゼン発表を頻繁にする人にとっては有益で参考になる情報がたくさんあります。 プレゼンすることが専門・仕事みたいな人には良いと思います。ただ、余計な無駄話もそれなりに入っているのでその分は読みにくいかもしれません。 *4

私個人的にはプレゼンは演って面白いものと捉えています。観るものではなく演るものです。ネタと発表機会があったらどんどん演りたい。 プレゼンのプロであってもなくてもそういう人には副読本的におすすめできると思います。


パブリックスピーカーの告白 ―効果的な講演、プレゼンテーション、講義への心構えと話し方

パブリックスピーカーの告白 ―効果的な講演、プレゼンテーション、講義への心構えと話し方

*1:でいいと思う。多分

*2:これは福原も自分で思いついて実践してたぞ。えっへん。

*3:直接的な興味が続かなくて、読むのに半年ぐらいかかりました。積ん読をぎりぎり捌くことができたというか。(苦笑)

*4:おそらく著者は口頭での発表のつもりで本を書いてしまっているのかもしれません。著者の本業はおそらくしゃべることです。

POH lite を JavaScript (Nashone)でやってみた。

天才火消しエンジニア霧島「もしPMおじさんが丸投げを覚えたら」|paizaオンラインハッカソンLite を、 JavaScript over Java でやってみました。 Nashone と言ったほうが通りが良いかもしれません。

プログラム

sample code for https://paiza.jp/poh/kirishima

実行結果

kazurofさんの採点結果[100点] 完璧ぃぃ!|paizaオンラインハッカソンLite

実行時間は 1.57 秒から3.19 秒 の範囲です。また一段と遅くなりました。 そんなものといえばそんなものでしょうか。

感想というか手応え感というか

特に難しいことはなく、ScriptEngine 云々を使ってやってみました。 配列の扱いがJavaと微妙に異なるのでそこだけ直してできあがり。

前回までで、Java8 のStreamとか、JavaScript over Javaでやってみましたが、 もっと変わった解き方はないかなあ、とおもっています。