UbuntuにLubuntuを上書きする

Ubuntuだといまいち操作感が重かったので、
軽量版のLubuntuに入れ直すことにしました。

しかしなかなかインストールが進まない…
どうやらインストールが何かの原因で停止してしまったようです。

う～ん、
HDDの容量も、ネットワークの状態もOKと出ているのですが…

ハードウェア的な原因と予想しましたが、
少なくとも自分の調査では各種オールグリーン…

似たような現象がないか調べたところ、
ここが一番近いと判断しました。

アンマウントでは結局うまくいきませんでしたが、
インストールの序盤でHDDのフォーマットを行うことで突破成功。

どうやらインストール済みのUbuntuが何か邪魔していたようです。

でも何が？

謎は深まりますが、
もう疲れたので調査はおしまいです。

これからインストールしないといけないものが大量にありますしね。

黒歴史の魔導書

HDDの中身を軽く確認していたら、
昔のゲームや小説のネタをまとめたテキストを発掘しました。

いやぁ、これは他人に見せられない！

どこぞのラノベに数十ページに渡って解説されている何かの如く！

走り書きの設定資料だというのに、
38KBもある…だと？

まあ今まで書いた小説を合計すると、
1MBを超えちゃうから今更なんですが…

本当に執筆が好きな人は、
これの何百倍、何千倍も書いているんでしょう。

…ぺらぺら

ああ！
読めば読むほど厨二心をくすぐられるフレーズのオンパレード！！

何だよ「精神量子学」って！

これは、
これは供養してやらねばっ！

Pixivとかもあることですし、
暇をみて本当の作品にすべきですかねぇ？

作品にすればもう少し痛さも軽減され…

あ、いや、でも、
先に【マドルチェ】の妄想二次ストーリーとかも書いてみたい！

まったく、ネタってのはどうしてこう積み重ねる一方なんでしょう…

消化！早く消化して綺麗にしないと！

メタファーの超危険

前回　＜

いつかの記事で、
メタファーには*厳密には*違う部分があって、
その違う部分が重要になることがあるという話をしました。

しかし最近、
別の角度からメタファーの危険に気づいたのでご紹介いたします。



専門外の人と議論するときのお話です。

まずは前提となる知識として、
難しい部分をメタファーで説明したとします。
(ソースコードが汚い＝部屋が汚い、とか)

そして、メタファーを使ってあーだこーだと議論しあいます。
(ほっとくと部屋はどんどん汚くなっていくでしょ？とか)

議論が白熱してくるとふと気がつくんです。

メタファーについて議論しているうちに、
本題の方から完全に逸れているってことにです。

議論そのものはメタファーを使っているんですが、
本題とメタファーが違っている部分にも波及していってしまい、
どんどんおかしな方向に進んでしまうんです。
(窓のふちの汚れは何に該当するんだろう？とか)

メタファーが有効に働いたのは、
説明の段階までだったのです。



誰かに教えるという意味では優秀であっても、
議論まで発展させるにはやはり本質を理解している必要があるみたいです。


フローチャートが説明などの限定的な用途でのみ有効であると言われるように、
メタファーもまたそうなのではないでしょうか？

メタファーが有効な範囲もまた、
とても限定的なのです。



議論がよく迷宮入りする方でメタファーを多用される方は、
一度メタファーを使うのをやめてみてください。

それでも上手くいかない場合は、
あなたの表現力が悪いのか、
もしくは議論を始める前提条件が整ってないのかもしれません。


メタファーは理解を助けますが、
より深い理解の妨げにもなるのではないでしょうか？


前回　＜

USBメモリからLinuxをインストールする

よくブログで備忘録的な記事を見て、
「ね～よwww」と思っていました。

そんな自分が備忘録的な記事を書くなんて…
くやしい！でも…ビクンビクンッ！

茶番はさておき、
内容はUSBメモリを使ってLinuxをインストールする方法についてです。

ノートパソコンのような、
CD/DVD ROMが無いような環境ではお手軽なのでオススメです。

元ネタはこちらです。
「USBメモリを使ってUbuntuをインストール No.1」

内容をまとめるとこんな感じです。

1. インストールしたいディストリビューションのISOイメージを手に入れる
   
2. UNetbootinを手に入れる
   
3. 準備用のパソコン(これはWindows環境)にUSBメモリを挿す
   
4. UNetbootinでISOイメージをUSBメモリに突っ込む
   
5. インストールしたいパソコンにUSBメモリを挿す
   
6. BIOSでUSBメモリからブートするように設定する
   BIOSごとの差異は気合で何とかする
   
7. インストールが、始まる…！

これで使い余しているノートパソコンを、

片っ端から再利用ですよ。

タバコは嫌いだけど、タバコ吸う人を止める気はない

うわ、自分の2月の投稿少なすぎ…！



…ってなことは置いておいて、
今日の話題はタバコについてです。

個人的ににはタバコは大嫌いです。
憎しみすら抱いています。

副流煙がわずかでもあれば調子が悪くなります。

飲み会で副流煙をたくさん吸ってしまった場合、
終わった後は店の外でものすごい咳き込んでいます。



しかしそれでも、
個人の私情を捨てて人類全体で見れば、
タバコについては賛成なのです。

タバコ税が上がってタバコを吸う人が減れば確かに嬉しいですが、
嗜好品にしては明らかに高すぎまず。

ミクロ経済学では公害などを税で抑制するようなパターンが紹介されていますが、
タバコはそれに当てはめてもそこまで高くはならないでしょう。

まあとくかく不平等さを感じます。



あ、いえ、それが言いたいんじゃなかったんでした。

タバコ税じゃなくタバコそのものについて言いたいんでした。

タバコは健康を害して寿命を縮めるというのが今の定説です。

つまりタバコを吸う人は、
自分の寿命を縮めるリスクを背負って吸っているだけなのです。

ただの自己責任でしかありません。

分煙や吸殻の始末さえしっかりしてもらえれば、
こちらに文句はありません。

むしろ人類全体の平均寿命を縮めてくれていることには感謝すべきです。

道義に反さず短命になっていただいているんです。

現在の食糧事情を考えてみてください。

人類全体が長生きしてしまっては、
あっという間に世界規模の大飢饉が待っています。

それを影で食い止めているとも言えなくはないのではないですか？

そうタバコとは、
増えすぎた人類に対してのアポトーシスとして機能しているんじゃないでしょうか？



…という仮説。

魚肉と茄子のピリ辛味噌炒め

難しい話を書く集中力がないので、
また料理の記事になります。

ピリ辛の炒め物って、
大抵のものは美味しい気がするのは何故でしょう？

ちなみに写真のは4食分あるので、
かなりの量は冷蔵庫で保存です。

スーパーで野菜を買うと袋で買うことが多いから、
どうしても一度に作る量が多くなってしまいます。

茄子3個分ですから…

ピーマンの肉詰め

久しぶりに料理をしました。

と言っても体は覚えてくれているようで、
野菜のカットは危なげなく終了。

忘れているのは火加減全般。
どれだけ焼けばいいのかさっぱりです。

生焼けは危険なので、
軽くフライパンに水を引いて、
蒸すみたいな工程を加えました。

…うーん、
肉汁が出てしまうのが欠点です。

やはり焦げ目で肉汁を封じ込めたほうがいいと思います。

でも出来上がりはそこそこでした。

玉ねぎがやたら多いのは仕様です。

誰にでも読みやすいソースコードは存在しない

仕事でJavaで書いたソースコードを引き継いでもらうことになりました。

Javadocもまあそれなりに書いていますし、
きわどいところにはそれなりにコメントも入れています。

全てのメソッドは長くても50行かそこらですし、
クラスだって長くて300行かそこらです。

というか、
長いクラスはみんなJavaBeansです。

サイクロマチック数だって一桁をキープしています。

うんうん、
これなら読みやすいに違いありません。

あ、次の担当者の方を見つけました。
ちょっと読んでもらいましょう。

あれ？
何か顔が青ざめているような…




はいストップ！

今回の話題はこれです。

ずばり“読みやすいソースコード”とは何かについてです。

でもこれが読みやすいソースコードだとか主張する気はありません。

十人十色とはよく言ったもので、
読みやすいソースコードも十人十色だと言いたいからです。

ポイントと思われるのは、
よく言われる「凝ったテクニックの実装は読みにくい」という部分です。

確かにその通りという部分は大きいです。
IOCCC大好きな自分にとっては身近なことです。

でも*凝った*といわれるテクニックってどこからなんでしょう？


とりあえず具体例を、
どっちが読みやすいですか？

パターンA

hoge(1);
hoge(2);
hoge(5);
hoge(11);
hoge(14);
hoge(20);
hoge(21);
hoge(77);
hoge(100);

パターンB

int[] parameters = {1, 2, 5, 11, 14, 20, 21, 77, 100};
for (int parameter : parameters) {
    hoge(parameter);
}

全員がBを選ぶと信じたいところですが、
Aの方が良いという方がそれなりにいるようなのです。

だいたいこういう方は、
新たに関数を作るだけでアレルギー反応が出ます。

そりゃ4桁や5桁の行数にもなる関数を平気で作るわけです。
彼らにとってはその方が*読みやすい*んですから。

この例はかなりアンダーを攻めたものですけど、
色んな所で読みやすさのラインが登場します。

有名どころは以下でしょうか。
・構造化定理
・オブジェクト指向
・命名規則
・正規表現
・再帰関数
・関数型言語(っぽいこと)
※別に難易度順とかじゃありません。どっちかというとカテゴリー？

全てのプログラマーは、
この何次元にも展開された無数に渡るラインのどこかに立っています。

そして自分のいるラインに近い場所が読みやすいソースコードなわけです。
遠ければ遠いほど読みやすいにくいソースコードなわけです。

あまりに位置が遠いプログラマー同士が、
一緒に仕事をしたときに不幸が起こるのではないでしょうか。

あなたがもしも、
「読みやすいソースコードを書こう。」言ったことがあるのであれば、
それはどこの人達にとってですか？

汚いソースコードにも種類がある

久方振りの更新…
まずは誰かの記事の引用で手軽に書くとします。

というわけで、
GoTheDistanceより「コードで周りを動かせるエンジニアになろう」です。

でこの記事についてですが、
まさにその通りです。

特に反論もありません。
いやぁ、いい記事ですね！

はいおしまい、
帰った帰った…というわけにはいきません。

一応、釘を刺す的な意味で補足ができたらな～と思います。

主にあちらを読んで、
「汚いコードでもいいんだ！どんどん書いて動かしていこう！」
と脊髄反射している方に対してです。

何が言いたいかというと、
汚いコードにも二種類あるということです。

綺麗に書ける人が書く汚いコードと、
汚くしか書けない人が書く汚いコードです。

ここには超えられない壁が見えるくらいの違いがあります。
(と妄想しています。)

なんて言ったらいいのか…
汚くする仕方がまるで違うのです。

汚い部分をいざ掃除しようとなったとき、
ゴミをまとめてほうきで掃けばそのうち綺麗になる一人暮らしの部屋と、
放射線を撒き散らして対処に困り続ける核廃棄物のような違いです。

で、元々の意味での技術的負債に溺れて失速…
最高速度に達する前に減衰するかの如くです。

なので汚く*しか*ソースコードが書けない人は、
そこら辺は気に留めてみてくださいねというお話でした。

でないとそのスタートアップは殺されます。

靴の整理

ダメになった靴を捨てないでいたら、
下駄箱がいっぱいになっていました。

初買いの靴が入らないので、
靴を一気に捨てることに。

結構あるのは分かっていましたが、
まさかビニール袋いっぱいになるほどとは思いませんでした。

ゴミ収集の方へ、
ごめんなさい。