Sachiko Kijima
Integration Dojoあるいはインテグレーション錬成道場受講後の復習用にどうぞ！
API Essential受講後の復習にどうぞ！
せっかくなのでServiceNowで行ったGraphQLの検証にまつわる記事をまとめて読めるようにしておきます
「レミングの死の行進みたいなプロジェクトだな」という印象を受けるプロジェクトに参加することがあり、(大体そうなるんですが、) それは本来どこがうまくいっていなかったのか、どうなければいけなかったかに興味があります。そこをうまくまとめた本。 ITやインフラなど、領域に関わらず規模の大きなプロジェクトの失敗事例を集め、その上でプロジェクトを成功させるために必要なアプローチを研究した人が書いた、成功するプロジェクトの秘訣の本です。 規模のでかいプロジェクトって失敗しますよね最初
Mobius Outcome Delivery Masterclassにて事例紹介させていただきました。 前半部分、なぜアーキテクチャにもOutcome Deliveryを使うのか、の部分のサマリを作っておきます。 イベントはこちら。 そもそもMobius Outcome Deliveryとは？Outcome Deliveryはデザイン思考をベースとした問題解決のフレームワークで、よくプロダクト開発に使われます。 ただし非常によくできており、一般的な問題解決にも使えるんで
我々のようなIT技術屋さんは時々ソフトウェアの構造を再整理したうえで作り直さなければいけないと言います。 これは技術的負債を減らすことで以下を獲得するためです。 安定性 よりバグが少なくなる 価値の実現までがより短い時間で済む セキュリティ などなど これはどの程度重要なのでしょうか。 ここではソフトウェアの構造が整理された状態でないことで実際に起こった問題を有名なリファクタリングプロジェクトの実例からお伝えします。Windows XPからWindows Vis
今の会社はすごく快適なんですけど英語を使う機会がまるっきりないので、いざという時にしゃべれなくなっていることに気がつきました。 なのでスキルのメンテのために英語の勉強をしています。 読むのはそれほど不安はないので問題はアウトプットなんです。 アウトプットは2種類、 口頭のアウトプット 文章のアウトプット で、どっちでも必要なのが自分の考えを英語の文章にする力、および文章生成のスピード感だと思います。 スピードを向上させるためには自分の中のフレーズデータベースが充実し
今の会社に来て英語のエスカレーションメールを書くことがなくなったのですが、過去のメモを発掘して、そういえば英語のエスカレーションメールを日本人が書くのってコツがあったよね、と思い出したのでメモっておきます。 英語で頑張ってエスカレーションメール書いたけど上が動いてくれない！が結構ありまして、嘆いている人のメールを見ると書き方がイマイチだったりするんですよね。 日本語で書いてGoogle翻訳をかけた、その後内容を整えた、みたいなやつだと動いてくれないことが多かったです。
自分はいろいろなことに興味があって情報収集をしているつもりだったので、生涯学習においてUnlearningが課題であることを読んだ時に他人事のように思っていたのですが、自分がきちんとUnlearningできていない領域を見つけて衝撃を受けました、という話。 すごくお恥ずかしい話なのですが。 自分がUnlearnできていなかった話私はここ数年iPhoneやiPad、Macを多用するAppleユーザーです。紙のデジタル化を粛々と進めており、デジタル機器便利だなーと思ってました。
実際の攻撃が発生し情報漏洩が起こったケース。 ホワイトハッカーの報告ではないので、目にした記事が正しいという前提でまとめてみます。 Trelloとは？SaaSのタスク管理ツールです。 カンバン方式のタスク管理用スペースを簡単に立ち上げられる便利なツールです。 攻撃の結果起こったこと15万ユーザーの情報が販売されていました。 Trelloから抜かれた情報はメールアドレス、フルネーム、ユーザー名と、直接漏洩した項目はあまりおおくありません。 特徴的なのはTrelloではない
しばらく調べていなかったのでまた調査を再開しました。 今回は少し前に見つけたUberの脆弱性。 ホワイトハッカーの方が2019年に見つけてUberに報告し、Uber側で既に修正済み。 ホワイトハッカーの方の脆弱性報告はどういう仕組みの脆弱性だったかまで明かしてくれるので、勉強になります。 脆弱性の内容ドライバー側が使用しているAPIと乗車ユーザー側のAPIを組み合わせると、電話番号からユーザーの情報を全て参照できるようになってしまっていました。 ステップは以下の通り。
マイクロサービスアーキテクチャ化案件っていうのは新規システムじゃなく既存システムで発生します。 では実装に入る前のグランドデザインフェーズってどう過ごしたらいいの? と最近よく質問されるので、言語化しておきたいと思います。 ここから先はあくまで マイクロサービスアーキテクチャなんてやったことないよ！ …という組織を、組織外のコンサルタントが支援する という視点でどのように進むものかという話をさせてください。 内容はマイクロサービスアーキテクチャやモダナイゼーション初
以前からCloud-NativeアプリケーションのTop 10ページが存在することは知っていたのですが、ほとんどがTBDなのでなんだろうと思ってたんです。 今見たら内容の入っているTop 10記事ができていました。まだレビュー中のようです。 日本語訳あります。 そもそもCloud-Native Applicationってなんだコンテナ技術を活用して動いているアプリケーション、くらいで考えていただくと良いと思います。 Amazonの説明によるとコンテナオーケストレーション
RCを書き換えようかとも思ったのですが、色々変更があったので別記事にしてみました。 大きな変更ではありませんが、順位が変わった、あるいは表現が変わったなどがRCとの違いです。 内容に変更がない場合は以前の記事をそのままコピペします。 API1:2023 オブジェクトレベルの認可の不備原文: Broken Object Level Authorization これは2019年から変わりません。 データベースでいうところのレコードレベルのアクセス権が設定されていないパターン
調査メモ。前回調査は2020/8。 誰得かわかりませんが、比較用に前回の調査メモ置いておきます。 従量型 (リクエストあたりいくら)従量型は利用者側 (APIクライアント開発者側) にとって支払い料金が読みにくいのがデメリットですが、その代わり呼ばれなかった時は料金が発生しないのが良いところです。 従量型から定額型に流れたと思ったのですが、また従量型に戻っているところがあったりなどして面白い。 新しい従量制のAPIを探す時は「pay as you go」などで見つかる。
10年かかってやっと「紙を最小化できた」というところまで来ました。 ノート術とか大好きで、紙のノート多用してたんです。 でも検索性が悪かったりして書いても情報を再利用しづらいとか、保管スペースの限界などでどんどんノートを捨てなければならず、デジタル化したいと思ってました。 普段ライフハック的なものは共有しないんですが、試行錯誤の時に記事をあちらこちら読ませていただいたので、同じように試行錯誤中の方々の何らかのヒントになりましたら幸いです。 ノートを使う目的を考えてみた最
意外とこういうのSaaSやソフトウェア製品の導入支援をしているときはお客さんに気を使って言えないんだけど今なら製品を扱ってないので言える。 ソフトウェア製品はIDEとかたたき台じゃないんだぞ！ 10年ほどソフトウェア製品を提供する会社におりますので、そこでみたトラブル事例から、SaaSやパッケージソフトウェアなどのソフトウェア製品をうまく活用する場合の心構えを書いてみました。 既存のソフトウェア製品を採用するって、初期開発はコスト削減になるかもしれませんが、戦略的にやらない
マイクロサービスアーキテクチャにした事例もあるけども、マイクロサービスアーキテクチャじゃなくした事例も目にするようになりました。 Istioはサービスメッシュとして使われるソフトウェアです。 最初Istioのコントロールプレーンの仕組みをマイクロサービスアーキテクチャを使って実現していましたが、弊害の方が強すぎてモノリスにしました、と言う話です。 コントロールプレーンの仕組み画像をサイトから引用させていただきます。 (a) がマイクロサービスアーキテクチャを採用していた時
新しいバージョンがRC (Release Candidate、リリース候補バージョン) になっているようです！ せっかくなので読んでみましょう。 正式にリリースされたら別の記事書くか、この記事を更新します。 オリジナルはこちら。まだGithubにあります。 ここからはまだ日本語の翻訳がないので、2019年版からタイトルの表現が変わっていないものは2019年版の日本語訳を踏襲し、表現が変わっているものや新しいものは英語で表現して本文中に適当な訳文をつけておきます。 ここでは
