Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって
QUIC for SSH の提案仕様が出たよ - ASnoKaze blog
「QUIC-based UDP Transport for SSH」という提案が提出されています。 トランスポートプロトコルとしてQUICを利用することで、様々な恩恵を受けることが出来ます。 ユーザランドでコネクションが管理されるため、TCPとは異なりOSレイヤのでコネクション切断の影響をうけない IPアドレスが変わっても接続を維持できる(コネクションマイグレーション) 経路上の第三者による切断に耐性がある(QUICでは通信の切断にも鍵が必要) 個人的にも、SSHがQUIC上で動作することで切断しづらくなることを期待しております。 それでは、この仕様についてざっと見ていくことにしましょう。 ただ、まだまだこれから議論がされる提案仕様ですので、設計は大きく変わるでしょう。 QUIC-based UDP Transport for SSH の概要 QUICは内部的にTLSハンドシェイクを行って
テスト仕様書と派遣テスター
プログラムの仕様からどのようなテスト入力し、どのようにテスト出力を確認すればテストが成り立つかをテスト仕様書に記述していくわけです。 この大変な手間がかかる仕事をテストのプロである派遣テスターにやってもらおうというわけです。 テスト仕様書さえできてしまえば、テストの実施作業は誰でもやれます。 というよりテスト仕様書を作る過程で、上の例でいえば確認日と確認者の箇所は埋まっていき、仕様バグ、設計ミス、基本的な動作確認ができてしまうのが普通です。 派遣テスターの主な仕事がテスト仕様書の作成であることは派遣会社にも派遣される本人にも説明しました。 なぜテスターがテスト仕様書を作るんですか？実際に派遣されてきた本人に一通りの説明をし、作業に入ってもらいました。 ところがいつまでたってもシステムを触っているばかりで、テスト仕様書を作る様子がありません。 理由を聞くと「なぜテスターがテスト仕様書を作るん
13カ国のSEに意図が伝わる、生産性20倍のビジュアル設計書
「開発チームには13カ国のエンジニアがいる。メンバーの足並みをそろえるには、日本語の文章を徹底的に排除する必要があった」――。 こう強調するのは、楽天カードの清水洋輔氏（システム開発部 会員システム開発グループ スマートデバイスチーム リーダー）だ。チームにはスマホアプリやWebシステムの開発を手掛ける13カ国50人のエンジニアが在籍する。開発プロセスにアジャイルを取り入れ、2週間～1カ月のサイクルでリリースを繰り返している。 清水氏らは2014年以降、開発スピードの向上やメンバーとのコミュニケーションを円滑にする取り組みを進めてきた。中でも設計書の改良が大きなテーマだった。何しろ13カ国のメンバーがいる。メンバー全員に意図が伝わり、開発スピードを高めるために設計書そのものを見直す必要があった。 大きな問題は、設計書が日本語の文章を主体にしていた点である。メンバー50人中26人が外国人で、
外注をしすぎた結果、他社に自社の仕様を教えてもらうというカオスな状況に多くの声「過度なアウトソーシングは非効率」
Ujörk🙏😌 @asazuke007 日本の大企業、外注しすぎて社内に仕様を把握できる担当者がいなくなり、他社に工数払って自社の仕様を教えてもらうというカオスな状況が生まれているので、過度なアウトソーシングはかえって非効率だと思いますね 2018-03-06 15:46:03
Dockerコンテナ時代の第一章の終わり、そして第二章の展望など － Publickey
コンテナ型仮想化の技術や実装はDockerが登場する以前から存在していたとはいえ、IT業界で本格的にコンテナの活用が始まったと言えるのは、やはり2013年3月に当時のdotCloudからDockerが登場したことがきっかけでしょう。 そうして始まったコンテナ時代の第一章は今年2017年、コンテナの標準仕様がOpen Container Initiativeによって策定完了し、コンテナオーケストレーションの事実上の標準がKubernetesに決まったことで基盤技術の基本要素がおおむね固まり、一つの区切りがついたように見えます。 そして今後は、この基盤技術を用いたコンテナによる分散アプリケーションのための様々なサービスや開発、テスト、デプロイ、本番環境に対応したツールやサービス実行環境などのソリューションが登場し、競う段階へ入っていくのではないでしょうか。 この記事では、Docker登場から現
Android スペック調査に便利なサイト - Qiita
Android デバイスは多くのメーカーによって様々な機種が発売されている。 そのため、機種によって搭載されている機能やスペックがバラバラである。 Android デバイス自体安い買い物ではないので 実際に買ってみて「○○機能が付いてないじゃん！」となると非常に悲しくなる。 悲しくなったことがある経験の反省も込め スペックを調べるためによく使うサイト集をまとめてみた。 GSMArena.com 情報がシンプルに1ページにまとまっているので見やすい。 まずスペック確認するならこのサイト、ぐらいにはオススメ。 デバイス関連のニュースや最新機種のレビューなどもあるので、情報収集サイトとしても活用できる。 参考：Google Pixel 2 https://www.gsmarena.com/google_pixel_2-8733.php PhoneArena.com 名前的にも内容的にも機能的にも
仕様書の書き方 - Qiita
仕様書を書く上で必要かなと思うことをまとめてみた。 対象者は、まだ仕様書なんて書いたことないよとか、何書くかいつも悩む、という方。 ここでいう仕様書とは、開発前の設計書というよりは、運用フェーズに引き渡す前に用意しておいたほうがよいドキュメント、という位置づけ。 仕様書の目的 仕様書を書く目的は、新しい人がチームに来た時に、スムーズに業務に取り組めること。 また、「人は時間が経つと必ず忘れる」ので、将来の自分のためでもある。 大事なこと 仕様書の目的を明確にする。 あれもこれも、と情報をたくさんのせても混乱する。 「仕様書にもメンテナンスコストがかかる」ことに注意する。 仕様書は正しい日本語で書く。 主語をきちんと入れることが大事(〜のつもりで書いた、というのは知らない人には伝わらない)。 情報は多すぎず、少なすぎず。 条件について場合分けして整理したり、図を用いたりすると良い。 前提と制
エンジニアが知っておいて損は無さそうなISOの標準規格たち - Qiita
「それ○○で標準化されているよ」って指摘されることほど、エンジニアにとっての屈辱は無いですよね。 ということで、世間知らずだと思われないためにも、手始めにISO縛りで有益そうな標準規格1をまとめてみました。 ちなみに、ISOとは…？ 国際標準化機構（International Organization for Standardization）は国際規格を策定する世界最大のボランタリーな開発組織で、国家間に共通な標準を提供することによって、世界の貿易を促進することに貢献している という組織だそうです。 (どう考えてもIOSと略すべきだと思うのですが、ISOになった理由は諸説2あるようです。) コード体系 ISO 639 (言語名コード) 例: 日本語 = ja, jpn 朝鮮語 = ko, kor 中国語 = zh, zho, chi, zho ドイツ = de, deu, ger, deu
mruby-spec進捗日記〜第二話〜 - スペクトラム
ここ最近の出来事をまとめてみた。 ruby/specの作者とPRを交換した 前回のブログを公開した所、ある日メンションがとんできた。 @_ksss_ I managed to run some Fixnum specs of ruby/spec on mruby. I made it work with iij/mruby, mrbgems and modifying mspec locally a bit— Benoit Daloze (@eregontp) September 11, 2016 @_ksss_ I am interested in what you're doing with ruby/spec, feel welcome to open an issue for discussion :)— Benoit Daloze (@eregontp) September 11
仮想継承とsingledispatch - atsuoishimoto's diary
以前、emitjson というパッケージを公開した。使い方は簡単に こちらに 書いたが、要はfunctools.singledispatch() をちょっと使いやすくしたものにすぎない。 singledispatch() は、Python3の抽象基底クラスと組み合わせると、非常に面白い使い方ができる。emitjson を例にして、使い方を紹介してみたい。 emitjson 簡単に emitjson の使い方を說明しておこう emitjson は、emitjson という名前だが、JSON を出力するためのモジュールではなく、いろいろなオブジェクトを json として出力可能なオブジェクトに変換するためのリポジトリを作成するモジュールだ。特にJSON専用ということもなく、たとえばCSVファイルを作成する場合などでも利用できる。 例として、datatime.date 型の日付と、PIL.Ima
Berkshelf
Berkshelf : Manage a Cookbook's, or an Application's, Cookbook dependenciesBerkshelf Manage a Cookbook or an Application's Cookbook dependencies Download ZIP Download TAR View On GitHub Berkshelf is maintained by the Berkshelf Core Team Getting Started If you’re familiar with Bundler, then Berkshelf is a breeze. $ gem install berkshelf Successfully installed berkshelf-2.0.0 1 gem installed Specify
ACIのディスカバリーの仕様 | SOTA
ACIのディスカバリーの仕様 App Container Image Discovery “AppcとCoreOS/Rocket” に書いたようにAppc Specではインターネット上に配置したApp Container Image（ACI）のURLとそれを検証するための署名のURLをACIの名前から解決する方法も仕様として定めている．その仕様がなかなか面白いので簡単にまとめておく． なぜ必要か Dockerではイメージの配布にDockerHubやDocker Registryを使う．使うしかない．イメージ取得をするにはRegistryと話す必要があり拡張性がない．.tar形式にして自分の好きなストレージに置くこともできるが気軽さは失われる．これらを踏まえてAppc specでは普通に使われているWebの技術/仕様（HTTPS+HTML）を用いて誰でもそれを実装できるようにしている． ディ
R Packages (2e) - 13 Testing basics
Testing is a vital part of package development: it ensures that your code does what you want. Testing, however, adds an additional step to your workflow. To make this task easier and more effective this chapter will show you how to do formal automated testing using the testthat package. The first stage of your testing journey is to become convinced that testing has enough benefits to justify the w
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxでハードウェア情報を表示するコマンドまとめ
Common Lisp 仕様入門|独学 Common Lisp
データ定義から読み取る仕様の目次 - Jの衝動書き日記
https://github.com/distribution/distribution/blob/master/docs/spec/manifest-v2-2.md
Docker Image Specification v1.0.0
GitHub - k1LoW/awspec: RSpec tests for your AWS resources.
