短期間で新技術を学ぶ技術
シリコンバレーのスタートアップを数多く取材する中で気付いた「シリコンバレーにおけるディシプリン（規律）の存在」や「General Electric（GE）やIBM、SAPといった老舗企業が必死になってシリコンバレーのスタートアップを真似している理由」、そして「日本企業がイノベーションを実現するための処方箋」について解説します 詳しく知りたい場合は「GE 巨人の復活」をご覧下さい。 http://www.nikkeibp.co.jp/atclpubmkt/book/17/P55110/ 今後の記事は「シリコンバレーNext」をご覧下さい。 http://itpro.nikkeibp.co.jp/siliconvalley/
ちょっといいJavaコードを書こう - Qiita
一人でプログラムを書いてたりすると、環境によってはあまりコードの書き方には指摘を受けなくて困りますよね。プロになっても、曲がりなりにもちゃんと動くコードを書けてしまうとあまりに当たり前のことなんかは指摘されることも稀で、そのままある程度偉くなっちゃった日には、もはや自分で気付くしかなくなってしまいます。 FindBugsとか、Effective Javaなら使ったり読んでみたり読ませたりすることはできますが、それ以前のところって難しいんですよね。よいコードと言うよりそれが当たり前だと思われているので、指摘するにしても「こうすればいいよ」（アドバイス）じゃなくて「なんでこうしてないの？」（詰問）になってしまいがちです。 そこで、最近そういうJavaニュービーに指摘している（したい）ことの多い、Javaの基礎的な事柄をまとめてみました。ワタシJavaチョットデキルって人は、これ以外にもやりがち
2016年のOSS圧縮ツール選択カタログ - Qiita
まだgzipで消耗し（略） 2016年、人類が待ち望んでいた、gzipを圧倒するOSS圧縮ツールzstd(Zstandard)がリリースされたにも関わらず、なんかあんまり話題になっていなくて寂しいので、ちょろいかんじの賑やかし比較記事を書きました。圧縮ツールのカタログ的に眺めていただけるかと思います。 はじめに （この記事で言う）圧縮ツールとは何か 圧縮ツールという呼び名は正確ではない（はず）です。平たく言えば、gzipやbzip2、xz、lz4などですが、人によっては、tarの裏側としてしか使ってなくて、聞いたこともないかもしれませんね。そういうときはまずgzipのmanpageとか読んでください。 しかし、そういうツールを何と呼べばいいのかわからないので、ここでは圧縮ツールと呼んでいます。 ややこしいですが、アーカイバではありません。アーカイブとは実態が一つのファイルになっているフォル
[Vim] シンプルなファイラー「Vaffle」をつくりました - ここぽんのーと
こんばんは。Vimがないと戦闘力が10%程度まで低下してしまうcocoponです。シンプルなファイル操作プラグイン「Vaffle」を新たに開発しまして、今回はその紹介記事です。 Vim標準のファイラー「Netrw」Vimには、「Netrw」という名前のファイラーが標準で付属しています。例えば :e . （カレントディレクトリを開く）のようにディレクトリを開くと、Netrwが起動します。 これがちょっと使いづらいのです。慣れの問題もあるのかもしれませんが、ファイル操作がサクッと直感的にできない。 例えば、 ~/foo.txt を ~/bar/ に移動しようと思ったら、 ~/ を開いてファイル一覧を表示移動先 bar/ を mt でターゲットに設定移動対象 foo.txt を mf で選択選択した移動対象を mm でターゲットに移動という操作になります。うーむ…。 ネットワーク越しのファイルを
![[Vim] シンプルなファイラー「Vaffle」をつくりました - ここぽんのーと](https://cdn-ak-scissors.b.st-hatena.com/image/square/929b6be91dd60118c1919761d750a9849cabe5c8/height=288;version=1;width=512/https%3A%2F%2Fcocopon.me%2Fdata%2Fblog%2F2017%2F01%2Fvaffle%2Fvaffle.png)
コミットメッセージの書き方 - MAYAH
ここ5年ほど pre commit review があるような環境(主に chromium とか)で働いてきたので、コミットメッセージの書き方を自分なりにまとめておきます。 コミットメッセージで伝えたいことはパッチのコンテキストである コミットメッセージはコードレビュー依頼であるという態度で記述します(受け売り)。そのため、コードレビュー者がパッチのコンテキストを理解できるように記述するべきです。なにをやっているのか分からないパッチを渡されるより、これはこういう理由でこういう変更をやっているパッチだということを伝えてからパッチを見たほうが、パッチの理解も速いでしょう。レビュー者にパッチのコンテキストを理解してもらえれば、コードレビュー速度が上がったり、コードのミスが見つけてもらいやすくなるという利点があります。 コミットメッセージの基本的なフォーマット コミットメッセージには一般的に使われ
私的アンリーダブルコード―他人を発狂させるための 9 のテクニック
コードはたいてい一度しか書かれませんが、何度も何人も読むことになります。 普段何気なく書いているコードが他人の時間と精神を削っているかもしれません。 そんなわけで、個人的に辛いなと思うことを 9 つ挙げてみました。共感してもらえるものもいくつかあるんじゃないかと思います。 実体にそぐわない変数名 見分けの付かない配列とハッシュの変数名 呼び出し元で true/false を指定するだけの引数 暗黙の実行順序 [] メソッドの定義・Array の継承 ハッシュの乱用 密結合した mixin 過剰な nil guard 条件によって異なる返り値の型 推薦図書 静的型付き言語を使うことで解消される問題もありますが、その選択肢はひとまずなしということで。 Ruby 前提になっていますが、他の言語にも言えることも多いと思います。 実体にそぐわない変数名 例えば Vehicle というクラスが定義され
Books For Site Reliability Engineering
By: Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield Can a system be considered truly reliable if it isn't fundamentally secure? Or can it be considered secure if it's unreliable? Security is crucial to the design and operation of scalable systems in production, as it plays an important part in product quality, performance, and availability. In this bo
「速」を落とさないコードレビュー
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/Read less
Rust は何が新しくないのか - ろじかるんるんものがたり
disclaimer 追記で注意書き足すのはどうなんでしょうね。ということで追記です。 別にギョムでガンガン書いてるとかではないです。 ノミコンの方も含めてドキュメント全部読んだ、API 一通り眺めた、型推論というかリージョン推論部分の概要眺めた、関連する論文読んだ、言語触った、程度の人間が書いてます。 正しくない、不正確な部分もあると思います。 雑です、すいません。 TL;DR 的には、C++ 置き換えるための言語として作られたので当然 C++ にあった概念引き継いでますよみたいな話です。 以下追記前の元の全文。 以下の記事が結構人気と聞きました。 Rustは何が新しいのか（基本的な言語機能の紹介） - いもす研 (imos laboratory) ここでは、記事中の「新しくない」部分を historical な話を交えて説明する形で何か書きたいと思います。 記事を否定するようなものでは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
