タグ

2018年6月28日のブックマーク (5件)

  • 数百GBのデータをMySQLからBigQueryへ同期する | メルカリエンジニアリング

    SRE所属の @siroken3 です。最近はもっぱらパートナー会社様とのデータ連携環境構築を主に、時々プロダクションのMySQL環境と分析基盤との連携インフラの構築が多いです。 記事は、メルカリに出品された過去すべての商品をBigQueryへ同期するにあたって取り組んだ時のお話です。 背景 当社では分析目的などでBigQueryを以前から使用しており、プロダクションのMySQLからBigQueryへデータを同期して分析に活用してきました。特に商品を表すテーブルは重要です。 しかし、後述する課題によりBigQueryにアップロードすることができなかったため、分析用のMySQLDBのスレーブとBigQueryを併用せざるを得ませんでした。とはいえ不便なので以前からBigQueryのみで商品テーブルも分析対象としたい要望がありました。 課題 メルカリでは販売済み商品を物理削除していないため、

    数百GBのデータをMySQLからBigQueryへ同期する | メルカリエンジニアリング
    yk5656
    yk5656 2018/06/28
  • 土日の体感時間を“1週間”に延ばせる!? 目からウロコの「時間の長さコントロール法」|新R25 - シゴトも人生も、もっと楽しもう。

    社会人になってから時間があっ!という間に過ぎてしまうようになった、と感じるのはわたしだけでしょうか。 否、毎日忙しいR25世代なら誰しもが感じたことがある「時間のふしぎ」だと思います。 心待ちにしていた週末を迎えてホッと一息吐いたのも束の間、気付けば日曜日の夜になっている。これってなぜ…? そんな悩みを解決するため、今回は「時間学」の先生に「自分の時間をゆっくり進める方法」を聞いてきました! 〈聞き手=いしかわゆき(新R25編集部)〉

    土日の体感時間を“1週間”に延ばせる!? 目からウロコの「時間の長さコントロール法」|新R25 - シゴトも人生も、もっと楽しもう。
  • DX: Developer Experience (開発体験)は重要だ - Islands in the byte stream

    DX: Developer Experience (開発体験)とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」(=義務)以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX

    DX: Developer Experience (開発体験)は重要だ - Islands in the byte stream
  • 貴重なノウハウの宝庫である「失敗談」を語ってくれる人に、わざわざマウントしに行く、残念な人たち。

    最初にまとめると、この記事で言いたいことは下の三点になります。 ・世の中に成功談は多いが、当に参考にすべき失敗談は極めて観測しにくい ・成功談よりも失敗談の方が、再現性、リスク把握、リスク回避などの観点から、ノウハウとして貴重である ・我々は失敗談をもっと評価するべきであり、失敗談を語ってくれる人を大切にするべきではないか 以上です。よろしくお願いします。 さて、最初に言いたいことは全部まとめてしまったので、あとはざっくばらんにいきましょう、 世の中には、いわゆる「成功談」とか「成功体験の記録」「成功者へのインタビュー」といったものが山ほど転がっています。 石を投げれば成功体験にぶつかる、と言ってもいいくらい、Webではたくさんの成功談を観測出来ます。 何故かというと、「人は基的に自分の成功談を語りたがる」上に、「人は基的に成功談を喜んで聞く」からです。 需要と供給が共にあるのですか

    貴重なノウハウの宝庫である「失敗談」を語ってくれる人に、わざわざマウントしに行く、残念な人たち。
  • エンジニアの能力と今どきの難しさ

    エンジニア(ここでは主にプログラマー)に必要な知識や経験って、ざっくりベース、カテゴリ、実行環境というレイヤー分けられると思ってて、それぞれに対してはだいたい以下のような定義で考えている。 ①ベース コンピュータサイエンス(CS)などの理論的なもの低レイヤー②カテゴリ フロントエンド / バックエンド / クライアントアプリなど③実行環境 特定のプログラミング言語や開発環境やツール、フレームワークやライブラリなど最近の潮流で言うと、③の部分から入る人が多いと思う。 ③は比較的習得が楽なこともあって、初心者がプログラミングを始める際には一番コストパフォーマンスが高い。中身はブラックボックスであってもなんとなく動くものは作れるので、自己満足にしろ仕事にしろ成果として見えるものにはなる。 ただし、流行り廃りが速く、手を動かし続けないとキャッチアップしていけない。 ①は習得するのに時間かかる。その

    エンジニアの能力と今どきの難しさ