  |
はてなキーワード: 「J」とは
プログラミングはセンスです。センスの無い人がプログラマになると、他のすべての人に迷惑がかかります。だから、センスの無い人は絶対にプログラマにならないで下さい。
プログラミングのセンスが無い人や、プログラミングをやったことの無い人は、知識を得たり経験を積んだりすれば、誰でも「良いプログラマ」になれると思っているようですが、無理です。
というのも、センスの無いプログラマの問題は、知識や経験の不足ではないからです。センスの無いプログラマの救いようの無い問題は「頭がおかしいこと」なのです。
題材は何でもいいのですが、具体的なコードを見た方がイメージがつきやすいと思いますので、とりあえず以下の問題を考えます。
住民のリストが与えられるので、背の低い順に男女ペアにしたリストを作って下さい。ただし、男女の数は同数であるとします。
const makePair = (persons) => { const males = persons.filter(person => person.sex === MALE) const females = persons.filter(person => person.sex === FEMALE) const compareHeight = (a, b) => a.height - b.height males.sort(compareHeight) females.sort(compareHeight) return males.map((male, idx) => [male, females[idx]]) // 男女の数は同数 }
この例はJavaScriptなので高階関数を使っていますが、仮にそういう機能が無かったとしても、
一方、センスの無いゴミプログラマは、以下のような名状しがたきコードを書いてきます。
function pair(psns) {
var i = -1;
var cnt = 0;
var flg = psns[0] && psns[0].sex;
var j = -1;
var tmp = null;
for(i = 0; i < psns.length; i++) {
//console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
//console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
if(psns[i].sex == flg) {
//console.log('cnt: ' + cnt + '->' + (cnt+1));
cnt++;
} else {
j = i - cnt + 1;
//console.log('swap ' + i + '<-->' + j);
tmp = psns[j];
psns[j] = psns[i];
psns[i] = tmp;
i = j - 1; // <- 理由は分からないが、i = jだと上手くいかない（by XXXX）。
cnt = 0;
flg = flg == MALE ? FEMALE : MALE;
while(j > 1) {
if(psns[j].height < psns[j-2].height) {
//console.log('swap ' + j + '<-->' + (j-2));
tmp = psns[j-2];
psns[j-2] = psns[j];
psns[j] = tmp;
}
j -= 2;
}
}
//console.log(psns, 'i=' + i, 'cnt=' + cnt, 'flg=' + flg);
//console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
//console.log('')
}
for(i = 0; i < psns.length; i++) {
//console.log('■■■■■■■■■■■■■■■■■■■■ BEGIN ■■■■■■■■■■■■■■■■■■■■')
j = Math.floor(i / 2);
//console.log(psns, 'i=' + i, 'j=' + j);
tmp = psns[i];
if(!(i % 2)) {
psns[j] = [null, null];
}
if(tmp.sex == MALE) {
psns[j][0] = tmp;
psns[j][1] = psns[i+1];
} else {
psns[j][0] = psns[i+1];
psns[j][1] = tmp;
}
i++;
//console.log(psns, 'i=' + i, 'j=' + j);
//console.log('■■■■■■■■■■■■■■■■■■■■ END ■■■■■■■■■■■■■■■■■■■■')
}
psns.splice(psns.length / 2, psns.length);
}
こんなコードのメンテナンスは御免被りたいです。一見して配列の要素を入れ替えていることが分かるだけで、実装を全て読まなければ（いや読んでも）処理の意図が全く分かりません。また、たとえば「i = j - 1」が間違って「i = j」などと書かれていてバグを起こしたとしても、原因を突き止めるのは困難を極めます。
さて、このコードは具体的に何がいけないのでしょうか。長すぎることがいけないのしょうか。変数名が分かりにくいのがいけないのでしょうか。引数を破壊的に変更しているのがいけないのでしょうか。不要なコメントが残っているのがいけないのでしょうか。よく見ると、ソート処理で車輪の再発明をしていたり、「j」や「tmp」などが場所によって意味が違うカメレオン変数になっていたりしますが、それがいけないのでしょうか。どれも正しいですが、それらを逐一直したところで、本質的な解決にはならないでしょう。
後者のコードはもはや「ここを直したら良くなる」とかいうレベルを超えています。たしかに、問題を具体的に挙げることはできます。このコードの致命的な問題が、凝集度の低さと、単一責任の原則(SRP)違反にあるのは間違いありません。しかし、後者のコードを書いてくる人に、
「住民リストを男女に分ける処理や、リストをソートをする処理、2つのリストをまとめる処理は、この問題とは独立して意味のある操作だから、別の関数として抽出しましょう。その方がコードの見通しがよくなるし、一部の処理を修正したときの影響も小さくなるし、単体テストも書きやすくなります」
なんて言ったって聞く耳を持たないでしょう。
そもそも、こういうコードを書く人は、この処理自体を「pair」なんて関数に抽出すらしません。まだこの問題では入出力のフォーマットが明確に定義されているので、他人が1から書き直せますが、実際のプロダクトでは、無数の副作用を起こす数千行のコードの迷路を彼の脳内フォーマットのデータが通るわけです。もちろん、テストコードなんてありません。
つまり、指摘をしても絶対に直らないのです。いくら言語の優れた機能やベストプラクティスを紹介しても、馬の耳に念仏。それらの利点を理解できるだけの脳みそが足りていないのです。
どうして、同じ処理を実装するのに、ここまでの違いが生じるのでしょうか。
これは、プログラミングの技術の問題ではありません。既に述べた通り、ふつうの人なら、特定の機能の有無とか知識の程度にかかわらず、ふつうのコードを書くのです。なぜなら、ふつうの人にはそちらの方が楽だからです。つまり、前者のコードは別に何か卓越した技術を身につけた結果書けるようになるものではなく、まともな感覚さえ持っていれば、プログラミング初心者にとっても前者のコードの方が書きやすいのです。
つまり、後者のようなコードを書いてくる奴というのは、現実世界の捉え方が常人とは著しくずれているのです。要するに、「頭がおかしい」のです。この病気はもう直りません。だから、センスの無い人は絶対にプログラマにはならないで下さい。
定期的に思うんだけどプログラムで無理な英語にせず日本語にすればいいのにって思う。
（実践はしていない）
日本語で書ける言語使うんじゃなくて変数名や関数名がUnicode対応で日本語書けるもの。
○画面に表示する時
フレームワークや言語にもよるけど表示するときに英語の名前から日本語の名前に変換して表示って手間があるものがある。
最近見かけた例だと.NETでプロパティの属性に表示名書いて表示するときに取り出していた。
最初から日本語だとそのまま表示でいいことが多くて一段手間が省ける
次に他の人の英語化したのを見る時。
その人の英語力にもよるけど、動詞名詞が変に混ざっていたり、sがついてたりなかったり、そもそもchildsみたいな謎の語があったり。
そこそこできる人同士でも、「私はニュアンス的にこっちの単語」「僕はこの単語のほうがいいと思う」とかある。
相手の書いたところがわかりづらいのはもちろんだけど、プログラム的に同じ意味なのにクラスや関数によって呼び方違うと辛い。
かといって全員に日本語と英語の対応を先に渡しておいて統一しようというのは大変すぎる。
（日本語だと仕様の時点で日本語で書いてるからまぁおかしなことにはそうならないはず）
----
次にデメリット
軽く調べた感じ主にこの2つな感じ。
○IME
と思うけど、実際チャットやこういう文章書いてて英語が出るときに割りと頻繁に押してる。
ほぼ無意識でやってて意外と苦じゃない。
短いとF10変換で半角にすることもあるけど、キーボードのタイプ数カウンタとか入れてみると半角全角キーはけっこう上位にいた。
それに、なんだかんだコメントは日本語で書くことが多くて、他の人と作るのならこまめにコメント書いてる。
そうなると全角半角の切り替えは普段からあるもので、あんまり気にするほどじゃない気がした。
最近じゃIDEやエディタの補完が優秀だし、日本語にするにしても「最初はjから始める」とかルール入れておけば「j」って打ってあとはスコープにあるいくつかの候補から選ぶだけで全角にしなくていいかもしれない。
githubで公開したりとかライブラリで再利用してもらうときに日本語じゃ使ってもらえない。ってことみたい。
私が日本語にすればいいじゃないって思ってるのは、ビジネスロジックというかそのアプリケーションの固有名詞みたいなところ。
「足し算」って関数名は 「add」 でいいと思うし、配列のそれぞれは element とか item とかそういう一般的な英単語でいいと思う。
具体例がいいづらいけど、業務システムで表示する金額の名前とか、日本語独特なものとか、一般的な単語じゃなさそうなの。
こういうのを日本語にしたいってわけなので、ライブラリ的な共通なところは英語で良いからgithubで公開する範囲も英語のものでいいと思う。
ただ、最近はやってるマストドンとか、ライブラリ的なものじゃなくアプリケーション自体をgithubで公開する場合はできない気がする。
でも、海外も対象にしてるものだと日本語特有なせいでわかりづらい英語になる苦労とか少なそうだしそういうのだと英語でいいんじゃないかな。
----
長くなったけど、まとめると、
業務システムの固有名詞とか日本語特有なものとか無理に英語化してよくわからないことになってり、見づらくなるくらいなら日本語使えばいいんじゃないかな
ということ。
まあ思ってる割には実践してないので、やってる人がいたら良かった・悪かったとか聞きたいなと思ったのが書いた理由。
帰ってきたらすごいブクマついてた。
絶対「自分でやってから言えよ」みたいな意見来るだろうと思って今日の空き時間に日本語行ける言語調べたり軽く日本語使ってコード書いてみたので、そのあたりと目についたコメに答えてみる。
まず、思いの外日本語プログラミング言語上げてる人がいたので、うまく伝わってなかったぽい。
具体例上げずにサッと書いたらからかな。
あと自分もわりとするけどタイトルだけ見て中身見ずにコメントしてた人もいるだろうなー。
これが、などしこやひまわりや、BF系のmisaやら北斗のあれやらうにゃーとか色々な「構文など最初から日本語を前提とした言語」ではないってこと言ってた。
---
最近の主要な言語ならだいたい Unicode 対応でしょと思って環境があった言語を試した結果はこうだった。
JavaScript/Python/PHP/Scala/Kotlin/C#/Go/Swift
rust と Lua は無理だった。
rust は確か前に、変数名が ascii 文字だけなことに日本以外のどこかの国からUnicode対応にしてって多くの要望あったみたいな記事があったし将来的に対応するんじゃないかなって思ってる。
実際に今どんな状態かは知らない。
その記事のコメントとかでみたけど、日本語以外は割りと自国の言葉を使ってたりするっぽいね。
VBA を上げてる人がいたけど、私はそこまでのはみたことない。（幸せ者っぽいな）
稀にエクセルマクロいじるときに使い方ググってて出て来る、解説してるページで関数名が日本語なのをたまに見るくらい。
パット見なんか気持ち悪い感はあるけど、読んだときのわかりやすさはけっこう大きい。
---
○使ってみて
大規模案件に使ってみてこその問題もあるだろうけど、簡単なスクリプト程度のを日本語にしてみて気づいたこと。
割といける。
PHPて言語は変数は全部$からはじめないといけない欠陥言語。
まあ変数のみのgrepのしやすさや予約語キーワードを変数名に使えるからメリットもある。
だが、$って打ちづらい。
Shift+4ってすごいつらい。
に比べて全角半角キーってちょい遠いけどそこまで苦痛じゃない。
GoogleIMEだけど、多少のタイプミスは補完で修正してくれるし、予測変換が優秀だし。
IDE重いから補完機能のない軽いエディタで書くようなときなら、IMEのおかげで英語の変数名で書くより速度は早いと思う。
---
少し前に知人から言われた日本語のデメリットを思い出したのでそれも触れとく。
「仕様変更で言葉変わったときに日本語だと全部書き換えないといけないよ。英語だと別にそのままでいいし。」
英語わからない人が、英語を言葉とみなさずただの記号として考えてるから、っていうような発言。
仕様変わって変数名まで変えるのは面倒なのはわかるけど、あとからコード読む人が英語で見て意味不明になる。
英語と日本語の対応をコメントに書いたとしても、全然意味の違う英語があるのは混乱でしかない。
こういう考えの人がいたら本当にやめてほしい。
---
あとは気になったコメントについて書いてく。
表記ゆれとか方言とか言い回しなどについては、全部日本語にするとあるだろうけど、私が想定してるのは直感的に英語にならないような固有名詞とか。
年金の例も○○年金というのがいろいろあって、全部英語だと嫌になってくるしよくわかる。
こういうのを日本語にしたい。
なので年金額を取得する関数で「年金額を取得する」「年金額を取得」「年金額を取り出す」とかの表記を迷うんじゃなくて「get年金額」でいいと思う。
特にDBにある項目だと仕様とかで先に言葉が決まってることが多いだろうし。
---
見た目について。
見た目が残念とか見づらいというのは同意。
見た目が悪いというのも全部英語っていう前提があるからで1ヶ月も日本語のコード見ればなれるんじゃない？って思う。
---
へとヘ
これはありそうな問題。
ただ、IDEを使う前提なら未使用変数のエラーとか、選択したときに色が変わってないとか、割と気づけると思う。
lとIとかアルファベットでもあるけど、IDEや高機能エディタ使うと困ることはほぼなくなった。
---
私が日本語にしたいような固有名詞をローマ字化してるプロジェクトにであったことはある。
それにローマ字のほうが「ん」でnは1つか2つかや、ヘボンorローマ？という日本語より表記が揃わない問題ある。
特にローマ字の場合自分がキーボードで打つ方じゃないと書きづらいのでそろえてもらうのに抵抗がある。
---
海外向けとか海外の人と一緒に作る系なものって最初から英語で困らない単語ばかりだと思う。
そういうのは対象外。
今回いいたいのは、元から日本しか対応してないような業務システムなど。
そういったところの固有名詞が日本語になったからって、困ることはないはず。
日本でしか使われないもの・海外向けにするにしてもフルスクラッチで作り直すことになるようなもの、
---
テストだと日本語が使ってる人多いのかな？ブコメのスタートップだし。
---
長くなったけど参考になる意見もいろいろあって助かった。
トヨタならT、ホンダならH、といった具合に頭文字のアルファベットで振り分けていったときに、
最も多くの企業が属するアルファベットはどれか、という企画です。
売上高ランキングはこちらの1位から100位までのデータを用いました。
A: イオン アイシン アルフレッサ 旭化成 アサヒ ANA
小売の最大手・イオンを筆頭に、自動車部品、医薬品、化学、飲料、航空と個性豊かな面々を取り揃える「A」。
JRとJTのツートップに石油のJX・鉄鋼のJFEと重量級を並べる脅威のJapan軍団、「J」。
彼らと戦うときは鉄道を使えないことはもちろん自動車もガソリンを失うことを覚悟せねばならないだろう。
N: 日産 日本郵政 NTT NTTドコモ NEC 日本郵船 日鉄住金物産 日本通運 NTTデータ
「N」が単独で5位にランクイン。「N」ihonをその名に頂く九つの企業が並ぶ。
物流、海運、郵便、通信、……情報と兵站を奪われた敵はもはや自滅するしかない。
M: 丸紅 三菱商事 三井物産 三菱電機 三菱重工 三菱ケミカル マツダ メディパル 三菱食品 三菱自動車 三井不動産
K: KDDI 関西電力 キリン コマツ 九州電力 神戸製鋼 鹿島建設 クボタ 川崎重工 京セラ 花王
現代においても日本を支配するのは彼らなのか、恐るべし三菱・三井グループの登場だ。
いざ戦いとなれば、かつて大財閥として鳴らしたその力を見せつけてくれるだろう。
業種は多岐にわたっているのでそれぞれの連携が勝負のカギとなるか。
T: トヨタ 豊田通商 東京電力 東芝 東燃ゼネラル 豊田織機 東レ 東北電力 東京ガス 武田薬品 大成建設 凸版印刷
日本一の巨大企業トヨタ、そして「東」軍団がずらりと並び、12社で「T」が2位となった。
まともなら横綱相撲で押し切れそうだが、苦しい立場に置かれる東電・東芝が弱点になりそうだ。
S: ソフトバンク ソニー セブン＆アイ 新日鉄住金 住友商事 スズキ 住友電工 シャープ スズケン 昭和シェル 住友化学 積水ハウス 商船三井 清水建設 双日
個人的にも意外な結果だったが、なんと「S」が15社でダントツの1位となった。
ソフトバンク、ソニー、セブン＆アイの三羽烏に、「結束」の住友グループを加え、質量ともに他を圧倒する。
スマホとコンビニという現代社会の二大基盤をがっちりと掴み、さらには住宅、家電、自動車と、もはや人々の生活を「S」が支配していると言って過言ではない。
彼らが連合すれば「T」でさえも恐れるに足りないだろう。
というわけで売上高ランキング上位企業が最も多いアルファベットは「S」でした！
Tumblrに限らず、昨今のコンテンツが所謂「タイムライン」に配されるタイプに共通していえることだけれど。
３．再び見ようとして、その時点の「最新（現在）」から過去に遡っていく
４．１の時点での「最新」に追いつく
５．毎回それなら別として、間があくと、その「間」に辿り着くのは実質不可能
既読／未読を管理して、しらみつぶしに全網羅したいというわけではなく、
単に、暇潰しで見るときに、前回の最新まで追いつくと、既読が続いて楽しくない問題。
あと、「J」とか「k」キーでコンテンツごとにひょいひょい移動するのだけど、
ぐん！ぐん！とスクロールするのが目に痛い。
以前、このスクロールを無効にする拡張機能があったけれど、仕様変更か効かなくなった。
あと、単純なリブログってよくするのに、何で[option]押しながら[r]なの？（Macの場合です）
間違って[command]押しながら「r」押して画面がリロード、折角深く迄潜ったダッシュボードから強制リレミト。
以上のこと、考えているの私だけでないはず、と検索してもみんな
「Tumblrいいよねー！」「jとkとrがすり切れてるわー」
みたいなのしか出てこなくて。
アプリとかあるのも知っていますけど、微妙に不安定だったりも。
みんなこんなんでTumblr楽しめてるの？
誰か教えてください。
http://anond.hatelabo.jp/20141130202457
はてなにちは！
主催者からの要請を受けたので増田アドベントカレンダー2014の16日目に飛び入り参加させて頂きます。
今回はGTDをお手本にして構築した増田処理ワークフロー管理手法「Getting Masuda Done」を紹介いたします。
増田に書かれた内容を効率的に把握して適切に処理していくのは情報感度の高いはてな村民には必須の嗜みですよね。
「GMD」では以下のフェイズに分けて増田を効率的に処理していきます。
増田を収集するにはFeedlyなどのRSSリーダーを利用します。
RSSの人気は下火になってきましたが、個人的には一番効率が良いと思います。
基本的に全エントリを読むべきなので「http://anond.hatelabo.jp/rss 」を登録します。
FeedlyはRSSの件数が多すぎると勝手に表示数が絞られてしまうので、「Must Read設定」をお忘れなく。
上記だけだと読み飛ばしてしまう事もあるので、ブクマ新着も登録しておきましょう。
http://b.hatena.ne.jp/entrylist?url=http%3A%2F%2Fanond.hatelabo.jp
その他、特定ユーザーのブクマやGunosyなどもRSS化して登録しておきます。
これらの全文を読むのは無理なので、タイトルと最初の3行ぐらいで収集対象にするかどうかを決めます。
約2秒ごとぐらいに「j」ボタンを押して次のエントリにいけば全エントリを把握できます。
上記の布陣にすれば、話題になるエントリは何度も見る事になりますし、直感は大体正しいのです。
気になったエントリがあっても、その場で読むとスピードが落ちてしまいますので、
「s」ボタンを押してチェックを入れてすぐに「j」をしましょう。
IFTTTを用いてFeedlyでチェックを入れたらPocketに転送するようにしておき「後で読む」のリスト化を行います。
この時点ではてブを使ってしまうとキュレーション能力を疑われてしまうので悪手です。
https://ifttt.com/recipes/229789-feedly-to-pocket
PocketがGTDでいうところのin-boxとなりますので、エントリ毎の優先順位を付けていきます。
緊急軸と重要軸をプロットして「すぐに読む」「後で読む」「いつか読む」という段階分けをします。
30秒以内で読めるような文章は整理するだけ時間の無駄なので読んでしまいます。
多少なりとも重要に感じたらブクマページを参照して以下のような選択肢から今後の対応を決めていきます。
複数の処理を同時に行う事も多々あります。個人言及系やシモネタ系は非公開ブクマが基本となりますね。
忙しい時などはPocketに未読記事が大量に残ってしまう事もあるのでその辺は徐々に消化していきます。
またブクマから転送したEvernoteを定期的に読み直しています。
はてなブックマークをブックマークとして利用する事はありません。
以上、ぼくは普段そんな感じで増田を読んでますよっていう紹介でした。
ますだーね！
俺はかつて和式派だった。肛門を拭きやすかったからだ。こと肛門へのアクセスに関しては、和式の方が洋式よりも分がある。行為時の体勢は若干ツラいが、総合的には和式、という判断だった。
しかし現在の俺は、圧倒的な洋式派になってしまった。理由は、ウォシュレットだ。肛門を素早く清潔にできる。紙で拭く回数が減り、肛門へのダメージも激減する。腹の調子が悪いときなど、大変ありがたい。暖房便座もかなり寄与しているが、何しろウォシュレットの存在が大きい。ウォシュレットの登場で、洋式はブレイクスルーと呼ぶに相応しい進化を遂げたと思う。
振り返ってみれば、俺にとって「便器について考えること」は「肛門について考えること」に他ならなかった。そして、洋式という選択に一切の疑念は無く、和式を徹底的に避け、ウォシュレット付きのトイレがない公共施設を軽蔑すらしていた。
しかし。今朝、こんなことがあった。
俺はサーバーの日次点検をしていた。バックアップ用のDATを交換し、H/Wアラートの発生有無を確認する。まぁ退屈な仕事だ。3本目のDATを交換している最中、俺は強い便意に襲われた。作業はまだ途中だった。しかしこれは無理だ、トイレに行くしかない。俺は作業を中断してトイレに向かうことにした。便利なことに、サーバー室を出た目の前にトイレはある。ここなら速やかに事を済ますことができるだろう。
だが、ひとつ問題があった。便器だ。このトイレには和式しかないのだ。
少し歩けば、洋式＋ウォシュレットのトイレがある。もはや骨の髄まで洋式派である俺としては、足を伸ばしたいところだ。しかし今回は事情が違った。事は急を要している。便意は俺から選択肢を奪った。やむを得ず、俺はサーバー室前のトイレに向かった。
少し早足でトイレに入った俺は、「和式」のプレートがついた扉を開け、いそいそとズボンを降ろし、腰を下げた。いつもより近いタイル地の床と、そこから伝わってくる冷気。忌避感と屈辱感が頭をよぎった。
次の瞬間。ずぅるりっ、という感触とともに、一気に便が排出された。押し出された、という表現が正しいかもしれない。まさに一瞬だった。
俺は首をがくりともたげて、目を閉じた。便意からの開放感で、頭の中は真っ白になった。ふぅ。自然と溜息が漏れた。しかし、すぐさま忌まわしい感情が湧いてきた。そうだ、これからウォシュレットなしで、トイレットペーパーだけで肛門を拭かねばならないのだ。
トイレットペーパーに手を伸ばし、カラカラと引き出す。この作業を、繰り返し行わなければならない。そしてその度に、拭き残しを確認しなければならない。自分がいかに汚れているのか、自分に知らしめる作業だ。なんて原始的で、合理性のない、恥辱的な作業なんだろう。そんな思いを巡らせながら、手にとったトイレットペーパーを尻にあてがおうと、腰を少し浮かした。そのときだ。便器の中に転がっている糞を見て、俺は驚愕した。
デカい。
これはデカい。なんだこれは。長さにして、30cmをゆうに超えている。指先から肘にかけて程の長さだ。しかも、よく見るとアルファベットの「J」のように途中から折り返している。全長は40cmに及ぶのではないか。思い返せば、確かに今回の便意は強く、腹の中に大量の糞が待ち構えていることは予感していた。しかし流石にこのサイズは想定外だ。俺は息を飲んだ。
そう、これが和式便器なのだ。和式の強み、それは「自然な糞の射出を阻害しないこと」そして「射出された糞の観察が容易であること」だ。便器について考えること、それは、肛門について考えること、だけではなかった。俺は忘れていたのだ。糞と向き合うことを。
肛門を拭き終えた俺は、レバーを引き、糞の消えた便器を確認してからトイレの扉を開いた。やり遂げた、そして見届けた。洋式では得られない、懐かしい充足感で満たされていた。軽い足取りでサーバー室へと戻った俺は、晴れやかな気持ちで作業を再開した。肛門に軽いヒリつきを感じながら。ほんの少し、拭き残しへの不安を胸に抱きながら。
俺は、ウォシュレットによって清潔とスピード、そして安心を得ている。しかし、代わりに失うものもある。再び便意が訪れたとき、俺はどうするだろうか。きっと、ウォシュレット付きの洋式を選ぶだろう。便利だからだ。そしてウォシュレットで尻を洗い流し、ろくに糞の確認もせず、さっさと流してしまうだろう。感慨も何もない。残るのは空っぽの便器だけだ。
何かを捨てて、何かを得る。俺は便器を選択しているのだ。