Posts

このところOCamlでアプリケーションをほそぼそと作っているのですが、その過程でClean Architectureっぽいものを採用してみました。 <!–more–> 作っているアプリケーション自体は、完全に趣味の領域のものなのでまだ公開していません。ただ、OCamlであってもなんであっても、ある程度の規模になったらなんらかの方法論は必要かな、と思い始めました。 packageそのものがいっぱいある moduleもいっぱいある どことどこが関連してるかよくわからなくなってくる これはもしかしたらmodule/packageの分割方法自体が問題か・・・？ ある程度Clean Architectureっぽいことも出来るようになってきたので、自分の知識を整理する上でも書いてみます。 Clean Architectureとは？ ググってもらうのが一番早いのですが、それは流石に不親切すぎるので・・・。 Clean Architectureは、 http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html が原典とされ、 Robert C. Martin によって提唱されたアーキテクチャです。 Onion Architecture/Hexagonal Architectureなど、過去のアーキテクチャも参考にしながら作成されたものになり、それらの特徴も一部受け継いでいます。 Clean Architectureは、以下のような制約を導入します。 ある層は、それより外側の層に依存してはならない ある層は、それより内側の層にのみ依存する これがClean Architectureにおける唯一の制約です。層としては、基本形として以下を提唱しています。 Entities いわゆるドメインモデルです Use Cases アプリケーションロジックです。Domain Logicよりは特殊化されていますが、サブシステムとかがないアプリケーションだと、大体がここにロジックがある感じになるそうです Interface Adapter/Gateway/Presenter UIやData Storeなど、外部との連携を行うための層です。 APIをGatewayとして実装する、UIの情報をPresenterから返す、とかいろいろあります Frameworks and Drivers Framework specificな処理とかです APIをFrameworkの機能を利用して作成する、とかであればここになります ただ、これ以外にも 層を 追加することは可能です。唯一の制約である、層の間にある依存方向を守る限り、層の増減は自由です。 OCamlでの課題（自分的に） OCamlである程度の規模のアプリケーションを作成する場合、恐らくある程度の単位でパッケージを作成する場合が多いと思います。最近は dune を利用すると思いますが、使わない場合であったり、一パッケージに全ファイルを置くのは色々問題があります。 module名がめっちゃ長くなる 1ファイル1moduleとかやると、ファイル名もめちゃくちゃ長いですが、そのmoduleを利用するときにすごく面倒になります 一般的なモジュール名がかぶる 特に被るのが Types とかの名前です 1ファイルに複数のmoduleを書くと見通しが悪い 1データ型1module主義とかやると、単純にファイルの中身がかなり長くなります OCamlerはあまりその辺は恐れないようですが。 この辺はfoldとかをうまく使えばいいのかもしれません 特に、頻繁に使うmodule名が長いと色々だれますし、毎回aliasを書くのもしんどいです。以前よりもmoduleを明示しなければならないケースは少なくなりましたが、一級moduleを利用しているとやっぱりきついです。 パッケージを分ける上での基準も厄介です。大抵は機能とか役割別だと思いますが、結構分けづらい感じになっていったりで・・・。 そこで、パッケージを分ける基準として Clean Architecture を使ってみました。 OCaml on Clean Architecture とはいっても、基本的には各層ごとになるようにパッケージを分割するだけです。そうすると、dependenciesの方向制御も簡単になります。私は、 domain, usecase, gateway, binary と分けています。こうすると、OCamlの制約とduneの機能で、以下のような利点を自動的に得られます。 ...

最近別のプロジェクトに0.5で参加することになりました。人生初の0.5です。おかげで？ガッツリ開発するケースが少なくなりそうで、それはそれで・・・と思う日々です。 それはともあれ、それぞれのプロジェクトでSpring Bootを触ることになりました。これまた人生初です。そんなときになかなか解決しなかったことについて書きます。 <!–more–> 今回やりたいことは以下のような感じです。他にもいろいろありますが、今回は絞っています。 Spring Boot 2系列 というかSprint Initializrで作ったプロジェクト テストのAssertionライブラリとして AssertJ を使いたい Custom Assertionを Assertion Generator でやりたい こんなことをやりたかったんです。 最初のbuild.gradle buildscript { ext { springBootVersion = '2.0.6.RELEASE' } repositories { mavenCentral() } dependencies { classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}") } } apply plugin: 'java' apply plugin: 'eclipse' apply plugin: 'org.springframework.boot' apply plugin: 'io.spring.dependency-management' group = 'com.example' version = '0.0.1-SNAPSHOT' sourceCompatibility = 1.10 ext { assertjGeneratorVersion = '2.0.0' } repositories { mavenCentral() } configurations { assertj } dependencies { implementation('org.springframework.boot:spring-boot-starter-web') testImplementation('org.springframework.boot:spring-boot-starter-test') assertj "org.assertj:assertj-assertions-generator:${assertjGeneratorVersion}" assertj project } // configuration and tasks for assertj sourceSets { test { java { srcDir 'src/test/java' srcDir 'src-gen/test/java' } } } def assertjOutput = file('src-gen/test/java') task assertjClean(type: Delete) { delete assertjOutput } task assertjGen(dependsOn: assertjClean, type: JavaExec) { doFirst { if (!assertjOutput.exists()) { logger.info("Creating `$assertjOutput` directory") if (!assertjOutput.mkdirs()) { throw new InvalidUserDataException("Unable to create `$assertjOutput` directory") } } } main 'org.assertj.assertions.generator.cli.AssertionGeneratorLauncher' classpath = files(configurations.assertj) workingDir = assertjOutput args = ['foo.bar'] } compileTestJava.dependsOn(assertjGen) args にある foo.bar はパッケージ名と思ってもらえれば。 ...

Irisキーボードを作ってから一週間くらい経ちました。その間、色々と試行錯誤して、ある程度決まってきたので、ここで一回紹介しておこうかと思います。 <!–more–> なお、日頃の入力は全てIrisから行うようにしているので、キーマップ以外は慣れました。小さいは正義。 Ergodox EZから無くなったキーたち Irisキーボード は、Ergodox EZよりもおよそ20キー弱少ない、54（または56）キーしかありません。また、改めて自分のErgodox EZのキー配列を見直してみた所、ちょうど無くなったキー部分に次のようなものがありました。 カーソルキー 主に日本語入力中の候補選択とかに、org-modeで多用していました Backspace/Enter 作成の都合上、親指部分のキーに2uのキーを使ったので、単純にbackspace/enterのキーが消えました {}[] の入力 人差し指内側のキーにそれぞれマッピングしていました 少なくともこれらのキーは、今までと別の場所にマッピングしてやる必要があります。 マッピング戦略 さて、マッピングをしないといけないキーは色々ありますが、いくつか個人的に譲れないものとかがあるので、まずはそれをあげていきます。 親指にShiftがある コレだけは譲れない 親指にEnterがある コレも譲れないと言うか、US/JPどっちにしろIrisだとEnterがあるべき場所にキーがそもそもないので・・・ 親指にSpaceがある 元々親指で押してたもんですし。 アルファベット+基本的な記号部分はQwertyから崩さない 別段ずらす必要はないので GUIキーはデフォルトのlayerに必要 タイル型WMを利用している都合上、コレは必須 蜂蜜小梅配列 を利用する Ergodox EZでは一つのレイヤーとして実装していたので 日本語切り替えはワンタッチで 現状維持。手軽に切り替えられることは効率に直結します という感じです。記号類は、Ergodox EZの時点でSYMBOLレイヤーみたいなものを作ってそこで入力するようになっていたので、LOWER/RAISEを利用するとしても変わらないかな、と。 では、これらを考慮して設定していったキーマップを解説していってみます。 レイヤー解説：Default layer https://github.com/derui/qmk_firmware/blob/master/keyboards/iris/keymaps/derui/keymap.c#L31 特筆すべき点というのはそんなに無いですが、親指に当たるキーは基本的に Multi Role になっています。同時押しのときと単独でのクリック時の挙動が違う、ということになります。 SFT_ENT 同時押しでshift、単独でEnterになるようになっています M_EISU M_KANA 単独だとかなと英数の切り替えを行います。切り替えは無変換のキーコードを出すようにしています 同時押しだとLOWER/RAISEに切り替えられます。このキーを２つとも押しっぱなしにすると、ADJUSTになります ここで一番変わっているのは、 m_kana と m_eisu です。本来であれば LT() マクロなどを利用するのですが、 LTマクロなどは標準のキーコードなどとしかセットで利用できません 。無変換とかと組み合わせることはできないということです。 ですので、自前で管理しています。こんな感じで。 bool process_record_derui(uint16_t keycode, keyrecord_t *record) { static bool enable_layer = false; static bool interrupt_in_layer = false; if (record->event.pressed) { switch(keycode) { case M_EISU: layer_on(_RAISE); update_tri_layer(_LOWER, _RAISE, _ADJUST); enable_layer = true; interrupt_in_layer = false; return false; break; case M_KANA: layer_on(_LOWER); update_tri_layer(_LOWER, _RAISE, _ADJUST); enable_layer = true; interrupt_in_layer = false; return false; break; default: if (enable_layer) { interrupt_in_layer = true; } break; } } else { switch(keycode) { case M_EISU: layer_off(_RAISE); update_tri_layer(_LOWER, _RAISE, _ADJUST); if (enable_layer && !interrupt_in_layer) { /* KC_MHEN equals KC_INT5 */ layer_off(_HACHIKOUME); SEND_STRING(SS_TAP(X_INT5)); SEND_STRING(SS_TAP(X_LANG2)); der_init_hk_variables(); } enable_layer = false; return false; break; case M_KANA: layer_off(_LOWER); update_tri_layer(_LOWER, _RAISE, _ADJUST); if (enable_layer && !interrupt_in_layer) { /* KC_HENK equals KC_INT4 */ SEND_STRING(SS_TAP(X_INT4)); SEND_STRING(SS_TAP(X_LANG1)); layer_on(_HACHIKOUME); der_init_hk_variables(); } enable_layer = false; return false; break; default: if (enable_layer) { interrupt_in_layer = true; } break; } } return true; } tapping_termなどの恩恵は受けられませんか、これくらいであれば、自前で実装してもまぁなんとかなります。 ...

以前の記事で、キーボードを自作するために色々と注文していましたが、一通り届いたので、実際に作ってみました。 <!–more–> Irisのキットの内容 今回は、IrisのPCBとステンレスのplateを購入しました。広げるとこんな感じになります。 ステンレスが眩しいです。想定外だったのが、このステンレスプレートがめちゃくちゃ重かったことです。どのくらい重かったかと言うと、片手分のプレートだけで Ergodox EZの片手分 くらいあります。 右上に見えているのは TRRS ケーブルです。あえてコイルしているのを購入してみましたが、このコイルが想定しているよりも硬かったため、しばらく伸ばしたりなんだりしています。 Irisのビルド ビルドは、公式のビルドログ と、 ASCII.jpの連載記事 を参考にしました。公式のビルドログは、 ProMicroを取り付けたところで終わっているので、それ以降の（ケースとか）手順については、ASCII.jpの記事が参考になりました。 作成自体は、ひたすらはんだ付けしていくだけなので、ここからは写真を多めに出していきます。 まずはモゲ対策をしました。コレをやったおかげかどうかはわかりませんが、今回結構な頻度でケーブルの抜き差しをしましたが、特に取れそうな感じはしませんでした。接着剤を盛るだけなので、やっとくのがおすすめです。 裏側からダイオードをいれていき、カプトンテープをマスキングテープがわりにして仮どめしました。カプトンテープを使うと、この後にダイオードをはんだ付けしても特に問題なかったので、普通のマスキングテープよりいいかも知れません。 途中の写真がなかったのであれですが、Pro Microとキースイッチまではんだ付けしたところです。コレは左手分ですが、実はこの時右手側で一列分キースイッチをはんだ付けするのを忘れていて、動作確認する時に ？？！！！ ってなってました。 プレートを付けてキースイッチを付けるとこんな感じになります。 所要時間は、細かく測ってませんがおよそ８時間くらいかかった気がします。最後の３時間位は、後述のトラブルを解決するためにかかった気がしますが・・・。 出くわしたトラブル はんだ付けが不安でしたが、実際やってみると、きちんとやり方を守れば、特に問題なくできました。しかしそれ以外のトラブルが・・・。 Pro Microを認識しない 私のメインPCはGentoo Linuxなんですが、カーネルのオプションを絞りすぎていて、Pro Microをリセットした時に作成される /dev/ttyACM0 が出来ない状態になっていました・・・ 足りなかったオプションとモジュールを追加して解決 USBをつないで動くときと動かないときがある マグネット式のUSBケーブルに若干の問題があったらしく、普通の向きと逆さまにしたらうまく動きました とりあえずは問題ないってことにしてます キーが一列反応しない そもそもキースイッチがはんだ付けされてなかったという悲劇 ハンタ付したら普通に動きました スタビライザーの装着をミスった PCB上に配置するはずが、よくわからなくてキースイッチと同じ側から入れてしまい、なんか不安定に・・・ 動くことは普通に動くので、まぁいいっか・・・っていうことにしてます スタビライザーを付けている人が少なく、どうもよくわからなかったのが・・・。次回があればミスをしないようにしたいところです。 ところでキーマップは？ こちら です。 今までのErgodox EZを再現することは当たり前に出来ないので、まだ試行錯誤しています。 特に、蜂蜜小梅配列を実装したキー配列が恐ろしくギリギリなので、ここをなんとかしたいところです。固まったら、改めて書きます。 次に向けて Irisを組んでみて、半田付けのコツであったりはなんとなく習得したので、次は crkbd にチャレンジしてみたいです。 それと、白軸と間違えて赤軸を使った所、びっくりするくらい重く感じているので、慣れるか別の軸で作るかをさっそくけんとうしています・・・ この記事は100% Irisで書かれました。

ふととあるところで、 関数型に書かれていない みたいな記述を見つけました。このときなんかモヤっとしたんですが、うまく言語化出来なかったので、ちょっと書いてみます。 <!–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から登録する方が色々楽ということで、あっちはあっちで書いていきますが、こっちも充実させていければと思います。