タグ

2016年12月2日のブックマーク (6件)

  • [Git] 2 つのリモートリポジトリの差分を確認する - Qiita

    他にスマートな方法がありそうな雰囲気をかもしだしていますが、とりあえず動作確認ができた方法が見つかりましたので投稿しておきます。 まず、片方のリモートリポジトリをクローンして、ローカルの master ブランチとします。 次に git remote add の -f オプションを使ってリモートブランチ tmp にもう片方のリモートリポジトリを fetch します。 master ブランチとリモートブランチ tmp とで diff を取ります。

    [Git] 2 つのリモートリポジトリの差分を確認する - Qiita
  • fuelphpで必ずやってる設定などまとめ - とりあえずphpとか

    完全に自分仕様になっているが毎回同じ設定を過去のプロジェクトのをみながら都度やっていて時間も無駄なのでまとめておく fulephpで準備されている機能の準備 日語を使う準備 fuel/app/config/config.phpを編集 //81行目くらい 'language' => 'ja', // Default language 'language_fallback' => 'en', // Fallback language when file isn't available for default language 'locale' => 'ja_JP.UTF-8', // PHP set_locale() setting, null to not set //88行目くらい 'encoding' => 'UTF-8', validation回りの準備 validationで使うメ

    fuelphpで必ずやってる設定などまとめ - とりあえずphpとか
    hirooka_digitalpl
    hirooka_digitalpl 2016/12/02
    “DBを使わない場合は不要ですが、使わない案件が今までないので必ずやってます 自分が勝手に毎回している設定 これ以降はさらに自分仕様のメモです アプリ内定義系ファイルの作成”
  • PHP で OAuth ログインを実装するなら「Opauth」が簡単で便利

    以前こんな記事を書いたことがあるんだけど PHPTwitter APIのOAuthを使う方法まとめ – 頭ん中 そのときから Twitter API の仕様も変わってて この記事をそのまんまなぞったらうまくいかない部分があると思います。 更新しないとなーと思いつつなかなか対応できてないんだけど、 Opauth を使えばここに書いた処理のほとんどを勝手にやってくれるから もうこれでいいんじゃないかという気がしてます。 Opauth – Multi-provider authentication framework for PHP Opauth とは サイトのタイトルにも書かれてるけど、 複数プロバイダに対応した PHP の認証フレームワークです。 Opauth のいいところ 対応ログインプロバイダが豊富 使ったことがあるサービスだけを挙げても すでにこのへんのログインに対応してる。 Bit

    PHP で OAuth ログインを実装するなら「Opauth」が簡単で便利
  • FuelPHPでopauthを使って色んなログインに対応してみた - スケルトン・エピ

    FuelPHPでopauthを使って色んなログインに対応してみました。 ログインのパターンは 1.通常のusernameとpasswordのログイン 2.Twitterのoauthログイン 3.Facebookのoauthログイン です。 TwitterとFacebookのログインについてはfuel-opauthを使っていますが、こちらの参考ブログ記事にも記載されている通りnamespaceの設定に不具合があるためgithubでforkしたものをsubmodule化しています。 家 https://github.com/andreoav/fuel-opauth家 修正版 https://github.com/letsspeak/fuel-opauth 今回作成したり変更したファイルは一通りgistにもアップロードしています。 不具合はいつも通り触りながら修正していこうかと思っていますが

    FuelPHPでopauthを使って色んなログインに対応してみた - スケルトン・エピ
  • 「手が動かせない人」への処方箋

    ところで私は、かつて「手を動かさない人」でした。 仕事にせよ、勉強にせよ、創作にせよ、音楽にせよ、どんなことでも「ごちゃごちゃ考えているより、まずやってみて場数をこなした方がスキルは育つ」というのは、大体の場合で当てはまる普遍的なセオリーであると思います。 ゲーム開発、アプリ開発なんかでも、実績を残している人はみんな「いいからまずやってみろ」って言いますよね。 手を動かすこと、超大事です。手を動かすことによって、課題が生まれ、自信が生まれ、ノウハウが蓄積されていく。頭で考えているだけでは何も始まりません。考えたものは、出力しなくてはいけません。 ところが、世の中には「手を動かさない人」がいます。取り敢えずやってみろ、というアドバイスを受けつつも、なかなか「取り敢えずやってみる」という実施タームに移れない、もしくは移らない人ですね。先日、Books&Appsさん内でもそれについての記事が掲載

    「手が動かせない人」への処方箋
  • テスト計画の立て方 - Qiita

    テスト計画をどう立てていくか、ふつうのシステムエンジニアにとって分かりやすく考えてみたいと思います。 テスト工程は、一番ざっくりした分類で単体テスト、結合テスト、システムテストに別れるのが一般的です。 この工程は、あくまでもV字モデルに対応したインプットがどの前工程で作られたものを検証するかの基準であって、実際にどういう観点をどういう手順でテストするか、はそれぞれのプロジェクトで計画します。それがテスト計画になっていきます。 しかし、ただの工程の話と、実際におこなうテストの内容の違いが分かっていないと、テスト計画何するものぞ状態になって、ろくなテストが実施されないことになりますし、そのようなプロジェクトも多く存在します。 テストの世界標準には、ISO/IEC/IEEE 29119があり、これを見るとテスト工程(Test Level/Phase)とテスト種別(Test Types)の組で、テ

    テスト計画の立て方 - Qiita