@kotyのブログ

PythonとかAWSとか勉強会のこととかを、田舎者SEがつづります。記事のライセンスは"CC BY"でお願いします。

オープンデータについて感じたことその後

先日以下の記事を書きまして。

更新の仕掛けが貧弱ではないかと思っていたのですが、google driveに置いたスプレッドシートからのアップロードが秀逸ということが分かりました。けっこうよく出来ていると思います。

一度アップロードしたスプレッドには、際アップロードするためのリンクが書き込まれます。

f:id:kkotyy:20150224094048p:plain

このリンクから簡単に再アップロードができます。またスプレッドシート経由なので自動化もしやすいんじゃないでしょうか。

あとはオイシイ(この表現が適切かは分かりませんが)データを持っている自治体や医療機関がこの仕掛を活用してくれるか否かですが。。。

オープンデータについて感じたこと

追記書きました。

オープンデータについて感じたことその後 - @kotyのブログ


こちらを読みました感想を。

コメントしようかと思ったのですが長くなるのでエントリーを書きます。

最初に結論を。

確かにattributeタグなんかは酷いと思いますのでお気持ちは分かりますが、どーにかこーにか許容できるレベルではないでしょうか。例示されているコードなんか「ほらこんなに簡単に整形できちゃいますよ。LINQならね」と読めないこともないですし。。。いやー、C# いいですよね。やっぱC# ですよね。シーシャープ、シーシャープ、ぁぁああああああ!!!!!!

すみません。取り乱しました。データ構造はどーにか許容できる(ということにして)ので良いとして、

そして 2 年前から何も変わってない...

と書かれている点の方が問題ではないでしょうか。一度公開したオープンデータを最新化し続けること、そして最新化し続けやすい体制(システム的にも人間的にも)になっていることが大事なのではと感じました。避難所の新設や廃止が反映されないようではデータの価値が薄くなります。

オープンデータデイ

話が脱線しますがオープンデータデイが今月21日に世界各地で予定されています。

http://opendataday.org/

金沢でも開催されるみたいですね。

https://www.facebook.com/events/1511155185804654/

オラが村、長野でも開催予定でおりまして、

http://glnagano.doorkeeper.jp/events/20368

オープンデータを最近調べています。*1

日本国内のオープンデータは下記に集約されるみたいです。

データを更新するための仕掛けが必要では

で思ったのですが、このサイトに上がったデータの読み取りはJSONやらRDFおよびCSVといろんな形式で取れるよう仕掛けが用意されてるんですが、データを書き込むアップロードするためのAPIが見つからないのです。

今のところは紙とかxlsとかの非定型書式を気合で整形してアップロードしているのでしょう。なのでAPIがなくてもあまり問題になっていないのかもしれません。しかしデータの鮮度を重視するなら、この先データを最新化し続ける 必要があります。その際に書き込む仕掛けが貧弱なのが問題だなと感じました。

末筆で恐縮ですが

北陸新幹線が開業しますね。ぜひ記念勉強会をhttp://nseg.jpと合同で開催しましょう。Rx教えてください。

あとで見たら元ネタのページけっこう反響があったみたいだな。こちらはだまっていよう。。。

*1:そんなレベルでオープンデータを語るので、おっかなびっくりです

謹賀新年2015

あけおめことよろでございます。

昨年の振り返り

昨年は公私ともに忙しく、また大きな変化のあった年でした。java力は多少上がったような。

子どもが産まれた

元気に育ってくれています。かわいいです。生まれてきてくれた息子と産んでくれた奥さんに毎日感謝しています。

転職します

新卒で入社してから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でした。

↓↓このネタでいこうとも思ったのですが、

こちらでお茶を濁そうと思います。

はじめに

XAMLといえばWPFWPFアプリ*1を作ったらどうしますか?当然そのアプリを使いますよね。 使うにあたってはアプリを配布しインストールする必要があります。というわけで*2、デスクトップアプリケーションについてまわるインストール方法の選択肢について、本エントリーでは書こうと思います。*3

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アプリであり、ここで比較するには向かないので割愛。

とっかかりのサイト

WPF XAML ブラウザー アプリケーションの概要

開発者がインストーラ(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:といったら良いのか、システムと言ったら良いのか

*2:WPFに限らずですが

*3:XAMLWPF→インストール という三段論法。強引ですんません

*4:セキュリティについてもいろいろあるけど、デスクトップアプリケーションとして考えるとFullTrustにならざるを得ないでしょう。ここでは割愛。参考:連載 ClickOnceの真実:第7回 ClickOnceが持つセキュリティ機構とは? (1/4) - @IT

*5:最近知った。元ネタ:WiX チュートリアル (日本語訳) — Lesson 4 アップグレードとモジュラー化の「どういう理由かは知りませんが、スモール・アップデートとマイナー・アップグレードは、、、のくだり」

謹賀新年

あけおめ、ことよろでございます。

ふりかえり

1年前のエントリーを振り返りますと。。。

WPF

2つのシステムがカットオーバーを迎えることができました。どちらも価値を生み出しています。そのひとつは実家向けのシステムです。月並みですが、ユーザーさんと直接会話して一緒に作り直接感謝の言葉を頂くのは、やりがいがあります。

WPFは業務システムのフロントエンドとして生きながらえていくと個人的には思っているので引き続き勉強したいです。

kinect

こちらは全く何もせず。

windows phone

お仕事

一昨年以上に昨年は会社が私に期待するものが変わってきました。「変化に対応しようぜ」と、いつも思ってきたものの自分に変化が訪れると対応できません。そういえば今年は年男なんだよなー。気づけば飲み会のときに注ぐより注がれることが増えてきたし、そりゃいろいろ変わってくるよなー。(うだうだ)

ショージキ言って会社ではあまり生きてる感覚がありません。

サンプロは皆さんご存知のサンデープログラミングですね。

そんな感じで結構ストレスフルな一年でしたし、周りから見てもイマイチな仕事ぶりだったろうと思います。

今年は

フロントエンドはWPFとAngularJSを、バックエンドはAWS&rubyを勉強したいです。作りたいネタは何となくあるので。ああ、あと英語ね、英語。

プライベートで大きな変化がありそうで、そんなに自由な時間が取れなさそうです。人生いろいろ。

仕事はマイペースで、というわけにはなかなかいかないものの、気持ちが戻るのを淡々と待ちたいと思いますです。

そして何より健康第一で。

WPFを帳票フレームワークとして使う

この記事はXAML Advent Calendar 2013XAML Advent Calendar 2013 - Adventar 15日目の記事です。昨日はahfさんのWF における xaml について簡単な説明をしてみるでした。

あまりインタネットで見ないので印刷ネタを本エントリーでは書いてみます。

簡単な印刷

webというかペーパーレス(死語)の時代になって久しいですけどもまだまだ印刷機能の需要はあります。ありますよね?

本格的に印刷機能を使うとなれば、有償無償の帳票ミドルウェアを利用することになるかと思いますが、 一人で作れる程度のちょっとしたスタンドアロンシステムにはちょっと大げさです。

本エントリーではWPFによるお手軽印刷方法を紹介しようと思います。

ソースはgithubに置いてあります。

プロジェクト構成

サンプルプロジェクトの構成は下図の通りです。WPFのMVVMフレームワークであるLivetを使っていますが、本題とは外れるので多くは説明しません。。。

f:id:kkotyy:20131210220947p:plain

画面

画面は本題とは外れるので多くは説明しません。

当サンプルプロジェクトでは、この画面で入力したものを帳票に出します。

f:id:kkotyy:20131210221331p:plain

帳票

帳票を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は便利ですね。ほかにこんなやり方があるよ、という方はぜひ教えてください。

参考サイト

WPF 4.5入門

WPF 4.5入門

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の要素でテストケースの実行が止まってしまい、残りの要素が実行されません。

f:id:kkotyy:20131112231531p:plain

成功する分には問題ないのですけどね。Visual Studioだと全部実行してくれるのに。*1

最終的にこう書きました。ErrorCollectorというクラスを使います。

参考:http://stackoverflow.com/questions/8779982/why-does-junit-run-test-cases-for-theory-only-until-the-first-failure

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;
        }
    }
}

f:id:kkotyy:20131112231538p:plain

これだと各要素のgreen/redにかかわらず、全ての要素をassertすることができます。

もっとええ感じにできるよ、と言う方はぜひ教えてください。

*1:よくみたらtheoryはexperimentalなんですね。experimentalだから仕方ないのか。。。