タグ

2019年3月7日のブックマーク (21件)

  • 2019-03-06 ダメな「運用自動化」の3類型 + α /operation-automation-3-bad-model

    ssmjp 2019/03での発表資料です。 「運用自動化の基原則」シリーズの番外編と位置付けています。 # 運用自動化の基原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24 運用業務の「構造化」: https://speakerdeck.com/opelab/20190524-structured-operation - 2019-04-18 運用自動化の基原則1 「引継ぎの原則」: https://speakerdeck.com/opelab/20190418-operation-automation-basis-principle-1 - 2019-05-24 運用自動化の基原則2「平易化の原則」: https

    2019-03-06 ダメな「運用自動化」の3類型 + α /operation-automation-3-bad-model
    braitom
    braitom 2019/03/07
    よくない運用自動化のパターンについて。事業継続性が向上しない自動化、サービス価値が向上しない自動化、デリバリ価値が向上しない自動化というアンチパターンの説明が書かれている。
  • サーバーレス失敗談 - DynamoDB編 / Serverless Fails

    Serverless Meetup Tokyo #11 での発表で使用したスライドです。 外部リンク: Serverless Meetup Tokyo #11 https://serverless.connpass.com/event/119559/ HiCustomer https://hicustomer.jp ServerlessなサービスのBlue/Greenデプロイメントの現実 | HiCustomer Tech Blog https://tech.hicustomer.jp/posts/blue-green-deployment-in-serverless/ サーバーレス失敗談 - テーブル設計編 | HiCustomer Tech Blog https://tech.hicustomer.jp/posts/serverless-fails/

    サーバーレス失敗談 - DynamoDB編 / Serverless Fails
  • AWS、侵入テスト申請やめるってよ - とある診断員の備忘録

    先日twitterを見ていたら、こんなつぶやきを拝見して、個人的に侵入テスト申請には色々思い入れのある身であるため、ビックリした「とある診断員」です。 あれ?AWSの侵入テスト申請いらなくなりました? pic.twitter.com/Z6ULU10SMy— 三ツ矢 ◎=3 (@328__) March 1, 2019 このブログでもとりあげましたが、今までAWSはペネトレーションテストや脆弱性診断などを実施する際に、AWS側への事前の申請が必要だったのですが、今回ポリシーの変更があったらしくどうやら不要になったようです。 ということで、私も自分で確認をしてみました。 Penetration Testing - Amazon Web Services (AWS) 現在日語版サイトは、翻訳が間に合ってないようでまだ更新されてないようですが(2019/3/5確認)、英語版の方は記載内容がガラリ

    AWS、侵入テスト申請やめるってよ - とある診断員の備忘録
    braitom
    braitom 2019/03/07
    AWSの侵入テストの事前申請が不要になったとのこと。
  • https://yamotty.tokyo/post/20190302_openess

    braitom
    braitom 2019/03/07
    分かる気がする。結局何のためにオープンにしているか、オープンの定義は何か、まで皆が理解しないとダメなんだろうな。ただ、チャンネルを全てPublicにしただけでは目的は果たせない。
  • 誰もが幸福になる成功指標のつかいかた - トクバイ テックブログ

    技術部の根岸(@negipo)です。おもにトクバイのウェブサービスを触っています。昨日の夜は一晩中イソギンチャクが泳ぐ動画を眺めて過ごしていました。 みなさん、サービス開発やってますか? ぼくはやってます。きわめて困難なことばかりでおもしろいですよね。ぼくはいつのまにか困難なことにめちゃくちゃなおもしろみを感じるようになってしまいました。たとえば成功指標の取扱いなんてわりとむずかしいのでおもしろいです。 「私たちはサービス全体のPVに対して責任を持っています」 「そうですね」 「今回の施策はサービス全体のPVを向上させるものです」 「わかりました。やってみました」 「よくわかりませんでしたね。PV、あんまり上がらなかったし」 「はい」 こういうこと、ありませんか? そんなことはないですか? あなたが一番最近やった施策ではどうでしたか? 「出したら前よりよくなるのが自明だから成功指標を立てな

    誰もが幸福になる成功指標のつかいかた - トクバイ テックブログ
    braitom
    braitom 2019/03/07
    サービス開発における成功指標について。成功の定義づけと成功指標の決め方、成功したかどうかをどのように判断するか、成功指標を決めることでどのような効果があるかなどが書かれている。
  • 企業ビジョンが自然体で根付かせたリモートワークと雑談

    リモートワークの課題として挙げられるのが、雑談をはじめとする仕事と直結しない「ゆるいコミュニケーション」の不足。創業当初からリモートワークを活用してこられたKaizen Platformでは、これを改善するために頑張り過ぎず、自然なやり方で取り組みを続けていました。プロダクトマネージャーの河部裕さんに話を聞きました。 新しい働き方を提供していくために、社員が自らリモートワークを実践 ―― リモートワークと雑談をテーマにお話を伺いますが、題に入る前に、Kaizen Platformの事業について教えて下さい。 河部裕さん(以下、敬称略):弊社には、2つのプロダクトがあります。「Kaizen Platform」は、創業以来取り組んでいるお客さまのウェブサイトの改善を実現するマーケティングプラットフォームで、私はこちらのプロダクトマネージャーを務めています。「Kaizen Ad」は、モバイル動

    企業ビジョンが自然体で根付かせたリモートワークと雑談
    braitom
    braitom 2019/03/07
    大事な考え“リモートワークは、基本的に「仕事の道具」の一つだと思います。なんでもかんでもリモートを選択するのではなく、必要なコミュニケーションによって必要な道具を選ぶことが重要です。”
  • Deep Work Hours

    braitom
    braitom 2019/03/07
    ポモドーロで目標管理ができるサービス。
  • GitHub - uber/kraken: P2P Docker registry capable of distributing TBs of data in seconds

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - uber/kraken: P2P Docker registry capable of distributing TBs of data in seconds
    braitom
    braitom 2019/03/07
    Uberで使われているP2Pアーキテクチャで作ったDocker Registry。Go製。
  • テスト自動化の今と今後

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、第6代黒帯 テスト自動化領域の山口です。 私が黒帯を拝命した2016年以降もテスト自動化に関する国内外の状況は変化しており、 もはや自動テストが検討されないソフトウェア開発は国内でも少なくなってきているように感じます。 そのような背景もあり、2019年4月18日、19日にはブラウザの自動テストツールであるSeleniumの国際的なカンファレンスであるSelenium Conferenceが東京で開催されます。 Selenium Conf Tokyo このカンファレンスは国内外のテストやテスト自動化で著名な登壇者による講演やその場でのディスカッションがあり、私も参加を大変楽しみにしています。 ヤフー株式会社は、カンファレ

    テスト自動化の今と今後
    braitom
    braitom 2019/03/07
    ヤフーでのテスト自動化の普及について。小さくテスト自動化を始め成果を出す、成果を出すと同時に普及できる人を育成する、全社の技術戦略に組み込んでいく。
  • スペックを上げてクラウドで殴るCI / pixiv TECH SALON #pixivTECHSALON

    pixiv TECH SALON ( https://techsalon.pixiv.co.jp/ )の発表資料です。

    スペックを上げてクラウドで殴るCI / pixiv TECH SALON #pixivTECHSALON
    braitom
    braitom 2019/03/07
    pixivのCI事情について。Unityアプリのビルドに時間がかかっていた問題をAWSを使うことでどのように改善したかについて書かれている。c5.2xlargeインスタンスを利用、3並列にすることで4倍の速度に。
  • Kubernetesの認定資格「CKA」を取得しました 〜これから受ける方へのアドバイス〜 - ビビリフクロウの足跡

    この度、Kubernetesの認定資格「CKA(Certified Kubernetes Administrator)」を取得いたしました! 今後受ける方のお役に立てばと、受験レポートを残しておきます。 要約 〜忙しい人はここだけ読んでね〜 試験に関する説明の書かれている英語のドキュメント「Handbook」「Important Tips」を熟読しよう! 「Kubernetes完全ガイド」の4章から8章は可能な限り、9章から12章は余力と相談して押さえておこう! 「Kubernetes The Hard Way」を1度実施し、各オペレーションの意味を理解しておこう! 受験動機 私の場合は、今まで培ってきたKubernetes技術知識を試すことが目的でした。また副次的な目的で、社内でコンテナ技術推進活動をしているため、その発言に説得力をもたせる意味もありました。 「Kubernetesの技

    Kubernetesの認定資格「CKA」を取得しました 〜これから受ける方へのアドバイス〜 - ビビリフクロウの足跡
    braitom
    braitom 2019/03/07
    リモートで試験管がちゃんといるし、レギュレーションもちゃんとしていてかなりしっかりした資格なんだな
  • Open Source Chart Image API | QuickChart

    Generate chart images with a simple, open API Add charts to emails, reports, and anywhere else. Over 4 billion charts rendered for users around the world. Get started View hosted plans https://quickchart.io/chart?c={type:'bar',data:{labels:['Q1','Q2','Q3','Q4'], datasets:[{label:'Users',data:[50,60,70,180]},{label:'Revenue',data:[100,200,300,400]}]}} ⇣ Embed charts anywhere. Our chart API generate

    braitom
    braitom 2019/03/07
    URLにグラフデータのJSONを渡すことでグラフの画像を返すAPIサービス。もうすぐ使えなくなるGoogle Image Chart APIの代替を狙っている。
  • Announcing the Open Sourcing of Windows Calculator

    Today, we’re excited to announce that we are open sourcing Windows Calculator on GitHub under the MIT License. This includes the source code, build system, unit tests, and product roadmap. Our goal is to build an even better user experience in partnership with the community. We are encouraging your fresh perspectives and increased participation to help define the future of Calculator. As developer

    Announcing the Open Sourcing of Windows Calculator
    braitom
    braitom 2019/03/07
    Windows標準の電卓アプリがOSS化された。MITライセンスでGitHubに公開されている。Azure Pipelinesなども利用していてモダンな感じ。
  • Fauna | The Distributed Document-Relational Database

    🚀 White Paper: How Fauna’s Document-Relational model addresses the limitations of traditional document databases

    Fauna | The Distributed Document-Relational Database
    braitom
    braitom 2019/03/07
    グローバル分散データベース。AzureのCosmosDBみたいなものかな。
  • 相手の文化を尊重するということ - 下林明正のブログ

    同質的集団の中にいると自分が属している文化を無意識のうちに当たり前のものだと思ってしまいがちだけど、当然集団の外では通用しないということを自覚し続けないとまずい。 別の文化に属する人と関わる必要があるときにすれ違いが生じるし、すれ違いに気づくときは大体は現実の問題として顕在化したときだからだ。 その文化は「何の」文化なのか、きちんと把握することが大事なのだと思う。日文化なのか、エンジニア文化なのか、ネットの文化なのか、など。把握できれば、相手がその文化に属しているのかいないのか類推し、対処することができる。 文化が違うときにどうするのかというと、基的に相手をコントロールすることはできないのだから自分が相手の文化を尊重するか、避けるしか無いのだと思う。尊重するのと受け入れるのは違う、というのもポイントだと思う。あくまで相手の文化を知ってそれに合わせるだけで、内面化するわけではない。そ

    相手の文化を尊重するということ - 下林明正のブログ
    braitom
    braitom 2019/03/07
    分かりみ。変に反発しても進まないので多少納得できなくても合わせた方が物事が進む。“あくまで相手の文化を知ってそれに合わせるだけで、内面化するわけではない。そうするだけで、大体の物事はスムーズに進む”
  • Engadget | Technology News & Reviews

    Research indicates that carbon dioxide removal plans will not be enough to meet Paris treaty goals

    Engadget | Technology News & Reviews
  • AWSの異常課金で気付いた不正アクセス--インシデントにどう対応したのか

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ウェブマーケティングサービスを手掛けるベーシックは、2018年12月に不正アクセスを受け、多くの顧客情報が第三者に侵害された可能性のあるセキュリティインシデントを経験した。結果的に情報流出は確認されなかったが、実際にインシデント対応を経験したことで多くの教訓を得たという。当時の状況などを開発部 最高技術責任者(CTO)の桜庭洋之氏に聞いた。 クラウドの課金で気付いた異変 同社が経験したセキュリティインシデントは、サービス提供基盤として利用しているAmazon Web Services(AWS)での不正アクセスが発端となった。同社のAWS EC2環境において何者かが不正にインスタンスを構築、稼働させ、仮想通貨の発掘を行っていた。その影響で

    AWSの異常課金で気付いた不正アクセス--インシデントにどう対応したのか
    braitom
    braitom 2019/03/07
    常に見えるようにしておくの大事だな。“毎日、Slackでレポートされる前日のAWSでの課金状況をチェックしており、不正アクセスに気付いた日(2018年12月6日)は、この金額が通常の2~3倍に増えていたという”
  • エンジニアリングの成果をより高度化するための仕事が、楽しくないわけがない――ヤフーのエンジニアリングマネジメントの考え方【デブサミ2019】

    「生涯エンジニアとして技術を極めたい」と願うエンジニアは少なくない。そこで問題となるのが、ピープルマネジメントができる人材の不足である。そもそもエンジニアリングマネジメントの仕事は、当にエンジニアのそれよりも魅力に欠けるものなのだろうか。エンジニアからマネージャーの道を選んだ背景と、エンジニアリングマネージャーとして大切にしてきたことについて、ヤフー株式会社 テクノロジーグループ Developer Relations アドボケートの山 学氏がセッションを行った。 講演資料:メンバーの成長とチャレンジのためにエンジニアリングマネージャーとして大切にしたこと ヤフー株式会社 テクノロジーグループ Developer Relations アドボケート 山学氏 マネジメントって、楽しい! 5つのポイント 山氏の現在の主な仕事は、ヤフーの持つテクノロジーやカルチャーの魅力を発信することと、

    エンジニアリングの成果をより高度化するための仕事が、楽しくないわけがない――ヤフーのエンジニアリングマネジメントの考え方【デブサミ2019】
    braitom
    braitom 2019/03/07
    いい言葉だ。“そもそもエンジニアリングが楽しいのだから、エンジニアリングの成果をより高度化するためのエンジニアリングマネジメントが、楽しくないわけがないじゃないですか”
  • わたしたちがチームであるために"期待合わせ会"をやりました、という話 - スタディサプリ Product Team Blog

    はじめまして、Web Developerの@tricknotesです。 今回はチームの期待を合わせるためのワークショップである「ドラッカー風エクササイズ」をわたしたちのチームで実践してみました、というお話です。 背景 なんでこのワークショップをやってみようと思ったのか…という話をする前に、まずわたしたちのチームの状況をお伝えさせてください。 わたしたちのチームは、ここ半年ほどで多くのメンバーが増えました。 その結果、古くからのドメイン知識に明るい古株層とまだまだドメイン知識の吸収を必要としている新入りメンバー層の間で大きな知識の隔たりがあるという状況になっています。*1 そんな中、歴史的経緯は気にせずいまの開発に集中してほしい古株メンバーと、そういった歴史的経緯を含めて吸収していきたい新入りメンバーの思いがそれぞれある、ということが振り返りの場で明らかになりました。 どちらもチームのためを

    わたしたちがチームであるために"期待合わせ会"をやりました、という話 - スタディサプリ Product Team Blog
    braitom
    braitom 2019/03/07
    ドラッガー風エクササイズの実践例。どのようにアレンジしたか、進め方、やってみての感想など。
  • OSSライセンスMeetup Vol.2「実録:GPL違反とその対応を振り返る」参加レポート | gihyo.jp

    OSSライセンスMeetup Vol.2「実録:GPL違反とその対応を振り返る」参加レポート 2019年2月21日(木)に開催された「OSSライセンスMeetup Vol.2「実録:GPL違反とその対応を振り返る」の参加レポートをお届けします。少しでもMeetupの雰囲気や魅力をお伝えできればと思います。 OSSライセンスMeetupとは その名の通り OSS(Open Source Software)のライセンスに関するテーマを扱うMeetupです。エンジニアに限らないさまざまな人に向けた「OSSライセンス」についての啓蒙や参加者間での知見の共有のための場という、ありそうでなかったMeetupです。 今回はGPLに主な焦点を当て、前半は日国内でGPL違反事例として語られるプロジェクトで当事者となった会社に在籍していた宮田晃佳さんを迎えて、状況や経緯、解決策、対応後の反響などについて振り

    OSSライセンスMeetup Vol.2「実録:GPL違反とその対応を振り返る」参加レポート | gihyo.jp
    braitom
    braitom 2019/03/07
    ふむ。“開発者寄りのライセンスの内容なので,法務に丸投げはできない。開発者と法務担当者で専門知識を持ち合って協議することがよい”
  • 続・マチマチとOSSの関わりをGitHubで振り返る

    ご近所SNS「マチマチ」を作っている武者(@knu)です。前回に引き続き、今回もマチマチとOSSとの関わりについて紹介したいと思います。 不具合のフィードバック それなりの規模のプロダクトを開発していれば、当然さまざまなライブラリやツールを使うことになりますが、自分達では特に変わった使い方をしているつもりはないのに、ふとバグに当たることがたびたびあります。認知バイアスの可能性もありますが、しょっちゅう 「なぜ我々が第一発見者なのか?みんな踏んでいないの?」 と感じている気がします。 そこで思い至るのは、「バグをバグであると認知して指摘する」こと自体が、スキルや経験の裏打ちを必要とする所業なのかもしれないということです。 自分に自信がない、ちゃんと調べる気に至らない、などの引っ込み思案に陥り、「きっと自分の使い方が悪いのだろう」「回避したら動いたからよしとしよう」と撤退してしまうエンジニア

    続・マチマチとOSSの関わりをGitHubで振り返る
    braitom
    braitom 2019/03/07
    ふむ。“バグをバグであると認知して指摘する」こと自体が、スキルや経験の裏打ちを必要とする所業なのかもしれないということです”