あるIT現場4 論理在庫遅延と実績とフラグと月頭、月中でデータパターンは192通りある
あるIT現場4 論理在庫遅延と実績とフラグと月頭、月中でデータパターンは192通りある
いやしかし。
なんだかなぁ。
ようやく、仕様を理解し始めた東北の歳をとった方が、
データをわざわざ消して、なにかおかしいとかいいだしたが。
あるうるデータパターンは最大２４通りかな。
そして、処理パターンは２つ。
それなのに、１９２通りある組み合わせのいくつかを発見しては、
このときは、あーだとか、こーだとか。
今更なにをいっているのか。
自分で好きに直せばいいのにな。
１９２通りの決定表でもはじめにつくればいいだろう。
ないときは、０と考えあると考えると途中で変わった。
更に、０ではいけないと変わった。
その後、ヤッパリ０だな！
とか、もう、ない組み合わせであーでもないこーでもない。
１９２通りあるんだから、その全部のデータパターンを作り、
結果がなんでなければならないのか何故、顧客に確認しないのだろうか。
私の考えでは２通りなんだがな。
それなのに、次の日になると、
「・・・これはー・・・」
とかいうのだが。
多分しばらくすると、１９２通りの組み合わせで、処理しきれない現象が発生し、
また、「あーでもない、こーでもない」とやりだすのかもな。
東北の若い人Aはよくがんばっているが、
東北の歳をとったほうに使われるとダメになってしまう。
まあ、明日のなるとまた
なんか言い出すのかもしれない。
元請の人が仕切って、もっていって直すことになる可能性が大だ。
そうそう、今日、東北の歳をとったほうに、「不具合だ」といわれてあるものを修正したのだが、
他システムからやってくる、論理在庫と、実績の意味がわかっているのなら、そんなことは言わないだろう。
おそらく、まったく意味が分かっていない。
論理在庫は遅延する。
だから実績を優先する。
論理在庫は不正確。
だから実績の出庫、入庫と前の論理在庫から論理在庫を出す。
前の論理在庫がないのなら、新規に作成された保管場所である。
論理在庫は遅延しても不正確な数量が存在する。
だからないときは、０と考えることに決まっていたのだが。
いやしかし。
なんだかなぁ。
ようやく、仕様を理解し始めた東北の歳をとった方が、
データをわざわざ消して、なにかおかしいとかいいだしたが。
あるうるデータパターンは最大２４通りかな。
そして、処理パターンは２つ。
それなのに、１９２通りある組み合わせのいくつかを発見しては、
このときは、あーだとか、こーだとか。
今更なにをいっているのか。
自分で好きに直せばいいのにな。
１９２通りの決定表でもはじめにつくればいいだろう。
ないときは、０と考えあると考えると途中で変わった。
更に、０ではいけないと変わった。
その後、ヤッパリ０だな！
とか、もう、ない組み合わせであーでもないこーでもない。
１９２通りあるんだから、その全部のデータパターンを作り、
結果がなんでなければならないのか何故、顧客に確認しないのだろうか。
私の考えでは２通りなんだがな。
それなのに、次の日になると、
「・・・これはー・・・」
とかいうのだが。
多分しばらくすると、１９２通りの組み合わせで、処理しきれない現象が発生し、
また、「あーでもない、こーでもない」とやりだすのかもな。
東北の若い人Aはよくがんばっているが、
東北の歳をとったほうに使われるとダメになってしまう。
まあ、明日のなるとまた
なんか言い出すのかもしれない。
元請の人が仕切って、もっていって直すことになる可能性が大だ。
そうそう、今日、東北の歳をとったほうに、「不具合だ」といわれてあるものを修正したのだが、
他システムからやってくる、論理在庫と、実績の意味がわかっているのなら、そんなことは言わないだろう。
おそらく、まったく意味が分かっていない。
論理在庫は遅延する。
だから実績を優先する。
論理在庫は不正確。
だから実績の出庫、入庫と前の論理在庫から論理在庫を出す。
前の論理在庫がないのなら、新規に作成された保管場所である。
論理在庫は遅延しても不正確な数量が存在する。
だからないときは、０と考えることに決まっていたのだが。
一気にスパムペタを削除しよう 妙なペタのIDの468881個のリスト リリース
一気にスパムペタを削除しよう 妙なペタのIDの468881個のリスト リリース
スパムIDは前回から２０００強増加しました。
妙なペタのIDの468881個のリスト リリース 一気にスパムペタを削除できます
■drunken推奨、ペタ削除対象、amebaIdのリスト
2014-06-22版 468881 ID
http://www.geocities.jp/tool_bou/tool/ame_peta/index.html
ameblo peta backup tool
■妙なペタの削除方法
ameblo peta backup toolを起動
F:ついたペタ削除を選択
自分のamebaId とパスワードを入力
①削除したいペタ amebaIdを入力欄に削除したいamebaIdを入力
(入力には、drunken推奨、ペタ削除対象、amebaIdのリスト、または、
削除したい、amebaIdを入力してくだだい)
②ついたペタ削除実行を押す
すると削除が始まります。
■(ameblo peta backup tool)ペタバックアップツール保管場所
ダウンロード場所⇒の一番下の方
2013-11-17 リリース済み
Ver 0.0.21
http://www.geocities.jp/tool_bou/tool/ame_peta/index.html
ameblo peta backup tool
スパムIDは前回から２０００強増加しました。
妙なペタのIDの468881個のリスト リリース 一気にスパムペタを削除できます
■drunken推奨、ペタ削除対象、amebaIdのリスト
2014-06-22版 468881 ID
http://www.geocities.jp/tool_bou/tool/ame_peta/index.html
ameblo peta backup tool
■妙なペタの削除方法
ameblo peta backup toolを起動
F:ついたペタ削除を選択
自分のamebaId とパスワードを入力
①削除したいペタ amebaIdを入力欄に削除したいamebaIdを入力
(入力には、drunken推奨、ペタ削除対象、amebaIdのリスト、または、
削除したい、amebaIdを入力してくだだい)
②ついたペタ削除実行を押す
すると削除が始まります。
■(ameblo peta backup tool)ペタバックアップツール保管場所
ダウンロード場所⇒の一番下の方
2013-11-17 リリース済み
Ver 0.0.21
http://www.geocities.jp/tool_bou/tool/ame_peta/index.html
ameblo peta backup tool
あるIT現場4 以上とイコールは天地の差 イブキの尻を揉んで見たい 実績があがってこないから、過
あるIT現場4 以上とイコールは天地の差 イブキの尻を揉んで見たい 実績があがってこないから、過去の実績+論理在庫が必要になっちまったよー
あーっ。
どうして、こうなるのか。
５本程度の改修を担当している。
現行とさほど違いがない改修だった。
が、もつれた。
なんども、なんども作り直しをした。
仕様も３人あつまると、３人それぞれ別のことを言い出す。
前々月、前月が１月ずれているひともいるし。
未来の実績が存在するから、あーだ、こーだ、うーだ始まる。
１つ目、FROM, TO があるのだが、FROMがイコールの意味であることも発生。
現行では、以上なのだが。
実績をみるときは、論理在庫の日付のFROMより前々月と前月を見る。
論理在庫を見るときは、FROMはイコールのものつまり当月を見る。
戦略ツールは、where句の一部
db.owner.仮想表名.FROM_日付 >= 入力日付
を渡してくる。
もうこのへんで、無理がある。
==========================
ん？な感じ
select
...
from
(
select
...
min(実績日) FROM_日付,
sum(実績) 実績_合計,
...
from 実績_T
group by
ビジネスグループ,
会社,
部門,
倉庫,
棚,
実績日
) db.owner.仮想表名
where #xxx#-FROM_日付
...
==========================
入力日が直接もらえない。
戦略ツールは、 #xxx#-FROM_日付を
db.owner.仮想表名.FROM_日付 >= 入力日付
と置換する。
だから、) db.owner.仮想表名
と一旦、インラインにくくるのだが、
以上の >= だから
min しても、入力日付と同じとは、限らない。
せめて、イコールの = でくればいいのだが、
イコールに直すことは、
改修対象外のものに、大影響が発生するので、無理。
しかた、ないから、カレンダーを導入し、それにFROM_日付がぶち当たるようにした。
そこで、min すれば、必ず、入力日付がなんであったか分かる。
しかし、入力日付の範囲が、遠い過去の 紀元前 を示す -1000-01-01 なのか、
とほい未来の 3001-12-13 なのかは、決めるのが難しい。
システム的に制限を設けるのは、まずいらしいので、
DB の制限値、0000-01-01 から 9999-12-31 の
カレンダーを作成するはめになった。
それで、結構上手くいったが、
多段階の沢山のインラインビューが発生すると、
全部インデックスDB が、このDBのバージョンではサポートされていないと
エラーメッセージを返す。
サポートされていないというところまで、パースできるなら、
サポートしてくれればいいのに。
また、大規模表の外部結合を、なんども繰り返すと、結果が不安定になる。
パフォーマンスを良くするため、スタークエリー？、サブクエリーをselect句にぶち込んで、
多段階のインラインビューにすると、
これまた、結果が不安定になる。
現場で採用されている全部インデックスDBは、バージョンが４世代ぐらい古いようだ。
SQL92 ににも、準拠していないところがあるようで、独自拡張は激しい。
マニュアルも雑だ。
全部インデックスDB は、使用カラムは３つ程度までが限度だ。
それ以上を使うと、応答が遅くなるし、結果が不安定になる。
こりゃつらい。
それでも、明日はなんとかしたいな。
あーっ。
どうして、こうなるのか。
５本程度の改修を担当している。
現行とさほど違いがない改修だった。
が、もつれた。
なんども、なんども作り直しをした。
仕様も３人あつまると、３人それぞれ別のことを言い出す。
前々月、前月が１月ずれているひともいるし。
未来の実績が存在するから、あーだ、こーだ、うーだ始まる。
１つ目、FROM, TO があるのだが、FROMがイコールの意味であることも発生。
現行では、以上なのだが。
実績をみるときは、論理在庫の日付のFROMより前々月と前月を見る。
論理在庫を見るときは、FROMはイコールのものつまり当月を見る。
戦略ツールは、where句の一部
db.owner.仮想表名.FROM_日付 >= 入力日付
を渡してくる。
もうこのへんで、無理がある。
==========================
ん？な感じ
select
...
from
(
select
...
min(実績日) FROM_日付,
sum(実績) 実績_合計,
...
from 実績_T
group by
ビジネスグループ,
会社,
部門,
倉庫,
棚,
実績日
) db.owner.仮想表名
where #xxx#-FROM_日付
...
==========================
入力日が直接もらえない。
戦略ツールは、 #xxx#-FROM_日付を
db.owner.仮想表名.FROM_日付 >= 入力日付
と置換する。
だから、) db.owner.仮想表名
と一旦、インラインにくくるのだが、
以上の >= だから
min しても、入力日付と同じとは、限らない。
せめて、イコールの = でくればいいのだが、
イコールに直すことは、
改修対象外のものに、大影響が発生するので、無理。
しかた、ないから、カレンダーを導入し、それにFROM_日付がぶち当たるようにした。
そこで、min すれば、必ず、入力日付がなんであったか分かる。
しかし、入力日付の範囲が、遠い過去の 紀元前 を示す -1000-01-01 なのか、
とほい未来の 3001-12-13 なのかは、決めるのが難しい。
システム的に制限を設けるのは、まずいらしいので、
DB の制限値、0000-01-01 から 9999-12-31 の
カレンダーを作成するはめになった。
それで、結構上手くいったが、
多段階の沢山のインラインビューが発生すると、
全部インデックスDB が、このDBのバージョンではサポートされていないと
エラーメッセージを返す。
サポートされていないというところまで、パースできるなら、
サポートしてくれればいいのに。
また、大規模表の外部結合を、なんども繰り返すと、結果が不安定になる。
パフォーマンスを良くするため、スタークエリー？、サブクエリーをselect句にぶち込んで、
多段階のインラインビューにすると、
これまた、結果が不安定になる。
現場で採用されている全部インデックスDBは、バージョンが４世代ぐらい古いようだ。
SQL92 ににも、準拠していないところがあるようで、独自拡張は激しい。
マニュアルも雑だ。
全部インデックスDB は、使用カラムは３つ程度までが限度だ。
それ以上を使うと、応答が遅くなるし、結果が不安定になる。
こりゃつらい。
それでも、明日はなんとかしたいな。
あるIT現場4 push してくれない、オプティマイザー
あるIT現場4 push してくれない、オプティマイザー
戦略ツールの都合で、じかに条件値だけを見ることができない。
条件全部がやってくる。
戦略ツールと表が合わない。
人間なら、深い深い深い深い深い深い深い深いそのビューの中の
ビューの中のビューのかなの
底に、条件値を入れて、最適ができるのだが。
今回使用している、縦のDBは、深い深いあたりで、最適化を止めている。
それでも、その最適化は、特許取得済みとかマニュアルに書いてある。
使えん、全く使えん。
戦略ツールが条件の全部ではなくて、
条件値をわたしてくれれば、いいだけなんだけどな。
戦略ツールの開発者は、現場で使われる表が
とんでもないものだとは、考えることができないのかな。
そうじゃなくて、表がこんなんじゃなければ、こんなことにはならんのだろう。
戦略ツールの都合で、じかに条件値だけを見ることができない。
条件全部がやってくる。
戦略ツールと表が合わない。
人間なら、深い深い深い深い深い深い深い深いそのビューの中の
ビューの中のビューのかなの
底に、条件値を入れて、最適ができるのだが。
今回使用している、縦のDBは、深い深いあたりで、最適化を止めている。
それでも、その最適化は、特許取得済みとかマニュアルに書いてある。
使えん、全く使えん。
戦略ツールが条件の全部ではなくて、
条件値をわたしてくれれば、いいだけなんだけどな。
戦略ツールの開発者は、現場で使われる表が
とんでもないものだとは、考えることができないのかな。
そうじゃなくて、表がこんなんじゃなければ、こんなことにはならんのだろう。
あるIT現場4 昔、沖電気の全部インデックス DB とういのがあった2
あるIT現場4 昔、沖電気の全部インデックス DB とういのがあった2
いやー。縦のDBは、今の現場の担当分には余り向いていない。
何しろカラムが多くなると徐々に遅くなってくる。
計算量が大きい分野なので、レコード数が業務向け横DBに比べると２桁くらい多い。
カラムにキーと数値だけならカラムが少し多くても何とかなるけど。
コード値とか日付を持つカラムが絡んでくると、極端に遅くなる。
何しろ、色んなカラムが沢山あるから、何かの結果を出したり、検索したりするのに、カラムを沢山使う。
すると、横DBの方が早いんじゃないかな。
rollup とか cube ウインドウ関数とか集合関数は早いんだけどな。
業務要件のことをやると。
どうしても、３秒とかかかっちゃうんだよ。
どうして、秒の単位の時間がかかっちゃうのか見えない。
まあ、扱っている量が内部的に、数千万とかに膨らむから仕方ないんじゃないかな。
連係もとのデータ、縦のDBの表定義、縦のDB、戦略ツール。
この組み合わせで、縦のDBの表定義が問題ありだ。
戦略ツールの制限もきつい。
連係もとの横DBをそのまま、使っていることが多い。
また、加工しても、横DB風にしちゃってる。
それは仕方ないかも知れない。
組織階層を縦に並べ替えて、
並べ替えを繰り返し、２次元風にしている。
元は横長だったのかも知れないが。
縦に並べ替えた結果、量が１００倍とかになる。
あることを行おうとすると、重複が発生していまう。
そこに戦略ツールの制限があって、全件処理した後に、
結果を一つだけとかになる。
組織階層は、親子だけにして、親子、孫、・・・
を２次元にする理由は、戦略ツールの制限を避けるためかもしれないが。
重複は回避が難しい。戦略ツールの別な制限がでてくる。
やっぱり、階層は、
階層問い合わせで扱うのが一番だと思う。
階層問い合わせなら、戦略ツールの２つの制限を突破できるのだが。
ある相当できると思われる技術者が、戦略ツールの２つの制限をとっぱするため、
がんばっているのだが。
階層分の制限の回避がからんできて、
終わるのかどうかもわからんらしい。
部品表展開とか、組織階層展開とかでてきたら、
まず考えるのは、部分的に親子ならそれはそのままで、いい。
そして、系列とか知りたいなら、階層問い合わせする。
系列を、２次元の表に展開し直すとかしないほうがいいよ。
月曜日にどうなってるのか。
うまくいってるといいな。
いやー。縦のDBは、今の現場の担当分には余り向いていない。
何しろカラムが多くなると徐々に遅くなってくる。
計算量が大きい分野なので、レコード数が業務向け横DBに比べると２桁くらい多い。
カラムにキーと数値だけならカラムが少し多くても何とかなるけど。
コード値とか日付を持つカラムが絡んでくると、極端に遅くなる。
何しろ、色んなカラムが沢山あるから、何かの結果を出したり、検索したりするのに、カラムを沢山使う。
すると、横DBの方が早いんじゃないかな。
rollup とか cube ウインドウ関数とか集合関数は早いんだけどな。
業務要件のことをやると。
どうしても、３秒とかかかっちゃうんだよ。
どうして、秒の単位の時間がかかっちゃうのか見えない。
まあ、扱っている量が内部的に、数千万とかに膨らむから仕方ないんじゃないかな。
連係もとのデータ、縦のDBの表定義、縦のDB、戦略ツール。
この組み合わせで、縦のDBの表定義が問題ありだ。
戦略ツールの制限もきつい。
連係もとの横DBをそのまま、使っていることが多い。
また、加工しても、横DB風にしちゃってる。
それは仕方ないかも知れない。
組織階層を縦に並べ替えて、
並べ替えを繰り返し、２次元風にしている。
元は横長だったのかも知れないが。
縦に並べ替えた結果、量が１００倍とかになる。
あることを行おうとすると、重複が発生していまう。
そこに戦略ツールの制限があって、全件処理した後に、
結果を一つだけとかになる。
組織階層は、親子だけにして、親子、孫、・・・
を２次元にする理由は、戦略ツールの制限を避けるためかもしれないが。
重複は回避が難しい。戦略ツールの別な制限がでてくる。
やっぱり、階層は、
階層問い合わせで扱うのが一番だと思う。
階層問い合わせなら、戦略ツールの２つの制限を突破できるのだが。
ある相当できると思われる技術者が、戦略ツールの２つの制限をとっぱするため、
がんばっているのだが。
階層分の制限の回避がからんできて、
終わるのかどうかもわからんらしい。
部品表展開とか、組織階層展開とかでてきたら、
まず考えるのは、部分的に親子ならそれはそのままで、いい。
そして、系列とか知りたいなら、階層問い合わせする。
系列を、２次元の表に展開し直すとかしないほうがいいよ。
月曜日にどうなってるのか。
うまくいってるといいな。
あるIT現場4 昔、沖電気の全部インデックス DB とういのがあった
あるIT現場4 昔、沖電気の全部インデックス DB とういのがあった
今の現場で担当しているDBの１つは、基本、縦で、全部インデックスであり、
表は、インデックスのビューとなっている。
（横にも格納できるオプションがあるらしい)
縦だから、一括投入は早い。
検索も、少ないカラムのときは早い。
集合関数も早い。
どのような検索に対しても、チューニングが殆ど不要で検索は、早いことになっているのだが。
カラムを沢山指定すると、とてつもなく遅い。
そして、DBを使うインターフェースとの相性がものすごーく、合わない。
表をいくつか結合すると、段々遅くなってくる。
他システムから取り込むデータを表に一括投入する仕組みになっているが、表の定義が、どうも、いまいちだ。
カラム数が多すぎる。
意味は同じだが、キーがことなり、同じ意味をもつキーが複数ある。
そういう表とキーが複数ある。
戦略を練る為のインターフェースになっているので、
何をどう選択されるか分からない。
結果、内部的には、殆ど全カラム持ってくることになる。
そして、１０億カラム持ってきても、使うのは、１万カラムくらいになる。
だから、物凄く、無駄が発生している。
そういう、無駄な、検索が多い。
はじめから、１万カラム指す検索は可能だが、
間に入っているインターフェースの都合で、
それは、やりにくことが多い。
チューニングすることになっているらしいが、
どうチューニングしたものか。
表を全部直すとか、インターフェースを開発元に直してもらうとか
しないとだめかもしれない。
今の現場で担当しているDBの１つは、基本、縦で、全部インデックスであり、
表は、インデックスのビューとなっている。
（横にも格納できるオプションがあるらしい)
縦だから、一括投入は早い。
検索も、少ないカラムのときは早い。
集合関数も早い。
どのような検索に対しても、チューニングが殆ど不要で検索は、早いことになっているのだが。
カラムを沢山指定すると、とてつもなく遅い。
そして、DBを使うインターフェースとの相性がものすごーく、合わない。
表をいくつか結合すると、段々遅くなってくる。
他システムから取り込むデータを表に一括投入する仕組みになっているが、表の定義が、どうも、いまいちだ。
カラム数が多すぎる。
意味は同じだが、キーがことなり、同じ意味をもつキーが複数ある。
そういう表とキーが複数ある。
戦略を練る為のインターフェースになっているので、
何をどう選択されるか分からない。
結果、内部的には、殆ど全カラム持ってくることになる。
そして、１０億カラム持ってきても、使うのは、１万カラムくらいになる。
だから、物凄く、無駄が発生している。
そういう、無駄な、検索が多い。
はじめから、１万カラム指す検索は可能だが、
間に入っているインターフェースの都合で、
それは、やりにくことが多い。
チューニングすることになっているらしいが、
どうチューニングしたものか。
表を全部直すとか、インターフェースを開発元に直してもらうとか
しないとだめかもしれない。
あるIT現場4 仮想倉庫 仮想保管場所 仮想保管棚 仮想在庫数 仮想口座 仮想残高 仮想貸越 仮
あるIT現場4 仮想倉庫 仮想保管場所 仮想保管棚 仮想在庫数 仮想口座 仮想残高 仮想貸越 仮想極度額 仮想ABC分析
今の現場は、仮想シリーズが多い。
仮想と実、仮想とリアル。
表にキーも多い。
キーでないもの、何故か、キーになっている。
無理な、項目。
仮想倉庫は、入出庫なしに在庫が増減する。
仮想計画数は、計画なしにしばらくするとじゃんじゃん、在庫が増えてゆく。
仮想口座は、入金なしに、何故か、０円から仮想利息？？？？でもつくのか、
残高が、増えてゆく。
いいな、そんな仮想銀行口座。
だが、ある仮想口座は、出金なしに、極度まで、貸越となる。
やだな、そんな仮想銀行口座。
仮想口座を開設し、入金と出金を合算しても、仮想残高と一致しない。
とても、決算おわると思えない。
今の現場は、仮想シリーズが多い。
仮想と実、仮想とリアル。
表にキーも多い。
キーでないもの、何故か、キーになっている。
無理な、項目。
仮想倉庫は、入出庫なしに在庫が増減する。
仮想計画数は、計画なしにしばらくするとじゃんじゃん、在庫が増えてゆく。
仮想口座は、入金なしに、何故か、０円から仮想利息？？？？でもつくのか、
残高が、増えてゆく。
いいな、そんな仮想銀行口座。
だが、ある仮想口座は、出金なしに、極度まで、貸越となる。
やだな、そんな仮想銀行口座。
仮想口座を開設し、入金と出金を合算しても、仮想残高と一致しない。
とても、決算おわると思えない。
一気にスパムペタを削除できます 妙なペタのIDの466768個のリスト リリース
妙なペタのIDの466768個のリスト リリース 一気にスパムペタを削除できます
■drunken推奨、ペタ削除対象、amebaIdのリスト
2014-05-11版 466768 ID
http://www.geocities.jp/tool_bou/tool/ame_peta/index.html
ameblo peta backup tool
■妙なペタの削除方法
ameblo peta backup toolを起動
F:ついたペタ削除を選択
自分のamebaId とパスワードを入力
①削除したいペタ amebaIdを入力欄に削除したいamebaIdを入力
(入力には、drunken推奨、ペタ削除対象、amebaIdのリスト、または、
削除したい、amebaIdを入力してくだだい)
②ついたペタ削除実行を押す
すると削除が始まります。
■(ameblo peta backup tool)ペタバックアップツール保管場所
ダウンロード場所⇒の一番下の方
2013-11-17 リリース済み
Ver 0.0.21
http://www.geocities.jp/tool_bou/tool/ame_peta/index.html
ameblo peta backup tool
■drunken推奨、ペタ削除対象、amebaIdのリスト
2014-05-11版 466768 ID
http://www.geocities.jp/tool_bou/tool/ame_peta/index.html
ameblo peta backup tool
■妙なペタの削除方法
ameblo peta backup toolを起動
F:ついたペタ削除を選択
自分のamebaId とパスワードを入力
①削除したいペタ amebaIdを入力欄に削除したいamebaIdを入力
(入力には、drunken推奨、ペタ削除対象、amebaIdのリスト、または、
削除したい、amebaIdを入力してくだだい)
②ついたペタ削除実行を押す
すると削除が始まります。
■(ameblo peta backup tool)ペタバックアップツール保管場所
ダウンロード場所⇒の一番下の方
2013-11-17 リリース済み
Ver 0.0.21
http://www.geocities.jp/tool_bou/tool/ame_peta/index.html
ameblo peta backup tool
あるIT現場4 勤務場所また、変更になった
あるIT現場4 勤務場所また、変更になった
いままでは、わりに家から近かったんだけど
今度の場所は、都内だが、遠い。
駅からも遠い。
とても不便な場所。
仕事は、ようやく少し動き出した。
いままでは、わりに家から近かったんだけど
今度の場所は、都内だが、遠い。
駅からも遠い。
とても不便な場所。
仕事は、ようやく少し動き出した。