Mackerel / NewRelic / Elasticsearch Seminar という夢のコラボーレーションのイベントで登壇してきました。3サービスそれぞれ強みがあって、勿論競合する部分（代替できる部分）もあるのだけど組み合わせて使うことが多いと思っているサービスです。次は「住み分けにこんなユースケースあるよ」みたいな話が出来れば聞きたいのでそういう企業で喋りたい人、絶賛大募集中です。 登壇について で私の資料はこちら。 speakerdeck.com インフラエンジニアからすると知ってて当たり前のtopコマンドの見方みたいな話になってます。でもtopは今を知るためのコマンドで歴史を知るためにはモニタリングが必要です。そして歴史（履歴）が無いと障害対応の時に比較することができません。これは id:y_uuki くんが言ってる下記のツイートがまさにそのとおりだと思っています。 モニタ

ソフトウェアエンジニアリング関連の書籍を読んでいると、「コンウェイの法則（Conway's law）」によく出会う。その引用元は、1968年4月に発表されたメルヴィン・コンウェイ（Melvin E. Conway）の論文 "How do committees invent?" で、例の有名な一文は結論（conclusion）に書かれている。 （前略） organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. （広義での）システムを設計する組織は、自らのコミュニケーション構造を真似た設計を生み出すという制約

こんにちは。エムスリーでプロダクトマネージャーとして働いている岩田（@a___iwata）です。 最近、弊社山崎が各所で「ホームランを打つ」ということについて言及しています。 anchor.fm エムスリーでは「ホームラン」と呼べるような事業が多数立ち上がっています。 最近では、後払いによる会計待ち時間ゼロ、使いやすい予約と問診、QRでのチェックインといったスマートな診療を実現するデジスマ診療が例として挙げられます。 digikar-smart.jp ここでは、そんなホームランを打てる人が多数在籍している環境に身を置くことでどんなことが分かったのかを振り返っていこうと思います。 ホームランバッターと同じ環境で働けると何が嬉しいのか？ という問いの答えになれば幸いです。 ホームランを打つ、とは何か "アイデアこそ全て"症 良いプロダクトは、自然に広まる ---- 本当に？ プロダクトのアイデ

1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から

ver 0.2022.8: 夏到来 夏休みを前にして日本の感染者数がまた増えてきていますが、皆様いかがお過ごしでしょうか。id:iwasiman (ver 0.2022.8)が今月もリリースのテストをしているようです。 ヒャッハー、休みに突撃だワン〜(ドボン) / フォント: Proxima Nova ver 0.2022.8: 夏到来 2022年7月のアウトプットと参加イベントを振り返ると Blog等 学び編 本 Udemyとか GitHub ポートフォリオサービス系 おしごと編 ライフ編 健康と生活 子育て 娯楽編 映像作品とか 本とか ではまた～ 2022年7月のアウトプットと参加イベントを振り返ると アウトプットしたものや参加したイベントなどをまとめてみました。 Blog等 2022/08/01 【感想】『モダンJavaScriptの基本から始める　React実践の教科書』：フルカ

スクラムと 見積り やっとむ 合同会社やっとむ屋

かとじゅんさんのお誘いで、私塾匠真堂にて登壇させていただき、Rust に関する話をさせていただきました。ありがとうございました。 今回のセッションを通じて Rust を始めたくなった方向けに、Rust をはじめるための資料をいくつかリストアップしてます。よかったらどうぞ。 プログラミング言語の学習方法について Rust についてまず概観を掴む 文法を学ぶ 何かアプリケーションを実装してみる ちょっと突っ込んだ話を知りたい コミュニティの力を借りる 仲間を見つける 更新履歴 プログラミング言語の学習方法について みなさんは新しいプログラミング言語を学ぶ際、どのように学びますか？ 私は、軽く制御構文やデータ型の作り方などを学んだ後は、すぐにアプリケーションを作ってみて、詰まったらリファレンスを参照するといった学び方をしていることが多いです。 逆に、リファレンスをまず眺めて、文法をしっかり把握し

データアナリティクス事業本部 サービスソリューション部 サービス開発チームのしんやです。 Notionの直近リリースノートに「Mermaidっていうマークダウン構文がNotionで使えるようになったよ！」という情報が載っていたので、試してみた内容を軽くではありますが紹介したいと思います。 目次 Mermaidとは 実践 #1. フローチャート #2. シーケンス図 #3. クラス図 #4. 状態遷移図 #5. ER図 #6. ジャーニーマップ #7. ガントチャート #8. パイチャート #9. 要件図 まとめ Mermaidとは Mermaidとは、フローチャート、シーケンス図、クラス図、ガントチャート、およびgitグラフを生成するためのマークダウン構文です。 コードから良い感じのグラフを生成できるイメージについては下記動画を参照頂くと良さそうです。 実践 では早速実践してみたいと思いま

35歳の技術者派遣で働くプログラマが転職活動をしたので、振り返りを記録しておこうと思います。同じような立場の人たちの参考になればと思います。 自己紹介新卒でメーカー系SIerの子会社に就職して、業務系SEとしてキャリアをスタートさせました。その後組み込み系にキャリアチェンジして、現在は技術者派遣会社で組み込み系プログラマをしています。社会人歴は13年になりました。 詳しい内容は以下の記事をご覧ください。 なぜ転職しようと思ったのか現職の技術者派遣の会社の方針が変わって、自分の方向性と合わなくなってきたことが理由です。 自分の志向としてはプログラミングをやりたくて、できればずっとコードを書いて収入を得たいと考えていました。しかし、会社の方は「ソリューション！コンサル！」みたいな方向に舵を切っていて、人事制度にもその傾向が強く出始めたために次の会社を探すことにしました。このあたりの感覚は、前職

はじめに ソフトウェアエンジニアでテストマンを生業とする Kuniwak です。今回は家を買うためにやったことを紹介します。 というのも、家を買うためにやったことを知人に話してみたら面白がられたため、誰かの役に立つかもしれないと思ったからです。 なおこの記事はソフトウェアに関する技術の記事ではありません（随所に検証の基本的な考え方などが散りばめられていますが…）。また、この記事で紹介する意見・手法は多分に cocopon 氏の影響を受けています。cocopon 氏の家購入エントリもこの記事と同時に公開されているはずです。 また、この記事はとても長いので先にポイントを説明しておきます。この記事ではライフプランシミュレーションに始まり次のような3Dモデルを作って日照や照明の検証をしていきます。また、3Dモデルを作るだけでは漏れが出るのでさまざまな検証を組み合わせています： 検証のために作った3

“良いコ／悪いコ”で悪魔討伐！ (お排泄物)コード撲滅！ #ミノ駆動本 の感想記事の後編です。よき設計を妨げる様々な悪魔を紹介した後は、まことの名をもって悪魔を封じ打ち払う命名の章から... “良いコ／悪いコ”で悪魔討伐！ (お排泄物)コード撲滅！ 10 名前設計 ―あるべき構造を見破る名前― 11 コメント ―保守と変更の正確性を高める書き方― 12 メソッド（関数） ―良きクラスには良きメソッドあり― 13 モデリング ―クラス設計の土台― 14 リファクタリング ―既存コードを成長に導く技― 15 設計の意義と設計への向き合い方 16 設計を妨げる開発プロセスとの戦い 17 設計技術の理解の深め方 まとめ：見習いエクソシストエンジニアに悪魔を見破る目を授けてくれる福音の書 悪魔討伐 〇〇コード撲滅!! 『良いコード／悪いコードで学ぶ設計入門』 良いコード／悪いコードで学ぶ設計入門―保

はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな

“良いコ／悪いコ”で悪魔討伐！ (お排泄物)コード撲滅！ 前々から本で出ることは聞いていたのですが、爆殺シリーズやク〇コード動画でおなじみのミノ駆動さんのコード設計を扱った本がついに2022/4に商業本で登場。東京ですと書泉ブックタワーでのコンピュータ書籍ベスト1を4週連続達成など、かなり売れています。 エンジニア界隈では早速GW中などに読んだ方も多いようでネットでも反響が大きく、感想記事もよく見かけます。Twitterでもハッシュタグ #ミノ駆動本 で毎日のように反響を見ることができます。 僕もGW明けから拝読しました。とても学びの多い本でしたので以下、章ごとに感想を。 “良いコ／悪いコ”で悪魔討伐！ (お排泄物)コード撲滅！ 1 悪しき構造の弊害を知覚する 2 設計の初歩 3 クラス設計 ―すべてにつながる設計の基盤― 4 不変の活用 ―安定動作を構築する― 5 低凝集 ―バラバラにな

「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」の著者、市谷聡啓さんが2019年6月に出版した「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」を拝読しました。 本書をおすすめしたい人 プロダクト開発において、アジャイル開発での進めかたを知りたい人 アジャイル開発チームのプロダクトオーナー(ビジネスサイド、企画者） プロダクト開発チームが所属している会社の経営者 アジャイル開発を新たに学びたい人 アジャイル開発をひととおり知っているが、あらためて学びたい人 「正しいものを正しくつくる」という中心理念 本書のAmazonレビューを見ていたところ、星1つのレビューを見つけました。 エンジニアの傲慢さが詰まった本 「正しい」という言葉を使うエンジニア、同じエンジニアとして非常に恥ずかしい思いです。 「正しいも

8冠達成にありがとう！そして、ありがとう！ スカイハーイ！↑ 祝タイバニ２期!!(挨拶) 　じゃなかった、幾つかのエントリで触れていきましたが、AWS認定の8冠を達成することができました。これまで反応・応援・お祝いなどリアクションいただいた皆様ありがとうございました。 さて思えば2019年から入門を始めてゆっくりじっくり資格突破を重ねてきました。このエントリでは時間類をまとめてみたいと思います。 8冠達成にありがとう！そして、ありがとう！ ワイルドに突破してきたぜ！ 掛かったデータをまとめてみるでござる 考察、雑感などしてみるよ まとめ：自分のペースでやるといいよ(結局それかよ) おまけ AWS認定 学習期間と学習時間をまとめてみよう ワイルドに突破してきたぜ！ 認定突破の順番を図にすると以下になります。 受験パスの図 新しくなったデジタルバッジだと...基礎コース〜アソシエイト〜プロフェ