GitHub Actions のコスト戦略 - GeekFactory
TLDR 開発体験が良くなると CI のコストも減る 不必要なジョブ実行を減らし、割れ窓を直すことから始めると良い Self-hosted runners ではクラウドコスト最適化の一般的なプラクティスも併用する GitHub Actions のコスト構造 GitHub-hosted runners GitHub が提供するインフラを利用する。一般的なクラウドより高めの料金設定になっている 1分単位で課金される。ジョブの実行時間が数秒間でも1分間で課金されるので注意 Public repository は無料、Private repository は従量課金になっている Organization 内で利用料金が合算されて翌月請求される。Organization Owner なら請求レポート (CSV) をダウンロードできる Self-hosted runners GitHub では課金され
google-api-java-clientの文字化けと対処法 - GeekFactory
Google Tasks APIにアクセスするコードを書いているのですが、App EngineのProduction環境で文字化けするパターンがあったのでまとめておきます。ちょっと変わった使い方をしていたので見つけました。 Tasks APIへのアクセスには google-api-java-client というライブラリを利用しています。このライブラリはTasks APIとJSONをやり取りし、内容をモデルクラスに変換してくれる優れ物です。OAuth 2.0のコード以外はモデルの操作で完結してしまいます。 今回はJavaScript（ブラウザ）とTasks APIの間にサーバサイド層を挟み、JavaScriptで使いやすいようにJSONを料理する仕組みを考えました。つまり、Tasks APIから受け取ったJSONをモデル化し、またJSON化してブラウザに送り出すことになります。 Acces
App Engineで動く並列処理フレームワーク ElShard - GeekFactory
App Engineで大量のデータを並列処理するフレームワーク ElShard を作っています。batch addとdeleteのサンプルができたので、とりあえずまとめてみます。 ElShardは、入力リストを分割して処理して集約する考え方に基づいています。並列処理はApp EngineのTaskQueueで実現しています。タスク間では10kBのペイロードしかやり取りできないため、データをやり取りする用途には適していません。そのため、実際のデータはDatastoreに格納しておき、キーをタスク間でやり取りすることになります。 現段階では集約をどうやって実現するか未定ですが、キーでソートされるというDatastoreの性質をうまく利用できる気がします。Matcher APIが使えるといいなぁ。 リストを処理する ElShardでは、InputとTaskの2種類のタスクを組み合わせてジョブネッ
プロパティの一部をkindに含める設計について - GeekFactory
データストアで時系列データをカレンダー表示したい場合、どのような設計が最適でしょうか。下記のモデル（Event）を考えます。 プロパティ 型 説明 key com.google.appengine.api.datastore.Key キー（userId/time） userId java.lang.String ユーザID time java.util.Date 日時 value int 数値 下記のアクセスパターンを考えます。 カレンダーに1ヶ月間のデータ（日毎の平均値など）を表示する。 カレンダーの日付をクリックすると、1日のデータを表示する。 最新10件のデータを表示する。 ログインユーザのデータを対象とする。 私の考える設計 まず、下記のモデル（EventCalendar）を作成します。 プロパティ 型 説明 key com.google.appengine.api.datasto
受託開発が抱える本質的な非効率性に関する考察 - GeekFactory
受託開発が抱える本質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。 外注のオーバーヘッド 契約に係るコスト。 限られた場所や時間で質疑応答を行うことによる損失 情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。 打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。 発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。 決定に要する時間が長くなる。 開発者が業務プロセスを学習するコスト 前提として、どんな要件でも学習コストは必ず発生する。 過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。 発注側から業務に関する説明を受ける機会（＝教育）が十分にないため、極めて非効率な学習にならざるを得ない。
AjaxによるFederated Loginの待ち時間の短縮 - GeekFactory
App Engine上のアプリでは利用者の体感待ち時間を短くするため、JSPを使わずにAjaxで実装することがあります。この方法はOpenID認証（Federated Login）でも有効です。 web.xmlのsecurity-constraintで認証をチェックする方法を以前紹介しましたが、この方法ではサーブレットを経由してログイン画面に遷移するまでに待ち時間が発生してしまいます。 代わりにクライアント側で認証をチェックすることで、ログイン画面に遷移するまでの待ち時間を省けます。クライアント側で認証をチェックするには、JavaScriptで ACSID というクッキー*1の有無を確認します。 （図の1） JavaScriptは認証Cookieの有無を確認します。初期状態では認証Cookieを持っていないので、ログインフォームを表示します。 $.extend({ /** * ログイン済み
流れるようなインタフェースでJSONを返す - GeekFactory
いわゆる流れるインタフェースでJSONレスポンスを返す仕組みを実装してみました。Slim3じゃなくても使えそうです。 public class EventlogController extends Controller { private final EventService eventService = new EventService(); @Override public Navigation run() throws Exception { List<Event> result = eventService.getEvents(asKey("k")); return Jsonize.list(result) .property("url", new PropertyAccessor<Event, String>() { public String get(Event model)
OpenID認証によるシングルサインオン - GeekFactory
App Engine 1.3.4でOpenID認証に対応しました。調べてみると意外と普通にシングルサインオンできたので、使い方と仕組みを説明します。 まず、OpenID認証を要求するURLパターンをweb.xmlに書きます。 <security-constraint> <web-resource-collection> <web-resource-name>Authentication required url</web-resource-name> <url-pattern>/user/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> 例えば http://xxx.appspot.co
OpenID認証によるアクセス制御フィルタ - GeekFactory
2010-06-05 お詫び：ソースコードに間違いがありましたので修正しました。OpenIDのIdentifierを取得するには getUserId() ではなく getFederatedIdentity() を使用してください。 データ変換タスクをTaskQueueに投入するページなど、開発者のみアクセスを許可したいURLにOpenID認証をかける方法を紹介します。 まず OpenID認証によるシングルサインオン - GeekFactory の通りにOpenID認証を有効にしておきます。この時点で認証は有効になっています。これから認可を設定しましょう。 例えば http://xxx.appspot.com/util/* は開発者のみアクセスを許可したい場合、web.xmlに以下を記述します。 <security-constraint> <web-resource-collection>
OpenID SSOの認証シーケンス - GeekFactory
App EngineでOpenIDシングルサインオンを利用した場合のシーケンス図を書いてみました。OpenID Providerが「はてな」の例です。 開発者が用意するページは黄色の部分に示したログインページだけです。設定内容は OpenID認証によるシングルサインオン - GeekFactory で説明しています。 シーケンスを説明します。 リクエストパスがsecurity-constraintにより保護されている場合、App Engineは認証状態をチェックする。 認証済みの場合は、本来のリクエスト処理を実行する。 未認証の場合は、ログインページ（/_ah/login_required）にリダイレクトする。 ユーザはログインページでIdentifierを入力し、ログインサーブレット（/login）にPOSTする。 ログインページは開発者が用意する。 フォームの隠し属性にcontinue
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
