Twitter以上ブログ以下

ただの読み物

Twigを外部Templateファイル無しで使う

この記事で分かること

Twigの亜空間殺法(嘘)

背景

自前でTemplateEngineみたいなことをしようとしたときに、そもそもPHPでTwig使ってるんだからそれ使えば良くない? ってなったので、調べた。結論を言うとやりたいことより複雑性が高かったので今回採用はしなかった。

Twig はこちら

Twig for Developers - Documentation - Twig - The flexible, fast, and secure PHP template engine

コード

なんかPHPシンタックスハイライト効いてるのか効いてないのかわからん……

use Twig_Loader_Array;
use Twig_Environment;

$targetTxt = "You are {{ replaceText }} ?";

$loader = new Twig_Loader_Array(['index.html' => $targetText]);
$twig = new Twig_Environment($loader);
try {
    $res = $twig->render('index.html', ['replaceText' => 'hogehogewww']);
} catch(Exception $e) {
    var_dump($e);
}

$res; 
// "You are hogehogewww ?"

Twig_Loader_Array でインメモリに index.html をKeyとしてTemplateを束縛。 束縛したTempleteをRenderするときに連想配列で置換したい内容を挿入。

なるほどなぁ。

マネーフォワードを退職した

この記事でわかること

とくにないです

背景

退職した。退職エントリだがレギュレーションとかを遵守した(つもりになった)やつは社内向けに書いた。 興味がある人はマネーフォワードへ入社してみてください。esaに多分残ってます。残ってるよね……?

内容

5/31 が退職日です。 5/25 が最終出社日です。

間がなかったのは有給がもうなかったからです。

6/1 からは新しい場所で働き始めます。

MFで学んだこと、知ったこと、なるほどなぁと思ったこと一覧です

  1. お金に対する忌避感を拭えた話
  2. 真っ向から技術力で殴ることの大切さと、難しさ
  3. 現金はある程度あればよくて、ほかはガンガン投資に回すとよさそうなこと(投機じゃないよ)
  4. 職業お金持ちは職業お金持ちなんだなぁということ
  5. 田町という街
  6. 事業の大切さ
  7. 本音と建前と社内と社外と……そんな様々な境界面にこそなにか大切なことがありそうだなぁという軽い気持ち
  8. 情報が閲覧できることの大切さ
  9. 自由と責任
  10. お金は大切

おわりに

おすすめのETF教えてください

zshrcに書いてある適当な関数を紹介する

この記事でわかること

特になし

git で upstream と merge する関数

なんで?

fork branch 運用をしていると originhaito/repo で、 upstreamoriginal/repo になる。 定期的に original/repo から持ってこないとたいへんなことになる。

関数

function upstream_update() {
    branch=$1
    git add . || git commit -m "upstream update cunked!" > /dev/null
    git checkout $branch > /dev/null
    echo "fetching upstream..."
    git fetch upstream
    echo "merging upstream..."
    git merge "upstream/${branch}"
}
alias uu="upstream_update"

これを uu develop とすると、 current branch は適当に commit して、 develop に checkout して、upstream の develop と merge する。

小文字英数字の uuid を発行する

なんで?

rubySecureRandom.uuid と振る舞いを合わせた uuidgen

関数

function lower_uuid_gen() {
    tr '[A-Z]' '[a-z]' <<< `uuidgen`
}

このまま実行するだけ

雑にメモ帳を開く

なんで?

わからない……俺たちは terminal の呪縛から解き放たれた……はずなんだ……

関数

function je() {
    filename=$1

    e /tmp/$filename
}

junk emacs の略だと思う。 いろんなOneNoteとか、BearとかEverNoteとかいろいろ試したけど、何故か無理なのでこうなった。

Vue + slick (jquery plugin) でハマった話

この記事でわかること

背景

気持ちとしてはこういうことをしたかった。

vueシンタックスハイライトが効かなかったので別々で……

<template>
  <div class='cards is-slick'>
    <div class='card' v-for="element in elements">
      <element></element>
    </div>
  </div>
</template>
export default Vue.extend({
  data() {
    return {
      elements: []
    }
  },
  methods: {
    async getElements(){ HTTP.get('/api/elements').map(x => Element.new(x)) }
  },
  // mounted か created かはともかく
  async created() {
    this.elements = await getElements()
  }
})

雰囲気はわかってくれると思う。雰囲気はね。 で、問題は <div class='cards is-slick'>slick でカルーセルにしたい。

なので、とりあえずこうやって見る

// ...
mounted() {
  $('.is-slick').slick()
}

これは動かない。何故かと言うと、 slick はそのイベントが発火した時点のdivしか補足できず、新たに読み込まれた div はカルーセルの対象外になってしまうためだ。 つまり

  <div class='cards is-slick'>
    <div class='card' v-for="element in elements">
    </div>
  </div>

この状態で slick() を発火しても意味がないということだ。 これをどうにかしたい。

ずさんな解決方法

つまり、全てのElementが用意された時点で slick() を発火してやれば良い。

export default Vue.extend({
  data() {
    return {
      elements: [],
      isSlicked: false
    }
  },
  methods: {
    async getElements(){ 
      await HTTP.get('/api/elements').map(x => Element.new(x)) 
    }
  },
  async created() {
    this.elements = await getElements()
  },
  watch: {
    elements(vals, oldVals) {
      if (!this.isSlicked) return;

      $('.is-slick').slick('unslick')
      this.isSlicked = false
    }
  }
  updated() {
    if(!this.isSliced) {
      $('.is-slick').slick()
    }
/**  2018/02/16 11時05分 更新
    this.$nextTick(() => {
      try {
        // 既に slick() してあるElementに対してもう一度発火すると落ちる。
        // 逆に、まだ slick() していないElementに対して `unslick` を発火しても落ちる。
        // ほんに〜〜〜〜〜?????????
        $('.is-slick').slick('unslick')
      } catch(_){ 
      } finally {
        $('.is-slick').slick()
      }
*/
    })
  }
})

updated$nextTick() を使うと全てのRenderが完了してから呼ばれる。 これで解決したけど、ずさんすぎる気がする。 たぶんComponentのライフサイクルの設計が間違っているんだと思う。

誰か良さげな回避策を教えて……ください……

  • そもそも slick を利用しないという選択
  • ルーセルくらい自前で作れるだろ感
  • etc...

rails で cookies を使ったテストをrequest, feature spec ではない書き方でテストするための方法が知りたい

この記事でわかること

request spec や feature spec ではない、 cookies だけをどうにかして取り出してテストを書きたいフレンズが、テストを書けるといいなぁって思えるようになる。 ただし、厳密には違う。違うんだ……どうしたらいんだ……教えてくれ…………(ほんとう?

背景

例えば以下のようなコードでテストを書きたかった

# app/models/state.rb # めっちゃだめなクラス名だな……
class State
  class CookiesAdapter
    def initialize(cookies)
      @cookies = cookies
    end

    def transition!(key)
      @cookies['state_transition'] = { value: key }
    end

    def in?(key)
      @cookies['state_transition'] = 
    end
  end

  def initialize(adapter)
    @adapter = adapter
  end
  
  def transition!(key)
    @adapter.transition!(key)
  end

  def in?(key)
    @adapter.in?(key)
  end
end

class HogeController
  def show
    @state = State.new(State::CookiesAdapter.new(cookies))
  end
  # ... 
end

State インスタンスの振る舞いは、実際には hogeAdapter の同名のメソッドを呼ぶことで、上の実装では CookiesAdapter しかないが、まぁRedisなりなんなりのAdapterがあればいい感じに振る舞いを分離できて幸せそう。 AdapterPattern のようなナニだ。

で、Cookiesを使いたい時に、 Rails では ActionDispatch::Cookies に実装*1があり、他にもあるが一番わかり易いのが ActionDispatch::Request#cookies_jar*2Cookies::CookiesJar.build 経由で cookies_jar を作って、その alias として cookies*3でのアクセスが実現できている。

困ること

  1. Cookies を直接インスタンス化するために必要なパラメーターがわからん(調べればいいんですが)
  2. request spec として、リクエストが透けた形で↑のモデルのテストを書きたくない
  3. feature spec として以下略
  4. ActionControllerインスタンス化でもいいけど、なんかもう少し上手いやつないかなぁ

ということでテストの書き方二種

二種? というのは、rails のバージョンで異なるため。古いバージョンとかは知らない。4.2は古いっていうのは、はいそうですね。

rails 4.2

RSpec.describe State::CookiesAdapter do
  let(:cookies) { ActionDispatch::Request.new({}).cookies }

え、なにそれ辛い。辛いというか、 とくに new({}) あたりが、「本当にそうなのか」がワカラナイ。 一応、 Rails.application.env_config でよいっぽいというStackOverflowの気持ちを見ることができるが、ほんと〜?となる。

unit testing - Setup cookie.signed in Rails 5 controller integration tests - Stack Overflow

rails 5

RSpec.describe State::CookiesAdapter do
  let(:cookies) { ActionDispatch::Request.empty.cookie_jar }

https://github.com/rails/rails/blob/master/actionpack/test/dispatch/cookies_test.rb#L12 rails が 自らのテスト↑で @requestRequest.empty で作成してそこから cookie_jar を取ってる。( 厳密には cookies_jar )

なんか結局イマイチだけど、まぁ rails がそうやってるなら、まぁいいんじゃないかな? となる。

おわりに

  1. rails5 を使おう
  2. そうでないなら ActionDispatch::Request.new({}).cookie_jar で一応取れる。ほんと〜?

河辺

拝啓

おげんきですか? 僕は元気です。

はじめに

壁 AdventCalendarが前回あったのは、 2015年である。

adventar.org

もはや知る人ぞ知らなくて良い、伝説となった(伝説のまま誰にも語り継がれず、そのまま闇に葬ったほうがよさそう)壁 Advent Calendarだが、 去年は「今年は?」「え、今年はやらないんですか?」「そんな馬鹿な」みたいに本人をつっついても全く本人が動かなかった。

そうして、世界のすべてが「なかったことにしたかった」壁アドベントカレンダー、それが

ということで帰ってきた。

何が言いたいかって、特に言いたいことはないよ。

本文

壁とは一体何かを考える。 物理的、あるいは精神的、抽象具体、様々な形式を用いて壁を認識することができるだろう。 壁、それは一人ひとりの解釈による部分が多く、また世界そのものは世界中の生命体の認識の最大公約数、あるいは認識によるだと定義したとして、その世界における壁とはつまり全ての生命体が「壁」と認識するもの、それはつまり何なのだろうかと思考するに、それはすなわち壁、なのではないか。壁という概念、壁という認識、壁という虚像に虚構に抽象に具体が混じり合ってもまだ壁と考えうる壁、それはすなわち壁、壁ってナニか?という疑問に対して招聘するは壁という認識そのもの、思考において壁を壁と認識した時に壁は初めて壁となり、そうでないものは壁とならず壁は壁たり得ないためそれは壁でなく、では元々何だったのかというと壁ではないなにかでしかなく、つまり僕達が今壁と考えうるものは全て壁であり、思考が思考する為の土台、壁が壁たりうる為の壁は、すなわち個々人の認識、いや、全ての思考する某の認識に依って壁が壁として起立するのである。壁とは本来何を指し示すかなどこの世界においては一切の意味はなく、壁が壁として認識される思考される事そのものに意味があり、壁が実際に、この言葉は間違っておりつまり、壁が「壁」として物理的に、つまりこの地球上に壁としてラベル付された形で壁があってもそれが全ての思考する某によって、壁として認識されなければそれは壁ではなくただのナニかに成り下がるわけだが、しかしであるならばそこにある壁というラベルは一体何なのか、この答えを出すためにも壁という概念についてより深く、より洗練された考察を導き出し演繹し、壁が壁たりうる為の思考する某の共通項を導き出すこと、その為の問いを今我々は壁として認識してしまっているがため、この概念の坩堝に対して何を振りかざしたところで思考の壁を超越し、壁を壁として俯瞰的に、概念的にあるいはよりもっと高度な次元から課題という壁を認識し、いや、そもそも次元という壁を認識してしまっている時点で壁を真に俯瞰して、客観して観察することは出来ないのではないだろうかという思考もまた、一つの壁ではないだろうかと考えうるに、世界の万物は、あるいは思考する某そのものもまた壁なのではないかと考えうるわけだ。

おわりに

kotobank.jp