マガジンのカバー画像

エンジニア小噺

481
本
しょっさんの書いたエンジニア向けのエッセイ集
運営しているクリエイター
しょっさん

#ITアーキテクト

気ままにサーバの構成を組んでみる

インフラ屋さんの悪いクセの結果、何が起きるかと言うと。 こういうものができ上がります。 インフラ屋さんやめたし、なんならもう自作サーバとか作る気もないのに、しょっさんは何をしているのか。 とりま長く使えそうなサーバーにしたかったのと、拡張性が豊かなもの、後々サーバにもGPU食わせられるようにとか色々考えていたらこんなになってしまいました。 SSD のとこも RAID 組めるんだけど SSD で RAID 組むのってどうなのとか感じたり、ひとまず何かあった時にUSBかな

しょっさん

インフラアーキテクトの悪いクセ。

intel NUC で作った docker サーバの調子が悪いな、から一晩あけて。 今度は NAS におさまっている 4つのHDDのうち、一つが WARNING を吐きました。"current pending sector" です。 まだ壊れたわけじゃないけれども、とはいえ一つのセクタが不安定なことにまちがいはありません。なるたけ早めに対処した方が良いです。 ここで考えちゃうわけです。「NAS も置き換えた方が…?」「むしろでかいサーバーを買ってまとめちゃうのは…?」選

しょっさん

Salesforce に入社して9年。FY25の振り返り 🫡 [無料で全文読めます]

早いもので、Salesforce へ入社して9年だそうです。なんかもう何十年と働いている感じがします。廻りからも言われますけど、いうほど重鎮じゃないです。態度がでかいだけです。ホント申し訳ない。 そういえば、あと 1年で Koa club だなってメールも届いていました。感慨深いですね。 毎年恒例ではありますが、ちょっと振り返ったりしてみます。 Certified Principal, Technical Architect として FY25から認定された Techn

¥900
しょっさん

Salesforce のデータ設計の考え方 (標準オブジェクト-補足事項)

データ設定の考え方というか、標準オブジェクトを使えと言う話に終始してしまったんですが、今日はエンジニア的なちょっとした補足事項を載せておきます。 標準オブジェクトは特別 標準オブジェクトは特別なんです。内部仕様についてはここで述べることはできないのですが、特別であるということはお伝えします。 何が特別かというと、Salesforce Platform 上に標準的な枠組みで最初から作っておいただけのデータモデルではないということです。カスタムオブジェクトでまったく同じもの

しょっさん

Salesforce のデータ設計の考え方 (標準オブジェクト編)

年末の振り返りの時期ですが、それと合わせてしょっさんがアーキテクトとして考えてることも振り返り、自分がいつも何を考えているのかちょっと整理してみようと考えました。 先日の記事は、お陰様でアーキテクトネタとしては異例のアクセス数で、みんな困ってるんだなーってイロイロ感じました。なかなかね、弊社の社員がこういったネタを書くことってないでしょうからね。新鮮さもあるかもしれません。英語だと色々あるんだけどね。 さて、せっかくだから、この記事で分類してカテゴリごとに考えてみます。今

しょっさん

Salesforce のアーキテクトは何を考えて構成を考えているか

Salesforce の Pre-sales で (ほぼ唯一の) Technical Architect しょっさんです(ｴｯﾍﾝ 本日 12/23 は、Perfume かしゆかの誕生日です。また Salesforce Advent Calendar の 23日目でもあります。ともかく。ゆかちゃん、誕生日おめでとう。今度の週末は逢えるね 🥰 さて。そんな Certified Principal, Technical Architect のしょっさんが、Salesforce

しょっさん

ITアーキテクトの思考法 (購入時の選定編)

タイトルと内容がまったく異なる内容で面白かったので、紹介と言うか便乗できないかなと思い紹介します。 日常生活における物理学者が何を考えているかを紹介しているエッセイ、日常譚です。エスカレーターで人が偏ってしまう理由やその解決法を考えてしまう、みたいな内容です。理系の人にとってはあるあるな内容を奥様の突っ込み含めて楽しめる内容です。気分転換には丁度良いと感じます。 さて、便乗とはどういうことかと言うと。ITエンジニアが普段、日常的に考えていることは何かと言うことです。プログ

しょっさん

実現可能性の検証 (仮)

AI でも代用できそうと言うか、取って代わって欲しい事があります。 それは、実現可能性の検証です。アーキテクトがアーキテクチャを準備はしたものの、その実現性と言ったものは一切担保されません。コレは、要件定義から外部設計、内部設計と進んでいっても永遠に担保されずレビューワが何度もウォークスルーを繰り返し、慎重に慎重を重ねていって確からしさを机上で検証していきます。 各種ハードウェアやソフトウェアなどの仕様を、穴が開くほど微に入り細に入り調査し、過去の経験を持って妥当性を「机

¥1,000
しょっさん

システム構成図の書き方 #3 (意味を持たせる)

システム構成図の書き方最終回です。 最後は「意味を持たせる」です。スライドの描き方ではなく、あくまでも構成の書き方なので、色をどうしたら良いとか、見栄えをどうしたら良いとかは他の記事を参考になさってください。 色や見栄えをどうこうする以前のお話をします。

¥300
しょっさん

システム構成図の書き方 #2 (配置編)

前回はシステム構成図を準備するための心構えというか、考慮しておくべき事項をまとめました。 今回は「配置」に関してです。システム構成図やネットワーク構成図を記す際、対象となるコンポーネントやモジュール、抽象化された機器などを配置して、相互の関係性を線を使って示すことが多いでしょう。 該当する「箱」とも言うべきコンポーネントの配置の仕方について考えてみましょう。

¥300
しょっさん

システム構成図の書き方 #1

ITアーキテクトが何者だろうかとか、ITアーキテクチャがなんなのかとか、今絶賛まとめている最中です。が、完成されたものを見るステークホルダーや開発者の人は「その構造化された構成図がキレイか、見やすいか、分かりやすいか」にしか興味がないことでしょう。きっと。 完成された美しいシステム構成図やネットワーク構成図などを見た時、それだけで良いシステムだと勘違いします。見た目の麗しさは人をごまかします。 だからといってと言うわけではなく、正しく伝わりやすいシステム構成図と言うものは

¥300
しょっさん

ITアーキテクチャとは何か(前振り)

ITアーキテクトは定義を重んじるんです。学者肌の人が多いのもありますが、まずそもそもエンジニア自体が定義を重んじるべきです。あやふやな単語を分からずに使っていると、お互いの認識に齟齬が発生して、何も伝わりません。 ITアーキテクトとしてスタートラインに立った時、まずはじめに言われたことは「言葉を正しく使うこと」でした。ええ。はい。わかります。おっしゃる通りです。 そんな正論はおいといて、実際には、現場はその実態とはかけ離れています。同じ言葉でも違う使い方をすることがありま

しょっさん

ITアーキテクトは何者か(5)

ITアーキテクトとしての役割は多くあります。果たすべき責任も負います。 その中でも重要な責任として「説明責任(Accountability)」があります。 ここでいう説明責任というのは、アーキテクチャを設計する上での「決定」から生じた結果に対して、その理由を明確にして説明する事です。 なのですが、この設計方針や設計を決定した理由が不明確なままになっているドキュメントが非常に多い。わたしが見せていただく設計書には「決定事項」と「パラメータ」しか記述がありません。設計方針の

¥500
しょっさん

今年こそ充実したプログラミング学習を

#今年学びたいこと と言えば。プログラミングです。 「しょっさんはITアーキテクトだろ」と言われたら、そこまでなんですけれど。今でもプログラム自体は書けますし、今でも嗜んでいるプログラミング言語は数多くあります。でも、そうじゃないんです。 わたしがプログラムを朝から晩まで書いていたころは、手続き型や構造型のプログラミングコードの書き方です。サブルーチンのないBASICや、特定の構造・モジュールをファイル単位で分割する程度のC言語、高速化だけのために分割されたアセンブラのラ

しょっさん