抽象的に考えることって意外と重要だよね！
抽象って？
「共通点」「公約数」なんて解釈しています。
抽象化って？
1つのことで複数のことが説明出来ること。
複数の共通点を見出すことでそれがどれにでも当てはまるから。
例えば、「魚」「肉」「野菜」この共通点は、「食べ物」である。
つまり、これらのものは食べ物であると説明出来る。
抽象化することで、長ったらしく話さなくて良いと言うのはメリット
だけど、お互いの認識が違うと間違ったほうに運んでしまう。
また、人によってもっと具体的に話して！と言う人もいるだろう。そういった面はデメリットに近いのかも知れない。
具体→抽象→具体
具体的な事例があって、それを抽象化してみて、他の案を探す。
一回引いてみる感覚なのかな？
これ結構使えそう！
抽象的にすることで、よりシンプルになって、選択肢が増える
抽象化することは、物事の共通点を見出して1つのことで複数のことが説明出来ること。
シンプルなんだけど、そこには情報がたくさん詰まってるんだよね！
具体的にしちゃうと、選択肢がそれしかないから、選択肢に余裕がないんだよねー
そうなると、考える事をしなく出来ちゃう環境になっちゃうから脳がだんだん衰えたり、面白くない人間になってしまうよねーそれは嫌だ！！！
具体的であればあるほど、楽である。
具体的が悪いと言う話をしているわけではないので、次の章...
実現するためには具体性が必要
抽象化は物事を机上であれやこれやと考えるのに対して、具体的は実際に実現するのが目的である。
こうなると、どちらも駆使した方が、必ず良いものが生まれてくるので、両方をうまい具合に使って行きます。
ラテラル・シンキングとは？
ラテラル・シンキングとは？
革新的なアイデアを生み出す考え方
前提、固定概念から疑って、あらゆる視点から物事を判断する考え方
水平思考、クリエイティブ・シンキングなんて呼ばれますね！
何故ラテラル・シンキングが必要なのか
ロジカル・シンキングはみんなと同じ答えが出る
発生した問題の要因を紐解いていく過程は誰にでも出来るから
例えば、クイズがあったとして、その答えを導くために、「ここがこうなると、こうなるから答えはこう！」ってみんな同じ答えになりますよね？
ロジカル・シンキングとは言わば、答えありきで考える考え方である
なので、みんなの答えは同じになる
つまり、これからAIなど技術が進歩する上で、同じ答えを出す人間はいらない
ラテラル・シンキングは十人十色の答えが出る
ラテラル・シンキングが使われる場面は、問題が複数あったり、隠れていたりする
そうなると、問題の解き方がわからない
だから、色んな仮定を想像して、検証してみる必要がある
例えば、クレーン車が走行中歩道橋に引っかかって抜け出せない
この時、「歩道橋を打ち抜いて走る」「レスキューを待つ」などが普通です
ですが、「車を低くすれば抜け出せるんじゃないの」と考えるとリスクを少なくして抜け出せます
色んな視点で物事を見れるラテラル・シンキングが重要になってきたりする
色んな視点
・鳥の視点 → 1歩引いて、全体をみる
・蟻の視点 → 細かい単位でみる
・第1者視点 → 自分視点「こうやったら良いんじゃないか」「これはダメだ」
・第2者視点 → 相手視点「これが欲しいんだろうな」「こうしたいんだろうな」
・第3者視点 → 客観視「第1者と第2者の需要と供給ずれてるね」「こう言う案もあるよ」
考えるためのキーワード
・そもそも、どうして
・視点を変える
・他に使えないか
・似た物はないか
・大きくできないか
・小さくできないか
・1部を変更できないか
・なくせないか
・逆にできないか
・組み合わせれないか
3分でわかるラテラル・シンキングの基本より
リファクタリングとはなんぞや！？
リファクタリングとは
『リファクタリング』とは、体質改善
外面は変わってないように見せて、中の細胞構成は綺麗に改善される技法
外から見た動作は変えないが、内部のデータ構造を改善する技法
『リファクタリング』によるメリット
基本的に内部の構造を変えたからと言って、バグが無くなったり、動作が変わったりする事はない。あくまで、『〜しやすいようにする』がキーワード。
例えば、内部の構造を改善し、読みやすいコードにする事で、バグを見つけやすくする、改修をしやすくする、コードを読みやすくする。
『リファクタリング』を行う時の注意点
『リファクタリング』を行う時の基本は、『ステップバイステップ』
同時に複数の処理を『リファクタリング』すると、どこでエラーが発生したのかわかりにくい、戻りたい時に余計な部分まで元に戻ってしまう。
『ステップバイステップ』にしていれば、もとに戻りたい時も『ステップバイステップ』で戻れば良いのだ。
委譲とは
『委譲』とは処理を委ねると言う事。
まず、『委譲』と『継承』が存在する。
『継承』は、クラス内に書かれたもの全てを使って良いよと言う状態。
この時の継承されるスーパークラス、継承されたサブクラスが存在する。
全部の処理が使えるなら良いじゃん！だけど、全部が使えるからこその悩みもある。
（そのプロジェクトで全ての機能を継承した何でも使えるオブジェクトをゴッドオブジェクトなんて呼ぶ。神だ。）
全ての機能が使えるからあれやこれやと色んなところで使うと、変更があった時の修正が面倒になったり、他の人がコードを見た時に作成者の意図が伝わりづらいと言う欠点がある。
『委譲』は、あるクラスの一部だけを使用する。必要な分だけを使わせてもらうと言う事。余分なものがなくて、作成者の意図が伝わりやすい。必要な分だけしか使わせてもらえないから、下手にいじる事もできないのよね。
Javaのコードで言うと...
『継承』→ extends
『委譲』→ Object oj = new Object(); oj.getValue();
「『継承』は最後の武器だ」と言われるまでに、使用は出来るだけ避けた方が良さそうな気がします...
ラテラルシンキングとは
『ラテラルシンキング』→ 水平思考
『ロジカルシンキング』→ 垂直思考（論理的思考）
『クリティカルシンキング』→ 批判的思考
『ラテラルシンキング』は、問題を解決するために、形に囚われずに色んな仮説を立てる事、点を絞っていく事
『ロジカルシンキング』は、問題をどんどん掘り下げていく事、点と点をつなげる事
『ラテラルシンキング』の使い所は、例えば、今年度の売り上げが、例年より落ちているのは何故か。不景気、感染症、単価が下がった、取引先が減ったなどなど考えられる要因は様々である。
考えるポイントは形に囚われすぎない事！
プログラムの動作確認したその後は...
出来る限りリスクを省け『ローリスクハイリターン』
『ハイリスクハイリターン』より、『ローリスクローリターン』の方が安定しているのは当たり前
だけど、一番良いのは『ローリスクハイリターン』
ここを狙いに行くにはと言う事を第1に考えたいもの
考えるべきポイントはリターンよりリスクを考えないといけない
言うならば、オフェンスよりディフェンスを意識しないといけない
株、FXでもよく聞く『損切り』
これは明らかにリスクを押さえようとする手法である
まずは、自分の城を固めた上で、敵陣に突撃しに行く
城がピンチになれば退却して体制を立て直す
この作業は気づいた瞬間に行動しなければ傷が深くなるばかり
勝負の世界で勝つためには、『どうやって勝つか』よりも『どうやったら負けるか』を徹底的に考えた方が勝率がグンと伸びる
派手な勝ち方は短期的な目線では良いが、長期的に見ると負けていることが多い
地味でコツコツ勝利を勝ち取る方が結果的に勝っている
『ハイリスクローリターン』か『ローリスクハイリターン』か
動作確認したその後は...
丹生込めて（めちゃめちゃ悩んで）作ったプログラムの動作が確認出来た。
ただその中（コード）を見てみると同じ処理が複数書かれていたり、変数名に統一性がなかったり、文字列リテラルが直書きされていたりで散々です。
「動作は確認出来たし、OK〜」でも良いっちゃ良いのだが、自分のスキルをあげるために取り組んでるので、見返して修正出来る部分は修正するのが一番スキルが高まるよねと言うお話。
でもこれって、今の自分の実力で制作途中でこれを考慮しながらやれ！と言われてもそっちの方が時間がかかる気がしている。
結局、自分のスキルレベルに合ったプログラムの作り方があると思うからそれを探ると言う期間でもある。
成功だと感じたのは、『先にファルダ、ファイルを作成しておく』
これをするとなると、何が必要で何の値をどこに渡すなんてことも考えれるから中々傑作だと感じている。
ただ、全体構造が見えていないと出来ない手法ではあるのが欠点。
ま、何回でも作り直しちゃえば良いのよ！
「全ての仕事はやり直しになるから、さっさと全体像を描け」
これに尽きます。
どうせやり直しだから、早く作って早く修正が出来るように持っていけば良いのよ！
気持ちを楽にして頑張って行きましょい！
ハードルを低くする
ハードルを低くする
大きいプロジェクトを動作させるより、小さいプロジェクトを複数動作させる方がエラーを発見しやすかったり、改修も楽になる
欠点として、ファイル、モジュールの数が多くなる
TDD(テスト駆動開発)
サンドボックスなどで動作(テスト)を確認してから本プロジェクトへ適用させる
各動作が検証済み→パズルのように組み合わせるだけ
高いハードルは飛び越えるのが大変だが、低いハードルなら数は多いが飛び越える為の力が少なくて済む
高いハードルは細分化して低いハードルをたくさん作る→確実にゴールを狙いに行く事を優先にする
普段着1種類ってお金持ってる人の特権？
スティーブ・ジョブズは服を1種類しか持たない→脳にも考える力の容量があるため、服を選ぶ為に考える力を消費させない
服を1種類しか持たないって結構お金が必要になると考える
主に気温に関する部分
もし、長袖しか着ないなら夏場は地獄
部屋の中では冷房が必要(電気代)
移動はタクシーが必要(タクシー代)
もしくは、住みやすい土地への移動
1種類しか持たないと言う選択肢は現状だと苦しいと感じる
Androidアプリ開発【Button イベント】
Android Studioの操作にようやく慣れたような慣れてないような何とも言えないひろ㌧です！まだまだ使ってない機能とかたくさんあるんだよね！きっと！
Androidアプリ開発の学習のため、Androidの公式developerのTrainingというものを使っています！
codelabs.developers.google.com
前回の記事
Androidの基礎01：初めてのインタラクティブUI
1.Toastの表示
Toastとは、通知みたいなもので一時的に画面の下の方に出てくるポップアップのこと
下図の場合、「Hello Toast!」と表示されているものですね！
Toast表示
実際にToastを表示するコードはこちら！
Toast toast = Toast.makeText(this, R.string.toast_message,
Toast.LENGTH_SHORT);
toast.show();
1-1.Toast クラスの変数を定義する
第2引数：R.string.表示させたい文字が格納された変数名（res/values/strings.xml内で定義）
第3引数：LENGTH_SHORTは2秒表示させる
LEMGTH_LONGは3.5秒表示させる
1-2.Toast変数名.show()でToastを表示させる
2.Buttonクリック時にイベントを発生させる
2-1.res/layout/Buttonが配置されているxmlを開く
2-2.ButtonViewに下記を追記
android:onClick="イベントメソッド名"
最初エラー表示が出ますが、ここで、WindowsならAlt + Enter、Macならoption + Enterで自動生成してくれます！本当に便利！何でも試せるので使ってちょ！
生成したメソッドにButtonがクリックされた時のイベントを記述していく
（カウントアップ、Toast表示、画面遷移など！）
Buttonのイベントの記述の仕方は他にもまだまだあるので、気になる方は調べてみてくださいな！
codelabs.developers.google.com
それではまたー！
Androidアプリ開発 【Hello World】
最近Androidアプリの開発の勉強をさせて頂いているひろ㌧です！
学習テキスト的なものがないかと思い探していましたところ...
Androidの公式developerで良さげなやつがあったので、今回からトライしてみようと思います！
まずは、基礎から始めましょう！
Androidの公式developerを参考にAndroidアプリ開発について勉強して行きます！
Androidの基礎01：Android Studio と Hello World
この章でやったことを記述して行きます！
1.開発環境の構築
IDE（統合開発環境）Android Studioのインストール
Androidアプリの開発に必要な要素が揃っているものです！
2.仮想デバイス（エミュレータ）を設定
実際に作成したプログラムをテスト、シュミュレーションしたい！
実際に存在する端末を設定してそれを画面上で表示させテスト出来ます！
余談ですが、実機によるテストも可能です！
3.お決まりの「Hello World」を出力
画面が生成出来たら、そのまま実行することで、「Hello World」と表示されます！
ちゃんと環境構築出来たよね？の確認ですね！
実際の表示画面↓
4.Log出力
エラーが発生した時にデバックの方法として、ログの出力で変数に値が入っているのかを検証したりします。
その時にこれを使うと良いですよー！
Log.v("MainActivity", "Hello World");
それぞれの引数はこんな感じですねー！
第2引数に文字型で変数とか入れてあげればその変数に入っている値を取得出来るよ！
本日はここまで！
オプション課題として「Hello World」の出力部を「Happy Birtyday △△△」とかに変更して、誕生日を祝ってあげようなんて粋な課題もありますので、トライしてみてください！
それでは〜！
