SEを父と夫に持つ奥さんへ

妻・夫を愛してるITエンジニア Advent Calendar 2016 - Adventar の19日目です。

今日は奥さんの誕生日だ。おめでとう。生まれてきて、出会って、結婚してくれてありがとう。

奥さんは高校の同級生で同い年なので、2ヶ月弱お姉さんになる。若い頃は「お姉さんだから言うこと聞いてね」とか話していたけど、最近は「おばさんになっちゃったー」とかふざけながら話している。付き合いだしてから10年弱、結婚してからは3年弱。こうやって同じ時間を過ごして歳を重ねていけるのが愛おしい。

タイトルにもしているけれど、奥さんのお父さん、義父は現役バリバリのSEとしてまだ働いている。 子供の頃は起きている間にほとんど家に帰ってこなかったらしく、母子家庭のようだったと話している。

自身もプロジェクトの状況次第では帰宅が遅くなることがあり、終電帰りや深夜の帰宅が続くこともたまにある。今年の1月から3月くらいは終電帰りが多くて家庭を任せきりだった。

忙しいと心身共に疲れてくるのだが、帰って奥さんと息子の寝顔を見ると疲れも吹っ飛んで、日々働くことができた。大変なプロジェクトだったけど、なんとか終わらせることが出来たのは奥さんと子供のおかげだと思う。ありがとう。

義父もSEということもあり、ガジェットや技術書への理解があるのもありがたい。 特に技術書は増える一方なのだが、仕事に必要なんでしょ？と理解を示してくれる。最近はさすがに多すぎだと怒られたので、先輩から頂いた裁断機でPDFに取り込もうと思う。 奥さんは看護師で、SEと同様に日々の勉強が必要なので理解があるのだと思う。

看護師といえば…最近鼻炎の治療を続けているのだけど、息子の胃腸炎を貰って39度の熱を出し、嘔吐したことがあった。 病院で診てもらい薬を貰ってきたのだが、飲み合わせが心配で胃腸炎の薬だけ飲もうとしていたら、奥さんが飲み合わせについて薬局に問い合わせてくれた。 普段はごはんを冷凍し忘れたり、安売りしてた肉を買って使い忘れたりするボケボケな奥さんだけど、スラスラ症状や鼻炎で飲んでる薬名、胃腸炎で貰った薬名を説明していて流石だった。うん、惚気だ。

子供はまだ2歳だけど、自分が使っているMacBookに興味を示してキーボードを叩いたり、iPadやiPhoneでゲームやyoutube見たりしている。 あまり画面ばかり見せたくないのだけど、父としては自分が好きなことに興味を示してくれるのは嬉しい。 将来、親子3代でなにか出来たら面白いなーと思っている。

とりとめのないブログになったけど、これから2ヶ月の年下期間を楽しみつつ、また同じ時を過ごしていこうと思う。

いつもありがとう。これからもよろしく。

UIテスト自動化でSIerのExcelスクショは滅びるのか

先日 JJUG CCC 2016 Fall に参加してきたってブログに書いたとおり、JJUG CCC 2016 Fallに参加してきました。

直接セッションは聞いていないのですが、 @backpaper0さんの 「Selenideを試行錯誤しながら実践するブラウザ自動テスト」というセッション中に流れてきたツイートがきっかけでタイトルの内容について考えてみたので書いてみます。

@backpaper0 さんの当日の資料は以下になります。

考えるきっかけになったのは、@khasunuma さんの以下ツイート。

@khasunumaさんは同イベントで Payara Micro の設計と実装 という発表をしています。Payara Microを利用している人には有用な情報が目白押しなので、見ることをオススメします。

8年間SIerにいますが、Selenideを導入すればそれで大量の失業者が発生するとは思えないってのが自分の考えです。

ただ、新人や若手がテスト要員(≒スクショ要員?)としてプロジェクトに突っ込まれ、死んだ目をしたテスト実行エビデンス取得マッスィーンになっているのを何回も見ているので心が痛いところです。

ツイート見ると蓮沼さんもツラい経験を多くしてそうですね(´；ω；｀)ﾌﾞﾜｯ… エビデンスの偽造…うっ頭が…

エビデンスの作成は面倒ですし、出来ることならスクショを撮ってExcelに貼り付けて…なんてことはやりたくは無いというのには同意です。

とはいえ、そんな簡単に撲滅できるような話ではないと考えています。

以下自分のツイート。

別のプロジェクトにいる後輩とやり取りをしているのですが、UIテストの自動テストはテストスクリプトの作成にそれなりにコストがかかります。

UIの変更が頻繁に入る場合、パッケージやサービスとして提供するので回帰テストの頻度が多い場合などはテストスクリプト作成コストを回収できる、もしくは回帰テストを行えるメリットが大きい場合などは採用を検討すれば良いと思います。

採用を検討すれば良い と書いたのは、そこには組織文化や、プロジェクトのコンテキスト、メンバーのスキルセットなど絡んでくるので、そこも含めて検討する必要があるからです。

そして、全てにおいて適用する / しない ではなく、特定のページのみ採用するメリットがあるのであれば部分的に導入するのも良いと思います。

自分がテスト戦略や計画において採用するテスティングフレームワークを決定でき、コスト度外視で採用できるならすれば良いですが、それで顧客や会社からの信用が得られるかは別の話です。

例えばUIの自動テストがコスト的に採用が難しい場合、手動でテストを行い、必要であればエビデンスとしてスクリーンショットを取得します。

その作業は単純作業でツラいものになりますが(どう感じるかは人によるでしょうが)、そういった作業は以下のようなツールを利用することでツラミを和らげてくれます。

手動テストは嫌だからUIテストを自動化する、ではなく、コストのバランスなどを見ながら自動化可能なところを自動化していけば良いのではないでしょうか。

また、そもそもエビデンスとしてスクショが必要なのかどうか顧客に確認することも大事です。 伝統的に取得しているから今回も…ではなく、本当に必要なのかどうか確認しましょう。 スクショにかかっていたコストを新機能の開発に充てられればお互い幸せになれます。

まとめ

思考停止でUIテスト自動化を する / しない の二元論で考えず、自分たちに合った手法やツールを検討・採用すれば良いと思います。 タイトルに対しての今現在の個人的な回答は、顧客がエビデンスとしてスクショを望み続ける前提で コスト度外視すれば可能だが、そんなことは有り得ないので滅びない です。

とはいえ、各ブラウザの仕様が統一されていき、Selenideのようなフレームワークがもっと洗練され導入コストが下がってくれば未来はわかりません。(全く別の素晴らしいソリューションが出てくることもあるかもしれません)

そんな未来がきたとき、死んだ目をしたテスト実行エビデンス取得マッスィーンのままだと新しい仕事に有りつけず失業してしまうので、そうならないようなスキルを身に着けておくようにしましょう。

…そんな未来が早く来ると良いですね(遠い目)

JJUG CCC 2016 Fall に参加してきた

f:id:tenten0213:20161203230601p:plain

www.java-users.jp

JJUG CCC 2016 Fallに参加してきました。

以下参加セッションの感想。

なんかツイートしてたの貼り付けておく。酔った勢いで書いているから記憶が…

Be a great engineer!〜 フォローすべきトレンド、スルーすべきトレンドをどう見抜くのか

@cero_tさんによる基調講演。見たことがある講演ではデモや技術的な内容が多い印象だったのですが、今回は大真面目に話していました。

朝一の講演だったので、ギリギリ着席。

記憶が曖昧だけど、何段階か状態？があって、一番上の理を理解した人は全てを手に入れるって感じの話しだったと思う。 なんかどこかにお金ってワードがあっても良さそうだなーって思ってツイートしたんだと思う。

技術トレンドの話しでガートナーの話しが出てきた。 自分自身がR&D部門にいた際に、組織長が組織の方針を決めるのに参考にしていたし、自分自身も内容を見たりした気がする。 最近はあまりガートナーは見ていなくて、ThoughtWorksのTechnorogy Radar とか良くみている気がする。

話しのなかでMicroserviceの話しとか出てきて、組織の話しもあった。 コンウェイの法則は、ソフトウェアの構造は組織を反映したものになる、だから例えばマイクロサービスのようなアーキテクチャにしたいのであれば、そのアーキテクチャに合わせた組織にしましょうって感じ。

全体を通して共感できる点が多く、自分も考えているような内容もあれば、違う意見もあって面白かった。

SIerもはじめる、わたしたちのDevOps

同僚のしょぼちむと、R&D部門に所属している阿佐さん の発表だったので最前列で応援してきた。

しょぼちむの資料

阿佐さんの資料

その時間帯のついっと。

なんかやると思っていたけど、PPAPの音楽流してあのサングラスとスカーフ？を付けてやるとは思わなかった。 DevとOpsでDevOpsって…

オープニングとは打って変わって、内容は割りと真面目でSIerがDevOpsに取り組む意味や、まだ社内向けではあるものの実践している内容の紹介をしていて良い内容だった。

これは自分も参画していたプロジェクトなのだけど、実際SIerの金融系のシステムの本番環境でDockerが動いていたりする。

1サーバ(1プロセスかな？)でもfalchioinコンテナを利用すると無停止縮退なしでデプロイ可能とのこと。 実際デモしていたが、3秒くらいで切り替わっていたので凄かった。

まだ社内システムが対象なので、弊社のメインの顧客である金融系や公共の大きなシステムでも事例を作ってみたいなーと思ったりしたりしなかったり。

ここから阿佐さんにチェンジ。 安心感と安定感のあまり、ツイートが少ない！

最初に資料がここにありますよーってサイトがちょっと見れなくてドキドキしたけど、実はGCP上にKubernetesを使ってDockerコンテナクラスタが動いてたとか。お茶目か。凄い…

f:id:tenten0213:20161204000419p:plain

f:id:tenten0213:20161204000605p:plain

名言。

阿佐さん、ランチ中にも名言残しまくっていて尊敬の念が止まらなくてヤバい。

日本でも出来る！最先端のDevOpsを導入する方法

社内の勉強会で牛尾さんのブログが取り上げられたり(自身も結構読んだ)、kawasimaさんから面白いよと勧められたこともあり聴講。

のっけから凄いテンションでDev-Opsとコール&レスポンスを求められて入る部屋間違ったかなと思った。

けどそんなのは最初だけで、終始わかりやすく軽快に説明してた。 ちょっとブログの内容にネガティブな印象もあったのだけど、直接話しを聞くと全然そんな印象は受けなかった。 文章と実際に話しを聞くのとでは捉え方が変わるのかも？

Spring CloudでDDD的なマイクロサービスを作ってみる

現在のプロジェクトでDDDのエッセンスが入っているアーキテクチャを採用しているため、椎葉さんのセッションを聴講。

立ち見だったのと、手書き資料、ソースコードやデモ、話しに集中していてツイートが少なめ。

考えて試して、トレードオフがあることを理解した上で妥協点を見極めて…といったプロセスが垣間見え、とても参考になりました！ 発表後に質問して丁寧に答えてもらったり、懇親会でも話すことができたのでホント嬉しかったし楽しかったです。

GitBucketを支えるJava技術とグローバルで使われるOSSの作り方(聴講はしていない)

椎葉さんのセッションと同時刻に行われていて聴講していないのですが、普段からヘビーユースしており(全社的に)、以前H2が壊れてPostgreSQLに移行した際もお世話になったのでご挨拶させていただきました。

その節は本当にありがとうございました。神対応でした。

弊社、かなりGitBucketを利用しているので、何かしらで恩返ししたいところです…

ドメイン駆動設計とScala 〜既存プロジェクトへの適用〜

お次は元同僚の角谷くんのセッションを聴講。

弊社ディスられて、生かして帰すまじって感じだった。

というのは冗談で、正直ディスられるような状況も多いので胸が痛いところだった。

現在の職場でも同様に苦労したようだけど、DDDを採用して改善したのは凄いと思う。 でもその前は結構良くない状態だったようだし、他のシステムも大丈夫なのかな？て気はするので、別にSIerだからとかは関係無いかなと思う。

比較的技術に興味がある人が多いってのと、システム開発を自分事として捉えられる人が多いってところは大きそうだけど。

内容はDDDについての引用が多かったので、もっと現場で苦労した点とか工夫している点が聞きたかったなー。

Spring Cloudアプリケーションの開発にDockerを活用し、Kubernetes上にデプロイするまで

最近Dockerをちょくちょく利用しだしているので、村田さんのセッションを聴講。

Kubernetesやfabric8など、さわったことが無いプロダクトが多かったので、デモを観て「おー、スゲー！」って感じだった。

fabric8-maven-plugin、凄い便利そうだったけど、mavenでやるのどうなんだろ？ いや、でも凄い便利そうだった。

Javaエンジニアのキャリアを考えるパネルディスカッション

最後は実物@hishidama さん見たさにパネルディスカッションを聴講。

平素お世話になっております。

実際、 @yusuke さんは大手SIerや外資、Twitterで働いたり、起業しているし、 @johtani さんは あのElastic社だし @yoshiori さんはドワンゴとかクックパッドだし、みなさんのキャリアや考えを聞きたかったってのが大きい。 最近上司との面談やメンターとの1 on 1、メンティーとの1 on 1をしたりもしたし。

内容はとてもおもしろかったのだけど、これしかツイートしていなかった模様。

ずっと技術でいくのか？という問いに対して、「マネージャになると自分で仕事を選べるし、プログラム書きたいなら書ける。どちらかしか出来ないという訳では無い」という感じの回答だった。(もう少し話していたけど)

実際今の部門のマネージャはコードを書いていないし、会議ばかりだし雑務多そうだし、そうなりたいと思えるマネージャがいないのだけど、自分がやりたいようにやれるのならそれも良いなと思ってしまった。よしおりさん凄い。

他にも凄い若者に勝てないから別の道で…とか自分が一番の下手くそでいたいから転職した(情熱プログラマに「一番の下手くそでいよう」という章がある)、とか面白い話がたくさん聞けた。

懇親会

いろんな人と話しができた。 あまり話せなかった人もいるので、次回にもっと話したい。

しょぼちむが再度PPAPしたりかわしまさんが真面目なフォローLTしたりして面白かった。

ちょっと個人的に引っかかるLTがあって不快になったのと、眠かったのでちょっとだけ早めに帰ってしまったのが心残り。

さいごに

こんなに大人数が参加するカンファレンスを運営してくださったJJUGスタッフのみなさん、登壇者のみなさん、サイコーのカンファレンスでした。 お疲れ様でした！！ & ありがとうございました！

WindowsマシンからMacにVNC接続する

MacからWindowsマシンにRDPする - てんてんのぶろぐ でMacからWindowsに接続する方法を書いたのですが、仕事をしているとWindowsからMacに接続したいシーンも出てきたので調べてみました。(例えばXcodeでエミュレータを起動してデモしたり、コードレビューしたり)

調べてみると、Macの設定を変更すればVNC出来る模様。

システム環境設定 - 共有 から

f:id:tenten0213:20161129205431p:plain

画面共有 にチェックを入れます。一応すべてのユーザにアクセスを許可しておきます。(しなくても大丈夫だと思いますが)

f:id:tenten0213:20161129205112p:plain

次にコンピュータの設定…からポップアップで出てきた選択肢の両方にチェックを入れ、パスワードを入力します。
これでMac側の設定は終わりです。

f:id:tenten0213:20161129210702p:plain

次はWindowsからVNCで接続します。 VNCのクライアントは会社で良く利用しているUltraVNCを利用しました。

UltraVNCクライアントを起動し、接続先のMacのIPかホスト名を入力して接続します。

f:id:tenten0213:20161129205131j:plain

パスワードの入力を求められたら入力すると、Macに接続されます。

f:id:tenten0213:20161129211234j:plain

これで会議室にあるPCから自席PC(WIn)にRDPして、自席PC(Win)からMacにVNCすることでデモとかレビューが出来る！

MacからWindowsマシンにRDPする

最近お仕事でiOSアプリを作ることになり、開発はMac、事務作業などはWindows、と使い分けなきゃいけなくて面倒だなーと思っていたのですが、 調べていたらMicrosoftからアプリが出ていたので利用してみました。

以下からMicrosoft Remote Desktopをダウンロードし、インストールします。

起動したら、New から新規のRDP接続を作成します。

f:id:tenten0213:20161114122619p:plain

以下のように、接続先のPC名、User/Passを入力します。

f:id:tenten0213:20161114122702p:plain

証明書が無く安全でない旨のメッセージが出ますが、 Always Trustのまま Continue します。
(ここは自己判断で）

f:id:tenten0213:20161114122522p:plain

すると、WindowsにRDPされて画面が表示されます。

f:id:tenten0213:20161114122909p:plain

ファイルを共有する

WindowとMacのRDP中のファイル共有も同アプリケーションで行えます。

対象の接続のRedirection を選択し、 Enable folder redirection にチェックを入れ、 +から共有するフォルダを追加します。
今回はユーザ直下にshareというフォルダを作成しました。

f:id:tenten0213:20161114123059p:plain

すると、WindowsにRDPした際に、以下のようにマウントしたフォルダが表示されるようになります。

f:id:tenten0213:20161114123126p:plain

ただ、Windows側からフォルダ共有してやる方が楽な気がします。

Apple Developer Programの支払から利用開始まで意外と時間がかかった話し

と、Appleにお布施を払ったものの、全然利用できるようにならない。

メンバーセンターに行くと、アカウント名の下にはPendingの文字が。

画面中央下にはYour purchase may take up to 48 hours to process.ってあるけど、48時間以上経っても使えない。

f:id:tenten0213:20161108191833p:plain

営業日計算か？でも2営業日以上経ってるよなって思いつつ、サポートに連絡してみる。

f:id:tenten0213:20161108193931p:plain

で、一旦返答待ち。

f:id:tenten0213:20161108193531p:plain

返信きた！

ん？もう年間契約が開始していると。

f:id:tenten0213:20161110002332p:plain

メールを探すとあった！って↑のメールの15分前とかじゃないか。
(2016年11月9日 9:50受信)

f:id:tenten0213:20161110003734p:plain

確かに使えるようになってる！

f:id:tenten0213:20161110001457p:plain

11/4(金) の朝8時に登録したので、11/8(火) の朝には使えるかな？と思っていたけど、実際に連絡が来たのは11/9(水) の朝だった。
48時間後は目安？ってとこなのかな。

土日挟んでて感覚的に長く感じたから問い合わせしてみたけど、とりあえず3営業日くらいはのんびり待ったら良い。

こんな記事もあって、支払情報と登録情報にズレがあると保留になったりもあるみたいなので怪しかったら確認したら良いと思う。

iOS / Swift開発環境構築メモ

iOS

直近ごりごりJavaでサーバサイドの処理を書いていたんだけど、次はiOSアプリをSwiftで作るってことになったので諸々調査とか準備を進めてる。

iOSは3年くらい前にちょーっとだけObjective-Cで遊んだことがあるくらい。

だいぶ開発環境周りも変わってるだろうからまとめておく。

OSの最新化

Xcode 8, Swift 3 でいくので、macOS Sierraにアップグレードしておく。

ここらへんはわりと緩い判断で、iOS 10のみのサポートで良いって言われたから最新でまとめている感じ。
リリース済のアプリケーションがある場合は結構大変そう。

Homebrewインストール

Mac用のパッケージマネージャ。なにかと便利なので入れておく。

以下を実行してインストールする。

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

社内proxyに引っかかる場合は、http_proxyとhttps_proxyを設定しておいてやる。

export http_proxy=http://example.com:proxyPort
export https_proxy=http://example.com:proxyPort

昔は気が向いた時にbrew updateしていたけど、最近は brew upgrade とか brew install したときに自動でupdateされるらしい。

Homebrew自体は上で設定した環境変数を見てくれるから、追加のProxy設定とかは必要ない。

Gitのインストール

プロジェクトではGitを利用するので、一応。

$ brew install git

インストールしたGitまでのパスを通しておく。

export PATH="/usr/local/Cellar/git/X.X.X/bin:$PATH"

バージョンを確認し、インストールしたバージョンだったらOK

$ git --version

Rubyのインストール

iOSアプリ開発におけるツール類がわりとRubyに依存しているので、Rubyをインストールしておく。

MacにデフォルトでRubyが入っているけど、global汚染だRubyのバージョンがーとか考えだすと面倒だからrbenvでRuby入れることにする。

$ brew install ruby-build
$ brew install rbenv

以下のコマンドでインストール可能なRubyの一覧を確認。

$ rbenv install -l

最新安定版をインストールして、globalに設定する。

$ rbenv install 2.X.X
$ rbenv global 2.X.X
$ ruby -v

後々使うので、bundlerをインストールしておく。

$ gem install bundler

SwiftLintのインストール

Swiftの静的解析用にSwiftLintを入れておく。

$ brew install swiftlint

.swiftlint.yml を設定してプロジェクトルートに配置することで、ルールを変更することができる。
ルールは以下を参照。

以下のようにコマンドでルールを確認することが出来る。

$ swiftlint rules

チームで使うGemのインストール

チームでGemのバージョンは合わせたいので、Gemfileに依存関係を書いてbundlerでインストールする。

Gemfileの書き方は以下を参照。

source "https://rubygems.org"

gem 'rake'
gem 'fastlane', '~> 1.2', '>= 1.2.3'
gem 'cocoapods', '~> 1.1.1'
gem 'xcode-install', '~> 1.3'
gem 'jazzy', :git => 'git@github.com:realm/jazzy.git'

インストール

$ bundle install --path=vendor/bundle

使うときはbudle exec する。 付けないとシステムにインストールした方が使われる。

$ bundle exec pod install

Xcode 8のインストール

手動

OSが古いとコケたりするみたいだけど、OS最新にしてからなら大丈夫っぽい。
互換性のところに、OS X 10.11.5以降と書かれている。

$ xcode-select --install

か

でインストールする。

xcode-install使う場合

チームでバージョン合わせたいし、後々スクリプト化とか考えたときにもCLIで実行出来たほうが良いので、こっちでいきたいとこ。 まぁ人数少ないし、人の増減もほとんど予定していないので別に良いんだけども。

userIdとかpasswordを求められたら、AppleのIDとpasswordを入れれば良い。

$ bundle exec xcversion update
$ bundle exec xcversion list
$ bundle exec xcversion install 8.0
$ bundle exec xcversion select 8.0

Xcodeのプラグインインストール

Xcode8でプラグインを使用するためには各プラグインにUUIDを追加する必要があるとかで、それをやってくれるgemをインストールしておく。

$ gem install update_xcode_plugins
$ update_xcode_plugins

プラグインマネージャのインストール

プラグインマネージャはAlcatraz一択っぽい感じ。昔も使ってたし。

以下を実行することでインストールできる。

$ curl -fsSL https://raw.githubusercontent.com/supermarin/Alcatraz/deploy/Scripts/install.sh | sh

なにはともあれVim

XVim入れる。

Xcode8に入れる場合は手順が違うので注意。

あとはお好みで

便利そうなの入れる

まとめ

とりあえずまとめてみた。 次は自動化できるところは自動化するようにするのと、CIあたりをまとめたい。