サマータイムを導入しないにしても日時をすぐ文字列にする悪習をやめるべきではないか

「サマータイム導入はコンピュータシステム的に難あり」は本当か (1/2)

サマータイムは簡単、という記事があまりにあれな件 - novtanの日常

タイムゾーンを考慮した日時の扱いのベストプラクティス - エムスリーテックブログ

サマータイムの話。

結局のところ「データ」としてローカル日時を持ってしまっているシステムが多数あり、それらがどれくらい影響するかわからない、ということが皆が反対する理由。

対策としては結局3つ目のブログに書いてあることがすべてで、システムの内部では一貫してオフセット付きの日時またはUTCでデータを持つべきで、システム境界を超える場合も可能な限り(ユーザーに不要な手間が増えるといった例外を除き)オフセット付きで時刻を扱いましょう、というだけの話。

それで、「ローカル日時を持っているデータ」って十中八九文字列ですよね？2018/08/19 23:00とか、201808192300みたいな文字列ですよね。それをDBに入れたりファイルに書き出したりしてるってことですよね？そういうの、もうやめませんか？そもそもなんのためにそんな事するの？っていうお話です。

なぜわざわざローカル日時でデータをもつのか 

java:OffsetDateTime (Java Platform SE 8)

.NET:DateTimeOffset 構造体 (System)

db:timestamp with timezone

文字列書式:ISO 8601 - Wikipedia

上記あげた*1ように、各プログラム言語でも絶対日時を持って便利に使える型が用意されているし、文字列書式も国際規格があります（もちろん文字列⇔オブジェクトの変換も一意的に行える）。にもかかわらずどうしてオレオレ文字列書式を考案してシステムに組み込んでしまうのでしょうか。

違いまーす。コンピューターが用いているのは、「データ」と「システム時刻」です。データには時刻の関連項目がありますね。みなさんに一番身近なのはファイルの更新時刻とかですね。ブログの更新時間なんてのもデータで持ってますよね。表示されるでしょ。まさかこれをずっと「内部時間で刻んている」わけないよね。X時間前、という更新時刻は当然XX:XX時というデータと今の時刻の比較をしているので、システム時間をバーンと変えたらX時間前との相対関係が変わって表示変わっちゃいますよね。

サマータイムは簡単、という記事があまりにあれな件 - novtanの日常

説明のためかもしれませんが、さも当然のようにブログの更新時刻をXX:XXデータでもってると言い切ってるあたり、サマータイム云々関係なく、またレガシーシステム云々も関係なく、日時を文字列で持つのが当然という意識が蔓延してることを示してますよね・・・（というかこの説明に関してはいろいろ・・・）

日本国内限定のシステムだから201808192300って書式のほうが誰が見てもわかりやすいから？

とはいえ連携するシステムやクラウドサービスなど、まともなシステムは絶対日時で日時表現してくるのであっちこっちでオレオレ書式に変換しなければいけませんよね？それに、文字列書式のままでは時刻演算(n日足すとかn時間足すとか)が困難なので、その度にParse/Serializeしなきゃなりませんよね。

正直これまわりでプログラマーもどきが「なんだかわからないけど9時間ずれるんです」とか言われたの1度や2度ではないのです。いったいなんのために確立した形式があるのにオレオレ方式を考案してバグや混乱を生み出すのでしょうか。

諸悪の根源は「ともかくわかりやすいから文字列にする」という風潮や単なる昔からの流れであると思われ、そういうわけのわからない悪習はもうやめてほしいと思うのですがいかがでしょうか。

おまけ 

中小企業向けの会計ソフトを手がけるＩＴベンチャー「ｆｒｅｅｅ（フリー）」（東京）の社内ＳＮＳでは、政府のサマータイム検討方針が報じられた６日、エンジニアや営業担当者らから疑問を投げかける投稿が相次いだ。

(中略)

　エンジニアの浅越光一さんは「対応に１カ月かかるのか、半年かかるのか、やってみないとわからない。その対応にかける時間があれば、新サービスの開発がどれほどできるかと思うと、もったいない……」とため息をつく。

サマータイム、ＩＴ業界に拒絶反応 よみがえる苦い記憶：朝日新聞デジタル

レガシーシステムを多数抱える会社ならともかく、さすがに2012年創業の会社で、海外進出をめざしてるクラウドサービスの会社がこの感じはかなりイメージダウンだとおもうのですがいかがでしょうか（好意的にみれば自社サービスは大丈夫で連携システムのつなぎを心配していると取れなくもないですが）

*1:ここにあげた仕様は比較的新しいものが多いが、しかしコンピューターの日時表現の基本は絶対日時であるUNIX timeであり、伝統的なプログラミング言語の日時型はそのラッパーなので、古い言語であっても絶対的な日時を保持するのはそれほど難しくない

ウォーターフォール型開発を教科書通りやると失敗する

常識かと思ってましたが、業界人であっても開発経験のない人には伝わらないことが多いので、書きます。

なお、ウォーターフォール型といっても明確な定義があるわけではないので、ありがちな以下のモデルを題材にします。

via 開発プロセスの基本を学ぶ | 日経 xTECH（クロステック）

なぜ失敗するか

ウォーターフォールの各フェーズの作業内容や成果物を上記のように定義すると、非常にわかりやすいです。が、失敗します*1。

要件定義/外部設計は、客がこう言っていた/客が言ってることを実現する画面はこんなのだ、という形で簡単に進んで、内部設計段階で詰まります。なぜなら、外部設計成果の実現可能性を検証していないから。

• ある画面と別の画面との処理内容がどうやっても競合する
• 画面表示に必要なデータを抽出できない

こういう問題が噴出します。そしてそもそもどういう前提で外部仕様作ったんだよ上流は、というネットでよく聞く上流対下請けの構図になります。

単純な話です。

*1:外部設計や内部設計は母数を要員数で割って、1日あたりの記載数かなんかを成果指標にしてスケジューリングする、といったプロジェクト管理をしているとこの時点で即炎上です

FaceIDに対する情緒的なクレーム

iPhone Xをゲットして約一ヶ月が経ちます。

ウリの一つであったFaceID(顔認証)も、前評判や各所でのレビューにもある通り、爆速で認証できていてすごいなと感じています。見たときにはもうすでに認証されている、っていう話もまさにそんな感じ。メガネをしてても大丈夫だし、暗くても大丈夫だし、概ね認識率はかなり高いという印象を持っています。

ただ、寝起きとかは認証がされにくいんです。まあ考えてみれば当たり前のことなんですけど、布団で顔の一部が隠れてたり、頬に腕を当ててたりするのでフェイスラインが見えないんで認証できないんでしょうね。マスクをしてると認証通りにくいともいうし、妥当なのかなと思います。

そんなふうに、理屈はよく分かるし理解もして納得もしているのですが、でも、それでもですね、顔認証に失敗すると腹が立つのです。ものすごく腹が立つのです。

おい、昼間はあんな爆速で見た瞬間に認証OKだったのに、たかが布団のせいでだめになるのかよ。そんな程度の気持ちだったのかよ！的な気分になって腹が立つのです。

まあでも、布団のせいだよなとおもって、ちゃんと顔をしっかり見えるようにして、iPhoneと向き合います。でもやっぱり顔認証に失敗します。

FaceIDもTouchID(指紋認証)も、何度か認証に失敗すると安全のためパスコード入力モードに移行するという仕様が発動するからです。よからぬことを企むひとを排除するという意図で、理にかなった仕様だと思います。とても良く理解しています。

でもめっちゃ腹が立つのです。わざわざ顔を見えるようにしてやったのに見もしないで不審人物扱いかよ！的な気分になって腹が立つのです。

TouchIDのときも認証失敗してパスコード認証モードに移行することはありましたが、そこまで気になりませんでした。ホームボタンに指を当てるという行為と画面をタップしてパスコード入力するという行為が近いからでしょうか。

一方、FaceIDの場合はとても腹が立つのです。わざわざ見てやったのに、結局押させるのかよ。見るのと押すのじゃ大違いじゃねーか！的な気分になって腹が立つのです。結局見てロックを解除したあとはタップするなり何なりして画面を触ることになるので、冷静に考えるとたいして手間や操作感は変わらないのですが、それでも腹が立つのです。理屈ではないのです。

連続で認証失敗→パスコード認証モードに移行、の話は他にも腹が立つ話があります。

iPhoneを手に持って歩いてるときなど、なにかの拍子(傾けてロック解除機能とかの影響が大きいのかな？)に画面がONになって、いつの間にか認証失敗を繰り返した影響で、画面を見た瞬間にパスコード認証モードになっていることがまあまああるのです。

理屈としては今書いたとおりなのでしょう。挙動としては正しいのでしょう。それはよくわかっているのですが腹が立つのです。お前は一体、街の雑踏のどの部分をオレと認識したのか！オレはそんな雑踏と見間違えるような顔なのか？的な気分になって腹が立つのです。

iPhone Xはまだもの珍しいので「ちょっと見せて」的な感じでよく触られます。で、なんか画面をこっちに向けて認証させて中身を見ようとしてくる輩も現れるのです。余談ですが、こういう人ほんとウザいですよね。

ただ、FaceIDには「注視が必要」というオプションがあります。顔を認識しただけでなくて、ちゃんとカメラの方を見ているかどうかを判定して、見てるときだけロックを解除する、って機能です。

このことをよく知っているわたくしは、そのウザい輩に画面を向けられたときも目を伏して決してカメラを見ないように気をつけます。

なのに、認証されるのです！とても腹が立つのです。見てねえじゃねえか！絶対見てねえじゃねえか！なんでわかってくれねえんだ！的な気分になって、とても腹が立つのです。

この注視機能もまた腹立ちの種で、iPhoneを机においてる段階で画面オンにして見つめると、結構失敗します。でも、なんで失敗したのかわからないのです。FaceIDの視野角を確認するすべがないので一部しか顔が映ってないから失敗したのか、注視してないと判断されたのか、よくわからなくて腹が立つのです。

持ち上げるのがめんどくさいので机においたまま認証させようとしてるのに、なにが悪いのかわからず認証に失敗するので腹が立つのです。そして、しょうがないなあと持ち上げたころにはまたパスコード認証モードになっていて、さらに腹が立つのです。

そうそう、視野角といえば、画面が横向きのときに顔認証が行えないことも腹が立つのです。いやいや、オレ、横になったくらいで誰だかわかんないような顔なの？的な気分になって腹が立つのです。

まとめ

腹が立つシリーズをいくつかお伝えしましが、いかがでしょうか。理屈はわかっているのに腹が立つ、という意味で「情緒的」というタイトルをつけさせていただきました。

興味深いのは、TouchID(指紋認証)とFaceIDはほぼおなじ挙動であるのに、TouchIDではこのような気持ちにはならないことです。それと、FaceIDが失敗すると「お前なあ！」的な、相手が人であるかのように感情を揺さぶられます。

思うに、顔がパーソナリティの代表であることが大きく関係してるのでしょう。

アイドルの追っかけじゃないですけど、顔を認識してもらえるのは嬉しいことです。顔を覚えてもらえることは自分を認めてもらえてるという実感の第一歩です。顔を突き合わせることはコミュニケーションの基本です。このへんが、人生生きてきても他人との違いなんて全く意識しないし、人と見せ合うこともないような指紋との違いです。

そういうパーソナリティの代表である「顔」を使って認証するだのしないだのって機能をつけるにあたっては、もう少しセンシティブに考えるべきではなかったのでしょうか。

ご査収くださいませ。

おまけ

スマートスピーカーがブームですが、Siriを始めとして、音声認識が自分を汲み取ってくれないときも腹が立つのです。

ヘイ！シリ！

ヘイ！！！ヘイ！！！シリ！！！

ヘイ！ヘイ！ヘイ！バーカ！

というようにキーワードなんて忘れるくらい腹が立つのです。機会があればこのシリーズも是非ご査収いただければとおもいます。

aiboベーシックプランという名称には風情がない

新aiboが発表されました。本体が20万弱で、月額料金（要はクラウド運営費）が3000円弱。そうなんですか。高いかなーとも思うけどクラウド側に主体があるPS Nowが2500円だから、まあそういうもんなのかなあとも思います。

で、問題なのはその月額料金の名称が「aiboベーシックプラン」であること。

新型aiboをソニーが発表。自ら好奇心を持った、生活のパートナーとなる犬型ロボット - Engadget 日本版

名称は「ご飯代」とかにしてほしい。“aiboベーシックプラン”

2017/11/01 13:06

新型aiboをソニーが発表。自ら好奇心を持った、生活のパートナーとなる犬型ロボット - Engadget 日本版

• [趣味]
• [おっさんほいほい]
• [ソニー]

吹きあがるコレジャナイ感＆「ただし使用には別途「aiboベーシックプラン」への加入が必要」っていうまるでスマホ感覚。今も続く熱烈なアイボ信者のほとんどが高齢者だと分かっていての鬼畜の所業かしら

2017/11/01 12:19 

AIBOベーシックプランとか言われると携帯電話感が出てしまうのでドッグフードの缶詰（フタを開けるとQRコードがプリントしてある）を毎月買ってくるみたいな方が風情があるのではないか

— 柞刈湯葉（イスカリユバ） (@yubais) 2017年11月1日

それな。ほんとそれ。まさにそれ。

どうしてこんなスマホプランみたいな名称にしてしまったのか。どうして「生き物のお世話」を感じさせる名称にできなかったのか。ハード面ではメカメカしい外観から本物の犬のような外観に変更したのに、ソフト面でなぜ電化製品のようなプラン名をつけてしまったのか。ちぐはぐの見本のようなお話です。

　スマートスピーカーが注目される中で、人との対話という点にも質問が及んだが、「企画段階で揉めたが、aiboは犬型のロボット。実は先代は犬型と呼んでなかったのですが……。今回は明確に犬を想定して作ったので、人の言葉は話さない。ただ音声は認識している。また、別の製品では、話すというインタラクションもありえる」とした。なお、“鳴く”機能は備えている。

via ソニーのロボット犬「aibo」が復活! 心のつながりをもつエンタメロボ。19.8万円 - AV Watch

スマートスピーカーじゃないんでしょ？犬なんでしょ？犬であることが大事なんでしょ？そこわかってて、わざわざ人の言葉を話さないようにするってとこまで考慮して丁寧に企画を進めてたはずなのになぜ・・・。

プラン名なんて単に言葉尻だけの問題なのですが、世界観というものは作り上げるのは苦労するのに、言葉尻だけで簡単に壊れてしまうものなのです。

犬っぽい外観に似せて、なんちゃらアクチュエーターで犬っぽい動きを再現させて、演出のために人間の言葉は話さないようにして、クラウドと連携して“人に寄り添う”を実現して、っていう苦労をしてやっと作り上げた世界観がプラン名の言葉尻1つでぶっ飛んでしまう。

結局、プロダクトに対してどういうイメージを持つかは、どういう世界観を提供しているかによるところが大きいですよね。世界観が、風情とか情緒とかそういう言葉で表現できる。良いプロダクトには良い世界観があって、すなわち風情がある。aiboベーシックプランという名称は世界観をぶち壊していて、すなわち風情がない。プロダクトの良し悪しを風情のあるなしで語るっていうのは面白いのではないかと思います。そこに風情はあるのかい？ってね。

先の引用文章からすると、製品が完成して、周辺整える段階まではちゃんと気をつけていたことが伺えますが、最後の詰めでなにか行き違いがあったのでしょうか。11/1にワンワンワンで発表です、なんてことを考える前にやることがあったのではないかな、と悲しい気分になりました。

おまけ

「ユーザーが使っている環境をバックアップできる。買い替えた場合は、新しいaiboにそれまでのデータをダウンロードして引き継ぐこともできる」という。

via ソニーのロボット犬「aibo」が復活! 心のつながりをもつエンタメロボ。19.8万円 - AV Watch

いやだから。ダウンロードて。風情を大事にしてほしいです。 

はてなブックマークiOSアプリはマテリアルデザインの悪い見本

はてなブックマークのiOSアプリを真面目に使ってみたらひどい出来だったので書きます。

基本構造

まずはアプリの基本構造をおさらいします。このアプリは大きな画面構成として

• メイン（様々なエントリー一覧）
• フィード
• マイページ

の3つからなっています。

はてなブログのコメント承認制が許されるのは小学生までだよねーキャハハ

つい1日くらい前からブログのコメントを承認制にしたので思うことを書きます。

わたしがブログをやる大きな動機として、主張に対して世の中の意見、反応を広く募りたいというのがありまして。そんなわけでコメント欄は匿名可かつ管理者承認不要、つまり誰でもかけて書いたらすぐ反映されるモードで運用してきました。 

過去に大炎上してコメントが何百件もついてコメント欄で争いが起きる事態wでもそのままだったのですが、でもよくよく考えるとコメント欄って自分の運営ポリシーとあんまあってないなあと思い始めまして、それについて書きます。

なお、コメントに対する基本ポリシーは以下の感じで。

コメントで知りたいのはご意見なんですかってことと、考えの相違点がどこなんですかってことだけなんだな。
それがわかれば終わりというか、そういう考えなんだ自分とは違うけど面白いな。お互い違うことがわかってよかったですねと。

— りんご4個分 (@uxlayman) 2017年2月14日

特に返答することがない

だいたいこれなんですけどね。とても有意義で、意図がよくわかって、記事とともにみんなの目に触れるべきご意見だ、本当にありがとうございますとは思うけど、それ故にこちらから特に返答することがない、という。

いいね！だけつけたい感じのやつ。

終わらない/始まらない

基本ポリシーに書いたように、「つまりなんなの？」「どこが相違点なの？」がわかればわたしとしては終わりなんですが、書いてる方はもちろん一家言あって書きこんでるわけなんで、終わってからが長いのです。

それからまあ、なにを主張してるのかわからないとか、記事と関係なさすぎて困るとかで、はじまらないパターンもあります。

そのあたりのやりとりに興味がなくて飽きちゃうんですよね。

熱量が違う

わたしは賛否はともかくだいたい記事の中で話を完結できるように書いてるつもりなので、コメントに書く内容も本文に書いてある内容をかいつまんで繰り返す、となりがちで。それでも納得いただけないなら本文の書き方が悪かったのかなー、と思うくらいで。

「議論したい」「意見を認めさせてやる」的なコメントと熱量が釣り合わないのです。

せまい

単純にせまいですよね、はてなブログのコメント記入欄。それにあそこに長文書くの嫌いなんですよね。長く書いてもみにくいし。かといって説明しきるには足りないし。そもそも長文なら新規記事書けばいいわけだし。

それとなにげにあそこの欄、はてな記法が有効になっちゃうんですよ。2回改行入れないと大きく改行されないとか。めんどくさいよねえ。

承認制にした結果ですけど、とりあえずすこぶる快調です。「通りすがり」みたいな名前で延々と粘着し続けるマン(何回通りすがるんだよw)とかは完全ブロックできますし。

でもそもそもコメント欄自体いらないかなあとも思いはじめてます。ブコメもツイッターもあるし。長い反論あるんならブログでも増田でも書いた方がお互い幸せなんじゃないかなあと。でもよくある揉め事みたいにブログ記事合戦みたくなるのもどうかと思いますがw

他の人々

読者登録してるブログをざっとみてみたら

5 承認制
13 制限なし
3 コメント欄なし

読者ブログ新しい順にみてみたらこんなんだった。ノーガードがおおいや

— りんご4個分 (@uxlayman) 2017年2月14日

こんなんでした。あんまりジャンルによる傾向の違いは見られなかったですね。好き好きというか。

とても印象的だったのが、一部で炎上ブロガーとして称されてるチルドさん。

承認制だったんだけど、チルドさんほとんどコメントに返信してないの*1。これはこれでいいよなあと。興味もないのに返信するから余計火に油をそそぐってのもあるだろうし。ご自由に書いてくださいませというのはポリシーとしていいかも。

まあしばらくはスルーしたり★だけつけたりいろいろ試行錯誤するかもですが、書いていただいて感謝の気持ちは忘れていませんのであたたかく見守ってくださいませ。

*1:ほんとは"一切"って書きたかったけどしてるのもあったw

SIerの下請け開発者ってレベル低すぎない？

ネット上ではSIer批判＝技術のことをわかっておらずプログラムも書けずPMも出来ない非効率でダメダメな上流工程と、 人月単位での労働力提供という業界の慣習に縛られ、持ち前の優秀な技術力・知識を生かせず非効率な作業を強いられているかわいそうな下請け開発者、という構図が確立されているように思います。

自分が関わるまでは、まあそうなんだろうなと思っていましたが、しかし実際にそういう立場のひとと関わりをもつにつれて、どうもそうではないのではないかと思うようになりました。このあたりの実情を書いていこうと思います。

なお、先に言っておきますが本記事で書くことは、上流工程がどうのとか、業界の多重請け負い構造がどうのとか、給料が安くてとか労働条件が過酷でとか、そういう話とは全く関係がなく、純粋にプログラミングのスキルの話だけです。

対象はおもに詳細設計、実装UTだと思ってもらえれば。外部仕様が決まった状態で、それを満たすそれぞれのモジュールを、必要であれば詳細化した上で実装して単体テストする、っていう。

自分の作ったものの仕様を説明できない

言ってみれば問題は全てはこれに尽きるのですが。

自分の作ったもの、たとえばメソッドなりクラスなりなんなりを作ったとして、その仕様を説明できないという人がかなりいます。

代わりに、延々と自分がコーディングした記述の説明をしてきます。

どんなプログラムであれ、特定の入力状態においてなんらかの処理を実行させて出力状態を得る、という構造は変わらないはずです。それは純粋関数なら引数と戻り値だし、オブジェクトならメッセージとオブジェクト状態だし、WebURL呼び出しならURL＋パラメータとHTML(テキスト)だし、といった具合に、ジャンルによって表現はかわりますがその本質は変わりません。