スイーツ（笑）と呼ばないで!!

私は、マシンをリカバリ(クリーンインストール)するのが好きだ。

大きな案件が終わった時とか、年齢が変わった時とか、いろいろなタイミングでリカバリをする。

そのタイミングで断捨離もできるし、何よりクリーンな状態からの再出発は気持ちが良い。

昨日も深夜に手元のMac Book Proをリカバリしていて、ふと昔学生時代に友人から聞いた話を思い出した。

大学1年生の頃、同じように遠く離れた地方から来ていた同学年の女の子がパソコンを入学祝いで買ってもらって来ていた。

その子の話では、パソコンを買ってすぐ、父親の指導で5回くらいリカバリーの訓練をつまされたらしい。

当時、彼女は、新品のマシンなのになぜわざわざリカバリをしなければならないのか、それも何度も何度もさせられるのか、本当に意味不明、ということでとても不満を持っていたようだ。

もともと父と娘の会話もあまり無いような家庭だったらしく、理由もあまり説明されないまま、パソコン好きな父親から強制的にやらさせた経験は、本当に苦痛以外の何物でもなかったんだろう。

でも、自分はその話を聞いたとき、なんて素晴らしい父親なんだと感動した。

パソコンは、キーボード操作やマウス操作ではOSは死ぬことがあっても、物理的に壊れることはほぼない、この復活の儀式さえ分かっていれば、何度でも蘇る。

だから、どんどん使え、使い倒してどんどん壊せ、そして何度でも蘇らせろ。

そういうことなんだと思う。

入学までの残り少ない時間、普段から会話もあまり無い娘に対して、
壊さないための細かい操作を教え込むのではなく、どんなに壊しても蘇らせられる方法だけを伝授した父親。

たくさん転べ、でも、心配するな、お前は転んでも自分の力で立ち上がる術を知っている。

その友達のお父さんの教育方針は今でも私の中に生きている。

初心者は、なるべく想定外のことが起こらないように正しい手順を覚えてそこからズレないようにしようと努力する。でも、正しい手順なんて何通りもあり覚えられるわけがない。

だから私は何かを指導するときにはよくこんな言葉を使う。

「大丈夫、それをやったからといって死ぬ人はいない」
「最悪のケースでも、xxxがoooなだけだ」


ま、たまには、滅びの呪文「バルス」みたいにもそれやっちゃーお終いよ、というのもあるけどね(笑)

[0回]

• 技術系の話題
• COMMENT：0

突然、個人的な話をするが、私は過去を振り返るのは嫌いだ。
ついでに言うと、3年以上先の未来について計画を立てるのも嫌いだ。

ただ、今流行りの真田丸など歴史ものは好きだし、そもそも昔は考古学者になりたいと思っていた時もある。また、将来世界はこうなっているかもしれないなぁ、と言ったような空想はするし、技術を採用するにあたって将来の見通しを立てたりはする。

前者と後者の違いは何かと言うと、前者は私個人の過去と未来の話で、後者はこの世界の過去と未来の話である。

それで、まず個人的なことで言えば、私は今しか見ない。仕事上、半年から1年先くらいまでは計画を立てるが、書いても1行程度の計画で、より現在に近づけば近づくほど段階的に詳細化されている。

逆に、この世界の話で言えば、私は現在と過去と両方を行ったり来たりして、現在の姿をより正確に理解しようと試みる。

つまり、現在を理解するために、過去を見るのである。

例えば、最近私はAWSについて強い関心を抱いている。

AWSには数十を超えるサービスがある。

初めてAWSの世界に足を踏み入れた時は、その数の多さと複雑さに圧倒された。

そういった一見複雑なものに出会った時には、

過去に戻ってみましょう!!

そうです、全てのものには始まりがあり、歴史があるのです。

昨日は初心にかえり、深夜自宅で一人Macの画面に張り付きながら、AWSのWhat's Newページを古い順にひたすら読んでいきました。

まず、どこまでさかのぼれるか。

https://aws.amazon.com/jp/about-aws/whats-new/2004/

このページが現存する最も古いものになります。

URLの2004を2003に変えるともう404ページになりますね。

AWSの最古のサービスと呼ばれるSQS(Simple Queue Service)の紹介文がありますね。beta testingと書いてあります。

2006年になるとおなじみのS3(Simple Storage Service)やEC2(Elastic Compute Cloud) が登場して来ます。まだベータだったりアメリカだけだったりしますが。

2009年になると、ヨーロッパでも利用可能になったり、CloudFront、ELB、EBSと言う見慣れたサービスや、インスタンスの契約でもスポットインスタンスなど多様化して来ます。この年に一気にAWSの世界が広がったのがよくわかります。

ここからは、毎年かなりの機能やサービスがリリースされていきます。一つ一つ挙げるとキリがないのでここでは割愛します。

2011年になると、

https://aws.amazon.com/jp/about-aws/whats-new/2011/

今まで英語だったページが日本語に切り替わります。

ついに、アジアパシフィック東京リージョンが利用可能になったのです。

その後も、毎年さまざなアップデートがあるのですが、そこも割愛します。

そして、最後の2016年のページに来ると、まずその数に圧倒されます。

かなり新しいサービスや機能が一気にリリースされていることがわかります。

つまり、もうあと数週間で終わるこの2016年はAWSの歴史の中では、かなりホットな時代なんですねー

時間は同じスピードで流れていたとしても、歴史というのは各年ごとに濃淡があります。動く時もあれば、全く変わらない時もあります。

そんな中、我々は、今、このAWSの歴史の中で一番熱い時代の真っ只中に生きているのです。

何という幸運でしょう!!


すみません、ちょっと熱くなりすぎましたね^^;;;;

今回、ブログではこんなことがあったよー、と出来事だけを追いましたが、このニュースリリースの概要を読むと、なぜのその機能やサービスが必要だったのか、どんな課題を解決するためにそれの機能やサービスをリリースしたのか、が読み取れます。

そうすると、ただ何の脈略もなくフラットなアイコンの羅列に見えたサービス一覧も、全く違ったように見えて来ます。

より、現状のサービスについて理解できるようになるのです。


ということで、もし人生で一見太刀打ちするのが困難な複雑な事象に出会ったら、可能な限り過去の歴史を追ってみましょう。どんなものも、シンプルでわかりやすいところから始まっているはずです。

蛇足ですが、私はLinuxのカーネルの最初のコミットのソースを読んだこともあります。OSというものが何であるのか、そもそも何を実現しようと、どんな仕組みで戦いを挑んだのか、よく理解できました。その延長線上で最新のカーネルのソースを読んだ時、だいぶ理解が進んだ記憶があります。


今日は、

困ったら、タイムトラベラーになったつもりで、現在と過去と両方を行き来したら良いよ、

という話でしたー

[0回]

• 技術系の話題
• COMMENT：0

昨日、知り合いのSEからDB設計で初めてMySQL使うらしくデータ型について相談された。

小数点以下1桁固定のカラムは何型?

と聞かれたので、(何を悩んでいるんだ?と心の中で思いながら)DECIMALとかNUMERICとかで良いんじゃない?と答えたら、

3.8+4.2=8

の8を8.0ではなく、8にしたいんだと、言われた。

さらには、文字列で持とうかな、とかブツブツ言ってた。

なんか、最近twitterで見かける、どこかの小学校の採点の話を思い出した。
(これとか、http://headlines.yahoo.co.jp/hl?a=20161129-00000081-it_nlab-sci)

ちなみに、

じゃ、結局どれが正解ですか?

という感じでこれだけの情報で判断しようとする人はDB設計者には向いていない。

これはケースによる。

例えば、文字列で持つのがナンセンスかというと、もう今後値の変更も計算もなく、単に表示にしか使われないのであれば、ある意味文字列で持てば最速で表現できるので悪くない。

後々、このカラムの値がSQLレベルでの計算に用いられて厳密に行きたいのであれば、やはり固定小数点型のDECIMALとかNUMERICが良いだろう。

例えば、整数部分の桁数がすごく大きくて、小数点以下なんて正直どうでも良いようなレベルの計算をするのであれば、浮動小数点型のFLOAT、DOUBLEでも良い。

他の視点として、そもそもSQLで計算するのか、例えばPHPとかで一度受け取って計算(つまり一度キャストされる可能性もある)あるいは表示するのか、でも話が違う。

これを、私は、DB設計者のバイアス、と呼ぶ。

DB設計では、DOAでデータにまず着目する、それに対して、設計者はバイアスをかけることで、現実のDB設計に落とし込む。そのバイアスをかけるためにはシステム全体の世界観を理解する必要がある。

だから、業務理解なくしてDB設計はできない。

弊社はいろんなスタイルのSEがいる。画面設計とか詳細仕様はプログラマにお任せするスタイルもあれば、その辺も細かく指示するSEもいる。

ただ、DB設計だけは、お客さんと直接話すSEが担当するというポリシーを採用している。会社としての理由はもしかすると別にあるかもしれないが、少なくとも私がそのポリシーに賛成する理由は、より良いシステム構築には上記のDB設計者のバイアスが必須だと考えるからである。

[0回]

• 設計
• COMMENT：0

例えば

http://www.recordchina.co.jp/a155573.html

こういうニュースを見た時、エンジニアである自分が真っ先にする行動は、

炊飯するのにどのくらいの電力が必要なのかググる

ということ。

そりゃダメに決まっているっしょ、という笑いながら否定するのは簡単だけど、

実際それがダメな理由が

・電力の問題なのか
・湯気や匂いなどの問題なのか
・倫理的な問題なのか
・マナー的な問題なのが
・法的な問題なのか
・単にそれまでそのようなことをやる人がいなかったという問題なのか

その他、いろいろ考えられる。

例えば、今回の場合は単に電力の問題なのだとすれば、いくらでも代替案が浮かぶ。

そして、そう言った行動に出る人がいるってことは、そこに需要があるということで、きちんと問題をクリアすれば、それは画期的なサービスにつながるかもしれない。

エンジニアにとっては、OKかNGか、という結論だけではなく、その理由をきちんと理解することが大事だと常々思う。

結論が理由とセットで頭に入っていれば、別の状況でその理由となる原因が異なっているとわかれば容易にそれまでとは真逆の結論を導き出すことができる。

技術論だけでなく、例えば、「戦争(殺人)はすべきか否か」とかって問題も、ダメならばなぜダメなのかしっかりとその理論構造を分析してみたり、普段からそういう訓練すると良いと思う。そういうトレーニングが、今目の前で直面している技術的な課題をクリアするのに案外役に立つものだ。

[0回]

• 技術系の話題
• COMMENT：0

Swift使ってiOSアプリを趣味で作成したりするが、
業務で使用するほどには詳しくない。

逆に、Webアプリは業務でよく作成する。

そんな中以下のような要件のお仕事の依頼が来た場合、こんな選択肢もありますよ、という話。

【要件】

1. iOS端末を使って業務アプリを構築したい。
2. タッチパネルの機能を有効に使いたい。
3. フルスクリーンで利用したい。
4. その業務アプリしか使用できないようにしたい。
5. メンテナンスが大変なのでSwiftとか使ったネイティヴアプリは嫌

さぁ、皆さんどうでしょうか、最後の要件5を読んで「ん?」となったのではないでしょうか?

こういうアプリ作成の時には、よく

「じゃー、ガワアプリだけ作って、中身は普通のHTMLとかJSとか使ったWebアプリにしましょー」

という話がでる。

でも、「ネイティブアプリは嫌」と言われるとそのソリューションは使えませんね。

そんな時の方法をこれからご紹介します。

まず、WebアプリをSPA(シングルページアプリケーション)で作成します。

そして、作成したWebアプリのヘッダーに

<meta name="apple-mobile-web-app-capable" content="yes">

<meta name="apple-mobile-web-app-status-bar-style" content="black">

こんな感じのmetaタグを設定します。

1行目がフルスクリーンにするための設定で、2行目はステータスバーの表示についての設定です。

これを設定したURLをSafariで開き、ブラウザの下にあるアイコンメニューの四角に上矢印的なアイコンをクリックしてホーム画面に追加を選択します。そうするとそのページへのショートカットがホーム画面に保存されます。

その際

<link rel="apple-touch-icon" href=“icon.png”>

こんなタグを仕込んでおくとアイコンが設定できるので、他のネイティヴアプリを見た目上全く違いが無くなりますね。

さあ、これで、ホーム画面上のアイコンを起動するとフルスクリーンのアプリが起動して如何にも業務アプリっぽくなりましたね。これで既にお客さんの要件のうち要件4を除いて全てクリアした状態となります。

要件4はどうしましょうか?

実は、上記の手順を踏んだことで、iOS内部における取り扱いにおいては、SafariでそのWebアプリを開いた時とは別の取り扱いになります。サーバサイドで取得されるUser AgentもSafariとは異なったりしますね。

少し回りくどい言い方をしましたが、これでいわゆるシングルアプリモードが使えるようになったということです。

設定>一般>アクセシビリティ>アクセスガイド

を開き、アクセスガイドの機能をオンにします。

パスコード設定のメニューより、シングルアプリモードを解除するためのパスコードやTouch IDの使用不使用が設定できます。

さあ準備は整いました。

ホーム画面から自作アプリのアイコンをクリックします。
フルスクリーンで立ち上がりましたね。
そこでホームボタンを3回押します。
これによりアクセスガイドが開始できます。
ちなわち、もう他のアプリに切り替えることは不可能になります。
(ちなみに、解除する際も同じくホームボタン3回押しでパスコード入れます)

さぁ、要件4も満たすことができましたね。

いかがだったでしょうか。

Swiftなど使ったiOSネイティヴアプリ構築のノウハウはない。でも、今ある技術でそれっぽく業務アプリを作りたい、特に端末固有の機能を使ったりする必要はないんだ、というあなた、早速今日からなんちゃってiOSアプリを作成してみましょー。

[0回]

• 技術系の話題
• COMMENT：0