Posts

最近人事／総務からのヒアリングした業務上の問題を解決していく、という社内プロジェクトに参加しています。 その中で、割と調べても出てこなかった事柄をメモしておきます。 <!–more–> 要望 今回解決したいのは、次のような問題でした。 色々な事情で、Excelから紙で印刷いないといけない 親会社の意向とかいろいろあるようで Excelの数が多い だいたい社員数くらいある（現状だと300↑） 印刷するのが手作業で辛い しかもそういう業務がけっこうある とにかく問題としては、 Excelを開く→最初のページだけ印刷する という業務が多く、かつ時間がかかる、と。電子承認とかそういう方向に行きたいらしいですが、まーいろいろ事情があるようで。 方針の検討 とりあえず抜本的ではないが、ある程度作る労力と、結果の省力化に貢献できるものとして、次のようなツールを作ることにしました。 Excelマクロの実行が必須 実行しないと正しい状態にならないので・・・ Excelの １ページ目だけ 印刷できる フォルダ内のExcelを一気に印刷できる 任意のフォルダでやりたい 困ったこと 人事／総務の方々は、ITレベルが様々なので、Windows標準で入っているものを使う、ということで、 PowerShell を使うことにしました。 ところが、いろいろ調べて（ググって）みても、 ExcelからBookを印刷する というものはあっても、 指定したページだけ印刷する ということをやっている人がまずいないっぽいという・・・。 フォルダ内のExcelを印刷するという回答 色々試す 色々試した所、次のサイトが気づきになりました。 https://docs.microsoft.com/ja-jp/office/vba/api/excel.workbook.printout このページ、Office VBAのヘルプですが、ここに引数が書いてあります。 名前 必須 / オプション データ型 説明 From 省略可能 Variant 印刷を開始するページの番号を指定します。 この引数を省略すると、最初のページから印刷します。 To 省略可能 Variant 印刷を終了するページの番号を指定します。 この引数を省略すると、最後のページまで印刷します。 Copies 省略可能 Variant 印刷部数を指定します。 この引数を省略すると、印刷部数は 1 部になります。 Preview 省略可能 Variant True の場合、印刷をする前に印刷プレビューを実行します。 False、または省略した場合、直ちに印刷を行います。 ActivePrinter 省略可能 Variant アクティブなプリンターの名前を指定します。 PrintToFile 省略可能 Variant True の場合、ファイルへ出力します。 引数 PrToFileName が省略された場合、出力先のファイル名を指定するためのダイアログ ボックスを表示します。 Collate 省略可能 Variant True の場合、部単位で印刷します。 PrToFileName 省略可能 Variant _PrintToFile_がTrueに設定されている場合、この引数は印刷先のファイル名を指定します。 IgnorePrintAreas 省略可能 Variant True の場合、印刷範囲を無視してオブジェクト全体を印刷します。 これをPrintOutに指定すればいいんじゃね！？ということで、こんな感じにしてみました。 ...

だいぶ前ですが、Tensorflowのメジャーバージョンアップである2.0のbetaがリリースされました。丁度いいので、以前作ったまま放置していたツールを更新してみようと思います。 <!–more–> 以前作ったのはこれです。Qiitaで記事も書きました。 https://github.com/derui/painter-tensorflow https://qiita.com/derui/items/fe232c87d981d241ae07 https://qiita.com/derui/items/9719efa14f44a792362b 大雑把に言うと、着色済みの画像から線画を抽出するものと、その逆版です。現在ではこういう個人レベルのおもちゃではなく、実際にサービスとして運用されてるものもありますね。 1. まず公式サイトを確認する 2.0-betaをインストールする方法は、公式サイトに載っています。ちゃんと確認しておきます。 https://www.tensorflow.org/install また、今回対象にするものは、GPUが大前提なので、CUDAとかの条件も確認しておきます。このへんがしんどいので、普通はGoogle Colabとかを利用するのが良いかと。私は裏側の学習も兼ねてやっているので、頑張って整えていきます。 https://www.tensorflow.org/install/gpu 2. CUDAとかを色々用意する 他のツールは触ったことがないのでなんとも言えませんが、TensorflowはかなりアグレッシブにCUDAのバージョンアップを行っている印象です。実際、2.0-betaでは以下を要求してきました。 Hardware requirements The following GPU-enabled devices are supported: NVIDIA® GPU card with CUDA® Compute Capability 3.5 or higher. See the list of CUDA-enabled GPU cards. Software requirements The following NVIDIA® software must be installed on your system: NVIDIA® GPU drivers —CUDA 10.0 requires 410.x or higher. CUDA® Toolkit —TensorFlow supports CUDA 10.0 (TensorFlow >= 1.13.0) CUPTI ships with the CUDA Toolkit. cuDNN SDK (>= 7.4.1) (Optional) TensorRT 5.0 to improve latency and throughput for inference on some models. ...

最近家に帰ってからめっきりプログラミングをしなくなってしまいました。いろいろやることがあると同時並行では難しいですね。 さて、今回はmozcの候補表示pluginを作ってみたというお話です。 <!–more–> https://github.com/derui/mozc-posframe mozcの候補表示は、標準で存在する Echo Areaへの表示、overlayでの表示のほか、 mozc-popup という拡張があり、大抵はこれを利用している方が多そうです。私もこれを利用していました。 （Emacs上での日本語入力にfcitxとかを利用している人は対象外です。そういう人のほうが多いんだろうか・・・） mozc-popupの利点 mozc-popupを利用していたのは、やはり利便性を重視してのことでしたが、特に以下の点がキーだったと思います。 変換位置と候補が近い overlayでもだいたい一緒ですが 実績あるpopup.elの利用 Spacemacsから入った人は知らないかもしれない、auto-completeで熟成したpopup表示に特化したlibraryです この結果、標準のoverlayよりも高速でした だんだんででくる問題点 mozc-popupを利用する前は、mozc + popupという組み合わせで長年使っていましたが、最近色々と問題が見えるようになってきました。 org-modeとpopup.elの相性が悪い 新しい拡張を作ることにした最大の契機 特に多数の折りたたみがあるときに顕著で、表示までの時間や、表示の崩れが非常に激しかった popup.elの更新頻度 一時代を築いたpopup.elですが、companyが台頭してからはだいぶ表舞台から消えてしまった感があります その仕組み上も複雑で、メンテナンスが困難だという話も child frameという潮流 Emacs 26から、frameに大きな拡張が入り、child frameと呼ばれる形態が可能になりました。端的に言うと、frameをfloating windowとして扱うことができる、というものです。 すでに様々なライブラリで利用されており、名実ともにEmacs26の目玉機能となっています。（個人の観測範囲では） https://github.com/sebastiencs/company-box https://github.com/emacs-lsp/lsp-ui しかし、あくまでframeを扱うものであるため、そのままだとpixel単位での操作が必要となり、非常に煩雑です。WIN32 APIでwindow作っていた時代になった気分です。それをラッピングしたlibraryが、 posframe です。 mozc + posframe 前述したmozc-popupの問題は、つまるところoverlayでの表現に限界があった、ということに尽きると思います。overlayはあくまでtextのpropertyでしかないので、複数のoverlayが設定された場合、その時時で異なる問題が出るであろうことは想像に難くありません PCで日本語を入力する場合、大抵はIMEを使うかと思います。Windows/macOS/Linux いずれも、候補表示そのものは 独立したWindow です。つまり、Child frameをこの用途に使うと丁度いいんじゃないか？というのは前々から考えていました。 すでにあるだろうと探してもなかったので自作することにしたわけですが。 mozc-popupとの比較 Pros org-modeやそれ以外でも、候補表示の時間がほぼ一定 調整の余地はありますが 表示崩れがない これがposframeを利用する最大の利点です 独立したframeを表示しているだけなので、複数のoverlayが設定されることに起因する問題から開放されています Cons install方法が煩雑 melpaとかに入っていないので、どうしてもstraight.elとかが必要です Emacs26以上 + GUIでないと動かない 個人的に、端末上で利用するのはもはや趣味の領域でしかないと思ってます 描画性能もほとんどの場合GUIツールキットの方が早いし、ChildFrameは性質上GUIでしか動きません 端末しかない？諦めてVimった方が幸せになれるかと・・・ ありがとう、mozc-popup mozc-posframeは、mozc-popupのソースを7割くらい流用しています。mozc-popupがなければ、そもそもmozc-posframeを作ろうと思ってなかったと思います。 まだmozc-posframeは若干のバグや性能向上の余地がありますが、すでに常用できるものになっている（というか常用してる）と思うので、よければ利用してみてください。

せっかくの個人ブログなのでこんなものも書いてみます。レビューというか感想ですね。 <!–more–> SEKIRO -SHADOWS DIE TWICE- （PS4版。以下SEKIRO）のプラチナトロフィー取得が終わったので、感想を書いてみます。完全に個人的な感想ですので、仮にこれを読んで買って満足できなかったとしても保証はできかねます。ご了承を。 なお、完全にプラチナ狙いで行ったので、3週目で終了しています。 書いている人間のスペック 前提として、この記事を書いている人間のゲーム的スペックを書いておきます。ライトではないがガチでもない、という普通の領域だと思います。 Demon’s Soul/Dark Soul(1のみ)/Bloodborneクリア経験あり 基本PS4/PCのゲームが主 やり込むというよりはトロフィー狙いが多い 最初の一周は一切攻略サイトとかを見ない、がポリシー どんなゲーム？ 死ぬことを楽しむゲームです なんの説明にもなっていないですね。ちゃんとした紹介は↑の更新サイトを見たほうが早いと思います。Demon’s Soul/Dark SoulやBloodborneをプレイしたことがある方であれば、ああいう感じ、と言えば伝わるでしょうか。SIEとFROM Softwareが手を組んだ作品です。ちなみに SEKIRO は せきろ と読むのが公式だそうです・・・ほんとか？ すっかりSoulライクゲームがFROM Softwareの代名詞になりましたが、30代くらいの人にとっては FROM Software＝アーマードコア とかなんじゃないでしょうか。もうアーマードコアが出ることはなさそうですが、もう一回プレイしてみたいものです。 閑話休題。 さて、Soulライクゲームと同じような感じ、と書きましたが、その内容は大きく異なります。同じなのは死んで覚える、というくらいです。私は最初の一周は公式サイト以外を見ないことにしているので、死にっぷりに拍車がかかります・・・。が、できればSEKIROやSoulライクゲームは最初だけは攻略サイトとかを見ないようにするのをおすすめしたいです。そのあたりは個人の裁量なので、最初からガッツリ見るも詰まったら見るも自由ですが。 SEKIROとSoulライクゲームの違い 簡単に箇条書していきます。 レベル概念の撤廃 Dark Soulとかでは、キャラクターの成長自体が個性になりますが、SEKIROでは成長要素は2つしかありません また、大抵のスキルは プレイを楽にする のではなく、 多様な攻略 を可能にするものなので、これを取ると楽になる！というのはあんまりないです 武器・防具の概念がない 最初っから最後まで装備は一緒です。アイテムで一時的に変更する以外、防御力を上げる手段は（把握している限り）ありません スタミナの概念がない 忍者なので 回避し放題、ダッシュし放題、攻撃し放題です 移動の自由度が圧倒的に高い 鉤縄のおかげで、探索が非常に楽しいです。 致命の一撃を狙うのが基本 HPを削り切る、というパターンは多くないので、特に雑魚戦における戦闘のテンポが非常に早いです ソウルの回収的な要素がない 死んだらそのタイミングできっちり経験値とかが半分になります 救済措置はありますが、あんまり期待しないほうがいいです 要素としては色々ありますが、とにかくゲーム内の要素が 剣を交えること に特化されている感じです。 キャラクターの成長＝自分の成長 Soulライクゲームでは、ある程度はレベルを上げてゴリ押し、ということができました。しかし、前述したとおり、SEKIROではレベルという概念がありません。アイテムを利用しないと、キャラクター自体の成長はありません。そして、そのアイテムは一部を除いて ボスを倒さないと取得できません 。 つまり、ボスで詰まった場合、 自分自身の腕を上げないと攻略できません 。ここでの腕は、相手のパターンを見切る、ということも含みます。この点がSoulライクゲームとの一番の相違でしょう。 逆に言うと、ボスに勝てた＝自分が成長した、ということにほかなりません。特に大ボスは、トドメにイベント的な最後の一撃が必要なんですが、それを行う＝勝利なので、イベント的な演出も含めて 勝利した瞬間の快感は凄まじいです （個人差あり）。 その快感を得るために、次のボスに向かってまた何度も死ぬ・・・と繰り返すことになります。その過程で、ベースになる腕も上がっていきます。 剣戟 を体感する 弾きと体幹システム上、基本的には攻め続けて、相手の攻撃は弾き（＝ジャストガード）し続ける、というのが理想です。そこに至るまでには何度も死ぬことになりますが・・・。逆に、そこに至ると、まさに映画のような剣戟を繰り広げることができます。これがまた気持ちいいんです。 ...

去年の12月くらいから、KotlinでAPIサーバーとバッチを含むアプリケーションを業務で作っていました。その感想を書いていきます。 <!–more–> 本題の前に閑話を。世間から１週遅れくらいで、 SEKIRO -SHADOWS DIE TWICE- をプレイしており、この間一周目が終わりました。私は一周目では攻略サイト等は見ないことにしているので、クリアと同時に解禁してみた所、一周目で出したエンドがなかなか厳しい（他のルートより短く、アイテムとかが集まりきらない）ものだと発覚・・・。若干バッドっぽい選択肢ではあったんですが、まさかそういったものだとは思わず。おかげで二週目が厳しいものとなっております。 複数周回がありそうな選択肢だと、バッドっぽいのから選択する癖があるんですが、それが仇となりました。まぁ、二週目を進めている感じ、明らかにPlayer Skillが高まっており、思ったよりも苦戦はしていないのですが。 閑話休題。 環境の前提 今回作ったアプリケーションは、既存のアプリケーションの完全作り直しなんですが、肝心の既存アプリケーションが PL/SQL で出来ており、完全新規に当たっては DDD を試験的に取り入れています。 Middleware/Framework 利用しているMiddleware/Frameworkは次のような感じです。 Spring Boot 言わずと知れた。 Spring Batch バッチを作成する必要があったので MySQL 現場ではだいたいこれのようでした。 Kotlin 今回の主役 jOOQ ORM。Oracleに接続する場合はcommercial licenceが必要なので注意（繋げなかった人） Gradle 大分こっちを選ぶ人が増えた印象 アーキテクチャ Clean Architecture とDDDを併用しています。Clean Architectureは、とりあえず原典に従って分割している感じですが、現状あまり困っていないです。ここについてもいつか書ければ。 プロジェクト構成 Gradleのmulti project構成を利用して、DomainやGatewayなどの依存方向を強制しています。DDDを実践する上で、Domainに余計な依存を入れないことが重要だと思っているので、これは結構おすすめです。プロジェクトは次のように分割しています。 domain usecase api batch infrastructure 依存関係は以下のようになっています。domainプロジェクトは、 test以外に外部依存ライブラリがない という状態になっています。 domain <-- usecase <- api └- batch Kotlinの適用範囲 全部 です。設定がめんどくさくてJavaになっているものも１ファイルくらいありますが、99.9% Kotlinで書いています。 Kotlin + SpringBootの感想 感想と言っても特筆すべきものはなく、あえて言えば 普通 です。Spring自体がKotlin対応を行っているということもあり、実に普通な書き心地です。 ただ、DIをしまくる関係上、関数で済むようなものでもinterfaceにしないといけないので、その点がストレスです。 @Component class Foo(private val bar: () -> String) { fun exec() = bar() + "test" } みたいなクラスがあったとき、関数をDIすることが出来ない（多分）ので、わざわざinterfaceを定義する必要があります。 ...

いろいろ書くネタを探しているうちに4月になってしまったので、3月にやったEmacs改善について書いてみようかと思います。結構量が多くなったので、分割します。 <!–more–> なお、かなりの部分で Emacsモダン化計画 -かわEmacs編- を参考にさせていただきました。私の.emacs.dはGithubにおいてあります。 https://github.com/derui/dot.emacs.d doom-modeline + all-the-icons doom-modeline all-the-icons 最初に入れたパッケージです。modelineが一気にかっこよくなりました。all-the-iconsでは色々調べましたが・・・。 (use-package all-the-icons :custom (all-the-icons-scale-factor 1.0)) (use-package doom-modeline :commands (doom-modeline-def-modeline) :custom (doom-modeline-buffer-file-name-style 'truncate-with-project) (doom-modeline-icon t) (doom-modeline-major-mode-icon nil) (doom-modeline-minor-modes nil) :hook (after-init . doom-modeline-mode) :config (line-number-mode 0) (column-number-mode 0) (doom-modeline-def-modeline 'main '(bar workspace-number window-number evil-state ryo-modal xah-fly-keys matches buffer-info remote-host buffer-position parrot selection-info) '(misc-info persp-name debug minor-modes input-method major-mode process vcs checker))) なお、全体的にuse-packageを利用しています。 which-key which-key ...

最近 Emacsモダン化計画 -かわEmacs編- を参考にしつつ、しばらくいじっていなかったEmacsをいじっています。しかし、all-the-iconsを導入したときに、アイコンが色々？な感じになってしまいました。 原因を探ったり何なりで解決できたので、備忘録として残しておきます。 <!–more–> 発生していた事象 普段Emacs上ではCicaフォントを使っています。以前はRictyを利用していましたが、Rictyよりもこちらのほうが好みだったので、1年くらい前から愛用しています。 https://github.com/miiton/Cica ところが、Cicaを利用している環境でall-the-iconsを有効にしたら、色々と問題が発生しました。スクショは撮っていなかったので画像はありませんが、次のような状態でした。 doom-modelineのアイコンが明らかにおかしい 保存アイコンが gopher になってたり、gopherのアイコン自体が違ってたり Gitのアイコンが地球儀になってたり アイコンのサイズが色々おかしい all-the-iconsのアイコンを全部表示すると、明らかに別のアイコンが表示されている という感じで、もう完全に何かが干渉していることは明らかでした。 調査 だいたいまずいのはフォント設定周りだろうと、使っているフォント設定自体を無効化すると、うまい具合に表示できました。これから、以下のような仮定を立てました。 追加で行っている設定では、 create-fontset-from-ascii-font で作ったものに set-fontset-font していた set-fontset-font の範囲は 'unicode だった＝all-the-iconsで利用している範囲を上書きしていた？ 仕様上、一回設定したものを上書きできないっぽい＝Cica側の特徴に原因が？ ここまでで、大体Cicaに設定されている絵文字部分とall-the-iconsが干渉している、と判断しました。 解決した 最終的には、Cicaから絵文字を除いたバージョンに切り替え、フォント設定を以下のようにしました。 (defun my:font-initialize () "Initialize fonts on window-system" (interactive) (cond ((eq window-system 'x) (let* ((size my:font-size) (asciifont "Cica") (jpfont "Cica") (h (round (* size 10))) (jp-fontspec (font-spec :family jpfont))) (set-face-attribute 'default nil :family asciifont :height h) (unless (string= asciifont jpfont) (set-fontset-font nil 'unicode jp-fontspec nil 'append)) (when (featurep 'all-the-icons) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-alltheicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-material-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-fileicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-faicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-octicon-family)) nil 'append) (set-fontset-font nil 'unicode (font-spec :family (all-the-icons-wicon-family)) nil 'append)) (message (format "Setup for %s with %f" asciifont size)))) (t (message "Not have window-system")))) この設定を、after-init-hookで実行しています。元々asciiとjpで異なるフォントを利用していた名残の設定だったので、整理しました。普通にset-face-attributeだけでいいんじゃないの？と思われるかもしれませんが、部屋のデスクトップと現場のラップトップでフォントサイズを切り替えられるようにしているので、若干複雑な設定をしています。 ...

タイトルの通り、CRA2 + TypeScriptのプロジェクトに、更にStorybookを追加してみました。 <!–more–> 前口上 いろいろ試すための個人プロジェクトを作って、色々なライブラリであったり、言語であったりを試しています。一応ツールとして利用したいと思って作っていはのですが、永遠に動くようにできないんじゃないかという懸念と戦いつつ実装しています。いつか日の目を見ることを祈りつつ・・・。 FrontendとしてはElectronで作っていて、Create React App + TypeScriptでGUIを作っています。今回、これにStorybookを追加することにしました。 Storybookとは Storybookの公式から、Storybookについてを引用します。 Storybook is a UI development environment and playground for UI components. The tool enables users to create components independently and showcase components interactively in an isolated development environment. https://storybook.js.org/basics/introduction/ Componentのカタログ（showcase）を作り、再利用を促しつつ、生きた例として提供する、という感じでしょうか。 なぜ追加するのか なんとなく＋気になるから。 ・・・いつもどおりの理由ですが、実際コンポーネントベースの開発をしていると、 基底となるコンポーネント が欲しくなります。これがないと、同じようなものが量産されるというのを実際に経験してます。また、実際に動くものがあると、話がしやすいとかの効果もあるようです。デザイナーと協業とかしたことないので、デザイナーから見ても嬉しいのか？というのは実感できませんが・・・。 ただ、いきなりプロジェクトに投入するのはどうなんだ？ということで、どうとでもなる個人プロジェクトで試してみようという次第です。 追加する 今回使うプロジェクトの前提は以下のとおりです。 create-react-appの2.1以降 create-react-app公式の方法でTypeScriptを導入している まずはStorybookを追加します。Storybook公式の手順は npm ですが、私は yarn を利用しているので、以下はyarn前提です。 $ yarn add -D @storybook/react # もしかしたら下のコマンドはいらないかもしれない $ npx -p @storybook/cli sb init # TypeScript向けのlibraryを追加します $ yarn add -D @types/storybook__react $ yarn add -D @storybook/addon-info @types/storybook__addon-info react-docgen-typescript-webpack-plugin $ mkdir .storybook さて、これで追加自体はできるんですが、これだけだと動かないようで、issueが立てられています。この中で示されている解決策を導入してみます。 .storybook/webpack.config.js として以下の内容を追加します。 ...

一ヶ月くらいEucalyn配列でできるだけ生活していたら、CorneでQWERTYが全然打てなくなっててびっくりしました。ノートPCのキーボードではちょっと引っかかるけど普通なので、Corne用の脳領域が出来たようです。 それは置いておいて、つい最近zshからfishへ移行してみましたので、関連する諸々をメモしていこうかと思います。 <!–more–> fishや他のdotfilesは以下で管理しています。 https://github.com/derui/dotfiles 移行の動機 なんとなく。 いきなりこう書くのもどうかとは思いますが、実際↑の通りなので。元々はzshを5年くらい使っていましたが、ここ2年くらいはほとんどカスタマイズとかもすることなく、完全に惰性で利用している感じでした。 zshはemacs/vimのようにカスタマイズを極めれば最高なのは確かなんですが、その時間自体を取れなくなってきた、というのが主な理由です。それと、結構前からfish推しの声を聞いてきたので、試してみたいというのもありました。 移行プラン zshからfishに移行するにあたり、何が必要か？を洗い出してみました。 plugin manager fzf + ghq/historyの連携 各種補完 ・・・めっちゃ少なかった。ので、移行自体はさらっと行けました。 plugin manager zshではzplugを利用していましたが、fishではfisherを利用しました。次のような感じでインストールしました。 # install fisher if not functions -q fisher set -q XDG_CONFIG_HOME; or set XDG_CONFIG_HOME ~/.config curl https://git.io/fisher --create-dirs -sLo $XDG_CONFIG_HOME/fish/functions/fisher.fish fish -c fisher end # change location of packages installed by fisher set -g fisher_path ~/.config/fish/fisher-pkg set fish_function_path $fish_function_path[1] $fisher_path/functions $fish_function_path[2..-1] set fish_complete_path $fish_complete_path[1] $fisher_path/completions $fish_complete_path[2..-1] for file in $fisher_path/conf.d/*.fish builtin source $file ^ /dev/null end fzf + ghq/historyの連携 zshでは、どこかから拾ってきたfunctionをそのまま利用していたのですが、fishでも同じようにして探してきました。 ...

諸事情（主に会社の事情）で、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. ...