忍者ブログ

スイーツ(笑)と呼ばないで!!

NEW ENTRY
04 2024/05 1 2 3 45 6 7 8 9 10 1112 13 14 15 16 17 1819 20 21 22 23 24 2526 27 28 29 30 31 06

05/05/16:58  [PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

12/21/11:55  ラピュタは何度でも蘇るさ(by ムスカ)


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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



拍手[0回]

PR

12/13/18:55  全てのものには歴史がある

突然、個人的な話をするが、私は過去を振り返るのは嫌いだ。
ついでに言うと、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回]

11/21/17:00  エンジニアの思考パターン

例えば

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

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

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

ということ。

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

実際それがダメな理由が

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

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

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

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

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

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

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



拍手[0回]

11/18/16:51  iOS端末を簡単に業務アプリ専用端末にする方法

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回]

10/28/19:18  ネット投票に関する情報技術上の大事な論点


基本的に、選挙の際には相当の理由がない限り投票に行く。

その日に予定が入りそうだなと思うときは、事前に不在者投票に行くことにしている。

そんな私ではあるが、やっぱりネットで投票出来れば便利なのに、という気持ちになることは多々ある。

そうしたらもっと投票率も上がるだろうに、と。

で、それをやらない理由は、個人情報流出とか、他の人のなりすまし投票とか、横に誰かが付いてて無理やり投票させられるのを阻止できない、とかを気にしているのかなー、と思っていた。

まぁ、最後に挙げた、横に誰かが付いていて・・というのはパッとは解決策が浮かばないけど、でもそれ以外の情報技術上の問題は、なんだかんだで最近は個人認証の技術や暗号化の技術も発達しているし、なんとかなるでしょ、って思ってた。

作ろうと思えばウチの会社でもそのシステムは作ることができる。

でも、この前勉強していて、

なるほど、これはちょっと厄介な問題だなー

と初めて理解したことがある。

今日はそれを紹介したい。

日本国憲法の第15条の最後の方に

「すべて選挙における投票の秘密は、これを侵してはならない。」

というのがある。

これが実は厄介な問題。

つまり、

投票行為については、個人をきちんと認証しその本人が間違いなく投票しているという事実を担保しなければならない、

その一方で、

誰が誰に投票したか、については、投票の秘密は守られなくてはならず、遡って個人を特定できてはならない、

ということ。

もし、国家権力が投票データやアクセスログから誰が誰に投票したかを知ることができるとしたら、時の権力者が自分たちに反対する有権者に対して粛清をすることも可能となる。今の平和な日本では考えにくいが(お隣の国では行われているが)、憲法とはそもそもそういった国家権力の暴走を牽制するためのものだ。

と言うことで、一見簡単そうに思えるネット投票システムも、結構面倒なことのようである。

ただ、いま世界中でこの個人認証・暗号化と匿名性の確保の二つを両立させるための研究が行われているらしいので、そのうち、ネット投票が実施される日も来るだろう。

一見簡単に思えるが行われていない背景には、実は自分が理解不足で知らないだけで複雑な問題があることもある、と言うお話でした。

拍手[0回]