信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

LIST OF ARTICLES

記事一覧

  • テクログ

    git clone 時に出た 「the remote end hung up unexpectedly」に辛勝した話

    どうも!エンジニア歴2年目に突入したわいです。連投になって申し訳ないんですけど、先日ハマった沼から抜け出すために苦悩したことを備忘録として書き留めます。ウダウダ書いていますが、結果だけ知りたい方はまとめまで読み飛ばしてください。何が起きたか開発環境を CodeCommit から git clone したときに、下記のエラーに阻まれた。(いろいろあって開発環境を消してしまった…)FATAL ERROR: Remote side unexpectedly closed network connection fatal: the remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed 1行目のエラーメッセージはなぜかコロコロ変わったりした。開発環境がないので、このままだと仕事ができないとかなり焦り、先輩に相談。>どうやら、リポジトリの容量がでかすぎるらしい試しに、先輩にもcloneし直してもらうと、、成功したあわよくばと思ったが、自力で解決するしかなくなった、、正直、Git Extensions のぬるま湯に1年間浸かりつづけていたので、Git が全くわかっていない。とりあえず、ガンガン試していく作戦に出た。何を試したかこれらの記事を参考にさせていただきました。ありがとうございます。https://stackoverflow.com/questions/6842687/the-remote-end-hung-up-unexpectedly-while-git-cloninghttps://cithukyaw.wordpress.com/2014/09/08/fix-for-the-fatal-error-early-eof-on-git-clone/https://qiita.com/cacahuatl/items/4d763e98f3934e3569ca① 「http.postBuffer」の設定を変更するgit config --global http.postBuffer 524288000 >結果は変わらなかったさらに2倍にしてみるgit config --global http.postBuffer 1048576000 >結果は変わらなかった② 「core.compression」を設定するhttps://git-scm.com/docs/git-configgit config --global core.compression 0 >結果は変わらなかった>設定値を -1, 9 と変えてみたが、結果は変わらなかった③  ssh接続のタイムアウトを設定する「Remote side unexpectedly closed network connection」で検索すると、sshのタイムアウトっぽいことが出てきたので試してみた~/.ssh/configServerAliveInterval 60 ServerAliveCountMax 3 >結果は変わらなかった④  一度にcloneする量を減らす(shallow clone)git clone --depth 1 <my_repo_URI> >結果は変わらなかったいくら調べても他の解決法が出てこないので、この時点でかなり詰んだと思った⑤  有線接続に変える在宅になってから、家の Wi-Fi で仕事をしていたことに先輩の一言で気づいたclone中の「MiB/s」が2倍近く増えたが、、>結果は変わらなかった>①~④のどれも結果は変わらなかった絶望の淵に立たされていたときに、一筋の光が差し込んだ⑥  masterブランチよりも軽いブランチをcloneするgit clone -b <smaller_branch> <my_repo_URI> >結果は変わらなかった一度にcloneする量を減らす(shallow clone)git clone -b <smaller_branch> --depth 1 <my_repo_URI> >clone成功!!現在、<smaller_branch>の最新のコミットだけ取得している状態なので、<smaller_branch>の全履歴を取得git fetch --unshallow >またもや、同様のエラーコミット数を制限して少しずつ履歴を取得git fetch --depth 8 # コミット数:8は任意 >fetch成功!!残りの履歴を取得git fetch --unshallow >fetch成功!!⑦  masterブランチを含め、他のブランチ情報を取得する.git/config の<smaller_branch>を * に変更する[remote "origin"]     url = <my_repo_URI>     fetch = +refs/heads/*:refs/remotes/origin/* git fetch >fetch成功!!これですべての履歴が取得できた>やっとの思いで、開発環境が復活!!まとめ結局、必要だったコマンド。git config --global http.postBuffer 524288000 git clone -b <smaller_branch> --depth 1 <my_repo_URI> git fetch --depth 8 git fetch --unshallow .git/config[remote "origin"]     url = <my_repo_URI>     fetch = +refs/heads/*:refs/remotes/origin/* git fetch 有線接続では以上のコマンドでcloneできた。Wi-Fi の場合、最後の git fetch だけがうまくいかなかった。>いきなり、* で fetch するのではなくて、別のブランチを一度 fetch して、再度 * で fetch したらいけたうーん、Gitムズイ、、そもそも、alpineでDocker環境を作ってたら、こんなことには、、他にいい方法があれば教えてください!以上、わいでした。健闘を祈る!!
  • 画像:ブログサムネイル

    テクログ

    オブジェクト指向は因数分解だ!!

    どうも!先月に入社二年目を迎え、とうとうパイセンと化したわいです。自粛期間中ということで、かなり暇なので長編に挑みます。暇な人はぜひ最後まで読んでみてください。「うわあ、暇だあ…」ってより実感すると思います。今回、またもやプログラミングを他の概念にこじつけるシリーズです。この一年間、新人プログラマーとしていろいろ苦戦しました。その中のひとつが、『オブジェクト指向とは』の理解です。オブジェクト指向に関する記事はたくさんあります。それこそ、「オブジェクト指向はもう古い」とされていたりします。ただ温故知新という言葉があるように、オブジェクト指向について学ぶことは決して意味のないことではないと思います。むしろ、プログラミングをする上での基本的な考え方が詰まっているように思えます。詳しく、そして正確に知りたい場合は、他の記事をおすすめします。https://www.google.com/search?q=%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91%E3%81%A8%E3%81%AF今回はオブジェクト指向のイメージを掴むために少しでもお役に立てればと思い、あえて変な角度からアプローチしてみます。その名も、「オブジェクト指向は因数分解だ!!」です。因数分解とは、「足し算・引き算で表されている数式をかけ算の形に変形する」ことです。例えば、cx^2+acx+bcx+abc = (x+a)(x+b)c となります。(中学数学でやりましたね?)ここで、下図のようなWebページについて考えてみましょう。(私自身、最初に車の例えを見たときピンとこなかったので…)犬の情報は、売られている犬がリストで表示されているとします。猫も同様です。店舗の情報は、住所、電話番号などが表示されているとしましょう。(ちなみに、私はペットショップに行くと悲しい気持ちになるので、基本的に中には入りません)かなり簡略化しているのでわかりやすいと思いますが、ペットショップのWebサイト = 犬の情報 × 猫の情報 × 店舗の情報という式が成り立つはずです。複雑なWebサイトでもこのように各パーツの組み合わせで成り立っています。これを先ほどの因数分解と合わせて考えてみます。ペットショップのWebサイト= cx^2+acx+bcx+abc (一見複雑だが…)=  (x+a)  ×  (x+b)  ×  c = 犬の情報 × 猫の情報 × 店舗の情報このようにWebサイトを因数分解することができました。「だから、なんだ?」という話なのですが、ここでオブジェクト指向について考えたいと思います。なぜわざわざ小難しいオブジェクト指向で書くかというと、それは変更に対して柔軟に対応するためです。どういうことかというと、「爬虫類も売ることにしたから、サイトに爬虫類の情報も表示したい」や、「犬を売るのをやめて、鳥を売ることにしたから変えてくれ」などという要望に、瞬時にそしてバグを出すことなく対応することがオブジェクト指向を用いると容易になるということです。適切にオブジェクト指向を使えば、似たような機能の追加が容易になり(再利用性)、たった一か所の変更のために他のパーツにバグが出ていないかページ全体をテストし直す必要がありません(疎結合性)。しかし、このオブジェクト指向の難しいところはどのように機能(クラス)を分割するかというところにあると思います。大雑把に分割しても効力は発揮しないし、かといって細かすぎても保守が大変になります。ここで、今回私が提案するのは「因数分解のように考えてみたら意外と上手くいくんじゃね?w」ってやつです。まず、「犬の情報」を「鳥の情報」に変えるということを因数分解で見てみましょう。これは、仮に a → d とすることで実現するとします。そうすると、ペットショップのWebサイト=  (x+d)  ×  (x+b)  ×  c = 鳥の情報 × 猫の情報 × 店舗の情報となり、(x+b)やc の値に何ら影響を与えることなく変更することが出来ました。ここで勘のいい人は、「おめえさん、x を変えたら『猫の情報 (x+b)』に影響を与えるだら?」と思うかもしれません。そうです。そして、この x がオブジェクト指向の要です。「犬の情報」も「猫の情報」も、『売られている動物がリストで表示される』という共通点があります。この共通点を規格として、インターフェースや抽象クラスにまとめ上げることで再利用性が高まり、さらに各々のクラスの役割がはっきりします。そして、ここで注意しないといけないのがなんでもかんでもこの x にまとめてしまうことです。各ペットの情報欄に年齢や性別のほかに、仮に「1日に〇回散歩に行かないといけない」という項目があったとします。これを x にまとめてしまうと『犬の情報 (x+a)』ではいいんですが、関係のない『猫の情報 (x+b)』に影響を与えてしまいます。だから、この場合は各ペットの情報欄の項目までは共通化せず、『売られている動物がリストで表示される』という根本機能だけを共通化することがいいように思えます。(犬と猫だけだと差異がわかりにくいですが、変わった動物を追加するとなると変な項目も増えそうです)かといって、ペットショップのWebサイトということなので、『売られている動物がリストで表示される』という機能の共通化を疑う必要はないでしょう。それだと、オブジェクト指向の意味がなくなります。次に、f(a) = x+a とすると、ペットショップのWebサイト=  f(a)  ×  f(b)  ×  c = 犬の情報 × 猫の情報 × 店舗の情報となり、 犬(a)  や  猫(b)  を f に与えるだけで欲しい情報が得られるということです。この f こそが、『売られている動物をリストで表示する』という機能であり、インターフェースです。この『動物』という抽象に対してプログラミングしていくことが、ポリモーフィズムです。最後に、カプセル化について考えます。f はインターフェースや抽象クラスで、 f(a) は『売られている犬をリストで表示する』という具象クラスです。実際にペットショップのWebサイトを構築する際は、この f(a) を使います。そして、この f(a) を利用するとき、『売られている犬をリストで表示する』という具象クラスであるということだけを知っていればよくて、f(a) = x+a だという具体的な中身を知っている必要は全くありません。実は、『売られている犬を「人気順に」リストで表示する』ということをやっていて、中身が f(a) = 3x+1+a と多少複雑になっているかもしれません。ただ、このように具体的な中身を知らずとも、 f(a) を使えばWebサイトは構築できます。クラスを外部から利用するとき、 f(a) のような簡素な見た目で提供し、影響範囲をクラス内にとどめておくことをカプセル化といいます。いかがでしたか?「オブジェクト指向は因数分解だ!!」理論は。あなたのソース、c(x^2+ax+bx+ab) や x^2(1+a/x)(1+b/x)c になっていないでしょうか?「うわあ、暇だあ…」最後まで読んでくださり、私としてはうれしい限りですが、相当お暇なんですね。なにか自粛期間にできる趣味をお探しになることをお勧めします。以上、わいでした。健闘を祈る!!
  • 画像:ブログサムネイル

    雑記

    我々はどこから来たのか 我々は何者か 我々はどこへ行くのか

    どうも!前回のブログで「エントロピー」という言葉を無理くり使って、物理学徒であることを匂わせ投稿した、わいです!今回はその伏線を回収させていただきます!私は、理学部物理学科卒業の生粋の物理学徒です。なぜ、物理学に興味を持つようになったかというと、ドラマ「ガリレオ」に憧れて、大好きな柴〇コウさんに近づくため、だとか高校のときの物理の先生が超絶美人だったから、とかいろいろと正当な理由はあるのですが、一番は「身近な現象を物理学で説明できる!」と知ったことです。そのうちの一つを今回はご紹介します。(※教科書にも載っているので、大した内容ではないです)それは、「なぜ空は青く、夕焼けは赤いのか」です。太陽の光はさまざまな色の光が混ざり合っています。そして、光は波の性質を持っています。色の違いはこの波の山と山の間隔(波長)の違いにより生まれています。赤い光は波長が長く、青い光は波長が短いです。そして、地球には大気があります。太陽の光は、この大気中の気体分子(酸素や窒素)にぶつかって進路を曲げられ、いろいろな方向に「散乱」します。波長が長い光は、気体分子の間をうまくすり抜けながら、まっすぐ届くのですが、波長の短い光は、気体分子にぶつかりやすく、すぐ散乱していしまいます。これらの性質が、空の色に関わっています。太陽が真上にあるときは、青い光が頭上でたくさん散乱され、空一面に青が広がります。しかし、太陽が地球の横側にあるとき(朝焼けや夕焼け)は、太陽の光が通過する大気の厚さが大幅に増えます。そのため、散乱しやすい青い光は途中で失われてしまいます。そして、散乱しにくい赤い光だけが到達します。だから、光の出どころである太陽の方角だけぼんやり赤く、空一面が赤く染まることはありません。なにか一方的に説明しましたが(間違えていたらすみません)、どうですか?おもしろくないですか?他にもいろいろな現象が物理学で説明できます。人類のオリジンストーリーも物理学で説明できる日が来るとワクワクしますね。みなさん自身は、どこに向かっていますか?以上、わいでした。健闘を祈る!!
  • テクログ

    ソースコードにおけるエントロピー増大則

    「ものごとは秩序だった状態から無秩序な状態へと変化していく」という意味でエントロピー増大則という言葉を使ってみましたが、正確には誤用です。ただかっこつけたかっただけです。以下、エントロピーという言葉を「乱雑さ」という意味で使います。どうも!今年の4月に入社したわいです。ブログを書くことから逃げ続けていたのですが、向き合います。しかも、テクログ!!!今回は粋なタイトル通り、ソースコードのエントロピー増大について書いてみたいと思います。仕様追加や変更などで、ソースコードのエントロピーはどうしても増大します。ここで、このエントロピー増大を少しでも小さくする方法をプログラミング歴1年未満の青二才が提案します。(※あてになりません)それは、「人間が読んで、自然な処理の流れになっているか」を意識してコーディングを行うというものです。「自然な」というのがすごい抽象的ですが、処理を上から順に言葉にしていき、それらを繫げたときに不自然でないかということです。これができていると、次に読む人に与える誤解が少なくなり、コーディングの意図も伝わりやすくなると思います。つまり、ある人がそのソースコードに何か処理を追加しようとしたとき、「この処理を追加するには、ここ(この行)しかないな」と誘導できるようなコードを書くことができればGOODです。これができると、追加や変更を加えてもソースコードがそこまで複雑にならない、つまりエントロピーの増大を小さくすることができると思います。具体的には、いろいろあると思いますが、とりあえず変数のスコープ(ソースコード上で見える範囲)をなるべく小さくするように心掛けると良いと思います。変数のスコープを小さくすると、次の開発者の変更箇所を限定できます。また、スコープを小さくするために、適度に関数化することで、処理の流れの見通しが良くなります。ただ、なんでもかんでも関数にまとめるのではなく、処理のフェーズ(深さ)を意識して、適度に関数に分ける必要があります。このように偏った意見(特に、具体例)でしたが、新卒プログラマーということで許してください。他にみなさんがコーディングの際に意識していることがあったら、是非教えてください!!以上、わいでした。健闘を祈る!!
  • 画像:ブログサムネイル

    レビュー

    土佐ブログ

    男もすなる日記といふものを女もしてみむとてするなりはじめまして。人類最高の書き出しをつづったのは、今年の4月に入社した紀貫之です。趣味は詠むことです。違います。今年の4月に入社したわいです。趣味は、、すみません。非常によくない始まりです。入社1発目のブログ投稿、とっつきにくい印象を与えてしまうのはご法度。ここからは安心してくださいね。それでは、和歌の話に戻ります。最近よく思うんですけど、平安時代にタイムスリップしてみたい。(注:身分、教養は保障されている。最長でも1ヶ月)行ってみたくないですか?雰囲気味わってみたくないですか?きっとドロドロした世界に違いありませんが、その中にも趣を大切にした優雅な世界が広がっているはずです。そもそも和歌って、卍すぎません?プログラマー1年目である私が、「いとをかし」なことを言いますが、和歌を詠むつもりでコーディングすると良い訓練になるのではないでしょうか。相手の歌を受けて(既存のソースコードに倣って)、相手に気持ちが伝わるように歌を詠む(次読む人が理解しやすいようにコーディングする)。なにより美しいと評価され、そして良いものは後世に残る。といっても、和歌は作者の真意は汲み取るためには行間を読む必要があり、そこに趣があります。しかし、ソースコードにそんなものは必要ありません。誰が読んでもパッと理解できるものほど良いはずです。まあ、言ってしまえば、和歌もコーディングも大した共通点はないのですが、ちょっとくらい平安気分で仕事をするのも悪くないと思います。結局、nullな話しかできませんでした。なんだか空気が悪いので、新卒として決意表明します。とにかくソースを読みます。そして、本や技術ブログもたくさん読んで、勉強します。あ、まだ趣味がなにか言ってなかったですね。そうですね、趣味は「読むこと」にするとしましょう、、以上、わいでした。健闘を祈る!!