2017年2月27日月曜日

Electron のインストールに失敗する(解決)

ちょっとしたことをしようとして、GUI アプリを作りたいと思いました。
手軽に作れるものは無いかと思った時に Electron があることを思い出しました。

Electron
http://electron.atom.io/

JavaScript というか Web 系の技術を使って GUI のアプリが作れるならと早速インストールしようとしたのですが、エラーが発生してしまいました。

$ npm -g install electorn-prebuilt
npm WARN npm npm does not support Node.js v0.12.2
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm You can find the latest version at https://nodejs.org/
npm ERR! Darwin 16.4.0
npm ERR! argv "node" "/usr/local/bin/npm" "-g" "install" "electorn-prebuilt"
npm ERR! node v0.12.2
npm ERR! npm  v4.1.2

npm ERR! Cannot read property 'path' of null
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/xxx/npm-debug.log

ぱっとエラーの内容を見る限り・・・よくわからん。
すぐに分かる人は、本当にしょうもない事しているなと思いますが、それは最後に取っておいて、分からないなりに取った行動を載せていきます。

1. node の再インストール

まず、単純に node がおかしいと決めつけて、node の再インストールを試みました。

$ brew uninstall node
$ brew update
$ brew install node
$ npm -g install electorn-prebuilt

結果、変わりませんでした。

2. npm のデフォルトディレクトリの権限を変更

よくわからないなりにエラー内容で調べた所、npm のデフォルトディレクトリの権限がおかしくなっているのではないか?との記事を見かけたので、これまた見よう見まねで変更処理を行いました。

$ npm config get prefix
...
/usr/local
$ sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}
...
$ npm -g install electorn-prebuilt

結果、変化なし。

3. node 自体を怪しむ

この辺から心が折れかけましたが、再度 node に目を向けました。
インストール実行後に WARN と出ていることから、node のインストールが上手く行っていないと思ったので、再度アンインストールしてから node のバージョン確認をすると、アンインストールしたはずなのにバージョンが表示されました。
多分、昔にパッケージを使って node を入れた気がしたので、それが悪さをしている物と思いました。
ちなみにここで、勝利を確信して、完全なアンインストールを行ってみました。

# 削除するパッケージの名前(org.nodejs.node.pkg.bom)は、本当にあるか確認すること
$ lsbom -f -l -s -pf /var/db/receipts/org.nodejs.node.pkg.bom \
| while read i; do
  sudo rm /usr/local/${i}
done
sudo rm -rf /usr/local/lib/node \
     /usr/local/lib/node_modules \
     /var/db/receipts/org.nodejs.*

# npm を削除
$ sudo rm -rf ~/.npm

$ brew install node
$ npm -g install electorn-prebuilt

が、しかし、node のバージョンは上がったにも関わらず、結果変わらずです(WARN がでなくなりました)。

$ npm -g install electorn-prebuilt
npm ERR! Darwin 16.4.0
npm ERR! argv "/usr/local/Cellar/node/7.6.0/bin/node" "/usr/local/bin/npm" "-g" "install" "electorn-prebuilt"
npm ERR! node v7.6.0
npm ERR! npm  v4.1.2

npm ERR! Cannot read property 'path' of null
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/xxx/npm-debug.log

4. インストール完了と恥ずかしさ

さて、ここまで来ると、もう手に負えないと感じ始めました。
なんなら、なんで Electron なんて使ってみようと考えたのか?という部分にまで至りました。

とは言え、諦めるのもかっこ悪いので、再度インストールコマンドをコピペして調べてみると。。。
Google から思いの寄らない返事が

。。。
Electron のつづりが間違っている。。。

そうです。インストールコマンドで指定している Electron のつづりを間違えていたのでした。

☓ electorn
◯ electron

ああっ!と少し自分でも自分に対して引いてしまいました。
その他、調べると現在は electron-prebuilt の -prebuilt なしでも良いとのこと。

$ npm -g install electron
/usr/local/bin/electron -> /usr/local/lib/node_modules/electron/cli.js

> electron@1.4.15 postinstall /usr/local/lib/node_modules/electron
> node install.js

/usr/local/lib
...
$ electron -v
v1.4.15

な、なんとか上手くインストール出来ました。
タイポはよくあるかと思いますが、インストールの際にはお気をつけを。
(この作業に 2 時間もかかってしまった。。。)

Written with StackEdit.

2017年2月26日日曜日

ほぼ日weeks2017とサンドウィッチ2016

手帳の季節になりました(若干おそいですが)。
昨年は、色々と手帳を試してみてみましたが、自分の使い方に有っているのがほぼ日 weeks だったので今年もリピートしてみました。

ほぼ日 weeks については、公式サイトを参照ください。
毎年改良が加えられているようですが、ぱっと見で気付いた点は、月刊カレンダーの祝日の表記が枠いっぱいになった点と、週間部分の左下の扱いでしょうか(これも公式見たほうがわかりやすいですね)。

ほぼ日(公式)
http://www.1101.com/store/techo/

今回購入したのは、カラーズのリネンと呼ばれるもの。
表紙が硬く、またリネンが貼られた物になります。
他にも、ビニールを採用した柔らかい物もあります。
weeks の良いところは、カバー無しでも使えるようになっている点ですね。

ただ、私は昨年 weeks 用のサンドイッチと呼ばれる B印YOSHIDA のカバーを買っているので、本当はどのモデルでも良かったりします。
ただ、年を重ねたときの補完の際に硬い表紙のほうが良く、落ち着いた色が良かったのでリネンにしました。

さて、手帳自体は、先ほどの通り公式サイトを見れば詳しく分かるので、ここではサンドウィッチカバーに入れた状態と、使ってみて思ったことを書きたいと思います。

サンドウィッチカバー

まずカバーの紹介です。
このカバーは、2016年版となっています。
2017年版にも同じ名前のカバーが用意されていますが仕様が変わっています。
なので、最新のものと違う部分がありますのでご了承を。

カバーを開くと以下のようになっています。
左右にページを差し込める様になっていて、左側には書類を挟めるようになっていて、右側にはカードが 2 枚収納する切り込みがあります。

また、左側にはジップがあり、開くとペン等の小物を収納することができます。
手元にあるペンが何本入るか確認してみた所、5 本程度であれば問題なく収納できます。

実際収納した感じが以下の通り。
若干パンパン気味です。物を入れての書き物の際には邪魔になるかもしれません。


全て詰めてジップを閉じた時

購入当初は、右側のみに表紙を入れた状態にすると閉じた時に左側のカバーが寸足らずになっていました。
ちょっとかっこ悪かったので、左右の表紙を入れ込んで使っていたのですが、今の状態を確認すると両方の表紙を入れずとも寸足らず問題が解決していました。
年経過で生地が伸びたのでしょうか?これはこれで良い誤算でした。

さて、実際にカバーをつけての使用感ですが、特に沢山のペンを一緒に持ちたいとか、書類やカードを持ちたいと思っていない限りはいらないかもしれません。
何故かと言うと先ほども書きましたが、通常状態でカバーがしっかりしていて十分実用に耐えるからです。
もし付けるとしてもビニールカバーでも十分なぐらいです。

ただ、ちょっと違った感じで手帳を持ちたいという方には、このカバーはとても良いものになるかと思います。

その他の小物について

買ってよかった小物としては、下敷きが思いの外良かったです。
紙自体がトモエリバーで薄くなっているので、筆圧をかけて書いた時に、後ろのページに書いた跡が残り書きにくなってしまいます。
跡がついているとボコボコしていますし、見た目も悪いのですが、この部分を下敷きによって軽減することが出来ました。
左右の 2 枚は不要ですが、1 枚は持っていたほうが良いかもしれません。
ただ、立って使うことが多い人は逆に邪魔になるので、気をつけてください。

まとめ

ターゲットユーザ層としては、女性な感じがしますが、色味によっては男性でも問題なく使うことが出来ます。
また、毎年の改良もあって使いやすさやみやすさが増してきている気がします。

カバーについては、カバー紹介部部でも書いた通り、普通に使うのであれば特に付ける必要はないかと思います。

一般的な手帳に比べると価格が少々高い気がしますが、いつもと違う手帳を使ってみようと思う中の一つの選択肢になれば幸いです。

Written with StackEdit.

2017年2月22日水曜日

Atom で文字数の表示を行うパッケージ wordcount

ブログを書いていると、気になるのが PV を稼ぐ方法。
その時に、よく目にするのが、大体 3,000 文字程度は文字数が有ったほうが良いとのこと。

これは、Web のスパイダーが来て、解析した時に文字数が少ないとインデックスが作れないから、3,000 文字程度は必要ということらしい。
通常は StackEdit を使用して書いているのだけど、若干クセがあるので、元となる文章はエディタで書きたい。

現在愛用しているエディタが Atom エディタだけど、標準では文字数のカウントが表示されない。
まあ、プログラム用のエディタ(?)なので、文字数なんて必要なってことでしょうか。

が、しかし、パッケージの多さもこのエディタの魅力で探してみると、やはりありました。
今回紹介するのは、その文字数を表示するためのパッケージです。

名前は wordcount。そのまんま。
インストールはいつもの通りで、メニューの Preferences… より「wordcount」と入れれば出てくると思います。

設定画面を見ると、以下のような設定ができるようです。

  • ファイルの拡張子でパッケージを適用させるための拡張子指定(とその逆のOn/Off)
  • 常にパッケージを有効にするかのチェック
  • 入力文字数にゴールを設定出来るようになっていて、そのゴールの文字数指定と達成したときの色指定
  • 全体のどのくらいでゴールとするかの指定
  • Markdown のコードブロックでのカウントを無視するかどうか
  • 文字数カウントを非表示の On/Off
  • 金額表示ための設定(例えば 60 とか書くと、$110 と合計表示してくれる)

以下は、実際にオプションを入れた状態で表示した画面。

実際に試してみると、文字数はそこそこ上手くカウントできている感じがします。
単語数については、英語の場合は良いけど、日本語ではあまり意味ない感じ(日本語で単語のカウントできたら、それはそれですごい)。
ゴールについても、達成時のみに色がつくのなら別段付けなくても良い気がします(中間の色指定があればよかったけど)。

面白いなと感じたのは、金額の合計処理がある所。
ただ、この機能も使うかと言うと、微妙な気がします。

まあまあ、使わない機能多いのですが、本来の目的の文字数が見えるようになっただけでも十分ありがたいパッケージでした。
類似のパッケージもあるのですが、ひとまず使ってみて、他に良いものがあれば比較検討したいと思います。

私と同じく、元の原稿は Atom で書かれる方は一度導入検討してはいかがでしょうか。
ちなみに、この文章自体は 1200 文字程度なので、合格点には達しませんでした(冗長な文を書くよりは良いでしょう)。

Written with StackEdit.

2017年2月20日月曜日

デスマーチの要因

すこし、時間がとれるようになったので、ブログを書きまくっている(それほどでもないか)。

この手の開発をしていると必ずと行っていいほど碌なことがない。
今回は、デスマーチになる要因とどうすれば良いかについて考えてみた。

経験上、大体デスマーチになるのは、開発の途中に事が起こるのではなく、全くの最初の段階で嫌な雰囲気が漂って来ている事を分かりつつスタートしている場合に起こっている。
これらは、大体お客さんと、作業をする人(設計及びプログラムする人)、そして間を取りまとめようとする人のギャップにより発生する。

その結果、以下の項目が挙がってくる

- 開発期間が短い
- 開発金額が少ない
- 開発内容がハッキリしていない
- お客さん側の担当者が決まっていない
- 技術力が足りない

この項目の発生は次の様なストーリーだろう。



お客は少ない金額で早く物が欲しいと思っている。頭ではシステムが浮かぶが詳細が見えていない場合が多い。
(最悪、簡単にできると思い勝手に納期を決めてしまっている場合がある。例えば 3 ヶ月後には新しいシステムに切り替えたいとか)

なので、打ち合わせの際に詳細が漏れまいと複数人で挑んでくる。
この時、お客側でも取りまとめがいれば良いのだが、複数人となると大概誰かがやってくれると思っている。
よって、個々人が思い思いの発言をして仕様が曖昧になる(開発内容がハッキリしない)。

それを取りまとめの人が聞くと、仕様が混乱してくる。
要るか要らないか分からない仕様が出てくるが、お客との話を聞くと単純な機能を言っているので大したことないと思う。
なので、期間や金額を適当にかつ最小限でお客に伝えてしまう。
また、やったこと無い内容についても、引いたら負けと思い堂々と出来ますと発言して返ってくる。

仕様があやふやなまま開発側は、怪しいと思いつつも見積もりを出す。
この時なぜか、期間や金額については補正が入り不利な状況になる。

そして、開発がスタートされる。
開発が進むにつれ、細かな詳細が不明となり、内容を聞くと仕様の追加が重なり、挙句片方を活かすと片方が機能しないなどと行った状態になったりする。
追加見積もりは、受け入れられないのに納期だけが迫ってくるようになる。



経験則と、フィクションが入っての内容だけど、多分こんな感じが多数だと思う。

結局これらの解決策は、関係者がどれだけ細かく段取りと見積もりが出来るかによると思う。

お客側の心得としては、開発内容をしっかりとまとめた上で取りまとめ担当と話をすること。
取りまとめ担当の心得としては、開発内容を理解しようとすること、無駄な部分を省こうとすること。
開発側の心得としては、開発内容を理解しようとすること、自分たちの開発力を考えて話をすること。

とにかく曖昧な部分を一つでも作ってしまうと、それが歪となり後々に影響が出ることになる。
状況を明確にして、出来ないこと、わからないことをしっかりと各担当に浸透させ話し合える事が重要だと思う。
無理な場合は最悪開発自体を断念するといったことも一つのカードとして持っておけば悲劇を産まなくて良くなるかもしれない。
(こういったことを言える関係性があれば、きっとデスマーチにはならないと思うが。)

今回の要因のなかで該当するものがあれば、対処するようにすればデスマーチは防げるかも!?

キートップを 2 色成形の物に変更してみた(FILCO SPKCS104D)

今回は、「Majestouch専用104英語配列・2色成型カスタムキーキャップセット(SPKCS104D)」の紹介です。

きっかけ

現在、アーキサイト製の I-T Touch AS-KB87C というキーボードを使用しています。
このモデル自体は現在販売していませんが、購入したのはもう 2 年ぐらい前になります。

地味ながらキーボードについてはこだわりが有ったので、ちょくちょく情報は仕入れていました。

良くキーボードの選定の基準となるのが、静電容量式、次にメカニカル、あとはメンブレンなどの接点方式。
その他に、パンタグラフや、バックスプリングなどの部分。
また最近ではゲーミング用でよく使われているバックライト。
USB や Bluetooth などの接続方式など様々な要件があるかと思います。

そんな中、私が気になっていたのが、キートップの成形方式。
通常であれば、単なるキートップにアルファベットを印刷をしたものが採用されているかと思います。
価格が上がってくると、昇華印刷や 2 色成形があり、こちらは耐久性重視となっているようです。

私が使っているキーボードは、スイッチは Cherry 製となかなかの物を使っていますが、キートップについては一般的な印刷タイプでした。
そこで、この部分を変更できないかと調べてみると、FILCO 製の 「Majestouch専用104英語配列・2色成型カスタムキーキャップセット」があることがわかりました。
「Majestouch専用」とありますが、キースイッチは Cherry 製を採用していたので互換性があるのではないかと。。。
ということで、早速購入してみました。

あと、探してみると最初から 2 色成形を採用しているキーボードがアーキサイトから発売されているようです。
作業が面倒な方はこちらの購入をしたほうが良さそうです。

キートップを見てみる

購入した内容は以下のとおりです。
キートップが真空パックされて入っています。

内容物は 2 色成形のキートップと、キートップを外す方法を書いた簡単な説明書のみとなります。

キートップ自体に艶があることがわかるかと思います。

比較するとよくわかりますが、背が高くなっています。
ちなみに、一部だけ変えると以下のような感じ

裏を見ると、2色成形になっていることが分かる(?)かと思います。

Shift やスペース などのキーが長い部分には、スペーサが付いています。
Majestouch であれば、この部分に金具を引っ掛けるようになるみたいです。

交換作業開始

今更ですが、書いてある通りメーカーも製品も全く異なるものなので、この作業は自己責任となります。
最悪の場合は、キートップが無駄になりかねませんのでご了承の程よろしくお願いします。

ということで、早速交換をしてみました。

問題発生!!強敵スペーサ

左上の ESC キーから右に向いて順調に交換をしていったのですが、長めのキーの部分で問題が発生しました。
キートップの部分の紹介部分でも分かる通り、少し長いキーにはスペーサが付いています。

今回のキーボードの長めのキーを外してみると、Majestouch とは違い、金具でサポートするのではなく、左右に別のスイッチ(?) があるタイプでした。

この部分を回避するためには、スペーサを外す必要があるのですが、このスペーサなんとボンドロックされていました。。。
強烈なボンドロックではなく、ネジを締めたときの緩み止めで使用されるタイプのボンドだったので、少し力を加えれば除ける事が出来るのですが、それでもなかなか外れませんでした。
スペーサの空いた部分にマイナスドライバーを突っ込んで引っ張ったりしてみたのですが、この方法ではスペーサを破壊してしまいました。

いよいよ、スペーサの部分を壊してしまい、めり込んだスペーサの除去ができない状態まできて諦めかけていたのですが、人間考えるもので、めり込んだ部分にピンバイスを使いなんとか取る事ができました。
しかし、同じ作業をあと数回繰り返さないかと行けないと思うと、気が遠くなりかけました。
一瞬交換の夢を諦めかけて、買うんじゃなかったなとも思ってしましました。

そんな中、諦めきれず良い方法が無いかと考えてみると、スペーサの間に、ニッパーを滑り込ませそのまま引き上げる方法を思いつきました。
この方法が案外うまく行き、先ほどまでの憂鬱な気分が一気に晴れ上がりました。
そして、全てのスペーサを取り除くことに成功しました。

苦労して全てのキートップを変更した姿が以下の通り。
とても見栄えが良くなりました。

使ってみた感想

なんとか苦労して変更できたので、早速入力を試してみました。

まず、すぐに分かるのが、キートップの触った感じです。
もともとのキートップがザラザラとした加工だったのですが、今回物は艶々しているので、指に吸い付く感じになりました。
好き嫌いがあるかもしれませんが、この感触は私としては好きな感触です。

次に、音の違いに気が付きました。
このキーボードは、青軸を使っていて入力の時に結構うるさいタイプのキーボードでしたが、キードップが肉厚になったためか音が少し低くなり、上品な感じになりました。

最後は困った点になるのですが、キートップが高くなることにより、指を上の方に上げないといけなくなったので、リストレストが必要となった部分です。
以前も若干手を浮かせてタイピングしていかたと思うのですが、手を浮かせる部分がさらに意識して入力しないといけなくなりました。
こういった部分で肩こりになりそうなので、リストレストは必要かと思います。
現状持っていないので、タオルを重ねて高さを稼いで使っています。

総合的に、入力が格別しやすくなったとかはないので、自己満足な世界になってしまいますが、個人的にはとても満足です。

まとめ

スペーサの部分で不安になりましたが、無事交換できたので良かったです。
今回はたまたまボンド部分が外せるタイプだったので良かったですが、この部分が完全な接着剤だと途方に暮れていたことでしょう。

別のキーボードを買ったら同じように交換するか?と言われたら多分やらないでしょう。
どうしてもとなれば検討しますが、スペーサのボンドの仕様が変わってしまうとアウトなのでなんとも。
やるにしても FILCO 製のキーボードを購入してからですね。

実際の使用感もとても満足しているので、苦労はありながらでも愛着があるキーボードになりました。
まあ、こんな事をするなら始めっから 2 色成形されているキーボードを購入したほうが安心・安全・確実なのでおすすめしませんが、カスタマイズ好きの方は検討してみてはいかがでしょうか。

広告

Written with StackEdit.

2017年2月17日金曜日

Oracle SQL Developer を使って PostgreSQL に接続する

PostgreSQL を使う時に GUI クライアントを使うことがあるかと思います。
よくみるのが pgAdmin で、最近 PSequel を知りました。

実際に上記のものを使ってみたのですが、今回は Oracle SQL Developer を使って PostgreSQL に接続してみたいと思います。

上記以外にも、PostgreSQL の wiki にまとめがありました。

Community Guide to PostgreSQL GUI Tools/ja
https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools/ja

1. 準備

まず、このツールを使うには、Oracle のアカウントを作成する必要があります(無償)。

次に、システムに JDK がインストールされている必要があります。
JDK がインストールされているか確認するには、ターミナルで以下のコマンドを入力して確認してください。
ここで、バージョン表記等が出ないのであればインストールされていないので、別途インストールしてください。

$ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

あと、当然ながら PostgreSQL はインストールしておいてください。
そして、ログインユーザとは別に DB 操作用のユーザを追加しておいてください。

ちなみに今回の私の環境は、

  • Mac OS 10.12.3(Sierra)
  • JDK 1.8.0_45
  • PostgreSQL 9.5.2

です。


2. インストール

以下のサイトより SQL Developer を入手します(Oracle アカウントが必要)。
入手したファイルを展開するとアプリが取り出せるので、アプリケーションに移動させてください。


3. PostgreSQL 用の JDBC ドライバの設定

通常は、Oracle の接続のみしか出来ないようになっているので、PostgreSQL も接続できるように JDBC のドライバを設定する必要があります。
まずは、JDBC ドライバを PostgreSQL のサイトから入手します。
この時に、入手するドライバは JDBC のバージョンに有ったものを入手してください。
(私の環境なら JDK 1.8.0 だったので JDBC42… が該当)

PostgreSQL JDBC Driver
https://jdbc.postgresql.org/download.html

取得できたらアプリケーションを起動して、メニューの Preferences… を選択し設定画面を出します。
プリファレンスのウインドウが表示されるので、データベース > サード・パーティJDBCドライバを選択します。
画面右に「エントリの追加」があるので、クリックして先ほど入手したドライバを選択します。
サード・パーティJDBCドライバを・パスに追加された事を確認して「OK」ボタンを押します。


4. 接続チェック

これで、接続の準備は出来ました。
接続ボタンを押すと、データベース接続の作成/選択のウインドウに「PostgreSQL」のタブが追加されているかと思います。
上部の接続名、ユーザ名、パスワードを入力して「テスト」をクリックしてください。
エラーの場合は、メッセージが表示されるので確認してください。

上手く接続できていれば、「データベースの選択」ボタンを押すことにより、右のリストにログイン可能な DB が表示されるので選択します。
選択後は、「接続」ボタンを押せば完了です。


5. 接続

接続ボタンを押すと、ツリー一覧に DB が表示されると完了です。


6. まとめ

Oracle のツールながら他の DB に接続出来る点はよいかと思います。
本当にざっくり触ったのですが、テーブル選択後のデータ表示後にデータを変更しようとしても編集できないのが気になりました。
クエリを発行すれば、変更はできるのですが、GUI の意味があまりないような。。。

最後最後でちょっと残念な気持ちになりましたが、GUI クライアントを探している方一度検討してみてはいかがでしょうか?

Written with StackEdit.

付箋紙で栞をつくる

付箋紙で栞を作る方法を紹介します。
といっても、オリジナルではなく、すでに沢山紹介されているので、自分自身のメモ書き程度の内容になります。

簡単なのにとってもオシャレ!折り紙で作る『三角しおり』が可愛いと話題に!
http://spotlight-media.jp/article/242409109108673033



1. 準備


今回手元にあったのが、長方形の付箋紙だったので、最初に正方形にするために、不要な部分を切り取ります。
初めから正方形の付箋紙や紙があれば、この工程は不要です。

2. 折り目を付ける


次に、折り目を先に付けておきます。
慣れれば、その都度折り込んで行けば良いです(記録を兼ねてなのであえて先に折り目を付けておきます)

3. 最初の折込み


先ほど付けた折り目に合わせて折込を行います。

4. 折り目を付ける その2


早くも最終段階になりましたが、差し込み部分を作るための折り目を付けます。

5. 仕上げの折込み


同じく、先ほどつけた折り目に合わせて折込を行います。

6. 完成


7. 使った感じ


使った感じは以下のような感じです。
本を閉じると以下のような感じです。

8. まとめ


この栞は、差し込みタイプなので、本を閉じても目立つし、ページも開きやすいので、付箋を栞として使うのと比べると使い勝手がよいです。
私自身あまり器用ではないのですが、非常に簡単に作ることが出来ました。
長方形の紙でも正方形に変えてしまえば良いので、一度作ってみてはいかがでしょうか。

Written with StackEdit.