Feature Toggles (often also refered to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practice

シックス・アパートでQAを務める井上です。 QA は「Quality Assurance」の略で、品質保証という意味ですが、あまり聞き慣れない言葉かと思います。QAという仕事は世間から脚光を浴びることも少ないので、どんなことをしているのだろうと思う方もいらっしゃるのではないでしょうか。 QAの仕事のフロー、役割や期待されていること、セオリー、はたまたQAあるあるについて、まとめてみます。 QAの仕事とは Movable Type や Lekumo など、シックス・アパートの製品やサービスの品質に問題がないかを確認して、ユーザーの皆さんに安心して利用していただける状態を保つのがミッションです。期待通りに動作するか、使いやすいか、どのブラウザでも同様に動作するか、セキュリティや性能に問題はないか、など様々な視点でチェックして品質を評価します。 日々のお仕事フローってこんなかんじ 製品に新機能を

ssmjp 2019/06での発表資料(その1)です。 # 運用自動化の基本原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24…

はじめに 先日、Rubyプログラマが本職である僕が、なぜか地元・兵庫県西脇市の中学校で情報モラル教育に関する講演をしてきました。 このエントリではなんでそんなことになったのか、そしてどんなことを話したのか、といった話を書いていきます。 【もくじ】 はじめに 講演を依頼されたいきさつ 去年の情報モラル講演会は本当にひどかった 今年は誰かな〜？ → えっ、僕！？ 当日使用したスライド この講演で伝えたかったこと 「スマホやSNSは怖い」だけでは終わらせない トラブルに遭遇したら大人に頼る（一人で解決しようとしない） リスクを語るときは、必ず予防策と対処法をセットで伝える テクニカルな解決策（設定の変更等）は重視しない 大人だって失敗したり、ちゃんとできてなかったりすることを伝える 生徒さんたちの感想 その他の裏話等 「経験がない＆時間がない」で、かなり準備が大変だった 信頼が置ける専門家の方た

1人もしくは（すごく能力の高い人だけの）少人数での開発と、大人数での開発ではプログラミングに対して気にするべきポイントに差があるような気がしています。 ここでいう大人数の開発とは、「プログラミングがどれくらいできるのか、自分が把握していない人がコードを書く可能性がある環境」を想定しています。 ここに挙げているポイントは「規模感に関わらず常に気にすべきこと」も含まれていますが、大人数になると特に問題が大きくなりそうなものをピックアップしてみました。 また、レビューに対する工数をすごくたくさんかけられる環境など、開発現場によっては当てはまらないものもいくつか含まれていますが、本記事ではあまり気にせず思いついたものを羅列しています。 本記事では基本的に「レビューでつぶす」という解決方法はあまり考慮していません。粒度によりますが、本当に厳密なレビューフローがないと、どこかのタイミングで読みづらいコ

読んだ理由 最近、ソフトウェアの設計力が不足していると感じる。もっといい感じにクラスを設計して、オブジェクト指向ぽいプログラムを書けるようになりたい。しかもスピード感を持ってやりたい。ということで、いまさらだけど、オブジェクト指向についてもう一度学んでみようと思った。本を読めばいいという訳じゃないけど、とりあえずもっと知識を増やしたい。渋谷の東急百貨店 7F の丸善＆ジュンク堂書店に行って、 オブジェクトデザイン (Object Oriented SELECTION) エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) の3冊で悩んだ結果、これを買った。決める要因となったのは、 ついでにデザインパターンについて理解を深められたらいいなと思った これまで

ども、@kimihom です。 今回は月額課金モデルの Web サービスを実現したい企業向けに設計の参考になる情報を提供できればと思う。こういう情報は割と自分なりに設計して実装するっていうパターンが多いかと思うが、とても大事なことなので慎重に検討していこう。 決済サービスの選択 まずは決済サービスをどれにするかって話。ここで一番大事なのは、扱うカード提供会社の種類だ。 Visa, Master は当然として、その他のクレジットカード会社が使えるのかどうか。ここは顧客のカード登録の自由度を決めるので、実は決済手数料よりもよっぽど大事な項目になる。要チェックだ。 あとは企業によっては収益が出た後の支払いフローも確認しておいたほうがいいかもしれない。収益の確定はいつで、支払いはいつなのか。黒字倒産するほど急成長することは稀だとは思うが、そのあたりのキャシュフローも事前に把握しておく必要がある。

女子高生と山月記 「虎になる」というフレーズが流行った。 高校時代の話だ。かつて鬼才と呼ばれた男が、己の心に潜む獣に振り回されて虎になる話を習った。重い題材なのにどうにも心にひっかかる上、人間が虎になるという衝撃的展開に驚いた。加えて「尊大な羞恥心」だとか「臆病な自尊心」とかいう妙に語呂の良いワードが登場することから、わたしたちは授業が終わってもこの話を忘れられず、結果「虎になる」というフレーズを局地的に流行らせた。 わたしたちは虎になった。主に葛藤してどうしようもない時や人間関係が煩わしい時、そして自分が嫌いになった時に。具体的に言うならテスト前や恋愛にまつわる他者とのいざこざ、理想と現実の狭間でもがいた時に、現状の気怠さを「ほんと虎になるわあ」と溜息交じりに吐き出したのだ。 仲のいいグループだけで使う暗号のような、気怠さの共有コードのような使い方をしていたのに、いつしか他のグループにも

+1 ボタン 2 AMP 11 API 3 App Indexing 8 CAPTCHA 1 Chrome 2 First Click Free 1 Google アシスタント 1 Google ニュース 1 Google プレイス 2 Javascript 1 Lighthouse 4 Merchant Center 8 NoHacked 4 PageSpeed Insights 1 reCAPTCHA v3 1 Search Console 101 speed 1 イベント 25 ウェブマスターガイドライン 57 ウェブマスタークイズ 2 ウェブマスターツール 83 ウェブマスターフォーラム 10 オートコンプリート 1 お知らせ 69 クロールとインデックス 75 サイトクリニック 4 サイトマップ 15 しごと検索 1 スマートフォン 11 セーフブラウジング 5 セキュリティ 1

Tama Ruby会議01のキーノートとして発表したスライドです。 https://tama-rb.github.io/tamarubykaigi01/ 参加レポートはこちら。 https://blog.jnito.com/entry/2019/07/07/102734

老後のためにコツコツ2000万円貯めていても、リストラされたり、転職に失敗したり、病気をしたりして、貯金がみるみる減っていき、ろくな貯金がないまま老後を迎えることになるかもしれない。 これに対し、「カネを使わずに人生を楽しむスキル」という資産は、たとえ不運が重なって生活保護で暮らすようになったとしても、がっつり残る。 「カネを使わずに人生を楽しむスキル」は、これ以上ないくらい、安全で確実な資産なのだ。 しかも、2000万円貯めるために毎月10万円貯金すると、毎月10万円生活費を削る必要があるので、現在の生活が貧しくなってしまう。 これに対し、「カネを使わずに人生を楽しむスキル」を蓄積するために毎月40時間を使ったとしても、現在の生活は貧しくなるどころか、逆に豊かになる。 なぜなら、「カネを使わずに人生を楽しむスキル」は、それを身につけるプロセス自体が、とても楽しいことだからだ。 あなたは、

Many programmers have a natural preference for short variable and method names. I doubt many would recognize this preference as a trade of brevity for clarity, but that’s often exactly the result. This is especially true if you subscribe to the ridiculous Church of 80-character Lines. It need not be that way. Writing terse code can be a joy even if you spell things out in abundant detail. Modern p

Oracle Database Technology Night #79 - Oracle Database 23ai 新機能 Oracle Advanced Cluster File System (ACFS)

ScalaMatsuri 2019 http://2019.scalamatsuri.org/index_en.html

みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。言い換えるとそれらがないとスプリントが開始できません。 本稿では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察してい

ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で

背景 今まで Stripe Subscriptions として出してきた製品がこの 4 月に Stripe Billing としてパワーアップし、新しくなりました。今回は、従来の定期支払いの請求に加え、より複雑な請求方法を Billing で実装できるようになりましたので、紹介していきます。 これまで Stripe Subscriptions 101 Part 1 としていた記事の更新記事になります。 今回のアップデートでは、段階制料金体系を構築する Tiered Pricing や毎月の利用料に応じて請求できる Metered Billing といった、主に SaaS 界隈で採用されている手法に、さらに寄り添うことができる仕組みとなりました。 例えば、ライセンスの数量テーブルに応じて価格が異なるサービスやライセンスが増えるごとに単価が異なるようなサービス、決められたサイクルで定期的に請求

「忍者式テストの定義が知りたい」という意見を観測しました。 実践者の一人として、現時点の理解を記録します。 簡単に言うと？ どういうときに向いている？ どうやって実施する？ 準備 最新のプロダクトをユーザー（の立場）で操作できる環境 手動テスト項目 毎日の作業時間（数分 〜 1時間） 嬉しさ 小さなテスト手順書から始められる 発見がある テスト手順に対して プロダクトに対して 新しいバグ バグを埋め込んでから発見するまでの時間が短い 何ではないの？ 歴史 その他の参考情報 名前 おまけ 簡単に言うと？ 忍者式テストは、手動テスト手法の１つです。 開発者が、日々のテスト実施を通して テスト項目 ユーザーとしての視点 テスターとしての視点 を育てていく手法です。 どういうときに向いている？ ユーザーインターフェースのテスト プロジェクトに参加したての時 プロダクトの目的、機能をよく知らない プ

MTBF（平均故障間隔）とかMTTR（平均修理時間）とか、世の中には品質をあらわすための指標が数多く存在するようですが「バグを発見してからプログラマーに伝わるまでの時間」という指標は、あるのかな？ わたしたちのチームは、これが圧倒的に早いです。 といっても、どこかと比較したことはないのだけど、どれくらい圧倒的に早いのか、最近のツイートに補足しながら説明します。 テスターが開発現場にいるときの場合 プログレスダイアログ関連のテスト中にクラッシュしたのでその場でプログラマー(←エース級)に見せたら「お見事！」て言われて（お見事！なんて初めて言われた…しかもエースに…）とログを取るエースの横で感動してたのだけど数時間後にはコミットされ今日はもう直ってた。バグは一瞬だけ光り輝く。— miwa (@miwa719) 2016年5月26日 テストしていると（はて、これはこういう仕様なのか、それともバグ