読者です 読者をやめる 読者になる 読者になる

ボクダイモリ

Life is like a Game

メディアアーティスト・落合陽一が教える 情報洪水に飲まれないためのいくつかの方法 読んだ感想

はてなブログからこっちのブログに移行しました

https://blog.daimori.com/


以下の記事を読んで興味深い内容だったので感想書いてみる。

noahs-ark.click

現代は情報過多な時代

ここでいうゾンビとは、TwitterFacebook、メディアから伝わる大量の情報によって 自分の意識や感情が薄くなっている状態のこと。
今の時代、どこにでも情報があふれており、誰でも簡単に、そして無意識に
その情報にアクセスしてしまう。

まさに大洪水(情報過多)の時代である。

この記事を読んで自分も常日頃からたくさんの情報に流されているなと改めて実感しました。
いつも自分にとって必要な情報を取捨選択してきたつもりではいたけども、
結局それは瞬間的な興味・好奇心に流されていただけなんだなと、情報に振り回されていただけなのかもしれない。

コンピューターが水(情報)を生んでいるんですね。洪水に飲まれてしまうと、Twitterを見ながらぼーっとしたり、ソーシャルゲームの単純作業を繰り返したり、とくにやりたいと思っていないことなのに、自分の時間をどんどん失っていきますよね。それって自分の感情や意識がない状態に近い。ゾンビみたいですよね。

通勤途中で無意識にスマホいじり始めたりする人っていますよね。僕もやってますが。
情報に振り回されて意識がないゾンビみたいになって…通勤電車の人たちがゾンビの群れに見えそう。

ゾンビみたいな人にはなりたくないなー。

じゃあゾンビにならないためにはどうすればいいのかというと洪水に巻き込まれないように箱舟に乗ればいいんだそうです。

洪水に流されないためには、方舟に乗ってその中にこもるしか方法はない。その方舟に乗る方法のひとつとして、自分で「文脈」をつくるということがあると思います。自分で歴史を語っていくという作業です。

記事の中で色々語っていますが、つまりは自分の中に強い芯を持つことが箱舟に乗る方法ということでしょうか。

他人や周りの情報に流されないことってなかなか難しいですよね。

そうならないために大事なことって他人の価値観に流されないこと、自分の気持ちに素直になることなんじゃないかなーと思います。

人間と機械の区別がつかない世界は地獄か?

でも、今のぼくらも、すでに人間と機械の区別がついていないかもしれない。例えば、Google検索をするとき、脳の海馬を紐解くような神経信号の伝達状態を伴いながらスマホを見ているという研究報告が以前ありました。つまりぼくらは、脳みその中を探す感覚でGoogle検索をしている。

これは衝撃。
人間の機能、行動の一部がすでに機械に依存し始めている。

自分はいわゆる「検索世代」の人間ですがまさにGoogle検索をしているときはこんなことが起きているんだろうなー。 今後も人間の機能は機械にどんどん依存していて、人と機械の区別が付かなくなってくる。

人間は将来VRの中で人生の大半を暮らすようになるかもしれない。
そうなったときに人間と機械との差というのは「身体」になる。
だから人々のほとんどの欲求は身体を感じることになるのだろう。

また、記事の中でなんでもできるVRの空間が天国か地獄かという話も興味深い。
身体的、精神的に満たしてくれる仮想空間は理想の空間と言えるだろうか?それとも人間から現実的な自由を奪う鳥かごか。
そもそも人々が認識する現実すらも脳が勝手に認識した一つの世界にすぎないだろうからこの議論は無意味なのかもしれない。

VR世界はいつか全ての人たちの理想が叶う世界になるかもしれない。
でもそれは落合さんのおっしゃっている、麻薬に浸っているのと同じことなのかもしれない。

でもそれの何が良くないのかと問われると答えは出せない。
それでもそれを実際に体験できる世界が将来来るとしたら自分は迷わずその世界にダイブすると思う。

音楽コンテンツの未来について

本記事では音楽コンテンツの未来についても語られている。

音としての気持ちよさと、中毒性がある。身体的なものを求めるこれからの時代に適しているんじゃないかな。

これは同意。

音楽って現代でも手軽に触れられるし、データ的にも軽量で扱いやすい。
身体で感じ取れるコンテンツとして優秀で将来的にも需要は増えていくんだろうなー。
ライブのような空間とも相性がいいので臨場感のあるライブはVRコンテンツの一つとして早々に活躍しそうな予感。

もはや現代に自由意志なんて必要ない?

自由意志が目覚めたのは産業革命以降。機械と人間とを比べることで、自分たちが主体的に行動できたり、意思決定できたりすることに気がついた。それゆえに、ぼくたちは機械みたいなものは人間ではないと定義しているわけです。でも、これからはどんどん機械と人間の区別がつかなくなるので、自我=身体になっていくでしょうね。

まじか。
人間の思考ってその時代の環境とか文化とかに深く関係してるんだ。

人間が自由意志を持つようになったのは、機械という比較対象が出現したことによりそれを初めて認識するようになったから。
そして今では人は情報の検索、情報処理をコンピュータに少しずつ任せている。
それじゃあ比較対象であった機械と人間との差が小さくなっていくとどうなるのか。

この問題はそのような世界では自由意志かという問題に繋がっている。

これからはどんどん機械と人間の区別がつかなくなるので、自我=身体になっていくでしょうね。

落合さんは記事の中でこうおっしゃっている。
人は自分の身体を感じることでのみ自分という存在を自覚するようになるのだろうか。
だとしたら人々が身体を感じるのにその人の自由意志が果たして必要だろうか。

自由意志が必要か?
この問題を考えたとき最初に思い付いたのは伊藤計劃さん著作の「ハーモニー」という作品だ。

Amazon CAPTCHA

この作品では、十分に発達した社会では自由意志が必要か?というのが一つのテーマになっている。

この作品から感じたことは、「自由意志が無くても人々が生きていける世界は作れるかもしれない、でもそれは人々にとって幸せなことなのか?」ということ。

自由意志が無い人、いわゆるゾンビたちでいっぱいになる社会は、優しいかもしれないけど残酷な世界だと思う。

落合さんの提唱するデジタルネイチャーが実現したとき、人々の自由意志というのはどう変化するのか。

それは最初の方で語ったゾンビを思い返すと少し想像ができるかもしれない。
将来の人々は現代のゾンビの延長線上の存在であると推測できる。

それは例えばたくさんの情報に囲まれて脳の中はマルチタスク状態の人だったり、意識や思考も浅く、表面的な意思決定を行いがちであったり。 情報に流されコンテンツを消費することだけに時間を費やしていく人たち。

うーん…自分はそうはなりたくないな(-_-;)

おわりに

この記事を読んで今の自分の置かれている状況、常にアクセスできる情報群に対しての考え方を改めさせられた。
特に情報に振り回されてしまうことへの危機感というのはものすごく感じた。
やっぱり自分は人間らしく自分の意志で生きていきたいし、情報やVRに対しては適度な距離で接していくようにしたい。

技術が進歩していくことでその社会に生きる人々の自由意志は少しずつ変容していくのだと思う。 それがどんな形に変わるのかは分からないけども、自分の意志は大事に持って行きたいと思う。

P.S. ぼくのりりっくのぼうよみさんの 「Newspeak」、すごくいい曲。TSUTAYAで借りてこよ

Noah's Ark

Noah's Ark

ハーモニー〔新版〕 (ハヤカワ文庫JA)

ハーモニー〔新版〕 (ハヤカワ文庫JA)

Nintendo Switch買った!

昨日地元にあるケーズデンキに置いてあったので購入。やったぜ! やはり田舎なのか人がいないせいか普通に置いてありましたね。 新宿や渋谷を探し回っても見つからなかったのでホントに見つかった良かったです。

任天堂ハードって毎回出す度にデザインとか操作性で色々言われることが多い印象なんですが、 今回このSwitchを触ってみた感想としては結構いいんじゃないかと思います。 Switchの立ち位置としてはWiiUの後継機ということになるんでしょうが、実物は据え置き機というよりかは サイズが大きい携帯機といった感じ。大画面でプレイしたければディスプレイに繋げればいいし、外でさくっと やりたければ携帯機として遊べる。
個人的には場所を選ばずスキマ時間で遊びやすくなっていると思うのですごく好印象。
また、コントローラー部分を付け外しできるし、すごく軽いので扱いやすい。
操作性についてはまだあまりプレイしていないのでなんとも言えませんが、悪くはない気はしています。 夏に出るスプラトゥーン2とかは問題なくプレイできそうです。

ちなみにソフトはゼルダを買いました。
ゼルダ風のタクト以来プレイしていないし、今作は評判がものすごくいいので楽しみです。
プレイ後の感想とかもブログに書くかも。

nodebrewを使ってNode.jsをインストール

はてなブログからこっちのブログに移行しました

https://blog.daimori.com/

仕事でnodeを使っているので勉強がてら触ってみる。

まずは環境構築から

開発環境

  • ツールのバージョン
    Homebrew 1.1.11

nodebrewのインストール

nodeのバージョンを管理したいのでnodebrewを使ってnodeをインストールすることにする。
まずはnodebrewをbrewを使ってインストール

$ brew install nodebrew
$ nodebrew -v
nodebrew 0.9.6

nodeのインストール

前述した通り、nodebrewを使ってnodeをインストール

$ nodebrew install-binary stable

上記のコマンドで最新の安定版がインストールできるはずだが、Failed to create the fileというようなエラーが出てインストールに失敗する(エラーログは取り忘れた) これはインストールするためのディレクトリがないために発生している。なので、まずはインストールするためのディレクトリを作成する。

$ mkdir ~/.nodebrew
$ mkdir ~/.nodebrew/src

ディレクトリを作成した後にもう一度インストールを実行すると問題なくnodeがインストールされる

nodeが使えるように設定

インストールしたnodeを実行できるようにnodebrewからnodeのバージョンを選択する

$ nodebrew use stable
$ nodebrew ls
v7.7.3

current: v7.7.3

また、nodeにPATHを通すために以下のように.bash_profileにPATHを追加

$ echo 'export PATH=$PATH:/Users/xxxx/.nodebrew/current/bin' >> ~/.bash_profile

ターミナルを再起動してからnodeを実行

$ node
> console.log('Hello Node.js!')
Hello Node.js!

環境構築おわり。

作業の工数を見積もるときの3つのポイント

自分は今年で3年目のエンジニアになるが、未だに作業工数の見積もりは難しく思う。

今までいくつかのプロジェクトにアサインされてきた。その中で、自分はPGとしてコーディングをしたり、 SEとして設計書作成をしていたが、共通しているのはそのタスクには期限があるということ。
そしてその期限をもって、プロジェクトの全タスクはスケジューリングされている。
タスクには期限を設ける必要があるため、そのタスクについていくつか考えなければならないことがあるだろう。

「そのタスクの成果物は?」
「そのタスクの完了にはどのくらい時間がかかるの?」
「そのタスクはいつ終わる?」

将来の結果を予測するのは難しい。だが見積もりは重要だ。
なぜならいつ終わるのか分からなければ、次のタスクをいつ振ればいいのか決めようがないから。

つい先日、プロジェクト内のPMに見積もりについていい事を聞けたので、ここでまとめてみる。 見積もりのポイントは次の3つ

  • タスクは細かく分割する
  • 工数はフィボナッチ数列を使って見積もる
  • 工数が分かるタスクで相対的に測る

1つずつ章ごとに分けてまとめてみる

タスクは細かく分割する

タスクの見積もりは難しい。それが大きなタスクであればなおさらだ。 タスクは細かく分けるほど正確な工数を見積もれるのだから、タスクを分けるのは重要なことだ。

個人的にはタスクは最大でも3日で終わるような規模にするべきだと考えている。
でないと自分の今持っているタスクを十分に見える化することができない。

例えば「実装」というタスクを振られたとして、その作業をどのように分けるべきか。

実装といってもコーディングして終わり、ではないだろう。コーディングが終わったら動作確認をしたり、 バグがあればまたコーディングに戻り、動作確認が終わればリポジトリにコミットして次はソースレビュー。
レビューで指摘を受けてまたコードを修正、動作確認、…という流れになるはず。
なのでタスクを分割すると以下のような感じ。

  • コーディング
  • ソースチェック
  • 動作確認
  • リポジトリにコミット
  • ソースレビュー
  • レビュー指摘箇所の修正
  • 修正後の動作確認
  • 修正後のソースコミット
  • 修正後のソースレビュー

このように作業に分割すれば見積もりはしやすくなるだろう。
また、ソースレビューは自分の作業だけでは完結せず、レビューが行われるまでは待ちの状態になる。
その点も考慮してスケジュールを組まないと余裕を持って期限内に終わらない可能性が出てしまう。
タスクが十分に分割されていれば、正確に見積もりができ予定通りに作業を完了させられるように なるのではないだろうか。

工数はフィボナッチ数列を使って見積もる

フィボナッチ数列とは1,1,2,3,5,〜と続く数列で、ある値はその前とその前の前の数を足し合わせた値になる。 フィボナッチ数列に登場する値を使うと相手に工数が伝わりやすくなるとのこと。 例えば

1人日:すぐに終わりそう
3人日:そこそこ時間かかるね
5人日:結構かかるな〜
8人日:え!かかりすぎじゃない!?
13人日:何かがおかしい

ポイントとしては5人日以上かかる想定であれば、そのタスクの見積もりは妥当ではないということ。
前の章でも述べたが、タスクは小さく区切るべきであり5人日かかるタスクというのはそもそもタスクの分割が 不十分である。従ってそのようなタスクがあれば、またタスクを分ける作業に戻るべきだろう。 また、1人日、3人日、5人日というような見積もりだけだとかなりざっくりしているが、さくっと相手に 作業時間を伝えることができる。
自分は見積もりに結構時間を使ってしまうタイプなので、この方法を活用して楽出来ればなーとか考えてます。

工数が分かるタスクで相対的に測る

あるタスクの作業量を伝える時、単純に何人日かかると言っても伝わりにくい場合は、 すでにある実績と比較して伝えるとわかりやすいらしい。
例えば、
「以前こういう作業にこれぐらい時間がかかり、今回の作業は誰々さんが実施するので〜倍の何時間かかります」
というような感じ。
この方法なら割と簡単に時間をかけずに工数を見積もれる気がしますね。

自分は実績をものさしにして見積もりをするということはしなかったですが、今後は実績はちゃんと計測して 将来の見積もりに役立てるようにしたいなー。

まとめ

ポイントとしては以下の通り。
1.細かくタスクを分ける
2.フィボナッチ数列でざっくり見積もる
3.タスクは他の作業と比べて相対的に測る

今回はPMとの飲み会でいい話が聞けたので、まとめてみた。
これらのポイントを抑えれば見積もりもきっと上手くなると思うので、これからはちょっと意識してみます。

Android4.3以前の標準ブラウザはplacefolderをサポートしていない

placeholderのcssをどうやって古いAndroidのブラウザにも対応させようかで詰まってたけど、 そもそも対応してなかったというオチ

http://caniuse.com/#search=placeholder

リンク先の通り、Android4.3以前のバージョンはplaceholderをサポートしていない。 もっと早くにこの線で調査すればよかったorz

caniuse便利だね

継続的インテグレーションによって何が出来るようになるか考えてみる

継続的インテグレーション(CI)について、軽くググってみたら色々出てきた。

継続的インテグレーションとは?– アマゾン ウェブ サービス

www.techmatrix.co.jp

なんでこんなこと調べていたかというと、社内のプロジェクトでCIについて議論する機会があったが、 この辺のノウハウには疎かったのであまり話についていけず気になっていたから。

今現在所属しているプロジェクトは、短いスパンでサービスをリリースしてはそれと並行して開発進めている、いわゆるアジャイル開発だ。
また、開発自体は外部に委託していて、うちの会社はコードの品質管理などをしている。

そんなプロジェクトだが、歴史自体は浅くCIツール(Jenkins)などは導入されていない。
あるとすればコードの品質を最低限保つためのSonarQubeがあるだけ。
それとソースはGitで管理しているが、なぜかリポジトリはBacklogで管理されている。
また、ブランチ管理はGit FlowとかGithub Flowとかではない。masterとリリース+開発用のブランチがあるだけ。

こんな感じのプロジェクトだが、プロジェクトの現状についてどう改善していくか議論する機会をもらえたので、 せっかくなのでCIツールとは何か、CIってなにするのか、問題点とか将来こうしたいなど自分の考えとか理想とかをまとめてみる。

CIについて

CIについては上のAmazonのページがよくまとまっている。
CIの目的はつまりこのような感じだろう。

  • 開発者の生産性向上
  • コードの品質向上
  • リリースと結果確認にかかる時間の短縮

上記3つを目標とする際、実際にするべきことはなんだろうか。それぞれ必要なことを軽く挙げてみる。

開発者の生産性向上

  • 重要なコーディングに集中する
  • 開発中に埋め込まれるバグを減らす
  • バグを早期発見する仕組みを作る

コードの品質向上

  • コードレビューを実施する
  • コーディング規約を設けて機械的にコードをチェックする
  • 定期的にビルドする(コンパイルエラーになるようなコードは埋め込まない)

リリースと結果確認にかかる時間の短縮

  • リリーススクリプトを用意して、リリース作業を自動化する
  • ビルド、リリース結果を担当者に通知する
  • ビルドからリリース結果確認までの手順を簡略化する

CIツール等を使えば上記のようなことはできそう。
他にもできることはありそうだが、とりあえずは上の項目をプロジェクトに盛り込みたい。

現プロジェクトの問題点

今プロジェクトが問題にしていることはだいたい以下の通りである。

  • CIツールがないため、自動ビルドや自動デプロイというような仕組みがなく、その作業に時間を使っている
  • 品質向上の為、SonarQubeを使ってはいるが、手動で行っていて時間がかかっている
  • 開発フローにコードレビューが存在せず、局所的にコードレビューを行っているのみ
  • リリースの手順が複雑、時間もかかる

現プロジェクトの問題点として、自動化できるような部分で時間を取られていたりしていて面倒くさい。
やはりエンジニアとして自動化出来る部分は自動化して、本質的な作業に集中したい。

また、ブランチ管理の規約を設け、開発用のブランチを用意することでブランチの構成をシンプルにした上で、 他のツールとの連携もしやすい環境にしたい。

そのためにもまずは、JenkinsなどのCIツールの導入や、ブランチ管理、開発フローの見直し等が必要なのかなと 考えている。

今後について

今のプロジェクトについて問題点を挙げたので、次はそれについて具体的な解決策などを模索していきたい。 まだまだ勉強不足で考慮が足りていない部分もあるだろうけども、今後メンバーとプロジェクト体制を見直していく上で 少しずつ知識を身に着けていければいいかなー。

まとめ

今回はCIとは何であって、プロジェクトの問題に焦点を当てながら理想の開発環境を書いてみた。

今後どうやってCIを導入していくかは気が向いたら書く。
今はもう疲れたから寝る。

【Swift3.0】Errorプロトコルを使った例外処理のサンプルを作ってみた

Swift3.0でErrorプロトコルとdo~catch構文、tryを使ってみた。 最小限のコードだけメモとして残しておく。

実行した環境は以下の通り

  • xcode version:8.2.1
  • swift version:3.0.2

Errorプロトコルを定義

以下の様にErrorプロトコルを定義する

enum TestError:Error {
    case Error1(String)
    case Error2(String)
}

enum要素に引数をとることで、エラーメッセージなどを呼び出し元から参照することができる。

次に上記の例外を投げる関数が以下。

func TestMethod(str:String) throws {
    if str == "error1" {
        throw TestError.Error1("エラー発生1")
    }
    else if str == "error2" {
        throw TestError.Error2("エラー発生2")
    }
}

また、例外をthrowするメソッドはthrows宣言をしないとコンパイルができない。

try~catch構文とtryで関数呼び出し

作成した例外を投げる関数をdo~catch構文の中で呼ぶ。
関数を呼び出すときは先頭にtryをつける。
Errorプロトコルの要素は引数にStringを取っているので、 例外発生時にその値を出力するようにしてみる。

do {
    try TestMethod(str: "error1")
} catch TestError.Error1 (let err) {
    print (err)
} catch TestError.Error2 (let err) {
    print (err)
}
//実行すると「エラー発生1」と出力される

まとめ

  • Errorプロトコルを使うことで例外を定義できる
  • 要素に引数を与えることで、例外発生時に呼び出し元にデータを渡せる
  • 例外を投げる関数にはthrows宣言をつける
  • 例外が発生しうる関数の呼び出しはdo~catch文の中で呼び出す