「xml」を含む日記 RSS

はてなキーワード: xmlとは

2018-04-08

読んだページを全部自動ブクマする

数日前に puppeteer で自動PDF にする試みを書いたブログホッテントリに入ってるのを見た

それに影響されて自動ブクマするもの作ってみた

bg.js

const username = ""
const api_key = ""

chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
	if(message.bookmark){
		bookmark(message.bookmark)
	}
})

async function bookmark(url){
	fetch("http://b.hatena.ne.jp/atom/post", {
		method: "POST",
		referrer: "no-referrer",
		headers: {
			Accept: "application/x.atom+xml, application/xml, text/xml, */*",
			"X-WSSE": await createCredential(),
		},
		body: `
			<entry xmlns="http://purl.org/atom/ns#">
				<link rel="related" type="text/html" href="${url}" />
			</entry>
		`.replace(/\t/g, ""),
	}).then(e => {console.log(e)})
}

async function createCredential(){
	const non = Math.random().toString(36).substr(2)
	const now = new Date().toISOString()
	const buf = new TextEncoder().encode(non + now + api_key)
	const u8a = new Uint8Array(await crypto.subtle.digest("SHA-1", buf))
	const str = Array.from(u8a, e => String.fromCharCode(e)).join("")
	const b64 = btoa(str)
	return `UsernameToken Username="${username}", PasswordDigest="${b64}", Nonce="${btoa(non)}", Created="${now}"`
}

username と api_key を埋めてバックグラウンドで動かす

page.js

chrome.runtime.sendMessage({
	bookmark: location.href
})

ページ内で動かすコード

URLバックグラウンドに投げる

今は全部投げるコードになってるが、必要に応じていらないドメインを弾いたりする

2018-03-13

大企業って無駄システム多くない?

大企業クライアント案件を受注したらしく社内説明会でどんなものを作るのか聞いてきた

詳しいことはもちろん書けないんだが、大雑把にいえば、その社内でのやることに応じたシステムが10や20とある

それぞれ独自フォーマットデータを扱うからシステム間のフォーマットを変換するシステム必要のようでそれを作るらしい


こういうのは大きいところならよくある話だとか

そして今回作るようなシステム間のデータ相互変換のようなシステムはすでにクライアント社内にいくつもあるらしい

さらにはそれら変換するシステム同士をつなぐシステムというものもあるらしい


それぞれのフォーマットは別だが中身はおなじということが多いらしい

それってなんか無駄すぎない?


フォーマットXMLとかJSONとかTSVとかの汎用フォーマット統一して各システム必要な部分だけをみればいいんじゃないの?

お金もらえるわけだから無駄であろうと作るのだろうが、無駄ものがどんどん膨らんで行きそうな気がして仕方がない

なんかシステム作る側があとから変換システムも作ってお金もらうために独自フォーマット採用しているように思えてくる

日本ITダメとか言われるのも価値のある新しいものを作るのじゃなくてこんな無意味ものをいっぱい作ってるからなんじゃないかなーとも思った


クライアント側が過去のものをそのまま使いたいとか変な要望を無理に通したせいでこんなことになってきたということもあるのだろう

IT系は人じゃなくて機械にあわせるべきだと思うんだよなー


2018-02-14

bug?

初めてスマホに表示された。

bugったのか?

This XML file does not appear to have any style information associated with it. The document tree is shown below.

&lt;rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xml:lang="ja"&gt;

&lt;channel rdf:about="https://anond.hatelabo.jp/rss"&gt;

&lt;title&gt;はてな匿名ダイアリー&lt;/title&gt;

&lt;link&gt;https://anond.hatelabo.jp/&lt;/link&gt;

&lt;description&gt;はてな匿名ダイアリー&lt;/description&gt;

2018-02-06

MPEG-DASHはなんで今になってXML採用しているんだ

2017-12-01

学科教員ブロックされた話

この記事いい話Advent Calendar1日目の記事です。

AdventCalendarに名前があるのにわざわざここで書いているのはハイコンテクストネタです。分かる人には分かります

突然ですが、先日僕の行く大学教員Twitterブロックされていました。

からなんだという話ではあるのですが、いい話っぽいのでまとめたいと思います

原因

いつからブロックされていたかが分からないので原因が詳細には分かりません。

色々と日々Twitterで僕が言っていることに反応したんじゃないかと思います

よっぽど構って貰える人がいないのか、中年おっさんTwitter学生空リプしまくったり、学生同士の会話のコンテクスト無視してクソリプをしているのを見ると悲しくなります

その人の講義はやれXMLデータベースだのJava Appletだのを言っていたので頭が痛くなって履修をやめました。

おそらくこういったことをインターネットバカスカと書いてクソクソ言っていたのでブロックされたのでしょう。

学科教員ブロックされないためには

同じ大学の皆様には教員との良好な関係を築くためにも上記のような心がけが必要だと思います

僕はインターネットクソ野郎なので無理でした。

2017-11-25

anond:20171125002759

いや、普通にJava案件ならどこでもXML読み込みなんてやってるから

 

しろPythonAI利用以外はJavaよりかなり遅いか

AIとか統計学時代に俺はJavaxmlファイルの読み書きをするプログラム

悲しい

しかもうまく動かないでやんの

2017-11-23

「何を勉強すればいいんだろう」から半年経った

anond:20170504171337

あれから半年、分からないながら自分なりに頑張って、Excel VBAVB.NETバッチ勉強した。いくつかアプリを作って、業務自動化し、会社の割と偉い人に認知され、評価もしてもらえた。今月からN予備校プログラミング講座を受講している。

で、半年前に書いた自分日記を読んで思ったのだが、これExcel使うの辞めればよくね?

検査表は、検査項目の文章や合否判定や値の入力欄なんかはWebで構築して、検査結果だけをXMLcsvで延々吐き出す。作業時間だってそうだ。

現場のすべてのPCExcel入ってる必要は無いんだ。どうせグラフにしたり傾向をつかんだり、そんなことをするのは一部の管理者に限られる。いざって時にだけ閲覧できればいいんだ。なんなら閲覧画面もWebでこしらえてしまおう。

Office購入費用も抑えられるし、PC環境依存しないし、なんだ、いいことづくめじゃないかセキュリティだけは不安から気を付けないといけないけど。

とにかく、迷いながらも勉強を進めてきてよかった。これからも続けていこう。

メタナントカ

例えば「AB」という概念があった時, 「ABAB」「ABのAB」「ABに関するAB」という概念も成立しうる場合, その概念は「メタAB」と呼べそうである.

あたりがぱっと思いつくけれど, 身近な例でも応用できないだろうか.

意外と難しい.

2017-11-03

Windows10メモリリーク

23日間ほどスタンバイを利用しながら、Windows使用し続けるとメモリリークになる。

物理メモリ 8 GB

コミットチャージ 32 GB

警告のダイアログが出る。

コンピュータメモリが不足しています

プログラムを正しく動作させるのに必要メモリ復元するにはファイルを保存してから、開いているすべてのプログラムを終了または再起動してください。

このダイアログテキストコピーできない。

イベントビューアを見ると、chromeウイルスバスターメモリを消費していた。

chromeを閉じてMicrosoft Edge を起動してみると、

イベントビューアではEdgeウイルスバスターメモリを消費しているとのこと。

なのでウイルスバスターアンインストール

Windows Defender に変更して様子を見た。

chromeメモリを消費しているとのこと。

物理メモリの利用可能な空き領域はあるけれども警告がでる。

イベントビューアのログWindowsログシステム→警告

Windows仮想メモリの不足状態を診断しました。仮想メモリを多く消費したのは次のプログラムです: coreServiceShell.exe (2848) は 1477959680 バイトを消費し、chrome.exe (12928) は 499216384 バイトを消費し、chrome.exe (18092) は 243965952 バイトを消費しました。

Windows仮想メモリの不足状態を診断しました。仮想メモリを多く消費したのは次のプログラムです: coreServiceShell.exe (2848) は 1521418240 バイトを消費し、MicrosoftEdgeCP.exe (5936) は 921763840 バイトを消費し、MicrosoftEdgeCP.exe (6960) は 575160320 バイトを消費しました。

Windows仮想メモリの不足状態を診断しました。仮想メモリを多く消費したのは次のプログラムです: chrome.exe (5220) は 658739200 バイトを消費し、chrome.exe (5908) は 238960640 バイトを消費し、chrome.exe (10488) は 235864064 バイトを消費しました。

ソース: Resource-Exhaustion-Detector

イベント ID: 2004

タスクマネージャーメモリ

使用中(圧縮) 4.6 GB( 398 MB)

利用可能 3.2 GB

コミット済み 31.8/31.9 GB

キャッシュ済み 1.4 GB

ページプール 741 MB

非ページプール 398 MB

ハードウェア予約済み 91.8 MB

リソースモニターメモリ

ハードウェア予約済み 92 MB

使用中 4822 MB

変更済み 53 MB

スタンバイ 1376 MB

空き 1833 MB

利用可能 3216 MB

キャッシュ済み 1434MB

合計 8100MB

インストール済み 8192 MB

イベントビューアのログXML

省略。

WEB検索しているとWindows 7 からある不具合なのだろうと私は認識している。

長期間使用によるメモリリークが他の方の環境でも再現すると推測しているので、ここに情報を共有する。

2017-10-16

Markdownは使いにくい

Markdownはただのマークアップ言語

HTMLに「画像を挿入」できないのと同じ


で、まあ、Markdownはその出自上「テキストファイルで見たときにそれなりの構造を反映した見た目であること」を重視してる

Markdown文書さらHTMLPDFに変換することをあまり目的としていないのだ

からそもそもグラフィカルな編集サポート機能画面があるならその編集画面内での記述方法Markdownである必要はないというかむしろ害悪なんだよね

画面の内側でXMLなりHTMLなりバイナリで保持してから変換してユーザーリアルタイムに見せればいい

いまのMarkdownは使いどころ間違った使い方をされてることが多いのだ、君は被害者といえる

あとマイクロソフト関係ないぞ!

2017-06-12

CSVテロ

上司accessCSVを取り込めないと騒いでいる。

そりゃそうだ。ファイル名にドットが入っているからな。

"定義XMLによるスキーマ確認が失敗しました。XMLドキュメントの行 | にエラーがあります。"というエラーメッセージが出るからな。

ふふ。苦しめ苦しめ!わしは帰り増田

2017-04-11

オライリーに出てくるフレンズ

参考:http://www.oreilly.com/animals.csp

2017-03-19

http://anond.hatelabo.jp/20170319132149

日本のお役所PDF大好きなのは、知っている。霞ヶ関から吐き出される有効資料は、ほぼpdf

一方で、e-statなどでは、ネ申エクセルや方眼エクセルとは、別の方向でcsvデータを公開している。

今、株価が上昇しているIT企業様は、PDFhtmlとを比べるような使い方はしていないのでは?

世界は、IT企業htmlPDFとを比べたらどちらを重用しているのか?

  

googlejava script 推しのJQueryを良く使ってるし、これからは、人工知能時代からxml形式とか、マークアップ言語は、良く出てくると思うよ。

Facebookphpなんでしょう?リア充御用達で、Twitterよりも株価資本も安定している。

これからは、you tubeとかLINEみたいなツールがどんどん出てくるから、先のことは分からないよね。

オープンソースでもGit hubみたいなツールが使われているんだし。。  

そう言えば、perlcgiは、ほぼお亡くなりになりましたね。

2017-03-02

大手SIerの現状

Excelマクロなんて使ってないんだけど、Excel保存するときxmlがなんとかってエラーが出るなぁ」

大手SIerプロパー2名の会話が漏れ聞こえてきた。


それxmlじゃなくて、xlsmのことですか?

xlsxファイルの中身がxmlということを知らないんですか?

というか、xml自体知らないんですか?


こんな人達が、基幹系システム新規構築しようとしていることが恐ろしい。

こんな人達が作ったシステムを、使わされる人たちが哀れでならない。


完全に呆れてしまった。

2017-02-23

.iniファイル

このまえSIerPHPプロジェクトで、パラメーターを設定ファイルに外だししようって話になって「.iniファイルの読込ルーチンはどうする? だれか作れる? ○○さんがもってるかも」って話になってたから、PHPなら標準でxmljsonの読込関数がありますよって言ってみたけど「あ、こいつまた小難しいこと言ってる」みたいな空気になって流されたな。

ホットエントリ内閣府CSVやばいって記事で思い出した。

2016-11-06

http://anond.hatelabo.jp/20161105032504

かなり時代錯誤を感じる。ネタであって欲しい。もしかしてITリテラシー低すぎ?というか、好きなソフトウェアは何なんだよ。ノーカンプラ???

高い

"Excel" なら安い。アプリの数百円からデスクトップ版の1.5万程度。ていうか、¥14,526で売ってる。

https://www.amazon.co.jp/dp/B015SMNVAK/

重い

Excelが重いとかどれだけ糞スペ。

Windowsしか動かない

Mac, iOS, Android, ブラウザでOK。

よくバグる

それはExcelに限った話ではない。ソフトウェアである以上多少のバグはしゃーない。つかリソースが糞なせいじゃねーの?滅多に落ちないが。

検索性が悪い

イミフ普通に検索出来るだろ。

共有PCとかだと高確率で使えない(Excelが導入されてないから)

ブラウザでOK。

Markdown表現できるレベル資料とかもはや何のためにExcel使ってるのかわからない

それはExcelのせいじゃなくて使う人間馬鹿なんだろ。

タブ表示が面倒臭い

ショートカットご存知無い?馬鹿?ページスクロールも面倒臭そうだな。見なくていいよ。

バージョン管理システム管理した場合Diffが見にくい

それはそのバージョン管理システムが糞なんだろ。Diffを見るだけならWinMerge+xdocdiff普通にやすいが。馬鹿なの?

セル結合死ね

嫌ならマクロで一括解除&復元でもしろマクロからでも普通に扱えるし、イミフ。罫線も死んじゃうの?

Excel製ワイヤフレームとか手書きの方が多分まだ保守やす

知らんがな。使い方の問題だろ。ExcelじゃなくてWordならいいのか?馬鹿

お節介な補完がうざい

嫌ならOFFにしろよ。馬鹿

方眼紙死ね

Excel方眼より良いものがあれば使わないだろ。普及度、使い勝手トータルでExcel方眼より良いものがあればぜひ教えろ。

学生相手Office持ってる前提でいろいろ求める風潮

しろ、今の大学Office使わないところあるの?マジ?普通総合大学ならITの授業あるだろ??レポートOffice使うだろ???

それとも持ってるけど使えない脳足りん系?F欄なのかな。

つか、Excelの話じゃないのか?

AシートとBシートで別々の人が全く関係ない作業しててもマージするとコンフリクト起こる

形式(.xlsx)はXMLZIPで固めただけだから分解して好きにしろ

2016-10-25

gmailフィルタードメイン一括変更

会社メールドメインが変わることになって山のようなフィルターも全部変更しないといけなくなった

最初のいくつかは手動でやってたけどあまりにもめんどくてぐぐったらいいほうほう見つけた

フィルターxmlエクスポートしてドメイン部分を一括置換してそれをインポートすりゃいいらしい

脳汁出た

2016-10-20

RSSって何?

なんかどこのサイトいってもフォーマットであるとか更新されてるかどうかわかるとか購入とか色々書いてあるけどさっぱり分からん

例えばFacebookボタンとかならFacebookシェアするボタンとか用途と共に書いてある、ツイッターも同じだけど

RSS活用してる用途とかは全然書いてくれてない

一体設置したらどうなのかとかどう使われるのかとかそこんところ抜け落ちてフォーマットだとか言われてもまるで理解できない

Wikiでさえ3パターン意味の揺らぎがしょっぱなにあってさらに混乱する

 

RSSアールエスエス)は、"Rich Site Summary"の略で、サイト概要記述する為のXML形式文書です。 このRSS提供したり、提供されたRSSのことをRSSフィードRSS feed)といいます。」

いやこの説明じゃ全然分からんから

なんでこの説明説明できた気になってんの?

RSSが何らかのサービスによって使われる要素ならそのサービスの内容と運用方法も照らし合わせて説明してくれよ。

なんでITってたまにこういうとんちきな説明だけで済ませようとすんのかね。

ひょっとして頭悪いんじゃないの?

2016-07-18

Vimフィルタコマンドで使うUNIXコマンド

http://vim-jp.org/vimdoc-ja/change.html#filter

Vimにはフィルタコマンドといって、テキスト任意UNIXコマンドで処理するExコマンドが用意されている。

用意されていて、実際強力なんだけど、Vim組み込み機能で間に合うことも多くて、下記以外はあまり使っていない気がする。

以前はVim正規表現に慣れないからとPerlを使ってたりもしたけれど、Vim正規表現も悪くないかなとなって。こう。

何かおすすめUNIXコマンドがあったら教えてください。

bc

簡単計算をするときに使う。1行に計算式を書いて「:.!bc<CR>」あるいは「!!bc<CR>」とすると計算ができる。

(小数を扱いたいときは-lオプション指定する)

「<C-r>=」で代用できる。

sh

長めのコマンドを実行するときに使う。「:%!sh<CR>」とすると書いたシェルスクリプトを実行できる。

最近Bashの<C-x><C-e>で良い気がしてる。こちらだとヒストリで戻って<C-x><C-e>として再編集することもできるので。

column

簡単な整列をするのに使う。ビジュアルモード選択して「!column -t<CR>」とすると整列ができる。

(デフォルトのセパレータがスペース二つなので、一つにしたければ-oオプション指定して「!column -to' '<CR>」という風にする)

vim-easy-alignやvim-aligntaが入っているならそれでいいかも。

jq, xmllint, pup

それぞれJSONXMLHTMLを整形するのに使う。JSONは「:%!jq .<CR>」、XMLは「:%!xmllint --format -<CR>」、HTMLは「:%!pup<CR>」。

ただ「jq . <JSONファイル> | vim -」としていたりして、直接Vimの中で使ってない場合が多いかも。

awk

連番を振る時、重複行を削除する時、指定した列を抜き出す時、などなど、色々なことに使える。

それぞれ「:%!awk '{printf"\%-6d \%s\n",NR,$0}'<CR>」、「:%!awk '\!a[$0]++'<CR>」、「:%!awk '{print$2}'<CR>」といった風にする。

tee

保存するために管理者権限必要場合sudoと一緒に使う。「:%!sudo tee %<CR>」とすると保存できる。

編集中のテキストを何処かに残すため……と思ったけど:wで事足りる。

2016-05-29

富士通退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いか想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると(後述の富士通入社して10年が経った人の話にもあるのだけど)新人能力客観的判断材料って大学資格応用情報レベル以上)程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士しか居なかった覚えがある。あと確か2~3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、(自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた)、そういうのに入社して間もなく入ってしまうと自身勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。(自分炎上案件に放り込まれ新人が寮で死んでたとか話を聞いたことある

上司対応はまあこれだけ見ればクソだわな。

富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業経営とか体制とか理解出来るんかね?と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的巨大企業特有問題があってそうなってるんだなって思う事が多々あった。

富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分経験と一致してる。特に富士通ソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか(特に学生なんかじゃ)判らないかなと。

それでこれらの話を見てどんな人が富士通(というか大企業)に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる(要するにそこそこの大学に行って卒業した人)、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解やすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社子会社で色々アルかもしれないけど。

で、自分入社から退社までの話。

入社10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1~2年したら子会社の統廃合とのことで富士通本体連携してる部署自分がそうだった)は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由実家事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体ソフト開発配属の人達研修をやったのだけど、その際に富士通本体人達と知り合った。(この際に全員のプロフィール冊子が配られた)そのときは流石子会社に入る人達本体とじゃレベルが違うな~と思いましたね。(ちなみに自分MARCHより下の院卒。)

自分が配属されたのは某製品部署API部分チーム。その製品C言語Java言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPポートプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙ヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語APIリニューアルするって開発してたのだけど、設計担当Javaしかやったことない人で色々とC言語流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね(ちなみに機能はそれサーチか?思うのもあった)。もっと酷かったのが初期製品Javaの公開メソッドで、マニュアルには「このメソッド引数○○を□□を指定した場合戻り値Objectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的C言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSWindowsLinuxSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0Genericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計実装結構良い感じに出来たと思う。ああ、そういえばRuby用のAPI効率化の開発ツールとかの名目仕事中に勝手に作ってたなあ。他にもC言語APIも内部実装がクソすぎ!とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対LDしてるんで完全に趣味なんだけどな。これでAPIC言語Java.NETになった訳だけど、現場案件で使われたのってほぼ全てJavaだったと思う。(開発中のサーバテストアプリC言語だけど)。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟必要かもね。

で、.NETAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品担当が増える事に。インストーラWindowsがInstallShieldというクソみたいな言語上で作られたものLinuxSolarisシェルスクリプトのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか)とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味C++勉強してたので何とかなった。あと、結構OSの知識(プロセスとか)が必要WindowsLinuxSolarisで動くコードを書く必要があってまあまあ大変でした(と言ってもifdefで切り分けるだけなんだけど)。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品バッチ処理に使えないかとか話が出てきたあたりで自分退職する事に。(退職の話は1年ぐらい前に話し合って決定済み)引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしま実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40~60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部(だったかな?)単位残業禁止になってホント残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通ソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか(そんなに深くはないけど)色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモ体験出来たのは良かったです(こなみ)。

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

2016-03-12

プログレッシブ最高じゃねえかNHK死ね

元日マイクロソフト古川享さんブログより。このブログかなり前から消えてるんだけど、復活の目処は無いのだろうか

放送通信の在り方に関する、私見その9

http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry

https://web.archive.org/web/20061105065656/http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!4256.entry

さて、この話をいつかはちゃん記述しておかねばと常々思っていたのですが、それに取り掛かろうと思うと胸の古傷が疼くというか、平常心を保って書こうと思ってもキーボードを叩く手に自然と汗が滲んでくるのです。しっかり深呼吸をして、書きます。(またまた長文にて、失礼)

まず、1999年5月24日発表の郵政省資料地上デジタルTV放送方式について電気通信技術審議会から答申」に記述のある以下の文章をご査読ください;

「また、昨年9月の暫定方式や既に答申がなされているBSデジタル放送方式CSデジタル放送方式技術的条件において、実証実験必要とする映像の表示方法とされていた720p(有効走査線数720本の順次走査による映像表示方法)について実験を行った結果、その性能が確認されたこと等が併せて報告されました。 この中で、720pは技術的にHDTV放送位置付けることが可能である、と結論付けられています。」(同上答申より引用

関連記事は、日経産業新聞(1999年5月25日PP.3)、日本経済新聞(1999年5月25日PP.11)、電波新聞(1999年5月26日PP.2)などにも掲載されています

以下は、そこに至るまでの「血と汗と涙のお話」であります

今となっては、720pや1080pのプログレッシブ方式プラズマ液晶テレビとの親和性映画CGなどの映像制作に有利なバリアブル・ピッチによる撮影パソコンによる編集再生環境においてその優位性を疑う人は居ないと思うのですが...1998年からこの1999年5月24日までの間、この720pを日本放送業界から抹殺しようとする「ありとあらゆる活動を展開した集団」がおり、その軋轢の中で多くの人が傷付き市場から去ることになったのでした。

個人の主張、そしてマイクロソフト立場は、1080iと720pどちらが良いか、どちらかひとつを採択するかではなく、仕様の中に1080iと720pを併記して頂きたいというものでした。 米国放送方式はATSCによるHD放送に向けた放送の標準フォーマットとして早くから1080i、720p、480p、480iが規定されていました。50年以上前発明されたテレビ放送米国に合わせてNTSC方式日本採用し、ヨーロッパ中国ロシアなどがPAL方式採用してきた背景からすれば、日米のテレビ方式デジタルハイビジョンHD放送)の時代になっても米国と同様の1080i及び720pを両方サポートするということは自然なことと思われました。日米間の互換性だけではなく、当時よりブラウン管チューブを使った重たいテレビ受像機は、急激な勢いでプラズマTV液晶テレビに取って変わることは明らかであり、走査線が走り一本ずつの光るスダレを交互に表示して人間の眼の残像を利用してひとつ映像に重ね合わせるという飛び越し走査よりは、一つ一つのセルが自ら発光する、もしくは遮光をオン・オフして光源を反射もしくは直視映像表現するフラットパネル時代には、プログレッシブ順次方式が有利と思われました。さらに、映像圧縮採用されたMPEG2方式においては、1080iは22Mbpsでは最高品質映像を表示するも、その転送レートを15Mbps以下まで落としてくると映像破綻するという現象も既知のことでした。720pはMPEG2による映像圧縮でも15Mbpsでほぼ最高品質を達成し,12Mbpsでもほぼ実用の域を保ち、さらMPEG2以外の圧縮方式MPEG4H.264WMV現在のVC1)などを使えば8Mbpsから12MbpsでHD放送を伝送できるというのが、私たちの主張でした。

当時の私の主張をまとめると、「HD放送1080iもしくは720pいずれでも撮影、記録、編集、伝送、受信、視聴できることとする。映像圧縮に関してはMPEG2に限らず、将来の斬新な圧縮技術を随時採択できることにする。コンテンツ保護技術や、個人認証課金技術特定技術一つに限らず、複数技術をそれぞれもしくは組み合わせて提供可能とする。放送通信の融合(連携サービス記述するメタ言語HTMLベースに各種プラグインそしてXML対応する。XHTMLベースにしたBMLはそのサブセットとして組み込む。」

それに対して、1080i擁護派は、「1080iが優れた方式で、議論余地は無い、プログレッシブの話をするなら帰れ!!」(実際に砧の某研究所で当時の所長に言われた言葉ですが...今の所長さん(E並氏)はとても紳士ですので、私は尊敬しております。決して誤解のないように)郵政省会合でも何度となく放送プロ達に諭(さと)されたものです。「君はPC業界に都合の良い方向へ持っていこうとしてるんでしょ」「崇高な放送世界邪悪世界に引き込もうとしている」と..多くの人が同席する会議の場で私は名指しで糾弾されたものです。

将来のデジタル放送の規格に720pは絶対入れないという強い意思とあらゆる活動は「1080iと720pを併記したらどうか」と主張する陣営を徹底的に痛めつけました。

当時、松下電器産業殿は720pの優位性を説きながらDVC Proをレリースされ、1080iと720pの両用機能を持った松下電器産業HD D5という放送局用ビデオデッキは、AJ-HD2700やAJ-HD3700という型番で欧米放送局でも沢山採用され、放送業界権威あるエミー賞DVC ProもHD D5も受賞されています。このD5というビデオデッキNHK殿に納入する時、720pの機能が付いているなんてことがバレると殺されるので、本体に点在するボタン11個以上押さないと、(つまり二人の人間の指を駆使してボタンを押さないと720pの機能アクティブにならないように細工がしてあったそうです。)..まるで隠れキリシタンが隠し絵にキリスト像を描いていたような話でありますが..この類(たぐい)のプレッシャは日々激しいものになってきて、魔女狩りに駆り出された狂信的な信者が、誰彼となく次々と火あぶりに挙げるような行為が続いたのです。

480pと720pの実験放送をやっていた日本テレビSさんKさんの受けた仕打ちは、某放送局のEB沢さんから直接日テレ社長のUJ家氏に電話をかけてこられて、「お宅の技術トップ人間は、ウチに対抗して何かやっているようだけど、けしからん話だ。そんなことではデジタルハイビジョン映像をウチから供給できなくなるけれど、それでも良いのかねぇ」と迫ったそうです。その結果SさんKさんは当然将来取締役約束されてもおかしくない何十年にも渡る業界に対する貢献がありながらいつのまにか表街道を去ってしまうことになりました。

テレビ朝日殿が新しいスタジオを作るにあたり、1080i/720pの両用ビデオスイッチャーを東芝から導入された時、某放送局のキツイお達しがテレ朝東芝に飛び、720pの機能は殺して納入するようにとの指示が飛んだそうです。そして、BS-iスタジオ導入で,1080iのカメラと720pのカメラを性能評価したという話を聞きつけて、「まさか720pのカメラを導入するなんてことはありませんね?」という問い合わせが某局から入ったそうです。

TBS殿も全く同様にメインスタジオへのHD機材導入にあたって1080iと720pの両用システムの導入計画純粋技術観点選択肢だけではなく、それ以外の見えない力に奔走されておられました。「魂の報道」を標榜するTBS殿の報道部門が、DVC Pro 720pを採択されたことが、唯一の救いと感じられました。

NAB98の会場にて明日から開場というまさに前日のこと、某放送局のY氏、会場を事前に巡回されJVC殿の会場にて1080iと720pの両用カメラ発見JVC殿に対して「好ましくない表示は控えるようにと一括」結果としてNAB98の初日には無残にも綺麗にできた展示パネル1080i/720pの文字列の720pの部分にはガムテープが張ってありました。

毎週のようにこのような話を耳にするにつけ、これは魔女狩りでも特高警察検閲でもあるまいに…現代の話なのに本当にそんなことが起っているのだろうかと自分の耳を疑っていました。そしてそれが、とうとう我が身にも降りかかったのでした。

1998年NABショウでマイクロソフトは初めて放送関連のコンベンション技術展示をすることになりました(関連記事)。松下殿より当時500万円程したHD D5デッキマイクロソフトは購入し、1080iと720pの映像を左右1対で比較デモ表示し、どのように優位性が表示されるか比較デモを予定していました。1080iの標準的撮影は1440x1150の1080i標準ビデオカメラによる撮影結果を1920x1080の映像計算しなおし(アップスケール)、それをスダレのような偶数奇数フィールドに振り分け送出するという方式を取っていました(現在デジタルハイビジョン放送の標準撮影方法です。)。そして同じ映像1280x720の720p標準カメラ撮影しD5デッキに録画した映像をそのまま720pで再生するというデモ内容でした。映像再生には当時の最高品質CRTスタジオモニター(8000ドルクラスSONY製品を2台)をマイクロソフトの展示会場に用意しておりました。比較展示用デモ映像は同じスタジオ環境撮影した1080iと720pのそれぞれの映像データをお持ちの松下電器産業殿からD5の録画テープをお借りして、初日デモへ向けて全ての設営と映像チェックが終わった時のことです。某放送局の方が、マイクロソフトブース垣間見るや、とても渋い顔をしておられます

私は夕方の6時過ぎに会場の設営も終わり、ホテルに戻ろうとしていたところ、松下殿から緊急の連絡が入り、展示に使っていたビデオテープを持って松下殿の技術担当役員ホテルの部屋まで来て欲しいとのこと..部屋に入るとその役員さんは、ベッドの上にあぐらをかいて、その両脇には15人を超そうという松下の方々が壁沿いに2列にずらりと並んで座っているではないですか..その姿はまるで、新入りの囚人(私)が牢名主親分に「今日からお世話になります」と仁義を切るのかい、というような雰囲気でありました。

そしてその親分さんが言うには、「そのテープ黙って置いて、帰ってくれ」とのこと..「冗談じゃない、そんなことしたら明日の展示は何も映像が表示できないではないですか?何故そんな唐突な話をこの期に及んでされるのですか」と問いただしたところ、松下マイクロソフトに協力して720pを推進するのはけしからんと、某放送からお叱りを受けたと..それだけでも絶句出来事なのに…「とにかく松下から映像を貸し出すなどとんでもない..即効撤収してくるように」との具体的な命令を受け私は必至に食い下がり、「その映像作品は全て松下殿の著作物であり、某放送局に文句を言われる筋のモノでは無いはずです。それを何故ゆえに引き上げなければならないのですか?」と伺えば..「その中のヨーロッパのお城のシーンはARIB加盟各社がテスト映像として皆で利用するために松下が供出したもので、そのテスト映像ARIBの会員でもないマイクロソフト勝手に使うのは如何なものか?」とのこと..私はさらに一歩も引かず交渉を続け…もしそれが現実になるのなら「明日の朝は急遽説明パネルを書いて、某放送局の名前実名で明らかにした上で、この名前会社の不当な介入でマイクロソフトでは展示ができなくなりました」と張り出しますよとまで迫りましたが担当役員は首を立てに振りません。最期に私は「判りましたこテープはここに置いて行きますが、夜中に誰かにまれたということにして私が犯人になりますから..盗難届けを出してください!!それでは如何でしょうか?」と交渉は3時間を越える押し問答となりました。

その結果最後に明らかにされた背景は、某放送局の方から松下役員に語られた厳しい言葉でした。それは、「君、僕らは今年50億円くらい君の会社からモノ買う予定だよねぇ、そんな態度でいると、50億円のビジネス失うことになるよ、君ぃ!! それでも良いのだね!!!」というもので、担当役員は縮み上がってしまったのだそうです。技術担当役員マイクロソフトの展示に協力をした結果、50億円のビジネスを失うことになったら営業担当役員との軋轢を生むことは必至であり、そこまでのリスクを負ってまでビデオテープマイクロソフトに貸し出すわけにはいかないとの判断、私はビジネス交渉でこんなに困り果てたことは一生に何度も無いというぐらい意気消沈しきっておりました。

10時にならんとするタイミングで、日本からシアトル経由でラスベガスに到着後、時差から回復する間も無く会場の設営を手伝っていた私はもうダウン寸前…そこで思いついた解決策は「判りました、このテープはお返ししましょう。その代わり今から新規撮影を開始しまから必要な機材と人を朝まで貸してください」と何とも無謀な提案を申し出たのでした。 NABのメイン会場からマイクロソフトの借りていたヒルトンホテルの部屋まで、HDカメラ(当時は100kg以上あったと思います)とD5のデッキを担いで深夜に部屋へ持ち込みスイッチャーや編集機もないままイッパツ撮りでデモ映像を仕上げなければなりません。私はそれまでにいくつかの放送スタジオ見学に行ったことはあるものの、映像プロデュースも撮影も全くのシロウトですので、カメラライティング撮影オペレーションに付き合ってくれる人たち3人ほどに朝まで付き合ってもらいました。

途方に暮れて困ったことは、深夜の12時にラスベガスホテル撮影できる生素材など有りはしないのです。それも著作権肖像権侵害せず、HD映像の違いが際立って表現できる素材、なおかつ1080iより720pの方が綺麗に見えるという素材(多くは、風にそよぐ木々とか波打つ水面、キックされたサッカーボールなんてものが使われるのですが..残された時間日中ロケハンに出かけることもできず、全てはラスベガスヒルトンの部屋で深夜、朝までの6時間以内に解決しなければなりません。

まず、深夜のルームサービス果物の盛り込みを頼みました。そしてその果物の表面に霧を吹いて光るリンゴの表面に張り付く水滴なんてもの撮影しました。本格的なスタジオと違って光の回り方も映像モニタを視ても、思ったような映像にはなりません。

夜も更けて3時を廻り4時にならんとした頃でしょうか、雑誌カラーグラビアをメクりながら、この際著作権の許諾を無視して雑誌に写っている写真撮影してしまおうか?こんな深夜にマトモに著作権の許諾などできる素材など有りはしないし、と途方に暮れていたところ、あるアイディアが湧き出てきました。「そうだ、ドル紙幣撮影すれば手彫りのエッチング表現された人間の顔やお札の文様HD撮影すればビックリするほど細かい映像として撮影対象になるに違いない、誰でもそのパターンが何か理解できるはずだし、何よりもお札の縦横無尽に走っているストライプが際立って720pと1080iの違いを引き立ててくれるに違いない」と確信するに至ったのです。ドル紙幣ビデオ撮影しても肖像権著作権を主張する人もあるまい、という点が一番大事ポイントだったのです。

壁に貼り付けた50ドル札(私の持っていたピン札はそれしかなかったので)にバッチリライティングを施し、撮影した結果は「キタキタキターッ」という感じ!!カメラパンして右へ左へ振りながらお札の表面を舐めるように撮影した720pの映像は細かい線の1本1本を明確に表示して、1080iの映像は実に見事にモアレ縞が出まくり画面にチリチリと汚い映像が糸を引きます。これでこの映像をそれぞれディスプレィに表示した上で、 Permalink | 記事への反応(0) | 11:32

2015-12-30

Excelが最強格闘技である

今、ちょうどExcelを使っている所でこれを書いている。

何故書いているかというと、XMLデータインポートを待っているからだ。

若い時は、Excelで全てをこなそうとする日系企業、はたまたドメ会社を心の底からバカにしていたのだが、年月が経ち、結果としてExcel最強説を私めが、提唱させていただきたい。

Excelが嫌いだった理由は、1 ダサい 2 ダサい 3 ダサい 4 経理じゃないんだから 5 これだけ洗練された仕組みがあるのにExcel使ってるの? 6 ダサい 7 重い

…などなどの理由である

昔の自分へ、反駁を試みたい。

Excelの素晴らしい所

・大抵の会社と人が使っている (若しくは互換性のある仕組みを使っている)

大学研究室であれば、実験的なものを使うことでもよかろう。しか社会はそうなっていないのだ。近所の八百屋も取り敢えず使い方は分からないまでも、Excelが入っているものなのだ

これは大きい。

逆に言うと、これだけ日本で浸透しているからこそ、ダサいとも言えるのだが。

Excel方眼紙

よくExcel方眼紙否定論者を見かける。こういう奴らは、Excel方眼紙の利点を理解していない。Wordでやってみろ。計算スムースに出来ないではないか。結果Excelで良いのである

・もはや表計算ソフトではなく、Officeのものである

Excel否定論者は、否定したいがあまり過去Excelイメージしか持っていない。実際長いこと使っていると、Excel表計算ではなく簡易的なデータベースとして大きく進化していたり、フォーマットの違うファイルを取り敢えず一回Excelに入れて吐き出しをさせるなど、文字列の扱いが遥かに得意になっていることに驚きを禁じ得ない。

VBAや数式など

以前はマクロ信者をただの狂信者だと思っていた。今でも一部はそうである。なぜならマクロ信者や数式教徒は、可読性を一切考えないオナニーしかしないからである

しかし中級程度まで熟達すると、多くのオフィスワーカーを不要にしてしまうすぐれものである

そろそろ30M程度のXML直感的に操作するためにインポートも終わる。もちろんこれだけ言ってもExcelダサいダサいがゆえに枯れている素晴らしい仕組みなのである

#加筆

しかし、逆に汎用的なツールになってきた事で、かなり重くなりつつあり、複雑な事をしないものGoogleスプレッドシート最近移管した。色々難しいもんである

ログイン ユーザー登録
ようこそ ゲスト さん