Regional Scrum Gathering Tokyo 2017
結果的にスクラムになってる！なのがいいと思う！ #RSGT2017
Regional Scrum Gathering Tokyo 2017
ペパボ研究所における学術的研究の意義 - ペパボ研究所ブログ
ペパボ研究所客員研究員の力武健次（りきたけ・けんじ）です。インターネットでは@jj1bdxとして活動しています。今年2017年よりペパボ研究所の客員研究員として、研究開発のお手伝いをすることになりました。この記事ではペパボ研究所に参加した動機と、今後の活動の抱負について書きます。 なぜペパボ研究所に参加したのか 昨年2016年6月にペパボ研究所が立ち上がった時、私はそのコンセプトとミッションに大いに感銘を受けました。学術的研究で得られた成果を運用に反映し、運用の課題を学術的研究のアプローチで解決するというペパボ研究所の手法は、かつて1990年から1992年に私が日本法人に所属していたDigital Equipment Corporation (DEC)のNetwork Systems Laboratory (NSL)とのやり取りで学んだものによく似ていたからです。 DECのNSLでは、現在
Introducing Helix - Rust + Ruby, Without The Glue
Introducing Helix Rust + Ruby, Without The Glue. This post is a write-up of the talk I gave at RailsConf 2016. You can find the slides here. There's a lot to love about Ruby – the sweet syntax, the focus on developer productivity and happiness, the mature ecosystem, and of course, the awesome community we built around the language. One thing that Ruby is not known for though, is being a particular
効果的な 1 on 1 ミーティングのためにマネージャができること
2016 年に逝去した、元 Intel CEO の Andy Grove による High Output Management の日本語訳が復刊され、さらに Hard Things の Ben Horowitz の序文がついたことで、改めてスタートアップ界隈でも 1 on 1 (ワンオンワン) ミーティングの効果が注目され、各社や各人の 1 on 1 のノウハウが共有されるのではないかと期待しています。 Y Combinator の Sam Altman はスタートアップ初期でのコミュニケーションの重要性を何度も説いています。特にスタートアップは業務が複雑になりがちで、かつ状況の変化も早いため、コミュニケーションがボトルネックになりがちです。 コミュニケーションの遅れは意思決定の遅れにつながります。そして意思決定の遅れは事業の進捗を遅らせたり、トラブルの兆候を見逃してトラブル発生の原因にな
Announcing Remacs: Porting Emacs to Rust
I am delighted to announce Remacs, a project to port Emacs to Rust! Emacs, at its heart, is a lisp interpreter written in C. In Remacs, we’re replacing this C code with Rust, and all the elisp you know and love will just work. If you’ve ever fancied contributing to core Emacs, this is a great opportunity to learn the internals. There’s tons of low hanging fruit, we have a list of good first bugs a
Big Sky :: golang の http.Client を速くする
« Windows からも ssh でリモートコマンド実行したい、それ golang で出来るよ | Main | Re: Go でシングルバイナリな Web アプリを開発しているときに webpack --watch をうまいところやる » この記事には幾らか正しくない部分がありました。後で訂正していきますが、ひとまず shogo82148 さんの解説記事も確認下さい。 http.Client はリクエスト毎に名前を引くので連続したアクセスはあまり速くない。 Goのhttp.Clientで名前解決結果cacheする楽な方法ないかな — fujiwara (@fujiwara) December 7, 2016 Go 1.8 からは Resolver が提供されるので、自前で簡単に名前引きのキャッシュを実装出来る。 Go 1.9 だった様です。 Go 1.8 Release Notes -
nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編）
Cの系譜を継ぐC#ではnullが長らく使い続けられてきたが、最近ではその存在が大きな問題だと認識されている。前後編でこの問題を取り上げ、今回（前編）はnullを取り巻く事情について考察する。 ← 前回 連載 INDEX 次回 → 近年、nullの存在は、billion dollar mistake（10億ドル規模の損失をもたらす過ち）と呼ばれるくらい忌避されるものになっている。 nullは、低コストでそこそこ安全に参照を扱えるという意味で悪くない妥協ではあるが、技術が進歩した現在ではもう少し賢い参照の扱い方があるはずである。C#のように、これまでnullを認めてしまっているプログラミング言語で、今からそれを完全になくすというのは現実的ではないが、nullに起因する問題を少しでも避ける手段はこれからでも追加していけるだろう。 今回は、nullが生まれるに至った背景から始め、nullが抱える問
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://go-review.googlesource.com/