t-hom’s diary

主にVBAネタを扱っているブログです。

Python Processingで写真を六角形に切り取って並べる

今回は写真を6角形に切り取って並べるPython Processingコードのメモ。

出来上がりのイメージはこんな感じ。

上記はSatisfactoryというゲームで撮りためた風景スクリーンショットである。
このゲームは最近Update 6という大型パッチがリリースされたところで、地形アップデートにより更に景観が美しくなっているので写真撮影が止まらない。

一枚つずつ紹介するのも多すぎるので小さくして並べようと思ったんだけど、パワポで縮小とトリミングを手でやり始めたところズレるしサイズも狂うしなんか微妙な見た目になってしまった。

そこでProcessingを使って綺麗にしようと思ったんだけど、どうせやるなら何か面白い形にしたいというのが発端。

コード

注意) 私の環境では画像データ38枚の読み込みに30秒ほどかかった。
大きな画像が大量に入ったフォルダーを指定するとフリーズする可能性があるのでご注意。

import glob
def setup():
    background(0)
    global radius
    radius = 87 #(1)
    size(1280, 720)
    
    #(2) (参考) https://discourse.processing.org/t/unexpected-strokes-are-shown-on-p2d-pgraphics/21660
    hexagon = createShape()
    hexagon.setStroke(False)
    hexagon.beginShape()
    for i in range(0,6): #(3)
        angle = i * PI/3 + PI/6 #(4)
        hexagon.vertex(cos(angle) * radius, sin(angle)*radius) #(5)
    
    hexagon.endShape(CLOSE)
  
    global photo
    photo = []
    
    files = glob.glob(ur"C:\Users\ho_\OneDrive\docs\My Games\FactoryGame\Screenshots\*")
    for file in files:
        print(file)
        p = loadImage(file)
        
        #(6)
        if (p.height < p.width):
            p.resize(radius*4, radius * 4 * p.height/p.width)
            cutlocation_x = p.width-radius*2
            cutlocation_y = p.height-radius
        else:
            p.resize(radius * 4 * p.width / p.height, radius*4)
            cutlocation_x = p.width-radius
            cutlocation_y = p.height-radius*2
 
        #(7) (Ref)https://forum.processing.org/two/discussion/18819/how-to-copy-a-triangle-out-of-an-image.html
        maskImage = createGraphics(p.width,p.height)
        maskImage.beginDraw()
        maskImage.shape(hexagon,cutlocation_x, cutlocation_y)
        maskImage.endDraw()
        p.mask(maskImage)

        #(8)
        p = p.get(cutlocation_x-radius, cutlocation_y-radius, radius*2, radius*2)
        photo.append(p)
    
def draw(): #(9)
    x = 0
    y = 0
    for i in photo:
        if y % 2 == 0:
            image(i, radius*1.8*x,radius*2 * 0.79 * y)
            x_limit = 8
        else:
            image(i, radius*0.9+radius*1.8*x,radius*2 * 0.79 * y)
            x_limit = 7
            
        x = x + 1
        if x == x_limit:
            x = 0
            y = y + 1

解説

  • (1) 正N角形の頂点は円に接するので、正N角形のサイズを頂点が接する円の半径radiusとして設定する。
  • (2) 頂点が円に接するということは、円周をN分割した切れ目のところがN角形の頂点になる。
  • (3) 今回は6角形なので頂点数、つまりループ回数は6回。
  • (4) 弧度法では360度が 2\pi ラジアンなので、6分割すると\frac {\pi}{3}である。これにiを掛けることで角度が求まる。また、図形を30度傾けるために\frac {\pi}{6}を足し合わせている。
  • (5) vertexはx,yを指定して図形に頂点を追加する命令である。三角関数でラジアン角度を座標に変換する。6回繰り返すと六角形の完成。
  • (6) 横長の画像か縦長の画像かを判定して縮小サイズと切り取り位置を分岐させている。

  • (7) 6角形をマスク画像としてPGraphics型のマスクイメージを作成し、画像に適用。
  • (8) マスクは画像全体に掛かるため、必要部分のみ切り取り、加工が完了したイメージをphotoリストに追加。
  • (9) xを増加しながら横に並べていき、規定数に達したらyを増やしてxをリセットする。yが偶数のときはxの最大個数を一つ減らす。

終わりに

今回はProcessingで私がやりたいことを実現できたので、今後Processingを活用するシーンが増えるという手ごたえを感じた。
また何か面白いアイデアが湧いたらProcessingを使ってみようと思う。

以上。

6/19 追記 1

指定するフォルダーによって読み込みできないバグに遭遇したので修正した。
どうやらUnicodeの文字化けと、バックスラッシュが特殊文字と解釈されていたのが原因のようで、パスの文字列にurを付けてUnicdeのraw文字列にすることで解決した。

# Before
files = glob.glob("C:\Users\ho_\OneDrive\docs\My Games\FactoryGame\Screenshots\*")

# After
files = glob.glob(ur"C:\Users\ho_\OneDrive\docs\My Games\FactoryGame\Screenshots\*")

(参考)
www.javadrive.jp

6/19 追記 2

スマホで撮影した縦長のJPEGを読み込むと横倒しになってしまう問題があることが分かった。
どうやらそれらのJPEGはもともと横倒しの画像にEXIFという方向の情報を付けることで縦向きとしてふるまっているらしく、WindowsのプレビューなどのEXIFに対応しているソフトでは縦に表示されるが、EXIFに対応していないソフトでは本来のデータどおり横向きに表示されてしまうらしい。

残念ながらProcessingはEXIFに対応してなさそうで、外部ライブラリ等を色々調べた結果断念した。
回避策として一番簡単なのはPNG形式に変換してしまうことだろうか。

私の場合はWebで一括置換するツールがあったので利用してみた。ただ本来横倒しでEXIFによって縦になっているJPEGをPNG化したら横倒しに戻ってしまったので、Windows標準のビューワーで回転させて戻した。
※このビューワーも曲者で、回転させてしばらくしないと保存されないのでサクサク回転させていくと中飛ばしになってしまうということが発生する。

6/19 追記 3

縦長の画像の場合に切り取る位置と縮尺が想定と違うことが分かった。
あんまり理論的に考えずにトライ&エラーで完成したと思い込んだ為のバグ。
これは時間を見て直そうと思う。

SymPyで三角関数のテイラー展開 ~ sin()の中身はどうなってるのか

前回desmosという数学ソフトのサンプルとしてテイラー展開を示したが、私にはよく分からないと書いた。

ただこれ、よく思い出してみると三角関数のsin()の実装がどうなっているのか気になって最近調べたサイトで見かけたことがある。
hackemdown.blogspot.com

つまり以下の式を使えばsin関数を自分で作ることができるということらしい。
 \displaystyle \sum_{n=0}^{a} \frac{ (-1)^{n}x^{2n+1}} {(2n+1)!}

※少し話が脱線するが、はてなブログはTeX記法が使えるので上記の数式は以下のように書ける。

[tex: \displaystyle \sum_{n=0}^{a} \frac{ (-1)^{n}x^{2n+1}} {(2n+1)!}]

少し複雑だけど有志がチートシートを公開しているのではてなブログで数式を書きたい時はTeX(てふ)について調べてみると良いかと思う。

…話をもどして、そのときはVBAでやろうとして階乗ですぐオーバーフローになったり、どこかで式の理解を間違えたのか値がズレすぎて諦めていた。

今回はSympyを使ってリベンジしてみる。

コードは以下の通り。

# 準備
import math
from sympy import init_printing, symbols, Sum, factorial, summation, solve
from sympy.plotting import plot
%matplotlib inline
init_printing(use_latex='mathjax')

x,a,n = symbols('x a n')

# 式の組立
y = Sum((-1)**n*x**(2*n+1)/factorial(2*n+1), (n, 0, a))

# 繰り返し回数 a の決定とプロット
f = y.subs({a:20})
plot(f)

Google Colaboratory でやってみると次の通り。

おお、サイン波っぽいのでた!
できてるようだ。

しかし実際にxを代入して計算させたいけどうまくいかなかった。
次のように文字式のまま表示されてしまい、solveしても結果が現れない。

なんかやりようはあるんだろうけど一旦断念してSum()の代わりにsummation()という関数を使うことにする。

関数f2として作成するコードがこちら。

f2 = summation((-1)**n*x**(2*n+1)/factorial(2*n+1),(n,0,20))

Sumを使ったときと式は大体同じだが、繰り返し回数を表す文字aは消えている。
最後の(n,0,20)がその代わりとなるもので、nは0から20まで繰り返すという意味。

こうするとシグマではなくそのまま総和が展開された形の関数ができあがるようだ。

なんかすごいのが出てきてしまったが、plotするとやはりサイン波がでてる。

この関数f2(x)が本当にsinになっているのか、以下のとおりmath.sin()と比較してみた。

小数点以下9桁まで一致しているので、そこそこ精度は出ている。
繰り返し回数をもっと増やせば精度を高めることができるだろう。

以上。




。。。やるか。

ばーん!

うぉぉぉぉ!!!

オォォォォヲォォォ!

よし、完全一致。

数式でるまで30秒かかったのでまったく実用的ではないけども高精度sinが出来た。

真面目な話、繰り返し回数を増やしても浮動小数点型で表せる小数点以下の桁数に限界があるのでどこで打ち切るかが問題となる。
またSin(10)程度ならテイラー展開が精度も高くて現実的なスピードで計算できるけど、角度が増えると計算量が増えるので、C言語のライブラリでは一定角度以上はあらかじめ計算した値をライブラリ内で持っていてそれを返すという実装になってるらしい。

コード読んだわけじゃないので本当のことは知らないけど。

以上。

数式だけで絵が描ける?関数グラフアートという世界とその原理

皆さんは関数グラフアートをご存じだろうか。
その名前のとおり、数学関数のグラフを使って描かれた絵や動画などの作品を指すのだが、これまで原理が分からずもやもやしていた。

下記の記事を読んで、これがdesmosというツールで作られているということがわかり、じっさいに使ってみたところ取り急ぎ原理だけは理解できたのでご紹介。
www.sendaiikuei.ed.jp


desmos.comにアクセスするとヘッダー中央にGraphing Caluculatorというボタンがあるのでそちらをクリックすると開始できる。

サインアップもできるようだけど、特にしなくても使える。サインアップするメリットは調べてないけど、恐らく作ったグラフを保存できるとかだと推測。

早速使ってみた。

ふむ。。ただのグラフだ。こんなので絵なんて描けるのか?

半信半疑だったんだけど、調べるとxやyをこのようにして範囲指定できるらしい。

なるほど。しかしここからどうすれば。。と思い更に調べる。

あ、なるほど、いくらでも数式足せるのか。

はい、原理完璧に分かった。

もともと何か一つの複雑な数式で一筆書きのようにアートが出来上がるのかと勘違いしていたので、そんなこと出来るのか?と疑ってたんだけど、複数の数式をごちゃっとグラフ表示しているだけということなら理解できる。

数学知識があまり無い為「出来る」と「出来ない」の境界が分からず、とんでもなく間違った想定に基づいて解決策をイメージしようとして全く分からないとなる。これってプログラミング始めたばかりの方も同じようなことに陥ってるんだろうなぁと、改めて初心者の気持ちを想像できた。

さて、原理は意外とシンプルで、描きたい線により近いグラフの関数をチョイスして組み合わせるという数学センスによって、より効率的で美しいアートが出来上がるというわけだ。

人様の動画だけど、作業の雰囲気はこんな感じかな。。
youtu.be

こういうのは数学で新しい関数を覚えるきっかけにもなるし、教育的にもとても良さそうだなと思った。

さて、まるでアート用ソフトのような紹介の仕方だったので最後に訂正しておくと、desmosはれっきとした数学グラフソフトである。左上のハンバーガーメニューをクリックすると左側にサンプルを選択するメニューが出てくる。

試しにテイラー展開というのを選んでみた。

aの値をスライダーで右に動かすと紫の線が徐々に赤線に張り付いていく。

何を意味してるのかは私にはさっぱりだけど。

以上

LEGO Mindstorm EV3 ライントレースボット P制御(比例制御)をやってみた

今回はライントレースボットのP制御をやってみた。
最終的にやりたいPID制御のうち、Pの部分である。

このPはPropotional(比例しているという意味)の略である。

ライントレースボットの場合はカラーセンサーで反射値を読み取るので、その値が目標値から遠いほど操作量を増やすという処理を行う。

今回は操作量を左右旋回の際に片側のタイヤの回転数をどれくらい上げるかという係数に設定した。-1.0~1.0の範囲に収まるようにしたのでプラスの場合は左タイヤを、マイナスの場合は右タイヤを加速させ、実際の加速量は通常スピードの5倍に操作量の絶対値を掛けあわせたものとした。マイナス値をうまく扱えないか思案してみたが眠いせいか妙案が浮かばず断念。

前回の記事で紹介したライントレースボットはオンオフ制御といって目標値を上回るか下回るかしか見てなかったので直線であってとも首を振りながらの走行だったが、P制御の場合は割とまっすぐ進める。

実際に動かしてみたのがこちら。
youtube.com

おそっ!

でもP制御だけだと速度を上げた時にオーバーシュートによってカーブで簡単に脱線してしまうのでこれくらいが限界だった。
直線で加速するなど工夫すればよくなりそうだけど、オーバーシュートするというデメリットがあった方がこのあとのPI制御・PD制御のありがたみが分かりそうなので、とりあえずはこのまま次の学習に進もうと思う。

コード

import time
from pybricks.hubs import EV3Brick
from pybricks.ev3devices import (Motor, TouchSensor, ColorSensor,
                                 InfraredSensor, UltrasonicSensor, GyroSensor)
from pybricks.parameters import Port, Stop, Direction, Button, Color
from pybricks.tools import wait, StopWatch, DataLog
from pybricks.robotics import DriveBase
from pybricks.media.ev3dev import SoundFile, ImageFile

# This program requires LEGO EV3 MicroPython v2.0 or higher.
# Click "Open user guide" on the EV3 extension tab for more information.

# Create your objects here.
ev3 = EV3Brick()


# Write your program here.
ev3.speaker.beep()

a_motor = Motor(Port.A)
d_motor = Motor(Port.D)
cs = ColorSensor(Port.S1)
a_motor.reset_angle(0)
d_motor.reset_angle(0)

KP = 0.02
SPEED = 36*2

a_motor.run(SPEED)
d_motor.run(SPEED)

while True:
    u = (50.0 - cs.reflection()) * KP
    print(u)
    if u > 0:
        a_motor.run(SPEED*5*abs(u))
        d_motor.run(SPEED)
    if u <= 0:
        a_motor.run(SPEED)
        d_motor.run(SPEED*5*abs(u))

以上

LEGO Mindstorm EV3 ライントレースボット 小回りが効くようにタイヤを改良

先日作成したライントレースボットだが、小回りが効かないことによるコースアウト問題に悩まされていたが、ソースコードを直してもうまくいかず、そもそも物理的限界があるようなのでマシンを改良することにした。

まず初号機。こちらは後輪2つを前輪と同じくらいの幅で配置していたが、摩擦が大きくて全然曲がり切れない。

初回の改造では後輪を中央に寄せてしっぽを振るように稼働できるようにしたのだが、これでもまだまだ小回りは難しいことが分かった。

どうも幅の太い前輪の摩擦が足りず、滑っているようだ。

左旋回したいときに下図の摩擦Aと摩擦Bを考えてみる。

曲がりきれていないマシンを観察したところ、2つの要因を発見した。

  • 摩擦Aが不足していることによって左タイヤがその場にとどまることができずに右タイヤに引きずられて一緒に進んでしまう。
  • 摩擦Bが強すぎることによって後輪が右方向にスライドできていない。

更に摩擦Aが足りない(つまり前輪が滑る)要因として、タイヤが幅広なため荷重が分散してしまい十分な摩擦力を発揮できていないのではと考えた。

そこで今回は、細幅のタイヤを調達して後輪はボールキャスターで置き換えることにした。

完成したのがこちら。

タイヤの左右回転比を1:10にして周回動作させてみたところ、うまく小回りできている。
youtube.com
(線の周りをまわっているのはたまたま軌道が合ってるだけで、ライントレースではない。)

次にライントレースさせてみたところ、こちらもうまくいった。
youtube.com

よし、これでマシン部分の基礎は完成した。

次にセンサーを複数個つかってよりスムーズなライントレースができるように改良していこうと思う。
PID制御の実装に向けて一歩前進した。

以上。

理解しなくとも受容できれば学習を前に進めることができると気づいた話

これまでの学習で自分は細かいところで躓いて、色々と疑問が解消するまで次に進めないと思い込んでいたけど、Sympyを使って微積分の学習をしているとどうやらそうでもないらしいということに気づいた。

ちょうど積分の学習に差し掛かった頃、次の表現が出てきた。

最初に見たときの感想は、

は?なにひとつイコールじゃないんだが?

というもの。
多分、プログラミング言語の代入を初めて目にする人ってこんな感想なんだろうな。

。。という話は置いておいて、要は\int ydx = \int 3x^2dx でいうところの\int ydxというのは y=3x^2でいうところのyに相当する、単に求める対象を表す記号なんだなということに気づいた。解説によると\int ydxは面積(y×dx)の積分にあたるらしい。

あとややこしいのは\int 3x^2dx = x^3+Cの部分。\int 3x^2dxを計算したらx^3+Cになるという意味のようだ。
つまり最初の=とは意味が違う。

これは積分の公式というのが書籍で紹介されていたので当てはめてみる。

Sympyを使って計算。説明によるとインテグラル記号 \intとディーエックスdxは「積分するんですよ」という指示にすぎないので計算には関係ないので外しておく。今回のような3x^2という風にx^nが定数倍されている場合は3 * x^2という風に分離してx^2を積分してから定数3を掛ければ良いとのこと。さらに積分定数Cは最後に足して完了。

つまりここで重要なのはx^2を公式に当てはめて変換するだけ。
Sympyを使ってやってみると、

確かに、\int 3x^2dx = x^3+Cとなることが分かった。

積分の公式は正直なんでそうなるのか分からないけど、不思議なことに受容できてしまっている。
これまで、学習を前に進めるためには「理解」が必須だと考えていたのだけど、最近はそうでもなくなってきた。
理解しなくとも受容さえできれば自分は次に進めるのだということに気づいた。

ではその受容条件は何なのか?
人によって「分かった」となる条件は千差万別。自分はどこに到達すれば納得して次に進めるんだろうか。

考えてみると、「再現性」を担保できた時点ではないかということに思い至った。

理由を知りたがるのはつまり、個別の答えが分かってもそれだけでは応用が効かないからである。
原理が分かっていれば値が変わっても計算ができる。だから原理を知りたがる。

でも物事を応用するために必ず原理を理解しないといけない訳ではない。
公式丸暗記でも、計算をコンピューターが肩代わりするでも何でも良い。

要は再現性さえ担保できれば、応用できるのだ。

そして先に進むことで学習した内容が繋がり、結果的に理解にたどり着くのもそちらの方が早いということが往々にしてある。

つまり今回の考察により、「さっぱり分からん!!」となったときにそこで躓かないために、「再現性が担保されたかどうか」という基準を手に入れた訳だ。

今度から何か困っても、再現性は担保できたから一旦受容して次にすすもう!という判断ができる。

この気づきって割と大きいんじゃないかなと思う。

私のブログ継続術 「継続しよう」と思わないこと

週間はてなブログにこんな記事が投稿された。
blog.hatenablog.com

これを読んで、昔100記事を達成したときにこんな記事を書いたのを思い出した。
thom.hateblo.jp

当時と考え方はそんなに変わっていないけど、最近読者になってくれた方もいるので改めて自分がブログ継続のためにとっているスタンスをご紹介。

目次

継続しようと思わないこと

私が一番大事にしている考え方なので真っ先に紹介。
継続するコツが継続しようと思わないことってのは変かもしれないけど、書かなければならないというプレッシャーは継続にとって大敵で、「継続できないから、やめてしまえ」となりがち。

たとえばもちろん毎日書き続けたらそれは継続していることになるが、週に1度でもまぁ継続していると言えるだろう。月に1度でもいい。なら年に1記事でも良いのでは?2年に1記事でもいいし、なんなら10年に1記事でも。。

一体どこからが「継続ではない」となるのかは曖昧だ。ひとつだけ条件がはっきりしている。「やめる」と決めないこと。
やめない限りはもう継続していると言って良い。

この屁理屈ヤロウが。。とお思いだろうが、ついでにもうひとつ屁理屈をかましておく。

やめないコツは、「始めないこと」である。

みんな「ブログを始めた」という意識を持っている。
でも私はそうは思わず、代わりに「何か書いて公開したいときに書ける場所を手に入れた。」と考えるようにした。

ということで、私はブログなんて始めてない。
いやまぁ客観的事実としては始めてるし、当時は始めたと言った気もするんだけど、後付けで意識的に「何かを始めた訳ではない」と思い込むようにしたのだ。
ということなのでつまり、始めてないのだ。だから、やめる必要はない。

何かが始まったわけではなく、そこに書く場所を持っているだけなんだから。

消さないこと

昔読んだWeb記事で、Webサイトの記事のタイプを「鮮魚と干物」に喩えているのを見かけた。
記憶も曖昧だしもう検索しても出てこなかったので直接紹介できないのが申し訳ないけど、鮮魚タイプとは時事ネタを積極的に扱い人を集めるタイプで、このタイプの記事は一瞬爆発的にヒットするものの時が立つにつれて無価値になり忘れ去られていく。

一方で干物タイプとは目立たないけど潰しの利く記事で、主に検索流入によるロングテールアクセス(何年経ってもそれなりにアクセスが続く状態)を狙うもの。

これは面白い考え方だなぁと思った。

技術ブログとか勉強メモ・思想メモは基本的に「干物記事」である。

100記事達成の記事で、「たとえブログの更新がとまっても、書いた記事が、たった一人にでも、たとえ10年かかっても、本当にその情報を必要とする人に届けば、そのブログは無駄ではない。」と書いた。
実はこの考えに至ったのはこの干物記事という考え方のおかげである。

たとえ1記事だけ書いてそのあと更新しなくなったブログでも、その1記事がたまたま誰かに届いて人を助けることだってある。
だから、継続できないからといって消す必要はない。

継続するコツが消さないことって、当たり前っちゃ当たり前なんだけど、継続できないからといって閉鎖という判断を取る方が一定数存在する。なんて勿体ない。別に消す必要ないのに。

ハンドルネームで書く

本名が悪いわけではないけど、ハンドルネームの方がなにかと書きやすいし、現実で何かあっても記事を消さずに済む。
匿名を嫌う人も居るけど、ハンドルネームは完全匿名(名無し)とはまた別で、もう一人の自分である。
ハンドルネームは人格的に整合性をもって取り扱うのでその人の本来の姿が出やすい。

ちょっと違う話になるけど、実名・ハンドルネーム・匿名のうち、一番その人の本質が出るのはハンドルネームだと思っている。

実名というのは実社会のしがらみと切り離すことが難しく、どうしても自分の考えを素直に吐露するというよりは立場を考慮した発言になりやすい。要するに建前で書かざるを得ないということが起こる。

一方で1回限りの完全匿名の場合は自分の人格というよりは、何を書いてもどこにもつながらないことから、刹那的な感情に左右されがちで、その人が「どうありたい」と考えているかともまた違う言葉が出てしまうと思う。誰しも苛立っていたり、一時の欲に負けてしまって心無いことを書き綴ってしまうということはあると思う。

ということで私はその人が大事に育てたハンドルネームで書いた記事が、現実世界のしがらみとは関係なく、さらに刹那的な感情をぶちまけるということもなく、一番その人の人格が現れると考えている。

固定の読者を意識しすぎない

ブログを書いていると固定の読者が付くことがある。いつも読んでもらえるのはありがたいし、それが心理的報酬になって書き続けるということもあるんだけど、そこに依存してしまうと結局プレッシャーになる。

だから私は基本的に「将来の自分」を主要なターゲットに据えつつ、「検索流入の一見客」におすそ分けするつもりで書いている。
要するにブログは基本的に自分用の勉強メモとして使っている。

面白いことがあったらそれを記録に残しておきたい。だから文書に書く。
でもどうせ書くならおすそ分け。だからネットに書く。減るもんじゃないし。それだけ。

誰しも人生で1度くらい、これはぜひメモに残して置きたいっていう出来事はあるだろう。
だったらその1記事だけブログに書いてみては。別にそれで放置したって良いけど、1度といわず2度目が訪れる。
そんなときに思い出せば良い。あ、そういやブログあったなと。

コメント欄オフ

これは人によると思う。
ブログを読んで共感いただいた方から励ましのコメントをいただくのがとても嬉しいというのは分かるので、別に現状困ってなければ特に変えなくても良い。でも私はチキンハートなので、あらかじめ批判が付かないようにコメント欄はオフにしている。そんなことで記事を書くのが億劫になるなんて、とてももったいないからだ。

まぁ、間違った情報をまき散らしてしまったときに訂正依頼の手段がないのは困りものだけど、命に係わるような間違いはしないように重々気を付けるし、些細なことで批判にさらされるリスクは取れない。

この批判によって意気消沈するリスクを注意深く避けつづけたからこそ、これまでに何百と記事を書くことができた。
結果的にそれらの記事が本当に必要とする方に届き、人助けになったのではないかと思う。

誰でも書けるコメントは諸刃の剣だ。承認製にしても良いけど、心無いコメントを万が一目にしてしまったらと思うと最初からオフが無難と考えた。

書きなぐる

人様にお見せするのだから綺麗に書こう、丁寧に書こうと思いがちだけど、あんまり気にしなくて良いと思う。
ですます調が整ってなくても、なんなら文法がめちゃくちゃでも別にそれは犯罪ではない。たかだかメモの延長に過ぎないのだ。

ネットの海をさまよいつづけて数年、ようやく求めていた情報が記事として現れるということがよくある。
このとき、言葉足らずでめちゃくちゃ分かりづらい解説だったとしても「よくぞ書いてくださいました!」という気持ちでいっぱいになるだろう。
だって、それは今まで無かったものだから。

ぜひ共有したい素晴らしい知見があっても、綺麗に書く自信がないから記事にしないという方も沢山いると思う。なんて勿体ないことだろうか。
世に出してしまえばだれかが拾ってくれることもある。そしてより分かりやすい形で広めてくれたりする。
だから、とりあえず自分しか持ってない情報は、出してしまえば良い。

文章の上手い、下手なんて気にしなくて良い。冗長でも、言葉足らずでも良い。
人生は十人十色。自分しか書けない話は、共有されること自体に価値がある。

ネタ被りを気にしない

他人の文章をパクってコピペしてくるのはダメだ。
でも同じネタを違う切り口で、あるいはもっと分かりやすく書くのはアリだ。
ブログなんて所詮自分用のメモ。書きたいと思ったそのテーマが他の人と被ってるからといって諦める必要はない。

最近、微分についての解説を読み漁っているんだけど、似たような解説がどれだけあっても困らないし、むしろ微妙な切り口の違いで物事を立体的にとらえられるので助かっている。

もし皆が「微分なんて今更いくらでも解説あるし、俺が書いたところで」なんて考えていたら今ある分かりやすい説明の大半は生まれていなかっただろう。

だから、ありふれて語り尽くされたテーマだとしても、書きたいと思ったら書けば良いと思う。

コンテンツに専念する

ブログサービスを使う

WordPressを使いたいという方は多い。こんな記事なんて読まなくてもブログを継続する自信がある方は良いと思う。
あくまで私の場合であるが、恐らくWordPressを使っていたらそれは継続的にメンテナンスが必要なものになってしまい、書きたいときに気軽に書けるというコンセプトが崩れてしまっていただろうと思う。
私の場合はWebデザインがしたいという欲求と、書きたい記事があるという欲求を棲み分けたことで気負うことなくブログを続けられている。
コンテンツ作成に専念するために、余計なセットアップやメンテはしないと決めた。

技術記事を書くのであれば、プログラムのソースコードを簡単にハイライトできるはてなブログがおススメ。

デザインに凝らない

ブログサービスが用意する標準テンプレートの中から気に入ったものを使う。それだけ。
自分カラーを出したい人は凝っても良いけど、コンテンツ作成に専念するためにWordPressではなくブログサービスを選択したのでデザインも凝らないことにした。

タイトルに凝らない

ネットで本名をもじったthomを名乗り始めた頃、はてなでthomアカウントが取れなかったのでt-homとした。
そんではてなブログ作成時に初期設定で表示された「t-hom's diary」をそのまま採用。これもコンテンツ作成に専念するという方針によるものである。
※URLだけは短く覚えやすいのが良いという方針で少し慎重に選択した。後で変えるの大変なので。

何にしようか一瞬考えたんだけど、さっさと記事を書きたかったので後で変えればいいやと思っていたけど、VBA記事を書いていたらこのブログタイトルで評判が付いてきたので、このまま固定した。

まとめ

ブログは書きたいときに書ける場所。継続することに拘らず、何か気づきがあったタイミングで、適当にメモ代わりに使っていけば、それは傍から見ると継続しているように見える。

気負わずに、時々思い出したタイミングで好きに書いてみると良いかと思う。

何年も書いてない方も大丈夫。あなたはやめていない。いつでも書ける。

もう消してしまった方・作ったことが無い方も大丈夫。書く場所は無料で、5分あれば作れる。
初めてブログを作るときのアドバイスとしては、タイトルやデザインに拘らないこととWordPressではなくてブログサービスを使うことをおススメする。なぜなら、それらに拘る時点で「気負っている」ということだから。
そういうのは、あとから何とでもできる。

どうせ作られたばかりのブログ記事なんて誰も読まない。
これは悪い意味ではない。だから自由に書けば良いし、気負う必要もないということ。

それでも、書いた記事は何年もかけてたった一人、本当にその記事を必要とする人に届くことがある。
これって素敵なことでは?それで十分なのでは?だから私は、ネットに書く。

以上。

当ブログは、amazon.co.jpを宣伝しリンクすることによってサイトが紹介料を獲得できる手段を提供することを目的に設定されたアフィリエイト宣伝プログラムである、 Amazonアソシエイト・プログラムの参加者です。