セカイモンの裏側

★毎週木曜日更新★ 海外ショッピングサイト『セカイモン』のブログです。私たちスタッフの仕事風景や日々の出来事など、     “セカイモンの舞台裏”とも言える日常を綴っていきます。

nginxのオレオレ証明書

結論からいくと

qiita.com

この通りやればうまくいけました。

もとの証明書を使いまわそうとして、かなり時間が取られてしまいました。

 

UI_set_result:result too small no password

パスワードを求められて no passwordにしようとしても無理だったり。

初めから作り直せば問題なかったな。

 

key values mismatch nginx

のエラーが出たり、

I_set_result:result too small:ui_lib.c:869:You must type in 4 to 8191 characters

とかのエラーもでて迷宮にさまよったりしてました。

 

今度からは、CAの証明書は関係無しに自己証明書を作ります。

ファットコントローラの何が悪い

ファットコントローラって忌み嫌われてる事が多いけども

www.slideshare.net

撲滅運動とかがあるくらいなんですが、MVCのルールにのっとればファットコントローラはだめですが、そもそもわかりやすいコードないし、クラス設計にMVCが必要とも思ってないです。

そもそもMVCってJAVAGUIで必要性があったからその考え方が広がったわけで、

しかも約20年位前に成り立ち!?

Model View Controller - Wikipedia

このMVCの概念を知った時から疑問の念に駆られていました。

当時のyahoo知恵袋

detail.chiebukuro.yahoo.co.jp

この時からMVCって不要にコントローラを膨らましているとすぐに思いついてその必要性が今になってもわからないです。

 

なので別に1つのコントローラに1つのアクションで問題ないのでしょうか?

ていうスレッドをkohanaのスレッドに何年か前に立ち上げました。この時も結局Modelにあえてソースコードを持ってくるという答えを得られませんでした。

single action per controller - Kohana Forums

結局前にも利用したこのページに激しく同意です。

togetter.com

なのでLibrary,Model,Util,Helperなどを作るときはModelとして扱って、作成する時はリーダー、マネージャーというか私に許可制とかにした方がいいかなw

じゃないと、そのクラスを使った人しかわからない機能を作るとなると属人的になっていくと思うので、作成するときは慎重にした方がいいかなっと思います。

 いずれにしても、コントローラの階層にファイルがいっぱいになってしまうので、2階層にしないといけないと思います。3階層はややこしくなるし。マイクロサービスなので2階層で十分かと思います。

 

共通ロジックはゴッドオブジェクトの始まりで不要、最悪最後の奥の手

共通ロジックを作ることはオブジェクト指向を知ったエンジニアが作るということで、かっこいい感じがしますが、あとになってだれだれさんが作ったクラスだから聞かないとわからないってことって現場ではあるあるの話だと思います。

今ゴッドオブジェクト、神クラスでググると共通クラスで使用しているものを限定するとこんな記事が出ました。

yyyank.blogspot.jp

JAVAの話ですが、意味としては同じです。

共通ロジックを作ってそれを使いまわせば、DRYなアプリケーションになると伝えられていますが、実際の実装では共通につかうはずだったクラスにあれもほしいこれもほしいとなって結局なんでもできる共通クラスとなり、それなしではシステムが動かないっていう風になるのはまだしも、単純な処理ですらその神クラスを通さざる負えない状況になって関所みたいになるってなると末期だと思います。

なので共通ロジックを作成するときは現場リーダーの許可が必要というルールの基に極力作成しませんっという方向で行きたいと思います。

共通ロジックを作成するより、コピペで展開していった方が結局見やすいのと運用での改修で影響範囲が抑えられるっていうメリットがあると思います。

 

業務系の機能はhandsontableを使います。

スマホ対応の場合は使えると思えないですが、PCで使用する場合はhandsontableを使用したいと思います。

google spreadsheetでも割と便利で使えます。ただし

・アクセス権

 全員が書き込める

 細かい権限がつけられない

・他のデータ連携ができない

・大量のデータを扱えない

の理由でメインの業務システムに組み込む必要があります。

google spreadsheetでは直接セルに書き込めるのでhandsontableを使用して、同じようン編集できた方がいいかなと思います。

UI、UXにもなるのでどこかでレビューを聞いた方がいいかもしれないです。

エンジニアテスト採用機能で試しで使ってみようかと思います。

DBとインフラ周りの権限について

在宅勤務のリソースを使わざる負えない状況にはいつかくると思うので次期システムの時に在宅勤務のエンジニアでも渡せる環境づくりが必要かと思います。

 

一時期オフショア開発などはやったけども、流れとしてはクラウドソーシングで会社単位よりも個人単位になっていく気がします。そういったときに簡単に仕事をどうわたすかを今試行錯誤しています。

 

なので権限をどこまで共有しどこまで制限するのかが重要になってきます。

 

プログラマーにはどうしても本番DBでないと確認が取れない事とかが出てきそうですが、できるだけ本番のDBを検証に素早く映せる環境を作ることが大切かと思います。

 

・本番DBに触ることができるのはオフィスにいる人のみ

やっぱり在宅勤務者には触らせるのは危険かと思います。1年以上働いたら触らせるとかいう規定があってもいいかもしれないです。

 

クラウドのコンソールと本番サーバーのroot権限は社員の中でも一部にしておく

本番サーバーでの障害対応はログを見たりnginxの再起動が必要であったりすることが多いけども、それは全てsudoで権限付与させておけばいいかと思います。クラウドコンソールからサーバーの追加が必要になった時は都度その一部の人が対応しないといけない事になりそうですが、コアになればなるほどインフラ周りの仕事が増えていくのは仕方がないことですね。

 

・本番サーバーのアカウントは別で作成するべき

同じアカウントでSSHキーを分けて行う運用も多いけども、本番ではやはり誰が何をどのファイルを変更したのかっていうログが大事なのでアカウントは都度作成、削除した方がいいかと思います。グループを同じにすればそこまで難しい話ではないかと思います。

本番サーバーに入れるという事は.envが見れるという事なのでDBに入れるという事、すなわち在宅勤務のプログラマーには本番サーバーにも入らせる事が出来ないという事になります。障害が起きた場合は、ログ見るなりはオフィスのスタッフが見てどのリリースが原因かを見て戻して作業をした人にリリースしなおしてもらうっていう作業になるかと思います。そうなると在宅勤務のエンジニアがスキルが高かったとしても本番に入れないので行動範囲が限られてしまいます。なので、2年間なのか、3ヶ月なのかわからないですがある一定の信頼を経て在宅のエンジニアにも本番に入れる権限を与えないといけない時がくるかも知れないです。

となるとなおさら本番DBから検証DBに半同期するような仕組みが必要になってくるという事になるかと思います。であれば多くのケースで「本番でしか検証できない」っていう事を防げるのかと思います。でも「本番でしか検証できない」って超あるあるの話ですが。。。

 

在宅勤務のエンジニアを募集しています。

セカイモンの採用ページから問い合わせお願いします。

 

 

テーブルのプレフィックスの定義とIDカラムについて

・まずはプレフィックスについて

テーブルのプレフィックスってよくあるのが、m_とかt_です。

m_はマスターテーブルで、t_はユーザーが登録するテーブルでそれだけでは足りないので、いろいろ付け足して行く事もあるかと思います。

たまに、m_だと思っていたらいつの間にかユーザーが登録するテーブルになっていたり。プレフィックスと違う仕様になっているのも見かけます。

なので次期システムではどういった命名規則にするかを考えていこうと思います。

定義する上でスタッフかユーザーかという視点よりもどれくらいの登録、更新頻度という分け方の方がいいのでは??という事で考察していきます。

m_**はマスターテーブルなので、スタッフが登録、更新するテーブル

なので1か月に1回くらいの登録、更新頻度

t_**はユーザーの入力という事で登録、更新する頻度はウォッチリストとかになると1日10回~100回、あとは入札とか落札といった登録と、会員登録といった所がユーザーが主に入力する部分かな、マイナーな部分でいくとマイ検索リストとかコミュニティの投稿はもうちょっと投稿してくれてもいいかと思いますが、、、発送指示とかもありますね。

でもまぁ、1日あたり10回~1000回ぐらいの更新頻度で限定できそうです。

次期システムの場合t_の次の通常フローとキャンセルなどのイレギュラーに発生するテーブルのプレフィックスを考慮しないとテーブルの数でいくとここの部分が大部分をしめるかと思います。

暫定的に倉庫での通常フローで発生するデータのテーブルをレギュラーからとってr_**でNG商品やキャンセルなどのイレギュラーで発生するデータのテーブルをi_**とかで定義してもいいかと思います。

オーバーサイズが通常なのかイレギュラーなのかが難しいところですね。

r_**の登録、更新頻度が落札の9割程度でi_**の登録、更新頻度がそのr_**の1割~2割ぐらいと分けるときれいにわけられるかと思います。

システムでログなどで大量に登録されるテーブルはh_**かl_**とかでいいかと思います。

更新頻度は100回~1万回/日であくまで削除されても特に影響がないサービスとかの場合のプレフィックスという事で。

最後にもともとコンフィグファイルで定義していたものをDBで管理するようになったテーブルとかはc_**とかで分けてもいいかも知れないです。ただ、m_**のテーブルの数がすくないのであればそういった分け方はしなくていいかもしれませんが。。

変更が多いマスターテーブルをどうするかを考えた方がいいかもしれないです。

システムで毎日変更しているようなマスターテーブルもm_**でいいのかどうか。1日1回ぐらいの更新なのであればやっぱりマスターテーブルですね。

カラム名はDB内でユニークにすべき

よくテーブルのID名を「ID」とする事が今までおおかったけども、そうではなくてIDが必要な場合はテーブル名+_+IDとした方が運用保守中で検索するのに大変都合がいいためそうした方がいいです。あとは、status,category,type,などのよく見かけるカラムもできればテーブル名プラスでやってもらった方がありがたいですね。

DB内で同じカラム名がある場合は意味も同じでjoinできる状態であればきれいなテーブル構成かといえるのではないでしょうか?

 

今回はルールを決めるっていうには歯切れが悪かったけども、こういった方向でいけたらぐらいしか書けませんでした。

phpにテンプレートなんていらない

PHPでよくSmarty,とかBladeとか使用している場面を見かけますが、テンプレートなんていらない。なぜならPHP自体がテンプレートなんで。

oshiete.goo.ne.jp

Smartyの存在を無視している以上、あえて過去の遺物を引きずる必要はないです。


Smartyはテンプレートエンジンですらない 

 という事を言っているが、Laravelでもbladeというのは不要でそもそも1つの言語でいいものを2つにする必要がない。

 

Smarty って、要らなくない? — INWORKS

 

SmartyでもBladeでも機能がたくさんあるし、たくさんあればあるほどデザインとロジックを分けるっていうそもそもの意味もなさなくなるんで、不要かと思います。

どこまでをロジック、デザインを分けるにしてもどっちとも取れない場合は結局担当者のコードの書き次第になるのでテンプレートを使用したからといってViewがきれいになるってなかなか難しい話かと思います。

 

次期システムのコンセプトはできるだけシンプル、初級レベルのエンジニアでもわかりやすいシステム設計という事でSmarty, Bladeが簡単とはいえそれはそれなりに覚えたり、関数を調べたりしないといけないと思います。

そのたびにSmartyググる行為がやる気を削ぐ削ぐ。

PHPでViewを書くことのデメリットはViewの見通しが悪くなってきそうになる事だけども、結局Smartyでやっても見通しが悪くなるViewをさんざん見てきたので、その時にコードレビューして確認する以外にないかと思います。

まぁViewからDBにアクセスさえしなければいいかなとも思います。。