タグ

ブックマーク / yakst.com (18)

  • GitHubのRails離れと、迫りくるMicrosoft | Yakst

    Microsoftによる買収が発表されたGitHubは、これまでどう進化し、今度どうなっていくのか?開発者プラットフォームとしてのGitHubが目指す未来を、同社のSam Lambert氏がプログラミング言語、データセンター戦略、AIといった様々な観点から語る。 [Ruby on Rails]原文 GitHub goes off the Rails as Microsoft closes in (English) 原文著者 Thomas Claburn (The Register) 原文公開日 2018-08-16 翻訳依頼者 翻訳者 mkasasagi 翻訳レビュアー doublemarket taka-h 原著者への翻訳報告 1888日前 メールで報告済み 1878日前 原著者承諾済み 編集 プラットフォーム改造で変わる「Ruby専門店」。今後はGoJavaKubernetesへ。

    teppeis
    teppeis 2018/09/27
    「GitHubがMicrosoft Azureを採用するのはまだ時期尚早であり、さらに特注品だらけな同社の運用を考えるとその可能性はさらに低いだろう」
  • InfluxDBのOpenTracing対応: 分散トレーシングのオープンスタンダード | Yakst

    マイクロサービスの構成が増えるにあたりシステムが複雑化し問題が発生した際の原因究明が困難となり分散トレーシングの必要性が高まっています。一方でこの計装はとても大変で、これに対しOpenTracingはベンダーに中立な標準規格を目指しこれを簡易化可能としています。InfluxDataはこれに対して、TelegrafのZipkinプラグインを提供しています。またInfluxDBはトレースのデータ保存にも構造的に最適なデータストアと考えており、InfluxCloudサービスでOpenTracingを実装中です。 [InfluxData]原文 OpenTracing | Open Standard for Distributed Tracing | InfluxData (English) 原文著者 GIANLUCA ARBEZZANO 原文公開日 2017-10-25 翻訳依頼者 翻訳者 tak

  • MySQLのレプリケーション手法の違い | Yakst

    ソリューションエンジニアチームに所属する筆者が、今では様々な手法が存在するレプリケーション機能について、改めて特徴や注意点を解説しつつ、レプリケーションのよくある「誤解」に対してもお答えしています。 このブログ記事では、MySQL(および Percona Server)環境におけるレプリケーション手法に関して改めて考察を行いたいと思います。あわせて、時折見受けられるレプリケーションの間違った考え方についても考えてみます。 私がソリューションエンジニアとして働き始めてからというもの、沢山の情報が公開されているにも関わらず、レプリケーションに対する「誤解」や「不完全な理解」が無くならないことを日々感じていました。 そもそもレプリケーションとは何か? レプリケーションは、1つのデータベースにデータを蓄積するだけでなく、別のデータベースにデータを複製し、転送することを保証してくれる機能です (複製

    MySQLのレプリケーション手法の違い | Yakst
  • MySQLの高可用性構成の展望2017年版(赤ちゃん編) | Yakst

    シリーズ第三回目で、「グループレプリケーション」「プロキシ」「分散ストレージ」について紹介している。グループレプリケーションはGaleraとの違いについて、プロキシには幾つかの選択肢があること、分散ストレージではオープンソースのAuroraのようなデーターベースが可能になることなどが述べられている。 この記事は、2017年現在で使用できるMySQLの高可用性ソリューションに焦点を当てたシリーズの第3回目です。 最初の記事では10年以上前から存在していた技術である「長老」を見ました。(訳注:長老編日語訳)第2回目の記事では「大人」 、つまりより最近の成熟した技術について話しました。(訳注:大人編日語訳)この記事では、新興のMySQL高可用性ソリューションを紹介します。私がブログで選択した「赤ちゃん」の高可用性ソリューションは、 Group Replication(グループレプリケーション

  • 人間らしくコードレビューするには(パート1) | Yakst

    自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithub

  • MySQLの高可用性構成の展望2017年版(大人編) | Yakst

    以前公開された「長老編」(https://yakst.com/ja/posts/4656) に引き続き、比較的新しいMySQL高可用性オプション(大人たち)について解説した記事。前回同様、初心者向けに「Galera」と「RDS Aurora」の2つを紹介している。 この記事では、いくつかの高可用性ソリューションについて考察を行います。 このシリーズの前回の記事(訳注:日語版はこちら)では、長きにわたって利用されてきたMySQLの高可用性ソリューションを取り上げました。私はこれらを「The Elders (長老たち)」と名づけました。レプリケーションなどは今でもよく使われており、MySQLの新バージョンがリリースされるごとに改善されています。 この記事では直近5年間で登場し、なおかつコミュニティの中で牽引力を増している高可用性ソリューションに着目します。私はその中から2つのソリューションを

    MySQLの高可用性構成の展望2017年版(大人編) | Yakst
  • MySQL 8.0 : クエリーキャッシュのサポート終了 | Yakst

    役に立つ場面もある一方、スケーラビリティー上問題があるとされてきたMySQLのクエリーキャッシュが、MySQL 8.0で廃止されることになる。その背景と理由。 免責事項 この記事はMorgan Tocker氏によるMySQL Server Blogの投稿「MySQL 8.0: Retiring Support for the Query Cache」(2017/5/30)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 Reneが昨日、ProxySQLのブログにこう書きました。 MySQLのクエリーキャッシュはパフォーマンスを改善するためにあるが、それは重大なスケーラビリティー上の問題を抱えていて、深刻なボトルネックに簡単になってしまいかねない。 これは、MySQLチーム内でも確かに長い間言われてきたことです。今日の記事の題に入る前に、少しイントロダクションを書かせて

    MySQL 8.0 : クエリーキャッシュのサポート終了 | Yakst
    teppeis
    teppeis 2017/06/11
  • 寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst

    これまでのMySQLでよく問題になった、絵文字や日語の文字の照合やソート順序の問題に関して、来たるMySQL 8.0では大幅な改善が加えられる予定になっている。この問題の概要と今後の改善方針について、MySQL開発チームからの解説。 免責事項 この記事はManyi Lu氏によるMySQL Server Blogの投稿「Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0」(2017/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0での私たちの計画として、utf8のサポートを大幅に改善します。utf8サポート自体はMySQL 4.1の頃にさかのぼりますが、いくつかの制限が存在しています。記事タイトルにもある「寿司 = ビール」問題は、バグ#76553のことを指しています。少

    寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst
  • マイクロサービス時代のHAProxy | Yakst

    マイクロサービスのアーキテクチャでシステムを開発すると、サービス間の通信を効率的に管理する方法が必要になる。この問題を解決するためにHAProxyを使う一例を提示する。 「マイクロサービス」は、この10年でもっとも興味深いアーキテクチャーのスタイルを表す言葉として、使い散らされている最新のアーキテクチャーバズワードでしょう。 マイクロサービスとは? Martin Fowlerの定義によれば以下のようになります。 要するにマイクロサービスというアーキテクチャーのスタイルは、それぞれが独自のプロセスで動きHTTPリソースAPIなどの軽量なメカニズムでコミュニケーションを取り合う小さなサービスの形をとったひとつのアプリケーションを開発していくというアプローチです。これらのサービスは、ビジネス上の機能を中心に作られ、完全に自動化されたデプロイの仕組みによって、別々にデプロイできます。これらのサービ

    マイクロサービス時代のHAProxy | Yakst
    teppeis
    teppeis 2015/11/11
  • GitHub : ノマドなエンジニア達とRubyをスケールさせる | Yakst

    GitHub技術ディレクターが語る、GitHubのインフラの特徴と、社員の6割がリモート勤務という社風、Hubotを使った協力的かつ新しい働き方。 Sam Lambertは、2013年にGitHubの最初のデータベース管理者として入社し、現在はGitHub技術ディレクターを務めています。このインタビューで彼は、今や1000万以上のユーザと2500万以上のプロジェクトを誇るサービスが、比較的シンプルな技術的スタックの上でどのようにスケールし続けてきたのかを考察しています。また、自作のパワフルなチャットボットであるHubotを使ってコラボレーションしつつ、従業員の約6割がリモートで働いているという、GitHubの大規模なオフィスレスな仕事環境についても触れています。 SCALE: 私としては、GitHubテクノロジーのユーザーというよりは主にテクノロジーの提供者であると思っていますが、そ

    GitHub : ノマドなエンジニア達とRubyをスケールさせる | Yakst
  • 類い稀なMySQLのJavaScript Connector (MySQL High Availabilityより) | Yakst

    node.jsを使ってMySQLへのデータアクセスを行うmysql-jsを紹介する。これを利用すればSQLを使わずにオブジェクト指向プログラミングの恩恵を受けることが出来る。 出典について この記事はcraigrussell氏によるMySQL High Availabilityの投稿「The JavaScript Connector for MySQL you never heard of」(2015/7/14)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 Webサーバをたてて、node.jsとExpressを使ってデータベースに接続するのはかつてないほど簡単になっている。node.jsを使ってRDBからデータを取り出すには、かつてはユーザーがSQL技術に熟練している必要があった。 そこでMySQLの開発チームは、MySQLからのドキュメントを保存、検索し、nod

    類い稀なMySQLのJavaScript Connector (MySQL High Availabilityより) | Yakst
  • Engineering at Monsanto: AWS上でのetcdのクラスタリング | Yakst

    バイオ化学メーカーのモンサントはAWS上にetcdのクラスタを展開している。興味があったので読んでみた。 概要 数ヶ月の間、我々のチームはAWS上で自動化されたDockerコンテナを構築することにフォーカスしている。我々はCoreOSを基盤として使おうと決めた。CoreOSはコンテナをコアとした軽量なOSだ。 各マシンのコンテナのスケジューリングとしてfleetを使っている。fleetはホストがターミネートされたとしてもコンテナを稼働させ続ける。 CoreOSとfleetはクラスタ内のすべてのマシンと、稼働しているコンテナの状態を共有する必要がある。 これにはetcdが効果的だ。etcdはクラスタの情報と共通のコンフィグを保存する分散キーバリューストアとして使われる。 巨大なプロダクション環境にて、etcdは3つもしくは5つのホストで稼働するよう設計されている。 Bootstrapの問題

  • Yakst | 人力翻訳コミュニティ

    [スタートアップ]翻訳者 doublemarket / 5ヶ月前 急成長するスタートアップがどうしてそのスピード感や勢いを失ってしまうことがあるのか、その背景にある構造とパターンを筆者の目から解き明かし、それを回避する方法を提案する。John Qian氏のブログ記事の翻訳。

    teppeis
    teppeis 2015/07/14
  • 大規模環境でMySQLのGTIDを適用して得られた教訓 | Yakst

    MySQL 5.6からの機能であるGTIDを、Facebookの環境に適用した際の流れと主な不具合、そしてそれらの修正点について、Facebookのエンジニアによるまとめ。 by Evan Elias and Santosh Praneeth Banda Global Transaction ID (GTID)は、MySQL 5.6の新機能の中でも最も使わずにはいられない機能の一つだ。このおかげで、フェイルオーバやポイントインタイムリカバリ、階層を持ったレプリケーションなどに非常に有益だし、クラッシュセーフなマルチスレッドレプリケーションの必須条件にもなっている。この数ヶ月で、我々はFacebookの全ての番用MySQLインスタンスで、GTIDを有効にした。その中で、この機能の適用方法や操作について、たくさんの知見が得られた。たくさんのサーバサイドの修正事項については、WebScaleS

    大規模環境でMySQLのGTIDを適用して得られた教訓 | Yakst
  • MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst

    MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、

    MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst
  • MySQLの大きなテーブルでのパフォーマンスを改善する10の方法 | Yakst

    MySQLコミュニティマネージャのMorgan Tocker氏による、テーブルサイズが大きくなるにつれてINSERTのパフォーマンスが落ちてきてしまうことを防ぐ様々な方法についてのまとめ。 今日は、パフォーマンス問題を引き起こす原因になる、サイズの大きいテーブルのパフォーマンスを改善することについて書いてみようと思う。このアドバイスのうちのいくつかは、たくさんのテーブルをまとめて大きくなっているデータベースにも適用できるが、大抵の場合、独立した大きなテーブルというのは特に問題になりやすいものだ。 一般的に知られていると思われるのは、テーブルを変更する時のスピードは、そのサイズが大きくなるにつれて遅くなることだ。以下の図は、一般的なB+ツリーインデックスのパフォーマンスを時系列で見たものだ。 このグラフは、MySQL@Facebookの記事から拝借したものだ。これは、insert buffe

    MySQLの大きなテーブルでのパフォーマンスを改善する10の方法 | Yakst
  • 私が他人のシェルスクリプトから学んだこと | Yakst

    私はシェルスクリプトの大ファンで、他人のスクリプトから面白い方法を学ぶのが大好きだ。最近、SSHサーバの2要素認証を簡単にするためのauthy-sshスクリプトに出会った。このスクリプト群を見まわしていて、みんなと共有したいたくさんのクールなことを見つけた。 出力に色付けする 出力文字列を、成功した時は緑に、失敗した時は赤に、警告は黄色に色づけしたいと思うことはたくさんあるだろう。 NORMAL=$(tput sgr0) GREEN=$(tput setaf 2; tput bold) YELLOW=$(tput setaf 3) RED=$(tput setaf 1) function red() { echo -e "$RED$*$NORMAL" } function green() { echo -e "$GREEN$*$NORMAL" } function yellow() { e

    私が他人のシェルスクリプトから学んだこと | Yakst
  • git rebaseを使うときのルール | Yakst

    Re: [git pull] drm-next Linus Torvalds Sun, 29 Mar 2009 14:48:18 -0700 (訳注 : Daveのrebaseのやり方が好みでないというLinusに対して) > 2009年5月29日(日曜日) Dave Airlieの発言 > > 今から自分がしようとしているのは、直線じゃないツリーを送ろうとしているだけだ。 > パッチを自分の次のツリーにマージする時はいつでも、そこにそれがあるからだ。 > 自分は、Ericのツリーを自分のツリーに直接プルして、その結果を送ろうとしている。 > きれいなマージ履歴について注意しているとは思っているけど、前に言ったように、 > カーネルツリーに関してのドキュメントが何もない状態では、君がどうしたいのか > 当のところは今の今まで分からないよ。 自分が求めているのは、きれいな履歴だ。でも、それ

    git rebaseを使うときのルール | Yakst
    teppeis
    teppeis 2013/08/03
    Linus「他人の履歴は消すな」「自分の履歴はきれいにしろ」わかりやすい。ただアップストリームのマージルールは一般的じゃない気がする。
  • 1