DataMapper のドキュメントを見たくてググったが出てくるのは Stack Overflow ばかりで公式サイトが検索結果に出てこない。 GitHub の DataMapper のリポジトリ（ Archive されている）経由で見に行ってみると、なんと ROM ( Ruby Object Mapper ) のページにリダイレクトされた。
ROM は Hanami で使われる ORM で、 DataMapper よりもさらに ActiveRecord と使い心地が異なる。
Qiita の以下の記事を読むと使い方のイメージが湧く。
軽くてシンプルなのだろうがだいぶ特殊だ。
Lokka の使い手は少なくとも Heroku が使える人で、そういう人ならば ActiveRecord の方が Rails の本やドキュメントで学びやすいはずだ。というわけで早めに、真剣に ActiveRecord への移行を考えなければならない。
ずっと過去記事をどうやって効率よく見せるか（自分自身が効率よく読むか）ばかり考えている。一つ前の記事では絞り込み UI について書いた。
ブログというものが生まれたとき、誰も 10 年以上にわたってインターネットに文章を書くことを考えていなかったと思う。多くの人は途中で脱落してブログを止めたり飽きてほかのところ（ Facebook や Twitter ）に移ったりしただろう。ただ、同じ場所でしぶとく書き続けている人たちもいる。自分もその一人だ。
そういう人たちにとって、過去に自分が書いた記事をどうやって閲覧するかというのは大きな問題だ。過去記事を探すのに本文込みの一覧ページをページネーションしていくのはあまりにも効率が悪すぎる。一覧でガッと見たい。
というわけで、インターネット老人にしか用のない機能かもしれないが、過去記事一覧ページの UI/UX は非常に大きなテーマだと思う。問題点と対策を整理してみた。
過去記事が溜まることの問題点は、過去記事が探しづらくなることだ。対策としては各記事に関連記事へのリンクを表示する方法と過去記事の一覧ページを用意して探しやすくすることがあると思う。
過去記事の一覧ページは以下を満たしていて欲しい。
10 年以上続いてるブログを書いてる人たちは多かれ少なかれ同じような問題（過去記事へのアクセシビリティ）を抱えているはずで、他の人たちがどうやっているのかを調べてみた。以下は長く続いているブログの Archive ページ。
ながしまきょうさんのブログ。
ブログのトップ自体が過去記事インデックス（タイトルのみ）になってる。本文を含む記事一覧ページはない。静的に生成してあって速い。絞り込むような UI はない。
関連記事のアルゴリズムやデザインなどを結構パクらせてもらっている cho45 さんのブログ。
本文込みの一覧ページとは別に年がずらっと並んでいる。記事の一覧はない。クリックすると年月ごとの記事一覧（本文込み）が表示される。記事を書いた時期を覚えておく必要がある。
Markdown の生みの親、 Apple ブロガー John Gruber のブログ。
本文込みの一覧ページとは別に年月ごとにグルーピングされた記事一覧（タイトルのみ）がある。このブログの Archives ページの UI に近い。検索窓があるが、 DuckDuckGo のサイト内検索に飛ばされる。スマートフォン用の画面がなく非常に見づらい。
hitode909 さんのブログ（はてなブログ）。
本文込みの一覧ページとは別に、本文が短く表示される過去記事一覧ページがあるが、一覧性は高くない（ページネーションが必要）。グローバルフッターに年月ごとの記事一覧へのリンクがあるほか、サイドバーにもカレンダー式のアーカイブ導線がある。「月別アーカイブ」は年をクリックすると月別のアーカイブ一覧が展開表示される。デフォルトだと今年（最新年）が展開表示されている。年・月・カテゴリーそれぞれの記事数がわかるのは便利だと思う。
Blog Hacks の著者 miyagawa さんのブログ（ Medium ）。 Bulknews 時代からの過去記事がいっぱいあるはずだけど現在は 2011 年分からしか公開されていないみたいだった。
タイトルのみの記事一覧ページはなく、一覧性は高くない。本文込みの一覧ページの上部に、年ごとの絞り込み UI が表示されている。年を選択すると月ごとの絞り込みができる。はてなブログに近い。
Medium が酷いのはこのアーカイブページへの導線で、トップページには最近の記事が数件表示されるだけで、過去記事への導線はページ下部に申し訳程度に置いてあるのみ。しかも Medium というサービスの利用規約ページへのリンクと並んでいるので存在に気がつきにくい。
先日の記事（ 蟻地獄と個人ブログ - portal shit! ）では Medium はまとも陣営に分類したけど、個人のブログ内で回遊することを極力できないようにしようとしているのが伝わってくる。蟻地獄感ある。
『ハッカーと画家』などポール・グレアム本の翻訳もされている shiro さんのブログ。
本文込みの一覧ページとは別に、本文が短く表示される過去記事一覧ページがある。年による絞り込みがあり、少し前のこのブログの Archives ページに近いが、 2002 年から記事があるので年のリンクが 19 個ある。 10 年後、 20 年後のことを考えると UI 上の問題が発生しそうだ。
最後にこのブログ。
本文込みの一覧ページとは別に年月ごとにグルーピングされた記事一覧（タイトル、カテゴリー、日付が表示）がある。年やカテゴリーによる絞り込みができる。
Hail2u 、 Daring Fireball 、 Island Life など記事のタイトル一覧が表示されるタイプが好みだ。 Medium の一覧性のなさは最悪だが、年月の絞り込み UI はおしゃれだと思った。
個人的にはこのブログの Archives ページが一番使いやすい。自分で作っているので当たり前だ。スマートフォンでの閲覧性も問題ない。記事一覧の状態で本文で絞り込めるやつがあれば完璧なので、少ししたらチャレンジしてみたい。
一個前の記事のキャプチャにあるように、従来テキストリンクだった年とカテゴリーの選択をセレクトボックスにした。 git log -S したところ去年（ 2019 年）の 11 月頃に変更を行ったみたいだ。もうそろそろ 2020 年になろうとしていて、 2005 年からやっていて年の数が 16 個になろうとしていてさすがに多すぎると思ったので整理のためにセレクトボックス化してコンパクトにした。
利用したのは React Select というパッケージで、色々カスタマイズできるみたいだけど面倒だったので素のまま使ってる。
Archives ページのリファクタリング のときのように、子コンポーネントのイベントをトリガーに親コンポーネントの setState() を呼び出すような作りになっている。作るときは結構難儀したけどおかげでスマートフォンで見たときも年やカテゴリーだけでファーストビューが埋まるということがなくなった。
現在のコードをまるっと貼り付けるとこんな感じ↓。
import React, { Component } from 'react'
import ReactDOM from 'react-dom'
import Select from 'react-select'
import PropTypes from 'prop-types'
import { withRouter } from 'react-router-dom'
import history from './history'
class YearSelect extends Component {
constructor(props) {
super(props)
this.state = {
data: [],
selectedOption: null
}
this.handleChange = this.handleChange.bind(this)
}
static propTypes = {
match: PropTypes.object.isRequired,
location: PropTypes.object.isRequired,
history: PropTypes.object.isRequired
}
async loadYearSelectFromServer() {
const request = await fetch('/archives/years.json')
const response = await request.json()
this.setState({ data: response })
}
componentDidMount() {
this.loadYearSelectFromServer()
}
handleChange(selectedOption) {
const year = selectedOption ? selectedOption.value : null
if (year) {
this.props.history.push(`/archives/${year}`)
} else {
this.props.history.push("/archives")
}
this.setState(
{ selectedOption },
() => { this.props.update(year) }
)
}
render() {
const options = this.state.data.map(year => {
return { value: year, label: year }
})
return (
<div className="year-list">
<Select
value={this.state.selectedOption}
onChange={this.handleChange}
options={options}
placeholder="Year"
isClearable
/>
</div>
)
}
}
const YearList = withRouter(YearSelect)
export default YearListimport React, { Component } from 'react'
import { BrowserRouter as Router, Switch, Route, Redirect } from 'react-router-dom'
import YearList from './YearList'
import CategoryList from './CategoryList'
import Archives from './Archives'
class App extends Component {
constructor(props) {
super(props)
this.state = {
category: null,
year: null,
length: 0
}
this.updateCategory = this.updateCategory.bind(this)
this.updateYear = this.updateYear.bind(this)
this.setLength = this.setLength.bind(this)
}
updateCategory(category) {
this.setState({ category })
}
updateYear(year) {
this.setState({ year })
}
setLength(length) {
this.setState({ length })
}
render() {
return(
<Router history={history}>
<div className="archive-filter">
<YearList update={this.updateYear} />
<CategoryList update={this.updateCategory} activeCategory={this.state.category} />
<div className="entry-length"><p>{this.state.length} entries</p></div>
</div>
<Switch>
<Route
exact path="/archives"
render={(props) =>
<Archives
category={this.state.category}
setLength={this.setLength}
{...props}
/>
}
/>
<Route
path="/archives/:year(\d{4})"
render={(props) =>
<Archives
category={this.state.category}
setLength={this.setLength}
year={this.state.year}
{...props}
/>
}
/>
</Switch>
</Router>
)
}
}
export default App
S3 のバケットを事故で空にしてしまってとても悲しかったので、写真以外の画像もきちんと管理してみることにした。
これまで、仕事やブログ用に作った図表みたいなやつは作ったあと JPEG とか PNG に書き出してドキュメントに書き出した後は適当にデスクトップに置いてあって、ある程度時間が経ったら定期的に削除するような運用にしていた。図表自体は Pixelmator や OmniGraffle で作っているが、ちょっと作ったやつは元ファイルごと消してしまっていた。しかしそれでは今回のようにミスって S3 を飛ばしてしまったときにリカバリできなくなる。
というわけで Pixelmator や OmniGraffle で作ったオリジナルファイルを残していこうと思ったのだけど、これらはプレビューできないし、 Mac の中で仕事のプロジェクトのフォルダの中にあったり、 iCloud の Pixelmator のフォルダの中にあったりデスクトップにあったりで非常にごちゃごちゃしており、 Finder だけで管理するのは無理っぽいなと思った。写真以外の画像ファイルを管理できる何かが必要だと思って調べてみた。
この手のやつは Little Snapper というのを使っていたが、途中から名前が Ember に変わって Mac OS のアップデートについて行けずディスコンになった。 Little Snappter / Ember は結構気に入って使っていて、画面のキャプチャを撮って注釈の文字を入れたりする用途に使っていたが、本来はこれらはデザイナー用の画像管理ソフトだと思う。
色々調べていて Eagle というソフトが存在することを知った。 Eagle はなかなかよくて、 JPEG や PNG 、 Adobe の Photoshop 、 Illustrator に加え Pixelmator や OmniGraffle に対応している。デザイン系だけでなく各所にファイルが散らばりがちな MindNode （マインドマップアプリ）や Numbers 、 PDF 、 Keynote 、 Pages 、 MS Excel 、 MS Word などドキュメント系のファイルにも対応している。
要するにパワーアップした Finder という感じなんだけど、ファイルの中身をプレビューできて一括でタグ付けしたりフォルダ管理できるのが便利。 いわゆる「ファイルの壁」問題が解決できる。デスクトップや iCloud Drive に散らばってるやつをとりあえず一旦突っ込んで整理してみることにした。
UI は日本語翻訳があるのだけどあまり出来がよくなく、スクリーンショットを「スクショ」と略していたり、全体的に翻訳が調子こいてる若者風なのが気持ち悪い…。いまは言語を英語にして使ってみてる。日本語文字列の検索精度がいまいちなところも気になる。 年賀状 で検索しても 年賀状 という文字列を含むファイルがヒットせず、かわりに 年賀 で検索するとヒットしたりする。日本語周りに課題が多そうだ。そのほか、 Windows 版も存在するせいか、通知の UI が Notification Center の標準 UI とかけ離れているところもちょっと気持ち悪い。
同系統の Pixave というのを以前「できる Mac OS X Advent Calendar 2015」で知って試していたが、当時の自分は Little Snapper / Ember の代替となるキャプチャに注釈を入れられる機能を求めていたので用途に合わないと感じた。いまもう一度見てみて試してみたが、 Eagle 同様にデザインデータだけでなく様々なファイルを扱えて、いまの自分の用途には適合してそうだった。惜しむらくはあまり活発に開発されていないようだった（ MindNode を取り込めるとウェブサイトに書いてあるが、最新バージョンの MindNode には対応していなかった）。Pixave は App Store の賞を受賞しているだけあって見た目がめっちゃおしゃれで Apple の標準 UI に準拠しており、使い心地は Eagle よりも Pixave の方がよい。もうちょい活発にメンテナンスしてもらえたらうれしい。
しばらく併用してどっちを使うか決めたい。
※ Pixave は韓国系の人が一人で作ってるみたい。以前好きで作っていた The Hit List （ ToDo 管理ソフト）も韓国系の人が作ってた。在米コリアンは優れたデザイナーが多いのだろうか。 The Hit List はめっちゃ UI が革新的だったのに更新が滞ってしまった。 Karelia という会社に買われたあとも更新が滞っている。 The Hit List のようにならないでほしい。
外出自粛かつ自分自身にコロ助疑惑があったのでずっと部屋に閉じこもってサイトのデザインをいじってた。
上がこれまでで、左下が今後、右下が画像がワイドな場合のバージョン。これまで横幅 1280px 想定にして画像も横幅 1280px のサイズで表示するようにしていた。
ただしこれだと写真は見やすくても文字が読みにくい。人間の目は 1280px 繰り返し左右に移動させるのには適していないようだった（ N=1 ）。
そういうわけでまたまた cho45 さんのブログのレイアウトをパクって、文章は横幅短めに、写真はでかいサイズで表示するようにした。
文章部分の幅を 800px にして、画像を読み込んだときに一定の条件にマッチしたら写真の横幅を 1280px で表示するようにした。 margin-left: -250px; してるのがミソ。横幅 800px だと大分文章は読みやすいし、でかい写真は大きく見えて便利。
@media screen and (min-width: 1422px) {
#content #main article .body > p {
img[class~="large"] {
width: $content-max-width;
max-width: $content-max-width;
margin-left: -250px;
}
}
}JS はこんな感じのコードを書いた。
const checkImageSize = (target) => {
if (typeof target === 'undefined') {
return;
}
const width = target.naturalWidth;
const height = target.naturalHeight;
const isPhoto = RegExp('(lh3\.googleusercontent\.com|\.jpe?g$)').test(target.src);
if (width > 1279 && width > height && isPhoto) {
target.classList.add('large');
}
}
const lazyImageObserver = new IntersectionObserver((entries, observer) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const lazyImage = entry.target;
lazyImage.src = lazyImage.dataset.src;
lazyImage.addEventListener('load', (event) => checkImageSize(event.target));
lazyImageObserver.unobserve(lazyImage);
}
});
});
const selectors = "#content article .body img, #content article .similar img";
const lazyImages = [].slice.call(document.querySelectorAll(selectors));
if ("IntersectionObserver" in window) {
for (let image of lazyImages) {
const src = image.src;
image.dataset.src = src;
if (lazyImages.indexOf(image) === 0) {
const promise = new Promise(resolve => resolve(image));
promise.then(checkImageSize).catch(setTimeout(checkImageSize, 100))
continue;
}
image.src = "";
};
lazyImages.forEach(lazyImage => {
lazyImageObserver.observe(lazyImage);
});
}画像の読み込みが起こったタイミングにフックして画像のサイズチェックを行い、条件にマッチしたら img タグに class を追加し、 CSS のメディアクエリと合わせ技で大きく表示するようにしている。以前やった画像の遅延読み込みのコードを改良した。
その他、 HTML 5 対応が中途半端だったのでマークアップを見直して、適度に <header> や <secition> 、 <article> 、 <footer> を使ってマークアップし直した。 このせいだと思うけど Google Adsense の自動広告が差し込まれる位置が変わった。これまでヘッダーの下に入り込んでいたやつが <header> と <article> の間に入るようになった。
今後も外出禁止が続いたらひたすら自分のブログをいじってしまう予感。こういうエネルギーを仕事とか個人サービス開発とかに当てられるとよいのだろうけどなかなかそういう方向には向かない。
最近、やたらこのブログにスパムコメントが来るようになった。コメントがあったらメールで通知されるようにしてるのだけど、コメント通知メールが一日十件くらい届く。
Google の reCAPTCHA を入れたことでほぼほぼスパムコメントは弾けていたのだけど、最近のスパムは reCAPTCHA をすり抜けるようになってしまったっぽい。加えて Akismet のスパム判定ロジックもポンコツになってしまったようで、ほぼほぼすべてのコメントをスパムと判定しなくなってしまった。
Lokka では Akismet でスパム判定されたコメントは一括削除できるようになっている（この機能は自分で作った）が、スパム判定されなかったコメントはちまちま一つずつ削除しなければならないのが非常に煩わしかった。
なのでコメント一覧にチェックボックスを表示して、チェックを入れたコメントを一括で削除できるようにしてみた。めっちゃ便利。
Akismet プラグインも少し改造して、自分で NG ワードを設定できるようにした。最近のスパムは露骨に Viagra とか Cialis みたいなキーワードが入ってて、どうしてこんなわかりやすいやつを Akismet は素通りさせてしまうのかわからないのだけど、自前の NG ワードフィルターで二重にチェックするようにした。
最後にアクセスログからスパムっぽいコメントの数を集計して管理画面のダッシュボードで閲覧できるようにした。引き続き監視していきたい。
Basecamp の Jason Fried が Amazon で REMOTE がバカ売れし始めたので返金を始めたそう。なぜ返金するのかというと、本が売れているのは多くの人がリモートワークを恐れており、そのような恐怖・不安に REMOTE という本が役立つから、とのこと。
For the foreseeable future, we’ll be refunding the purchase price of our book “REMOTE: Office Not Required”. Buy a copy, tweet me a picture of you holding the book w/ a sales receipt dated 3/10/20 or later, and we’ll PayPal you a complete refund (DM your email, please).
— Jason Fried (@jasonfried) March 11, 2020
アメリカはリモートワーク先進国なのかなと思っていたけど、やっぱり昔ながらの方法で仕事してた会社もあったんだろう。アメリカでもコロナウイルスが猛威を振るいつつあるいま、そのような会社もリモートワークをやるようになり、リモートワークの心構えが書いてある本がバカ売れしてるということですね。おもしろい。
HashiCorp の Mitchell Hashimoto さんのリモートワークについてのツイートもおもしろかった。これまでのリモートワーク経験で得られたことが書かれている。
The force to remote for much of the workforce is going to be very positive but also create a ton of FUD. Lots will “get it” and it’ll work for them and they’ll be forever changed. Many will realize it isn’t as simple as pretending your at-home desk is your in-office desk.
— Mitchell Hashimoto (@mitchellh) March 11, 2020
全従業員をリモートワークに、という動きは良い傾向だと思うが、たくさんの不安・疑念・不信を引き起こす。多くの人が「はいはいこんなもんね」という感じで仕事をするだろうが、リモートワークは一筋縄ではいかない。多くの人が仕事に使う机を会社のものから自宅の自分のものに置き換えただけのことではないな、ということに気がつくだろう。
It also just isn't going to work for some people. Not everyone is compatible with remote and that's okay. We've had numerous people over the years quit HashiCorp saying "loved the work, loved the people, but I just need in-person social interaction." That's totally normal.
— Mitchell Hashimoto (@mitchellh) March 11, 2020
リモートワークは一部の人にとってはうまく機能しない。みんながリモートワークに適応できるわけではなく、それは仕方がないことだ。これまで HashiCorp ではたくさんの人が「仕事は楽しい、同僚も好きだ、ただやっぱり自分は顔をつきあわせたコミュニケーションの方がいい」という理由で会社を去って行った。これは自然なことだ。
このほかにも Hashimoto さんが新しく従業員を雇ったときに説明するリモートワークについての心構えが書かれていてうなずきながら読んだ。一番最初のやつから結構ショッキングだが事実だと思う。
(1) "You won't make friends." Brutal, but honest. You need to have a strong friend circle OUTSIDE of work cause you aren't going to make one at work. You'll become friends with your coworkers -- yes -- but you probably won't hang out, have your kids share school, etc.
— Mitchell Hashimoto (@mitchellh) March 11, 2020
「君は友だちができない」。残酷だが事実だ。リモートワークをするなら、仕事以外でとても仲の良い友だちがいないとダメだ。なぜなら仕事では友だちができないから。リモートワークでも同僚とは仲良くなれる。でもリモートワークの同僚とは遊びに行ったり、子ども同士が同じ学校になる、ということはない。
そのほかのツイートもおもしろいので読んでみて下さい。
Jason Fried が元の Tweet を消してしまっている。およそ 400 件の返金請求が来たみたい。自動化できておらず破滅状態なので返金は終了するとのこと。
UPDATE: MARCH 12, 2020: Incredible response to this offer. Nearly 400 refund requests so far. But the success is the downfall. Totally overwhelmed by processing all these refunds, etc. So ending the refund program today. Next time will automate more. Thanks everyone!
— Jason Fried (@jasonfried) March 12, 2020