1on1-questions/README.ja_JP.md at feat/i18n-jp · mohikanz/1on1-questions
私があなたのために取り除くことができる障害はありますか？ マネージャーとして、私にやめてほしい/始めてほしい/続けてほしいことは何ですか？ この1週間のどの時点で、仕事に最も不満を感じましたか？ それを治めるために私にできることは何ですか？ フィードバックは十分ですか？どうしてそう思いますか？ 私に何かフィードバックはありますか？ あなたは十分なフィードバックを受け取っていると思いますか？ フィードバックはあなた個人の成長に役立っていますか？ あなたが求めるフィードバックを得るために、私に何ができますか？ どうしたらもっとあなたをサポートできますか？ あなたの日常をもっと充実させるために、私にできることはありますか？ どうしたらあなたとのコミュニケーションをもっと良くできるでしょうか？ どんな風にフィードバックを受け取りたいですか？ あなたにとってこのプロジェクトをより挑戦的、または面白く
githubのissue, pull request 検索をハックする！ | ランサーズ（Lancers）エンジニアブログ
こんにちは、エンジニアの上野です。 ランサーズストア の開発責任者として日々奮闘中です。 今日は、エンジニアみんな大好きgithubの検索クエリをハックする！！と題して、検索クエリの解説をしようと思います。githubではissueやpull requestを検索するときにクエリを指定すると結構柔軟に条件を指定して調べることが出来ます。 自分自身、入社してから数え切れないリリースをしているので、しばしばこのクエリを用いて過去のissueなどを調べています。せっかくの機会ということで、「公式helpに沿ってルールのまとめ」と「普段使っているクエリの紹介」の2部構成でお届けします。 githubのissue, PR検索用で使えるクエリ一覧 ここからは公式helpにある文法を日本語で解説していきます。 公式のhelpのまとめ方が少し冗長だなと感じる部分は項目を合体させてできるだけ簡潔に記述するよ
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
A simple golang web server with basic logging, tracing, health check, graceful shutdown and zero dependencies
main.go ��Q,�U � w,�U package main import ( "context" "flag" "fmt" "log" "net/http" "os" "os/signal" "sync/atomic" "time" ) type key int const ( requestIDKey key = 0 ) var ( listenAddr string healthy int32 ) func main() { flag.StringVar(&listenAddr, "listen-addr", ":5000", "server listen address") flag.Parse() logger := log.New(os.Stdout, "http: ", log.LstdFlags) logger.Println("Server is starting
レイテンシーを計算する技術の話 - LINE ENGINEERING
こんにちは、LINEメッセンジャーのサーバーサイドとモニタリングプラットフォームの開発を担当しているフィ（@dxhuy）です。この記事はLINE Advent Calendar 2017の20日目の記事です。 今日は、モニタリングシステムでよく使うレイテンシーやその計算方法などについて紹介したいと思います。LINEでは、日々ユーザが楽しくメッセージを送れるように、システムの安定性を第一に考えています。安定したシステムを保つためにたくさんの指標を見守る必要がありますが、その指標の1つが「レイテンシー」です。 ウィキペディアでは、レイテンシーは以下のように定義されています。 デバイスに対してデータ転送などを要求してから、その結果が返送されるまでの不顕性の高い遅延時間のこと インターネットサービスにおいては、レイテンシーは基本的に「レスポンスタイム」のことです。つまり、リクエストを受けてからレス
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
優秀なプログラマになるために - @ledsun blog
みんな良いこと言うので、刺激を受けて考えたことを記録します。 生きてるだけで丸儲け ストレス対処法 撤退戦術 タスク殺すマシーン 人間に戻る儀式 運 技術力を身につける方法 車輪を再発明する 脱ゴールデンハンマー病 学習の助 優秀なプログラマとは？ おまけ 生きてるだけで丸儲け 優秀なプログラマーになるためのコツ · GitHub 優秀なプログラマーに「育つ」んだし、それには時間が必要 優秀なプログラマーになるということは、上記の通り長時間を要するということも踏まえると、メンタルヘルスにリスクがある環境に長時間暴露されることが不可避である 業界で長きにわたり活躍し続けている人というのは、それだけですでにひとかどの人物 すごく良いです。 優秀なプログラマになる前に、死んでしまっては元も子もありません。 生き延びることはなにより大切です。 幸か不幸か現状のIT業界はハードなストレスにさらされや
Linux におけるスレッド数の上限 | yunabe.jp
並行 (Concurrent) 処理を実装する方法としてスレッドは非常に強力なツールです。 スレッドを使えば同時に1つの処理しか行えない既存のプログラムに大きな修正を加えることなく、 並行処理を実装することが可能です。 またイベントとコールバックを複雑に組み合わせた非同期的なプログラムに比べて、 同期的なプログラム (例えばファイルの読み込みにコールバックが出てきたりしない普通のプログラム)は プログラムの流れを自然に書くことができ、 可読性・保守性・テスト、デバッグのしやすさの面で遥かに優れています。 スレッドを使うとプログラムをそれほど複雑・難読化にせずに並行処理が実装できます。 一方でスレッドを使った並行処理には欠点もあります。 欠点の1つは、スレッドモデルでは1つの処理に対して1つのスレッドを用意するので、 システムのスレッド数の上限で同時に行える処理の数が決まってしまう点です。
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のようなプルリクエストのガイドラインを導入しました。 プルリクへのコメント (原題 : Approach to writing a Pull Request) プルリクエストには目的を明記しましょう。たとえば… これは〜を調べてみるためのプロトタイプです これは
[Github Universe 2016]巨大なGitHubを支える3点分散システム「Spokes」とは?
レポート [Github Universe 2016]巨大なGitHubを支える3点分散システム「Spokes」とは? 世界中で使われているGitHub。そのリポジトリの総数は3800万、Gistの総数は3600万を超えている。このような大規模システムはどのような仕組みで構築されているのだろうか。Githubが9月13日から15日にかけて開催した年次イベント「GitHub Universe 2016」で、同社のGitインフラストラクチャエンジニアリングマネージャであるPatrick Reynolds氏が発表した内容からその仕組みを解いてみる。 データ複製の仕組みを変更 GitHubは最近、インフラストラクチャの構造を変更したそうだ。これまで、ファイルサーバに配信されたデータはいわゆるRAIDのような技術を使って複製が行われていた。これをアプリケーションレベルでのレプリケーションとなる分散型
![[Github Universe 2016]巨大なGitHubを支える3点分散システム「Spokes」とは?](https://cdn-ak-scissors.b.st-hatena.com/image/square/b6ca22b1617eaf18cdc50c4cea7ac5d99bfaaa3b/height=288;version=1;width=512/https%3A%2F%2Fnews.mynavi.jp%2Ftechplus%2Farticle%2F20160923-githubuniverse5%2Findex_images%2Findex.jpg)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - eliben/raft: :rowboat: Raft implementation in Go
GitHub - thewhitetulip/web-dev-golang-anti-textbook: Learn how to write webapps without a framework in Go.
Emoji Cheat Sheet
Nginx Location Match Visible
Add a help target to a Makefile that will allow all targets to be self documenting
OpenMetrics/protos at master · RichiH/OpenMetrics
GitHub - getgauge/gauge: Light weight cross-platform test automation
GitHub Audio
GoでFUSEを使ってGitHubのIssuesをマウントする - Qiita
SSH client in GO · GitHub