エラーコードをググってたら3日経っていた

*URL名はちょっと前までよくやっていたファイル名の付け方を現したものです(実話)。素人が一生懸命スパコンやWSL等と戦った時の記録。エラーコードをググってもよくわからない世界がそこにはあるのです。

seabornでset_theme() を使っても結局ヒートマップの枠線が消された悲しさを強引に解決(plt.imshow() 不使用)※強引じゃないバージョンもあるよ

ヒートマップをseabornで書きたかった(plt.imshow()で細かい設定するのがめんどくさそうで逃げた)

色々事情があってオーバードクターになり、必死に投稿論文を書いています(何年やってるんだ…?)。

それ故Figを作成しなくてはいけないのですが、データ量が多かったりVBAがさっぱり分からなかったり(昔パワポ用のマクロ作ったことありますが物凄く悪戦苦闘した思い出しかない)といった事情のため、基本的にJupyterLab上でmatplotlib、seabornを使ってFigを作成しています*1

ヒートマップはplt.imshow() を利用するパターン(Creating annotated heatmaps — Matplotlib 3.5.3 documentation)ではなく、seabornにてを描画していたんですが、どうしてもseabornの性質上「いい感じにしてくれる」せいで枠線消えちゃうんですよね、デフォルトだと。枠を付けたいならplt.imshow() で書けよって話なんですが、個人的に設定したい部分を手軽に弄るのにはseabornを使いたかったので(見出しにもありますがimshow()から逃亡)、なるべく少ないコードで枠を付けたかったんですが、結構格闘しました。以下、超初心者の格闘記録をば。ここに行きつくまで何時間使ったんだろうこの人は*2。もしかしてplt.imshow() でのヒートマップ描画(自分用パラメーターのセットも含む)を習得した方が早かったのでは説もあるけど考えないことにします。

set_theme() をも超えていくヒートマップ枠線問題

(ほぼ)デフォルト設定にて描画

とりあえず、一旦sns.reset_defaults()にてrcParamsをデフォルトに戻した状態でヒートマップを描画してみます…って嘘つきました。カラーマップだけBluesにしています(データはseaborn.heatmap — seaborn 0.12.0 documentationにある方法で生成)。

比較としてデータが空のAxes (title = Axes 2)を右に並べました。カラーバー含めて2つのAxesがなんとなく揃っている感を出すために、plt.subplots()の引数にsharey=Trueを入れたり、ax2.set_aspect('auto', share=True)とか無茶やっているのでheatmapのsquare=Trueが効かない状態です。という事で良い子はうかつにマネしないでください(僕はいつもカラーマップを別なAxesでプロットしているのですが、今回は横着してやってないです…w)。

from __future__ import print_function 
%matplotlib inline
import jupyter_console
from matplotlib import pyplot as plt
import numpy as np; np.random.seed(0)
import warnings
warnings.filterwarnings("ignore", category=DeprecationWarning) 
import ipykernel
import pandas as pd
import seaborn as sns
fig, (ax1, ax2) = plt.subplots(figsize=(8,3), ncols=2, sharey=True)

uniform_data = np.random.rand(10, 12)

ax1 = sns.heatmap(uniform_data, cmap='Blues', ax=ax1, 
                  square=True,
                  cbar=True,  
                 )
ax1.set_yticklabels(labels=ax1.get_yticklabels(), rotation=0)
ax1.set_title("Axes 1 (sns.heatmap() )")

ax2.set_aspect('auto', share=True)
ax2.set_title("Axes 2 (only matplotlib)")

plt.tight_layout()
plt.show()

Axes 2はmatplotlib単体でプロットされているため、現在のrcParamsがそのまま適用されることで枠線などが出てきます。一方、sns.heatmap()を用いたAxes 1では枠線が消えています。seabornが「いい感じにしてくれた」事でrcParamsの設定が上書きされてheatmap用の設定になっているみたいです。

(なるべく楽に)枠線を付けたい→ sns.set_theme()との出会い

さてここに枠線を付けたいときにどうすればいいか、とりあえずの理想は「デフォルトの設定を弄って何とかならないか?」という事だったのでドキュメントを見てそれっぽい関数が無いか探してみました。するとsns.set_theme()seaborn.set_theme — seaborn 0.12.0 documentation)を発見。リンク先をざっくり見た感じ、matplotlib単体でのプロットを含めたデフォルト設定を永続的に変更する(seabornのスタイルに手を加えることもできる)ものっぽい*3。確かにリンク中の

The seaborn theme is decomposed into several distinct sets of parameters that you can control independently:

という説明及びその直下にあるプロット例、そして最後にある

custom_params = {"axes.spines.right": False, "axes.spines.top": False}
sns.set_theme(style="ticks", rc=custom_params)
sns.barplot(x=["A", "B", "C"], y=[1, 3, 2])

というサンプルコードで枠線の制御をしているのを見るに「set_theme()を使えば枠線問題何とかなるんじゃね?」となったので試してみました。

いやなんで枠だけ付かねえんだよw(指定キーワードの問題?)

まあその、この記事を書いている時点でお察しなのですが、この試みは失敗に終わっていますw とりあえず先ほどのAxes 1Axes 2をアレンジした実例を...。

# ↓辞書記述の順番とか適当なのはご愛敬…。
rcstyle = {
    'axes.spines.right': True, 'axes.spines.left': True, 'axes.spines.top': True, 'axes.spines.bottom': True, # 上下左右の枠線追加
    'axes.linewidth': 1.5, 'axes.edgecolor': 'k', 
    'xtick.bottom': True, 'ytick.left': True, # 下と左に目盛線追加
    'axes.labelsize': 'medium', 'axes.titlesize': 'large', 
    'xtick.color': 'k', 'ytick.color': 'k', 'ytick.labelcolor': 'k'
            }

sns.set_theme(context='notebook',
              style='darkgrid', # 本来はspines(枠線), ticks(軸目盛線)なし
              rc=rcstyle, # これでspinesとticksが入るはず
             ) 

fig, (ax1, ax2) = plt.subplots(figsize=(8,3), ncols=2, sharey=True)

uniform_data = np.random.rand(10, 12)

ax1 = sns.heatmap(uniform_data, cmap='Blues', ax=ax1, 
                  square=True,
                  cbar=True,  
                 )
ax1.set_yticklabels(labels=ax1.get_yticklabels(), rotation=0)
ax1.set_title("Axes 1 (sns.heatmap() )")

ax2.set_aspect('auto', share=True)
ax2.set_title("Axes 2 (only matplotlib)")

plt.tight_layout()
plt.show()

Axes 1 (heatmap)さん? いや何が違うんですか?一応タイトルのフォントサイズでかくするのが反映されているような気がするくらいですかね。Axes 2が狙い通りの設定で、プロットエリアはseabornの'darkgrid'スタイルを保ちつつ、darkgridに本来ない枠線と軸目盛線が入っています。 「もしかしてseabornのheatmap描画時は軸周りのrcParamsが反映されないのか?」と思い、 'xtick.bottom': True'ytick.left': Trueのところをコメントアウトして軸目盛線を無効化すると

いやそれは反映されるのかよ!そういや後述の方法で軸線を付けた時、線の色はrcParamsベースの設定が反映されていたなあと思い出しました。ちなみにヒートマップのカラーバーを消しても変化なし。

たかがプロット、されどプロット。「matplotlibとseaborn分かんねえなやっぱり(個人的にExcelとかよりはやりやすいけど)」と思いつつも試行錯誤した結果2つの結論に行きつきました。

暫定的和解策

1. sns.despine()の目的外利用(?)

注: 普通は絶対2の方がいいですw 発見した順から正直に記載している都合でこっちを1番目にしています。

懲りずにseabornのドキュメントを読んでいたらどういうわけか見つけてしまった物体。それが、sns.despine()です。 seaborn.despine — seaborn 0.12.0 documentation内の

Remove the top and right spines from plot(s).

という記述にもある通り、基本的には上と右の枠線を消すために存在しているメソッドです。が、オプションで上下左右の軸線をどうするか指定できるので、それを利用して逆に軸線を付加することもできます。

# 前略
ax1 = sns.heatmap(uniform_data, cmap='Blues', ax=ax1, 
                  square=True,
                  cbar=True,  
                 )
ax1.set_yticklabels(labels=ax1.get_yticklabels(), rotation=0)
ax1.set_xticklabels(labels=ax1.get_xticklabels(), rotation=0)
# これ↓
sns.despine(ax=ax1, right=False, top=False, left=False, bottom=False)

ax1.set_title("Axes 1 (sns.heatmap() )")

# 後略

我ながら酷いやり方ですが、一応ワンライナーで書けるし枠線付いたんでヨシ!2番目の正当な使い方を学習したので、多分もう使いませんが。

2. spines[''].set_visible(True)リストで記述 (['']内にはleftなどが入る)

多分一番シンプルなのがこれですね。 実をいうと前々から軸線の追加にあたり、spines['left'].set_visible(True)などは使っていたんですが、今回何があれでここに書いているかというと…。実は僕、今までこれをリストで記述可能と知らず、left, right, top, bottomそれぞれに関して4行で書いていたんですよ。いやあもうその…。とりあえず、なぜこれを知らなかったと凹み半分、これで楽になるなと喜び半分でドキュメントのサンプルコードを載せます。(以下2つともmatplotlib.spines — Matplotlib 3.5.3 documentationより)

  • 通常のリスト形式
spines[['top', 'right']].set_visible(False)
  • そして、リストで行けるということは…スライスで全指定も…。はい…。
spines[:].set_visible(False)

ということで、スライス全指定が一番平和そうですね。今回のケースに適用してみます。

# 前略
ax1 = sns.heatmap(uniform_data, cmap='Blues', ax=ax1, 
                  square=True,
                  cbar=True,  
                 )
ax1.set_yticklabels(labels=ax1.get_yticklabels(), rotation=0)
ax1.set_xticklabels(labels=ax1.get_xticklabels(), rotation=0)

# スライスで全指定
ax1.spines[:].set_visible(True)
ax1.set_title("Axes 1 (sns.heatmap() )")

# 後略

こちらもsns.despine()の無茶苦茶な使い方をした1と同様しっかりと枠が付きました。

なお、カラーバーに枠線が付かないですが、subplotで別なAxesにカラーバーをプロットして、同様のことをすれば付くかと思います(今回は作業時間等の都合上やってないですが)

JupyterLabのShow Contextural Helpspinesのところクリックしてようやく気が付くという。もっとpythonの勉強をしようと思います。…ん?あれ?あ、もちろん論文書きます。論文優先です。論文。いやでも、Fig作成がこれで捗るようになったので(そのためにかかった時間は、サンクコスト…って扱うには掛かりすぎたな)。

ちなみに上記サンプルコード等が載っているページの大元(matplotlib.spines — Matplotlib 3.5.3 documentation)を見ていたら、matplotlib.spines.Spineクラスのところにはpatchがどうこうと書いてあったのですが、rcParams周りの設定で'patch.edgecolor': 'black''patch.force_edgecolor': Trueを設定しても結局ヒートマップに枠線付けられなかったんですよね。ただ、今回設定したのはmatplotlib.spines.Spinesクラス(SpineではなくSpines)で、そっちはcollections.abc.MutableMapping関連のようなのでpatchは意味がなかったんでしょう、おそらく。そこら辺を弄ればデフォルトでseabornのheatmapにも枠線がつけられるのかもですが、さすがにこれ以上深追いする気力と時間は無いですね…。今のところ、ワンライナーで書ければもう充分ですw 論文が落ち着いたら検証したいところですがいつ落ち着くのか。

自分への教訓

  • rcParamsaxes.spineが無に帰したせいで、seaborn経由の原因かと思いひたすらseabornのドキュメントを中心に調べていたけど、基本はやっぱりmatplotlibのドキュメントをちゃんと読みましょう。そうしていたら絶対sns.despine()よりもspines[:].set_visible(True)を発見していたはずw

  • matplotlibとseabornについて理解がちょっと深まった(初歩的な部分で)のと、これでプロットがヒートマップ以外も含めスムーズになるのは確かだけど、変なところにこだわって調べ物するのは(今はまだ)程々にしろ…。試行錯誤の過程だった調べ物で、解決してから「回り道だったな」と判明したもの以外にも、明らかに拘りすぎて今調べなくていいよねそれっていうのが多々存在したので。論文。論文優先だから君(ちなみにこのブログも論文の気晴らしにちゃちゃっと書くつもりが思ったより時間かかってしまったのでやっぱり僕はだめですねこういうところ)。

先生ごめんなさい、可及的速やかに草稿を...。

*1:ウチの研究室でグラフをExcel以外で書いている人はみんなRです、肩身が…w

*2:取り急ぎ論文用にさっさとコード量問わないもの組めって話、というかそっちはもう組んであるんですよね。コードがごちゃごちゃしていて変えたかっただけでこんなことを…w こんなんだから論文がいつまでも仕上がらない。

*3:set_style()とか暫定的なスタイル変更系のもありましたがヒートマップ用の.ipynbファイル用なら永続的変更をしたかった

UGE利用マシンにぶん投げた大量のジョブ情報の中から欲しいところだけ一括表示(TSUBAMEやその他UGE利用計算機向け)

TSUBAMEみたいな、UGE*1*2でジョブ管理している計算機に大量のジョブを投げたは良いものの、qstatで一覧を見てもどれがどの計算だかわかんねえやこれってなる人いますか?私のことです。いやジョブ名なりスクリプト名なり変えろよって話なのかもしれないですけど(みんなどうやっているんだろう)。
自分の場合、分子動力学とかをやっているのだが、条件が違うだけでやっている計算は同じという事も多い。それ故ジョブスクリプト名は使いまわしで、ディレクトリを変えてジョブを投げるタイプ。ジョブ名を付けていたこともあるがそれはそれで面倒。というかファイル名を変えるとえらいことになるタイプなので…。メールオプションも開始時は一気に投げるとき逆に大変なことになるから付けていない。終了時の通知くらいはつけようかと思っているけど。

という事で投下中のジョブ一覧をみられるスクリプトを組んでみた。ちょっと最近大量の計算を投げて頭がぐっちゃぐちゃになっていたのだがこれでだいぶ楽になった。スクリプト組むのはまだ全然慣れていないのでちょっと試行錯誤があったけど。

こんな感じ。getjob.shという名前で保存している。

#! /bin/sh

## get job_ids with qstat
currentjob=`qstat | awk '{print $1}' | sed '/job-ID/d' | sed '/-/d'`
# echo "$currentjob"
NR=`echo "$currentjob" | awk 'END{print NR}'`

echo number of jobs: $NR


## details of each job
for i in `seq 1 $NR`
do

# echo ${i}

## get each job information
JOBi=`echo "$currentjob" | sed -n ''${i}' p'`
# JOBi=`qstat | awk '{print $1}' | sed '/job-ID/d' | sed '/-/d' | sed -n -e ${i}p`

## display each job information
echo job_number: $JOBi
qstat -j $JOBi | grep -e cwd -e job_name -e job_state -e start_time
echo ""

done

コメント部分だが、自分の場合「いらねえなこれ」ってなった部分や一時的にオフにしているところは#1つ、普通に説明とかのコメントは#を2つつけるようにしている。適当な英語はご愛嬌。

実際に動かすとこんな感じで標準出力に出てくる。##のコメントは追記。

number of jobs: 10
job_number: xxxxxx ## 実際はジョブID
cwd:                        /hoge/hogehoge/hogehoge_hoge ## 投入したディレクトリ
job_name:                   hoge.sh ## 投入したジョブ名
start_time            1:    10/08/2021 12:50:36.105
job_state             1:    r

job_number: yyyyyyy ## 実際にはジョブID
cwd:                        /hoge/hogehoge/hogehoge_hoge/foo/bar ## 投入したディレクトリ
job_name:                   hoge_hoge_hoge.sh ## 投入したジョブ名
start_time            1:    10/08/2021 17:37:44.980
job_state             1:    r
## 以下省略(あと8個はさすがに長い)

自分の場合ジョブID、スタート時間、ディレクトリとスクリプト名をとりたかったのでこんな感じで組んでいる。前述の通りメールオプションの終了通知と合わせるともっと便利なのかもしれない。

TSUBAME3.0に入っているAlphaFoldをようやく試した(計算中...)

前置き

タンパク構造予測ツールとしてぶっちぎりの精度を誇るAlphaFold2(AF2)。7月中旬、論文がリリース。

doi.org

同時にソースの公開も。タンパク質界隈では凄い祭りになっていた。梅雨時でくたばっていたので、祭りは観測するだけになってしまったのが悔やまれる…。

github.com

さて、そんなAF2だがTSUBAME3.0にも2か月前には入っていた(Alphafold2 公開のお知らせ | TSUBAME計算サービス)。ただ、ずっとGoogle colab版(ColabFold)で遊んでいてさっぱり使っていなかった。ColabFoldはこれ。

github.com

とあるタンパクの予測をしていたのだが、colab版でも結構それっぽい構造は出してきた。個人的には、disorder領域を無理やり巻かないで潔く伸ばしてくるところに感心。今まで使っていた他のツールだと、その領域を無理やりたたんできたのでとんでもない絵面になっていたので。

ただ、colab版はさすがに参照するデータベースが簡易版になっている(bfdがsmall_bfdになっている)。

  • How does this compare to the open-source version of AlphaFold?
    • This Colab version of AlphaFold searches a selected portion of the BFD dataset and currently doesn’t use templates, so its accuracy is reduced in comparison to the full version of AlphaFold that is described in the AlphaFold paper and Github repo (the full version is available via the inference script).

引用元: https://colab.research.google.com/github/deepmind/alphafold/blob/main/notebooks/AlphaFold.ipynb

これをフルスペックにして計算したかったのでようやくTSUBAMEで計算することにした。

TSUBAMEでジョブ投入

TSUBAMEに入っているAF2はnon-docker版が大元っぽい。

github.com

TSUBAMEに投下するジョブスクリプトの例はここにある。

helpdesk.t3.gsic.titech.ac.jp

やらかした点など

  • -aの値はデフォルトだとallになっているからと思って省いたらGPUねえぞって怒られた。今になってみれば、-gを指定していて-aが無かったらそら怒られるわなと。番号を指定しなくていいだけで-a自体は付けないといけない(-gがデフォルトでTrueなのに付けているのと同じだと後から気づいた。いまだにこういうところで引っかかるレベルには素人)。
    • -aで指定する番号は多分ノードのgpu数に合わせて0から連番でつければいいんだと思う(多分。この辺もよくわかっていない)上のジョブスクリプト例だとf_nodeだからgpu4つあるので-a 0,1,2,3
  • モデルのファイル名をオリジナルでつけようとしたら怒られた。model_nじゃないとダメっぽい(1つなら-m model_1、2つ出したいなら-m model_1,model_2)。まあディレクトリ指定するからそこでなんの構造かは判別しろって事ですね。スクリプトを弄ればデフォルトのモデル名は変えられると思うけど結局変えていない。

  • ジョブ投げると標準出力じゃなくてエラー出力ファイルの中身がたまっていくが、ジョブが落ちていない限り心配ない。ジョブ投げた後もターミナル開いていると、確かに物騒な出力が出てくるのでドキッとするが、よく見るとWarningとかに交じって下のようただの進捗が出ている。

I1002 10:17:11.375301 46912496428352 utils.py:36] Started HHsearch query
I1002 10:21:18.952636 46912496428352 utils.py:40] Finished HHsearch query in 247.577 seconds

ということで形式上標準エラー出力扱いになっているために全部エラーログに入るっぽい。まだジョブが終わっていないけど、今のところは全部エラーログにぶち込まれている。

以上、まだ計算途中だけどやらかしなどの記録として取り急ぎ。

lessでのシンタックスハイライトを、lesspipeだけ?で実現できた (TSUBAME3.0)

概要だけ取り急ぎ。

なんか訳の分からないままにあれこれ試していたらできた。理由は不明。関連ツールのインストールも含めたら2日くらい費やしたような…。いいから論文書け。

概要

以下をやったらlessシンタックスハイライトが効いた。ただ、正攻法よりは不完全な気がする (まだ手元(WSL2 openSUSE-Leap-15.2) に導入しているsource-highlightと比べていないので詳細不明)。

TSUBAME3.0にて

  • Homebrewでlesspipeをインストール
  • ~/.bashrc
LESSOPEN="|~/homebrew/Cellar/lesspipe/1.89/bin/lesspipe.sh %s"

と書き加えてsource ~/.bashrcか再ログインのいずれか。 これで lessコマンドを使えばシンタックスハイライトができる(デフォルトだとちょっと不完全な気がするが)。てっきりsource-highlightも必須だと思っていたので驚いた。

以下はhomebrew/Library/Homebrew/brew.shについて、less brew.shを行った際のスクリーンショットである(lessのオプションに-NMRを付けているが、Mが効いていないっぽい)。 f:id:notadsl:20210913010832p:plain

1行目に==> append : to filename to switch off syntax highlightingが入っていることと、ところどころコメントアウト箇所が白くなっているのが正攻法(source-highlightを入れて実行する場合)との違いなのだろうか?

まあ、コメントアウトの件はご愛嬌。ずっとsouce-highlightがうまいこと導入できなくて苦労していたので、lesspipeだけである程度済むなら個人的には十分である。

ローカルなら、zypperなりapt-getなり使えば良いけど、rootが無いとこういう時に辛い。ビルドアレルギーなもんで。

以下、備忘録兼ねた記録を…と思ったがフルで書いていたらいつ公開できるかわからないので、とりあえず結論だけでもと思い公開。本ブログでは試行錯誤過程もなるべく示したいので、関連パッケージインストールも含めたドタバタ劇も書くつもりなのだが…。また後ほどという事で、今回はご容赦願いたい。

2021-9-13追記: オプションなど一部項目を追加

テーマ選定と、デザインCSSによるコードブロック周りのカスタム

はてなブログのテーマ選定

既にこのはてなidでは1つブログを持っているが、ジャンル分けのために本ブログを作ることにした。それにあたり、まずはテーマ選定。

このブログだとコードを書く場面がやたら多いと思うので、そのあたりの実装に重きを置いていそうなプログラマー向けのテーマを選ぶのも考えたが…。自分のキャラ的に、今どきのIT屋さん、特にフロントエンドの方々っぽいものは似合わないなと判断*1。一般向けの中から気に入ったものを探していたところ、こちらを発見した。Roughというテーマで、製作者はKDE (id:jinseirestart)さん。 blog.hatena.ne.jp

上記リンク中にある、

2カラムのシンプルなレスポンシブテーマです。Brutalist Web Design(ブルータリスト ウェブ デザイン) を取り入れて、あえて昔のWebサイトの雰囲気を出した無骨なデザインが特徴になっています。

という言葉通りのデザインに惹かれ導入。

デザインCSS欄を利用したコードブロック体裁カスタム

コードブロック等の表示がどうなるか下記のデモサイトで確認。 hatebu-theme-rought.hatenablog.com また、実際に自分のブログでプレビューをして挙動を確認した。基本的に一行が長くなると折り返すようになっているようだが、あまりに長いとHOGE=/hoge/hoge:$HOGE...のように、一定以降が省略されてしまう現象があった。 そこで、横スクロール式に変更を検討。

RoughのライセンスがCC-BY-ND 2.1だったので、「あれ?これいじっていいのかな」と思ったが、調べてみたところ、横スクロール化は、はてなブログの「デザインCSS」に追記するだけであり、元のCSSを変更するわけではないようだ*2

その他、僭越ながらコードブロックの背景色なども変更させていただいた。

最終的には、以下をデザインCSSに追記する形となった。

pre, code {
    max-height    : 500px;
    overflow      : scroll;
    white-space   : pre;
    text-overflow : clip;
}

.entry-content code {
    background-color: #b5cee2;
    color           : #333;
}

.entry-content pre.code {
    background-color: #0a2f4d;
    color           : default;    
}

pre, codeがコードブロックのスクロール部分。 参考にしたのはこちらのブログ。 www.taneyats.com

.entry-content code.entry-content pre.codeがそれぞれコードブロック、インラインコードの背景色等の変更部分だ。コードブロックの背景はPowerShellターミナルの背景色っぽくしてみたつもりである。 なお、カラーリング変更方法についても先人の知恵を参考にさせていただいた。 kuwamai.hatenablog.com

スクロールの挙動確認をしたところこんな感じ。無事横スクロールが出来ている。

--prefix=test $HOME=/home/User testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest 

インラインコードについては、本家だと黒背景に白文字という武骨でカッコいいものだったが、薄めの色に慣れていたのもあり(先ほどから何回か登場しているが)現状に至った。まだ暫定ではあるが…。ここに時間を割きすぎて記事がかけなかったら本末転倒である。

*1:同様の理由で、柳田悠岐の愛称っぽい名前のサービスも非登録。読む側としては大変お世話になっています。ただ、自分が記事を書く光景が想像できなかったので、当面はROM専継続予定。

*2:知財の講義を何回受けてもライセンス周りはややこしくて苦手である。例えばRough同様CC-BY-NDのテーマについて、元のCSS自体をカスタムし、自分のブログに用いることは再配布にあたるのだろうか?など。デザインCSS欄は、このあたり難しさを回避する意味合いもあるのだろうか