Aokashi Room

作った作品の紹介やレビュー、トラブルシューティングとか色々

2017年が終わるので

2017年そろそろ終わりを迎えるのでいつも通り振り返ってみます。

今年は努力と失敗を重ねた年だったと思います。去年の2016年は積極的に勉強会に参加する傾向がありましたが、今年は作品を出したり、試しに動かしたりする傾向が多かったです。

得られたもの

今年制作した作品はこんな感じです。また、これによって得られたスキルも合わせて載せます。

技術的なもの

  • Aokashi Home
    • VPS(サーバー)の設置スキル*1
    • git によるブランチの分け方
    • Hugoによるテンプレートの使い分け方
    • CI による自動化方法
  • WWA Wingのクラシックモード
    • CSSによるテキストの扱い方
  • インターンシップ
  • Node.js(express) で動作するWiki
    • npm の扱い方
    • JavaScriptの非同期処理と同期処理の扱いについて*3
  • 大学の研究室によるソフトウェア開発
  • WWASAVE.js のDocker設定ファイル(未完成)
    • docker-compose.yml による複数コンテナの扱い方
  • WWA Wing PE(現在製作中, 詳細は後述)

aokashi.hatenablog.jp

aokashi.hatenablog.jp

趣味

  • (作品ではないが)PC
    • PC内部の配線の仕方
  • WWA(とRPGツクールMV)の素材制作(去年に引き続き)
    • ドット絵の制作スキル*5
    • ゲームで扱いやすいサイズの決め方
  • WWA FanSquare

aokashi.hatenablog.jp

aokashi.hatenablog.jp

その他

  • ArchLinux のインストールと大学での活用
    • Linuxの運用スキル、主にパッケージの扱い方
    • Linuxで利用できるソフトウェアの選定(これはスキル...か?)
  • (作品はどうかは別として)大学のレポート
    • TeXの扱い方

aokashi.hatenablog.jp

aokashi.hatenablog.jp

まとめ

このように、去年と比べて外部に顔を出す機会が減ってしまったかと思います。また、幾つかトラブルもあって周りにご迷惑をおかけしてしまったこともありました。申し訳ありませんでした。

ちなみに、今年は自身で行動することが多かったです。実は3月辺りでプログラミングのバイトに入るつもりでした。しかしながら、うちの学部の性質上、授業講義で休みの曜日が全然取れず、バイトの参加は無理だと9月に諦めてしまいました。来年は授業に出席することはおそらく無い*6ので、なるべく迷惑を掛けない範囲で外部で行動していきたいです。

遊んでたもの

(作者さんにはつらい話ですけど)Real Train Mod が Minecraft 1.12 に対応したら何か動き出すつもりです。

WWA Wing PE

現在、WWA Wing の拡張機能である WWA Wing PE を開発しています。WWA Wing に WWAeval のイメージ表示機能を(完全移植ではないですが)追加する拡張機能です。

この WWA Wing PE を使うことによって、フィールドを暗くしたり、エフェクトで派手な攻撃を演出したりすることが簡単にできるようになります(多分)。

ある程度完成したら、 WWA Wing に機能追加していこうかと思います。

最後に

最近は関数型プログラミング言語の Haskell の学習を初めてみました。使う側も開発する側も扱いやすいソフトウェアを頑張って開発していきたいです。

それと、今年PCを組み立てたんですが、これからはノートPCをメインに使う傾向が多いです。プログラミングに使うソースファイルを毎回2つのPCの間で転送するのが面倒ですので...*7

ということで、来年もよろしくお願いします。

*1:主に公開鍵認証によるSSH接続の辺り

*2:前からある程度は知っていたけど、知らなかったものもあって使っていて便利に感じました

*3:個人的にはまだ理解していないですが...

*4:主にステートパターンによる状態ごとの処理の分割

*5:主に光の当たり方による色の使い方

*6:仮に取得できない単位があっても、バイトの行動に支障は出ないはずです。

*7:余談ですが、ノートPCをメインにすると思い始めた頃にはノートPCの故障が頻発したことがありました。現在は落ち着いています。

ThinkPad Yoga 260で起こるプチフリ現象を探ってた

去年の6月に購入したThinkPad Yoga 260ですが、一瞬画面の動きが止まる「プチフリ」の現象に悩んでいました。現在は問題を見つけたため、落ち着いていますが、もしかしたらまた起こるかもしれません。ただ、参考になるかもしれないので記録しておきます。

症状

  • 一旦カーソル操作が止まったりする(3秒程度?)
  • 時には一切応答せずフリーズしてしまう場合がある
    • この場合はPCを閉じてスリープ状態にすればフリーズは解消される
  • ただし、動画再生中やキーボード入力中は発生しない
  • プチフリ発生中に何か操作を行った場合、その操作は反映される
  • 音声が再生されている場合、音声は再生されたままで止まらない

下記で対策を施した時点では、上記の症状をすべて知っているとは限りません。特に音声再生の問題についてはかなり後で知りました。

まず初めに

動作がおかしいと疑い始めた時に、ソフトウェアのアップデート(Windows UpdateLenovo Companionとか)を行いましたが、直りませんでした。

また、プチフリが発生したときにイベントビューアのログを見ましたが、プチフリらしきログは見当たらず...。

Creators UpdateとSSDを疑う

この症状は Windows 10 の Creators Update を適用したときに疑い始めたので、Creators Updateが悪いと思ってインターネットで記事を探しました。ニュースに取り上げられるような記事がなく、解決策も少なかったのですが、SSDのLPM機能が働いていると聞きました。ちょうどSSDが不調かなと思ったところでこのLPM機能をオフにしました。また、システムがうまく動かないと言われている高速スタートアップもオフにしました

が、両方行っても直りませんでした*1

SSDを交換してみる

ここまで行ってだめならハードウェアが悪い、と思いSSDを交換することにしました。プチフリが起こりやすそうなSATA接続のSSDを避けてPCIe接続(NVMe規格)のSSDを購入すれば何とかなる、と思っていましたが、まだ高価なため、SATA接続のSSDで我慢しました。

結果、WD Blue SATA SSD (3D NAND 512GB) を購入して、交換しましたが、症状はそのままでした。

じゃあPCIe接続のSSDに切り替えるか...と思ったところでPCが不調になり、起動に時間がかかったり、スリープから復帰できなかったりしました。修理に出しましたが、このプチフリの件をサポート側に伝えるのを忘れてしまったのか、修理後でもプチフリはそのままでした。

発生条件を確かめる

このプチフリは、前述の通りタスクマネージャーを起動したままだとほぼ発生しませんでした。タスクマネージャーはプロセッサをよく利用することから、常駐するソフトウェアでもインストールすればいいのかと思い、セキュリティソフトを導入しました。そして、カーソルが動かないことは、ポインティングデバイスに問題があると思い、タッチパッドの無効化を解除しました

が、どれも症状は直りませんでした。

グラフィックが悪かった

もうLenovoサポートに連絡でもしようかと思っていたんですが、ここでIntelのグラフィック設定があることに気付き、デスクトップのコンテキストメニューからIntel Graphicsの設定画面を開きました。

f:id:aokashi:20171210201309p:plain

いろいろ項目を見て確認したところ「パネル・セルフリフレッシュ」の項目が怪しいと思い無効にしました。

f:id:aokashi:20171206193357p:plain

この後プチフリらしき症状は見当たらず、ちゃんと動いています。

何が起きているのか

「パネル・セルフリフレッシュ」は「画面がずっと同じのままで表示されている場合はGPUを停止して、省電力化を図る」ものでした*2。なので、画面がずっと静止状態にならなければ、この症状は起こらないのでは、と思います。なので

  • タスクマネージャーを開きっぱなしにして、タスクバーのアイコンを常に表示するようにする
  • タスクバーの時計で秒を表示するようにする*3
  • タスクバーに常にモーションを加えるツールバーを入れる*4

のようにすれば、症状は直るのではないかと。でも、上記のグラフィック設定をすればそこまでする必要はないですよね。

また、この設定はLinuxでも変更できるみたいですので、Linuxでもおかしいと思ったら修正はできます*5

ちなみに、購入したSSDはデスクトップPCにも装着できるので、無駄な買い物にはなってないかなと思います。

*1:ただ、発生頻度は落ちたかなー、と思ってました

*2:参考: 「新しいThinkPad X1 Carbon」開発チームに聞く、“あのキーボード”に込めた意図 (1/4) - ITmedia PC USER の3ページ目

*3:表示の仕方はここでは割愛します。

*4:TTClockでもありですね。私がWindows XPを使っていた時は愛用してました。

*5:参考: Intel Graphics - ArchWiki

Node.js(Express)で動くWikiを作ってました。

11月1日~7日の7日間は大学の休講日でした。この7日間を利用してWikiのシステムを作ってみました。

github.com

現在はページの閲覧と編集、ページの一覧表示が出来ます。ページは名前(ファイル名)と内容からなり、タイトルは内容の見出しで代わりに使う形になります。

f:id:aokashi:20171112003338p:plain

検索機能は見た目だけ出来ていますが、まだ完成していません。今後は、以下の機能を実装する予定ですが、自身のWebサイトのリニューアルもあるのですぐには難しいと思います。

  • 検索機能の実装
  • ページのバージョン管理
  • メニュー(サイドバー)の実装
  • markdownの書式にちゃんと対応できるようにする
    • 上の図では、リスト1, 2, 3 と2つ連続していますが、そのうち片方は 1., 2., 3. と出すつもりでした。

仕様

リポジトリ名の「express-test」は仮称です。今後変更する予定があります。

作成の経緯

こちらはWebサイトで記事が完成した後に移転する予定です。

Wikiのシステムを作りたい理由はいくつかあって、インターネットにあった様々なWikiのシステムには惜しいところがそれぞれありました。

  • Pukiwiki(現在自分のサイトの資料集で使用中): markdown記法に正式に対応していない
  • dokuwiki: 同上
  • gollum: タイトルが日本語だと取り扱いに難がある*2
  • crowi(まだ使った経験が無いです): チーム内でしか見ることが出来ない(はず)

また、GitHubWikiも使っていましたが、ページ名が最初からサイドバーに付いていることとリポジトリ1つ作らなくてはならない制約から、資料集のような形で使うつもりはありませんでした*3

つまり、 日本語がちゃんと扱えて、markdownも使えて、周りから見える、たくさんページを持つことに適したWikiシステム を求めていたのです。

自分で作ろうと思ってはいたものの、なかなか動き出せませんでした。後になって色々な事情で悪いことがあって自信を失ったことから、技術力を上げるためにWikiシステムを短期間で作成することにしました。

動作環境はWebブラウザで動くアプリケーションをメインに開発しているため、JavaScriptで使えるNode.jsを選びました。

1人単独の開発のため、意見を出し合う時間が無くマイペースで開発を進めることが出来ましたが、決めた目標の定義が曖昧で「これでいいか」と思って中途半端に切り上げたことや、実装の仕方に悩むこともありました。しかしながら、今後npmで新しいパッケージが出てきたときに、短時間で組み込んで確かめられる機会が出来ました。

現在はQiitaのような情報共有サービスが進んだことから、自身がWikiを設立して備忘録の代わりに使うケースは減りました。私の場合は世界観の資料を扱うこともあって、Wikipediaのような百科事典のサイトが適していることから、開発を続けていくつもりです。

最後に

もしかしたら、実装の仕方に誤りがあるかもしれません。GitHubでIssue投稿やPull Requestをお待ちしております。あと早いうちに名前を決めます。

*1:2台の実行環境があって、片方がHome、片方がProのエディションを持っています

*2:ただしあくまで自分からの経験によるものです。

*3:開発関連の資料をまとめるのであれば、GitHubWiki機能は大変便利だと思います。

Speaker Deckのスライド公開取りやめについて

先月の8月27日、私のSpeaker Deckのスライドを、一部を除き公開を取りやめました。

Speaker Deckにはライトニングトーク(LT)で発表したスライドが含まれていて、発表後では内容を調整して公開していました。しかし、自分自身無理してスライドの制作、発表を行っていたため、公に出せるようなものではないと思い、公開を取りやめることになりました。決して、高頻度でLTのスライド制作と発表を行うことに悪いことはありません。

今後、公開を取りやめたスライドの公開を再開する予定はありません。それでも必要でしたら、私までご連絡ください。また、この後も現在公開しているコンテンツの公開を終了する場合もあります。

スライドの公開の取りやめでご迷惑をおかけしたこと、そして報告が遅れたこと、お詫び申し上げます。申し訳ございませんでした。

句読点を末尾に持っていける文章表示プログラム

前に、GitHubのGistにこんなものを投稿しました。

句読点がメッセージの末尾にきた場合、折り返さずに詰めるプログラム · GitHub

これは、文章を表示する際に、横末尾*1の文字の次が句読点*2だった場合に、その句読点を折り返さずに末尾に持っていくプログラムです。

実際に聞いてわからないと思うので、動いている様子を見てみましょう。

f:id:aokashi:20170810181655p:plain

句読点の「、」が3行目にはみ出していることが確認できますでしょうか。

以下は、Gistのソースコードです。長いので動く仕組みとかどうでもいい方はそのままスクロールしてください。

句読点がメッセージの末尾にきた場合、折り返さずに詰めるプログラム

注意

ただし、このプログラムをうまく動かすには幾つか条件があります。

  • フォントは固定幅フォントを利用すること
  • 文字数として全角文字は1文字で、半角文字は0.5文字でカウントします
  • CSSletter-spacing は利用しないこと(利用すると半角文字2つ分の幅が全角文字1つ分の幅と合わなくなるため)

そもそもなぜ作ったのか

多分ここが本編かもしれません。

役に立ちそうだけど、実際に使われている場面は想像しにくいと思います。

これは、JavaアプレットWWAのメッセージの表示方法を再現したかったからです。なお、Javaアプレットで実装されているWWAのことをこれからは原作と言います。

現在、JavaScript移植のWWA Wingを原作っぽく再現するようにしています。原作では、メッセージが横16文字分収まりますが、句読点をその横にはみ出すこともできます。

f:id:aokashi:20170810182826p:plain

原作では、上の図のように動いています。最終行に句読点がメッセージとメッセージ枠の隙間に付いていることが確認できます。

WWA Wing ならではの問題

WWA Wingは原作と違って、メッセージがHTML上でテキストがそのまま表示されます。わかりにくいと思いますが、この実装により、メッセージの内容をそのままテキストとして選択やコピーができます。試しにテキストのカーソルを載せると、文字が選択できる状態になっていることが下の図で確認できます(参考)。

f:id:aokashi:20170812140212p:plain

原作では、文字列を1文字ずつ描画して、折り返す必要になったときには描画位置を決めている変数を操作します。わかりやすく説明すると、xpyp が存在していて、それぞれ文字を描画する画面のX座標、Y座標を表しています。折り返す場合は xp を0にして、 yp に1行分足す仕組みになっています。ただし、次の文字が句読点だった場合はその操作をスキップする仕組みになっています*3

ただし、WWA Wingでは、HTMLのテキストが表示される都合上、Javaアプレットでは一切関わらないであろうHTMLの親子関係が存在しています。メッセージ枠の要素にメッセージが入るため、文字の位置はここで!とかのように細かく調整することができません*4

そこで、原作の仕様を似た形として、折り返す場合は br 要素を挿入して改行する方法もありますが、下の図のようにメッセージ全体をコピーして、貼り付けた結果に改行が含まれてしまいます。ページ内検索や、貼り付けたテキストへの検索を行う方もいますから、なるべく必要以上に改行されたくないのです。

f:id:aokashi:20170812142237p:plain

解決策と実装方法

このような問題を解決するために改行の代わりに実際に表示する1行分それぞれspan 要素として設ける形にしました。

  • 実際に表示する1行分は、折り返した場合に表示される1行分です。

はみ出た句読点を置くために、1行の領域に複数の span 要素が入らないために、その要素の幅はメッセージボックスいっぱいに指定しています(width プロパティが 100%)。

しかし、インライン要素は幅が指定できないため、その span 要素にはCSSdisplay プロパティには inline-block を指定しています*5

f:id:aokashi:20170812195737p:plain

説明した通りに、要素の仕組みを上の図で表す事ができます。赤い枠が span 要素になります。ここでは6つあります。

こんな感じで、今回制作したプログラムはこのように利用しています。気になる方は、プログラムのHTMLファイルを開いてみて、開発者ツールで要素を確かめてみてください。

このような実装はCSSには存在しない

残念なことに、今回のプログラムのような実装はCSSでは用意されていません。まあ、用意したらここまで苦労する必要はないと思うんですがねー...。

似たものとして font-feature-settings プロパティがありますが、句読点のみならず、カギ括弧も対象だったり、そもそも末尾に置かなくても詰めてしまい本来の目的と違っていたりするので、使おうとは思いませんでした。

最後に

とりあえず「できた」のですが、今後の課題とかは現在思いつきません。もしあるとしましたら、横幅の文字数を指定しなくてもいいようにしたいこと、計算量を減らすためにアルゴリズムを最適化すること、でしょうか。

ちなみに、原作っぽく再現したWWA Wingはもう少しユーザーに体験できるようになります。

  • 8月24日追記:ベータ版が公開されました、お確かめください。→WWA Wing

*1:折り返す直前の文字の、次の文字で、文章全体の一番後ろではありません。

*2:ここで指す句読点は「。」と「、」の2つです

*3:ただしメッセージには枠や余白も存在しますので、必ずこの方法で描画するとは限りません

*4:しかし、その分文字を置くだけというメリットは存在しますが...

*5:幅が 100% なら単純に div 要素使ったほうが楽かもしれないですが、ブロック要素になると先程あげた br 要素の挿入と同様に貼り付けたテキストに改行が生じます。

RPGツクールMVに列車を走らせるぞ

今までWWAの素材向けに列車の素材を制作していました。しかし、マルチプラットフォームRPGツクールMVが発表されました。素材規格は1マス48×48と、32×32や40×40よりも更に広い解像度になります。

もちろん今まで制作した素材を使いまわすのは違和感があるし、色数を気にしないことからいっその事使いたい色数で制作できることから模索しながら制作しました。

  • 説明に利用されている画像は素材公開前に制作したものと、後に制作したものが混合しています。
  • ここでは、列車の正面から見たイメージを前面、側面から見たイメージを側面と言います。
  • どんな感じで作ったか、長めで説明します。

以下は目次です。

とりあえず作る

まずは前面の横幅を48pxにした形で制作しました。結構小さいようですが、RPGツクールMVの自動車の素材もかなり小さく作っているので、これでもいいかと思って制作しました。

f:id:aokashi:20170717195630p:plain

ここで映っているのは205系です。最近までは列車の素材を作るときに205系をお手本にすることが多かったです。でも、上の図では何か違和感があります。高さの割に奥行きが少ないように見えます。

見る角度を決める

まず列車を見る角度を定める必要がありました。そのため俯角による高さと幅の関係を決めました*1。ある角度から見下ろした際、実際の幅や高さはどれほど縮小するのか、計算します。

俯角は45°に決まりました。例えば、前面の高さが1とした場合、45°から見下ろすと√2で割る形になるため、0.70710...となります。45°ということは0°と90°のちょうど中間ということで、天面の奥行きも同じことがいえます。

f:id:aokashi:20170717195649p:plain

上の図のように縦に潰れたような感じですが、まあ良くなりました。また、この時は前面の幅を96pxにした形で試作もしていました。

サイズの選定

48pxは小さすぎる、96pxは大きすぎると思い、ここで最適なサイズを探しました。

元になる高さと幅の比率も決める必要がありました。最適な比率を求めて、Wikipediaの車両限界*2や手元にあった東武鉄道の電車見取り図のクリアファイル、各鉄道会社の車両紹介などから、最適な比率を求めました。ここで、幅2800mm, 高さ3600mm(床下分を除くと2700mm)鉄道車両をベースにしました。

ここから、様々な幅で簡易な形で列車の素材を制作、調査しました。

  • 48px
  • 60px
  • 64px ... 一時期はRPGツクールVX(ace)で2マス幅になる64pxを検討していた
  • 68px
  • 70px
  • 72px ... 48pxと96pxの中間のサイズ
  • 78px ... 新幹線を96pxのサイズにした場合、在来線になるとこのサイズになる
  • 96px

更に条件を縛る

制作や調査をしましたが、それでも最適なサイズが見つからないので、ここから条件を加えました。

  • ドアのサイズはプレイヤーに収まる程度のサイズにする。
    • 程度なので、収まらなくても良い。
  • マス単位でピッタリ収まるようにする。

まず上記の条件で幅48pxは除外になります。やっぱり、48pxは小さすぎましたね。

それでも見つからない...と側面で縦のポジションを確認しました。下の図のように、この時は線路を中央に置くように基準を決めていましたが、この場合になるとドアがマスの境目を跨ぐ形になってしまい、大変使いづらいことが分かりました。でもなぜ線路を中央に置きたかったのか、これはなかなか説明しづらいのですが、縦と横の線路でポジションを揃えることで、カーブの素材を作りやすくしたかったからです。なお、線路を中央に置いた場合、幅60pxが上のマスでピッタリ収まります。

f:id:aokashi:20170716213832p:plain

ここで、側面のポジションを、ドアがマスの下辺と接するように基準を変えました。最終的には、横幅70pxに決まりました。理由は色々ありますが...

  • 上記の要件を満たしている(ただし側面で2マスピッタリ納める場合は、床下分を除く必要がある)
    • 前面はドアが見えず、側面より使う場面が少ないと思うので、前面の場合は横幅2マスピッタリにはなりません。
  • 定めた幅2800mmは70の倍数なので1px辺り40mmちょうどと、この後実際のサイズ[mm]から作る際[px]には計算しやすい
    • つまり1000[mm]の横幅にしたければ40[mm]を割るだけで25[px]になる!

f:id:aokashi:20170716213847p:plain

やった!いい感じに乗れる!(上図参照、キャラクターが僅かにドアと接しているのはRPGツクールMVの仕様です)

f:id:aokashi:20170716215600p:plain

先程Twitterでアップロードした検証用ファイルは最終的に上の図になりました。横幅70pxの分にドアの分が塗っていませんが許してください。幅96pxになるとほぼリアルスケールになりますが、このサイズになると制作するのも利用するにも難しいですね...。

制作に取り掛かる

WWAで制作した時は他サイトの素材を混合する際に変色しないように決まった色数で制限をしていましたが、RPGツクールMVの場合は特に制限を受けることもないので使いやすい色数で制作しました。ただし、色を決めるのが下手であることと、8や16の倍数でRGB値を求めたいことから、やっぱり256色で制作しました。下の図の通り、制作に利用しているパレットはWWAで制作したものをベースにしています。

f:id:aokashi:20170716221203p:plain

制作した素材がこちらになります。前面の素材が無いですが許してくだ(略)。

パンタグラフの制作は大変でした。側面から見ると大きいように見えるけど、正面から見ると予想より結構狭かったです。

ところで...RPGツクールMVのSeason Passには蒸気機関車の素材があります。この場合は私の2倍以上のサイズになっているようですね。床の上に乗車することはありえない、いや海外だったらあるかもしれないですが、このままのサイズで制作するつもりです。

ちなみにスクリーンショット以外の画像は好きに使ってください。あ、利用する時はAokashi Homeから利用したよ、みたいな報告があれば喜びます。この後ちゃんと素材コンテンツに追加するつもりです。

f:id:aokashi:20170717211423p:plain

最後に...国鉄時代の車両によくある、前面右側面の金具は何でしょうかね。タブレット閉塞にタブレットを掛けておくもの...じゃ無いですよね。

お世話になったサイト

2018年3月28日追記

公開しました。この記事を公開したときよりも凝って作ってます。

TeXやnpmがだいぶ分かってきたお話

最近までは、レポートを制作する際にMicrosoft Wordとかのワープロソフトウェアを利用していました。というのも、去年か一昨年辺りにTeXを利用しようとして途中で挫折したことがあったためです。

最近までは周りがTeXやnpm、herokuとかを使いこなしている中、私だけ*1なかなか理解できず追いついていけない状態でしたが、だいぶ分かってきたので記事に残しておきます。なお、TeXとnpmの間で関係とかは無いのでそれぞれ別に説明します。ちなみに、下記の説明は間違いが残っているかもしれません。

TeX

TeXは簡単に言うと、記号と文字列を組み合わせて紙の文章に印刷できるPDFファイル*2を生成するプログラムです。TeXと一口に言ってますが、実際は派生*3が数多く存在していて、現在は機能的にもその派生を利用することが多いです。HTMLがWebサイトを作るためにテキストで書いているならば、TeXは文章を作るためにテキストで書いている事になります。多分。

TeXの環境構築で挫折した

そんなTeXですが、最近までは環境構築で挫折していました。環境構築をし始めた時はTeX Live(詳細は後述)をインストールしていましたが、そのままインストールして容量を大きく取っていたことで後に手放してしまいました。

その後、Linuxを使い始めて、TeXのエディタも使い始めたのですが、実行の際にエラーが表示されてうまくいきませんでした。この後、検索で資料を得るなりした所、自己解決しました。

  • 前述の通り、TeXのプログラムは派生が数多く存在していること。そしてその上にプラグインを活用して、出力する文章のバラエティ(?)を広げている。
    • この2つを導入するには数多くのプログラムとプラグインが必要なので、ここでTeX Liveでインストールすることで手間が省ける。
  • また、TeXのエディタはTeXのプログラムと別であること
    • エディタはどうしようかとそれぞれインストールして試しましたが、TeXWorksで落ち着きました。
    • インストール後はTeX Wikiの記事に従ってタイプセットを追加しました。
  • TeX Liveは確かに容量を大きく取るが、インストーラーの際は「スキーム」を選ぶことで容量は削減できる

TeXはHTMLやmarkdownのような手軽さには及びませんが、学べる環境が構築できただけでも大きな進歩だと思いました。

npm

npmはパッケージマネージャです。パッケージマネージャについてはLinuxを学ぶ際に理解しているものの、今までの感覚で試すとエラーばかり出力されてしまい、困っていました。

Webでは npm install (パッケージ名) とかの箇所がよく目立っていて、「(パッケージ名)をパソコンにインストール...ただの実行ファイルをインストールして何に活用するんだ?」と思っていました。

Angularを学習し始める時からnpmについてだいぶわかってきました。Angularを入れる際も、npm install angular@1.6.4*4 と記載されていて、疑問を持ちながらnpmでインストールした所、ちょっとした便利さを感じました。

  • npmはJavaScriptCSSのファイルを取り扱う際でも、バージョンアップのためにWebからダウンロードする手間が省ける。
    • 「パソコンにインストールする」のではなく、「プロジェクトにインストールする」感覚で扱う。
  • ただし、コマンドラインから実行するプログラムも存在する。パソコンにインストールする感覚で扱いたい場合はインストールの際に -g を添える。

以前は bower を、最近は yarn を扱うことが多いみたいですが、まだ初心者なので npm で慣らすことにします。

その他

現在、Dockerやherokuとかのインフラ系の知識が疎い*5ので、色々構築して学んで見ましょうかね。

*1:もしくは周りの一部かもしれない...

*2:TeX初期の頃はDVIファイルでしたっけ?

*3:LaTeX, pLaTeX, ...

*4:バージョンは2017年6月26日現在

*5:特にDockerは大量の仮想マシンが同時稼働することで、リソースの使用量に疑っている