フィッシングやマルウェアのURLを共有する時、リンク化されないように hxxp://example[.]comのように記載する事があると思います。 その変換形式を定義する、『A Standard for Safe and Reversible Sharing of Malicious URLs and Indicators』という提案仕様がIETFに提出されています。 用語 難読化(Obfuscating): 誤ってクリックされないようにする変換のこと 難読化解除(De-obfuscating): 難読化されたものをもとに戻す変換のこと IOC: indicators of compromise。悪意あるURL、メールアドレスのこと もともとは、『無害化(defanging)』『もとに戻す(refanging)』の用語を使ってはいたがObfuscating, De-obfuscatingに
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって間
「QUIC-based UDP Transport for SSH」という提案が提出されています。 トランスポートプロトコルとしてQUICを利用することで、様々な恩恵を受けることが出来ます。 ユーザランドでコネクションが管理されるため、TCPとは異なりOSレイヤのでコネクション切断の影響をうけない IPアドレスが変わっても接続を維持できる(コネクションマイグレーション) 経路上の第三者による切断に耐性がある(QUICでは通信の切断にも鍵が必要) 個人的にも、SSHがQUIC上で動作することで切断しづらくなることを期待しております。 それでは、この仕様についてざっと見ていくことにしましょう。 ただ、まだまだこれから議論がされる提案仕様ですので、設計は大きく変わるでしょう。 QUIC-based UDP Transport for SSH の概要 QUICは内部的にTLSハンドシェイクを行って
プログラムの仕様からどのようなテスト入力し、どのようにテスト出力を確認すればテストが成り立つかをテスト仕様書に記述していくわけです。 この大変な手間がかかる仕事をテストのプロである派遣テスターにやってもらおうというわけです。 テスト仕様書さえできてしまえば、テストの実施作業は誰でもやれます。 というよりテスト仕様書を作る過程で、上の例でいえば確認日と確認者の箇所は埋まっていき、仕様バグ、設計ミス、基本的な動作確認ができてしまうのが普通です。 派遣テスターの主な仕事がテスト仕様書の作成であることは派遣会社にも派遣される本人にも説明しました。 なぜテスターがテスト仕様書を作るんですか？実際に派遣されてきた本人に一通りの説明をし、作業に入ってもらいました。 ところがいつまでたってもシステムを触っているばかりで、テスト仕様書を作る様子がありません。 理由を聞くと「なぜテスターがテスト仕様書を作るん
「開発チームには13カ国のエンジニアがいる。メンバーの足並みをそろえるには、日本語の文章を徹底的に排除する必要があった」――。 こう強調するのは、楽天カードの清水洋輔氏（システム開発部 会員システム開発グループ スマートデバイスチーム リーダー）だ。チームにはスマホアプリやWebシステムの開発を手掛ける13カ国50人のエンジニアが在籍する。開発プロセスにアジャイルを取り入れ、2週間～1カ月のサイクルでリリースを繰り返している。 清水氏らは2014年以降、開発スピードの向上やメンバーとのコミュニケーションを円滑にする取り組みを進めてきた。中でも設計書の改良が大きなテーマだった。何しろ13カ国のメンバーがいる。メンバー全員に意図が伝わり、開発スピードを高めるために設計書そのものを見直す必要があった。 大きな問題は、設計書が日本語の文章を主体にしていた点である。メンバー50人中26人が外国人で、
Ujörk🙏😌 @asazuke007 日本の大企業、外注しすぎて社内に仕様を把握できる担当者がいなくなり、他社に工数払って自社の仕様を教えてもらうというカオスな状況が生まれているので、過度なアウトソーシングはかえって非効率だと思いますね 2018-03-06 15:46:03
コンテナ型仮想化の技術や実装はDockerが登場する以前から存在していたとはいえ、IT業界で本格的にコンテナの活用が始まったと言えるのは、やはり2013年3月に当時のdotCloudからDockerが登場したことがきっかけでしょう。 そうして始まったコンテナ時代の第一章は今年2017年、コンテナの標準仕様がOpen Container Initiativeによって策定完了し、コンテナオーケストレーションの事実上の標準がKubernetesに決まったことで基盤技術の基本要素がおおむね固まり、一つの区切りがついたように見えます。 そして今後は、この基盤技術を用いたコンテナによる分散アプリケーションのための様々なサービスや開発、テスト、デプロイ、本番環境に対応したツールやサービス実行環境などのソリューションが登場し、競う段階へ入っていくのではないでしょうか。 この記事では、Docker登場から現
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Android デバイスは多くのメーカーによって様々な機種が発売されている。 そのため、機種によって搭載されている機能やスペックがバラバラである。 Android デバイス自体安い買い物ではないので 実際に買ってみて「○○機能が付いてないじゃん！」となると非常に悲しくなる。 悲しくなったことがある経験の反省も込め スペックを調べるためによく使うサイト集をまとめてみた。 GSMArena.com 情報がシンプルに1ページにまとまっているので見やすい。 まずスペック確認するならこのサイト、ぐらいにはオススメ。 デバイス関連のニュースや最新機
仕様書を書く上で必要かなと思うことをまとめてみた。 対象者は、まだ仕様書なんて書いたことないよとか、何書くかいつも悩む、という方。 ここでいう仕様書とは、開発前の設計書というよりは、運用フェーズに引き渡す前に用意しておいたほうがよいドキュメント、という位置づけ。 仕様書の目的 仕様書を書く目的は、新しい人がチームに来た時に、スムーズに業務に取り組めること。 また、「人は時間が経つと必ず忘れる」ので、将来の自分のためでもある。 大事なこと 仕様書の目的を明確にする。 あれもこれも、と情報をたくさんのせても混乱する。 「仕様書にもメンテナンスコストがかかる」ことに注意する。 仕様書は正しい日本語で書く。 主語をきちんと入れることが大事(〜のつもりで書いた、というのは知らない人には伝わらない)。 情報は多すぎず、少なすぎず。 条件について場合分けして整理したり、図を用いたりすると良い。 前提と制
「それ○○で標準化されているよ」って指摘されることほど、エンジニアにとっての屈辱は無いですよね。 ということで、世間知らずだと思われないためにも、手始めにISO縛りで有益そうな標準規格1をまとめてみました。 ちなみに、ISOとは…？ 国際標準化機構（International Organization for Standardization）は国際規格を策定する世界最大のボランタリーな開発組織で、国家間に共通な標準を提供することによって、世界の貿易を促進することに貢献している という組織だそうです。 (どう考えてもIOSと略すべきだと思うのですが、ISOになった理由は諸説2あるようです。) コード体系 ISO 639 (言語名コード) 例: 日本語 = ja, jpn 朝鮮語 = ko, kor 中国語 = zh, zho, chi, zho ドイツ = de, deu, ger, deu
ここ最近の出来事をまとめてみた。 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
以前、emitjson というパッケージを公開した。使い方は簡単に こちらに 書いたが、要はfunctools.singledispatch() をちょっと使いやすくしたものにすぎない。 singledispatch() は、Python3の抽象基底クラスと組み合わせると、非常に面白い使い方ができる。emitjson を例にして、使い方を紹介してみたい。 emitjson 簡単に emitjson の使い方を說明しておこう emitjson は、emitjson という名前だが、JSON を出力するためのモジュールではなく、いろいろなオブジェクトを json として出力可能なオブジェクトに変換するためのリポジトリを作成するモジュールだ。特にJSON専用ということもなく、たとえばCSVファイルを作成する場合などでも利用できる。 例として、datatime.date 型の日付と、PIL.Ima
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のディスカバリーの仕様 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）を用いて誰でもそれを実装できるようにしている． ディ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
