タグ

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

  • 6年間におけるGoのベストプラクティス | POSTD

    稿は、QCon London 2016で行った講演の内容に基づいています。スライドとビデオは近日中に掲載予定です) 2014年に開催された最初のGopherConで、私は「 Best Practices in Production Environments(番環境でのベストプラクティス) 」と題した講演を行いました。 SoundCloud の私たちはGoのアーリーアダプターで、その時点までに既に2年近く、番環境向けの様々なGoコードを書き、実行し、メンテナンスしていました。そして私たちはいくつかのことを学んだので、その教訓をまとめ、多くの人に伝えたいと思ったのです。 それ以来、私はフルタイムでGoを使う仕事を続けています。SoundCloudではその後の活動やインフラチームで、そして現在は Weaveworks で Weave Scope や Weave Mesh の開発に使ってい

    6年間におけるGoのベストプラクティス | POSTD
    ismage
    ismage 2018/08/27
  • なぜGo言語は設計が悪いのか – Go愛好者の見地から | POSTD

    さて、このタイトル、かなり挑発的ですよね。それは認めます。もう少し説明すると、私は大胆なタイトルが好きなのです。人の注意を引くことができますからね。とにかく、この記事では、Goがひどい設計の言語(実際、当に全て台無しになります)だということを証明していこうと思います。私は既に数カ月間Goで遊んでいますし、たしか6月のいつだったかに初めてHello, Worldを走らせてもみました。私は数学がそんなに得意ではありませんが、あれから既に4カ月経っていますし、 Github 上のパッケージもいくつか手に入れました。言うまでもありませんが、私は仕事Goを使ったことは全くないので、”コードサポート”や”デプロイ”やそのあたりに関する私の意見は話半分で読んでくださいね。 私はGoが大好きです。使ってみて大好きになりました。慣用表現を理解したり、ジェネリクスがないことや、おかしなエラーハンドリングや

    なぜGo言語は設計が悪いのか – Go愛好者の見地から | POSTD
    ismage
    ismage 2017/11/14
  • JOSE(JavaScriptオブジェクトへの署名と暗号化)は、絶対に避けるべき悪い標準規格である | POSTD

    注: 稿は元はJSON Web Tokens(JWT)について書いたものですが、JWTはJavascript Object Signing and Encryption(JOSE)のサブセットであるため、以下の批評はどちらかというとJOSE全体に焦点を当てています。 もし既にJavascript Object Signing and Encryption(JOSE)を実装することを決めているなら、それがJSON Web Tokens、JSON Web Encryption(JWE)、JSON Web Signatures(JWS)のいずれであっても、その決断に疑問を持つべきです。間違いを犯そうとしている可能性があります。 この投稿に書いたことはすべて、RFC 7519、RFC 7515、そしてRFC 7516に則っています。将来、新規のRFCでは以下に挙げるような欠陥はなくなっている可能

    JOSE(JavaScriptオブジェクトへの署名と暗号化)は、絶対に避けるべき悪い標準規格である | POSTD
    ismage
    ismage 2017/10/10
  • なぜUber EngineeringはPostgresからMySQLに切り替えたのか | POSTD

    はじめに Uberの初期のアーキテクチャは、Pythonで書かれたモノリシックなバックエンドアプリで構成されており、データの永続性のために Postgres を使っていました。当時から比べて今のUberのアーキテクチャはかなり変わっており、 マイクロサービス のモデルや新しいデータプラットフォームになりました。特に、以前Postgresを使っていたケースの多くで、今は Schemaless 、つまりMySQLの上で構築された新しいデータベースのシャーディングレイヤを使います。今回の投稿では、私たちが見つけたPostgresの欠点を探り、MySQLの上でSchemalessと他のバックエンドサービスを構築するに至った経緯について説明していきます。 Postgresのアーキテクチャ 私たちはPostgresで以下のような多くの制約に直面しました。 書き込みでの非能率的なアーキテクチャ 非能率的

    なぜUber EngineeringはPostgresからMySQLに切り替えたのか | POSTD
    ismage
    ismage 2017/08/21
  • ビヘイビア駆動開発 ― ウォーターフォールモデルからのステップ | POSTD

    ビヘイビア駆動開発(BDD:Behavior-Driven Development、振る舞い駆動開発ともいう)を実務に沿って簡単に紹介し、ソフトウェア開発プロセスに対してこの手法がどれほど有益かを説明します。 はじめに BDDで重視しているのは、フィードバックループを最小限に短縮することです。BDDはソフトウェア開発手法の進化の中で、理論的に一歩前進したものといえます。稿ではBDDの概念と、その原型のモデルを説明します。 ソフトウェア開発者や、エンジニア部門のマネージャー職に就いている人ならば恐らく、以下の図のようなウォーターフォールモデルはよくご存じでしょう。 注釈: Waterfall model:ウォーターフォールモデル System Requirements:システム要件定義 Software Requirements:ソフトウェア要件定義 Analysis:要求分析 Progr

    ビヘイビア駆動開発 ― ウォーターフォールモデルからのステップ | POSTD
    ismage
    ismage 2017/03/24
  • Railsアプリを66%スピードアップ ― Railsキャッシュの完全ガイド | POSTD

    (訳注:2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕を一緒にするけれど、当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50~100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング(これは全く別の難物で、あなたのアプリケーションに実装する必要はありません)は、別の機会で扱いましょう。 するべきキャッシングをしない理由

    Railsアプリを66%スピードアップ ― Railsキャッシュの完全ガイド | POSTD
    ismage
    ismage 2016/09/28
  • Gitのコミットメッセージの書き方 | POSTD

    (訳注:2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注:2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳: プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション:なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest

    Gitのコミットメッセージの書き方 | POSTD
    ismage
    ismage 2016/03/27
    ポケットへ入れた Gitのコミットメッセージの書き方
  • WebSocketには注意が必要 | POSTD

    近い将来WebSocketがRailsで使用できるようになると聞くと、デベロッパはみんな舞い上がって興奮します。 しかし、 あなたのユーザは、あなたがWebSocketを使用しているかどうかなんて気にしません 。 ユーザは、”快適なリアルタイムWebアプリ”を求めている。 デベロッパは、”快適でビルドが簡単なリアルタイムWebアプリ”を求めている。 オペレーションは、”デプロイ、スケール、管理が簡単なリアルタイムWebアプリ”を求めている。 上記全ての要望をWebSocketがかなえてくれるのなら素晴らしいことですが、この実装の詳細は高いコストがかかります。 超高性能で全二重なクライアントとサーバ間の通信は、当に私たちに必要なのか? WebSocketは、クライアントに情報を配信するための簡単なAPIと、クライアントからWebサーバへ情報を送信するための簡単なAPIを提供します。 サーバ

    WebSocketには注意が必要 | POSTD
    ismage
    ismage 2016/02/02
  • JavaScriptのデバッグのコツと技 | POSTD

    以前の記事で、 Webアプリケーションのデバッグの仕組み について触れました。今回は実践的なJavaScriptのデバッグについて掘り下げていきたいと思います。 ブラウザデベロッパツール 私の個人的なお気に入りはChromeデベロッパツールです。SafariやFirefoxはChromeほどの高水準に達していません。しかし、徐々に改善されてきています。FirefoxにはFirebugと改良されたFirefoxデベロッパツールが組み合わされた機能が備わっています。もし、Firefoxチームがビルトインされているデベロッパツールの改良の中で素晴らしい仕事をし続けたとしたら、Firebugはいつか、すたれるかもしれません。 個人的な好みにかかわらず、ターゲットとするあらゆるブラウザで、全てのコードのテストやデバッグができるようにすべきです。”あらゆるブラウザ”には、かの有名なInternet E

    JavaScriptのデバッグのコツと技 | POSTD
    ismage
    ismage 2015/09/05
  • 優秀なJavaScriptの開発者になるための5か条 | POSTD

    (注記:7/15、いただいた翻訳フィードバックを元に記事を修正いたしました。) 子供の頃、私の興味は互いに関係性のない様々な分野に及んでいました。数学歴史も大好きでした。 ルネッサンスマン 、つまり 博学者 と言う、複数の分野に秀でた人になりたいと思っていました。これはとても難しい課題で、私は突如として、器用貧乏な人になってしまう危機に直面したのです。 私は特定の分野に特化しなくては、と考え始めました。そうすればたとえルネッサンスマンにはなれなくても、少なくとも、器用貧乏にならなくても済むと思ったのです。どうしたらソフトウェア開発をするのに必要な広い知識を保ちながら、1つの分野で専門性を高めることができるのでしょうか。 この記事では、過去5年間、私が良いJavaScript開発者になるために使ったテクニックとリソースの概要をお伝えしようと思います。 最近の多くのWeb開発者は、ある共通の

    優秀なJavaScriptの開発者になるための5か条 | POSTD
    ismage
    ismage 2015/07/14
  • コードレビューのベストプラクティス | POSTD

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

    コードレビューのベストプラクティス | POSTD
    ismage
    ismage 2015/06/12
  • ソフトウェア開発で得た教訓22箇条 | POSTD

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

    ソフトウェア開発で得た教訓22箇条 | POSTD
    ismage
    ismage 2015/06/03
  • GitLab flowから学ぶワークフローの実践 | POSTD

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

    GitLab flowから学ぶワークフローの実践 | POSTD
    ismage
    ismage 2014/10/23
  • Rubyにはウンザリ!動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD

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

    Rubyにはウンザリ!動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
    ismage
    ismage 2014/08/29
  • 1