TCP socketではwriteの後すぐにcloseしてはいけない。 相手側に全てのデータが届いてからcloseする必要がある。 shutdown で書き込み側だけハーフクローズするとよい。 相手側がcloseしてから、こちらをcloseする。相手側がcloseしたことは、readを呼んでブロックさせておくと、読み込みバイト数==0 つまりEOFになったことでわかる。
TCP socketではwriteの後すぐにcloseしてはいけない。 相手側に全てのデータが届いてからcloseする必要がある。 shutdown で書き込み側だけハーフクローズするとよい。 相手側がcloseしてから、こちらをcloseする。相手側がcloseしたことは、readを呼んでブロックさせておくと、読み込みバイト数==0 つまりEOFになったことでわかる。
Go初心者がやってしまいがちなやらない方がいいことを書き出してみました。 情報検索や環境構築 golang.jpを見に行ってしまう Golang(ごーらんぐ)と呼んでしまう(by hogedigo) depが最新推奨のパッケージマネージャだと勘違いする(Go標準の「go mod」を使おう) 「GO???」環境変数を理解せずに設定しまくる(わからない場合は一切設定しないのが正しい) しょっぱなからgvm,gobrew,goenvなどのマルチバージョンのマネージャを入れようとしてエディタ連携環境構築に失敗する (複数バージョンのGoの運用は既に標準のGoだけでできるようになっている) エディタにgoimportsやgolintを設定し忘れる OSのパッケージマネージャまかせで古いGoやgccgoをインストールしてしまう エラーハンドリング周り err変数名のバリエーションを増やしすぎる(ほとん
現在のプロジェクトでも様々な技術的負債が出てきていて、出るだけならまだしもなかなか返済を計画化できず、どうしたものかと思っています。 そんなとき、 merpay Backend Engineer Meetup #6~技術的負債について~ - connpass が開催されるというのを目にし、これは是が非でも行きたい、話を聞きたいと思っていました。 そして行ったら meetup はとにかく最高で、懇親会まで含めて最高だった。 自分のところの技術的負債 Meetup 技術的負債の状況 負債の返済方法 負債返済専門の人を作る 四半期ごとに負債を含めて OKR を定義 負債と新規開発を分けない 負債返済のポイント 技術的負債を作らない工夫 イベントとして 自分のところの技術的負債 最初のコンテキストとしてぼく自身の関わっているプロジェクトの技術的負債の状況を記載しておくと、技術的負債は多いです。多い
2019年 総括 会社が真っ二つになり、所属が変わりました 😇 仕事 総評 兎にも角にも会社が分社化したのはとても大きな話です。 この業界、もはや政治のうねりに逆らえないのは覚悟していましたが… 元々必要な人材が集まっていた会社が分断化されたわけなので、リソースという面では確実に歪なものになりました。 こちらは時間が解決してくれるとは思いますが、まだまだ大変。 ただ双方の会社共にビジョンは明確ですし、自分はポジティブに捉えています。 今年の大きな仕事としては所属変更後のサービス名/ドメイン名変更対応ですね。無停止でほぼ問題なく移行できたのは本当良い仕事をしたと思っています。 ただ、どうしてもリソース不足というところで今年も仕事をこなすことで精一杯でした。 理解はしていましたが、余裕がないと 新しいことが学べない 既存の知見で設計/実装を進めてしまう エンジニアとしての進化が出来ていない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く