arveltのソフトウェア技術メモ

Arvelt's software technology memo

Androidアプリを手動で別の端末にインストールする

Androidアプリを手動で別の端末にインストールする。 OculusGoのVRビュワーが使いにくいので一番使いやすいと思ったやつをOculusGoで動かせるか試したりしたので覚書。ちなみに動きませんでした。ですよねー

$ adb devices
List of devices attached
XXXXX17510009999    device

$ adb shell pm path se.chai.vrtv.free
package:/data/app/se.chai.vrtv.free-1/base.apk

$ adb shell cp /data/app/se.chai.vrtv.free-1/base.apk /storage/emulated/0/Download

$ sudo adb pull /storage/emulated/0/Download/base.apk
/storage/emulated/0/Download/base.apk: 1 file pulled. 23.4 MB/s (15921479 bytes in 0.650s)

$ adb devices
List of devices attached
XXXXX8177   device

$ adb install base.apk
Success

Linuxのしくみを呼んで

Linuxのしくみの読書メモ。ていうかこれほぼ目次だ

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

Inspired: 顧客の心を捉える製品の創り方 を読んで

Inspired: 顧客の心を捉える製品の創り方 の読書メモ。だいぶいい本だったのでおすすめ。実際に積んだ人間が、こうしたときはうまくいったよ。というのを教えてくれる。

ベストプラクティス

  1. プロダクトマネジメントの役割
  2. ユーザーエクスペリエンスの役割
  3. 製品の市場性評価
  4. ユーザーモニター制度
  5. 製品原則
  6. ペルソナ
  7. 製品のアイデアを見つけ出すことに集中得する
  8. プロトタイプの活用
  9. ターゲットユーザーとプロトタイプをテストする
  10. 改善するためにはデータを使う

プロダクトマネージャーの懸念事項リスト

  1. この製品は、ターゲット顧客の心に届いているだろうか
  2. 私達は、出来る限りのことをやり尽くしてこの製品を使いやすいものにしただろうか
  3. この製品は、競争に勝てるだろうか。今現在の競争ではなく、製品をリリースする時点での競争に勝てるだろうか。
  4. 私は、この製品を実際に買ってくれる顧客のことを理解してるだろうか。私が望んでいる製品ではなく、自分たちが作ろうとしている製品を買ってくれる顧客のことである。
  5. この製品は、本当に差別化できているだろうか。どう差別化できているかを、会社の経営陣には2分で、頭の良い顧客には1分で、業界アナリストには30秒で説明できるだろうか
  6. この製品は、実際に動くだろうか
  7. この製品は、欠けているところがなくあるべき製品として全体となっているだろうか。顧客はどう思ってこの製品を買うだろうか。それは私達が計画した売り方と一致しているだろうか。
  8. この製品の強みは、顧客にとって大切なことと一致しているだろうか。私たちはその強みを積極的にアピールしているだろうか
  9. この製品にお金を払う価値はあるだろうか。それはいくらで、理由はどうか。顧客はこの製品に代わるものを他でもっと安く手に入れることができるだろうか
  10. 私は製品開発チームのメンバーがこの製品のどこが優れていると思っているかを理解しているだろうか。それは私の考えと一致しているだろうか

市場調査

  • 現実にユーザーはだれなのかを理解しているか?
  • ユーザーは製品をどんなふうに使っているのか?
  • ユーザーは製品をどうやって使うかを理解できているか?ユーザーはどこでつまずくだろうか?
  • なぜユーザーはこの製品を使うのか?
  • ユーザーは製品のどこが気に一致得るのか?
  • ユーザーは製品のどこが気に入っているか?
  • ユーザーが製品にあればいいと思っていることや、変えてほしいと思っていることは何か?

製品仕様

  • 仕様書には、ユーザーエクスペリエンスが全て記載されていなければならない
  • 仕様書には、ソフトウェアの動作を正確に表現しなければならない
  • 仕様書はそれぞれの立場にとって必要な内容が全部盛り込まればならない
  • 仕様書はアップデートされなければならない
  • 曖昧さ、混同を避けるため、マスターを1つ用意する必要がある
  • これらを満たすのはハイファイプロタイプである。ハイファイとは提案されているユーザーエクスペリエンスを正確に再現することである

製品仕様の検証

  • 実現可能性の検証
  • 使いやすいかどうかの検証
  • 買いたいと思ってもらえるかどうかの検証

製品における感情の役割

  • 顧客に製品を買う気を起こさせる感情にどんなものがあるか
  • 自分たちの製品以外には他のどこでその欲求を満足させることができるか

個人向け製品で大切なこと

企業向け製品で大切なこと

  • 使いやすさ
  • ちゃんと動くこと
  • 特別仕様
  • ユーザーモニター制度
  • 顧客vsユーザー
  • 製品のインストール
  • 製品の設定・カスタマイズ
  • 製品のアップデート
  • 販売プロセス

Inspired: 顧客の心を捉える製品の創り方

Inspired: 顧客の心を捉える製品の創り方

2017年を振り返って

前年度たてた目標

コンピューターサイエンスを勉強する
 特にアルゴリズム
新しいプログラミング言語について勉強する
 たぶんelixirかGo
積極的にコードリーディングする
 何かアプリかサービスとかを気軽に作る
漫画を書く
 例大祭と夏コミと冬コミ

 

目標を達したか

  • コンピューターサイエンスを勉強する
  • 新しいプログラミング言語について勉強する
  • 積極的にコードリーディングする
    • これらは全くできなかった
  • 漫画を書く

所感

漫画しか書いてねえなこいつ?
とにかくプログラミングができなくて困っているのだが、できるようになるビジョンが見えないままプログラミング自体を嫌いになっている状況にある。学習行為に手がついていないのは、その極限にまで落ち込んだモチベーションのせいであろう。 プログラミングを初めて10年になるができるようになっているわけではなく、どうにも自分には向いていなかったようだ。とはいえ10年をつぎこんでしまったのでいまから別の業種に転換することも難しい。かなり厳しい状況におかれている状況に間違いない。
仕事においてもデキる人との差が顕著になってきており、なんとかしてほしい的なことを要請されている。ふふふ。。。それができたらとっくに私も圧倒的成長を遂げていたましたとも。
とりあえず色々なものを諦めて、基本からやり直したほうがいいのだろうと思っている。例えば、コードを読んだ絶対量がそもそも少ないのでは?持ってるコードの引き出しが少ないせいで書くときにも困るのでは?ということをボスに言われたりしたのだが、これは私が思っていることとだいたい同じで、おおよく見ていてくれるのだなと感慨深かったりした。コードだけからこういうのがわかるのは私のボスはやはり優秀な人物なのは間違いない。
というわけでコードリーディングをしてみようというのが1つ。コード書かない仕事にシフトしてもいいよということを提案されているのだが、それってコード書けること前提ですよね!?という感じがあるのでやっぱり基礎的なことをおさらいせんことにはどうにもならないだろう。ていうか自分の力にするためのコードリーディングってどうやればいいだろう…?ということがわからなかったのでやっぱり能力がそもそも足らないきがする。というわけでただわかるだけじゃなくて、自分の力にするためのコードリーディングのやり方ご存知でしたら教えてください。
あとは製品作るよりも、コードのメンテナンス、コードを描きやすい環境を整える的な方が、ゴールが明確なので取り組みやすくそっち方面にいってもいいかなと思い始めている。ライブラリのバージョン管理したりメンテナスしたり、既存のAPIに追随したりとか。そういう感じのやつ。
そんなふうに全く暗い話しかでてこないのだが、年いってから始めたお絵かきやら漫画やらは新刊3冊までこぎつけて多分逃避的な意味もあるのだろうが、とりあえず出せたのでよかった。ていうかここで技術ブログで漫画の話してもしょうがないのでさわりだけ。 書くのは結構大変で一ヶ月二ヶ月の可処分時間を全て捧げてやっと1冊という感じなので、春と冬だけとかそういう感じにしたい。漫画描きは趣味の1つとして今後も続けたい。

来年の目標

  • コードリーディングする
    • Django
    • Goole App Engine SDK
    • 自社製品のコード
  • 周辺環境やライブラリについて調べる癖をつける
    • アップデートしたりメンテナンスしたりできるようになる
  • 漫画を書く

Real world HTTPを読んで

私は雰囲気でWebアプリケーションを書いている。 いまだにCOBOLを書いていた時間の方がながかったのだからまだまだひよっこである。 少しでもWebの気持ちがわかるようになりたいのでちまちま読んでいた。

私は以下の項目について内容を思い出せるであろうか?人に説明できるであろうか?できなかったのなら私はこの本を読み直すべきである。

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

「リファクタリング」にみるコードの不吉な匂い

以下は「リファクタリング」Martin Fowler、に出てくる コードの不吉な匂い である。これらを感じるコードは不具合の温床になりやすい、ということらしい。

これらを眺めてなぜいけないのか、どう修正したらいいか。時々思い出そうと思う、思い出せなかったら読み直すのだ。

 

  • 重複したコード
  • 長過ぎるメソッド
  • 巨大なクラス
  • 多すぎる引数
  • 変更の発散
  • 変更の分散
  • 属性操作の横断
  • データの群れ
  • 基本データ型への執着
  • パラレル継承
  • 怠け者クラス
  • 早すぎる一般化
  • 一時的プロパティ
  • メッセージの連鎖
  • 中間者
  • 仲が良すぎるクラス
  • 暮らすのインターフェース不一致
  • 未熟なクラスライブラリ
  • データクラス
  • 相続拒否
  • コメント

 

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

 

 

「USJのジェットコースターはなぜ後ろ向きに走ったのか?」を読んで

最近USJ行ったので、前から気になっていた「USJのジェットコースターはなぜ後ろ向きに走ったのか?」を読んだ。

 

ハリーポッターが当たるのは間違いない、だがそのためには売上の半分をつぎ込む設備投資をする必要がある上に、なによりも完成までの3年間をいかにして持たせるか。そのためにお金を描けずに客を呼ぶ方法は?ということについて頭をひねった経緯がえがかれている。とてもおもしろい。

 

実際行った感じたしかにUSJはよくできていて、ハリーポッターの世界がここにあるということに関してはあふれんばかりの努力を感じ取れたし、そもそも私はジェットコースターには乗れない方だけども、ここでしか買えないグッズなどを大量に買い込んだりして楽しめた。

とはいえ、フィールドは思ったよりこじんまりしているしお城はスケール感が小さいし、雨の日でも楽しめるようにしたというが実際は屋根がある場所がほとんどなく最悪の体験だったし、やはりこんなものかと思ってしまったのである。楽しかったからこそ、気に入らない部分が目につくとかそういったことだと信じたい。

 

この人のアイデアの考え方は、解決しなければいけない問題を正しく前提におくことでそれを埋めるアイデアをひねり出す、というものだ。これはつまり、宮本茂が言うところの「アイデアというのは複数の問題をいっぺんに解決することだ」ということの目的を逆算して実行していることになる。
宮本茂が山内や横井から受け継いだ天性の嗅覚で答えを嗅ぎつけていたのに比べ、この人はアイデアを閃かなければ行けない状況、というものを作ることでその問題を解いていたのである。またそれをただのひらめきで済ませないために、数字の裏付けを必ずとっていたというのは理想的と言える。

この人にプログラミングをやらせたらきっといいプログラマになるだろうと思った。

 

ところで、
イデアの発想法についてはみな色々一家言あるようで様々な人が触れている。たとえば以前読んだもので言えば、「アイデアのつくり方」などは森岡氏が言っている手順ほぼそのものと言っていい。

アイデアのつくり方

アイデアのつくり方

また森岡氏が言うところの、「リアプライ」という概念はこれはつまりすでにあるものを形を変えて実行するということであるが、それは星新一が実践していたところの「アイデアは異なる同士の組み合わせ」のことであるし、そもそもそれはアイザック・アシモフの言葉である。

このようにアイデアとその実践ということについては、多くの人がみな色々な方法を試し実践していたのである。幸い私はそのようなことをしなければ打破できない状況に置かれたことはほとんどないのだが、にっちもさっちもいかなくなったのならこのような偉大な先人のことを思い出したいと思う。