Goはオブジェクト指向言語だろうか？ | POSTD
“オブジェクト指向”の意味を本当に理解するには、この概念の始まりを振り返ることが必要です。最初のオブジェクト指向言語はSimulaという言語で、1960年代に登場しました。オブジェクト、クラス、継承とサブクラス、仮想メソッド、コルーチンやその他多くの概念を導入した言語です。おそらく最も重要なのは、データとロジックが完全に独立したものであるとする、当時では全く新しい考え方をもたらしたことでしょう。 Simula自体には馴染みがない方も多いかもしれませんが、Simulaからインスピレーションを得たとされるJavaやC++、C#、Smalltalkといった言語は皆さんよくご存知でしょう。さらにそこからインスピレーションを得たものとしてObjective-CやPython、Ruby、JavaScript、Scala、PHP、Perlなど様々な言語があり、Simulaは現在使用されているポピュラーな
Capybaraを使って、Rails+JavaScriptの非同期な統合テストを書く | POSTD
上からも分かるように、ページの読み込みが完了する前に、テストでリンク探しを始めたのにも関わらず、Capybaraは優雅にインタラクションを処理しています。 しかし、Capybaraがこれらの非同期の問題を処理してくれるにもかかわらず、成功したり失敗したりする一貫性のないテストにいとも簡単に陥ってしまうのはなぜなのでしょう。 競合状態の数を最小限に抑えて、Capybara APIを正しく使用するには、いくつかのコツがあります。 最初に適合するエレメントを見つける 悪い例 first(".active").click まだページに.active要素がない場合、firstはnilを返し、クリックは失敗します。 良い例 # 完全に一致するものが欲しい場合 find(".active").click # ただ単に最初の要素がほしいだけの場合 find(".active", match: :first
GraphQLはWeb APIの次のフロンティアか？ | POSTD
RESTの規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
人間らしいGitのエイリアス | POSTD
断固としてコンピュータ言語を拒絶する 私の知っている最も一般的な .gitconfig は、ユーザ名の設定だけが記されたものです。そして、その次に一般的なものはこれです。 [alias] ci = commit cia = commit -a cam = commit --amend cama = commit --amend -a cl = clean cldf = clean -df res = reset resa = reset HEAD ... # 82 more 4-character aliases このコンフィグは、要するにあなたの頭の中のスペースをキーストロークに置き換えます。短縮コマンドのエイリアスを覚えれば、タイピング数の節約が可能です。しかし私はこれが好きではありません。私はタイプミスをしますし、睡眠不足なこともたまにあるので、このエイリアスではやりづらくなってしま
ソフトウェアのスケーラビリティについてスターバックスが教えてくれること | POSTD
2004年に Gregor Hohphe が「 スターバックスでは2相コミットを使わない（Starbucks Does Not Use Two-Phase Commit） 」という優れた投稿を発表しました。それを読んでいたら、学生時代にスターバックスでアルバイトをした頃がいきなり関わってきました。何年もの間に次第に分かってきたのは、プログラマでさえ有名なコーヒーショップのチェーンから学べることが思った以上にあるということです。 多くの人はスケーラビリティのあるソフトウェアを作ろうしますが、最初に考えていたよりも非常に難しいことがあります。個々のタスクをこなしているうちに「あらゆるものの重要性は等しく、同じリソースを必要とし、決まった順序で同期的に進行する」と考えてしまう罠に陥ってしまうのです。 実際には、少なくともスケーラビリティのあるシステムでは、当てはまりません。もちろんスターバックス
コーディングを学ぶこと、それはあなたが考えるよりも大変です | POSTD
要約：全ての根拠が示しているのは、「プログラミングには高い適性を要求されますが、適性を持った人間はわずかしかいない」ということです。最近の流行の短期でコーディングを学べるコースは、デマカセを売り付け、プロのプログラマのスキル不足解消に何ら力になってないのです。 これはイギリスからの観点での記事です。私はこの事象について、とりわけソフトウェア開発者の社会的地位に関しては、他の地域決してこの通りではないと思っています。 メディアが共通して取り上げるテーマは、スキルのあるプログラマの不足です（”プログラマ”も”コーダ”も”ソフトウェア開発者”も、ここでは全て同じものを意図し、区別せずに使用しています）。このコーディング技術のギャップには解決の糸口が見えない心配が多くあります。要は”明日の高品質な仕事”を担う候補者を生み出すことに失敗しているということです。例えば、 The Telegraph の
Gitを学んでいて「なるほど！」となる瞬間 | POSTD
Gitは速く柔軟性がありますが、理解に時間のかかる分散型バージョン管理システムです。Gitを始める前に次を理解しておきましょう。 通常のバージョン管理 分散型バージョン管理 本 や 学習書 、 指南書 はGitを理解するのに役に立ちました。しかし、その他にもGitの理解に至ったきっかけがありますのでご紹介します。 ステージング・エリアがある Gitにはステージング・エリアがあります。繰り返しますが、 ステージング・エリアがあるのです 。 これには混乱しました。リポジトリ（「オブジェクトデータベース」）とステージング・エリア（「インデックス」と呼ばれる）の両方がGitにはあります。チェックインには2段階あります。 git add foo.txt インデックスにfoo.txtを追加します。これだけでは、チェックインは完了していません。 git commit -m "message" リポジトリ
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
アジャイルの破綻―原因、そして新たな提案 | POSTD
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
テスト駆動開発（TDD）はもう終わっているのか？ Part 2 | POSTD
前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
眼鏡なしのコードレビュー | POSTD
例えば、あなたが驚くほど聡明な開発チームのメンバーで、コードレビューのみに一日の時間を確保しているとします。しかし作業を開始して2時間後、眼鏡を忘れてきてしまい、午前中はぼんやりとしたカラフルな表示を見つめていただけだったということに気づいたとします。さて、あなたはどうしますか? 家まで歩いて10分もかからないし、天気も良ければ、眼鏡を取りに帰るのが一番です。でも朝家を出るとき、攻撃的なスズメバチの群れが眼鏡の置いてある部屋に巣を作って、邪魔されたくない様子だったらどうしますか？ そういう時はもちろん、コンタクトレンズを付けてきたふりをして、恥ずかしい思いをしないようにするのがよいでしょう。実際に読むことなく膨大な量のファイルを見分けることができるということを覚えておいて下さい。 参考コード 1 不安の種は隔離するべきだということに誰も異論はないでしょう。そしてもちろん、あらゆるクラスは一
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
