  |
はてなキーワード: locとは
他企業のシステムとも連携して、従業員の作業を軽減させるシステムだね
まあ旅行会社みたいなシステムと思ってもらえばわかりやすいかな
日程調整
航空チケットの手配
観光地への送迎
こういうのをうちのシステムが引き受ける
$ bundle exec rails stats ではこんなかんじ
Code LOC: 228263 Test LOC: 249984 Code to Test Ratio: 1:1.1
俺の作業分は
https://github.com/ORGANIZATION/REPOSITORY/graphs/contributors
で見たら
4,191 commits 1,767,573 ++ 887,923 --
くらい
こんなもん？
https://twitter.com/michihikofujiei/status/1707668694703202345
@michihikofujiei
「こんな国に産んでごめんね…」母が怒りに震えて訴え…中3男子はねられ死亡、なぜ?東京高裁「逆転無罪判決」【判決要旨】(ＳＢＣ信越放送)
被害者の父親「もしこのようなことで救護義務違反が認められないのであれば、同じような事件が結構起こっていると思うんですよ。
弁護士が悪いのか。この手の変な裁判はちょくちょく見る。警察か利権団体化した被害者団体がやっている感じがする。いずれもパターンが共通しているから。
高裁の「飲酒運転の発覚を免れようとする意志と救護しようとする意志は両立する」という主張が理解出来ない。
逆転無罪判決「被害者に人工呼吸している。救護義務違反の罪は成立しない」東京高裁 中３死亡事故 母親「最低の判決」【長野】(テレビ信州)
これを罪を免れる行為と言うなら何もしない方がマシ。やってもやらなくても結果は同じ。
心中、少なくとも意思決定能力のない子供に対するそれはただの身勝手な殺人で、情状酌量の余地など皆無だと思うんだが、何故こんなに同情されるんだろう？
しかも心中するとか言って自分だけちゃっかり生き残ってるじゃん
何処に同情する要素があるのか分からない
「ボロボロになりながらも不妊治療を続け、５人の子どもを失った。」も何も、それは自分の意思で選んだ事ですよね？
そんな夫を選んだのに不妊治療を続けたのも自分の意思でしかないのに、何故降って湧いた災いかのように言うのか意味が分からない。
結婚したくても出来なかった女性の事は嫁き遅れだの売れ残りだのと馬鹿にする一方で
自らの意思で男を選んで結婚し子供を産んだ女が同情される意味が本当に理解出来ない
しかも、もっと年配ならまだしも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 にするというのはありますけど。
