SRE チームの評価に役立つレベル別チェック リスト | Google Cloud 公式ブログ
※この投稿は米国時間 2019 年 1 月 26 日に Google Cloud blog に投稿されたものの抄訳です。 このたび、『The Site Reliability Workbook』がウェブサイトで閲覧できるようになりました。Google で生まれ、他の企業にも広まりつつある Site Reliability Engineering（SRE）は、運用上の問題をソフトウェア的に解決するためのエンジニアリングであり、Google におけるエンジニアリングの本質的な部分を占めています。 SRE は考え方であり、一連のプラクティスやメトリクスであり、システムの信頼性を保証するための処方箋でもあります。SRE モデルを構築すれば、サービスの信頼性が向上し、運用コストが下がり、人間が行う作業の価値が高くなって、サービスとチームの双方で大きなメリットが得られます。上述の新しいワークブックは、
僕のやってきた失敗したサービスについてのまとめ
19歳、まだインターネット黎明期の2000年くらいから、本格的にインターネットサービスを作り始めて来ましたが、非常に多くの失敗をしてきました。 失敗したものって目立たないので、あんまりデータとして残っていません。 基本的に、僕は失敗しないほうがいいと思っているタイプです。うまくいかないパターンを潰した、という失敗はいいと思うんですけど、多くの場合、思考が深くなりきれなかった、やるべきことをやりきれなかった、とかです。 というので、思い出をまとめてみました。 インターネットサービスを作りたい！とか、事業をやりたい！という人に参考になるかなと思って書いたんですが、書き終えてみると、そこまで学ぶことがなく、恥を晒している感じなので、980円に設定しています。どちらかというと、暇つぶしとか、人の失敗をみて安心する用です🤣。そして、そこまで読まれたい！というわけでもないので、おそらく一定数までいっ
なぜ開発言語にRubyを選んだのか？ SmartHRが明かす、成長の軌跡と技術選定 - Part1
2018年12月14日、品川シーズンテラスカンファレンスにてRubyアソシエーションが主催するイベント「Ruby Business Users Conference 2018 Winter」が開催されました。すでにRubyを活用しているユーザーや、これからRubyをビジネスに活用しようと考えている人が集い、情報交換を行いました。基調講演「スタートアップの銀行口座残高と技術選定」に登壇したのは、株式会社SmartHR副社長兼最高開発責任者の内藤研介氏。創業から今日に至るまでの軌跡と、開発言語としてRubyを選択した理由を語ります。 スタートアップの銀行口座残高と技術選定 内藤研介氏：お疲れ様です。素晴らしいプレゼンばかりでしたね。もう、まつもと（ゆきひろ）さんの話も聞いたし目当てのプレゼンも聞いたし、花金だし。「そろそろ帰りたいな」なんて方もいらっしゃるかもしれないですが（笑）、もう少しだけ
こんなやり方もありますよ？Webサイト制作にワークショップを活用する方法 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは！ 名古屋出身ディレクターのちゃんれみです。 今年の夏はひとり夏フェスデビューをしました。年々ひとりでできることが増えていきます。 さて、ちゃんれみは Web サイト制作のディレクターをしているのですが、サイト制作にワークショップを取り入れる機会が増えてきました。ワークショップのおかげで、デザイン提案が一発 OK！なんてこともあり、記事で取り上げもらったこともあります。 ワークショップとは ワークショップは、学びや創造、問題解決やトレーニングの手法である。参加者が自発的に作業や発言をおこなえる環境が整った場において、ファシリテーターと呼ばれる司会進行役を中心に、参加者全員が体験するものとして運営される形態がポピュラーとなっている。 セミナーは登壇者から一方的に情報を与え、参加者は受動的にその情報を得るという形態に対し、ワークショップはファシリテーターという司会役を中心に、参加者全
年末なのでBug Bashしてみたら盛り上がった - 弥生開発者ブログ
Misoca開発チームの北村です。 年末の寒波で山に雪が増えることを期待しています。 年末だしBug Bashやってみた 年越しまでWork-In-Progressな作業を持ち越したくない（年明けに記憶を取り戻すのが大変そう） 休暇直前に大きなリリースはしたくない ということで、この機会にBug Bashをやることにしました。Misocaで開催するのは初めての試み。 Bug Bashのやり方などはKyashさんの下記の記事を参考にしました。 blog.kyash.co Bug Bashやってみた 普段一緒に仕事しないメンバーで3チームを作り、Misocaを叩いてみました。 いじわるな入力：めちゃくちゃ長い文字列、HTMLの要素を書き換えて本来想定しない値を設定する ブラウザを2つ立ち上げて、同じデータを同時に編集する URLを書き換えて他の人の情報が見れないか 何度もreloadしたりsu
個人アプリ開発を支える技術と開発フロー - Qiita
iOS Advent Calendar 2018 の 10 日目です。 アプリをいくつかリリースしたり、ハッカソンでアプリを作ってきた中で個人的に定石となってきた開発フローや使っているツールなどをざっくりと時系列順で紹介します。 企画・アイデア 日頃から、何気なくアイデアを考えたりしています。「これ不便だな」と思ったら、どんなツールがあれば良くなるんだろうと考えてアプリのアイデアにしたり、Twitter などで面白い技術を使った動画を見つけたら、「これって他にも応用できないかな」と考えたりしています。 アイデアを考えているだけでは 3 日後には忘れてしまうので、メモをしておきます。 自分がよく使っているのは Trello と Simplenote です。 Trello でボードを作り、ジャンル (ユーティリティ、ゲームなど) ごとにリストを作って、アイデアのコア部分をカードにメモしています
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。｜じゅ ごん｜note
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。 [Ateam Lifestyle x cyma Advent Calendar 2018]の5日目は、株式会社エイチームライフスタイルの@gonjyu121が担当します。 はじめに最近のWEBサービス運営チームというと、事業運営や企画営業のチームと、エンジニアチームが一緒になって働く事が多いですよね。 そんな時、多くのエンジニアが、 「品質保持やリファクタリング、改善系のissue（タスク）の優先度がなかなか上がらず、着手できない・・・・・・」 といった悩みを抱えがちです。これなんですが、非エンジニアの皆さんからすると、 「エンジニアがすごいのは分かるんだけど、何をやってるか、なんでこんな時間がかかるのか、正直分からないんだよなー」 と思っていたりします。こんな話、
「実装しない」機能の決め方
考える犬個人開発のアプリはシンプルさが肝要。AdobeやMicrosoftのような巨大企業でない限り、機能で勝負しても負けるのは火を見るより明らか。難しいことは他に任せて、自分が解決したい問題にだけ集中する。作りたいアプリ像がはっきりしていれば、機能の取捨選択は簡単にできる。 拙作のInkdropというMarkdownノートアプリも、無駄な機能を付けないように努めている。そのためならユーザの要望も遠慮無く断る。今このアプリにお金を払ってくれている人は、そのシンプルさを買ってくれていると断言できる。ユーザさんにヒヤリングした時、以下のようなメッセージを貰った： My suggestion would be to try to keep the app clean and simple, focus on supporting developers primarily and not to o
ゲーム開発における失敗するに決まってるプロジェクト問題 島国大和のド畜生
俺は開発中プロジェクトの進行具合を見ればその後の成功失敗をわりと当てることができる。（偉そうに出たが、開発者の何割かは息を吸うようにこれをやる） 数日一緒に仕事をすれば確度はもっと高くなる。 美味しんぼにおける、「天ぷらを揚げる前に、上手い天ぷらをあげる職人が分かるか？」という奴だ。これのチーム版。 なぜそれが解る人と解らない人が居るかを説明する。 犬は嗅覚の世界で生きていて、鳥は視覚の世界で生きている。お互いの世界は理解することができない。 ゲームの開発現場には、犬、鳥、トカゲ、深海魚、ナマケモノと各種種族が入り混じっているので、ある属性の人には別の属性の人の重要な事象がまるで見えていない事がある。犬の世界は鳥には分からないのだから。 例えば日本人は、昔、青色と緑色は同じと扱っていた。どうでもよかったのだろう。 砂漠の民はラクダを表す言葉が年齢性別によって細かく区別されているという。重要
Storybookがなぜ必要か？(Vue.js編) - Qiita
まさあき(@masaaakikunsan)です。 最近よく、「Storybookを導入しよう」「Storybookがいい」と言う話は聞きますが、意外となぜ必要なのか、どう使うのか、という記事がみつからなかったので、基本的な使い方をサンプルと共に紹介します。 TL;DR StorybookでUIコンポーネントのカタログを作ることができる カタログのおかげでデザイナーと認識の齟齬が生まれなくなる アドオンを追加するとStorybookがかなり便利アイテムになる Storybookとは ざっくり言うとコンポーネントのカタログです。 コンポーネントライブラリの参照ができ、各コンポーネントの様々な状態の表示などができるものとなります。 また、アプリ外で実行されるため、UIコンポーネントを単独で開発でき、コンポネの再利用、テストの容易性、開発スピードを向上させることができるのが魅力です。
自分のコードを嫌いにならない、そのためにやるべきこと
「異能」ともいえる際立った能力や実績を持ち、まわりから一目置かれるエンジニアを1カ月に一人ずつ取り上げ、インタビューを掲載する。今月取り上げるのは、テスト駆動開発（TDD）の日本での第一人者として知られる和田卓人氏。JavaScriptのテストフレームワーク「power-assert」の作者でもある。最終回である今回は、power-assertの開発やテストに対する考え方などを聞いた。 （前回から続く） 自社製品を開発しようとワークフローエディターを自作して得たJavaScriptのスキルセットは、ぼくの大きな財産になりました。ワークフローエディターはかなり複雑なソフトウエアなので、テストコードなしでは開発は困難です。そこでJavaScriptのテストについてもいろいろ調べてみました。しかし、JavaScriptのテストの仕組みは当時はまだ全然発達しておらず、ほぼ手探り状態でした。 201
【初心者向け】テストコードの方針を考える（何をテストすべきか？どんなテストを書くべきか？） - Qiita
はじめに 「テストコードを書きましょう」とはよく言われるし、テストコードが大事だってことも理解できるんだけど、何をテストしたらいいの？どんなテストを書いたらいいの？と迷っている初心者プログラマさんは意外と多いのではないでしょうか？ そんな方たちに向けて、この記事では僕が普段意識しているテストコードの方針を紹介します。 おことわり 本来であれば具体的なコード例も豊富に入れたいところなのですが、かなり時間がかかってしまうので、いったん文章メインで記事を公開します。 もしかすると、そのうちコード例も一緒に盛り込んだ「リッチバージョン」を公開するかもしれません。 この記事の前提条件 この記事ではあくまで、「今現在、筆者が仕事で書いているテストコードの方針」です。 そのため、状況が異なると適用しづらい方針も出てくるかもしれません。 筆者は以下のような現場でコードを書いています。 月額定額で、お客様と
React NativeをWebに持ってくることの意味 - ナカザンドットネット
ブラウザはGUIアプリケーションプラットフォームではない Flexboxについて React DOMはGUIアプリケーションフレームワークではない React NativeはGUIアプリケーションプラットフォームの抽象である React Native for Webがブラウザに持ち込んだもの コンポーネントが便利 スタイル周りも良い感じ TouchableOpacityでタップ表現もラクラク 他にもいろいろあるけど プロダクション事例が強すぎる 作者のnecolasも語ってた まとめ 余談：React系のアプリケーションフレームワーク React Native for Webは、React NativeをWebに持ち込む試みです。 しばしば、こういった試みに対して「わけがわからない」「本末転倒である」といった意見を見かけますが、筆者は妥当な試みであるという印象を持っています。ちょっと頭の中
［速報］AIがコードのレコメンドやバグの指摘など開発を支援してくれる「Visual Studio IntelliCode」発表。Build 2018
［速報］AIがコードのレコメンドやバグの指摘など開発を支援してくれる「Visual Studio IntelliCode」発表。Build 2018 マイクロソフトは、米国シアトルで開催中のイベント「Microsoft Build 2018」で、AIを用いてプログラマの開発を支援する「Visual Studio IntelliCode」を発表しました。 Announcing Visual Studio IntelliCode - Enhancing everyday software development with the power of #AI across the entire development lifecycle. See what’s coming: https://t.co/k5eaYWcfnM #VS2017 #VSIntelliCode pic.twitter.co
プロダクトオーナーのアンチパターン
みなさんこんにちは。@ryuzeeです。 スクラムにおいてプロダクトオーナーは非常に重要な役割を果たしますが、一方でうまくやるのが難しい役割でもあります。 たとえばプロダクトオーナーには、ビジネス価値を最大化する、プロダクトのビジョンを周りに示して理解させる、プロダクトバックログを管理する、ステークホルダーをマネージする、開発チームの成果物の受け入れ可否を判定するといった多岐に渡る責任があり、限られた時間の中でバランスを取りながらやっていかなければいけません。 今回は、こういうのは避けようというアンチパターンを紹介します。 そもそも…多忙すぎるプロダクトオーナー不在のプロダクトオーナースクラムイベントに参加しないプロダクトオーナー単にマネージャーやリーダーという理由だけのプロダクトオーナーそもそも複数人で意思決定権限が分散されたプロダクトオーナープロダクトオーナーとスクラムマスターを兼任す
「中年の危機」ど真ん中のオッサンがWEBサービス作ってみた。 - Qiita
自己紹介 こんにちは。 Hirozといいます。 タイトルにある「中年の危機」は、かっこよく言えば「ミッドライフ・クライシス」と言うそうです。 私は、そんな中年の危機ど真ん中の文系非エンジニアのアラフォーおっさんです。 35歳くらいから「このままでいいのか」と思うようになり、葛藤の迷宮に入り込んでしまいました。 今もまだ抜け出せていません、たぶん。 その過程で「組織の肩書きによらない素の自分の力でやってみたい」、「直接人の役に立つ実感が得られることがしたい」と思うようになり、それを具現化する手段としてWEBサービスを造ってみたいと思うようになり、2017年12月にWEBサービスをリリースしました。 自分でプログラミングを習得しながら作るぞと思ったのが2017年の2月。 開発環境作りなどのトラブルに翻弄され、本格的にコードを書き始めることができたのは2017年の5月末。 そこからコツコツと開発
「巨大プルリク1件vs細かいプルリク100件」問題を考える（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 100 Duck-Sized Pull Requests 原文公開日: 2017/12 著者: Kurtis Funai 日本語タイトルは内容に即したものにしました。 2018/02/07: 初版公開 2022/02/24: 更新 Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 本記事では、昔ながらの問題である「巨大なプルリク1件と超細かいプルリク100件、どっちなら戦う気になれる？」に対する回答を示したいと思います。チームの一員としてよりよいコードを書くためのガイドラインについてもある程度解説します。今回の記事は、すべて以下のツイートから触発されました。 10 lines of code
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DevRelの基本とマーケティング戦略
技術選定の審美眼 / Understanding the Spiral of Technologies
Android案件見積りに現れる要素、あるいは丁寧に埋設された地雷たち
