IT関連雑記帳

IT関連の話をつらつらと

Qiitaで見かけたディープラーニングと競馬に関する2つの記事

ディープインパクトではありません。

久しぶりにQiitaを眺めていたら、こんな投稿を見かけました。

qiita.com

タイトル通り、ディープラーニングと競馬に関するお話です。
こちらには以下のように元となった記事があります。

qiita.com

ディープラーニングは専門外だし、競馬はだいたい外れるのでほとんどやったことが無いのですが、かなり邪な気持ちで眺めてました。

いやまあ、正直な感想を言うと、どちらもすごいなぁと。

専門外だけに全てがすごく見えるのかもしれませんが、特に検証の方はプログラムとデータを分析し、仮設と検証をかなり丁寧に行っているので、僕のような専門外の人にも一見の価値はあると思います。

ところで競馬の魅力っていうものがさっぱり分からないんですが、どういうところが楽しいんですかね? 誰か教えてください。

そうだ。邪な気持ちといえば、以前僕も「オッズに合わせて単勝を買えば、絶対負けないんじゃないかな」と思い、VBA(なんかすみません)で計算するプログラムを書いたことがありました。

ロジック的にはものすごく簡単なのに、いつまでも計算が終わらないし、必要な金額が6億円を余裕で超えたので諦めましたね。

技術力もなければ、お金もないということで。
とりあえず以上です。

技術書典7で購入した本の感想 その3

技術書典7で買ってきた本の感想です。
まだ読んでいるのかと呆れられるかもしれませんが、まだ買った本の半分も読んでいないんではないでしょうか。このままだと、

読み切らないうちに次の技術書典が開催される
 → 本が追加される
  → 読み切れない
   → 技術書典が開催される
    → 本が追加
     → 読み切れない

みたいなループとなってしまいそうです。

ゲームもそうですが、なんでこう積んでしまうのでしょう。頭にケーブルを挿して、本の内容を脳にロードできる機能が欲しいと思う今日この頃です。

さて、今回は以下の本の感想です。

サークル名 Crab ink
書籍名 202 Accepted

f:id:ta9mi3:20191105202935p:plain
※例によって技術書典のサイトより転載させて頂きました
 https://techbookfest.org/event/tbf07/circle/6306503757660160

前回に引き続き、Crab inkさんの本になります。
章の構成は以下の通りで、多種多様な話題が載っています。

まえがき
第1章 本書の執筆 Tips rev2
第2章 JaSST Review開催報告
第3章 テスト自動化をこれからはじめるひとへ
第4章 ほめるをうけとめる・してきをうけながす
第5章 Agile QA Nightの質問に答えます
第6章 自動テストのためのプログラミング独学術
第7章 不具合票に関するあれこれ
第8章 テスターのプロフェッショナリズムについて(後編)
あとがき

ざっくり感想。
1行だけするところもありますが、ご容赦ください。

第1章はこの本の執筆環境情報の共有

眺める程度でした。もし同人誌を書く機会があったら、参考にさせて頂こうと思います。

第2章はレビューについての話

レビューというと、どうしてもレビュアー vs レビューイの戦いというイメージが強く、どちらかというと苦手です。書いたプログラムの設計書をお客様と対面レビューするときなんかは、当方が説明下手ということもあり、できれば避けたいのです。

とはいえそれでは困るので、興味を持って読ませて頂いたのですが、「レビュー中に『指摘』は行わない」という記載があったのにはビックリでした。これは自分がレビュアーになったときに参考にしたいと思います。

あとは、「レビュー(Re view)じゃなくてファーストビュー(First view)」になっていないかという言葉にドキッ。レビューをするにあたって、その機能についてそれなりに知っている必要があるんですよね。そうでないと、誤字脱字ぐらいしかチェックできないわけで、エンジニアとしてもっと仕事に入り込んでいかないとなぁと思ったのでありました。

第3章はテスト自動化についての話

「テスト自動化の失敗としてよくあるのが、一度自動化したもののメンテナンスコストが大きすぎて動かせなくなってしまう=腐ってしまう、です」

あー、分かりすぎる。

お客様がテスト自動化を行う時に、導入予定のツールの評価を担当したことがあるのですが、作るのはいいとしても、それが毎回使えるわけでもなく、常に手をかけないといけないんですよね。

このメンテナンスコスト問題については、「とりあえず自動化」みたいに自動化を銀の弾丸のように考えている人に、ちゃんと認識してもらいたいところです。

第4章はタイトル通り

褒められ慣れてないし、指摘されると地の底まで落ち込む性格なので、参考になりました。

第5章はAgile QAに関するQ&A

質問とその回答がたくさん載っていました。
Agileとはあまり関係ないところで評価業務をしていますが、とても参考になりました。QAが持つ責任、開発との関わり方、いろいろありますが、結局は開発は作るだけ、テストはQAと言ったような縦割りでなく、チームとしてまとまる、まとめるのが大切ですよね。

第6章はプログラムの勉強についてのお話

個人的にゲーム作りをしたいと思っているのですが、他にやることがあったりで時間が取れずに進まないんですよね。って、自動化の話とは関係ないところで参考になりました。

第7章はバグ票の話

テスト業務についたころは、「不具合を出すのはプログラマーの責任なんだから、不具合の事象だけ報告すればいいじゃん」って思ってました。元々は開発者だったので、「俺にプログラムを書かせろよ」ぐらいの感じだったかもしれません。

プログラマーは開発で忙しいので、不具合調査をすればするほど製品のリリースが遅れるんですよね。そうなるとエンドユーザーさんが困るわけで……。「我々がお手伝いしますよ。リリースまで一緒に頑張りましょうね」という意識が大切だと思えるようになってきたのは、歳のなせる業ですかね。

記載内容はまとまっていて分かりやすいので、不具合票に関する後輩への指導に役立てられそうな気がします。

第8章はプロフェッショナルとは、について

「プロ意識とはこういうものだと思います」みたいなことが書いてあります。会社員として働いていると、こういうプロ意識というのは薄れるときがあるので、日々ちゃんと意識していかないとなと思う次第であります。

とりあえず今回は以上になりますが、次回もCrab inkさんの本の感想を書く予定です。

技術書典7で購入した本の感想 その2

台風19号で自宅近くの多摩川が決壊しそうな状況ですが、個人的にやるべきことはもう無いので技術書典で買った本を読んでいました。

今回読んだのはこちら。

サークル名 Crab Ink
書籍名 201 Created

f:id:ta9mi3:20191012164144p:plain
※画像は技術書典7のサイトより借用

複数のメンバーで作成されており、目次は以下のようになっておりました。

第1章 本書の執筆 Tips
第2章 チームビルディングのコツ
第3章 ソフトウェアエンジニアのための、ブログでアウトプットする技術
第4章 実録! ゆるっとファシリテーター
第5章 ソフトウェアテスティングポエム ~良いテスト、悪いテスト~
第6章 気軽に参加すべきレビューの話
第7章 今までに出会った困ったテスト計画書
第8章 「迷えるテスト管理ツール

第2章のチームビルディングのコツなんかは、執筆者と考えが似ているのか、同意するところ満載。

それからレビューというとどうしてもレビュアーとレビューイの対決みたいな感じになりがちなので、第6章の「気軽に参加すべきレビューの話」というのも参考になりました。お互いに気軽に内容を確認しあえる関係や環境が作れるといいですよね。

こちらのサークルさんでは上記の書籍以外にも2冊購入させて頂きましたが、未読なのでまた別途感想を書きたいと思います。

とりあえずは以上です。

技術書典7で購入した本の感想 その1

技術書典7で買ってきた本の感想です。
たくさんの本を買いましたが、読んでいる時間がなかなか取れないので不定期になると思います。

なんで不定期かといいますと、以下のゲームを進めているからです。

という話はいいですか。そうですか。そうですね。

今回は以下の本の感想です。

サークル名 kuluna.class
Webサイト https://twitter.com/kuluna
書籍名 おめでとう! QAはQAエンジニアにしんかした

f:id:ta9mi3:20190927221458p:plain
※画像は技術書典7のサイトから借用いたしました

アプリの自動テストについての話で、初めてモバイルアプリの試験コードを書いていくという内容です。

事前にサークルチェックをしたときに、本のタイトルを見て購入を決めました。

読み始めてすぐ、目次に出てきたXCodeという文字を見て初めて、iOSのアプリを対象にした本であることに気が付きました。私の現在の仕事はモバイル関連のテストを中心としていますが、どちらかというとAndroidが中心で、iOSはほとんど触ったことないんですよね。Swiftもコードは書いたことが無いですし。

とはいえ、今までのプログラミング経験を元に、掲載されているSwiftのコードはほぼ理解できたのでよかったです。

ただ、P.66に載っているサンプルコードの中で1箇所だけ悩みました。

let noTask = app.tables.cells.count == 0
XCTAssert(noTask)

これは、app.tables.cells.count == 0が最初に評価されて、その結果のtrueまたはfalseがnoTaskにセットされるという認識に至ったのですが、合ってますかね?

個人的にこういう書き方をしたことがないので、引っかかったのはそれくらいですね。

手元にMacが無いので実際に手を動かして動作を確かめることはできませんでしたが、環境の構築から、ボタンのタップ、画面の遷移や画面内容の確認などが載っており、初めてプログラムを書く人に導入としてオススメしやすい本だなと思いました。なにより読みやすかったですし。

私もこういう感じで周りの人に教えていけたらなー。

とりあえず今回は以上です。

ソフトウェアテスト入門という資料を作成しました

ソフトウェアテスト入門という資料を作成したので、Speaker Deckに公開しました。

元々は社内で発表する予定で作成したのですが、いろいろあって発表機会を失ってしまったため、こちらでの公開となります。公開用に、自己紹介のところだけ差し替えました。

speakerdeck.com

資料を作るにあたって、まずは聞き手の構成と技術レベルを考えました。

  • 聞き手はテスト関係者だけでなく、開発プロジェクトのメンバーも多い
  • 新人からベテランまで集まっているので、技術レベルはバラバラ

つまり、職種も経験もバラバラな人達を相手にソフトウェアテストについて話をしろという無茶ぶり。発表時間も「10分程度で」という制限だったので、実際問題どうしようかなと......。

あとで別ルートから聞いた話では、依頼主はテスト自動化の話を期待していたようです。
しかし、上記の通り職種も技術レベルもバラバラな人達を相手にいきなりテスト自動化の話をしても、「ポカーン」とされるのがオチだと思ったので、ソフトウェアテスト入門というお題にしました。

特に、うちの会社開発メンバーはテストエンジニアの事を「手順書に従って試験をするだけの人」だと勘違いしている節があるので、「こんなにやることがあるんですよ」「技術力が必要なんですよ」という事を伝えようって思いました。

作成した資料の構成は以下のようになっています。

  • テストエンジニアのお仕事
  • 開発とテストの関係
  • テスト7原則
  • テストの基本、バグの見つけ方

結果、制限時間10分に対して22スライドとなりました。
それでも、自己紹介を含めて10分で話せるように準備したんですけどねぇ......。

それはそうと。

最初、SlideShareに公開しようと思ったのですが、SlideShareってLinkedInのアカウントが必要で、基本的に本名じゃないですか。それはイヤだなーと思ったので、GitHubのアカウントを持っていたし、Speaker Deckで公開することにしました。

僕のハンドルを知っている会社の人もいるので、Speaker Deckにしたところで分かる人には分かってしまうのですが、知らない人は知らなくてもいいかなと。

とりあえず今回は以上です。

技術書典7に行ってきました

池袋のサンシャインシティー展示ホールで開催された、技術書典に行ってきました。

f:id:ta9mi3:20190922212430j:plain

技術書同人誌博覧会には行ったことがありますが、技術書典は初めてです。

ta9mi3.hatenablog.com

14時に行って待機列に並びます。

4列が1セットという感じで、行った時には2セット形成されてました。最終的に入場は……何時だったんでしょうか。一緒に行った人と話をしていたので、あまり待たされた印象が無いです。時計を見るのも忘れていましたしね。

サークルの数と人の数に圧倒されつつ、事前にチェックしていたサークルさんで本をゲット。入場が遅かったので一部の本は完売。それでも十分な収穫でした。

というか、お金がもたないですよ。
家計簿を付けるのが怖い……。

進捗神社にお参りもしてきました。

f:id:ta9mi3:20190922211604j:plain

おみくじを引いたところ……

f:id:ta9mi3:20190922211754j:plain

もう若くはないので、デスマーチは勘弁してください。

さて、今回買ってきた本をご紹介。
テストエンジニアなので、テスト関連の書籍がほとんどです。

f:id:ta9mi3:20190922212146j:plain

f:id:ta9mi3:20190922212233j:plain

f:id:ta9mi3:20190922212259j:plain

f:id:ta9mi3:20190922212331j:plain

買ったからにはちゃんと読まなくては。

ファーウェイのHarmonyOSのこと

中国のファーウェイから、HarmonyOSが発表されて10日が経ちましたが、いまいちよく理解できていないんですよね。

例えばこんな記事や

japanese.engadget.com

こんな記事がありました。

monoist.atmarkit.co.jp

新しくOSを出すのはいいと思うんですが、いまいち信用できないというか、今までの経緯を振り返るとOSレベルからやりたい放題なのかなと疑ってしまうわけです。

どうなんですかね?