第一。搬入新家之前，给家里有瑕疵的地方拍照，做好备份，这样在退租的时候，尽量避免支付多余修复的钱。 第二，开通电力和瓦斯的那些事。 开通电力和瓦斯，建议在搬家的前一周联系东京电力公司。我是通过电话联系的，客服人员会很温柔的和你沟通，电力和瓦斯是一家的。注意区分下《东日本，西日本》自己住的区域是属于哪边。 第三，买家具。 这方面有很多网站，建议不要分开买。有《新生活セット》里面有套装，这样会更加优惠一些。我的是在乐天买的，注意好，他们送货是否收费。我就没注意好被坑了3000日元。 一定要区分好燃气灶的类型是LP的还是东京gas的，买错的话退起来很麻烦。 一般性：2点セット包含了《洗衣机，冰箱》，3点セット包含了《洗衣机，冰箱，微波炉》，根据自己选择即好 我买的是3点セット，然后有在他们店里掏2000日元买了把电脑椅子，又加了13000买了煤气灶，同一个店铺买，这样会比较超值一些。总共掏了58000。 要不是最后被坑了3000日元，我真会给他5星好评。一定要商量好价格，价格一定要明确，明确下来。 第四，开通网络 开通网络需要提前20天预约，从审核你的住所是否能安装他们公司的网络，到施工结束大概需要花这么多时间。不同的网络公司需要不同的网络设备，有些公司不用再另外掏钱买，有些则不行。 网络最快的就是 NURO 了，光纤实际下载速度可以达到60M一秒，IP是固定的。 现在用的是 《ぷらら 》不推荐使用，网络速度比较慢。ping baidu.com 的话，会有25%的掉包情况。ping google 倒是没啥问题，实际下载速度最大10M。 最后，总结 不要把日本人想象地多美好，不会坑你。他们只是没找到机会。如果你觉得我这句话是错的，不相信，我只能笑你还是太天真。 看房子的时候，一定要看好洗衣机的排水口，距离安装位置是否过远，怎么排水。

調査 サンプル画面を書くときに、「４００MB」以上のMP4ファイルをアップロード時、JVMからメモリー不足エラーが起こりました。 普段、この時、JVMの占用メモリー引数を修正するだけでいいですが、別の実現し方で、解決しようと思いました。 動作はユーザーさんが複数のファイルを選んでから、ファイルごとにアップロードする、しかし、ファイルが多き過ぎて、Jvmに配れたメモリー資源が足りないことになりました。 画面を見ると、管理画面のファイルアップロードテキストは制限されてない、追加アップロードボタンをクリックすると、ファイルテキストを画面に追加できます。 一つのファイルテキストは選択できるサイズが最大１GBまで、五つのテキストは５GBになる、このように換算する。 アーキテクチャ 処理フロー 解決案 大ファイルを分割して、何回にアップロードするように修正。ファイルを分割して、ファイルブロック単位として、アップロードする。 もちろん、サーバーにアップロードする後、組み合わせて、AmazonのS3に保存する。 幸せなことは、Java APIを見ると、ファイルブロックが直接にS3にアップロードする、全ブロックがアップロード完了する後、シンプルに「組み合わせる範囲」のAPIを呼び出すだけで、リモートのS3サーバーに正常に読み取りができる。 最後 テストする後、一つテキストは２GBでもかまいません、日常使用に対する問題なかった。 インターネットのスピードが調整不能のため、時間がかなりかかる インターネットの有無にも仕方ないだろうか、草　：）

課題説明 今って、大きく課題にアサインしてもらった。現状は、データ数が多すぎるので、そして、データ抽出したあとにそのロジックコードも長すぎる、ざっくりみると、２００００行以上である。中で別システム連携であるのみにならず、DBデータの再抽出も多い。 テストの最小単位で３万件のデータをダウンロードに試してましたが、ローカルの開発環境で全然無理です。１５分ほどにかかったあと、すぐダンしてしまった。 プロジェクトリーダーは「エラーになる行を見て、解決してください。」と言った 僕にとって日本では技術のことが知らないリーダーが多いです、実際はこんなに簡単に解決ではなく、性能問題は開発の段階に考えられるものと思うですが、仕様不備やスケジュールを合わせるため、開発段階にもややこしかったかもしれない ほぼ、現状を把握から解決まで二週間を経った、問題は以下になる loopの中にLoopが多すぎる 全件数を抽出した、未出力のデータって長期にメモリーを占用する 全データ処理後一瞬にファイルを出力する、４００MBくらい SQL：where id in(...2000個以上のストリング...) 本番環境のメモリーは４GBがあるのに、２GBだけ使われてる 実現目標 100000件以上のデータがダウンロードできるように修正 アーキテクチャはこうになる 解決案 一番目の解決案はリストタイプをMapタイプに修正すればＯＫです。 二番目は全件数を抽出したので、回数による処理件数を制御すると僕は考えてます。リーダーさんは、「処理件数」だけで制御いけないかという質問を頂きました。 １人は「５００件」、１０人同時にダウンロードすれば並列件数が５０００件です。３０人なら、１５０００件。 以上の問題をもって、実験したが、５０００件以内は別の機能に性能影響が最も小さい。 三番目の解決案は、一行ずつファイルに出力する、処理後にＣＳＶの該当オブジェクトをNullにして、JVMがメモリー資源を自動的に開放できる 四番目は根拠の問題はMySQLのインデックスに走らなかったです、INの結合句は２０００以上であるので。これに対すて、新しくテーブルを作成しました、毎回処理の回数データは「 insert into  new_ table_name(申込ID) select * from  old_ table_data 」テーブル