PHPカンファレンス関西2016で基調講演してきました | メルカリエンジニアリング
サーバーサイドエンジニアの@Hirakuです。 2016年7月16日(土)、 PHPカンファレンス関西2016 にて基調講演をしてきましたので、その報告と補足をします。 トーク動画は後日公開されると聞いていますので、口頭で補足した内容などはそちらをご期待ください。 内容について 講演内容は今年2月に公開した記事 光遅い問題を克服してcomposerを10倍速くした話 – Mercari Engineering Blog をもう少し詳しく解説したものです。 基調講演ということだったので、Composer自体の細かい話をするよりも、なぜこんなことに時間を費やしてきたのか、自分より若いエンジニアに何か伝えるものがないか、というようなことを考えて、エモ全開の内容になりました。 改善活動だけを話すとComposerを貶す内容になってしまいます。詳しい事情も知らない人にDISの口実を与えるのも嫌だった
Composerを速くするために必要だったもの // Speaker Deck
PHPカンファレンス関西2016の基調講演です。
[php]本当は怖いcomposer (require-devの落とし穴について) · DQNEO日記
composer.jsonの"require-dev"という仕組みには落とし穴があります。 使うときは十分気をつけましょう。 そもそも"require-dev"とは何か？ 本番環境で必要のない開発環境用のパッケージを記述する場合に使います。 { "require": { "symfony/http-foundation": "2.4.*", }, "require-dev": { "phpunit/phpunit": "3.7.*" } } 例えばこのように記述すると、本番では"http-foundation"のみを使い、開発環境ではそれに加えて"phpunit"も使う、というようなことが可能になります。 うっかり"require-dev"パッケージを呼び出すコードを書いてしまうと事故になる。 例えばプロジェクトでYAMLファイルを扱いたいと思って"symfony/yaml"を呼び出すコー
![[php]本当は怖いcomposer (require-devの落とし穴について) · DQNEO日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/8f7de7c0278993661a11fbc3637f96292ba773aa/height=288;version=1;width=512/http%3A%2F%2Fdqn.sakusakutto.jp%2Fimages%2Fkali.jpg)
「そんなself-updateで大丈夫か？」 Composer編 - CARTA TECH BLOG
こんにちはこんにちは、 VOYAGE GROUPでBuild prayer*1として活動している@_nishigoriです。 pip, bundler, rebar 等 各プログラミング言語のビルドツールないしパッケージマネージャ等と呼ばれているツールを弊社でも利用していますが、 PHPでは依存管理ツールとしてComposerを利用しているプロジェクトがあります。 今回はComposer本体のバージョニングについて紹介し、 利用する上での良い側面と悪い（と思われる）側面を紹介します。 はじめに Composerの入手 最新版 *2 Installer self-update リリースサイクル 効能 デメリット self-updateする日時によってrevisionが異なる（場合がある） ある日のself-updateで突然死 Tagging Versions Installer self-
光遅い問題を克服してcomposerを10倍速くした話 | メルカリエンジニアリング
はじめまして。サーバーサイドエンジニアの中野(@Hiraku)です。2015年12月からメルカリで働いています。 2016年1月27日(水)の第98回PHP勉強会@東京にて、composerを速くする取り組みについて発表をしてきました。 composerはPHPにおける実質スタンダードなパッケージマネージャです。 このcomposer、日本で実行すると非常に遅く感じます。この原因は普通ならこう表現すると思います。 githubやpackagistが日本から遠いから composerの実装がよくないから しかし発表ではあえて「光が遅いから」という主張をしました。 一般常識として、光の速さ(真空中で秒速約30万km)はとてつもなく速いものという認識だと思います。しかし一方で、地球や宇宙の規模など極限的な状況に携わる仕事をしている人であれば「全然速くない、むしろ遅い」というのが普通の感覚です。
PHPアプリケーションをRspecでテストする - fortkle blog
この投稿はPHP Advent Calendar 2014の4日目の記事です。 Webブラウザを操作して実施するテスト（以降ブラウザテストと表記）をPHPアプリケーションで実施したい思ってPHP製のテストフレームワークを探していたのですが、あまりよいものが見つからず日本語の情報も少なかったので、いっそのことRspec+Capybaraでやってしまえ！ということでやってみました。 目次 概要 用語の説明 PHPアプリケーションをRspec+Capybaraでテストする テストをTravisCIで実行する 1. 概要 簡単いうと、PHPアプリケーションをビルドインサーバーで動かし、その環境に対してRspecとCapybaraで書かれたテストケースを実行することでブラウザテストを行います。 環境はCentOS release 6.6 (Final)、PHP 5.5.19で実行しています。PHPの
composer 導入をまじめに考える - Qiita
これは結構大きいPHPのプロジェクトに composer を導入する機会があったので、そのときに考えてたことや行ったこと、使い方などをメモするために書いた。 モチベーション 私達は PHP のパッケージの管理を管理する際は pear と git submodule を利用していた。これらのやり方は意外と長続きした。これらにはついて様々な問題を抱えており、ついに限界がきてしまった。 pear pear でパッケージを導入するには root 権限が必要なので、毎回インフラチームに導入を依頼するのが必要があった。 pear で導入されたパッケージについてバージョンを上げようとすると、全APサーバーで更新をかける必要があった。 これらの点から面倒だったのと、気軽に変更できないので、不要になったものも削除されることなく、放置されるのが問題だった git submodule こちらは pear とは異
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
