コード日進月歩

プログラミングの技術的なメモなど

echoした文字列を権限を超えて付け足したい場合はteeを使うと安全かはさておき楽

タイトルがすべてを語っているTips。

ケース

  • すでにexportした環境変数を永続的に使うために書き出したい
  • echoして /etc/environment などに書きたい
  • sudoしなきゃいけないのでただのリダイレクトだとできないので他の方法でやりたい
  • シェル芸でなんとか設定ファイルのProvisioningをしたい

方法

$ echo TEMP_VALUE=$TEMP_VALUE | sudo tee -a /etc/environment

-a オプションは追記なので、付けないとまるっと今までのがなくなってしまうので注意

(じぶんが考える)向かないケース

  • ゼロから起こさないファイルに継ぎ足しするとき
  • シェル以外である程度ファイルを構成しても問題ないとき

『Webサイト』をつくる上で必要なドメイン知識

先日、とある人と会話していたときにふと思ったが、Webサイトを作る上のドメイン知識って

  • ホームページはどうやって作られているか、HTMLとはなにか
  • 動的ページと静的ページの違い
  • PC向けとスマートフォン向けで考えねばならないUXとは何か

みたいなものってのは割とWebサイト開発に関わるみんなが持っている知識なんだけど

  1. 検索から来ることを主体としたWebサイト
  2. 何かの媒体(紙や他のサイト)からくることを主体としたWebサイト
  3. イントラネットで使うようなWebサイト

こうなると同じ「Webサイト」のように見えて、必要なドメイン知識はかなりかわってくる。

  • Aの場合は検索エンジンからちゃんと補足してもらえるような作りをしなければならないし
  • Bの場合はどの媒体から来たかをちゃんと作る機構を考えなければ行けないし
  • Cの場合は使われるイントラネットの環境がどのようになっているか知らないと行けない。

こう考えるとひとくちに「Webサイトづくりをしたことがあります」と考えて『経験者だから安心』と仕事をお願いするととんでもない認識の落とし穴がありそうだなと思った。


この話の発端は主に上で話をしたところで、格別流入Googleからの検索に頼るようなサービス出ない限りはSEOというものを考えないサイト構成になる。それこそエンジニア主導だとRESTfulであるかとかそういうことに考えが行きがちである。

ただの別アプリから使われるAPIなら構わないが、SEOを考えるWebサイトの場合は話が違う。

いかに自然にわかりやすいか、直感的であるかというところがベースにあり、あとはGoogleが提唱する要素を適切に配置できているかが重要になってくる。昨今、Webサイトへ立ち寄るきっかけなんてググるSNSの誘導が主たるものなので、ちゃんとGoogleから覚えめでたくないと人がそもそも集まってこない。

このGoogleからどうやったら気にかけてもらえるかというのは

  • サイトマップの作成と送信をちゃんとやる
  • ページの読み込みスピードが早い
  • 構造化データを用意する

みたいな話だとは思うが、この知識はタグの書き方だったり、どういうデータをサーバに置くとかなので、技術的な知識も入る部分。特にサイトの設計段階で見誤るとGoogleには解釈しにくいサイトを作ってしまうとかが発生しうる。

ただこういう知識は前段で話した、Aのようなサイトを開発しないと勘がはたらかないし、それらに対する実装アプローチも持ち得ていない。

仮に敏腕でやり手のWebディレクターがいたとして、とてもユーザにとってよいサイトを作ることができても、Aの観点でサイトが構成されていないと悲惨な結果になるのではないだろうか。

Webサイトをつくるのは、難しい。

参考サイト

binding.pryの強制終了方法

デバッグ用途で binding.pry を入れたはいいが、ループ内に仕込んでしまったので exit をしてもずっと聞かれ続ける しかも Ctrl + C とかでも止まらないし…みたいな人ためのメモ

方法

exit! もしくは !!!

参考リンク

編集後記

  • 結構みんな知らないということに気づく。
  • むしろ binding.pry も存在を知らない場合がある
  • 投稿したつもりが反映されてなかったやつ

BigQueryで作ったクエリは保存できるし、共有もできる。

BigQueryはSQLだし、手元に違う形でクエリを残しがちだけど、普通にUI上で保存したり共有したりすることができる。

プロジェクトで保存すると、同じBigQueryを覗ける人はリンクさえわかれば編集もできる。

編集をしてほしくない場合はpublicなクエリとして公開すれば共有できるので、日々の集計とかやる場合はオススメ

忙しい日は本当にデモコードを暇もないので違うことでお茶を濁す

activerecord-importでバルクインサート / バルクアップデートする

Railsのデフォルトで大量のデータをinsertすると、1レコードずつinsertするのでDBが悲鳴をあげる可能性がある。それを防ぐgemとして activerecord-import があるのでそれを使う。

このgemはupdateも一気に出来るのでそれも紹介する。

環境

rails (5.1.5)
activerecord-import (0.23.0)

インストール

以下を Gemfile に追加

gem "activerecord-import", "~> 0.23.0"

使い方

素のActiveRecordに使う場合はgemがインストールしてれば使えるので特に設定等の追記は必要なし。

一応色々やり方はあるんですが、割とシンプルな方法を今回はご紹介。

bulk insert

{{テーブルのモデル}}.import {{insertしたいモデルを持つ配列}}

みたいな感じなので、実際は以下の感じ。(動作未検証)

names = ["Taro","Ziro","Sato"]
users = []
names.each do |name|
  users << User.new(name: name)
end

User.import users

bulk update

{{テーブルのモデル}}.import {{updateしたい値に差し替えたモデル}} on_duplicate_key_update: {{アップデートしたいカラムのシンボルの配列}}

みたいな感じなので、これも実際は以下の感じ。(動作未検証)

no_name_users = User.where(name: nil)
update_users = []
no_name_users.each do |users|
  users.name = "NoName"
  update_users << users
end

# nameだけUpdate
User.import update_users  on_duplicate_key_update:[:name]

参考サイト

一般的なシステムとゲームシステムの垣根

こんなTweetがあった

仮想のプレイヤークラスからコマンド情報を送信すると同じプレイを再現出来るって話です。

これってWebテストフレームワークの文脈で行くとSeleniumも同じようなことやっているなーという気持ちになり。

いわゆる一般的な業務システムとゲームシステム(主にクライアント側)って結構各々独自の進化をしてきたんですが、だんだん同じ道を歩いている部分があり、そこの垣根や重なる部分が絶対あるはずで、そこを歩み寄れたり、お互いの長所を取り込めたら幸せなことがあるんじゃないかなと思ったりした。

雑記として今日書きたかったことはそんな感じです。

『あしたの現場で役立つ「システム設計の原則」と「越境」のはじめかた』に行ってきたよメモ

業務がめちゃくちゃ忙しい最中だったが、あしたの現場で役立つ「システム設計の原則」と「越境」のはじめかた - DevLOVE | Doorkeeper に行ってきましたのでメモ

発表メモ

speakerdeck.com

上のスライドベースで 現場で役立つシステム設計の原則 の著者 増田さんと カイゼンジャーニーの著者 市谷さん、新井さんの対談形式だったので アジェンダごとに各著者の方々のコメントをさらっとまとめています。

双方から見た本の感想

増田さんから見た「カイゼンジャーニー」

  • 自分が見てきたことがマイルドに再現された感じ

市谷さん、新井さんから見た「現場で役立つシステム設計の原則」

  • 新井さんとしては「増田さんが語りかけてくる」そんな本
  • 市谷さんとしては、今の時代にフィットさせたオブジェクト指向を読み解くための本

何故この本を書いたのか、書いてみてどんな変化が起きたか

「現場で役立つシステム設計の原則」増田さん

  • Javaの入門書とDDDの間の本がないということで企画が持ち上がり、その折に自身の考えをまとめてもいいかなという観点で書き始めた
  • 変化としては周りの反応が多く、自身の周りでしか得られなかったフィードバックがネットなどを通して得られたのが大きかった

カイゼンジャーニー」市谷さん、新井さん

  • 仕事を「自分事」として考えてやってもらう人が増やしていきたいという思いで書いた。
  • 執筆後のフィードバックとしてみんながやっているだろうと削ろうとおもっていた「振り返り」のあたりが書いてくれてありがとうというフィードバックがあったりと気づきがおおかった

執筆の裏側

「現場で役立つシステム設計の原則」増田さん

  • 書き始めてからかなりの時間が経過してしまった
  • ただ言語化することはとてもいいことだということに気づきがあった。なかでも最初のプレビュー版で知り合いにレビューしてもらう過程でいろいろな忌憚のない意見がもらえて、すごく勉強になった部分があった

カイゼンジャーニー」市谷さん、新井さん

  • 同じく言語化するということはとてもいいことだと感じた
  • 2017年11月に新たなスクラムガイドができたが、作成にあたり読み返したりした際に原文と翻訳でいろいろな解釈があるなと再認識できて学びがあった

それぞれの本で最も言いたいことは何か

「現場で役立つシステム設計の原則」増田さん

  • コードを書こう、良いコードを書こう
  • 良いコードを書くためには設計スキルが必要だし、そのためには分析のスキルが必要となるのでドメインに興味を持つが大事

カイゼンジャーニー」市谷さん、新井さん

  • 受け身で仕事すると辛くなってくるので、やはり自分ごととして働く人が増えてほしい。そういうものの取っ掛かりになれば。(新井さん)
  • 上手く行かない人、良くない場所などいろいろな関係性の中で開発することはある。その中で色々と選択肢を選ぶことになるが、その選択肢幅を広げてほしいという意図で作った。(市谷さん)

どんな問題を扱うのか、問題の根幹・本質を見定める方法、問題解決のアプローチ方法

「現場で役立つシステム設計の原則」増田さん

  • 問題意識は冒頭に書いたとおり、変更しにくいコードを作らないためにどうしたらいいか。
  • 基本のアプローチは入出力の処理とビジネスルールの計算をどうやって分離するかという部分。
  • 本の中ではビジネスロジックの作り方に焦点を当てている。

カイゼンジャーニー」市谷さん、新井さん

  • 人にまつわる問題を解決するためにフォーカスを当てた本、どうすれば人にまつわる問題を解決できるか。
  • 両方の書籍に言えることだが、暗黙知の露出、開発側とそうではない部分にある暗黙知を露出させて共有することがドメインの成長につながる

何を学ぶのか、学び方のコツ、教えた方のコツ

「現場で役立つシステム設計の原則」増田さん

  • コードやプログラムを動かすこと、テクニカルな技術に興味があるのは大前提のはずなので、その動かすプログラムの内容を知るべき。
  • その内容とはすなわち業務内容なので、もっと業務内容に関して興味を持ち、ロジカルのようでロジカルでない業務ロジックを見つめていく。

カイゼンジャーニー」市谷さん、新井さん

  • カイゼンジャーニーは何故ジャーニーかというと、当事者が成長していくことを描きたかった。一足飛びでは成長できない、土台を積み重ねていくからことたどり着ける。適当ではなく、計画的にそれらをやっていかないとうまくいかない。
  • 経験則というのは重要、怖がらずにやってみる

どのように始めるといいか

「現場で役立つシステム設計の原則」増田さん

  • 自分がやる気になればできることなんて実は山ほどある。はじめてみて三日坊主みたいに挫折することもあるけどネガティブに捉えずまた気が向いたら始めればいい、そうやって続けていくことが大事。

カイゼンジャーニー」市谷さん、新井さん

  • 自身のタスクの見える化、分解、前工程と後工程を見ていくなど自分の範囲でやっていく。それがうまくできたら徐々に広げていく。
  • 自分がこうしたいと描く妄想は大事、それを持ちながら行動していくことでいつか上手く周り始めることがくる

大喜利(質問コーナーパート)

Q.DDDを行うにはプログラマとビジネスの人達との相互理解、協働が必要と思います。とはいえバックグラウンドや経験が全く違うので大きなギャップがあるのも事実です。そのギャップを埋めるために先ずは何から手を付ければ良いでしょうか?
  • ドメインエキスパートも普通の人間なんで、相手の言うことはヒントとしてとらえ、ドメインエキスパートに過度な要求はしない
  • このまま歩み寄れないと気づいたときはどちらかが埋めるしかない、相互理解をして初めてプロダクトを作り上げる足並みが揃うのでそれを大事にする
  • 業務の言葉がわからない、認識がずれているというセンサーは大事。ズレているんじゃないかセンサーはマックスにあげて、違和感をすぐに察知していくことが重要
Q.増田さんの本では型を定義してそれを使うことを推奨されていたと記憶しています。個人的には好きな方法ですがプロジェクトのORMと合わなかったりで断念することが多いので、折衷案があれば・・・
  • フレームワークを変えろ!
  • モデルとドメインオブジェクトとDBのレイヤを分けることに執着してほしい
  • ドメインオブジェクトとテーブルとのダイレクトなマッピングはしない
  • 処理的にはオーバーヘッドだけど、やるだけの価値はある
Q.システム設計の原則にすべて従って開発したらクラスとテーブルの数がえらいことになると思うのだが非正規化をどうされてますか
  • 経験上おかしくならない、ただビジネスルールはミスリードすると起きうる
  • 関心事ごとにテーブルわけるとすっきりする
  • 事実の記録は正規化するが、集約したデータ用のテーブルをつくる事実の設計と集計は別の切り口を使うと良い
Q.お三方の経験として、人の問題とコードの問題が同時に起きていて大変だったと言うことはありますか?そういうときにどういうアプローチをとって解決されたのか気になります。
  • 人の問題って体力と精神力を使う。疲れることもある。
  • 仲間と人担当とシステム担当など、軸足を変えるような担当分けをするのも良い。
  • コードもチームの問題もぐちゃぐちゃになったものを全部改修するのは無理。手がつけられそうなところから少しずつやる
Q.ドメインモデルの綺麗さと、パフォーマンスとの兼ね合いが悩ましい
  • 業務的に正しく表現できてればパフォーマンスが出るのではない
  • コードをチューニングするよりもハードで殴る
  • どういう設計でどういうパフォーマンス条件の時に問題がでるかは興味範囲

全体を通しての感想

  • ドメイン駆動のスライドを漁るようになってから増田さんのお名前を拝見するようになり、「現場で役立つシステム設計の原則」を読んで自分の中でのちょっとしたパラダイムシフトが起きたぐらい感銘を受けた本の一つなので、今日も姿勢という観点で参考になる部分が多かった。
  • 「現場で役立つシステム設計の原則」はコードに対して、「カイゼンジャーニー」は人に対してシステム開発を行う経験則やアプローチを語ったものであり、どちらも『自分の手の届く範囲から変えていき、そこで成功体験を得たら隣人に、チームに、組織に広げていく』ということを薦めている話なんだなという感じなんだなと思った。
  • 今日の話のエッセンスを日頃の開発業務に転換していきたいなと思った。
  • カイゼンジャーニーには未読なのでポチった。

関連リンク

テーマとなった本