/note/tech

PDM - PEP 582対応のパッケージマネージャ

また新しいパッケージマネージャが出てきたんですか...いい加減標準を決めて欲しいものであるが

dev.toのServiceクラスについてDDDとPofEAAを読んで考察してみた

個人的にはServiceクラスの役割は↓の認識。

「Domain Layerとクライアントの間のインターフェースの役割」

Clean Architectureみたいにアプリケーションサービスとユースケースサービスで分割するのは過剰かなと思っている。

CQRSとか言った時点でイベントソージングとかいうシステム担保された即時整合性の敵を受け入れるわけで...

CQRSとか言った時点でイベントソージングとかいうシステム担保された即時整合性の敵を受け入れるわけで、エヴァンスさんは「いまどきCQRSとかマイクロサービスとか考えないのありえん」ってすでに8年ぐらい前に言ってた気がする

@tanakahisateru

割り切るとこは割り切ってやっとけ。絶対担保せなあかんとこなんて、かなり密な構造しとるはずやぞ。切るか切らんか顧客と話し合ってええモデルの割り方考えるんやで。互いに理解できる共通語大事やろ ← 本質的にはここまで

@tanakahisateru

RDBMSのトランザクション機構による整合性の担保を手放すのもツラいけど、何よりバグやトラブルで更新が失敗した場合、どこからやり直さなきゃならないか考えるポイントが増えるのがツラいというのがある。

更新失敗はスパッと再投入でヨシ! とするべきか、途中の成功しているデータは保持したまま失敗地点からやり直すか? そもそもリラン機構をどう実装するか? と考えることが増えていくから無闇に採用するのを躊躇うところはある。

SRE を成功させるには、まず計画を立てることが大事

プロダクトに関することを全部やる。それが、プロダクトマネージャー

技術的負債とステークホルダと説明責任と

日本語処理にも革命!?分かち書きをせず高品質な事前学習を実現する CANINE がすごい

要注目だな

一括請負契約はソフトウェア開発にやっぱり向いていない

手続き型主流のプログラマにとって手続き型が金稼ぎの手段なわけで、そこにオブジェクト指向を持ってくると...

手続き型主流のプログラマにとって手続き型が金稼ぎの手段なわけで、そこにオブジェクト指向を持ってくると「なんでそんな意味不明なプログラミング技法を持ってくるんだ!?俺の金稼ぎの邪魔をしたいのか!?!?」ってな感じで、当時俺に対する異常な敵愾心はやっぱ金だったろうなぁ。

@MinoDriven

これは少なからずあったろうなぁとは思うけども。

一方で、当時のオブジェクト指向信奉者の言い分は「そのコードはオブジェクト思考的ではない(からダメ)」みたいな頭キマったヤク中みたいな感じだったから仕方ない面もある。

具体的なメリット/デメリットで語れないとやっぱダメだよねという教訓だけが残った。

これだけ気を付けて書いてもらえるとみんな幸せになるポイント2つだけ

GoFの23のデザインパターンを,Javaで活用するための一覧表 (パターンごとの要約コメント付き)

デザインパターンを読み解く

GoFの23パターンをそのまま解説している本が多く、事細かな制約があるかのように見えるせいか、かえって本質が捉えづらくなっている印象があります。23パターンがすべてではないし、このパターン自体パターンが言われ始めた初期に出されたもので、洗練されていないと思うのです。「○○パターン」と言われると何か特殊なテクニックなのだと考えてしまい、かえって難しくとらえているのではないでしょうか。

正直言って、クラス設計の上位レベルのコンセプトと、コーディングのテクニックをごっちゃにしたような印象があります。

よく、デザインパターンをそのまま適用できないという意見がありますが、それもそのはずで、挙げられているのはクラス構成における一例にすぎません。無理に当てはめて、「このアプリケーションには○○のデザインパターンが使われている」などと自慢するのは意味がないし、細かく分析して「StrategyとStateの違いはこうである」などと研究対象にするのも意味がないと思います。GoFの例に合致していないから効果が薄いと思うのも間違いです。

最初にデザインパターンを知った時は理解できないパターンも多くて、自分のスキルが低いせいかな? と思ってた時もあったものだが、今改めて見ても「いや、これは使い道ないだろ」みたいなのはやっぱりある。

というか、元々Javaの古いバージョンでGUIアプリを作成することを想定している感じから、主にWEBアプリ(API)では使う場面がないパターンが出てくるのは当然ではある(FlyWeightとかChainOfResponsibilityとか)。

そういう観点で改めてデザインパターンの再評価をするのも面白いかもしれない。

Googleが社員のパフォーマンスを調査した所、社員の学歴に相関性はなく「人生でどれだけ苦労したか」が...

Googleが社員のパフォーマンスを調査した所、社員の学歴に相関性はなく「人生でどれだけ苦労したか」が関係していた調査結果が興味深い。挫折は自分自身を見つめ直しアイデンティティを作り直す機会でもある。『どんな失敗も、新たな一歩となる』というエジソンの言葉の本質はここに通じているのかも

@satotin_yusuke

Googleの採用基準の1つに『Googliness』というグーグルらしさを求める指標がある。これは、Googleを自分なりに解釈し情熱的に何かを変えようと好奇心を持っているかという事で、この能力こそ失敗の経験が活きているのではないかと思った。本田圭佑の『失敗して後から失敗を美学にする』を胸に刻みたい

@satotin_yusuke

苦労というか挑戦やリーダーシップの話だと思うんだよな。

分散処理ライブラリRayを使ってシングルプロセスアプリを

ほぅ

「運用組織」の考え方と設計 〜 運用組織論 2021

アーキテクトを目指すエンジニアの最短ルート

今日から始めるPrometheusによるシステム監視

過去のデスマ自慢を肯定的な文脈でやらない方がいいんじゃないかなぁ…という気持ちがあります

過去のデスマ自慢を肯定的な文脈でやらない方がいいんじゃないかなぁ…という気持ちがあります。極限状態に追い込まれることで能力が覚醒するみたいなのは単なる生存バイアスであって創作としては楽しいものですが、現実の世界でそれを振る舞いとして肯定するのは望ましくない。

@ryushi

SESにおけるデスマは基本的に不愉快な時間でしかないし、炎上してるから基本タスク消化優先になるのでプロジェクトを通して得られた知見も大したものではなかった。

そもそもデスマをやらかす会社や現場はそれが常態化しているので、全体的なスキルも低いので学べるものは少ない。

他方、そもそも人数の少ないベンチャーで1から10まで自分が面倒みなきゃいけない状態だと幅広い知見が強制的に身に付くというのは事実で、そうやってスキルを身に付けたという成功体験や成功事例はやっぱりある。

ようこそ、Kubernetes沼へ。商用サービスSREの現場から

サーバーサイドのユースケース、だいたいアプリケーションサービスである

サーバーサイドのユースケース、だいたいアプリケーションサービスである

@a_suenami

まあサーバーサイドエンジニアがユースケースと命名したくなるのはそれがドメインモデルを使用しているからだし、ユーザにとっての(本来の?)ユースケースはもう少しお金の匂いがするというか、マーケティング的な観点が強いような気はしますね。

@a_suenami

めんどくさいからアプリケーションサービスをユースケース(同音異義語)と受け入れてる

@irof

同一視しても実用上目立った害も無いしな。

サーバサイドはAPIを提供するだけみたいな構成では特にそうだ。

SQLを直接書いた方がわかりやすい」と言ってフレームワークのORMを一人だけ使おうとしないベテラ...

プロジェクトの方針としてorm使おうと決めているのに特に断りなくsql使うなら問題だと思います。

また、SQLを直接書いた方が分かりやすいは一定以上書ける人なら間違いなくSQLの方が分かりやすいです。どのデータを取ってくるかを直に書いているイメージになるので。

ただ、勘違いしてはいけないのは別にSQL直書きは遅れている技術でも劣っている技術という訳でも無い事です。

ormは入門レベルのsqlなら書けますが、分析関数や再起クエリ、view、materialzed view、集合の足し算、引き算などはサポートしていません。そのため、大規模な開発やパフォーマンスが求められる部分ではSQL直書きは避けられないでしょう。病院などの大規模なDWHのシステムならSQL使わないとシステム死にますし、下手したら書けません。

よくあるSQL不要論はこれらの開発経験を積んだ事が無い方が仰っている事が多いと見受けられます。

そのプロジェクトがSQLを書いた方が良いものかはこちらでは判断出来ないですが、もし上のケースに当てはまるプロジェクトなら一度見直してみては?

クエリビルダーは使いたいがORMはあんまり使いたくない派

AIと学生に同じ課題でレポートを書かせるとどうなるか--実験結果が公開

全体として、教授の評価は、GPT-3が生成したレポートはやや技術的な印象ではあるが、文法、構文、単語の頻度の点で人間の作文を模倣できたことを示した。ご想像通り、AIのレポート作成にかかった時間は、人間の実験参加者たちよりもはるかに短かった。人間の参加者がレポート完成までにかかった時間は平均で3日間。一方のGPT-3は、3分~20分だった。

EduRefによると「人間による補助なしでも、GPT-3が提出した課題は人間の書いたものとほぼ同じ評価を受けた」という。「GPT-3のレポートに対する教授のコメントの49.2%は文法と構文に関するもので、26.2%は要点と詳細に関するものだった。主張と構成についてのコメントもあったが、それぞれわずか12.3%と10.8%だった。人間のレポート提出者に対するコメントもほぼ同じ割合だった。文法と構文に関するコメントがほぼ50%、要点と詳細に関するものが25.4%、主張に関するものはほぼ13%、構成が10.4%だ」

会社の文化を言語化すると何が起こるのか。Engineering Ladderの作成プロセスとその結果

DBSJ presents 最強データベース講義シリーズ

ASUS Tinker Board 2 入荷

おっ、入荷してた

派遣で行った先々で「ああ俺もコード書きてえなあ」みたいな技術力あるけどポスト的にコード書かせてもらえ...

派遣で行った先々で「ああ俺もコード書きてえなあ」みたいな技術力あるけどポスト的にコード書かせてもらえなくなったおじさん方を幾度となく見た

@ogato_desuyo

大手だとそんなものなのだろうか

リアクティブシステムとCQRS/ESで実現する Chatwork新アーキテクチャについて

Javaでもう一度学び直すオブジェクト指向プログラミングを関数型プログラミングで考え直す 〜第1章〜

ドメイン知識は、容易に失われる

鬼滅の概念モデリング

おもしろい

GCPで構築する、これからの変化に対応出来るデータ分析基盤の作り方

業務システム構築におけるデータモデリング

現代的システム開発概論

React(TypeScript) + Go + Auth0 で実現する管理画面

DDD入門とLaravel

10年放置されたレガシーコードをモダン化する

今年DeNAのMobageは15周年を迎えます。同時にそれを支えてきた技術にも15年の歴史があることになります。サービスを構成しているさまざまな技術は、そのときどきの事情やトレンドによって適切に更新・メンテナンスしながら運用されてきました。

一方でサービスを構成する重要なコンポーネントであるにもかかわらず、多様な理由から長らくメンテナンスもされず、現場から忘れ去られてしまったものも存在します。実際Mobageのサービスのひとつ「アバター」にそのようなコンポーネントがあり、それがあることをきっかけにサービスの存続に関わる問題としてにわかに噴出するということがありました。

そのため該当コンポーネントのコードをアップグレードし、かつ今後は誰でもメンテナンスができるようビルド環境の再整備を行いました。今回はこの実例をもとに、レガシーコードをモダン化した試みを紹介します。

人々の営みだ

business-rules - Python製のルールベースエンジン

なぜルールエンジンを使うのか

ルール駆動開発

ルールベースエンジンを使ったビジネスルールの切り出しとマイクロサービス化。

これはいずれ挑戦してみたいテーマだな。

メルペイxティアフォー 機械学習社会実装のためのシステム開発の話

見てる

マネジメントでやらかして炎上するプロジェクト、例外なく炎上した後に「クソ長い進捗会議」を開くようにして...

マネジメントでやらかして炎上するプロジェクト、例外なく炎上した後に「クソ長い進捗会議」を開くようにして作業時間を削ってさらにトドメを刺しにいくのな。

この現象なんか名前付けれそうだな…

@legendkelbin

マイクロマネジメントに切り替えないと実際の進捗状況が見えないという問題もあったりするからなんとも。

そうなる前に成果物の定義や進捗確認の仕組みを作れなかった時点で手遅れではあるのだが。

転職会議から冪等でないバッチ処理を根絶した話

なるほど。Redisをロックファイル代わりにするのか。

巨大モノリスをKubernetesに移行してシングルクラスタ運用にするためにどうしたか

わーい

pySBD - Python製のテキスト境界検出ライブラリ

ふーむ

ドメイン駆動設計って、なんなら自分でセールスするぐらいフロントマンなみに詳しくなる事だと...

ドメイン駆動設計って、なんなら自分でセールスするぐらいフロントマンなみに詳しくなる事だと思ってる

エヴァンスさんのドメイン駆動設計の語彙に精通することがドメイン駆動だ、ということじゃないよね。むしろそれによってドメインから遠ざかっている人も多いのじゃないか。

@sugimoto_kei

@aileron

まぁドメイン(ビジネス)を知るってそういうことではあるとは思うけども。

一方でシステムとして切り出した「ドメイン」が全てを表現していると錯覚するのはやはり無知故の全能感を感じてしまうな。

1on1ミーティングとは? 人事マネージャーが伝える心得 実践編

妻「データサイエンティストっていう職業があるの?」

妻「データサイエンティストっていう職業があるの?」

僕「あるよ」

妻「あ、昔いた会社にいたかも。何もできない子でね、マーケティングチームに貢献するとか言ってずっとグラフをこねくり回してるの」

@_marony

えぇ...

DevLead by DMM Group #3 〜評価制度・育成編(エンジニア・デザイナー)〜

興味深い話だった

とりあえずゲームプログラムを完成させる上で重要なのは「開発と効率化は別でやる」という点に尽きる

とりあえずゲームプログラムを完成させる上で重要なのは「開発と効率化は別でやる」という点に尽きる

どれだけ処理が似ていようが、完成するまでは決して一纏めにするな。同じ処理を5回でも6回でも書け。関数にしようなどと考えるな

@satetu4401

敵モンスターを作るなら、とりあえず5~6体完成して1シーン通しでプレイできる状態になるまで処理をまとめた関数を作らない事が重要だ

きちんと個性を付けて繊細な調整までやった上で、今後もずっと使って行くことが決まったものだけ纏めればいい

@satetu4401

ゲームプログラムは「手で触りながら繊細に調整する」必要がある

細かく調整しているうちに、同じ処理だった部分が微妙に変化して、結局まとめられなくなるのは珍しい事ではないし、それに「こいつだけ別の処理」が頻繁に発生する

@satetu4401

敵キャラを50種類作る場合「同じ文章を50回書くのを1回にするだけでいい」という効率化よりも

「共通の処理の中に1体のためだけに特別な処理を入れる」を何度も繰り返す方がコストが嵩むことが多い

@satetu4401

ゲームプログラミングに限らず、WEBアプリケーションにも当てはまる。

ちょっと似ているからといって脳死して共通化したがるプログラマはいるけど、大体共通部分がIF文の嵐になって手が付けられなくなるし、そもそも規模がそこまで大きくないので愚直に記述した方がマシだったということは多い。

とはいえ、そこを上手くまとめてみせるのがプログラマの腕の見せ所でもあるというのは否定はしない。

みずほ銀行ばかり障害を起こす理由

直接の原因は知らないので非エンジニア向けの戯言、はいはい嘘松程度に聞き流してくれ。

タイトルは釣りみたいなもんだ。データも客観的な観測もない。本当の理由なんて外部からわかるはずがない。

単に一個人が中の人らに酒を注がれつつグチられた内容の総集編だ。

前提として、社会インフラ系のIT基盤は設計や運用に企業体質が出やすい。

わかりやすいのはSuicaとかで、ハードウェアのFelicaこそソニーの技術だが、Suicaのシステムアーキテクチャは完全に鉄道屋のそれだ。

アプリやWebなんぞは使い勝手がイマイチだが、Suica自体のシステムダウンで首都圏の自動改札が全滅、復旧するまで使えませーん、なんて事態は聞いたことがないだろう。

安全が全てに優先する。

そういう作りにしてあるのだ。

じゃあみずほ銀行はどうなってるかというと、とりあえず止めない、安定運用できたら3社統合の負債を返そうとする、それだけで精一杯だ。

銀行屋のロジックで生きてるから、抜本的な改善はかなり難しい。

MHIR(みずほ情報総研)が大体開発にあたるわけだが、ここでの評価はほぼ銀行の出世と一緒。

入社前の面接の時点で出世コースを見出された賢い社員は、有力な派閥の上司の元で可愛がってもらい、成功すれば出世する小さな案件をあてがってもらう。

あまり大きい案件はリスクが大きい上、成功すると目をつけられる恐れがあるからだ。

そこで卒なくこなした奴が同期より少し上に行く。

年次にあわせて適切なサイズ・リスクの案件をもらい、統括し、出世する。

リスクの高い案件は技術知識だけで政治力のないはねっかえりにでもくれておけばいい。

そう、半沢直樹で見た世界だ。

こんな環境で誰が「抜本的な改善のため落ちにくい安定したシステムアーキテクチャを検討しましょう」なんて言う?

コストは?要員は?リスクは?KPIは?

それで何のリターンが得られる?

「とりあえず動いてる」「止まったら運用のせい」「何日でも詰めさせて復旧すればいい」のに?

第一、そんなことを言える奴は出世欲がない。

出世してないから権限も予算もない。

改善チームとかやってみるけど体裁だけだ。

詰んでるんだよ。組織として。

中の奴らがどう思ってるか知ってるか?

「確かにうちもひどいが他所も対して変わらねえよ」

下手な正義感振りかざしても何も変わらないからな。正しい学習性無気力だ。

そこそこ給料がいい分、このご時世では家族がいる奴はなおさらリスク取れないしな。

まあ、3社統合の時点でシステム屋が本体の建前と開発の実際との整合性が取れず、結果として歴史に残る大失敗から始まってるようなところだ。

マトモになるには時間がかかるだろう。

20年やそこらで企業体質は変わらないからな。

ほかの銀行がここまでやらかさない理由もわからん。

中の人やOBさんよ、「ホントのところ」をバレない程度にちょろっと教えてくれるの待ってるからな。

他社の中の人も「うちもひどい」「ここはまだマシ」とかあるだろ?

データ移行で発生したみずほ銀行のシステム障害についてまとめてみた

動かないコンピュータで散々イジられるのはかわいそうな気もするけど、まぁしゃーない

某国立病院のITエンジニア職を辞めることにした

■はじめに

予め伝えておくが、身バレ防止に、多少だがフェイクを織り交ぜた内容になっている。

そして、そのフェイクも他の医療機関(国立と名の付くどこか)での実際の出来事を複数織り交ぜている。

だが、伝えたい実情に偽りはない。

高度な医療を担う国の機関で、エンジニアと組織がこれほど腐っていては、将来性もへったくれもないと思うんだ。

某国立病院は国そのものではない。

だが、公的な組織がシステム構築・運用するとどうなるか、多少でも公にし、何かを考えるきっかけ・ヒントになってほしい。

役所的な仕事の仕方を受け継いでいるはずだと思うから。

ちなみに、次の仕事は、ある大手の企業で新システムの導入支援をすることになった。

私としてはそちらの仕事のほうが面白いし、自分の能力・経験にとってプラスになる。

■自分

  • 主任(電子カルテとか色々)
  • 地方国立大学院卒(情報工学)
  • 前職は大手システムインテグレータで専門はインフラ
  • 在職して3年目

■辞めるきっかけになったもの

■■非効率な業務

  • 指示されるまで(言われなければ)やらない
  • スキルを無視した仕事配分
  • 作業能率は評価対象外
  • 評価制度の形骸化
  • 残業する人が評価される傾向
  • 内部の申請書類多すぎ(しかも原本提出)
  • 未だに認め印必須
  • 委託業者に丸投げして当然という意識
  • ↑故に人が全然育たない
  • 疲弊して退職していく委託業者のエンジニアを何人も見てきたこと
  • 育たなくても知ったこっちゃないという意識
  • 当事者意識の欠落
  • なのに「自分は勝ち組」という意識がなぜかある人多数

■■実務経験の圧倒的な欠如

民間出身者ではなく博士後期課程とか、某大学研究室出身者を無理やりねじ込む事例はよく見る。

専門職も含めて管理職側に実務経験がないか少なすぎるせいで、「なんでこの要員に単純作業ばっかりやらせてるの?」という仕事配分が、頻繁に起こる。

IT技術職なのに技術的な実務経験ゼロだから、スキルを持った人間に何ができるのかが、全然理解できていないらしい。

ゆえに、人を使い潰し、能力を劣化させる仕事ばかりさせる。

作業能率で評価されることもないから、表立って問題にもならない。

変えようと思えば、相当一生懸命、提案しないと話は聞き入れられない。だが、大体、そこで疲弊する。

何のために大学院卒を雇っているのか…。

■■教科書の知識だけ

勉強のできる人は多い反面、勉強の知識しかないから、他にも急を要する事はあるというのに、重箱の隅ばかり細かくつつくから、部下も、ベンダーも、委託業者もやる気をなくす。

■■「自分はお上」という傲慢な意識

ある時、システム部門トップがあからさまに、こう言い放ったことがある。

「結果は全部ベンダーに押し付ける!!」

公表されていないが、実は当病院では、電子カルテ更新プロジェクトが失敗するに至った。

本番リプレース時期は予定より大幅遅延し、リプレース当日はシステムが使用不可能になる事態さえ発生し、未だに実装されていない機能が多数存在する。

ただ、これにはベンダー側の問題が第一としてある。

しかし、受入テストもろくすっぽやらず納品した事例もあり、あながち、ベンダー側の問題が全部とまでは言えないと私は思っている。

まぁ、ベンダー側が保守費用の範囲で何でもしてくれる、と考えてもいたのだろう。

医療情報学会の有力者もいるから、「自分達に嫌われると大変なことになるぞ」という意識もあるらしい。

ちなみに、電子カルテ更新プロジェクトは実質は失敗だったにも関わらず、医療情報系の某雑誌では「成功」だとか「問題は何もなかった」と強調され、当事者が成果アピールしていた。

現場の負担軽減よりも自分の経歴が大事らしい。

研究に仕える人間が事実を捻じ曲げ隠してしまうものなのかと、残念だった。

これ以来、成果報告を見聞きしても疑うようになった。

■■採用の独占、閉鎖的な環境

民間の人材は基本登用されなず、医療情報学会、特定大学の出身者がコネで採用されているのが実態(6NCの一部は特にこの傾向がある)。

新規な人材が流入する余地が少ない。

実務を担うはずの職種に実務経験ゼロの院卒を無理やりねじ込む人事が普通に起こるので、ヒラのエンジニア、非常勤職員・委託業者の負担が増加する。

事実、私の職場では増えた。

委託業者は、3カ月に1度は人が辞めていく。

■■完全なる年功序列

仕事ができなかろうが、能力があろうがなかろうが、暇だろうが、係長に昇進する事態はなぜ起こるのか?

■■仕事をしなくてもクビにならずに昇進可能

厚生労働省から転籍で来たある職員(役職は室長)がいたが、会議中は普通に居眠りし、仕事といえば申請書類を整理しているだけで、一日中、何もせずにPCに向かっていた。

人事ローテーションで別の国立と名の付く病院に移動したが、そこでも室長らしい。

■補足

指摘されてる別の匿名ダイアリは別人だな~。

同じなんだと関心しているけど、同じ匿名のますだと思ってもらっても全然いい気はする。

■結

民間企業でもあるかもしれないが、デジタル庁を創設すほど意気込みがあるなら、公的機関から率先して変わってほしい。

こんなに質の低い技術力で医療とICTの何のコラボレーションができるのだろう。

公的組織にいたら、間違いなく、能力は腐る。

でも、COCOAやHERSYSはこうなってほしくない。

もし、同じだとしたら、最悪だ。

公的機関(医療機関)の情シスをして分かったこと→DXなんて絶対無理

公的機関(とある病院)で情シス部員として、もう何年か勤務しているが、なかなか酷い。

公共機関全部が一緒じゃないことは分かっている。


でも、これが医療情報学会が育てた医療情報技師の姿なのか?

■理由1:請負業者・外部業者に丸投げ

保守、運用管理を別業者に委託するのはよくあるにしても、

「保守・運用管理以外の仕事」も丸投げしてしまう。

理由は単純で、正職員が「定時で帰りたいから」と、「やっかいな仕事はやりたくないから」(正職員のくせに)。

あと人によっては、実務担当職で採用されているのに「研究がしたいから」を理由に請負業者に丸投げしている(口では言わないが、見てたら分かる)。

ちな、請負業者は契約を切られたくないから、理不尽でもやらざるを得ない。


医療情報部的な部署がある医療機関になると診療情報管理士がいることもあるのだけど、

ITとか全然知らない人も多いので、文書とか診療情報のことに関しても、

「ITとか全然分からないから」ということで「保守・運用管理」だけが契約範囲の業者に丸投げする人もいる(管理士の仕事なのに)。

ただ、診療情報管理士が個人的に丸投げしているわけではなく、当病院では部署ぐるみ。

実際はできないから投げているのではなく、雑用だと決めつけ、やりたくないから、投げているのが実態。

正職員を甘やかしている。


まぁ、でも、当院の診療情報管理士について言えば、とりわけ、丸投げとか「これは私の仕事じゃない」とすぐに逃げたりするのですけどね(システム職ではないが)。

「システムのことなんて分からない」と言えば、すぐに誰かに押しつけれる(請負業者に)。

そして、甘やかしてそれを認めてしまう文化。


それに対して、請負業者・非常勤職員は雑巾のように扱われる。

請負・非常勤が大変な状態になっていても、「役割が違うから」と手助けすることは一切ない。

反対に、正規職が大変な時は、請負・非常勤は手助けをするように求められる。


医師・看護師が怒っても責任も含めて丸投げしているのが現状だから、改善しない。

現場から怒られるのは責任の重いはずの正規職員ではなく、半分は組織の外側にいる請負業者の社員と非常勤職員。

逆に、忙しい人間を尻目に、半日以上も政治の雑談したり、業務的に必然性のない資格の勉強をしている職員も実際いる。

不健全でしょ?

で、「自分、公務員だぞ、いいだろ」という態度出てるんですよ。


そのくせ、指示されなければ何もしないのだけどね(当院について言えば、これは管理士・事務方に多いな)。


「発注側」という高みに立って上から目線になっているのもあるし、

端から見ていると「自分たちは公務員で誰もが羨む天上人」という意識があるようで、

「公務員になれたというゴールを達成」したものだから、自己研鑽するという意欲さらさらない(実際にない)。


ちなみに、自己研鑽をしなくても怒られることはない。評価も下がらない。民間企業ではありえないぬるい職場。


あと、簡単な帳票を作成する作業でさえ、業者に頼らないといけない。

Accessレベルを使いこなせない、のが実態。


ああ、あと、公的機関は予算は全部使い切るのが基本なのも一因かもね。

手が空いている人もいるのに、請負・非常勤に実務はそちらにふって、業務中に業務に関係ない資格の勉強をする人もいるのだけど、

請負・非常勤の存在がないと、そういう仕事の仕方は成り立たないでしょ。


腐ってるけど。


ちなみに、非常勤職員は1年の任期付きなのだけど、確信犯的に継続を繰り返して任用することが普通になっている。

「時短勤務をしているだけの常勤職員」のはずなのに、経費の安い非常勤にしているだけ。


■理由2:実務経験者が少ない

あとでも書くけど、特定大学のある研究室の就職の受皿になっているせいで、競争試験が形骸化している。

医療情報学会経由かつ、その大学の人間が優先的に採用されるのが実態。


こういう人は大抵がSE実務の経験はないけど、「研究だけはしたい」奴ら。


帳票作れば多少の業務改善もできるのだけど、そんなこともできない。

ただ、研究は大好きらしいので、医療情報学会とか論文の書き方は詳しい。


だけど、現場の医師・看護師さんが困っていても、


研究>>>>>>>>実務


という優先順位。


大丈夫、仕事が溜まったら請負業者・時短勤務の非常勤職員にねじこめばいい。


こうして、

  • 定時で帰宅する正規職員
  • 実務そっちのけで研究に勤しむ正規職SE
  • 仕事をねじこまれて残業続きで給料の安い請負業者・時短勤務の非常勤職種

という構図ができあがる。


医師や看護師の実務を改善してそれを研究成果にする、なら納得するのだけど、

あいにく、そうではない(あまり書くと身バレするが)。


技術的に分からないことがあったらどうするか?

これの解決方法は、簡単。


外部業者・請負業者に分かりやすい資料を作成させて説明させればいい。

「説明するのは、お前らの仕事だ」と恫喝してね。


こうして、専門知識を勉強していくわけさ。

理由3:正職員の目標管理制度がザル(形式だけ)

そりゃあ、自己研鑽を義務づけたら自分たちが大変になるのが分かってるから、上司ぐるみでちゃんとやらない。


DXもくそもない。

■理由4:ずっと同じ作業しかできなくても評価は下がらずボーナス満額もらえる

公務員は絶対に首にならないからね。


むしろ、DX推進なんてやったら仕事が増える。

だから、やらない。


やっても、やらなくても給料は一緒だから。

だったら、やらないほうが楽だよね?

現場の医師・看護師は大変だけど、「別業務で大変だから」とか「できない」と言えば、何とでもなる。

実態は、暇で手の空いてる人もいるけど。


ちなみに、現場の医療職が怒っても、電話は受付対応は非常勤職種と請負業者に全てやらせている。

これについては、ある診療情報管理士の正規職員がこう言っていた。


「電話や受付対応をすると怒られたり、トラブル対応のために走り回って調べないといけないから、やりたくない」


「専門知識がないから対応できない」とか「正規職員の業務に差し支えるから」、という理由なら理解できる。

でも、そうじゃないのは見れば分かる。

ただただ、高ストレスの仕事で仕事の種類として嫌だから、えり好みしているだけ、なんだよな。


病院という組織の立場に立って責任ある地位にいるから高い給料を貰っているのに、ね


実際、正規職員はSEも含めて、後ろに隠れたがる。

責任感ある正職員もいるが、全員がそうじゃない。

回答の責任も丸投げし、現場の怒りは請負業者・非常勤職員に対応させる。


正規職員の責任なんてどこへやらだ。


博士課程で採用された人は、「私、博士卒だから給与はいいですよ〜(笑顔)」と言ってた。


6時間勤務のはずの非常勤職種にも、常勤職員には与えないような詰め込みの仕事、残業が発生しやすいトラブル対応の仕事を与えることも普通。

見る限り、時短勤務の職員が残業をする率が高く、申請もきちんとしていない(あまりきちんとやると「なんで多いんだ」と怒られる)。


請負業者も同じような境遇だ。

人の入れ替わりが多く、どんどん人が辞めていく。

でも、直接雇用しているわけじゃないから、何も問題視はされない。


でも、こうなって一番困るのは、現場の医師・看護師・コメディカルなんですよ!


■理由5:特定大学出身者でポストが独占されてるから外部者が入らず、改善の余地がない

まぁ、これも大きいよね。


能力じゃなくて出身大学で取るものだから、実務能力も関係ないし、公正な競争もない。

白い巨塔で育って来た人に実務ができるわけがない。

クビにすることもできない。


できないから請負業者、非常勤職種に丸投げするしかない。


ちな、公的機関(独立行政法人も)は、採用にあたっては必ず公募をしないとけない。

でも、特定の人しか入れないようにするための抜け道がある。


これは、自分の職場で実際していることなのだけど、

採用条件を他の人が応募できないような条件にしてしまうこと。


「博士課程保持者」とかね。


実際は博士課程の人間じゃなくても十分できる仕事なのだけど(そもそも実務の仕事に博士課程は必要とは言えない)、

特定大学の特定研究室の就職の受皿になっているから、要するに、特定者に便宜を図った不公平な採用が行われいるんですよ。

公平な競争なんて、一切無い世界ですよ、公共機関なのに。

法令遵守してんのかよ。


で、来た博士課程の人と言えば、院卒なのに実務的な対応能力なんて無いんですよ。

実務を担う職種に研究職を無理矢理ねじ込んで研究活動してるもんだから、現場から問合せが来ても他の誰かが代わりに対応しているのが実情。


理由6:職場・組織の問題に対して当事者意識がない、現場対応から逃げたがる

現場の医療職からの問合せに対して、受付対応・回答(調査をさせたりも)を請負・非常勤職種にやらせ、

正規職はコア業務へ集中したいからと称して、ネットのニュースサイトをずっと見ていたり、資格の勉強をする者もいる。


正規職には現場の怒りは届かない。

彼らは後ろに隠れたがる。当事者意識なんてものはない。

なんだろうな、こういう意識の持ち方は公務員特有だという気がする(当然人によるよ)。


ああ、そいや、正職員の方々の中には、情報収集に熱心な人がいて、

管理する立場でもないのに請負業者が記録している対応の履歴を業務時間中にやたら細かく見てる人も、一定数いる。

職務上は明らかにする必要ない行為なのだけど、そんな時間をわざわざ作る余裕があるから不思議。

で、現場対応、窓口対応は嫌だと言う。

情報収集に熱心なのは、重たい仕事が自分に来ないよう注意してるからだが。


現場対応はできればやりたくないから請負業者・非常勤職員にやらせる、これは本当に多い。

これは本当に正規職員の給与に見合った責任ある行動なのか?

正規職員のイスはもらった。大変なことは別の人にやらせて、楽もしたい。でも、しっかりとした給与も退職金も福利厚生もほしい。

それが実態。


理由7:そもそも経費削減・業務効率化という意識がない。経費の使い方ガバガバ。


だって、年間の予算全部使い切らないと次年度から減らされますから。

備品、必要ないのに買いまくってます。


数名は職場の自分PCに、iMacを使用しています。

当然、予算で買っている。

Macを買う業務上の必然性は一切ありません。

ていうか、職場のシステムはWindowsがベースなんで。

なぜMacか?

当人達いわく「かっこいいから」「Macがいいから」だそうです。

同等の性能ならWindowsのほうが絶対安いですよ。


でも、「Macがほしいから」というだけの理由でMacを買ってました。

いいねー、公務員。

こういうことをするのは大抵、公的機関で純粋培養された職員です。


職場全体は慢性的に赤字なのだけど、経費は使い切るものという意識があるようで…。


さすがに自分はMac買ってません。

無駄遣いすぎることが分かっているので。


あぁ、あと、ブレードサーバーわざわざ買った人いるけど、

あんまし使ってらっしゃいませんね。


研究費は使い切るもんだという意識もあるみたいですが、それにしても無駄遣いでは?

業務効率化も糞もないのに、ボーナス満額もらえるんですよね、国の財源で!


これが、公共機関の情報システム部門ですよ。


DXなんてできない、というより、DXなんてそもそもやる気がない。

だって、自分のことしか考えていないからね。


こうしている間にも、医療職はどんどん疲弊しているというのに。


くたばっちまえ。


医療情報学会も嫌いになりました。


これが、お前らの言う、コミュニケーション、コラボレーション、コーディネーションの本当の姿だったんだな?

言っても何も変わらないんだ。

だから、ここに書いて残す。

Goのプロジェクト構成の基本

最近のIT関連に思うこと

確かに...と思いつつ、我々はもはやCPUの動作を把握しているわけではないという現実もある。

Goの静的解析ツールをgolintからstaticcheckに移行した話

採用母数の違いで技術選択するなんて、ソフトウェア中心のスタートアップでは、悪手以外の何物でもないな

うーん、採用母数の違いで技術選択するなんて、ソフトウェア中心のスタートアップでは、悪手以外の何物でもないな。特定の技術に固執するような開発者を雇うことが一番リスキーだ。

@sugimoto_kei

弊社製品は、極めて特殊な技術スタックの上に構築されている。それは、顧客とユーザーのニーズにぴったり合っており、弊社の弱みではなく強みだ。

@sugimoto_kei

一理あるとも言えなくもないけど、エンジニアの頭数の方が重要という考え方もある。

テックリードやアーキテクトが特定技術に固執するのは残念感あるけど、それ未満の若手エンジニアなら特定の技術に憧れを持っていてもいいし、それを餌に採用するのもひとつの戦略ではある。

特にWEBアプリケーションの場合、結局はブラウザに表示されれば何で実装されていようが重要ではないので採用を重視した技術選定は別に間違ってはいない。

DDD 、少しでも言及するとすぐ警察が現れてそれは DDD じゃないと否定しにかかるから絶対そのうち誰も...

DDD 、少しでも言及するとすぐ警察が現れてそれは DDD じゃないと否定しにかかるから絶対そのうち誰も言わなくなるだろうなというのがある

@zeriyoshi

OOP、UML、アジャイル、関数型プログラミング...教条主義者が破壊してきた生態系はとても大きい

なので、教条主義者は一緒に仕事をしたくないランキングトップ3入りしている。

半導体製造「弘芯」の巨大詐欺が中国で話題に

景気がいい時は詐欺もスケールが大きくなるな

Domainディレクトリとかドカンと切るとイマイチになる理由

Domainディレクトリとかドカンと切るとイマイチになる理由

@d_horiyama_web

パッケージやモジュールごとに中身を

「公開」「internal(触るな)」

の2つに分けるくらいがよいのではと半年くらい前から思ってる

internalがたまたまDBだったり外部APIだったりする

@d_horiyama_web

内部実装の中で別のモジュールを呼び出してる場合そのモジュールの公開APIを呼び出しているわけで抽象と実装は多層構造なんですよね

1層のドメイン/インフラに平坦化するのがそもそも無理がある

@d_horiyama_web

plantumlでうまく絵を描けない時点でなにかがおかしい

@d_horiyama_web

Domain層がいわゆる公開APIでインフラ層、アプリケーション層はそれらの実装という考えてではいかんのか?

OCNはスマホにグローバルIPを割り当てるため、常に何らかのアタックがされ続け、常に受信側のスマホが...

「OCNモバイルだとスマホの電池減りが早い」みたいな意見を見たとき「は?SIMによる違いとかありえなくない?」

って思ったけど、OCNはスマホにグローバルIPを割り当てるため、常に何らかのアタックがされ続け、常に受信側のスマホがそのパケット捨てるために…みたいな記事みてなるほどと思った

@hako584

そんなことになってるのか

TinyDB - Python製の組込みドキュメントDB

SQLiteみたいに使えるファイルベースのドキュメントDBだそうな。

追記

これ、本当にJSONファイルにDictを保存していくだけっぽいな...サイズが大きくなった時のパフォーマンスがやばそう。

完全マネージドな k8s ! GKE Autopilot を解説する

GKE Autopilot は GKE の新しいモードです。Control Plane に加えて、Node が完全マネージドになります。これまでの GKE では Node はユーザー自身が必要台数分作成し、以後の Day 2 オペレーション (e.g. アップグレード) 等も気に掛ける必要がありました。GKE Autopilot では Node は Control Plane と同様、Google の SRE が管理することになります。

説明だけ読むと一般的なWEBアプリケーションに向いてる感じなのだろうか

管理職のための役職引退マニュアル

すごい

解くべき問題に集中するために慣れてる言語を使うってのは重要なんだろな

Doug Cutting氏にどうしてHadoopの実装言語としてJava選んだの?って聞いたときの答えも似たような感じ。言語として致命的な欠点が存在しないことと、ライブラリが潤沢に揃っていること。解くべき問題に集中するために慣れてる言語を使うってのは重要なんだろな。

なぜmoldをRustで書かないのかという質問が来たけど、

1. C++が一番慣れてる

2. Intel TBBみたいな良いライブラリがそろってる

3. こういうプロジェクトでは、実装しようとしているもの自体が興味深いのであって、どの言語で実装するかはそこまで重要ではない という感じかな。

@rui314

@kmizumar

特に必然性なく流行りの○○使っちゃうのはアンチパターン。

経歴書を彩りたいという欲求は理解できるけども。

JIRA とか Confluence とかは、機能要件をゴリゴリ充実させて星取り表上はとても機能豊富なんだけど、非機能...

JIRA とか Confluence とかは、機能要件をゴリゴリ充実させて星取り表上はとても機能豊富なんだけど、非機能要件がろくに顧みられていない、というやつの典型例に見える

@dmikurube

まあ商売として大間違いではないと思う…たまにイラッとくるけど

@dmikurube

あの手の製品は機能要件で開発すべきものが無限に出てくるから、まあそっちに手は回らないだろうな、というのはわかる

@dmikurube

とにかくfeatureをブチ込めばええやろ精神

MinIO - Go-lang製のオブジェクトストレージ

↓興味が湧いたのでメモ

第655回 オブジェクトストレージ,MinIOを使用する

MinIOはオープンソースでマルチプラットフォームなオブジェクトストレージサーバーで,Goで書かれているためファイル1つあれば実行できるという手軽さが魅力的です。もちろんAmazon S3互換APIを採用しているため,クライアントも選び放題です。またドキュメントが豊富なものも魅力的で,おおむね自分がやりたいことはできてしまうでしょう。

へぇ、面白そうだ

東工大、IoT向けCPUアーキテクチャ「SubRISC+」。エネルギー効率3.8倍

SubRISC+では、データからの異常検出やデータ探索をする軽量アルゴリズムをリアルタイムに処理し、警告などのかぎられたデータのみ送信する用途を想定。命令数を4つに限定することで小型/低消費電力化を図った。一方でチューリング完全であり、これらの用途以外の汎用プログラムも処理できるとしている。

↓は東工大のプレスリリース

本研究で開発した組み込みプロセッサは、減算・シフト・論理演算・メモリアクセスの4種類の命令のみから成るRISCプロセッサ[用語7]であり、減算結果に応じて条件分岐するという特徴を持つことから、このアーキテクチャ(図1)を「SubRISC+」と名付けた。近年は心電図・加速度などのデータ(図2a)のセンシング機能が、ウェアラブルデバイスや携帯端末に搭載されることが増えている。SubRISC+は、それらのデータから異常検出やデータ探索する軽量アルゴリズム[用語8]をリアルタイムに処理し、警告などの限られたデータのみを送信する用途を想定している。なお、SubRISC+はチューリング完全[用語9]であるため、これらの用途以外のあらゆるプログラムを処理することができる。

取り返しのつかない我がエンジニア人生よ

ここには年に1回くらい殴り書きしてるんだけど、史上最大に気持ち悪いおじさんの自分語りになってしまった。というか長すぎ。誰が読むんだ、これ。

自分は33歳、妻と未就学児1人の計3人で、人口100万人以上のそこそこの地方都市に暮らしている。

会社は子会社系のSIer。新卒で入った。これがまあ、ネットでよく馬鹿にされるような典型的な時代遅れの会社だった。

正直、入社時は「エンジニアとして働く」「会社の安定性」の両方が満たせそう、ぐらいの浅はかな考えだった。で、実際のところ大企業である親会社の盾もありまあ、安定していた。競争原理が働かず仕事は嫌でも降ってくる。給料は年功序列で上がっていき、昨年の年収は大体月20時間の残業で600万だった。世間的にはそこまで高いとは思わないんだけど、この会社の外での自分の市場価値を考えれば高いと思っている。

一方でエンジニアとしてはそりゃもうひどい環境だった。10年前に入った頃から使っている技術も会社としてのマインドは何ひとつ変わらず現状維持がモットー。口では「子会社としての安全神話は終わった」「DXだ」と言っているが、行動が伴っていない。

こんな環境に危機感を覚えないわけがなく、数年前に転職活動をしてみた。その頃はこっちに有力な求人は無く、とにかく東京の求人に応募していた。その結果、有給ぶっ込んでの日帰りで東京に行く過酷な面接に力尽きて断念した。というのは建前で、チャレンジすることにビビってたのかもしれない。本業であまりにも技術的な取り組みがないのでプライベートでプログラミングしたりWebサービス作ってみたりしてたけど、それも趣味程度の取り組みで「今からじゃ遅いんじゃない?」と自分でブレーキを踏んでいたんだ。

そんなこんなで「まだ今の会社でできることがかあるはずだ!」と自分に言い聞かせて続けてきた。結果、市場価値が上がるような仕事は何もしていない。自分なりに新しい仕組みを取り入れてみたりはしたけど、それだって会社にインパクトを与えるもんでもないし、Qiitaのやってみたレベルかつ今ではレガシーな技術たちだ。

「SIerはPMになるしかない」なんてよく言われるが現職のPMは協力会社に見積と作業ぶん投げて、死ぬ程使いづらい社内ツールに決められた進捗項目を入れていくだけの仕事。あれで「PMできます」なんて言えない。

それで昨年立ち上がった超大型プロジェクトが外部NWから遮断されたオンプレのサーバーで、自社製フレームワークを使い、IE11"を"ターゲットに開発されることになってふと思ったんだ。

「このままGitHubもクラウドもDockerもBacklogも使わず、(自称)エンジニア人生が終わるんだろうな」と。この会社での人生があと30年も続くのかと。

個別の技術に思い入れがあるわけではないんだけど、やっぱり技術で課題解決したいと思って入ってきた世界だからさ、会社の前例やルールじゃなくて、合理的で先のある技術を使いたいんだ。

結局、転職を思い立った数年前から業務外での勉強をやめることはできなかった。でもこれは何のためにやってるんだろうな。本業ではクラウドもWebプログラミングも、アジャイル開発手法も求められていないのにね。虚しさが募ってくる。いっそのこと本業が完全に別の業界だったら良かったのに。(実際別業界と言っていいレベルだけど……)

じゃあ転職するの?20代で「今さら」と言って止めたのに?それこそ今さらだろう。コロナ流行によって東京本社のフルリモート勤務求人が劇的に増えた。もう少し若ければ追い風だったかもしれないが、社会人10年を超えたおっさんが、新しい会社どころからフルリモートなんて環境で働けるのだろうか。あ、もちろん現職はバリバリ出社。シンテレワーク頼みのVPN環境はあるけど社内ルールとかいろいろあって無理なんだって。

年代的には技術とリーダー経験がそれなりに求められるんだろうけど、これまでの経験ではとても満たせそうにない。本業ではレガシーなシステムの保守でそのほとんどが業務よりの仕事でなんちゃってPMやってただけ。独学の開発経験なんて昨今問題になっているプログラミングスクールと大して変わりないだろう。

転職サイトではベンチャーとかから声かけてもらえるけど、まともなエンジニアと話するのがもう怖い。

思考がネガティブな方向にしか向かない。こうなったらいよいよ腹を括って現職にしがみつくしかないんだろうか。しかし、ここまで会社への不満を溜め込んでしまったら、今後若手の取り組みに苦言を呈する老害になる未来が見える。

現職を続けてよかったことと言えば今の家族を持てて、(今のところ)無理のないローンで家を買えたこと。子供は一人で確定だし、子供が小学校に上がるくらいには妻も時短解除で普通に生活はしていけるだろう。

安定を求めた結果が今なんだけど、仕事への不満抱えながらあと30年耐えること考えるとめまいがしてくる。(あと10年もしたらそんな不満も忘れて老害化してる可能性もあるけど。)一方で無能おじさんがこれから新しい会社で活躍する未来は思い描けない。

よく歌詞に「思い描いた大人にはなれなかったけど」とかあるじゃん。あれ、子どものころは芸能人とかスポーツ選手とか、そういう人になれないって意味だと思ってたけど、実際は自分の仕事に誇りを持てず。ただただ惰性で生きる人のことだったんだね。立派にエンジニアの責務を果たしている人たちが雲の上の存在に感じるよ。

今後の人生で一番若いのは今この瞬間で、悩んでる暇なんか無くて行動するしかないんだろう。というか実際のところ現職が自分には合っているんだろうが、理想とのあまりのギャップがとてつもなくしんどい。悩むのをやめたい。もう労働を捨てたい。

33歳でここまで悲観的になれるものだろうか?

IPアドレスに縛られない新しい通信識別技術と既存のインターネットが共存するための国際規格が発行されました

本規格では、例えば農産物のトラッキングシステム2などの非常に広域かつ多数相互間で利用されるIoTアプリケーション向けに、IPアドレスに縛られないICN技術を導入する上での基盤を規定しています。具体的には、電子メールやインターネットアクセスなどの既存のサービスへの接続を担保しながら、膨大なデータの転送を実現できるIoT DEP(Data Exchange Platform;データ交換プラットフォーム)を定義し、その要求条件を規定しています(図3参照)。主な内容は以下のとおりです。

  • IoTサービスの概要
  • IoTネットワークの構成
  • IoT DEPのネットワークモデル
  • IoTリファレンスアーキテクチャにおけるIoT DEPの位置づけ
  • IoT DEPの機能
  • IoTシステムでのIoT DEPの運用
  • IoT DEPの要件

ふーむ?? よくわからん。

レーザーカッターで自分だけのRaspberryPiケースを作ってみよう!

Tinker Board 2 買ったらケースも作ってみるか

シングルボードコンピュータEXPO2021

面白そうなので見てみよう

ASUSが新製品「Tinker Board 2」シリーズを発表

· 卓越したIoT性能: 64-bit Armv86アーキテクチャを採用した6コアのRockchip RK3399 SoCに加え、マルチコアのMali-T860 GPUを搭載

· 簡単設定ツール:パフォーマンスの微調整や監視を直感的に行えるソフトウェアで、簡単な3ステップによる初期設定

· プロレベルの管理: ASUS IoT Cloud Consoleによるデータ管理や分析に加え、OTA(無線)によるファームウェア更新もサポート

· Android 10サポート:優れた3D性能、Android Neural NetworkやAdiantum暗号化により効率を5倍向上

気になる

Dapr × Kubernetes ではじめるポータブルなマイクロサービス

マイクロソフト、オープンソースの分散アプリケーションランタイム「Dapr 1.0」リリース。Kubernetes対応、サ...

分散アプリケーションでは、アプリケーションが相互に機能を呼び出し、メッセージをやり取りしつつ動作します。また、分散環境でのステート管理などの仕組みも必要です。

Daprはこうした分散アプリケーションを実現するための基本的な機能を提供するランタイムとして開発されました。

分散環境への対応をDaprに任せることで、プログラマはアプリケーションのロジックの開発に集中でき、分散アプリケーションの開発が容易になります。

具体的には何をしてくれるものなんだろうか?

階層構造(a.k.a ツリー構造・ディレクトリ構造・フォルダ)をDBでどう設計すべきか

UI出力を前提とする木構造データならJSON(など)で静的に定義してDBに保存すればよい

...のでは?

UI出力を前提とする木構造データというのは、アプリケーションのメニューや商品カテゴリーなどのようにUI上で木構造のリストとして表現されるデータを指す。

UI表示に利用されるだけであることが明らかである[1]なら、わざわざ面倒臭い木構造を頑張ってRDBで実現する価値は低いし、保守性も下がる[2]。

UI出力に利用されるだけであるなら、それに必要な構造を直接JSON[3][4]で定義し、そのJSONをアプリケーションに読み込んでもらえば目的は達成できる。

JSONを編集するのが面倒なことは予想できるが、それでは隣接データモデルや閉包データモデルのデータをメンテナンスするのとどちらが大変なのか? と考えた時、労力はどちらもさほど変わらないのではという感じはあるし、テキストエディタでする場合、構文チェックなどのサポートが得られる点で多少はJSONに分があるのではなかろうか。

JSONのサイズが巨大(メモリに乗せるのが難しいサイズ)になったらどうするのだという話もあるが、UI表示が前提であるならそもそもそんな馬鹿げたサイズにはならないことが期待できる。また、仮にJSONが巨大化してしまった場合も大抵の言語にはストリーム方式でデータを読み込むライブラリぐらい存在するだろう(希望的観測)。

そのように考えると、データ処理を行う上で木構造であることが重要なデータ[5]なら仕方ないとしても、単にUIに表示するためだけに木構造を実装するのは割に合わないのではないか? JSONで木構造を定義してそれを返却すれば要件を満たせる場合もあるのではないだろうか? という事を考えた。

脚注

Appendix: サンプルJSON

JSONで書くとこんな感じだろうか? 頻繁に更新するのは面倒くさそうだ。

item_tree = [{
    id:xxx,
    name:xxx,
    child: [{
        id:xxx,
        name:xxx,
        child: [{
            id:xxx,
            name:xxx,
            child: [{
                id:xxx,
                name:xxx,
                child: []
            }]
        }],
        {
            id:xxx,
            name:xxx,
            child: [...]
        }],
    }],
}]

履歴管理ができるテーブル構造を考えてみた

アソビュー!では様々なデータをRDBで取り扱っていますが、テーブル構造はメンテナンスが難しいです。

モノリシックなマスターテーブルが存在していて、更新日カラムが付属しているけどどこを更新したのかわからない。

また、過去のデータがほしいけどマスターテーブルなので元々がどんなデータだったかわからない。

ということがたまに発生したりします。

上記から履歴管理ができるテーブル構造を作る必要があったため、検討をしました。

という要件から SHOP_REVISIONS テーブルが生まれる理由がよくわからなかった。

マスターテーブルの過去の構造を取り出したいのであれば、リビジョンだけではテーブル構造の再現はできないのでは。

そうではなく特定のリビジョンの時のデータの状態を取り出したいということであるとしても、 SHOP_IMTE_* テーブル達はリビジョンに関連付けられていないので、やはり特定のリビジョンの状態を取り出すことはできないように思える。

そもそも SHOP_REVISIONS テーブルはどのタイミングで更新されるのか? 配下のテーブルが更新される毎に更新されるのだろうか?

状態をデータベースのカラムではなくテーブルで表現する

履歴データを更新することは極力避けたいので、基本は3番の「状態遷移だけを蓄積するテーブルを用意する」案を採用するかな。

この記事で言うIDがレコードのIDを指すのかある種の取引ID的なものなのかいまいち曖昧だったので、IDのユニーク性を保証云々がよく分からなかった。

状態管理テーブルを作るなら特に理由が無ければヘッダー:ディティール構造を採るので取引ID的なものは外部キーとして持つはず。

一緒に仕事したくないエンジニアベスト3

●第一位: マウント大好きエンジニア

論外。他人を不快にすることが生き甲斐なのだろうか?

●第二位: 常に被害者気分なエンジニア

常に自分を被害者ポジションに置こうとする者は何をやってもダメである。

●第三位: 原理主義者/教条主義者

原理主義者/教条主義者は建設的な議論が困難。本当の○○は〜とか○○本では〜みたいな事を言い始めると要注意である。

メリット/デメリット、実用性、実効性辺りを考えて議論できるようになろう。教科書通りにやればいいというものではないのだ。

merpay QA Tech Talk 〜なぜ今「全員品質」なのか?〜

より良いサービスを継続的に届けるための新しい習慣ができるまで

ロバストネス分析を用いた設計と工数見積もり

データ分析を支える技術 DWH再入門 #devio2020

Googleが開発した「改ざん不可能なログシステム」を構築できる「Trillian」とは?

Trillianの改ざん耐性を支えているのはハッシュ木と呼ばれるデータ構造です。ハッシュ木は元データをハッシュ化し、そのハッシュ値をツリー状につなげていくことで、高い改ざん耐性を実現しているのが特徴。ハッシュ木の技術はバージョン管理システムのGitやビッドコインなどにも採用されています。

TrillianのソースコードはGitHubで公開されており、誰でも無料で使用することができます。なお、TrillianのビルドにはGoのバージョン1.14以上が必要とされており、データストレージにはMySQLもしくはMariaDBを用いることができます。

EXPERIENCE JAPAN PICTOGRAMS

日本観光を楽しむすべての人へ。

EXPERIENCE JAPAN PICTOGRAMSは、デザインの視座から、日本観光の魅力的な体験を支えるべく生まれた新機軸のピクトグラムです。シンプルでわかりやすい造形、そして「二度目の日本」をキーワードに、従来のピクトグラムよりも日本の体験を一歩深く掘り下げた独自性あるラインアップが特徴です。

企画・制作する日本デザインセンターは、ピクトグラムを誰もが自然と目にする日本観光のインフラと捉え、そのデザイン性を追求すること、そして1人でも多くの方に使っていただくことを何よりの使命と考えています。それゆえにすべて無償公開とし、商用利用も可能です。EXPERIENCE JAPAN PICTOGRAMSが日本への興味・関心のキッカケとなり、日本の観光体験を少しでも豊かにできればと心から願っています。

すばらしい

翔泳社祭2021

2/18〜2/25まで翔泳社の書籍が半額セール。

とはいえ、定期的にセールしてるから読みたい本は大体購入済みなんだよな。

「スピード」と「品質」のスイッチング ~事業成長を支える生存戦略~

デブサミ今日だったか。

毎度ながらなんでアーカイブ公開してくれないんだろ。

差し込みの多いプロダクト開発のスケジュールの精度を上げるためにはバーンアップチャートがおすすめです

プログラマの仕事がAIに奪われる事があるとすると、それはコンパイラやエディタに革新的な改善が入ってそれを...

プログラマの仕事がAIに奪われる事があるとすると、それはコンパイラやエディタに革新的な改善が入ってそれを使える人だけ居ればそれ以下の人は要らない、みたいな入り方をすると思っていて、現時点でもJenkinsに仕事を奪われた簡易テスターみたいな人は可視化されにくいだけでいっぱいいそう。

@kumagi

Jenkinsに限らずバージョン管理システムでも似たようなことは起きていた。

そもそも論なんだけど、SESに関して言うとロースキルや駆け出しのレベルで話をするのってナンセンスだと思ってる

そもそも論なんだけど、SESに関して言うとロースキルや駆け出しのレベルで話をするのってナンセンスだと思ってる。

そもそも高度専門技術職の人間を一時的に借りたい、ってのがSESであって、高単価で話出来ないのはシンプルな派遣業のアレだと思うんだよね。

@ellnore_pad_267

ほんまこれ

受託、力関係が対等でこちらがハンドル握れるようなとこなら大体良さそう

受託、力関係が対等でこちらがハンドル握れるようなとこなら大体良さそう

所謂大手データセンター系のそれはヤバそう

@MatsuP8

それは確かにありそう。技術コンサル + 構築という感じなら対等な力関係を維持できる。

問題は技術コンサルをやれるエンジニアは希少なのでスケールしないことと、妥協して能力の低い人や営業を挟んでしまうと一瞬で御用聞きベンダーに堕してしまうこと。

つまり継続性が低いのだな。

【ドメイン駆動設計入門】パネルディスカッション with レビュアーズ

COCOA不具合放置の遠因か、開発ベンダー選定で繰り返された「丸投げ」の実態

現在の体制は、厚労省と発注先ベンダーの両方が問題を抱えている。ただ原因を究明するならば、厚労省の前任者らが関わっていた発注プロセスが最善だったのかという点まで踏み込んで検証すべきだ。

というのも厚労省の説明や関係者の話を総合すると、厚労省は発注当初、接触確認アプリに十分な知見がないベンダーや、開発グループを公平に選べない立場にあったベンダーに実質的にベンダー選考を委ねていたからだ。新型コロナ禍でリリースを急いだとは言え、「技術や開発体制の優劣で開発ベンダーを選ぶ」という選択肢を放棄したことが、現在まで続くバグの遠因になった可能性がある。

開発費の流れはこうだ。厚労省はHER-SYSで確保した予算9億4000万円(2020年度第1次補正予算時点)の一部を振り分ける形で、COCOAの開発をパーソルP&Tに発注した。パーソルP&Tはそのうち1615万円をエムティーアイに支払う契約を結んだ。ただし契約当初は保守開発でなく主にユーザーサポート業務を想定したものだった。

有料の2ページ目が本番らしいが、別に契約したくはないしなぁ

プロダクトマネジメントの罠「ビルドトラップ」とは? アジャイルや組織改革の専門家、吉羽龍太郎氏が解説

アウトプットは「人や機械、組織が作ったものの『かたまり』や『量』を示すもの」。プロダクト開発におけるアウトプットとは、リリースしたプロダクトの機能やこなしたタスク、書いたコードの量ということになる。

アウトカムはアウトプットを受けて発生したものである。例えば顧客が抱える問題の解決や行動の変容を指す。そしてアウトカムから生まれた組織に与えたビジネス的、金銭的な影響をインパクトという。

つまりプロダクトマネジメントで最も重要なのは「アウトプットではなく、顧客が抱える問題を解決し、ビジネス的な成果、インパクトを与えること。アウトプットに偏重すると、リリース自体をゴールと捉えてしまうことが多くなるので要注意です」と吉羽氏は指摘する。

ビルドトラップに陥っているかどうかを見分けるにはどうすればよいのか。以下がビルドトラップの兆候であると吉羽氏は7つのケースを挙げた。

  • 約束されたロードマップ、長すぎるバックログ
  • 競合他社との機能比較
  • 必要性のわからない機能
  • 生産性やベロシティに対する課題ばかりが表出
  • ステークホルダーの干渉
  • 権限のないプロダクトチーム、意思のないプロダクトチーム
  • 役に立たないKPI

ビルドトラップを防ぐ7つの対処方法

  • (1)適切なプロダクトマネージャーを据える
  • (2)適切なチーム構成にする
  • (3)適切な戦略を組織に行き渡らせる
  • (4)ソリューションの前に問題を理解する
  • (5)ソリューションを探索する
  • (6)適切な指標を定めて活用する
  • (7)組織をプロダクト主導にする

技術的負債との付き合い方とその変化

  • 技術的負債への対応観点で今うまくやれてること、自分たちの苦手なことを確認したら対策が見えてきた
  • 必要だったのはチームで技術的負債についてコミュニケーションできるようになることと、負債の把握と管理
  • チームの在籍年数が長い人から短い若手や内定者アルバイトまで全員が技術的負債の存在を認知し、特定の個人ではなくチーム全員で負債返済の対応ができている

2000年代オブジェクト指向は絶対の正義だった。つまり僕は洗脳を経験している

これは自分も身に覚えがある。

あと、J2EEという宗教も付け加えておこう。

ITエンジニアとしての勉強をやめた話

業務に関することを業務外でも勉強してたらそれは単に「常に仕事をしている」状態だから、そりゃ精神を病むだろう。

自宅でやる勉強は業務とは直接関係ない(あってもよいけど必須ではない)自分が興味のある領域を学ぶことに使うべきだ。

そこで学んだことを業務に活かせればよし、活かせそうにないなら転職時のアピールポイントにするぐらいのノリでやるべきだろう。

というか「業務時間外でも勉強する」というのはそういうものだと思っていたので、「業務時間外でも業務のことを考え続ける」という発想が無かった。

なるほど、それで「業務時間外でも勉強するべきか否か」みたいな議論が発生するわけか。

LaravelのSailはちょっと使いたくないかな

久しぶりにLaravelを触ることになって色々試していたのだけど、LaravelにはSailというDockerラッパーが追加されたらしい。

直感的に「これはいけない」という感想しかない。

奇しくもLaravel JP Conference2019で聞いた↓の話と全く同じである。

個人的にはSailは使わずに済ませたいものだが、Sail並の完成度の環境を提供できるのかというとそれも工数的にしんどいものがあるのは現実ではある。

どうしたもんかな。

NEXT