Goは、 信頼できる賢い人たち によって作られた愛すべきささやかなプログラミング言語で、 現在も成長中の大規模なオープンソースコミュニティ によって、継続的に改善が続けられています。 Goの基本原則はシンプルであることですが、時折、約束事が分かりにくいこともありますね。以下では、私がどのようにしてGoのプロジェクトを始め、どのようにGoのイディオムを使っているかを紹介したいと思います。一緒に、Webアプリケーション用のバックエンドサービスを構築しましょう。 環境の構築 新規プロジェクト Webサーバの作成 ルートの追加 複数APIへのクエリ 並列化 シンプルさ 追加演習 環境の構築 最初のステップは、もちろんGoをインストールすることです。オフィシャルサイトに用意されている、 お使いのオペレーティングシステム用のバイナリディストリビューション を使ってください。MacでHomebrewを使

文：Daniel Sim　分析：Lee Shangqian、Daniel Sim、Clarence Ng ここ数ヶ月、シンガポールのMRT環状線では列車が何度も止まるものの、その原因が分からないため、通勤客の大きな混乱や心配の種となっていました。 私も多くの同僚と同じように環状線を使ってワンノースのオフィスに通っています。そのため、11月5日に列車が止まる原因を調査する依頼がチームに来た時は、ためらうことなく業務に携わることを志願しました。 鉄道運営会社SMRTと陸上交通庁（LTA）による事前調査から、いくつかの電車の信号を消失させる信号の干渉があり、それがインシデントを引き起こすことが既に分かっていました。信号が消失すると列車の安全機能である緊急ブレーキが作動するため、不規則に電車が止まる原因となります。 しかし8月に初めて発生した今回のインシデントは、不規則に起こっているように見えるた

(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい

新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します（またはソースコードを丹念に調べます）。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか？ 「誰かが既にこの問題を解決しているはずだ！では、なぜこの問題に対する答えがStack Overflowにないのだろうか？」 そのとおりです。恐らく誰かは既にそれを解決

ここで論じているのは、オーディオアプリの開発者が陥りがちな 4つの間違い 、 より良く開発する方法 、 問題個所の発見方法 です。主に開発者向けの内容ですが、開発者以外の方にも知っておいてもらいたいと思います。ここでは、開発者向けの診断ツールである Realtime Watchdog を紹介し、 人気のあるオーディオライブラリの調査結果 を提示します。 オーディオアプリの開発はとてつもなく楽しいです。やりがいを感じるし、創造力を発揮できる範囲が大きく広がり、ひとたび開発が終われば、 誰かがクリエイティブなツールとして使ってくれるのです！ こんな分野は多くないし、この領域で働けるなんて非常に幸運だと自分でも思っています。 しかし、仕事でオーディオアプリを扱う時には深く考えなければならない部分もあります。オーディオアプリの開発者としてユーザに対する責任があるのです。大前提として、ユーザを公共の

(2016/7/7、いただいたフィードバックを元に記事を修正いたしました。) JavaScript、特にNode.jsといえば、 コールバック地獄 がよく連想されます ^(1) 。たくさんの非同期I/Oを扱うコードを書いたことがある方には、おそらく以下のようなパターンはおなじみでしょう。 export default function getLikes () { getUsers((err, users) => { if (err) return fn(err); filterUsersWithFriends((err, usersWithFriends) => { if (err) return fn(err); getUsersLikes(usersWithFriends, (err, likes) => { if (err) return fn (err); fn(null, lik

あなたが真剣に Docker に取り組んで、その全てを学びたいと思っているのでしたら、もう探し回らなくても大丈夫です。 本稿では、Dockerがどのように機能するのか、どんな部分が話題になっているのか、そしてマイクロサービスを構築する際の基本的な開発作業にどのように役立つのかについて紹介したいと思います。 本稿では例として、ローカルで実行するコードからマイクロサービスやデータベースを実行するコンテナまで、バックエンドにMySQLを用いたシンプルなNode.jsのサービスの例を使います。 Dockerとは何か Dockerとは要するに、（仮想マシン用のテンプレートに非常によく似ている） イメージ を作成して、 コンテナ でイメージのインスタンスを実行できるソフトウェアです。 Dockerには、 Docker Hub と呼ばれる大量のイメージのリポジトリがあり、これを利用して作業を始めたり、無

1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い

以下に紹介するのは、 Docker を使って node.js 用のWebアプリケーションを開発、およびデプロイする際に、私が四苦八苦しながら学んだ秘訣やコツです。 このチュートリアル記事では、Dockerで socket.ioのチャットサンプル を白紙の状態から本番状態へとセットアップしていきます。このプロセスを通じて、そうした秘訣などを簡単に習得していただければ幸いです。特に、以下のような内容について見ていきます。 実際にDockerでNodeアプリケーションを起動する。 すべてをrootとして実行させない（悪いやり方です）。 開発時のテスト-編集-リロードサイクルを短くするため、バインドを使用する。 再構築を高速にするため、 node_modules をコンテナで管理する（これには秘訣があります）。 npm shrinkwrap で、ビルドを反復可能にする。 開発環境と本番環境で Do

(編注：2016/5/31、頂いたフィードバックを元に記事を修正いたしました。) larry wall 怠慢と勤勉 コンピューティングにおいて、”laziness(怠惰)”は幅広い意味の単語です。大抵は、もし必要が無ければ何もしないということを意味します。その正反対を指すのは”eager(勤勉)”です。後で必要になる場合に備えて、できるだけ働くということを意味します。 以下のJavaScriptを見てみましょう。 function ifThen (a, b) { if (a) return b; } ifThen(1 === 0, 2 + 3) //=> undefined ここで、問題です。「JavaScriptは 2+3 を評価する？」答えはお分かりですね。「評価する」です。呼び出し関数に、引数を引き渡すこととなると、JavaScriptは eager(勤勉＝先行評価) で、式の全てを

多くのGoogle社員と同様、私は起業したくてたまりませんでした。Googleで働くのは名誉なことで、大きなメリットがありましたが、”これ”という決定的な何かが欠けていたのです。 私たちの多くは”あの偉業”を成し遂げた”あの人物”と呼ばれたいと思っていますが、既に定評のあるテクノロジ大企業で、そういった人物になるのは不可能です。 その原動力がどこから来るのかは誰にも分かりませんが、私は多くの人々が自分と同じ気持ちを抱いていることを知っています。私はその欲求を満たすために、会社を設立せざるを得なかったのです。 スタートアップでは資産のほとんどは経営陣が持っていて従業員は持ち分が少なすぎると書かれた文章を読んで、がくぜんとしました。それで自分の会社を設立する決心をしたのです。まず、共同創業者と私は、2012年2月頃に仕事を辞めました。私たちには大した計画はありませんでした。取り組もうとしている

私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ

Atom は、今注目の最新テキストエディタです。私は、このエディタをソフトウェア開発に使用しているのですが、オープンソースになっているので、少しでも貢献できればとAtomが抱えるIssuesについて検証してみることにしました。私は、 ある奇妙なバグ を見つけました。それは、Atomのユーザ speter がテキストを1行書き、行末で Enter を押した時に起こりました。新たな行が書けるようになるまで、Atomは30分も計算していたのです。私は、そんな単純かつよくあるオペレーションもろくにできないことに大きな衝撃を受け、早速その原因を探ることにしました。 検索 これが、問題のテキストです。 vVar.Type().Name() == "" && vVar.Kind() == reflect.Ptr && vVar.Type().Elem().Name() == "" && vVar.Typ

ここ数年、私はWeb開発と機械学習の自習に多くの時間を割いてきました。 学習のテーマは、Javascript、Node、ReactからPython、scikit-learn、ニューラルネットワークに至るまで多岐にわたりましたが、全てに対して私は一貫したアプローチで取り組みました。 そのアプローチとは、単純な（陳腐と言ってもいい）3ステップで進める、という手法です。しかし、 Web開発のシロウトだった私が5カ月で、プロだと自覚できるほどになった のはひとえに、このアプローチで臨んだ自習の成果だと思っています。 そこで私は、この自習法がほかの誰かのお役に立てるかもしれないと思い、少し記事を書いてみることにしました。 この記事は、何も分からないままやみくもに挑戦を始めた、2012年当時の自分自身に教えるつもりで書いています。 ステップ1：習うより慣れろ 新しいテクノロジを学ぶためにまず実行する最