投稿者: soeno

2017/04月入社 フロント周りを触らせてもらっています。

年末にいろいろ振り返る

コメントする
こんにちは株式会社イメージ・マジックのsoenoです 。
今週テックブログということでクリスマスっぽい何かを考えていましたが、
終わりましたね。クリスマス。
それでも何か季節感のある投稿をと思った結果、今回のテーマは振り返りです。
会社のブログなので入社以来で いろいろ振り返ってみようかと思います。
 

入社以来何が変わったか

変わったこと（いろいろありますが今回は3つ。）
  1. 黒い画面を怖がらなくなった。
  2. IntelliJ IDEA と少し仲良くなった。
  3. データが降ってくると思わなくなった。
詳細は以下の通りです。



変化の詳細

黒い画面を怖がらなくなった。

　コマンドプロンプトの入力機会が増え、
コマンドプロンプトで何かを操作することは特別で危険なものという意識から
環境を整えたり、エラーの確認に必要なものと理解しました。


IntelliJ IDEAと少し仲良くなった。

直近ではgitでやらかしたときの後始末でお世話になりました。
個人的には
　　「CapsLock + Alt + 縦に選択」　での複数エリア編集からの
　　「ctrl　+　ｗ」　での単語選択、の後の入力がとても素敵だと思います。
　　　→構造の近い要素で単語の長さを気にせずにクラスを足すなどできます。



データが降ってくると思わなくなった。

　フロントのみ開発していると、 型やら数は最初に取り決め
サーバーから取り決めた形で降ってきたデータで色々する。（その後は知らない。）
　という認識が、サーバー側の処理も見える環境によって、 phpが渡すデータを作り、その大本にはデータベースがいて …… などという 一連のやり取りとしてみえるようになりました。（何ならDBが書き換わるところまで見えます。）

　よって、データは降ってくるものではなく、それ用に加工され渡されている。という理解になりました。


まとめ

　全体的に古めで人力な開発から、フレームワーク等を使った新しく、パワフルな開発環境へ変わった印象です。


おわりに

朝のエレベータで死ぬほどネストしたscssを思い出し、
さらにそれすら修正後（css→scssへ）のデータだったことを思い出し 。
いろいろ変わったものだとしみじみ思いました。

今後もいろいろな変化があると思いますが、
その変化が良いものであるといいと思います 。

それでは少し早いですが良き年末、良き新年を！

Google chromeでの2種類のスクリプトテスト

コメントする
株式会社イメージ・マジックの技術ブログ、今週の担当のsoenoです。


今日は4月の初めの日です。

新学期かつ新元号の発表の日となります。

11時半が発表だそうです。

そんな節目のテックブログ何となく大事に思えるのですが、大丈夫でしょうか？

元号はともかく、今日の担当も実はエイプリルフールだったりしないかなと思いつつ始めます。

ブラウザでのスクリプトを動かすとき

あまり使わない関数の書き方に迷ったとき、

そういう時はコマンドラインでスクリプトを動かすとテストできます。

コンソールからスクリプトの実行

手順は以下の通り

  1. chromeブラウザでF12キーを押して DevToolsを立ち上げ
  2. メニューバーのConsoleを選択
  3. アクティブになっているテキストエリアにスクリプトを入力してEnter
https://www.google.com/で試す場合

  • まずhttps://www.google.com/に移動して
  • コンソールに以下のスクリプトを入れてEnter!
[HTML] document.forms.f.q.value = “新元号”; document.forms.f.submit(); [/HTML] 新元号についての検索結果がでます。

スニペットからスクリプトの実行

手順は以下の通り

  1. DevToolsのメニューバーのSoursesを選択
  2. 左のメニューのSnippetsを選択（なければ横の矢印を押して出てくるlistから選択）
  3. New Snippedの左の+ボタンを押して新規のSnippetを作成
  4. 空白のエリアに実行したいスクリプトを入力
  5. Ctrl と Enterを同時に押すか、右下の再生ボタンをクリック。
https://www.google.com/で試す場合

  • まずhttps://www.google.com/に移動して
  • 上の手順でSnipedの入力画面まで進み、
  • 以下のスクリプトを入力しCtrl + Enter!
[HTML] var searchForm =document.forms.f; searchForm.q.value = “新元号”; searchForm.submit(); [/HTML]

注意点

jQueryなどのプラグインの動作を試したいといった場合は対象のプラグインが読み込まれている必要があります。

※例のgoogleページへのスクリプトは内部の変数などかわってたら来ません。

終わり

最後の平成に間に合わせようと駆け足になりましたが、以上です。

新しい元号の新しい時代が良いときとなりますよう…。

Seleniumテスト環境設定時の注意点

コメントする

はじめに

株式会社イメージ・マジックの技術ブログ、今週の担当のsoenoです。

二週間以上前に買うと決めたものを未だに買えていません。
日常生活においてはどうでもいいことこそ、タスク管理が重要なのかもしれません。

さて、今回はSeleniumのテスト環境の設定時に気を付けることを書こうと思います。


Seleniumとは。

webアプリケーション向けのテスト実行ツールです。
GUIを通した操作を自動で行わせることができます。

名前にまつわる注意点

Selenium~といった名前が結構いろいろ出てきます。
細かく書いていくとかえってやこしくなるので実例は省略します。

調べた結果が何かおかしいといったときは手元のSelenium~と参照している資料のSeleniumが同じものかを確認するといいかもしれません。（バージョンなど）

selenium builder

「GUIから操作してテストを書き出せる。」というものだったらしいのですが、
今はもうないです。

同様の機能を提供するSelenium IDEというプラグインもありますが
2019年1月の時点でスクリプトの書き出し機能はいません。

Selenium IDE は書き出しはできないとはいえ、自動化時にどのように動くかや、
web Driverで使用するターゲット名の確認ができる点で有用だとおもいます。
記録と再生のみならばこれだけでも十分かもしれません。

PhantomJS

非表示で実行されるブラウザ、非表示軽量のため本などでseleniumとセットで使われているのですがこちらもメンテナンス終了とのこと。
https://groups.google.com/forum/m/#!topic/phantomjs/9aI5d-LDuNE

Headless Chromeに切り替えるか、Headless FireFoxにするか、
もしくはメンテナンス終了ということを考慮しつつphantomjsを使うか等の判断がいります。

その他

環境設定時にプラグイン間のバージョンが整う必要があります。
バージョンがおかしいというエラーが出たら解消します。

久しぶりに触ると忘れていたりするのがヘッドレスブラウザの起動
テストの前にwebDriverTypeとして指定したブラウザを起動します。

最後に

GUIのテストは日々更新されるブラウザを対象とします。
環境にもまだまだ変化がありそうです。
その時に今回は待ったことで再びはまらないように気を付けたいと思います。

セレクタの詳細度の概要と（とデバッガ？）の話

コメントする

はじめに

株式会社イメージ・マジックの技術ブログ、今週の担当のsoenoです。

オフィスが移転し二週間がたちました。

文京区は神田に比べて子供の姿をよく見ます。

少なくとも神田でベビーカーを見た記憶がないのでしみじみと地区による差を感じています。（さすがに記憶にないだけですれ違ったりはしていたのだと思いますが。）

さて、今回はcssのセレクタの詳細度の概要（とデバッガ？）について書きます。

CSSが反映されないとき。

cssを触りだすと、反映してほしい指定が来ないことがあります。

（赤くなってほしいところが赤くならない等々。）

大体そういう時は

・その指定を反映させるための条件が足りていない。

・よその指定が反映したい指定を打ち消している。

あたりだったりします。

そんなときはCSSがimportantまみれになる前に要素の指定の方法を見直していきます。

状況の確認方法（chrome ディベロッパーツール）

選択中の要素にどんな指定がされているかは下記の手順で確認できます。

・調べたい要素を右クリック。
・出てきたメニューから検証を選択。
・ディベロッパーツールが要素を指定した状態で開きます。
（選択中の要素はelements内をクリックするなどで変更可能。）
・右のエリアのstyleの項目に表示されているのがその要素についているcssです。

※手順の記載の都合でchromeで書きましたが大体のブラウザで同様のことができます。

ディベロッパーツールで要素を選択しているのにかけたはずの指定が見つからないときはcssのリンクや指定で間違いがあるかもしれません。スペルの間違いや、ファイルのパス等そのほかの部分が違う可能性の方が高そうです。

指定した項目に打消し線（文字にかぶさる横線）が入っていて反映されないという場合。おそらく詳細度で何とかできる問題です。

重複した指定と詳細度の関係

cssではそれぞれ数値が割り振られており、それを合算した結果でcssで使われる指定が決まります。

割り振られている値を詳細度と呼びます。

ですので設定したい項目が何かに打ち消されている場合は打ち消している項目よりも反映させたい項目が詳細度が高くなるように指定すれば解決します。

厳密な指定がいる場合は詳細度の数値、計算方法について調べてみてください。

計算するサイトや、詳しいサイトありますのでいろいろ見てみるのがいいと思います。

また、厳密な計算が必要なほど込み入っているのであればスコープや設計を見直たほうが早いかもしれません。

要素の詳細度について

さて、以下詳細度が高い順に記述すると

1.important

記述例

css

.btn-red{
　　background:red !important;
}




2.htmlのタグに直接書かれるスタイル


記述例


html


<div style="background:red"></div>;



3.idにあてられたスタイル


記述例


html


<div id="red-btn"></div>;



css


#red-btn{
   background:red !important;
}



4.クラスへあてられたスタイル


記述例


html


<div class="red-btn"></div>;



css


.red-btn{
　　background:red !important;
}


5.その他


疑似要素などありますがこの辺りの衝突はあまり見ないのと、大体他のクラスにつけて記述することが多いと思いますので省略します。


尚、同じ詳細度の指定が複数個所にあった場合は後に読み込まれる方が優先されます。


一応優先度の反映のされ方をざっくり書くと


優先度が高いものが反映されますので、importantが赤といえば他が何を言っても赤です。


importantがいないときはタグに書かれたスタイルが優先されます。


importantの指定もタグの指定もなければidの指定が優先されます。


そのすべてがいないときはclass、classさえいないときはその他疑似要素等への指定が使われます。


ここまで把握したら反映させたい項目を邪魔している指定を見てみます。


詳細度が反映させたい要素より高いはずです。


自身の詳細度を高める、相手方の詳細度が不必要に高いときは下げるなどして調整すれば正しく反映されます。


終わり


詳細度についていろいろ書きましたが、厳密に調整しないといけない状況はなかなか大変なので設計で何とかできるようになりたいです。


補足（Chromeディベロッパーツール）


ディベロッパーツールのstyleではスタイルの左に表示されるチェックボックスのオンオフでスタイルの着脱ができます。

衝突している指定についてブラウザ上で相手側の指定をオフにして試してみることができます。

同じスタイルの指定が複数個所にされていて反映されない場合はディベロッパーツールであらかじめみることができます。

inputのtypeが”file”の時の選択エリアの話

コメントする

はじめに

株式会社イメージ・マジックの技術ブログ、今週の担当のsoenoです。

今朝の神田は雨でした。

技術が発達すると傘を差さずにぬれずに通勤なんてことも可能になるのでしょうか。

さて、今回は仕事中にはまったcssについてです。

というか、タイトル通り<input type=”file”>で指定したはずの選択エリアの話で、

指定したつもりのエリアと食い違うことがあるという話です。

前提

状況としては結構色々やらないと発生しないのでニッチな投稿となるのですが、

– <input type=”file”>を使用している。
– カスタマイズしている。<input>は非表示にして使用。
– ボタンエリアは結構狭め。

な感じで発生します。

挙動

ボタンの外を押してもイベントが発生する。

要素にボーダーを付けたりして調べてもそれらしきサイズの要素がない。

再現可能なコードはこんな感じ


//~略~
<style>
.uploadArea{
  position: relative;
  color: #fff;
  background: #2ab1e7;
  width: 30px;
  height: 30px;
}
.uploadBtn{
  position: relative;
  height: 100%;
  width: 100%;
  opacity: 0;
  cursor: pointer;
}
</style>

//~略~

<body>
 <div class="uploadArea">
  <label for="uploader">
   <input id="uploader" type="file" class="uploadBtn">
  </label>
 </div>
</body>

//~略~

解決法

opacityを１にしてみると何が起きているかすぐにわかります。

inputのタイプがfileの時はアップロード用のボタンがあるが、それがはみ出てしまうというのが今回の不具合の理由でした。

なので修正はuploadAreaのcssに overflow: hidden;を足すだけ。

わかってみるとショックなほど簡単なことなのですが、inputエリアのタイプがfileの時はボタンを持っている。というのを忘れていると、この範囲何？誰？みたいなことになります。

最初に疑ったのはz-indexだったり、opacity:0にした時点で見つけにくくなるわで、結構はまったので取り上げてみました。

開発サイドから見るバグ報告の話

コメントする

こんにちは株式会社イメージ・マジックのsoenoです。

私はフロントエンド側でバグを受け取る側にいます。
いざバグが上がってくると手一杯になり伝えられない報告について。
もらうと助かる報告とその理由などについて書いてみようかと思います。

まず不具合の発生時に報告を上げる側は以下のような思いを抱いているのではないかと思います。
・壊れているので直してほしい。
・クレーム来てるから早く動いてほしい。
・細かいことはわからないけどとにかく何とかして。

急いでほしい、早く結論が知りたい。
そんなときほど初期に上がる報告が重要です。
開発側で報告を受けたとき、いろいろと調べるポイントがあります。
素敵な報告をいただくと調べなくてはいけない箇所が減ったり、
うっすらと見当がついたり、もしくは重点的に確認するべき場所を決定できます。

ではもらってうれしい報告を手軽に書く方法について考えてみます。
あってほしい情報や、必要な項目について抜けなく上げるために
作文などでなじみのある５ｗ１ｈに照らし合わせて考えました。
５ｗ：　いつ、どこで、だれが、何を、どうした。
１ｈ：　どのように

報告時に書く５ｗ１ｈを言うと以下のようになります。

・いつ（When）
内容：バグ発生時刻（特にサーバー周りのバグの時に重要）
理由：記録を確認するときに膨大な情報の中から探す場合、時刻がわからないと探しきれないことがあります。

・どこで（Where）
内容：ネットワーク接続環境など。社内で接続しているかそれとも社外か。遅い回線ではないか。
理由：ネット回線のスピードによる挙動の場合そのスピードでないと再現しないことがあります。
対処する場所、対処可能な部署が違うこともあり得ます。

・だれが（Who）
内容：バグ発生時の環境、ブラウザ、ブラウザバージョン、端末(pc?smartphone?)、OS（windows?mac?linux?…）
理由：特定のブラウザのみで発生する動きがあるので、そのブラウザしか再現しないことがあります。

・なにを（What）
内容：ウェブでいうとどのページの(url等)どの要素に対して操作を行っていたか
理由：ページとどの要素かがはっきりしていると違うページの違う要素を延々調べなくて済むようになります。

・なぜ（Why）
内容：そもそも何のためにその操作をしたか。
理由：操作の意図ですが、想定した操作外での不具合の把握でしょうか。
バグ取りというよりはサイト改修、改善時に知っておきたいところです。

・どのように（How）
内容：バグ発生のための手順
理由：手元の環境で再現するかどうかはとても重要です。壊れていないものを直すためには
どうしたら壊れるのか、どこが壊れるかもしれないのかなど、上の５W総出で類推することになります。
特徴的な動作や、何か心当たりやひらめきがないと難しいということもあります。

追加でもう一つ5w1hでは足りなかった要素として”hope”を足します。

（英語的に正しいかの検証はしません。）

・どうなってほしかったか（Hope）
内容：正しく動いていたらどうなるか
理由：バグと仕様との判断と、一見正しく動いているように見える挙動の際に何が問題になっているかを特定します。

何か特殊な状態があればそれも追記してあるとなおいいです。
例として思いつくものを上げると
・同一画面を複数ブラウザで開いていた。
・ブラウザで戻るボタンを押してのフォーム入力。
等々

この報告を私が読む場合、下に書いた順番になります。
０、特殊な操作、状態の報告
１、どのように（How）
２、どうなってほしかったか（Hope）
３、なにを（What）
４、だれが（Who）
５、いつ（When）
６、どこで（Where）

順番は個人の手法、サーバー担当かフロント担当かで違ってくると思います。
特に抜けて困るのは１、２、３番。
サーバー側は加えて5番。（多分）

早く回答してほしい、今すぐ着手してほしい。
そういうときほど初期の報告が大切です。
そんなこと言ってもちゃんと書いても遅いじゃん。
という意見もあるかと思います。
ですが、ちゃんと書いていなければきっともっと遅かったはず！
というわけでもらってうれしい報告について書きました。

最後に、こちらの記事は一個人としての意見ですのでご注意ください。
フロント周りやってますのでサーバーあたりに抜けがあるのではないかと思います。
開発にもいろいろあります。自分のケースによりあうものを参考にするといいと思います。
（web上に既にきれいに書かれているものもあります。）