Galapagos Tech Blog

株式会社ガラパゴスのメンバーによる技術ブログです。

ブログの極意を教わったのでかいてみたよ

こんにちは!テストチームとのの(TW:@tonono2587)です。 先日2017/01/30,バンさん( GitHub:@vanhuyz )と一緒に勉強会に参加してきました! このエンジニアブログも試行錯誤しているところなので、参考になりました。感想などまとめましたので、ぜひ読んでください。

f:id:glpgsinc:20170206212440p:plain ブログかくのも真剣(必死)ですよ…


参加した勉強会はこちら↓

「サポーターズ勉強会 エンジニアのためのブログ講座」
【学生&若手エンジニア向け勉強会】エンジニアのためのブログ講座 - connpass

2017/01/30 19:30〜 @渋谷サポーターズオフィス
講師:田中賢治さん


■内容

エンジニアのためのブログ講座で講師をさせていただきました! | Developers.IO


ご自分のブログで、レポートをあげてくれていました。内容はこれがすべて!って感じです 笑
そのなかで、わたしが個人的にいいなと思ったところをまとめます。

[気持ち編]

■自分にとってブログを書くメリット
・自分の理解を測り、深める…知識のアウトプット先、インプット元になる
・知人が増える

■自分以外の人にとってのメリット
・ハマるところはだれしもハマる。そんなときの助けになる
・書いている人からモチベーションをもらう


[書き方編]

■習慣化の方法
・とにかく小さい単位でつづける…少しでも、やってみた→どうなったの繰り返し
・他の人とかぶっても気にしない。自分が書くことに意味がある
・書きたいときに書く!
■装飾をうまくつかう
・リンクの貼り方や文字の装飾など、意味を知って効果的につかう
■目次から書いてみる
・目次を先につくり、テンプレート化する
・それに沿って書くと書きやすい

[ということで、やってみた!]

「目次から書いてみて、テンプレート化する」
たしかにこれなら早く書けそう!!と思ったので実践してみます。

こんな目次をつくりました〜
・バンさんと行った
・日時
・内容
・やってみた
・感想

すごくざっくりしているので、「内容」のところを書きながら細かくしていった感じです。
自分のメモを読むときにも整理しやすくて、はやく書けている気がします!
(ここまでで30分かかってない)

結果:「なんかはやく書けてる!気がする!!!」



[感想]
現実的に言うと、いままでの2本は書き始めてから1日以上、3日くらいで完成だったと思います。
話を聞いて、コツみたいなものがあるのかな〜となんとなく思いました。そこから「書ける!」気分になっていきました。
これからブログを始めようとしている方々とも交流できて刺激になりました。
そのとき弊社HPを見せてドヤ顔したのですが、なんとこのブログへのリンクがないことに気がつきました∑(*`ロ´ノ)ノ
近々HPにリンクを貼ってもらう予定ですので、応援よろしくお願いします〜!!

ドヤ顔できるガラパゴスHPはこちら

www.glpgs.com

それでは、またお会いしましょう、とののでした〜

テスト分析とテスト設計勉強会に参加しました!(前編)

こんにちは!テストチームとのの(TW:@tono2587)です。
先日2017/02/03、「テスト分析とテスト設計勉強会」に参加してきました!
同日〜翌日のJaSSTには参加できなかったのですが、この勉強会はわたしにとってたいへん学びがありましたので、参加レポートとしてまとめたいと思います。

f:id:glpgsinc:20170210160415p:plain ふむふむふむふむ

■「テスト分析とテスト設計勉強会」

2017年2月3日(金)@日本大学駿河台キャンパス
め、めずらしいつくりの建物でしたよ(迷ってないよべつに全然)

https://connpass.com/event/47938/connpass.com

教室がけっこう埋まっていたように見えたので、参加者は多く感じました。

■参加前の気持ち

動機や興味、自分のなかでの課題や知りたかったことのイメージです。
・業務でテスト設計することが増えてきた
・あんまり上手く設計できていない気がする(レビュー戻り多い)
・絶対もっとなんかいい方法があるはずだ
・「初心者向け」←わたしのことか。呼ばれている

■勉強会の内容(前編)

□秋山さん:JSTQBのテストプロセスについて
・「プロセス」とは何か
 相互関係のある活動のセット。(活動は入力を出力に変換すること)
活動の例:<(入力)お湯にパスタを入れる>−[(活動)煮る]−<(出力)柔らかくする>
プロセスは、このような[活動]のセット
JSTQBのいう「テストプロセス」とは何か
 基本的には、
 [①テスト計画とコントロール]−[②テスト分析と設計]−[③テスト実装と実行]−[④終了基準の評価と報告]−[⑤テスト終了作業]
によって構成される。
・これらの①〜⑤のテスト活動は、開発と整合している必要がある。
 システムテストレベルでいうと、
プロジェクト計画と同時にシステムテスト計画を始め、
要求仕様→システムおよびアーキテクチャ設計仕様→コンポーネント設計仕様と並行してシステムテスト分析および設計をおこない、
…以降も開発の活動と並行して行う。

・テスト分析、テスト設計とは?
 ・テスト分析とは:テストベースを分析すること。テスト条件を識別する。
入力:テストベース…仕様書、議事録などテストをつくるもとになるもの。これはドキュメントで、レビュー済みの整ったものをつかうのがよい。
活動:テストベースとテスト目的を分析する…ユーザーはなにをしたいのか(目的)など
出力:識別されたテスト条件…いろんな粒度で定義することが望ましい。画面(粗)、画面の部品(細)、など

 ・テスト設計とは:
入力:テスト条件
活動1:テスト条件をどうやって網羅していくかなどを決めていく
活動2:テストケースをつくる。どういうテスティングで確認するのか、どういう環境でどういう期待値で…
出力:テストケース

・構造化分析と構造化設計について
 開発と同じでテストも、いきなりコードを書いていたが、ループするところとかは構造化しましょう、となっていった

『構造化分析とシステム仕様』トム・デマルコ 著 によると、
 ・分析とは、行動をとる前に実施する、問題の調査である
 分析の最も重要な生産物は「仕様書」である。分析をすることで具体的にしていき、それが「仕様」になる
 分析の後に続く行動とはそのシステムを構築することである。

 ・設計とは、手続き的な部分(順序)と、階層的な部分を決めて、構築することである
 トップダウンで分割して順番と階層を決めて、ものをつくっていく

ーー質疑応答より
・「テストは条件次第」
 テスト対象に従って、どんな要求があるのかを確認して決めていく。
 →先にものさしを決める。

・テスト条件が様々な粒度で定義することが望ましい理由は?
 人によって(立場などによって)みているものが違うので、お互いに合意をとるためにも必要になるから。
 (共通言語みたいなもの、というイメージでしっくりきました。)

□藤沢さん:テスト分析・設計について、釈然としないところ

・テスト分析も、設計も、要するにどんなことを言うのか?→わけなくてよくない?
・仕様書のコピペはばぜだめなのか
→仕様書に書いていないことをテストに入れるべきだ
・「テスト」も「分析」も曖昧だからくっつけてもわかんないのでは?
・「分析」ってなんだ?…理解できるようにわけることなんじゃないか。
*分析 のアウトプットが曖昧ではないか?どこまでやれば「分析」が終わっているのかわからない
・分析しないと困ることは?
 ・分析しないと仕様が曖昧だから、必要なテストが漏れる
 ・なにをテストしたのかわからないことになる

・藤沢さんのいまの感じの定義
分析:グループにわけてわかりやすくすること
設計:テストケースの元ネタをつくること
実装:元ネタ(設計)からテストケースを作成すること

・テスト設計をしないと困ることは?
 ・仕様書のコピペでテストケースをつくると、なんでこのテストケースなのかわかりづらいし、説明が不足する
 ・なんでこのテストで十分なのか説明できない

・分析と設計、どっちかが欠けるとかはなく、セットなのでは???
・どこからどこまでが分析/設計なの?

・結局、分析/設計はなにがしたいかようわからん!!

■前編までの気持ち

秋山さんのお話で、教科書的な「テスト分析」と「テスト設計」を知ることができました。
テスト分析やテスト設計といった言葉の意味自体ぼんやりとしていたので、お話を聞いて形がつかめてきた感じがします。
それをふまえて自分の仕事を振り返ると、テスト分析が全然できていないこと、テスト設計も上手くいっていないことがわかりました。
だからレビューの戻りが多いし、時間もかかるのだと思いました。

なんとなくつかんできたと思っていたところでしたが、藤沢さんのお話にはなんだか説得力があって、
「どこまでが分析なんだ」みたいなところはとくに(ああ…たしかに…??)と納得してしまい
(((分析)))や(((設計)))がまたもやもやしたものに…
このお話があったお陰でこのあとすごくスッと話が頭に入ってきたのですが、この時点では正直もやもやした理解しかありませんでした。

後編へつづく

UITextViewを画面いっぱいのサイズにする

御機嫌よう、ガラパゴスのおとめです。

今日は、UITextViewを、オートレイアウトを使って、キーボードを除いた画面いっぱいのサイズにしてみようと思います。UIScrollViewに入れてキーボード表示時にスクロールさせるのではなく、使える広さは全部UITextViewにします。

この記事は、Swift 3.0とXcode 8.2.1を対象としています。

Viewの作成

適当にプロジェクトを作成して画面を作ります。よくある感じのUITableViewのある画面で追加ボタンを押すと入力画面を表示するイメージでViewを作成し、Text Viewを適当にドロップしたら、Add New Constraintsで上下左右を0に設定します。

f:id:glpgsinc:20170124183807p:plain

キーボードの通知を受け取る

さて、UITextViewは画面いっぱいにしていますが、このままでは下部がキーボードに隠れてしまいます。そこで、キーボードが表示された時に大きさを調整する必要があります。

キーボードに関連する通知は、NotificationCenterを通じて取得することができます。キーボード関連の通知は以下のようになっています。

通知 呼ばれるタイミング
.UIKeyboardWillShow キーボードが表示される時
.UIKeyboardDidShow キーボードが表示された後
.UIKeyboardWillChangeFrame キーボードがViewの位置やサイズを変更する時
.UIKeyboardDidChangeFrame キーボードがViewの位置やサイズを変更した後
.UIKeyboardWillHide キーボードが非表示になる時
.UIKeyboardDidHide キーボードが非表示になった後

通知を処理するには、NotificationCenter.addObserver(...)で、通知とそれを受け取る関数を指定します。ここではViewが表示される時に呼び出します。

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    let notificationCenter = NotificationCenter.default
    notificationCenter.addObserver(self, selector: #selector(self.keyboardWillShow(notification:)), name: .UIKeyboardWillShow, object: nil)
    notificationCenter.addObserver(self, selector: #selector(self.keyboardWillChangeFrame(notification:)), name: .UIKeyboardWillChangeFrame, object: nil)
    notificationCenter.addObserver(self, selector: #selector(self.keyboardWillHide(notification:)), name: .UIKeyboardWillHide, object: nil)
}

もちろん.addObserver(...)したからにはお行儀よく.removeObserver(...)しましょう。Viewが表示される時に.addしたのですから、その反対といえばViewが消える時ですね。nameを指定しなければ、全ての通知を解除します。

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    let notificationCenter = NotificationCenter.default
    notificationCenter.removeObserver(self)
}

UITextViewの制約を変更する

今回はオートレイアウトを使っていますので、キーボードが表示される時に、下の余白をキーボードの高さに合わせることで実現します。

まず、Assistant Editorを表示して、ドキュメントアウトラインのConstraintsから.bottomをCtrlキーを押しながらEditorにドロップします。

@IBOutlet weak var todoConstraint: NSLayoutConstraint!

これでコードから制約を変更することができるようになります。では関数を実装しましょう。キーボードの高さを取得して、制約にその値を設定します。レイアウトを変更しますので、最後にUIView.layoutIfNeeded()を呼び出します。

func keyboardWillShow(notification: Notification) {
    let rect = (notification.userInfo?[UIKeyboardFrameEndUserInfoKey] as! NSValue).cgRectValue
    let duration: TimeInterval = notification.userInfo?[UIKeyboardAnimationDurationUserInfoKey] as! Double
    self.todoConstraint.constant = rect.height
    UIView.animate(withDuration: duration, animations: { () -> Void in
        self.view.layoutIfNeeded()
    })
}

キーボードの種類を切り替えたり変換候補が最初に表示される場合などでキーボードの高さが変わる場合でも、.UIKeyboardWillShow通知が発火します。

反対にキーボードが非表示になる際には、制約に0を入れます。

では実行してみましょう。UITextViewをタップしてみると、(スクリーンショットでは分かりにくいですが)キーボードを除いた高さになりましたね?

f:id:glpgsinc:20170124184056p:plain

さいごに

最近Swiftに入門したのですが、入門前はキーボード表示でViewのサイズを変更するなんて簡単というか自動でできそう? くらいの勢いでした。こうして記事にして見ると実際簡単そうですが、実は意外とハマったり?

さて、ガラパゴスでは人類の進化に貢献したいエンジニアを大絶賛超募集しています。皆様の応募をお待ちしています。

www.glpgs.com

では、御機嫌よう。

この記事は業務の一環として業務時間を使って書きました