| @技術/プログラミング

react-select-before-after.jpg

一個前の記事のキャプチャにあるように、従来テキストリンクだった年とカテゴリーの選択をセレクトボックスにした。 git log -S したところ去年( 2019 年)の 11 月頃に変更を行ったみたいだ。もうそろそろ 2020 年になろうとしていて、 2005 年からやっていて年の数が 16 個になろうとしていてさすがに多すぎると思ったので整理のためにセレクトボックス化してコンパクトにした。

利用したのは React Select というパッケージで、色々カスタマイズできるみたいだけど面倒だったので素のまま使ってる。

Archives ページのリファクタリング のときのように、子コンポーネントのイベントをトリガーに親コンポーネントの setState() を呼び出すような作りになっている。作るときは結構難儀したけどおかげでスマートフォンで見たときも年やカテゴリーだけでファーストビューが埋まるということがなくなった。

react-select-smartphone-view.jpg

現在のコードをまるっと貼り付けるとこんな感じ↓。

子コンポーネント(年のセレクトボックス)

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 YearList

親コンポーネント( App.js )

import 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

| @技術/プログラミング

Archive ページ をリファクタリングした。

これまで gulp をビルドに利用していた(Archive ページを React Router 化)が、 webpack を使うように変えた。

React のコードも見直して、 DOM の状態に依存して表示・非表示を切り替えるコードがあったりして( 🐙 Archive ページにカテゴリごとの記事件数を表示する機能を追加 )ごちゃごちゃしてたので DOM を直接ごちゃごちゃ操作するのをやめて React で管理するように変えた。親コンポーネント、子コンポーネント、孫コンポーネント、子コンポーネントの兄弟コンポーネント間で状態を共有する必要があって、結構難儀した。

Archives React Component 1.png

実際の画面を見るとこんな感じ。

Archives React Component 2.png

App というコンポーネントがルートにあって、子に CategoryListCategoryList の子コンポーネント( App からすると孫)に Category コンポーネントがある。記事一覧自体は CategoryList と兄弟コンポーネントである Archive コンポーネントが担当している。

Archives React Component 3.png

こんな感じで特定の Category が選ばれたことを Category のクリックイベントをトリガーに CategoryList に伝達し、 CategoryList はさらにそれを App コンポーネントに伝える。その結果が App から Archive コンポーネントに伝えられ、表示内容が変更される。

この辺を参考にして実装した。コールバック関数を props として引き回し、状態を回収する感じ。

ただこういう込み入った状態の管理を React で行う場合は Redux などを利用するのが良いようだった。

前職のとき、 Redux とか Flux が出てきた頃に F/E のエンジニアの人たちが熱狂してたけど自分はいまいち理解できなくて、傍観するだけだったが、いまさらにして何となく Flux アーキテクチャの概要的なものを把握することができた気がする。ただ自分の場合は深みに入り込まず極力シンプルに作りたいと思っていたので Redux などには手を出さず、 Callback で愚直に状態を親コンポーネントに伝達していく方法をとった。

React 、やっぱり大分良いものだとという感じがした。 jQuery でクラスや CSS で show - hide を Toggle していた頃とは隔世の感がある。

| @旅行/散歩

アルプス遠征で白馬に行ったとき、福岡からは松本経由で行った。前の記事に書いている通り台風の影響で縦走の予定がピストンとなったため、松本を一日観光する時間ができた。

松本には去年の秋に友達の結婚式で行っていて、そのとき市内を少し観光してすごくいいところだなと思った。前回は帰りの飛行機の時間の都合でできなかったことがいくつかあり非常に悔やまれたので、今回は前回できなかったことをやってきた。

宿泊

泊まったのは花月というホテルで、結構よいホテルのなはずなのにハイシーズンにもかかわらず低価格で泊まることができたが、部屋に入って窓を開けるとこの景色でなるほどという感じだった(これはこれで面白くてテンション上がった)。

IMG_6027.jpg

昼食 1

松本には昼過ぎに着いたのでホテルに荷物を置きに行き、 The Source Diner に行った。ここには前回も来ていて、カウンターの席に座るとお店の人が料理している様子を眺めながら食事することができる。自分も料理するの好きなので目の前で料理してくれるタイプの店はプロの慣れた手さばきが見られてとても楽しい。

DSC_5954.jpgDSC_5960.jpg

物色

あたりをうろつく。ナワテ通り外れの角にあるポーランド食器のセラミカがよくて、以前来たとき器を買うか迷ったが荷物になることや結構高いこと( 21cm の皿でも 3000 円から 5000 円くらいする)、帰りの飛行機まで時間が限られていたことで決心しきれず、買わずに帰ってきてしまった。あとあとこのことが非常に悔やまれて、もしまた松本に行く機会があればセラミカを訪ねて皿を買いたいと思っていた。

買いたい器に目星をつけたが今日は荷物になるので買わないでおく。

コーヒー 1

その後、セラミカの器でコーヒーが飲める喫茶店「カフェあげつち」でコーヒーを飲んだ。この喫茶店は 300 円でコーヒーが飲めてレトロな家具や調度品が飾ってあり休憩にちょうどよい。観光客向けというより地元の人が談笑しに来ている感じ。年季の入った建物を修復して公営の会議スペースとして利用しているようである。

松本城

そこから松本城に行った。前回も今回もお城の中には入らなかった。入り口に「ここから 30 分待ち」というような看板があったが、ああいうのがあると入るのをためらってしまう。

DSC_5962.jpg

お土産 2

夜は会社の仲良しおじさん連中と飲みに行くことにしていたので、ムラマサに行ってお土産を物色した。ここも前回来たときに気にはなったけど時間がなくて素通りしてしまった店(まつもと空港で売ってるだろうと思ってスルーしたら売ってなかった)で、寄らずに帰ったことを猛烈に後悔したので滞在中何度も訪ねて入念に物色した。シュークリームが名物のようだったが旅行者で冷蔵庫に保存することができないのでお店の人にお勧めを聞いて天守石垣サブレを買った。この手のクッキークリームサンド的なお菓子にはあまりテンションが上がらないのだが、帰ってきて食べてみたら確かにおいしかった。

DSC_5978.jpg

飲酒 1

花時計公園の横にある信州ゴールデン酒場に行った。山賊焼を食べたが焼きという名前なのに揚げてあるのにはびっくりした。あと付け合わせキャベツについてくる味噌が完全にう◯こに見えてやばかった。キンミヤハイボールがよいと foursquare の Tip にあったので頼んだらもろに甲類焼酎のアルコールにやられて悪酔いした。

IMG_6024.jpgDSC_5983.jpg

飲酒 2

二軒目はナワテ横丁にある彗星倶楽部という名前の店に行った。両腕にタトゥーを入れたお姉さんがやっててかっこよかった。つまみも全部うまかった。

IMG_6025IMG_6025

さらにもう一軒行ってそばを食べたけど泥酔し過ぎていてあまり思い出したくない…。

朝食

12:50 にバスセンター集合だったので早めにチェックアウトして朝食を食べに行ったが、目当てにしていたおきな堂はモーニング営業を取りやめており路頭に迷ってしまった。二日酔いで勘が鈍っており、ふらふらしながらナワテ通りの適当なパン屋に入ったところいまいちだった…。せっかくよいホテルに泊まってたのだから大人しくホテルの食堂のモーニングを食うべきだった。同僚によると「まるも」という喫茶店が良かったとのこと。

お土産 3

萬年屋というところで味噌を買った。信州味噌はなかなか九州では買う機会がないので面白い。二年熟成の味噌を買った。

IMG_6025

コーヒー 2

この日のメインイベントはセラミカでの器購入だったがオープンが11時なので開店まで暇をつぶす必要があった。朝食のコーヒーがいまいちだったので年季の入った外観だが今風の若い人が載ってそうなチャリンコが停めてある喫茶店に入ってコーヒーを飲んだ。

IMG_6025IMG_6025IMG_6025

セラミカで散財

11 時になり満を持してセラミカに行った。山小屋泊ですっかり朝が早くなったので 11 時はもう夕方みたいに感じる…。皿を三枚とマグカップを買った。グラタン皿も良さそうだったが流石に高すぎた(一万円オーバー)。カード払いしたが二回分割したかったのに何も聞かれず一括で決済されてしまった…。ただ買った皿はとてもよい。何でもおいしく感じる。

IMG_6031IMG_6031

昼食 2

ホテルの近くに有名なそば屋があるようだったのでセラミカで買い物をしたあと行ってみたが、 11:30 オープンで 11:35 に着いたにもかかわらずすでに満席で店の外まで列ができていた。今から並んではバスセンターの集合時刻に間に合わなくなるので仕方なく別のそば屋に入った。この日は暑かったが鴨南蛮が食べたくてだらだら汗をかきながら熱いそばを食べた。

IMG_6025

散策

そばを食べたあと、ホテルに預かってもらっていた荷物を受け取り、ホテル横の湧水場で湧き水をナルゲンボトルに汲んだ。松本は市内各所でこのように水が湧き出ているようである。重いザックを背負いバスセンターまで 10 分ほど歩いた。松本は標高 600m あるとはいえ 8 月の日中は暑く、大量に汗をかいた。

インスタグラムスポット

途中、ふとん屋のたたずまいが良すぎて写真を撮った。ここは去年来たときも見かけて写真を撮ったが、去年は一眼レフを持ってきておらず iPhone でしか写真を撮れなかったことをとても悔やんでいた。

IMG_6025 IMG_6025IMG_6025

感想

松本は岳都や学都、楽都と言われるが、確かにそうだなと思った。北アルプス登山の足がかりとなる街で市内から北アルプスの山々の姿を見ることができる。また信州大学の本部があり旧制高校の松本高等学校もあって学問の雰囲気も感じる。ナンバースクールがあった熊本(第五高等学校)よりも貫禄がある。加えて音楽が盛んなようで、街中に小澤征爾の音楽祭のポスターが貼ってあった。どうやら市をあげて音楽振興に取り組んでいるようである。

生まれ故郷の阿蘇もかつては阿蘇登山の拠点として駅前に旅館がいくつもあり栄えていたが、自動車が普及し日帰りで訪れることができるようになって 90 年代にはそれらの旅館は全て廃業してしまった。松本はきっとその時代から変わらず岳都として栄え続けているのだろう。山の高さや数が阿蘇とは全然違うとはいえ、山岳観光都市として参考にできる点は大いにあると思った。

アルプス登山がてらまた行きたい。

| @労働

リモートワーク別に寂しくないし楽勝、みたいなコメント多いけど違和感あった。リモート楽勝という人はフリーランスとか受託の会社の人なのではないかと思う。自分のブックマークコメントは以下。

激しく同意。雑談したい、家族から家事を頼まれる、オフィスにいる連中から事業理解が低いと責められる、毎日服を着替える能力や通勤電車に乗る能力が失われる、などなど — http://b.hatena.ne.jp/morygonzalez/20180309#bookmark-359971190

「こいつはわかってない」問題

自分の場合は事業会社に所属した上でのリモートワークだった。事業会社(大抵のスタートアップもこれに含まれるはず)の場合はソフトウェアエンジニアにも事業やプロダクトへの理解が求められるので、リモートだとなかなか厳しい部分がある。事業理解は日々の MTG の他、オフィスで何気なく交わす雑談や昼飯の時なんかに醸成されるものだと思うので、リモートだと MTG での情報伝達密度が下がるし雑談や昼飯に至ってはそもそも不可能なので自分自身の事業理解も深まらない。仮にこちらに事業に対する理解があったとしても、それをオフィスにいる連中に伝えることが難しいので結局「こいつはわかってない」という烙印を押されることになる。リモートワークやってて同僚のエンジニアの皆さんとは友好関係を築けたと思うけど、 PM や上司とはなかなか良い関係になれなかった。

家庭内で仕事が軽んじられる

家族がいる人の場合は家族が「こいつ家にいてあんまり忙しくなさそうだから家事を頼もう」ということになりがち。自分の場合は子どもの幼稚園の送り迎え(バス乗り場まで)、幼稚園から帰ってきたあとの子守、洗濯物干し・取り込み、などを頼まれることが多かった。配偶者も仕事をしていて家事を分担する、ということなら当然やるけど、我が家の場合は嫁さんが習い事やヨガで忙しいので家事をやらなければならない、という感じで、自分の仕事は嫁さんの習い事よりも優先度が低いものなのだろうかと悶々とした。

社会適応能力の低下

毎日身支度をする能力、出かけていく能力も確実にむしばまれていく。転職してリモートワークからオフィスワークに切り替えて、朝の混んでる時間の電車に乗る通勤生活を再開してからの数ヶ月間は肉体的にも精神的にも非常につらかった。また家で仕事してると出歩かないので当然に運動不足になる。自分で意識してジョギングしたり体を動かしたりしないと確実に健康を損なう

自分がリモートワークに対して否定的な見解を持っているのは以上のような背景があるのであった。

良い面もある

もちろんリモートワークには良い面もある。

ワークライフバランス

子育てのための一時期や家族の看病が必要な時期には非常にありがたい制度だと思う。ワークライフバランスは非常に良好になる。

集中維持

コード書きに集中したいときにもリモートワークは便利だった。リリース前など、移動の時間も惜しんでコードを書きたいときには朝 10:00 から夜の 24:00 頃まで風呂とトイレと飯の時間以外はずっと仕事してたこともあった。それでも 10 時間は時間が空くので十分睡眠をとることはできる。これも前にブログで書いたような気がするが、いつでもオフィスに仕事しに行ける環境で、自分の裁量で週に数日リモートで仕事をするのが一番満足度の高い働き方になると思う。

地方都市に暮らしながらデラウェア法人で働ける

あとそもそも福岡では前職のような数十億円規模の資金を調達してがつんと成長しようとしているスタートアップの仕事にありつくことなんかは不可能なので、田舎に住んでいても都会のイケてる手法で仕事できてたのはリモートワークならではだったと言える(これも元記事に書いてある)。いまの職場でやってることは前職で身につけた1もの(スタートアップで働くエンジニアのディシプリン的なもの、あるいは技術顧問おじさんの素養)を土台にしているので、これは非常にありがたかった。

まとめ

ひとくちにリモートワークといってもいろいろな形態、状況があるので、↑の記事のブコメのように「リモートとか楽勝じゃね?」というコメントを読んでうかつにリモートワークを始めようとしている人がいたとしたらちょっと踏みとどまってもらいたいし、自分に向いているか、勤務先のビジネス領域・ビジネスモデルなども加味した上で決めてもらいたいと思う。

あとリモートワークだとコードレビューが甘くなりがちではないか、という問題もあるけどそれはまた別の話かもしれない。

References


  1. 当時は自分は全然成長してないと思ってた。こういうのを身につけたんだということはあとから気がついた 

| @技術/プログラミング

このブログの Archive ページ自分で作った Lokka Plugin でできているのだけど、ここを React を使って作ってみた。 React チュートリアルの写経の題材を自分のブログにした感じ。 CoffeeScript オワコンと言われて久しいけど Coffee で書いた。 JSX を CoffeeScript で書くときはバッククオートで囲むとよいという知見が得られた。

Entry = React.createClass
  render: ->
    `(
      <li className="entry">
        <a href={this.props.link}>{this.props.title}</a>
        <div className="detail-information">
          <span className="created_at">{this.props.created_at}</span>
          <Category category={this.props.category} />
        </div>
      </li>
    )`

| @技術/プログラミング

公開している Lokka の DB (MySQL) のデータを、手もとの Lokka の DB (SQLite) に取り込むときに毎回やり方を忘れるので書いておきます。

今回は MySQL to Sqlite converter という gist のコメント欄に書いてある以下の方法を試した。

sudo gem install sequel
sudo gem install sqlite3
sudo gem install mysql
rbenv rehash
sequel mysql://user:password@host/database -C sqlite://db.sqlite

これでデータを MySQL から SQLite に変換できた。Lokka をローカルで起動してアクセスしてみるが記事が表示されない。DB の中にはちゃんとデータが入ってるし、管理画面から記事一覧を表示するとちゃんと記事が表示される。どうも Post.published[] を返すみたい。

手でクエリを投げてみると

sqlite> select * from entries order by created_at desc limit 1;
             id = 960
        user_id = 1
    category_id = 5
           slug = eye-pro-is-shit
          title = Eye-Fi Pro を買ったけどクソだった
           body = [hitode909さんの日記](http://hitode909.hatenablog.com/entry/2013/05/24/093749 "hitode909の日記")...
           type = Post
          draft = 0
     created_at = 2013-10-06 07:28:00.000000
     updated_at = 2013-10-06 13:11:23.000000
frozen_tag_list =
         markup = redcarpet

draft = 0 なので表示されそうなもんなんだけど、よくよく調べてみると SQLite には Boolean 型がなくて、DataMapper は SQLite に Boolean 型のデータを保存するときは t/f の文字列で保存するみたい。これは盲点だった。

結局 draft = 0draft = 'f' に変えてあげればすべての記事を表示できるようになった。

| @技術/プログラミング

一月くらい前から Lokka の master ブランチを自分のブログ用のブランチに merge してサイトをデプロイすると謎の白画面が出るようになっていて困っていた。現象は極めて謎で、ローカルの開発環境(RACK_ENV='development')では見られず、本番(RACK_ENV='production')だけで発生した。HTTP ステータスコードは 1054 が返ってきたりする。なんか変な gem でも入れてしまったかなと休みの日に動作検証したりしていたんだけどついぞ分からなかった。

SQL 弱者なので気がついてなかったんだけど、2月15日の commit で Site モデルに新しいフィールドが追加されていた(Add default markup in admin/site/edit · 2243dc5 · lokka/lokka ※この機能便利すね)。なので bundle exec rake db:migrate しないといけなかったわけだった。ローカルで動いている開発環境(データベースは SQLite)では Migration なんて行ってないんだけどエラーは出なかった。本番は MySQL で動いていて、こちらでだけエラーが出るようだった。

しかしいざ migrate しようとすると失敗する。

bundle exec rake db:migrate
Upgrading Database...
rake aborted!
Invalid default value for 'updated_at'

のようなエラーが出る。updated_at のデフォルト値がおかしいらしい。このときのテーブルの構造を見てみると以下のような感じだった。

mysql> desc entries;
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| Field           | Type         | Null | Key | Default             | Extra                       |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| id              | int(11)      | NO   | PRI | NULL                | auto_increment              |
| user_id         | int(11)      | YES  |     | NULL                |                             |
| category_id     | int(11)      | YES  |     | NULL                |                             |
| slug            | varchar(255) | YES  |     | NULL                |                             |
| title           | varchar(255) | YES  |     | NULL                |                             |
| body            | text         | YES  |     | NULL                |                             |
| type            | text         | NO   |     | NULL                |                             |
| draft           | tinyint(1)   | YES  |     | 0                   |                             |
| created_at      | timestamp    | NO   |     | 0000-00-00 00:00:00 |                             |
| updated_at      | timestamp    | NO   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| frozen_tag_list | text         | YES  |     | NULL                |                             |
| markup          | varchar(255) | YES  |     | NULL                |                             |
+-----------------+--------------+------+-----+---------------------+-----------------------------+

調べてみたところ MySQL の Mode が NO_ZERO_DATE になっている場合、MySQL は timestamp 型のフィールドのデフォルト値に 0000-00-00 00:00:00 みたいな値を設定することを許さないらしい。 mysql - Invalid default value for 'create_date' timestamp field - Stack Overflow

検証用に別にテーブルを用意して bundle exec rake db:setup してみたところ、以下のような構造のテーブルができた。

mysql> desc entries;
+-----------------+------------------+------+-----+---------+----------------+
| Field           | Type             | Null | Key | Default | Extra          |
+-----------------+------------------+------+-----+---------+----------------+
| id              | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)          | YES  |     | NULL    |                |
| category_id     | int(11)          | YES  |     | NULL    |                |
| slug            | varchar(255)     | YES  |     | NULL    |                |
| title           | varchar(255)     | YES  |     | NULL    |                |
| body            | text             | YES  |     | NULL    |                |
| markup          | varchar(255)     | YES  |     | NULL    |                |
| type            | varchar(50)      | NO   |     | NULL    |                |
| draft           | tinyint(1)       | YES  |     | 0       |                |
| created_at      | datetime         | YES  |     | NULL    |                |
| updated_at      | datetime         | YES  |     | NULL    |                |
| frozen_tag_list | text             | YES  |     | NULL    |                |
+-----------------+------------------+------+-----+---------+----------------+

created_atupdated_atdatetime 型になるらしい。なので以下のような ALTER 文を実行した。

mysql> alter table entries modify column created_at datetime, modify column updated_at datetime;
mysql> desc entries;
+-----------------+--------------+------+-----+---------+----------------+
| Field           | Type         | Null | Key | Default | Extra          |
+-----------------+--------------+------+-----+---------+----------------+
| id              | int(11)      | NO   | PRI | NULL    | auto_increment |
| user_id         | int(11)      | YES  |     | NULL    |                |
| category_id     | int(11)      | YES  |     | NULL    |                |
| slug            | varchar(255) | YES  |     | NULL    |                |
| title           | varchar(255) | YES  |     | NULL    |                |
| body            | text         | YES  |     | NULL    |                |
| type            | text         | NO   |     | NULL    |                |
| draft           | tinyint(1)   | YES  |     | 0       |                |
| created_at      | datetime     | YES  |     | NULL    |                |
| updated_at      | datetime     | YES  |     | NULL    |                |
| frozen_tag_list | text         | YES  |     | NULL    |                |
| markup          | varchar(255) | YES  |     | NULL    |                |
+-----------------+--------------+------+-----+---------+----------------+

これで最新のコードをデプロイしても真っ白画面になることはなくなった。以前遭遇した更新時に created_at の値が更新されてしまう問題 もフィールドの型が timestamp だったのが原因なのだと思う。SQLite から MySQL への移行は一筋縄では行かないことが分かった。

DataMapper はソースコード内の記述内容から動的に Migration を行えるけど、ActiveRecord みたいに $APP_ROOT/db/ ディレクトリに Migration ファイルを作ってくれたりしないので DB スキーマの変更が必要なことに気がつきにくい。便利だけど不便な感じがする。Rails で $APP_ROOT/db/ 以下にアホみたいにファイルが出来ていくの嫌だと思っていたけど、スキーマ変更に気がつかずコードをデプロイしてウェブアプリケーション停止みたいな自体は防げると思った。

ブログ書こうと思ってパソコン開いて「ついでに最新版の変更を取り込むか」とかやるとデプロイできなくなったりして書きたかった記事が書けず残念な感じになる。はてなブログでブログ書いてて画面が真っ白になったらひとでくんさんに不具合報告して直してもらえば良いので楽だと思う。