「無印良品」公式サイト、年末から続くメンテナンスが終わらず。再稼働は1月下旬予定 48
ストーリー by hylom
何が起こっているんだ 部門より
何が起こっているんだ 部門より
Anonymous Coward曰く、
無印良品では年末年始にWebサイトやネットストアのメンテナンスを行なっており、予定では2020年1月1日よりWebサイトやネットストアの稼働が再開する予定だったはずなのだが、「システムメンテナンスに想定以上の時間を要している」という理由でメンテナンス期間が1月下旬まで延期されている（無印良品Webサイトでの告知、ITmedia）。
当初は「1月上旬まで」の延期だったが、現在は「1月下旬まで」となっている。
システム統合にSOA？ RDBMS？ bashで十分！ (スコア:3, 参考になる)
コメントタイトルの記事が2009年に出ているが、今回の件と関係あるのだろうか。
https://www.atmarkit.co.jp/news/200909/07/lltv03.html [atmarkit.co.jp]
今回の件がどのレベルの「更新」なのか分からないので関係ない可能性もあるが、
記事のシステムの保守がつらすぎて、入れ替えてやる→ドツボに、という流れではないかと邪推してしまう。
Re:システム統合にSOA？ RDBMS？ bashで十分！ (スコア:1, 興味深い)
関係ありそう。
https://twitter.com/ponta_murakami/status/1215764842818101248 [twitter.com]
Re: (スコア:0)
元コメの記事と繋げて読むと、凄い…マジっぽい。性能とか気を利かせて特殊な事をやると、後の人に引き継げずドツボにハマるものなぁ。
Re:システム統合にSOA？ RDBMS？ bashで十分！ (スコア:1)
https://www.esd21.jp/news/251d831b824bb14087777c0739fd81f44f87bc96.pdf [esd21.jp]
https://www.usp-lab.com/works.html [usp-lab.com]
基幹から腐ってるってどこぞできいたけどなんか他でも影響でそうだな。
リストに載ってるウエルシアは基幹システム刷新で乗り切ってる(はずな)ので無印も一から構築すべきだったな。
# 無印のサイトってここ数年検索して結果帰ってくるのにうん秒かかる感じだったので
# やっと刷新かよと思ったらこんなことになってて驚いてる。
Re: (スコア:0)
> リストに載ってるウエルシアは基幹システム刷新で乗り切ってる(はず
東急ハンズもほぼユニケージから脱してDynamoDBにデータを置く方式に移行したっぽいですね。
https://www.hands-lab.com/tech/entry/1482.html [hands-lab.com]
を見るとデータ連携や集計バッチではユニケージが残ってますが。
https://www.hands-lab.com/tech/entry/5437.html [hands-lab.com]
こっちを見るとまだ残ってる部分については負債の塊って扱いに。
一応上記のブログだとユニケージは
> 初学者がまず動くアプリケーションを作成して、動くものを作ることができる
Re:システム統合にSOA？ RDBMS？ bashで十分！ (スコア:2)
Re: (スコア:0)
そうですね。旧ザクでガンダムにショルダーアタックかますような美学を感じます。
でも自分が乗るならやっぱドムかゲルググあたりにしときたいのもまた確か。
Re: (スコア:0)
うーんこの...
シェルスクリプトで大抵のことはできるよ！ってのは個人的には楽しかっただろうなと思うけど。
Re: (スコア:0)
パッと見ゲロ吐きそうになる。でももしかするとこの手法が覇権を握った並行世界もあるのかもしれない。
ただやっぱ、スタンダード(結果的にであっても)な実装でないと丸ごと負の遺産に化ける可能性は避けられないね。
Re:システム統合にSOA？ RDBMS？ bashで十分！ (スコア:1)
汎用のツールを組み合わせての...ならいいんだけど、自作コマンドてんこ盛りで。
ただ小さくぶった切ったツールをパイプでまた繋いだだけに見える。これ、これらのコマンドを作った本人しかメンテできないだろ。
selfがセレクトで、sm2がサムアップ,sm4が中間計,sm5が合計,mapが縦横変換... だれが判るかい！
Re: (スコア:0)
> selfがセレクトで、sm2がサムアップ,sm4が中間計,sm5が合計,mapが縦横変換... だれが判るかい！
うーん、このネーミングセンスはすごい(悪い意味で)…
命名ってプログラミングのなかでも相当に大事な作業の筈ですよねえ…
Re: (スコア:0)
うちの会社は元物理学者がつくったシェルスクリプトが意味不すぎて、そのたびにphpやpythonに少しづつ置き換えてる
シェルスクリプト好きな人って変数名短くしがち
Re: (スコア:0)
昔のFORTRANを思いだした。
悪い意味で。
Re: (スコア:0)
> シェルスクリプト好きな人って変数名短くしがち
シェルスクリプトから呼び出すコマンド類がそもそもそうですからねえ。
cpとかmvとかlnとか。
ただし sm2、sm4、sm5 には、そういう嗜好の範囲を超越したヤバいものを感じます。
Re: (スコア:0)
シェルスクリプトで開発とか眩暈がする。
Re: (スコア:0)
viとかemacsとか…
Re: (スコア:0)
山ほど一時ファイルできそう。
Re: (スコア:0)
直後のツイートで「という予想」と言ってますよ！
https://twitter.com/ponta_murakami/status/1215764940176285696 [twitter.com]
Re: (スコア:0)
中の人ならなおのことそういわないといけないし。
想像だとしても割としっくりする予想なわけで。
シェルで書いたかどうかは置いといても、メンテや移行にこんなに労力がいるというあたりで、大したことのない「スーパーエンジニア」なんだろうなとはおもいます。
# メンテや移行、増強・増設の方針まで考えないシステムなんて
Re: (スコア:0)
件の人の以前のツイート等を見ても中の人らしき形跡もなく、話題なものをたくさんリツイートするタイプの人です。直前に@ITの例の記事を誰かがツイートしたものもリツイートもしてます。
ツイート時点で@ITの記事も含めて Togetter 等でも話題に上がってましたので、話題に言及して自分の予想をツイートした多くの人達のうちの一人と見るのが妥当だと思います。
ツイート内容からしても、「中の人」としてしっくりするようなものではないです。
当時からUSP研究所に委託する形で改修していたようなので、「解決できるスーパーエンジニアはもういない」というのはおかしいんですよ。今も存在しているUSP研究所にまた頼めばいいんだから。
そもそも例の開発手法は、標準コマンド+αでできていて依存するものが少ないのも売りの一つなので、ツイートにあるサーバ引越し程度でどうにもならない状況になるとは考えづらい。
結局、今回の件と例の開発手法が関係があるかどうかは謎のままかな。
Re: (スコア:0)
一番設計やらせちゃダメなタイプの人よな。
大規模システムなら後の保守や拡張も考慮するのが普通だろうに誰も止める人がいなかったのか、あえてそうやったのか。
どちらにしても良い会社とは言えん。
Re:システム統合にSOA？ RDBMS？ bashで十分！ (スコア:1)
でも、こういうの経営者にウケは良いのよ。
・小粒だけどコンスタントに成果が出る。
・要望に対して短期間（1週間、1か月程度）で成果が出る。（見える）
・プログラマ＆作業員も業務報告に「〇〇ができました」と安定して成果が書ける。
・費用も安い。
つまり、早い、安い、動くシステム開発手法なんだよ。
問題は、ハードウェア性能を浪費することぐらいと、性能限界があること。
負荷の高いオンライン・トランザクション処理を除けば、十分使えるのよ。
まあ、Ｅｘｃｅｌと同じや。
遅い、高い、動く（？）システム開発手法は、ウケが悪い。みずほ銀行とか何百億の追加費用がかかったっていうし。
「後の保守や拡張も考慮するのが普通だろうに」というのは、普通じゃないんですよ。どこもこれができなくて苦労しているのだ。
Re: (スコア:0)
そんなに受けがいいシステムなら、そのまま使えばいいわけで。
使えないから移行するんでしょう。
ウェブストアを閉鎖したりなどで発生した機会損失を考えたら、シェルで安く上げた費用とポピュラーなシステムで作り続けていたことと、どっちが本当に安上がりだったんですかね。
Re: (スコア:0)
VBと一緒に滅びてほしい
これが (スコア:1)
無印不良品
本当にメンテか？ (スコア:0)
株価もストップ安なので、もっと何かあるかも？とか思ったりも。
Re: (スコア:0)
中国でパクリに敗訴してたしなぁ。
https://www3.nhk.or.jp/news/html/20191213/k10012214161000.html [nhk.or.jp]
Re: (スコア:0)
商標が抑えられていたなら、MUJICOOLとかにすれば良かった？
切り戻し (スコア:0)
切り戻しもできないのか
なにかデータでも吹き飛ばしちゃったのか
なぜ無理に新システム移行するのか？ (スコア:0)
新システムがダメなら、しばらく新システム移行を延期して旧システムを使えばいいのに
なぜ旧システムを使って急場しのぎが無理なのだろうか
Re:なぜ無理に新システム移行するのか？ (スコア:1)
サーバー機器をリース契約でやってて事情により延長できないとか、いろいろあると思います。
OSサポート切れとかも。
Re: (スコア:0)
windows2008で作ってたんだよ。
あながち笑えない人はいると思う。
Re: (スコア:0)
ワイ：万一の場合に備えて従来システムの並行稼働も行うので、その対策費用をお願いします。
キャク：は？ 問題起きるの前提とはなんや！ちゃんと作ればそんなの必要ないやろ。
エイギョー：承知しました！ ワイ君そういうことで！
Re: (スコア:0)
「ワイ」って何？Y?
Re: (スコア:0)
ワイはワイ以上のなにもんでもないで
Re: (スコア:0)
で？分を途中で止めるな
Re: (スコア:0)
「分を止めるな」、時間系の能力かな？
なかなか日本語がお達者なようで ←
Re: (スコア:0)
パワー型のスタンド使いかな？
Re: (スコア:0)
万一の場合ってのを説明出来ないのも営業と同罪だよ。
もうちっとだけ続くんじゃ (スコア:0)
1月下旬を予定。
ホントに下旬で終わるのか？
Re:もうちっとだけ続くんじゃ (スコア:2)
去年クラウドが飛んだとかでデータ喪われて復旧できくなってた自治体はどうなったんだろう。
Re: (スコア:0)
旧システムを諦めて、既存ECサイトに商品登録しなおして再開ってパターンかなぁ
Re: (スコア:0)
残念、基幹業務システムからなので、システム再稼働できなきゃ、紙伝票。
これを機に (スコア:0)
もっとシンプルな構造のECサイトとして再出発してくれませんかね
だいぶ昔から良品週間の時だけたまに使ってたけど年月の経過とともに
見た目は微妙な違いしかないのにどんどん重くなっていった印象
正規表現処理は実装によって大きく処理速度が異なる (スコア:0)
unixのコマンド内蔵正規表現ライブラリ、単独の正規表現ライブラリなんかでも、
同じ処理で、一瞬で処理が済んだり、フリーズしたかとおもうくらい時間がかかったりする
商用UNIXの正規表現ライブラリがクソ遅くて、
Linux(GNUのコマンド類)じゃ一瞬で動くものが、
商用UNIXではフリーズしたかの如く時間がかかるパターンとかにあったことがある
Re:正規表現処理は実装によって大きく処理速度が異なる (スコア:4, 興味深い)
それはたぶん、ライブラリが使ってるアルゴリズムの問題。
「正規表現のマッチング問題」は、そのまま素直に実装した場合、「*」などの繰り返しは割り当てを変えて繰り返す(バックトラック)ことになります。
そのため、パターンによってはものすごく時間がかかることになり、最悪値だと、長さnに対して O(2n) の時間が必要。
ところで、「正規表現のマッチング問題」はそのまま「非決定性有限オートマトン受理問題」に一対一対応するのですが、「非決定性有限オートマトン」は「決定性有限オートマトン」への変換が可能です。決定性の場合、バックトラック不要で、一回読み進めるだけで判定可能。処理時間はO(n)です。
そのかわり、「非決定性から決定性への変換」という事前処理が必要ですし、決定性有限オートマトンはメモリ消費がすごく大きくなります。こっちがO(2n)になる。
どちらも利点欠点がありますが、最近はメモリに困ることはないので、決定性のデメリットは薄いですね。
UNIX古来のツールでいうと、grepは非決定性で、egrepは決定性変換してる。
egrepは検索はものすごく速いけど、(オートマトンの変換で)検索開始までちょっと待たされるので、
昔は検索内容と検索量でgrepとegrepを使い分けてたりしましたが、
今は何も考えずにegrepですね。ていうかGNUはgrepもegrepも実体は同じ(オプション違い)だし。
Re:正規表現処理は実装によって大きく処理速度が異なる (スコア:1)
バックトラックについてはCloudflareの障害 [it.srad.jp]とかありましたね。
今時のスクリプトの処理系だと大抵はDFA+NFAのハイブリッド的な実装なので
かなり無頓着なパターンを書いてもクセに合わせた挙動になりますが、
コマンドや単体ライブラリを直接叩く場合はアルゴリズムを知っておかないと駄目ですね。
Re: (スコア:0)
それはIBMのlocaleライブラリがglibcに取り込まれる前の話ではないだろうか？