Somurie Engineer's Blog

AWS+BitnamiWordPress環境でLet’sEncryptを更新した

はじめに AWS・BitnamiのWordpressを使っているんですが、Let’sEncryptの更新が失敗したので更新手順をまとめます。 急に安全ではない接続になった ある日ブログを見たらHTTPS対応しているはずなのに鍵マークに黄色い△マークが・・・。この接続は安全ではありませんとの表示もされているのでLet’sEncryptのはじめての更新(3ヶ月毎更新)に失敗したのだろうと察し、直しました。 更新をしてみるとエラーが発生 手作業で更新をしてみると以下のエラーが発生。初回の発行コマンドでもダメ。前回こんなの発生した記憶ないけど何か変わったんでしょうか。 ./letsencrypt-auto has insecure permissions! 修正手順 ほぼ こちらの手順通りでうまくいきました。 Let’sEncryptをキレイに再インストールしたかったのですが、既存のLet’sEncryptがインストールされた場所からの削除・今のドメインの失効コマンドは諦め(上記と同様のエラーが発生するため)。 やや汚いですが完了とします。次回更新うまくいくと良いな・・・

JSUG勉強会2019その7ビズリーチにおけるSpringの活用に参加した

ビズリーチ社内で実施されたJSUG勉強会に参加してきたのでまとめを書きました。 Contents 1 勉強会概要 2 1部 クラウド時代だからspring-retryフレームワーク。 2.1 プレゼン内容 2.2 所感 3 2部 フレームワーク移行で学ぶ Spring Boot のつまづきポイント 3.1 プレゼン内容 3.2 所感 4 3部 これで怖くない!?コードリーディングで学ぶSpring Security 4.1 プレゼン内容 4.2 所感 5 全体所感 勉強会概要 勉強会名: ブログ記事_JSUG勉強会2019その7ビズリーチにおけるSpringの活用 場所: ビズリーチ社(渋谷駅) 日時: 2019/7/12 19〜21時 1部 クラウド時代だからspring-retryフレームワーク。 渡邉 祐さん (株式会社ビズリーチ)による発表でした。

6月振り返り

総括 5月に続き、AtCorderとDDDに力を入れた。 AtCorderについてはABCでD問題までは普通に解けるようになってきた。競技プログラミングらしくDPが結構できるようになってきたのは実力がついてきたと実感している。 DDDについては副業として仕事を頂くことになったため、実践で学ぶ形になった。 新規開発であり、SpringBoot最新バージョンを採用している。ツール類もメインで入っている職場と異なる点が多く、キャッチアップに時間がかかっている。 Achived 開発 AtCorder大会に週1で参加。400点問題までは解けるようになった DDDの書籍「現場で役立つシステム設計の原則」を読み終えた DDDの書籍「エヴァンス本」は読み終えない。一旦実践を優先するため諦めた(3割完) Springの勉強(SpringMVC、SpringBoot、SpringSecurity、SpringDataJPAの浅い所を一通り) 「Spring徹底入門」の読書(6割完) GitHub上で複数人開発。Issue、ラベル、プルリク等の出し方 IntelliJ Ultimateの使い方。IntelliJ内の用語概念、ショートカット、LiveTemplate等(本格的なJava開発でIntelliJを使うのが初めて) 「IntelliJハンズオン」の読書(完読) Bulmaの概要理解(副業で扱うため) インフラ なし IT基礎 なし 英語 なし Problem AtCorderで有向グラフが理解できていない AtCorderでDPのパターンによっては解けない(パターンが色々あるのでももう少し経験を積みたい) Springの知識不足 腱鞘炎は椅子を変えたら調子よくなった。適切な位置に肘置きがあるだけで手首の負担が大幅に減る Try for next month 次の現場向けに何らかシステムを見せられる状態にしたかったが副業が開始したため一旦そちらに注力する DP、有向グラフは大会で確実に解ける状態にする Springの書籍を読破する(浅く広く大まかな構成とできることを頭に入れる) Java9、10、11、12の新機能サンプルプログラムを書く Springに関して記事を書く。始めてみて感じたことがテーマ 8月末にどういった状態でありたいか JavaかRailsの何らかのシステムが出来上がっていること → これは諦める(年内は無理そう) ブログが見せられる状態であること DDDに関する意見を書く 簡単なプログラムを書いて、ブログで説明する AtCorderとGitHubのリンクを貼る GitHubが見せられる状態であること → 簡単なプログラムのサンプルは上げたい AtCorderが見せられる状態であること

「プロダクトをつくるとはどういうことなのか? -正しいものを正しくつくる-」にZoom参加した

はじめに 以下セミナーに参加したので内容をまとめました。 セミナータイトル: プロダクトをつくるとはどういうことなのか? -正しいものを正しくつくる- 参加スタイル: Zoom参加 プロダクトづくりのためのソフトウェア設計スタイル(増田さん) メモ 創発的な設計活動では、局所的な仮設と実験を繰り返すことはできるが、全体に視野を広げる必要がある 答えがあるわけではない。仮設と実験を繰り返す 動いたから正解ではなく考察をすることが必要。 オブジェクト指向より前に型がある。 作っているうちにこの型よりこの型が良いねといった形で改善していく ビジネス活動の関心事夫々に対して設計実装の型とする データの重要度が見えてくる。処理の文脈から画面/テーブル間の関係性に気づくことができる 型や計算にフォーカスしてモジュールを作成すると、計算のタイミングやアウトプットの場所といった全体のデータの繋がりが見える 所感 最近DDDの開発に入らせて頂いているが、設計に答えがあるわけではないという言葉は常に頭の片隅に置いておく必要がありそう。 実際に何が答えかわからない中、これがベストと言えない状態で試行錯誤に時間がかかりすぎている。 まだ決まっていないことは仮の前提を立てるなど、一旦現時点でできるベストを選択し、スピード感を出すようにトライしていみる。 一旦はプロダクトをハリボテとして作り上げて、そこから新たな視点で見ることもできると思うので、考えすぎて作業が遅くなりすぎないように注意しなければならない。 アジャイル開発は2度失敗する(市谷さん) メモ 教科書通りに進めるのではなく、早く少しだけ形にする。新たに分かってきたことを現実的に受け止める方法を検討する 理想的な状況を前提に考えていてはダメ 理想的なプロダクトオーナーは都合の良い概念 所感 今の仕事ではプロダクトオーナーの理想を押し付けているなと思った。正解をプロダクトオーナーが持っているわけないし、協力して良いプロダクトを作るように意識を変えないといけない。 (多分もっと重要な話をしていたと思うんだけど聞き取れなかった・・・) QA 重要な20%の見極め方。相対的に比べてどちらが重要かを比べる。50:50、25:25・・・。一番大切なのは経験。お客さんの事業におけるマーケットでのポジションで見極める。リーダーは他社が追いつかないようにする策に特化。ニッチャーは得意な点。 最後に Zoom参加は初めてでしたが、音声はやや聞こえにくかったです。後半はかなり聞き取りが厳しかった・・・無念。

SOLID原則について調べてみた

はじめに オブジェクト指向プログラミングにおける有名な原則であるSOLID原則についてまとめました。 何番煎じかわかりませんが、自分の言葉で書いてみようと思います。 SOLID原則とは Single Responsibility Principle 単一責任の原則 Open / Closed Principle 開放閉鎖の法則 Liskov Substitution Principle リスコフの置換原則 Intarface Segmentation Principle インタフェース分離の原則 Dependency Inversion Principle 依存性逆転の原則 単一責任の原則 クラスを変更する理由は複数存在してはならない。役割が複数ある場合、それぞれの役割が変更理由になり得る(責任=役割=変更する理由になる元)。 具体的にはプロパティの管理やあるクラスのデータベース管理など。 細かく分ければ良いわけではなく、クラス名が一言で添えられる程度の分割が良さそう。 開放閉鎖の法則 既存のコードに修正を加えないで済む手法。 拡張に対してオープンであり、修正に対してクローズドである。 言い換えると、振る舞い方を追加することで変更に対応することができ、その変更は既存の振舞には影響しないこと。 方法論としては、呼び出し側が抽象を操作し、派生クラスの追加により変更を行う。 リスコフの置換原則 基本クラスを使っている箇所では基本クラスの代わりに派生クラスを使っても動かなければならない。 例えばスーパークラスが吐き出さないExceptionをサブクラスが投げてはいけないなど、派生クラス固有のプログラムはNG。 派生クラスは基本クラスより引数の条件が緩くなければならない。例えば基本クラスが正の整数を受け付けるのに派生クラスが100以上の整数しか受け付けないのはNG。 派生クラスは基本クラスより返り値の条件が厳しくなければならない。 インタフェース分離の原則 クライアントに、クライアントが利用しないメソッドへの依存を矯正してはならない。 インタフェースを分離することで修正範囲が狭くなる。 インタフェースの規模が大きくならないよう、異なる意味合いのメソッドはインタフェースを分ける。 依存性逆転の原則 上位のモジュールは下位モジュールに依存してはならない、どちらも抽象に依存すべきである。 下位モジュールを使用する箇所に直接型定義として記載するのではなく、上位モジュールとして振る舞えるように記載する。 具体的には下位モジュールから抽出されたインタフェースを型として持ち下位モジュールは注入する形にする(定義自体を外に記載するDIが良さそう)。 下位モジュールが上位モジュールの中で直接使用されている状態を「下位モジュールが上位モジュールに依存している」と言う。 まとめ 言葉こそ知らなかったものの、普段気にしている点ばかりでした。ちゃんとソフトウェアに落とし込めているかは別の話だけど・・・。 普段気にしていても改めて言葉で書いてみると難しいですね。自分の言葉で説明できるようにならないとと改めて思いました。 デメテルの法則など、上記以外の法則・原則もあるようなので調べる必要ありです。

Bulmaについて調べてみた

Bulmaを仕事で使うことになったのでさっくり概略を調べてみました。 Contents 1 Bulmaとは 1.1 Flexboxとは? 2 ノンデザイン? 3 プロジェクトへの取り込み方 4 気になったポイント 4.1 画面レイアウト 4.2 実装方法 4.3 モジューラビリティ 4.4 面白そうな細かい機能 5 所感 Bulmaとは オフィシャルサイトによると以下の通り。OSSのCSSフレームワークで。Flexboxをベースにしているようです。 Bulma is a free, open source CSS framework based on Flexbox モバイルファーストのレスポンシブデザイン。 モジュールとして組み合わせて使うことができるようです。 Flexboxとは? FlexboxはCSS3で採用された機能で、正式名称をFlexible Box Layout Moduleといいます。 名前の通り、フレキシブルなレイアウトを簡単に実現する仕組みで、親Box・子Boxにより構成されます。小要素のBoxを横並びで表示し、親要素と小要素の横幅に応じて自動的に折り返して次の行に表示するなど、閲覧するブラウザ・端末に応じて見やすいレイアウトを自動的に生成します。 ちなみにGridレイアウトと混同しがちですが、Flexboxは1次元レイアウト、Gridは2次元レイアウトです。

2019年5月振り返り

総括 AtCorderとDDDに夢中になった月だった。何かしらのシステムを構築して公開したい気持ちはあるが、サンプルの作成やお手本コードとの照らし合わせなど、基礎力を高めることをまず行っている。今年は基礎力を高めることが第一目標でもあるため当分継続する予定。 AtCorderは自分の実力不足を知る良い機会だった(心が折れないように頑張ろう・・・)。 研修に参加し、他のエンジニアの関心が何に向いているのか知る良い機会になった。DDDはやはり人気。 Achived 開発 Rubyのチェリー本読み終えた。一通りRubyは読めるようになったと思う。AtCorderの問題をRubyで解いたため基本的な処理は効率的・簡潔に書ける JJUGに参加した DDDの学習。参加できなかったが「レガシーをぶっ潰せ」の参加報告ブログを読んだり、JJUGで関連セミナーに参加、BPstudyに参加した RubyブロックやProc等、関数型言語要素の理解(動作原理やスコープ) AtCorder大会(ABC)に2回参加。300点問題で引っかかる・・・ AtCorderが難しい。数学要素と効果的な計算方法の選定がネック。ABCの過去問A、BはRubyに慣れるために多数解いた。C、Dはまだ慣れていない インフラ なし IT基礎 なし 英語 移動中の英語リスニングは継続中(5月半ばから気温がやけに高くなり自転車通勤はストップ) Problem AtCorderの300点問題に時間がかかりすぎている 腱鞘炎が再発してしまい治らない。長くタイピングし続けると辛い Try for next month AtCorderのC、D問題の過去問を解く。Cは大会で確実に解ける状態にする 腱鞘炎を完治するために書籍学習等をバランスよく組み入れる(読書が捗ってちょうど良い) モチベーションキープのためにDDD研修に参加・もくもく会を開催する 以下は着手中。継続して実施する。6月はAtCorderとDDD。書籍学習と手を動かす作業のバランスに気をつけて進める。 Rubyメタプログラミングの完読(6割完) DDD学習「設計の本」の完読(5割完) DDD学習「エヴァンス本」の完読(2割完) クリーンアーキテクチャのプログラム自分なりにサンプルを作ってみる(Java12で) Java9、10、11、12の新機能サンプルプログラムを書く 8月末にどういった状況でいたいか? ある程度学習する方向性が見えてきたので3ヶ月後の理想の姿を考えてみました。以下の通りです。他の仕事も頂けるようになりたいのでインプットを終えてアウトプットしている状態になりたいですね。 ・JavaかRailsの何らかのシステムが出来上がっていること ・ブログが見せられる状態であること ・DDDに関する意見を書く ・簡単なプログラムを書いて、ブログで説明する ・AtCorderとGitHubのリンクを貼る ・AtCorderが見せられる状態であること ・GitHubが見せられる状態であること

BPStudy#141〜DDD(Domain Driven Design)実践の現場に参加してきた(DDD初研修)

参加背景 今月に入って本格的にDDDを学習中なのですが、対面で増田さんの話を聞いてみたく参加してみました。 進捗としては「現場で役立つシステム設計の原則」と「エヴァンス本」共に2〜3割程度を読み終えたところで、まだまだDDD初心者です笑 DDD初セミナーでテンション上がってるのでまとめ記事書いてみました。 研修概要 19時半から21時半のセミナーでした。会場は総武線千駄ヶ谷と代々木駅の間にあるpixiv社でした(社内の環境良くて羨ましかった) 概要は以下の通りの2部構成でした。 セミナーページ 第1部 ドメイン駆動設計の正しい歩き方~どこに焦点をあわせ、どう実践するか 増田亨 氏 第2部 モデル駆動型開発によるビジネスをソフトウェアに落し込む1つのやり方 株式会社アクティア 高崎健太郎 氏 (ちなみに会場は満員御礼のようでした!すごい人気!) 第1部 ドメイン駆動設計の正しい歩き方 プレゼン資料は こちらです。 プレゼンで気になった点 内容は上記スライドの通りですが、気になった内容は以下の通りです。 最近はドメイン駆動設計を試したアウトプットが増えてきた なんでもドメイン駆動設計と照らしてしまっている気がする。設計の一般論だったり、ドメイン駆動設計ではないような内容もある ビジネスがそもそも複雑。システム化すると複雑になる。ビジネスの複雑さが根本原因 核心にある複雑さを解くと周辺が自然に明確になる。入出力はフレームワーク等により自然になる 核心にフォーカスを当てると全体が綺麗になるので意識的に見た方が良い マイクロサービスでもドメイン駆動設計の言葉が出てきた。コンテキストマップやサブドメインなど 開発者がビジネスの活動を継続的に学び続けることが大切。深く洞察していないとどこがコアかわからない チームメンバー全体で行動原理の意識付けが必要 パフォーマンス・チューニングで盛り上がった時などに行動原理から外れてしまうことがある ビジネスを多少学んでビジネス用語をある程度使えるようになった時は要注意。ビジネスの複雑さはそんなものではないため、よりビジネスを継続に学び続けることが必要 1つのテーブルだけで答えが出るようなものはコアドメインではない。そんなに複雑ではない ドメイン駆動のモデルと実装は、どろどろした切り離せないもの実装したら微妙だったからモデルを見直すこともある。モデルと実装は密に結合している 技術的に無理やりシステム間を連携させることもできるかもしれないが、シンプルでスマートな方法を常に検討する。考えるか考えないかで出来上がるものが変わる 例題の宿泊予約システム料金計算について 料金計算については画面もDBも関係ない。ドメイン層として独立させる(ドメイン層だけで開発してテストできる)(ドメインを隔離するの原題はisolating the domain) モデルを仮に作成し、コーディングする。しっくり来なかったらモデルを回収する。モデルを綺麗に作成してそれをコード化するわけではなく往復する コアはスコープ次第で変わる。システム全体か、料金計算の中かで異なる シーズンか特別室か一般室かなど軸は色々試してみる。主軸の選び方を絵だけではなくコーディングまでして確認する。3択あるのであれば3つとも多少書いてみて追っかけやすさなどを確認する 歯抜けの仕様書をもらった時に埋められるほどのビジネス知識になったらベスト。POの変更要件に対してどこを修正すべきかがわかるようになると良い ドメイン駆動言語に最適なのはJava。Pythonも良いが、Javaが良い。動的な言語だけではわからないことがあるため静的な言語をちゃんとやった方が良い 結局現場に導入するには、DDDの体験的な習得が必要。エヴァンス本は即効性はないがジワジワ効いてくる。着目点など、設計の質が変わってくる。読みにくい本なので注意 エヴァンス本の読み方コツ エヴァンスの読み方としては、体験的に習得し、想定読者条件をクリアしてから読むのが良い 2003年ごろのオブジェクト指向モデリングの本は読まない方が良い。顧客クラスや商品クラスといったモデリングはDDD的に意味がない。DBとテーブルをJavaのクラスに当てはめているだけのアプローチであり意味がない オブジェクト指向設計の文書(ワークスブラックのオブジェクトデザイン、バートアンドメイヤーのオブジェクト指向入門(ドンキの2冊)、ラーマンの実践UML)※スペルが間違えているかも 「現場で役立つシステム設計の原則」は日本語で翻訳ではなく読みやすい書籍 QA ビジネスルールを引き出すにはどうしたら良いか。間違えていても仮のビジネスルールを持っていって訂正してもらう。営業はわかっていない。あと、興味ない分野には手を出さない方が良い。モチベーションが上がらない -ドメインマスターが捕まらない場合はどうしたら良いか。 DDDにより変更要件を仮実装するハードルが低くなる。痛みがなく暫定的な実装ができるため -なぜビジネスルールは複雑なのか。「 ビジネスルールの複雑さに立ち向かう」というSlideShareにまとめてある 所感 ビジネスの活動を継続的に学ぶことは避けられないんだろうなと。フリーランスで対象のシステムが不定期に変化する場合はどうなのだろうか 例題として上がった宿泊予約システムの料金計算は大変勉強になった。具体例があるのは本当に助かる モデルと実装を往復する。試しに実装してみるという考えが大切という考えに至らなかった。目からうろこ。 エヴァンス本は読みにくいと思っていたがやはり読みにくいらしい笑。まだ読み始めのため読み方のコツが聞けて助かった エヴァンス本は紙で買うべきだった。Kindleで読みにくい・・・ 自らの著書「現場で役立つシステム設計の原則」を推していたが、仰る通りエヴァンス本と比較して日本人にわかりやすくて余計なことを書いていない。エヴァンス本より前に読むべき。 オブジェクト指向設計の書籍はハードルが高そうだが読まないと。。 宿泊システムのモデルになった宿の裏設定もあってリアルさに笑った笑。こういった背景を理解すると複雑なビジネスロジックになる理由がよくわかる(背景をわかっていないとストレスになるんだなと)。 ちなみに宿の裏設定は以下のようなもの 標高2000mにあるホテル 人材・食材の調達コストが高い 客が入らない場合に販促活動が必要 ちなみに「現場で役立つシステム設計の原則」は こちらで紹介されています。

動的型付言語と静的型付言語

背景 今までJavaの開発が多く、Javaは静的型付言語であった。最近Railsの開発に携わっており、静的型付言語と動的型付言語の違いを実感することがあったため雑ですが今思うことを以下に備忘メモとして残しました。 静的と動的型付言語の違い Rubyは動的型付言語であり、開発時にカルチャーショックを受けることが多い。 簡単な書き方であれば困ることはあまりないが、メタプログラミング要素を含む書き方になると調査難易度が格段に上がる。 現場で感じた動的型付言語のメリット・デメリットは以下の通り。 大規模になればなるほどメリデメは顕著に現れるように思える。現に現在参画している案件は大規模のため、以下の特徴を強く感じている。 静的型付言語のメリット (慣れると)開発生産性(メンテナンス性含む)は高い 静的型付言語のデメリット 慣れない間は遅い Ruby初学者 可読性が低い 静的コードチェックができないため、メソッド呼び出し可否が不明確 プロジェクト新規参入者の学習コストがかかる 影響範囲調査に時間がかかる(対応箇所の検討は付くが、裏取りに時間がかかる。CircleCIなど自動的に回帰テストを行える環境が整っていると良い) (雑な言い方だが)頭が良くないときつい。抽象的思考能力と大きめの脳内キャッシュ(短期記憶能力)があると良い プログラマの使い方を制限しないため空気を読んだコーディングが必須(コードレビューは必須) 最後に RubyはDDDと相性が良いように思える。 ドメインを明確に決めることで役割が明確化し、可読性、メンテナンス性が高まる。(デグレも起きにくい) Rubyの設計スキルを上げるためにDDDを学ぶ必要がある。 Railsの場合、ControllerとModelが確実に分割されるが、Modelが複雑化した時の書き方は追って学習する必要がある(ActiveRecord::Concernやmix-in、他にもある?) 大規模のプロジェクトでRails(動的型付言語)を使っている場合は序盤は全体構成の理解に徹するべき。 SOAによるサービス単位での分割など、大規模になりすぎないようにシステムを分割することを検討した方が良い。

Rubyのよく使う定義メソッド確認コード

よく使うメソッドの確認方法をまとめました。 クラスメソッドとインスタンスメソッドを両方出力するメソッドは見当たらないです。欲しかった・・・ class Test class << self def class_method1 end end def instance_method1 end end puts "--- class ---" t = Test.new p Test.methods # クラスメソッドのみ p Test.methods(false) # クラスメソッドのみ(親クラスを除外) p Test.public_methods(false) # publicなクラスメソッドのみ(親クラスを除外) p Test.instance_methods # インスタンスメソッドのみ p Test.instance_methods(false) # インスタンスメソッドのみ(親クラスを除外) puts "--- instance ---" p t.methods(true) # インスタンスメソッドのみ p t.methods(false) # インスタンスメソッドのみ p t.method(:instance_method1).source_location p t.methods(true).grep(/method1/)

4月の振り返り

振り返り総括 IPA試験があったためそれに費やす時間が多かった。 AtCorderが面白い。Rubyで遊びつつデータ構造やアルゴリズムの勉強ができるので楽しい。当分遊ぼうと思う。併せてRubyメタプログラミングの書籍で勉強中 通勤中は英語勉強がベスト。オーディオブックは他に注意を向けると文脈がわからなくなるため単発の英語が良い。DUO3.0は優秀。 Achived 開発 DB調査用のストアドプロシージャを作成した インフラ AWSサーバレスでRails環境を構築した(特別作りたいものがなくなったため、HelloWorldのみで一旦辞めた) ブログHTTPS対応 IT基礎 DBスペシャリスト試験勉強 Keep 勉強時間は多めに確保し続けることができている。継続する Problem 書籍は全部読まずに要点のみ読む (長期課題)デザインセンスが乏しい。色合いやWebサイト全体構成など Try for next month Rubyの基礎本の要点を読み終える Rubyメタプログラミング書籍を読み終える システム設計の原則本が読み途中。もくもく会を企画する AtCorderABCを90問解く(平均1日3問) AtCorder大会に参加してみる(5/25)

Let’s EnclyptでEC2上のWordPressをHTTPS化する

こちらを参考に AWS Bitnami+WordpressのHTTPS化をしてみました。 Contents 1 certbotのインストール 2 証明書の発行 2.1 ACME v2とは? 2.2 バックアップを取得 2.3 シンボリックリンクを作成 2.4 権限をrootのみにする(ln先の権限をなくさないとダメっぽい(3〜4行目) 2.5 Apache再起動 2.6 httpへのアクセス時にhttpsへリダイレクト 3 証明書の自動更新設定 certbotのインストール $ sudo -i $ curl https://dl.eff.org/certbot-auto -o /usr/bin/certbot-auto $ chmod 700 /usr/bin/certbot-auto 証明書の発行 以下コマンドで証明書発行ました。このコマンドを見つけるまでに時間がかかった。 $ cd /tmp/certbot $ ./certbot-auto certonly --agree-tos --manual-public-ip-logging-ok --manual -d "

AWS Lambda&Rails5.2.3で格安サーバレス運用をする

背景 RailsでWebシステムを公開したい時、どこのレンタルサーバを使用していますか? Railsが動作する前提で探すと(PHPと比較して)どうしても高くなってしまい、遊び程度のシステムを作成するにはどうも気が引けます。 簡単なWebサービスであればAWSのサーバレスアーキテクチャがかなり安く運用できそうなので、簡単な運用費計算と簡単な動作確認までを記事にまとめました。 環境 MacOS Mojave 10.14.4 Homebrew 2.1.0-27 Ruby 2.5.3p105 Rails 5.2.3 作業日 2019/4/14 運用費計算 王道ですが以下3つの構成から成る簡単なWebアプリを作成するとします。大まかな料金表は以下の通り。 Route53 ホストゾーンの登録 0.5USD/Month 標準クエリ100万件毎 0.4USD/Month (日割りされるみたい。少なければ0USD?) S3 ストレージ料金 最初の 50 TB/月 0.023USD/GB リクエスト料金 S3 Select によって返されたデータ 0.0007USD/GB lambdac 1,000,000 件のリクエストか400 GB-秒まで 超ざっくりですが、皮算用は0.5USD/月程度です。内訳は以下の通り。 Route53 1万アクセス/月の場合、登録料0.5USD+0.004USD S3 0.5GBのコンテンツの場合、0.00000023USD -20GBのリクエストの場合 (1アクセス2MB×1万アクセス)、0.014USD/GB lambda 無料 安すぎるけど計算間違えてないかな・・・。 既に計算している人を見ると、やや違うけど、とんでもない金額にはならなそうなのでとりあえず進みます。 AWS SAM CLIのインストール $ brew tap aws/tap $ brew install aws-sam-cli $ sam --version SAM CLI, version 0.

MySQLで全てのテーブルからキーワード検索する

はじめに 最近仕事させて頂いている現場でER図が存在せず、foreign key設定もされておらず、DB構成の理解に時間がかかりました。 画面上で入力した値がどこに設定されているかすぐ検索するためにDB内の全検索プログラムが見当たらなかったので作りました。(MySQL8.0動作確認済) カーソルの使用経験があまりなかったのでちょうど良い題材でした。 データベースから全検索 drop procedure if exists searchValueInAllTables; delimiter // create procedure searchValueInAllTables(IN table_schima_name varchar(255), IN keyword varchar(255)) begin declare v_table varchar(255); declare v_column varchar(255); declare done int default 0; declare cur cursor for select table_name, column_name from information_schema.columns where TABLE_SCHEMA=table_schima_name; declare continue handler for sqlstate '02000' set done=1; -- SQLSTATE 値 '02000' で「データなし」状況時にhandleし、done=1を設定する。その後のアクション「継続」をcontinueで指定 set @keyword = keyword; drop table if exists WORK_DATA; create temporary table WORK_DATA( -- temporaryを付けると一時テーブルとして作成できる。セッションを抜けると自動でDropされる table_name varchar(255), column_name varchar(255), hit_count int ); open cur; repeat fetch cur into v_table, v_column; if not done then set @sql_search=CONCAT('SELECT COUNT(*) INTO @cnt FROM ' , v_table, ' WHERE ', v_column, ' LIKE ?

2019年3月の振り返り

振り返り総括 3月はシステム開発は少しだけ、調査や読書の時間が多かった。 4月・5月はWebサイトに拘らず、自分が作りたいシステムを作ろうと思う。(次商談に向けて何か成果物は欲しい) 今の所一番興味があるのは株など投資売買に関連するサポートシステムなど。 体調管理にはかなり力を入れていたが、2回程体調が悪くなってしまった(長めに睡眠を取ったら治った)。寒い中の自転車通勤&久々の運動だったからかも・・・。 週1日は頭を休める日を引き続き取っておいた方が良いなと思う。 Achived 開発 クリニック向けレスポンシブデザインWebサイトの作成(既に契約済みだったため運用なし) ・ミック本(DB書籍で有名な本)読み途中(DBスペシャリスト試験向け)  ・システム設計の原則読み途中 IT基礎 証明書の仕組みやプロセス・スレッドの違いといった細かい部分を学んだ(全然記事にしていない・・・) 安いサーバ運用の調査。Railsを使うのであれば結局AWSのサーバレスが一番安そう(最近Rails対応したみたいですね) ミック本(DB書籍で有名な本)読み途中(DBスペシャリスト試験向け) システム設計の原則読み途中 Keep 自転車通勤 通勤中の英語、オーディオブック Problem (長期課題)デザインセンスがない。色合いやWebサイト全体構成など Try for next month (休日)DBスペシャリスト試験があるため3年分過去問を解く (平日)AWSでサーバレスシステムを構築 GWが始まるため、作るものを検討・着手 執筆は週に1記事程度で継続