Posts

ふととあるところで、 関数型に書かれていない みたいな記述を見つけました。このときなんかモヤっとしたんですが、うまく言語化出来なかったので、ちょっと書いてみます。 <!–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を使ったのは初めてです。 ...

個人的には2年くらい前から Ergodox EZ を使ってきました。セパレート式に目覚めたのはこれが契機で、自宅も仕事場もErgodoxに統一しています。ただ、不満がないかというとそうでもなく、よりよいキーボードを探していました。そんなとき、半年くらい前から自作キーボードが非常に賑わって来ていることに気づきました。これはムーブメントに乗るしか無い！と半年遅れくらいで乗ることにしました。 <!–more–> Ergodoxの不満 自作するにも、まずErgodox自体の不満である点をあぶり出す必要があります。最近の使い方を鑑みると、次のような不満がありました。 でかい。持ち運びはかなりきつい Kinesisもそうだったが、親指に役割が過剰 一番強いと言っても、本来の可動範囲と違うので、やりすぎると親指だけ痛くなったりする（実体験 人差し指内側のキーが基本死んでる 一番下の段のキーは基本使ってない など、使っていくうちにどんどんデッドキーが多くなっていきました。それと、個人的にもqmk_firmwareの挙動に慣れてきたりして、レイヤーを使いこなせるようになってきたことが大きいです。 自作候補 色々ありますが、以下のような選定基準にしました。 キー配列は格子 親指部分が独立している 親指部分に機能が集中しすぎていない でもSandSはやりたいのである程度欲しい 親指にshiftが無いと色々と効率がだだ下がりします 見つけた範囲だと、以下のキーボードがドンピシャのようでした。 crkbd Helixベースのため薄い 3行6列。かなりミニマル 個人的に数字を結構多用するので、ないときついんじゃないかって思う かなり理想的 irisよりも注意事項が少ない印象 iris ほぼ理想形（多分） 親指部分を 1u 2個と2u 1個で選択可能。ただ、実際に打っている感じだと、この場所で上下を打ち分けるのは結構しんどい可能性が高いです ビルドログが豊富 若干分厚いが、Ergodox EZよりもずっと小さい 今回は、丁度在庫が復活したので、Irisを組んでみることにしました。crkbdの方も、在庫が復活したら買う予定です。限度額が余ってれば。 注文内容 Keeb.ioでだいたい注文しました。 PCB Kit プレート 若干高かったですが、ステンレスにしました。初心者なのに大丈夫か？って思わなくもない ProMicro × 2 TRRS Cable コイルしてるのにしてみました キーキャップは、参考サイトにあった ジェイダブル から買いました。変に凝ったら素で 10k円 いってしまった・・・。なお軸は赤軸です。軽い＋リニアなのがいいのです。 工具類とUSBケーブルはAmazonで揃えました。 はんだごてとコテ台 白光 ダイヤル式温度制御はんだこて FX600 白光(HAKKO) こて台 633-01 定番っぽいのでこれに。こういうので奇をてらってもなんにもならないので・・・ はんだ goot 両面プリント基板用はんだ SD-61 0.8mmのものがちょうどいいらしいのでこれに ニッパー goot ニッパー YN-10 ドライバーとかはあったんですが、なぜかニッパーがなかったのでこれで。鋼線切断能力が1.3mmということで、Pro Microの足も切れるはず その他 エポキシ系接着剤 モゲ防止に 3M しっかりつくクッションゴム 8x2mm 台形 22粒 CS-04 クッションに ユニバーサル基板 はんだ付けの練習用に マグネット式のUSBケーブル モゲ防止 + 持ち運び用 1Mはないと部屋で使う時足りないので これ以外にも、テスターや絶縁テープなど購入しています 総計で 30k円 くらいいってます。Ergodox EZよりは安いと言えば安いけれども・・・ ...

この半年くらい、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> 今回必要だったのは以下の部分でした。 ...

今まで放置しっぱなしだったはてなダイアリーが終了するというニュースを受けて、個人ブログ移行の問題が出てきました。 はてなブログに移行する、ということも考えました。しかし、ちょうどブログについて考えていたところだったので、過去を振り切って新しく作ってみました。なんか独自ドメインもあったので。 <!–more–> 移行時に重視した点 いざ移行を考えた時、以下のようなフローでやってみたくなりました。 Githubにpushしたら公開される ブログの内容が全部公開されるけども、そもそも公開してるので気にしない 独自ドメイン+HTTPS Hugoで生成 出来ればorg-modeで書きたい 最後は願望でしたが。 利用したツール/サービス このブログを作成するにあたり、以下のサービス・ツールを利用しました。 Hugo テーマとしては hugo-nuo を使わせてもらいました ox-hugo Netlify Github これは前提ですが なお、執筆環境は基本的にEmacs一択です。 ox-hugoからのexport ox-hugoは、 org fileをmarkdownにexportするbackend です。backendとは、Org modeにおいてorg fileを変換するための処理みたいなものです。 とにかく、markdownを生成するものなので、Github上には .org と .md の両方のファイルがcommitされていきます。これは、仮にOrg modeを利用しなくなっても、markdownをそのまま書けばいい、ということでもあります。この点を鑑みて、リポジトリの容量については一旦置いておくことにしています。 執筆フロー Org modeで書く TODO を付けてdraft化 draftになっている間は、pushしても表示はされない（はず） 保存すると自動的にox-hugoがmarkdownに変換 ローカルで確認 書き終わったら DONE にしてcommit/push というフローでやっていきます。 決めかねてる点 Hugoだと基本的に posts/<ファイル名> 、という形式になるようですが、個人的にはいつ書いたか？をURLに入れておきたいです。 ただ、色々な人の構成を見ている限りでは、日時はHugoに任せて、タイトルだけにしているケースが多いようでした。郷に入れば郷に従え、ということでとりあえず従っておきますが、なんかモヤモヤします。 所感 Qiitaの方はmarkdownで書いている＋Webから登録する方が色々楽ということで、あっちはあっちで書いていきますが、こっちも充実させていければと思います。