良いコードを書けるようになりたい 私は基本的にはソフトウェアはずっと趣味で独学でやってきたのですが、最近GitHubでコードを公開するようになったり、仕事でも少しソフトを書くようになったので、良いコードを書くための基礎を勉強したいなと思い、年末年始に以下の本を読んでみました。 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)posted with ヨメレバDustin Boswell,Trevor Foucher オライリージャパン 2012-06-23 AmazonKindle楽天ブックス ベタープログラマ ―優れたプログラマになるための38の考え方とテクニックposted with ヨメレバPete Goodliffe オライリージャパン 2017-12-15 AmazonKindle楽天ブックス 「リーダブルコード」
![良いコードを書けるようになるため「リーダブルコード」と「ベタープログラマ」を読んでみた - karaage. [からあげ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/b0f7a13dd914bc3e8bea51fe6b55fb13107b369a/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Fc57d7fbd6f5641b2f51e643f69d9c70ee2e6a887%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fk%252Fkaraage%252F20180102%252F20180102111827.jpg)
SINGULARITY P2 Containers for Science, Reproducibility and Mobility Presented By: Gregory M. Kurtzer HPC Systems Architect Lawrence Berkeley National Lab gmkurtzer@lbl.gov http://singularity.lbl.gov/ CONTAINERS IN HPC: SINGULARITY CONTAINERS (YESTERDAY IN A NUTSHELL) CONTAINERS IN HPC: SINGULARITY SO… WHAT IS ALL THE COMMOTION ABOUT? ▸ Reproducibility and archival software and environment stacks ▸
Redirecting… Click here if you are not redirected.
When Google’s Gradient Ventures invested in us, they did so with an understanding that it is incredibly hard to deploy AI/ML infrastructure — and that every dev team is going to need to solve this problem. Our solution, the AI Layer, is a best-in-class architecture. As our co-founder, Kenny Daniel says: Tensorflow is open-source, but scaling it is not. DevOps for AI presents massive challenges to
There is more to building a sustainable Deep Learning solution than what is provided by Deep Learning frameworks like TensorFlow and PyTorch. These frameworks are good enough for research, but they don’t take into account the problems that crop up with production deployment. I’ve written previously about technical debt and the need from more adaptive biological like architectures. To support a via
KubernetesでGPUを使う 一般的なWebアプリケーションと比較してMachine Leaning（ML）は複雑なインフラを要求する．Data processingを行う環境やModelのTraining/Validationを行う環境，実際にサービスからModelを利用するためのServingの環境といった複数の異なる環境が必要であり，WorkloadによってはCPUだけではなくGPUも必要になる．これらを効率的に扱うためのインフラを構築・運用するのは容易でなくGoogle and Uber’s Best Practices for Deep Learningにあるようにこれまで培われてきたDevOpsの知見を結集していく必要がある． このような複雑なMLのインフラとしてContainerとKubernetesが利用されることが多くなってきている．特に複数の環境間のPortabi
広く使ってもらうためというよりは、自分のアプリケーションで何度も同じコードを書きたくないのがライブラリ化のモチベーションです。 Inspired by repatch and ngrx/storelacolaco/reactive-storeの設計はrepatchとngrx/storeに影響を受けています。Angularでアプリケーションを書くことが多いので、RxJSフレンドリーなストアとしてngrx/storeを使っていましたが、2つの不満な点がありました。 現在の状態のスナップショットが取れない（非同期APIしか存在しない）ActionとReducerが冗長代わりになるストアのライブラリを探したところ、repatchは自分がほしいものにとても近かったのですが、RxJSのObservableと互換性がないことと、subscribeできる単位がストア全体という部分が不満で、結局自分で作るこ
GitBucketでの長年の課題の1つがGitリポジトリのスケールアウトと冗長化でした。Gitリポジトリを格納するストレージに分散ファイルシステムを使うというのは1つの解決策になりますが、分散ファイルシステムの運用はなかなか大変です。もっと手軽に使い始めて徐々にスケールできる方法はないものかと考えていたのですが、1つ思いついたアイデアを試すために実験的にコードを書き始めてみました。 github.com 基本的なアイデアは普通のGitサーバを複数台用意しておき、リポジトリを分散配置するというものです。例によってScalaとJGitを使って実装されています。 Gitクライアントからのリクエスト（pushやfetch）はフロントコントローラーでルーティングされ、リポジトリの配置されたノードにプロキシされます。リポジトリは全く同じものが複数ノードに存在するので1ノードが落ちても動作を継続すること
3つのコミュニケーションパターン 会社でコーチング研修があり、(主に部下と1on1を想定して)コミュニケーションパターンが以下の3つに分けられるという話がありました。 コーチング： 「答え」は相手の中にある 相手の話を聞く/問いかける/人となりを認める ティーチング： 「答え」はこちらにある 知識ややり方を教える/相手が理解してないことを説明する フィードバック： 成長を促すために、周りからどう見えているか、思われているかを伝える ポイントは 「いつもティーチングで自分が思うことばかり言ってしまってないか？アプローチには種類があることを認識し、適切に使い分けていこう」 という話でした。 これだけでもとても面白い話だったのですが、「これ、コードレビューでも同じではないか？」と思ったのです。 レビューにおけるティーチングとコーチング ティーチング ティーチングはいわゆる「指摘」です。 プルリク
OS起動中に保持されるDNSキャッシュを表示するには、ipconfig /displaydns または powershell -c Get-DNSClientCache （Windows 8以降）を使う。 >ipconfig /displaydns Windows IP 構成 www.gstatic.com ---------------------------------------- タイプ AAAA のレコードがありません www.gstatic.com ---------------------------------------- レコード名 . . . . . . . : www.gstatic.com レコードの種類 . . . . . : 1 Time To Live . . . . . .: 236 データの長さ . . . . . . : 4 セクション . . . .
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
