ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA #Forkwell_Library
![ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell](https://cdn-ak-scissors.b.st-hatena.com/image/square/4a6b555e9341fe0c6a316d9f9060f79f39991624/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F0f396f1510824474ad3c4783c43d97f3%2Fslide_0.jpg%3F29082463)
はいどうもー。クドウマサヤ(@masaya_dev)です。先日、東京からはるばる広島まで行ってきました。そう、YAPCという技術カンファレンスのために。 気づけば開催からもう2週間が経ち、東京へ帰ってきてからいろんな人にYAPCの思い出を語りました。語っていない日の方が少ない。思わず人に話したくなってしまう、それくらい心に残るイベントでした。 というわけで遅ればせながら思い出を綴っていこうと思います。ブログを書くまでがYAPC。 結論「良いLTは結論から」なんてエンジニア界隈ではよく言われますが、この記事でも先に結論を。 本当に参加できてよかった。 プログラミングが好きで、エンジニアリングが好きでWebエンジニアとして働いてきて十数年。 あの杜甫々(とほほ)さんをはじめ、dankogaiさん(@dankogai)、t_wadaさん(@t_wada)、naoyaさん(@naoya_ito)、
[beta] Next.jsクイズ2 • <p>にはなにが表示されるでしょうか? /app/page.tsx "use client"; import { useCallback, useEffect, useState } from "react"; export default function Home() { const [date, setDate] = useState(); const fetchDate = useCallback(async () => { const response = await fetch("/api"); const data = await response.json(); setDate(data.date); }, []); useEffect(() => { fetchDate(); }, [fetchDate]); return ( <
開発プロジェクトにおいて、開発スピードを測る尺度としてよく使われるのが「ベロシティ」です。このベロシティによって示される数字を適切に扱い、開発に活かしていくにはどうすればよいのでしょうか。 そのことを詳しく株式会社アトラクタ 吉羽龍太郎氏のセッション「ベロシティ Deep Dive」が、1月に都内で開催されたアジャイル開発の代表的な方法論であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2024」で行われました。 吉羽氏のセッションの内容をダイジェストで紹介しましょう。 本記事は前編、中編、後編の3つに分かれています。いまお読みの記事は前編です。 これから「ベロシティ Deep Dive」ということで「ベロシティ」についてお話をしていきたいと思います。 ベロシティを使っているっていう方、会場にどれぐらいいますか? (手が挙がる) 結構多いで
1日中ずっと仕事でMacを使っているぼくがほんとに使っているアプリを順不同で12個あげていこうと思う。 Google、Microsoft、など定番アプリは除外している。 1.AltTab 現在使用しているアプリを一覧表示して選択できるアプリ。 たくさんアプリを開いていて使いたいアプリが埋もれてしまったときとか、2つのアプリを行き来したいときに便利。 Windowsだと標準の機能みたいだ。 「開いているウインドウがないアプリを隠す」という設定にして格段に使いやすくなった 2.Alfred Macのすべての起点となるアプリ。 アプリの起動、ファイルやフォルダ、ウェブサイト、Google Driveの検索、離席時のスクリーンセーバー起動、計算機などできることは数しれず。 ぼくがよく使うのは、 ・Dropbox内のフォルダ検索 ・Google Drive内のファイル検索 ・計算機(地味だが使いやす
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか? また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか? 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
https://enog.jp/archives/2828 ENOG81で発表したスライドです。
RFC9460が出ました 昨年、このエンジニアブログでHTTPSレコードについてとりあげました。これを書いたときはHTTPSレコードはまだインターネットドラフトだったのですが、2023年11月、ついにRFC9460として標準化されました。 RFCにはなったけど日本語の詳しい記事はまだ少ないし需要あるかなーと思って改めて解説を書きはじめたんですが、だらだらとクソ長くなって書いた本人が読んでも眠くて退屈な内容になってしまいました。ので、書いたものはばっさり捨てました。 そういえばいまから3年前、DNS Summer Day 2021で発表したプレゼン資料がありました。これをRFCになった現在の内容にあわせてアップデートしたほうがてっとりばやいしわかりやすそうです。 ということで、加筆修正した資料を置いておきます。DNS屋さんはとりあえず全部読んでおいてください。Web屋さんは前半だけ理解してお
ビジネスの重要指標をモニターするために、ダッシュボードを作ったものの、時間の経過と共に、誰にも見られなくなってしまう、といった経験はありませんか? そうなってしまう理由の1つに、そこから得られる情報がビジネスの改善に結びつかない、あるいは特定のアクションに結びつかないため、ダッシュボードの閲覧者にとってあえて見る必要がなくなってしまうことがあります。 そこで、ダッシュボードの閲覧者に役立つ効果的なダッシュボードを作成するうえで、おさえるべき4つのポイントを紹介いたします。 1. モニターすべきは遅行指標でなく先行指標です 「売上」、「閲覧数」、「サインアップ数」などの「後追い指標」をモニターしても、それらは既に起こった「結果」なので、もうすでにとき遅しです。つまり、望む結果を得るために行動を変えることができません。 そこでしっかりとモニターしなくてはいけないのが、「リピート率」、「エンゲー
2023年、私はneccoでCTO兼フロントエンドエンジニアをしながら、専門学校の外部講師をつとめ、さらに本を一冊書き上げました。そのかたわら、STUDIOのユーザーフォーラムにTips記事を投稿したり、個人開発アプリをメンテナンスしたりもしていました。そして主婦として、毎日、自炊や洗濯などをこなし、老猫の介護も行っていました。私よりも忙しそうな人はたくさんいるものだとは思うものの、1日が24時間しかない中で、これらの膨大なタスクをこなすのは私にとって大変なことでした。 そんな私の支えになっていたのが「時間記録」でした。その内容はシンプルで、やるべきことをリストアップしたら、そのタスクごとにかかった時間を計測、記録していくというものです。 身体が「食べたもの」で作られるとしたら、人生は「やったこと」で作られると思っています。時間を記録していくことで、毎日の自分の行動を可視化できるようになり
どうもお疲れ様です。MESIです。 これは私が駆け出しの新卒1年目の頃でしょうか。 ある社内のつよつよエンジニアからこう言われました。 「MESIよ。流行りのフレームワークの使い方を覚えるのではなく、土台を理解しなさい」 彼はそう言い残すと1冊の本を残し会社を去っていきました。 これ。 託された本を読んでみたものの当時の私には難しすぎました。 理解ができないのですが、何が理解できないのかがわからない。そんな状態でした。 毎日この本とにらめっこをしましたが、時間だけが過ぎていきました。 大学でコンピュータサイエンスを全く学んでいない状態で入社した当時の私には難しすぎたのです。 私は諦めずにOS関連の低レイヤーの本を読み出しました。そして以下のループにハマりました 本の内容が理解できない ↓ 本を理解するために別の本を読む ↓ 理解できないのでまた別の本を読む いきなり難しい本にチャレンジをし
コンサルタントをやっていた時、「できない理由」を並べ立てる人々に数多く出会った。 彼らの習性として「新しい何か」には、ほぼ「忙しい」と反対する。 また、リスクばかりを強調し、その打開策は探そうとしない。 例えば、こんな具合だ。 企画「今年の方針発表にもあった通り、お客さんにサービスの満足度についてヒアリングをしたいのですが。」 営業「いや、今すぐは忙しくて無理ですよ」 企画「社長からは「すぐに」と言う話だったと思いますが……、なぜですか?」 営業「ただでさえ目標がキツイので。目標達成に影響が出ます。」 企画「そうですか。では、我々が動くので。営業の方は何もしなくていいですよ。」 営業「いや、それも困ります。」 企画「なぜですか?」 営業「お客さんを混乱させてしまうかもしれないからです。」 企画「具体的には?クレームが来る、という事でしょうか?」 営業「まあ、そうかもしれません。」 企画「か
昨年末に人生ではじめて面接を担当したので、考えたことを書いていきます。 大前提 面接をやるにあたって、個人的に心がけたのは「勘違いしない」ということです。 ネット上で流れてくる人事みたいな人間にはなりたくないな、と。 ただ採用する側になってみて、確かにこれは担当者を勘違いさせる魔力があるなと感じました。 良くないですね。 ただやっぱ採用って組織やチームとしてはめちゃくちゃ重要な活動なので、そこにコミットするのは大切。 特に小さな会社であればあるほど。 前提 今回の採用に関しては、iOSエンジニアの中途採用でした。 新卒採用だったらまた基準は違うと思います。 やるべきこと 面接に臨む前に、履歴書・職務経歴書は熟読しました。 SNSアカウント/Github/ポートフォリオサイトがあれば、それもサラッと見て。 面接そのものは実際そんな大事じゃないのかなと改めて思ったりもしました。 書類からある程
2024年3月31日をもって、32年間続けてきた放送作家業と脚本業を辞めることを表明した鈴木おさむ。マンネリを捨てることで、働く意味、人生の目的、幸せのカタチが見えてくるという。著書『仕事の辞め方』の一部を再編集してお届けする。1回目。 老害は60代、70代の話ではない 僕は「老害」による被害者側だとずっと思ってきました。 でも、この一年はそうでもないと思っています。 老害は60代、70代の話ではない。40代から老害を与える加害者側に立っている人もかなり多い。 事の始まりは、とあるYouTube チャンネル。『街録ch』という人気チャンネルをご存じでしょうか? 三谷三四郎というテレビディレクターが町中で、とんでもない人生を経験した人たちにインタビューするもので、これがとてつもなくおもしろい。 三谷Dは、元々お昼の番組『笑っていいとも!』のADさんで、そのあとディレクターになり、僕もいくつか
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個(勝手セレクション)」という興味深いポストをX(旧Twitter)で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個(勝手セレクション) コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
Let’s get the XKCD reference out of the way, shall we? Okay, now let’s talk about the Open Source sustainability crisis. The purpose of this post is to define terms. What is Open Source sustainability? Why do I say it is in crisis? My answers are that sustainability is when people are getting paid without jumping through hoops, and we’re in a crisis because people aren’t and they’re burning out. W
質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く