Cocoa勉強会関西 第70回 に参加してきました

cocoa-kansai.connpass.com

直前まで参加できるかどうか怪しい状況でしたが、どうにか都合をつけることができました。
そして、どうせ参加するなら喋りたい！ということで、少しばかり喋ってきました。

喋った内容

Code Signing（コード署名）についての話でした。
どちらかといえばMac寄りな内容ですが、コード署名という作業が必要なのはiOSもMacも同じです。コード署名でトラブルが発生するのはアプリをリリースする直前であることが多いのですが、慌てて適当に操作して「何かよくわかんないけどもできちゃった」で終わりにしてしまう人は多いですし自分もそうでした。きちんと基礎を学ぶことで、再現性のある仕事をできるようになりたいと思い、このテーマを取り上げました。

他の方の発表

• iOS10でリモートプッシュ通知をできるだけ簡単に送る by STUDIO SHIN さん
• もうすぐはじまるATS必須化について by niwatakoさん
• 統計から見るアプリユーザーの姿 by niwatakoさん
• iOS10からこっそり使えるApp Extensionの「これが欲しかった」オプション by niwatakoさん
• Sparkle で Mac アプリを自動アップデート by kanizaさん

資料は冒頭にリンクを貼ったconnpassのページとかからリンクされている、かも。
全体的に、証明書だとか暗号化の話題の多い回でした。

次回は2017年2月11日の予定だそうです。

おまけ

codesign（コード署名）の綴りって、co-design（一緒にデザイン）と一緒なんですよね。今更ながら。

— T.Motooka (@t_motooka) 2016年12月3日

#SVG で スクラッチくじ を作ってみた

この記事は、SVG Advent Calendar 2016 の3日目の記事です。

SVG Advent Calendar には、このような記事も過去に投稿しています。

• clip と transform との組み合わせ - 職業プログラマの休日出勤
• 手入力のSVGでクリスマスツリーを描こう☆ - 職業プログラマの休日出勤
• マスター・オブ・円弧 #SVG - 職業プログラマの休日出勤

さて。
年末ということで、宝くじ や 占い、それに類するものに興味をお持ちの方も多いかと思います。私自身はそのようなものは好きではないのですが、くじ等を作る側（射幸心を煽る側）の人間として各種法令を遵守しながら立ち回ることは嫌いではありません。ここでは、くじを作る側の人間として、SVGでスクラッチくじを作る手法を紹介したいと思います。

まずは完成品のご紹介

さすがにブログ記事の中でJavaScriptを動作させるのはどうなんや…ということで、別のサイトにHTMLファイルを置くという形でご紹介いたします。

https://www.tmotooka.com/svg_scratch.html
このページにアクセスすると、銀色（実態は灰色ですが）の部分をマウス操作やタッチ操作で削ることができ、削ると隠されていたメッセージが表示されます。
「もう一度 くじ を引く」ボタンを押すと、銀色の覆いは元に戻り、中のメッセージはランダムで切り替わります。

こすったときに何が起きているのか？

まず初めに、SVG画像としては、銀色の覆いの向こう側には、あとで表示されることになるはずのテキストのメッセージが描かれています。その手前のレイヤに、銀色の長方形が描かれています。

JavaScript のコードでは mousedown mousemove touchstart touchmove などのイベントを捕捉し、マウスカーソルの位置やタッチ位置を把握しています。
その動いた軌跡を、ある程度の太さの線分で結び、その線分で描かれた領域だけ銀色の覆いが非表示にする、ということを mask という機能を使って実現しています。

mask とは

SVGで描かれている内容のうち、指定した領域を透明にすることができます。領域は、<mask>で囲まれた内側で、通常のSVGと同じように描くことで指定することができます。白く塗り潰された領域は描画され、黒く塗り潰された領域は透明になります。
mask の適用先では mask="url(#{mask要素のid})" という形で適用するべきマスクを指定します。

詳細な説明は、こちら。
Clipping, Masking and Compositing – SVG 1.1 (Second Edition)

銀色の覆いをカスタマイズしてみる

スクラッチの仕組みは、くじではなくプリペイドカードなどにおいても頻繁に用いられます。そのようなものの中には銀色の覆いに対して模様を描いていることもあります。
今回紹介したスクラッチくじでも、そのような模様を描くことが可能ですし、実は少し修正するだけで模様を登場させることが可能です。

ソースの中に path id="wave" と書かれた部分があると思います。この要素の stroke="none" を stroke="#000000" に変えることで、3本の黒い波線を表示させることが可能です。この path はmask適用している <g> タグの内側に居ますので、削る操作をしたとき、銀色の覆いと一緒に削れていきます。

何故これを作ったのか？

今年の8月に、名古屋のWeb界隈の皆様の集まり「WCAN」主催のイベント「WCAN mini 2016 Vol.2 SVG Maniax in NAGOYA」に参加してきました。
wcan.jp
このときの参加レポート： 名古屋のSVGイベントに参加してきました - 職業プログラマの休日出勤

参加レポートには書いていませんが、この懇親会においてどなたかが「SVGでスクラッチくじとか作れたら面白そうだよね」という発言をされていました。このとき私は十分な量のお酒を頂いていたので誰の発言だったのかを思い出すことができないのですが、ここで私は「実装するぞ！」という宣言をしたことだけは覚えています。それから忙しい日々が過ぎる中で「早く SVGスクラッチくじ を作りたい」という想いは募る一方でした。

このときの約束を果たすことができて、私は幸せです。

さいごに

紹介した SVGスクラッチくじ はMITライセンスにて利用許諾しています。皆さんも、許諾の範囲内でこれを生かし、世界中の多くの人を楽しませるような くじ を作って下さい。
楽しみにしています！

医療情報サイト WELQ（ウェルク）への自分自身のアクセス記録を調べる

医療情報のキュレーションサイト「WELQ」（ウェルク）について、適切でない情報が多く掲載され、かつ強力なSEO施策が実行されていた結果として検索結果の上位に食い込んでいた、とされています。
本日飛び込んできたニュースの中に、当該サイト、および、運営会社であるDeNAが他に運用している多くのキュレーションサイトが閉鎖された、というものがありました。
掲載されていたコンテンツにどれほど適切でない情報が掲載されていたのか、今となっては調べるのも面倒臭いですが、医療にそれほど詳しくない我々がそれらのサイトの情報を知らないうちに見ていて、知らないうちに鵜呑みにしている可能性も十分に考えられます。
そのような情報が脳内に存在していたとしても直ちに自分が死ぬ訳ではありませんが、どれほど自分がアクセスしていたのか、知っておいて損することは無いでしょう。

自分が問題のあるサイトにどれほどアクセスしていたのかは、ブラウザの履歴を辿って行けばわかります。しかし、全てを人間の目でチェックすることは極めて困難です。ならば、機械的に調べてみようではありませんか。
この記事では、例として、MacのFirefoxの履歴を調査する方法をご紹介します。

祝・はてなブログ5周年！（第一弾）

お題に沿って記事を投稿することでキャンペーンに応募できるタイプのやつです。
第一弾の応募締め切りは11月6日だけども、7日から始まるはずの第二弾のお題が未発表のようなので第一弾のお題で応募。上手く拾われるかな？？
とにかく、5周年おめでとうございます！

はてなブログ5周年ありがとうキャンペーンお題第1弾「はてなブロガーに5つの質問」

1.はてなブログを始めたきっかけは何ですか？

とあるイベントで、βリリースのときに「はてなブログできたよ」というお知らせを頂いたので。

2.ブログ名の由来を教えて！

一時期、休日出勤が多すぎて自宅で何も作れない時期が続いていて「これじゃいかん、何の技術も身につかない」と思い、ほんのわずかな土日技術調査の成果をブログに書き留めようと思いました。そのような経緯があって「休日出勤」という語を含めることにしました。

3.自分のブログで一番オススメの記事

一つ挙げろと言われても難しいものがありますが、これですかね。ウォーターフォール型開発を良いものにするためにはどうすれば良いか？と真面目に考察した記事です。
tmotooka.hatenablog.jp

4.はてなブログを書いていて良かったこと・気づいたこと

はてなダイアリー をそれなりの期間利用させて頂いていたこともあって、ずっと はてな記法 を使っていました。
最近は MarkDown 派の人も多いようですけども、自分にとっては便利だなー、使っててよかったなーと思ってます。

5.はてなブログに一言

今後ともよろしくお願いしますm(__)m

PHP処理中にHTTPサーバ再起動

PHPに限らず、Webアプリケーションを動かしているとどこかのタイミングでHTTPサーバを再起動する必要に迫られることがあります。
そのタイミングで誰もアクセスしていないという保証があるのなら話は簡単なのですが、その保証があることは、以前は極めて稀でした。近年では再起動すべきタイミングにおいては稼働中のサーバを一旦ロードバランサーから切り離すことで新規の HTTP Request を受け付けないようにし、実行中の処理が全て捌けてから再起動するといった運用も行われます。とは言え、再起動したときにどのような現象が起きるのかを知っておくことは無駄ではありません。何故なら、1秒を争うような状況に追い込まれてしまったときはロードバランサーの操作をせずに再起動することも考えられるからです。他にも知っておくと幸せになれる場面はあるでしょう。

このあたりの挙動に関して、自分の知識がn年前の状態のまま更新されていないことに気付いたので、ちょっと実験することにしました。
HTTPサーバ経由で実行された PHP のプログラムが、HTTPサーバ再起動（やそれに近い操作）によってどのように取り扱われるのか。試してみましょう。

PHP の処理

次のようなものを用意しました。それぞれの処理が実行されている途中で、再起動（など）を実施します。

• wait_with_sleeping.php : sleep関数で処理に時間がかかる場合
• wait_consuming_cpu_resource.php : PHPの処理でCPU資源を食い潰している場合
• wait_on_background.php : PHPのコードの中からバックグラウンドプロセスを立ち上げた場合

コードは GIST として公開しています。
PHPで時間のかかる処理を再現する。signalとか受け取ったときの挙動の確認。 · GitHub

検証環境

• AWS EC2 t2.nano (512MB RAM) 2台（Apache検証用 と NGINX検証用）
• Amazon Linux 2016.09
• Apache の場合
  • sudo yum install php70 で PHP 7.0.11 と Apache 2.4.23 をインストール
  • sudo service httpd start で Apache 起動
• NGINX の場合
  • sudo yum install php70 で PHP 7.0.11 と Apache 2.4.23 をインストール
  • sudo yum install php70-fpm で PHP-FPM をインストール
  • sudo yum install nginx で NGINX 1.10.1 をインストール
  • sudo service php-fpm start で PHP-FPM 起動
  • sudo service nginx start で NGINX 起動

検証結果

再起動方法	sleep	CPU資源を食う処理	バックグラウンド
sudo service httpd restart	死ぬ	死ぬ	死ぬ
sudo service httpd reload	死ぬ	死ぬ	死ぬ
sudo service httpd graceful	sleepが中断される	きちんと待ってくれる	死なない
sudo service nginx restart	死ぬ	死ぬ	死なない
sudo service nginx reload	きちんと待ってくれる	きちんと待ってくれる	死なない

ちなみに、PHP 5.6 でも同様の結果が得られました。
標準で用意されているサービス取り扱いのコマンドの範囲では、NGINX の方がより直感的な運用ができるかもしれません。signalを受け取ったら sleep がinterruptされる挙動を期待するようなプログラムを書いているのであれば Apache の方が良いでしょう。もっとも、この特性以外の要因の方が、HTTPサーバを選択する上で重要である場面は多いでしょう。

そう言えば以前、Apacheで運用しているサービスで sudo service httpd reload を流したところバックグラウンドの処理が死んでしまってビビったことがあるのを思い出しました。今だから言える。

追記＠2016.11.10

再起動方法	sleep	CPU資源を食う処理	バックグラウンド
sudo service php-fpm reload	死ぬ	死ぬ	死なない
sudo service php-fpm restart	死ぬ	死ぬ	死なない

例えば php.ini とかを変更する際は php-fpm を再起動することになるでしょう。その結果はご覧の通りです。やっぱり Apache の方がええんかな…？