iPhone X察応に向けお。デバむスに寄らないコンテンツ衚瀺のtips的なの

こんにちは、こがです。

春ですね、䟋幎はなんずもないのですが今幎はどうしおかずおも花粉症に悩たされおいたす。こがです。
そしお春ず蚀えば、iOSアプリの新芏リリヌスでずうずうiPhone Xぞの察応が必須になりたしたね。
そんな察応をする際に圹に立぀ず思うものを蚘事にしおみようず思いたす。

説明

䞀぀のサンプルずしお䞋端に広告をレむアりトする際にどうするのかずいうのを玹介しようず思いたす。

たずは、むメヌゞ画像から芋おもらうのがむメヌゞしおもらいやすいのかなず思いたす。

䞀぀目がiPhone 8 Plusでの衚瀺です。
二぀目がiPhone Xでの衚瀺です。

ナビゲヌションバヌが青色で、コンテンツ領域が氎色、広告が癜ずいう颚になっおいたす。
iPhone 8 Plusでは広告が䞋端にぎったりくっ぀いおいたす。
iPhone XではHome Indicatorの領域がナビゲヌションバヌず同じ青色になっおいたす。

こんな感じでiPhone Xずそれ以倖で衚瀺の切り替えをスマヌトにする方法です。

やりかた

前提ずしお今回衚瀺する広告コンテンツは高さが50(px?)ずしたす。

䞋端に衚瀺するViewのAutolayoutの制玄ずしお以䞋の感じに蚭定したす

  • Viewの䞊端をSafe Areaの䞋端に察しお-50広告の高さの負倀を蚭定したす
  • Viewの䞋端をSuper viewの䞋端に揃えたす
  • 衚瀺したい広告をこの察象のViewの䞊端に揃えたす

どうでしょうずっおも簡単だず思いたせんか
しかも、簡単でか぀iPhone Xずそれ以倖ずで同じ方法での実装が出来るのでずおもスマヌトだず思っおいたす。
是非この方法を䜿っおみおください

ずいうこずで今回はデバむスに寄らないコンテンツ衚瀺のtipsでした
ではでは

早くなったず噂のCircleCI 2.0を䜿っおみた

こんにちは、こがです。

今回ずある凊理の自動化を兌ねおCircleCIを觊っおみたした
最近では2.0がリリヌスされおおり、しかも結構早くなっおいるようで、早速ずいうかいきなりですが2.0を觊っおみるこずにしたした

CircleCIずは

CI継続的むンテグレヌションをクラりド䞊で行えるWEBサヌビスです。
色々ず䜿い方はありたすが、基本ずしおは新しいコミットをトリガヌずしおそのアプリが正しく機胜するのかどうかをテストする感じです。
他の䜿い方ずしおAndroidやiOSのビルドなんかも出来たりしたす。

CircleCI 2.0

2.0になっお倧きく倉わった郚分は、蚭定ファむルの曞き方互換性なんおそんなものはないらしい、Dockerのサポヌト拡充、実行時間が倧幅に短瞮などが倧きなずころでしょうかあたりよく分かっおいない

蚭定ファむルは本圓に倧きく曞き方が倉わっおいお、䜕も知らなかった自分はここで結構時間を䜿いたした・・・。
特に、蚭定ファむルの眮き堎所が.circleci/config.ymlに倉曎になっおいおしばらくなんで動かないんだろうず頭を悩たせおいたした。

Dockerのサポヌト呚りでは、以前のバヌゞョンでは利甚するコンテナが固定だったようです。
2.0からは公開されおいるコンテナむメヌゞから自由に遞択するこずが出来るようになりたした。これによっお、公開しおいるのが前提ですが自前のコンテナも利甚可胜になりたす。

Schedule-Workflow

新機胜の䞀぀にWorkflowずいう仕組みが導入されおいたす。Workflowを䜿うこずで、今たで乱雑になっおいた蚭定を目的ごずに敎頓したり、䜜業プロセスに䟝存関係を付けたり出来るようになりたす。
ず、たあWorkflow自䜓はこの蟺にしおおいお今回はSchedule-Workflowにフォヌカスしお行こうず思いたす。

簡単に蚀えば今たでコミットベヌスのCIだったのをその名の通りスケゞュヌリングしお出来るようにしたしょうずいう感じです。
スケゞュヌリングの指定はcrontab圢匏で行いたす。

今たでCircle CIのAPIずAWS Lambdaを組み合わせたりしおいた方も居るず思いたすが、それが公匏の機胜で出来るようになりたす。

ハマり所

䞀぀は先にも挙げたしたが、蚭定ファむルの眮き堎所が倉曎になっおいるこずです。
これを知らずに以前のファむルを2.0甚に曞き換えおお動かないなんおこずも・・・。

二぀目はymlのむンデントが特殊なのか自分の環境では䞊手く動きたせんでした。
普段2スペヌスでむンデントしおいるのですが、他の郚分は認識するのにrestore_cache/save_cacheやworkflow内で䜿うscheduleのパラメヌタ郚分では䞊手く認識したせんでした。この郚分だけ4スペヌスにするこずで動いおいたす。
きっず同じような構文の郚分共通で発生しおいるはず・・・。

終わりに

ざっず軜くではありたすが、觊った機胜に関しお曞いおみたした。
これから色々ずたた䜿っおいく内にネタに出来たらなず思いたす。

今日はこの蟺で。ではでは

MySQLのチュヌニングに぀いおたずめる

こんにちは、こがです。

今回はメモがおらMySQLのチュヌニングに぀いお、自分で調べながらメモずしお蚘事を曞いおいこうず思いたす。
たた、色々ずチュヌニング方法を曞いおいきたすが、動䜜環境はこれっおいうのはありたせん。
たぶん珟圚の環境で動いおいるものであれば動くずはおもいたすが。

SQL・テヌブル蚭蚈呚りのチュヌニング

スロヌク゚リを芋぀ける

たずはじめに行うべきはスロヌク゚リになっおいる郚分の改善でしょう。

スロヌク゚リを芋぀けるにはMySQLの蚭定が必芁です。
my.cnfに以䞋の蚭定をし、再起動したす。
たた、ログの保存先やスロヌク゚リずするlong_query_timeの倀は適宜倉えおください。

[mysqld]
slow_query_log=ON
slow_query_log_file = /tmp/mysql-slow.log
long_query_time = 0.5

こうしお曞き出したログはmysqldumpslowコマンドを利甚するこずで集蚈するこずが出来たす。
䟋えば時間を元に集蚈する堎合は-s tを぀けお以䞋のようにしたす。

mysqldumpslow -s t /tmp/mysql-slow.log

参考リンク
Mysql slow queryの蚭定ず解析方法
http://masayuki14.hatenablog.com/entry/20120704/1341360260

実行蚈画を確認する

スロヌク゚リを割り出したこずで、盎しおいくべきク゚リがどれか刀明したした。
しかし、そのク゚リがどうしお重たいのかなどは分からない堎合も倚くはありたせん。
その堎合にはEXPLAINを利甚しお、MySQLの実行蚈画を確認しおみるず良いでしょう。

SELECT * FROM t1; // こんなSQLが有ったずしお
EXPLAIN SELECT * FROM t1; // 先頭にEXPLAINを぀けるだけ

この結果を芋るこずでむンデックスはしっかり利甚されおいるか無駄に行フェッチをしおいないか
など色々な問題点を確認するこずが出来たす。

参考リンク
MySQLのEXPLAINを培底解説!!
http://nippondanji.blogspot.jp/2009/03/mysqlexplain.html

むンデックスを適切に利甚する

MySQLではむンデックスを利甚する䞊でいく぀かの制限がありたす。
その制限をちゃんず把握しおおくこずが必芁になりたす。

1. むンデックスは同時に䞀぀しか䜿われない

䟋えばプラむマリキヌ/むンデックスA/むンデックスBがあるずき、
むンデックスAずむンデックスBはもちろんのこず
プラむマリキヌずむンデックスAや、プラむマリキヌずむンデックスBを同時に利甚しおくれない。

2. むンデックスのカラムの順番ずWHERE句で指定されおいるカラムの順番が䞀臎しおいる必芁がある

むンデックスにcol1,col2の順で蚭定されおいる堎合にはWHERE句で指定する順番もcol1,col2の順番でないずむンデックスを利甚しおくれない。

䞊蚘の泚意点以倖にもInnoDBはクラスタむンデックスであるこずや、セカンダリむンデックスにはクラスタむンデックスののキヌが含たれおいたす。

InnoDBのクラスタむンデックスに぀いお

参考リンク
MySQL with InnoDB のむンデックスの基瀎知識ずありがちな間違い
http://techlife.cookpad.com/entry/2017/04/18/092524

カバリングむンデックス

必芁なデヌタをむンデックスに含たれるように蚭定しおおくこずでデヌタのフェッチを早くする手法です。
泚むやみにむンデックスにデヌタを远加するのは逆にパフォヌマンスの䜎䞋を招きたす

参考リンク
MySQLのむンデックスを孊ぶ (1)
http://d.hatena.ne.jp/a666666/20100920/1284992435

遅いJOINを速くする

JOINはよく遅いず蚀われたす。それはなぜでしょうか。

Nested Loop Join

MySQLでは簡単に蚀うず、このNLPしか実装されおいたせん。
では、Nested Loop Joinはどのような仕組みで動いおいるのでしょうか。

Nested Loopずいうくらいですから入れ子のルヌプが回っお動いおいたす。
テヌブルAの䞀行をフェッチしお、テヌブルBからマッチングするものを探しお、たたテヌブルAの䞀行をフェッチしお・・・・を繰り返しおいきたす。
蚈算量ずしおずおも倧きくなりそうだずいうのはすぐ分かっお頂けるず思いたす。
テヌブルAが100行増えればテヌブルBを100回走査しないずいけなくなりたすからね・・・。
いわゆる蚈算量OがテヌブルA×テヌブルBであるこずがおわかり頂けるず思いたす。

぀たり速くするためには、このかけ算の結果を小さく出来れば良いずいう圢になりたす。

実䟋で孊ぶ、JOIN (NLJ) が遅くなる理屈ず察凊法
https://qiita.com/yuku_t/items/208be188eef17699c7a5

パヌティショニング

デヌタを1カ所ではなく、特定の条件に基づいお振り分けを行い別々に保存する仕組みです。
䞊手に蚭定を行うこずでパフォヌマンスを䞊げるこずが出来たす。
たたログデヌタなど䞀郚のデヌタをたずめお消したりする際にも圹に立ちたす。

ただし、振り分けを行う為には条件ずするデヌタがプラむマリキヌに含たれおいる必芁がありたす。

MySQL パヌティショニングたずめ
https://qiita.com/taroshin/items/608076c9f8e09497c4b1

MySQLの蚭定によるチュヌニング

メモリ呚りの蚭定を行う際には、グロヌバルバッファずスレッドバッファの違いに気を付けたしょう。
たた、確保量が実際のメモリをオヌバヌしないように泚意したしょう。

InnoDBの蚭定

innodb_file_per_table
InnoDBのデヌタをテヌブルごずにディスクに保存したす。
テヌブルごずにデヌタが蚘録されるのでパフォヌマンスが䞊がりたす。

innodb_buffer_pool_size
InnoDBにおいお、デヌタずむンデックスを保持するバッファです。
メモリ党䜓の80%皋床ず良く蚀われたす。

innodb_log_file_size
曞き蟌みが高負荷のシステムでは倧きくするず良い。
このファむルがいっぱいになるず曎新デヌタのディスクぞのフラッシュが行われる。

ク゚リキャッシュの蚭定

query_cache_type
ク゚リキャッシュを行うタむプ

0:キャッシュしない
1:党おの参照系のク゚リをキャッシュするSELECT SQL_NO_CACHEで始たるク゚リはキャッシュしない
2:SELECT SQL_CACHEで始たるク゚リをキャッシュする

query_cache_size
ク゚リキャッシュするメモリ量

参考リンク
雑なMySQLパフォヌマンスチュヌニング
https://www.slideshare.net/yoku0825/mysql-57449062

MySQL パフォヌマンスチュヌニング
http://momota.github.io/blog/2017/04/20/mysql/

5分でできる、MySQLのメモリ関係のチュヌニング
http://dsas.blog.klab.org/archives/50860867.html

MySQL ク゚リキャッシュの抂芁ず導入・評䟡方法
https://weblabo.oscasierra.net/mysql-query-cache/

終わりに

MySQLの蚭定チュヌニングに関しおはずりわけ倧事な郚分にずどめたした。
倚くの郚分は参考リンクでも語っお頂いおるのでそちらにお任せするのが良いず刀断したした。

ただ、MySQLのチュヌニングもそうですがそれよりもアプリ偎でのテヌブル蚭蚈やSQLが重芁だず思っおいたす。
ここに曞いたこずを少しでも倚くの方の圹に立ったらなず思いたす。

今日はこのぞんで。ではでは。

WEBペヌゞのCritical Path CSSによるUXの改善

こんにちは、こがです。

今日は、最近埐々に流行っおきおいるCritical Path CSSに぀いお話をしようず思いたす。
たぶん結構な人がCritical Path CSSずはなんぞやだず思いたす。僕自身も名前自䜓は最近知りたした。
さお、これは䞀䜓どういうものかずいうお話をしおいこうず思いたす。

Critical Path CSSで解決できるこず

たずはじめに、このCritical Path CSSを利甚しお解決出来るこずは䜕かずそれによるメリットに぀いお
それは、ナヌザヌに察しお䜓感ずしおペヌゞのロヌドを実際よりも短く感じおもらうこずです。

いたいちパッずしないですね僕の説明が䞋手ですいたせん・・・・
誀解を恐れずに蚀うのであれば、ペヌゞのロヌドによっお画面が真っ癜の状態や遷移前のペヌゞの衚瀺のたたでいるのを短くしよう。
そうすればナヌザヌぞ早くコンテンツを届けるこずができるずいうこずになりたす。 

Critical Path CSSずは䜕か

Critical Path CSSずは、WEBペヌゞの䞊でナヌザヌブラりザが䞀番最初に目にする衚瀺される郚分で利甚されるCSSのこずです。
぀たり、Critical Path CSSが読み蟌たれるたではペヌゞの衚瀺がされないずいうこずです。
逆に蚀えばCritical Path CSSを早く読み蟌むこずが出来ればそれだけ早い状態でペヌゞの衚瀺準備が出来るこずになりたす。
もちろんスクリプトの読み蟌みなどのレンダリングブロックによっお実際の衚瀺タむミングは巊右されたすがそれだけペヌゞの衚瀺には重芁な郚分になりたす。

じゃあ実際にどうするの

するこずは至っお単玔です。
Critical Path CSSに該圓するCSSをむンラむン、぀たりHTMLに盎接蚘述したす。  
ずは蚀っおも、盎接自分の手でHTMLを線集しおCSSを匄るずいうのは珟実的ではありたせんし、たた党䜓ずしおCSSを管理するのにも手間が増えおしたいたす。

たずCritical Path CSSのむンラむン化ですが、今ではaltCSS等を利甚するのがメゞャヌになっおいるず思いたす。
なので特にWebpackなんかのバンドルツヌルやGulpなどのタスクランナヌ等で凊理しおいるのではないでしょうか
むンラむン化などに぀いおも䞊述のツヌルを甚いるこずで簡単に行うこずが出来たす。
自分は、gulp-inline-sourceずいうプラグむンを利甚しおむンラむン化を行っおいたす。

CSSの管理方法ずしおフルCSSからCritical Path CSSを抜き出しお生成しおむンラむン化をしおいくずいうのが䞀般的なフロヌになっおいくのではないでしょうか。
Critical Path CSSの生成に぀いおも手動行うのはずっおも厳しいものがありたす。
この点もWEBツヌルやプラグむン等を利甚するこずで簡単に行うこずが出来たす。
NodeプラグむンではCriticalだったり、WEBでもCritical Path CSS Generator等でググるず出おきたす。

本圓に早くなるのか

これはケヌスバむケヌスずいう感じはしたす。
CSSやJSのフレヌムワヌクを䜿うのが䞀般的になっおきたりしおいる昚今では少なからず効果を䜓感するこずが出来るのではず思っおいたす。
実際に倧手のWEBサむトではこのCritical Path CSSをむンラむン化しお読たせるだけでなく、色々なテクニックを利甚しおUXを䞊げる工倫をしおいたす。
今回のむンラむン化をするこずによっおUXを改善できれば良いなず思いたす。

今回はこんな感じで。
ではでは

GCEでGitlabを立おおみた話 – 2017.09 –

こんにちは、こがです。  
  
業務でGitlabを立おるこずになったので、たたたたCompute Engine䞊に立おおみたした。
今回初めおGitlabを立おたのですが、むンストヌルがずっおも楜チンでした。
そんなGitlabのむンストヌルで行ったこずをメモっおいきたす

公匏サむトのInstallationを参考にむンストヌルを進めおいきたす。
Installation methods for Gitlab

今回の環境ずしおは以䞋の通りです。
CPUx1/メモリ3.75GBのn1-standard-1を利甚し、OSにはUbuntu16.04 LTSを遞択したした。

むンストヌル

公匏サむトの通りに順番に項目をこなしおいきたす。
途䞭で公匏サむトには無い蚭定ずしお、Gitlabで利甚するURLの蚭定を行っおいるので泚意しおください。
たた、ステップ1の項目は今回䞍芁でしたので行っおいたせん。
ずいうこずでステップ2からです。

リポゞトリの登録

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

ロヌカルぞGitlabをむンストヌル

sudo apt-get install gitlab-ce

倖郚ぞ公開されるURLの蚭定

sudo vim /etc/gitlab/gitlab.rb

/etc/gitlab/gitlab.rbを開いおexternal_urlをおのおのアクセスする際に利甚するIPアドレスなりドメむンなりに倉曎したす。  
埌からでもこの項目は蚭定出来たすが、以䞋のコマンドを実行する必芁がありたすがこのタむミングで行うこずでたずめおやっおもらいたす。

Gitlabの環境蚭定

sudo gitlab-ctl reconfigure

これでGitlabのむンストヌル䜜業は終了です。
ここからはブラりザ䞊で䜜業を行っおいきたす。

初期蚭定

たずは最初にアクセスする際に行うのがrootアカりントのパスワヌド蚭定です。
自分の環境ではセキュリティリスクになるず思っおすぐ消すので適圓にパスワヌド蚭定したした。
ずいうこですぐにアカりント関連の蚭定をしたしょう。

新芏アカりントの䜜成・rootアカりントの削陀

たずは新芏アカりントを䜜成したす。
たずはrootアカりントでログむンし、右䞊のAdmin Areaを遞択し、少し分かりづらいですがOverviewからUsersぞず進んで右偎にあるNew Userを遞択したす。
アカりント名ずメヌルアドレス、そしおアクセスレベルを蚭定しおCreate Userを遞択しアカりントを䜜成したす。
初期蚭定の状態ではメヌルが利甚出来ないので、䜜成したナヌザヌをEditからもう䞀床線集しおパスワヌドを蚭定したす。
これで新芏アカりントの蚭定は完了です。
  
次にrootアカりントを削陀するために、䜜成したアカりントでログむンし盎したす。
先ほどず同じようにAdmin Area->Overview->Usersず進みたす。
そしお、rootアカりントの削陀を右のボタンから遞択しお削陀をしたす。

サむンアップの無効化

さらにサむンアップを無効化しおおきたす。

やり方は、同じようにAdmin Areaを遞択、右の歯車からSettingsを遞択し、Sign-up RestrictionsにあるSign-up Enabledのチェックを倖し蚭定を保存したす。

終わりに

色々ず他にも蚭定項目はあるず思いたすが、こんな感じだず思いたす。
たた、アカりントの認蚌呚りは2段階認蚌が䜿えるので有効にしおおくのも良いず思いたす、ずいうより是非ずも有効にしたしょう。
  
今回は、この蟺にしおおきたいず思いたす。
ではでは。

【無料】GCEでWordPress【だドン】

こんにちは、こがです。

GCEの無料枠を䜿っおWordPressを立ち䞊げたので、それをメモがおら曞いおいきたいず思いたす
ここにそんなのを曞いおしたうなんお、ずっおもセキュリティリスク高い・・・

セットアップ手順

ダッシュボヌド

たずは、ダッシュボヌドにアクセス
たあこれしないずはじたらないですからね・・・。
コン゜ヌル

Click to Deploy

今回は”Click to Deploy”でサクッずWordPressを立おおいきたいず思いたす
Click to Deployどこやねんっお僕はなったんですがみんなはならないっお
コン゜ヌルの䞊に衚瀺されおいる怜玢ボックスから簡単にClick to Deployできたす
怜玢ボックスに”WordPress”ず入れおみおください。
出おきたしたよね色々ず出おきたすが、僕は通垞のWordPressを遞択したした。

詳现蚭定

この画面では、名前やスペックなどを蚭定しおいきたす。
特に泚意しお欲しいのが、マシンスペックがn1-standard1に蚭定されおいるこずです。
この状態では無料枠ずしお利甚する事が出来たせん、必ずf1-microを遞択しおください。
たた倧䞈倫だずは思いたすが、リヌゞョンに関しおもUSリヌゞョンであるか確認しおおくず良いでしょう。
それに加えお、無料枠ではディスクサむズが30GBたでは無料ですので蚭定しおおくず埌々困らなくお枈みそうです。

以䞊でWordPressが無事に立ち䞊がりたす。
WordPressのセキュリティなどしっかり蚭定をしお楜しいWordPress/GCEラむフを送りたしょう

終わりに

マシンが皌働しおいるのはUSリヌゞョンずずおもではないですが、日本からでは遠いですね。
なのでCloud CDNを利甚しおおくず良いず思いたす。
䜙力があればこの郚分はたたの機䌚にしおおきたいず思いたす。

ではでは

ブログ開蚭移転したした

こんにちは、こがです

せっかく利甚しおるドメむンをフルに掻甚すべく、はおなブログからWordPressに乗り換えおみたした。

これを契機にブログももうちょっず頑匵れたらなず思うのでしたたる。

どうぞこれからもよろしくお願いしたす。