「データソース」を含む日記 RSS

はてなキーワード: データソースとは

2018-10-29

anond:20181029072313

チェックを二重三重することの大事さをわかった上でだけど、

・数値を手入力した時に誤って入力した

そこは電卓引っ張り出す前に入力値の方をまずダブルチェックなさいな。

・誤った計算式を設定した(されていた)

そんなに誤り許されないんだったらそのExcelファイルが徹底的にテストされるようにした方が良いんじゃないかな。

そんなに他の人の作業時間を浪費させるExcelファイルがあるとして、専属保守要員がいないのはちと問題な気がする。

もし、作業員の誰かの入力ミスとかで勝手計算式変えられちゃう、みたいな事例が発生しているようならもう運用フロー自体が間違ってると思うよ。


データソースが外部サービスとき、外部サービスの方に誤りがあった

可能性の話で言うなら「Excel自体バグ」と同じように杞憂で済ませらるようにも思うけど。

Excel自体バグ(ほぼゼロ)

いっそExcel使うの止めた方が良いんでは。

システム化とか、そっちの方にお金時間使うべきフェーズになっていないか検証すべき現場は多いように思う。

木こりジレンマ」ってやつに陥ってるタイプ

Excelの内容を電卓検算

これ、定期的に話題になって、いつでも意味ない派が大多数なんだけど、意味あるケースも多々あるから

まず、Excelの内容が正しくない場合がある理由は多岐にわたる。

・数値を手入力した時に誤って入力した

・誤った計算式を設定した(されていた)

データソースが外部サービスとき、外部サービスの方に誤りがあった

Excel自体バグ(ほぼゼロ)

など。

で、誤りの検知方法なんだけど、ざっと見ればわかるはずとか、眺めればわかるはずとか言ってる人が多数だけど、それじゃ見落としのリスクが高いから。

文章だって、一字一句確認しながら読んでも誤りを見逃すことが結構ある。だから校閲という職種存在するんだね。

電卓でチェックというのは、そういう誤り検出のメソッドの一つ。

電卓で再計算し直すという方法は、以下のメリットがある。

・チェックのカバー率が常に100%(文章で言えば、一字一句飛ばさずにチェックするのと同じ)

・実際に数字入力すると、入力間違いに気付きやすい(場合がある)

計算式が間違っているときは、ほぼ100%誤りを見つけられる

2018-08-05

anond:20180804215900

言葉説明したり、事実なんだから言うまでもないとか、そういうことで事実根拠を示したり示されたりすることで十分な日常の人には無縁だと思うので必要ない人とあなたには必要ないとおもうしこれからも撮らなくてもいい

ただ現実にはどうか実際はどうだったか客観的にみて第三者からみて記録を遡るとなどしてもう一度確認して次の行動や現在評価をしたいひとには撮らざるをえない

自分記憶けが絶対であるはいいきれないし次回の判断にその前提を確実に生かしたいし次によりよいものを得ようと努力をしたい比較をして「前例としてあったわ」という感情のおこることを避けたいというとき撮影など記録をする

いつでもなにを見てもその日にあるものは依然のそれとは違うのだから新しい今日のそれ(前と同じもの)を楽しめるというのならば記憶も記録もないほうが楽しめるだろうとは思う

ただ私個人はそういうところについて、記録があり前例比較もしたいし共有することで選択肢の幅をひろげたい

それだけの差でしょう

あとそれについて同意をもとめたり数量的に多い少ないで良い悪いを決めることでもないと思うのでその共感をなんのデータソースもなしに(記録もなしに)求める事について容易さを感じているのだとしたら記録を参照したい側からすれば勘違いではないかと思う

2018-05-04

[]2018年5月3日木曜日増田

時間記事文字数文字数平均文字数中央値
005611385203.379.5
0161465176.243
02283477124.256.5
03294545156.736
04176071357.164
05155744382.9128
06304886162.965.5
07374608124.552
08626410103.440.5
0973563377.242
1070656393.852
11101792578.535
121061011795.442
13140961068.633
14137756555.235
15114666658.532.5
1612113028107.739
178812250139.242
181401141781.634
191601534495.926.5
2011612046103.833.5
21153865956.631
221631331081.735
23617475122.551
1日207819938596.037

頻出名詞

人(198), 自分(132), 女性(82), 今(79), 増田(76), 差別(71), 女(71), 人間(71), 話(70), 仕事(68), 男(66), 男性(60), 感じ(57), 相手(55), 社会(54), 問題(53), 同じ(51), 日本(51), ー(50), 必要(49), 気持ち(49), 意味(49), 前(46), あと(45), 普通(44), 関係(43), 親(42), 時間(41), 会社(40), こんな(40), 子供(40), 好き(39), 気(38), 目(36), 低能(35), 山口(35), 言葉(34), 被害(34), 存在(34), 今日(34), 結婚(33), 生活(32), 友達(31), 他(30), 最近(30), 手(29), 主義(29), https(28), 行動(28), メンバー(28), 安倍(28), 男女(28), 発言(28), 一緒(27), 頭(27), 心(26), 時代(26), 家(26), 専用(25), 意見(25), 自身(25), 理由(25), 人生(25), 車両(25), おっさん(24), 状態(24), ネット(24), 先生(23), 金(23), 現実(23), 周り(23), 場合(22), 結果(22), 世界(22), 責任(22), 娘(22), 自己(22), 別(21), 最初(21), 他人(21), 自体(21), ダメ(21), い(21), 全部(21), 大変(21), レベル(21), 可能(20), ~(20), アニメ(20), 女子(20), 昔(20), 否定(20), 馬鹿(20), 理解(20), 個人(20), 自民党(19), 嫌(19), 逆(19), 一番(19), http(19)

頻出固有名詞

増田(76), 日本(51), 山口(35), 安倍(28), 自民党(19), 日(18), 東京(14), キモ(14), TOKIO(14), 自衛隊(12), アメリカ(8), 達也(8), 加計(7), 民主党(7), カス(6), 平成(6), 公明党(6), 昭和(6), 福島(6), JK(5), 共産党(5), 韓国(5), 羽生(5), スキ(5), 柳瀬(5), 中国(5), 晋(5), 大阪(5), マック(5), ぇ(5), 敬之(4), 愛媛(4), faq(4), チャイルド(4), 麻生(4), 京都(4), テレビ朝日(4), NHK(4), qa(4), ニセ(4), iPhone(3), 所(3), gt(3), CPU(3), 太郎(3), bot(3), 悟(3), フジテレビ(3), 出口(3), 健(3)

MeCabNAIST辞書 (2011年に更新が止まっている。)

MeCabmecab-ipadic-NEologd辞書 (固有名詞新語に強い。正確に形態素に分割することよりも意味のある単語としてまとめることに重点が置かれている。)

頻出名詞

人(184), 自分(125), 今(75), 話(68), 男(66), 女(66), 仕事(66), 増田(66), 人間(63), 女性(62), 感じ(55), 相手(51), 問題(51), 必要(49), 気持ち(48), あと(47), 意味(45), 差別(44), 前(44), 日本(43), 気(40), 子供(39), 普通(39), 男性(38), 目(37), 親(37), 関係(36), 低能(35), 好き(35), 社会(35), 今日(34), 会社(32), ー(32), 言葉(32), 友達(31), 存在(31), 結婚(31), 最近(30), 手(30), 他(30), https(29), 頭(28), 時間(27), 心(27), 理由(25), 意見(25), 現実(25), 人生(25), おっさん(24), 別(24), 被害者(23), 状態(23), 周り(23), しない(23), じゃなくて(23), 発言(22), 家(22), 場合(22), 金(22), 女性専用車両(22), 行動(22), 最初(21), 理解(21), 他人(21), 結果(21), A(21), 全部(21), 娘(21), レベル(21), 世界(21), 自体(20), 馬鹿(20), 先生(20), 男女(20), 勝手(20), 昔(20), 生活(20), アニメ(20), 嫌(20), ダメ(20), 否定(20), 逆(19), www(19), 批判(19), 顔(19), 大変(19), 一番(19), 誰か(19), 男性差別(19), 職場(19), 女の子(19), 一緒(19), 結局(18), 話題(18), http://(18), 時代(18), 記事(18), 無理(18), 自身(17), 山口(17)

頻出固有名詞

増田(66), 日本(43), じゃなくて(23), 被害者(23), 女性専用車両(22), 娘(20), 男性差別(19), 山口(17), 安倍(15), TOKIO(15), 可能性(14), 安倍総理(14), なんだろう(14), いない(13), 自民党(12), 自衛隊(12), 主義者(12), スマホ(12), A(11), 山口メンバー(11), 生活保護(11), hatena(11), カス(11), 元増田(11), 差別主義(10), いいんじゃない(10), 一緒に(10), Twitter(10), 男女平等(9), 女子高生(9), 1人(9), 2人(8), PC(8), ブログ(8), s(8), 上の(8), JK(8), 社交辞令(8), わからん(8), B(8), …。(7), リアル(7), 犯罪者(7), ツイッター(7), 一方的(7), ニセ科学(7), 劣等感(7), コミュ障(7), キモ(7), 私たち(7), ジャニーズ(7), キモい(7), ネット右翼(7), まんこ(6), ブコメ(6), 2018年(6), 普通に(6), 東京(6), 20代(6), 山口達也(6), 昭和(6), 何度(6), 社会人(6), ???(6), 公明党(6), 発言権(6), アメリカ(6), 毒親(6), 加計学園(6), 100%(6), 個人的(6), パワハラ(6), 基本的(6), 最終的(6), 笑(5), かな(5), 加害者(5), 1年(5), にも(5), 共産党(5), なのか(5), GW(5), 悪いこと(5), 外国人(5), 非モテ(5), いいね(5), 強制わいせつ(5), 自己責任(5), 脳内(5), 安倍自民党(5), 低所得(5), キチガイ(5), 人として(5), ー(5), フェミ(5), マジで(5), イケメン(5), 想像力(5), ニート(5), 婚活(5)

例えば「女性」と「専用」と「車両」に分割されていたのが「女性専用車両」で1語と数えられている。辞書データソースとしてはてなキーワードを使ったと書いてあるからよりはてな向きかもしれない。

いいんじゃない」が固有名詞扱いされているが、これは多分はてなキーワードソースにした弊害ではないだろうか。はてなキーワードを見ると「いいんじゃない」というジャニーズタレント楽曲があるという。「リアル」もはてなキーワード三菱テレビブランドとして説明されているせいで固有名詞扱いなのかもしれない。

一長一短があるな。

2018-04-03

高校生自己肯定感自己有用感)

高校生自己肯定感が低い、というニュースhttps://www3.nhk.or.jp/news/html/20180403/k10011388681000.html)をいくら読んでも、近年低く「なってきた」というデータソースは見あたらない。なのに記事結論は「国立青少年教育振興機構は「集団生活体験が減って、他人評価を気にする若者が多くなっていることが原因ではないか」と話しています。」……こういう記事を誰が信用するのか?

そして、冷静に考えて欲しい。いったい、いつ日本人の「自己肯定感」が高かったか、を。

2017-05-12

製造業新卒で入って数年経過したけどもうダメかもしれない

新卒製造業に入った。

大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。

悪く言えば自分能力絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。

相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。

無駄が多いという感想は本配属後も変わらなかった。

本来業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。

せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。

プログラミング経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドVBAから、Rやら自社製品の解析用環境の割と珍しいタイプスクリプト言語など(特定されそうだからぼかすけど。)

とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手作ってみたりして提案していた。

物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。

この辺で気付いたことだが、製造業ITリテラシーは驚くほど低い。製造業一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。

なんせまともにプログラムを書いたことが無い新人半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。

ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。

(そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。)

2年目に気付いたのは、弊社エンジニアITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。

製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。

無骨だが使いやすイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。

から逆に言えば下々の人間コピペでなんとか恰好を整えられるのだった。

彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。

私はそれに感動した。なんせWebスクレイピングみたいな方法他人が社内プラットフォーム社内WIKIに上げた報告をまとめたり、製造データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。

それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。

何にせよそういったもの一気通貫自動化できるポテンシャルがあると感じられた。

SQLjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しか管理IT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

ところがその「ビッグデータプロジェクト人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)

自分ドメイン知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。

具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果確認の為に数十億行のデータ活用された。彼らの力が無ければ常識的時間では終わらなかった仕事だった。

残念だったのは彼らの優秀さの割に一般エンジニアスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。

そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。

このころ私は入社3年目に突入していたが、

もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。

そういう時に起ることは不要冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署相手側にも存在するということだ。

まりどちらにもある部署統合するか一方を無くすかという戦争が始まるのだ。IT例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)

一方で製造業の本懐である製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存顧客への説明必要からだ。

そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか

(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)

今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である

旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフ簡単に表示され、A社側のお偉いさんからも好評を得ていた。

だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。

そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉

増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」

もちろんhtmljavascriptphpRoRも一行も書いたことが無いのが当時の私である

果たして旧A社のプラットフォームはB社のプラットフォームデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。

そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。

クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベル筆舌に尽くしがたいものがあるが、

反面教師だと思って耐える日々だ。

最近分かったことは旧B社のバックエンドスクリプトデータを引っ張るついでに意図的に旧A社のプラットフォーム攻撃しているということだ。DDoSとまでは言わないが、悪意100%である

いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォーム不安定かつ重くなることを意図しているらしい)

旧A社から継続されてる業務はまだそこ使ってるんですけど・・・

それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。

旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングレベルが二回りぐらい違うように見える)

この不毛な戦いはいつ終わるのだろう・・・つらい・・・

そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。

そもそも私はエンジニアなのだろうか・・・少なくとも職位にはそう書いてあるけど・・・

2017-05-06

http://anond.hatelabo.jp/20170506063750

少なくとも日本語CDユーザ側が多くを入力してた

さらに当時のGracenoteのFAQらしきもの引用

C 買ってきたばかりのCDPC音楽ソフトウエアに読み込ませても、タイトル情報が表示されません。新譜CDはいつごろから情報を取得できるようになるのでしょうか?

新譜CDによってデータベース登録されるタイミングにばらつきがありますCDによって、発売日前でも情報を取得することが可能ですし、発売から一週間経ってもデータが取得できない場合もあります世界最大の音楽情報データベースであるGracenote Media Database(CDDB)は、インディーズ盤、非売品、語学CD輸入盤等のあらゆる音声CD対象としているため、データソースの一部は、ユーザーサブミッション依存しており、データ標準化処理作業時間を要するためです。また、CDを発売するレコード会社登録できるように、レコード会社向けのデータ登録管理用のプログラムを用意しており、これをお使いのレコード会社新譜CDついては、CDの発売日には情報取得ができるようになっています

の中の一文

世界最大の音楽情報データベースであるGracenote Media Database(CDDB)は、インディーズ盤、非売品、語学CD輸入盤等のあらゆる音声CD対象としているため、データソースの一部は、ユーザーサブミッション依存しており、データ標準化処理作業時間を要するためです。

根拠とし、

さらには

新譜CDによってデータベース登録されるタイミングにばらつきがありますCDによって、発売日前でも情報を取得することが可能です

CDを発売するレコード会社登録できるように、レコード会社向けのデータ登録管理用のプログラムを用意しており

無視して、

CDDBデータベースは、ほぼ、ボランティア(各ユーザー新譜を入手して、入力した情報シェアする)方式だったはずだ。

事実だと結論付けるには根拠に乏しく、論理の飛躍が見られる。

営利サービスCDDBを含めてすべてのCDDBサービスが有志による入力よって成り立つボランティア運営だという悪質なデマを広めないで欲しい

的外れな主張がもっともらしく書かれていてとても不快

http://anond.hatelabo.jp/20170505225416

いやだから昔の話でしょ?

もともとのCDDBは誰でも使えて誰でも登録できるサービスで、運営企業に移ったあともしばらくは、少なくとも日本語CDユーザ側が多くを入力してたよ?

俺も何枚か入力したよ?

2009年時点でも、iTunesタイトルが表示されない増田がごねてるし、その頃のGracenoteのFAQには

http://anond.hatelabo.jp/20090420031928

データソースの一部は、ユーザーサブミッション依存しており

とあった。

2017-05-04

Power BI (無料版) のサービス内容が 2017 年 6 月 1 日に変更されます

今回の更新により、取り扱い可能データ容量の拡大とリフレッシュレートの増加が実現され、またすべてのデータソース制限なくアクセスできるようになりますダッシュボードの共有機能Power BI 無償版ではご利用いただけなくなりますが、Power BI Pro では引き続きご利用いただけます

なお、Power BI Pro 試用版は、試用期間が延長され、2017 年 6 月 1 日から 2018 年 5 月 31 日までご利用いただけるようになりました。ぜひご興味のある方は 2017 年 6 月 1 日以降、通常どおりにサインインするだけでお試しいただけますので、ご検討ください。Power BI Pro の詳細については、こちらまでお問い合わせください。 ぜひ、Power BI のご利用をこの機会にご検討ください。何卒、よろしくお願いいたします。

チーム

Microsoft Power BI



https://view.email.microsoftemail.com/?qs=dfa1f8d87fa9b4c98d92aab8f53a9a11a1b4be5f21e34d637e497df82429c0d5c69b54f89c65014b2f176b5a9e91f9f53c02cbc3264f0f10946b8ec4d1d2cd0cdca29cde607807664bc2be2684e5d32c

2016-03-24

東京アニメアワードフェスティバル2016に関連しそうでしない話

話題になってるね東京アニメアワードフェスティバル(TAAF)2016。

いま来た人でどれくらいバタバタしてるか知りたい人は、PDFを読むと良い。

http://www.shortfilmdepot.com/en/home/accueil/affichereglement/nIdSection_PM/253/nNumLangue_PM/2/idFestival/66/file/Tokyo_Anime_Award_Festival_Short_Animation_F_%E6%9D%B1%E4%BA%AC%E3%82%A2%E3%83%8B%E3%83%A1%E3%82%A2%E3%83%AF%E3%83%BC%E3%83%89%E3%83%95%E3%82%A7%E3%82%B9%E3%83%86%E3%82%A3%E3%83%90%E3%83%AB%E3%80%80%E7%9F%AD%E7%B7%A8%E9%83%A8%E9%96%80

短編アニメーションの応募要項という重大な文書にもかかわらず、8ページ目にしれっと「長編アニメーショングランプリ」とか誤字があるわけですよ。

(流石に英語の3ページ目はちゃんと TAAF2016 International Short Animation Grand Prizeとなってる)

まり、そういうミスをするような組織体であるというのは、まあ最初から判ってたわけです。

一般的一般社団法人の話

一般社団法人日本動画協会にはあんまり関係ないんだけど、一般論として一般社団法人には色々あります

ちゃんとしたところ、いいかげんなところ、ちょっとどうかと思うところ、色々です。

で、重要なところなんですが、一般社団法人って、公益法人じゃないし株式会社じゃないし、役所でもないわけです。

割と立ち位置中途半端なこともあって、良い意味でも悪い意味でもユルイことが多いわけですね。

例えば、お役所はこういう文章を出しません

実行委員会との連携や、長編及び短編審査、招待作品選定等、極めて順調に準備が進んでいます

江口氏のディレクターの解任による不利益不都合は一切ありません。

江口美都絵氏(東京アニメアワードフェスティバル・元フェスティバルディレクター)に対する刑事告訴・民事裁判に関する御報告 (2016/2/15 付発表文に対し、第8項を追加発表) | 日本動画協会

「極めて順調に」とか「不都合は一切ありません」とか、お役所は書かないのです。

役所文書口約束ではなく文書)は、広い意味公正証書と呼ばれてて、ちょっと特殊な扱いになるからです。

民事訴訟法228条あたりを読むとわかるよ。普通公文書と呼ぶよね)

なんで書かないかというと、こういうことになった時に、結構マズイ&面倒なことになるから

shortfilmdepot.com の本年度の登録者エントリー手続が行えなかった作品につきましては、TAAF事務局は、来年度開催予定のTAAF2017に対しても応募受付可能とする措置をとり、shortfilmdepot.comの運営者と協議を行い、登録者に対して告知を行います

TAAF2016 「コンペティション部門短編アニメーション」ノミネート全作品発表! | 東京アニメアワードフェスティバル2016

  1. 解任で不利益不都合一切ない
  2. shortfilmdepot.comには登録したけど、TAAF公式サイトを通じてエントリーしなかった人のは、来年

役所文章はこういう「1番の解任で問題ないって書いてる以上、2番の問題は解任された人とは無関係だよね」という言質をとらせないようになってます

念の為補足すると、1番を書いて無ければ「揉めたの契約解除した委託先に妨害されたからだから、そっちに損害賠償してね」って出来た)

請求 or 訴訟 万能主義

まあ、これもお役所仕事とかの典型ではあるので一般論として聞いて欲しいんだけども、

世の中には「言えばまあ通るんじゃないかな」的な勢いでイイカゲンな事をしてくるところがワリとあります

仕事発注して仕事が動き出してから「やっぱあれキャンセルね、一銭も払わないからだってキャンセルだし」みたいな。

役所不思議時間間隔で動いてるので、お金なかなか払ってくれなかったり、微妙に話がなくなったりします。

書類になってるとちゃんと守ってくれるし、イイカゲンなことは書かないんだけどね。

(なので、役所のひとに無茶言われた時は、文書請求してくれって返すと大抵お金払ってくれる)

と、同様に、なんかこう、訴訟すれば自動的に通ると思ってるひとも結構ます

まあ訴訟慣れも嫌なモンだけど、メンドウ嫌がるひと多いからね。

TAAF2016とは何の関係もない一般論だけど、例えば

  1. クラウド管理を任されててアカウント持ってる
  2. 突然のクビ!
  3. 「お前しか管理者居なかったから引継でデータよこしたり仕事しろ

となったとき、「じゃあ確認訴訟するかあ」とはならないことが多い。

雇用契約上の地位確認→クビじゃねえよな→和解金貰って辞めるのパターン

まんま泣き寝入りなんだけど、まあメンドウだからね。

これもまあ一般論なんだけど、

クビにはされましたが邪魔しました、だと負けるけど、

クビは無効ですノータッチです、だと勝てることが多いよね。弁護士忠告しないのか。

東京アニメアワード 357件

ここまで読んでくれた人にちょっと良いことを教えるけど、

東京アニメアワード 357件」でググった時に出てくるサイトあるよね。

はい、それが転載可能なリストです。

まりウラドリしない」「独自ソース持たない」「主張を転記してくれる」美味しいサイト群。

ちょっと説明すると、TAAF2016の短編応募はこんな状況でしたってのがTAAF2016サイトで公開されてる

コンペティション部門短編アニメーションの応募総数は、インターネット上の応募受付サイトである shortfilmdepot.com への登録者で、TAAF公式サイトを通じて自らエントリー手続を行った方々の173作品を含む522作品でした。

shortfilmdepot.com の本年度の登録者エントリー手続が行えなかった作品につきましては、TAAF事務局は、来年度開催予定のTAAF2017に対しても応募受付可能とする措置をとり、shortfilmdepot.comの運営者と協議を行い、登録者に対して告知を行います

TAAF2016 「コンペティション部門短編アニメーション」ノミネート全作品発表! | 東京アニメアワードフェスティバル2016

わかりにくいんだけど、

  1. 全部で522作品
  2. TAAF公式サイトに直接作品を持ち込んだのが、173作品
  3. shortfilmdepot.comに作品投稿したけど、直接TAAF公式サイトに来なかったひと(522-173=)349作品
  4. 3番の人は、来年のTAAF2017でも受け付けるよ。

というわけで、349作品が(理由不明だけど)来年受付になるよ、と書いてある。

というわけで、いま357件って書いてるところは、ちゃんとしたデータソース別に持ってないんじゃないかなあ。

(なお、530件-173件=357件になる。530件っていうのはおたぽるが役所にヒアリングした時の数字だね)

こういう時、慎重さに差がでるから、良く観察したほうが良いよ(誰がとは言わないけど)

ゆる~く書いてるように見えるのに、確認が取れた数字しか載せないところは、やっぱ揉まれてんなあという感じ。

東京アニメアワードフェスティバル、大量の未審査作品を発生させたまま終了… | 東京都議会議員 おときた駿 公式サイト

まとめ

カクヨム増田のイチジャンルをとられるのはちょっと悔しいよね

2015-08-18

http://anond.hatelabo.jp/20150818134020

そんな自明なことにいちいちデータデータソースソース言い立てるから実際に動画広告なんてやっちゃうんだろうなーってよく分かる流れ。

2014-12-15

MS SQL SERVER 接続アドレス ポートインスタンス指定する記述

MICROSOFT SQLSERVER で、データソース接続先)が名前付きインスタンスでかつ既定と異なるポートを使用している場合に、クライアント接続先を指定する書き方。

COMPUTERNAME¥INSTANCENAME,PORTNUMBER

例 MYSERVER1¥SQLEXPRESS,1500

エンマークはもちろん実際には半角で。

2014-10-22

http://anond.hatelabo.jp/20141022112101

分からんのか? 料理の味というものが素材や調理によってではなく「食べた時の状況」やらの再現不能なクオリア的なモノによっても支配されているように、声優の演技とやらも、同じデータソースでも「聞いた人」「聞いた状況」「聞いた環境」によりエクスペリメントが異なってくるってことなんだよ。

全ては妖怪のせいなんだけどね。

2014-06-29

http://anond.hatelabo.jp/20140629123018

ADHDが知能的に健常者に勝るっていう統計存在しないだろ。

統計云々はいからデータソースもってこいよ。

俺もADHDだがな、俺たちはただのゴミだよ。資本主義社会ゴミ

認めてもらおうと思うなら、頭下げて謙って努力する以外に手はねーよ。

無能ADHDが「〆切は守れませんが頭はガチでいいんです」なんて

ふざけた主張するたびにこっちの肩身も狭くなるからやめろ。

俺たちはシンプルに劣ってるんだよ、それだけの話だ。

ADHD特質を丸ごと受け容れて貰おうなんてのは諦めろ。

2012-11-06

iPhone5の予約日と入荷日の関係についてグラフ作成した。

iPhone5の予約日と入荷日の関係についてグラフ作成した。データソースとしては、【16GB&32GB専用】iPhone5入荷連絡待機所1-7

http://logsoku.com/thread/anago.2ch.net/iPhone/1349596183/

を使った。総データ数961。

こちらがグラフ

http://t.co/hv4gQkQx

丸の面積が人数を表す。だいたい峠は越えたようだが、まだすぐ入荷するかんじでもない。

スレ記述にブレがあるので、それを直すのにけっこう時間をかけてしまった。

いまさらではあるがけっこう有益情報ではないだろうか。

だが、これをブログに載せると遊んでいるとしか思えないので、増田に載せる。

2011-10-18

Steve Yegge の Googleプラットフォームに関するぶっちゃけ話を訳した(前編)

Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす
http://japan.internet.com/busnews/20111013/8.html

記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。

2011/10/19 08:14)ありがたい誤訳の指摘をいただいたので3カ所修正

Stevey の Google プラットフォームぶっちゃけ

僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは(しかもその印象は日々強まるのだけれど)、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやもうとにかくね。百、いや二百のポイントで二つの会社比較することが出来るだろうけど、僕が正しく覚えていれば、 Google はそのうち三つを除いて優れている。実にある一点に関してはスプレッドシートを書いたんだけど、法務が外に出すなって言うんだ。リクルーティングは惚れ込んだみたいだけどね。

まり、まあ簡単に言えば、 Amazon の人事採用プロセスってのは基本的に欠陥品なんだ。だって、チームがチーム毎に、自分達のために人を採用するんだぜ。だから、色々平均化の努力はしてるみたいだけど、採用基準はチームによって信じられないくらいバラバラさ。そんでもって作業工程ってのも腐ってる。ソフトウェア信頼性工学なんてお呼びじゃないし、エンジニアに何でもやらせようとするんだ。コーディングする時間もないくらい。もちろんこれもチーム毎にバラバラで、要するに、運次第ってところ。施しやら困った人を助けるのやら、コミュニティに貢献するのやら、そんなのはもってのほかバカにしに行くんでもなけりゃ、近寄るべきじゃないね。それにまた施設も染みだらけの壁に囲まれた箱みたいな家畜場で、装飾やらミーティングエリアなんてものには一銭も使ってない。給料やら福利厚生なんてのも最悪だ。まして最近じゃあ Google やら Facebook っていうライバルがいるのにね。社員特典なんてものも見たこと無かったな。採用通知の番号を照合して、ハイ終わり。コードベース悲惨のものエンジニアリング基準ってものがないんだから。チームによっては個別にがんばっていたくらいかな。

公平に言えば、彼らは良いバージョン管理ライブラリシステムを持っていた。これは僕らもまねるべきだし、僕らのところには同様のものが無い、良い pubsub システムもあった。でも多くの部分で彼らが使っていたのは、ステートマシン情報RDBMS に突っ込んだり読み出したりするだけのくそみたいなツールの塊だった。僕らならただでも欲しくないようなね。

僕が思うにその pubsub システムライブラリ管理システムが、まさに AmazonGoogle より優れている三つのうちの二つだ。

早期にリリースして、狂ったようにイテレートするってのも彼らのうまいところじゃないかって言うかもしれない。けど逆もまたしかり。彼らは早期にリリースすることを何にもまして優先する。品質保持やらエンジニアリング規則、その他長い目で見たら重要になってきそうなものはみんな後回し。そんなだからたとえ市場競争相手よりアドバンテージがあったとしても、結局ちょっとしたことをやるのにも問題を起こしちゃうよね。

でも、一つ、そんな政治的な、思想的な、技術的なへまを補うだけの、彼らが本当に本当にうまくやってることがある。

Jeff Bezos悪名高きマイクロマネージャーだ。彼は Amazon の小売りサイトの1ピクセルまで管理する。彼は以前 Larry Tesler を雇った。 Apple主任科学者で、たぶん世界で最も有名で尊敬される HCI エキスパートさ。そんでもって、 Jeff は Larry が言ったことを、 Larry が辞めるまで3年間無視し続けた。 Larry は大規模なユーザビリティ研究もやっただろうし、少しの疑いの余地も無く誰もそのひどいサイト理解できないってことをデモしたに違いない。けれど、 Jeff は1ピクセルたりとも動かさせはしなかった。トップページにぎっちりつまった内容の1ピクセルたりともね。それらはまるで何百万という彼の貴重な子供達なのさ。けれど Larry はそうじゃなかった。

マイクロマネジメントAmazon が僕らよりうまくやっている三つ目ってわけじゃあない。つまり、まあ、彼らはうまくマイクロマネジメントをやっていたと思うけど、それを強みって言いたいわけじゃ無い。まずは何が起こっているかみんなに理解してもらうための文脈を準備しているだけさ。僕らはこれから公衆の面前で、 Amazon で働きたけりゃ私に金を払えと言ってのける男について話すわけだからね。誰かが彼に反対したときは、彼は彼の名前入りの小さな黄色ポストイットを手渡して、誰が会社を動かしているかを常に忘れさせまいとする。思うに彼は全くの… Steve Jobs なのさ。ファッションデザインセンス抜きのね。 Bezos はとんでもなく頭が切れる。誤解しないで欲しい。彼の前じゃ、普通コントロールフリークなんてヤクが極まったヒッピーみたいなもんだよ。

それであるJeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。

彼の巨大な指令はこんな感じだった。

1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータ機能を公開すること。

2)各チームは各々そのインターフェースを通じて通信しなければならない。

3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデルバックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。

4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。

5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界デベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。

6)そうしない者は解雇される。

7)ありがとう!良い一日を!

ハハ!。ここにいる君たち150人ちょっとの元 Amazon 社員ならもちろんすぐにおわかりの通り、7番は僕が付け加えたジョーク。 Bezos は間違いなく君たちの一日なんかに興味ないからね。

それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 Wal(ごにょごにょ)Mart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢インターフェース」という言葉連呼する男だった。 Rick は歩き回り、「堅牢インターフェース」について語り回り、そして言うまでも無く、みんなたくさんの進展をし、 Rick にそれを知らせた。

それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなものインディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。そのほんの一部をちょっぴり挙げると、こんな感じだった。

  • ポケベル通知( pager escalation )はどんどん難しくなった。だってチケットの本当の持ち主がわかるのに、20回は行ったり来たりしないとならなかった。もしあるチームからの一回の応答に15分かかったとしたら、正しいチームがそれを受け取るまでに何時間もかかってしまう。たくさんの前準備と測定としっかりしたレポーティングをやるようになった。

とまあこれらがほんの一例。他にもたくさんの、おそらく何百の、 Amazon が見つけた個別発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。

中編に続く

2010-08-11

伝播過程

細々と投稿していた、当時フォロー&フォロワー1桁だった自分

どうして一夜にして200以上のリツイートをもらったのか、

未だに解せなくて、自分記憶Web上の記録を整理してみる。

(幸運なことに、自分投稿数・フォロワーともに極端に少ないので、

 当該つぶやきの伝播範囲を抽出しやすい状況にもあった。

 せっかくなので、誰もがアクセスできるWeb上の記録などを参照して、伝播過程を分析してみる。)


当該つぶやき投稿は、22時半ごろ。

いつものように、マイペース&ひっそりと投稿

早い時期のRTに気づいたのは、投稿した翌日の午後。

確かまだRTは20前後で、サブカル系とくに東方関係の人たち中心だったと記憶している。

(残念ながら、最初に誰がRTしてくれたのか覚えていない。

 公式の「リツイートされたあなたのツイート」欄に表示されるのは「最新の15人」だけなので、

 伝播過程を正確にたどれず、あやふやな自分記憶に頼らざるをえない。)


その後、同日(投稿翌日)の18時過ぎから、爆発的にRTが増えるんだけど、この辺は、http://twimpact.jp/の記録と一致する。

どうも伝播経路が二つあって、一方はサブカル系へpixiv利用者や腐女子ネットワークを中心に伝播し、

もう一方はデザイナー竹内光司さん(@adesignerjp)やtwicca開発者のAoyama,Tetsuyaさん(@r246)が

恐らく18時半~19時頃にRTしてくれて、クリエイター系にも拡散した模様。

(この二人が目にした伝播経路にもすごく興味があるんだけど、調べようがないんだなあ。)

RTの増加時期は、自分記憶では、投稿翌日の夕方18時台にひとつと、22時台にもうひとつの大波があった。

前者ではとくに、10代から20代のサブカル系が趣味の生徒&学生っぽい人たちが目立ったので、

「こりゃ、帰宅時にtwitter始めた人たちがRTしてくれてんのかな」と、

突然に増えていくRTに目を見張りながら、ボンヤリ考えたのを覚えている。

ちなみに、当該つぶやきをRTするには、そもそも「四時」が自動ポストされることを知っていることが前提だから、

その利用者周辺を中心に拡散するのは道理。

そういうわけで、比較的若年層のサブカル系とクリエイター系に拡散したんじゃないかと、自分は納得している。


ところで、http://twimpact.jp/チャート図(「ReTweetレーダー」)は、

自分アイコンから直接矢印が引かれているもの以外は、ほとんどアテにならない。

アイコンに併記される数字はこれまでRTされた当人の投稿数を示すように、

既存のトータルな影響の流れを図式化したものであって、当該つぶやきのRTとは無関係だからだ。

(そもそも、チャート図に表示されている勝間女史と「四時」の親和性は極めて低いだろうし。

 念のためと、勝間女史の投稿を「もっと見る」でひたすら遡って確認してみたけど、

 やっぱ自分はRTされてなかった。証明完了。)

それゆえ、今まで一度もRTされていない人や非公開の人は、データとして表示されていないし、

恐らくはtwitterの「リツイートボタンを押して拡散した場合公式RT)しか対象としていないようだ。

twitterリストには、非公式RT=RT@ID名と記入した場合でも、カウントに入れて表示してくれるっぽい。) 

だから、RTが87としか表示されていないのだろう。

twitterリストでは、投稿翌日の午後から翌々日の午後までに、227RTあった。

 その後、RT解除または非公式RT投稿を削除されたりしたようで、現在は222で定着した模様。)


もうひとつhttp://retweeter.unicco.in/というサイトでも、伝播過程の分析がある程度可能。

こちらでは、「48 retweets 」があって、「total : 14,637 views」と表示された。

このRTが48という基準がよく分からないけれど、こちらのサイトでは、RTされた時間をたどることができるのがメリット

それと、フォロワーの数を組み合わせて、当該つぶやきを閲覧したであろう人数を概算してくれるのも面白い

(実際のRTは、このサイト予測の5倍弱なので、総閲覧数も変わりそうだけれど、

 でもまあ目安として、数万人規模の閲覧があったというのは、すごく興味深い。)

他方で、デメリットとしては、上述のRTのデータ数が不明なのに加えて、

当該IDの全てのRTがずっと記録されているわけではなく、

「一定期間以上ログを残すのは、100以上のRTに限る」といった制限がされている印象。

(というのも、当該つぶやき以降に、別の自分つぶやき投稿をRTしてくれたフォロワーがいて、

 RT直後にはこのサイトに、自分IDでは2つのRTに関するログが残っていたのに、

 数日を経て今日見たら、ログは当該つぶやきだけ=1つだけに減っていたから。)


他にも、伝播過程の分析としては、

お気に入り」登録してくれた人をたどるというのも一案だけれど、

こちらは公式にデータオープンにされていないだけあって、もっと難しい。

例えば「ふぁぼったー」は、そもそも登録者しかデータとして表示されないっぽいので、ほとんど使えない。

(登録してない人は、自分お気に入りされたかどうか検索することはできても、

 お気に入りした人としてカウントされる=データソースとして反映されることはないっぽい。) 

実際に、当該つぶやきをRTしてくれた人で、なおかつ「お気に入り」登録してくれた人を

twitter上で自分は何人か見つけたけど、「ふぁぼったー」には全く反映されていなかった。


ちなみに、SPSSも今年6月日本語twitter解析ソフトを出している。

http://www.spss.co.jp/campaign/tw.html 

ソフトが手元に無いので上記サイトの記事だけで予測するに、ハッシュタグ付き投稿感性分析メインみたいだし、

とんでもなく高額(学割でも17万円以上!)で、さらさら購入する気になれず。

分析事例を見ると、とくに続編では時系列の変化が内容ごとに分かって、確かに面白そうなんだけどさ。

リンク先に掲載されているハッシュタグを使ったつぶやき分析の2つの例。とくに続編(後者)が秀逸。

http://www.mm-lab.jp/news/12/

http://www.mm-lab.jp/news/63/


以上、自分用のメモに、「そこに山があったから登ってみた」的な、伝播過程の分析。

2009-04-20

http://anond.hatelabo.jp/20090405153659

もう2週間も前の増田記事に対してレスするのもどうかと思ったがインターネット上で誰かがこの記事を検索することを想定して書いておく。

元増田検索したCDDB情報だと本質的な部分が分からない。

一方GracenoteのFAQにこういうのがある。

C 買ってきたばかりのCDPC音楽ソフトウエアに読み込ませても、タイトル情報が表示されません。新譜CDはいつごろから情報を取得できるようになるのでしょうか?

新譜CDによってデータベースに登録されるタイミングにばらつきがあります。CDによって、発売日前でも情報を取得することが可能ですし、発売から一週間経ってもデータが取得できない場合もあります。世界最大の音楽情報データベースであるGracenote Media Database(CDDB)は、インディーズ盤、非売品、語学CD輸入盤等のあらゆる音声CD対象としているため、データソースの一部は、ユーザーサブミッション依存しており、データ標準化処理作業に時間を要するためです。また、CDを発売するレコード会社が登録できるように、レコード会社向けのデータ登録、管理用のプログラムを用意しており、これをお使いのレコード会社新譜CDついては、CDの発売日には情報取得ができるようになっています。

もともとCDDBサービスが始まった頃はユーザーCDを買った人)が自分で取り込んだCDタイトル情報をみんなで共有しようぜというものだった(と思う)。

上記Gracenoteの説明では、大概はCDを売る人がデータベースに登録し、一部がユーザーサイドで登録されることとなっているが、どのくらいの割合でユーザーが登録しているのか分からない。

ただ私自身もタイトル情報未登録のCDがあった際には、自分が登録したタイトル情報CDDBに送信している(但し最近はほとんどその必要はない)。

そして一つ言えることはGracenoteの中の人がひたすら登録作業をすることはあり得ない。

  

結局ユーザーにとっては無料サービスということもあり、曲名が表示されなかったら諦めて自分で打つしかない訳だ。

一方、曲名が表示されたからと行ってそれでよしという訳でもなく、それが正しいかどうかについてざっとでも見る習慣もつけた方が良い。

本気で間違っていることもある。誰のせいかはわからない。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん