呟いた事

予告：片桐さんがUWPアプリを作ろうとしています

片桐　継（Tugu Katagiri） — Sat, 28 May 2016 12:36:00 GMT

今、修羅場です。

現在、このハムスターは某業界でお仕事していますが、大人の事情で大変なことになっています。

やることやらお仕事やら納期やらがたくさんです。休日は休養です。

なので、一段落しないと、DECODEのおさらいもできません。

作りたいUWPアプリあるのにorz

ということで、６月あたりには、タイトルっぽいことをはじめてみようと思います。

決意表明、それだけですｗ

Open Live Writerを使っています

片桐　継（Tugu Katagiri） — Sun, 27 Mar 2016 22:33:00 GMT

2016/2/13にVer.0.6.0になっておりまするですよ。

サイトはここ：http://openlivewriter.org/

今は亡き？（でもないがｗ）　Microsoft Windows Live Writer のオープンソース化した後継ソフトウェアなんだけど、使い慣れてしまうと、これの再インストールができないのはつらいのよねｗ

なので、この子を入れてみることにした。これの便利なところは、画像いれたり、PlugIn設定すればSyntaxHighlighterが使えたりするところ。

といっても、公式サイトでは、まだPlugin機能はComingSoon、、、なのさ。でも、ソース見ると実際には仕掛けがあるっぽいので、やってみようかなってことで、探してみた。ら、すでに、あったよｗ　プラグインｗｗ

SyntaxHighlighterを仕込んでみる

ちゃんと、作り主が対応済だってさーｖ

サイトはここ：http://richhewlett.com/wlwsourcecodeplugin/

ここにOpenLiveWriter用のファイルがある。

でもって、これをダウンロードして、フォルダにセット。

セット先の説明はここ。

Option 1: By default OLW will look in the Plugins folder inside the application path (e.g: C:\Users\UserName\AppData\Local\OpenLiveWriter\app-0.5.1.3\Plugins) but this path will change as OLW auto-updates itself (i.e. the app number will change). To install copy the plugin (and its supporting txt file in the downloaded Zip package) to that path using the latest …\app-x.x.x.x folder present on your system. Each time OLW updates to a new version you will need to re-copy or move the plugin into the new …\app-x.x.x.x folder.

要するに、OLWのプラグインフォルダにいれればいいらしい。

なので、入れてみた。そして、OpenLiveWriterを起動して、ファイルメニューからOptions選んで

おー、導入成功ｖ

Public Class Hoge

	Property HogeHoge As Sting

End Class

うむ、あとはこっちの設定かorz

いろいろすっ飛ばしたからなぁ＜を

いろいろを引っ越し予定

片桐　継（Tugu Katagiri） — Mon, 08 Sep 2014 03:34:00 GMT

プライベートも含めて

なので、今後は
ここを気にしてくれると有難いかも。

生きていくのってホント大変だよね。良い子のミンナは、私みたいな人間にならないようにｖ

ああ、そうか、F#は、.NetFramworkのライブラリも使えるんだっけ。

片桐　継（Tugu Katagiri） — Mon, 11 Aug 2014 16:03:00 GMT

F# でリスト要素の追加と削除は、イテレータや演算子を使って、ちょっと自分でアルゴリズムを書く必要があるみたい。

ここでカリー化とか再帰とかなんだかんだと数学をほとんどやってない人にとってはとっても難しい用語や考え方が出てくるわけなんだけれども。

確かに、細かい条件を指定して、便利に確実に高速に処理できる方法があり、それを実践していくのはとても良いこと。でも、分析分解してコードに変換していくにあたって、対象が極めて単純な処理の時には、逆にメンドクサくなっちゃう。

結局、わがままなんだけどねｗ

で、やった解決策。

System.Collections.Generic.List<T>

を使ってリストオブジェクトを作成して、そのメソッドを使ってやってしまえ、という……。

Xamarin使ってると、.NetFrameworkの存在を忘れてしまうよねｗ　実は使えるのにね、使ってるのにね。

サンプルはC#やVBしかないかもしれないけど、型が違うわけではないので、そこは素直に使えばOK。

そしてLinqでさくっと検索や取得。F# 本来の良さはかなり失われているような気がせでもない。＜を

そういえばLinqの正体ってイテレータとか、えーなむあぶる、とか、なんかそんな話を昔していたようなｗ

ふむ、何もかも懐かしいｗ

JUnitのassertはどうして書くのが良いんだろうか？

片桐　継（Tugu Katagiri） — Wed, 23 Jul 2014 10:20:00 GMT

ちょっと、迷って困ってた。

JUnitのテストを書いてて、

とある整数型リストは、1,2,3,4 の四つの要素を持っているはず。
リストの要素の順番はどうでもいいが、要素の中身はこうであるはず。

ってのを、JUnitのassertで検証したい、となった時、書き方としては、

assertTrue(actItem.getRolled().containsAll(Arrays.asList(1, 2, 3, 4)));
assertThat(actItem.getRolled().containsAll(Arrays.asList(1, 2, 3, 4)), is(true));
assertThat(actItem.getRolled().toArray(new Integer[0])
　　　　　　　　, IsArrayContainingInAnyOrder.arrayContainingInAnyOrder(1, 2, 3, 4));

と、こんな風に、色々とあるんだけど、どれが判りやすいんだろうか、正しいんだろうか。

考えるネタとして、逆に、このassert文はこれをテストしたいんだな、と、assert文から読み下してみたらどうなるのかなぁと思って、やってみたの。

１２３４の値で構成されたリストを引数としたContainsAllメソッドの実行結果が、trueであることを確かめたい。
１２３４の値で構成されたリストを引数としたContainsAllメソッドの実行結果が、戻り値trueであることを確かめたい。
リストの構成要素を整数配列型にキャストした結果が、並び順関係なく１２３４の要素で構成されていることを確かめたい。

こうなった。なので、この場合、確かめたいことをassertしているのは、３ってことになる。

だって、テストしたいのはContailsAllメソッドじゃないし。リストの要素だし。

といいつつも、私は個人的な好みでシンプルな１が好き。何をassertしたいのか、コメントしとけば良いもん。＜我儘ｗ

でも、個人のお気楽開発ならこんな風に好きにして良いけど、チームでの開発であるなら、こういうの、きっと、どれにしときましょ？とすり合わせた方がいいね。

assertの書き方は、チーム内なり、プロジェクト内なりで、ある程度基準を作っておくと、ここで何を確認したかったのか、仕様の要点が何なのかが判りやすくなって、後から来た人にも、作って忘れちゃってる人にも、親切なテストコードになると思うの。よくある「好きにしていいよ」が一番よろしくないオチ。後で混乱したり、なんでこうなってるの？、これはなにをテストしてるの？が起きちゃうこと請け合い、つか、経験則ｗ

Androidアプリケーションでリソースを呼び出してみる

片桐　継（Tugu Katagiri） — Mon, 14 Jul 2014 10:46:00 GMT

作り始めて、意外と楽しくてメモが増えてるｗ

Androidアプリケーションを作るためのプロジェクトをEclipseで新規作成すると、一杯フォルダができる。

そして、このフォルダたち、それぞれ役割があって、きっと、それらの中でも良くお世話になるのが、resource関連だと思うの。

たとえば、サイコロアプリをつくりたいなーとか考えた時、画面やボタン、メッセージなんかは日本語かもしれないし、他の国の人が使えば、他の国の言葉の表示も必要になる。

そんな時、このリソースファイルに定義をまとめて作っておくことで、色々と作業が楽になるんだなってことが判ってきた。

たとえば、/res/value フォルダのstrings.xml

今は日本語でつくってるけど、国際化対応では、このファイルをフォルダごと増殖させてフォルダ名に国コードを設定して中身を対応しておけば、あとはAndroidさんが使っている人のネイティヴ言語と比較して、使えそうなものをチョイスしてくれる仕掛けみたいね。

とりあえず、日本語で今は作ってるけどｗ

で、話を戻して、そのstring.xmlに、ちょこっと登録。

<resources>
    <string name="app_name">Simple Dice</string>
    <!-- ErrorMessage -->
    <string name="DRIE0001">日本語だよ</string>
    <!-- Setting -->
    <item name="DSIZE_MAX" type="integer">200</item>
</resources>

これだけで、ソースコードからはID：DRIE0001、ID：DSIZE_MAX のリソースとして中身が認識できるようになる。

そこで、Contextオブジェクトを参照できるクラスで、取得用のメソッドを作っておいて、

	public String getResourceString(int ID){
		return getContext().getString(ID);
	}

	public Integer getResourceInteger(int ID){
		return getContext().getResources().getInteger(ID);
	}

あとで、このメソッドにIDを渡してやれば、リソースファイルで定義した内容が取れる仕掛け。IDもR.stringクラスやR.integerクラスに登録された状態になっているのでインテリセンスにでてくるから探しに行かなくても大丈夫。

ソースの中で定数定義やら、メッセージ定義やら、そういう固定リソースなものはファイルに出してしまおうね、って事がお作法。うん、覚えた。

後で国際化するにしても、メンテするにしても、リソースファイルの中で完結してくれるなら何よりだよね。

おもしろいなー。こういう仕組み。

以下、呟き。

リソース読み取ればいいって判ったけど、その取得元になるアプリケーションコンテキストの実体は、どこが保持しているんだろう？

アプリケーション起動時、onCreateの段階でもうすでに実体が存在しているので、OSからアプリケーション起動時に、恐らくはシングルトンで作られて、後はそれを提供していく形になってるんじゃないかなぁと考えてる。まぁ、動かして、アドレス見ればわかることだけど、まだきちんと調べてないｗ

とすると、後続？のクラスたちからコンテキスト使わせるには、そのアドレスを判るように提供する仕組みさえ作っておけば、どこからでもリソース取得できるようになる。具体的には、コンストラクタでコンテキストのアドレス渡してやれば良いってだけだけどね。

ただ、そうすると、反・祖結合、というか、クラス同士の結びつきが相当ベタな形になっちゃうのが、感覚的にどうよ、とか思ったりする。

できるだけ、クラス間って密接な関係取らない方がコード書く時考えること少なくて済むし、バグ探しやすくなるし、リファクタリングしやすくなるし。

そんな風に考えた時、SpringFrameworkってほんと、良くできた仕組みだなぁって思った。

うん、なんとなく、そんなことを思っただけ。

Androidエミュレーターでアニメーションが動かないorz

片桐　継（Tugu Katagiri） — Thu, 10 Jul 2014 12:19:00 GMT

やりたかったこと。とある画像を、ずっとくるくると回転させていたかった。

起きた現象。エミュレーター上では、画面に画像が出るだけで、うんともすんとも言わないorz

ある日、テストの設定を間違えて、充電中だったUSB接続の実機にテストアプリを配置してしまった。

動いてるやん！

悩んだ半日を返せ；；

教訓。低スペックPCではエミュレーターの画面表示が正しいとは限らない。時々は実機で試そう。

覚えたorz

過去記事への、ごめんなさい

片桐　継（Tugu Katagiri） — Mon, 16 Jun 2014 10:11:00 GMT

ひさしぶりに投稿して気づいたのだけれど、闘病生活入るに際して色々と整理した関係で、過去記事のイメージファイルや一部のCGI機能などがリンク切れ等で見えなかったり使えなかったり、不具合が出ています。

整理するのに時間かかるので、ちょこちょこ直していけそうなら頑張りますがが、全部を綺麗に復旧させる気力と体力と集中力がないため、申し訳ないのですが、そのまま放置の方向になるやもしれません。というか、そうなると思うｗ

先にお詫びしておきます。ごめんなさい。

生存確認ｗ

片桐　継（Tugu Katagiri） — Mon, 16 Jun 2014 00:28:00 GMT

えっと、生きてます(笑)

ちょっとヤヤコシイ病気とつきあいつつ生きているので、社会とは隔絶した世捨て人のようになっておりますが、生きております、今のところｗ

最近やっと、集中する、ということが出来るくらいの薬の効き目が身体に出て来てくれています。そこで、少しずつ、社会復帰にむけて、色々と再勉強を兼ねて、Androidアプリなぞ作ってみようかなと思い立ったわけです。

一年近く、開発作業から離れてるわけですから、簡単にはいかんでしょうけれど。

目的がAndroidアプリなのは、自分のNexus7タブレットにいれて、持ち歩いて使いたい、という希望があるからで、Apple製品とは無縁＆貧乏でVSはExpressしかダウンロードできませんわ＆MVPなにそれ美味しい？の立場の私としてはちょうど良い素材なんではないかと考えての事です。

SpringIDE無料だし、Java開発環境無料だし、自家製で売るわけでも配るわけでもないし、色々と気軽に試せるしってことでｗ

今考えていることとしては、アプリの概要やらTodoリストはGoogleDocに保存、一人XPの為の作業管理はTracLightning、ソース管理はGitで。TracLightningにSubversionあるじゃんと思いつつも、うーん、使ってみたいし、的にｗ　ここは色々と使いながら考えてくことにする。

まずはゆっくり、環境構築からはじめますかねー。

あ、でも、開発用サーバーはHyper-Vで作ることになるやｗ

どうなりますことやら。

OneDrive、パスワードが判らなくてアクセスできなくなっちゃってるの。セキュリティコードがどうのとか、ややこしいことされたら復帰する気も萎える。

で、さっそく、Hyper-Vを使ってるWindows2008Serverを久しぶりに覗いてみると、Cドライブが真っ青に。

うん、そうだよね、長い間、ほったらかしてパッチは自動更新でひたすら動かしてたもんね。

空き容量なんて、もう無いよね。

というわけで、お掃除。

だいたい、このCドライブが満杯になる原因は「c:\winsxs」ディレクトリのせい。

エクスプローラから見てみると、すぐに判る。

で、こいつ、何もの？と調べると

WinSxS フォルダーのクリーンアップ
http://msdn.microsoft.com/ja-jp/library/dn251565.aspx

こういう記事を発見。なんとなく、ツールで削除するのが安全そうだと理解するｗ

こちとらWindows2008Serverなので、ちょっと記事の古いものをさらに探して、

大きな Windows コンポーネントストア (WinSxS) ディレクトリが原因で発生するディスク領域の問題を解決する方法
http://support.microsoft.com/kb/2795190/ja

Vista、Windows2008Serverに関連する記事を発見。

コマンドも理解したので、早速実行ｖ

そのまま、ウィンドウ消えるまで放置して、実行終了後に確認。

おー、紫が出てきたー。空き容量できたよー。古いPCにIDEで40GHDDのサーバー稼働なのが我が家ですｗ　SATAなにそれ美味しい？

Cドライブのお掃除までやって、とりあえず休憩。

【TDD Advent Celndar 2012】12日目：虫退治もTDD！＋オマケ話

片桐　継（Tugu Katagiri） — Wed, 12 Dec 2012 17:05:00 GMT

TDD Advent Celndar 2012　12日目の記事になります。

11日目は　@bash0C7　さんの

ハイプレッシャーを克服するためのテスト駆動開発の重要な「二歩目」#TddAdventJp - koeだめ

でした。　プ、プレッシャー……、読んでて、TDDとっかかりの頃の「どーすればいいんだ」的な気持ちを思い出しました。初心忘れずでいたいよね、ってことで、12日目、行きましょう。

TDDは新規開発だけの手法？

いえいえ、リファクタリングにも使えます。

それだけ？

いえいえ、私は、虫退治、ことバグ取り、でも有効な手段だと思っています。

アプリケーション稼働後や総合テスト中にバグ発覚！こんなときだってTDDで退治しちゃえば良いんです。

てなお話を。

手順は次の通り。

バグが発生するまでに呼び出されていたクラスを列挙する。
それらのクラス個々に対して「バグ発生時のデータと条件下で本来どうあるべきだったのか」テストを追加してレッドとなるテストがあることを確認する。
追加した全てのテストがグリーンとなるまで修正作業を行う。
既存すべてのテストがグリーンとなることを確認する。

ポイントは2。バグが発生するまでに、実行されていたクラスメソッドをさかのぼり、「このクラスメソッドではこんなデータや条件の場合に、こうあるべきだった」テストを追加していく下りです。

つまり、テストコードでバグ発生当時を再現していく、ってことですね。もしかしたら、その想定データや条件はすでにテストにあったりするかもしれません。そうしたら、ここはとりあえずテストコードを書く必要はないな、となるでしょう。現場によっては、再現作業の中で、仕様に問題があることが判ったりして、きちっとテストコードを書いていると何かと助かることもあったりします。

そして追加したテストの中に、レッドとなるテストが存在するはずです。

そのテストの対象メソッドにバグが隠れている可能性が高いわけですから、実装コードの修正箇所がしぼられてきます。

ここまでの間に、実装は全く手を付けないで、テストコードだけに着手する、これが大事です。

実装コードに手を付けるのは、レッドとなるテストをすべて洗い出してから、にします。

特定と修正個所が確定したら、ここから実装コードを修正して、グリーンになれば勝利……のはずですが、そのグリーン、追加したテストだけじゃ意味がない。つまり、4.が重要になります。

修正したことによって、既存の「こうなるべき」ところに影響が出ているかもしれません。

今回追加したテストも含め、既存のテスト全てがグリーンとなることを必ず確認することが大事です。

つまり、TDDは新規開発、リファクタリングにのみならず、バグと問題のあぶり出し、修正後の動作担保までとってくれる、現場には有難い手法でもあるのですね。

以下、オマケ話。

私は近年Javaでプログラミングすることが多いので、テストにJunitを使っています。

規模の大きなアプリケーションだと、たくさんのパッケージ、クラスになってきてそれらのテストも膨大です。一連のこの機能だけの結合テストをしたい、なんて時には全部流すと時間がもったいない。

そこでTestSuiteクラス、実行したいテストクラスだけをまとめておける機能が備わっているクラスを使って、テストアプリケーションを作って実行していくことで効率をあげています。

といっても、Mainメソッドの中に対象となるテストクラスの名前がずらーっと列挙されてて、最後に１行テスト実行メソッド書く、という構成の、作業のたびに作り直しのメンドクサイものでしたけれど。

ところが、Junit4では列挙しなくてはならなかったTestSuiteの対象クラスをアノテーションにまとめられるようになりました。アノテーションというのはオブジェクト定義の時に付与できるパラメータのようなものなのですが、これを使うことでMainメソッドの中のコードを触る必要がなくなります。

   1:  @RunWith(Suite.class)

   2:  @SuiteClasses({ AxxxTest.class, BxxxTest.class, CxxxTest.class, DxxxTest.class })

   3:  public class TestSuiteRunner {

   4:      public static void main(String[] args) {

   5:          JUnitCore.main(AllTests.class.getName());

   6:      }

   7:  }

サンプルの2行目の＠マークのある1行に、あちこちのパッケージに散らばってしまったテストクラスをまとめて、その行だけ履歴管理できれば良いのですから、とっても便利。

というわけで、オマケでしたｖ

次はposaunehmさんです。