returnえんじにゃー

学び直し中元エンジニアのアウトプットブログ。技術やものづくり。たまに猫。

Rail7のstatus: :see_other、status: :unprocessable_entityについてメモ

はじめに

Rails7でscaffoldした時にdeleteやupdateのredirect_toについてくるstatus: :see_otherstatus: :unprocessable_entity

前職で携わっていたRails5やRails6のプロジェクトでは見たことがなかったので調べてみた。

deleteにデフォルトでついている

  # DELETE /users/1
  def destroy
    @user.destroy!
    redirect_to users_url, notice: 'User was successfully destroyed.', status: :see_other
  end

なんなのか

status: :see_otherはHTTPステータスコード303に対応している。

新しくアップロードされたリソースではなく別ページにリンクする時にこのステータスを指定しないと、 一部のブラウザなどでは元のリクエストメソッドを使用してリダイレクトしようとするため、 二重 DELETE などの望ましくない動作が発生する可能性があるらしい。

Rails 7でデフォルトになったturbo-railsに対応するために必要らしく、 railsガイドでもこのステータスを指定することを推奨している。

※ button_to の場合は status: :see_other を付けなくても正常に動作する。

updateの方は?

  # PATCH/PUT /users/1
  def update
    if @user.update(user_params)
      redirect_to @user, notice: 'User was successfully updated.', status: :see_other
    else
      render :edit, status: :unprocessable_entity
    end
  end

なんなのか

status: :unprocessable_entityHTTPステータスコード422に対応している。

サーバーにリクエストが到達はできているけど、送られてきたデータが原因でリクエストを処理ができなかった時などに返ってくる(バリデーションエラーなど)。

このステータスを明示的に返してあげないとエラーメッセージが表示されない。

そもそもなんでついているのか(これから追記予定)

Rails7から標準になったgem 'turbo-rails'に対応させるために上記のようなステータスをちゃんと返す必要があるらしい。

参考

ActionController::Redirecting

Getting Started with Rails — Ruby on Rails Guides

422 Unprocessable Entity - HTTP | MDN

レイアウトとレンダリング - Railsガイド

Turbo Handbook

Rails7+Mysql8.0環境をDockerで構築したらOperation not permitted (ThreadError)

はじめに

エンジニア復職を目指しキャッチアップでRails7環境を作成したときに詰まったところをメモ。

起きたこと

参考記事を見ながら以下ファイルの生成&編集

docker-compose.yml, Dockerfile, Gemfile, Gemfile.lock, entrypoint.sh

そしてdocker-compose up --buildを実行!

・・したところ、下記エラーが起きた。

/usr/local/lib/ruby/3.2.0/open3.rb:223:in `detach': can't create Thread: Operation not permitted (ThreadError)

エラーファイルを追って見るとDockerfileのbundle installで起きているらしい。

なんじゃいと思いエラーを調べてみたもののいまいち解決方法が分からなかったが、以下の記事を発見。

RabbitMQ & Docker: Failed to create thread: Operation not permitted (1) - Stack Overflow

I add the same issue with Docker 18.03 , solved with docker v20.10

自分のDocker見てみると、Docker version 19.03.13。古っ!

今までは会社のPCを使っていたから、自分のPCの開発環境は3年前のもので止まっていた・・。

しかもDocker for Desktopからアップデートしようとしたところ最新の更新を取得できないというエラーが起きた。

とりあえず、まずはDockerを再インストールしてそこからもう一回様子を見てみる。

やったこと

brew update

今入っているDockerはDocker Desktopだったので、 今後の管理を兼ねてbrew installでDockerを入れられるようにまずbrew自体を更新

brew upgrade docker で失敗したので brew update しました。 #homebrew - Qiita

dockerアンインストール

MacでDockerを完全にアンインストールする3つの方法 - Dr.Buho

dockerインストール

brew install docker --caskを実行。

以下記事とおなじエラーが起きたので一度brew remove docker も実行した

Mac 向けDocker をHomebrewでインストールしようとしたらつまづいた話 #Docker - Qiita

再度docker-compose up --buildを実行

無事ビルド成功🎉

その後は参考記事の手順通りでRails画面まで到達。

感想

  • 後から色々調べたらおなじようなエラーが起きている場合、Dockerfileのbundle installのバージョンを指定したらよかっただけなのかも・・?まあでもこれからまた色々やるにあたりアップデートするに越したことはないのでよかった。

Docker環境でCould not find 'bundler'のエラーが出た時の対処法 | book-reviews.blog

  • このエラーを1個1個解決していく感じ、やっぱり楽しいなあと思った

参考

開発環境作成

【Docker】Rails 7+MySQLのDocker環境を構築する

DockerでRails7+Mysql8.0環境を構築してRspecを書くまで #Docker - Qiita

【初心者向け】Rails 7+MySQL 8.0の開発環境をDocker composeで作る方法 | Muscle Coding

Docker周り

HomebrewでDocker Desktopを再インストールするときに注意すること - とことんDevOps | 日本仮想化技術のDevOps技術情報メディア

MacにHomebrewでDockerをインストールする – インターステラ株式会社 技術ブログ

【Mac M1】Dockerのインストール方法

エラー調査

ThreadError can't create Thread: Resource temporarily unavailable · Issue #4353 · rubygems/rubygems · GitHub

Object-Oriented Conference2020に参加してきた。以下レポっす。

  • 2020/02/16に御茶ノ水女子大で行われたオブジェクト指向がテーマのカンファレンスに参加してきたので、レポ投下。
  • Object-Oriented Conference概要。
  • 敬称略です。
  • 駆け足でメモしたところがかなりあるので、間違っているところ、あいまいな部分かなりあると思います。
  • 詳細、正確な情報はYOUTUBEアーカイブをご覧ください!(自分も見返さなければ)(いつまであるかは不明)

基調講演

keynote: Object-Oriented Diversity

登壇者

成瀬 允宣(@nrslib)

概要

fortee.jp

スライド

speakerdeck.com

レポート

あなたのオブジェクト指向はなんですか?

『多様性』をうまく扱うために、ポリモーフィズム多態性)がある。

ポリモーフィズムは前後関係による文脈が大事、
  • 前後関係をうまく使うのがポリモーフィズム
  • 前後関係 は英語で『コンテキスト』。
  • 一連の中のコンテキストを恐れずに使ってほしい。
  • コンテキストを理解することが大切、多様性をうまく扱う。
  • コンテキストを理解すると、素直なプログラムが書ける。
ポリモーフィズムを恐れない為のアドバイス
  • 対話するとき
    • 例えば、カンファレンスで質疑応答するとき
      • もしかして、質問する人がつよつよにみえてる??まさかりコワイよね。
        • 質問が出るということは自己表現したいということ。
        • 好奇心旺盛になっている子供と一緒。そう思うと見え方が変わってくる。
  • コンテキスト、来歴を理解してあげましょう。

所感

  • ホールAでの発表だったが、すでに満席でYoutube配信をホールBでみた。
  • オブジェクト指向に関わらず、コンテキスト(前後関係)を理解するのはとても大切。来歴を理解することで、争いや誤解が生まれなくなる(はず)。生まれたとしても、建設的に話ができるのでは。
  • 質問される側の心構え的な話がでたが、質問する側も相手のコンテキストを理解した上で質問するの大切、とおもった。

セッション

DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか

登壇者

松岡(@little_hand_s)

概要

fortee.jp

スライド

little-hands.hatenablog.com

レポート

DDDとオブジェクト指向の関係

DDD
  • ソフトウェア開発志向の1つ。
    • 適用する対象の何らかの問題を解決するために導入される。
  • Domain Language(https://domainlanguage.com/ddd/reference/)
    • 本より読みやすいのでおすすめ。
  • モデリングから劇的な利益を得られたものからエッセンスを抽出する。
モデルとは何か?
  • まず、DDDでの『モデル定義』をしよう。
    • モデルとは問題解決のために物事の側面を抽象化したもの。
      • ドメインモデル
        • 現実世界をも問題を解決するモデル。
      • データモデル
        • DBに何かを永続化するモデル。
  • 今回はドメインモデルの話。
抽象化について
  • たとえば、履歴書
    • 履歴書の要素として、写真を貼る場所、履歴を描く場所などがある。
    • 上記の目に見える要素以外にもたくさん要素がある。
      • 履歴書のメーカーや紙の素材、書いているときの気持ち・・・etc。
        • すべての要素をモデルに落とし込むことはできない!
    • 抽象化とは、要不要の判断をすること。
よいモデルとは
  • わかりやすいモデルが良いモデルか?
    • No。問題解決ができることモデルが良いモデル。
よくないモデルとは
  • 問題解決ができない。
  • 実例
    • 採用管理システムで考える
      • 書類選考、一時選考、最終選考を考慮したシステムを構築しました!
        • 書類の前に面接があるんですけど・・・。
        • 求人の関係ない採用もあるんですけど・・・。
      • 上記のような柔軟な対応がむずかしい、となるとどうなるか。
        • 運用でカバー!!!(技術の敗北)
          • カバーできるレベルなら問題ない。
            • 他のUXと競う場合は完全に不利になる。
  • DDDの実装パターンを的確に反映して、まったくバグがないシステムを実装したとしても、拡張性がなければ利益は生み出せない。
よいモデルを創るには
  • ドメインに詳しい人にしっかり話を聞く。
    • しっかり会話をして得た知見をモデルにフィードバックする。
    • モデルは最初から完成しない、変わっていくもの。
モデルとコードが乖離してしまうと・・・
  • モデルの更新をコードに正しく反映できているか分からなくなる。
  • 案件に途中から入る人はコードから読む。
    • コードからモデルが理解できない、モデルからコード理解できないとソフトウェアとしての価値が低い。
  • モデルがそのままコードになっているのが望ましい。
    • 「オブジェクト」でモデルを表現したい。
  • モデルを継続した変更に耐えうるようにするためには、拡張性の高い設計が必要。
軽量DDD
  • DDDの実装パターンだけ取り入れる手法に意味はあるか?
    • 意味はある!
    • 拡張性の高いベストプラクティスを取り入れるだけでも十分価値がある。
    • コードがぐちゃぐちゃすぎるとできない。コード品質を上げると、漸くモデリングする余地が生まれる。
ドメインモデリングの方法
  • ユースケース図、ドメインモデル図だけつくる。
  • ユーザとアプリケーションの、相互作用を定義する。
    • ユースケース
      • 一般的なUMLのものと同じ。
      • ユースケースを具現しないとモデル出来ない。
      • 解決したい課題が解決できない。
    • ドメインモデル図
      • クラス図の簡易版。みんなでホワイトボードでかきかきする。
      • 振る舞いはいらない。属性も代表的なものだけでOk。
      • ルール、属性、ドメイン知識を吹き替えで記述する。
      • 集約の範囲を明記する
        • 集約は決めておいたほうが
        • 集約 =「かならず守りたい、整合性を持ったオブジェクトのまとまり」
  • 実際のモデリング方法はホワイトボードで殴り書き。
コードへの落とし方
  • アーキテクチャは代表者がざっと決めて開発を進める。
  • プレゼンテーション層 ⇒ アプリケーション層 ⇒ ドメイン層(エンティティ)の順番。
  • まず動くものを作りましょう!ひどいつくりでもOK。
  • その後、リファクタリングしていく。
    • ドメインモデルにかかれてる制約がアプリケーション層に実装されていた ⇒ ドメイン層に移譲する。
    • 整合性が保たれるし、アプリケーションがシンプルになる。
  • レイヤーによって書くべきことが決める。
    • レビューコメント論争を生まない為に。
    • コード全体に規律を持たせることができる
  • お手本コードを作る。
    • Application,Entity,Repository。
    • ドメインモデル図をもとに実装する。
  • 本を読む。
  • 手を動かしてみて、どう書き分ければいいんだっけ??と模索してみる。
    • 模索することで、モデリングの必要性を感じやすい。
    • どういうコードに落とし込まれるかをイメージできた方がいい。
    • DDDのコーディング、モデリングともに一発では難しい。
    • コーディング、モデルのどっちかだけうまくなることない。

質問

※ 質問はslidoより転載。

Q.既存のMVCベースのフレームワークを利用していると、オニオンアーキテクチャやクリーンアーキテクチャの適用が難しいなと感じています。MVCにおける○○はどのレイヤーなのか?このレイヤーは○○を利用すべきなのか、それとも別のクラスにすべきか?等で手が止まります。どのような手順で適用していくと良いのでしょうか?
  • A.Railsとかの場合、変にMVCを引きずるとぐちゃぐちゃになる。
    • オニオンで行くならオニオンで行く!と決めるほうがいい。
Q.集約単位の見極めが難しいのでは?こつはありますか?
  • A.本にもあるが下記2つ。
    • トランザクション範囲が大きくなってしまっているか?
    • 整合性保ちたい範囲はどこか?を決める
Q.モデルの新規作成や改善にあたっていきなりコードから入る人がいます。個人的にはいきなりコードに入る前にもう少し手前でたくさん試せればいいなと思うのですが、その方法についてアイデアはありますでしょうか?
  • A.価値を感じるまでが難しい。。
    • 話ながらいきなりボードに書き出す手法がある。(目の前で描かれると無視できない。)
Q.軽量DDDに価値がないとは思わないのですが、問題は軽量DDDを行って手元でコードを書いて満足してしまう、この状態でDDDをやってると思ってしまう人がいることだと思います。お話されたようなモデリングに向かうアプローチがあってこそのDDDだと思うのですが、そこに意識が無い人への対応など、何かお考えなどありますでしょうか。
  • A.自分が作ったシステムが本当に役立ってるか?というところに意識を向けることが大事。
Q.CQRS などの文脈で Query はレイヤーを両略してよいだとか、ORM を使ったシンプルな実装でよいという意見をよく見かけるのですが、データの解析やビジュアライゼーションがメインのアプリケーションで、複雑な Query ロジックをドメイン層で表現するのはありですか?(ドメインエキスパートはデータアナリストです)
  • A.クエリに寄せたほうがいい。更新系と参照系でオブジェクトを分ける。
    • 更新はオブジェクトの切り方、集計とかビジュアライズは参照の用途で違うので知識が混ざらないようにしたい。
Q.お手本のコードは詳しいひとじゃないと書けないですか?
  • A.やってみたいひと、強い意志がある人で進めればいい。
Q.軽量DDDはコードからDDDを導入する、とお話しがありました。例えば、ドメインエキスパートがもういない、すでに仕様をわかるひとがいない、レガシーなコードで保守だけでなく機能追加もある…みたいな案件で、それぞれの課題をクリアーにするために、軽量DDDは使えるのではないか、と感じましたが、松岡さん的にはアリでしょうか?
  • A.「コード汚い」という問題と、「仕様がわからない」という問題は違う。
    • 仕様がわからない・・「ドメインモデル図」を仕様理解のためにつかえばいい。
Q.golangでDDDはできますか?
  • A.できる!

所感

  • 技術書典で本を絶対買います!
  • 重要なことは「問題解決できているか」。DDDを導入することではない。
  • 問題の切り分けが上手になりたいなあ。
  • DDDは「やってみたいひと、強い意志がある人で進めればいい」という言葉に感銘を受けた。 自分には技術が足りないから・・とかで逃げない。責任をもって進もう。と思った。

オブジェクト IPPON グランプリ

登壇者

  • パネリスト Chatwork株式会社 加藤 潤一 (@j5ik2o) 株式会社バリューソース 神崎 善司(@zenzengood) 弁護士ドットコム株式会社 天重 誠二(@tenjuu99) 株式会社オージス総研 原田 巌(@iwaoRd)
  • モデレータ 株式会社チェンジビジョン 平鍋 健児(@hiranabe)

概要

fortee.jp

スライド

  • 見つけられませんでした。(見つけ次第貼り付けます)

レポート

UMLは何の略ですか?

  • 回答無し。

なぜオブジェクト指向

  • 考えるツール(神崎)

オブジェクト指向はClass?Message?

  • Scalaやってるとどっちもある(神崎)
    • プロログ以外の物はすべて入ってる。
    • 向いてるところで使えばいいと思っている。
    • 考えるツールと言っていたが、関数型も好き。自分で書くときは関数。対象をとらえるときはオブジェクト指向
    • 最近はテクニカルなものに興味なくなった
  • ユーザと話した時に、何を考えているんだろう?というときにオブジェクト指向で考えている。 どっか分析をしていて、Entityとしてとらえてる。(原田)
  • オブジェクト指向は自分の考え方に合うと感じる。(平鍋)
    • いまや分析論とまでになった。対象カテゴリを決める、知る、概念となってしまった。
      • オブジェクト指向はプログラムから生まれたと言われている。
        • ヒープ上にずっと残っているもの=オブジェクトだった。
  • 両方捉えられるものだと思っている。(天重)
    • アジャイルの言語でものをつくるとき、はやく作らなきゃ!ユーザと認識合わせなきゃ!同プログラムにつたえよう!設計⇒分析⇒要求というライフサイクルを回すことも近い。
  • Complexな状況に適応するため。(加藤)
    • 環境の変化に耐えられる。ひっくるめてこれにいきつく。
  • 存在たら占める何かを合意する。(原田)
    • 属性を切っていった後に見える本質。

DDDってオブジェクト指向?

オブジェクト指向GUI か?(天重)

  • アラン・ケイオブジェクト指向を産み出したと同時にGUIも生み出されたが、イコールになりうるか?(天重)
    • ~1995 YES 1995~ NO。(神崎)
      • まともなWindows機が出てくるまではそうだったが、今は違う。
    • モデルを渡すのではなく、モデリングをみんなでする。(原田)
      • GUIであろうが、ロジックだろうが、目の前で会話をかくだけで、モデルを残せる。お客さんはモデルに影響がある。 現場で6年間やって漸く理解して貰えてきた。モデルアーティファクトモデリングみんあでやった
    • UserAcount/rename("kato")(加藤)
    • イメージを捜査してシンボルに至るbyアラン・ケイ(天重)
    • アジャイルにつぶされた(平鍋)

コードがあればモデリングはいらない?

  • コードの量が多いのはしんどい。(平鍋)
  • エディターがどんなになっても便利になっても、10万行もあればわからないし、理解できない。(神崎)
  • マギシステムの付箋(エヴァ)。(原田)
    • マギシステムになにかあった時に、システムの裏に付箋が貼ってあって調整する。
      • こういう存在であってほしい。コードがあればいいということはない。
        • 設計意図がつたわる。モデルがあれば理解出来るというところを大切にしたい。
  • モデリングは仮説⇒コード・テストは実証。モデリングは図示、コード・テストは詳細。(加藤)
    • 二重管理は大変だがツールで管理すればいい。関連づいていないといけない。
      • 複数モデルは書く?(平鍋)
  • モデルはシミュレーション、コードは制約(天重)

好きなモデリングツールは?

  • パワポ(神崎)
    • マクロが書けるのでモデリングツールになる。最近はもっぱらパワポ
    • 要件定義とやる人と絡む際、相手の敷居が下がる。
  • ことば(天重)
  • miro.com or ふせん(加藤)
  • Aster(主に手書き)。(原田)

所感

  • OOCのデザインをみて、Ipponグランプリを思いついたらしい。たしかに!
  • そういえば、OOCのデザインはなんで黄色と黒なんだろう。
  • パネリストの方々は歴史というか原案てきな部分をしっかり網羅している。そこら辺の部分の理解の甘さを痛感した。本や原著をしっかり読んでおきたいと思った。
  • miro.com、使ってみたい。
    • 「モデルを渡すのではなく、モデリングをみんなでする」はとても大切だと感じた。DX。

概念投影によるオブジェクト指向設計の考え方とその方法

登壇者

hirodragon(@hirodragon112)

概要

fortee.jp

スライド

speakerdeck.com

レポート

前提

  • プログラミングの基礎があること。
  • そのうえで、設計をやってみたい。何からやってみてもわからない。設計活動の迷いとの闘いをしている人向け。
  • 何が正解かの捉え方の説明。
  • 設計活動の考え方。
  • DDDとか具体的な手法概念の説明しない。
  • Before Principal、Before pattern、Before Paradigm

設計を難しく感じる理由

  • 正解がわからない、何から始めればいいか分からない、GOALがわからない・・。
  • 設計が進んでいる道が分からない。
  • スタートラインがわからない
    • DB、画面設計書?クラス図?
  • ゴールがわからない。
    • ゴールなんてない!
  • 何かを覚えてやる、暗記でOK? 設計は暗記じゃない、論理が組みたっていないとできない。
  • 全体像を知っていると認識が違う。
    • 迷いはミスにつながる。
    • 自分の中に指針を持って設計すること。

アプリケーション開発とは

  • 現実世界の活動代行
    • 現実世界は意様々な活動を無数のアプリケーションが支えてる
    • 小人が中で動いているようだが、実際に小人はいない。
    • やりたいことをイメージすることが大事。ソフトウェア化の前提をクリアにしないといけない。

設計とは

  • 4w1h
    • What・・・小人がいる世界を作る
    • Who・・・エンジニア
    • Where ・・・コンピューターの中に
    • Why・・・代行させたい
    • Howが一番重要。
  • システム化したい領域を投影する。この無の世界に現実世界を代行してくれる新たな世界を作り上げる。
  • 世界を創世している、くらいのつもりで取り組む。エンジニアの力で、無から有へ。
  • ただし、コンピューターは現実世界を知らない。
    • 与えられた武器はプログラミング言語
    • ここに現実世界の「営み」を代行してくれる小さな世界を作り上げる
  • じゃあ、どうやって世界をつくるのか?
    • 概念投影。
      • コンピューターは現実世界を知らない
        • 設計をせずともプログラムは動く。簡単に作れる。
        • ただし、ほんとにコンピュータも理解してますか?
          • 例えば、コレクションを受け取って性別が"man"だったら配列に加え、男性だけのリストを返すとする。
            • 実際はコンピューターは不明な何かを受け取って、不明なプロパティが文字列の中と比較し、配列にいれて、出来た配列を返しているだけ。manとか知らん。
            • 無の世界に持ち込まれたのはプログラミング言語の作る世界のみ。
        • 人間は文字(man)を見て、自分の世界の概念と照らし合わせることにより無意識に認知ができる
        • コンピューターはプログラミング言語が成約した概念のみしか認知できない。
        • このようなギャップのことを『セマンティックギャップ』という。
          • 「認識が当たり前ではないと意図的に考えない」と、セマンティックギャップが認識できない。

概念を投影するとは?

  • 限られた武器でコンピューターに仮想的な現実世界を教えて存在させる必要がある。
  • 存在 = 実在ではなく『認識』できること。
  • 認識できる=『概念が定義されていること』。
    • 例) ゴルフクラブがある。これは存在か? 幼稚園児から見るとそれはただの棒。概念がない。 おじさんから見るとゴルフクラブ。概念を知っているから。
  • 概念を教えて仮想的な現実世界を作る ⇒ 概念を投影するということ。
  • 与えられた武器はプログラミング言語

公理と定義

  • 公理
    • 無条件で正しいと定められているもの。正しいという証明が不要なもの。
    • string、int、bool、dateなど言語が用意する型やClassも公理。言語が提供しているものは公理。
  • 定義

    • 公理をもとに新しく正しいと定めたもの。
    • ユーザー定義クラスなど。
  • 無の世界に投影させる際、公理の方のみ使用すると現実世界にある概念が存在しない世界となってしまう。

  • 定義は公理を使用して型を作るが、定義は人によって意味が異なる可能性がある。

Activity(営み活動)

  • 何かを売る・買うなどといった、アプリケーション有無に限らず存在する大前提。
  • Activityを表現するために必要な論理、ロジック。
  • アプリケーションを駆動するために必要だが、現実世界の営みに影響力を持たない。
  • 現実世界の営みを代行してくれる小さな世界を作り上げる

Domain Actibity

  • 例えば、「ホテルの予約」というような営みがあれば存在するもの。アプリがなくても別の媒体でできる。
  • ドメインモデリング
    • 必要な単語を洗い出す(用語集を作る)。小さな単位でまとめる。
    • 出てきたアクティビティに関するものをまとめる。
    • 作った単語集を少しステムに近づける 。
  • 概念投影
    • ドメインモデリングの対象者たちをアプリケーションに投影する。
    • アプリケーションが現実世界の知識をもつ (柔軟性をもつ)。

ApplicationLogic

  • Activityと混同しがち。ClassというよりInterface。

暗記しても意味ない。目的を実現するためのもの。

  • 手法や理論を用いる前にその活動が何を実現しようとしているのか指針を持つことが重要。
  • 概念の投影により、仮想世界に現実世界を存在させる概念投影指向という考え方。
  • 投影されたすべては単一で存在する概念。Atomicな存在まで概念を分析する。
    • オブジェクト指向ではClassとして表現される。
    • 単一債務、関心の分離 設計せず複数の債務監視を持った処理作成など。
    • 概念投影指向の概念はすでに単一で分離する必要がない。
    • 単一な概念を統合するとDomainとして表現が膨らむ。

表現としてのふくらみ

  • レイヤードアーキテクチャ

    • Port- Adaptor
      • Application Logicとして投影されている
  • 契約による設計

    • 関数シグネチャに型を指定そ、各振る舞いの事前条件や事後条件を制限する。
    • 契約したい概念はActivityとApplicationLogicとしてアプリケーションの世界で認識できるようになっている。
    • あとは契約を描くだけ。公理の方のみでは契約書けない。
  • DDD
    • Domain蒸留サイクルの中心に据えた設計方法。
    • 概念投影と相性良い。
    • Activityの洗い出しをするドメインモデリングをする際にできたモデルをアプリケーションに落とし込む。
    • ドメインがアプリに振り回されることはない戦略設計に基づいて、ドメインを蒸留していく。

所感

  • 主催者の方の話が聞けたのはあつい!
  • 内容えもい。我々は世界を作っている。そのくらいの気持ちが大切。
  • 概念の話、「散歩する侵略者たち」という映画を思い出した。
  • 最初のコンテキストの話にも通じるものがあった。
  • 公理と定義の考え方、何かを考えようと思ったときに一番最初に考えるための指針として持っていようと思った。

オブジェクトライフサイクルとメモリ管理を学ぼう

登壇者

ariaki(@ariaki4dev)

概要

fortee.jp

スライド

speakerdeck.com

レポート

  • オブジェクトはどこからどこへ行くのか。
  • 星の数ほど作り出されるオブジェクトにどんな意味があるのか?

メモリ管理

  • CPUの中にレジスタがあり、内部データを保管している(x64系は16個ある。64*16)
  • フロントサイドバスがメモリからCPUに転送する。
  • CPUの中でメモリとやりとりをするがかなり低速。x64系はメモリがキーとなっている。

  • New object(); されたとき何がおきるか

    • object生成⇒格納先候補(アドレス)⇒変換テーブル⇒実格納先。
    • new object();⇒ 論理アドレス ⇒ ページテーブル ⇒ 物理アドレス
    • 変換テーブルを参照する理由はいろいろあるが、セキュリティのためもある。
  • x64アーキテクチャでは?

    • OS <-> RAM間は64bit単位で読み書きされる。
    • 64bit中48bitがメモリアドレス。(最大256TB)
    • 48bitが5つの箱に入っており、それぞれのテーブルが次のテーブルの場所を差している。
    • 具体的なオフセットアドレスを差している。
    • MMU(メモリマネジメントユニット)がメモリのアドレスを割り当ててる。
    • アドレスが変換された対応表のTLBがある。
      • TLBがあれば、高速にアドレスを引き出せる。TLBがあるからこそ今日のCPUが速い。
        • ただし、あるせいで攻撃されることもある。
      • if文などの分岐の処理をCPUが先読み実行出来る。
        • ブランチ両方を先読み。
        • 実行して成功率が高くなければ成功率下がる。
        • 投機的実行。突き詰めればもっとはやい処理が書ける。
    • メモリ要求用に応じて4kb、2mb、1GBごとに区切られたページが確保される。
    • 仮想~物理の対応はページテーブルで管理。
    • 頻繁に使われるアドレスはTLBにキャッシュ。
    • ページテーブルはOSが定義しているが、動作はCPUの機構。

メモリアロケータ

  • プログラム ⇔ メモリアロケータ ⇔ OS-CPU
  • malloc()
    • 確保したいメモリサイズに応じて自動で最適なサイズを割り当てる。
  • メモリサイズごとに異なる領域を確保。
    • fastbins < 160
    • bins> 160
  • 大きなメモリはmmap命令。
  • freeしても内部的にはキャッシュしていることある。
  • chunk単位で確保。8byteでアラインメントされている。

アラインメント

  • アラインメントとは、メモリ使用教を キャッシュラインにあわせること。

      • short・・・2byte
      • int・・・4byte
      • float・・・4byte
      • double・・・8byte
      • char・・・1byte
  • アクセスに無駄がなく、高速に読み書きできる

  • CPUによってはアラインメント違反はエラーになる未使用領域が発生する。
  • アラインメント最適化
    • キャッシュライン+高級言語の仕様。
      • メモリがどのくらいひつようかは、言語仕様をを読み解かないといけない。

スタックとヒープ

  • スタック
    • 確保・解放が速い。
    • 寿命が短い。
    • サイズ小さい。
      • コールスタック
        • 関数様に確保されている。ローカルの変数等。
        • 関数ごとにスタックフレームという枠を作ってデータを入れている。
        • 積んでいることで、そのリターン後に自動で破棄される。
  • ヒープ

    • 確保・解放が遅い。
    • 自分で寿命を決められる。
    • サイズ大きい。
    • 参照型の実態を持つ。
    • 好きなだけ好きな時に割り当てられる。
    • 誰かが解放しないといけない。
  • CPUの中で処理できるデータは64bit(xbit)

  • メモリの読み書きを頻繁に行っている。
    • 高速に保つためCPU内でN次キャッシュをもつ。
    • アクセス速度はバスクロック/メモリクロックに依存する。
    • オブジェクトで管理されるメモリ領域はアラインメントされる。
    • 大きなオブジェクトはの確保は重い。

オブジェクトの正体

  • New object(); -> オブジェクトヘッダとオブジェクト実体ができる。
  • オブジェクトヘッダの言語ごとの実装
    • Javaについては割愛してしまいました・・(スライドを参照くださいませ)

    • PHP5

      • ZVAL構造体
      項目 内容
      refcount 参照カウンタ
      type 型を示す文字列
      is_ref 参照集合かどうかを判定するbool値
    • PHP7

      • ZVAL構造体
      項目 内容
      interned 文字列がインターン化された状態
      refcount 参照カウンタ
      is_ref 参照有無
      • interned(インターン化)

        • 同じ文字列を共通領域に保管し、個別にメモリを確保せず参照する。
        • 数値などの他の方は対象外。
        • どれくらいメモリを使ったか。
        • 最初から定数と持っているものはメモリをかくほせず、インターン文字列としている。それ以外は別途メモリが確保される。
        • 変数は実態は別にある。
          • 箱の中に文字列が入っている(実際のメモリ)を参照。
            • リンクが切れた(参照が終わった)場合hrefcountが0になる。
              • GCの対象になる。
              • ref_countは実際にデータを参照しているのが何個あるかを示す。
      • コピーオンライト

        • $ar2 = $ar1;の時点では$ar2のメモリは確保されない。
        • $ar2[0] = 1;の時点で値が複製(コピーオンライト)される。
        • 配列に値を一個ずつ突っ込むと、8個ごとにメモリを追加確保していることがわかる。
          • 8倍ごとにメモリが追加確保されている?
        $ar1= ['a','b','c'];
        $ar2 = $ar1;
        $ar2[0] = 1;
        unset($ar2);

GC(Garbage Collection)

  • GCとは

    • 不要になったメモリ領域を自動で回収する仕組み。
    • 今年60周年。
    • 主要な言語ほぼすべてに採用される。
    • メモリ使用量が一定の閾値を超えたら実行される。
    • メモリリークが発生する。
  • 代表的なアルゴリズム

    • 参照カウント・・・オブジェクトの参照数が0のもの。
    • マークアンドスイープ・・・未使用のオブジェクトをマークした後に削除。
  • 循環参照するとメモリが残り続ける。

    • unsetしたとしても、PHPが判定できない。
    • GCが発生するタイミングでクリーンされる。
  • PHPGC

    • 参照カウント方式。
    • GCコレクトサイクル。
    • unsertで即座にアクセスできなくなる。
    • オブジェクトが10000件達するまで削除されない。
    • 三色マーキング
      • 白色・・・GC前。
      • 灰色・・・到達した。
      • 黒色・・・到達済み。

まとめ

  • 設計だけじゃなく、プログラムの中の設計にも目を向けてみよう!

所感

  • がっつり低レイヤーの話!むずかしかったけど面白かった。
  • メモリ管理、普段考えられてなかったけど今後はしっかり考えてきたい。
  • 言語(同じ言語でもバージョンによって)によってメモリ管理の仕方が違うということがざっくり理解できた。これから使う言語(ruby)についても調べてみよう。

タイトル

オブジェクト指向システム開発

登壇者

株式会社メディアドゥ 濱口賢人(@kent_hamaguchi)

概要

fortee.jp

スライド

  • 見つけられませんでした。(見つけ次第貼り付けます)

レポート

まず、オブジェクトの定義をしよう!

  • システムそのものもオブジェクトである。
  • 設計は仮設提唱。
  • 苦しまない開発をしたい。

オブジェクトって何?モデル?

  • そもそもオブジェクトとは? ふるまい、構成要素、hogehoge?
  • 本セッションはでは、『唯一の振る舞いであり、それを支えるための洗練された構成をもつこと』と定義してみる。

各レイヤーのオブジェクト

  • 横と縦で考えてみる。

      • 組織観点
      • プロダクト観点
      • システム観点
      • インフラ観点
      • ソフトウェア観点
      • 組織観点 -> 組織論、人間論、コンベイ・・・。
  • 組織もオブジェクトなのでは。定義があって、インスタンスが立っているイメージ。

  • システムもオブジェクト。

各レイヤーをオブジェクトとして見てみる。

  • クリーンアーキテクチャー。
  • 上位レイヤーのオブジェクトは論理性が破綻しているととつくれない。
  • 成果物が目的に成り立たず、破綻する。
  • 仮説
    • 目的への達成方法を論理設計する。
      • ソフトウェア開発は論理的なコンピュータを扱う。
      • 故に論理的に成り立っているべきである
      • HOWTOからはいっていっても、結びつかないと意味がない。
  • 証明

    • 仮説を結果へ成果物を作成し実証する。
    • 論理的。筋的に成り立つものであれば実装できるべきである。
  • オブジェクトを支える仮説実証の流れをアジャイルスクラムで回していく。

    • コーディングに入った途端分からなくなる、ゴールを見失う。
    • 振る舞いはなんとか担保できても、内部構造が破綻する継続的な改善できない。
    • そもそも後から理解出来ない

これはゾウですか?

  • 組織のトップレベルで話されているが、セクションが分かれすぎてそれぞれの部署の話しかしてない。
  • 大きい組織でなればなるほど裁量が分かれていってしまう。
  • 全体を視座を上げる。
  • 事実に基づく信憑性のある仮説を立てて、結果を直視する。
  • 仮説たてながら事実に基づいた正しいふるまいのオブジェクトを蒸留する。

半面直感を大事にする

  • いろいろ考えても、結局机上の空論。
  • 直感を検証なしにこねるのはよくないが、素早く検証し事実か確かめることは大切。

オブジェクトを使う目的

  • 個人にしても組織にしても、社会に対して何を提供し恩恵を出すのかが大事。
  • 最終的には人が価値を判断する。

オブジェクトを支える

  • オブジェクトが期待されるふるまいを続ける。
  • ゴールに沿った論理設計を行い、コードはそれらを素直に表現できること。

所感

  • 『セクションが分かれすぎてそれぞれの部署の話しかしてない』はめちゃくちゃあるある・・小さいチームでさえ起こりうる。
  • みんなが視座を上げるために、どのようなことをしたらいいんだろう。前職(現職)では自分だけ空回ることが多かった。
  • 直感を大事にする、という言葉は今回初めて出てきた。方式も大事だが、経験もすごく大事だよなあ。
  • 何にせよ、フットワーク大事。

全体所感・気づき・メモなど

  • まだゴリゴリにオブジェクト指向を理解できているわけではないから、すこし緊張しながら臨んだが、DDDの話やモデリングの話などコーディングにとどまらない話が多くとても面白かった。
  • 相手と考えをすり合わせるツールとして、オブジェクト指向がいかに便利で有用か分かった。もっと理解するためにも、まずはしっかりコーディングを勉強したいと思った。
  • 御茶ノ水女子大の建物素敵だった。
  • きなり屋のラーメン、うまかった。
  • 自分で考えつつまとめるのうまくなりたい。議事録てきな、スライド読んだ方が早いみたいなまとめ方しかできないな。。。

レポっした。

ClassicASPでセッションタイムアウトを20分以上に設定する(IIS)

はじめに

現在携わっているシステムはいわゆるレガシーシステムというやつで、
ClassicASP&VB.Script(ブラウザはもちろんIE)という、どの懇親会に行っても失笑される(または何それみたいな顔をされる)システムたちを保守しているのだが、
最近「セッションタイムアウト時間を20分から1時間に変更してほしい」という依頼が来たのでいろいろ設定した際、なかなかめんどくさかったのでメモ。

やったこと

IISでの設定

ASP.NETの資料は大量に出てくるのに、ClassicASPの資料全然出てこおへん・・と思いつつ
下記サイト様を参考に、まずWEBサイト>該当のアプリケーションを開き、セッション状態>Cookieの設定内のタイムアウトを設定してみた。

参考
https://blog.goo.ne.jp/greenracoon/e/b8f62f2c640e3cdd143aa67cb60be5b5
https://codeday.me/jp/qa/20190304/358777.html

セッション状態をクリック。

タイムアウトはデフォルトで20分なので、60分に設定してみて、まずは30分後に様子見。


しかしタイムアウトしてしまった。しかも20分で。

むむむ‥と調べたところ、どうやらWEBサイトだけでなく、そのサイトが乗っているアプリケーションプール(DefaultAppPool)の設定をしないといけないらしい。
※ WEBサイトで「インプロセス」という設定をしていると、アプリケーションプールの設定を有効にするらしい。




なので、試しにアプリケーションプールの設定を5分にしてみて、5分後に確認してみたところ5分でセッションが切れた!

これを5分⇒60分にして再度様子を見たところ・・・・またしてもタイムアウトしてしまった!

どうやら20分で切れてしまっている模様。

他の各設定を必死にさがしたところ、
ASP』の中の「セッションプロパティ」「制限プロパティ」のなかにもタイムアウト設定箇所を発見。


そこにあったのか・・・!

こちらも20分になっていたので、とりあえずどちらも1時間に延ばして様子をみたところいけた!

アイドルタイムアウトの優先度的には、アプリケーションプール>WEBサイトの設定なんだろうけど、
そもそもWEBサイトのセッションが先に切れてたらそりゃどうしようもないわな、というような話でした。

そして、よく調べりゃ出てきてた・・・。

参考
http://classicasp.blog.fc2.com/blog-entry-10.html
https://culage.hatenablog.com/entry/20100618/1276786

まとめ

普段IISを意識したり触ったりしてこなかったので、もっと勉強する必要があると反省した。。
また、先人の尊さを敬いつつ、きっとこの世界の片隅で私のようにレガシーなシステムたちに苦しんでいる人たちがいると思うので、
そういう人たちの救いになれるようになるべくこういうことも発信していきたい、そう思ったのでありました。唐突なマザーテレサ感。

おわり。

GASでWEBスクレイピングしてSLACKBOTでドーン!!ボガーンや!!!!~GASでWEBスクレイピング編~

前置き(飛ばしていいやつ)

先日、我が社に「Slack」が導入された。

「あ~~ん???Slack???今更何言ってんだこいつ今時どこのIT企業でも入ってるやろォ???なあにを高らかに宣言しとんねんボッケェ~~あと普通弊社っていうやろカスゥ~~」と思われた方もいるだろう。

そうです。その通り。あなたの言う通り。間違いない。大正解です。どうぞ、スーパーひとし君人形です、ご査収ください。
あと、弊社って言葉はなんか嫌いだからあんまり使いたくないの。分かっていただけるぅ?

ゴホン。話を戻します。

私が所属する会社はIT企業なのになぜか最新の(『最新じゃないけど我が社にとっては最新』の意)ツールや技術等に非常に及び腰なのである。

そんな我が社で「Slack」が導入されるという事は非常に目覚ましい進歩、
はいはいをしていた赤ちゃんが時速60kmではいはいができるようになった、
みたいな感じなのである。いや結局はいはいなんか~~~い。(どんがらがっしゃん)

ゴホンゴホン。

さて、その導入された「Slack」を遊び尽くすべく、無意味なリマインドを大量に入れて同僚に嫌われたり、先輩の顔写真のスタンプを大量生成し先輩に嫌われたりしながら 充実したSlackライフを満喫していたのですが、一つ問題が生じました。

「『記念日』が負担になっている問題」である。

上記、決して「恋人が記念日を各週単位で設定してくるからマジ重たくてつらたんオブザイヤー受賞」というリアルガチ記念日の話ではない。

我が社のSlackのチャンネルに『記念日』というチャンネルがある。
Slackが導入されたことがあまりに記念的出来事だったので、私がおもわずチームメンバーとその他を巻き込んで作成したチャンネルだ。

作成した当初は「なんやんねんこのスレ」「邪魔くさい」と盛り上がっていたものの、 見切り発車で作ったものだったので、数日後には誰も書き込みもしない見もしない過疎チャンネルとなってしまっていたのが、 8月のある日突然メンバーの一人(私の上司)がこのような書き込みを投稿し始めたのだ。

f:id:kurunaki1117:20190930123434p:plain

えなにこれ怖、と思って最初は無視していたが、次の日も次の日も同様の投稿を毎朝書き込んでくる。

どうやら、このチャンネルを再活用すべく(という名目でふざけたいから)、『記念日』にちなんで「本日の記念日」を毎日書き込むようになったらしい。
その結果、おかげでこのチャンネルを通じ「こんな日あるんや」「こんなの記念日にする必要あるんか」というような会話から雑談が始まる、活発なチャンネルに生まれ変わったのだ!

自分が作ったチャンネルが活用されていくのはとても微笑ましくもあり、 これからもこのチャンネルを通して楽しくコミュニケーションを取っていけるのだろう、そう思っていたある日。

上司がぽろっと私にこうこぼしたのだ。

「記念日投稿するの超負担」

衝撃である。

どんなに忙しい時も、毎朝記念日が載っているHPから記念日をコピペし、メモ帳で若干加工したものをSlackに張り付けなくてはいけないという義務感が彼にとってかなりの負担になっていたのだ。

そんな状況を目の当たりにした私は、自ら勝手に始めたおふざけ行為で苦しんでいる上司を救うべく、立ち上がった。

「GASでWEBスクレイピングしてSlackBOTでドーン!!ボガーンや!!!!」

~完~

いや前置き長~~~~~~。

やったこと(本編)

  • GASでWEBスクレイピング(スクレイピング用のライブラリを使用)。
  • GASからSlackにメッセージ送信(SlackAPI)。
  • 上記メッセージは決まった時間に投稿する。(GASのトリガーを使用)

今回は『GASでWEBスクレイピング』の部分をまとめたよ。

GASでWEBスクレイピング

ライブラリの導入

まず、下記HPを参考にHTMLをパースしてくれるライブラリを導入してみる。

Easy data scraping with Google Apps Script in 5 minutes
https://www.kutil.org/2016/01/easy-data-scrapping-with-google-apps.html

下記ブログを参考にしました。導入からメソッドまで丁寧に解説してくださっているので、とても便利!

参考
GASで簡単WEBスクレイピング!HTMLを簡単にパースできるライブラリParserを使ってみた
https://www.kotanin0.work/entry/2019/01/06/200000

取得するHPを確認。

今回取得したいのは、下記HPの今日の記念日のところ。しまくとぅばって何。

参照
雑学ネタ帳 -今日は何の日・明日は何の日-
https://zatsuneta.com/category/anniversary.html

f:id:kurunaki1117:20190930123050p:plain

上記HPをChromeデベロッパーツールにてHTMLの構造を見てみたところ、 下記の様に3つの記事のdiv要素が同じclassが設定されていた。

f:id:kurunaki1117:20190930123119p:plain

<!--▼ 今回取得したいHTML--> 
<div class= article>
    <h3> 今日 9月18日(水)の記念日・年中行事 </h3>
    <p></p>
    <ul>...</ul> 
    <p></p>
</div>
<!--▲ 今回取得したいHTML--> 
<div class= article>
    <h3> 明日 9月19日(木)の記念日・年中行事 </h3>
    <p></p>
    <ul>...</ul> 
    <p></p>
</div>
<div class= article>
    <h3> 9月の記念日・年中行事一覧 </h3>
    <p></p>
    <ul>...</ul> 
    <p></p>
</div>

私が欲しいのは一番上の今日の記念日の部分。上手に取得できるかしら・・と思ったがそこはさすがのライブラリさん。
下記のように記述するとこのようにデータを取得してくれる。

データの取得

  • URLにアクセスし、HTMLを文字列として取得
  • その文字列の中から、<div class= article>で始まり</div>で終わるデータで、 一番最初に見つけたものを文字列として取得

ソースは下記。

 // URLを記述
  var url = "https://zatsuneta.com/category/anniversary.html";
  
  // 対象のURLにアクセス
  var fetch = UrlFetchApp.fetch(url);
  
  //HTML文を取得
  var html = fetch.getContentText();

  // <div class="article">で始まる</div>で終わるHTMLで最初に見つかったものを文字列で返す。
  var data = Parser.data(html).from('<div class="article">').to('</div>'.build();

  // logにてデータ確認
  Logger.log(data);

上記の実行結果はこんな感じ。(ブログを書いている日(9/30日)で実行)

画面 f:id:kurunaki1117:20190930123858p:plain

[19-09-30 11:37:13:039 JST]
<h3>今日 9月30日(月)の記念日・年中行事</h3>
<p>
<ul>
<li><a href="https://zatsuneta.com/archives/109304.html" title="世界翻訳の日(9月30日 記念日)">世界翻訳の日</a></li>
<li><a href="https://zatsuneta.com/archives/109301.html" title="クレーンの日(9月30日 記念日)">クレーンの日</a></li>
<li><a href="https://zatsuneta.com/archives/109302.html" title="くるみの日(9月30日 記念日)">くるみの日</a></li>
<li><a href="https://zatsuneta.com/archives/109303.html" title="紅葉の見頃予想発表日(9月30日頃 記念日)">紅葉の見頃予想発表日</a></li>
<li><a href="https://zatsuneta.com/archives/109305.html" title="交通事故死ゼロを目指す日(2月20日・4月10日・9月30日 記念日)">交通事故死ゼロを目指す日</a></li>
<li><a href="https://zatsuneta.com/archives/109306.html" title="クミンの日(9月30日 記念日)">クミンの日</a></li>
<li><a href="https://zatsuneta.com/archives/109307.html" title="両親の日(9月30日 記念日)">両親の日</a></li>
<li><a href="https://zatsuneta.com/archives/109308.html" title="奥様の日(9月30日 記念日)">奥様の日</a></li>
<li><a href="https://zatsuneta.com/archives/109309.html" title="ニッポン放送 HAPPY FM93の日(9月30日 記念日)">ニッポン放送 HAPPY FM93の日</a></li>
<li><a href="https://zatsuneta.com/archives/10930a1.html" title="翻訳の日(9月30日 記念日)">翻訳の日</a></li>
<li><a href="https://zatsuneta.com/archives/101302.html" title="EPAの日(毎月30日 記念日)">EPAの日</a></li>
<li><a href="https://zatsuneta.com/archives/101305.html" title="サワーの日(毎月30日 記念日)">サワーの日</a></li>
<li><a href="https://zatsuneta.com/archives/10110k5.html" title="キャッシュレスの日(毎月0の付く日 記念日)">キャッシュレスの日</a></li>
<li><a href="https://zatsuneta.com/archives/109217.html" title="秋の全国交通安全運動(9月21日~30日 記念日)">秋の全国交通安全運動</a></li>
<li><a href="https://zatsuneta.com/archives/109246.html" title="結核予防週間(9月24日~30日 記念日)">結核予防週間</a></li>
<li><a href="https://zatsuneta.com/archives/10901c.html" title="歯ヂカラ探究月間(9月1日~30日 記念日)">歯ヂカラ探究月間</a></li>
</ul>
</p>

いい感じに取得できましたね。
今日は世界翻訳の日なんだって。へ~~。

こんな感じで.build()を使って該当するHTML文字列が取得できましたが、今度はその中の「記念日」の文字列たちを全て取得したい。
その場合は.iterate()を使う。これは、文字列の配列が返ってくる。
ソースは下記。

   // さっき取得したdataの中から<a><li>タグ内の記念日を配列として取得する
  var day = Parser.data(data).from('">').to('</a></li>').iterate();

  // logにてデータ確認
  Logger.log(day);

今回の取得の仕方は.from('">').to('</a></li>').とちょっと力業・・。
.from('<a').to('</a></li>').というように指定したところ、下記の様に<aから</a></li>までのすべての文字を持ってきてしまった。

[19-09-30 12:14:52:234 JST] [ href="https://zatsuneta.com/archives/109304.html" title="世界翻訳の日(9月30日 記念日)">世界翻訳の日,  

HTMLとして認識しているわけではなく、ただの文字列の中から探してくれているんだもの、そりゃそうだ。
なので、直前の要素かつ汎用的にデータが取得できるぎりっぎりの所をむりやり探して取得させた。

実行結果はこう!ちゃんと配列でとれてるとれてる!

[19-09-30 12:03:18:154 JST] [世界翻訳の日, クレーンの日, くるみの日, 紅葉の見頃予想発表日, 交通事故死ゼロを目指す日, クミンの日, 両親の日, 奥様の日, ニッポン放送 HAPPY FM93の日, 翻訳の日, EPAの日, サワーの日, キャッシュレスの日, 秋の全国交通安全運動, 結核予防週間, 歯ヂカラ探究月間]

これで取得したデータをday.join('、')で句読点で結合してあげて、logで出力したらほれ!できたできた~~!

[19-09-30 12:08:59:161 JST] 世界翻訳の日、クレーンの日、くるみの日、紅葉の見頃予想発表日、交通事故死ゼロを目指す日、クミンの日、両親の日、奥様の日、ニッポン放送 HAPPY FM93の日、翻訳の日、EPAの日、サワーの日、キャッシュレスの日、秋の全国交通安全運動、結核予防週間、歯ヂカラ探究月間

データ取得側はこれでおーけー。
あとはこれをSlack側に流すぞ。

まとめ

思っていたより長くなってしまったので分ける。完全に前置きのせい。
次は下記についてまとめる。

  • GASからSlackにメッセージ送信(SlackAPI)。
  • 上記メッセージは決まった時間に投稿する。(GASのトリガーを使用)

以上!!!!!!!!!!!!!!!!!!!!!!!!(厚切りジェイソン風)

既定のプログラムを変更する

SQLファイルを開こうとすると、いつもSSMSが立ち上がってしまい、接続状態がないときは時間がかかるわぜんぜん表示されないわでめんどくさかったけど放置していたところ、
ある日仕事でPostgresSQLをインストールしたら、SQLファイルをたたくとPostgresが立ち上がるようになってしまったので、これを機に変更。

 

下記パスにて設定を行う。

コントロール パネル\プログラム\既定のプログラム\関連付けを設定する

 

確認すると、やはりPosgresに変更になっていた。。(デフォルトでそうなるのかな)

f:id:kurunaki1117:20180327101831p:plain

 

いつも右クリックでEditorで開いていたので、既定のプログラムをEmEditorに変更。

f:id:kurunaki1117:20180327101757p:plain

OKを押すと、下記に変更になった。

f:id:kurunaki1117:20180327101916p:plain

別に大したことはしていないけど、いつもめんどくさいなあと思うことを放置しがちなので、小さいところから無駄を省いていきたい。と思う。