お役所や大企業がIT調達の呪縛から逃れるためには - ku-sukeのブログ
宮坂さんのTweetを拝見し、僕もここ数年DXだとかFintechだとかよくわからない業界でもがいてきて少し見えてきたことがあるので言語化してみたい。 勉強になった。行政ではIT調達なる言葉を使うが、ソフトウェア/デジタルサービスは「調達」という言葉に馴染まないのではと。サービスが顧客期待に応えるかは事前に積算できず不確実性が。顧客に聞きながら改善するしかない。これが今の予算/調達制度に抜群に相性が悪い仮説。 https://t.co/RUV1HzrDoe— 宮坂学 Manabu Miyasaka (@miyasaka) 2020年9月19日 おさらい。IT調達の呪縛とは まずはじめに、この国の遅れたIT化や、いけてない（ようにみえる）システムがなぜ起きているか、その原因の多くが、システム開発を「モノの調達」と同じフローに載せていることである。 たとえば、コピー機を100台、カラーレーザー
GraphQLはWeb APIの次のフロンティアか？ | POSTD
RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
参考訳：Docker ネットワーク設計哲学 - Qiita
Docker 社の Blog にネットワーク機能や新しい Compose 1.6 に関する投稿がありました。翻訳しましたので、以下参考程度にどうぞ。 対象となるのは、2016年2月にリリースされた Docker Engine 1.10 Docker Swarm 1.1 Docker Compose 1.6 です。 Docker Networking Design Philosophy | Docker Blog https://blog.docker.com/2016/03/docker-networking-design-philosophy/ Docker 1.7 で実験的にネットワーキングが導入されてから Docker 1.9 の初期リリースに至るまで、コミュニティから素晴らしい反響がありました！ 何よりもまず、議論、評価、プルリクエスト、山積みの課題、これら全てにかかわる皆さんに感
ターゲットを絞り、利用シーンを提案する――――ウェアラブル普及に向けたソニーの秘策
―― 思いもよらなかった使い方やアプリとは？ 田嶋氏 地方自治体の健康促進や介護施設の応用などですね。SmartBandにGPSが入っていれば、例えばシニアの方をトラッキングなどもきます。 ―― ウェアラブル端末が出た当初は、ガジェット好きな人が買うイメージがありましたけど、セグメントを広げることも重要ですね。 田嶋氏 ガジェット好きな人が買って、3カ月使って終わるというのが初期のころ。今は「ガジェットで何をするか」に行かないといけません。最初は買うけど長続きをしないというのがあるので、継続的に使っていただくユースケースやアプリをちゃんとご用意する必要があります。エンドユーザーの使い方は1つではありません。明確に用途を示さないといけませんが、我々が示すというよりは、我々とパートナーさんが示すということです。 アプリ開発の支援も積極的に行う ―― その（用途を示す）ために、どういう取り組みを
こてさきAjax:Chromeから綺麗に消えた Web Intents。その理由を追ってみる - livedoor Blog（ブログ）
2012年も残すところあと1週間あまり、明日はクリスマスです。今年1年はWebとデバイスとの連携を中心に色んな活動をしてきました。「最新のWeb技術（Chrome の Socket API）を用いるとブラウザから直接TVを操作できる」ことを紹介し、それと Web Intents を組み合わせると「YouTubeで検索したビデオを、テレビで視聴することができるよ」といったデモ(内容は、下のYouTubeをチェックしてみてください)を紹介してきました。 しかし、残念ながら（たぶん）2012年12月18日以降のChrome canaryで、Web Intents が使えなくなりました(Chromiumの対応Issueはこれ)。10月末ぐらいから、chorme://flags で「有効」にしないとWebページからは使えなくなっていた（Chrome の Web Apps では使えていました）のですが
結局、Twitter API 1.1で何が変わる？ 5つのポイント
結局、Twitter API 1.1で何が変わる？ 5つのポイント：Twitter APIと開発者規約変更のインパクトまとめ 変更による影響範囲や、一部APIの廃止、レートリミット方式の変更、アプリケーション当たりのユーザー数、ツイート表示方式の厳格化などを5つのポイントにまとめて解説 開発者のはしご外し？ Twitter API狂騒曲 Twitterは2012年8月から9月にかけて開発者向けのブログで、APIや開発者規約の変更を立て続けにアナウンスしました。一部APIの廃止やレートリミット方式の変更、ツイート表示方式の厳格化など、影響は多岐にわたり、物議を醸しています。 Changes coming in Version 1.1 of the Twitter API Current status: API v1.1 Sunsetting @Anywhere Twitter、サードパーティ
TwitterのCEO、「真のプラットフォーム」の構築を強調--開発者の怒りの声を無視
Twitterが最近実施した同社サービスへのアクセス制限措置に対して、開発者コミュニティから怒りの声が上がっているなか、同社の最高経営責任者（CEO）であるDick Costolo氏は米国時間9月18日、その決定がより幅広いユーザー層に向け、今よりも奥深いプラットフォームを構築したいという考えに基づくものだと語った。 Costolo氏は18日、「Today Show」に出演して「モバイルを最重要視する」というTwitterの新たな戦略を明らかにしたほんの数時間後の夜に「Charlie Rose」に出演し、サードパーティー製のTwitterクライアントの機能を制限する措置について、個人ユーザーから大企業ユーザーまでをも含むあらゆるユーザーのためにTwitterのエコシステムを発展させていくという流れのなかで説明した。しかしながら、広告収入のさらなる増大を図っているのではないかという巷の意見に
Twitter API 1.1リリース 開発者の対応リミットは2013年3月5日に
Search API＋APIバージョン1.0ベースのウィジェットは2013年3月5日にサポートが終了するので、それまでに「Embedded Timelines」に置き換える必要がある。 米Twitterは9月5日（現地時間）、予告していた「Twitter API」のバージョン1.1へのアップデートと、開発者向けガイドライン「Developer Rules of the Road」およびアプリでのTwitterデータの表示について定めた「Developer Display Requirements」の改定を実施した。主な変更点は予告時点と大きく変わらないが、詳細がすべて明らかになった。 開発者は、半年以内、つまり2013年3月5日までに、APIのこの改定に対応する必要がある。 Twitterは、8月にAPIのアップデートを予告した際、クライアントアプリのユーザートークンの上限を10万に制限し
TweetBotのメッセージと新しいTwitterAPIルールの整理
僕も愛用しているTwitterクライアント、Tweetbotがブログで「パニクるな」というメッセージを発信しています。かんたんに紹介したい。 ちなみに、僕自身Twitterの規約改正にモロ影響受けそうなアプリを作っているだけあって、規約改正を読んで、いろいろ海外のブログの説明とか読んでたところ、これはやべえどうしようと泣きながらブログ書いただけあって、最初は確かにパニックであった！ というか、勢いで書いたブログが想像以上にバズって、それのほうがビビった。なので、できるだけアップデートしようと思って、その後いろいろ新しくわかった事を元に４回ぐらい追記したりしたけど、分かりにくいと思うので、現時点の情報を整理してみる。 とりあえず、TweetBotのメッセージを黒字でかんたんに紹介。 APIコールの制限について API認証は元からやってるからTweetbotには問題ない。 新しいAPIコールの
Twitter api ver1.1、痛いところ、痛くないところ
Twitter apiのガイドラインが改定になるそうです。 Twitter API v1.1でのAPI利用ルールの変更について こちらの日本語ブログは当たり障りのないところしか書いてないので、関係者は英語の方を読むことを強くおすすめします。 Changes coming in Version 1.1 of the Twitter API どうしてもこういう制約が増えるものは、ネガティブが極大化するので、ちょっと冷静に見てきましょう。 ■すべてのapiのエンドポイントに認証が必要、さらにレートリミットの変更 現在、検索apiなどはOAuthの認証が不要で、IPアドレス毎に一時間あたりのアクセス数が定められていますが、これが廃止になり、2013年3月までに全てOAuth認証を通した方法に変更を求めています。 さらに、１時間毎にapiにアクセス可能な数が、apiの内容によって変わります。今までは
Metro UIは「UXアプリ養成ギプス」 : 小野和俊のブログ
昨日、今日とWindows Developer Days(WDD)に参加してきた。二日間セッションに参加して感じたのは、「Metro UIは『UXアプリ養成ギプス』だ」ということである。 デザインの原則がある。 例えば原則のひとつに、”Content before Chrome”というものがある。これは、「コンテンツを主役にし、ツールバーやメニュー等のコンテンツへの没入を妨げるものは最小限にする」というものだ。 こうしたデザインの原則やガイドラインがきちんと決められている、ということは重要なことではあるが、それ自体はさほど驚くべきことでもない。先日ブログに書いたように、最近の主要なプラットフォームには、大抵UX/UIのデザインガイドラインが定められているからだ。 では私が何に驚いたかというと、Metro UIではこのデザインガイドラインが「半強制」されていることだ。 UX/UIに意識の高い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【＃モリトーク】第24話：明らかになった新Twitter APIの全貌
【＃モリトーク】第23話：Twitterクライアントは本当に終わるのか
Good night, Posterous