  |
はてなキーワード: locとは
【11/11 26時追記】読みづらいと言われたので体裁だけ記法でちょっと編集。中身そのまま。増田は全く分野違いの素人野次馬である。
内容はニュースソース、プレスリリース、Wikipedia、ツイッターの電力系の人、鉄道系の人の書いたことなどを鵜吞みにしている。変な点言ってくれたら参照元くらいは答えられると思う。
大事なことなので冒頭のここにも書くが、JR四国によると前日の停電と瀬戸大橋の断線は無関係とのこと。下衆の勘繰りをしながら調べている最中にそう報道された。
―――
気になって素人が調べたことのまとめ。間違ってるかもよ。1度寝かせた文章に追記を重ねたため構成が悪くなってわかりづらいけど。
・瀬戸内海の瀬戸大橋経由で中国電力と繋がる「本四連系線」交流2回線(1L、2L)
・紀伊水道の海底ケーブル経由で関西電力と繋がる「阿南紀北直流幹線」直流1回線(第1極、第2極)。
うち第2極は制御保護装置更新工事のため10月末〜来年3月で停止中。
四国は発電力が潤沢で、通常時は上記経路で本州に電力を「輸出」している立場である。
電気は溜めておけないので、需要に対して供給(発電)を一致させるよう細やかにコントロールする必要がある。
需給バランスが崩れると周波数が乱れ、発電機の破損や大規模停電に繋がりかねない。
瀬戸大橋の本四連系線の2回線あるうちの1回線(2L)を停止させたメンテナンス作業中、使用中の1回線(1L)に何らかのトラブルがあり2回線ともに停止。
阿南紀北直流幹線のみで本州と繋がる状況になる。中国電力に輸出していた経路が断たれ周波数が高くなり(電力余り)、徳島の橘湾火力発電所が連系線トラブルと同時刻に停止。
本四連系線を復帰させるため、2Lのメンテナンスを中止し2Lの復旧作業中、何らかの原因で阿南紀北直流幹線の本州向き潮流(関西電力に輸出している電力量)が急増。
昼とは逆に周波数が下がり(電力足りない)、四国内の一部を停電させ需給バランスを保つ。停電は約37万戸。しばらくのち本四連系線2L復旧。
停電復旧。
瀬戸大橋内の架空切断のためJR瀬戸大橋線の列車が瀬戸大橋上で立ち往生。乗客は約150人。
列車はパンタグラフ3基がすべて破損し自走できない。上下線で運転見合わせ。
立ち往生した列車に救出用列車を横付けして乗客を救出し、隣駅に到着。
阿南紀北直流幹線で潮流が急増した「何らかの原因」だが、単なる寒さでの暖房起動などによる需要増ではないトラブルのようだ。
橘湾発電所の停止は本四連系線トラブルを検出した系統安定化装置の電制(電源制御)によるもの。
停電は周波数乱れを検出した周波数低下リレー(UFR：Under Frequency Relay)の作動によるもの。
四国電力管内でのUFR作動は記録の残る1966年以降で初めて。
停電地域が不思議にバラついているが、詳しい人が見るとUFRだと察しが付くらしい。
都市部を避けつつある程度の需要のある市街地ということか(ど田舎を停電させても需要増が覆らない)。
淡路島は北部が関西電力の管轄で南部が四国電力の管轄。南北それぞれで送電を受けている。
(これって非常時に一方向から送電してさらに向こうの本州(または四国)にまで送電できないの？よくわからないが本州四国を繋ぐのは上記2経路のみ扱いなのでできないのだろう)
停電により愛媛の伊方原子力発電所は運転上の制限から逸脱する影響があった。
原発は多重の安全機能確保のための運転上の制限として、外部電源は系統上の独立性を有する必要がある。
つまり、互いに依存しない複数の変電所または開閉所からの送電回路が必要だ。
伊方原発の外部電源は6系統あり、川内変電所から2系統、大洲変電所から4系統。
大洲変電所の上流にあるのは川内変電所経由2系統、小田変電所経由2系統。
停電により小田変電所からの電力が停止し、川内変電所のみに依存する系統となった。
これを「運転上の制限逸脱」略してLCO逸脱という（Limiting Condition of Operation）。
さらに、ちょうど大洲変電所からの4系統のうち2系統が点検中であった。
伊方原発は1,2号機が平成終盤に運転終了しており3号機のみ。
その3号機は7月から定期検査に入りその一環で10月から調整運転中(発電・送電はしている)。3号機は今年12月で運転開始から30年となる。
今回の定期検査で原子炉内の中性子の測定装置に不具合が見つかり運転再開が3週間遅れていた。
2023年成立(2025年施行)したGX脱炭素電源法で、運転開始から30年を超える原発は最長10年ごとの管理計画を原子力規制委員会に申請・認可を受ける必要がある。
これまで原発の運転期間は原子炉等規制法で原則40年・最長60年とされていたが、GX脱炭素電源法により上限は撤廃され60年超も運転可能となった。
伊方3号機は10月認可済み。
伊方原発3号機の使用済み核燃料を保存するプールは容量の92%が埋まっている。
プール以外で一時保管するための乾式貯蔵施設の設置工事を進めている。
これを満たさない状態が発生すると電力会社は逸脱を宣言し原子力規制委員会に報告するとともに速やかに対応する。
逸脱すなわち原子炉施設保安規定違反というわけではなく措置を講ずれば良いらしい。
経済産業省は四国電力送配電に停電の原因究明と再発防止策の報告を求めている。期限は停電発生から30日以内。
国土交通省はJR四国に運転停止トラブルの原因究明と再発防止策の報告を求めている。
停電と瀬戸大橋の断線の関連を疑ってしまうが、JR四国の発表では関連はないらしい。
JR四国は非電化区間が多く汽車(ディーゼル気動車)が走っている。停電時に電車は運休してしまうが汽車は走る。
岡山のJR西日本側からディーゼル機関車の手配も考えただろうが、結局救出には運行可能な下り線を四国側からの列車が逆走して(瀬戸大橋は複線)向かいの線路に横付けして板を渡して客を移動させ、そのまま逆走を続けて代走した。
立ち往生したのは高松発岡山行きの快速マリンライナー10号。この10号の前には朝5時頃から同路線を同2,4,6,8号、特急しおかぜ2,4号、普通列車2本が通過している。
直前の通過はしおかぜ4号。前日の終電は23時頃のマリンライナー70号。8,10号は1日2本だけの7両編成。他の編成は時間帯により2両または5両。
7両の内訳はJR四国の5000系が3両、JR西日本の223系5000番台が4両。
瀬戸大橋は10個の橋の総称。立ち往生した場所は最も岡山側である下津井瀬戸大橋の中央付近か。
仮に歩いて向かう場合、最も岡山側とは言え橋の全長1447mの半分+トンネル230m＝約1kmの距離がある。最寄の児島駅からは約4kmある。
JR瀬戸大橋線はJR本四備讃線の愛称であり、JR西日本岡山支社とJR四国が管轄する。
瀬戸大橋そのものは独立行政法人高速道路保有・債務返済機構(旧：本州四国連絡橋公団)が保有し、JR四国が借り受けている。
道路は一般道のない高速道路で、管理は本州四国連絡高速道路株式会社。
電線の本四連系線の管理は電源開発発送電ネットワーク株式会社(電源開発株式会社から発送電分離)。
これ
13歳の娘と性交渉を繰り返し 妊娠させた父親「僕のことが好きなのかと…」「娘からの『アプローチ』あったから」裁判の中で語られた理由とは
妻も娘も寛大な刑を望んでいる上に、出所後も住むつもりで居る
正直、こういうのはままある、かなり稀だけど
娘に性的興味が強く、かつ父に嫌悪感が出なかったら一定確率でそうなるだろう
どれだけ純愛だと主張しようが社会は「グルーミングだ」という結論なので情状酌量の余地はないんだけど
ヤフコメが怖くて
「父も娘も知的障害では？」みたいな、そういうコメントが散見される
これ自分で何言ってるか分かってんだろうか？
「知的障害者は親子で合意セックスするようなやつだ」って言ってるんだよ
おそろしいよコイツらが
乱暴な言い方をすれば「キチガイ親子だな」って言ってるわけ、真顔で
たぶん、認知的不協和ってやつなんだろう
健常な13歳の女子は性的に興味があるわけないし、父とセックスしたいと思うわけはない
なら理由があるはずだ！ってなる
実際には、そういうことは稀に存在するし、しかし大人側が自制しなければいけないというのが正しい解釈なんだけど
「そういうことが稀に存在する」でもう信じたくないからおかしな方向へ行き、結果とんでもない結論に至る
やだねえ
こういう奴らが真面目な顔してるのが一番嫌だし一番怖い
心中、少なくとも意思決定能力のない子供に対するそれはただの身勝手な殺人で、情状酌量の余地など皆無だと思うんだが、何故こんなに同情されるんだろう？
しかも心中するとか言って自分だけちゃっかり生き残ってるじゃん
何処に同情する要素があるのか分からない
「ボロボロになりながらも不妊治療を続け、５人の子どもを失った。」も何も、それは自分の意思で選んだ事ですよね？
そんな夫を選んだのに不妊治療を続けたのも自分の意思でしかないのに、何故降って湧いた災いかのように言うのか意味が分からない。
結婚したくても出来なかった女性の事は嫁き遅れだの売れ残りだのと馬鹿にする一方で
自らの意思で男を選んで結婚し子供を産んだ女が同情される意味が本当に理解出来ない
しかも、もっと年配ならまだしも36歳って私よりも若いし、到底女が自立出来ないような時代じゃないのに
どうしてこうも前時代的な「可哀相な妻・母」のイメージで捉えて同情する人が多いのか
（あと、この母親が今36歳で去年殺害した時に息子が8歳、それ以前に5度の不妊治療って事はおそらく20代前半で結婚しているんだが、
『女が若ければ必ず健康な子供が産める』という信仰を押し付ける人達はどう思うのか）
https://b.hatena.ne.jp/entry/4736080561518980709/comment/TakamoriTarou
https://www.security-next.com/145617
https://aws.amazon.com/jp/s3/pricing/?nc=sn&loc=4
添付ファイルと言ってる感じはExcelかWord、もしくは画像か
これを書いてる時点で米ドルは 134.84円
| 1 W | 2 W | 52 W | ||
|---|---|---|---|---|
| kB | 10338900 | 20677800 | … | 537622800 |
| GB | 9.85994339 | 19.71988678 | … | 512.7170563 |
| USD | 0.061624646 | 0.123249292 | … | 3.204481602 |
| JPY | 8.309467292 | 16.61893458 | … | 432.0922992 |
| JPY (SUM) | 8.309467292 | 24.92840188 | … | 11450.44593 |
支払い総額を一般化すると ΣY(k) = [JPY/W]*k*(k+1)/2
五年後には支払い総額は 281,940円
五年後の容量は 2564 GB
ただ置いてあるだけで、月に8642円が出ていく
まあ件のシステムでホワイトリスト形式でファイルを消しているのは容量を節約しているのではなくてセキュリティ的な側面だろうとは想像するが
効果のほどははっきりしないとしてもね
「@RealClownfishTV Kneon what do you think of APRIL 2021 NPD BOOKSCAN - TOP 20 ADULT GRAPHIC NOVELS? you will laugh at what you don't see on the chart. https://t.co/TYJZ8jOqEM」 / Twitter
https://twitter.com/allocta/status/1391608725916446720
「Wait, it's ALL manga?!」 / Twitter
https://twitter.com/RealClownfishTV/status/1391611755185557509
【悲報】 アメコミ関係者「助けて！！アメリカのコミック売上ランキングが日本の漫画に占領されちゃったの！！！！！」 [426633456]
令和３年度最新版『アメコミは売上でも日本の漫画に押されている』という言説に対する反論集+α - Togetter
https://togetter.com/li/1716495
ロックタウンは、ショッピングセンターのかつて存在したブランド名。
大和ハウス工業とイオンの共同出資により設立されたデベロッパー、ロック開発株式会社が展開・運営していた。
「ロック」(LOC)は「Land Owner and Company」の頭文字を取ったもので、大和ハウスグループの土地有効活用事業(LOCシステム)の
名称でもある。大和ハウスによるイオングループ向の中小型ロードサイド店舗開発の事業主体となっていた。
2011年8月31日、同日付をもって、イオンが大和ハウスの保有する全株式を取得してロック開発を完全子会社とし、翌9月1日をもって
ショッピングセンター名は「ロックタウン」が、同日付で「イオンタウン」を冠にしたSC名に変更され、看板も順次変更された。
https://ja.wikipedia.org/wiki/%E3%83%AD%E3%83%83%E3%82%AF%E9%96%8B%E7%99%BA
あれは平成になったばかりのことである。私の実家は町の台地の下側にあった。町は単に「上」「下」と呼ばれている。「上」のやや裏側、養老乃瀧の横、パチンコ屋の地下にそのゲーセンはあった。無論、「下」にもゲーセンはあったし、こっちは１Ｐ50円だったのだが、些か小汚い（後に人生で唯一回のカツアゲに遭うこととなる）。その点、上のゲーセンは新タイトルの開拓に割に熱心で、発売後にＧ-LOCの可動筐体なんぞも入った。１P100円で天井は低かったが、店内は場所の割には明るかった。
家庭方針でファミコンが与えられなかった私は、中学に入ると間もなく小遣いはもちろんの事、色々な"錬金術"（図書券の釣りを現金でくれる本屋で買うとか、親支給のオレンジカードで切符を間違って買うとかだ）で小銭を作っては、一人でせっせと通ったものである。当時から些か反射神経に難のあった私の目当てはもっぱらバブルボブルだ。２でもシンフォニーでも、メモリーズでもない、素のバブルボブルである。御存じない方にお教えすると、「1986年にタイトーから発売された固定画面アクションゲーム。『泡』を題材にした独特のアクションを用いる」(ウィキペディア)だそうだ。ステージは100まである。
で、ウィキペディアの続きを見ていただければわかるが、このゲーム裏ワザがあり、コイン投入前にコマンドを入力することで自機がパワーアップ出来たり、ノーミス報償をミスしていても取れるように出来たりする。これは公式がシールを筐体に貼って告知していた。貼っていない店もあり、上のゲーセンはそれだった。私はたまたまE電(当時）で別駅までゲーセン遠征をしてそれを知ったのである。
そして、40面までたどり着き、裏ワザで出現するはずのノーミスアイテムをとって裏ボーナスステージに潜入し、ここでゲームオーバーを迎えると、ハイスコア表示に102面到達のありえない表示が出るようになる。これに厨房だった私はハマった。
無論、ゲーム自体は下手なので（どのくらいかというと、ミスしやすくなるのでスピードアップアイテムを取らないほどである）40面にたどり着けるかはわりに運である。しかしたどりつけば、栄光の102面表記ができるのだ。もっとも、ハイスコアは次の奴のために「I.F」にしておくのだが(こう入力しておくと次のプレーヤーは序盤にいいアイテムが取れるのだ)。
そんなある日のことである。いつも通りちまちまと面を進めていると、テーブル筐体（まだアップライトは最新型であった時代だ）の向こうからリーマンと思しき兄ちゃんがしげしげと私のプレーを見ている。しかしこちらの腕前は先述の通り、この日は運もなかった。40面の前で私のバブルンはコマが尽きた。今日はついてねぇな、と思って席を立とうとすると、リーマンが黙って隣に座り、百円玉を筐体に投入するではないか。
バブルボブルは古いタイトルである、コンテニュー機能はない。が、１Ｐ側がきちんと死に切ってゲームオーバーになる刹那の前に２Ｐ側が参戦すれば、疑似的なコンテニューが出来るのだ。何するんだこいつ、と思ったら、リーマンはもう一枚コインを突っ込んで１Ｐ側のスタートボタンをも押すではないか。
何をしゃべったかも覚えていない。とにかくいきなり現れたリーマンは私にコンテニューと共闘をおごってくれたのである。しかもたしか1000円ぐらい。何故そんなことを彼がしたのか、同じ裏ワザ使いとしてのよしみを感じたのか、こいつならエンディング－協力プレーでないとみられないのである－に行けると値踏みを誤ったか。理由は聞かなかった。とにかく彼が夏目を崩した百円玉で行けるところまで行こうぜ－そんな闘いである。
何面で死んだかはもうとっくに覚えていない。大分足も引っ張ったはずである、ボスの待つ１００面まで行かなかったのは確かだ。
「いやぁ残念だったねぇ」とにこやかに笑う彼に何度も礼を言って、その場でわかれて以来そのままである。上でも下でも、いやさ遠征先でも当然このリーマンと邂逅することはなかった。正に一期一会。
私の人生で、極々たまにこんなことが起きる。だから私は、少々楽天家に育ったのかもしれない。バーチャロンが終わり、戦場の絆に乗り遅れて-あれは私の感覚では高すぎた-私はゲーセンを卒業した。
追記：
id:kisiritooru 遺憾ながら違う。後学の為その判定の根拠をお伺いしたい
id:htnmiki い、インポちゃうし!!
再追記：
id:kisiritooru こちらこそ即レスでないので申し訳ない。私の感覚だと、平成一桁前半ぐらいは「平成になったばかり」だと思った
私はソフトウェア製造業で十年近く働いているが設計書と言えばExcelまたはWordだった。
UMLなどの作図にツールを使用することはあっても、最終納品物としてはExcelに画像として張り付けて提出していた。
もちろんExcel方眼紙については批判もあるのは理解しているが、開発者、運用者、顧客など関係者すべてが手間なく簡単に読めることを条件とすると、やはりExcelに落ち着いてしまう。
そんな私に表題のようなことを提案されたわけだが、最初何を言っているのかわからなかった。
設計書と言えばExcelという私には設計書をwikiで書くという発想がみじんもなかったからだ。
開発者、運用者、顧客のだれでも手間なく容易に読めるという条件はwikiでもかなえられることに気付いたが、私にはwikiの知識がほとんどない。
彼に詳しく聞いてみると、前に参画していたプロジェクトでは社内サーバに建てたwikiを用語集として活用していたそうだ。
wikiには顧客業務の専門用語などを記載して、製造工程以降に参画してくるメンバーとの情報共有のツールとして使用していたらしい。
そういった運用をしているうちに彼はwiki自体を設計書とできないか考え、調査したところ実際にwikiを設計書として使用している会社もあるようだということで、今回提案に踏み切ったらしい。
私も今調べてみたところwikiで設計書を書くという運用をしている会社もあるようだが、メリット・デメリットがwikiの知識があまりない私には判断しかねている。
ぱっと思いつくデメリットとしては、第一に、やはりマークアップを記述するコストが非常に大きいように思える。
記述する手間だけでなく、記述するスキルを手に入れるためのコストも考えると無視できないコストが必要となるように思える。
第二に、保守以降、一つのシステムに複数の改修案件や故障対応が並行するようなことはままあることだが、ソースはSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である。
メリットとしては、リンク機能で各設計書間を容易に行き来できることが第一に挙げられる。
第二に、改訂履歴や差分が標準で用意されていることもメリットであろう。
第三に、検索が容易であることがあげられる。この点はExcelと比較して十分大きなメリットだと思っている。
私がぱっと思いつく限りではこんなもんである。
はてな諸兄の中にwikiで設計書を書いたことがある方がいれば、メリット・デメリット、その他運用において気をつけるべきことなどあればご助言願いたい。
なお、今回の案件は数万LOCの小規模な、VBからWEBアプリへの置き換え案件であり、顧客から設計書の決まった書式などは指定されていない。
そのため自社の標準の設計書テンプレートを使用する予定だった。もちろんExcelである。
また、設計書作成に使用するツールでExcel、Word以外の素晴らしいツールがあれば教えていただきたい。
どうかよろしくお頼み申し上げ候。
autopagerize incrementalでググるとそれっぽいのが出てくる
こんなかんじの記述をAutopagerizeの適当な場所に追加したら連番URLでも使えるようになるはず
var pages = getElementsByXPath(this.info.pageElement, htmlDoc);
var url = this.getNextURL(this.info.nextLink, htmlDoc);
if (this.info.incremental) {
var exp = new RegExp(this.info.incremental.nextMatch,'i');
var _m = this.info.incremental.nextLink;
var step = this.info.incremental.step || 1;
url = this.requestURL.replace(exp,function(m0,m1){
var n = parseInt(m1,10) + step;
return _m.split('#').join(n);
});
}
var next = getFirstElementByXPath(xpath, doc);
if (next) {
if (this.info.incremental) {
var loc = this.requestURL || location.href;
var exp = new RegExp(this.info.incremental.nextMatch,'i');
var nextLink = this.info.incremental.nextLink;
var step = this.info.incremental.step || 1;
if (loc.match(exp)) {
return loc.replace(exp,nextLink.replace("#",parseInt(RegExp.$1)+step));
} else if (!loc.match(exp)) {
return loc + nextLink.replace("#",step);
}
} else {
return next.getAttribute('href') || next.getAttribute('action') || next.getAttribute('value');
}
}
連番に適応するSITEINFOはこんなかんじになる
pageelementは普通のsiteinfoと同じ
nextlinkはリンクをたどるわけじゃないので意味ないのだが一応書いておく必要があるので'//a'とでも書いておけばいい
url: '^http://matome\.naver\.jp/odai/'
,incremental: {
nextMatch: 'page=(\\d+)'
,nextLink: 'page=#'
}
,pageElement: '//div[@role="main"]'
,nextLink: '//a'
サンプル
元記事はそんなに外してもいないと思いますけどね。
静的型付き言語として関数型言語を持ち出してくるのは、論点が違うような気がしました。
静的型、型推論の嬉しさって、関数が一級かどうかでも違ってくると思いますし。
(つまり、静的型の得失について、scheme vs ML での議論と Java vs Perl の議論は別物だと思います)
結局は適材適所という結論にしかならないと思いますが、たとえば Web 系なら静的型付き言語で書いても面倒臭さの方が多そうです。
Web 系で一番面倒なのは文字列の扱いなので。そこは型システムで何も解決しないですよね。
そういうことより、文字列を関数名として $funcName(arg1, arg2) みたいにコールできたりとか、
そういう柔軟さが便利なのですよね。
こういうの、静的型がある言語だと大変ですよね。Java ならリフレクションですよね。
他の言語ではどうするのでしょう。おそらく、自前で関数テーブルを作ることになるでしょうか。
静的型を持たない言語での開発が、大規模になると破綻するというようなことが言われます。
大規模開発といっても、大抵フレームワークの規約に沿って実装するだけですし、
規模を LOC だと考える限りにおいては、大規模になっても複雑さは LOC に比例しませんから。
単純にモジュール数が増えるだけで、一つ一つは単純な実装の繰り返しですよね。
おさしみにたんぽぽを乗せるお仕事と変わりません。たんぽぽの山が積まれていて途方に暮れるだけです。
もちろん、大規模になったときにスケールしなくなるので C/Java にするというのはありますけど。
