タグ

ブックマーク / postd.cc (10)

  • HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD

    HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200

    HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
  • コマンドラインでPostgreSQLを操作する – psqlで効率を上げる | POSTD

    私は、もう4年も毎日のようにPostgreSQLを使用しています。以前はデータベースとやりとりするためにGUIアプリケーションを用いていました。しかし今では、お気に入りのツールを使いながら効率よく作業できる、ビルトインのコマンドラインツールだけを使用しています。 稿は、 psql というコマンドラインツールを通して実現可能なタスクを複数のセクションに分けて説明します。ここで挙げる項目は次のとおりです。 psqlの設定 ヘルプの使用 データベースが遊び場 データベースの探索 クエリの作成 出力の比較 データベースのクローン作成 データの抽出 psqlの設定 あらかじめpsqlはある程度設定されています。そのため、稿では提供されているオプションを詳しく説明しません。psqlの使用がより楽しくなる2つのオプションについてのみ説明します。 1つ目は、データが横長でも正しくスクリーンに映し出され

    コマンドラインでPostgreSQLを操作する – psqlで効率を上げる | POSTD
  • R vs Python:データ解析を比較 | POSTD

    主観的な観点からPythonとRの比較した記事は山ほどあります。それらに私たちの意見を追加する形でこの記事を書きますが、今回はこの2つの言語をより客観的な目線で見ていきたいと思います。PythonとRを比較をしていき、同じ結果を引き出すためにはそれぞれどんなコードが必要なのかを提示していきます。こうすることで、推測ではなく、それぞれの言語の強みと弱みの両者をしっかりと理解できます。 Dataquest では、PythonとRの両方の言語のレッスンを行っていますが、データサイエンスのツールキットの中では両者ともそれぞれに適所があります。 この記事では、NBA選手の2013/2014年シーズンの活躍を分析したデータセットを解析していきます。ファイルは ここ からダウンロードしてください。解析はまずPythonとRのコードを示してから、その後に2つの異なるアプローチを解説し議論していきます。つま

    R vs Python:データ解析を比較 | POSTD
  • リレーショナルデータベースの仕組み (1/3) | POSTD

    リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術(ビッグデータ、NoSQLJavaScriptなど)を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか? 私は開発者として、理解していないものを

    リレーショナルデータベースの仕組み (1/3) | POSTD
  • コードの品質を維持したまま開発スピードを上げる | POSTD

    高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる

    コードの品質を維持したまま開発スピードを上げる | POSTD
  • コードレビューのベストプラクティス | POSTD

    Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上

    コードレビューのベストプラクティス | POSTD
  • Rubyにはウンザリ!動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD

    この記事を書き上げるには、相当長い時間がかかりました。来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって? それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発(TDD)の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい

    Rubyにはウンザリ!動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
  • サーバの適切な名前の付け方 | POSTD

    現在、 MNX ではクラウドホスティングサービスの新しいデータセンタを立ち上げているところで、とてもバタバタしています。クラウドホスティングサービスは、今の私たちの主な業務ですが、この会社が始まった当初は、Linux管理のコンサルティングサービスを中心としていました。そのサービスを通じて、たくさんの顧客環境を目の当たりにしましたし、それと同じ数だけの、顧客ごとに異なるデバイス名の指定方法も見てきました。そしてもちろん、その全ての指定方法をいいなと思ったわけではありません。名前の付け方は、コンピュータ草創期からの問題ですよね。おのおのがホスト名の指定方法について一家言持っていました。でも、それらの方法は最初のうちはうまくいっても、時を経てシステムインフラが拡大し、状況に応じて変更を余儀なくされるようになると、すぐに扱いにくくなってしまうものがほとんどでした。 そこで今回は、先述した私たちのデ

    サーバの適切な名前の付け方 | POSTD
  • 科学者が書いた質の低いコードが、ベストプラクティスに則ったコードに勝る理由 | POSTD

    今ちょうど、 科学者の手によるコードは質が低い という投稿を読み終えたところです。科学者の書いたコードは”ソフトウェア・エンジニア”が関与したコードと比べて質が劣るという内容でした。 私は10年以上同じ職場に勤めていますが、同僚の多くは数学や物理学が専門で、”ソフトウェア・エンジニアリング”の知識はほとんど持っていません。 そこでは、大惨事は必ずと言っていいほど、自分のことをいっぱしのプログラマだと思っている少数派によって引き起こされます。かくいう私も、少なくとも数件、いまだ解決を見ていない大きな不具合の原因を作ったことがあります。他にも大きめのバグをいくつか出しましたが、幸いその時のコードはお蔵入りしたため、私に無駄な給料を払わされた雇い主が被害をうけたくらいで、同僚の生産性を大きく損なうことはありませんでした。 その度(少なくともほとんどの場合)私は反省し、それまでにも増して退屈なくら

    科学者が書いた質の低いコードが、ベストプラクティスに則ったコードに勝る理由 | POSTD
  • 機械学習アルゴリズムへの招待 | POSTD

    機械学習の問題 については以前に紹介したので、次はどんなデータを収集し、どんな機械学習アルゴリズムを使うことができるのかを見ていきましょう。投稿では、現在よく使用されている代表的なアルゴリズムを紹介します。代表的なアルゴリズムを知ることで、どんな技法が使えるかという全体的なイメージもきっとつかめてくるはずですよ。 アルゴリズムには多くの種類があります。難しいのは、技法にも分類があり拡張性があるため、規範的なアルゴリズムを構成するものが何なのか判別するのが難しいということですね。ここでは、実際の現場でも目にする機会の多いアルゴリズムを例にとって、それらを検討して分類する2つの方法をご紹介したいと思います。 まず1つ目は、学習のスタイルによってアルゴリズムを分ける方法。そして2つ目は、形態や機能の類似性によって(例えば似た動物をまとめるように)分ける方法です。どちらのアプローチも非常に実用的

    機械学習アルゴリズムへの招待 | POSTD
  • 1