Rubyに入門する必要があったので、Rubyを書いたことがない僕でも最近話題になっていると知っていた、プロを目指す人のためのRuby入門を購入して読んでみました。
Kindleで読んだのではじめはわからなかったのですが、紙の本では全体で472ページとかなりボリュームのある本で、読み終えるのにかなり時間がかかりました。
出版からかなり期間が空いてしまっていますが、感想と良かったところを描いておこうと思います。

難易度

第1章で書かれている対象読者に「Rubyを使った仕事に就きたい人」ということが書かれており業務でのプログラミング歴といえば、1年半程度PHPとJavaScriptで仕事をしてきて今度Rubyを使って開発する予定の僕にはピッタリの本ではないかと思いました。
実際、各章の例題を写経したり、いたるところに出てくるサンプルコードをirbで実際に動かしたりすることで、これまでに学んできた言語との書き方の違いを意識しつつ学習をするめることができました。
また、Ruby以外の基本的な話題や、書籍では書ききれないトピックなどは、著者の伊藤淳一さんの書かれたブログや、参考文献、読むべきドキュメントなどを豊富に記載していただけているので、本当に初学者であっても丁寧にやっていけば読破できるのではないかと思いました。

TDD、リファクタリング

この本では2章から10章でそれぞれの章の文法を理解するための例題があります。

すべての例題は、こちらで写経しました。

github.com

お題紹介からTDD(テスト駆動開発)のサイクルを説明しながら読者と一緒に例題を解いていくというスタイルでした。
TDDについての詳しい説明はありませんでしたが、

通らないテストを始めに書く
とりあえず通るように仮実装する
テストコードを増やす
本実装をする
リファクタリングをする

という一連の流れを実際に各章で体験することが出来る、良い例題でした。

その中でも、第7章の改札機プログラム、第10章のワードシンセサイザーの作成はすごく面白く進めることができました。

Rubyらしい書き方

例題が終わった後は、各章の文法をより深掘って説明されています。
すると、

この文法のこの書き方は、実は以前説明したこの書き方でも代用できます
この書き方は一応文法として紹介しておきますが、あまり業務で触れることはないでしょう

などと言った説明が散見されます。

この本でも言及されていますが、以前からRubyは色々な書き方ができる、というように聞いていたので、それを実感しました。

一度読んだだけでここで紹介されているすべてを書き方を覚えることはできないので、頭の片隅に入れつつ折にふれて戻ってきたときに、自分の進歩がわかるのではないかと思いました。

まとめ

Rubyに入門しましたが、紹介されていた資料なども読み切れていなかったりするのでこれがRubyの「門」なんだな、という感じです。
これからコードを書いていってこの本に立ち返っていくことになるだろうと思いました。

2018-03-25

【2018年版】分割キーボードのErgoDox EZ購入から利用開始まで

キーボード ErgoDox

分割エルゴノミクスキーボードとして有名な、ErgoDox EZを購入したので、まだ3日しかたっていませんが、購入方法と行った設定などをまとめておきます。
まだ慣れませんが、この記事はすべてErgoDox EZで書いています。

f:id:zuckey_17:20180325144301j:plain:w400

動機

ErgoDoxの特徴としてあげられるのは、

左と右でキーボードが別れている
親指に6角キーが割り当てられるという変わったキー配列
キーのマッピングはオープンソースで開発されているソフトウェアによって、カスタマイズ可能

ということですが、買った基本的な動機は単なるミーハー心です。
後は肩こりひどくなってきたので胸を張って肩甲骨をしっかり閉じた状態にしておくという開発体験をしたいということで、購入しました。

購入

ergodox-ez.com 公式ページから購入しました。
Let's splitや自作することも検討したのですが、はんだ付けなどやったことがなかったため、初めてとしてやめておきました。

僕の場合は、3月5日に注文して3月22日に到着したので、2週間強で受け取ることができました。
ブログによっては、5日位で届いたというのも見たことがありますし、注文完了のメールによると受注生産だそうなので、混み具合によっても変わってくるのではないかと思われます。

注文完了メールには、トラッキング出来るよ、と書いてあるように見えますが、実際そのリンク先には注文内容がそのまま載っているだけです。
運送業者は(おそらくデフォルトだった)DHLを選択しましたが、発送が完了した段階でDHLから連絡がきて、何日に届くのかということがわかります。
僕の場合は時間指定はできず、22日中に届くと書かれていましたが、21時ころに届きました。

f:id:zuckey_17:20180325143840j:plain:w300

金額

角度をつけるための足 $25.00
リストレスト $30.00
本体 $240.00

を購入しました。注意が必要なのは、値段はこれだけではなかったということです。
全世界共通の配送料が +$30と運送業者に支払う税関係が約3000円かかりました。

オプションについて

筐体はブラック、キーキャップもブラックの無刻印のものを選びました。
キーボードの軸はそれによってうち心地とかがかわるというので悩みましたが、

fps.game2ji.com

を参考に、静かで疲れにくいという観点から、赤軸を選びました。

設定など

到着した状態で、USBを繋げばUS配列キーボードとして普通に使うことができます。
デフォルトのキー配列は、こちらのURLから確認することができます。

ErgoDox EZ Configurator

こちらのページではErgoDoxの特徴であるキーマップのカスタマイズをすることもできます。
ここでは、キーマップを独自のものに変更する手順を紹介します。

準備

まず、Teensy Loaderというキーマップの書き込みに必要なアプリケーションで、利用しているOSにあっているものを以下のページからインストールする必要があります。

Teensy Loader Application - available for Windows, Linux and Macintosh systems f:id:zuckey_17:20180325144350p:plain

キーマップを決定

ErgoDox EZ Configurator f:id:zuckey_17:20180325145322p:plain

こちらのページにアクセスし、
Clone and modify this layoutをクリックします。
すると、キーマップが変更できるようになります。
GUIで簡単に変更することができますが、真ん中のロゴをクリックすると英語ですが、このページの詳細な使い方の動画に飛ぶことができます。

レイヤー

キーマップ設定画面にはLayerというタブがあります。
レイヤーを変えて、それぞれのキーに違う役割を割り当てることができます。
レイヤーを変えるためによく使う役割は以下の2つです。

TG: レイヤーを切り替えます。他のキーが切り替え後のレイヤーの役割をするようになります。
LT: この役割を割り当てられているキーを押している間のみ、他のキーが指定のレイヤーの役割をするようになります。

それぞれを利用する場合には、キーをクリックして出てきた吹き出しの↓で示した部分にそれぞれ、「LT」「TG」と入力することによって候補を絞ることができるのでその中から選びましょう。 f:id:zuckey_17:20180325144359p:plain 他にも様々な役割があるので、キーをクリックして説明を見ましょう。

キーのコンパイルとダウンロード

好きなようにキーマップを変更できたら、キーマップに名前をつけてからCompile this layoutボタンを押します。
次に、Download this Layoutボタンを押すと、.hexの拡張子を持ったファイルがダウンロードできると思います。

キーマップの書き込み

最後に、Teensy Loaderを起動し、「File>Open Hex File」をおして先ほどダウンロードしたキーマップファイルを選択します。
そして、右手側のキーボード以下の部分にある小さな穴の中のボタンを押します。(僕は安全ピンでやりました。)

f:id:zuckey_17:20180325144230p:plain:w300

すると、「Operation>Program」が押せるようになり、押した後に、「Operation>Reboot」によって、キーマップの書き込みが完了します。

完了すると、指定のキーマップによる入力が、完了していると思います。

まとめ

まだ、消品が到着してから2日しか経っていないので、レビューではないですが購入から利用開始までの流れを書きました。
特に注文してからの流れや、初めてのキーマッピングのところなどは、最近の日本語の記事は多くなかったと感じたので、参考になれば幸いです。
これからもキー配列などどんどん変わっていくとは思いますが、次は、キーマップのローカルでのコンパイルや、マクロを登録するなどに挑戦したいと思います。

2018-03-18

npxとnpm-run-allでローカルモジュールを実行する

JavaScript 小ネタ

小ネタです。

npm管理下のプロジェクトで、なにかのモジュールのコマンドを叩きたいということがよくあります。

その場合、僕がよく使っていたのは、

./node_modules/.bin/(パッケージ名)
package.jsonにnpm-scriptsを書いて npm run (script名)

でした。

npx

ところが、npm 5.2.0からは、npxというコマンドが利用可能になり上のどちらの方法よりもシンプルに使えるようになっていました。

npx （パッケージ名）

また、npxコマンドを使うと、ローカルのプロジェクトにインストールしていないモジュールのコマンドも、一度だけ実行することが出来ます。

npm-run-all

また、npm-scriptsをたくさん実行したいときがあると思います。その時は

npm run lint & npm run build:server & npm run build:client

などと書いたりします。

こちらもnpm-run-allというコマンドを利用すると、シンプルに書くことができます。

www.npmjs.com

npm install -D npm-run-all

してから、上記のようなコマンドであれば、

npm-run-all lint build:*

というふうにまとめることが可能です。

コマンドの実行時に、オプションとして

-sで順次実行に、-pで並列実行になるので、こちらも覚えて置くと良いかもしれません。

まとめ

ちょっとしたことでしたが、僕は最近まで知らなくて、いちいち./node_modules/.bin/(パッケージ名)などと書いていたので、その手間が省けて良いなとおもいました。
こういう日々の細々した事によって効率に違いが出てくるので、皆さんもそういった小ネタをどんどんアウトプットしていただければ嬉しいです！

2018-03-18

TypeScriptで"SyntaxError: Unexpected token import"になったときの解決方法

TypeScript

昨日の記事を公開したところ、

blog.zuckey17.org

↓のように、

ライブラリと型定義のimportとで分けている必要はあるのか？

という指摘をいただきました。

const { createConnection } = require("mysql"); // ライブラリのimport
import { Connection, MysqlError } from "mysql"; // 型定義のimport

僕も実装をしている際に、以下のような書き方をしようとしましたが、

import * as mysql from "mysql";

トランスパイル後のjsを実行するとランタイムで以下のようなエラーが出てしまいました。

******/ts-mysql/src/index.ts:1
(function (exports, require, module, __filename, __dirname) { import * as mysql from 'mysql';
                                                              ^^^^^^

SyntaxError: Unexpected token import
    at createScript (vm.js:80:10)
    at Object.runInThisContext (vm.js:139:10)
    at Module._compile (module.js:607:28)
    at Module.m._compile (/Users/matsumura/dev/src/github.com/zuckeyM-17/ts-mysql/node_modules/ts-node/src/index.ts:400:23)
    at Module._extensions..js (module.js:654:10)
    at Object.require.extensions.(anonymous function) [as .ts] (/Users/matsumura/dev/src/github.com/zuckeyM-17/ts-mysql/node_modules/ts-node/src/index.ts:403:12)
    at Module.load (module.js:556:32)
    at tryModuleLoad (module.js:499:12)
    at Function.Module._load (module.js:491:3)
    at Function.Module.runMain (module.js:684:10)

tsconfig.json

結論としては、tsconfig.jsonのcompilerOptions中のmoduleの値をes2015からcommonjsに変更すると解決しました。

module

TypeScript公式のcompilerOptionsのリファレンスにおいて、
moduleの項には、

target === "ES3" or "ES5" ? "CommonJS" : "ES6"

という記載がされています

トランスパイル先がES5やそれ以下の場合、CommonJSを使いましょうということですね。
今回は、サーバサイドで動かすということで、WebpackやBabelなどを利用せず、Node.jsとして動かすという実装だったので、CommonJSを指定する必要があったようです。

Node.jsとES2015のmoduleのインポートの方法の違い

moduleにES2015を利用するとそれでは普通に使える、import/exportの記法は、そのままスルーされる。型定義のimport句については、TypeScriptのトランスパイル時の静的解析に使われるだけなので、ランタイム時には影響がなかった。

ということでした。
つまり、サーバサイドで動かすとしても、WebpackやBabelをかませるなどすると、問題なく利用できるようです。
そちらを検討しても良いかもしれません。

まとめ

TypeScriptのみならず、JavaScriptにおいても、モジュール解決や、import/export、が実行環境などによってややこしいです。
また、環境設定などは公式や人の記事を見て動けばそのまま使ってしまっていたり、一度固まればあまり振り返る機会がなかったりしていました。
日頃からtsconfig.jsonや、webpack.config.jsなどなどもやもやしながら使っている部分があるので、もう少ししっかり学習する必要があると感じました。

今回のブログをかけたのは、昨日のブログにたいして指摘いただけたからです。
もしこのブログでも気になる部分がありましたらコメントやTwitterで指摘いただけるとうれしいです。

おまけ

TypeScriptを簡単に実行するために、ts-nodeという実行環境を利用しています。

npx ts-node 実行ファイル

とすると、TypeScriptを実行することができます。

しかしながら、この状態では、importが利用できません。
そのため、import/exportを利用したい場合は、以下のようにprojectオプションを付ける必要があります。

# --project の引数は、tsconfig.jsonへのパス
npx ts-node --project tsconfig.json 実行ファイル

2018-03-17

TypeScriptでMySQLを触るメモ

TypeScript

最近、TypeScript でサーバサイドを書く機会がありました。
DBに MySQLを利用していましたが、データの挿入や取得の簡単なものでも、少しハマったのでメモを残しておこうと思います。
TypeScriptについては、触りたてということで間違いなどがあれば、コメントやTwitterなどで指摘いただければと思います。

github.com

作成済みのデータベース

すでに作成しているデータベース、テーブルは以下のような状態になっています。

データベース名：sandbox テーブル名：users

users

id	name
1	zuckey

インターフェース

interface User {
  id?: number;
  name: string;
}

事前準備

ライブラリのimportとMySQLコネクションを作成します。

const { createConnection } = require("mysql"); // ライブラリのimport
import { Connection, MysqlError } from "mysql"; // 型定義のimport

// コネクションをはる
const con: Connection = createConnection({
  host: "localhost",
  port: 13306,
  user: "root",
  password: "password",
  database: "sandbox"
});

SELECT

const selectSql = "SELECT * FROM users;";
const getUsers = (): Promise<User[] | Error> => {
  return new Promise((resolve, reject) => {
    con.query(selectSql, (err: MysqlError | null, results: any) => {
      if (err) {
        reject(err);
        return;
      }
      resolve(results);
    });
  });
}

getUsers().then((users: any) => {
  users.forEach((user: any) => console.log(user.name)); // "zuckey" と表示
  process.exit(0);
})
.catch((err: Error) => {
  console.log(err);
  process.exit(1);
});

INSERT

const insertSql = "INSERT INTO users SET ?;";
const createUser = (name: string): Promise<string | Error> => {
  return new Promise((resolve, reject) => {
    con.query(insertSql, { name: name }, (err: MysqlError | null, results: any) => {
      if (err) {
        reject(err);
        return;
      }
      resolve("success!");
    });
  });
};

new Promise((resolve, reject) => {
  con.beginTransaction((err: MysqlError) => {
    if (err) {
      reject(err);
      return;
    }
    resolve(getUsers());
  });
})
  .then((result: any) => {
    console.log(result); // "success!"と表示
    process.exit(0);
  })
  .catch((err: Error) => {
    console.log(err);
    process.exit(1);
  });

ハマった部分

@types/mysqlにおいて、Connection.query の第2、3引数のqueryCallbackの型定義は以下のようになっています。

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/mysql/index.d.ts#L226

export type queryCallback = (err: MysqlError | null, results?: any, fields?: FieldInfo[]) => void;

そのため、上の例ではこちらにのっとっています。

しかしながら、「typescript mysql」でググると、3番目くらいに出てくる以下のリポジトリを見ると、

f:id:zuckey_17:20180317073552p:plain:w300

https://github.com/types/mysql#usage

queryCallbackの第2引数は、SELECTの場合 RowDataPacket[]、INSERTの場合 OkPacketになる、という風に読めます。
スター数などを見ると明らかに怪しいですが、使用例を出してあると、それっぽいな、と思ってしまいました。

まとめ

振り返るとそこまで難しくはないですが、ハマってしまったのは、サードパーティ性ライブラリの TypeScriptの型定義の扱いに慣れていなかったのかなと思いました。
引き続きTypeScriptを触っていき、学習しようと思いますが、MySQLの利用については、ORMの利用を考えようと思います。

2018-03-10

雑な感想とメモ【PHPerKaigi 2018】@練馬区産業プラザ 20180310

phperkaigi.jp

前夜祭に引き続き当日も参加しました。

blog.zuckey17.org

トークの感想と聞いている最中のメモを残しておきます。

PHPの現場公開録音もありました！！

togetter.com

TODO: 資料とビデオのパスを追加

トーク

今からでも出来る!Wwbサービスモニタリング!! - @soudai1025

speakerdeck.com

soudai.hatenablog.com

RDBで有名な@soudai1025さんのWebサービスについての監視についてのお話。有名でお名前はしってたんですが、初めてトークを聞きました。
僕は普段アプリケーション層の開発をしていて、インフラをされている方ほど、監視は積極的に考えていなかったです。

そんな中で、話を聞いていたんですが、

小さく初めてその後踏み込んでいくこと
時系列データを取って可視化すること

などを強調して語られており、初心者にもわかりやすいトークでした。

SOLIDの原則って、どんなふうに使うの？ - @hidenorigoto

ベストトーク賞おめでとうございました！！

✨✨✨ベストトーク賞発表🎉「SOLIDの原則って、どんなふうに使うの？」後藤秀宣 ( ゴトウヒデノリ )さん @hidenorigoto でした！！！✨✨✨#phperkaigi
— PHPerKaigi 2018@3/9-10 本編＆懇親会チケット販売中！ (@phperkaigi) 2018年3月10日

[資料公開待ち]

とある新人と先輩のコミカルなやり取りを例にしてオープン・クローズド原則について説明してくださってました。
名前は聞いたことがありましたが、理解はしていなかったので非常にわかりやすく、他のかたもTwitterでおっしゃっていましたが、新人教育みたいな場でやってほしいトークでした。

「バリエーションからソースコードを守る」という表現が非常にキャッチーでわかりやすかったと思いました。

サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技 - @yoku0825

サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技 from yoku0825

www.slideshare.net

PHPなしのMySQLのバックアップのお話。
監視と同様、普段あまり気にしていない分野でしたが、主に

フルバックアップ
バイナリーログバックアップ

という2つのバックアップ手法を用いてDBの復元が出来る方法を、注意点とともにまとめてくださっていました。
細やかな情報が書いてあるスライドを爆速で飛ばしていくスタイルで、資料はしっかり読み返さないとなという感じでした。

Hackで作るマイクロフレームワーク - @ytake

speakerdeck.com

事前に資料が公開されるスタイルだったので、読んでから参加しました。
Hackという言語は触ったことがなかったので、その概要と今後の大まかな流れについて知ることができました。

型定義ファイルのhhiファイルの紹介で、TypeScriptやFlowTypeのことを例に出されていて、結局そのへんはコミュニティの尽力なんだなっていう風に思いました。

また、前夜祭でのテスティングフレームワークにもありましたが、言語を勉強するときにフレームワークを作るというのが勉強になる、ということだったので、とりあえず公開されているらしいコードをよんでみるこからはじめてみたいな、と思いました。

PHPStanで始める継続的型検査 - @Hiraku

speakerdeck.com

PHPStanによる静的解析の話。
素のPHPに対してのもの、という点では違いますが、↑のトークも見ようによっては静的型解析の話でした。

7系でプリミティブ型の型注釈が入ったとはいえ、あまり強くない型チェックのPHPと静的な解析は難しく、テストで担保するべき部分があるということをおっしゃっていました。
前前夜祭のLarvel Meetup Tokyo #10、前夜祭とともにテストの話が多かったのも、静的な言語が流行りつつある中で、動的なPHPを好きな人たちが、それでも安心感を持って開発するためには、テストが必須だったということなのかな、と思いました。

まとめ

前夜祭とは違って、PHPを利用してアプリケーション開発をする上での色々な分野の話を1日で聞けたのは非常に楽しかったです。
最近参加した大きなカンファレンスの中でも、どなたの発表もすごく上手だな、とすごくハイレベルに感じたので、発表する手法としても学ぶ分が多かったカンファレンスだったと思いました。*1

僕はしがないラジオというPodcastのパーソナリティをしているんですが、そのリスナーの方が話しかけてくださって、写真を取りました！！ありがとうございました。
こういうのも、カンファレンスのいいところだなと思いました！

ペチパーカイギで
しがないラジオのズッキーさんと記念撮影‼

あざまっす！＞＜#しがないラジオ #phperkaigi pic.twitter.com/IykR6SlU5P
— gremito (@grem_ito) 2018年3月10日

おまけ（以下メモ）

あくまで個人的なメモです。詳細は、公開される資料とビデオを参照ください。
LTもありましたが、ビールが入っていたので省略します笑

今からでも出来る!Wwbサービスモニタリング!! - @soudai1025

PHPerのためのWebサービスモニタリング

モニタリングしてますか？
アプリケーションエンジニアのためのモニタリング

障害に気づく
障害原因を究明
未然に障害を防ぐ

話さないこと

システムメトリック
データベースの監視はしない

過去のスライドとかブログを見てほしい

そーだいなるらくがき帳

Webサービス + PHP

Webサービスは生き物 = 常に変化
シーズンや時間帯、年によっても変わる

3層の監視

サーバサイド
- モニタリングしやすい
インターネット
- コントロールできない領域だからこそ、監視が必要
クライアント
- コントロール可能だが、ユーザ操作など意図しないことが多い、予期しない不具合

可視化が大事

時系列のデータを取る

課金料や使っているサービスのモニタリングもする

モニタリングの勘所

ちっちゃく始める

リソースを"正しく"使えているか？
- リソースは過不足なく使えているか？
意図しない挙動に気づく
- リリースによる変化の機微に気づく

踏み込んだシステムの可視化

スライドに多くの例示あり

誰も見ないグラフに意味はない => ダッシュボードの棚卸しが必要

PHPのモニタリング

PHPの仕組み？
プロセスとPHP

イベントとPHP

参考ブログ: 2015年Webサーバアーキテクチャ序論

PHPとキャッシュ

OPCache => コードキャッシュ
APCu => データキャッシュ

https://github.com/krakjoe/apcu/
https://gist.github.com/ck-on/4959032

Apache Server Status
nginx_status

まとめ

常に見続けられるわけじゃないから、時系列にデータを持つ、そして定期的に変化を確認する
推測 -> 計測 -> 観測
事実をより多く、正しく知ることで、未来を正しく予測できる

Webサービスを監視するときに僕達が考えたこと
SRE本

エンジニアには根拠が必要
なんとなくでは仕事はできない

テストコードはプログラムの品質の可視化
モニタリングはインフラの品質の可視化

QA

DBの問題は金で殴ると解決する
- CPU
- メモリ
- ファイルI/O
サーバレスのモニタリング
- 正しく処理ができているときにどのくらい時間がかかっているか、その結果、処理の数が増え続けていたら注意
- AIで自動でindexをはるとかいう時代になったときにエンジニアはどう振る舞うのか？が今後の課題

SOLIDの原則って、どんなふうに使うの？ - @hidenorigoto

SOLIDの原則
5つの設計原則の頭文字

単一責務
Open Closed
リスコフの置換原則
インターフェース分離の原則
依存関係逆転

オープン・クローズドの原則

目標

原則の理解する

コマンドラインで使うTODOアプリ - いわゆるMVC フレームワークは使わない - TODOにバリエーションが有る - TODO - GoogleCalendar由来のTODO

常に未知の仕様を検討するわけじゃなく、検討すべき根拠のあるものを検討する

オープン = 機能を拡張できる
クローズド = 修正を行わない

同時に満たす

バリエーションを起因として、モジュールに新たな振る舞いを追加する際に、既存のコードを修正せず、単に新しいコードを
バリエーションからソースコードを守る

バリエーションによって変化する部分は？軸に沿ってまとめる

勝手に調べた資料: 何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita

おすすめ書籍: レガシーコード改善ガイド

サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技 - @yoku0825

MySQLのバックアップ

リプレイする

最初から全部同じクエリを発行していれば、同じテーブルを再現できる
全て正しく

randomは難しい

リプレイ unsafe = バックアップ unsafe

手法おさらい

フルバックアップ
バイナリーログバックアップ
差分バックアップ

定期的なフルバックアップとバイナリーログバックアップをする
※レプリケーションフィルターは使用しない

バイナリーログバックアップ

任意の時間まで戻れる
できるだけ多くのログを他のストレージにうつしておけるかがキモ

GTID

日々のバックアップ

バックアップスクリプトのログを残す
文字コードの設定が変わっている場合の文字化け => configもバックアップしとこう

障害の切り分け

単純なクラッシュ
データの復元

サーバー1台でやる？

結局スレーブ作ったほうが早い。。。

フルバックアップをデイリーで取って90日分のバイナリーバックアップ

binlogのリアルタイム保存の方法

--read-from-remote-saver  --stop-never --raw

スレーブだと思って文字コードを整えて、やってくれる

リストアの手順
gtid_mode

まとめ

安全なバックアップライフを

QA

binlogのバックアップの正しさはどう担保する？

監視
1つ1つのバックアップ量を小さくして取り直しのオーバーヘッドをできるだけ小さく

Hackで作るマイクロフレームワーク - @ytake

なぜGoじゃないの？
=> PHPの開発者が使えるものを増やしかった

開発するための知識

PHPのコードがそのまま実行可能
厳格なType Checker
Async, XHP, Generics, Collections
3.24 LTS
HHVMは、Hackを対象にしていくので、PHPとHackはどんどん別物になっていく

Type Checker

decl
parcial
strict

既存のPHPコードはstrictでは使えない
=> コードレビューをビジネスロジックに

callableに気をつける

hhiファイル

TypeScript, Flowと同様の型定義ファイル
単体では実行不可
使いたいPHPのコードも保管したい場合は、作成してpackagistで公開しよう！

PSR For Hack

独自のものを作ろうとしている
PSR-7対応のライブラリから対応してくるもよう

強力なライブラリ

hhvm/hhvm_autoload
Composer Plugin

hhiを探して、IDEの補完が効く
PHP7依存のライブラリは、コマンドでHackで使うことができる

hack-router

ytake/hh-container

コードは資料参照

mixed使うな！
anyと一緒笑

コンパイラのために書く
invariant

hhvm/type-assert

RouterとContainer、簡単なValidationがアレば、最低限の動作が可能に

フレームワークは小さなライブラリの集合体へ

Request BodyなどのValidationにtype-assett
mixedのケア

まとめ

Hackだからなにか特別なもの、というのはない
バグが少なく堅実
コードレビューの負荷軽減
簡単では？

QA

文化的バックボーン、簡単なものになれているユーザーを取り込むのはきびしい？
- PHPの悪いところをなくす => C++のながれや、その違いが出てきている
- 別離の方向に進んでいるのは事実
フレームワークはあるの？
- ない、作ろう

PHPStanで始める継続的型検査 - @Hiraku

dynamic と static

dynaic = 動かしてみる

実行されると困る場合
全部テストするのは現実的にムリな場合

static = 動かさずに読む

言語によって出来ることが違う
理論上、決定できない種類のものもある

工夫が必要

影響範囲が多いと漠然とした不安がある

マニュアルでは莫大な時間が
リリースに勇気が必要

staticをCIに組み込みたい！

PHPStan

phpstan/phpstan

Install

composer
phar版
docker hub

バージョン違いに注意

Run

vender/bin/phpstan
カスタムルールも設定可能
正規表現でエラーメッセージをマッチさせることもできる

CIとの連携

2段階でのチェック
reveiwdogが便利

autoload

PHPStanは一部コードを実行する
autoloadに酔って呼び出されたファイルは実行されてしまう

PHPは静的解析しづらい
コンパイルとランタイムの境界が曖昧

100%静的に頑張るのではなく、動的も混ぜるPHPらしいいい落とし所

PHPStanの基本動作

型注釈が丁寧であればあるほどよい
PHPの型注釈は自由度が低い
なので、PHPDocを混ぜて使う
PHPStanはどちらも解釈してくれる

スカラ型に注意

doubleじゃなくてfloat
integer、booleanはない

PHPDoc

PHP公式の機能ではないが、標準らしきものはある

スペース区切り
型を固定した配列
union風記法
true/false

現状できないこと

リスコフの置換原則(LSP) - 型を派生した時、元の能力が減ったらだめ

クラスで頑張れなくもない
ムリに頑張る必要もない

テストすればいい

不安ならユニットテスト

まとめ

PHPも静的解析がしやすく
static方面の充実により漠然とした不安が
動的と静的の美味しいところを使う

*1:実際、ベストトークはすごく僅差だったという話でした

メモ

メルカリ 会場スポンサー LT

チームをCQRS - boiyaa

CQRS ?

人の役割もCQRSを取り入れたい？

フロント未経験者のReactプロダクト改善 - shikichee

たまる技術的負債

Context API

子階層から直接呼び出せるようにしたい

React.createContext()

What is necessary for Developer Friendly UI? - kuwahara

Bad sample of Web page UI

forkwell スポンサーLT

できないエンジニア

できるエンジニア

Vuetifyで学んだあれこれ - ともこ

Vue

さわってみて

HyperappでMarkdownエディタを作って薄い本をかきたい - atsuco

Hyperapp?

Markdownエディタ

Osushiに見るフロントエンドのセキュリティ - シベ

「控えめにいって最悪の経験をした」

セキュリティ対策

継続的 npm update のために実践していること - シゲオカ タダシ

Tokyo Otaku Mode

nom update

npm ローカルモジュールを活用する

アップデートツール

WASMとES modules - chikoski

WASMはモジュール

WASM Web embedding API

より便利に

難易度

TDD、リファクタリング

Rubyらしい書き方

まとめ

動機

購入

金額

オプションについて

設定など

準備

キーマップを決定

レイヤー

キーのコンパイルとダウンロード

キーマップの書き込み

まとめ

npx

npm-run-all

まとめ

tsconfig.json

module

Node.jsとES2015のmoduleのインポートの方法の違い

まとめ

おまけ

作成済みのデータベース

users

インターフェース

事前準備

SELECT

INSERT

ハマった部分

まとめ

PHPの現場公開録音もありました！！

今からでも出来る!Wwbサービスモニタリング!! - @soudai1025

SOLIDの原則って、どんなふうに使うの？ - @hidenorigoto

サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技 - @yoku0825

Hackで作るマイクロフレームワーク - @ytake

PHPStanで始める継続的型検査 - @Hiraku

まとめ

おまけ（以下メモ）

今からでも出来る!Wwbサービスモニタリング!! - @soudai1025

話さないこと

Webサービス + PHP

3層の監視

可視化が大事

モニタリングの勘所

ちっちゃく始める

踏み込んだシステムの可視化

メルカリ会場スポンサー LT

継続的 npm update のために実践していること - シゲオカタダシ