現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR

今日は、開発者が見積もりを作成している時に脳内でどんなことが起きているのか話してみたいと思います。なぜこんなにも見積もり作業が難しいのか、そして、私の見積もり精度は相変わらずひどいものですが、私がどうやって（非常に幸せな事業主の方々に向けて）ソフトウェアを書いて生計を立てる術を編み出してきたのかについてお話ししたいと思います。 まずは昔話をひとつ。 あれは\<私がものすごく年寄りには見えない程度の年代をここに挿入>頃でした、私は年若き開発者でした ^(1) 。大学のコーディング演習では優秀な成績を修め、若手開発者として誰がどんな問題を提示してきても解決し、想像を絶する速さでどしどしコードを量産していました。新しい言語は週末の間に習得し、書けるようになっていました（少なくともそう信じていました）。 それで自然な流れとして自分でプロジェクトを取り仕切ることになりました。アカウント・マネージャが

私はこのところしばらく仕事でVMやコンテナを扱っていましたが、大学のいくつかのプロジェクトでJavaのコードを書かなければならないときは未だにvimを使用せず、新たに本格的なIDEをインストールしなければなりませんでした。これにはいつもイライラさせられていましたが、ついに今週、Dockerコンテナ内でNetBeansを実行できるようになったのです。それによって普段使用しないJavaのコードを書くための膨大な環境をパソコンにインストールしなくて済むようになりました。 Dockerコンテナ内でGUIアプリケーションを実行する場合には、いくつかの方法があり、 X11転送を行うSSH や VNC を使用します。しかし私が発見した最もシンプルな方法は、X11のソケットをコンテナと共有して、直接使用するというものでした。 このアイデアはとてもシンプルで、以下の Dockerfile を開始点として使用

私は 以前の投稿 で、Angularなどのフレームワークがあまり好きではない旨を述べました。宣言的なHTMLのタグや属性、{{二重波括弧}}のプログラミングを開発するということには、 どうも抜け落ちている部分がある ようです。そして、どのフレームワークも独自のやり方で開発されているため、それを理解しサポートするためには、ツールのアップデートに多大な労力を 浪費する 注ぐ 必要があります。 さらに、そんな先入観を抜きにして考えてみても、Angularの今後に関して最近入ってきた情報は、私がますます頭を抱えてしまうような内容だったのです…… ツールに新たに追加される概念は、1つではなく3つ！ Angularをサポートするためにはツールのアップデートが必要ですが、今は下記を考慮していく必要があるようです。 Angular v1の構文 Angular v2の構文（従来と 大きく異なる ようです）

Pro Git第2版の驚くべき冒険と最終的なツールチェーン ほぼ6年前、私はApressから執筆が予定より遅れていたPro Gitと呼ばれる本の手伝いの誘いを受けました。結局原著者が書き続けないことを決めて、私が最初から書き直して2009年8月頃に最終的に出版されました。最初の3章あたりは、私はWordで本を書きました。そして編集者に文書を送って、しばらくして最終的な版を手にしました。 この3章のあとで、私たちが執筆と技術的な編集段階のためにMarkdownに切り替えて、同意された編集のためにだけWordへ戻るように提案したとき、私はやめようとしていました。一旦本が完成したら、私はすべての内容をMarkdownへ再び戻したので、それを私が作成したWebサイトにおいてオンラインで発表できました。幸運にも、原著者は著作をクリエイティブ・コモンズ・ライセンスとすることでApressと同意しました

Dockerレジストリ は、今やあふれんばかりの状況です。これを書いている時点で、”node”と検索すれば、1000件弱の結果がヒットします。どうやって選べばいいのでしょうか？ いいDockerイメージを構成するもの いい悪いは主観ではありますが、私がいいと考えるDockerイメージには、いくつかの基準があります。 実用的： 以下に例を挙げます。 最初にコンテナにアップデートを適用しなくても、Android SDKのイメージがプロジェクトをコンパイルできる。 MySQLのコンテナが、データベースとユーザを使用してサーバをブートする方法を明示する。 最小限： コンテナの利点は、アプリケーションをサンドボックスできること（セキュリティがない場合には、ホストファイルシステム上で混乱を避けられること）です。ホストシステムにnode.jsをインストールしたり、JDK（Java開発キット）でシステムを

以前、 OpenVz コンテナだった私の” ホームクラウド “と、 私があらゆるビルドに関して”ビルドサーバ”のリビルドを推奨するようになったワケ について書きました。 Docker はあっという間に私のお気に入りのツールに仲間入りしました。限りなく静的なサーバ環境を作り出す繰り返し可能なビルドを作成するという考え方が気に入ったからです。 今回は、私がDockerを使用する中で繰り返し現れるようになったいくつかのパターンを説明します。どれも特段に目新しいものでも非常に驚くようなことでもありませんが、皆さんにとってそれが役立つものであり、また皆さんがDockerを使用する中で遭遇するパターンについても聞くことができれば幸いです。 私がDockerを使って色々なことを試す根本にあるのは、データを喪失することなくDockerコンテナそのものが自由に再作成できるよう、ボリュームにあり続ける状態を維

この記事の目的は、機械学習ソリューションを大規模に展開するための実用的なガイドを提供することです。全てのものが正しいと立証されたわけでもありませんし、また最適であるとも限りません。私たちが実際に展開した際には、いくつかのトレードオフもありました。アカデミックな環境であれば必要とされるであろうあらゆる論拠の積み上げを必ずしも行うことなく、随時簡便な方法で済ませたところもあり、それについてはおわびします。そのような箇所は投稿を通じて明確に示しながらも、この記事が皆さんの役に立つことを願っています。 少し背景から説明します。TOTEMS AnalyticsはInstagramの（ハッシュタグと関連のあるオーディエンスやコミュニティの）解析を行います。この1年で、Instagramのオーディエンスに関する統計情報への需要はかつてないほどクライアントから寄せられています。そこで私たちは6カ月前、プラ

数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト

パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な（そして驚くほど活用されていない）アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l

これからご紹介する私の試みはなかなか難しい側面があり、物議をかもすかもしれません。また、お見せするのは初めてなので完璧とは言えないかもしれません。私はソフトウェアエンジニアのスキルとその影響力を評価するシステムを開発しようとしています。少なくとも、プログラマが成長していく理想的な成長過程を大まかに描いてみようと思います。評価スコアは0.0から3.0まであり、それぞれの数字は専門能力を開発していく際の出発点を表しています。 このシステムは主にビジネスの観点から見た、ソフトウェア業界が求めるものに基づく 実務的な スケールです。数学的な才能や高速アルゴリズムを書く能力、Linuxカーネルの内部構造に関するプログラマの理解の深さなどを評価するスケールではありません。もちろんこうした能力は重要ですし、通常、エンジニアのスキルとともに伸びていく能力ですが、私のシステムが焦点を当てたいのはそこではあり

長文ですが、よかったら読んでください。 就職面接でプログラムの解読を求められました。そして、就職が決まりました。 皆さん、こんにちは。新しいブログを開設したので、私は今とても張り切っています。週に何度か記事を投稿するつもりです。 タイトルを見れば大体の話の内容は分かると思いますが、これから書くのは、トルコのアンカラで受けた就職面接の話です。 私が応募した職は「ソフトウェアセキュリティエンジニア」でした。面接中、面接官たちは非常に専門性が低い質問をしてきましたが、分かることもあれば分からないこともありました。 その後、その企業からメールが届き、保護および暗号化されたバイナリファイルが添付されていました（「解読してみろ」ということでしょう）。 帰宅後にファイルをダウンロードすると、ファイルを開くために聞かれたのはパスワードだけでした。面接官が私に課した課題は、そのパスワードを探すことでした。

一部誤訳の指摘があったため、修正しました！ご迷惑おかけして申し訳ございません！ あなたは自分でCSVを書いてみたいですか？　フィールドはコンマで区切り、行は改行で分けます。簡単ですよね。数行書けば勝手が分かるというものです。 でも、ちょっと待ってください。 フィールド内にコンマがある場合は？ ダブルクォート（”）で、該当のフィールドを囲みましょう。簡単ですね。 では、ダブルクォートで囲めるフィールドに例外はあるのでしょうか？ フィールド内にダブルクォートがある場合は？ フィールド内の各ダブルクォートに対して、ダブルクォートを二重化して適用しましょう。そうすれば元のダブルクォートをエスケープすることができます。 なお、二重化したダブルクォートと空フィールドを囲んでいるダブルクォート（ ...,"",... ）を勘違いしないように気を付けてください。 フィールド内に改行がある場合は？ その場合

ほとんどの開発者は、自動のガベージコレクション（GC）を当たり前のように使っています。これは、私たちの仕事を容易にするために言語ランタイムが提供する素晴らしい機能の1つです。 しかし、最新のガベージコレクタの中をのぞいてみれば、実際の仕組みは非常に理解しづらいことが分かります。実装の詳細が無数にあるため、それが何をしようとしているのか、また、それがとんでもなく間違った事態を引き起こしかねないことについて十分理解していない限り、すっかり混乱してしまうでしょう。 そこで、5種類のガベージコレクションアルゴリズムを持つおもちゃを作ってみました。小さいアニメーションはランタイムの動作から作成しました。もっと大きいアニメーションとそれを作成するコードは github.com/kenfox/gc-viz で見ることができます。単純なアニメーションによってこうした重要なアルゴリズムを明らかにできることは

白状しますが、私にはひどいダッシュボードを構築してきた責任があります。個人的に、この記事に書いた間違いのほとんどを犯してしまいました。ユーザに謝罪するとともに、同じ過ちを繰り返さないことを誓います。これらの過ちが悪い見本として、プロジェクトマネージャやデザイナ、エンジニアがひどいダッシュボードを構築したり確認したりする無駄な時間を少し減らすのに役立つことを願います。 法則1：ほとんどのソフトウェアのダッシュボードはひどい ひどいと言うのは このGoogle画像検索 のようなひどさ（まだ吐いていませんよね？）のことではありません。退屈で、設計が不十分で、有用性も一切ないという意味です。 信じられませんか？　では、今すぐ優れたダッシュボードのソフトウェア名を3つ挙げてみてください。 見つかりましたか？　ええ、そうだと思いました。しかし、ダッシュボードはどこにでもあります。あなたが使っているSa

Gitによるバージョン管理では、従来のSVNなどよりずっと簡単にブランチングやマージができます。さまざまなブランチ戦略やワークフローが可能であり、以前のシステムに比べるとほとんど全てが改善されたと言えるでしょう。しかしGitを利用する多くの組織はワークフローの問題に直面します。明確な定義がなく複雑で、Issue Tracking Systemと統合されていないからです。そこで、明確に定義された最良の実践的方法としてのGitLab flowを提案したいと思います。issue trackingには feature driven development と feature branches を組み合わせます。 他のバージョン管理システムからGitに移行する際によく耳にすることは、効果的なワークフローの開発が難しいということです。この記事ではGitワークフローとIssue Tracking Sys

あなたは技術者採用の面接が苦手ですね。そう、あなたですよ。間違ったスキルを探し求め、適正の無い人たちを採用して、自分自身と会社に悪い影響を与えているのです。応募者リストを見直さなくとも、今までとは違う人材を採用し、会社の業績を上げ、あなた自身も仕事をもっと楽しめるようになりますよ。 いささか大胆な物言いだということは承知しています。仕事での経験を積み面接を担当するようになってから10年、大小の企業の様々な部署で、技術者を雇うための数多くの面接をしてきました。採用する人材が会社に及ぼす影響についても見てきました。完璧な採用を目指せというつもりはありません。私自身がこれまで何度もしてきたあらゆる失敗をあなたが犯さなくても済むよう、お伝えしたいのです。私がこれまで学んできたことは次のようなことです。 誤った判断基準 1. 応募者の現時点の知識に基づいて採用しない 面接で犯しがちな最初の間違いは、

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

後編を公開しました（2014/10/8） これは、テスト駆動開発（TDD）とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2～3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の

私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり