日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能

こんにちは。atama plusでデザイナーをしている税所です。 今回はデュアルトラックアジャイルをやってみての気づきを書きます。 デュアルトラックアジャイル自体は、『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』でも述べられていたり、『正しいものを正しくつくる』でも近しい概念が述べられていたりして、注目度が上がってきているように感じています。 atama plusでは、私が入社する前からデュアルトラックアジャイルを行っておりました。当時はその進め方を知らず、採用面接で「デュ、デュアル・・・！？」となりましたが、内容をきいて「理想的だなあ」「でも、ちゃんと回せるのかな？」と思っておりました。 なにはともあれ、「まずはトライしてみよう！」とやってみての気付きをつらつらと書いていこうと思います。 入社してから１年、デュアルトラックでの取り組みを経験して、解像度を高めてチーム

Cy#の河合です。今回新しくオープンソースライブラリとして、マスターデータの管理用途を主眼に置いた、読み取り専用のインメモリデータベースを公開しました。 [GitHub – Cysharp/MasterMemory] 今までのゲーム開発の経験から、「省メモリ（インメモリということもあり使用メモリ量には気を使う」「高速なデータベースロード（構築に時間がかかるとゲームの起動速度に大きく影響する）」「高速な検索（ディクショナリのルックアップと同程度のクエリ）」の３点を重視して作りました。以下がベンチマークの結果となります。 MasterMemory、SQLite、LiteDB、RocksDBがインプロセス、Memcachedのみ別プロセスのマシン内通信による比較です。SQLite（ファイル読み込み型）の4700倍高速で、1クエリでのアロケーションはゼロです。また、保存時のファイルサイズも極小です

「このマンガがすごい！2019」オンナ編第1位など漫画賞を席巻！ 亡き夫と通った思い出の喫茶店が閉店し、立ち寄った書店では料理本がいつもと違うコーナーに。時が過ぎ去る寂しさのなか、彼女の目に止まったのは１冊のBLコミックス――。75歳の老婦人と書店員の女子高生が織りなすのは、誰もまだ見たことがない日々でした。 ■PVや著名人によるコメント動画などを掲載中の特設サイトはこちら→ 特設ページ

今日で仕事が納まった。それと同時にチームメンバーが一人チームを去ることになった。送別会もしたのでお別れはまあそれなりにしたんだけど、結構自分に影響を与えたのでなんとなくブログとして残しておくことにした。 うちの部署は複数のスクラムチームで構成されているスクラムオブスクラムという形を取っている。僕がこのチームに配属されたのは二ヶ月前くらいのことだ。部署内の別のチームからこのチームに異動したのがきっかけだ。チームメンバーの一人であり、今回お別れした人は認定スクラムマスターを持つエンジニアであり、このチームはちゃんとアジャイルなチームになろうとしているという話を事前に聞いていた。(以降、この人を彼と呼ぶ) 前職でもスクラム開発はやっていたつもりだったし、以前のチームでもスクラムを行なっていたのでなるほどなるほどという感じでチームのやり方に乗っかっていくことにした。見積もりをして、計画で洗い出し、

この文章は、2019年4月18日に開催された国際カンファレンス SeleniumConf Tokyo 2019 で行った基調講演の文字起こしを土台に加筆修正したものです。 当日の講演資料は speakerdeck で、動画は YouTube で公開されています。 Clean code that works - How can we go there? - Takuto Wada | SeleniumConf Tokyo 動作するきれいなコード - どうたどり着くか 本日の講演タイトルは「動作するきれいなコード - どうたどり着くか」です。動作するきれいなコードへ至る道の話をさせていただこうと思います。 資料は公開予定で、講演の写真撮影も問題ありません。ツイッター等での実況も大歓迎です。ハッシュタグは #SeConfTokyo です。 改めて自己紹介です。和田卓人（わだたくと）といいまして、

2019年3月14日開催のD3QAイベント「Agile QA Night」での発表資料です。 https://d-cube.connpass.com/event/121450/ スライド内で紹介した参考資料 ◆P34 テスト駆動開発から品質保証へと橋を架ける https://speaker…

この記事は Product Manager Advent Calendar 2019の18日目 です。 はじめに プロダクト作りにおける負債の種類 技術的負債 組織的負債 関係者的負債 思想的負債 負債の誕生 影響し合う負債の恐ろしさ 地道に負債を解きほぐしていく おわりに はじめに Yamotty氏の素晴らしい記事に触発され、 ストラテジーと実装の一致を保つのが困難な状態、つまり プロダクトに関わる負債のせいで進捗しづらくなった時に どのように戦っていけばいいのかを掘り下げていきます。 スタートアップの強みはストラテジーと実装の一致 早さが生まれる理由は「ストラテジーと実装が一致しているから」だと考えている。 逆に言うと、これらが一致していない場合、早さは生まれない。 正しい戦略が、組織や技術的負債のために実行されなければバツ。 逆に素晴らしいテクノロジーを扱えるチームがあったとしても、

Calendar page for Qiita Advent Calendar 2018 regarding モブプログ ... また空いてるので「書いてみようかな」って少しでも思った人はぜひ書いてください！ Advent Calendarはやったことあるかないかや、エキスパートであるかどうかに関係なく、この流れに乗ってアウトプットするぜっていう勢いがすべてだと個人的には思っております。せっかくなのでモブで記事を書いてみてはいかがでしょうか（ネタ提供）？ モブプログラミングのよくある誤解この1年半近く、モブプログラミングについていろんな方とお話する機会があったんですが、その中でよく出てくるモブプログラミングのよくある誤解について書いてみようと思います。 前提として、「モブプログラミングはすべてにおいて最＆高だからやるべきだ！」とは全く思っていません。 ですが、SNSなどを見てもネガティブな

君へ、 つい最近まで、南米で3ヶ月ほどデータエンジニアとして仕事していた。Tシャツで帰ってきて震えた。寒くて。 僕にとって2019年は、あんまりいろんなことが無かったくせに、いや糞ヒマだったからこそ、いろいろ考えることが多い1年だったと思う。最後の3ヶ月以外は、基本的にヒマだった。 過去に僕はベルリンで1年ほど働いていたこと*1があり、まあ結論からいうと音を上げて、日本に逃げ帰ってきた。何がそんなにしんどかったかというと、ベルリンは十分英語で生活できるとはいえ、ドイツ語関連のトラブルシューティングに付き合ってくれるドイツ人の友人を作ることができなかったというのが大きいが、そういう人間関係を構築することが出来なかったことも含めて、当時所属していた会社の上司および同僚と上手くいかなかったのが致命的だった。 とくに、エンジニアの同僚氏、つまり君は、まったく許せなかった。 あれからもう3年も経ち、

Dave Rensin, Google The rise of highly distributed computing systems based on microservices has made predicting and debugging our products more complex…

GMOペパボ Advent Calendar 2019 - Qiita 13日目の記事です。 昨日は tosite0345 さんの コミュニティを支える技術 でした。 今年をふりかえると、自分の仕事がすこしだけ楽になるようなツールを作って OSS として公開することにチャレンジしていました。今日は最近つくったツールの紹介と、そのような取り組みをはじめたきっかけについて書きたいと思います。 最近 業務にて不正利用が疑わしい海外の電話番号を見かけたときに、国番号を調べたことがありました。特別手間ではないけれど、検索しなくても済むようにしてみようかと思って、電話番号の地理情報を調べる CLI ツールを作りました。実装においては google/libphonenumber のサードパーティをお借りしています 🙏 つくったもの https://github.com/ryoma123/phong つ

この記事はLAPRAS Advent Calendar 2019の9日目の記事です 概要 LAPRASに入る前、業務の内容をDMでたくさん受け取って辛いという課題があった DMを受け取るとパブリックチャネルに優しく誘導してくれるDM警察というBOTを作ったがLAPRASに入ったら需要がなかった なんでや？じゃあLAPRAS関係ないやろ！？ まとめ 課題 - 業務の内容をDMでたくさん受け取るのは辛い このような内容をDMで受け取ると少し困ります。 パブリックチャネルの発言であれば、僕がこの質問に答えられない場合でも「@知っていそうな人 さん、わかりますか？」とメンションするだけで事が足ります。たまたま会話を見ていて知っている人が能動的に答えてくれる事もあるでしょう。また、後々一連の会話をシェアしたくなったときでも、この会話へのリンクを貼れば経緯を伝えることができます。DMではいずれも叶いま

「Game Graphic Design Advent Calendar 2019」の初日の記事です。 ゲーム制作に関する素敵な記事がたくさん公開されると思いますので、私自身もワクワクしてます。 言い出しっぺとして、初日としてまず何を書こうかなと思ってたんですが、以前Twitterでチラッとつぶやいた「普段ゲームUIを作るときってどういう工程があって、どういう流れで作っているか」をまとめてみたいと思います。 というのも、いろいろな方から「何から手を付けていいのか…」「デザインが上手くまとまらない」「デザイナーが社内外注みたいになってしまって…」みたいな話をよく聞きまして。 そのアンサーになるかは分かりませんが、自分の場合はこういうフローで、こういうことを意識してますよ。というのを書いてみたいと思います。 もちろん組織や人によってやり方は様々だと思いますので、こんな風にやってる人もいるんだ、

本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ

はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は