セカイモンの裏側

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

Xcodeの初期化

 

ググっても3が何のことかわからなかったので、

メモ

Finderを開いて上のバーのメニュー(Finder, ファイル, 編集, 表示,移動, ウィンドゥ,ヘルプ)の「移動」をクリック

optionキーを押すと隠しメニューが出てくる。

いやぁ、難しいですわ。

 

  1. Xcodeを終了する(メニューからXcode->Quit Xcodeまたは⌘+Q)
  2. Finderを開く
  3. optionキーを押しながらメニューの移動をクリックする
  4. 「ライブラリ」を選択する
  5. 「Preferences」を展開する
  6. 「com.apple.dt.Xcode.plist」を削除または移動させる(移動させた場合ファイルを元に戻せば設定も復元されます)
  7. Xcodeを起動する
  8. 完了

 

 

さくら(専用,VPS) VS AWS

オンプレミスから移行するにあたって、比較検討してみた結果
さくらにしてみました。
AWSは落ちないという定評があるけども価格が高く
さくらは安いけどもあまり評判がよくない
すこしグラフにまとめてみました。

さくら AWS

VPS, 専用サーバーはサーバーを用意するだけでオンプレミスとほぼ変わらない

安い

メルカリ、Pixivなどで実績がある

会社の実績、自己の経験の実績もある

シェアトップ

落ちない

価格が高い

サービスが多いのでベンダー依存になる

決済が自動(勝手にされる)

再起動でIPが変わる

AWSにしなかった7の理由

エンジニアとしてはサーバー起因のトラブルが起きる可能性がすこしでも少ない方が安心できるのでどうしてもAWSを選択してるのもわかりますが、さくらも

99.95%とうたっているみたいです。

https://server.sakura.ad.jp/payment/

 

理由①AWSにしたからといって絶対に落ちないという保証もない

https://style.potepan.com/articles/9034.html

 

理由②ベンダーロック

オンプレミスからAWSへの移行はよく聞きます。しかしながら、AWSから他のクラウドサービスの移行は聞かないです。なぜでしょう。かなり難しいかと思います。

RDS, S3, EC2はWebサーバーとしても、Cloud Watch、Lambda等を他の移行するとなると自分たちで各々のサービスを構築しないといけないです。バックアップなども取れるかは知らないですが、身近でAWSから移行したというのを聞いた事がないです。

値上げされても泣き寝入りするしかないと思いますが、いつか来るのではと思っています。

 

理由③検証機にもAWSって高すぎる

落ちないっという保証で料金が高いAWSなので別に落ちてもいい検証機にもその保証が必要か!?って思います。うちでは検証機はオフィスに使わなくなったPCにLinuxインストールしたりしてLAMP環境揃えたりしています。

 

理由④EC2で再起動するとIPが変わる

検証とかで、本番でも再起動するとIPが変わるなんて不便きまわりないのでどうしてもelastic ipで料金を支払わざるを得ない。なので単純な比較の場合はこういった必須オプションの料金が含まれていない事が多いのでAWSを使いだしたら想定以上に高くなったっていうケースの要因にもなるかと思います。

 

理由⑤サービスが多いし最近はアプリサービスを打ち出している

一見メリットのように見えはしますが、サービスが多い分、そのサービスを使用するとベンダーロックの割合が増える

ELBとかは自前でやるとnginxとかになりますが、それを一からってなるとスキルと度胸が必要そうです

ただ、これのもう一つの問題はAWSサービスの知識がスキルってなってる風潮があり、システム的にもマインド的にもロックがかかってしまいます。AWSのサービスの知識なんて問い合わせればいいだけなんでスキルでもなんでもないのに、なぜか響きがいいのか「Redshift経験あります」ってなぜかプラスになっています。

流石マーケティングトップのアマゾンって思います。

 

理由⑥アクセス負荷などでも落ちずに気づいたら請求書が高額

請求があまりにもしれってされる事が多いので、高額請求っていう経験が何度か。。。

以前の職場のアプリ開発でユーザー数10人程度なのに、月50万とか。。

アプリのバグでループしてアクセス負荷が高くなって気づかずに月額請求見たらゾッとしたことも。。ぼったくられたって感覚はありますが、一般的には勉強代だそうです。

お金は会社が負担して、エンジニアはそこまでお金に関心がない事が多い、さらに社長クラスはシステムに詳しくないので、費用がかさむ事が多いケースかと思います。

 

理由⑦サーバーのインフラ知識よりもAWSの知識がついてしまう

ベンダーロックとも重なるけども、エンジニアのスキル的にサーバーを一からインストールする事がないと、PCにLinuxを入れたり、他のクラウドでの取っ掛かりもスキルといった観点でなかなか難しいのではと思いました。

 

結局落ちる時は落ちるし落ちた時のシステム構築に時間とお金を費やした方がと思いました。

 

 

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

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

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

・アクセス権

 全員が書き込める

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

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

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

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

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

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

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

テーブルのプレフィックスの定義と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にアクセスさえしなければいいかなとも思います。。

ModelをLibraryとして使う

典型的なMVCは好きではないです。

ViewとControllerを分けるのはわかるし納得ができる。

あと、古いフレームワークでDBとのクエリをModelでまとめるのも納得できる。

しかし、今時DBとの接続がフレームワークが設定されていので、あえてModelでSQLの記述と接続を記述しなくてもいいかと思います。

古いフレームワークの場合はmysql_connect()を記述してSQLも書いてとなって色々Model上で記述が多くなってくるかと思います。

しかし、最近では細かい記述はしなくてもよく

$results = DB::select( DB::raw("SELECT * FROM some_table WHERE some_col = :somevariable"), array(
   'somevariable' => $someVariable,
 ));

これでコントローラからもSQLが記述できるのでModelで記述する理由もだんだんとなくなってきているかと考えられると思います。

 

そうなってくるとMVCじゃなくてVCだけでもほぼいいんじゃないか?っていうのが考えです。

VCになると結局さらにファットコントローラの思想に行きついてしまいます。

 

とはいえ、じゃぁModelは不要って事になるので使わなくてもいいかってなるけどもライブラリとして使用することでいいじゃないかっていうのが今回のコンセプトです。

 

ライブラリとして使用するつもりが1つのコントローラからのみのアクセスになるってことよくあったり、一回きりの関数の呼び出しが他のコントローラからもModelを呼び出すってこともよくあります。

であれば初めから何がライブラリで何がModelに入れるべき処理っていうのを分けなくてもいいかと思いました。

モダンなフレームワークでのMVCについて懐疑的な意見のページを参照します。

togetter.com

ここに記載されてる事とほぼ同意です。一般的にはMVCにするときれいになるとかロジックはModelに書くべき、ロジックをModelにかけないエンジニアはまだまだ初級レベルみたいな概念がまかり通っているが、MVC自体にメリットがなければVCでもいいのではというのが個人的な意見です。

言いたいことを代替して言ってくれてるからすっきりします。

「LLのフレームワークはコードを整理してるだけ」という意見をModelとControllerの分け方を整理してるだけとくみとって解釈すると、もしコントローラで2000行ぐらいになるファイルになるのであればそれを分割してModelに分けていってもいいかと思います。

変更箇所が多そうな部分を切り出せばバージョン管理上、運用しやすくなるメリットはあるので。

共通ロジックはゴッドオブジェクトとsingle action per controllerの時にまたこの話になると思います。

 

 

 

POSTは全てAjaxで

<form>タグでpostすることを始めに覚える事かと思いますが、システムを作るうえでJavascriptからPOSTした方がいい理由がたくさんあります。

なので今では何も迷わずにPOSTをAjaxで行っています。

ではいつもの通りメリット・デメリットを記載していきましょう。

 

色々他の記事も参考にしようとしたけども、formタグとの比較でのメリットデメリットに対しての記事がなかったので参照なしに書き綴っていきます。

 

メリット

・サーバーに負担がかからない

 まぁ、これはサーバーが多少は負荷がやわらぐかもしれないけども、作り方次第ってのも大きいのと、Ajaxにしたからといって劇的に変わるわけではないと思いますが、一般的にこれが一番初めに想起させるメリットみたいです。

・バリデーションがJSで書ける

 バリデーションをJS上で書くことによってユーザーへのレスポンスをフルリロードしなくても、メッセージをエラーとしてユーザーに見せる事ができるので、ユーザーにとっても、サーバーにとっても都合がいいかと思います。中にはサーバーサイドでしか確認がとれないバリデーションとかもあると思いますが(ユーザーIDがユニークかどうか)、大部分はそうではないので大きなメリットかと思います。

・POST後の表示を考えなくてもいい

 formでPOSTするとPOST後に成功したエラーになったにかかわらずそれなりのHTMLを書いて表現しないといけないです。でも、JSからではエラー内容、通常のレスポンスもJSONで返すだけで済むのでPOSt後のデザインを考える必要もないです。

それに伴ってコントローラ名を**add,**edit, **delみたいに表示はJSON, 他はHTML表示というように分かりやすく分ける事も可能になってきます。

・formタグの位置を気にしなくてもいい?

 JSでは.POST時にどこのタグから取得するかを指定できるので、HTML上どこにタグ、データを置こうが関係なくPOSTできるようになります。hiddenタグでやればformでもできるのでメリットは薄いですが。。

 

デメリット

・コールバックを知らないといけない。

 POSTした後何かしらのサーバーのレスポンスをもとにアクションを起こしたい場合はコールバック上でアクションの関数を実行しないといけないので、慣れてない人には1ステップの障害になるかもしれません。でもコールバックは覚えないとWebエンジニアって言えないくらいですね。

・どこからの実行なのかがわかりづらい

 とんでもないJSファイルからPOSTを実行しているっていうケースもあるので、どこからどのように実行するかのルール決めをしないといけない。

・バリデーションをJS,サーバーサイド両方で記載しないといけない。

 基本はバリデーションはJSで行って、サーバーサイドではサーバでしかチェックすることができないバリデーションのみでOKかと思います。例えば、通常のユーザーの操作以外の悪意があるようなPOSTに対して「あなたは悪意があるPOSTです」ってわざわざ言わなくてもいいので適当にレスポンスは丸めておけばいいかと思います。

 

ずっとWebをやっててJqueryのPOSTでやることになんら違和感もなくやってて、それで運用も問題ないので、POSTは全てAjaxでいいという結論です。