プログラミングと料理の共通点は意外に多いのでは？
こんばんは。昨日の続きになります。昨日つらつらと記事を書いた後でふと思ったことがあります。
「プログラミングの手順は料理の手順と似ている点が多いんじゃないだろうか？」と。
昨日の記事はこちらです。
karasuma-kitaoji.hatenablog.com
この中でプログラミングに関する一連の流れを書き出してみました。以下の通りです。
- まず、最終目的（何をやりたいか）を書き出す
- そのために何が必要かをとりあえず書き出す
- すべき内容をパーツ毎に細かく分割してみる
- 全体の流れを考えて、大枠を作ってみる
- 3.で作ったパーツを仮に当てはめてみる
- 流れにおかしな点がないかを確認してみる
- 実際に動かしてみる
- エラーメッセージを基に該当箇所を調べる
- 手直しする
- 7.に戻る
- 正常に動作するまで繰り返す
- 動作確認完了
こうして眺めていて気づいたのですが、「実際に料理をする手順に酷似しているんじゃないか？」と。
まぁ、エラーメッセージは吐きませんがｗ
でも、大枠はそうだと思うんですね。「何をやりたいか」は「何を作りたいか」に相当しますし、「必要なものを書き出す」というのは、「必要な食材を洗い出す」ということに相当します。
作業分割やおおよその流れを押さえるのも似てますよね。
なので、ここからはあくまで個人的意見ですが、こんなことが言えるのではないかと。
- 料理好きな人はプログラミングの素養があるのでは？
- プログラミングが得意な人は料理の素養があるのでは？
- 家庭科の先生こそプログラミングを教えるのに向いているのでは？
なんとなくそんな気がしてきたんですよね。一見何の接点もない全く別の分野ですが、取り組み方が似てますので、どちらかが得意な人は短期間でもう一方の腕を一気に上げられそうです。
そんなことを感じた日曜日でした。シェルスクリプトの具体的な例の話は後日してみたいと思います。<(_ _)>
プログラミング喰わず嫌いから脱出するヒントみたいなもの
こんばんは。今回はちょっと緩めのネタですがお付き合い下さい。
最近、シェルスクリプトを書く機会が増えてまして。正確には、他人が書いたシェルスクリプトを手直ししているといったところでしょうか。
追い込まれるとなんとか出来るものですよね
私自身、プログラミング（シェルスクリプトですけど、ここでは広い意味での「プログラミング」としてお話を進めます）自体はそんなに得意ではないんです。それでも、ネットワーク関係の仕事をしていると、単純作業を自動化したいということはあります。なので、避けて通れない場面もあるんですよね。
私自身の話で恐縮ですが、「克服」とまでは行きませんが、どうにかこうにか対処出来た経験に基づいて書いてみようかと思います。数年後に小学校でプログラミング教育が始まります。「どうやってプログラミングを克服すればいいのだろう…」と悩んでいる小学校の先生方のお役に少しでも立てれば…という想定で書いてみます。
（具体的な対象者を設定した方が書きやすいかと思いました。もちろん、小学校の先生に限りません。「どうもプログラミングが苦手だ」という方の一助になればと）
ざっと一連の流れを追ってみました
自分自身でやってみたことをつらつらと書き出してみました。
- まず、最終目的（何をやりたいか）を書き出す
- そのために何が必要かをとりあえず書き出す
- すべき内容をパーツ毎に細かく分割してみる
- 全体の流れを考えて、大枠を作ってみる
- 3.で作ったパーツを仮に当てはめてみる
- 流れにおかしな点がないかを確認してみる
- 実際に動かしてみる
- エラーメッセージを基に該当箇所を調べる
- 手直しする
- 7.に戻る
- 正常に動作するまで繰り返す
- 動作確認完了
といった流れになろうかと思います。別にプログラミングだからといって特殊なことはないんじゃないかと思えてきました。何をしたいのかをはっきりさせて、おおよその流れを理解してから設計図を書いてみる。設計図に基づいて個々の部品（モジュール）を作る。個々の部品がちゃんと動いたら、その部品をどの順番で組み合わせればいいかを確認する。そして、継ぎ目のチェックを行い、ひたすらテスト。
「とりあえず設計図を描く」から始めてみる
そんな感じだと思います。プログラミングに苦手意識を持ってしまうのは、案外1.の部分で躓くケースが多いんじゃないかと勝手に推測してます。「何をしたいのか？」ということを書き出してみましょう。そうすると、「そのためには何が必要か？」「そのためには何をしないといけないか？」が見えてくるはずです。
プログラミング恐れるに足らず。まずはやってみましょう！(^^;;
Googleが誤経路制御情報を送信した件の続きについて
こんばんは。Googleが誤経路制御情報を流してしまい、OCNやKDDIがとばっちりで通信障害を引き起こした問題についての考察が出ていましたので、取り上げます。
こちらはITproの記事です。
記事でも書かれているように、確かに海外で同規模の障害が発生したというような話は特に出ていませんでした。なぜ日本、特にOCNとKDDIに集中したのか？という疑問が新たに出てきます。そのあたりに関して、分かりやすく解説されています。
本来経由しなくていいパケットまで「OCNへの最短経路はベライゾンからGoogleへ向かうルートだ」という大量の誤経路制御情報を掴んでしまったルータによって迂回させられたというのが真相のようです。大回りすることで遅延やパケットロスが発生してしまったと解説されています。
これ以外にも大量の経路制御情報を掴まされてしまった各ISPのルータが経路再計算のために大幅にリソースを消費してしまい、まともに機能しなくなってしまったことで通信障害が発生したことが真相のようです。KDDIの場合はGoogleからベライゾンに送られてきた経路制御情報が大量に降ってきたことで、配下のISPにも通信障害が発生したとあります。
そして、こちらは著書「インターネットのカタチ」で話題になっているあきみちさんのブログです。オレゴン大学が公開しているBGPフルルート情報を解析したという記事です。
GoogleがBGPでリークした情報の中身を見てみよう:Geekなぺーじ
Googleが正しい経路制御情報を8分後に送信したことが解析結果より間違いないとの分析をしておられました。8分後に訂正したから、即座に解消するわけではないという理由についても説明しておられます。正しい情報を受け取っても、そこからさらに再計算して適切な経路を算出しないといけません。膨大な間違った情報を受け取ってしまったルータが正しい経路を再計算するのに時間もかかりますし、処理能力を超える誤ったデータを受け取ってしまったルータはハングアップという事態に陥ったことも理解出来ます。「大量の経路制御情報を受け取らないようにフィルタをかけてなかった」というような指摘もありましたが、特にBGPにおいては性善説で成り立っている部分が大きいですから、根本的問題解決はそう簡単ではないんだろうなぁと思います。
と、余談ですが、産経新聞の記事で野田総務大臣が今回の障害の詳細を調査すると会見しました。
既にGoogle側のミスだということは報道されていますが、効果的な再発防止策は見つからないと思うのですが…。まさかプロトコルの根幹から変えるとか言い出したりはしないですよね？？？
防災の日に改めて防災について考えてみる(2)
こんばんは。9月1日は防災の日ですね。先日予告しました防災対策を考える記事を書いてみようかと思います。8月29日に以下の記事を書きました。その続きになります。
karasuma-kitaoji.hatenablog.com
「インターネットは目的のサーバ等と通信する場合、最適とされる経路を選択する」というような表現をされることがあります。災害時は迂回ルートを使って通信することがあります。しかし、今回の通信障害のように、不適切な経路情報を送信してしまった場合、逆に遅延したり、通信出来なくなったりすることもあり得ます。災害時に平常時に通るルータ（や回線）が落ちた・故障した場合に迂回ルートを経由することもあるのですが、迂回ルートが設定ミスによる不適切な経路情報だったら、遅延や通信障害が発生することもあります。
となると、1つのメールアドレスや1つのSNSのIDに頼り切るのは危険です。複数の連絡手段を確保しておく必要は少なくともあるかもしれません。
そもそもメールやSNSのようにインターネットだけに頼るのはリスクヘッジの点では問題ありです。携帯電話や公衆電話・つながるようであれば固定電話の機能・サービスを使うのも手ではないでしょうか。携帯電話であればショートメッセージと呼ばれるSMSを使うのも手です。iPhoneの場合はiPhone同士やiPadやiPod TouchやMac相互間ではiMessegeを使いますが、これはインターネット経由になりますので、明示的にSMSを使うように設定変更する必要があります。iPhoneの場合は「設定」-->「メッセージ」-->「SMSで送信」を選んで、ONにすることで対応可能です。
公衆電話や固定電話・NTTdocomoの携帯電話から使える「災害用伝言ダイヤル」があります。
他の携帯電話会社でのサービスですが、Softbankの場合は音声対応の伝言板機能があります。
auには音声対応の伝言板機能は見つけられませんでした。auはこちらです。
MVNO各社については独自の伝言板サービスを運用していません。大手キャリアやNTT東西のサービスを使うように勧めています。
あと、ちょっとそれますが、SIMロックフリーなAndroid機ですと、Jアラートなどの機能が使えないことがあります。災害時に備えて、Yahoo!防災情報アプリをインストールしておくことをお勧めしているサイトが多いです。この点に関しては同感です。いざというときに役立つかと思います。
インターネット・携帯電話以外の機器についても言及しようと思いましたが、次回送りにさせていただきます。<(_ _)>
＜つづく＞
Free Wi-Fiの無線区間暗号化はユーザまかせでいいものかどうか(1)
こんばんは。Free Wi-Fiネタの続きです。市中に溢れるFree Wi-FiのSSIDの数が半端ではないことを実感します。実際どの程度利用されているのでしょうか？「とにかく（キャリアやMVNOの）パケットを使いたくない」という方々が多いのではないかと思います。本当かどうかは定かではないですが、InstagramのJKユーザが3G/4Gで使わないようにするために、アンインストールしておいて、Wi-Fi環境のあるところでアプリをダウンロードして再インストールして使うとかなんとか…。
安全はタダではないし、自分の身は自分で守るのが鉄則
「タダだし、極力Wi-Fiで通信したい」という気持ちも理解出来なくもないですが、セキュリティ面的にどうなのよ…と言いたくなることがあります。そういう方々の多くはFree Wi-Fiの無線区間が暗号化されていないことによるリスクには関心や危機感がないんだろうなと思います。こういう環境でも安全に使うためのVPNなんですが、「とにかく（キャリアやMVNOの）パケットを使いたくない」という方々は購入してないんだろうなという気がします。
それに「自分は関係ない」「盗まれて困る情報はない」と宣う方々も少なくありません。スマホは個人情報の塊です。本当に個人情報を盗まれても困らないのでしょうか？？？
ならば別の方法を考えないと
これだけ個人情報漏洩でいろいろ騒ぎになっている昨今（最近もありましたよね）ですが、それでもいざ自分のことになると、危機感がないようです。
前々から考えていたことで、まだ完全に調べきれてないのですが、プロキシサーバを上手く使えないものかということです。Wi-Fi環境（無線LAN）で接続させる場合、DHCPサーバを設置して管理することが多いと思います。DHCPサーバにはIPアドレス払い出しだけでなく、デフォルトゲートウェイやDNSサーバやプロキシサーバのIPアドレスを通知することが可能です。
そこで、端末とプロキシサーバの間が接続先に関係なく、常時https接続であれば、自動的に無線区間も暗号化されることになります。それにSNSではwebベースのサービスが多いですから、これで十分賄えそうです。
それでプロキシサーバソフトウェアであるSquidについて、squid.confを調べてみようかと画策中です。SSLサーバ証明書の問題もありますので、このへんをどうやって解決するかという点についても考察して行きます。
＜つづく＞
「格安SIMではJアラートが受信出来ない」は本当か？
こんばんは。昨日は北朝鮮からのミサイル発射でJアラートが鳴った/鳴らないという話がネット上をにぎわせていましたね。
Twitter上でも「鳴った」「鳴らなかった」というようなツイートがTL上に流れてきていました。私自身は大阪なので、エリア外であり、鳴ることはありませんでした。
こちらはNHKの記事です。
さて、ここで問題になってくるのは「格安SIMだから鳴らない」のか、「格安スマホだから鳴らない」のかという点です。最近は両者を混同して使われることが多いため、一体どちらを指しているのかうろうろするということがままあります。
この場合は後者が正解です。このあたりについて、engadgetに書かれています。
こちらにもありますように、「MNOの回線かMVNOの回線かは関係ない」とあります。なので、どこのSIMを使っているのかではなく、キャリアが販売していないスマホで受信出来ない端末が少なくないということのようです。
あ、Apple Storeで販売されているSIMロックフリー版iPhoneは問題ないそうですよ。ですので、SIMロックフリー版iPhone＋格安SIM（MVNOのSIM）で使っておられる方々は御安心下さい。
全てのMVNOでどうなのか、全てのSIMロックフリー端末でどうなのかは不明ですが、IIJmioのページ（てくろぐ）に詳しい記事があります。
IIJ側で確認の取れている端末については言及されてはいます。そうでない端末に関しては、Yahoo!アプリを入れておくことを推奨しますとあります。十分役に立つと思いますので、Jアラート対応/非対応に関わらず、インストールしておくのはありかと思います。
と、なぜiPhoneだとSIMロックフリー版でもOKなのかということにも言及されています。iPhone・iOS内の「キャリア設定」によって、MVNOが借り受けている回線キャリアの設定が反映されるから受信出来るんだそうです。
結論ですが、「SIMロックフリー機なら、とりあえずYahoo!防災アプリは入れとけ！」ということのようですね。何もないことが最も良いにこしたことはないのですが。
Google誤経路制御情報送信による通信障害を受けて防災対策を考える(予告編)
こんばんは。Googleの誤経路制御情報送信により発生した国内の通信障害がなぜ起きたかが以下の記事に詳しく載っています。お馴染みのITproですが。(^^;
こうしてみると、インターネットも脆い側面が存在するということなんですよね。「災害時には強い」と言われがちですけど、今回のような障害が発生するとちょっと不安になりますよね。そこで、今回と9/1(予定）の2回で「インターネットと防災対策」について、少し考えてみたいと思います。
ちょうど防災の日が近づいています
9/1は防災の日ですね。災害時の情報収集・通信手段としてインターネットが活用されるようになって久しいですね。「電話は通じないけど、SNSではなんとかつながった」というような話をよく耳にします。たとえば、Twitterの場合、サーバが米国にあります。サーバに到達するまでの経路は必ずしも一つではなく、途中経路で障害が発生した場合は迂回ルートを使って到達します。そのあたりが「災害に強い」と言われる所以ですが、今回の障害で不安が頭を掠めることになりました。
スマホ（のデータ通信機能）のみに頼るのは危険かも
電話も輻輳することが十分予想されます。となると、メールやSNSに頼ることになるかと思います。この場合も単一のサービスに依存するのは危険だと思います。万一、そのサービスが使えなくなったときのことを考えると、その時点で終了になります。
なので、連絡先（というかSNSのIDやメールアドレスなど）は複数通知しておいた方がいいかと思います。
今回は予告編ということで短めですが、次回はもう少し掘り下げて書いてみます。
