前回に引き続いて 株式会社フォトシンスで社会人インターン？をしている(id:kazupyong)です。 本日でフォトシンスでの社会人インターンが終わります。 前回はインターンの経緯を書いたのですが、 今回は実際にインターンで何をやっているのかというのを書こうと思います。 Akerunのアーキテクチャー説明 まずはCTOの(id:kazuph1986)から Akerunの歴史とAkerun Pro、Remote、ドアセンサー、NFCリーダーなどなど Akerun本体のハードウェアの仕組みとWebやアプリで使ってるアーキテクチャーの説明と、 実際に鍵が空くまでのフローをレクチャーしてもらいました。 Redashのセットアップ redash.io 公式だとAMIから起動するのが主流のようですが、 AMIのベースとなっっているのがUbuntuでDebian系なので、 管理コスト的に社内のサーバーを

実装がまったく思いつかないバグを見つけました。来週「◯◯のように直したら(バグが)出なくなりました」なんて言ったら「えー」て言うからね♡— miwa (@miwa719) 2016年9月16日 テスターが見つけるバグには、狙い通りに見つかる(またはそれに近い)ものと、そうでないものがありますよね。 前者の「狙い通りに見つかるバグ」というのは、例えば、プログラマーが「いつも動く」を前提に作っていることを想定して、テスターは「動かないときもある」を起こして見つかるものです。 使用するファイルをリネームしてみる データベースのサービスを停止してみる ネットワークケーブルを引き抜いてみる 同期処理なら、こんなことを考えながら、手を動かしていきます。 何をしたら二人は永遠に待ち続けてしまうだろうか お互いの状態を変数でフラグ管理しているのだとしたら、それらが正しく更新されないのはどんな時か その更新

最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。 一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。 1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。 事前アンケートを用意するメリット 話すことが事前に想定できる アンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。 どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない（雑談は雑談で良いものだけど）。 その場で回答が思いつかなくて適当な返しになることがなくなる（お互いに） 自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってか

私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して

どもども インフルで絶賛謹慎中のkazuphです。 少し頭痛はしますが、熱も下がってただ寝てるのも暇なのでブログでも書こうと思います。 今日は先々週末くらいにやった非エンジニア向けのGAS勉強会の話です。 GASとは Google Apps Scriptの略です。ExcelでVBAを知っている人へは「それのGoogle SpreadSheet版」と言えば通じるかなと思います。 要は一定以上複雑なことをやりたかったり、アプリケーションと呼べるレベルのことをやろうと思った時に、セルの関数の組合わせだけではやれないことをするときに活躍するプログラミング＋その開発環境になります。 GoogleはそれをJavascriptにて提供しています。これをGoogle Apps Scriptと呼んでいます。 GASで何ができるか？ 本来であればシートをプログラムから参照し、プログラム側で集計などし、結果をシ

健康は命より大事。 repeat after me. 「健康は命より大事。」 以下蛇足。 ここでいう「健康」は、身体的なものと精神的なもの、両方を含みます。いずれも健康であれば、キャリア的分岐点も、人生の節目も、35歳を越えても、なんとかなる可能性があります。 どちらかの「健康」に不安がある状態で新たなる敵が出現すると、戦う前から打ちのめされた気分になってしまうものです。 まずは心身の健康にとって有害であるものから、少しずつ距離を取ることを考えてみましょう。自分を守れるのは自分だけ。自分の健康を守れるのも自分だけなのです。 ここ数日、キャリアの棚卸しや35歳以降のエンジニアライフについて言及しているテキストを多く目にしたので書いてみました。健康は命より大事。これだけ覚えて帰ってください。

はじめに テスト自動化自体にフォーカスを当てることが多いが、このセッションでは人に焦点を当てる 自己紹介 浅黄 色々と経験してきて、品質って大事だなと思えるようになってきた 10数年前に商用ツールを使ったのが自動化のきっかけ OSSに偏ってきた（ココ数年） 技術開発部に所属 後藤 7年前にIT系に入って負荷分散システムを作る 検証って面白いと考えるようになってベリサーブに転職 実務レイヤーではなくマネージメントレイヤー 玉川 コンピュータサイエンスを大学で学んでいた 最初の6年間は開発していた 自動テストやCIの知見が溜まってきた 技術開発部に所属 自動化エンジニアを育てるために教育もしている 松尾 院までコンピュータサイエンスを学んでいた 新入社員の頃からテストに興味を持つ 分散ネットワークなどを学んでいた 2年前からクックパッドに転職 今はモバイルアプリ中心 プロセス全般を見ているが、

Selenium/Appium Advent Calendar 2014の23番目、12月23日の記事です。少しメモしていたことがちょうどAppiumの話しだったので、ついでに。 テストエンジニアしています @Kazu_cocoaです。普段はこちらに細々ブログを書いているのですが、まとめ的なものなのでこちらに書いてみようと思います。 七転び八起きなAppiumを使ったモバイルテストのたしなみにて、Appiumを使ったモバイルアプリのテスト記述に関して、出くわしたつらみを書きました。 一方で、もっと単純な、 どうやってAppiumを実行した時にその要素を特定するか という箇所に関してまとめて言及されているような資料がないように思えたので、少しそのあたりを書いておきます。いずれも、実際に使ってみてのものなので、これ以上に使い方があるかもしれません。 環境 Mac OS X Maverics /

こんにちは。技術部の松尾(@Kazu_cocoa)です。 安定したリリースを継続して回す為には、開発プロセスや実装も大事ですが、その中でどのような確認、テストを継続して行うかも大切になります。そこで、開発プロセスにおけるテストをどのように切り分けて、構築していくかという考え方に関して少し整理してみようと思います。 これにより、実施されているテストによって検出できる/できない不具合がどのようなものか、それが開発中のどこで防ぐことができるのかを整理できるようになってくると思います。また、安定したリリースを実現するためのボトルネック解消に向けて、どのレベルでテストを充実させると効率的にそれが達成できるかという所も考えることができるようになります。 テストレベルによるテストの区分け テストレベルという言葉にも様々な定義がありますが、ここではざっくりとテスト対象となる範囲や領域を意味することにします

モデレータ： 浅黄 友隆（ヒューマンクレスト） 松木 晋祐（ベリサーブ） 登壇者 松尾 和昭（クックパッド） 三浦 一仁（AAAメンバ） 荻野 恒太朗（楽天） 森下 大介（ヤフー株式会社） 小井土 亨（SQiP 運営委員会メンバー,株式会社OSK） はじめに（浅黄） このパネルディスカッションでは「これから」に焦点を当てる 後半はツイートを拾います 今まで色々なことをやってきたと思います。 その上で、今後、挑戦的にやってみたいことを聞いてみたいです。 今後、テスト自動化で、広げたいこと、挑戦したいこと 松尾 挑戦したいことは1つある サーバー込みのサービスが分割されている 大きなサービスが個々のサービスに分割され始めている それに対して、サーバー間での連携が壊れていないか確認するところが見えていない サーバー間やクライアントサーバー間のAPIを変えてもテストの中で気付くようにして、最終的な

わたしはちょっと意地悪らしい。 例えば、あるテストケースを思いついたとする（しかもかなりの高確率でうまく動かなそうなやつ）。それをね、モノが出来上がって自分の目でちゃんと動くこと（気持ち的にはちゃんと動かないこと）を見届けるまで、プログラマに話さない。*1 とあるイベントのパネルディスカッションか何かで @m_seki から「それは意地悪だなー」と言われて、はじめてそれが意地悪なんだってことに気がつきました。そういうテストを思いついたらすぐに言ってよ！てことみたい。もしプログラマがそれを考慮しないで実装してしまったら確実にバグになるわけで、黙っていることは開発にとって何のメリットもない。 なぜ話さないのか。話せなかったのか。それなりに理由はあったんだけど、まあ、それはいいや。意地悪は良くない。それからは思いついた嫌なシチュエーションや心配事は、なるべく言うようにしてる。 ということは、わた

先日、第7回Quesに参加してきました。 atnd.org 参加メモ 今回は事情によりノートPC画面が見れなかったので内容が飛び飛びですが、スライドに載っていないこと（発表者が直接発言していたこと）と質問内容を中心にメモを取っていました。 nihonbuson.hatenadiary.jp nihonbuson.hatenadiary.jp 発表内容について 全体的な内容については、それぞれの発表スライドとsakaimoさんのブログ内容が参考になるかと思います。 sakaimo.hatenablog.com 勉強会全体の感想 「アジャイル＆テスト自動化」「テスト分析」という、一見関係ないような2つを題材にすることで、普段知らないことを学ぶことが出来て良かったのだと思う。 テスト設計を考える人にとっては、アジャイルやスクラムなどサイクルが短いものに対して考える機会が少ない…かも テスト自動化

＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり

告知ページ connpass.com スライド 20151021 cookpad talk_test_engineer from Kazuaki MATSUO www.slideshare.net 自己紹介 発表者 松尾和昭 登壇者 和田卓人 今日は開発者視点のテストについて話していきたい 諸橋恭介 開発者だが、Cucumberに興味あり 庄司嘉織 E2Eテストが大嫌い 経歴 テストとクックパッドの働き方 大学時代は暗号系・分散コンピューティング系を研究 教授の影響でQAに興味を持つように ACCESS入社 テストを志向して入社 主にサーバーサイドをやっていた 異動したけど、テストをやり続けたかった クックパッド入社 Cookpadでは品質を向上させるためにテストを行う QAとは何をする役割なのか？ Googleの場合 Test Engineerはマニュアルテストをする人ではない QAの役

仕事のコードで，子クラスがたくさんいる難しいクラスがいて，継承関係を整理したいけど，どこがどうなってるのか一見すると分からなかったので，静的解析してクラス図をレンダリングするやつを作った． github.com package2plantumlclassdiagramっていうコマンド(長い)に，このファイルたちをレンダリングしてくれ，って渡して，PlantUML形式のファイルを作る PlantUMLでPNGとかに変換 という手順で使う． % package2plantumlclassdiagram ~/Plack/lib/**/**.pm > plack.plantuml % GRAPHVIZ_DOT=$(which dot) plantuml -charset UTF-8 -tpng plack.plantuml Plackのソースコード全体をレンダリングするとこんなかんじで，継承してる

導入経緯 「serverのログ見るときに複数のserverにsshで入って見るのとかつらめ」 という理由からリアルタイムで集められたら幸せになれるのではと考え、 fluentdを使ってみようとい結論に至った訳です。 なぜfluentdにしたのか 他にもflume(良く知らない)とかあるのになぜfluentdにしたかと言うと下記の理由から Rubyで実装されているのでカスタマイズとかプラグイン作る場合も作りやすいかな gemとして提供されているのでRubyプロジェクトでは導入しやすいかな プラグインがいっぱいある RubyKaigiでそのっつさんの下記のお話を聞いていたりで使ってみたかったとかそんな感じ Fluentd Hacking Guide at RubyKaigi 2014 リアルタイムログ解析もしてみる Fluentdを使うならElasticserchとKibanaも導入してリアル

【2016/09/10追記】 勉強しなおして、Elasticsearchの知識についてさらにまとめた記事を書いたので、そちらを参照してもらうと良さそうです。 blog.shibayu36.org 最近Elasticsearchの勉強をした。ただ、入門のためどのような資料が適しているかを知るのが大変だった。そこでどのように勉強したかについてメモをしておく。少しまとめエントリー的なノリになりそう。 Elasticsearchの概念を知る 全文検索技術の基本を知る Elasticsearchのドキュメントのたどり方を知る の順に学習を進めていった。 Elasticsearchの概念を知る Elasticsearchの学習を始めようとした時に、まずは基本からということで以下の本を読んでいた。 高速スケーラブル検索エンジン　ElasticSearch Server (アスキー書籍) 作者:Ｒａｆａｌ

テストフェーズとテストレベル 昨日受けたソフトウェアテストの資格試験で面白い問題があった。 縦軸にテストフェーズ、横軸にテストレベルをとってテスト計画を作れ という趣旨のもの。 システムテストフェーズで単体テストレベルのテストを実行する？！ みたいなw 継続的システムテストのコンセプトが一般的にまだまだ理解されにくく、その原因は Myersの言う「テストフェーズ」[1] Beizerのいう「テストのスコープ・観点（テストレベル）」[2] あたりを混同しているエンジニアが多いからなのかなとちょうど考えていたので、この問題は僕の心にクリティカルヒットした。このブログエントリでは、継続的システムテストをテストフェーズとテストレベルから整理し直してみる。 継続的システムストのテストフェーズとテストレベル 継続的システムテストのテストフェーズ 継続的システムテストでは、 ・開発テストフェーズ　　（開

最近、仕事でとあるプロジェクトを進めているのですが、いざ「スクラムをまわそう！」「プロダクトバックログを作ろう！」と言っても、「どうやって始めたらいいんだろう？？」と素人にはなかなかわからないもの。 そんなとき「ユーザーストーリーマッピング」という単語を見つけました。今回は僕が「ユーザーストーリーマッピング」を勉強するにあたって参考になったスライドを紹介します。 と、そ・の・ま・え・に ユーザーストーリーとは？ ユーザーストーリーとは、顧客の視点からサービスや商品の要件を記述したものです。 書くときは ＜役割＞として ＜機能や性能＞が出来る。 それは＜ビジネス価値＞のためだ。 という風に書きます。たとえば、ECサイトの検索機能の場合、 ＜客＞として ＜商品の検索＞が出来る。 それは＜欲しい商品をすぐに見つける＞ためだ。 こんな感じになります。 ユーザーストーリーマッピングとは？ 上のような