忙しくて更新できませんでした；；って書いてるブログの寿命そこから数週間説

表題の通り、仕事が忙しくてサボってました。

仕事との両立ってみなさんどうしてるんでしょうね。

で、その仕事が落ち着いてきたので更新します。

少しでも寿命を伸ばしていきましょう。

今までは、３日に１記事更新を目標としてきましたけど
これがなかなかしんどそう。

今とかは時間ができたのでそれも無理じゃないけど今後また忙しくなると思うとそれは厳しいかも。

というわけで、目標とか無しで気が向いた時に適当に更新する方向に修正。

目標持ってやるのも大事だけど、気負ってやって疲れて結局何もできないみたいのが最悪だからね。

とりあえず、時間ができたということで今後の更新予定というか学習予定について考えてみる。

今まで書いてきた記事の中でやりたいと思っていたこと

・Rx
・紹介した個々のライブラリについてまとめる
・描画の処理について掘り下げる話

ブログ内で云々言ってたものはこんなもん？

けど考えてみるとこの辺の話って割と細かい話なので一旦後回しでいいかなーと

それよりも自分がこの時間のある時にやっておきたいことがありまして・・・

Kotlinの勉強です。

JavaとSwift触ったことあるからってんでなんとなーく今使っているんですが

実務と並行しながらなもんでガッツリ時間使っての勉強はまだしてない。

というわけで、今更ながらkotlin始めます。

まあ、kotlinばっかではなく、実務とか普段の生活の中で書きたいことが生まれたら都度都度書いてきます、そのへんは柔軟に。

あとブログの書き方についても一つ

自分、エディタってのを全然使ったことがないもので

業務中にたまーにエディタ使って〇〇やってーって言われても？？？となってしまうんですわ。

まあ確かにメインの業務では使わないけどプログラマーとして使えるようになっておかないとなーと思ったりしたりしてるので

ブログの記事作成をエディタでやろうと思います

奇しくも最近 myMacBookPro を購入したので viエディタでやろうかなーと。

Vimって文章書くためのエディタじゃないんですけど

まあ、書けない事はないでしょう

とりあえず慣れるためにVim使います。

記事の中身はviでやって、装飾ははてなブログの色々を使ってやる予定。

本当ならHTMLで全部上手いことできるのがベストなんでしょうけど、本業もおぼついてない時に、実務と全然関係ないHTMLの勉強を始めるのもなんか違うと思うので、まあそれはおいおいということで。

あと、今までの記事見返してると、ブログの見栄えもよろしくないなーと思うのでそこも課題。

まとめると

・kotlinの勉強始める

・文章はVimで書く

そんな感じなので次は一旦Vimエディターの基礎に関する記事をvimエディタを使って書きましょうかね。

その次からkotlinで。

【Androidプログラミング】SurfaceViewの動画にぼかしを書けたくて色々やったけどできなさそうだった話

※関係ないアイキャッチ

やりたかったこと

surfaceViewで再生している動画に対してリアルタイムでモザイク処理をかけたかった。

ざっと調べるとOpenGLを使って描画処理自体に手を入れることで実現できそうだったけど
OpenGL使えないし、簡単に済ませたかったので別の方法を探していた。

動画の上に一枚フィルター噛ませてうまい具合にできないかなーと。

WindowManagerを使ってみる

WindowManagerに"FLAG_BLUR_BEHIND"っていうのがあって、これを使うとブラーが実現できるらしい
が、これはAndroid4.0.4から非推奨で代替メソッドもない模様。

こんな便利メソッドをなぜ使用不能にしたのか・・・。

developer.android.com

外部ライブラリを使う

調べているとBlurryというライブラリを発見。
簡単なコードで画面にブラーをかけられるっぽいので試してみる。

Blurry.with(this.getActivity())
.radius(10)
.sampling(2)
.async()
.onto(rootView);

上のコードは"rootView"（画面全体）に対してブラー処理を行うもの。
SurfaceView外のUIにはガッツリブラーがかってくれたが、肝心のSurfaceViewにはかからず、無事死亡。

聞くところによるとSurfaceViewはそもそもViewとしての作りが他のものと違うから、同じように扱うのがそもそも難しいかもとのこと。

ついでに以下のようにすると、対象のviewをキャプってそれをブラーかけたものをimageViewに表示してくれる。この方法でも無理だったけど。

Blurry.with(this.getActivity())
.radius(25)
.sampling(2)
.async()
.capture(view)
.into(imageView);

ただ、このライブラリなかなかに便利だったので、機会があれば使っていきたい。

github.com

BlurMaskFilterを使ってみる

Paint paint = new Paint();
BlurMaskFilter filter = new BlurMaskFilter(10,BlurMaskFilter.Blur.NORMAL);
paint.setMaskFilter(filter);

mainRender.setLayerPaint(paint);

結論からいうとこのコードは無理。
そもそもPaintにフィルターをかけるとしても、その画を描画するその処理に対してフィルターを割り込ませる必要があるのにこれはそれをしていない。

ちなみに割り込ませたとしてもBlurMaskFilterはビットマップに当てる場合には簡単にはいかないっぽいことは以下。
kinsentansa.blogspot.com

ちなみにこんなことをやっても無理だった。

Paint paint = new Paint();
BlurMaskFilter filter = new BlurMaskFilter(10,BlurMaskFilter.Blur.NORMAL);
Canvas canvas = holder.lockCanvas();
canvas.drawPaint(paint);

holder.unlockCanvasAndPost(canvas);

とりあえずsurfaceViewと画面描画に対する理解が甘いのでそのへんの勉強と

OpenGLもやらないとダメなのかなあ・・・

【Androidプログラム】Androidのgradleを歩いてみる

※関係ないアイキャッチ

Androidのgradleについて
なんとなーくで、なんとなーく使っている感じなのでこれを機にざっとまとめる。

そもそもgradleとは

Java環境におけるビルドシステムのこと。
Groovyという言語で構築を記述することが可能。

JavaのビルドシステムはJavaではなく別の言語とのこと
正直しんどいと思ったけど、記述方法はかなりJavaに似ているらしくそこまでハードルは高くはないとのこと。

gradleとはなんぞやということについては以下が詳しい。

mixi-inc.github.io

ここに大体のことは書いてあるが、今回は勉強の意味もあり自分で歩いてみたいと思うので
以下に自分が前に触ったgradleをベースに上からなぞっていく。

歩き始める

apply plugin: ‘com.xxxx.xxxxxxxxx’

プラグインの宣言を行う。
kotlinなどの一部ライブラリを使う際にプラグインが必要な場合は、ここにも記述。

repositories{
　jcenter()

　maven{url ‘https://maven.google.com’}
　mavenCentral()
　
}

使用するリポジトリの記述。
jcenter()やmavenCentral()はライブラリを提供してくれるリポジトリの名前。

これを記述することでjcenterやmavenCentralで公開されているライブラリが使えるようになる。
なお、ライブラリによってはCentralの方で公開されていない場合があるので
maven{url ‘https://maven.google.com’}のようにURLを指定してやる必要もある。

android{
　compileSdkVersion 23
　buildToolVersion “23.0.1”

　flavorDimensions ”default”

　testOptions.unitTests.includeAndroidResources true

　kapt{
　　generateStubs = true
　}

androidのビルドの設定を行うところ

compileSdkVersion 23、buildToolVersion “23.0.1”ではcompile>build するのに必要なSDKやビルドツールのバージョン指定。

flavorDimensions ”default”でBuildValiantの設定を行う。

”BuildValiant”については以下が詳しい。
qiita.com

”default”だと単純に buildType*flavor で設定されるっぽい。

testOptions.unitTests.includeAndroidResources true

Robolectricというユニットテストをするツールを使うための設定。
Robolectricについては以下が詳しい。
qiita.com

kapt{
　　generateStubs = true
　}

kaptとはkotlinでJavaのアノテーションを使うのをサポートするツールで、ここはその設定を行っている。

generateStubをtrueにしておくことでannotation processingで生成されたクラスからのエラーを回避できる。
しかし、trueの場合ビルドが遅くなるのでデフォルトはfalseになっている。

defaultConfig{

　　//端末やストアにおいてアプリを認識する一意のID、アプリ公開後は変更不可
　　//https://developer.android.com/studio/build/application-id?hl=ja
　　applicationId “jp.sample”

　　//最低SDKバージョン
　　minSdkVersion 23
　　//推奨SDKバージョン
　　targetSdkVersion 23

　　//アプリのバージョン設定
　　//https://developer.android.com/studio/publish/versioning?hl=JA
　　versionCode 1
　　versionName “1.0”

　　//マニフェストに埋め込まれる変数の値を設定
　　//　　　　　　　　　＝[変数名 : 値]
　　manifestPlaceholders = [scheme_name:”sampleApp”]
　　
　　buildConfigField “String”, “SAMPLE”, “\”sample\””

　　testInstrumentationRunner “android.support.test.runner.AndroidJUnitRunner”
　}

defaultConfigで各フレーバーで適応されるデフォルト設定を行う。

manifestPlaceholders でマニフェストに埋め込まれる変数の値を設定する。

buildConfigFieldはビルドの段階から値を指定できる変数で、定義された変数は BuildConfig.java に定義され、そこから呼び出すことが出来る。
buildConfigField “型名”, “変数名”, “値” 　で変数を定義できる。

testInstrumentationRunner “android.support.test.runner.AndroidJUnitRunner”
はJUnit4形式のテストをするために必要で詳細は以下に譲る。
y-anz-m.blogspot.com

　signingConfigs {
　　//デバッグ時_デバッグ時のみ適応される仮の内容
debug {
storeFile rootProject.file('debug.jks')
storePassword 'storePass'
keyAlias 'aliasKey'
keyPassword 'keyPass'
}
　　//リリース時_キーストアの内容
release {
storeFile rootProject.file('release.jks')
storePassword 'storePass'
keyAlias 'aliasKey'
keyPassword 'keyPass'
}

signingConfigs は署名設定を記述する領域。
後述のbuildType毎に設定することができる。

buildTypes{
　　debug {
debuggable true

　　　 minifyEnabled false

shrinkResources false

signingConfig signingConfigs.debug

　　　applicationIdSuffix ".debug"

testCoverageEnabled true
}

release {
debuggable false
minifyEnabled true
shrinkResources true
testCoverageEnabled false
signingConfig signingConfigs.release

proguardFiles( getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' )
}
}

buildType毎の設定。

debuggableはtrueにすると汎用のデバッグキーストアにてAndroid端末でAPK署名を設定できるようになる。

minifyEnabled はfalseにすることでコードの圧縮を有効にしている。

shrinkResources はfalseにすることでリソースの圧縮を有効にしている。

signingConfig signingConfigs.debugでは署名情報の指定をしている。
今回の場合では、デバッグ用の署名情報を指定。

applicationIdSuffix ".debug"では該当のビルドタイプでビルドした際に
アプリケーションIDに付加させるセグメントを設定。

testCoverageEnabled trueではコードカバレッジ（コード使用率の測定）を有効にしている。

proguardFiles( getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' )
ここではコードを難読化している。
リバースエンジニアリングなどのセキュリティ対策の一環として行う。
developer.android.com

sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
}

sourceSets ではソース参照先の指定を行う。

productFlavors {
develop {
minSdkVersion 23
}
product {
minSdkVersion 23
}
}

productFlavors もbuilldTypeと同様でビルド時の設定を行う。
2つを組み合わせることでバリエーションを持ってビルドを行うことができる。

lintOptions {
　　//ここをfalseにすると静的なコード解析エラーが発生してもビルドを継続する
abortOnError false
}

lintOptions ではコード検査ツール"Lint"の実行時のオプションを設定できる。

abortOnError をfalseにすると静的なコード解析エラーが発生してもビルドを継続する。

jacoco {
toolVersion = "0.7.7.201606060606"
}

jacoco はJavaの単体テストでコードカバレッジのレポートが出力できるライブラリ。
ここではそのバージョンを指定している。

dependencies {

compile "com.android.support:appcompat-v7:${support_lib_version}"
・
・
・

}

dependencies にはアプリケーションの依存関係を記載する。
主には使用するライブラリを記載する。

ちなみに上で使用している"compile"は廃止予定のコンフィグレーションなので"implementation"で行う。
developer.android.com

また、gradle内にはgroovyを使用してメソッドも記述可能で
それはAndroidStudioの右側のgradle窓で使うことができる。

早足でしたがざっと以上。

今回はザックリでもいいから全部読むのが目的でしたが
今後は個々に見る機会も作れればと思う。

【雑記】2019年5月時点_NURO光の工事がネットの情報よりもだいぶ遅くなってる件

NURO光といえばとにかく速くて安い！

だけど、工事が遅い！！

・・・という情報は色んなまとめやらブログやらに載っております。

で、自分もPCゲームやらを楽しんでいるので

どうせならNURO契約するかー

と、申し込んで工事待ちをしている最中なのですが・・・

どうやら、巷で出回っている情報よりも長く待たされそうだということがわかってきました。

自分の今の状況を説明させていただくと

NUROの申し込みした
一回作業の方が来られて建物を見た
どうやらマンションの共有部に工事を入れないとダメみたいだった
工事について管理会社と大家は快諾
工事待ち

という状況。

で、サポセンにどのくらいかかりそうなのか？と聞くと

「わからない」

とのこと。

まあ先に工事の準備をしている物件で管理会社と折衝してるんだろうから
そりゃわからんだろうし時間もかかるんだろなーとか思いながら
Twitterで「NURO　工事」とかでエゴサしてみると

「友達がNUROの工事で半年待たされてる」

「NUROの屋内工事終わったけど、次の屋外工事は早くても8月らしい・・・」

みたいな話がけっこーな数出てくる。

あれ？事前に見たまとめサイトとかブログでは長くても三ヶ月！とか書いてなかったっけ？

てなわけで、それらのサイトを確認してみると

「念願のNURO光、三ヶ月も待たされたけどやっと繋がった！」（投稿日2017年）

「申込みから二ヶ月！屋外工事終わりました！」（投稿日2016年）

みたいな感じでかなり情報が古い。
サイトの更新日を見てなかった私もアレですが。

てな感じなので、やはり情報の鮮度が高いのはツイッター
今後、この手の商品に手を出すときはGoogle先生よりもTwitter先生のほうが優秀かもしれませんね。

で、ざっと調べた感じNuro開通まで半年コースがかなり濃厚な自分はどうしたかというと。

幸いなことに、自分のマンションにはフレッツ光のマンションタイプがすでに引かれていたので
Nuro開通まではそれを使って気長に待つことにしました。

この手のことを調べてると怒って解約してる人も多いんですが
プロバイダやら契約プランやら選んでいけば、解約手数料もかからずに短期間だけ別回線使うこともできるし
Nuroで契約者向けに安く貸し出しているモバイルWifiもなかなか優秀なので
対応の悪さにイライラせずに、色々と模索してはどうかなと思いました。

対応は悪くても回線の優秀さはホンモノらしいですしね。

【Git】特定のファイルをGitの追跡対象から外す

※関係ないアイキャッチ

表題のことについて
よくあることかと思います。

色んなブログで取り上げられている内容ですが
自分の勉強のため、以下にまとめていく。

.gitignoreに登録する

もっともメジャーな手段かと思う。

無視設定を行いたいフォルダ内に".gitignore"というテキストファイルを作成。
その中に、無視したいファイル名やらディレクトリやらファイルの種類などを書いていく。

それぞれの書き方やらは以下のリンクが詳しい。
qiita.com

techacademy.jp

この方法で追跡対象から外すと以下のような効果が期待できる。

git add .gitignore でこのテキストファイル自体もバージョン管理に含めておくことで
そのプロジェクトを共有するチーム全員が無視すべきファイルとして
.gitignoreの設定を共有できる。

project/.git/info/exclude に登録する。

登録する方法は.gitignoreと同じでファイル内に無視したいファイル名やらを記載します。

この方法を使用するのはバージョン管理に含めずに無視するファイルを設定したい場合。
無視するファイルが自分の作業環境に依存するならばこの方法を取る。

git config --global core.excludesfile $HOME/.gitexcludeを使う

登録方法
git config --global core.excludesfile $HOME/ .gitexclude
echo "無視するファイル名.拡張子" >> $HOME/ .gitexclude

この方法を使うとこの登録を行ったユーザーで作業する限り
指定したファイルは常にGitの追跡対象から外れる。

この設定はユーザーに対して適用されるので
該当のユーザーで作業している限りは全てのプロジェクトに対して共通適用される。

3つほど方法を紹介したけど
.gitignoreが一番使うかな。

【Git】いまさら始めるGitの勉強_勉強した内容のメモ（ブランチ・マージの操作編）

※関係ないアイキャッチ

※マージについてのメモ※
pullを行った際に、互いにGitが進んだ状態だった場合には、２つのコミットのマージが行われる。
二つのコミットをマージした際にはマージコミットというコミットが行われ、このマージ自体に対してコミットIDが発行される。

gitの設定の確認
git config -l
※remoteやbranchの設定を確認可能

pull の詳細な意味
git pull “アクセス先” “ブランチ名”
→”アクセス先”の”ブランチ名”から pull を行う。(“ブランチ名”を省略した場合、masterが自動的に選択される)

git pull origin master
→origin の masterブランチ からpull を行う。origin がどこに設定されているかは git config -l で確認できる（remote.origin.url の部分）。

※競合マークの見方※
<<<<<<< と >>>>>>> に囲まれている部分が競合している箇所
=======の行を境に二つの修正が並べられる。

以下に例示

　　<<<<<<< コミットID1

　　1の修正

　　=======

　　2の修正

　　>>>>>>> コミットID2

現在作業しているブランチを確認する
git branch

新たにブランチを切る
git branch “新規のブランチ名”

ブランチを移動する
git checkout “ブランチ名”

ブランチログを視覚的に確認する
git log --oneline --graph --decorate --all

外部リポジトリを origin/master にコピーする
git fetch

指定のブランチを、自分が今いるブランチに合流させる
git merge “指定のブランチ名”

pullをfetchとmergeで表現する
git pull = git fetch + git merge origin/master
fetch で外部のブランチをローカルに取り込み、自分のマスターに合流させている

【Git】いまさら始めるGitの勉強_勉強したコマンドを書いてく

※関係ないアイキャッチ

表題の通り。
前回に紹介した本の内容に沿って学習中で
その中で出てきたコマンドを忘れないように以下にバーっと書いていく。

現在のディレクトリでGitを使う

git init

指定のファイルをGit（インデックス）に追加する

git add “指定のファイル名”

インデックスの内容をリポジトリにコミットする

git commit -m “コメント”
※ -m をつけなかった場合、viエディタが起動してメッセージの入力を促される。

ログを見る

git log

簡潔なログを見る

git log　--oneline

過去のコミットを比較する

git diff “コミットID１”　“コミットID２”

指定したファイルを指定のコミットの状態に戻す

git checkout “コミットID” “ファイル名”

現在のHEADがどのコミットIDを指しているかを表示する。

git rev-parse HEAD

現在いる階層以下の内容を全てインデックスにaddする

git add .

add と commit を同時に行う

git commit -a -m “コメント”
※このコマンドで自動的にaddされるのはインデックスに既にあるのみ。つまり新規のファイルは作業用フォルダから git add コマンドでaddしてやる必要がある。

最新のコミットの内容を確認する

git show
※ git show “コミットID”で該当のコミットの内容を確認

指定のファイルをインデックスから取り除く

git reset HEAD “指定のファイル名”

インデックスにある指定のファイルをコミットIDの状態にする

git reset “コミットID” “指定のファイル名”
＝コミットIDがHEADの場合、リポジトリ（HEAD）の内容とインデックスの内容がイコールになるので実質的にアンステージされる。

作業フォルダとインデックスの状態をHEADの状態にリセットする

git reset --hard HEAD

コマンド書式を確認する

git ‘該当のコマンド名’ -h

gitの状態を確認する

git status

最新コミットのコメントを修正

git commit --amend
※このコマンドで表示されるviエディタにて変更
※--amend はHEADのコミットを上書きする

指定したファイルをインデックスと作業フォルダから消去する。

git rm “ファイル名”

インデックスと作業用フォルダにあるファイルのリネームを行う

git mv “元ファイル名”　”リネーム後ファイル名”
※インデックスと作業フォルダ両方に同名のファイルがある必要がある

作業フォルダ以下のファイル全ての変更、追加、削除等の変化をインデックスに登録する。

git add -A

※ここの操作を色々試しているときに"detached HEAD"になってしまったので、その解消法は以下。
qiita.com

プロジェクトをHEADの一つ前の状態に戻す

git reset --hard HEAD~
※HEAD：最新のコミットの状態
HEAD~：最新のコミットの一つ前の状態
HEAD~~：最新のコミットの２つ前の状態
HEAD~2：最新のコミットの２つ前の状態

対象のファイルをインデックスからのみ削除する

git rm --cached “ファイル名”

特定のコミットをなかったことにする

git revert “コミットID”
※revertを行なった場合、revertをしたことがログに残る

特定のコミットを削除する

git rebase -i “消したいコミットの前のコミットID”
※上記コマンドで起動するvi上で消したいコミットIDを”dd”で消す。

一つ前のコミットとまとめる

git rebase -i “まとめたいコミット二つのコミットIDを含められるコミットID”
※このvi上でまとめたいコミットの新しい方のIDに squash を指定。

最新コミット
・
・
・
まとめたいコミット１
まとめたいコミット２
・
・

上記の場合、まとめたいコミット２より過去のコミットIDを指定する。

いくつか前のコミットを修正する

git rebase -i “修正したいコミットを含むコミットID”
※このvi上で編集したいコミットIDに edit を指定、するとHEADが該当のコミットIDに移動した状態になり、コミット待ちの状態になる。その状態でプロジェクトを修正し、add とcommit --amend を行う。最後にgit rebase --continue を入力して元の状態に戻す。

物量が増えてきたので一旦このくらいで。