Programming

諸事情（主に会社の事情）で、AngularとState管理について評価する必要が出ました。ただ、今までそもそもAngularを触ったことがなかったため、Angular公式のTutorialをやることにしました。このTutorialが結構な分量なので、これにstate管理を追加すると丁度いいんでは？ということでやってみました。 <!–more–> Angular CLIのインストール まずはAngular CLIをインストールします。基本的にglobal installを推奨しているようですが、global installはめんどくさい時もあるので、今回はlocal installでなんとかならんかやってみます。 $ yarn add -D @angular/cli $ yarn ng new angular-tutorial --directory . --force $ yarn ng serve --open 一回CLIだけをaddしてから、無理やり上書きするというパワープレイでいけます。ここからは、Tutorialを普通に進めます。 Tutorialをやる（HTTP以外） Tutorialを進めていきます。集中してやれば、大体2〜3時間で終わるくらいのボリュームです。ただ、今回はstate managementをやるのが目的なので、HTTPが絡むような部分はstubにしておきます。 とりあえずTurorialが完了しただけの状態が以下のリポジトリです。masterブランチがその状態です。 https://github.com/derui/angular-tutorial-ngrx では、これにngrxを追加していってみましょう。 ngrxとは Angularを表す ng と、RxJSを表す rx がくっついているのでだいたい想像がつきますが、RxJSを前面に出したAngular用のstate management libraryです。公式ページでは次のように表現されています。 Store is RxJS powered state management for Angular applications, inspired by Redux. Store is a controlled state container designed to help write performant, consistent applications on top of Angular. ...

ふととあるところで、 関数型に書かれていない みたいな記述を見つけました。このときなんかモヤっとしたんですが、うまく言語化出来なかったので、ちょっと書いてみます。 <!–more–> まず始めに観測する 関数型 とか 手続き型 と言いますが、一体どういう基準で話しているかは、書き手・話し手に依存するようです。ただ、ある程度一貫しているのは 関数型という場合、多くの場合は関数がファーストクラス 手続き型という場合、低レイヤーな言語で書かれているようなものを指しているケースが多い 稀に、関数型言語と手続き型言語という感じでの使い方もされる様子 関数型言語としてはHaskell/Lispなど 手続き型言語としてはC/昔のJavaなど くらいのようです。私の観測範囲が狭すぎるのであれですが・・・。 関数型の書き方とは？ Java7から8になったタイミングでよく言われたのは、 Project Lambda によって導入されたLambda式でした。私もご多分に漏れずよろこんで使っているわけですが。ただ、これはJavaという言語が関数を言語のファーストクラスにした、という意味ではなく、単純にあまりに冗長だった無名インターフェースを簡単に書けるようにした糖衣構文です。 例えばこういうのが Thread thread = new Thread(new Runnable() { @Override public void run() { ... } }); こうなります。 Thread thread = new Thread(() -> {...}); どう見ても後者の方が圧倒的に短いです。ですが、これは単に () -> {} が、 Runnableインターフェースの run メソッドの実装として扱われているだけです。IntelliJとかであれば、RefactorだったかSourceから、糖衣構文にした場合としない場合にそれぞれ変換できますので、やってみるとわかりやすいです。 同じくJava8で入った Stream は、このLambdaを使い倒して貰おうというのが明白なインターフェースをしています。大抵、このStreamとLambdaを組み合わせて書いたものを関数型的というケースが多いようです。 何がモヤッとするのか 一応今までに Haskell や Common Lisp、 OCaml(公式が表示されなかったので日本版) を触っていますし、OCamlは今も継続して使っています。Javaは仕事で大量に書きましたし、JavaScriptも大量に書いています。C/C++も普通に使っていました。それぞれ、関数型言語と言われたりオブジェクト指向言語であったり、手続き型（C++はあれですが）言語と言われていたりします。 そんな中でモヤっとするのは、 見た目だけで関数型かどうかは決まらないのに、スタイルで語るのはなんか違うのでは無いか と最近思ったりするからです。試しにやってみるとわかりますが、Stream + Lambdaで調子に乗ってベタ書きすると、すぐに再利用不可かつ、for文で書くよりも可読性の悪いものが出来上がります。 関数型と手続き型の狭間 では実際に、私の思う手続き型と関数型の違いをコードにしていってみます。ここでは私が一番Loveな言語であるOCamlを使います。 let () = let num = ref 12345 in let buffer = Bytes.make 5 ' ' in for i = 5 downto 1 do let n = !num mod 10 in let v = match n with | 1 -> '1' | 2 -> '2' | 3 -> '3' | 4 -> '4' | 5 -> '5' | _ -> assert false in Bytes.set buffer (pred i) v; num := !num / 10 done ; print_string (Bytes.to_string buffer) 12345 という数字を "12345" という文字列にするのを、ものすごく冗長に、かつrefや副作用バリバリで書いてみました。OCamlにはwhileもありますが、ここではforを使いました。OCamlでforを使ったのは初めてです。 ...

この半年くらい、Tableauをよく触っています。そんな中、今まで国内だけで使っていたTableau Workbookを国外でも利用したい、という話が出てきました。 そんなときにできることをまとめてみます。 <!–more–> 以下のような方に参考になれば。 Tableauのワークブック/シートがそれなりにある 日本語ガッツリだったものを国外でも利用する必要に迫られた Tableauでの多言語化 まず、Tableau自体は多言語化されています。 Measure name/メジャーネームとか 合計とか ですが、 ラベル系については一切サポートがありません。 シート名、ダッシュボード名とかもありません。実際にフォーラムでも同じような質問を見つけましたが、そこでは以下のような解決策が示されていました。 各Labelを計算フィールドにする 言語を表すパラメータを作る 計算フィールドの中で、パラメータの値（＝各言語）毎にラベルを定義する これを全部に対して適用する ・・・シートが1つ2つならまぁいいかなって思わなくもないですが、私がもっているのは30シート/10オーバーのDatasourceだったので、とてもじゃないですが参考にできませんでした。 一括で変換したい フォーラムの中では、それ以外にも案が示されていて、その中で一番有望なのが XMLを直接書き換える という方法でした。 Tableauの .twb 拡張子は、エディタで開いてみると単なるXMLになっています。これを直接書き換えればいいやん、というある意味単純な話です。これしかない！って感じで、この路線で進めてみました。 こぼれ話：TableauのAPIクライアント コミュニティで作られているものですが、tableau_toolsというライブラリがあります。 tableau_toolsのリポジトリ これの中にも、Workbookをよしなに書き換えてくれそうなものがあったので、最初はこれを使ってみました。ただ、私の目的にはそぐわなかったので、利用しませんでした。どちらかというとTableauのAPIを叩くほうが主眼のライブラリだったんで、それも仕方ないかな、と。 Tableau Workbookの構造 XMLをいじるには、まず構造を知る必要があります。実際に翻訳で書き換えていった中で、結構色々と知ることができました・・・。 Tableau Workbookは、大きく以下のような構造になっています。翻訳で利用しなかった部分は省略してます。 <!-- Workbookのrootエレメント --> <workbook ...> ... <datasources> <!-- データソース。パラメータもデータソースです。パラメータは、captionがなくってnameがParametersで固定です。 --> <datasource name="Parameters"> <!-- nameはTableauの計算フィールドとかで利用するときの名前です。captionは、「名前の変更」をしたときに設定されるやつです --> <column caption="foo" name="[parameter 1]"> <!-- 「別名」から設定されるものです。membersもセットになっている・・・かもしれません。 パラメータの場合は少なくとも必要でした。 --> <aliases> <alias key="0" value="foo" /> <alias key="1" value="bar" /> </aliases> <members> <member alias="foo" value="0"/> <member alias="bar" value="1"/> </members> </column> </datasource> <!-- PostgreSQLとかのDatasourceだと、nameはtableauが生成した値で、captionには画面側で利用する値になっています。 --> <datasource caption="foo" name="..."> <column caption="a" name="original"> ... </column> </datasource> </datasources> <worksheets> <!-- 各ワークシートです。nameがWorksheetとIDとほぼイコールなので、変更する場合は結構大変です --> <worksheet name="worksheet1"> <style> <!-- 軸のstyleに関する設定です。element="axis"の中を見ると大体わかります --> <style-rule element="axis"> <format attr="title" value="軸" /> </style-rule> <!-- 凡例のstyleに関する設定です。いくつかある場合は複数になるようです。 valueをいじるだけでいいパターンと、formatted-text/runを追加する必要があるケースがありましたが、 formatted-textも設定しておくのが正のようです。 --> <style-rule element="legend-title-text"> <format ...> <format value="凡例" ...> <formatted-text><run>凡例</run></formatted-text> </format> </format> </style-rule> </style> </worksheet> </worksheets> <dashboards> <!-- ダッシュボードです。worksheetと同じく、nameがIDです --> <dashboard name="dashboard"> <!-- ダッシュボードでの配置を管理しているもののようです。 翻訳では、この中のnameが、変更後のworksheetと同様になる必要があります。 --> <zones> <zone name="worksheet1" ...> </zone> <zone name="worksheet2" ...> </zone> </zones> </dashboard> </dashboards> <windows> <!-- tableauデスクトップとかで下に表示されているものの一覧です --> <!-- class=dashboardはダッシュボード、class=worksheetはワークシートです。 ここのnameは、必ず<worksheet>や<dashboard>と一致させる必要があります。 --> <window class="dashboard" name="dashboard"> <viewpoints> <!-- dashboardの場合だけ（多分）翻訳が必要です。ここのnameは、他の<workspace> 要素と一致している必要があります。 --> <viewpoint name="worksheet1" ...> </viewpoint> </viewpoints> </window> <window class="worksheet" name="worksheet1"> </window> </windows> </workbook> 今回必要だったのは以下の部分でした。 ...