ﾅﾂへの扉
PHPで気軽にテーブルスキーマをマイグレーションするツール - Qiita
マイグレーション？ マイグレーションは一般的には 移行する という意味になります。 WEB開発界隈では一般的にマイグレーションツールというと、 テーブルスキーマの更新などをソースコードレベルで管理運用できるようにするツールのことを指すことが多いです。 Ruby on Railsで開発を行った事がある人などは馴染みが深いかもしれません。 PHPでは？ 大丈夫です、PHPにもちゃんとあります。 symfonyが利用するコンテナ doctrin にはmigration機能が用意されています。 cakePHPだってbundleとしてmigrationツールは用意されています。 今流行りの高速フレームワークphalconにもdevtoolsという開発ツールの中に用意されています。 それぞれ使い方などは異なりますが、ソースコードレベルでテーブルスキーマを管理することが可能です。 そんな有名なPHPフレ
PHPカンファレンス2017 講演資料まとめ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 4年連続4回目のPHPカンファレンスに参加したのでまとめます！ 足りない情報とかあるので必要なら追記していただけると助かります PHPカンファレンス2017 phpcon2017 twitter #phpcon2017 日時：2017年10月8日(日) 10:00〜17:00 場所：大田区産業プラザ PiO タイムスケジュール：https://joind.in/event/japan-php-conference-2017/schedule/grid 講演 session01: PHPの今とこれから2017 スピーカー：廣川 類(日本P
APCキャッシュを安全に扱うSafeApcを作った - nazolabo
https://github.com/nazo/safeapc なにこれ？ APC(APCu)のユーザーキャッシュ（アプリから指定するキャッシュ。ソースコードのキャッシュではない）を「そこそこ安全に」扱うための簡単なラッパーです。 どう使うの？ packagistに登録してあるので普通にcomposerから入れてください。 基本的には普通にapc_fetchとかするのがSafeApc::get等に変わっただけです。 あと、リクエストの最初に、以下を入れる必要があります。 // キャッシュで使用するリクエスト開始時間を指定 SafeApc::setCacheStartTime($_SERVER['REQUEST_TIME']); // キャッシュのバージョン番号を指定（この例では外部ファイルから） SafeApc::setCacheVersionKey(file_get_contents('
APC (Alternative PHP Cache) をモニタリングする - kakakakakku blog
2016年にもなって APC (Alternative PHP Cache) の話かよ！って感じもするけど，最近 APC の調査していて，個人的に学びが多かったので，主に apc.php に関してまとめておこうと思う． 前提 APC (Alternative PHP Cache) PHP の実行コード（実行時に生成する中間コード）をキャッシュする機構 PHP: APC - Manual OPcache PHP 5.5 から APC より高性能な OPcache がビルトインとなった よって APC を使うバージョンは PHP 5.3 / 5.4 などに限られる（完全にレガシー技術に） PHP: OPcache - Manual apc.php を設定する APC をインストールすると apc.php という名前のモニタリングツールが同梱されている．環境によって異なるとは思うけど /usr/
【PHP】 APCu apc.shm_sizeを超えるとどうなるか - 旅するえんじにあ - Engineers to Travel -
さてAPCuを使うようになり、まず気になるところがキャッシュと云えど限界はある。 そう、apc.shm_sizeだ。 毎回悩ましいのが、どれくらいの容量を設定していればいいのか。 実際にはttlに設定されている(実際にはプログラム上で明示的に指定するのだけど)時間でクリアされるため そこまで大きなメモリを確保する必要はない、けれども、一体どれくらいを設定したらいいのか。 更に言うと、設定したメモリを超えてしまった時、どういったことが起きるのか。 今回のAPCuはCSVデータを保存しておく（消えても問題ないようなデータ）ことが利用目的です。 どれくらい確保するかについては実際保存するだろうCSVデータなりを運用することを想定として多めに作成し、実際にAPCuに保存した上で容量を確認すれば問題ないかと思っています。 もちろんバッファも考えて多めに確保はします。 問題はその想定を超えて、オーバフ
第66回PHP勉強会でPHP-FPMの話をしました - hnwの日記
3月27日に開催された第66回PHP勉強会でLT発表してきました。以下が発表資料です。 発表内容は、 PHP-FPMとuWSGI+PHP pluginを試してみた話と、PHP-FPMの面白機能紹介といった内容です。 個人的にPHP-FPMの記事は絶賛記事が多すぎて気持ち悪いと感じていたので、そこまで絶賛するほどかなあ？という主張をしてみました。 というのも、よくApache+mod_phpという1サーバ構成とnginx+PHP-FPMという2サーバ構成を比較していたりするんですが、静的コンテンツと動的コンテンツが入り乱れる状況なら後者の方が有利なのは当然で、公平に比較するならApacheの前段にnginxを入れるべきだと思います。 もちろん、ノウハウゼロの状態からならnginx+PHP-FPMの方が最適な設定に早くたどり着けそうですし、今後ますます期待できるソリューションだと思うので、普通
シンボリックリンクを用いたアトミックデプロイと opcache と realpath cache - ngyukiの日記
これまで PHP のアプリケーションのデプロイは rsync でどべーとコードを撒いていました。が、それだと新旧のコードが混在するし Capistrano とかはデフォでシンボリックリンク切り替えでアトミックなデプロイになっているし、周回遅れな感じもしますが今後は似たような方法でデプロイしたいと思います。 releases/ ディレクトリの中にリリースタグでディレクトリを掘ってコードを配置して current を最新のリリースのディレクトリへのシンボリックリンクにします。そして Apache や Nginx でドキュメントルートを current の中の公開用のディレクトリに設定します（/path/to/app/current/public とか）。 /path/to/app/ releases/ 20161213/ 20161224/ 20170101/ current -> relea
php-timecopをPECLに登録しました - hnwの日記
かれこれ5年ほどメンテしている拙作のPHP拡張「php-timecop」ですが、このたびPECLに登録しました（PECL :: Package :: timecop）。 PECLというのはPHP本体に含まれないPHP拡張を提供する公式のリポジトリです。PECLのアカウントは承認制になっており、誰でも登録できるわけではありません。イタズラやお試しでの登録は減るでしょうが、代わりに登録への精神的ハードルが上がってしまうような仕組みだと言えるでしょう。実際、PECLに登録されているパッケージ総数は365個（2017/7/8時点）と多くはありません。また、日本人と思われるPECLアカウントは筆者以外では5人でした。 本稿では、PHP拡張をPECLに登録するまでのプロセスや、実際に登録してみてわかったことなどを紹介します。 PECLに登録するメリット さて、そのPECLですが、PEAR*1の衰退とと
PHP、CakePHPバージョンアップの決断 | ランサーズ（Lancers）エンジニアブログ
インフラエンジニアの金澤です。 この度、ランサーズ稼働環境（PHP + CakePHP）のバージョンアップを決断しました。 まずは私から、その経緯と計画についてお話いたします。 バージョンアップ決断の理由 ランサーズは、2008年にサービスを開始しました。 現在、PHP 5.3.29 + CakePHP 1.3.6 で稼働しており、長らくバージョンアップせずに開発を続けてきましたが、今回、PHP 7 + CakePHP 3までバージョンアップすることを決断しました。 その理由は、主に以下になります。 旧バージョンのサポート終了 PHP 5.3もCakePHP 1.3も、サポートが終了しています。 今後、特にセキュリティに関わるバグが報告された場合、今のバージョンを続ける限り、自分たちで対応する必要があります。 （実際、独自に手を入れている箇所がいくつか存在します） ライブラリバージョンアッ
グーペのPHPバージョンを5.2から7.1にアップグレードしました - Pepabo Tech Portal
こんにちは、グーペグループエンジニア @hypermkt と技術部インフラグループ・シニアエンジニア @hfm です。半年に及ぶグーペのPHPアップグレード作業が2017年5月中旬に全て完了し、PHPバージョンは5.2から7.1になりました。今回の記事ではアップグレードの過程と効果について、ご紹介させていただきます。 はじめに 8年目のホームページ作成サービス「グーペ」 なぜ8年目のタイミングでアップグレードをしたのか アップグレード基本方針 PHP5.2との後方互換性を維持する deprecatedの対応は優先度低め 事前準備 新旧両バージョンで継続的テスト より広範囲をカバーできるE2Eテストを重視 リアルタイムエラー検知 下位互換性のない変更点の修正 php7ccによる互換性の自動検知 MySQL関数の削除 preg_replaceへの置き換え PHP7.1用php.iniの作成 リ
PHPの現場
49. 2025 年のカンファレンス（tomzoh / cakephper） @tomzoh さん、 @cakephper さんと PHPerKaigi2025、PHPカンファレンス福岡2025、キャンピングカーなどについて話しました。 2年半ぶりの収録 2021年との違い PHPerKaigi2025 運営の裏側 php-fpm セッション コードバトル PHPカンファレンス福岡2025 Ask the Speaker 登壇サポート キャンピングカー 配信日：2025-04-06 収録時間：1:27:52 48. キャリアと開発の力点の変遷（hidenorigoto） @hidenorigoto さんと、キャリアと開発の力点の変遷、システム開発と人などについて話しました。 後藤さんのキャリア プレイヤ、プレイングマネージャ期 エンジニアリングマネージャ期 CxO 期 設計への道 設計を学
PHP: 付録 - Manual
Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Enumerations Errors Exceptions Fibers Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Predefined Attributes Context options and parameters Su
PSR-2 コーディングガイド（日本語）｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
このガイドはPSR-1に準拠し、標準的なコーディング規約のためのスタイルガイドです。 このガイドの目的は、複数メンバーがコードを読む際の認識のずれを抑えることです。 これはPHPコードをどのような書式にするかについて、ルールや期待値を共有することで実現します。 スタイルルールは、様々なプロジェクトの共通内容から生み出されています。 様々な作者が複数プロジェクトを横断して協力しあうことで、全てのプロジェクトで有用なガイドライン策定の助けとなります。 従って、このガイド本来の利点は、ルール自体にはなくルールを共有することにあります。 文書内記載されている "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 及び "OPTIONAL" は、RFC 21
includeって書きたくない僕たちのためのオートローディングとComposer - Qiita
こんにちはこんにちは、PHP書いてますか？ include_once してますか？ それともキミは require_once 派？ ところで、現代的なPHPではクラスファイル(ここではclass, trait, interfaceを含む定義ファイル)では、わざわざファイルをinclude/requireしなくても自動的に読み込む機能をカンタンに構築できる環境があるので、紹介いたします。 この記事は手を動かして動作確認しながら読めるように構成してありますので、斜め読みするだけではもったいないですよ ヾ(〃＞＜)ﾉﾞ はじめに 今回の記事ではクラスの自動ロード(オートローディング)の概要に絞って解説しますが、名前空間の文法や細かい説明を含めて包括的に解説した記事は、既にWEB+DB PRESS Vol.91｜技術評論社にて「PHP大規模開発入門 第12回 名前空間とオートローディング」として発
PHP BLT #4 に参加してきました - OTOBANK Engineering Blog
@riafです！ 先週の木曜日ですが、株式会社メルカリで開催されたPHP BLT #4にまとめブログ枠で参加してきました。 何かネタを作って LT 申し込もうとしてたんですが、ちょうど枠が埋まっていたの(と、エンジニアブログのネタを探していたの)で、初めてのまとめ枠でした。 ブログを書くより、5分のネタ作る方が簡単だなって..思います...。 さあ、気を取り直して早速まとめていきますよ！ 会場はメルカリ メルカリは六本木ヒルズにあります。広くて素敵なオフィスです。余ってる場所ほしい。 会場後ろ側のワゴンでビールと軽食が提供されています おしゃれ。 開始時刻に！ と思ったらトップバッターの人が不在 (遅刻)。 というより、開始時刻になっても集まっているのは 20 人程度で、ゆるーくスタート。 suzukiさん トップバッター不在のため、2番手の suzuki さんからスタートです。 PHP
アプリケーションから例外を投げる派、投げない派 - Shin x Blog
例外をどのような状況に投げるかもしくは投げないか、というのはわりと意見が分かれるところです。もちろん、プログラミング言語によっても異なりますが、同じプログラミング言語ユーザ同士でも様々です。 基本の考え方 ベースとしては、Effective Java の項目 39 にある下記の方針が参考になります。 例外的な状況の時にのみ例外を使う。 Effective Java 禅問答のような定義ですが、これには異論は無いでしょう。例外を正常フローで利用したり、制御構造に用いるべきではありません。 人によって異なるのは「例外的な状況」の解釈です。 例外的な状況 この「例外的な状況」の解釈は人によって異なるようで、これまでも議論になっていました。これまで聞いた解釈を乱暴に分けると以下の 2 パターンに分かれます。 1. アプリケーションから独自の例外を投げる派 ランタイムやミドルウェア連携などプラットフォ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://pecl.opendogs.org/
PHP開発者のためのHeroku入門 | Salesforce Developers
GitHub - composer/installers: A Multi-Framework Composer Library Installer
