/note/tech

bleve - Go言語製の全文検索エンジン

興味深い。ストレージはVoltDBを使う模様。

事業を支える技術選定 / Engineering Decision Making Process For Business

NULL嫌いのUPDATEしないDB設計 #DBSekkeiNight

NULL撲滅委員会の会員による発表

DXに関する私的な殴り書き

マイクロアドのログ蓄積の流れ

セガ、ゲームセンターをクラウドとして転用する「フォグゲーミング」を研究開発中

「フォグゲーミング」とは、全国のゲームセンターをクラウドとして転用するという構想。ゲームセンターに設置されているゲーム機のCPU/GPUを転用することにより、コストダウンと低遅延を実現。プレイヤーは高品位なゲームを楽しむことができ、ゲームセンターは営業時間外でもお金を稼ぐことができるとのことです。この「フォグゲーミング」は、フォグコンピューティング (*) に近い発想であると説明されています。なお、現在稼働しているゲーム機を転用するのは難しい模様です。

※フォグコンピューティングとは:ネットワーク環境の中で、データがクラウドに行く前、端末に近い場所でのミドルウェアによる分散処理環境。大量のデータをインターネットを通じて送信する前に処理することで、上位システムやクラウドへの負担集中を回避することを目的とする。

興味深い

タスクランナーをmakeからcargo-makeへ移行

Rust製のタスクランナーであるcargo-makeの紹介。

確かにこれはお手軽かつポータビリティ高そうでいい感じ。

Kubernetes、やめました

自分用メモ: ウェブ設計チェックリスト

GitHub Flow (Japanese translation)

GitHub Flowの説明

develop ブランチなんてオワコン

github flowはdevelopブランチを切らない方針なのか。

まぁ確かに。

git の develop ブランチは必要なのか、またはリリースtagについて

確かにここ数年、developブランチ本当に必要なのか? と思うことが増えた。

リリースタグでリリースを管理するなら、別にmasterがどんどん更新されてもいいわけだし、ある程度大きめの開発なら個別にリリースブランチを作ればいいって事になりがち。

すると、developの存在価値は...? みたいになる。

テストケースをまとめて固めて「テストカタマリー」

ソフトウェアテストについて考える

Infrastructure as Codeにおける理想のドキュメント管理を目指して #infrastudy

プログラマーの仕事を始めてすぐ、多くのプログラマーが僕よりずっと酷いコードを書くことを知り、

プログラマーの仕事を始めてすぐ、多くのプログラマーが僕よりずっと酷いコードを書くことを知り、この業界で生きていく自信がついたが、今は多くのプログラマーが僕よりずっと酷いコードを書くなかでプロジェクトを成功させなくてはいけないことを知り、この業界で生きていく自信がなくなり始めた。

@tannakaken

一緒に働く人間は本当に重要

Castjs - Chromecast Sender APIライブラリ

ふむ

ソフトウェアテストを勉強して設計やマネジメントが上手になった話 #iijlab_seminar

プログラマにできるとよさそうなこと

ここまでできるようになるのに、概ね10年は見ておく必要がある

データマネジメントなきMLは、破綻する。

RootlessモードでDockerをより安全にする [DockerCon発表レポート]

NTT須田氏のRoorlessモードDockerについての発表

あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない?

ドメインロジックのモデリングと実装

Tag:

要件定義・仕様化・実装の継ぎ目をなくすCCSR開発手法

優れたソフトウェア開発チームが持つ共通点とは?

ソフトウェア開発チーム、イキリエンジニアが1人いるだけで崩壊するのが悩みの種である

面接とかでPython詳しいですか?とかいわれることあるから、「OOPの言語てだいたい同じだし〜

面接とかでPython詳しいですか?とかいわれることあるから、「OOPの言語てだいたい同じだし、Pythonの仕様にちょっと疑問ある部分もありますが、自分でPythonをゼロから作れって言われたら作れます。」って言ってる。

??って反応になるときもあるけど、言語設計開発で博士とってるのに聞くなと思う

@hncgu

博士号が重要視されない社会の現実

2020年5月におけるPython開発環境の選択肢

Pipenvクソ重いし、別の方法も考えるかな...

beekeeper-studio

クロスプラットフォームなRDB管理ツール

Google社のテクニカルライティングの基礎教育資料がとても良かったので紹介したい

モダンなシステムにSLI/SLOを設定するときのベストプラクティス

Security / AuditabilityをSREチームの成果指標に加えた話

Tag:

「OpenSSH 8.0/8.0p」リリース、scpプロトコルに関連した脆弱性を修正

なお開発チームはscpプロトコルは時代遅れで柔軟性がなく、修正が容易ではないとし、sftpやrsyncなどを使ってファイル転送することを奨励している。

ふーむ

MySQLの物理削除によるパフォーマンスの悪化とその回避策について

大規模に物理DELETEを行うと統計情報が想定と異なる状態になる事があります。そのような際には OPTIMIZE TABLE を実行し、テーブルを再構築する事で一定の効果が得られます。

また、将来的には大量の物理DELETEを行わなくて済むような設計をするのが良いと思います。

やはり論理削除は禁止して、削除は物理削除&削除済みデータテーブルへINSERT+メッセージキューで負荷を調整みたいな戦略がいいのだろうか?

SLI, SLOとカオスエンジニアリング、そしてオブザーバビリティ SRE Lounge #12

Tag:

システム境界が実態とそぐわない時、システムは複雑化してしまう

RDRA支援で様々なシステムを見ていて思うことがある

システムを複雑化させる要因の一つに、システム境界が実態とそぐわないことがある

システムの単位が開発プロジェクトの単位で決まり、そのプロジェクトの制約(納期や予算)からシステムスコープが制約され、システム間のインターフェースが決まる

@zenzengood

あるビジネスルールが複数のシステムにまたがる場合、システム間の連携が必要になるたびに条件や情報が重複して実装される。

さらにシステムが分かれることで不要な手処理が発生する

特に近年は納期の要求がきつく、間に合わなければ手処理で対応ということが多く、複雑さに拍車がかかっている

@zenzengood

システムスコープの見直しを実装から考えていくと袋小路に入る、なぜならば実現可能な局所的な判断になるからである

システムの関係を見直すにはそのサービスや会社の特性を広く俯瞰して理解していないといけない

システムの拡張や変更はその会社・サービスの特性から発生するからである。

@zenzengood

では会社やサービスの特性をどのように可視化するかというと、ビジネス要素とバリエーション(RDRA用語)を俯瞰することである。

つまり、ビジネスルールの元になるビジネス要素とバリエーションは、ビジネス上のパラメータになっており、ビジネスはこのパラメータの組み合わせを変えながら進化する

@zenzengood

ビジネスパラメータが俯瞰できると会社やサービスの特性が見える

現場はそれらのバリエーション個々の存在は認識しているが、俯瞰できずシステム機能として複雑さだけが見え、複雑なビジネスルールが存在しているように見えている

結果として複雑なビジネスロジックを生み出している

@zenzengood

ビジネスパラメータが明確になるとシステムの変化の範囲も見えてくる。さらに会社やサービスの特性が見えてくることで、ビジネスパラメータそのものを拡張する関心事が分かる

システムの単位を考える時に、対象の機能やサービスが将来拡張される部分か否かが見通せ、より適切なシステムの単位が見える

@zenzengood

2年半のエンジニアリングマネジャー経験から学んだこと

CPU律速なRuby/Pythonコードはデフォルト設定のdocker上で遅くなる

まじか...

DBプラットフォームの変遷 - ベアメタル、VM、そしてコンテナへ

Tag

Scheduling Profile が実現する Pod 配置戦略の最前線 #InfraStudy

Tag

全てがクラウドネイティブで良いのか。その謎を明らかにすべく我々はエンプラの奥地に向かった

Tag

Cloud Native Development Design Patterns

Tag

IaCにおける理想のドキュメント管理を目指す

Tag

プログラミングスクールを卒業したゴミを面接した結果

だから少しきつい言い方をすると趣味で英会話教室や料理教室に通ったくらいのレベル感だったのでお断りをしました。

ただ、激詰めしたりとかしたいわけではなかったのでこういうこともお伝えしました。

1. 人間性を否定しているわけではないですよ。努力はしていると思うしそもそも向上心がなければ高いお金を払ってスクールにすら行っていないでしょう。

2. お金を実際に払って仕事を依頼する立場に立って言うと実務が伴わなければ技術に価値はありません。正直現実はものすごく厳しいです。

3. ポートフォリオとしてコピペとか課題を出すのはさすがにまずいです。

4. 具体的にフリーランスだったらこれくらいは自分でできないといけないです。

5. 制作会社は未経験でも雇うところはあるけれども自分で調べて解決する力が必要です。

6. スクールを卒業してもその程度のレベル感であればあえてプログラマーを目指すよりはもっと自分にとって適性のある仕事を探したほうが幸せになれる可能性が高いです。

言葉遣いは荒いけど、実際プログラミングスクール上がりの人々のレベルは結構閉口するものがあるので、まぁ...

とはいえ、面接でお説教はちょっとイキリ過ぎている。

どうして未経験者はそんなにWebエンジニアにこだわるんだい?

■わけがわからないよ。

ここ数年で全く関係ない業種から、Webエンジニアになりたい人がかなり増えてるけど、わけがわからないよ。

どうして、君たちはWebエンジニアにそんなに魅力を感じるんだい?ぼくはWebエンジニアをしてるけど、そこまでこだわる理由がわからないよ。

自由な働き方ができて、給料も高く、ストレスフリーで働けるって思いこんでるみたいだけど、そんなのは怪しいインフルエンサーやプログラミングスクールの宣伝文句に過ぎないさ。

解説するよ。よく読んで!

■そんな…あんまりだよ、夜間メンテナンスや緊急対応があるって、こんなのってないよ!

君たちはソシャゲがメンテナンスになったときに、文句を言ってるけど、

君たちがなりたいWebエンジニアが、メンテナンス中に何をしているか想像したことがあるかい?

メンテナンス中、彼らはプレッシャーに耐えながら必死で働いているんだ。ユーザーのために、早くサービスを再開しようとして。

システムに問題が発生したら、深夜や休日でも関係ないよ。技術者として自分が作ったシステムに対して責任があるんだ。

それでも君は、自由で好きな時間だけ働けると思うのかい?

■なんで、Webエンジニアになったら高給になれると思ったんだい?

わけがわからないよ。君は国内のインターネット産業の動向や経済ニュースをチェックしてるのかい?

未経験からWebエンジニアになってキャリアを積み上げて、今は高給を得ている人も確かにいるけど、それは時代が良かった部分もあると思うんだ。今まで国内のWeb業界は爆発的な成長を遂げていたからね。インターネット人口がどんどん増えていたから、何もしなくても成長できたのさ。

でも、これからはどうだろう?ほとんどの人がスマートフォンを持って、インターネット人口がカンストしている日本で、これからもWeb業界の成長が維持できると思うのかい?

給料っていうのは、ポジションによって決まるんだよ。業界が成長している間は、給料が良くておいしいポジションが増えるけど、成長しなかったら良いポジションは増えないさ。そうなったら良いポジションを得るには席を他の人から奪うしかなくなるね。君は良いポジションのために、ベテランWebエンジニアと戦う覚悟があるのかい?

そもそも、今のインターネット産業は完全にバブルになっているんだ。これがどういうことだかわかるかい?

数年前からWebエンジニアの給料が高騰してるけど、これは金融市場や大企業から多額の出資をうけたベンチャー企業が、相場よりも高い金額でWebエンジニアを雇っていることが一因になっているんだ。不安定で知名度のない会社がいい人を雇うには金を積むしかないからね。

でも、今の世界経済の混乱の中で、ベンチャー企業に出資したいと思う人がどれだけいるかな。出資する人がいなくなったらバブルが崩壊するね。そうなったら、数多くのWebエンジニアが職を失うことになるんだ。

そうなったら、僕もWeb業界から淘汰される可能性もある。替わりはいくらでもいるからね!

■あるよ。エンジニアにも、たくさん種類が、あるんだよ。

なんで君はエンジニアを志しているんだい?ものづくりをしたいから?手に職をつけたいから?プログラミングがしたいから?

じゃあ、Web以外の分野でもいいんじゃないかな?

エンジニアの中でも機械設計や電気回路、素材、建築など様々な分野があるんだ。

あまり知られてないけど、それらの分野も未経験からエンジニアになる方法はあるんだ。例を挙げると、未経験者OKのCADオペレーターの派遣とかがあるね。最初はほとんど派遣からスタートにはなるし、キャリアアップには若さが重要になるけど。

プログラミングがしたかったら、組み込みエンジニアという職種もある。あと、SEも選択肢にいれていいと思う。どうして君はSIerが全部クソと決めつけるんだい?そんなの会社や部署によるさ。それはWeb業界も同じだね。

■今までのキャリアを粗末にするんじゃねえ、〇すぞ。

そもそもどうして今の仕事を辞めてまで、Webエンジニアになろうとするんだい?

なぜ今の仕事に、真剣に向き合わないんだい?

隣の芝が青く見えているだけではないかい?

Web業界なら、青い鳥がいると勘違いしてはいないかい?

未経験の分野に行くよりも、今まで経験があるところで勝負したほうが有利なのは自明だよね。

■僕と契約して

そんなこと長々と言われても、これからどうすればいいかわからないって? 

そんなの簡単さ。

僕と契約して今すぐQBプログラミングスクールとQBサロンに入るんだ!!

「VM 時代の開発とKubernetes による Cloud Native な開発のこれから」

Tag

golang-migrateでDBマイグレーション

マイグレーションツールはフレームワークから独立していて欲しさあるのと、DSLではなくSQLでなんとかしたさがあるので、これはよいかも。

デザインドックで学ぶデザインドック

パッケージソフトウェアの新機能開発で Design Doc を書いてみた

Googleのデザインドックのマークダウンサンプルらしい

ふーむ

BlackSheep - Python製のノンブロッキングWEBアプリケーションフレームワーク

イベントベースのノンブロッキングIOなWEBアプリケーションフレームワーク

一通りの機能は揃ってるぽい。

個人的にはsanicでいいかなという感じ。

Architecture Decision Records導入事例

ADRを実際に導入した事例紹介。

フォーマットについてはそこまで厳格に決める必要はないかなと思う。

DXとかDevOpsとかのなんかいい感じのやつ

Tag:

「社員はコードを書いてはいけない、派遣に書かせればいい。社員は定期人事で二年後に異動に...」

自分の中での最高のクソエンジニア発言はこれです。

「社員はコードを書いてはいけない、派遣に書かせればいい。社員は定期人事で二年後に異動になるから、保守ができなくなる。それよりもどんな部署でも使える仕様書を書く技術を身につけるべきだ」

@tokoroten

これの解説をいい加減書いておくと

・コード書けないやつに設計させるのは無謀

・コード書く能力はどこの部署でも役に立つ

・devopsが機能していないので、保守ができない開発環境である

・派遣に任せたからといって、保守ができるわけではない

・会社の制度を疑わないのが最高に頭悪い

@tokoroten

asim/git-http-backend - Go-lang製のGit HTTPバックエンド

GitリポジトリをHTTP/HTTPSで公開できるようにしてくれるAPサーバ的なもの。

Gitには同様のCGIプログラムが同梱されているけれど、それをGo言語で再実装したことでパフォーマンスが向上しているのだとか。

自分のサーバでリポジトリを公開する時に便利そう。

Istioがマイクロサービスからモノリシックなアプリに変化。その背景とは

Goaを使ってAPIサーバ開発してみた

Goとクリーンアーキテクチャ DMM.go#2

データ基盤のメタデータを継続的に管理できる仕組みを作る(ペパボ編)

Site Reliability を向上するためにやったことすべて

レガシーシステムからのデータマイグレーションあれこれ

魔法のiランド懐かしい

ドメイン駆動設計における「良いモデル」と「悪いモデル」とは

仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編

スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた

Creating Documentation in an Agile Scrum Environment

【スライド約300枚】ベンチャーマネージャーのマニュアル

しゅごい

自分がコードレビューで気をつけていること(2020.5 iOSアプリ開発版 )

melonJS

ふーむ

Phaser - JavaScript/HTML5ゲーム作成フレームワーク

ふーむ

ROIを気にするべきは、人事制度など、始めたら戻れない「不可逆的なもの」だけ

IT系で自社サービスつくってる会社で上司が「ROIは?」って連呼し始めたら要注意。製造業と違って"試すことのコスト"が極端に低いから「ROIをいちいち計算して説明する」ことがむしろROIを悪化させてる事に気づいてない。ROIを気にするべきは、人事制度など、始めたら戻れない「不可逆的なもの」だけ。

@tairo

なるほど

オープンソースのベクター画像編集ソフト「Inkscape 1.0」リリース

おっ、Inkscapeが1.0になった

受け入れ基準の設定時などに役立つプラクティス「Example Mapping」を翻訳したので紹介します

単体テストが書きにくい=もとがクソコード理論

単体テストが書きにくい=もとがクソコード理論。ほとんどの場合であってる。

@voluntas

悲しい現実

PyPika - Python Query Builder

クエリビルダーそのものとしてはこんなプロダクトもあった。

APIはこちらの方が好みかな。

とりあえず使えそうな SQLAlchemy 入門(※ ORM機能は使いません)

そういえばSQLAlchemyにはクエリビルダー機能があったんだった

退職エントリ ~独立系SI企業からユーザ系企業に移るまで(裏編)

つらい

動的解析を利用し、実働6日でレガシーコードを1/3削った話(Perl編)

LinuxコミュニティはRustを受け入れた

Rustはこういった事情から、Linuxコミュニティに受け入れ始められた。私は、将来的に、Linuxに関するツールのすべてはRustで書かれるものと確信した。PerlもPythonも、駆逐される。LVMもRustでrewriteされるに違いない。

ほんまか...?

CSSにおける汎用化の先送り、ユーティリティファーストCSS、レイアウトプリミティブ

個人的な経験則として、レイアウトプリミティブのパターンは実際にかなり多くのレイアウトの実装に適用できる。それぞれのパターンをクラスとして再利用できるようにしておくと、結果的にCSSの総量をかなり削減できる。つまりはCSSを書く場面が減り、新しく作らなければならないコンポーネントや要素の数が減り、命名の機会が減る。もちろん共通化はテンプレートエンジンで行える。

パターンの収集という意味でレイアウトプリミティブは絶妙である。ウェブデザインの中で無意識的に繰り返されていたようなレイアウトの手法を拾い上げ、極めて汎用的な形式知に変換することによって、思いもしなかった抽象化の可能性が提示されたように感じた。OOCSSの原則であった「構造とスキンの分離」は、ページからそのパターンを発見する困難さゆえに機能しなかった。大袈裟かもしれないが、レイアウトプリミティブはウェブデザインの普遍的なパターンに思える。設計を進めていく最中でパターンを発見していくのには無理があり、あらかじめわかっているパターンを拠り所にできる方が間違いがないだろう。(レスポンシブデザインという制約が昨今のレイアウト規則を画一化した結果とも言えるかもしれない。)

2020年度 ミクシィ新卒研修 -設計・テスト

プロプライエタリな製品特有の機能を誰も使用していないので、もうそれは一般的なお金のかからない...

お客様から

「(例)今回Linux使うって御社言うけど、Java・Tomcat上のWEBアプリケーションをHP-UXではなくてLinuxで動かすメリットってなに?」くらいの一般的なざっくり質問が来て自分なりの答えをつらつら書くの巻

@nfujita55a

上はあくまで例ですが、プロプライエタリな製品特有の機能を誰も使用していないので、もうそれは一般的なお金のからないものにしようよ、が回答の基本線。

@nfujita55a

ベンダー「新規開発プロジェクトで予算も余裕あるだろうし、ふっかけとくか」

プロジェクト当初の意思決定者「まぁ、予算も余裕あるし保険的な意味で採用しとくか」

現場「マニュアルわかりづらいし、ネットに情報ないし、サポートのレスポンスも遅いし、そもそも使わなくてもなんとかなるから使わんとこ...」

みたいな流れよくある

OSSはたくさんのユーザの目によってバグレポートが出され、直され、品質が上がっていく(こともある)

OSSは

- 世界中の人によって開発される(こともある)

- たくさんのユーザの目によってバグレポートが出され、直され、品質が上がっていく(こともある)

- メンテナが辞めても別の有志によって開発は継続する(こともある)

- 問題があってもすぐに自分で修正できる(こともある)

@satoru_takeuchi

はい

メインフレーム、無停止サーバ、クラウドにおける信頼性

メインフレームの異常処理

自称コンサル「クラウドのコンサルできます」

自称コンサル「クラウドのコンサルできます」

私「ほう・・・」

ーーー

現場

コンサル「どのクラウド使いますか?PaaS/SaaSの利用ありますか?サーバのサイズは?OSは?そこを決めてもらわないと費用算出できません!」

客「」

ーーー

私「それコンサルじゃねーよ。単なるお見積もりだ」

@ixl_jp

こういうの本当にあるから困る

ゲーム開発プロジェクトマネジメント講座

プロジェクトの初期に立てた計画は最終的にどれほどの誤差を生むのでしょうか?

まさかの当初計画比10倍という無茶苦茶な数値が出てきました

対処5

月の労働時間を160時間から290時間にする

会話の中にも、コードの中にも、画面にも、データベース定義にも、あらゆるところに存在する言葉

ユビキタスとは、至る所に存在するという意味。

この語感が、カタカナからは全く伝わらない。

会話の中にも、コードの中にも、画面にも、データベース定義にも、あらゆるところに存在する言葉。

そういう感覚が理解できると、ユビキタス言語という言葉にこめたエヴァンスの意図が理解できる。

@masuda220

ユビキタスという単語が全て悪い気がするので、改めてしっくりくる日本語を当てるべきだと思うんよな。

できれば四字熟語が望ましい。

個人的かつ暫定的には「概念要素」がよいと思ってる。

ちなみに「概念要素」から構築される概念の集合体は「概念構造体」と呼称したい(モデルとほぼ同義)。

バニラアイスを買った時だけ始動しなくなる車の話。あるいはデバッグとは斯くあるべしのこと

これはゼネラルモーターズの顧客と同社の顧客担当職員の間で実際に起きた話です。苦情はゼネラルモーターズのポンティアック部門に寄せられました:

“これは貴社宛ての二度目の手紙です。今までご返事を頂かなかったことを責めるつもりはありません。なぜなら私自身その内容がクレージーであると感じているからです。しかし私の家庭では毎晩食後のデザートにアイスクリームを食べる習慣があり、どの種類のアイスクリームにするか家族全員で投票で決め、私が車で店に買いに出掛けます。また私は最近ポンティアックの新車を購入ましましたが、問題はそれ以来私が店に行く度に起きていたのです。つまり私がバニラアイスクリームを買うたび、店から戻ると車が始動しないのです。一方他の種類のアイスクリームの時は車は上手く始動するのです。私がこの問題を深刻に受け止めているということを、たとえばかげたもののように見えても、貴社に是非知ってもらいたいのです:”

“ 私が他の種類のアイスクリームを買うときは上手く始動するのに、バニラアイスクリームを買うときに限って車が始動しないのはポンティアックに何か問題があるのか?“

さて、技術者にとっての問題はなぜ車は短時間だと始動しないかということでした。バニラアイスクリームではなく、時間に問題あり!!!!  技術者はすぐさま答えを導き出しました。“ベーパーロック(Vapor lock)”それは毎晩起きていたのです。しかし他の種類のアイスクリームを買うときに余計に掛かっていた時間が車のエンジンをクールダウンさせ、これが車の始動に有効に作用していたのです。バニラのときは時間が短く、エンジンはベーパーロックを解消するまでには至らなかったのです。

そのタイミングで投入することに対する経済合理性が無い納期は納期じゃねぇんだよ

そのタイミングで投入することに対する経済合理性が無い納期は納期じゃねぇんだよ。

@effy_staffs

一理ある

プロダクトの成功に必要な 3 つのステージと 20 のタスクについて:現場の動き方をまとめました

Clean Architecture の勘所は『鎖国』だ。

ふと クリーンアーキテクチャは『鎖国』に例えると分かりやすい という事に気が付きました。

超絶ざっくり言うと、クリーンアーキテクチャとは、

鎖国して、出島でのみ外界と貿易することで、国内をきれいに保つための『方法論』 です。

貿易を出島でのみに制限する ことで、列強諸国から 国宝のビジネスロジックを守る のです。

ドメインを大切にする DDD 的な考え方ですね。

実際に原著を読んでも、外から内への処理を抽象化する理由はほとんど描かれていません。

さらっと『外から内でも DIP 適用しようね。』くらいのノリで書かれています。

内から外は NG だから DIP 適用しろよって記述は沢山あるんですけどね。

おそらく内から外 だけではなく、外から内 のやりとりも抽象化する。

すなわち「全ての階層間のやりとりを相互方向に抽象化する」 ことで 究極にクリーンになるよ、って事でなんでしょう。

JSON Web Token (JWT) の 仕様 と 使い方

署名のアルゴリズムにNone使うのを禁止しておけばとりあえず改竄は防げるのでは?(そもそも何でNoneが設定できるんだろうか)

ネットワーク構成図を考える: NW図の基本とモデル指向NW図のススメ

Tag:

さくらのVPSを支える技術とこれから

現在はお名前コムVPSを利用しているのだが、どうもこのサービス放置されている気配がある[1]ので、別のVPSに脱出するべきか検討しているところではある。

候補に上がるのはConohaかさくらVPSなのだけど、どちらもランニングコストが多少とは言え上昇するので微妙に気が進まず腰を上げられずにいる。

かと言って海外のVPSサービスというのもちょっとなぁ...という。

脚注:

Tag:

今さら聞けないKubernetesと軽量Kubernetes環境K3s

Tag:

最近は内部状態を変化させない不変(immutable)な設計が当たり前になってきている

オブジェクト指向設計は、型によるモジュール化が本質。手続きによるモジュール化とは基本の発想が異なる。

かつてのオブジェクト指向プログラミングは、内部状態を変化させる設計が多かったが、最近は内部状態を変化させない不変(immutable)な設計が当たり前になってきている。

@masuda220

不変大事

現場で遭遇するかも知れない、こんなプログラマ達

1. ガンダルフ

指輪物語のガンダルフのような風体をしていて、コードの世界において魔法が使える。 細かくどうでも良い事を議論するのが大好きという欠点はあるが、絶望を救うものとしてチームにキープしたい人材。

2. 殉教者

仕事中毒。 家では風呂と寝るだけ。 会社で寝ることにプライドを持っている。

3. マニア少年

語りだしたら止まらない。 ドラゴンボールZとガンダムWの違いについて熱く語る。 何故プレステ3がXBox360より優れているのかを熱く語る。 多くのものが日本からの輸入。 職場が趣味で占拠されている。 そして、仕事中も趣味の事を考えている。

4. ビンスニール(Vince Neil)

ロックンロール野郎(女性の場合もあり)。 長髪、破けたジーンズ。 会社でBon JoviやDef Leppardを口ずさむ。 (Motley CrueとかGunsじゃないのか???と思いました。。。)

人間的には楽しい事が多い。 ひたすら二日酔いなのは勘弁して欲しい。

5. 忍者

隠密行動。 チームのMVPであるが誰もそれを知らない。 朝、バージョン管理システムでupdateをしてみて始めて忍者が働いていた事に気が付く。

忍者が入っているプロジェクトは何故かうまく行く場合が多い。 ただし、忍者は孤高の戦士であるため皆と同じような業務形態を強いてはいけない。

6. 理論家

プログラミングに関しては何でも知っている。 プログラミング言語の歴史に関して4時間語ってくれる。 最適化によって3ナノ秒高速化できることを誇ってくれる。

でも、問題は理論家が実際の開発現場を知らない事である。 しかも、生成されるコードはあまりに「エレガント」過ぎて凡人には理解できない。

数時間で出来る作業も、ツールがエレガントではないという理由で作り直してしまって3ヶ月かかる。 うまくプロジェクトの範囲内に興味の対象を持たせるようにハンドルできれば、理論家は最強のメンバーになる。

7. コードカウボーイ(The Code Cowboy)

コードカーボーイの本能は静止不可能。 大抵は凄いプログラマで、通常の2~3倍の速度でコードが書ける。 ただ、テストやチェックが大嫌い。

コードカウボーイのコードはスパゲッティ状態。 生成速度に対して最適化した書き方をしたから。

コードカウボーイを締め切りが最重要であるプロジェクトに放り込めば、プロジェクトは期限内に終わる。 コードカウボーイは忍者のうるさいバージョンであり、目の前にあるものをなぎ倒しながら突進していく。

8. 落下傘部隊

氏にかけているプロジェクトを救うために投入される最後の希望。 長期のコード開発には向かないが、状況を素早く判断して適応する能力はピカイチ。 コードのコア部分を本当の意味で全部理解はしていないかも知れないが、通常では成功しない状況でも何とかしてくれるかも知れない。

9. 二流エンジニア

「まあ、許せる」品質以上のものを生成することはない。 雇用を続けるのも「まあ、許せる」という理由。

雇用面接を行うときに、このタイプの人はどんなプロジェクトにいたかを良く語ってくれる。 しかし、そこで何を担当したかを聞いた途端に話ができなくなる。 組織にそのような人間を招き入れると、出て行って頂くのに数年かかる。

10. エバンジェリスト

エバンジェリストは、どのような環境であったとしても、今の環境を全て捨てて新しいものにすべきであると主張する。 エバンジェリストは理論家の真逆。 ソフトウェア開発の事は恐ろしく良く知っているが実際のコード書きはあまりしない。

エバンジェリストは心の中ではプロジェクトマネージャであるが、まだ昇進できていない。 そのため、その他のメンバーが意図を汲んであげなければならない。

ろくな人間がいなくて草

RustでDDD

Istio Overview

Goのアーキテクチャとフレームワークについて

ちなみに、他人のおすすめを真に受けて脳死状態でフレームワークとアーキテクチャを決めると、 開発や運用を通じて発生した問題に対する最適な解決策を考えることができなくなる可能性がある。 なぜかというと「技術選定時は xxx という理由で xxx を選択したが、今は yyy が問題になっているので技術選定時の xxx という前提が間違っていた可能性がある。なので、xxx ではなく zzz という方針に切り替えよう」という考え方ができないからである。 やはりアプリケーションアーキテクチャにおいて思想や方向性といったものは重要である。 相談する相手の回答はそれっぽく聞こえるかもしれないが、ちゃんと自分でも考えるのが重要である。

はい

Infrastructure As Codeでモジュール化が難しいのはなぜなのか

過剰に共通化を目指しちゃう問題。

若気の至りでやってしまって後悔するやつだ。

NEXT