ブログを書いてて、途中で止めた。それでも意味があることもある。

自分はちょくちょくそういうことあります。

これはブログネタになるかもと、色々考えを広げるために下書き的に書いていったんですが、途中で「ダメだ。これ以上は広がらん」といってボツにしたようなエントリ。

ブログを書くのを途中でボツにした理由

途中でブログを書くのを止めた理由は幾つかあります。

・ 最初は面白いネタだと思って書いてたが、まとめてたら「これ面白い？」と自分で懐疑的になり書くのを止めた

・ 何が言いたいのか自分でわからなくなってきた

・ どうしてもオチ（結び）が見つからない

・ 答えが見つからない

・ 書いてる途中に答えが見つかった

・ わざわざブログで書くことではないかな、と最初の情熱が消えた

・ 他の人がすでに言っていた（答えがかぶった）

ボツにしたネタの内容によって、いろんな理由があるのでしょう。

書くジャンルによって違ってくるのですが、自分で1つの議題にあれこれ考えてみたときに、そういうことが出てきたりします。

他人のブログを読んでインスパイアされたネタでも、その議論に対する自分の意見を書いたらいいだけなのに、途中で挫折することもしばしばです。

まぁ、一言で済んでしまうようなネタもあったりするので、「33分探偵」みたく無理やり引っ張って1エントリを書くのもなんだかな、と思ったりすることもあります。

なので、技術系のエントリは検証とかそういうのに時間がかかったとしても、書きやすいネタではあります。

答えがはっきりしているものですので、各テーマだけを決めてしまえば、後はその結果を書いていくだけで済んだりします。（それが読者にとって読みやすかったり、わかりやすかったりするかは別ですが）

ボツすることの意味

例えそのエントリをボツにしたとしても、それまでの間に色々考えたことは無駄にはならないかなと、思ったりします。

自分の考えをまとめていったときに、それがすでに他の人が出している答えとかぶったとしても、ある話題に対して体系的にまとめてみた結果、そうであると言う一つの答えが導けたりもしているので、それを公表しなくても、自分の中で解決した結果が出るわけです。

自分の考えをまとめという点でブログというツールは優れているものだな、と思ったりします。

もちろんTwitterなんかでこまめに吐き出し続けることで、答えを得ると言うやり方もあると思います。

ただ、それをまとめて公表するとなるとブログのほうがわかりやすいでしょう。

ただ、ボツにするとしてもアウトプットを出しておくと言うことも1つの方法かな、とも思います。

答えが出なかったとしても、今頭の中にあるもやもやとした考えをなんとなくですが、出しておけば誰かがそれに答えてくれるかもしれませんし、何日、何年か後に自分でそのエントリを見直して答えが見つかるかもしれません。

下書きだけしておくのも良いでしょうし。

実際、自分でも数ヶ月前に書こうとしてボツにしたネタを再度拾い上げて書き上げてみた、と言うこともあったりします。

やっぱり時間を置くことで考え方も変わってきたりします。

あの時には答えが出なかったけど、その後の経験や他の人の考えを読んだら答えが出たとか。

少なくとも、いろんなネットの情報に触れて自分なりに考えることを始めてみると言うことは、意味のあることだと思います。

自分の中に答えが無かったとしても、その考えの種を拾い集めておき、いつかそれを咲かせることができれば、自分の考えの変化を知るバロメータにもなるかもしれません。

単にボツにしてしまって考えるの止めてしまうのは少しもったいない気がします。

関連記事

技術ネタをブログに書く上で気をつけている7つのこと

知らないから書けるブログ

アウトプットの一環として活用するブログ

ブログが読まれるきっかけと読まれるためにすべきこと

ブログを続けるモチベーションの維持の仕方

Twitterとブログはどっちが信頼を得やすいのかな

昔ならブログに書けたこと

ネットでN対Nのコミュニケーションってあるのかな？

表現ツールの多様化、ブログに代わるもの

ブログが埋めるもの、Twitterが埋めるもの

ネットでN対Nのコミュニケーションってあるのかな？

ふとそんなことを思いました。

例えば、友達と数人で飲みながらわいわいするような会話、会社でいろんな担当者を呼んで議論する会議、そんな複数人が双方向でやり取りするコミュニケーションは、ネットの世界では随分と少ない気がします。

単にそれらをネットに置き換えてチャットをする、というのはあると思いますけど。

が、多くは1人（1つ）の問いかけや議題に対して、複数人がわいわい意見を言うような1対Nの形式が多いですよね。

しかも、その意見をいう人は互いに顔を知らずに話しているわけです。

2chで取り上げられるスレッドでも、話題を提供する人が1人いて、語り手と聴衆というような形式で話が進んでいくことが多いです。

途中、幾人かがが合いの手入れますけど、それは語り手（話題の提供者）に対してのものが中心で、聴衆同士が意見を交わすことはほとんどありません。

なので、1対Nという表現は、そのコミュニティを取り巻く状況を俯瞰してみたらそうであって、実際のところは語り手と聴衆の1人が1対1のコミュニケーションをとり続けているだけ、と言うのが実際だったりします。

リアルの世界でも局所的に見れば、もちろん1対1の会話と言うもので成り立ってはいるのですけれど、それに対して別の議論が巻き起こることはあります。

ネットの匿名性から、互いに知らないもの同士、しかも自分たちが中心にいない場では、その脇役同士が会話を交わすことにあまり意味を持たない、というのも1つあるかもしれません。

飲み会の場では、いろんな人が弄られて時に自分に主役の場がまわってくることがありますけど、ネットの世界の多くでは、その場というものは自分が作り出さなくてはならず、しかもその「場」というのは、共有しにくい性質を持ってたりします。

例えば、ブログで1つの話題を提供して、それに反応しようとした場合、コメントしてもいいですけど、もう少しきちんとまとめて意見を書きたいなら、自分のブログにその場を持ってこないといけなくなったりします。

トラバしてたとしても、場が離れている関係から、円滑にコミュニケーションもとり難いですし、何よりも反応が遅く、話題の鮮度が落ちていってしまいます。

Twitterも基本、1対Nのコミュニケーションツールではないでしょうか。

ある人の発言に反応して、フォロワーがPOSTしだす。

そんな繰り返しで会話が成り立ってたりします。

でも、フォロワー同士が会話しだすのは無いですよね。

まぁ、そのフォロワー同士がフォローしあっておらず、知らない同士で会話がしにくいと言うのはあるかもしれませんけど。

Twitterって個を表現できるツールですけど、議論するとなるとその人のタイムライン上では会話が成り立っても、外野（フォロワー）の人には、その情報をつかみにくかったりもします。

なんかこの辺がもう少しどうにかなったら面白いのにな、と思ったりします。

これは日本だけなのかどうかわかりませんけど、ネットの世界を見ていると発言者を立てる、という文化があるような感じも受けます。

とりあえず自分の意見を伝えてみて、外野が何か言っててもそれに反応することは、元ネタの発信者の場を壊すことになってしまうな、というような感じでしょうか。

空気を読むというかなんと言うか。

ただ、当然その助言に対して新たな意見や議論の余地と言うのは生まれてくるもんだと思ったりします。

リアルの世界でも、当事者以外のところで熱弁を振るうもの同士がいたりしますし。

なんか、この辺をもっと押し上げていったら、ネットってより面白い方向になるのではないかな、とそんなことを思ったりもしました。

関連記事

技術ネタをブログに書く上で気をつけている7つのこと

Twitterの台頭でRSSは死んだのか？

ブログを書いてて、途中で止めた。それでも意味があることもある。

表現ツールの多様化、ブログに代わるもの

ブログが埋めるもの、Twitterが埋めるもの

ネットとリアルの境目、表現とその感覚

簡単にファイル検索をするためのlocateコマンドオリジナル活用法

Linuxでファイルを探したい場合、findコマンドが一般的ですが、コマンド実行後に検索を開始するため、実行結果が得られるまでに結構な時間がかかったりします。

こういう場合、locateコマンドを使うことで、瞬時にファイルの情報を取り出すことができます。

実際にやってみればわかりますが、体感速度でも雲泥の差がでます。

locateコマンドは、updatedbコマンドにより、予めファイル一覧のDBを作っており、そのDBに問合せることで、高速にファイル検索を実現しています。

欠点としては、DBが使われてるが故に新規に作成したファイルはDBが更新されるまでは検索できないと言うところにあります。

そして、DBを更新するupdatedbコマンドは負荷がかかる上に時間もかかります。

ですので、頻繁に実行することは現実的ではなく、ほとんどのディストリビューションにはバンドルされているものの、cronで深夜にひっそりと動くように設定されています。

#!/bin/sh

nodevs=$(< /proc/filesystems awk '$1 == "nodev" { print $2 }')

renice +19 -p $$ >/dev/null 2>&1

/usr/bin/updatedb -f "$nodevs"

一見、便利なのかどうか良くわからないlocateコマンドですが、使いようによっては色々なことができたりします。

例えば、毎日深夜にcronで動かす際に、DBを別々に保存しておけば、その日ごとのファイル一覧を保存したDBが作れたりします。

急にファイルが増えた際に、何時そのファイルが増えたのかや、インストールされたコマンドの一覧を取り出すなんてこともできます。

ここでは、オリジナルのlocate用DBを作りながら、locateコマンドの使い方を簡単に説明してみます。

locate用のオリジナルDBを作る

まずは、locate用のオリジナルDBを作ってみます。

DBの作成方法は、updatedbコマンドを使います。

# updatedb -U /var/www/htdocs/ -o /var/lib/mlocate/test.db

「-U」オプションは、DBに取り込む対象のディレクトリです。

上記の例では、Apacheのドキュメントルート以下を仮定して実行しています。

こうすることで、日々のコンテンツファイルの一覧をDBに格納しておくことができ、ファイルの増減を管理するのに役立ったりします。

次に「-o」オプションですが、これはオリジナルのDBファイルパスになります。

オリジナルのDB（オプションなしでupdatedbを実行した場合に更新されるDB）は、「/var/lib/mlocate/mlocate.db」なんかにあるかと思います。（ディストリビューションやバージョンによって異なっていると思いますが）

これで、ドキュメントルート以下のファイル一覧を格納したオリジナルのDBができました。

次に、そのDBからlocateコマンドを使ってファイルを検索してみます。

# locate -d /var/lib/mlocate/test.db *.html

/var/www/htdocs/html/error.html

/var/www/htdocs/html/index.html

/var/www/htdocs/html/login.html

ちゃんとできているようですね。

もし、DBに取り込みたくないディレクトリがある場合は、「-e」オプションの後にそのパスを指定しておきます。

# updatedb -U /var/www/htdocs/ -e /var/www/htdocs/images -o /var/lib/mlocate/test.db

これで、「/var/www/htdocs/images」ディレクトリにあるファイルは、DBに取り込まれません。

除外したいディレクトリが複数あって、毎回書くのが面倒であれば、「/etc/updatedb.conf」ファイルの「PRUNEPATHS」変数に追記しておいても同様の効果が得られます。

PRUNEPATHS = "/afs /net /sfs /tmp /udev /var/spool/cups /var/tmp /var/www/htdocs/images"

オリジナルのDBを毎日更新する

例えば、下記のようなシェルスクリプトを作って、cronに登録しておけばその日ごとのlocate用DBを作成することも可能です。

#!/bin/sh

DAY=`date +%d`
DBROOT=/var/www/htdocs/
DBPATH=/var/lib/mlocate/locatre_$DAY.db
/usr/bin/updatedb -U $DBROOT -o $DBPATH

DBは「locate_xx.db」というファイル名（xxは日付）でできますので、その日に存在していたファイルを確認することもできます。（あくまでupdatedbコマンド実行時点の結果になりますが）

実行結果を比較すれば、その日に新しく作られたファイルや削除されたファイルの一覧を取り出すこともできるでしょう。

簡単なファイルを追跡ツールとして利用できるかもしれません。

[PR]お名前.comのホームページ作成ツール★誰でも簡単にWebクリエイターに

[PR]光ファイバー/ADSLを楽しむなら「安心」「安全」の@nifty！

[PR]キャンペーン開催中！パソコンを買替えるならFRONTIER

関連記事

ImageMagickを使ってコマンドラインからCAPTCHAを作ってみる

Linuxサーバー上でデータ操作に便利な10のコマンド

簡単にファイル比較ができるdiffコマンドの使い方

inotifyを使ってファイルやディレクトリに起きたイベントを簡単に監視する

[Linux] 削除できないファイルの作り方

不要なファイルやディレクトリを削除できる「tmpwatch」コマンド

logrotateでローテーションされるファイル名を変更する

Logwatchでサーバー上のログを集約する

[24時間365日] サーバ/インフラを支える技術