Android studioの設定

【Android Stadio備忘記録】
◆インストールおよび実行は管理権限で行うこと
◆Android StadioでADBなどが起動しない　→　セキュリティソフトが邪魔をするのでブロック解除
◆
SDK＞extras＞intel＞Hardware_Accelerated_Execution_Managerで、
その中にある「intelhaxm-android.exe.exe」を実行してインストールをする。
　1024MBなど変更可能

◆インストール方法
1.JAVAのSDKのダウンロードとインストール
2.JAVA_HOMEとPATHの設定
3.Android Stadioのダウンロード
4.Android Stadioを管理者権限でインストール
　インストール先　C:\Program Files\Android\Android Studio
　SDK　C:\Android\sdk
　エミュレーターの設定画面　1024MB

◆設定
1.Welcom to Android Studio から「Configure」を選択、「SDK Manager」を更に選択
　Android SDK の画面から、4.4以上を選択し、インストール
2.「Launch Standalone SDK Manager」をクリック
　Extras　
　　Android support Repository
　　Android support Library
　　Google Play Service
　　Google Play Repository
　　Google USB Driver
　　Intel Hardware Accelerated Execution manager
　をインストール
3.PATHの追加
　sdk/platform-toolsとsdk/toolsを追加

android studio

android studioをインストールをして最初の関門をクリアしたと思ったら、Updateをすると、またエミュレーターが起動しない。
難しい設定だ。慣れるといいのだが、慣れる前にUpdateが行われるために・・・
今後は、Updateをせずに利用することにしてみる。

設定で若手組が混乱するのがわかる。
この辺の説明がないので、なおさら混乱しそう。

備忘として記録

設計書の品質を高めるには-2

次に基本設計について

• 入出力の確定(必要とするものは網羅）
• 処理概要
• 処理方式(あくまで概要)
  システム方式、ネットワーク方式、運用方式、システム障害、共通処理
• ハードウェアの全体概要
• 共通アプリケーション処理(概要)

全体構成をまず考えて、概要全般をかき、あとから詳細化。
整合性から、全体像から部分を構成

さらに性能などの諸要件は、総合テスト仕様書全般の概要を記載しておく。
要は設計書に具体的な処理内容に触れるものや例文は総合テスト仕様書に記載し、品質管理面の強化を図ることが重要です。

設計書はあくまで対顧客、そして総合テスト仕様書の結果が全てです。
これを忘れると、単なる言葉遊びではないですが、顧客側の思いとシステムを作る側の思いが整合していない場合が多いです。
顧客によっては、例文のほうが理解しやすいし、システムを作る側の品質も向上します。

設計書の品質を高めるには-1

設計書をかくことが下手な人が多い。ベンダーなどによってさまざまな書式があるが、なぜ必要とする設計書なのかを理解していない人が多い。
各工程は連続にあり、それぞれが独立しているのではない。

また要件定義などで未確定事項が多い、また新技術で、どのように設計書をかくか悩むことも多いだろう。
基本を忘れないでほしいことがある。

要件定義で必要なのは、何をするのか、どのように行うのかを明確にする。
単なる要望書でもなく、希望的憶測でもないのは確かであるが、多くのものは憶測や、希望的見解を述べて、技術的根拠がないものも見受けられる。
技術的検証などの工程があれば問題はないが、これがない場合はどうするのか。

ベンダーによっては、
1)予算などが豊富なベンダはパイロットチームが、先に技術的検証をしながら、工程単位に確認を行う。
2)予算のなし、や製造で何とかしようとするベンダーは確認をせずに設計書を固める
圧倒的に多いのは、2)のほうで、1)を行うベンダが少ないのが実情
品質が悪くなったり、手戻りが多く、工数が激増するのはこのことも一つの要因。

基本的には小さくともパイロットを作成し、確認を行うことが重要である。

Spring - 01

DIについて、
基本的な事項は省略

DIの目的について
①POJOの利用
②DIコンテナからnew演算子を消す
　⇒FactoryMethodなどのデザインパターンの排除
③DIコンテナから渡されるインスタンスをインタフェースで受け取る
　⇒インタフェースのコンポーネント化
　⇒クラス(インタフェースの実装)が変更・拡張されても、それを利用しているクラスのへの影響範囲を極小化できる。
　⇒利用しているクラス(インタフェースの実装)を置き換えてもテストが可能。

DIの利用範囲
①コントローラとサービスとの依存関係
②サービスとDAOとの依存関係

アノテーションとDI
①インスタンス変数の前に@Autowiredをつけると、DIコンテナがそのインスタンス変数の型に代入できるクラスを@Componentがついているクラスの中から見つける
　⇒インジェクションをする
　⇒インスタンス変数以外にメソッド宣言前でも可能
②DI方法はXML定義
　⇒Bean定義ファイルが必要
　
　　@Autowired、@Resourceを利用する場合の宣言

　　@Conpmnent、@Serviceなどのコンポーネントを利用する場合の宣言
③インジェクション可能なクラスは1個
　⇒複数名がある場合、@Qualifierを使用する(@Componentに名前を使用する)
　⇒Bean定義ファイルを利用する