taisablog

taisa's engineer blog

スクリーンショット 2019-06-26 20.34.46

投稿日:

-

執筆者:

関連記事

2019年の抱負

本業頑張るのはもとより、2019年の抱負がある程度固まってきたので書いておきます。 Google Cloud Platformを使う これまでAWSを自分で多く触るケースはあまりありませんでしたが、GCPを使うケースが増えてきたので今年からはAWSではなくGCPをたくさん触っていこうと思います。 数学をやる 高校3年になるまでは大学行く気もなく全く授業をまともに受けていませんでした。高校2年の終わり頃に少しまじめに授業を受けるようになり、少しずつ数学が楽しくなってきた頃大学進学も視野に入ってきました。そんなときに自分が文系を選択していたことを知り、私立受験は英国社の三教科であることを知り(国立など受験の仕組みすら知らず)、そこで自分の数学学習人生は終わりました。そんなこんなで今までやってきたのですが、ふと最近以下の投稿をみてなんとなくやってみようかなと思いはじめました。記事のようにAIや機械学習の為ということも少しはありますが、自分としてはただの興味ですのでどこまでやれるかはわかりませんが、今小学中学の復習を終え数I・Aをちらちらみはじめています。 文系エンジニアが機械学習に入門するために小学校の算数から高校数学までを一気に復習してみました。 宅建をとる 今の本業が不動産テックということもありますが、これもただ興味が出てきたのでやってみようかなという感じです。宅建みやざき塾というYoutube動画が秀逸なので今はこの動画を移動中などにみています。 体力をつける 小さい子供が2人いると休日にランニングすることもままならないので去年は体重がかなり増えてしまいました。運動ができてないだけでなく、肩こりなど疲れやすい状態になっていたのでこれを今年は改善しようと思います。最近は食事や運動を気にしつつ「長生き味噌汁」をはじめました。 まとめ どこに向かっているのかという感じはありますが、本業で事業を伸ばすことを頑張りつつこれらをやっていこうと思います。

PHPによるDBUnit超入門

例えば簡単なWebサービスでMVCのフレームワークを使っていてビジネスロジックを書く用にコントローラとモデルの間にサービス層を追加して開発している場合、コントローラやサービスはモックを駆使しながらテストを書いていくことができます。ただ、例えばフレームワークをバージョンアップしたい、PHPをバージョンアップしたいなどの場合に既存のモデル層に影響がないかをテストで確認したいなんてことがあります。そのような場合には、DBUnitを導入してみてもいいかもしれません。ということで本記事ではPHPによるDBUnitの使い方を書いてみます。 事前情報 今phpunit/dbunitをインストールしようとすると以下の文言が出力されます。詳しくはこちらのissueに書いてありますが、どうもSebastianさんはdbunitのメンテナンスをやめるようです。ただそれを受けてforkしたプロジェクトが出てきているようなので大丈夫かと思います。今回はSebastianさんの純正dbunitを使っています。 Package phpunit/dbunit is abandoned, you should avoid using it. No replacement was suggested また、DBUnitに関する詳しい情報はマニュアルにありますのでご確認ください。https://phpunit.de/manual/6.5/ja/database.html#database.implementing-getdataset 作成したサンプルプロジェクト 今回は、dbunitの確認だけをしたいので、dietcakeのmessage-boardというサンプルプロジェクトを利用しました。今回作成したDBUnit用のサンプルプロジェクトは GitHub からダウンロードして確認できます。 git clone git@github.com:taisa831/phpunit-dbunit-sample.git cd phpunit-dbunit-sample composer install # mysqlサーバを立て`app/config/sql/board.sql`を実行する(SQLは下記に記載しています) # テスト実行 ./vendor/bin/phpunit PHPUnit 7.5.8 by Sebastian Bergmann and contributors. ….. 5 / 5 (100%) Time: 207 ms, Memory: 4.00 MB OK (5 tests, 14 assertions) アプリ用のDDLです。開発用DBとは違うのでboard_dbunitというテーブル名にしています。 — — — Create database — CREATE DATABASE IF NOT EXISTS board_dbunit; GRANT SELECT, INSERT, UPDATE, DELETE ON board.* TO board_root@localhost IDENTIFIED BY ‘board_root’; FLUSH PRIVILEGES; — — Create tables — USE board_dbunit; CREATE TABLE IF NOT EXISTS thread ( id INT UNSIGNED …

no image

2017年の抱負

2017年になって1Qが終わろうとしているけど、年末に考えた2017年の抱負を書こうと思う。 2017年の抱負 いろんなことはできないので3つ+サブ目標で考えた。 生産性ビックデータビジネス・インテリジェンスサブ目標 フロントエンド 英語 生産性 これまでも開発の生産性を意識した活動をしてきたが、全員の開発効率アップ、品質アップのような守備的な活動が多かった。けど今年はスクラム体制にして攻撃的な面も加えていきたいと思う。 去年までの振り返り 去年までは2人1組のような小さなチームで開発し、できたらリリースするというサイクルで開発していたが、以下の問題が細かく積み重なってきていた。(サービスの規模がそういった状況に陥る状況にまで成長したとも言える。) マネージャーの管理コストが高い要件定義して開発に仕事を振る側の負担が大きい開発者が指示待ちになる開発した機能が属人的になる開発メンバーが他のメンバーが何をしているか把握できない(チーム感がない)開発・営業・運用で足並みを揃えるのが難しい これらの問題を一気に解決する為に2017年からはスクラム体制で開発を進めることした。 スクラムのチーム構成 最初のスクラムチームの構成は以下の7人体制 プロダクトオーナースクラムマスター(自分)開発チーム デザイナー兼コーダー 中堅エンジニア 2~3年目のベトナムメンバー(2人) 新卒エンジニア スクラムを始めるあたり読んだ資料と書籍 Wikipedia まず最初に見たのがWikipedia。スクラム自体はある程度決まった型があるので、ここを見るだけでも大体の流れを確認することができた。また、スクラムガイドがリンクされているので合わせて読んだ(こちらも17ページ程)。 SCRUM BOOT CAMP THE BOOK 次に読んだのがこちらSCRUM BOOT CAMP THE BOOKこの本はスクラムについての概要はわかったけど実際どんな風に進めたらよいかが分からないという方におすすめ。実際の流れを漫画を交えて説明してるので読みやすいし一連のスクラムの流れがわかる。個人的にはスクラムガイドとこの本を読めばスクラムを開始できると思う。 スクラム実践入門 他の書籍も一応見ておこうと思って呼んだのがこちらスクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)この本ではいくつかの企業の事例が紹介されている。スクラムを始めるきっかけなどが書かれているので事例を見てみたいという方には良いと思う。 Joy,Inc. ジョイ・インク 役職も部署もない全員主役のマネジメント この本は直接スクラムには関係ないけど、おもしろい取り組みをしていて、開発の生産性をあげたいという意味で参考になっておもしろかった。スクラムを始めるにあたって読んでおいてよかったなという一冊。 ビックデータ 2つ目の目標はビックデータを本格的に扱うこと。数年前にバズワードになったけど、本格的にあたり前のように活用されるのがこれからだと思う。データがたまり、インフラが整いデータを安価で扱いやすい状況になってきている。ビックデータといっても様々な文脈があるが、個人的な活動の目標としては「GoogleBigQuery」、「AWS」を触りつつ手元にあるデータをいろんな形でこねくり回せる状態にする。というのを目安に進めていく。 ビジネス・インテリジェンス 3つ目もビックデータの文脈だが、データから有効な示唆出しをすることが一つのゴールになるのでそこを見失わないようにしたい。いろいろ触って「データサイエンティスト」の雰囲気がなんとなくつかめてきた。という状態にしたい。 サブ目標 いくつもやりたいことをこなすなんてことは自分にはできない。けどサブとしてでもやりたいと思ってるのが以下の2点。 フロントエンド jQuery脱却して一気にモダン化させたい(楽に開発をしたい) 英語 英語の勉強をするというよりは英語を使う環境に身をおける状態にする英語の技術系podcastを聞く 今年の抱負のまとめ 生産性を最大化しつつデータをこねくり回せるようにするできればフロントを最適化して英語も多少はコミュニケーションがとれるようにする

PHPライブラリをPackagistに登録する方法

PHPのライブラリをPackagistに登録する方法を書いておきます。PackagistはPHPのパッケージリポジトリで、登録しておくとcomposerを使ってプロジェクトへインストールすることができます。ここではとあるプロジェクトをPackagistに登録する前提の流れで進めていきます。 Packagistに登録するプロジェクトを作成する 新規でプロジェクトを作成しcomposer initを実行します。 mkdir amazon-photo-formatter cd amazon-photo-formatter composer init composer initを実行すると色々と聞かれるので順番に進めていきます。まずはパッケージ名が聞かれます。<vendor>にはGitHubのアカウント名を指定し、<name>にはライブラリ名を記載します。ここではtaisa831/amazon-photo-formatterと記載しました。 Package name (/) [taisa831/packagist]: Descriptionはライブラリについての説明文なので、Format amazon photo file name to amazon photo’s format.と書きました。その他についてもサジェストされている内容とするか必要な内容を決めて進めていきます。 Description []: Author [Masaki Sato , n to skip]: Minimum Stability []: Package Type (e.g. library, project, metapackage, composer-plugin) []: library License []: MIT 次にこのライブラリが依存しているものがあればこの時点で指定することができます(後から手動で記載することも可能)。ここではphpunitを利用するのでrequire-devでphpunitを指定しました。 Would you like to define your dependencies (require) interactively [yes]? no Would you like to define your dev dependencies (require-dev) interactively [yes]? Search for a package: phpunit Found 15 packages matching phpunit [0] phpunit/phpunit [1] phpunit/phpunit-mock-objects Abandoned. Use instead. [2] phpunit/php-token-stream [3] phpunit/php-timer [4] phpunit/php-text-template [5] phpunit/php-file-iterator [6] phpunit/php-code-coverage [7] …

Gitの参照 – HEADとheadsとtagsとremotes

Gitの参照についてまとめました。また別記事にてGitの内側について記載しています。 配管(Plumbing)と磁器(Porcelain)Git オブジェクト Gitの内側についておさらい 「git init」すると「.git」ディレクトリができるがその中についてがテーマ普段は使わない配管コマンドと呼ばれる下位レベルのコマンドがある4つのオブジェクトがある blobオブジェクト(ファイルに相当) treeオブジェクト(ディレクトリに相当) commitオブジェクト(commit情報を保持) tagオブジェクト(Tagを保持) Gitの参照って? ここで取り上げるGitの参照は「HEAD」ファイルと「.git/refs」配下のことを示します。「git init」した直後「HEAD」ファイルは「refs/heads/master」を参照し(初期化直後はなにも存在しない)、「.git/refs」配下には、headsとtagsディレクトリがあります。ブランチにcommitするとheads配下にブランチ名のファイルができ、HEADファイルはheads配下のブランチ名を参照します。 # masterにcommit後 # HEADファイル ref: refs/heads/master # refs配下の構造 └── refs ├── heads │   └── master └── tags Gitの参照の種類 Gitの参照の種類は次の通りです。 heads:作業中ブランチのcommitを参照tags:commitをわかりやすくする為の名前付け用remotes:リモートブランチのcommitを参照HEAD:作業中のブランチに対するシンボリック参照。HEADは基本的にheadsを参照しているので、他の参照と区別する為シンボリック参照と呼ばれます 動作確認の為の事前準備 次のような3つのcommitがあるリポジトリを用意しremoteへpushしておきます。 % git log –pretty=oneline master 1f36229bc26825222b191dcd63929392d9d8e2fd third commit 543ee947f5a865e1a998f793120667c3bf89fc80 second commit 23391397b4316d334e9293c4f7d1d601c1f24c4c first commit % git remote add origin git@github.com:taisa007/internal-git.git 次からはこのリポジトリを利用します。クローンする場合はこちらを利用してください。 構成 構成は次の通りです。「.git/refs」ディレクトリ配下にそれぞれheads, remotes, tagsというディレクトリが作られています。 % tree .git └── refs ├── heads │   └── master ├── remotes │   └── origin │   └── master └── tags Gitの参照の解説 「refs」配下にあるファイルはそれぞれ最後のcommitをファイルに記録しています。例えば現在masterは「third commit」にいますが「git log –pretty=oneline master」とすると次のようなcommit履歴が確認できます。 % git log –pretty=oneline master 1f36229bc26825222b191dcd63929392d9d8e2fd third commit 543ee947f5a865e1a998f793120667c3bf89fc80 second commit 23391397b4316d334e9293c4f7d1d601c1f24c4c first commit …