役立つコードレビュー（CR）のコツは、学校では習いません。アルゴリズム、データ構造、プログラム言語の基礎は習っても、確実に役に立つフィードバックを返す方法をじっくりと教えてくれる人はいないでしょう。 コードレビューは優れたソフトウェアを作り出すには欠かせないプロセスです。レビューを通したコードは、そうでないコードよりも 質が高く、バグが少ない 傾向があります。健全なコードレビュー文化には、副次的な利点もあります。たとえば、 バス因子 を押しとどめる、新メンバーのトレーニングに最適なツールになる、など。また、コードレビューは優れた知識共有の手段でもあります。 前提 まずは、この記事のポイントの前提を提示する必要があるでしょう。それは以下のとおりです。 信頼のおける環境で作業をしている。あるいは、あなたとチームは、あなたの信頼性を高めることを目指して作業している。 コードではないシナリオでフィ

(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) GutenbergとWordPressに関する騒動は、PHPの終焉につながる最新記事です。深呼吸をしてください、みなさん。トロールは無視し、Mark TwainとFidel CastroとPHPとの共通点を見ていきましょう。そして、もっと重要なのは、スタートアップやスモールビジネスにとって、PHPが今でも合理的な選択である理由です。 PHPはいつから廃れ始めたのか “PHPはもうダメだ”といったブログの投稿が、登場し始めたのは2011年のようです（これより古いものを見つけたら、お知らせください）。Mediumや、mushroomsのように突然出現したcoding bootcampsを探し回れば、その唯一の共通点は、みんながPHPを嫌っているか、あるいは単に無視しているかです。どうやら、法外な値段のコー

「児童３０人をレイプした小児性愛者でHIV陽性の司祭　教会の外で磔りつけに」 というようなタイトルを最近、見たことはありますか？　それほど以前のことではないでしょうね。こうした不快で輝かしくないタイトルには、特に心がそそられるものです。ソーシャルメディアのフィードをスクロールしているとき、大げさな見出しの付いたニュースがシェアされているのに出くわしたことは、誰にでもあるはずです。疑いを抱きながら記事をクリックして読む人もいれば、ニュースの出どころを確かめもせずに即座にシェアする人もいるでしょう。 注釈： 「画像が付いているからといって、ネット上の情報をどれもこれも鵜呑みにしてはならない」―アブラハム・リンカーン 批評精神のある読者なら、数分間の手間をかけ、Googleが指示する注意義務を払って話の真実性を確かめるでしょう。でも、そのときには、その話は急速に広まって何百万回も閲覧されていて、

本稿は、オブジェクト指向プログラミング（OOP）について予備知識のないJavaScriptの学習者向けに書かれています。OOP の中でJavaScriptに関連する部分にのみ焦点を当て、OOPの概要については説明しません。ポリモーフィズムについては、静的型付け言語の方が適しているため省きます。 なぜOOPを知る必要があるか？ あなたは初めてのプログラム言語にJavaScriptを選びましたか？　あなたはコードが10万行以上にわたる巨大企業のシステムを扱う腕利きの開発者になりたいですか？ オブジェクト指向プログラミングを最大限活用できるように学ばなければ、到底無理でしょう。 様々な考え方 サッカーでは、安全に守りを固めることもできますし、サイドからの高いボールに飛びつくこともできます。また、先など考えずに攻撃することも可能です。これらの戦略は全て同じ目的を持っています。それは試合に勝つことで

デスクトップ ここでは、実際にデスクトップアプリケーションにならしめているデスクトップアプリケーションの一部についてお話しします。特定のスキルセットを必要とするデスクトッププラットフォームは大量に存在しています。例えば、Photoshopは画像を扱うアプリケーションなので、Photoshopなどで何か書きたければ、画像の処理を行うアルゴリズムと技法を絶対に知っておく必要があります。Dropboxなどで何か書きたい場合は、ソケットプログラミングを絶対に知っておく必要があります。そしてVisual StudioなどでコンパイラやIDEをビルドしたければ、コンパイラの操作方法を絶対に知っておく必要があります。ここではその詳細には触れません。デスクトッププラットフォームに取り組みたい場合に最も使う可能性のある言語について見ていきます。 デスクトッププラットフォームに関して言えば、プログラマはC++

プログラミングの森の奥で道に迷わないために 私がプログラミングの仕事を始めたばかりのころの悩みの種は、どの言語や技術を選ぶべきか、でした。何を学び、何から始めればいいのか。プログラマとしての初仕事を獲得するために知っておくべきことは何か。そのころ（ほぼ10年前）、CourseraやUdemyや SoloLearn は、ありませんでした。いい職に就くための確実な方向、完璧な道筋がどんなものなのか、私にはわかりませんでした。高給で、満足できて、優遇される、21世紀の宇宙飛行士、つまりプログラマの仕事を得るには。 問題は今でも相変わらず同じです。ビギナーは選択の段階でつまずき、優れたプログラマになるための近道はなく、コミュニティは「Pythonっていう言語は簡単ですか？」というような新入りの質問を歓迎するほど温かくもありません。プログラマとして成功するための道筋は、むしろ以前よりも見えにくくなっ

情報科学科の卒業生やプログラマの中には、UberやNetflixのような新興企業や、 Amazon 、 Microsoft 、 Google のような大企業や、InfosysやLuxsoftのようなサービスを基本とする企業で、プログラミング、コーディング、ソフトウェア開発の仕事に就きたいと考える人が大勢います。しかし、実際にそういった企業で面接を受ける場合、大半の人が プログラミングに関してどのような質問をされるか 見当もつきません。 この記事では、 新卒生からプログラマになって1〜2年までの 経験値が異なる人たち向けに、それぞれの プログラミングの面接でよく聞かれる質問 をいくつか紹介していきます。 コーディングの面接では、主に データ構造とアルゴリズムに基づいた質問 がされますが、 一時変数を使わずにどのように2つの整数をスワップするのか 、というような論理的な質問もされるでしょう。

メッセージの耐久性と持続性 分散型システムのノードは演算し、データを保存し、互いにメッセージを送信し合います。メッセージ送信の重要な指標は、これらのメッセージがどれだけ確実に届くかです。基幹システムでは、消失メッセージがゼロでなくてはならない場合がしばしばあります。 分散型システムにおける通信は、RabbitMQ、Kafkaなどの分散型メッセージングサービスを用いることがほとんどです。こういったメッセージングサービスはメッセージ配信において様々なレベルの信頼性をサポートしています（または、サポートするように設定を変えられます）。 メッセージの永続性とは、メッセージを処理しているノードで何らかの問題が起こった時、その問題の解決後に処理されるよう、メッセージはそこに残ることを意味します。メッセージの持続性は多くの場合、 メッセージキュー レベルで用いられます。持続性のあるメッセージキューを実装

新しいプロジェクト始まると、開発者はいきなりプログラミングに飛びつく傾向があります。それもいいでしょう。結局、それが仕事なのですから。でも、時には飛びつく前にブレーキをかけて、ソフトウェア設計から手を付けるのもいい考えかもしれません。 “ホワイトボードを使う長袖のホワイトシャツの男性”（出典： Trent Erwin ／ Unsplash ) ソフトウェア設計にはいろいろな方法があります。UMLなどのモデリング言語のソフトウェアを利用することもできるし、 テキストを書いて 画像を使うこともでき、あるいはホワイトボードに描くこともできます。ここで大切なのは、ソフトウェアの開発中に設計を保存して再考できることです。設計は多少なりとも改善していかなければなりません。ですから、いつも最初からホワイトボードに描きたいというわけではないのならばデジタルデータで、設計を行うのも良さそうです。データの保存

DevOpsエンジニアになるためのイラストガイド（関連コースへのリンク付き） DevOpsは今とてもホットなテーマです。多くの友人、同僚、上級開発者である知人がDevOpsのエンジニアとなり自分のいる組織の中で第一人者になろうと一生懸命になっています。 私は DevOps の恩恵を心から認めています。DevOpsはソフトウェア開発とデプロイの改善に直結しているからです。しかし私の限られた経験から言っても、DevOpsのエンジニアになるのは 簡単ではありません。 非常に多くのツールと事例があり、適切な学び方を選ぶのがとても難しいのです。 Javaのブロガー としてよく質問を受けます。例えば、 DevOpsのエンジニアになるにはどうすれば？ どのツールを学べば？　どんな事例を参考にすれば？　DevOpsエンジニアにはMavenとJenkinsがマストですか？ DockerやKubernetes

多くの人が気付かないうちにWeb2.0からWeb3.0への移行が進みそうです。アプリケーションの見た目は現在使っているものとほとんど変わりませんが、バックエンドで変化が進んでいきます。未来を予測する人ならば、クラウドを使うSiacoin、ソーシャルメディアのプラットフォームとしてのSteemit、さらに未来を予想する手段としてAugurも頭に浮かぶのではないでしょうか。 適正に動く最初のブロックチェーンがリリースされたことを見れば、人々がWeb2.0を離れWeb3.0へ向かっているのは明らかでしょう。なぜなら、開発者というのはテクノロジーとWeb2.0のユーザーフレンドリーな手法を身につけても、更に使いやすいと考えられているWeb3.0に着手しようとするからです。 上の図の分布では、いろいろな企業とWeb2.0のセグメントが示され、ブロックチェーンに基づいたプロジェクトのどれに勝ち目がある

スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外

(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま

バックエンドに関する経験があった私は、2年前にモバイルソフトウェアエンジニアとしてUberに入社しました。担当することになった仕事は、決済機能の構築を含む アプリの刷新 です。その後、 技術管理の側に回る ことになり、チームそのものを率いることになります。配下のチームは、決済を行うバックエンドシステムの多くを担当していたため、責任者となった私もバックエンドに触れる機会が以前にも増して多くなりました。 Uberで働く前は、分散型システムの経験はなきに等しかったと言っていいと思います。 それまでの私は、一般的なコンピュータサイエンスの学位を取得後、フルスタックのソフトウェア開発に10年間、関わっていました。分散型システムについては、一応、大まかな仕組みやトレードオフなどは知っていましたが、一貫性や可用性、冪等性などの概念に精通していたとはお世辞にも言えません。 この記事では、大規模で可用性が高

機械は言語の処理を学習する際、人が書いた文章のサンプルから性別や人種的な偏見を継承します。 トルコ語では、”彼（he）”、”彼女（she）”、”それ（it）”を表すための代名詞が、”o”の1つしかありません。”o”の代名詞が含まれるトルコ語の文章をGoogle翻訳で英語に翻訳する場合、翻訳アルゴリズムは英語のどの代名詞が”o”に相当するのかを推測することになります（性別が不明な場合、大抵は”彼”）。そして、アルゴリズムは ジェンダーバイアス（性差に基づく偏見） を反映しながら、”彼は医者です”、”彼女は看護師です”、”彼は勤勉です”、”彼女は怠け者です”のような形で文章を翻訳するのです。言語処理の学習に際して、多くのアルゴリズムは人が書いたニュース記事やWikipediaなどの文章を参考にしており、こうした言語モデルから単語間の関連付けを行っています。しかしそうすることで、例えば” 「彼」

(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) Pythonは高い人気を誇り、DevOps、データサイエンス、Web開発、セキュリティの分野で使われています。 しかし、速度に関しては高い評価が全くありません。 JavaとC、C++、C#、Pythonの速度を比べるには、どうしたらいいのでしょう？　答えは、実行するアプリケーションのタイプに大きく左右されます。完璧なベンチマークはありませんが、[手始めに比べる手段](https://algs4.cs.princeton.edu/faq/)としてはThe Computer Language Benchmarks Gameが適しています。 私は10年ほどthe Computer Language Benchmarks Gameを参照していますが、Java、C#、Go、JavaScript、C++などの他言

経営に関する名著「 High Output Management （邦題：ハイアウトプット・マネジメント（＝高い成果を可能にするマネジメント））」の中でAndy Groveは、”トレーニング（訓練・教育）はマネージャーの仕事”であり、組織の成果を向上させるためにマネージャー（経営者・管理者）が実践できる最高のレバレッジ活動だと述べています。 多くの組織のマネージャーにとって、この言葉は現在においても参考にできる素晴らしいアドバイスでしょう。しかし、現代のソフトウェア開発チームのマネージャーに関して言うと、その中心となる考え方はシフトしています。 > エンジニアリングチームの成果向上にとっては、GitHubのプルリクエストなどで実行するコードレビューが、今では最大のレバレッジポイント（レバレッジの作用点）である。 品質管理以上の役割 従来、コードレビューのプロセスは品質管理のツールと見なされ

開発者が、開発者ではない同僚から言われて嬉しい11の言葉 – 「クライアントが、IE6で使えなきゃダメだと言っている」 「 決して、 君にキレそうなのを隠すために笑っているんじゃないよ」 非開発者は、職場の開発者をコードで魔法を生み出す人々だと思っています。開発者なら、終日複雑なAPIインテグレーションを構築することもあれば、マウスをカチカチさせて単にSteamで West of Loathing をプレイしているだけの場合もあるでしょう。99％の同僚にはその違いが分かりません。テック企業は開発チームなくしては文字どおり存在しえないのに、開発者は、日がな無為な会議に出て他人の仕事を自分の手柄にしているチーフ・インスピレーション・ニンジャといった役職の人々よりも給与が低かったりします。 開発チームともっとうまくコミュニケーションをとれる方法はないものかと考えている人に、開発者が非開発者から言

最近、『The Atlantic』に掲載された非常に重苦しい 記事 「The Coming Software Apocalypse」（きたるソフトウェア大惨事）を読み終えました。同記事は最初のうちは、人に傷害を与えたり、人の命を奪ったりした恐ろしいソフトウェアバグについて述べており、いい内容です。しかし、途中から急に残念な展開になっているのです。 同記事の著者はソフトウェア業界の多くの思想的リーダーにインタビューをしましたが、 Light Table 、 モデル駆動工学 、 TLA+ といった新しい技術を生み出したリーダーだけを選んでいます。 私はこうしたツールに何ら反対しているわけではありません。Light Tableプロジェクトに資金提供さえしました。優れたソフトウェアツールは優れたソフトウェアを書きやすくすると思います。しかし、ツールは「大惨事」に対する解決策ではありません。 著者は