FuelPHPでfacebookログインを実装したときのまとめ - Qiita
FuelPHPでfacebookログインを実装したい 調査結果 Opauthを利用するのが良さそう ここ( https://github.com/andreoav/fuel-opauth )からFuelPHP用のパッケージを利用できそう Opauthは， PHPでOauthログインをするためのフレームワークです(ざっくり) 使ってみた とても丁寧にREADMEが書かれており， 簡単に実装できた(見習いたい) しかし , メールアドレスが取得できない．．． メールアドレス取得できない原因 随分更新されていないようで， 最近の(?)facebook SDK のアップデートによってデフォルトでは取得できなくなっているらしい その他の項目もパーミッションが必要になっているものがたくさんありました 参考( https://developers.facebook.com/docs/facebook-l
PHPでPDFファイルからOCR処理をしてみる - Qiita
雛形に沿ったPDFファイルを読み込んで、特定の場所の文字列を文字認識で取得する。 というアプリケーションを作りたかったので、忘備録代わりに。 普通にググるとImageMagick+GhostScriptが大多数でした。 一度試してみましたが、OCR処理を通すために必要な解像度まで上げるとCPUが悲鳴を上げます。 今回はWebサービスへの組み込みも考えているので、もっと軽量にしたい・・・ なので、LinuxコンソールアプリのpdfimagesとGoogleオープンソースOCRエンジンのTesseract-OCRを組み合わせてみました。 環境 centos6 php composer imagemagick pdfimages Tesseract-OCR 準備 yum install imagemagick-devel poppler-utils tesseract-devel //要epel
mbstring正規表現デフォルト文字エンコーディングは”EUC-JP”だった
(Last Updated On: 2018年8月13日)デフォルト文字エンコーディング設定の仕様変更はPHP 5.6リリースの際に私が行った変更ですが、ブログで紹介していなかったような気がするので紹介します。PHP 5.5以下のmbstring正規表現デフォルト文字エンコーディングは”EUC-JP”でした。 一応、RFCには all functions that take encoding option use php.internal_encoding as default (e.g. htmlentities/mb_strlen/mb_regex/etc) と書いているのですが、これだけではmb_eregなどのデフォルト文字エンコーディングが変わっている事に気が付かない方も多い（気が付かない方が多い？）と思います。 PHP 5.6のデフォルト文字エンコーディング設定 PHP 5.5以
PHPの制限一覧
(Last Updated On: 2018年9月21日)PHPには他の言語と同様に様々な制限があります。まとまった資料が見つからなかったのでまとめておきます。PHPの制限と言っても実行時間の制限のようにマニュアルに記載されているINI設定などは記載していません。 PHPのデータ型制限 整数型 PHPの整数型のレンジはOSにより異なります。 32ビットOS – 符号付き32ビット整数。最大2^31-1、最小-2^31 64ビットOS – 符号付き64ビット整数。最大2^63-1、最小-2^63。ただし、PHP 7.0未満のWindows OSでは64ビットOSでも最大2^31-1、最小-2^31。 ネイティブの整数型を超える範囲の整数には任意精度整数（実質無制限）をサポートするGMPまたはBCmathが利用可能です。モジュールはデフォルトで組み込まれないですがGMPの利用を推奨。PHP 5
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
「論理削除」ではなく「無効化」を - 設計者の発言
以前の記事で、テーブルに「スタンプ属性」をいちいち載せるのは惰性的習慣ではないかと書いたが、似たものに「論理削除フラグ」がある。各テーブルにいちいちこれが置かれているDBを見ることがあるが、それもまた惰性の結末ではないか。スタンプ属性だろうが論理削除フラグだろうが、必要ならば置くべきだし、必要でないなら置くべきではない。ただし、多くのケースで必要なのは「論理削除」ではなく「無効化」であることは知っておいたほうがいい。 削除のややこしさは、他テーブルとの関係にある。まず、通常の削除（物理削除）について見よう。テーブルAと参照関係にあるテーブルBがあるとする（図１）。ここで、テーブルA上のレコード①が、テーブルB上のレコード③と④によって結合（参照）されているとすれば、①を削除することは許されない。もし削除してしまえば、存在しないAレコードを結合するBレコードの存在を許してしまう。典型的な更新
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
