■

https://szkwjp.sakura.ne.jp/suzukawaeditor_nansho.html

スズカワエディタの難所

スズカワエディタは下記の手順でプログラムされている。

①一つのファイルを数MBに分割する。

②分割ファイルを読み込むと同時に専用フォルダーに保存する。

③同時に分割ファイルから必要なデータを取得する。

④各分割ファイルを一つのリストとして連結する。

⑤動作を滑らかにするためにプログラムを改善する。

⑥この後必要に応じて各種機能を追加する。

スズカワエディタの作者たる私（YoshihikoSuzuki）の場合であるが、プログラミングにかかった時間は①～④に約２週間、⑤に約６週間である。⑥については機能によって大きく異なり、短くて１週間、長いもので２年近くかかっている。プログラミング開始から２１年以上経過するが未だに継続中である。

この難所？RopeとかSumTreeでググればサルでもある程度は解決できる。

https://github.com/oonyanya/FooList/tree/main

もしかしたら、できるかなと思い、実装してみたら、ディスクに書き出すこともできた。

"Ropes: anAlternative toStrings",by

Boehm, Atkinson, and Plass, inSOFTWARE--PRACTICE AND EXPERIENCE, VOL. 25(12), 1315–1330 (DECEMBER 1995).

https://www.cs.tufts.edu/comp/150FP/archive/hans-boehm/ropes.pdf

なんで知ってれば、鈴川エディタっぽいものは比較的簡単に作れる。

二分探索木版でもリーフノードをリンクドリストでつなぐのはくそ面倒だけどな…。

あと、二分探索木ではなく、B+木とかで実装してるならマジですごい。

Permalink |記事への反応(0) | 11:55

ツイートシェア

■anond:20251212014332

githubあさるかググれば、早い方法、出てくるぜ。

picetableという名前ではなく、RopeとかSumTreeという名前になってるけどな…。

https://github.com/oonyanya/FooList/tree/main

こっちはBigList.csあたり読めば元となったであろう論文が出てくるし、

https://tadaoyamaoka.hatenablog.com/entry/2019/08/18/154610

こっちは論文で言ってることを日本語で解説していたりする。

ただ、リバランスの個所は誰も日本語化してないんで英語の論文を読むハメになるけどな…。

Permalink |記事への反応(0) | 12:04

ツイートシェア

■

BZのソースコードが公開されていたので斜め読みしていたら、面白いことに気づいた。

FooListはRopeで処理をしていて、BZのほうは赤黒木で処理をしてるんだが、考え方は基本的に同じだった。

https://gitlab.com/devill.tamachan/binaryeditorbz/-/blob/master/Bz/SuperFileCon.h?ref_type=heads

Permalink |記事への反応(0) | 14:25

ツイートシェア

■

AvalonEditorのドキュメントはropeで管理してたのか。

意外と使ってるところあるんだな。

https://github.com/icsharpcode/AvalonEdit/blob/master/ICSharpCode.AvalonEdit/Document/TextDocument.cs

Permalink |記事への反応(0) | 15:48

ツイートシェア

■

鈴川エディタやEmEditorで少ないメモリー使用量で巨大テキストをファイルを編集できるとうたってるが、.NETでも見事に再現できたぞ。

1.2億行×100文字の全置換えでGCのメモリー使用量は340MB程度で、行の操作は86MB程度、合わせて426MBだ。

その辺の.NET製テキストエディターコンポーネントに組み込んでも500MBぐらいで済むと思う。

（その代わりワークファイルは30GBぐらいは行ってるはず）

鍵はropeというデーター構造を使用することとropeにアクセスする際、ディスクに保存する機構を付け加えるだけだ。

特にソースコードで見るべき個所はBigList.cs、Node.cs、DiskPinableContentDataStore.csの所だけだ。

多少遅くて構わないなら、ディスクに保存することはそこまで難しくはない。

メモリーマップドファイルは何かと面倒なので使ってないが、.NETでMMDataStructuresとかメモリーマップドファイルを扱うやつがあるんで、メモリーマップドファイルでも行けるはずだ。

benchmark start

size:120000000

AllocatedGC Memory:66,304bytes

addtime:173334ms

AllocatedGC Memory:101,257,168bytes

replace 1time:816628ms

AllocatedGC Memory:101,247,232bytes

replace 2time:1179279ms

AllocatedGC Memory:333,371,424bytes

replace 3time:1886714ms

AllocatedGC Memory:333,257,000bytes

enumratotiontime:1638579ms

AllocatedGC Memory:331,904,816bytes

clear buffer

AllocatedGC Memory:66,304bytes

addlinetime:46649ms

AllocatedGC Memory:86,939,136bytes

updatelinetime:77635ms

AllocatedGC Memory:87,272,912bytes

clear buffer

AllocatedGC Memory:69,448bytes

Finished.HitAnyKey

https://github.com/oonyanya/FooList

Permalink |記事への反応(0) | 21:24

ツイートシェア

■GC目線に立ったバッファーの評価

C#などコンパクションあり世代別GCを使った場合の話。参照型だとまた話は変わってくる。

http://s170199.ppp.asahi-net.or.jp/vivi/docs/buffer/edit_buffer.php#measure

vector

gap_vector

なかなかメモリーが解放されない。

つらい。

テキストの操作はやりやすい。

gap_vectorは少し早い。

list

行の文字数が85000バイト超えない限りは悪くはない。

メモリーの断片化もGCのおかげで起きないしね。

ただ、テキストの操作が微妙にやりにくい。

rope

GCフレンドリー。

リバランスのアルゴリズムがわかりにくいし、実装が面倒。

何だよ。フィナボッチ数列にバランスの取れたノードを放り込んで再構築って。

操作自体はAVL木のリバランスよりははるかに楽だけど、こっちはこっちで訳が分からん。

ただ、テキストの操作はgap_vectorなみにやりやすい。

なお、既存のライブラリーはライセンス的な意味で地雷だったりする。

速度の比較

CPUが違うので参考程度に。

構築速度：gap_vector ＜rope ＜＜＜ list

メモリー使用量：gap_vector ＜rope ＜ list

シーケンシャルアクセス：rope ＜ list（ポインター使用） ＜ gap_vector ＜ list

Permalink |記事への反応(0) | 13:47

ツイートシェア

■

テキストエディタのelisが世に出たのは1997年。

Boehm,Hans-J; Atkinson, Russ; Plass, Michael (December 1995). "Ropes: anAlternative toStrings" (PDF)

という本が出たのは1995年。

elisが出た当初、どうやって巨大なファイルを開いていたのかが謎だったけど、ropeというデーター構造の作り方はelisが出たときにはすでにあった。

だから、こんな事が出来たのか。

ただ、この頃は翻訳エンジンはそこまで賢くないので、英語をそのまま読んでいたことになる。

すごいとしかいいようがない。

Permalink |記事への反応(0) | 10:23

ツイートシェア

■anond:20250220134419

RopeもといBigList+GapBufferでさくさくエディターの置き換え処理をやってみた。

使用したマシンはCore i7 14700、メモリー32GB、IntelARC A750。

１００万行×１００文字を置き換え。

addはバッファーの構築で、０．８秒ぐらいで終わる。

replace1は３文字削除の３文字挿入で、３．５秒ぐらいで終わる。

replace2は３文字削除の４文字挿入で、４．９秒ぐらいで終わる

replace3は４文字削除の３文字挿入で、３．６秒ぐらいで終わる。

enumratotionはNULデバイスへの保存で、１．１秒で終わる。

benchmark start

AllocatedGC Memory:60,600bytes

addtime:729ms

AllocatedGC Memory:199,388,824bytes

replace 1time:3490ms

AllocatedGC Memory:199,405,136bytes

replace 2time:4861ms

AllocatedGC Memory:368,390,560bytes

replace 3time:3577ms

AllocatedGC Memory:368,390,560bytes

enumratotiontime:1086ms

AllocatedGC Memory:368,390,736bytes

clear buffer

AllocatedGC Memory:84,360bytes

１００万行の行とインデックスの変換テーブルの追加と更新処理はこのくらいで終わる。

変換テーブルの処理は構築が０．２秒、行が増えない更新は０．１秒ぐらいで終わる。

addlinetime:170ms

AllocatedGC Memory:32,805,312bytes

updatelinetime:110ms

AllocatedGC Memory:32,811,000bytes

clear buffer

AllocatedGC Memory:84,616bytes

Finished.HitAnyKey

結論

マシンの進化はすごい。

.NET8で、さくさくエディタとほぼ互角になるとは。

以下、ソースコード。

https://github.com/rirufa/FooList

Permalink |記事への反応(0) | 00:14

ツイートシェア

■

一次元インデックスから二次元インデックス、すなわちバイト数であらわされる位置から行と桁への変換がテキストエディターだとよく発生する。

この変換を素早くするために変換テーブルを作るのだが、普通に作ると更新の時にO(N)かかる。

さくさくエディターの作者は局所的行更新手法で殆どの場面ではO(1)、最悪はO(N)にしていたが、色々と事故が発生しやすい。

特にstepRowをまたぐ状況でテーブルのほぼ全部の更新を避けようと思うと事故りやすい。

俺は何度も事故を起こした。

そこで別のやり方でオーダーを削減してみた。

https://github.com/rirufa/FooList/blob/main/List/BigRangeList.cs

考え方は至極単純でRopeをたどるときに変換テーブルの長さを覚えておき、ついでに変換を済ませておこうというごくごく簡単なものである。

この方法により、変換テーブルの更新はO(Log N)+M、探索はO(Log N)+O(Log M)程度で済ませられるようになった。

局所的行更新手法に比べるとだいぶ遅いが、Mが十分に小さければそこまでコストはかからないはず。

ただし、マーカーみたいに連続していないものを放り込んだら、うまく動かないのでそこはご了承いただきたい。

以下、100万行の要素を操作したときのベンチマーク。

CPUはCore i5 10400F、メモリー16GB。

ブロックサイズは392。

addlinetime:297ms

AllocatedGC Memory:32,803,672bytes

updatelinetime:151ms

AllocatedGC Memory:32,809,360bytes

clear buffer

AllocatedGC Memory:82,976bytes

https://github.com/rirufa/FooList/blob/main/EditorDemo/Program.cs

Permalink |記事への反応(0) | 16:59

ツイートシェア

■

https://github.com/rirufa/FooEditengine/tree/lazy_load

https://github.com/rirufa/Fooeditor.WinUI

16GBぐらいメモリーを積んでれば1.1GBまでは読み込めることを確認した。

ただ、ずるをしていて、行の構築はぎりぎりまでしないようになっている。

一応、最終行への行ジャンプと編集と削除、置き換えだけはできるし、保存と内容の表示もできるが、最終行まで表示すると3GB近くメモリーを食う。

読み込んだだけでも2.5GB近くはメモリーを食う。

読み込んでから操作できるようになるまでかかる時間: 35秒程度

保存: 13秒程度

全置換え: 25秒程度

全置換えからのアンドゥ: 25~40秒程度だったと思う

EmEditorや鈴川エディタすごすぎるだろ。

それでそこまでメモリーを食わないとかやばい。

しかも、速いとか。

とはいえ、ここまでできたのBigList、もといRopeのおかげだ。

Ropeの存在を知らなかったら、.NETで巨大ファイルの編集は夢のまた夢だった。

とはいえ、BigListに制約(Int.MAX-1=2^31-1までの要素しか扱えない)があるし、LOH入りを回避するため、ブロックサイズを64KBに抑えてるので、せいぜい2GBぐらいまでしか扱えないが…

（BigListは計算上、4GBまでなら読み込みだけならできるけど、最大行数がInt.MAX-1=2^31-1までしか保持できないので、実質的には無理やと思う。それにそこまでの動作は確認してない。NTFSで一般には手に入らないマシンを用意してまで動作確認したマイクロソフトすごすぎ）

https://szkwjp.sakura.ne.jp/suzukawaeditor_nansho.html

①一つのファイルを数MBに分割する。

②分割ファイルを読み込むと同時に専用フォルダーに保存する。

③同時に分割ファイルから必要なデータを取得する。

④各分割ファイルを一つのリストとして連結する。

⑤動作を滑らかにするためにプログラムを改善する。

⑥この後必要に応じて各種機能を追加する。

鈴川エディタもリンクドリストでそれぞれのファイルをつなげると遅いので、おそらくRopeの考え方を使っているものと思われるが、あの意味不明なリバランスのやり方を論文から読んでそのまま実装するのはすごいとしか言いようがない。

どこかのだれかがBigListを実装してくれなければそもそも巨大ファイルの読み込み機能を追加できなかった。

追記：証拠画像

https://d.kuku.lu/p68expc2e

Permalink |記事への反応(1) | 15:57

ツイートシェア

■

テキストエディタを高速化するためにある人が書いたBigListを改造して、リーフノードをリンクドリストでつないだら全列挙が早くなって、スタックオーバーフローしなくなった。

ただ、その代わり元々のコードにあったノードの共有機能はいらなそうなので省くことにした。

Core i5 10400F、メモリー16GBで、100文字×100行＝1億文字を突っ込んで、あれこれ操作した場合はこのくらいの速度で動く。

benchmark start

AllocatedGC Memory:60,392bytes

addtime:1728ms

AllocatedGC Memory:416,037,968bytes

replace 1time:5776ms

AllocatedGC Memory:416,082,104bytes

replace 2time:5694ms

AllocatedGC Memory:416,082,272bytes

replace 3time:5196ms

AllocatedGC Memory:416,082,296bytes

enumratotiontime:1179ms

AllocatedGC Memory:416,082,440bytes

clear buffer

AllocatedGC Memory:82,360bytes

Finished.HitAnyKey

https://github.com/rirufa/FooList

ListやGapBufferだとGCに優しくないけど、BigListだとLOH入りしないので、GCに優しいのだ。

その代わり速度はBigListの中身はRopeなので、少し遅くなるのだ。

Ropeで、リーフノードをリンクドリストでつないだ場合、挿入と削除、追加、ランダムアクセスはO(Log N)、全列挙はO(N)なのだ。

MITライセンスなんで商用でも問題ないけど、元々のBigListのライセンスに不穏なことが書いてあったので、気になるなら、自分で書き直したほうがいい。

元々のBigListはこの本を参考にしたようなのだ。

The rebalancing algorithmis from "Ropes: anAlternative toStrings",by

Boehm, Atkinson, and Plass, inSOFTWARE--PRACTICE AND EXPERIENCE, VOL. 25(12), 1315–1330 (DECEMBER 1995).

https://www.cs.tufts.edu/comp/150FP/archive/hans-boehm/ropes.pdf

Permalink |記事への反応(3) | 13:44

ツイートシェア

■

http://hvivi.dyndns.org/sse/replaceAll.html

さくさくエディタのまねをして全置換えでベンチマークを取ってみた。

benchmark start

AllocatedGC Memory:60,392bytes

addtime:1996ms

AllocatedGC Memory:440,048,840bytes

replacetime:10779ms

AllocatedGC Memory:440,082,632bytes

replacetime:10682ms

AllocatedGC Memory:440,082,656bytes

clear buffer

AllocatedGC Memory:82,280bytes

Finished.HitAnyKey

ベンチマークのソースコード

https://github.com/rirufa/FooList

Rope<T>は削除と置き換え、文字列のランダムアクセスがO(log N)なのでさくさくエディタに比べると遅い。

それでも秀丸やMeryよりは早いが…

Permalink |記事への反応(0) | 11:37

ツイートシェア

■これからプログラマーになりたい学生へ

大体のものは日本語でアルゴリズムやデーター構造の解説があります。

でも、時々、こういうのがあります。

https://www.cs.tufts.edu/comp/150FP/archive/hans-boehm/ropes.pdf

Rebalancing

Rebalancing produces a balancedversion of the argumentrope.The original

is unaffected.

(中略)

Many variations of this approach are possible. Our balance conditionwas expressed

in terms of length, and our algorithm tends tomove long ¯atropes close to the

root.One could also rebalance purely in terms of node count.

Ropeがくそ遅いのでリーフノードをリンクドリストでつなごうとしたら、訳が分からなくなりました。

適当にやってはいけないと思い、ググったら、Ropeのリバランスのやり方を解説した奴は英語の奴しかありませんでした。

だから、英語はまじめにやったほうがいいです。

あと、リンク先を読めばわかるけど、数学でおなじみの記号がいたるところに出てきます。

数学アレルギーがあるとまじで嫌悪感で胸いっぱいになります。

こうはならないように数学はまじめに勉強したほうがいいです。

数３Ｃまで取ったほうがいいです。

大学に行けば体系的にアルゴリズムやデーター構造、最先端の技術を教えてくれますが、情報系の大学は数３Ｃが必須です。

そして、ネットに転がってるデーター構造の解説書は数３Ｃを勉強していることを前提に書かれていることが多いです。

微分積分が出た時代の数１Ａと数２しかとってないので、この手の本はマジで訳が分かりません。

だから、おじさんは高校生向けの優しい、アルゴリズムやデーター構造の本で勉強しました。

そして、低賃金プログラマーになりました

なぜかというとライブラリーしか触れず、リンクドリストやＡＶＬ木、クイックソートや基数ソートをかじったぐらいのプログラマーは腐るほどいるからです。

だから、君たちはおじさんのようにはなるな。

Permalink |記事への反応(2) | 17:32

ツイートシェア

■

Wintellect.PowerCollections.BigListくそ早いな。

100万行×100文字追加して、３文字削除の３文字挿入、３文字削除の４文字挿入やったが、xyzzyぐらいの速度は出た。

ただ、さくさくエディタには勝てんな。

BigListの内部で使われてるRopeの性質なので仕方ないか。

benchmark start

AllocatedGC Memory:60,616

addtime:1370ms

AllocatedGC Memory:344,041,272

replacetime:6541ms

AllocatedGC Memory:344,101,024

replacetime:8153ms

AllocatedGC Memory:688,101,192

clear buffer

AllocatedGC Memory:100,808

Finished.HitAnyKey

Permalink |記事への反応(1) | 22:35

ツイートシェア

■

Ropeというやつがあるのか。

ただ、Ropeは検索を二分探索木で素早くする探り当てる都合上、ノードを直接いじることができない。

そこでノードを削除したいときはぶった切ってつなぐことをやるようだ。

この発想はなかった。

https://github.com/FlatlinerDOA/Rope

なお、時間計算量は追加がO(1）で、要素の取得がO(lon N)なので、GapBufferよりは遅い。

ただ、RopeはGCにとってはメモリー管理がやりやすいというメリットがあり、ユーザー目線だと巨大なファイルを読み込んでもメモリー解放に時間がかからないという利点がある。

Permalink |記事への反応(1) | 17:12

ツイートシェア

■略語三文字英単語は全てプロレス技

僕は日常に潜む略語三文字英単語の危険性に気づいてしまった。

あれは、すべてプロレス技なんだ。いや、これは冗談なんかじゃない。

もう一度言うが、三文字の英単語はすべてプロレス技だ。

例えば「RPG」、これが危険極まりない。

みんな「ロールプレイングゲーム」として楽しんでいるけど、本当は「Rope-Press Gutbuster（ローププレス・ガットバスター）」の略だ。

つまり、ロープに押し付けられた勢いで腹をガツンとやられる技。腹がへこむなんてもんじゃない。あれを知らずにゲーム感覚でやってる奴ら、無防備すぎる。

次に「ATM」。これも危ない。「Automatic TellerMachine」だって？いやいや、違う。「Aerial Torture Maneuver（エアリアル・トーチャー・マニューバー）」だよ。

空中で拷問じみた関節技を繰り出される。お金を下ろすどころか、自分が宙を舞うことになるぞ。しかもそれが待っているのは駅前のコンビニ。油断してATMに近づけば、即座にプロレスの世界に引きずり込まれる。

日常に紛れ込むこうした略語が、どれだけ危険かを僕は訴え続けている。

だけど、みんな僕の話を聞いてくれない。

ある日、同僚のTが「PDF送っておいたから確認して」と言ってきたんだ。PDF、あれもプロレス技だよ。なんだと思う？「Piledriver Fast（パイルドライバー・ファスト）」だ。

頭から地面に叩きつけられて、しかもそれが高速だなんて、考えただけでも恐ろしい。僕は絶対にそのファイルを開かなかった。あんな危険なもの、目を通してはいけない。

さらに「CPU」。これは会社の会議中に頻繁に使われるから特に要注意。「Central Processing Unit」だって？そんなの表向きの意味にすぎない。「ChokeholdPower Uppercut（チョークホールド・パワー・アッパーカット）」の略だ。

首を絞められたあと、ものすごいアッパーカットが飛んでくる。これを毎日のように会社で話している奴ら、知らずにプロレス技を仕掛け合っているんだよ。僕はそのたびに身構えるけど、周りの連中は平気な顔して「CPUの性能が…」とか言っている。いつか全員がリングの上で痛い目に遭うのを、僕はただ見守るしかない。

僕の警告を無視して、略語を日常的に使い続ける奴らに嫌気が差し始めた頃、ついに「LOL」が出てきた。これも「LaughOut Loud」とかいうネットスラングだと信じ込んでいる人が多いけど、真実は違う。「Leglock Overhand Lariat（レッグロック・オーバーハンド・ラリアット）」だ。笑ってる場合じゃない。相手の足をねじって、顔面にラリアットが飛んでくるなんて、笑えないどころか恐怖そのものだ。SNSで気軽に「LOL」なんて使ってる奴ら、本当はリング上でバチバチにやり合ってるのに、本人たちは全然気づいてない。

僕はそんな略語三文字の世界を避けるため、いったん距離を置こうと思っていた。

だが、どうやらそれはもう不可能だ。

僕は逃げられない。日常に紛れ込む略語三文字英単語の世界から逃げることなんて、できやしなかったんだ。

僕はいつもプロレスのリング上にいるんだと、ようやく理解した。

こんな状況になっても、やっぱり誰も僕の話を信じてくれない。だけど、君は分かってくれるだろう？

三文字の英単語には何かしらの「技」が潜んでいる。

気をつけろ、リングの上に立っているのは、もう君も同じなんだ。

Permalink |記事への反応(0) | 15:09

ツイートシェア

■都道府県名を雑に英訳する

Permalink |記事への反応(3) | 11:40

ツイートシェア

■anond:20221125130739

https://ejje.weblio.jp/content/play

4 不可算名詞

a 動きのゆとり，ゆるみ;活動[作用]の自由.

Give some play to therope.ロープを少しゆるめなさい.

There's too much [little] play in the brakes.ブレーキの遊びが甘[堅]すぎる.

Permalink |記事への反応(0) | 13:13

ツイートシェア

■anond:20221114154059

君の縄。 -Yourrope.-　が秀逸過ぎたんだよ

Permalink |記事への反応(2) | 15:52

ツイートシェア

■20代前半女性が本当に着ているファッションブランドランキング

7/28に追記しました

一番下にあります

あと文章を一部修正しました

概要

3年前にこんなのを書いたんですけど

anond:20180624003725

20代前半女性版が必要になったので作りました！

ルール

年齢以外は前回と同じです

• 調査対象ブランドはWEARのこのページで投稿数が10000以上の321ブランド
  • これ以上はやる気ないし必要性も感じないです
  • 前回より87ブランド増えています
• そのブランドでコーデ検索をすると「そのブランドのアイテムを1つ以上使用したコーデ」が出るので、それを「性別：レディース,ユーザー：その他ユーザー,年齢：22歳～25歳」という条件で絞り込んだ結果件数を「20代前半女性による投稿数」とします
  • その他のユーザーで絞り込むのはブランドの宣伝用アカウントやブランドPRに協力していることもあるWEAR公認ユーザーなどを除外するためです
  • 20代前半と言いつつ20～24歳ではなく22～25歳で絞り込むのは、20代のうち大学生が多くを占めるであろう20～21歳を除外し、残りの22～29歳を半分に割って前半を22～25歳、後半を26～29歳としたためです
    • 分かりやすさを優先して20代前半女性と表記しています
• 20代前半女性による投稿数が1000以上だった135ブランドをランキングにしました
• 2日ぐらいで調べたので数自体はわりと正確だと思いますが、WEARを使って調べている以上WEARユーザーの好みに偏っていると思います
• 全体コーデ数は上に挙げたページに書いてある数ですがメンズ・レディース両方を取り扱っているブランドもレディースオンリーのブランドもあるので特に参考にはならないと思います
  • 今回は20代前半女性/全体で計算した20代前半女性率も載せてみます
• 「そのブランドのアイテムが使用されているコーデの数」によるランキングなので買う数が少ない靴、バッグ、腕時計などのブランドや汎用性の高いアイテムが人気のブランドは上位に来やすい傾向があると思います
• 調査対象コーデ数が女子大生版と違うと思うのでコーデ数の比較はできません

20代前半女性が本当に着ているファッションブランドランキング結果発表！！！

おわりに

135ブランド中前回から順位が最も低下したのは2016年に日本から撤退したAmerican Apparel(43位→109位)でした

店舗撤退やブランド終了といった事情が何もないブランドに限るとone way(69位→124位)になります

逆に上昇したのはTODAYFUL(180位→118位)、ROSE BUD(126位→75位)などです

おまけ:最近の撤退・終了まとめ

FOREVER 21(19位)

日本撤退:2019年10月末

9月末にアメリカの本社が経営破綻していました

E hyphen world gallery(41位)

ブランド終了:2020年7月31日

ストライプインターナショナルは他にearthmusic&ecology(12位)、Green　Parks(117位)、SEVENDAYS=SUNDAY(121位)、AMERICAN HOLIC(126位)などを展開しています

CECIL McBEE(129位)

店舗・EC撤退:2021年2月末

ステーショナリー、靴などに名前を貸すライセンス事業は継続するようです

ジャパンイマジネーションは他にAnk Rouge、BE RADIANCE、a.g.plusなどを展開していますがいずれも本ランキングでは調査対象外(全体コーデ数が10000未満)で、この中だとAnk Rouge以外も撤退とのことです

AmericanEagle(130位)

日本撤退:2019年12月末

7/28追記

コメントがたくさん来ていたので少し補足します！

ブランド名について

no brandはブランド名ではなく、文字通りノーブランド(ブランド不明)の服のことです

同様にVINTAGEは古着、Handmadeは手作りのものを指しています

サマンサモスモスがSM2とSamansa Mos2に分かれているのは冒頭に貼ったWEARのブランド一覧ページに2つ載っていたためです

こういうのを除外したり統合させたりしていると切りがないので全部そのままにしています

アイテム別ランキング

そっちの方が役立つとは思いますが面倒なので誰かお願いします

もしかして手動？

手動です

WEARユーザーの偏り

他にこういうサイトがないので仕方ないです

その他諸々

ちゃんとした調査ではなくあくまでもネタなので細かいことは気にしてません

Permalink |記事への反応(17) | 18:25

ツイートシェア

■低身長ガリ(男)向けの服のブランド

彼氏が165cm52キロ(これでも前は45キロしかなかったからマシになったほう)なので服の選択肢が少ない。今回は私が彼氏に色々と着せてみて調べた低身長ガリでもイケるブランド、無理なブランドを述べていく。

低身長ガリ大歓迎ブランド

・nanouniverse

・attachment

→低身長ガリのためのブランドと言ってもいい

　流行りのオーバーサイズはあんまりない

低身長ガリでもいけるよブランド

・beauty andyouthunited arrows

・united arrowsgreen label relaxing

・EDIFICE

・UNITEDTOKYO

・STUDIOUS(ココで扱ってるドメブラも基本ok!)

→基本いける、ものによっては無理

低身長ガリ厳しめブランド

・ADAMETROPE

・tomorrowland

・BEAMS

・Luis

・URBAN RESEARCH系列

・ジャーナルスタンダード

→セレクトショップだから一概には言えないけど

　サイズ感がでかい

低身長ガリお断りブランド　

・AURALEE

・COMOLI

・グラフペーパー

・1LDK

・flannel

・マーカウェア

　→まじで！！この辺は！！ガリは！！やめたほうがいい！！！ブッカブカなるから！！！！私もこの辺きてる男好きで、彼氏にも進めてみたけど全く似合ってなかった泣

あと、男も骨格診断は絶対やった方がいいです！！！私の彼氏はいわゆるウェーブだとわかってから、似合う服を選びやすくなった気がするので。

それから、足元！！ガリガリの人は靴はシンプルなやつのが合う！！私の彼氏も流行りのゴツいスニーカーに手を出してたけど、1色のものはともかくカラフルなハイテクスニーカーとかは全く似合わずでした・・・

Permalink |記事への反応(3) | 12:03

ツイートシェア

■anond:20200604142946

ザイル　も。

Seil　独語

rope　英語

Permalink |記事への反応(0) | 17:14

ツイートシェア

■anond:20190711174020

1930, "elasticrope," probably an extended use of the identicalword used in late 19c.British schoolboy slang for "rubber eraser;" this probablyismore or less onomatopoeic, from notions of bouncy + spongy.

オノマトペから来た可能性が高いので何語でもよさそうだぞ

Permalink |記事への反応(0) | 18:22

ツイートシェア

■20代後半女におすすめの通勤服のブランド

20代後半、オフィスカジュアルな服のおすすめのブランドあったら教えて欲しい

普段は、MISCH MASCH、Natural Beauty Basic、ROPE'PICNIC、UNIQLO当たりを買ってる

オフィスカジュアルな服ならokでジーパンや派手な服装はNG

フード付きのパーカージャケットも着て行ったことあるけど、何故か問題なかった

だから割と服装の基準は緩いのかも

UNIQLOは主にズボンを買ってる

それ以外とブランドではズボン以外を買ってる

雑誌とかの大半の服はなんで1万～2万近くするんだよ……

たまにプチプラも乗ってたりするけどさ

１着辺り、5000円～7000円以下のやつがいい

Permalink |記事への反応(0) | 23:39

ツイートシェア

■なわとびなわとびなわとび

「なわとび」に使う縄のことを「とびなわ」と言うらしいことを今知った。

英語で書くと、

なわとび(動) :jumprope

なわとび(名) :rope-jumping

とびなわ(名) :jumpingrope

そりゃそうか。

なわとびとびなわあいわなびいびわなわとび

わたしはびわになりたい

あいわなびあ

びーるがほしい

Permalink |記事への反応(1) | 01:46

ツイートシェア