「tips」の記事 - Crieit

Galaxy Angel（無印）を 64bit の Windows 10で動かす際のTips

2020-10-25T04:17:51+09:00

TL; DR

異常にもっさりしてしまいのは、対象 DirectX が古く、 FPS が早くなりすぎるのが原因です。
FPS を60に固定化することで、解決できます。

本記事の内容は、あくまで自己責任でお願いします。
ゲームの動作対象外であるため、万が一のことがあっても僕は責任を持てません。

はじめに

かつて一世を風靡した、 Galaxy Angel をご存知でしょうか？
ブロッコリーによる、キャラクターメディアミックス企画 Project G.A. のゲーム版第1作品です。
通称、 GA （無印）と呼びます。

アニメ版ではコミカルギャグ調一辺倒、ゲーム版ではシリアス一辺倒と、作風／キャラの性格／背景などがまるで違う作品として、後世に多大な影響を与えたシリーズとして有名ですよね？（同調圧力）

ギャラクシーエンジェルとは (ギャラクシーエンジェルとは) [単語記事] - ニコニコ大百科

ゲーム版では、 ADV（アドベンチャー）パート／艦内移動パート／ SLG（シミュレーション）パートの3つで構成されています。
この中でも SLG パートは、 DirectX をゴリゴリ駆使したであろう、 3D で宇宙空間を舞う戦闘機を自在に操作できるシステムであり、個人的に一番オススメできる部分です。
特に通常戦闘時の BGM が良い！

INTRODUCTION | GALAXY ANGEL

PC ゲームとして 2002 年に発売した今作は、当然ながら動作確認環境は Windows 98 以上、 DirectX 8.1 以上と古く、64bit 版 Windows 10 での動作は想定されていません。

しかし、僕は何としてでも、このゲームを、特に SLG パートを、いま遊びたいと思いました。
その際に、引っかかった点と解決策を、それぞれ記します。

Galaxy Angel（無印）を Windows 10 で遊ぶための軌跡

GA（無印）を Windows 10 で遊ぶためには、次の作業が必要です。
調べてから知ったんですが、このゴリゴリ 3D ゲームを CD に突っ込んでたんですね......

CD-ROM でのインストール
修正パッチの適用
- FAQ | GALAXY ANGEL
ゲーム起動準備
ゲーム起動

本記事では、ゲーム起動準備についてのみ説明します。
インストールと修正パッチ適用はできたものとして、以降の内容を読んでください。

全画面強制起動を止める

起動すると厄介な問題が後に控えているので、全画面強制起動を確認したい場合は、次節での FPS 設定を終わらせてからにしましょう。

インストールした GA.exe をダブルクリックすると、全画面でゲームを起動してしまいます。
今時 PC ゲームで全画面強制なんてまず無いですが、昔のゲームあるあるですね。

これを防ぐには、ショートカットを作成します。

まず、GA.exe をコピーして、適当なディレクトリ（一般的にはデスクトップでしょうか？）に右クリックで「ショートカットの貼り付け」を選択すれば、ショートカットを生成します。

次に、生成したショートカットを（ダブルクリックではなく）クリックで選択し、右クリックで「プロパティ」を選択すると、ショートカットファイルのプロパティ画面を表示します。

そして、「ショートカット」タブを選択し、「リンク先」の項目の最後に -w を入力して「OK」を押してください。

before: "C:\Program Files (x86)\BROCCOLI\GalaxyAngel\GA.exe"
after: "C:\Program Files (x86)\BROCCOLI\GalaxyAngel\GA.exe" -w

以上で、設定は完了です。
ショートカットをダブルクリックすると、ウィンドウ表示でゲームが始まります。

FPS を固定化する

一度、ショートカットをダブルクリックしてみてください。
「にゅにゅにゅにゅにゅ、ブロッコリーにゅ」というデジコの声と共に、映像が流れると思います。

Di Gi Charat Official WebSite でじこのへや

問題は、そのあと、真っ白な画面がしばらく続きながら、BGMだけ流れている状態になってしまう点です。
これは、ゲーム画面描画が異常に遅いだけで、1分ほど待機すれば、起動画面が表示されます。

何故かわかりませんが、他のウィンドウやデスクトップなどをクリックすると（ゲームウィンドウを非アクティブ化すると）、描画がスムーズになります。

これは、対象 DirectX が古すぎて、 FPS を固定化できていないことが原因のようです。
以前調べた時は、 FPS が 240 くらいになっていました。

dmm版ギャラクシーエンジェル Windows10でのウィンドウモードプレイの仕方まとめ / Twitter

これを解決する方法の1つに、 DEC と呼ばれるツールを利用する方法があります。

DEC の入った ZIP ファイルをダウンロード／解凍し、中身を GA（無印）が入ったディレクトリに置いちゃいましょう。
既定では、ウィンドウ画面の左上に、 60 FPS で固定化している様子を表示しているはずです。

これで、設定完了です！
ショートカットをダブルクリックし、ゲームを楽しみましょう！

おわりに

僕には大事な情報ですから、記録のために書いておきました。
ご興味がある方や、手元に CD が残っている方は、ぜひ楽しみましょう。

DMM 版もあると聞いて調べたんですけど、今はもうリンクが切れてるため、おそらく販売停止ぽいですね、残念......

ギャラクシーエンジェル　PC版について。 - Togetter

username や filename は、これから区切ろうと思う（userName や file_name としようと思う）

2020-10-20T14:04:20+09:00

TL; DR

区切らない場合、属性が追加される際に面倒になると思いました（実際なりました）。

はじめに

username とか filename を区切らない派でしたが、今日から区切る派（userName, file_name などと命名する派閥）になろうと思います。

区切る派に変更した理由

急に新しい name 属性が増えた際に、対応が面倒だと気づいてしまいました。

例1

username （ユーザー名）属性が存在する際に、「ユーザー表示名」属性が必要になった場合、 userDisplayName と username が併存しているのは気持ち悪いです。
かといって、 displayname は長すぎて、個人的には区切りたい欲が強くなりますが、その場合は displayName と username が併存するため、やっぱり気持ち悪いです。

例2

filename （ファイル名）属性が存在する際に、「入力ファイル名」属性が必要になった場合、区切りとして input_filename は違和感があります。
かといって input_file_name と filename が併存しているのは気持ち悪いです。

おわりに

命名は難しいですね。

PowerShell で Git の reset/stash などを使う際に履歴を指定する方法

2020-10-04T23:29:37+09:00

本記事は、 Qrunch からの移転記事です。

移転元: PowerShell で Git の reset/stash などを使う際に履歴を指定する方法 - 雑木林

TL; DR

中括弧で表記する文字列は ' で囲みましょう。

はじめに

みなさんおなじみ、履歴を戻すコマンドは、下記の通りです。

gitで履歴を戻すコマンド（実行不可）

git reset HEAD@{0}

また、スタッシュを適用するコマンドは、下記の通りです。

gitでスタッシュを適用するコマンド（実行不可）

git stash pop stash@{0}

しかし、 PowerShell で上記を実行しようとすると、次のエラーが発生し、履歴リセット／スタッシュ適用できません。

PowerShellで履歴を戻そうとした際のエラー

error: unknown switch `e'

解決策

PoserShell では、中括弧に特別な意味があるため（スクリプトブロックと呼ぶらしい）、中括弧内の文字列をコマンドとして実行してしまうからみたいです。

about_Script_Blocks - PowerShell | Microsoft Docs

' で囲み文字列化することで、実行できます。

gitで履歴を戻すコマンド（文字列化）

git reset 'HEAD@{0}'

gitでスタッシュを適用するコマンド

git stash pop 'stash@{0}'

または、中括弧エスケープ処理をすることでも可能です。
PowerShell のエスケープシーケンスは ` ですよね。

gitで履歴を戻すコマンド（エスケープ処理）

git reset HEAD@`{0`}

git reset HEAD@{1} results in error · Issue #106 · dahlbyk/posh-git

おわりに

エラー文だけでは理解できず、地味に苦労しました。
PowerShell は ~~めんどくさい~~ 奥が深いですね。

GitHubのデフォルトラベルを和訳 + 絵文字付加

2020-10-04T23:26:27+09:00

本記事は、 Qrunch からの移転記事です。

移転元: GitHubのデフォルトラベルを和訳 + 絵文字付加 - 雑木林

TL; DR

絵文字	原文	和訳
🐛	bug	不具合
📝	document	ドキュメント
🔙	duplicate	別チケット有
✨	enhancement	新機能など
🤝	good first issue	初心者歓迎
🆘	help wanted	助けて！
⛔	invalid	不適当な内容
❔	question	質問
❌	wontfix	意図的な中止

はじめに

GitHubのリポジトリを最初に作成すると、Issue／プルリクのラベルとして、下記が出現します。

これらの意味を知りたくなったので、調べてみます。
ついでに、該当しそうな絵文字を探して付けてみます。

各ラベルの説明と和訳と絵文字

以降、各ラベルについての説明と和訳、そして絵文字を付けてみます。

下記に参考ページを載せます。

About labels - GitHub Help

bug

特に言う必要は無いと思いますが、バグですね。
ただ、日本ではバグという言葉は強すぎるという意見もあるので、「不具合」の方がいいかもしれません。
絵文字は 🐛 でいいんじゃないですかね。

documentation

これは、比較的最近作られたラベルですかね？
上記画像のリポジトリは2年前くらいに作ったので、存在しないです。

純粋に、「ドキュメント」で良いと思います。
絵文字は 📝 にしましょう。

duplicate

これは、既存のIssueが既に立っていることを示します。
「別チケット有」なんてどうでしょうか？
絵文字は、ドンピシャなものが無かったのですが、 🔙 とします。

enhancement

新機能や要望のIssueでよく見かける気がします。
「新機能など」とすることで、機能追加以外についてもこのラベルで対応できるのではないでしょうか。
絵文字は、みんな大好き ✨ です。

good first issue

直訳では「最初のIssueに良い」ですかね。
実は「最初のコントリビューター向けのIssue」、という意味があるそうです。
意訳ですが、「初心者歓迎」なんてどうでしょうか？
絵文字は 🤝 なんていいですね。

OSS 貢献における GitHub の Issue 探しについて手始めに調べてみた - Qiita

help wanted

GitHubのヘルプページには「メンテナが課題やプルリクについて助けを求めていること」とあります。
ということで、意訳ですが「助けて！」としてみます。
最後のびっくりマークにより、声を大にして求めている感じを出しています。
絵文字は 🆘 がぴったりです。

invalid

文法エラーなどでもよく登場しますが、直訳では「無効な」という意味です。
Issueにラベル付けすることを考えると、「不適当な内容」としてみると良いかもしれません。
不適切とまでは言わないが、Issueに価値が無くなってしまったことを伝えたいです。
絵文字は悩みましたが、このラベルが付いたらクローズされそうなので、 ⛔ としてみました。

question

質問する際に使えますね。
和訳も「質問」で良いと思います。
絵文字は ❔ としてみます。
❓ もありますが、デフォルトラベルの背景色が赤紫っぽかったので、白色の方にしました。

wontfix

不具合はあるが未修正のままにするなどのように、あえて変更しないことを意味します。
「意図的な中止」とすることで、意図が伝わる気がします。
絵文字は ❌ がいいですかね。

おわりに

英語だととっつきづらいものも、日本語にすることで理解が進みますね。
絵文字文化ももっと広まることを願います。

Gitのコミットメッセージに絵文字付きプレフィックスを適用する

2020-10-04T23:25:37+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Gitのコミットメッセージに絵文字付きプレフィックスを適用する - 雑木林

TL; DR

コミットメッセージのプレフィックスは、Angularスタイルを基準としています。
また、各プレフィックスに絵文字を付ける際は、下記のようにしています。

プレフィックス	絵文字	絵文字の綴り
feat	✨	sparkles
fix	🐛	bug
docs	📝	memo
style	📁	file_folder
refactor	♻️	recycle
perf	⚡️	zap
test	✅	white_check_mark
chore	🍰	cake
init	🎉	tada
merge	🔀	twisted_rightwards_arrows
review	👌	ok_hand
wip	🚧	construction

はじめに

コミットメッセージにプレフィックスを付ける文化が、少しずつ広がっています。

一方、コミットメッセージに絵文字を付ける文化も、広まりつつあります。

両者を組合せれば、最強のプレフィックスが出来上がるのではないかと考えました。
ということで、絵文字付きプレフィックスという考え方を提案し、ここに記すこととします。

コミットメッセージにおける絵文字の付け方

コミットメッセージに、絵文字名を : で挟むことにより、GitHub上で表示できます。
また、コンソール上では、 emoji-cli などを利用することで、表示が可能です。

コマンドラインで emoji を扱う - Qiita

例えば、 ✨ (sparkles) という記号をコミットメッセージに書きたい場合、コミットメッセージを次のように記述します。

:sparkles: feat(ruby): やさしい日本語ページのルビタグ対応

すると、GitHub上のコミットメッセージとして登録されます。

covid19-miyazaki/covid19: 宮崎県(非公式) 新型コロナウイルス感染症対策サイト / Miyazaki COVID-19 Task Force website

コミットメッセージの1行目は、表示できる文字数に制限があるため、長すぎる絵文字名の絵文字は気をつけたほうがいいかもしれません。

git commit 時に書くコミットメッセージ1行目の表示文字数上限を調べてみた - Qiita

各プレフィックスと絵文字の紐付け

大前提として、プレフィックスを使う場合は、リポジトリ内で統一する必要があります。
これは、プレフィックスを使ったとしても、意味がわからなければ伝わらないからです。
同様に、多くの種類の絵文字を使うことも否定的です。
これからの時代は、プロジェクト毎に、コーディングスタイルと共にコミットメッセージスタイルも定義する必要があると思います。

今回は、Angularスタイルのプレフィックスを参考にします。
~~理由は、それ以外のスタイルを知らないからです。~~

angular.js/DEVELOPERS.md at master · angular/angular.js

また、絵文字については、Gitmojiを参考にします。
~~理由は、サイトが綺麗だからです。~~

gitmoji | An emoji guide for your commit messages

オリジナル絵文字を利用する場合は、GitHubで使える絵文字チートシートを参考にします。

🎁 Emoji cheat sheet for GitHub, Basecamp, Slack & more

以降、各プレフィックスの内容を説明し、それに見合った絵文字を紹介します。

feat

feat: A new feature

新機能を追加する際に利用します。

Gitmojiでは、同等の絵文字として ✨ (sparkles) を定義しています。
新機能を導入する際に使う絵文字です。

:sparkles: Introducing new features.

ということで、 feat には ✨ (sparkles) を利用します。

余談ですが、新機能というと、無かった機能を追加した際のみにも聞こえます。
僕の場合は、既存機能を変更する際や、既存機能を削除する際にも使っています。
変更／削除についても、変更することによって統一性が図れるとか、削除することによってUIが向上するとか、変更／削除そのものが機能追加という場合が多いなーと思っていたからです（いわゆる enhansement と同じ意味として捉えています。
これについては、プロジェクト毎に決めておくといいかもしれません。

fix

fix: A bug fix

不具合を修正する際に利用します。

Gitmojiでは、同等の絵文字として 🐛 (bug) を定義しています。
意味は全く同じです。

:bug: Fixing a bug.

ということで、 fix には 🐛 (bug) を利用します。

また余談ですが、個人的には、修正コミットに 🐛 を付けることは、若干抵抗があります。
GitHubでIssueファーストの開発をしていると、Issueでは不具合発見として 🐛 を付けて、修正プルリクとして 🐛 の絵文字を付けてしまいませんか？
🐛 という絵文字自体には2つの意味があるからです。

不具合発見時
不具合修正時

前者は 🐛 で問題ないのですが、後者については考える余地があるはずです。
もし虫網や虫籠の絵文字があれば、それを使っていたのですが......

コミット時に不具合を意図的に入れることは考えられない点と、不具合発見時をコミットメッセージで表すことが無い点、さらに不具合 == バグ == 🐛 を知らないエンジニアがほぼいない点を考慮して、 fix には 🐛 がいいかなと考えました。

docs

docs: Documentation only changes

ドキュメント類を修正する際に利用します。
修正と言っていますが、追加や削除時にも使ってよいと思います。

Gitmojiでは、同等の絵文字として 📝 (pencil) を定義しています。
ドキュメント類を記述する際に利用します。

:pencil: Writing docs.

また、 pencil と memo は、GitHubでは同じ絵文字として認識されます。

ちなみに、鉛筆だけの絵文字は pencil2 です。
~~これは酷い......~~

ということで、 pencil では文字ベースとして判断しづらい点から、 📝 (memo) を利用します。

style

style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

ソースコードの可読性を変更する際に利用します。
Lintを適用した際や、空行を追加した際など、振舞いに変化を与えない変更が該当します。

Gitmojiでは、 🎨 (art) が当てはまるかもしれません。
🎨 は、ファイル構造を変更する際、または、ソースコードのフォーマットを変更する際に利用します。

:art: Improving structure / format of the code.

style という観点で言えば、2番目の意味に該当することは間違いありません。
また、1番目の意味も、ファイル構造の style という側面で見れば、該当すると見ることもできます。

しかし、 art という単語からは、UIに関連しそうなイメージが付きます。
実際、下記のようなIssueも上がっています。

🎨 for design and 📐 for structure · Issue #320 · carloscuesta/gitmoji

style という内容に合わせるため、ここでは 📁 (file_folder) を利用します。

📁 File Folder Emoji

refactor

refactor: A code change that neither fixes a bug nor adds a feature

ソースコードの可読性を向上する際に利用します。

Gitmojiには、同等の絵文字として ♻️ (recycle) を定義しています。
意味はほとんど同じです。

:recycle: Refactoring code.

ということで、 refactor には ♻️ (recycle) を利用します。

perf

perf: A code change that improves performance

パフォーマンスを向上する際に利用します。

Gitmojiには、同等の絵文字として ⚡️ (zap) を定義しています。
意味は全く同じです。

:zap: Improving performance.

ということで、 perf には ⚡️ (zap) を利用します。

test

test: Adding missing or correcting existing tests

テストコードを追加する際や、既存テストコードを修正する際に利用します。

Gitmojiには、同等の絵文字として ✅ (white_check_mark) を定義しています。
意味は全く同じです。

:white_check_mark: Updating tests.

また、チェックマークの絵文字は、他にも ✔️ (heavy_check_mark) が存在します。

正直、どちらでもいいとは思います。
個人的には、Windowsでの開発が多かったため、 ✔️ を利用していました。
✔️ のチェックの色が緑色で、わかりやすかったためです。

しかし、他OSではチェックの色が黒色で、わかりづらくなっています。
一方、 ✅ は、殆どのメーカーが緑色矩形の白抜きチェックであり、わかりやすくなっています。

ということで、 test には ✅ (white_check_mark) を利用します。

chore

chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

自動生成ツールによりファイルを変更する際に利用します。
chore とは、雑務という意味があります。

choreの意味・使い方・読み方 | Weblio英和辞書

Gitmojiには、該当する絵文字はありません。
一部分で該当しそうな絵文字は、いくつか定義しています。

少し頭を悩ませましたが、英語圏のスラングである 'It's a piece of cake' から取って、 🍰 (cake) を利用します。

it's a piece of cakeの意味・使い方・読み方 | Weblio英和辞書

Angularスタイル以外

以下は、Angularスタイル以外のコミットメッセージで利用する絵文字です。
プレフィックスは付けても付けなくても構いません。

First commit

最初のコミットとしてよく使われる first commit ですが、Gitmojiでは 🎉 (tada) として定義しています。

:tada: Initial commit.

ということで、 first commit には 🎉 (tada) を利用します。
プレフィックスは init とします。

余談ですが、個人的には first commit を空メッセージにするのは懐疑的です。
必要無いから消したのか、書き忘れたのか、空メッセージでは判断できないためです。

Gitの最初のコミットは空コミットにしよう - Qiita

Merge commit

マージ実行時のコミットですが、Gitmojiでは 🔀 (twisted_rightwards_arrows) として定義しています。

:twisted_rightwards_arrows: Merging branches.

ということで、マージコミットには 🔀 (twisted_rightwards_arrows) を利用します。
長いですが、マージコミットの1行目はあまり重要であることは少ないため、問題なしとします。
プレフィックスは merge とします。

Review commit

レビュー指摘反映時のコミットですが、Gitmojiでは 👌 (ok_hand) として定義しています。

:ok_hand: Updating code due to code review changes.

ということで、レビュー指摘反映コミットには 👌 (ok_hand) を利用します。
~~あまり個人的には多用しないようにすべきとは思いますが......~~

WIP commit

作業中コミット (WIP: Work in Progress) ですが、Gitmojiでは 🚧 (construction) として定義しています。

:construction: Work in progress.

ということで、作業中コミットには 🚧 (construction) を利用します。
プレフィックスは wip とします。

おわりに

現在ではプライベートリポジトリでしか利用してませんが、個人的には可読性が上がっている気がします。
これを開発チームに展開して共有できれば、また違った世界が見えるかもしれません。

絵文字は、用法用量を守り、適切にご利用ください。

ちなみに

Gitmojiでは、本記事と似たようなIssueが立っていました。
もしかしたら、Gitmoji側で方針が決まるかもしれません。

Add a "semver" field for each emoji · Issue #429 · carloscuesta/gitmoji

こんなリポジトリもあります。
これを使えば、本記事の内容をPJで統一しやすくなりますね。

negokaz/git-fancy-message-prefix: A Git prepare-commit-msg hook for fancy commit message

Qrunchにおける自身のブログページからタグを消す方法

2020-10-04T23:24:24+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Qrunchにおける自身のブログページからタグを消す方法 - 雑木林

TL; DR

次の2つを実施すれば良いです。

「よく使うタグ」モジュールの除去
記事下のタグ表示エリアの除去

はじめに

以前、Qrunchにおけるタグとカテゴリの使い分けについての記事を書きました。
その際、「タグはQrunchサービス全体の分類子として、カテゴリは自身のブログ内の分類子として、それぞれ使い分けができそう」と書きました。

Qrunchのタグとカテゴリの使い分けベストプラクティス

しかし、Qrunchのブログページにおけるデフォルトデザインには、何ヶ所かタグを表示しています。
そのため、タグをブログページでは使わないようにするための手法が、完全に使えるとは言えません。

本記事では、Qrunchのブログページからタグを消す方法を記します。

タグを消す方法

まず、デザイン修正方法を記します。

Qrunchでは、ブログページのデザインをカスタマイズできます。
ダッシュボードのサイドバーにおける、デザイン欄を選択してください。

すると、「デザインの設定」ページに飛びます。
この画面から、デザインを修正していきます。

Qrunchのブログページに存在するタグ表示エリアは、サイドモジュールとフッターの2箇所です。
それぞれについて、消す方法を記します。

サイドモジュールからタグを消す

サイドモジュールからタグを消す方法は、ワンクリックで可能です。

サイドバーにおける「サイドモジュール」欄の「よく使うタグ」項目を削除すれば良いです。

フッターからタグを消す

フッターのデザインは、カスタムCSSで消します。

サイドバーにおける「カスタムCSS」欄のテキストエリアに、 .content-module.tag-content-module.entry-content-module クラスを非表示にするCSSを入力します。

.content-module.tag-content-module.entry-content-module {
    display: none;
}

おわりに

これで、Qrunchのブログはカテゴリでしか分類できなくなりました！
タグをカテゴリをうまく使い分け、よいQrunchライフを送ってください。

Sublime Text起動中に「LocalBridge.exe - 正しくないイメージ」というエラーが発生する場合の対処法

2020-10-04T23:22:43+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Sublime Text起動中に「LocalBridge.exe - 正しくないイメージ」というエラーが発生する場合の対処法 - 雑木林

TL; DR

Officeというアプリを消しましょう。
うまくいく場合があります。

Skypeが入っている場合も、消せる場合は消しましょう。

はじめに

Sublime Textを起動中、突如謎のエラーダイアログが出てくる場合があります。

LocalBridge.exe - 正しくないエラー

X:¥Users¥USER_NAME¥AppData¥Roaming¥Sublime Text 3¥Packages¥IMESupport¥imesupport_hook_x64.dll は Windows 上では実行できないか、エラーを含んでいます。
元のインストール メディアを使用して再インストールするか、システム管理者またはソフトウェアの製造元に問い合わせてください。
エラー状態 0xc000012f。

このエラーダイアログ、Sublime Text起動直後は特に発生しませんが、数分起動し続けていると出てきます。
しかも、Sublime Textが起動中は、エラーダイアログを消しても消しても邪魔してきます。
Sublime Textを消した後、数回エラーダイアログを消し続けることで、ようやく消えます。

これを完全に消す方法を探ります。

原因

どうやら、 IME Support プラグインが原因のようです。

https://github.com/chikatoike/IMESupport/issues/27

IME Supportプラグインでは、 imesupport_hook_x64.dll というライブラリを利用しています。
このライブラリの実態を、実はOfficeアプリ（後述）でも利用してしまっており、OfficeアプリとSublime Textの両方で同じライブラリを掴もうとする際に、エラーダイアログが出現してしまいます。

1-1/3+1/5-1/7+1/9-・・・:Sublime Text3の設定メモ - livedoor Blog（ブログ）

解決方法（暫定）

Officeアプリをアンインストールすることで、解決できます。

Officeアプリというのは、いわゆるWordやExcelといったMicrosoft Officeの1アプリではなく、特に必要ない「新しい Office を始めよう」または「My Office」というような名前の、Office製品自体を管理するアプリのようです。

このアプリをアンインストールしても、他のExcelやWordといったMicrosoft Officeのアプリは消えないので、問題ありません。

おわりに

Sublime Textを使う人は、ほとんどがIMESupportを入れていると思うのですが、ほとんどエラー対処法が見つからなくて困りました。
これで、少しでもエラーダイアログのイライラが解消できたら幸いです。

実は

また表示されました。
今度は SmartAudio3.exe になってます。

Officeアプリ消したけど、他にも掴んでいるんでしょうか？
続報を待て！

Qrunchのタグとカテゴリの使い分けベストプラクティス

2020-10-04T23:21:48+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Qrunchのタグとカテゴリの使い分けベストプラクティス - 雑木林

TL; DR

タグはたくさん書こう。
カテゴリは少なく書こう。

はじめに

Qrunchで記事を書くときに、真っ先に出てくるタグをカテゴリ。

この2つの違いを正確に理解している人は、果たしてどれだけいるんでしょうか？
僕はわかりません！

ということで、Qrunchのタグとカテゴリの挙動から、どのように使い分けたらいいのか、そのベストプラクティスを探ります。

挙動調査

下記のような記事を作成し、タグとカテゴリの挙動を調べます。

事前知識

タグとカテゴリを知る前に、どうしても理解しておく必要があるものがあります。
それは、「Qrunch.net」と「Qrunchブログ」です（この2つの名称は、本記事独自のものです）。

「Qrunch.net」とは、いわゆるこの画面です。

Qrunchの記事として書かれた様々な項目が、一覧として表示されています。

一方、「Qrunchブログ」というのは、上記画面の記事を書いている各ユーザーが主体のブログのことです。
これは、各ユーザーごとにフォーマットが異なります。

Qrunchというサービスは、この「Qrunch.net」と「Qrunchブログ」の2つを併せ持つサービスのことです。
ということを前提に、話を進めていきます。

また、「Qrunchブログ」のフォーマットは、Editorialを利用しています。

カテゴリ

記事にカテゴリを付けると、「Qrunchブログ」における記事上部にカテゴリとして表示されます。

また、「Qrunchブログ」の側面に、既存の記事全てのカテゴリを「カテゴリ」という項目として一覧表示しています。

しかし、「Qrunch.net」の記事の方には、何も表示されません。
「Qrunch.net」を色々見てみましたが、それらしい項目は見つかりませんでした。

「Qrunchブログ」のカテゴリをクリックすると、同じカテゴリを付けている自身の記事が一覧表示できます。

つまりカテゴリとは、「Qrunchブログ」にのみ表示される分類子ということです。

挙動調査まとめ

タグは「Qrunch.net」と「Qrunchブログ」の両方に影響を与えるのに対して、カテゴリは「Qrunchブログ」にのみ影響を与えるみたいです。

また、タグもカテゴリも分類子であり、タグは「Qrunch.net」における他ユーザーの記事も表示できるのに対し、カテゴリは「Qrunchブログ」の自身の記事のみ表示できるようです。

ベストプラクティス

次のような使い方を提案します。

タグの使い方

記事におけるタグは、その記事に関連していそうなキーワードをできるだけ書いておきましょう。

これにより、次のような効果が期待できます。

「Qrunch.net」からのユーザー流入の向上
- 他ユーザーの記事のタグと同じタグを指定できれば、関連記事としてユーザー流入を見込めます。
「Qrunch.net」における他記事タグとの表記揺れの解消
- 大文字小文字を区別する仕様があったり、英語表記カタカナ表記といった表記揺れを解消することで、同じタグの指定率の向上が見込めます。

しかし、次のようなデメリットも存在します。

「Qrunchブログ」の関連記事が見つかりづらい
- 自身の「Qrunchブログ」で関連記事を見つけたい場合、どのタグで検索すれば良いかわかりづらい
タグの管理が大変になりやすい
- 全ての表記揺れに対応する場合、タグの表記揺れ対応項目を全て記録しなければ、タグから関連記事への遷移が困難になってしまいます。

上記デメリットを解消するのが、カテゴリの利用です。

カテゴリの利用

記事におけるカテゴリは、自身の「Qurnchブログ」における分類子として、自身が管理できる量だけ記載しましょう。

これにより、次のような効果が期待できます。

タグ乱立による「Qrunchブログ」関連記事検索性低下の防止
- 自身の「Qrunchブログ」内では、タグ検索ではなくカテゴリ検索を使うことで、「Qrunchブログ」内の関連記事の検索性を維持できます。
タグ乱立によるタグ管理性低下の防止
- 自身の「Qrunchブログ」内では、カテゴリ検索による関連記事への遷移を主軸とするため、タグ管理をする必要がなくなります。
- カテゴリ管理はする必要がありますが、カテゴリの量は少なく（管理できる量だけ記載）するため、管理の負担は少なくなります。
独自の分類子による「Qrunchブログ」内の検索性向上
- 自身の「Qrunchブログ」でしか通用しない独自の分類子を、カテゴリとして指定することにより、「Qrunch.net」のタグとは無関係そうな分類子を独自に定義できます。
- シリーズ物などに独自カテゴリを指定することで、「Qrunchブログ」の検索性の向上が見込めます。

カテゴリが「Qrunch.net」に影響を与えないことを逆手にとった活用法が考案できます。

おわりに

Qrunchにおけるタグとカテゴリは、影響範囲が異なります。
つまり、タグはQrunchサービス全体の分類子として、カテゴリは自身のブログ内の分類子として、それぞれ使い分けができそうです。

もちろん、タグの濫用は御法度ですよ。
他ユーザーの迷惑にならない程度に、全く無関係のタグは付けないようにしましょうね。

用法用量を守って、良いQrunch生活を送りましょう！

PowerPointのスライドサイズ制限対策あれこれ

2020-10-04T23:19:34+09:00

本記事は、 Qrunch からの移転記事です。

移転元: PowerPointのスライドサイズ制限対策あれこれ - 雑木林

TL; DR

下記に、3原則を記します。

デザインは大きく変わる覚悟をすべし
たくさんの手段の中から1つづつ試しすべし
地道な努力がサイズ削減の達成を約束するだろう

ユーザーの声も募集しています。

某社員
私は40MBのパワポを2MBまで削減できました！

はじめに

社内の規定などで、PowerPointのスライド（以降、パワポと呼ぶ）サイズ制限をかけているような場合、せっかく綺麗に作ったパワポが提出できない、なんてことがあったりします。
それでなくても、常日頃から容量も125GBしかないようなちんけなPCを使っている場合 ~~（えらく具体的ですね）~~ 、データサイズとの戦いは日常茶飯事です。

最初からサイズ容量を超えないように作ることも大事ですが、保存するごとにサイズが大きくなっていく様を見続けてパワポ作成を続けるのは、精神衛生的によろしくありません。

最初はサイズを無視して作成しつつ、後でサイズを下げる方法は、一見遠回りをしているようでいて、実はサイズと戦う時間を一括にまとめるという、きわめて効率的／合理的な手法だと考えます [要検証] 。

本記事では、どのような削減方法があるのか、何をすればよいのかを、1つづつ紹介していきます。
~~サイズ制限のために画像はありません。~~

事前準備

パワポサイズ肥大化の原因特定

パワポのファイル、いわゆる .ppt や .pptx ファイルが、zipファイルの拡張子違いであることは、意外と知られていません。

まずは、作成した .ppt または .pptx ファイルをコピーし、コピーしたパワポファイルの拡張子を .zip 拡張子に置換えてみましょう。
その後、コピーしたzipファイルを解凍すれば、中身が出現します。
これにより、どのファイルがサイズ肥大化の原因となっているかを判断できます。

主に画像ファイルが圧倒的にでかいため、そちらを見てみましょう。
解凍したディレクトリ内の ppt/media/ ディレクトリに入っていると思います。
明らかに大きな画像ファイルがあれば、そのファイルが本当に必要かどうかを考えておくのも大切です。

画像ファイルの種類や保存形式

PNGファイルは縦横の大きさを小さくしても、大きくする際に戻しやすい（可逆圧縮）性質があります。
一方、JPGファイルはその逆で、大きくしようとするとのっぺりとなりやすい（不可逆圧縮）性質があります。

可逆圧縮と不可逆圧縮のどちらが優れているかはTPOで異なりますが、データサイズの観点から見れば、不可逆圧縮形式のファイルのほうがデータサイズは小さいため、本記事の対象としては優位性が高いです。

他にも、たとえば画像ファイルの種類、ビットマップ形式であるJPGやPNGとベクター形式であるSVGの違いや、具体的な保存方法などを知っておくと、どうすれば画像ファイルのデータサイズが削減できるか、といったことが理解しやすくなります。

実践

事前準備ができたら、あとはパワポサイズを削減してみましょう。

PDFにする

意外と盲点ですが、 .ppt または .pptx 形式である必要がないなら、いっそのことPDFファイルにしましょう。
40MB程度のパワポが6MB程度まで減るので、もし可能であれば試してみてください。

欠点としては、それより下げる方法がない、ある意味では最終手段ということですが......

フォント埋込みを諦める

どんなにデータサイズが小さなパワポでも、フォント埋込みをした瞬間に6MBくらい増えてしまいます。
10MB程度なら許してもらえる環境であればよいですが、2MBレベルを求められる環境では無理です、諦めてください。

実際に発表で利用する場合は、フォント埋込みの代わりに画像として置換える、なんて技もあります。

もし、課題の提出用であれば、フォント埋込みをする必要もないかもしれません。
代わりにトップ画面にでかでかと「〇〇フォントを利用していますが、埋込めませんでした！」って書いておけば、デザインについてとやかく言われることは無いのではないでしょうか？

画像のアート効果で容量肥大化を防ぐ

PowerPointの機能として、「画像のアート効果」を選べるものがあります。
これは、普通の画像を簡単に「マーカー手書き風」にしてくれたり、「フィルム粒子風」にしてくれたりするため、意外と使える場面が多くて重宝できます。

しかし、中にはデータサイズ肥大化に貢献してしまうアート効果というものもあります。
例えば「フィルム粒子」効果では、画像をドットレベルでザラザラにするため、非常にデータサイズが大きくなります。
このような、データサイズを大きくしやすいアート効果はなるべく使わないようにしたいです。

画像の必要性を考える

本当にその画像が必要か、考えることも大切です。

セクションごとにスライドを挿入している場合、そこに表示する画像は本当に必要か？図形で代用できないか？などを考えてみましょう。
意外と不必要な画像を使っていることは多いです。

複雑な図形は1枚の画像に置換える

1スライドに何枚も画像を入れている場合、それらすべてを1枚の画像として貼り付けることで、データサイズを削減できることがあります。
特に、1スライドだけにしか使ってないような画像がたくさんある場合に重宝する手法です。

画像を圧縮する

スライドで利用している画像ファイルサイズを、直接圧縮できる機能があります。

下記の参考ページなどで紹介されていますが、「パワポ画像圧縮」で調べてもたくさん出てきます。
脳死で「電子メール用」レベルまで圧縮しましょう。

「PowerPoint」で作成した重い資料の容量（サイズ）を下げる方法 | @niftyIT小ネタ帳
https://koneta.nifty.com/koneta_detail/180928000645_1.htm

スライド自体を画像にする

下記のような参考ページでも書いてありますが、フォント埋込みを諦めた時点で、デザインの崩壊は防げません。
しかし、1枚のスライドを丸々画像にすることで、デザインを維持しつつデータサイズを削減できることがあります。

フォントの埋め込みだけじゃない！ – 環境に依存しないプレゼン資料の作り方 3種 | The Power of PowerPoint
https://thepopp.com/フォントの埋め込みだけじゃない-フォントイン/

注意点ですが、全スライドを画像にすると、逆にデータサイズが大きくなることもあります。
各スライドごとに変更してみて、データサイズ遷移を見守ってください。

おわりに

テラバイトが当たり前の時代になっても、いまだにサイズ制限をかけているのは時代錯誤も甚だしいですね。
とはいえ、1個人が現状を大きく変えることは難しいです。
できることをやりつつ、もし偉くなったら「サイズ制限なんて無くそう」と言ってください。

vimrcファイル（環境設定ファイル全般）はGitHubで管理するといいのではないか

2020-10-04T23:17:10+09:00

本記事は、 Qrunch からの移転記事です。

移転元: vimrcファイル（環境設定ファイル全般）はGitHubで管理するといいのではないか - 雑木林

はじめに

皆さんは、出先にvimrcファイルがあれば良かったのに、という経験はありませんか？

偶然にも、私はそんなことが何度かありました。

例1：インターンシップ

それは、とあるインターンシップでのことです。

回想はじめ

偉い人「AWSサーバ1つあげるから、これで何か作ってください」
私「よっしゃいじり倒したろ、さてapacheの設定ファイルは......」
私「Vimの設定がデフォルトで全然使えん！！！」

回想おわり

さて、私はこの時、偶然にもGitHubにvimrcファイルを置いていたため、クローンしました。
するとどうでしょう、行番号も碌に表示していなかったVimに、命が吹き込まれたのです。

私は、このインターンシップを大成功で収めることができました。

例2：新しい業務用パソコン

それは、新しい業務用パソコンがたくさん届いた時のことです。

回想はじめ

私「さて、環境構築するか」
新パソコンA「Vim無いよ」
新パソコンB「Vim無いよ」
新パソコンC「Vim無いよ」
私「......これ全部同じことしないとならんの？」

回想おわり

さて、私はこの時、偶然にも（以下略）

私は、たくさんの新しい業務用パソコンにいち早くVim環境を整えることができました。

例3：vimrc編集後

それは、突発的にvimrcファイルを書換えた時のことです。

回想はじめ

私「ふへへ、ついに最強のvimrcを書いてやったぜ」
私「さて、これを私が利用している別のパソコンにも入れなきゃ」
私「えーっと、家のデスクトップ、家のノート、新パソコンA、新パソコンB、新パソコンC......」
私「......今日はそろそろ帰ろう」

回想おわり

さて、私はこの時、偶然にもGitHubでvimrcファイルを管理していたため、新しいvimrcをpushしました。
別のパソコンを使う際にpullすればいいだけですから、その日は何も考えずに帰りました。

数日後、別のパソコンを利用時にvimrcをpullするとどうでしょう、Vimが生まれ変わったのです。

私は、常に最新のvimrcをどこでも利用できるのです。

おわりに

vimrcは便利ですが、慣れてしまうとデフォルトのVimが苦痛になってしまいます。
いち早く自分の環境に（PCを）適応させるため、GitHubで環境ファイルを管理するのは1つの手だと思います。

上記を活用して、快適環境の生活を過ごしませんか。

追記

GitHubで管理する前は、USBにvimrcを入れて生活していました。
書換えた時に面倒なことになるのは、お察しの通りです。

dxdiagを使って爆速で自分のPC性能を知る

2020-07-15T20:30:17+09:00

はじめに

自分のPC性能を調べたりする必要が稀にある
メモリの搭載量や、CPU・GPUの情報って基本的に別々の場所に掲載されてるので、調べるのってめんどくさい
そんなときはdxdiagを使うと早いよ！という記事

dxdiagとは

以下マイクロソフトサポートページより引用
(https://support.microsoft.com/ja-jp/help/4028644/windows-open-and-run-dxdiagexe)

このツールを使って、DirectX のサウンドとビデオに関する問題のトラブルシューティングに役立つ、デバイスの情報を収集します。このような情報は、サポート担当者から要求されることがあるほか、ヘルプが必要な場合にフォーラムに投稿することもできます。

一言でまとめると、dxdiagはPCの性能を収集してくれる便利ツール。

dxdiag開く

検索バーにdxdiagと入力。一番上に出てくるdxdiagをクリックして開く。

dxdiagの使い方

システムタブ

CPU、メモリ、OSのバージョン等がこのタブで見れる。基本的な情報はこのタブだけでOK

OSのエディションもここで確認できる。

ディスプレイタブ

GPUはこのタブで確認可能。オンボードのグラフィック性能も見れる。

サウンドタブ

名前の通り、搭載しているサウンドデバイスの性能を確認できる。

PC性能を出力

画面下部にある情報をすべて保存を押すと、PCのCPUからサウンドデバイスまで、すべての情報をテキスト形式で出力してくれる。

PCの情報を受け渡すときに使うと便利かも

最後に

dxdiagは便利なのに、あんまり知られてなくて勿体ないなーと思っていたので。
より良いPCライフを送る手助けになったら幸いです。

UnrealEngine4のNiagaraで作ったパーティクルにコリジョンを持たせる

2020-07-13T09:21:27+09:00

はじめに

・環境はUE4.25
・ものすごく短い記事です。
・言いたいことは後半。
・~~CollisionQueryなんてモジュールは現存しない~~

なぜ地面に残したい？

・元々雪のようなパーティクルを作ってた。
・雪が地面に当たって溶ける表現を作りたかった。

How 2 残し方

・エミッターのパーティクル更新にCollisionを追加。

・Collision内のBounceにあるRestitutionの値を-1.0に設定する。

0だとわずかにバウンドしてしまう。ピタリと止めるには-1.0ぐらいが適切みたい。

設定すると↓のように地面に張り付くような形で止まる。

CollisionQueryは古い

ここまでの処理を作ろうと色々調べたら、CollisionQueryというモジュールが出てきた。実はこれUE4.23までのNiagaraで使っていたモジュール。UE4.25では存在しない。

検索してもこの通りヒットしない。

~~CollisionQueryが見つからないと小一時間悩んだ~~

ということで、UE4.25のNiagaraでパーティクルのコリジョン関連の設定が必要なときはCollisionモジュールを使おう！

まとめ

エンジンのバージョンが上がると、存在してたモジュールが無くなったり、名前が変わることがあるので自分が使っているバージョンの情報を調べることって大切だなって思った。

同じことで他の人が苦労しないことを願ってる・・・。

WindowsからmacOSに乗り換えてとまどった話 vol.5 〜Safariに右のタブを閉じる機能がない〜

2020-02-25T18:18:54+09:00

みゃほわーん！(⋈◍＞◡＜◍)。✧♡

というわけでひげちゃんです。

世間はコロナウイルスで阿鼻叫喚な状態ですが、生存確認のためにも変わらずやってきたいと思います＾q＾

今回は久々に通常路線に戻り、WindowsからmacOSに乗り換えてとまどった話シリーズです。

今回の戸惑ったお話

僕はWindowsでずっとメインブラウザとしてBraveを使ってたので、Macを使いだしてからも当然のようにBrave使ってたんですが、段々重くなってきてバッテリの消費も激しくなってきたので、純正ブラウザのが色々最適化されててよいのかもと思いちょっと前にSafariに乗り換えたんです。
そしたらまたもや戸惑いました。何故か右のタブを閉じる機能がない

なんで"Close Tabs To The Right"がないの

最初まじで理解できなかったんですけど、Safariには右のタブを閉じる機能、いわゆる"Close Tabs To The Right"がないんですよね（唖然）。
こんなクソ不便なことってありますか？？？？？

そこでひげちゃん閃きました。

ないなら作ろう(脳死)

今回のソリューション

最初アドオンとかないかなーとも思ったんですが、なんかSafariアドオン一個入れる度に変な動きしたりするので極力バニラな状態の方がいいよな〜と思い、今回はAppleScriptで解決しました。

tell window 1 of application "Safari"
    close (tabs where index > (get index of current tab))
end tell

色々調べて試行錯誤したんですが、たった3行ですみました。簡単！
あとはコレをAutomatorで設定して、Servicesからショートカットキーで呼び出すようにすれば完成です。

おわりに

~~今回AppleScript初めて触ったんですけど~~、(前にもvol2で触ってました笑)なんか擬似コードみがあって好きだなぁってなりました（語彙）

KUSANAGI で環境ごとにページキャッシュを生成する

2019-04-14T15:37:04+09:00

はじめに

KUSANAGI にはページキャッシュ機能があるが、通常環境ごとにキャッシュが分かれず、PCやスマホで表示が異なる場合問題が生じる。

方法

KUSANAGI 設定画面デバイス切替ページにアクセス

https://hogehoge.com/wp-admin/admin.php?page=kusanagi-core/core.php&tab=theme-switcher

ホスト等は各自の環境に置き換えて下さい。

「デバイスによるテーマ切り替えを停止」のチェックマークを外し、[変更を保存] をクリック

解説

方法はとてもシンプルでした。テーマ切替を行っていない場合でも有効。

WordPress プラグイン「Contact Form 7」の reCAPTCHA (v3) ラベルを必要なページのみ表示させる

2018-12-17T13:28:01+09:00

はじめに

世界で最も使われている WordPress プラグイン「Contact Form 7」にて、後方互換性の無いオプション機能のアップデートが行われました。

具体的には本プラグインが reCAPTCHA (v3) に対応し、同時に旧版である reCAPTCHA (v2) への対応が廃止となりました。

v2 を用いている場合はアップデートと同時に無効となります。
引き続き reCAPTCHA を用いる場合は v3 への対応が必要で、新たに v3 用のサイトキー、APIキーの設定が必要です。

こちらの作業は管理画面上の操作で済むので、大した問題とは捉えていなかったですが、この設定を行うとあらゆるページ上で以下のラベルが表示されます。

これは非常にうざいので、以下のコードで必要なページに対してのみラベルを表示させるようにしました。

コード

以下のコードをテーマの functions.php 等に記載します。
'your_pagename' は適宜お使いのページスラッグ置き換えて下さい。

    add_action('send_headers', 'remove_recapcha');
    function remove_recapcha($wp)
    {
        if (array_key_exists('pagename', $wp->query_vars) && $wp->query_vars['pagename'] === 'your_pagename') {
            return;
        }
        remove_action('wp_footer', 'wpcf7_recaptcha_onload_script', 40, 0);
        remove_action('wp_enqueue_scripts', 'wpcf7_recaptcha_enqueue_scripts', 10, 0);
    }

実例

お問い合わせ – にじさんじ配信スケジュール