HTML5とか勉強会「Webパフォーマンス」でLTしてきた。

html5j.connpass.com

これに行ってきました。LTもしました。時間配分をミスって失敗しました、ごめんなさい／(^o^)＼。

元々はLTをするつもりは全く無かったんですが、気づいた時には補欠が100人くらい居たので、勢いでLT枠に申し込みました。

話したこと

話した内容を箇条書きにすると、以下の通りです。

• 社内に勉強をする習慣を根付かせたかったので、行動してみた。
• その題材として「パフォーマンス」を選んだ。
• でも、周りとの温度差が半端なくて何回か心が折れた。アプローチを変えて再挑戦した。
• 組織には色々な人間がいて、皆が技術に燃えている訳ではないことに気づく。でも、何人かは熱い反応を返してくれる人がいて救われた。
• 他人に変えてもらうなんて甘えなので、自分が行動しろ。まずは自分を変えろ。

資料は以下に挙げてます。時間内に終わらなかったので、補足文章をあちこちに加えてます。

https://speakerdeck.com/rukiadia/zu-zhi-nipahuomansugai-shan-wogen-fu-kaserutiao-zhan

反省点

5分で収まるようにする努力をもっとしないといけない。話す内容はもっと絞るべきだった。

機会を見つけて、再挑戦します(ヽ´ω`)。

そして現在

色々頑張ってみたけど、会社を辞めようかなと考えている。

理由は「キャリアパスが描けなくなった」とか「一緒に働きたかったメンバーがいなくなってしまった」とか色々あるけど、 会社の方針に従う気が起きないのが大きい。

次回は事業会社に行こうと思ってるので、良い事業会社があったら教えてくれると嬉しいです。

最近、仕事をしている時に心がけている事

ここ半年近く、意識している事がいくつかある。主だった内容を挙げると以下のようになる。

• 作業をキリの悪い場面であえて止める
• コーヒーを飲む量を減らす
• こまめに席を立つ

それぞれの説明と、こんな事を意識しようと思い始めた経緯を書いていきます。

それぞれの説明

上で挙げた3つの行動の意味をちょこちょこ書いていきます。

作業をキリの悪い場面であえて止める

キリの悪い場面であえて作業を止めておくことで、昼食や会議から戻ってきた後に作業を再開しやすくするのが目的です。

キリの良い場面まで進めてしまうと、時間を置いた後にスムーズに作業に戻りづらくなってしまうんですよね。 昼食を食べつつ、途中まで進めていた実装を再考していると、より良い方法が思い浮かんだりもするので、習慣化して正解だなと個人的には考えています。

コーヒーを飲む量を減らす

コーヒーを飲みすぎると、頭が痛くなって効率がガタ落ちするので量を控えるようにした。ただそれだけの話です。 それだけの話なんですが、自分は珈琲大好き人間なので、量を減らすのはなかなかに大変でした・・。 一気に量を減らすのは現実的ではないので、週ごとに量を少しずつ削っていく計画を立てて地道に矯正しました。

今では、午後に1杯飲むくらいの量に落ち着いてます。 量を適度にしておけば、頭も冴えるし、トイレも近くならないので非常に良いです。

こまめに席を立つ

1時間半に1度くらいのペースで席を立つ。ただそれだけです。

集中するとモニターに顔を近づけて前のめりになってしまい、その姿勢を長時間続けて腰が痛くなる・・というお決まりのパターンから脱したかったというのが主な理由ですね。ヘルシープログラマーという本にも「長時間同じ姿勢でいるのはNG」的な記述があったので、それを真似しただけです。

厳密に時間を測っている訳ではなく、実装で詰まったりハマり始めたら席を立ち、水を片手に外に出てウロウロ散歩するというリズムを作っています。 そうしている内にパッと解決策が浮かぶ事もあるのでオススメです。 ※それでも解決策が浮かばなかったら、周りに相談しましょう！長時間悩んでるアピールをするのは時間の無駄です。

思い始めた経緯

「一丁前に他人に意見する前に、自分の不出来な点を直すのが筋かも」 そう思ったのがきっかけです。

去年の夏頃は、社内で荒れに荒れていた時期で上司に反発しまくっていました。

• 新人を雑に教育して案件に放り込む体制（「Java歴3年です」みたいなノリ）が糞だった
• 明確な方針や展望も示さずに「面白くしていこう！」とか宣う上の連中に嫌気がさした
• 一緒に働きたかった人間が辞めてしまって半ばヤケになっていた

こんな感じの環境の中で、内部のイケてない部分を指摘して改善していこうとして裁量を持っている人達に噛みつきまくってた訳です。 荒れに荒れていた中で思ったのが「まずは自分の不出来な点を直すか」という点でした。 「自分のイケてない部分を棚に上げて文句を言うのは筋を通ってない」という、割と精神論に基づく考えではあります。

敵を少し増やしてしまったし、社長には嫌われたっぽいけど、自分の働き方を見直す機会になってよかったなと思っています。 ※チームで開発する時に注意する点とかも色々やっているのですが、長くなりすぎるのでここでは書きません。

やってみて

障害対応とか、周りへのフォローとかが無ければ、ほぼ残業せずに帰ってる。 作業も徹底的に前倒しでやっているし、懸念点は先に潰し切っているので、遅れも全然無し。割と良い流れが出来てる。 改善出来る点は多分あると思うので、地道に良くして行こうと思う。

「最近定時で帰ってるけど、忙しくないんですか？」 とか宣う周りの声はガン無視しとけばいいです。

Frontrend Conferenceに参加してきた話

Frontrend Conference - A conference for front-end developer（2015年2月21日開催）

フロントエンド界隈のコミュニティとして名を馳せていたFrontrend。 その活動の締めくくりとして''Frontrend Conference''というイベントが開催されると聞いて参加しました。様々なセッションやLTを聞いた中で、「これは良かったな〜」とか「印象に残ったな〜」みたいな感想を書きます。

Pragmatic Front-end Developer: From Artisan to Expert

個人的に印象の残ったセッションその一です。 内容としては、フロントエンドエンジニアに求められるスキルセットにフォーカスを置いたお話でした。主に印象に残っている点を列挙すると、

• HTML/CSS/JSはメンテナンスしやすいとはいえない。
• 専門的な知識がなくても書けてしまう手軽さによって生じる問題。
• ソースをメンテナンスするためのツールの重要。
• 方法論やツールは多く存在するが、そもそもの問題が人と人の間にある。
• コーディングガイドラインやツールは運用され続ける事に意味がある。
• 人は「実際に見えるもの、動いているもの」に対しては意見が言いやすい。
• Webは変化するもの。変化に対して寛容であるべき。
• 作ったものに責任を持つ。
• ツールにはツール毎に解決しなければいけない問題がある。
• ツールは開発者の利便性を優先しがちである。
• 知識を増やすための時間を定常的に設ける。

モダンなツールやら世界的にメジャーなコーディングルールを入れたところで、運用する側の人々に問題があれば、結局問題の解決には結びつかないというのは強く感じました。ルールを決める等の行動を起こす前に、チーム内で現状を認識して、向かう方向を統一しておくことが下準備として重要なのかなと思います。

チームの規模が大きくなればなるほど、品質を保つためのルールが必要になると思いますが、そのルールで運用をやっていくのが無理になっている現状を目の当たりにしてる自分として頭の痛い話でした。

Reactive Programming in JavaScript

「リアクティブプログラミングとは何ぞや？」というテーマのセッション。

「リアクティブ」がそもそも何なのかについてをネットで検索すると玉石混交状態で「結局どういうことなの？？」みたいな感じになるので、The Reactive Manifestを読んでみましょう。
寝る前に読むと、気づいたら朝になったりしてることがあるので、日中の元気が残っている時に読むのがオススメです。

感想としては「雰囲気はわかったけど、これ自分で実際にやらないとすぐに頭から消えてくやつだ」って感じでした。少し前にMeteorというフレームワークを使ってみた経験があったので、理解度はそこそこ・・だった気がしてます。

セッションの内容はRxJSがメインだったのですが、発表者の方はBacon.jsが好きという事だったので、どっちを学んでみるか悩み中です。

Inline layout

CodeGridの高津戸さんのセッション。JS側の「ServiceWorker」のセッションも興味があったので悩んだのですが、CodeGridの著者の方の喋りを聞きたかったので、結局こちらを選択しました。

• font-size
• WindowsXPのサポート終了に伴って使う機会の増えた「display: inline-block」
• vertical-align
• line-height

普段良く使っているCSSを掘り下げた話でした。 「リストの点と文章が綺麗に揃わない」「チェックボックス、ラジオボタンがブラウザによってズレる」 といった誰もが遭遇したことのある現象。僕も今までゴリ押しで直して、そもそもの原因を深堀りすることはしていませんでした。

目新しい話ではないかもしれませんが、こういう細かい話も絶対に大事だと思うので聞いて良かったです。

JavaScriptテストの疑問、お答えします。

個人的に一番印象に残ったセッション。

JavaScriptのテストの手法は知ってても、普段は手動でUIテストをやっている事が多く、テストコードを書いたことはあまり無かったのでモヤモヤしていました。Javaならユニットテストをする前提でコードを書くのは普通かもしれないけど、JSはうーん・・？」みたいな感じです。

しかし、テスト界隈を遠目で見てると

• 「テストコードを書かない奴はギルティ」
• 「自動化最高！！ﾋｬｯﾎｰ！！」
• 「まだ手動テストで消耗してるの？？」

みたいな空気感が漂っている気がしていました。思い込みかもしれないですけど。
自動化する事自体を有難がっている風潮が少なからずあった気がして、正直あまり近寄りたくないと思っていたのは事実です。

ただ今回のセッションを聞いて、

• 不安を解消するためにテストをしている。
• 何のためのテストなのかを明確にして、そもそも必要がなければテストをやらないという選択肢もある。
• 部分的に自動化をするだけでも価値はある（テスト自体は手動でやるが、準備は自動化する）

といった辺りの話を聞けたので、大分スッキリした感じはします。 自分自身、テストという行為を必要以上に高尚なものだと思い込んでいた面もあったので、 そういった反省点を見つけるきっかけにもなり、非常に有意義な話が聞けたと思っています。

まとめ

CSSは辛くて糞だと思ってるけど、僕はCSSを愛してます。

スクロールバーの有無によって、ブラウザの画面が横にずれる話

今日の午前中、ずっとハマっていた内容をメモ。

今回対処する事象

ページ内容の高さが、ブラウザのウインドウの描画領域におさまらなくなった時 ページがスクロールバーの幅の分だけ横にズレる。

作ったもの

今回は下記のような画面を作った。

「説明文のタイトルがリストで並んでいて、リストをクリックすると詳細な説明文が表示される」 よくあるアコーディオンっぽい画面ですね。 ※上記のサンプルでは、青空文庫から適当に持ってきた文章を使っています

対処前の状態

サンプルの画面で説明文を表示していくと、ブラウザにスクロールバーが表示されたタイミングで 画面がｶｸｯと左にズレる。これがどうしても気になったので、対応策を調べてみました。

行った対処

今回はCSSの修正だけで対応を行うことにしました。

html {
    overflow-y: scroll;
}

「スクロールバーの表示有無で画面がズレるなら、 最初からスクロールバーの領域を表示しておけばいいじゃないか」という話です。

動きが気になる方は、上のJSFiddleで動きを試してみてください。

所感

jQueryのバグを真っ先に疑ってしまったせいで、午前の3時間をこいつの調査に使ってしまったのはここだけの話。泣けます。

MeteorでAndroidアプリが動かせるのかどうか試す

本記事はMeteor Advent Calendar 2014の14日目の記事になります。

ネタの完成度がイマイチだったので、Qiitaでは無く自分のブログに書かせて頂くことにしました。

今回のお題は「MeteorでAndroidアプリが作れるのかどうか試します」ということで、早速始めます。

Meteorとは？

AdventCalendarの初日担当の方が詳しく説明して下さっているので、ここでは簡単な説明だけします。一言でいうと「リアルタイムなWebアプリケーションフレームワーク」ということです。

フレームワーク内部にデータベース（MongoDB）が内包されており、DBが更新されたタイミングでアプリ画面が逐一切り替わる動きを簡単に実装できたりします。 一々ブラウザの更新を手動で行わなくてもいいのは地味に便利です。

詳細が気になる方はMeteor公式のチュートリアルをやってみると良いと思います。 「おお・・！これ・・いいかも！」ってなること請け合いです。

AdventCalendarを書こうと思ったキッカケ

https://www.meteor.com/blog/2014/09/15/meteor-092-iOS-Android-mobile-apps-phonegap-cordova

「よし試そう！」って思いました。

アプリを作って、ローカル環境で動かす

※ここからの操作はMac、Linuxで行うことを想定しています。 Windows環境はまだ公式でサポートが始まっていないようです・・。

1.ターミナルで以下のコマンドを実行する。

curl https://install.meteor.com | /bin/sh

2.インストールが完了したら、任意のディレクトリで以下のコマンドを実行。アプリのプロジェクトファイルが作成されます。

meteor create myapp

3.作成されたプロジェクトファイル内に移動し、以下のコマンドを実行。

meteor

ローカル環境でアプリが立ち上がっていることを確認してみましょう。http://localhost:3000/

こんな画面が立ち上がれば成功です。

アプリをサーバーにデプロイする

Meteorには公式から提供されているサーバー環境があり、そこに自分のアプリをデプロイ出来るようになっています。 （自前で用意する必要がなくて楽ですね）

1.プロジェクトディレクトリ直下で以下のコマンドを実行。

meteor deploy [任意のアプリ名].meteor.com

例：meteor deploy testapp.meteor.com

デプロイが完了したら、ブラウザで動きを確認してみましょう。 コンソールにデプロイ先のURLが表示されている筈です。

アプリを動かす

meteor公式のwikiとか見ながら、アプリが動かせるかやってみます。

1.AndroidSDKを入れる

※結構大きいサイズのファイルをDLすることになるので、テザリングでやるのは控えたほうが無難です。

meteor install-sdk android

2.Androidを動作対象に加える

ディレクトリ直下で以下のコマンドを実行

meteor add-platform android

Android SDKのライセンス条項が表示されるので、サッと目を通しておきつつ同意。

meteor list-platforms

と打って、androidが出ていればOKです。

3.エミュレータでアプリを動かす

（※実機で動かすことも可能ですが、今回はエミュレータで動作確認を行ってみます）

meteor run android

しばらく待つと・・

こんな感じでエミュレータ上で先程作ったアプリが動かせます。

あとがき

実機で動かすことも出来るんですが、ブログを書くタイミング実行したら何故かビルドに失敗してしまったため やむなくエミュレータで動かすことにしました。

あと、投稿がギリギリになってしまったのは非常に良くなかったなと反省してます。

Meteor Advent Calendar 2014 14日目の記事は以上です。 お疲れ様でした。

第16回Androidデ部で発表してきた

表題の通り、第16回Androidデ部で15分くらい発表をしてきました。今回は!Androidなテーマでやるということで、最近興味が湧いている「フォーム」の話でもしようかと思ってスピーカー枠に申し込んでみました。

発表テーマは「フォームについて考えてみた」で喋りました。
資料はこちら。使いづらいフォームについての考察や改善案をつらつらと語っています。

---

資料に書いてあることをくどくどと書いても仕方ないので、ここでは質問タイムで上がっていた話題について書きます。

質問内容：「使いやすいと感じたフォームってありました？」

ありました

あったのですが、僕が発表資料に画像を載せ損ねたせいでその場でお見せすることが出来なかったため、ここで紹介することにします。

---

一休

ホテルやレストランを予約出来るサービスを展開しているサイトなのですが、ここのレストラン予約フォームが良い感じだなーと思いました。実際の画面は以下になります。

使いやすいと感じた点

• 画面に余計な要素（関係の無いページヘのリンク、バナー等）が無いので入力に集中できる。
• お店に行く人数の内訳を入力すると、合計金額をリアルタイムで表示してくれる。幾らかかるか予約の段階で教えてもらえると安心できますよね。
• このサービスに登録した氏名を「代表者お名前」に自動で入れておいてくれる。
• 「次へ」ボタンが「戻る」ボタンよりも大きめになっていて、色も分けられている（押し間違えの防止）。

画面を無駄なく使ってて、よく考えられてるページだなと思える良いフォームだと思います。

ちなみにレストラン予約サービスを使うには会員登録が必要なんですが、その会員登録中もイラッとさせられることも無かったです。

---

以上。勉強会への参加レポと、発表の質問に対する回答でした。 ではまた。