ソケットプログラミングのTips
概要 ソケットプログラミングに関するTipsをメモレベルで記載する。 切断検知と経路切断 TCPコネクションの切断検出 対向がclose()、shuttdown()、プログラム終了等をしたときの切断検出について。 OSをシャットダウンさせた場合も通常はアプリケーションの終了処理が走り、正常な切断が動く。 受信側の切断検出は、recv()がlength==0で返ってきたとき、または、errno==ECONNRESETとなる。（ECONNRESETはRSTによって切断された場合） 送信側の切断検出は、切断された後2回目のsend()がエラーとなる。 ※相手がclose()→こちらがsend()→相手にパケットが飛ぶが待ち受けプログラムがいないためRST応答が来る→もう1度send()→エラー ※send()自体はカーネルの送信バッファにデータコピーするだけなので、TCPレベルの応答（送信完了）
「プログラミング言語Go完全入門」の「完全」公開のお知らせ | メルカリエンジニアリング
メルペイ エキスパートチームの@tenntennです。本稿は Merpay Tech Openness Month の11日目の記事です。 「プログラミング言語Go完全入門」の期間限定公開のお知らせでも書いたように、メルペイでは、社外の方向けにGopher道場という体系的にGoを学べる場を無償で提供してきました。Goの普及を目的にこれまでに8回開催し100人以上の方に参加していただきました。 また、Gopher道場の動画や資料はGopher道場 自習室として誰でも利用できるようになっており、現時点で300名以上の方が利用されています。 Gopher道場の資料のベースになっている「プログラミング言語Go完全入門」は、2020年7月31日までの限定公開になっていましたが、本日より公開期限を撤廃し、完全公開することになりました。 また、本日8月31日から始まる「Online Summer Int
和田(t_wada)さんに技術相談をしました - CureApp開発者ブログ
2016 - 11 - 07 和田(t_wada)さんに技術相談をしました 二週間ほど前にはなりますが、 日本のTDD( テスト駆動開発 )の先駆者である和田さん(t_wada)をお招きして、 技術相談会を行いました。 日頃、開発時に感じていた悩みを聞いていただき、 和田さんにビシバシと解決していただきました。 そこで今回は特に印象に残った、 不安定なテストとの付き合い方 フレームワーク 選定基準 品質保証のやり方 について書こうと思います。 不安定なテストとの付き合い方 私たちは、普段から不安定なテストに悩まされていました。 不安定なテストとは、 ローカルでは通るけどCIでは落ちる 遅くて タイムアウト になるときがある など、コードでなく環境によって結果が左右されるテストのことです。 この不安定なテストによって、開発に新しく関わった人に毎回同じような説明をしたり、説明をし忘れて不要な対
Private Presentation
Private content!This content has been marked as private by the uploader.
分散システム処理モデルに関する動向について（MapReduceからBorgまで）
詳細については後述しますが、MapReduceの処理モデルは、上記の通り各区分ごとにそれぞれ単純化（限定）されたモデルであったと言えます。 また、MapReduceの関数プログラミングおよびグラフ的な特徴も合わせて以下に整理してみます。 関数プログラミング的な特徴 MapおよびReduceフェーズは、それぞれ関数型プログラミングのMapおよびReduce処理をモデル化したものです。MapReduceは、参照透過性がある純粋な関数処理と言えます。参照透過性とは入力により出力が一意に決まる性質のことです。言い換えればMapReduceの処理は、大域などの処理に影響する外部の環境は持たず、内部的にも静的な一時変数などの状態も持たないことを意味します。 純粋な関数処理は複数の処理が同時に実行されても他の並列に動作している処理の状態には左右されないため、この参照透過性は並列化に向いている性質がありま
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
PHPカンファレンスで関数プログラミングの話をしてきた - だいくしー(@daiksy)のはてなブログ
「こんどのPHPカンファレンスで関数プログラミングの話をしてください」 突然のお誘いに戸惑いつつも、"PHPカンファレンスで登壇"なんてたぶんこの先二度と縁がないかもしれない、と思ったのでお引き受けして、喋ってきた。 この登壇にはひとつ大きな問題がある。 ぼくはPHPをやったことがない そのような状態での冒険的な登壇だった。 発表内容 セッションは30分。この時間内に話すことができる関数プログラミングの話題は限られている。また、PHPカンファレンスということで、参加者の多くが関数型言語の普段使いではなさそうだ。 今回のセッションでは、関数プログラミングの入り口として「参照透過性」このキーワードだけを覚えて帰ってもらおう、というアプローチでのぞむことにした。 関数プログラミングの入り口として、このキーワードを選んだのには次の理由がある。 PHPプログラマが明日からでもさっそく自分のプログラミ
動詞de!! モデリング ①「導入編」
平鍋 「モデリングしてますか？」 今日は、セイコーエプソン(株)の萩原さんをお招きして「動詞de!! モデリング」、”誰でもできるモデリング”の手法についてご紹介いただきます。では、萩原さん、よろしくお願いします。 萩原さん セイコーエプソンの萩原です。よろしくお願いします。 今日は「動詞de!! モデリング」ということで、誰でもできるモデリング、という形で説明していきたいと思います。「モデリング習得」には、3つの壁があります。 1. オブジェクト指向の敷居が高い、2. UMLの習得が難しい、3. そもそも「モデリング」ができない 「動詞de!! モデリング」という事なので「動詞」がポイントとなっていきます。 この「動詞」なんですが、Value Engineering (VE)の機能の定義を見るとその良さが、よく分かってきます。 目的語と動詞で、機能を表します。「腕時計は、時刻を示す」とい
われわれは、いかにして変更点を追うか
われわれは、いかにして変更点を追うか ChangeLog/Issueを追う技術 自己紹介 azu @azu_re Web scratch, JSer.info アジェンダ 変更点を ChangeLogで知る Issue/Pull Requestで知る Commitで知る アジェンダ 変更点を Commitに書く Issue/Pull Requestを扱う ChangeLogにまとめる 変更点を追う :mouse: ChangeLogの追い方 ChangeLogを追うにはまずChangeLogの更新に気づく事が必要 GitHubでライブラリのリリースを見ていくためのツールや方法に書いた 更新検知の仕組みや補助ツールについて リポジトリのWatch => azu/github-reader タイムライン => azu/github-reader Star => starseeker GitHu
デザインパターンの話 - Qiita
irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければならない言語でしか基本的に役に立たないパターンであり、C++ の様にキャストだけで可変オブジェクトを不変オブジェクトに変換できる言語ではこのパターンは無用なはずである。 Java が出る前の本でこれがパターンとして挙げられてゐたといふのが俺には不思議に感じられる
Code Review Best Practices
At my current company, we do a fair amount of code reviews. I had never done one before I started here so it was a new experience for me. I think it’s a good idea to crystalize some of the things I look for when I’m doing code reviews and talk about the best way I’ve found to approach them. Briefly, a code review is a discussion between two or more developers about changes to the code to address a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アセンブリ言語のみで言語処理系を作った話 // Speaker Deck
https://qiita.com/lambdalice/items/124199b62d66d7c745a1