ティアのホームページ☆ミ:Page 146 oC
<<< << < prev3$F? 146/554ページ(1661件) $FAnext3 > >> >>>
To Close..ゆゆゆ その2 2014年12月22日15時29分
先日書いたここの予想と、実際のアニメの進捗は、合っている部分もあれば、間違っている部分が大半のような感じですが、

それで居ても、大筋は余り間違えていなかったように感じます。



12話まで見てない人は、見てからの方が良いですよ??

11話までのネタバレを含んでいます☆




神樹様がどう言う存在なのかは、軽く本編で触れられていましたが・・・

まさか、四国以外滅んでいるとは思いもしませんでした。

贄システムは、そのまんまの贄のようで、前勇者との欠損部分は特に関係が無いみたいですけど

勇者システムを乗り越えて勇者として完成するかと思っていた、その辺りのお話は、
東郷さんの機転により、あっさり滅亡か、勇者かの2択になってしまって、わっし〜さすが!

どっちが原作か微妙に判らないけど、わっし〜の話が本になっていますよね。

初めは、どんだけパクった話かと思っていたんですが、そうですか、東郷さんの話ですか。


初めてこの作品を見たときは、良く有る感じの学生が勇者やってる程度かと思っていたんだけど、5話で敵全滅とか、ありきたりでは無いと思いました。

その時点では、話がどっち方面に進むのかが不透明だったので円盤買うかちょっと悩んだんですけどね?
ここ(12話)まで来たら、話の最後がどう転ぼうとも買うことにしまして、取りあえず注文したんですが・・・・
12/25入荷だそうです。

売り切れか〜、

限定版のゲームには特にこだわってないけど、それ以外の仕様が違ったらヤダな?とか思っては居ます。


他、異能バトルは日常系のなかでとか、買おうかなとか?思わなくも無いけど、
原作の方もちょろっと最新刊が途中で放置になっているけど、
急にお金が必要になって貯めることになったので、円盤沢山買っていられないので、中古が安くなってセット売りになってから買うかな?って感じ?


それはそれとして、あれだけの小さな空間では、
1.携帯は作れない。
 レアメタルとか必要ですから、日本だけでは作れません。
2.それ以前の環境平衡
 エコシステムとしての循環が成り立たないサイズ
3.襲撃がとても頻繁
 例え勇者システムが有っても、そう遠くない未来にいずれ全員が神樹様の贄になって終了
4.壁の向こう
 実は、壁が撃退時のみ有るんだと思っていたんだけど、常にあるのが笑った。
 世界の果てが見えるってどう考えてもおかしい。
 閉鎖後に生まれた人はそうかもしれないけど、閉鎖前から生きている人って居ないのかな?情報統制とかどうしたんだろう?

ある日奴らがやってきた→神様頑張った→箱庭が残った

まぁ、1日2日くらいは世界中が戦ったかもしれないけど、その僅かの間に、人的、経済的、技術的な資源を集めること何て不可能ですから、たまたまあそこだけ残ったのでしょうね?

あの壁の中ってどんなに長く保っても100年かそこらが限界でしょ?

やっぱり、神樹様じゃ無い柱が必要じゃ無いかな?それで、バーテックスの奴らを根本的に解決しないと、今日明日を生きるだけになっちゃうんじゃ無いかと思う。

バーテックスそのものに対する情報があたしには無いから何とも言えないんだけど

何らかの条件を満たせば、居なくなるのか、それとも全滅させないとイケないのか、その辺りがさっぱり分からないわね。


ああいうのを見ると、地球って、やっぱりこのサイズ無いと生物は生きられないよね? とか思うのです。
閉じる
テーマ:日記 URL:https://tsukiyori.sakura.ne.jp/index_m.cgi?ID=1226
 
To Close..だから、それを不具合という 2014年12月20日12時31分
具合が正常では無い状態。それを不具合と言います。

プログラムを作る上で、不具合というのは基本的に無い様に作っています。


今のプログラムは関数型が主だったもので、

aというパラメータを入れるとそれを計算した結果のAを出力します。

これは非常に固定的な物で、いつ、何処で、どんな風に、実行しようとも変わりません。


ですから、不具合が発生するはずが無いのです。

ゲームの場合も、アプリケーションでも、それらは変わりません。


ただ、パラメータが一つでは無く複数有るだけの話です。

パラメータが複数有ると、パラーメータの一つがちょこっと変わっただけで、画面上では大きく違う動作を行うことがあります。

それでも、全てのパラメータを正しく、順番通り、処理すれば不具合など発生しないのです。

それが、プログラムの利点で有り、プログラムの限界でもあります。


でも、それが故に、本来不具合は発生しないのです。
それでも、不具合が起きる。ユーザーから苦情が来る。

制作者は死にものぐるいで不具合の原因を突き止め、それを修正する。


大抵は、「全てのパラメータを正しく順番通りに処理」していないから起きます。


プログラムの作成は大抵、半年〜数年掛けます。


また、商品の寿命が長ければ、機能強化やらなにやらアップデートを繰り返すことになります。


作り始めた当初と、作り込んでいく先でプログラムに 新型と旧型が混ざることになります。


新型のプログラムというのは、これまで有った不具合を但し、新しく追加した機能のために様々なパラメータが増えたりしています。

しかし、古い方にはそう言った物が一切ありません。

大抵は、追加した機能により修正した部分よりも、何も変更しても居ない部分で発生することが多かったりもします。


でも、それ以上に問題なのは、連携です。

プログラム1とプログラム2の間で、取り決められている条件の物でパラーメータを遣り取りし、お互いに補完し合いながら動作することがあります。

しかし、プログラム1はアップデートしていないのに、プログラム2だけアップデートするなどで、取り決められた当初とは違うパラメータの遣り取りが発生する場合があります。

本来であれば、プログラム1側で、定められた範囲外のパラメータに対しては、プログラム2にエラーを返したり。

予め、プログラム2と連携するときに相手のバージョンを確認するなどの対応があれば、不具合が発生しないのですが・・・

相手側が一切情報を公開していない場合はどうなるのでしょうか??


ようするに、OneDriveの事です。


REST APIはあれもこれも色々と出来ると言っていますが。実際に始めると、色々と出来ないことが多いのが分かります。

じつはブラウザを利用したり、MS純正のOneDriveアプリを利用したりすると、ファイルの更新日が正しく反映されていたり、100M以上のファイルが送れたりします。

REST APIにはファイルが大きい場合は分割送信が出来ると書いてあり、 HTTP1.1のページへの誘導を行って、Range パラメータを利用することで、大きいファイルの送信が可能と言っていますが・・・、

multipart/byteranges
とか
Range
の話ですが、どれもこれも、サーバーのレスポンスの話として書いてあって、クライアントからの送信時に使えるかは分かりません。

いずれ試してみますが、WebClientではサポートしていないので、自分でバイナリデータを作ってやってみるしか有りません。

ようするに、OneDriveと、同期を取る方法として、現在公開されている範囲のRESTでは不完全なわけです。


「100M以上のファイルがあると同期が正常に取れない。」 これが一つ目の不具合です。


しかも、それだけじゃ有りません。


今作っているソフトは、OneDriveとクライアントで同期を取るだけで無く、一方的にアップロードすることや、一方的にダウンロードすることも出来ます。

ようするに、相互に最新の物を優先する方法と、 クライアントにあるのを絶対のマスターとすること、逆に鯖にある物をマスターとすることが可能になっています。

で、OneDriveのREST手引きには、「自動的にアップロードする様なアプリの作成は控えるべき」と書かれていましたが、ならば、一方的なダウンロードには特に問題が無いと言うことに成ります。


先述の通り、ファイルの更新日などが正常に反映されない、させる方法が公開されていないREST APIで更新するくらいなら、ブラウザでアップロードする方が楽かもしれません。

で、実験してみると、これがまぁ、不具合が出るのです。


サイズが100M以上有るから?

それも違います。
先日500M以上のファイルをなんの問題なくダウンロード出来ました。

じゃぁ、何か?


これまで、テストと称してダウンロードを始めたのですから、初めてのダウンロードです。

当然です。

ディレクトリも全部自動作成です。
それにもかかわらず、ダウンロード時にエラーが出るのです。

エラーを詳細に追ってみると、あり得ない場所であり得ないエラーが出ていたのです。

先ほどの通り、初ダウンロードです。
フォルダ自体も、事前に作っています。

しかし、根本的なところとして、事前にファイルがあった場合、それと差し替える機能を作ってあります。

そして、その差し替え機能が動作していました。

ダウンロードは、そもそも異なる名前でする用になっています。
違うファイル名でダウンロード、現在のファイルを別名に変更、新しいファイルを正しいファイル名に変更、古いファイルを削除、

そう言った手順です。

エラー処理も多重に入れており、いざというときは、旧ファイルで復旧出来るようにしてあります。
まず1つめの問題。
何故、ファイルがあったか。

考えられることは一つしかありません。2回ダウンロードしたからです。

ファイルリストに何らかの影響で、同名のファイルが二つあったのです。
ファイルリストはOneDriveに提出して貰っているので、履歴か何かの影響で複数合ったのでしょう。
2つ目の問題。
先ほどの通り、置き換えるようにプログラムを作っています。
例え2回ダウンロードしたとしても、後からダウンロードしたのが優先されるだけでエラーが出るはずがありません。

しかし、フォルダを見てみると、ファイルがありません。

ファイルは単純に、moveで順番に更新しているだけなので、消えるはずがありません。

しかも、ダウンロードしたファイルがありません。既存のファイルを大体のファイル名に変更した物はあるのに、ダウンロードしたファイルがありません。

一応、ダウンロード時にエラーが出た場合は、エラー処理を行いますので、それはそれで問題はありません。

ダウンロードを完了したのに、ダウンロードしたファイルが無い。

それが、今回の不具合です。


では、原因は何故でしょうか?

もちろん、2回同じファイルをダウンロードしようとしたこともあるでしょうが、もう一つが
1回目のダウンロードです。

1回目は別名でダウンロードしますが、特別な名称ではありません。
単に適当な文字列を追加しただけで、ユニークではありません。

別名で保存−>正式なファイル名で保存。
2回目の実行時ですが、先に別名の方を削除するプログラムを先頭に入れています。
そして、ファイルがある場合はエラーで返すことになっていますので、ここまでは問題ありませんし、別名でダウンロードした後、既存のファイルがある側の処理にうつっています。

ここで、既存のファイルの代替への変更が完了しています。
ここまでは実行されているのでエラーはこの後と言うことに成ります。

ダウンロードしたファイルを正しいファイル名へ変更ですが、ここでファイルが無いのでエラーになっています。

考えられるのは、ダウンロードのエラーですが、エラーその物は発生していないし、もう一つで言えば、ダウンロードは正常に終了したのに、ファイルは作られなかった。

ですね。


これらのことより
1.同じファイル名があったら、どちらをダウンロードするか判断する。
2.例外が発生しなくてもダウンロードが失敗していないか確認する必要がある。

ですね?
2.に付いては、事前のファイル情報を受信したときに、ファイルサイズとか調べておかないと分かりませんね? あと、ファイルの時間とかも更新日付で修正した方が良いかもしれません。


ある程度連続でダウンロードするとファイルの受信が出来ない。これが二つ目の不具合です。

ちなみに、ある程度は結構なファイル数です。
また、詳細なテストのために暫く放置していたためか、それ以降のファイルが全く受信出来なくなっていました。

閉じる
テーマ:日記 URL:https://tsukiyori.sakura.ne.jp/index_m.cgi?ID=1225
 
To Close..進まない原稿 ※続き追加しました。 2014年12月19日07時29分
土日にしか書いてないので、当たり前なんですが?
静波に履かせるパンツを何にするか考えた結果、その辺で売っている可愛いのを片っ端から買い集めて検討しました(笑)

レースでフリフリなのも可愛いですが、無地なのや、チェック、縞模様も好きだし、
結構迷う。

それはそれとして、パンツを見る上で、一番可愛いポーズと言うのはほぼ決まりました。

「パンツの見える人物が可愛い」ではなくね

パンツはそもそも前と後ろと、二通りの見られ方が想定されていると思うのです。

パンチラやら、脱がされている最中とか、スカートなら、めくられている時もかな?

前からなら、アソコを中心とした、V字、ボクサータイプ?なら、M字?
まーV字と言っても下は尖っていないので何字でしょね?

アソコの緩やかなカーブ、ソコへ向けての多数の引っ張りジワ、模様の歪み、真ん中に筋が入っていると、陰唇のプックリ感や柔らかさが見て取れるわね☆

シンプルな無地を書き込んでも良いし、チェックを歪ませても良いわね☆

ボクサータイプだと、足の付け根への引っ張りジワがさらに増え、アソコへの、集中゛力゛か、上がるわ?
さらには腿の部分が、程よい横じわで内腿の詳細なディテールと、パンツと太股の境目がむっちり感を出す。

前からはアソコの可愛さが余す事無く表現できるけど、ただのエロよね(笑)

どんだけ可愛くても、履いている娘のエロさが、引き立つだけ。

前からじゃパンツの可愛さを表現しきれないわ?


続きは、次号 続きです・・・・


なので、Tバックは論外なのです。

Tバックに対して、フルバックとか言うらしいのですが?

お尻を柔らかく包み込む生地、お尻に合わせて変幻自在な伸縮を行う。


バックプリントがあるもの、生地自体に柄があるものとか色々とありますが、この場合、無地はちょっぴり残念感が大きいです。


後ろ側における最大のポイントは、お尻その物が割れていることに起因する、伸びと緩みです。
また、下部は・・・クロッチの前側はアソコを柔らかく包み込む反面、後ろ側はお尻の割れ目に挟まれます。

この割れ目に沿って進みながらも、フルバック所以の生地が左右に引っ張られ、すぐに一番引っ張られる場所に到達します。

クロッチの後ろ部分で、お尻の割れ目を表現しながらも、生地が伸びて割れ目を隠しているところが、必用以上にエロくしない重要なポイントで

ウエストに掛けて細くなることで、伸びていた生地が緩み、場合によっては、ゴムで締めている分ウェスト直下が緩んでいる物もあります。

でも、柄的に伸びも余ったりもせず、ぴったり肌に吸い付くくらいが一番だと思います。


お尻の特徴を全体で表現しながらもお尻そのままの形状を表すこと無く、パンツの伸縮にて柄を歪ませることでその役目を全うしていることを知らしめる。

お尻じゃないわ!、パンツよ!

お尻かくして、パンツ隠さず!


パンツが見えることで可愛さがが最大になる。パンツの可愛さが最も強調されるんだと思います。


ちなみに、上記を満たす光景として

膝上くらいの高さから、スカートが翻って、クロッチの後部、ちょっとのお尻の割れ目及びバックの大半が見えている状態(上半身は振り返って恥ずかしがっているような感じがお勧め)が最もステキかと思います。

そういえば、クロッチとの境目を2本線引いている人が多いけど、
一つは、前側の布とクロッチの布との境目であって、二本目はあるとしても、折り返しを縫い止めるための補強で、ないものの方が大半だと思うの。

昔はいていたお子様パンツには、破けにくいように縫ってある物が多いけど、最近のパンツはほぼ縫っていないわ?

あと、クロッチの部分の当て布を、外側に縫い付けている3パーツタイプもそれなりの量有る事が分かったけど、
あたしとしては、クロッチの部分を当て布も、外側も分離している4パーツタイプのパンツがお勧め。

これにより、クロッチの縫い目が、前側と後ろ側に2ヶ所2本ずつ4本入る(注:前述の通り1本ずつで2本のパンツが最近増えています。)のと、
前の生地と後ろの生地を縫っている部分が1ヶ所でクロッチの縫い目が真ん中辺り(正中では無い)に1ヶ所2本だけ有るタイプが有るわけです。

1ヶ所タイプの物は、補強のために折り返してから縫ってあるので、ほぼ必ず2本ですね?


それはそれとして、最近のパンツは、クロッチの当て布(内側の方)がとても短いのが多い。
アソコと、後ろと2ヶ所をくまなく覆うには、それなりの長さ10cm以上は居ると思うんだけど、短いのは5cmも無い物もあるわ?

あたしの体形が間違っていなければ、ほぼ真下。
アソコの口の下にだけ有るわね?

日常的な状態での、保護とか、防衛とか、目隠しとか、衛生とか そういう事を考慮したものでは無いと思うわ?

多分、勝負パンツね?

脱がされるまで耐えられれば良いとか、そういう感じ?

お汁の多いあたしの場合は、一瞬でスケスケになると思うけど。


パンツ談
閉じる
テーマ:日記 URL:https://tsukiyori.sakura.ne.jp/index_m.cgi?ID=1224
 
<<< << < prev3$F? 146/554ページ(1661件) $FAnext3 > >> >>>