ある程度アプリケーションの規模が大きくなってくると、ある変更がどこまでの影響範囲だと思っているのかがコミュニケーションにおいて重要
Pull Requestに動作確認方法を書け - 橋本商会
ある程度アプリケーションの規模が大きくなってくると、ある変更がどこまでの影響範囲だと思っているのかがコミュニケーションにおいて重要
はてなインターンで最高の夏を過ごしていた話 - guni.log
えー、ブログのネタは鮮度が大事だそうです。 さて、今年の夏は株式会社はてなさんのサマーインターンに参加させていただきました。 2,3ヶ月前っすね。冷蔵庫開けて確認するのが怖くなるぐらいの時間経ってますね。 ごめんなさい。 developer.hatenastaff.com 期間は8/13~9/7の一ヶ月間。 場所は株式会社はてな本社(京都)。 選考 選考は以下の２段階からなります。 書類選考 面接 書類選考は自己アピール的なことと、GitHubのアカウント、rot13のPythonでの実装を書いて送りました。 面接は、東京にも京都にも気軽にいけるわけではないため、Hangoutでやっていただきました。 自己アピールにも書いてない成果物もGitHubから探し出して聞かれたので正直驚きました。 やっぱりアウトプットは大事(なおブログ)。 事前課題 事前課題では、GoとTypeScriptの勉強
5ch(旧2ch)をスクレイピングして、過去流行ったネットスラングの今を知る - にほんごのれんしゅう
5ch(旧2ch)ではここ数年はTwitterを使用するようになってしまいましたが、ネットのミームの発信地点であって、様々なスラングを生み、様々な文化を作ってきたと思います。 学生時代、2chまとめとか見ていたので、影響を受けてきたネット文化で、感覚値からすると、どうにも流行り廃りがあるようです。 5chの過去ログを過去18年ほどさかのぼって取得する方法と、懐かしいネットスラングのドキュメントに占める出現具合を時系列でカウントすることで、時代の変遷でどのように使用の方法が変化したのか観測することができます。 文末に「orz」って付けたら若い人から「orzってなんですか？」と聞かれて心身共にorzみたいになってる— ばんくし (@vaaaaanquish) October 19, 2018 図1. 今回集計したorzの結果 例えば、今回集計した5chの書き込み500GByte程度のログからで
気兼ねなくアクティビティを書き留められるTrickleというサービスをリリースしました - maru source
こんにちは丸山@h13i32maruです。 今日、Trickle（読み:トリクル）というサービスをリリースしました！ アクティビティ トピック 他の人のアクティビティ Trickleは「Twitterなにか少し疲れてきたなぁ。でもやめたいわけではないし、うーん」と僕が困っていたことを自分で解決するために作ったサービスです。 なので自分をターゲットにしたサービスなのですが、せっかくなので多くの人に使ってもらいたい！というわけで、リリースのお知らせを兼ねた紹介記事を書きました。気になった方は是非続きを読んでみてください。 まとめ 自分のアクティビティをトピックごとに気兼ねなく書き留めることができる ジョギング、読書、猫と遊ぶ、などの自分で作ったトピックごとにアクティビティを書き留める 他人の興味あるトピックだけをサブスクライブ（いわゆるフォロー）できる 「Aさんの読書トピックはサブスクライブし
IPv4 アドレス競合検出 (RFC5227 日本語訳) - アルプス登山の玄関口・笠井家
2008年7月に公開された、RFC5227 [IPv4 アドレス競合検出]の日本語訳です。同一ネットワーク上で、複数ホストに同一の IP アドレスがアサインされないようにするための技術、ならびに、万一アサインした場合にどうすればよいか、等を規定する標準です。 原文は、http://www.ietf.org/rfc/rfc5227.txt をご参照下さい。邦訳の誤りにお気づきの場合、ページ最下部のメールアドレスまでご連絡いただければ幸いです。 なお、可読性向上のため、ページのヘッダ・フッタを省略し、原文には無い改行を、適宜挿入しております。ご了承下さい。 Network Working Group S. Cheshire Request for Comments: 5227 Apple Inc. Updates: 826 July 2008 Category: Standards Track
RFC1812 - Requirements for IP Version 4 Routers
Network Working Group Request for Comments: 1812 Obsoletes: 1716, 1009 Category: Standards Track このメモのステータス このドキュメントは、インターネット社会のためのインターネット標準トラックプロトコルを規定し、改善のための議論や提案を要求する。このプロトコルの標準化状態と状況については、「インターネット公式プロトコル標準」(STD 1) の現在の版を参照されたい。このメモの配布は制限されない。 序文 このドキュメントは、旧ルータ要件の RFC1716 の更新版である。その RFC はワーキンググループで実施された重要な作業を留めたが、現在の標準を考慮して IESG の現在の技術を適切に記述することが出来なかった。 現在の編者はドキュメントの更新を求め続け、調達規定や実装者向けの指針として有効に
補講 Gratuitous arpの実装違い - Jの衝動書き日記
前回、ARPパケットの扱いについて書いた。本（詳解TCP/IP Vol.1 プロトコル）によると、Gratuitous arpの送り手とターゲットのMACアドレスとIPアドレスは次のように設定するとある（前回載せたサンプルソースもこれでやっている）。 送信元MACアドレス：arpパケットを送信するIFのMACアドレス 送信元IPアドレス：調査したいIPアドレス ターゲットMACアドレス：設定なし ターゲットIPアドレス：送り手IPアドレスと同じ だが、これだとLinuxはARP応答を返してくれない。Linuxが応答するのは以下のGratuitous arpである。 送信元MACアドレス：arpパケットを送信するIFのMACアドレス 送信元IPアドレス：0.0.0.0(設定なし) ターゲットMACアドレス：FF:FF:FF:FF:FF:FF(Broadcast) ターゲットIPアドレス：調査
これで完璧DHCP 第2回 | 日経 xTECH（クロステック）
Step1 やりとりを追いかけてみよう 四つのメッセージを交わせば 設定情報がもらえる どんな設定情報がもらえるかという話はStep2に任せて，Step1ではDHCPのやりとりを見ていこう。 その前に，DHCP通信のプレーヤから確認しておこう。 登場するプレーヤは二人。IPアドレスなどの設定情報を割り当ててもらうDHCPクライアントと，設定情報を一元管理してDHCPクライアントに情報を割り当てるDHCPサーバーだ。 この二人が通信し合うことでDHCP通信は成り立つ。当然そこには，どんな手順でどんなフォーマットのパケットをやりとりするかというプロトコルが決まっている。この決まりがDHCPである。そして，実際にこの決まりに従って動くプログラムが二人のプレーヤの正体である。 図2 DHCPはどこにある？ IPアドレスなどの設定情報をもらうDHCPクライアントは，ほとんどのパソコンOSが備えている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Test262.report
http://zacodesign.net/blog/?p=643