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

Arvelt's software technology memo

2018年を振り返って

essay development

前年度たてた目標

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

目標を達したか

  • コードリーディングする
  • 周辺環境やライブラリについて調べる癖をつける
    • 全然やってない
  • 漫画を書く

所感

漫画しか書いてねえなこいつ…（１年ぶり二度目
プログラミングができなくて困っているのだが、できるようになる道筋はもはや見えない。なんでプログラマになったのか。なのでプログラマ以外の職業へと転職を考えてはいるのだが年齢がいきすぎてもはや機会を逸している。苦痛なプログラミングといかに向き合っていくのかということを考えていかなければならない。
１０年やってプログラミングが身につかなかったという事実から自分の才能をすでに見限っているのだが、ことWebに関して言えばまだ触れ始めて５年であるともいえる。できる人は半年もすれば全てを掴んでしまうのであるが、そこは凡人以下の私であるので天才の 1000倍時間がかかったとしても驚きはない。

という風に将来を悲観しているのだが、仕事で完全新規のAndroidアプリを一人で作ったりしていた。そういうのはできるようだ。もしかしてWebよりもネイティブモバイルのほうが性に合っていたかとかそういう話なのだろうか？
ならWebやめてモバイルやるかーと思ったが、これも年齢のせいで転職はできない。作れるだけなら若い人間でいいわけで、プラスアルファーが必要という話である。とはいえアプリ作るの意外と嫌でなかったので勝手に勉強するのはやぶさかではない。
これはそういう勉強のやり方ばっかりやってたのでそうなったのだと思う。つまり新しい技術のプロトをさっと作るという方面には可能性があるようだ。ただこれ正社員ポジションでやることじゃないんだよな…。
そうはいっても今いるのはWebの会社なので。Webの中でやれるようなことを探していく必要があるのだが、技術側は諦めて人間寄りの方を模索するのも１つだなと気づいた。好きじゃないけど。私は好きと得意がかけ離れるタイプの人間のようなのでおそらくやってやれないことはないのだろう。
組織寄りプロダクト寄りビジネス寄り、技術を理解できる人間がそっち方面で果たせる役割というのを探ってみたいと思う。
漫画描き。好きではないがわりかしこなせるというだけでプログラミングをやっているので大変なストレスと苦痛と共に過ごしている。そこでストレス解消のために全然別のクリエイティング行為であるところの漫画がハマったのではないだろうか。まんがかくのたのしいかみえしになりたい

来年の目標

  • モバイルアプリ勉強する
    • これは単純に興味あるので
  • 新しい技術をいち早く試す
  • コードリーディング
    • Web関連のコードを読んだ絶対量が少ない問題
  • 技術プラスのスキルの模索
    • 一番地続きはプロダクト方面。仕様や設計には適正がなかったので、運用とか改善の方面
  • 漫画を書く
    • 例大祭。それと夏か冬のどちらか

kotlin fest 2018に行ってきた話

kotlin Android

最近Androidアプリをkotlinで書こうとしています。ちょうどkotlin fesがあったので行ってきました。 スライド公開されているのでだいたいこの辺から見ることができます。

kotlin.connpass.com

「Kotlinアプリのリファクタリングポイント」と「Kotlin コルーチンを理解しよう」あたりが私に良かったなぁという気がします。 実際kotlinでモバイルやろうとすると、それはAndroidの仕組みの話なの？Javaの話なの？kotlinの話なの？みたいのが混ざってしまいさっぱりわからなくなってしまいがちです。

結局Javaなので詰まったらJavaまで降りていかないと行けないみたいなときもあるっぽいので、絶対に降りないように凝ったことするくらいならその仕様にNoを突きつけるくらいでいきたいですね。大変な思いをするためにプログラミングをやっているわけではないのでツラさを押し付けてくるなら殴り飛ばしてやるからなまじでおまえまじでこの野郎おまえ

あとyahooブースでモブプログラミングとか初めて見ましたけど。昔ペアプロもそんなうまくやれなかったし。ほんとに効果あるんでござるかぁ？みたいな気持ちでいます。ああいうの合うタイプと合わないタイプがあるんですかね。ペアプロとかモブプロって優秀な人がさらに加速するための装置であって、普通の人が普通のことをやるには向いてない気がします。でもOvserber.delegate()でしたっけ？は初めて知ったのでありがとうございます。

あとwebDB pressの特集でkotlinがきたり、kotlin盛り上がってますねー

f:id:arvelt:20180825105757j:plain f:id:arvelt:20180825125253j:plain f:id:arvelt:20180825105745j:plain

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

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のしくみを呼んで

book linux

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

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

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

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

book

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

ベストプラクティス

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

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

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

市場調査

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

製品仕様

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

製品仕様の検証

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

製品における感情の役割

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

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

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

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

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

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

2017年を振り返って

essay development

前年度たてた目標

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

 

目標を達したか

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

所感

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

来年の目標

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

Real world HTTPを読んで

book

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

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

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

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