「レコード」を含む日記 RSS

はてなキーワード: レコードとは

2019-04-13

anond:20190413102620

これ、ちびまるこちゃんの地元だな

変なおじさん中学生になった永沢君、はまじ、ブー太郎たちにエロレコードをあげてると思うとわかりやす

2019-04-03

Office2016とAccess2019について

現在、弊社では在庫管理Access使用している。

以前は何か独立した装置で行っていて、2000年問題(!)の際にAccessに切り替えたそうだ。

しかし、新しいAccess(弊社ではAccess2016)を使用してMDBファイルAccess2000-2003データベース)の最適化を行った時にレコード消失するバグがあった。

消える量は微々たるものであるが、最適化のたびにランダムデータが消えるのではデータベースとしては役に立たない。

このバグについて調べるにあたって、偶然会社倉庫に眠っていたAccess2007を発見し、それで検証してみたところものすごい量のデータ消失していた。2007環境作業していた人はおかしいと思わなかったのだろうか?(社内でAccessはこの在庫管理しか使っていない)

2016で同様の検証をしてもなかなか消失確認できなかったが、実務上確実にデータが消えていることを時折確認している。これは最新バージョンで解消されているそうだが、会社PCであるのでアップデート適用が随時は行われず、4か月遅れであるようであった。

ただ、4か月遅れとはいえ時折バージョンアップされているにも関わらずバグが解消される気配が全くないまま業務を行っていたのだが、いい加減やってられないのでやむを得ずAccess2019を導入することとした。このあたりについて調べている時、そもそもバージョンアップ内容のアナウンスがかなり複雑に隠されていたり、アナウンスされていなかったりとMicrosoftの不親切さを痛感した数時間だった。

ただし、Access2019にアップグレードたからといってバグが解消される確信はなかった。

私はそもそもMDBなどという古い形式で強行するのはやめたい、システム的にも古い上に個人エンジニアが開発したものであり、古いからではなくそもそもの造りにバグが多く、現在弊社の事業規模に見合ったサポートを受けられていないことからシステムのもの更新して欲しいと上申し続けている。

というか2000人を抱える大企業でこんな古い(しかバグを抱えた)データベースに頼っているってどうなの?

しかしなかなか承認を得られないため、やむをえず応急処置的に最新版である2019を導入することとした。

データベース管理に使っているPCにはボリュームライセンス版のOffice2016がインストールされている。

ここにAccess2016を個別に購入し、インストールしている。

ライセンス的にはOffice2016とAccess2016は別であるが、同じ2016同士なので共存できているようだ。

ここにAccessのみ2019をインストールしてみようとしたが、Office2016がインストールされているためインストールできませんとなってしまった。

以前、別の会社にいた時に2003と2010か何かは共存させた気がするのでできると思っていたが、起動のたびにオンライン認証しているからだろうか。今はもう無理らしい。

そもそもボリュームライセンス版のAccess2019(Office2019)のインストールは非常に面倒くさい。

いわゆるインストーラではなく、コマンドプロンプトからインストールであるGUI環境創造し、推進してきたMicrosoftが、この2019年になってCUIを持ち出してきたのだから驚きだ。

このあたりは調べたらいろいろ有意情報がたくさんでてくるので、そちらを参考にしてもらいたい。

ちなみにConfiguration.xml作成は非常に面倒であるが、Microsoft提供している、質問に答えていくだけで作成してくれるものを使うのが一番楽にできる。

リモートがオンになっているとインストールに支障があるというのも謎だ。

バグに対しても、Office2016とAccess2019の共存についても解決できていないが、もしこの記事を見て何か思い当たる点がある人がいれば連絡をください。

2019-03-26

さよならオトカドール

ファンは読まないほうがいいと思う。

(こんなとこみてる人いないか)

ひたすら愚痴


どうしてこうなった


なぜ日本語がまともに出来ないのにこんな長文を書くに至ったかは、一言で言えば界隈が荒れているから。

荒れているというのはあくま自分主観しかないので、純粋オトカドールを楽しんでいる人は本当に読まないほうがいいと思う。

自分でも書いていて気が滅入りそうになる。

前提として

自分オトカドールアンチではない。

好きだからこそ、素直に楽しめない現状がつらくて、

オトカドールキャラクターを見ただけで嫌悪感をおぼえる自分に腹が立っている。もちろん作品キャラクターに罪はない。

荒れている(と自分が思っている)要因は

お問い合わせメール問題

ファンのもの問題

の二つ

今の界隈がどんな状況なのかはわからないけど、少なくとも自分が無理になったのはこれ。

お問い合わせメール問題


まず、お問い合わせメール問題

ある一部のファン更新公式に促すため週に一回程度、

毎週共通テーマに沿ってファン一人一人が要望を送ろうというもの

しかしこれには

「毎週送るのは流石にどうか」

「送ることによってなにか成果は得られたのか」

「そんなことをするよりも、筐体でプレイするほうが公式には利益になる」

など、どちらかと言えば否定的意見が多かったような気がする。

送る側の主張としては

「たくさん送ったほうが更新再開を望むファンがたくさんいることがわかる」

意見は蓄積され、必ず製作側に伝わる」

彼らの主張には同じコナミから展開されている「ときめきアイドル」の事例が出されることが多い。

ときめきアイドルは、配信開始から一年と経たずサービス終了となってしまったスマホゲー。(直球)

自分プレイしていて、キャラクターは多くないけど、《推し》の色々な姿が見られるのは魅力だった。

VRモード楽曲に惹かれ、もっと彼女たちの活躍を見たいと思っていた矢先のサービス終了通知は本当に悲しかった。

このアプリサービス終了後も遊べるようにしてほしいという声がお客様相談室に寄せられたらしく、結果としてオフラインで遊ぶことができるようアップデートが施された。

恐らく、オトカドールにもお問い合わせによる公式アクションを期待してのものなんだろう。

何らかの形で公式に動いてほしい、という気持ちはとてもよくわかる。

でも、ときめきアイドルのように必ずしも反映されるとは限らないこともわかっている。

自分カスタマーサポートセンターで働いていたことがある。

自分職場では同じようなお問い合わせを同じ人物が何度も送ってきても業務に反映されることはなく、定型文で返すのが常だった。

検討する、とは言うけどもちろんそんなことしない。窓口で終わり。

しろクレームのほうが大事にとってあったりする。

もちろんコナミで働いていたわけではないので実際意見が伝わっているのか、蓄積されているのかどうかはわからないけど、

メール推進派は「必ず」いい方向に向かうと断言している。

本当にそうなんだろうか……そこだけは引っ掛かっている。

ときめきアイドルだって作ったモデルが勿体ないとか、オフライン化が楽だったからお問い合わせがたくさん来た体にしたんじゃないか、くらいゲスパーしてる。

その他の行動


個人的メール推進派に嫌悪感をおぼえるのは彼らのお問い合わせメールに関する行動だけではない。

若手俳優界隈やアイドル界隈のファンたちはライブイベントなど、現地に行かない自称ファンのことを《在宅》や《お茶の間》という蔑称で呼ぶことがある。

このメール推進派はそのような人たちが中心にいる。

筐体で遊ばず、ネットの隅でヘイトを垂れ流し、お前らより愛はある!と純粋ファンたちにマウンティングしてくる。

きっと更新が再開されたら「自分たちがメールを送ったおかげだ!」とドヤるに決まっているし、

仮に終了の告知が出されたら「お前らがメールを送らないから!」と責任を擦り付けてくる。

本当に害悪

また、彼らは「オトカドール同人活動をする層がオトカドールイメージを悪くしている」と壊れたレコードのように繰り返すが、

新規層を取り込む際に障害になっているのはむしろメール推進派をはじめとする《終了おじさん》的な立場の人たちだ。

公式から終了すると発表があったわけでもないのに恣意的なまとめを作り、ファン不安を煽る。

ツイッター上でオトカドールについて検索しようとすると最初候補は「オトカ 終了」なんてこともあった。

本当はファンの皮を被ったアンチなのでは?とすら思う。

また、彼らは同人活動ファン主催イベントにもまるで公式側の人間かのような口出しをする。

公式利益にならない」同人活動を見下しているが、一体何様?

同人活動を何か履き違えているのではないか

人口も筐体も少ないオトカドールにおいてはファンアートなどから存在を知る人も多いはず。

少なくとも「オトカドールは一部の自称ファン創作制限し潰されるジャンル」だとわかるほうが同人活動よりはるか害悪だ。

この問題からファン同士の交流もギスギスしたり、盛り上がる話題愚痴になってしまたこともあり

ジャンルを離れる大きな原因となった。

普通ファン


もう1つの懸念はその《普通ファン》たちについて。

オトカドールプレイ人口は少ないし筐体の設置店舗も少ない。

からこそファン同士の繋がりは強く、また閉鎖的になりやすい。

語彙力マイナスまで振り切ってるのでうまく言えないが、

要は「マイナージャンルに命捧げてる自分を見てくれ!」みたいな人たちが多いような気がする。

原因といってもこっちは完全に私怨

周りはそんなこと思ってない人が大半だと思う。

ファンのせいで界隈が荒れているというのは予め言った通り、あくま主観しかないのでこちらは真面目に読まなくてもいい。

狭い界隈だからこそその界隈の中では猿山大将になれる……つまり承認欲求を満たすための道具にオトカドールが使われている気がしてならない。

ファン同士の交流楽しいし新しい発見もある。

まり多くを語らない作品であるから解釈はたくさんあるし 、モチーフ元ネタから創作できる人たちは本当にすごい。ただ尊敬する。

でも、愛をアピールするためには何をしてもいいのか?

変なことをすればするほど注目を集められると味を占めて、何かとオトカに絡めて暴れる輩がいる。

ぶっちゃけ痛い。

自信を持つことは大切だとは思うが、特殊性癖をドヤ顔で自慢するような痛さで自分は耐えられなかった。

若いファンも多いから、中二病の一部だとは思うけど、成人したファンでも悪ノリに付き合っている今の界隈は正直疲れる。

ファンの中で心配なことはもう1つあって……

男女関係……女性ファンが多いからか、女性ファンワンチャンを狙う男性ファン結構いる。

いや、男女間のことなんて余計なお世話かもしれないが、ファンの年齢層が幅広いからこそ、気を付けなければいけないと思う。

実際被害が出ているという話も風の噂で聞いた。

よくツイッターを見ていれば、未成年女子執拗に絡む成人男性ファンが少数いることはわかると思う。

女性相手にされないかジャンルを去った人がいるということを聞いたときはげんなりしてしまった。

男が全員ワンチャン狙いじゃないとわかってほしいが、自分も警戒されているんだろうと思うと迂闊に話しかけられない。

でも被害に合ってからじゃ遅いから、みんな自分の身は自分で守ってほしい。

自分含め、大人は頑張ってフォローします。

……まあ、特にだって声をあげているファンがいない以上、おかしいのは自分のほうなんだろうけどね。

気にしすぎかな。

さよならオトカドール


昔はどんな形でもオトカドールが続いてくれさえすれば何でもいいと思っていた。

このゲームの魅力は挙げればキリがない。

語り尽くせないくらいこのゲームが好きだった。

でも今はむしろ終わってくれとさえ思う。

きっとオトカドール出会った頃のように純粋に楽しむことはもうできない。

どこの界隈にもこんなような話はあるあるなのかもしれないが、自分は長いことオタクをしていてこんなことはなかった。大きいジャンルだったからかもしれないが。

からファンの行動でここまで作品を好きな気持ちが左右されるとは思わなかった。

こういうことを名前を出して主張すると、

「じゃあやめれば?」

お気持ちヤクザw」

って言われるから今日ここに書いた。

ファンが界隈を変えるなんてどだい無理な話で

から自分が離れる。ただそれだけの話。

吐き出してすっきりするかと思ったけど案外そうでもない。

自分はまだオトカドールオタクとして界隈に存在しているけど、こんなこと考えてるって知れたらあっという間に人は離れていくんだろうな。

それまでの関係だと割りきるしかないけど。

オトカドールは夢だった。

長くて楽しくてとても大好きだった夢。

それなのに今は、筐体の前まで行ってもプレイできないくら重症になってしまった。

でも本当にオトカドールが好きだから

いつかまたプレイできるようになりたい。

から、それまで

2019-03-24

anond:20190324094739

SQLアンチパターンではないが、デッドロックについても投げっぱなしのあのSELECT FOR UPDATEの説明はなんなのかね。

1回のトランザクションでupdateを2回発行する場合と1回のSQL複数行のアップデートをする時はデッドロックリスク考慮するってだけで、かなり初心者にはありがたいと思うんだけどね。

1回のトランザクション複数回update文を投げるケース

tA =# begin;
tA =# update t1 set column = value where id = 1;

tB =# begin;
tB =# update t1 set column = value where id = 2;

tA =# update t1 set column = value where id = 2;
tB =# update t1 set column = value where id = 1;
tB =# ERROR:  デッドロックを検出しました

1回のSQL複数行のアップデート文を発行するケース

tA =# begin;
tA =# update t1 set column = value where id = 1;

tB =# begin;
tB =# update t1 set column = value -- update all record

tA =# update t1 set column = value where id = 2;
tA =# ERROR:  デッドロックを検出しました

あと、先勝ち後負けを実現するのはSELECT FOR UPDATEではなく楽観的ロックな。

tA =# begin;
tA =# select updated_at from t1 where id = 1;
         updated_at         
----------------------------
 2019-03-24 06:17:37.952893

tB =# begin;
tB =# select updated_at from t1 where id = 1;
         updated_at         
----------------------------
 2019-03-24 06:17:37.952893

tA =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0;
UPDATE 1
tB =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0;
UPDATE 0

MySQL存在しないレコード更新しようとするとギャップロックになるから注意な。

2019-03-18

Dr.ストーンで作ってきたものまとめ(98話まで)

文明が滅んだ後の作中時系列順(小説版含む)

石器

チャート石を削って作成

石器を利用して作成

紐を利用した道具で作成

紐を利用した罠で捕まえた鹿の皮で作成

木で作成

ブドウ作成

ブランデー

土器で酒を蒸留して作成

ナイタール液

エタノールブランデー)と硝酸コウモリ排泄物)で作成

保存食燻製肉)

炎(煙)で作成

モルタル

炭酸カルシウム(貝)と砂で作成

石鹸

炭酸カルシウム(貝)で作成

クロスボウ

作成描写なし

六分儀

作成描写なし

黒色火薬

硫黄箱根産)と硝酸カリ(元コウモリ排泄物)と木炭から作成

滑車

火薬と紐と石鹸(潤滑剤として使用)で作成

車(動力なし)

滑車を流用して作成

炎色反応(黄)

炎+塩でクロム作成

炎色反応(青緑)

炎+銅でクロム作成

炎色反応(紫)

炎+硫黄クロム作成

静電気発生機

硫黄を球状に固めてクロム作成

金メッキ

水銀+砂金で作成

方位磁石

水に磁石を浮かべてクロム作成

鉄(砂鉄)

磁石収集

送風機1号

皮で風船状の送風機を作成

ラーメン

猫じゃらしで作成

送風機2号

竹筒でポンピングタイプの送風機を作成

鉄(製鉄版)

送風機を使って炉で作成

銅線

銅を炉で溶かして作成

(強力な)磁石

ウルシで絶縁した鉄棒に銅線を巻き、雷を当てて作成

腕力発電機

銅と強力磁石作成

電気、光

腕力発電で一瞬だけ作成

ガラスレンズ眼鏡

珪砂で作成

科学実験用のガラス製品

ガラスでカセキが作成

釣り道具(釣り糸、ルアー、浮き、糸巻き機

ヤギの腸を釣り糸にして作成

ソーセージ

ヤギの腸で作成

ギター

ヤギの腸で作成チューニングは千空の知識を元に計算して実施

硫化水素検知機

槍を銀メッキして作成

スマスク

炭酸カリウムと灰で作成

硫酸

硫化水素検知機とガスマスクを利用して採取

塩酸

硫酸+塩で作成

ロロ硫酸

湯の花塩酸作成

水酸化ナトリウム

塩水を電気分解して作成(電気腕力発電)

アニリン

石炭燃えカスコールタール塩酸で洗ってから酢酸エチル(酒+酢)をかけて作成

炭酸

から出る二酸化炭素を水に混ぜて作成

氷酢酸

酢と焼いた貝の化合物硫酸をかけて作成

ケテン

鉄と氷酢酸作成

無水酢酸

氷酢酸とケテンで作成

アセトアニリド(解熱鎮痛剤)

無水酢酸アニリン作成

パラアセトアミベンゼンロロスルホン酸

アセトアニリドにクロロ硫酸を混ぜて作成

パラアセトアミベンゼンスルホン酸

パラアセトアミベンゼンロロスルホン酸とアンモニア作成

重曹

炭酸水酸化ナトリウム作成

サルファ

パラアセトアミベンゼンスルホン酸を塩酸で煮て重曹で洗って作成

コーラ

炭酸+パクチー+ライム+ハチミツ作成

鉄で作成

わたあめわたあめ

酒、みりんから作った糖を利用して作成

ギア

改良版わたあめ

電子回路用の導線

動作ギアで均一化した改良版わたあめ機を利用して金の繊維を作成

繊維をこより導線作成

ノコギリ

鉄を使ってカセキが作成

水車

ギアを使ってクロム作成

水力発電

水車で作成

バッテリー

硫酸と鉛で作成

自動製鉄機

水車を動力に送風機を改良して作成

電球

ガラス+金の導線+水銀作成

タングステン(原石)

バッテリー電球洞窟に入って採取

望遠鏡

レンズ作成

ガラス管内部のみを3400度以上に加熱する装置

タングステンフィラメント

加熱装置内部を水素で満たして作成

ヒッグマンポンプ

カセキの技術力で作成作成描写なし)

暖炉

作成描写なし

ホルマリン

木+銅で作成

マンガン電池

亜鉛+マンガン+炭で作成

フェノール樹脂(プラスチック

石炭+水酸化ナトリウム+ホルマリン作成

真空管

ヒッグマンポンプ作成

電波送信

真空管作成

ロッシェル塩

ワイン+海藻作成

マイク

ロッシェル塩+プラスチックメガホンで作成

電話

マイク+電波送信器で作成

レコード再生

骨+ギア+マイク作成

爆弾

水素+酸素+鹿の膀胱作成

マグネシウム

煮た海水から取ったにがり電気分解して作成

閃光玉

マグネシウム+電球作成

ブラックライト

ニッケル+バリウム+電球作成

ぜんまい

銅板で作成

レコード再生機(音楽再生用)

ぜんまい再生速度を制御して作成

回転カッター

水車で作成

首振りエンジン

回転カッターを利用して型を取った鉄の精密機器暖炉作成

首振りエンジン作成

惑星探査用エアレスタイヤ

竹を編んで作成

草を水酸化ナトリウムで煮て作成

カーボン樹脂

紙とプラスチック作成

使い捨て装甲車

車をカーボン樹脂で装甲して作成

漂白

汗を電気分解してクロム作成

血糊

シソカタバミクロム作成

ラプチャーディスク

皮で作成

火炎弾

硫酸+鉄粉作成

音響兵器

爆弾と銅板で作成

混酸

硫酸+硝酸作成

ニトログリセリン

混酸+石鹸作成

ダイナマイト

ニトログリセリン作成

スタンガン

マンガン電池で作成

ロロ酢酸

酢+塩素+硫黄

ロロ酢酸ナトリウム

ロロ酢酸+水酸化ナトリウム

シアンナトリウム

血+

シアノ酢酸

ロロ酢酸ナトリウム+シアンナトリウム

エチルシアノアセテート

シアノ酢酸+酒

医療接着剤

エチルシアノアセテート+ホルムアルデヒド

冷凍庫

エンジンピストン+金の細糸

温度計

ガラス水銀作成

通貨制度

石油需要基準作成

麻で作成

気球

布で作成

地図

気球観測した情報を元に作成

小麦畑

地図を元に小麦を探して作成

パン

小麦作成

ガラス+水酸化ナトリウム+銀+アンモニア+干しブドウ作成

銀塩カメラ

鏡+塩水

石油

気球+カメラ情報収集して油田を探索して発見

ガソリン

作成描写なし

スターリングエンジン

冷凍庫技術転用して作成

モーターボート

作成描写なし

蛍光塗料

亜鉛鉱で作成

ブラウン管

三角フラスコ+蛍光塗料作成

レーダー

ブラウン管+水晶+アンテナ作成

ソナー

ブラウン管+水晶+マイク作成

金属探知機

ブラウン管+水晶+コイルクロム作成

鉱山

金属探知機を使ってクロム発見

レール、トロッコ

作成描写なし

舗装道路アスファルト

廃液と砂利で作成

2019-03-13

anond:20190313113027

外国の大量殺人鬼が大量殺人出来た要因で日本では用意しにくそうなものはなんだ?

・強力な銃器

・強力な爆発物

・大量の死体を捨てて隠匿する場所

長期でレコードうちたてる殺人鬼には特に三番目が重要

アメリカなんかだとだだっ広い荒野を庭として持ってるような奴がいる


まあれだ

安易な○○人論に着地する前にちったあ頭使って考えろよ

バカなりにな

2019-02-14

anond:20190214110011

焼きそば雇用契約上の問題から擁護不可能だけど、blog にもあるように直にお客様を知る貴重な機会だから

絶対査定評価には入れない。あくま任意代休も用意する」とした上で、少し強めにプッシュするのは良いと思う

が、雇用契約には無いことさせるのに、追い出し部屋はやるとか、アカンやつですやんな

雇用契約にない事をやらせる=ゼネラリスト として育成し、可能な限り別ポジションを用意するってスタンスでなきゃ

どう言い訳することも出来ないはずだ

でもまぁそれよりも、個人的にはこっちのがキツイ、この会社で働くメリットとは・・・

開発者サーバスペックも、何台で構成されているのかも、どのような場所に置かれているかも知ることができません。sshもできなければログも見れず、メトリクスのグラフを見ることすらできません。ちょっとしたバグ調査であるテーブルレコード数を調べるのにも、発行するSQL文を添えた作業依頼書を承認リレーする必要がありました

あとほんといい加減ゼロベースから作り直して

UI検索機能改善させよ?ね?

そしたらプレミアム戻ったるわ、端金やし

IT層には元から嫌われておった anond:20190214123654 anond:20190214100949 anond:20190214103049

IT層には嫌われとった

ニコ動レガシーなのでゼロベースで作り直そうが総意

他にはこういうのもあった

引用元http://hiroki-uemura.hateblo.jp/entry/2015/09/01/230611


さら開発者サーバスペックも、何台で構成されているのかも、どのような場所に置かれているかも知ることができません。sshもできなければログも見れず、メトリクスのグラフを見ることすらできません。ちょっとしたバグ調査であるテーブルレコード数を調べるのにも、発行するSQL文を添えた作業依頼書を承認リレーする必要がありました。


これらがなぜ必要なのか、いつからこうなのか、誰も知りません。聞いても誰も答えてくれません。しかしながらこのように決まっているのです。


(中略)


最後総務部追い出し部屋したことです。やめさせたい人間グループウェアから登録解除し、総務部という名前を持った統合思念体統一し、PCも共有で1台しか与えない。昨日までエンジニアをしていた人間スーツを着て社内を歩いて備品の補充をする。そんなことが許されていました。


(中略)


焼きそばを焼かなければならない必然性

2019-02-12

マギレコってゲームスレ荒らし運営に訴えられたF9(スプマン)って荒らしがいる

よくソシャゲスレって荒らし湧いてるけど意外にああいうのって訴えられたりするのかもね。

マギレコードマギレコ)ってゲームスレ荒らして壊滅させたF9(スプマン)って荒らしも訴えられたらしい。

マギレコ以外にも白猫、FGO、プリコネ、シャドバ・・・と色々なゲームスレ荒らして壊滅させてきたらしいけど。

アンチ行為も程々にしておくべきね。

逮捕されなくても、身バレなんてしたら一生大変な目に合わなければならないだろうし。

2019-02-10

anond:20180830212442

ワイはCDレコードも買ったことないし

音楽番組見ないしPCも常時ミュートにしてるやで

2019-02-09

カノン進行を大逆循環と呼ぶことについてを書いたが、パッヘルベルカノンのようなほとんど無名だった曲が後世の神アレンジで有名になるということを考えたい。パッヘルベルカノンが有名になった経緯というのは謎に包まれている。参考:【訃報】流石だったよなパイヤールhttp://lavender.5ch.net/test/read.cgi/classical/1366627357/ 他の曲ではヴィヴァルディ四季なんかもとてもバロック時代との作品とは思えないので後世の味付けで有名になったのだと思う。そういう曲は結構あるはずだ。

そもそもクラシック指揮者はどういうところで評価されるのかを考えると、曲の発掘という面もあるとおもう。フルトヴェングラーカラヤン、C. クライバー小澤征爾などもそういう発掘曲があるのだと思う。ヴィヴァルディ四季場合を調べると、イ・ムジチ合奏団が有名で日本レコードがすごく売れたらしい。合奏団が有名なケースもあるようだ。

ネットではカノンのJPOPへの影響が拡散されているが、現代での過去曲の評価作曲者評価が上がることになる。演奏指揮より作曲者評価が上なのは正当な評価だろう。実際パッヘルベルカノンのような美しい同度3声カノンをかける作曲者現代にいるとは思えない。でも場合によってはすごいのは誰なのか評価が安定しない事もありえると思った。

2019-02-06

COBOLってこんな言語

日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。

https://anond.hatelabo.jp/20190205192741

COBOL本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルデータ処理を想定している感じ。

SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通JavaRubyで全体の流れを記述してデータベース入出力をSQLで書く。COBOLもそんな感じで、全体の流れをJCLやShellスクリプト、あるいはJP1のような運用管理ソフトで書く。SQLの1個の処理に相当するのがCOBOLコンパイル単位で、それごとにソースファイルが分割される。ひとつソースファイルに2個以上の処理を書くこともできるけど普通はしない。ここまで理解すると古いCOBOLに1ファイル内のすべての処理に影響するグローバル変数しかないのや、今のCOBOLコンパイル単位をまたぐ真のグローバル変数がないのも、それほどクリティカルではないことがわかると思う。もし、本当に複数の処理にまたがる値が必要なら、データベースに格納してしまえばいいんだし。

で、SQLでいうところのデータベースに相当するのがCOBOLではデータファイルsedawkテキストファイルCSVファイルを行ごとに処理するのとちょっと似てるけど、COBOL場合は固定長ファイルという点が違う。改行文字は入ってなくて、たとえば150バイトごとに次のレコードみたいな形式。これの1レコードごとに何月何日何時に〇〇という商品を□□円で売ったとか書いてあるのが典型的データの内容。それを集計して今日は〇〇が何個売れて売上がどれだけあったとか、出金合計がいくらで入金合計がいくらで、みたいな財務諸表を作ったり。SQLと同じように税率なんかが書いてあるマスタデータと、日々の売り上げが書いてあるトランザクションデータがあって、突き合わせたりということもする。こういう集計処理だからUIはなくて、夜中に自動起動するようなバッチプログラムが主な使われ方。(混乱するから余談だけど、今のCOBOLSQLを使って普通RDBにもアクセスできる。ただ使い方としては、RDBファイル処理→ファイル処理→ファイル処理→ファイル処理→ファイル処理→RDBみたいに、最初最後だけみたいなのが普通

入出力がファイルから今の感覚で考えるとアクセスは遅い。でもメリットもあって、1回に1行しかメモリに乗せないからどんな巨大なデータでも時間さえかければ処理できる。それこそ国民ひとりひとりの年金データとかね。あと、途中でバグ不正データで止まってもデータを失うのは最小限で済むので復旧が比較的楽だったり。

データベースの話に戻ると、テーブル定義はどこに書いてあるかというとデータファイル側ではなくてCOBOLプログラム側、というのがSQLと一番違うところかも。つまり、このデータファイル構造はこれこれこうなっていると想定して読みます、とソースコードに自分で書く。当然実際のデータ構造がそれと違ってたらおかしくなる。

まあそんな感じで80年代くらいに会計処理をする目的だったら悪い言語ではなかったので、銀行官公庁とか、電力水道ガスといったライフラインを扱う大企業がこぞって導入して今に至る感じ。普通大企業は途中でSunかに置き換えてその後Linuxクラウドさらに置き換えたりしたけど、最初に作ったシステムが大きければ大きいほど、重要であれば重要であるほど現代的な環境に置き換えられないというのが今の課題

2019-01-24

フェイクニュース親玉といわれたSpeee社での思い出

https://www3.nhk.or.jp/news/special/net-koukoku/article/article_02.html

言及されたSpeee社に所属した事がありその時の所感を述べてゆきたい。(そこそこ長くなったので時間がない人は総括だけ読んでほしい)

高学歴者で構成されていた

創業者のH氏からし名古屋大の物理学部であり、理系高学歴が立ち上げた企業だった。H氏は理系卒だが営業経験があり20代前半でSpeee社を起業した非常に優秀な人間であった。

ざっと思い出すだけで、東工大早稲田慶應京大と言った世間一般でも高学歴と呼ばれる人間が中心に構成されていた。

基本は学歴不問で高卒叩き上げみたいな人もいたが高学歴者が中心であった。

開発部には、商用コンパイラ作成経験があるという本当に優秀な人もいたし、高学歴で優秀な人が多かった。

また、人柄も多くは世間的には「いいヤツ」と呼ばれるような前向きで、気さくで親切な人が多かった。

ただ、私の在職中に敏腕営業マネージャーパワハラが発覚し、飛ばされかけた事件もあったことにはあったので、演じることがうまい人も多かったのかもしれないが。

まぁ聞いた話によるとSpeee社は一度派閥争いにより乗っ取られかけたことがあるので、人柄重視の採用をしていたらしい。

当時の業務

私が在職中のSpeee社の事業の柱はSEOだった。当時はまだページランク存在していて、それをあげるに被リンク有効だった。

なので何をするかというとお客さんのページにリンクするためにブログなどにツールを使ってリンクを貼りまくるという結構グレーというか、

今なら完全にブラックな事をしていた。

他にもページランクが高いドメインが売られていると自動的に購入するツールや、

意味のないワードサラダまみれのサイト自動生成しそこからお客さんのページにリンクするツールなどを作成していた。

かにもお客さんのページの検索順位を記録するために、グーグル検索結果をDBに保存するため、レコード数は数十億とあった。そのため大量レコードを捌くノウハウみたいなのは結構蓄積されていた。

私が所属していたのは開発部だったので、ここらへんのツール作成メンテを行っていた。

当時のSpeeeの中心は営業部であった。前述したように創業者のH氏からし営業出身であり、創業必要資金を貯めれるくらいには優秀な営業であった。

そのため、営業部はH氏のお目にかなう優秀な営業部員で構成されており放送局など大手企業から案件を受注していた。

Speee社の営業部には他のWebSIerにはない特異な風習があった。

それは大手案件を受注した営業オフィスの中心で受注報告を行い、それを全社員が聞き拍手喝采を行うというものだった。

おそらく営業になろうという人間は他の部署人間に比べて目立ちたがり屋が多いのでこの風習麻薬的にモチベーションを爆上げしたものだと思われる。(もしこれを読んでいて営業成績に悩んでいる経営者かいたら参考にしてほしい)

あと、SEO分析する部署もあり、この部署には東工大数学科出身人間などがおり、コンサルティングと数値分析を行っていた。

このように営業部的な雰囲気が私に合わなかったが、基本的には働くには良い会社だったと思う。業務倫理的にグレーな事を除けば。

総括

当時の事を総括すると高学歴かつ優秀で人柄もいい人たちが、情弱を騙すような倫理的にグレーな事をして結構利益を上げていた。

その有様はスタンフォード監獄実験のようだった。

これが資本主義で金を稼ぐという事がどういう事なのかを実感できた。

WELQ事件などを通してグーグル検索結果はゴミばかりと認知されてきたが、Speeeでの経験はそれを予想するには十分であったし、個人的にはそれほど踊ろなかった。

そして、ネット理想とか良心資本主義の前には、あっさり敗北するものだと認識できた。

だって、すごく優秀な人たちがフルタイムで壊しにかかっているのだから

追記

イニシャル間違ってたので修正した

2019-01-19

anond:20190116194952

ワイは音楽にそこまで思い入れないやで

レコードCDとか買わないしネットも音量0で見てる

anond:20190119131657

それはしらなんだよ

xebraの壊れたレコードかとおもってたけど

俺が来る前にはてな流行ってたってことなのかな

2019-01-12

anond:20190112181108

というか「お前は差別主義者だ」「お前の中にある差別主義自覚しろ」という旨の短文だけ壊れたレコードみたいに繰り返す方がいい。

短文は短文であるが故論理的に強固。宗教的な決めつけはロジックを持たない故、非ロジカルな部分で強固。

したがって効く奴には一番効くし、あまり効かない奴にも少し効く。

深いところまでロジック理解している奴には効かないが、そういう奴はそもそも自覚のない差別主義者」にはならない。

2019-01-11

anond:20190111210322

壊れたレコードのような差別主義者だ。

その「小児性愛は他害」と言うロジック自体ロリコン差別実態

それは人権を踏み躙ってることをなんら隠すものではない。

ロリコン人権を踏み躙って子供の人権を選んでるだけ。

から、誇れよ。正義なんだろ?

何をそんなにムキになってるんだ差別主義者?

2019-01-05

anond:20190105021619

「どうせチキン日本はこれに対して『遺憾の意』を表明するくらいで、なあなあで終わるだろ」と舐めてかかったら、

真向から反論証拠映像の公開してきたので、メンツのためにもう後には引けなくなった感。

もう彼らは壊れたレコードのように正当性のない謝罪要求をし続け、日本が呆れて追及を止めるところに持っていくくらいしか逃げ道がないのだろう。

2019-01-03

需要は縮小、役割を終えつつある光学ドライブメディア市場

https://www.bcnretail.com/research/detail/20170929_43588.html

 レコードCDへ、ビデオカセットDVDへと、アナログからデジタルへ転換したが、今度はメディアを介したコンテンツ配給からインターネット配信へと提供方法が変化している。メディアに保存していた「デジタル資産」を外付けHDDUSBメモリなどにコピーリッピング)しておかなければ、近い将来、現在所有している資産が見られなくなる可能性は高い。

問題となるのは個人で集めたファイルとか(もちろん海賊版とかでは無いぞ)、撮影した写真バックアップですよね。

SDカードなどに移行しないといつかは読み込めなくなる時代が来るだろうという事ですね。

ドライブ自体は、中古も含めたら市場からはそう簡単には無くならないのでしょうが

2019-01-01

anond:20190101181441

本の場合電子書籍液晶画面で読むと目が疲れるという人がかなりいて、それは「デジタル配信音楽聴くと耳がおかしくなる」という人よりだいぶ多いと思われる。

電子ペーパーKindleなんかだと目の疲れは緩やかだと言われるけど、あれこそパソコンに対するワープロ的な存在ぽいんだよな。

なので、革新的電子書籍リーダーが出ないかぎりは、紙の書籍CDほど急激に減少しない。

そして、現在でもCDがかなり残っていることを考えると、30年程度では紙の本は無くならないだろう。

あと、電子化されていない古い書籍が、レコードCDの比でなく大量にあるので、古書店的な存在は無くなりづらいのではないか

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