nDiki : macOS

macOS

2018年9月25日 (火)

今日のさえずり: せっかく iPhone X (テン)と言えるようになったのに iPhone XS で台無し(エックスエスって言っちゃう)

2018年09月25日

[ permalink ]
[ 9月25日全て ]

2018年10月4日 (木)

Alfred 3 for Mac の表示量を増やす

Alfred を使っていて

  • search text の文字数が少なくて長めのテキストを入力する時に全体が見えない
  • result text の文字数が少なくて似たような長いファイル名が複数あると区別できない

と不便に感じるようになったのでサイズを変更してみた。

Alfred Preferences の Appearance で Alfred macOS Theme を複製し、

  • Window Width: 559px を 1024px に
  • Search Text Size: 34px から 24px に
  • Result Text Size: 18px から 16px に

に変更。これで一度にだいぶ見渡せるようになった。参照したい表示の上に Alfred がかぶった時のために透明度を上げた方が良いかなと思っていたけれど blur がかかっていてどのみち読めなさそうだったのでここは変更せず。

[ permalink ]
[ 10月4日全て ]

2018年10月13日 (土)

Ulysses で TextBundle を使うのどうなのか調べてみた

Markdown 形式ファイルと、そこから参照されている画像ファイルを1つにまとめて管理する形式として TextBundle がある。ライティングアプリ Ulysses が対応しているのでちょっといじってみた。

TextBundle は package format と compressed format がある。 package format は macOS のパッケージの形になっていて、 textbundle という拡張子をつけたディレクトリの中に info.json と text.* (Markdown なら text.md)、それからテキストファイルから参照しているファイルを asserts/ サブディレクトリに置くという仕様である。macOS の Finder からは1つのファイルのように表示される。

TextBundle を使うメリット

メリットは以下。

  • テキストファイルと参照されている画像ファイルを一緒に管理できる(ばらけないで移動したりできる)。
  • TextBundle に対応していないテキストエディタでも text.md を簡単に開いて編集できる。

TextBundle を使うデメリット

非対応アプリケーションから使う場合にデメリットを感じる。

  • 非対応アプリからみると TextBundle 毎にディレクトリがあることになるので、ディレクトリだらけな感じになる。ドキュメント毎にディレクトリを開いて中のテキストファイルにアクセスする必要がある。
  • Markdown ファイル名が text.md 固定なので、ファイル名だけでは区別できなくなる。

Ulysses for Mac の場合

Ulysses は TextBundle に対応しているので通常の Markdown ファイルと同様1つのシートとして自然に扱える。

普段 Ulysses for Mac では Dropbox の中のディレクトリを外部フォルダとして指定して使っているので以下、外部フォルダの時の話し。

Ulysses の外部フォルダ上の Markdown ファイルに貼った画像をエディタ上でプレビューできるのは現状 TextBundle だけ。エクスポート時も TextBundle 内の画像ファイルは書き出されれるけれど、(相対パス・絶対パス問わず)ファイル名で参照しているものは書き出されない(http/https な URL で指定した画像は HTML でエクスポートする際は画像が貼られる形になるが PDF ではだめ)。Ulysses だけを使って画像を扱いたいなら TextBundle を使う以外選択がない感じだ。

Ulysses 上で TextBundle なシートを保存するたびに参照されている画像ファイルを残して他は assets/ から消されてしまう。なので assets/ の下に画像作成に使ったソース・ファイル(マインドマップファイル)を一緒に置いておくおような管理はできない。そもそもテキスト編集で間違えて画像参照を消して保存実行してしまうと、画像ファイルだって消えてしまうので、画像ファイルだってオリジナルを別で保存しておく必要がある。

TextBundle は使うのは控えた方が良さそうだ。

[ permalink ]
[ 10月13日全て ]

2018年11月1日 (木)

今日のさえずり: タイムテーブルがピチピチ

2018年11月01日

[ permalink ]
[ 11月1日全て ]

2019年3月1日 (金)

一気に MacBook Pro リプレース作業をやり切った

MacBook Pro (Retina, 15-inch, Mid 2014) から MacBook Pro (13-inch, 2018, Four Thunderbolt 3 Ports) にリプレース。

今はデータをほぼ Google ドライブや Dropbox に置いているので、やるのは macOS の設定と Mac アプリケーションのインストール & 設定がほとんど。今は自分でビルドしていれているものもほとんど無いので楽だ。

Mac アプリケーションは先に入れた方が捗るもの (Google Chrome・Google 日本語入力・Dropbox・Google ドライブや Karabiner-Eements・Alfred など)があるので、入れたい順序のグラフを Graphviz で書きながら進めていった。

プリンタと Chrome 拡張機能の個別設定以外は概ね移行完了。数日に分けてやる感じかなと思っていたけれど、夕方に仕事の気分切り替え的に始めたら一気にやってしまった。

あ Emacs まだ入れてないなー。

メモ: rumember のインストール

 $ cd ~/local
 $ git clone https://github.com/tpope/rumember.git
 $ GEM_HOME=$HOME/local/rumember gem install launchy

~/.rtm.yml は前のものをコピー。

[ permalink ]
[ 3月1日全て ]

2019年4月9日 (火)

PC でのワンタイムパスワードのシークレットキー管理に KeePassXC を使う

TOTP アルゴリズムを使っている2段階認証/2要素認証のシークレットキーの管理・ワンタイムパスワード生成はスマートフォンアプリの Google Authenticator とIIJ SmartKey を両用している。メインのスマートフォンが使えなくなった時のために、使っていない古いスマートフォン残しておいてそこにもシークレットキーを登録しているのだけれどこれ面倒。バックアップは PC (Mac)で管理したい。

そう思って調べたところ、普段パスワード管理に使っている KeePassX のフォーク版 KeePassXC が TOTP 生成機能をもっているということを知った。

KeePassX の開発保守が停滞していることもあり KeePassXC にこのタイミングで乗り換えつつ KeePassXC で 2段階認証/2要素認証のシークレットキーの管理をしてみることにした。

クロスプラットフォームで公式サイトでは Linux 用・macOS 用・Windows 用のパッケージが配布されている。

シークレットキーの登録

IIJ SmartKey に登録しているキーについてそれぞれ QRコード生成をし別のカメラで読み取り、その中の secret の値を KeePassXC のエントリに登録していく。エントリを作成し(あるいは既存のエントリを選択し) TOTP の設定でキーを入力し保存すれば OK。

ワンタイムパスワードの生成

もちろんワンタイムパスワードの生成にも対応している。これがあればスマートフォンが手元に無くても要 TOTP 認証のネットサービスにログインできる。便利。

パスワードデータベースファイルの管理

KeePass パスワードデータベースファイル (kdbx) に保存されるので、あとは好きな方法でバックアップ。

[ Mac アプリケーション ]

[ permalink ]
[ 4月9日全て ]

2019年5月8日 (水)

macOS Mojave で暗号化されたディスクイメージを作成する

過去、Windows で TrueCrypt や VHD + BitLocker を使って暗号化ボリュームを作っていたけれど、 macOS では一度も作ったことがなかった。標準で入っているディスクユーティリティでできるので作成してみた。

[ファイル] - [新規イメージ] - [空のイメージを作成] で以下の設定でイメージを作成しマウント。 

 名前: Naney.sparsebundle
 場所: ~/var/image
 名前: Naney
 サイズ: 64GB
 フォーマット: APFS
 暗号化: 128bitAES暗号化
 単一パーティション - GUIDパーティションマップ
 イメージフォーマット: スパースバンドル・ディスクイメージ

簡単。

[ permalink ]
[ 5月8日全て ]

2019年6月19日 (水)

mermaid の CLI を macOS 上で使えるようにする

6月上旬に使い始めた Markdown エディタ Typora で mermaid を使いダイアグラムを作成してみたらなかなか良かったので、 mermaid のデータから画像を単独で生成できるよう CLI を入れた。

インストールは以下。 

 $ brew install yarn
 $ yarn add mermaid.cli

実行は以下のような感じ。 

 ~/node_modules/.bin/mmdc -b transparent -w 1920 -i input.mmd -o output.png
[ permalink ]
[ 6月19日全て ]

2019年10月3日 (木)

macOS Mojave にアップグレード

macOS Catalina がもうすぐ出そうなのでまず macOS Mojave にアップグレードした。去年の8月に macOS High Sierra にして以来のアップグレード。

先送りしていた理由の1つだった「ScanSnap Manager を ScanSnap Home にする」も一緒にやっておいた。

[ permalink ]

今日のさえずり: 今月の「ムー」、創刊40周年記念特大号なんだ。ずっと続いて欲しい。

2019年10月03日

[ permalink ]
[ 10月3日全て ]

2019年10月17日 (木)

VS Code で PlantUML

Qiita:Team で PlantUML を使ってダイアグラムを書くのにまず手元で編集したいと思い、 Visual Studio Code (VS Code) に PlantUML 拡張を入れた。 

 ext install plantuml

で拡張をインストール。

Mac (macOS) では Graphviz (それに必要な Java ランタイム)も入れておく。 

 brew cask install java
 brew install graphviz

これで Alt-D で PlantUML プレビューができるようになる。

関連

[ permalink ]
[ 10月17日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.097486s / load averages: 0.27, 0.37, 0.31
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker