謹賀新年2015
あけおめことよろでございます。
昨年の振り返り
昨年は公私ともに忙しく、また大きな変化のあった年でした。java力は多少上がったような。
子どもが産まれた
元気に育ってくれています。かわいいです。生まれてきてくれた息子と産んでくれた奥さんに毎日感謝しています。
転職します
koty会社辞めるってよ
— にしざわ こういち (@koty) November 7, 2014
新卒で入社してから12年ほど勤めたSIer*1を退職しました。一年前には全く辞めるつもりはなかったんですけども。。。退職理由はなんですかね。ああいうのに向いている方がやればいいと思います。
今年から新しい会社にお世話になります。幸運にも今の住まいを変えることなくご縁にめぐり会えました。ビバ田舎。
また近況や前の会社との違いなどの感じるところをお知らせしたいと思います。近況エントリーが無い場合はお察しください。。。
昨年のin/out
仕事も忙しく子どもも産まれというわけで、読書やサンデープログラミングはほとんどできませんでした。このブログの記事も正月と無理やり書いたXAML advent calendarだけだし。世のお父さん達はどうやって時間作ってるんですかね。最終的には睡眠時間を削るしかないんだろうか。。。
2か月の休暇
11月12月と有休を消化していました。有休は取れて当然とはいっても、取らせてくれた会社には感謝しています。おかげで育休のような休暇を取れました。家事や育児に参加できましたし、何より子供の成長をリアルタイムで見れるのは素晴らしいことです。休みの間にずり這い、つかまり立ち、ハイハイができた瞬間に立ち会えました。育休は状況が許すんであれば取った方がいいし、より取りやすい雰囲気が世のお父さんの周りにできればいいなと思います。
2か月も休んで何もin/outが無いのかと言われればほとんどありませんでした。子守を優先するとほとんど時間を捻出できず、私的プロジェクトの進捗は自分がやりたかった2割ほどしかできませんでした。
今年の目標
まずは新しい環境に慣れねば。勉強したいこととお仕事の内容が一致する予定なのでまずはお仕事がんばりたいです。
自分はマイペースがモットーなんですが子どもが産まれたことでさすがにマイペースとはいきません。どうにか自分の時間を捻出したいです。ああ、あとオープンウォーターの大会に一つくらい出るくらいに水泳の練習時間も取りたい。。
*1:と言っていいでしょう。
デスクトップアプリケーションインストール考
この記事はXAML Advent Calendar 2014http://qiita.com/advent-calendar/2014/xaml 17日目の記事です。昨日はideaki19さんのWinRT C#/XAML お手軽に実装できる引っ張って更新コントロールの紹介 - ideaki's blogでした。
↓↓このネタでいこうとも思ったのですが、
帳票作るならWPF pic.twitter.com/WxC0fSrSCt
— にしざわ こういち@NEET (@koty) November 26, 2014
こちらでお茶を濁そうと思います。
はじめに
XAMLといえばWPF。WPFアプリ*1を作ったらどうしますか?当然そのアプリを使いますよね。 使うにあたってはアプリを配布しインストールする必要があります。というわけで*2、デスクトップアプリケーションについてまわるインストール方法の選択肢について、本エントリーでは書こうと思います。*3
ようやく書き始めたけど、xamlとはかなり遠くなってしまった。。。
— にしざわ こういち@NEET (@koty) December 15, 2014
WPFをインストールする方法は大きく以下かと思います。
- 利用者がbinをコピーしてインストール
- 開発者がbinをzipに固めて配布し、利用者が解凍してインストール
- XBAPを作成してwebアプリケーションの一部として配布し、利用者がインストーラを(結果的に)起動してインストール
- 開発者がClickOnce配布サイトを作成して媒体を配布し、利用者が配布サイトからインストール
- 開発者がインストーラ(setup.msi/setup.exe)を作成して配布し、利用者がインストーラを起動してインストール それぞれ長短や用途を見てみましょう。
利用者がbinをコピーしてインストール
開発者自身が使う俺得ツールであればコレでもいいかもしれませんね。もしかしたらVisualStudioでF5を押して済む場合もあるかもしれません。
開発者がbinをzipに固めて配布し、利用者が解凍してインストール
開発ツール等、利用者がパソコンの知識をある程度持っている場合はこれでもいいかもしれません。
開発者がClickOnce配布サイトを作成して媒体を配布し、利用者が配布サイトからインストール
ClickOnceは、デスクトップアプリケーションを配置するための技術です。 配置方法は大きく分けて二つあります。*4
利用者がパソコンに詳しくない場合、zipを解凍してくださいというわけにもいきませんし、意図しない場所に配置されてしまう危険もあるでしょう。インストール手順が簡便である必要があるわけです。その場合、媒体のダウンロードとインストールを一気通貫でできるClickOnceは良い選択肢かもしれません。
また、バージョンアップが容易にできるのがClickOnceの大きな利点です。ユーザーは特にすることなく起動時に自動でアプリケーションのバージョンアップが行われます。
短所として、インストール時にレジストリ登録できない等、後に述べるsetup.mxi/setup.exeによるインストールと比較するとできることに制限があります。参照:連載 ClickOnceの真実:第3回 Visual Studio 2005でClickOnceを極めよう (2/2) - @IT
また、媒体を配置しておくwebサーバーにIIS以外ではMIMEの設定が必要です。昨今のレンタルサーバでは.htaccessの設定くらいはできるんでしょうからあまり問題にならないですかね。参考
とっかかりのサイト
ClickOnce 情報のサイト - いっしきまさひこBLOG
ClickOnceでググると一番に出てきますね。こちらに情報がよくまとまっていました。
XBAPを作成してwebアプリケーションの一部として配布し、利用者がインストーラを(結果的に)起動してインストール
XBAPはWPFアプリケーションをwebブラウザに埋め込むための技術です。内部的にはClickOnceが使われています。C/Sの頃使っていた帳票コンポーネント等をwebアプリケーションに移植した後も引き続き使いたいといった場合に一部の画面で使うことになるかもしれません。
もはやデスクトップアプリではなくwebアプリであり、ここで比較するには向かないので割愛。
とっかかりのサイト
開発者がインストーラ(setup.msi/setup.exe)を作成して配布し、利用者がインストーラを起動してインストール
よく目にするsetup.msiやsetup.exeによるインストールですね。
WiXというツールでsetup.msiをそこそこ簡単に作れます。作成にあたってはxmlにインストーラの設定を記述します。GUIがあれば最高なんですがxmlをポチポチと書く必要があり、ある程度勉強する必要はあります。
実際にはsetup.msiだけで済まず、少なくともアプリケーションをバージョンアップするためにはsetup.msiをラップするBootstrapperと呼ばれるものが必要です。それがsetup.exeというわけです。*5Bootstrapperの作り方はアプリケーションによって千差万別です。自分はC++プロジェクトを作ってみましたが、、、
とっかかりのサイト
WiX チュートリアル (日本語訳) — Windows Installer XML ツールセット入門
こちらで概要はつかめると思います。
まとめると
というわけで強引に表にまとめるとこんな感じになるかと思います。
インストール方法 | インストールの簡単さ | バージョンアップの簡単さ | インストール機構作成の簡単さ | インストール機構の柔軟性 |
---|---|---|---|---|
binをコピー | ○ | △ | ◎ | △ |
zipに固める | ○ | △ | ◎ | △ |
XBAP | ◎ | ◎ | △ | ○ |
ClickOnce | ◎ | ◎ | △ | ○ |
setup.msi | ◎ | ○ | △ | ◎ |
おわりに
浅くてすんません。。。最近必要があって調べたのですが、主にエンプラ分野で使われているためなのかインストール関連の情報はインタネットにはあまりなく四苦八苦しています。web全盛の昨今インストール不要なものが多いですがまだまだwindowsデスクトップアプリケーションが必要とされる場面はあるでしょう。たぶん。。。
*1:といったら良いのか、システムと言ったら良いのか
*3:XAML→WPF→インストール という三段論法。強引ですんません
*4:セキュリティについてもいろいろあるけど、デスクトップアプリケーションとして考えるとFullTrustにならざるを得ないでしょう。ここでは割愛。参考:連載 ClickOnceの真実:第7回 ClickOnceが持つセキュリティ機構とは? (1/4) - @IT
*5:最近知った。元ネタ:WiX チュートリアル (日本語訳) — Lesson 4 アップグレードとモジュラー化の「どういう理由かは知りませんが、スモール・アップデートとマイナー・アップグレードは、、、のくだり」
謹賀新年
あけおめ、ことよろでございます。
ふりかえり
1年前のエントリーを振り返りますと。。。
WPF
2つのシステムがカットオーバーを迎えることができました。どちらも価値を生み出しています。そのひとつは実家向けのシステムです。月並みですが、ユーザーさんと直接会話して一緒に作り直接感謝の言葉を頂くのは、やりがいがあります。
WPFは業務システムのフロントエンドとして生きながらえていくと個人的には思っているので引き続き勉強したいです。
kinect
こちらは全く何もせず。
windows phone
「Windows Phoneに関しては、2014年に、なにかしらの道筋をつけたい。製品が登場するかどうかは別にして、少なくとも社内においては、方向感を出すことができるだろう」しばらくないな。。/Windows Phone 8の国... http://t.co/d9P8Ir596V
— にしざわ こういち (@koty) 2013, 12月 31
お仕事
一昨年以上に昨年は会社が私に期待するものが変わってきました。「変化に対応しようぜ」と、いつも思ってきたものの自分に変化が訪れると対応できません。そういえば今年は年男なんだよなー。気づけば飲み会のときに注ぐより注がれることが増えてきたし、そりゃいろいろ変わってくるよなー。(うだうだ)
ショージキ言って会社ではあまり生きてる感覚がありません。
泳いでるかサンプロしてると生を実感できる。「オレ生きてるぜ!」っていう感覚。
— にしざわ こういち (@koty) 2013, 12月 26
サンプロは皆さんご存知のサンデープログラミングですね。
そんな感じで結構ストレスフルな一年でしたし、周りから見てもイマイチな仕事ぶりだったろうと思います。
今年は
フロントエンドはWPFとAngularJSを、バックエンドはAWS&rubyを勉強したいです。作りたいネタは何となくあるので。ああ、あと英語ね、英語。
プライベートで大きな変化がありそうで、そんなに自由な時間が取れなさそうです。人生いろいろ。
仕事はマイペースで、というわけにはなかなかいかないものの、気持ちが戻るのを淡々と待ちたいと思いますです。
そして何より健康第一で。
WPFを帳票フレームワークとして使う
この記事はXAML Advent Calendar 2013XAML Advent Calendar 2013 - Adventar 15日目の記事です。昨日はahfさんのWF における xaml について簡単な説明をしてみるでした。
あまりインタネットで見ないので印刷ネタを本エントリーでは書いてみます。
簡単な印刷
webというかペーパーレス(死語)の時代になって久しいですけどもまだまだ印刷機能の需要はあります。ありますよね?
本格的に印刷機能を使うとなれば、有償無償の帳票ミドルウェアを利用することになるかと思いますが、 一人で作れる程度のちょっとしたスタンドアロンシステムにはちょっと大げさです。
本エントリーではWPFによるお手軽印刷方法を紹介しようと思います。
ソースはgithubに置いてあります。
プロジェクト構成
サンプルプロジェクトの構成は下図の通りです。WPFのMVVMフレームワークであるLivetを使っていますが、本題とは外れるので多くは説明しません。。。
画面
画面は本題とは外れるので多くは説明しません。
当サンプルプロジェクトでは、この画面で入力したものを帳票に出します。
帳票
帳票をUserControlとして定義します。
<UserControl x:Class="WpfPrintReportSample.Reports.ReportSample" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:vm="clr-namespace:WpfPrintReportSample.ViewModels" mc:Ignorable="d" d:DesignHeight="1122" d:DesignWidth="793"> <UserControl.DataContext> <vm:MainWindowViewModel /> </UserControl.DataContext> <Grid> <Label Content="{Binding Text}" FontSize="70" VerticalContentAlignment="Center" HorizontalContentAlignment="Center"/> </Grid> </UserControl>
ここでミソなのが、
<UserControl.DataContext> <vm:MainWindowViewModel /> </UserControl.DataContext>
とバインドするViewModelを設定しておくことです。こうすることでVisual Studioのデザイナ上でViewModelがバインドされて表示されます。
ViewModel
今回は簡単のため画面と帳票で同じViewModelをバインドしています。
using System.ComponentModel; using System.Windows; using Livet; using Livet.Commands; namespace WpfPrintReportSample.ViewModels { public class MainWindowViewModel : ViewModel { public MainWindowViewModel() { if (DesignerProperties.GetIsInDesignMode(new DependencyObject())) { Text = "あいうえお"; } } public string Text { get; set; } private ViewModelCommand printCommand; public ViewModelCommand PrintCommand { get { return this.printCommand ?? (this.printCommand = new ViewModelCommand(this.Print)); } } private void Print() { Printer.Print(this); } } }
既に述べたVisual Studioのデザイナ上で表示されるデータは、ViewModelの引数なしコンストラクタ内で設定されたデータです。
引数なしコンストラクタが実行時にも使われる場合、デザイン時に使われるとエラーしてしまうことがあるでしょう。そういうときには、下記のように
if (DesignerProperties.GetIsInDesignMode(new DependencyObject()))
デザイン時と実行時で処理を分けることができます。地味に便利。
出力ロジック
印刷は下記です。
using System.Collections.Generic; using System.Windows.Controls; using System.Printing; using System.Windows.Xps; using System.Windows.Documents; using System.Windows.Markup; using WpfPrintReportSample.ViewModels; using WpfPrintReportSample.Reports; namespace WpfPrintReportSample { public static class Printer { public static void Print(MainWindowViewModel viewModel) { //Set up the WPF Control to be printed var fixedDoc = new FixedDocument(); var objReportToPrint = new ReportSample(); var ReportToPrint = objReportToPrint as UserControl; ReportToPrint.DataContext = viewModel; var pageContent = new PageContent(); var fixedPage = new FixedPage(); //Create first page of document fixedPage.Children.Add(ReportToPrint); ((IAddChild)pageContent).AddChild(fixedPage); fixedDoc.Pages.Add(pageContent); SendFixedDocumentToPrinter(fixedDoc); } private static void SendFixedDocumentToPrinter(FixedDocument fixedDocument) { XpsDocumentWriter xpsdw; PrintDocumentImageableArea imgArea = null; //こちらのオーバーロードだと、プリンタ選択ダイアログが出る。 xpsdw = PrintQueue.CreateXpsDocumentWriter(ref imgArea); //var ps = new LocalPrintServer(); //var pq = ps.DefaultPrintQueue; //こちらのオーバーロードだと、プリンタ選択ダイアログを飛ばして既定のプリンタにスプールされる //xpsdw = PrintQueue.CreateXpsDocumentWriter(pq); xpsdw.Write(fixedDocument); } } }
結果として以下のようなオブジェクト階層でFixedDocumentオブジェクトが出来上がります。
FixedDocument └ PageContent └ FixedPage └ UserControl(DataContextをバインド)
最後にFixedDocumentをXpsDocumentWriterに渡します。
利点
追加のミドルウェアいらず
開発時、実行時ともに専用のミドルウェアは不要で.NETランタイムさえ入っていれば使うことができます。
Visual Studioのデザイナ上で帳票を作れる
ソースコード中でオブジェクトを配置するのではなく、WYSIWYGで帳票を作れます。
帳票レイアウトの柔軟度が高い
何といってもWPFですから、Advent Calendarで皆さまが書かれているようにかなり柔軟度が高いです。特にItemsControlが強力ですね。データの件数に合わせて罫線を引くなんてことも簡単です。
まとめ
駆け足ですが、WPFによるお手軽印刷を紹介しました。windowsアプリケーションでの簡単な印刷ならこれで十分かなと思います。やはり.NETは便利ですね。ほかにこんなやり方があるよ、という方はぜひ教えてください。
参考サイト
- http://d.hatena.ne.jp/Yamaki/20080225/1203915252
- http://hokkai53.cocolog-nifty.com/blog/2008/01/wpf_3199.html
- http://blogs.bitlan.net/ito/?p=1541
- 作者: 大田一希
- 発売日: 2015/09/27
- メディア: Kindle版
- この商品を含むブログを見る
JUnitによるデータ駆動テストで困ったこと
データ駆動テストについて。Visual Studioだと、これhttp://codezine.jp/article/detail/6110?p=3にあるような感じで、データ駆動テストの記述および実行結果を確認できます。
今回JUnitでデータ駆動テストがしたかったので、まず下記のように書いてみました。
package com.mycompany.datadriven1; import static org.hamcrest.CoreMatchers.is; import static org.hamcrest.MatcherAssert.assertThat; import org.junit.experimental.theories.*; import org.junit.runner.RunWith; /** * 足し算するクラスをテストする */ @RunWith(Theories.class) public class AppTest { @DataPoints public static Fixture[] PARAMS = { new Fixture(1, 4, 5), new Fixture(2, 5, 8), //このテストケースが失敗する new Fixture(3, 6, 10) //このテストケースも失敗するけど↑が通るまで失敗だと分からない }; @Theory public void 足し算データ駆動テスト(Fixture f) { assertThat(f.expected, is(App.plus(f.a, f.b))); } static class Fixture { private final int a; private final int b; private final int expected; Fixture(int a, int b, int expected) { this.a = a; this.b = b; this.expected = expected; } } }
しかーし、これだとテストが失敗したDataPointsの要素でテストケースの実行が止まってしまい、残りの要素が実行されません。
成功する分には問題ないのですけどね。Visual Studioだと全部実行してくれるのに。*1
最終的にこう書きました。ErrorCollectorというクラスを使います。
package com.mycompany.datadriven1; import static org.hamcrest.CoreMatchers.is; import org.junit.*; import org.junit.experimental.theories.*; import org.junit.rules.ErrorCollector; import org.junit.runner.RunWith; /** * 足し算するクラスをテストする */ public class AppTest { public static Fixture[] PARAMS = { new Fixture(1, 4, 5), new Fixture(2, 5, 8), //このテストケースが失敗する new Fixture(3, 6, 10) //このテストケースも失敗する }; @Rule public ErrorCollector collector = new ErrorCollector(); @Test public void 足し算データ駆動テスト() { for(Fixture f:PARAMS){ collector.checkThat(f.expected, is(App.plus(f.a, f.b))); } } static class Fixture { private final int a; private final int b; private final int expected; Fixture(int a, int b, int expected) { this.a = a; this.b = b; this.expected = expected; } } }
これだと各要素のgreen/redにかかわらず、全ての要素をassertすることができます。
もっとええ感じにできるよ、と言う方はぜひ教えてください。
*1:よくみたらtheoryはexperimentalなんですね。experimentalだから仕方ないのか。。。
応募エントリ
はてなブログ2周年おめでとう!> id:hatenablog
(最近こんなエントリばかりだな。。)