タグ

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

  • スクラムで失敗する5大理由とその対策としてできること | POSTD

    スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外

    スクラムで失敗する5大理由とその対策としてできること | POSTD
  • 大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 後編 | POSTD

    メッセージの耐久性と持続性 分散型システムのノードは演算し、データを保存し、互いにメッセージを送信し合います。メッセージ送信の重要な指標は、これらのメッセージがどれだけ確実に届くかです。基幹システムでは、消失メッセージがゼロでなくてはならない場合がしばしばあります。 分散型システムにおける通信は、RabbitMQ、Kafkaなどの分散型メッセージングサービスを用いることがほとんどです。こういったメッセージングサービスはメッセージ配信において様々なレベルの信頼性をサポートしています(または、サポートするように設定を変えられます)。 メッセージの永続性とは、メッセージを処理しているノードで何らかの問題が起こった時、その問題の解決後に処理されるよう、メッセージはそこに残ることを意味します。メッセージの持続性は多くの場合、 メッセージキュー レベルで用いられます。持続性のあるメッセージキューを実装

    大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 後編 | POSTD
  • 大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編 | POSTD

    バックエンドに関する経験があった私は、2年前にモバイルソフトウェアエンジニアとしてUberに入社しました。担当することになった仕事は、決済機能の構築を含む アプリの刷新 です。その後、 技術管理の側に回る ことになり、チームそのものを率いることになります。配下のチームは、決済を行うバックエンドシステムの多くを担当していたため、責任者となった私もバックエンドに触れる機会が以前にも増して多くなりました。 Uberで働く前は、分散型システムの経験はなきに等しかったと言っていいと思います。 それまでの私は、一般的なコンピュータサイエンスの学位を取得後、フルスタックのソフトウェア開発に10年間、関わっていました。分散型システムについては、一応、大まかな仕組みやトレードオフなどは知っていましたが、一貫性や可用性、冪等性などの概念に精通していたとはお世辞にも言えません。 この記事では、大規模で可用性が高

    大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編 | POSTD
  • マイクロサービスはもう十分 | プロダクト・サービス | POSTD

    モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。要旨 モノリスとして管理するには複雑すぎるというシステムでない限り、マイクロサービスは検討さえしなくていい。ソフトウェアシステムの大多数は、単一のモノリシックアプリケーションとして構築されるべきである。そのモノリス内のモジュール性が良好になるよう注意を払う必要はあるが、別個のサービスに分けようとしてはいけない。 – Martin Fowler 明確に構造化されたモノリスを構築できない時、なぜマイクロサービスがその答えだと思うのか。 Simon Brown 始めに マイクロサービスの利点と欠

    マイクロサービスはもう十分 | プロダクト・サービス | POSTD
    golden_eggg
    golden_eggg 2017/07/05
    代替アーキテクチャが流行りだすとメリット(と思われる内容)に目が向きがちで、デメリットを検証するステップを飛ばして万能薬のように飛びついてしまう、アルアル。。
  • Go言語のリアルタイムGC 理論と実践 | POSTD

    (編注:誤訳、意味の分かりづらい訳を修正しました。リクエストありがとうございました。) 毎日、Pusherは数十億のメッセージをリアルタイム、つまり送り元から宛先まで100ms未満で送信しています。どのようにしてそれを可能にしているのでしょうか。重要となる要因はGoの低レイテンシのガベージコレクタです。 ガベージコレクタはプログラムを一時停止させるものであり、リアルタイムシステムの悩みの種です。そのため、新しいメッセージバスを設計する際には慎重に言語を選びました。Goは 低レイテンシを強調している ものの、私たちは懐疑的でした。「当にGoを使えば実現できるのか? もしできるならどうやって?」 このブログ記事ではGoのガベージコレクタを、どのように機能し(トリコロールアルゴリズム)、なぜ機能し(こんなに短いGCによる一時停止時間の実現)、そして何よりも、それが機能するのかどうか(GCによる

    Go言語のリアルタイムGC 理論と実践 | POSTD
  • 技術的負債の返済 – レガシーコードをリファクタリングで救うには | プログラミング | POSTD

    レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう?この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう?この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります! リスたちは毎年何千もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。

    技術的負債の返済 – レガシーコードをリファクタリングで救うには | プログラミング | POSTD
    golden_eggg
    golden_eggg 2017/01/02
    ゼロから書き直したものがうまくいくことは滅多にないって夢も希望も無い言葉に聞こえるけど割りと真理突いてるので、心の片隅でいいから置いておいた方が良いと思う
  • くだらないAPIなんていらないよ – 2016年のウェブスクレイピング事情 | POSTD

    ソーシャルメディアのAPIとそのレート制限は、あまり気分のよいものではありません。特にInstagram。あんな制限つきAPIを欲しがる人がいったいどこにいるんでしょうね? 最近のサイトは、スクレイピングやデータマイニングの試みを阻止するのがうまくなってきました。AngelListはPhantomJSすら検出してしまいます(今のところ、他のサイトでそこまでの例は見ていません)。でも、ブラウザ経由での正確なアクションを自動化できたとしたら、サイト側はそれをブロックできるでしょうか? 並行性を考えたり、さんざん苦労して用意した結果として得られるものを考えたりすると、Seleniumなんて最悪です。あれは、私たちが「スクレイピング」と聞いて思い浮かべるようなことをするためには作られていません。しかし、賢く作り込まれた今どきのサイトを相手にして、インターネットからデータを掘り当てるための信頼できる

    くだらないAPIなんていらないよ – 2016年のウェブスクレイピング事情 | POSTD
    golden_eggg
    golden_eggg 2016/12/06
    ニヤニヤしながら読んだw
  • GitHubのコード検索 : プログラマにとっての宝の山 | POSTD

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

    GitHubのコード検索 : プログラマにとっての宝の山 | POSTD
    golden_eggg
    golden_eggg 2016/09/29
    タイトルだけで同意だけど、学習途上の言語についてはgood/badをどう見極めるか難しい事もある
  • 「Erlangを使用して、効率的な決済システムを構築するには?」 | POSTD

    決済システムの構築は、ショパンのワルツを演奏するのに似ている。問題解決における万能的な方法がそこには含まれていて、どのような問題にも適用することができる。 先日、Erlangを学習しているという若いプログラマから、なかなか興味深いメールが送られてきました。その内容は、金融システムのサイトを構築するのにErlangは適切であるかどうかを知りたいというものでした。高度な並列処理を行うフォールトトレランスなアプリケーションの構築にはErlangが適した言語であるという記事を目にしたのと、私のを楽しんで読んだことで、彼はErlangに興味を持ったのだそうです。 彼の質問に対する私の回答は、「プログラムYにXは適切なのか?」というタイプの全ての質問に対する回答とほぼ同じです。同じ質問に何度も答えることを避けるために、その回答をここに記したいと思います。 問題を解決する際には、まず最も難しい問題から

    「Erlangを使用して、効率的な決済システムを構築するには?」 | POSTD
  • 私たちがAmazon Web ServicesからGoogle Cloud Platformに乗り換えた理由 | POSTD

    https://flic.kr/p/os8Taq 要約:AWSは素晴らしいが、Googleはその グーゴル 倍素晴らしい。 AWS re:Invent (参加料は1,600ドル)に参加したり、チーフ・エバンジェリストの Jeff Barr をフォローしたりすれば、あなたはたちまち、Amazon Web Servicesのとりこになるでしょう。 毎年何百もの新機能が登場しており、べ放題・融通が利く・運用担当者不要の、オンデマンドサービスのビュッフェのようです。まあ、実際にべてみるまでは、の話ですが…。 Amazonは素晴らしいです。しかし、Google Cloudは「開発者によって、開発者のために構築された」ものであり、それが一目で分かるのです。 移行した理由 App Engine GAE はきちんと機能し、オートスケーリング機能も持ち、ロードバランサや無料のmemcacheも備えていま

    私たちがAmazon Web ServicesからGoogle Cloud Platformに乗り換えた理由 | POSTD
  • Linuxシステムコール徹底ガイド | POSTD

    要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法(例あり)、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは? 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ(MSR) アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3

    Linuxシステムコール徹底ガイド | POSTD
  • 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
  • Gopherの道を歩む – Node.jsからGo言語への移行 | POSTD

    私は大学時代に、興味位でJavaScriptを始めて、それ以来ウェブページを幾つか作成してきました。JavaScriptは常にC言語やJavaの合間の楽しい息抜きでしたが、アニメーションや、ユーザをあっと言わせるようなちょっとしたことを提供するといった、特殊な目的にかなり限られた言語だと考えていました。JavaScriptは覚えやすく、開発者に具体的な結果をすぐにもたらしてくれるので、コーディングする方法を学びたいと思っている人に私が教えた最初の言語でした。JavaScriptHTMLCSSを少し組み合わせれば、ウェブページが出来上がります。プログラミング初心者には喜ばれます。 その後、あることが2年前に起こりました。当時、私は、主にサーバーサイドのコードとAndroid用のアプリのプロトタイプに取り組む研究職に近い立場にいました。すぐにNode.jsの存在が目に留まりました。バック

    Gopherの道を歩む – Node.jsからGo言語への移行 | POSTD
  • HTTPレスポンスのgzip圧縮による日時リーク : Torの秘匿ネットワークの秘匿性を脅かす仕様・実装について | POSTD

    よって、このヘッダがgzip圧縮データに付いていれば、適当なWebサーバにgzip圧縮リクエストを出し、gzip圧縮レスポンスを待って、バイト数が0x1f 0x8bで始まっているかどうかということと、正確な圧縮日を確認できるのです。 一般的なWebサーバでは、これは非常に限定的なシナリオにおいてのみ有用です。なぜなら、サーバの地理的な位置はいずれにしても隠されず、これもまた隠されていないサーバIPアドレスが分かればすぐに特定されるからです。しかし、 秘匿サービス では、サーバの時間帯に関する情報は、サーバが稼働している可能性のある国を特定するのに非常に役立ちます。 gzipの仕様を見れば、ファイル更新時間のヘッダフィールドには、ローカル時刻ではなく、世界時を使用すべきことは明確です。しかし、多くのサイトが世界時の代わりにローカル時刻を送信しています。どうもMicrosoft Windows

    HTTPレスポンスのgzip圧縮による日時リーク : Torの秘匿ネットワークの秘匿性を脅かす仕様・実装について | POSTD
    golden_eggg
    golden_eggg 2016/03/21
    gzipヘッダにローカル時刻を使用する事によって、サーバが稼働している国を特定される可能性があるという話
  • DHHはどのようにRailsのコントローラを書くのか | POSTD

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

    DHHはどのようにRailsのコントローラを書くのか | POSTD
    golden_eggg
    golden_eggg 2016/03/19
    "DRYやSRPが過大評価され過ぎ" 100いいね!したい
  • Vim-Galore : Vimについて知っておくべき全てのこと(1/5) | プログラミング | POSTD

    (編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) (訳注: 2016/2/26、記事タイトルを変更いたしました。) 特定のトピックについての記述をご希望ですか? Issue を立てるか、 Twitter で私までお知らせください!ありがとう! はじめに Vimとは何か? Vimの基原則 最初の一歩 ミニマルなvimrc 自分の実行しているVimの種類を知る チートシート 基礎 バッファ/ウインドウ/タブ アクティブ/読み込み済み/一覧表示/名前付きバッファ 引数リスト マッピング マップリーダー レジスタ 範囲 マーク機能 補完 モーション/オペレータ/テキストオブジェクト autocmd 変更履歴リスト/ジャンプリスト アンドゥツリー クイックフィックスと位置リスト マクロ カラースキーム 折り畳み機能 セッション ローカリティ 使用方法 オフラ

    golden_eggg
    golden_eggg 2016/02/23
    github( https://github.com/mhinz/vim-galore )のREADME翻訳するなら、本家にREADME_ja.md を追加するPR投げて欲しいな
  • 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
  • WebSocketには注意が必要 | POSTD

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

    WebSocketには注意が必要 | POSTD
  • TCPを(少しは)理解しておくべきその理由 | POSTD

    この記事はTCPの 全て を理解する、あるいは 『TCP/IP Illustrated』 (訳注:日語版: 『詳解TCP/IP〈Vol.1〉プロトコル』 )を読破しようとか、そういうことではありません。ほんの少しのTCPの知識がどれほど欠かせないものなのかについてお話します。まずはその理由をお話しましょう。 私が Recurse Center で働いているとき、PythonでTCPスタックを書きました( またPythonでTCPスタックを書いたらどうなるかについても書きました )。それはとても楽しく、ためになる経験でした。またそれでいいと思っていたんです。 そこから1年ぐらい経って、仕事で、誰かが「NSQへメッセージを送ったんだが、毎回40ミリ秒かかる」とSlackに投稿しているのを見つけました。私はこの問題についてすでに1週間ほど考え込んでいましたが、さっぱり答えがでませんでした。 こ

    TCPを(少しは)理解しておくべきその理由 | POSTD
  • 横柄なパスワード – パスワード認証に関する改善策 | POSTD

    パスワードにはうんざり。改善しましょう。 誰もが経験するあの瞬間。新しいサービスに登録し、パスワードを選んで入力する。でも、入れません。選んだパスワードは十分安全なはずなのに、使いたいサービスが独善的にそれを拒むのです。 記号、数字、大文字、小文字を少なくとも1つずつ使用しなければなりません。 小文字の長いパスワードの方がドルマークだらけの短いパスワードより安全だということを証明する、 XKCDの有名なコミック のことは忘れましょう。まず、あなたの主力パスワードが $$ICECREAM$$ だとします。アイスクリームは、恐ろしい人生の希望の灯火とも呼べるほどの大好物なので簡単に思い出せます。そして、このパスワードにはブートのための特殊文字が入っています。 残念なことに、 $$ICECREAM$$ には小文字と数字がないので、客観的に見れば安全ではありません。そこで、このサービスのためのパス

    横柄なパスワード – パスワード認証に関する改善策 | POSTD