タグ

2016年7月16日のブックマーク (14件)

  • Gitで美しいコミットの歴史を作る - Qiita

    ランチ Git flowなので以下のブランチが存在するが、今回登場するのはdevelopとfeatureである。 master: 唯一無二で即番リリースできる資産。 develop: 次期リリース候補の資産。開発中はdevelopを更新していく。 feature: 実際の開発はfeatureブランチで行う。開発が終わったらdevelopにマージされる。 release: リリース準備をするためのブランチ。バージョンとか上げる。 hotfix: 緊急対応するためにmasterを親として作成されるブランチ。対応後はmasterとdevelopにマージされる。 美しい歴史を作ってみよう featureの歴史を美しくする まずはfeatureの歴史を美しくしてみよう。 B機能とC機能の修正をfeature/modify_B_Cというfeatureブランチで開発を行い、 次のような歴史ができたと

    Gitで美しいコミットの歴史を作る - Qiita
    etakaha
    etakaha 2016/07/16
  • Domaの開発で大切にしている10のこと - Qiita

    自己紹介 中村 Domaの開発者 開発歴 7年と2か月 twitter: nakamura_to github: nakamura-to Domaとは? JavaDBアクセスフレームワーク 注釈処理(JSR 269)でコード生成 & コンパイル時検証 実行可能なSQLテンプレート Doma歴史 2009/05: 開発開始 2009/02: v1.0.0リリース 2014/07: v2.0.0リリース (Java 8対応) 2016/06: v2.11.0リリース(最新版) 1. 動かさないとわからないを減らす コンパイル時にできるだけチェック Javaコードに対して 例:アノテーションの存在チェック SQLファイルに対して 例:パラメータの存在チェック

    Domaの開発で大切にしている10のこと - Qiita
  • 今更聞けないOAuth2.0

    OAuth2.0まとめ speakerdeck はこちら↓ https://speakerdeck.com/satot/jin-geng-wen-kenaioauth2-dot-0#Read less

    今更聞けないOAuth2.0
  • とあるDoma2の使い方

    class: center, middle # とあるDoma2の使い方 Doma勉強会 in 東京 2016/07/09 --- class: left, middle ## 自己紹介 * 中村 学(Nakamura Manabu) * [@gakuzzzz](https://twitter.com/gakuzzzz) * 株式会社 Tech to Value * Japan Scala Association --- class: left, middle ## 今日の内容 うらがみさんの[Doma実践](http://backpaper0.github.io/ghosts/doma-practice.html#1)が面白かったので、<br/> 僕も普段こんな感じでDomaを使ってるよ、<br/>というのを紹介しようと思います。 --- class: center, middle #

  • KPI に寄与できない開発課題を、組織全体で取り組むということ - クラウドワークス エンジニアブログ

    はじめに クラウドワークスエンジニアの八木です。 先般の記事でも触れられていた通り、クラウドワークスではシステムのフレームワークとして採用している Ruby on Rails を 3 系から 4 系に移行しました。 残念ながら、「こことそことあそこを直して、さあリリース!!!」とはいかず、それなりの時間を投入して行いました。 今回は、Rails のバージョンアップをスムーズに行えないという技術的課題は一旦脇に置いておいて、フレームワークのバージョンアップという「事業の KPI に直接寄与できない開発課題」に対して、クラウドワークスの開発チームがどのように取り組んだか、組織体制の話を書いてみたいと思います。 チーム体制の変遷 まず、クラウドワークスで Rails4 対応するために組んだ組織構成について、時系列に沿って簡単にご紹介します。簡単にご紹介と言いつつ先に要約すると、最初は Rails

    KPI に寄与できない開発課題を、組織全体で取り組むということ - クラウドワークス エンジニアブログ
  • OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜

    [参考情報] 【永久保存版】OAuth 2.0 / OpenID Connect シーケンスまとめ URL:https://qiita.com/kura_lab/items/812a62b5aa3427bdb49d タイトル: 『OpenID Connect 入門 〜コンシューマー領域におけるID連携のトレンド〜』 概要: コンシューマー領域におけるID連携のトレンドであるOpenID Connectの概要と仕様のポイントについてご紹介します。 OpenID TechNight Vol.13 - ID連携入門 Aug. 26, 2015 URL:https://openid.doorkeeper.jp/events/29487Read less

    OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜
  • マイクロサービスで必要になるかなぁって思って僕がOAuth2とOpenID Connectをなんとなく分かるようになるまでの物語 - Mitsuyuki.Shiiba

    プライベートの勉強は気が向くままにふらふらと。梅田の地下街を歩いてる感じで!(←つまり迷ってる) 元々は、Pivotal Japanさんの、この「今日から君もヒーローだ!」的なタイトルに惹かれてJava(Spring Cloud)でマイクロサービス作るぞーって進めてみたのであった。が、早速その2の「認可サーバーを立ち上げよう!」で「あー、これ知らない。分かんない。もう寝たい。」となってしまったのだった。 そんな僕が「なんとなく分かった!」になるまでの物語。・・・になるはず(ここを書いてる今はまだ分かってない)。 たぶん1ヶ月したら何を読んだか忘れてると思うので記録しとくことにした。 github.com ゴール OAuth 2.0って聞いたことあるけど、よく知らない。この辺、マイクロサービスの認証・認可部分で必要そうだなーって思うので、OpenID 2.0とOpenID Connectも含

    マイクロサービスで必要になるかなぁって思って僕がOAuth2とOpenID Connectをなんとなく分かるようになるまでの物語 - Mitsuyuki.Shiiba
  • 普通の人でもわかる Paxos

    4. 登場人物 •  クライアント –  プロポーザに、書き込みをお願いする人 –  登場人物といっておきながら、話はプロポーザが値を 持ってから始めればいいので、以下登場しません。 •  プロポーザ –  アクセプタの過半数に同じ値を書き込むよう頑張る •  アクセプタ –  プロポーザから来た値をよきにはからう(後述) •  リスナ –  最後に、過半数のアクセプタから値をゲット。 6. 基的な動き(フェーズ2) •  フェーズ2a(プロポーザ側) –  過半数のアクセプタから約束が返ってこなかったら、 どこかで諦めて、メッセージIDを増やして最初からや りなおし。 –  過半数のアクセプタから約束が返ってきたら、メッ セージIDと値を添えてアクセプタにプロポーズを送る。 –  プロポーズを送る際に、もしも約束に(ID, 値)の組が ついて返ってきたら、自分の値を、返ってきた約束の

    普通の人でもわかる Paxos
  • ローンチから10年を経たSaaSシステム開発が抱える問題にどう取り組んだのか | TECHSCORE BLOG | TECHSCORE BLOG

    SaaS システムを開発しているみなさま、お元気でしょうか。松です。 当社プロダクトの Synergy! は 2005 年にローンチした、数千テナントを抱える SaaS 型 CRM システムです。 Synergy! のような SaaS システムはローンチしたらそれで完成ではなく、継続的に機能追加や機能改善を繰り返していくことがユーザーにとっての魅力のひとつです。Synergy! 開発ではこのサイクルスピードが年々落ちており、開発パフォーマンスの維持、向上が大きな課題になりつつありました。 また、ローンチから 10 年を経たプロダクトを、今の時代を反映したプロダクトとしてリニューアルしたいという強い要望も社内から出ていました。これまでも機能強化は続けてきましたが、抜的なユーザーエクスペリエンスの変革を実現するには、機能を新しくデザインし直さなければなりません。大規模な機能追加や機能改善が

  • わかりやすさの技術 - やしお

    社内向けの教育資料を、ど素人でもわかるようにと思いながら作っていて、じゃあ「わかりやすい」って何だろうって考えてた。今まで読んできたいろんなわかりやすかったとそうでないを思い浮かべながら、一般的にここを注意すればわかりやすさを確保できるだろうっていうポイントを一旦まとめておこうと思った。そうしてまとめてみると、に限らず人に何かを伝えること一般に適用される話だなと思った。 読む側の負担を減らす わからない=理解をはばむ障害物がある。この障害物を取り除く/回避する作業が「わかる」ために必要になる。その作業を、作者ではなく読者が負担するとき「わかりにくい」になる。 日社会だと情報の受け手の側がこの「わかる」ための作業を負うことでコミュニケーションを成立させる傾向にある。空気を読むというようなことだ。そのため発信者側が事前に手を尽くしてわかりやすく発信するというのが苦手で、相手が汲み取っ

    わかりやすさの技術 - やしお
  • マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ - Qiita

    マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。 マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。 「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか? Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。 いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。 マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編) ECサイトをマイクロサービスアーキテクチャで作ることを考えてみ

    マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ - Qiita
  • Cache-Control の Immutable 拡張によるリロード時のキャッシュ最適化 | blog.jxck.io

    Intro ブラウザはリロード時に、 max-age に満たないキャッシュを持っていても Conditional GET によってキャッシュの Validate (有効性の問い合わせ)を行う。 Cache-Control Extension として提案されている Immutable 拡張は、キャッシュが max-age 内であればリロード時もキャッシュヒットさせる拡張である。 このヘッダの効果と、サイトへの適用について記す。 Cache-Control Cache-Control に max-age を指定することで、ブラウザにリソースをキャッシュさせることができる。 このキャッシュは max-age の期間内は fresh とみなされ、 fresh であればサーバへの問い合わせなく再利用される。 サーバへの問い合わせ(RTT)が無いため、事実上最速のリソース取得となる。 Reload

    Cache-Control の Immutable 拡張によるリロード時のキャッシュ最適化 | blog.jxck.io
    etakaha
    etakaha 2016/07/16
  • ソフトウェア出荷判定セキュリティ基準チェックリスト発表 | SAJ 一般社団法人ソフトウェア協会

    ソフトウェア出荷判定セキュリティ基準チェックリストを公開 設計から運用まで開発現場で使えるセキュリティ要件を策定 2016年7月13日 一般社団法人コンピュータソフトウェア協会(略称「CSAJ」、東京都港区赤坂)は、パッケージソフトウェアやWebサービスセキュリティ品質を向上させるための「ソフトウェア出荷判定セキュリティ基準チェックリスト」を発表しました。 誰もが自由に使える開発プロセスに応じたセキュリティ要件48項目 チェックリストは、CSAJ会員企業でセキュリティや品質保証を担当する専門家が制作したもので、ソフトウェアの品質の一環としてセキュリティを捉え、開発現場での仕様策定や出荷テストの際の評価項目として幅広く利用できることを目的として構成されています。チェックリストは、CSAJの以下Webサイトからダウンロードでき、クリエイティブコモンズライセンスに基づき、CSAJ会員のみなら

  • CSSのブラウザサポート状況を自動でチェックできるdoiuseが便利 - $shibayu36->blog;

    最近書いているCSSがそもそも今サービスが推奨しているブラウザでサポートされているのかチェックするのだるいと思っていたら、doiuseという便利なツールを見つけた。 doiuseとは https://www.npmjs.com/package/doiuse CSSのブラウザサポートのチェックをしてくれるモジュール。caniuse のデータベースを利用して、ブラウザと自分が書いているCSSを指定して、サポートされていないCSSの書き方を見つけてくれる。 試す環境を用意する とりあえず試すための環境を用意する。適当なディレクトリを作って、必要なライブラリをインストールする。また、検証するためにbootstrapも入れておく。 $ mkdir try-doiuse $ cd try-doiuse $ npm install --save-dev doiuse $ npm install --sa

    CSSのブラウザサポート状況を自動でチェックできるdoiuseが便利 - $shibayu36->blog;
    etakaha
    etakaha 2016/07/16
    ブラウザサポートの静的解析