たしかに回避するべきだが、デバック起動でパフォーマンスが落ちて、動作確認に時間がかかっては意味が無い。
printしたほうが早いのなら、prinデバッグで良いのでは？と最近思い始めた。
やることが無くて、戦略とか作戦について、自分は仕事の中でどうするべきか、思いを馳せてみた。
最上位概念。戦わずして勝つやり方を考える。
敗者から見て、卑怯といわれる方法が戦略？
仕事の中では、開発の古典（デザインパターンとか、原理原則）を学ぶことが戦略に該当すると思う。
ただ、戦術面での下積みがないと、戦略は使いこなせない気がする。
デザインパターンも、いきなり教わるのではなく、開発で悩んだ結果、デザインパターンを知ることで、よりよく使えると思う。
戦いを作る。どうせ戦いが始まるのなら、有利な状況で戦いを作る。
仕事のうえでは、言語の先取り学習とか、情報収集、アンテナ張りかな？
危険な仕事の気配を感じたら、擦り付け先を考えるのを良くする。だけど、やりたくない泥臭い仕事は、高確率で俺のところに来るから、処世術が下手なのかもしれない。。。。
言語の先取り学習は、たぶん、即座に現場に活かせることはないと思う。
どちらかというと、投資の意味合いが強い気がする。
Javaなら早期ビルドのころから追ったほうが、確実に有利。
覚えるのが、出てからよりも、よく覚えられる気がする。
たぶん、情報が出ていないから、自分で情報を取りに行くため、不明点が明確になって覚えやすいのだろうと思う。
戦う術。
仕事のうえなら、リーダブルコードを書く、ＵＭＬで意思疎通を計るなどかな？
戦略・作戦・戦術を長く続けるためのリソース確保。
疎かにすると、戦略レベルで崩れて、戦わずして負ける。
マインド（学習意欲）を強くする、快適な学習環境が、そうだろうか？
ブログを書くのも、長く学習するうえで必要かもな。
あとは、検証環境を迅速に作れるdockerをマスターしたり、webサービスを高速に作れるSpringBoot覚えたりが、そうだろうか？
作業するときはメガネをしているのだが、たまたま忘れた。。。
画面がぜんぜん見えないから、作業にならない。。。
メガネがないとダメなんだ。。。
メガネがないと。。。
プリンは飲み物
分類するなら汁物。俺の中では、味噌汁と同じ分類。
マナーを気にするところでは、スプーン使うけど、家の中ではすすって食べる。
icloudからバックアップ移行したが、素早く、しかも簡単に移行できたことに驚いた。
バックアップから復元したが、アカウント情報を使えて、アプリがすべて再インストールされるから、そのまま使えるような感じだな。
セキュリティ面が心配になるが、Appleは個人情報保護の観点が強いから大丈夫だろう。
safariとか、cookieからの保護が強すぎて、Google認証で苦戦した思い出があるから、ある程度は信用している。
前に使っていたipad、回収してもらいたいんだが、あの回収シール、どっかやっちゃった。。。
mac bookは、見つけたんだけどなぁ。。。
新製品を箱から取り出すドキドキ感がたまらない。
今度は、落とさないように大切に使おう。。。。
Android開発をするようになって、C++と連携しているソースを初めてみた。
nativeってワードを今まで見たことなかったが、初めて見た気がする。
今まで開発したなかで、見た記憶はない。
用途を確認したら、C++等のネイティブな実装を呼び出すときにだけ使うらしい。
そりゃ、見ませんよね。。。
どこかで、C++との連携する試し実装をしてみたい。
Serviceを実装したクラスが連携。
onBind()で返されるStubの実装が、処理の代理、もしくは振り分けを実施する。
初めて飲んだが、コーヒー嫌いな俺でも飲めた。
甘めなのが、個人的には不満だったかな？
現場で発煙があったらしく、リスク回避のため、取り替えるらしい。
こういう話を聞くと、やっぱり、怖くて手が出せないよね。。。
個人では、モニタは、PHILIPSかiiyamaを使ってる。
やっぱり、使うとしたら２択になってしまう。
どこかのサイトで、不要・必要みたいなことが書いてあったので、改めて考えた。
個人的には、デザインパターンの考えは必要。
特にＦＷを作る場合は。
使う側が不要と感じるのは、それだけうまく状態管理とかをFW側が隠してくれてるからだと思う。
最近だと、SubjectとObserverパターンは、よく使うんじゃないかな？
Reactiveプログラミングだと必須だと思うのだが、使わないものなのだろうか？
古典的なプログラミング作法を知らないのは、かなりの遠回りをするような気がしてならない。
苦労してデザインパターンを自分で見つけてもいいかも知れないが、たぶん、その頃には、現役でいられるか怪しい気がする。
個人的には、一回問題にぶつかって、モヤモヤ悩んだあと、デザインパターンを知るべきだと思う。
最初っからデザインパターンを知ってしまったら、過度な適用や、誤ったパターンの適用をしてしまいそうな気がする。
一度、自分で熟考するのが大切だと思うな。
その方が、プログラミング能力は向上すると思う。
バージョンが新しくなったらしく、新規のUIで操作できるリンクができてた。
ただ、new UIで書いたコメントが、古いUIで見れないっぽい。。。
管理者権限剥奪されてるアカウントで環境変数をdosからコマンド操作で変えられるのは、OKなのだろうか？
変わってるのは、ユーザ環境変数だから、ＯＫなのかな？
target1.8にしただけでは、streamは使えない。
APIのバージョンも合わせる必要がある。
Androidで、ネイティブ層の実装とJavaの実装の連携方法を見ているのだが、さっぱり分からない。。。
なんとなく、ポインタ取得して同じところをみている感じがするのは、感覚的に分かった。
いろいろ実験してみないと、本当に推察が正しいのか判断できない。
読み込もうとするHTMLがないから起こってるっぽい。
原因がよく分からないが、Android Studioのインスタントランが原因っぽい。
おそらくだが、ビルド後に配置される場所に、何らかの操作で消したが、Android Studioが差分を検知できなかったため、再配置されず、起動時にエラーになったと思われる。
たぶんね、ファイル移動をしたような、しなかったような記憶がある。
インスタントランを停止して再ビルドしたら、動作した。
これで半日悩み続けましたわ。。。
縦長ディスプレイが現場に欲しい。
ピボットできるディスプレイでも可。
ドキュメント見るときに、多くの情報が見れる縦長の方が、楽チン。
ワイド１縦長１のデュアルディスプレイが、開発には最適だと個人的に思ってる。
win8.1で、以下のコマンドで確認できる。
gradlew app:dependencies
別プロジェクトで作られたサンプルを、今のプロジェクトに適用させようとした際に、依存関係がぶつかり会いすぎて、一覧にしないと分からないから使った。
もう、依存関係をスルッと解決する方法はないのかな？
このコマンド実行する場合は、プラグインが必要になる。
com.android.support が競合する。
これは、しょうがないものらしい。。。。
基底のＦＷだからだろうか？
いまいち、腑に落ちなかった。
ＴＴＳを再生する機能を作っているのだが、前日まで音声が出てたのに、当日使えなくなって焦った。
単純にミュートになっていただけだった。。。
こんなしょうもないことで、半日潰してしまった。。。
俺が何かソースを変えてしまったか？ってかなり疑ってた。
ちゃんと動いた時点でGit管理しておけば、もっと早くに疑念を持ったかも知れない。。。
ローカルでいろいろやるにしても、何かが確定した時点で、ＶＣＳにツッコむべきだと思いました。
先週の続き。
手順書に書いてないと思ったら、情報が散らばっているだけだった。。。
よくよく読むと、解決できないこともない。
でもさ、こういうのって、読み手に優しく書くものじゃないの？
情報が分散するのは、手順書としてはダメな方だと思うわ。
ガンプラの組み立て説明書を手本にしなさいと言いたい。
ミニ四駆でも可。
もう、頭ハゲそう。。。
あっちを解決したと思ったら、こんどは別の場所で衝突したり、モグラたたきやっているようだった。
全部解決して、いざ動かすと、動かないという仕打ちを受けると、心が砕けそう。。。
