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

スベリミナル効果

技術的なことを書こうと思ってたけど何でも書くことにします

技術的なことを書きたいんですけどね… 指摘・質問・罵倒コメントください…
ダジャレ好きの方はこちらにどうぞ→スベリブログ2.0

YAPC::Kansai 2017に行ってきてます

早いもので、前回のYAPC::Hokkaido から3ヶ月経ってたらしいですが、YAPC::Kansai 2017に参加してきました。前回はなぜか、参加後1ヶ月経過してからブログを書くという体たらくだったので今回は帰る前に書きます。

 

今回のYAPC::Kansaiは「温故知新」がテーマということでしたが、そのテーマどおり、様々な事柄について歴史的な視点で振り返って頂いた発表が多く、個人的には非常にタメになりました。2008年に就職した私ですが、その時点ではエンジニア的な知識はほとんどゼロな状態から始まり、分からないことを調べ続ける日々が10年弱経過し、やっとこさ目の前の仕事だけでなく外の世界も見えるようになってきたところで聞くには丁度良いテーマだったと思っています(10年弱でそれは遅過ぎだろというツッコミは御勘弁を…自認しております…)。

 

そんな感じで、今回も聞かせていただいた発表について、つらつら書かせて頂こうかなと思います。

 

実録すぐわかるPerl

この本の著者である深沢さんの発表でした。 

すぐわかる オブジェクト指向 Perl

すぐわかる オブジェクト指向 Perl

 

私が入社後さほど経たないうちに、そこそこ分かり難い既存Perlコードをメンテするにあたり、凄く役に立った本。いや、ウソです、その当事はイマイチピンとこなかったけど、ある程度の量のPerlコードを見てから再度読んだら「な〜るほど、東芝♪(古いし今はよくない)」って感じになって、一段レベルが上がった気になれた本という方が正しい。もっと早く理解できていれば…と思った記憶があります。

お話としては、自分が使うワンライナーならぬテンライナー、そして社内に展開するツールとしてのPerlについて。細かい話はスライドが公開されることを期待して省きますが、正規表現テスターという味噌蔵はマネしたいと思った。Perl正規表現は似たようなものが必要になったりするけど、社内ツールとかワンタイム作業だと、使った後は大抵どこか行ってしまうので。ポイントは、まちがえた正規表現も敢えて残すという所でしょうか。MS Officeとの共存も見習いたい、若干諦めてたから…

 

そんな深沢さんから、今からPerlを始める人にはこれ!という一冊が紹介されていたよ!みんな、もしこれからPerlを始める人がいたら、お勧めしてね!(私はさっきKindleで買ったのでこれから読みます) 

かんたん Perl (プログラミングの教科書)

かんたん Perl (プログラミングの教科書)

 

 

2017年春のPerl

@charsbar さん。前回のYAPC::Hokkaidoのおさらいを含めてという感じでした。CentOS5が終わっても、まだだ、まだ終わらんよ!(Solaris10 2018-01 5.8.4)というお話がよかったですね。前回も書きましたが、ミラクル・リナックスさんの素晴らしいサービスがあるので油断は禁物かもしれません。私はこのサービスを使う側になってしまっているので何も言えませんが…

 

レガシーな Perl システムに DDD(ドメイン駆動設計) を取り入れる

さいとう まさあき (@masakyst)さん。関西人は「まんねん」を使わないというお話でした。

もとい、長期サービスは人の入れ替わり・知識の継承・仕様の肥大化などで色々大変!という、共感の嵐を呼ぶモンスターに対してオブジェクト指向というアイテムで戦っていく勇者達のさくせんについてのお話。要約するとこんな感じでしょうか。

>さくせん >オブジェクト指向

指針が たりない!

>つかう >DDD戦術

DDDを全く勉強していない私が聞いていたところ、あれ?これ普通のオブジェクト指向の話だっけ?という感じになってしまったのですが、まとめでそういう所感が出てきたのでやっぱそうなのか、と思いました。DDDって難しそうということは分かった気がする。

そして、最後のこのワードが凄く重要だと思いました。

「理論が正でなく、チームで共有できたことが正」

正直、「オブジェクト指向」という概念だけでも人によって結構認識が違うので、コードレビューとかで喧嘩になるんですよね… まずは認識を合わせることが大事ですよね。見習いたいけど、難しいんだなあ、これが… そもそも、そんなもの、無いのかもしれないし…

 

MojoliciousとWebSocketでサーバPush配信

木本 裕紀さんの発表。「サンプルコードPerl入門」にはお世話になってきました。

MojoliciosもWebSocketも、何となくは知ってるけど… 程度だったので凄くよく理解できた気がする。是非何かで使ってみたいと思いました。構想はちょっとあるけどマッチするかはまだ分かっていない…

にしても、前の発表と連続して「Shift-JISとEUC-JPが混在するシステム」の話が出てきてすごくつらい気持ちになった。と思ったら「PerlPHPが混在」ということでますます恐ろしい気持ちになった。世の中、みんな色々大変なんだよね。勿論、最初にそういう構成にした人だって、悪意を持ってやったわけではないのだから…

 

mail_form.cgi reborn

小飼 弾 (@dankogai)さん, @moznion さんによるスペシャルセッション。主旨はここを参照。

ライブコーディングもさながらに、@dankogaiさんが放つdisの連続が面白かったりw

そしてライブコーディングの魔物がプロジェクタを落とすという悪行に…

マジで演出じゃないのかと思ったけど外しました。異様な盛り上がりがあり、すごく楽しかったです。あまり時間が無かったですが、修正の一つ一つに重要なポイントがさらりと含まれていて勉強になりました。

 

Perl ウェブ開発の中世 〜CGIPlack の間〜

OGATA Tetsuji (@xtetsuji)さんの発表。HTMLの普及から始まるお話はまさに温故知新という感じでした。聞けてよかった。最後におっしゃられていた、

「古い技術が悪、新しい技術が善ではない」

というのは本当に重要だと思います。私も自虐的に以下のようなツイートをしましたが

実際、上記のCGIはルータの設定UIみたいなものの話で、管理者が一日一回使うか使わないかみたいなものなんですね。そういう場合はCGIで十分なわけです。だから別に刷新とかも必要ないからCGIなんです(Perlのバージョンについてはちょっと置いといて…)。

ちょっと話がズレてる?かもしれませんが… いや、まさに例のメールフォームじゃないですが、動作している以上、本当に刷新が必要なのか否かが重要であり、「古いからヤダ!新しいのがいい!」という理由で無謀なリファクタをすべきでは無いです。そして、今のシステムに何が必要かを判断するためには、その古い技術がどういうものであり、どういう課題を解決するために新しい技術が生まれたかを知っていることが大きなポイントであり、そのエッセンスがふんだんに含まれた発表内容だったと感じました。こういう話は、私も後輩に伝えてあげないといけないなあと思いました。(と言っても、ぼくも2008年頃からのスタートだからまだ若い…ような気がする…)

 

はてなシステムの考古学

@motemenさん発表。これもまた、はてなというシステムに対する歴史のお話。実に興味深い内容がたくさんありました。メモ不足でしたが…

最後の方で、以下の言葉の引用がありましたが、

組織の知識は暗黙知形式知の間を行き来しながら発展する

なんか、今の自分の組織では上手くこれが回っていないなあと発表を聞いていて思いました。暗黙知のままずーっと保持されて人が居なくなるたび失われる… まずは考古学ができる下地が無いと温故知新も難しいのかもなあ…としんみりした感じになってました… さすがにこのスライドは公開されないですかね…?

 

LT

@makamaka さんのが凄かったです。Perlの話だったし!?間違いなく一番笑いをとっていたはず。見習いたい(そこをかよ)。

 

 

温故知新 (Keynote)

竹迫 良範さんの発表。なんかもう盛り沢山で消化しきれなかった感がありますが。

まずDirpcapは後で触ってみる。パケット見る必要のあるお仕事なので…

Dripcap - ☕️Caffeinated Packet Analyzer

 

アセンブラ短歌とか、パンチカード読めますよね、とか…レベル高杉内。この辺はちょっと追いつけない感がありましたね…

若者ってどのあたりまで含まれるのかな…1983年生まれは…ただの知識不足ですかそうですかつらい。

 

マインスイーパーのデモ。これがたまたま見てたんですよね。

2011年なんてYAPCの"や"の時も知らなかったんで知らないはずだけどなあ…と思い返していたらこんな動画を見ていたことに気づきました。ここに来て、生で聞けるなんて結構すごいことだなあと思いました。温故知新とは違う気がするけど、わりと感動した。

少なからず、情熱をあれだけ注げることがやっぱ凄いんですよね。その辺りが自分に一番足りない部分だとは思うのですが、こればかりは性格的な部分もあるので難しい… でもこういう発表を聞くのはすごく楽しいので、情熱を分けてもらう、刺激をもらう、的な意味でもすごくいい発表を聞けたと思いました。

 

 

まとめ

あー、疲れた。やっぱ書きたいこと全部書こうとすると時間かかっちゃいますね…

なんにせよ、やっぱりYAPCは楽しいです。最初にちゃんと覚えた言語は間違いなくPerlですし、その最初の頃(今もな気がするけど)お世話になった御本人様がたのお話を聞けるという凄く良い機会でした。既に次回の YAPC::Fukuoka 2017 HAKATA が決まっているということで、これはもう行くしかないよなあという気持ちで一杯でございます(まだ購入はしておりませんが)。

本当にいい話をして頂いたスピーカーの皆様、そして、YAPCを支えるスタッフの皆様、マジで毎度ありがとうございます。こんな短期間で開催してもらえるのが凄いです。いきものがかりのライブくらいしか旅行の動機が無かった私にとって本当にありがたいです(しらねーよ)。

 

ぼくももっと素敵なPerlフレンズになれるよう精進いたします…

 

 

明日は千鳥の漫才を見てから帰ります。どうもお疲れさまでした。

 

そういえば YAPC::Hokkaido 2016 SAPPORO に行ってきました

テクノロジー プログラミング

お久しぶりです、そしてあけましておめでとうございます。

もう一ヶ月前になりますが、YAPC::Asia改めYAPC::Japanとしての第一弾、YAPC::Hokkaido 2016 SAPPORO に思い切って参加してきました。神奈川在住なんですが、普通の土日に冬の北海道まで行くのはさすがに厳しいか…とは思ったものの、「スピーカーに @miyagawa さん呼んでおけば50人ぐらい増えるだろ」枠として頑張って参加しました(笑)  遅まきながら、聞かせて頂いたトークなどを交えて簡単にまとめておこうかと思います。

まともなレポートについては以下を読んでもらう方がよいと思います。

gihyo.jp

 

まずは天候との戦い

前日入りしないとキツイなあとか、関ジャニの札幌ドームライブが重なってホテル空いてねえとか諸々ありましたが、最大の敵は10年振りの記録的な大雪でした。

札幌の10日の最深積雪は65センチに達しました。積雪が65センチ以上となるのは12月上旬としては1987年以来29年ぶりでした

f:id:hijili2:20161210084356j:plain f:id:hijili2:20161210090648j:plain

会場へ行く途中の札幌市街、および会場付近。

♪行きも帰りも結構な欠航、でもYAPC決行、会場への道は雪との決闘(1~3スベリ)

とかおかしなテンションで口ずさんじゃいましたよ。もう笑うしかない雪でしたね。私の便は行きも帰りも運良く飛べたのですが、帰りの便が、元々21:00 発だったのが2時間ほどおして羽田に着いたのが深夜0時過ぎ… そこからタクシーの行列に並び、家に着いたのは3:00前でしたね… それでも、欠航で帰れなかった方々に比べたら全然良かったと思いますが。久々に、自然の厳しさを実感する機会になりました。さすが試される大地…

あ、あと靴は滑り止めが着いたものを最低限用意すべきと思いました。悩んだけど前日に買って履いていってマジよかった。降った後は凍ってスベりまくります、いや、ダジャレ言ってるからだろ、とかじゃなくて。 

 

以下、聞いたお話についてちょこっと書いていきます。

 

HTTP/2の課題と将来

スライド:http://blog.kazuhooku.com/2016/12/http2yapc-hokkaido.html

ほんとコレに尽きる。本当にありがたい。

HTTP/2の通信はもう1/3を占めてきているが、まだ技術課題が残っており、それに対するお話。HTTP/2ならずとも、TCPバッファの話とかは通信一般の話として勉強になりました。CDNとか使うにあたり、PUSHも意識しないといけないなあと思いました。正直、細かい部分は咀嚼しきれてないですが、こういう話があることを知っているだけでかなりプラスになると思いました。

 

2016年のPerl

スライド:http://www.slideshare.net/charsbar/2016perl-long-version

Perl6 と Web 開発と

スライド:https://docs.google.com/presentation/d/15op4A2s1aCSorX81myYukE2OnMGAx6AzR3Y0kj-iF2Y/embed?slide=id.p

 

Perl 5.24 とか、Perl6の話だったわけですが… 私の業務環境、CentOS5ベース(Perl 5.8.8)で…今度、やっとCentOS7ベース(Perl 5.16.3)に上げる(はず)という状況なもので…遠い未来の話でした。でも、LINEアプリなら言語バージョンが古くても作れる!やったね!

 

Number Unlimited

スライド…は無いけど関連URLはこちらの発表リンクから:https://yapcjapan.org/2016hokkaido/timetable.html

※今気づいたけど各スライドへのリンクは上記ページに貼られてましたね

コンピュータ(Computer)は「計算機」、「計算」が扱うのは「数」である、ということで、各言語の数の扱いについて解説いただきました。ただ、厳密な小数や素数を未だ使う機会が無いのでピンと来なかった部分もあります… 機械学習とか始めるとそんな機会もあるのかしら(4スベリ)

というか、Perlインタラクティブシェル的な使い方( $ perl -dE 1 )から知らなかったです… 2004年からやってるのか…

 

ちなみに、@dankogaiさんはポケモンGO TL35でした、すげえ。私は28です。メタモンまでは捕まえましたが、もうフェードアウト気味です(余談すぎる)。

 

10年モノ熟成Perlとの付き合い方

スライド:http://www.slideshare.net/masaki/10perl

今回一番共感した発表でした。同じような業務をやっている今日この頃なので… この課題に一人で取り組まれているということで、物凄く大変そうだなあと思ったり。懇親会でもお話させて頂きましたが、元々、私の会社と同規模(?)の競合企業におられたということで、その辺りの体験も似ていました…また一歩転職したくなった。そして、この点は本当に見習いたい。

ここまで継続させてきた先駆者の実績をリスペクトしましょう

歴史的な経緯があると、なんだこのクソコード!と言いたくなることもしばしばあるのですが、実際このコードが商品・サービスを動かしてきたから自分が雇われている、と思わなければいけないと反省いたしました。頑張ってクソ古いCPANとか更新していきます。JSON.pmが動かなくなっても直します。

 

AndApp RPGツクールMVの舞台裏とSPAの運用について

RPGツクールMVで遊びたくなった。でも、予想以上にFFXVにハマってしまっている身としては、ここにも手を出すのは、やっぱつれぇわ。

技術的な部分でも、Web業界ってやっぱ色々進んでるなあと感じました。一つ前の発表も踏まえるとそこに追いつくのも一苦労なんだよなあとしみじみ思ったり。やっぱつれぇわ。(言えたじゃねえか)

 

今から始めるMicrosoft Azure - Dive into Azure

うーむ、Microsoftさん打って出てるなあ、という動画からスタート。データセンターの広大な予定地など見せられてしまうと平伏する気しか起きない。色々ご説明頂いたのですが、やっぱ使わないとダメですね、まだ各種クラウドがピンと来てない自分がいる、マズい。それは次のスペシャルセッションでも痛感することとなる…

 

スペシャルセッション「今さら聞けない、でも聞きたい。クラウドの過去・現在・未来」

AWSからは荒木靖宏さん、さくらインターネットからは田中邦裕社長、Azureは久森達郎さん、GCPからは千歳滑走路封鎖のため飛行機が旋回して戻ってしまったけどリモートで参加の福田潔さん、司会が技術評論社の馮富久さん、というスペシャルなセッションでした。セッション中も言われていましたが、この4つのクラウドサービスの担当者が揃って話をするってそうそう無いですよね。

60分のセッションのエッセンスを簡単に拾ってみると、

 

クラウドに諸々を預けることに対する"安心感"は課題、安全性と分けて両立させる必要がある

 

・犯罪捜査時のデータ要求に対する判断は各国の法律に基づくため、リージョンによる事情も様々あるらしい。

 

・各社に様々な視点やオススメがありワケガワカラナイヨ目的用途に応じて使いわける必要がある。ちなみに、「日本に対するイチオシサービスをあえて1つ挙げるなら?」に対しては、以下のような回答がありました(担当者および私の個人的なニュアンスを含むのでその辺ご理解ください)

 GCP: App EngineとBigQuery、インフラ管理を無くすという流れにおいて特徴的なサービスとのこと

 AWS: S3、沢山のサービスが存在するがそのほとんどがS3と関連するため

 さくら: GPUクラスタと国内向けCDN、クラウドはもっと贅沢に使うべき。また、ゲームなどはグローバルを意識する必要があるだろうが、自治体など国内で閉じるものもあるためそのような視点として国内向けもある

 Azure: AppService, 開発ツール系、開発全体サイクルの中で使えるサービスが特徴的。生産性も考えてみてほしい。

また、日本は各社がリージョンを置いている特異な国であり、日本語でも沢山の情報が得られるのでもっと利用すべきという話もありました。確かに、そう考えると使わないのが勿体無い感じになってきます。

 

・Q:Webコンソール遅いんですけど…

 GCPAWS・Azure: API使おう

 さくら: 歴史的経緯でAPI無い…汎用性維持のために難しい部分もあるが頑張ります...

 

こんなところでしょうか。もっと色々な話はあったかと思いますが。にしても、さくらインターネットさんがこの3社に肩を並べて話しているのが凄いなあと思いました。さすがに最後の質問のような部分で差を見せつけられるような点は沢山ありますが、ともすると弱みになる部分を特徴に変えて戦うところが勉強になりました。なにはともあれ、やっぱりもっと積極的に利用しないとなあと、今更ながら再認識いたしました。

 

モジュールメンテナンスを通して感じる最近の Perl

スライド:https://speakerdeck.com/syohex/yapc-hokkaido-2016

Perlモジュールのメンテナンスの話ですが、やはりここでもPerlの盛り下がりが語られておりました。私もPython勉強しようと思いました(違)

メンテナンスのためにサポート対象を減らす、という話で、「なんでPerl 5.8なんだよ、そっちが上げろよ」(会場笑い)という流れがありましたが、笑えなかったぜ… 結局、どこも古いまま動かさざるをえない状況を作ってしまっているんですよね… 以下なんかはPerl5.8延命のお知らせですからね。

japan.zdnet.com

メンテナの方の負荷にもなるし、やはり今後は簡単にアップデートできるような構成を念頭に置かないといけないですね。その一つの手段がクラウドではありますかね(クラウドにすれば解決するとは言っていない)。

 

LINE Bot on the Perl

スライド:http://www.slideshare.net/kazuhiroosawa/line-bot-on-the-perl-yapchokkaido-ver

なんか、今回のYAPCではサブリミナル的にLINE Botの話が入ってきた印象があります。2016年4月頃にザワついたときにも興味はあったのですが、正式版でしかもコンテストがあるということなので、少し手を出してみようかなと思いました(がモノができるとは言っていない)。アイデアを出すことがまず難しい…

 

Delivering a CDN

待ってましたのmiyagawaさん発表。悲しいかなノートPCのバッテリーが終了してしまいメモを残せなかったのですが… 今の時代 toggetter 見ればいいよね。

  ,j;;;;;j,. ---一、 `  ―--‐、_ l;;;;;;
 {;;;;;;ゝ T辷iフ i    f'辷jァ  !i;;;;;  CDNなんて開発して面白いのかな・・・
  ヾ;;;ハ    ノ       .::!lリ;;r゙
   `Z;i   〈.,_..,.      ノ;;;;;;;;>  そんなふうに考えていた時期が
   ,;ぇハ、 、_,.ー-、_',.    ,f゙: Y;;f.   俺にもありました
   ~''戈ヽ   `二´    r'´:::. `!

 というような話でした(分かるか)。

安定稼働が必要とされるサービスでいかに継続的にリリースするか、という感じですが、まさに私がやっている業務と共通する部分が多くてためになりました。DarkLaunch(一部のユーザに先行リリース)はやっぱみんなやるんだよね。リリース後の監視は24時間で足りるのか?とも思いましたが、そこら辺はどういうサービスかにも依存しますよね。他にも、局所的にリリースするとか、リリース後に監視するとか、課題認識は同じだなあと思ったのですが、具体的に何を監視するかっていうのがかなり難しいところだろうなとも思います、提供するサービスによって全然違う部分も出ますしね。

まあ、ただのrebuild.fmファンなので、生で聴けただけで満足した感もありました笑 今年もsupporter継続しております。

 

最後に

私にとって初の北海道、そんな中大雪に見舞われるなど色々ありましたが、会場に入れば非常に快適で楽しいYAPCでした。スタッフの皆様、本当にありがとうございました。地方開催は、食べ物が美味しかったり、旅行のきっかけとしても良いと思いました(事前調査してなかったため寿司をが食えなかったことが悔やまれる…)YAPC::Kansaiも是非行きたいです。

 

July Tech Festa 2016 に行ってきました

テクノロジー ネットワーク プログラミング

rebuild.fmの宣伝で聴いたのをきっかけに July Tech Festaに参加してきました。

インフラエンジニアの夏の祭典ということで、自分の業務的にはYAPCなどよりもこちらの方が近く、もっと前から参加してればよかったなあと思う話ばかりでした。ブログを書くまでがJFTということなので、聞かせていただいた話について自分の感想をつらつら書かせていただきます。

 

現実が正解だ!やってみんとわからんことだらけ さくらのIoT企画 開発365日の軌跡 そして次の365日へ

はてなインターネットにて、IoT用のインフラサービス(さくらインターネット、「さくらのIoT Platform」を2016年度中に提供)を提案して実現するまでのお話。色々と気づきがありました。

  • 自分にIoTインフラの視点が無かった

IoT機器が増えるとどうなりますかねー、みたいな話は度々してたんですが、基本的にセキュリティの話ばかりでインフラを提供するという目線の話は全然していませんでした。色々足りてないなあと実感しました。

  • 新しいことを始めるのはどこでも大変

企画を考案し、イメージ化、提案・交渉(予算獲得)、開発人材が入る… に至るまで約3ヶ月を要したと。人によっては長い・短いが違うと思いますが… ということでしたが、個人的には早いんだと思います。会社規模が大きくなるほどここの所要時間が増えていくのだと思いますが… さくらで3ヶ月なら他ではどのくらいかかるんでしょうね… 自分の会社では…考えたくもない…まずそこの流れがどうなってるのかすら分からん

  • 知らないこと沢山

MarathonとかRoLaとか全然知らんかった。天草Xアスロンも知らなった(それはしょうがない)。導入事例の話は興味深かったです。

 

情シス戦線異状アリ!? 自作のパケットレコーダーで海外拠点のLANを自動監視してみた

スライド:http://www.slideshare.net/cloretsblack/lan-64323110

海外拠点を結ぶインフラでのトラブルシュートを自動監視したというお話。インフラではないけど、ネットワークの問題をトラブルシュートしてる身としては非常に共感もあり、勉強になることもあり、すごくためになりました。

  • 海外の事情

海外ならではの問題が印象的でした。国による法律的な問題とか、スイッチ売ってないとか、小数点の区切りがピリオドではないとか、様々なものがあるんだなあと驚きました。国内でもままならないのに、すぐ「海外展開だー」という話が出る昨今、このようなお話はとても貴重でした。

  • 情シスの事情(私は情シスでは無いですが)

Q.最も感謝される場面は? A.困り事を迅速に解決したとき > 障害を未然に防いだとき ←それな

未然に防いでも誰も褒めてくれない…(は言い過ぎかもしれませんが)、これ本当にそうなんですよね、何かが発生してすぐ解決できるほうがポイント高い。海外の従業員相手にはギブアンドテイクが必要という話もありましたが、そうなってくると定期的に問題発生させて自動解決する仕組みでも作った方がいいのではと思ってしまったり…(ダメ、絶対)

迅速な問題解決のために、パケットをキャプチャし続けて異常を検知する仕組みを構築、自身で販売もされているそうです(リンク参照)。確かにこういう仕組みが無いとキツイとようやく気づき始めていた今日このごろなので、見習っていきたいなと思いました。私の所のサービスでは、定常的にキャプチャし続けることは愚か、機器一個追加してもらうのも大変な現状なので、やり方を工夫する必要はあるのですが…

 

人工知能の技術で有名なニューラルネットワークのフレームワークであるChainerを用いた対話Botを使った俺の屍を越えてゆけ

スライド:http://www.slideshare.net/Gushi/chainer-bot-slide-share-64321155

機械学習系は知識さっぱりながら聞いてみました。正直、中盤以降はキツかったです…

  • 対話botについて

対話型botの価値や個性について、分かりやすく説明していただき、ふむふむなるほどと聞いていました。キャラクター性を付けるって難しそうだなあと思ってたらできてなかったw

  • 概念…?距離…?

ゴメンナサイ。

あと、エンティティキリングって強そうなポケモンのわざだなと思いました。

 

CIプロセスにセキュリティ診断を組み込もう!Eclipse CheとOWASP ZAPで実現する、セキュアなシステム開発のすすめ

  • OWASP, OWASP ZAP

名前は聞いたことあったんですが、ちゃんと知らなかった。The Open Web Application Security Projectの略ですね。内容は… 以下のスライドが分かりやすいよ、とのことでしたw

Presentations by OWASP Japan // Speaker Deck

とにかく世の中をセキュアにして、インターネットで余計なものを気にせず謳歌したいと、そういうことみたいです。ZAPはそのためのWebサイト診断ツールです。ローカル環境で使ってみたけど、やはりローカルではイマイチ有用性が分からんですね。借りてるレンタルサーバにぶつけてみたいけど… 怒られそうなので止めておきました。

元々、発表者の方が立ち上げたコミュニティとのこと。勉強会のドタキャンが多くて困っているらしいので、申し込んだら行きましょう(ここで私がいうことか?)。偶然にも話題のDoorkeeperのページだったので今後の動向が気になります(主旨が違う)。

Eclipse Next-Generation IDE!!とのことで、今後ちょっと触ってみようと思いました。本当に思ったよ。

 

サーバ構築をbashスクリプトから自動化ツールに変えてみませんか? 

スライド(公開用):http://www.slideshare.net/deadbeef00/jtf2016

発表用と公開用のノリが違い過ぎてワロタwww それはさておき。

少し状況は違うのですが、スライドと似た課題をどうにか解決すべき立場にいるため、色々考えさせられました。以下の記事は発表者様が書いたもので、スライドの詳細とも言えるものなので合わせて参照すると良いみたいです。

  • ツールを導入すべきかどうかの判断

質問もさせて頂いたのですが、ツールはツールで学習コストがかかります。一方、bashでも少し頑張れば、自動化はある程度可能だと思います。例えば、今回のスライドの「大量のサーバに同一スクリプトを適用してログも残したい」という問題であれば、以下の感じでいけると思います。

servers.txt ここに対象サーバのIPとポートが書かれているとして、

192.168.0.1:2222
10.0.0.1:22

以下のようにssh経由で実行し、スクリプト実行結果をそのまま残すことができます(鍵とか設定済み前提)。

#!/bin/bash
USER=root
SCRIPT=./set_snmpd.sh # yum -y install net-snmp とかやってるシェル
LOG=hoge.log

for server_port in $(cat servers.txt); do
	server=${server_port%%:*}
	port=${server_port##*:}
	echo "#####################################" >> $LOG
	echo "Start install script @ $server_port"   >> $LOG
	echo "#####################################" >> $LOG
	ssh -l $USER -p $port $server 'bash -x ' < $SCRIPT >> $LOG 2>&1
done

まあ、もう少し整形しようはあると思いますが… SCRIPTを変えれば、基本的に使いまわせるはずです。

個人的な話になりますが、自分でできるものは自分で作らないと気がすまないオジサンがいるため、よく分からないツールは基本的にNGを喰らってしまいます。ただ、事実ちょっと頑張れば自動化はできるわけで、使い方を調べる必要のあるツールを使う必要があるのかしら?とも思うわけです。

この辺りを質問というか相談させて頂いたのですが、まずは使ってみてどれだけ楽になるかを示す、証拠を残したり複雑な作業が必要になったときはツールの方が良い、というようなお話をいただきました。

加えて、たまたま見つけた以下のQiita投稿は非常に参考になりました。

「無理をしない」とは

  • chef,ansibleなどのdevopsのツールは、 「開発者がインフラ設定をするためのもの」と解釈されがちだ。

  • しかし、少なくとも自分の周りでは、開発者が、開発者がイキナリ、インフラ設定をすることは想定していない。インフラの知識や構成管理の知識がないためだ。これらのツールを使う人は、通常、インフラ担当者や運用担当者が想定される。

  • 開発を生業をしていない人(インフラ担当者や運用担当者)が、使うツールとして、ゴリゴリとしたコーディングではなく、設定ベースや手順ベースでできる事が重要。

  • 開発している人が忌み嫌うベタ書きを是とした記述で可読性を上げるという考え方です。
    要は「コーディングではなく、手順書の延長としてのツール」が重要です。

多分、それなりの開発者が実施し、かつそれなりに低コストで実現できるのであればツールはそこまで必要でないのかもしれませんね。ただ、一回作った後に、コーディングをしない人に回してもらうなどを考えるならば、このようなツールを検討すべきなのかな、と思いました。

 

なんかエラく話が発展してしまった…このペースだと書き終わらないのでこの辺で… 別記事としてもう少し書くかもしれません。

 

ディープラーニング入門-DQN(Deep Q-Network)の理論解説とTensorFlowを用いたシンプルな実装例

スライド:http://www.slideshare.net/enakai/tensorflowdqn

憧れの?中井さんの発表だったので。DQNが何かはほとんど知らなかったけど… 中井さんのブログにはCentOS7やらDocker絡みの話でお世話になりっぱなしだったので、本人を見たいというミーハー感がありました(なんか気持ち悪いな

  • 分かった気になった

DQNの理論をわりと初心者向けに丁寧に解説して頂いて、なんか分かった気になったぞ!という感覚を得られました。私は、学生の頃に組合せ最適化問題を解く研究をしていたので、基本的な部分(局所解に陥らないよう探索する)は同じだと思うのですが、多段になるとかその辺がまだまだ良くわかってないですね… いいきっかけを貰えたので、学習してみようと思いました。最近になって フェルマーの最終定理 (新潮文庫) を読んでいたのも、数学の話を聞く上で丁度良かったと思いました(笑

  • 学会こわい

質疑応答にて、久々に学会での厳しい質問の感じがあり、少し懐かしさを覚えました… ちょっとハラハラしましたね笑

 

懇親会

今回もぼっちで懇親会に参加しました。人見知り+技術話についていけなさそう、という恐怖で大抵そんなに話せないのですが、今回はDMM.com Laboの方に声をかけて頂いたり、その流れでカッコイイ名刺の株式会社Aimingの方とも話せたり、発表者のSonarmanaさんから色々聞けたり、最後ちょろっと中井さんともお話できて楽しかったです。こんなに話すならちゃんと名刺補充してくればよかった…(4枚しか入ってなかった…)

 

 おわりに

なんか適当に書きすぎた気がしますが… とにかくためになったし、非常に楽しかったです。お弁当や飲み物、お菓子の充実や豪華な景品などもさることながら、運営の方々が凄く親切なのが印象的でした。本当にありがとうございました。

 

しかし、こういう場に行くと完全な受け身状態になってしまって、自分から発信というか、ギブアンドテイクのギブができない人材だなあ、と痛感させられます。なんかこう、もう一段上にいくというか、能動的に発信していく姿勢を持たなければいけないなあとしみじみ思いました(って、2,3年前くらいから言ってる気がするけどね)。

 

ポケモンGOを安全に遊ぶためのひでんマシン60

雑談

※8/1 バッテリーセーバーに関して追記してまぁす。早く直してほしい…
※8/14 バッテリーセーバーに関して記載戻しました、バグ直っているようです

 

どうも、30過ぎのオッサンポケモントレーナーです。ポケモンGOが楽しくてしょうがない今日この頃です。

 

ただ、ポケモンGOに関しては色々言われており、特に、スマホを見ながらの移動による事故が危ぶまれております。実際、私もポケモンを求めてだいぶ外をウロウロしましたが、スマホをガン見している人も確かに多く、危なっかしい場面も目にしました。

このままでは「お盆を迎える前にポケモンGO規制ラッシュになってしまうのでは!?(全然ウマくない)」という不安で夜も眠れず、夜な夜な近所のジムでジムバトルを繰り返してしまいそうです。

 

そこで、微力ではありますが、いい大人がウロウロして身につけた「ポケモンGOを安全に遊ぶコツ」を書いてみようと思います。「そのくらい言われんでも分かっとるわ!」という声が聞こえてきそうな内容ではありますが… 禁断の自転車編もあります…

※「ひでんマシン」は、ただのつりざおタイトルです。60はGOに似てたから付けただけです…

 

徒歩編

基本的には徒歩で遊ぶに限りますね。乗り物に比べて幅も取らないし小回りも利きます。とはいえ、大事故の可能性は否めないので注意はもちろん必要です。

1.移動時は画面を見ない

基本の"き"ですね。そもそも歩きスマホがダメなんですから。ただ、ポケモンGOは画面を見ずとも色々と情報が得られます。

 ポケモンが出現→振動

 ポケストップ近くに来た or 近くから離れた→効果音

この2つがあれば大抵の場合は困らないと思います。また、バッテリーセーバーが有効であれば、下を向けることで画面が暗くなりバッテリーを節約できます。※8/1 バッテリーセーバーがiOS版から消えてしまいました…そしてAndroid版でもバッテリーセーブ状態から復帰すると操作不能になるバグが発生し続けています… でも、画面が消えていると思って、ウロウロするときの基本姿勢は、以下の感じが良いと思います

 ・スマホを下に向け、手を下ろして持つ(ネックストラップも有効)

 ・イヤホンで音を聴く(あまり大音量にせず、なくても良い)

手を下ろすことで、ついつい画面を見てしまうことがなくなるため、周囲への注意力が高まります。振動や効果音があれば移動を止めて画面を見る、コラッタだったら無視して歩き出す、といった感じです。是非お試しください。

2.移動を止める時も状況に合わせて

これは普段の生活でもやりがちですが、狭い道や人通りの多い道で急に止まると当然ぶつかります。じゃあ脇に避けようと急に曲がったりすると、自転車が突っ込んできたりします。あえて書くほどでは無いかもしれませんが、一応…

 ・急に立ち止まらない、後ろから人が来ていないか確認して道の端に止まる

 ・急に進行方向を変えない、これも後ろを確認する

 ・狭くて混雑した歩道では開けた場所に出てから止まる

徒歩の場合、一度出たポケモンが急に消えることは(たぶん)無いので、電柱の脇とか、駐車場の一角とか、立ち止まりやすいポイントをまず見つけてから止まるのがよいと思います(基本過ぎると思いつつ、たまにやっちゃうんだよなあ…)。

3.ARモードをOFFにする

これをやってしまうとこのゲームの醍醐味が…という声もあると思いますが… まあこれはどっちでもいいと思うのですが、ARモードを切ることでスマホをどの方向に向けてもポケモンをGETすることができます。余計な動きや方向の縛りが無くなるだけでも思考に余裕がでます。

そして、ARモード切ったほうがぶっちゃけ捕まえやすいし…

 

自転車編

ダメですよ、自転車スマホなんて。でもね、卵育てなきゃいけないじゃないですか。そしてね、ポケモンの世界の中で主人公の少年は颯爽と 100万円のじてんしゃ を乗り回すじゃないですか。あの じてんしゃ のBGMが頭にこびりついて離れないわけです。だから、乗りたいんです、でももちろん安全に。ということでちょっと実践してみました。

1.移動時は画面を見ない

徒歩と一緒やんけ!って話なのですが、制約が全然違います。まず、手でスマホが持てません。町で見かける人たちは片手に持って走ったりしてましたが、非常に危なっかしいです。なので、四の五の言わずこういうものを使うべきと思います(なんかこのために書いたみたいになってきたけど、そういうわけではない…) 。

ポイントは、スマホの向きを回転できる商品を買うことです。普通に取り付け、走らせるときはクルッと逆向きにしてしまいます。

f:id:hijili2:20160725235546j:plain

取り付けた感じ。

 

f:id:hijili2:20160725235554j:plain f:id:hijili2:20160725235558j:plain f:id:hijili2:20160725235601j:plain

走りだすときはクルリと上下の向きを回転させます。これでバッテリーセーブモード(有効にしてね)になるため、画面が消えます。※8/1 同上。でも大丈夫です、バッテリーセーバーが無くても、少し緩めに固定して画面位置を下に下げることで、よそ見もできないし、両手はハンドルで普段と変わりありません。もしポケモンが出たら振動するので、相当な悪路や、車がよっぽど多い道でなければ十分認識できます。

また、もう一つの制約として、自転車に乗りながらイヤホンを使用するのは違反です。よって、音を聞かないか、大音量でSEを響かせながら走るかどちらかしかありません。某公園で、堂々とアプリ音を鳴らしながらポケモンを黙々とゲットするオジサンの姿には感動すら覚えましたが、マネできなかったので私は音無しを選択しました…

ということで、自転車にどうしても乗りたいのであれば、

 ・スマホを固定できるホルダーは必須、手に持ちながら運転しない

 ・走行中はよそ見しないようにホルダーを逆向きにして画面を消す

 ・音による情報は諦めるか、普通に鳴らす

くらいはすべきと思います。徒歩編の「2.移動を止めるとき…」は言わずもがな、自転車でも同じです。

2.ポケストップを探すんじゃない、ポケストップになっていそうな場所を探すんだ

1の対策をしても、やはりポケストップが気になるため注意力が散漫になりがちです。ここは一つ発想を変えて、自転車に乗っているときはポケストップ"候補"探しをしてみると現実世界をしっかり捉えることができる気がします。

例えば「あれ?あそこに神社あったっけ?ポケストップじゃね?」と予想し、近づいて停止し、スマホを回転させて確認します。「やっぱポケストップになってる、ラッキー」てな具合にアイテムを回収します。意外と、こっちの方が面白かったりするかもしれません。(しないか)

ただ、場所探しに夢中になって人を見ていないと本末転倒なので、その辺りは頑張って注意するしか無いんですけども…

3.基本はたまご育成だけにしよう

何だかんだ書きましたが、結局の所、自転車の殺傷能力(自分へのダメージ含む)は徒歩の比ではないので、とにかく人の少ない道を選ぶべきだと思います。ポケストップが無いとか、ルアーモジュール使われてないとか言わず、そういう目的の探索は秋葉原にて徒歩でやりましょう。ホルダーにスマホ付けて、止まらずただ走るだけならば誰も文句の言いようはありません。自転車はそういうふうに使うのがよいと思いました…

 

まあ、そんな感じで、安全に事故なく、報道にいじめられないよう楽しみましょう。以下、おまけ。

 

田舎編

あ、もう自由にやってください。崖とか山道とかだけは気をつけてください。あ、あとリアルポケモン(やせいのリングマとか)にもお気をつけください。

 

車編

ダメに決まってるだろ、バーカ。また風当たり強くなるじゃねーか。運転手はプレイ諦めろ。ってかバスに乗れ。

 

夜道編

深夜徘徊するのはやめましょう。大人でもさ… ただ、人通り多い分には滅多なことも起きなさそうな気はしている。

 

最後に

いやね、ポケモン初代やってたのは小学生の頃だったんですけど、あそこまでハマったゲームってそんなに無いんですよ。確か、大会レギュレーションのポケモン育てるためにタウリン · ブロムヘキシンとかを積むのはもちろんのこと、戦闘回数が多いと能力値が上がりやすいって聞いて、マサラタウンの草むらのポッポとコラッタだけでケンタロスのレベル55まで上げるとかしてたんですよ(大会は結局出なかったですが…)。今こうやってアメを集めて育成してる感じで、その頃の熱意を少し思い出したりして、結構楽しんでるんですよ(すぐ飽きる可能性は大ですけども)。

なので、全国各地でポケモンGOで事故だ事件だと言われると悲しいんですよね。ポケモンGOは13歳以上からということで、そこそこ大人な人たちがメインで遊ぶものなわけですから、各個人が注意してやってればそうそう変なことにはならないはずなんです。ということで、あたり前の注意を当たり前にして、楽しく遊びましょう。

 

 

とかいう記事を書いた翌日に、よそ見して人とぶつかる、とかありそうで怖い…(8/1 大丈夫でしたよ)

 

いまだChangeLogメモで工数集計しているという話

プログラミング ダジャレ ネタ

ChangeLogメモってイマドキのかたは使ってるんですかね?
私は5年くらい前に以下のようなサイト様を見て使い始め、まだまだ使っております。

ChangeLogメモの実践
clmemo@aka: Change Log メモを試してみよう

ChangeLogメモとは、以下のようにChangeLog形式でメモをとっていくものです。

2013-07-01 Wed. @hijili2 <hoge_fuga@noexist.com>

    * トラブル対応: Aさんエスカレ XXX案件
        - 原因調査 1h
        - 対応 30m

    * 実装 プロダクトA: モジュールB 3h
        - xxxでハマる、以下で解決
            $ hoge hoge

2013-06-30 Tue. @hijili2 <hoge_fuga@noexist.com>

    * 設計 プロダクトA: レビュー会 1h
        TODO: 確認する

    * トラブル対応: Cさんエスカレ
        - 原因調査 45m
            進行中のプロダクトAに影響するかも...


個人的にChangeLogメモは視認性がよくてマークダウンより好きです。

ただ、これだけだと、適当にインデント付ければChangeLogである必要無くない?
って話になるのですが、形式が決まっていることがポイントだと思っています。

先人の皆様もemacs-lisprubyなどで、ChangeLogメモ用のgrep
すなわちclgrepを作っており、私もそれをマネしだしてから、かなり重宝してます。

GitHub - hijili/clgrep: grep command for changelog memo
# 大したコードでは無いです、しかもPerl...

形式があれば何でもできる」と高名なプロレスラーの方も言うように、
ちょいちょい拡張できます。("元気"と"形式"をかけるのは無理があるな1スベリ)


まあ、普通に使おうと思ったらこんな感じです。
「この前 hogeコマンド使って解決したの何だっけ?」みたいなとき。
該当した1ブロックをgrepします。

$ clgrep hoge hoge.txt 
    * 実装 プロダクトA: モジュールB 3h
        - xxxでハマる、以下で解決
            $ hoge hoge


「プロダクトA関連の作業だけを一覧したい」みたいなときは
-tを使うと、タグ(と私が勝手に呼んでる部分)だけを対象にgrepします。

$ clgrep プロダクトA hoge.txt 
    * 実装 プロダクトA: モジュールB 3h
        - xxxでハマる、以下で解決
            $ hoge hoge

    * 設計 プロダクトA: レビュー会 1h
        TODO: 確認する

    * トラブル対応: Cさんエスカレ
        - 原因調査 45m
            進行中のプロダクトAに影響するかも...

$ clgrep -t プロダクトA hoge.txt 
    * 実装 プロダクトA: モジュールB 3h
        - xxxでハマる、以下で解決
            $ hoge hoge

    * 設計 プロダクトA: レビュー会 1h
        TODO: 確認する


そこそこちゃんと書くようになってきたので「このまま週報に載せてまえ」
と思い、日付昇順に並べてヘッダだけ出せるようにしてみたり。
また、その際、各行末の \d[mh] をパースして集計するようにしてみたり。

$ clgrep -r . hoge.txt 
2013-06-30 Tue. @hijili2 <hoge_fuga@noexist.com>
    * 設計 プロダクトA: レビュー会 60m
    * トラブル対応: Cさんエスカレ 45m
2013-07-01 Wed. @hijili2 <hoge_fuga@noexist.com>
    * トラブル対応: Aさんエスカレ XXX案件 90m
    * 実装 プロダクトA: モジュールB 180m


お約束の「工数見える化せい」的な話があれば、csvで吐けるようにしてみたり。

$ clgrep --csv . hoge.txt 
# tag,time(minute)
# TOTAL_TIME,375
トラブル対応,135
実装 プロダクトA,180
設計 プロダクトA,60


こんな感じで使っており、個人的には意外と便利だと思ってます。

ただ、結局の所は「いかにちゃんとメモを残せるか」が鍵なので、
そこが面倒で続かなくなりがちではあります…
# 本気で忙しい時は何も書かなくなります…

とはいえ、書くときは結構シンプルで、パースもしやすい一つの形だと思っております。
もしご興味あればお試しください。


では最後に「こんなChangeLogはChangeしろ」をお届けして終わります(は?)


2016-07-19 Tue. @hijili2 <hoge_fuga@noexist.com>

    * トラブル対応: お客様帰宅時間に間に合わず、明日再調査

    * 実装 プロダクトA: コードレビュー -> 指摘を受け再修正 4日遅れ

    * 出社: 9:15 電車遅延のため遅刻

2016-07-15 Fri. @hijili2 <hoge_fuga@noexist.com>

    * 実装 プロダクトA: 3日遅れ

    * 出社: 9:30 電車遅延のため遅刻


ChangeLogっていうか、遅延時ログだ。(リスケしろ2スベリ)



2016-07-20 Tue. @hijili2 <hoge_fuga@noexist.com>

    * トラブル対応: お客様が自己解決、追加調査不要とのこと

    * 実装 プロダクトA: 別プロジェクトとの兼ね合いでリスケ、納期1ヶ月延長

    * 出社: 9:45 遅刻かと思ったがシステム故障のため全員9:00扱いになった


ChangeLogっていうか、もはや珍事ログだ。(全てフィクションです3スベリ)




最後のが書きたくてこの記事を書いた気がするのはきっと気のせい。