共通プラットフォーム一覧CPE概説 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
CPE(Common Platform Enumeration) ～製品を識別するための共通のプラットフォーム名の一覧～ >> ENGLISH 共通プラットフォーム一覧CPE(Common Platform Enumeration)(*1)は、情報システムを構成する、ハードウェア、ソフトウェアなどを識別するための共通の名称基準を目指しています。 CPEは、米国政府が推進している情報セキュリティにかかわる技術面での自動化と標準化を実現する技術仕様SCAP(Security Content Automation Protocol)(*2)の構成要素のひとつです。米国政府の支援を受けた非営利団体のMITRE社(*3)が中心となり仕様策定を進めており、2007年1月30日に最初の原案であるCPEバージョン1.0が公開されました。 その後、米国の脆弱性対策データベースであるNIST(*4)のNVD(
情報系研究者のための研究ノート - Qiita
Abstract 計算機科学研究での記録のとり方 を書いてから半年ほど過ぎて、さらに知見がたまったので書き直します。情報系研究者が、紙ベース以外で研究ノートを取る場合に何をすれば良いか とにかく効率よく研究するにはどうするか をいくつかまとめました。改善案があればコメント希望、自分も研究効率をあげたいので教えてほしいですね。半年ぐらい経ったらたぶんまた書き直すと思います。 Introduction 本記事は、締め切りの明確に定まっている文章(上位国際学会論文、国際学会論文のrebuttal(反論)データ、学位論文)のための実験を円滑柔軟に行う上での効果的なノウハウを提案する。この内容は、筆者のいる研究室でのゼミ内容を幾分反映してはいるが、それだけにはとどまらない。内容はいくつかの段階に分けられる。 実装段階での工夫 実験デザイン段階の工夫 実験実行段階での工夫 Preliminaries
エラーハンドリング・クロニクル #nds41 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに プログラミング技術の歴史は、ありとあらゆる歴史がそうであるように、いろんな「史観」で眺めることができます。ならば、プログラミング技術の歴史を、「エラーハンドリングとの戦い」という視点から見ることもできるのではないでしょうか。本日は、エラーハンドリングとの戦いの歴史を俯瞰することで、エラーハンドリングの勘所について考えていこうと思います。 なお、このエントリはNDSという勉強会の第41回で発表した内容と同一です。 Cの時代 Cの時代のエラーハンドリングでは、関数の返り値と、グローバル変数errnoを見ることで処理が成功したか失敗したかを見るのが一般的でした。 例として、文字列をlongに変換するstrtol関数をmanで引いてみましょう。すると、だいたい以下のようなことが書かれています。 変換に失敗すると、0を返す 変換に失敗した場合、グローバルな変数であるerrnoに以下の定数を
第1回 なぜ、Hadoopはどのように動くのか、を学ぶのか | gihyo.jp
はじめに ビッグデータ解析のためのシステム基盤として、Hadoopをはじめとするオープンソースのデータ処理ソフトウェア（データ処理系）が広く利用されつつありますが、当該データ処理系をすでに利用している、もしくは利用の検討をしている読者の方々の中には、たとえば以下のような問題を抱えている方が少なからずいらっしゃるのではないでしょうか。 データ処理系の使い方はなんとなくわかるが、その内部をあまり理解できていない。または、内部の動作原理がよくわからないので、本格的に使う気にならない。 同様の目的を達成する複数のデータ処理系において、どれを使って良いかがよくわからない。または、適切に使い分けられていない気がする。たとえば、どのような場合にHadoopを用いて、どのような場合に同類のデータ処理系であるImpalaやSparkを用いれば良いかが“明確に”わからない。 このような問題を解決するには、
巨大 Pull Requestを避けるための9つのポイント - Qiita
巨大 Pull Requestの問題 レビューに時間がかかる、疎かになる テストとコードを照らし合わせが大変 本番で問題が起きたときに、問題の切り分けがしにくい masterとの差分を反映する際のレビューが難しくなる 一つのミスが大きなfeatureブランチになるきっかけになることも 大きくなるとmergeに時間がかかり、ますます大きくなる どのようにして大きなPRを避けるか PRが大きくなりそうな時は事前に相談する 作業しているときに、変更点がたくさん必要になったときは早めにレビューアーに相談する 複数人で開発しているときは、しっかり話す時間をとる PRが大きくなる問題は後で変更するのが難しいので、最優先で相談するとよい。近くにいるなら直接相談する。いないときはチャットで相談する。 モデルだけの変更とテストを書く なにか機能の変更がある時に、まずモデルからレビューする 実際にどういう変化
On Flux Stores and Actions
There’s been a lot of discussion on what Flux is, the different variations, and how the pattern can be improved upon. I’ve even blogged about Flux here on this blog! I’ve been doing a lot of work with React and Flux in the past month. In that time, I learned a lot about architecture, patterns, and community best practices. I want to share some ideas that I’ve been thinking about here. In this post
What the Flux? (On Flux, DDD, and CQRS)
Flux is an application architecture designed by Facebook for their JavaScript applications. It was first introduced by Facebook in May 2014, and it has since garnered much interest in the JavaScript community. There are several implementations of Flux. Frameworks like Fluxxor keep to the original Facebook Flux pattern, but reduces the amount of boilerplate code. While other frameworks like Reflux
浅野紀予「思想としてのペースレイヤリング」 | ÉKRITS / エクリ
建物は変化する。刻々と成長し、みずから学んでいくものである。単なる空間的な構造物ではなく、時間というパラメータを考慮に入れ、この世界に生まれ、様々な成長を遂げ、やがては死に至る、一種の「有機的存在」としてとらえなおす必要があるのではないか。 スチュアート・ブランド※1 は、著書『How Buildings Learn』で、時の流れとともに建物に何が起こるのかを探究しました。そのなかでブランドが提示した「ペースレイヤリング（Pace Layering）」の概念は、建築の世界にとどまらず、情報やメディアに関わる分野でも多くの注目を集めてきました。 この本が世に出てから20年後の今、その思想の意味をあらためて考えたいと思います。 スチュアート・ブランドの基本モデル ペースレイヤリングの基本となったのは、この本で示された以下のモデルです。 ［図1］ “Shearing Layers of Chan
持続可能な開発を目指す ~ ドメイン・ユースケース駆動（クリーンアーキテクチャ） + 単方向に制限した処理 + FRP
この記事は、開発を持続可能にできるようなアーキテクチャとその適用方法を考察するものです。 骨子はできていますが、実装経験をフィードバックして詳細を若干変更するかもしれません。 勉強不足な点もあるので、意見を歓迎します。 開発においてよくある問題点 ビジネスロジックの本質が何だったか見失う。ソースコードのどこまでが業務上の関心で、どこからがそれを実現するための技術上の関心か分からなくなる。 入出力双方向の処理が散在して処理が追い切れなくなる。特にイベント処理でどこに飛ぶかわからないコールバック地獄になる。 初期化・つなぎ込み・統合者的オブジェクトが小さな機能単位で生まれて統一感が無くなる。 状態を持つ値が大量に散在して副作用を起こしバグを生む。 これらの問題の結果、小さな単位ごとに個人のノウハウで"良い"設計がされ、機能を追加しようとしたときにどういう方針で行えばよいか分からなくなる。 解決
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
JavaScript設計の世代と近未来の話。（JavaScriptおれおれAdvent Calendar 2014 – 24日目） | Ginpen.com
JavaScriptおれおれAdvent Calendar 2014 – 24日目 個人的に、こんな感じで認識してますって話。書くにあたりあんまり精査してないので勘違いありそう。やさしく教えてください。 もちろん個々人では先取りしてあれやこれややってる人もいて、そういう人たちは特に今でも第一線で頑張っているように思う。 原初 設計なし DHTML (Dynamic HTML) NoScript 設計なしに書いていた時代。 もちろん個別のアルゴリズムとかはあったんだけど、アプリケーションというよりはウィジェットとかそういう規模のもの。 あれよあれ、マウスカーソル追っかけるやつとかそういうの。もちろんまともに考えられたものもあったけど、少数派。JavaScriptといえば「よくわからない派手で邪魔なもの（を作るやつ）」という認識。ブラウザーの設定やプラグインでスクリプトの実行を停止している閲覧
メソッド名をシンプルにするために、 知っておくと便利な英語のprefixとsuffix - codic ブログ
メソッド名などをネーミングする際に、知っておくと便利な、接頭辞と接尾辞をリストアップしてみました。どのように元の単語の意味が変わるかのルールを知っておくと、よく使う単語をベースにボキャブラリーを増やすことができるので、覚えておいて損はないと思います。 使う場合は、当たりを付けて実際の使用がないか、Googleなどで調べてみてください。 1. pre-, post- / 事前〜、事後〜 per-は、元の意味に “事前に、前に”、post-は “事後に”という意味が付け加わえます。汎用性が高いのでとても便利です。afterやbeforeの代替になるかもしれません。 // 事前テストする function testBefore(); ↓ function pretest(); // 事後処理する function executeAfter(); ↓ function postexecute();
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
神獄のヴァルハラゲートのCSS設計 - I'm kubosho_
CSS Architecture Advent Calendar 2014 9日目の記事になります。 神獄のヴァルハラゲートのCSS設計方法について振り返りつつ、こうしているということや、上手くいったところ、改善したいところを書いていこうと思います。 アプリの規模 ASP.NET MVCを使っていて、View側はRazorテンプレートを使っているのですが、Razorのファイルを検索してみると以下の量となります。 find ./ -name "*.cshtml" | wc -l 1674 実際には、これにフィーチャーフォン向けのファイルや、部分的なViewファイルも含まれています。 なので、実際CSSを適用しているファイルの量は、この検索結果よりは格段に減りますが、それでも、約600ファイルはあると思います。 ちなみに、今年のはじめに同僚の@mayukiが、ソーシャルゲームのフロントエンドと
【動画】 名著『リーダブルコード』を解説者と一緒に読み解こう 〜3章 誤解されない名前〜 - Schoo（スクー）
オンラインの無料動画で学ぼう！須藤 功平先生
Web APIを作るときに考えること。 - パルカワ2
この記事はPepabo Advent Calendar 2014の11日目の記事です。 前日は、tnmtさんのVagrantのshell provisionerでApacheのビルド済tarボールをOSバージョン毎に作る術でした。 はじめに 今回は、Web APIを作るときに考えることをまとめました。 本当は、社内向けに資料を作っていて、社内の勉強会とかで話せればいいか〜って考えていたんですが、アドベントカレンダーのネタが本当になくて困っていたのでこれを使います。 対象者 APIを作る時、と書いてますが、クライアント側の人にとっても知っておく必要があることなので、サーバ側の人・クライアント側の人両方が対象者です。 APIを作るときに考えること 「APIを作るとき」と言っても、色んな状況があります。 まずはそれを絞ります。 APIの種類 プライベートAPI アプリのAPIなど使う人が限定され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Do Not Learn Frameworks. Learn the Architecture.
プログラムを高速化する話
oreilly.com
Introduction - 艦これAPIを叩く
