2018-10-02（火） Doorkeeperでは、PayPalとStripe経由でのクレジットカード払いという2通りのオンライン決済方法を提供してきました。しかし、残念ながら、PayPalではそのサービスの質に関わる問題を繰り返し経験し、また、今後それが改善されることが予想できる確たる証拠もありません。Doorkeeperを利用するイベント主催者や参加者にとって快適なサービスを今後PayPalが提供してくれることを確信できないことから、クレジットカード決済をStripeのみで対応すべくPayPalのサポートを終了することに決定しました。 私たちのデータによれば、PayPalではなくStripeを採用しているイベントにおける決済完了率が最も高いことから、この変更はDoorkeeperに関わるすべての人にとって有益であると考えています。また、先日発表した毎回クレジットカード情報を入力しなく
Elasticsearch クエリーのデフォルトのオペレーターは OR です。これ自体は問題ないのですが、このORが適用されるタイミングがとても違和感 … 。 どうやら、リクエストする単語が１単語でもアナライザーで解析され、分割された最小単語単位でORで検索されるみたい！ どういう事かと言うと、キーワード：「東京都」 で検索した場合、アナライズ後、「東京」 と 「都」 の２単語にトークナイズされ、検索は 「東京 OR 都」で検索される動きをしているようです。 もちろんこの場合、「東京都」を含んでいるドキュメントもマッチしますが、「東京」だけ、「都」だけ、または、「東京 … 都」「都 … 東京」などの単語が離れているドキュメントにもマッチする可能性があります。 ネットを調べてもあまり見当たらず、みんなどうしているんだろう？当たり前の仕様なのか？この動き違和感ありありです。 デフォルトの仕様を
対象は feed の entry を本文込みで保存した 100万行ほどのテーブル。PostgreSQL 8.3.7 on x86_64-pc-linux-gnu. まずは単純な方法。 SELECT * FROM entry ORDER BY random() LIMIT 1; 直感的 シンプル しかしシーケンシャルスキャンが起きる $ EXPLAIN ANALYZE SELECT * FROM entry ORDER BY random() LIMIT 1; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------------- Limit (cost=174494.29..1744
プロダクトを中心に構築された組織は、エンドツーエンドで作業を監視する。Conwayの法則を逆転して、プロダクトに基づいた長期的なチームを確立することにより、組織が安定すると同時に、作業の管理と優先順序付けが容易になる。レトロスペクティブはプロダクト管理の強力なツールだ – 継続への自信を与え、組織に対するリスクや損失の可能性のあるものを素早く見つけ出せるようにしてくれる。 アジャイルコーチでトレーナ、講演者、コンサルタントのArdita Karaj氏は、eXperience Agile 2018で、“What’s my product”と題した講演を行う。同カンファレンスは10月1～2日、ポルトガルのリスボンで開催される。 InfoQではeXperience AgileをQ&Aや要約、記事などでお伝えする予定である。今年のテーマは“人々を通じた改善”だ。 世界各地から集まった業界のトップリ
はじめにこんにちは、Zaim で iOS チームのリーダーをしている @y_sumida です。 以前のエントリ、大規模サービス開発で起こりがちな「やり直し」が激減した私たちの仕様確認フロー #Zaim では、Zaim でやり直しを減らすために整備した仕様確認の流れをご紹介しました。 流れの中に 真剣にレビューする というものがあったのですが、もう少し掘り下げて、開発する上で見逃しがちな「細かい仕様」をどう発見し、手戻り少なく実装しているかについて共有したいと思います。 一口に「細かい仕様」と言っても色々あります。例えばサービス開発の中でも、入力フォームに文字数制限をかけたり、金額によって数字の色を変えたりと、値に関する仕様は基本かつ複雑になりがちです。これらを曖昧なままにしておくと、仕様には沿っているものの、不思議なバリデーションや、ユーザーから見て矛盾したデザインのままリリースされ
Cloud Native Buildpacks (CNBs) transform your application source code into container images that can run on any cloud. With buildpacks, organizations can concentrate the knowledge of container build best practices within a specialized team, instead of having application developers across the organization individually maintain their own Dockerfiles. This makes it easier to know what is inside appli
Export all iconschoose some icons on right to narrow your selection
iPhone や iPad、Apple Watch といった、Apple のモバイルデバイスのディスプレイサイズがひとまとめで比較できる一覧 PNG を作成しました。 以下の項目がブチ込んであります。 ・名称、米国での発売年、物理的なドット数、物理的な解像度、 論理なドット数、論理的な解像度、Retina画像、倍率。 ・対角インチ数、ドットピッチ、横縦アスペクト比、 ノッチや角丸を考慮した表示領域の面積。 ・対応OS。Apple が正式に発表していないものに関しては、私が計算した数値になりますので「だいたいこんなもんか」程度でお願いします。間違ってるところや変なところがありましたら、@onthehead まで、優しくご指摘ください。 Apple mobile device display size PNG 画像iPhone、iPad、Apple Watch をひとまとめにした一覧です。ぱっ
「美意識のある経営」というのを、生涯のテーマに掲げていきたいと思っています(大げさですが)。それはもちろん「自社」もそうだし、「他社」に対しても普及していきたいテーマです。 「美意識のない企業」の仕事はしないし、「美意識のない提案」はしないようにしていきたい。そして「美意識のない企業」は淘汰されていくような社会になればいいなと思っています。 ここでいう「美意識」とは、「物理的な審美眼」だけではなく、「精神的・文化的な審美眼」をさしています。言ってしまえば、Googleが "Don't Be Evil." と書いていたものです。つまり、「儲かればいい」という概念だけでなく、その事業が「社会をよりよい方向に進めるか」ということを追求する経営者の意識です。 分かりづらいので「美意識のない経営」について話します。 「美意識のない経営」とは、社員を不当に残業させたりする経営です。その場限りの売上のた
消極的な人よ、声を上げよ。......いや、上げなくてよい。 ー「消極性デザイン宣言」 そのタイトルに興味を惹かれて一気読みしました。 これがよかった。自分の感じていた違和感をデザインで解決しようとしている。 わかる、わかるなあ。 服を見ているだけなのに求めてもないおすすめをしてくれるショップ店員と話さざるを得ない空気も、合コンという恋愛対象としてジャッジメントされるような空間で2時間以上も強制的にコミュニケーションを求められるとか、スマホの画面をのぞいているのかのぞいていないのか電車の隣の席の人の視線が気になる…。 「でも、嫌だなんて言えない」 消極的人間の行動をテーマにデザインを考えてみると「ユーザーのため」という言葉に懐疑的になる必要性があることがわかってきました。 「わかりやすさ」という強要ユーザーインターフェースといえば、ユーザーが「使いやすいこと」「目的の導線に導くこと」「行動
はじめに AWSを利用しているプロジェクトのリーダーは一読ください。 AWSアカウント契約の準拠法と、管轄裁判所を変更する手順をまとめます。 お客様のAWS環境を自社が代行して契約しているようなケースの場合、米国法のままになっている可能性があります。後述するAWS Artifactから、本番環境で使用しているAWSアカウントの準拠法を確認することをお勧めします。 AWSを使うプロジェクトでPLが意識すること RFPや要件定義時の非機能要件の確認事項として、「クラウドサービスの準拠法が日本法であること」 を確認されたほうが良いと思います。 AWSとの契約のおさらい AWSは米国企業であるため、たとえ東京リージョンにアカウントを作成したとしても、契約の準拠法はワシントン州法、同契約に関するあらゆる紛争に関する第一審裁判所はワシントン州キング郡州裁判所または連邦裁判所になっています。 情報元（A
ジョブキューイングシステムをどうするかでチームのリーダーとやりあって考えたことがあるのでまとめておく。 Rails で使うジョブキューイングシステムの技術選定で、リーダーは Amazon SQS 推し（レガシーシステムで SQS を使っている）、自分は Sidekiq 推しだった。前職時代に Sidekiq を使ってトラブルに遭遇したことはなかったし、とても簡単に使えるので Sidekiq で十分だと思っていた。 Sidekiq は GitHub でのスター数は 9000 オーバーで、 Rails の ActiveJob バックエンドとしては事実上のデファクトスタンダードだといえると思う。ググれば情報がいっぱい出てくるし、チームメンバーもリーダー以外は全員 Sidekiq の使用経験があった。 GitHub - sidekiq/sidekiq: Simple, efficient back
hatsApp cofounder Brian Acton, 46, sits in a cafe of the glitzy Four Seasons Hotel in Palo Alto, California, and the only way you’d guess he might be worth $3.6 billion is the $20 tip he briskly leaves for his coffee. Sturdily built and wearing a baseball cap and T-shirt from a WhatsApp corporate event, he’s determined to avoid the trappings of wealth and runs his own errands, including dropping o
デザイン・イノベーション・ファームのTakramが毎週２本のペースでお届けしているポッドキャスト「Takram Cast」。その音声の一部をnoteで公開しています。全編を音声で楽しみたい方は「Takram Cast」でお待ちしてます。 さて、今回は「融けるデザイン」の著者である渡邊恵太さんをお迎えして、自己帰属感やIoT時代のインタフェースデザインのありかたについて、ディスカッションしました。「ユーザーフレンドリーvsマシーンフレンドリー」「exUI」など新しいキーワードについても紹介します。 ( トークの導入部分は省略して、佳境に入ったあたりから抜粋 ) 田川 この『融けるデザイン』の本のあとに、ここの本を書いてた時点では気づいてなかったこととか、例えば新しく考え始めて、まだ答えになってないんだけど自分の中でちょっとテーマになりつつあるとか、それが新しいトピックっていうのはどうですか？
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
