/note/tech

Linuxカーネルに意図的にバグを混入したとして大学にコミュニティ出禁措置

オープンソースソフトウェアの脆弱(ぜいじゃく)性に関する論文の執筆のため、Linuxカーネルに既知のバグを含むパッチを送信したことを理由に、ミネソタ大学に対して「Linuxカーネル開発への貢献の禁止」、つまり出禁措置が行われました。

つまり、オープンソースソフトウェア(ここではLinux)に対して意図的に悪意あるコードを貢献という形で組み込めるかという研究がやりたくて、実際にLinuxカーネルメンテナで試したら即バレして出禁になったという感じか。

当然の結果だし、Linuxカーネルメンテナのレビューは適切だったという実績になるんだな。

最初にクソコードを書いた者はどんな立派な方法論者よりも偉大である。誰も表現しなかったドメインを...

最初にクソコードを書いた者はどんな立派な方法論者よりも偉大である。誰も表現しなかったドメインを稚拙ながらどうにか表現したのだから。最後にクソコードにクソを継ぎ足した者はどんな言い訳をしようと最低である。病人に言われるがまま酒を勧めた考えなしと同じだから。

@tanakahisateru

対症療法しかできん場合もあるからなぁ

【マネジメント】プロジェクトは管理しない

コードが読めるソフトウェア開発者

確かにコードを「しっかり」読めて、全体の整合性保全に貢献できるエンジニアは貴重。

多くの場合、ビッグバン結合キメてそこで発生した細々した問題に都度対応していくというアプローチを取りがちだけど、実はそれってかなりハイリスクなんだよな。

プログラマにも読んでほしい「QCべからず集」

「保守コスト低めで生き続けるコードにしたい」っていう意図で Go を選択するのはかなり正しいと思っている

「保守コスト低めで生き続けるコードにしたい」

っていう意図で Go を選択するのはかなり正しいと思っている

PHP も部分的には適格だけど, Laravel を選ぶと死ぬ(PHP が +10 してくれたのを Laravel が -1000 ぐらいもっていくイメージ)

@mpyw

go言語の人々、見てると「とりあえず...」という感じでクリーンアーキテクチャ風の構成にしたがるけど、「それ、本当に保守コスト低くなります??」ってなるんだよな

それなりのキャリアになると、好きか嫌いかとかカッコいいかダサいかとかじゃなく、目標に対してやるべきか...

それなりのキャリアになると、好きか嫌いかとかカッコいいかダサいかとかじゃなく、目標に対してやるべきかやらざるべきかで考えることの方が圧倒的に多い。

@sogitani_baigie

ほんまこれ

レイヤードアーキテクチャ

文化的負債との戦い: 老舗ソフトウェア開発会社でアジャイル変革を仕掛けた8年間

JSONファイルはもういらない? クライアント側のJavaScriptを最小限にするHotwire

HTMLの断片をAjaxで取得してページに埋め込む手法、昔はPjaxと呼ばれてた気がするなぁ

なんとなく理論が数学的に整備されていることがハロー効果的にもっともらしい印象を与えてしまって...

そういや,僕が関数型プログラミングで一番意味がわからないところは,「関数型プログラミングは数学的な意味での関数を使用することでプログラミングを行うこと」という感じの説明がされてると思うんですけど,Printf.printf とか数学的な意味での関数じゃねえじゃんってなるとこなんですよね...

@Mizunashi_Mana

関係データベースでも似たような話があって、RDBモデルは数学の集合論に基づいていてだから「正しい」のです、みたいな雑な主張を見かけたことがある

@pokarim

数学がそれ単体で工学的な正しさを証明するということはありえないはずなんだけど、なんとなく理論が数学的に整備されていることがハロー効果的にもっともらしい印象を与えてしまっているところがありそう

@pokarim

そんな雑なまとめ方する奴おるんか...?

ライティングソフトウェア

これ良さそうだな。4/22発売か。

Excel駆動でWBSやガントチャートが作れない人はどこに原因があるのか?

では、どこに原因があるのか?

1つの観点として、そういう人たちは、PERT図を描いた経験がないのだろうと思う。

つまり、タスクの全体の構造が見えていない。

タスク同士の因果関係、タスク同士の依存関係が見えていない。

たとえば、ガントチャートを作る前にタスクをExcelで洗い出すだろう。

しかし、Excelで縦列に並べたタスクを見ても、その先行・後続の関係や優先度はそれぞれ違う。

それらをつなげて一つのガントチャートを作った、という経験がないようだ。

確かにそこまで教えられたことはないな。ちまたのプロジェクトマネジメント入門的な書籍もWBSまでで終わってることが多い。

進捗管理の基本はクリティカルパスをきちんと管理することだ。

クリティカルパスとなるような重要なタスクさえ抑えれば、他のタスクはクリティカルパスから追跡できる。

そういう考え方をしていないリーダーがいた。

つまり、Excel上で、タスク一覧をこねくり回しても何も進まない。

では、どうやると治療できるのか?

一つの案では、連関図法のように、タスクを付箋紙で全て書き出して、グルーピングして、先行・後続でつなげていく、という作業を何度か経験すればいい。

そうすれば、タスクをグルーピングして依存関係を考えるうちに、このタスクも必要だから付け足そう、このタスクは他のグループにまとめたほうがいい、とか、これらのタスクは並行で稼働させたらメンバーを有効活用できる、とか、色々気づくはず。

あるいは、インフラ担当のメンバーが1人しかいないので、彼のタスクは全てクリティカルタスクになってしまう、とか、担当者のタスクが溢れている、とか分かれば、早めにメンバー確保するとか、色々対策を打つはず。

なるほど。次の機会で試してみたい。

最近わかってきたけど、どうもある種の人には専門家が「それは~の理由でできないんです」と丁寧に説明して...

最近わかってきたけど、どうもある種の人には専門家が「それは~の理由でできないんです」と丁寧に説明してもそれは善意でいってるのではなく「やりたくないから誤魔化しているだけだ」と捉える部分があって、そういう人はどんな適当な方法でも「私ならできます」という商売人の方を好むんだろうという

@iiduna_yutaka

この発想のお陰でとんでもない事になっているシステムは結構ある印象。

プロは軽々しくできるって言わないのだ。

炎上したプロジェクトで見たあるプライムベンダーの思い出

でも、プライムをやるって、こういうことなんだぞ、ということを間近に見れたし、もし仮に自分がプライムをやるのならばそうしようというモデルも学べた。もうあの体験は一度だけでいい。知ると知らないのでは大違いだ。だから、プライム案件、顧客と直接契約し、構築案件をやりきる企業というのは、そういう矜持を持っているのが前提であり、そうでなければ、プライムベンダーなど目指すべきでもないし、いずれ炎上案件にぶちあたり、できないで逃亡するのがオチなんだろうと思う。

これは確かにそうかも

新卒エンジニアが1年間で得たベストプラクティス

一年目でこれはすごい

一番文句言われなさそうな React コンポーネントの書き方

・function vs. アロー関数 -> アロー関数

・型は基本的に VFC でつけて、 children が欲しい場合は明示的に props に追加する

・return を省略するか -> しない

・props を destructure するか -> しない派だったけどした方がいい気がしてきた

「今から無理してVimやEmacsを使うと消耗するから素直にVSCodeやJetBrainのIDE使ったほうがいい VimやEmacsの...

「今から無理してVimやEmacsを使うと消耗するから素直にVSCodeやJetBrainのIDE使ったほうがいい VimやEmacsの宗教戦争をするのは馬鹿馬鹿しいのでやめろ」というかなり本質的なガイダンスを受けて感動し、この教員を全面的に信頼していくことを決意

@SnO2WMaN

昔から使っていて既に馴染んでいるみたいな事情もないのに、Vim/Emacsを使い始めるのはただのイキりでしかないし、正直イタいだけなので止めた方がいい。

接触確認アプリ「COCOA」の不具合の発生経緯の調査と再発防止の検討について

事態の分析と説明は必要とは言え、不毛な仕事だ

コードリーディングのコツは極力コードを読まないこと

インターフェイスだけ理解して、実装は極力読まないことが巨大なコードベースの理解には必要ということだな。

そこらへん意識していないと、ついつい全部読もうとして「無理です」ってなっちゃう。

IPFS入門

匿名ではないWinnyみたいな印象

Connascence:コードの結合度を測るもうひとつの指標

コナーセンス(Connascence)とは、1992年にMeilir Page-Jones によって考案されたソフトウェア品質指標で、それまでの結合メトリクスを改良して、オブジェクト指向言語用に再構築したものとなります。

静的なコナーセンス: コードレベルで生じる結びつき
    名前のコナーセンス Connascence of Name (CoN)
        他方のコンポーネントが持つ要素の名前(メソッド名など)を参照している状態
    型のコナーセンス Connascence of Type (CoT)
        他方のコンポーネントが持つ要素の型を知っている状態
    意味のコナーセンス Connascence of Meaning (CoM)
        複数のコンポーネントが特定の値の意味を共有している状態
    位置のコナーセンス Connascence of Position (CoP)
        メソッドのパラメータ順序などを知っている必要がある状態
    アルゴリズムのコナーセンス Connascence of Algorithm (CoA)
        他方のコンポーネントがどんなアルゴリズムを用いているかを知っている必要がある状態
動的なコナーセンス: 実行時に生じる結びつき
    実行順序のコナーセンス Connascence of Execution (CoE)
        他方のコンポーネントを利用するにあたって、メソッドなどの実行順を知っている必要がある状態
    タイミングのコナーセンス Connascence of Time (CoT)
        他方のコンポーネントを利用するにあたって、実行タイミングなどを知っている必要がある状態
    値のコナーセンス Connascence of Value (CoV)
        コンポーネントが持つ値同士が関連していて、同期をとって管理する必要がある状態
    アイデンティティのコナーセンス Connascence of Identity (CoI)
        複数のコンポーネントが、個別具体のインスタンスを共有している状態

開発手法は、実験を交えて変えていく。〜エンジニアのマネジメントどうしてる?

何故エンジニアには性格悪い人が多いのか

ヤバい現場から生き延びたサバイバーが多いからでは。

最近まで心理的安全性を担保された状態で優秀なエンジニアになれるような就業環境がほとんどなかった。

最近思うことは性格の悪い人がエンジニアになるのかエンジニアをやってると性格が悪くなるのかが疑問です。

何故かちゃんとエンジニアやってる人って効率重視だからなのか分からないんですが偉い口調強かったし高圧的だったり出来ないだけで煽ってきたりみたいな人多いんですよね。なんででしょうね?

@HayashiHaNemui

@poyonum

性格がいい奴は他人のお守りでしゃぶり尽くされて早々に退場するからでは?

RACIとは?RACIチャートで管理部門の業務責任を可視化した話

メンバーが増えると出力が落ちる「リンゲルマン効果」と対策としてのDRI

一方、アップルではスティーブ・ジョブズの時代から「DRI」(Directly Responsible Individual)という責任の所在の明確化を行なってきたことで知られています。直訳すると「直接責任を負う個人」です。DRIはアップルの社内用語が外部でも広まったものと言われています。アップルの地図アプリの混乱で解雇されたのは、まさにDRIだったのではないかと思います。

DRIを運用する組織では、プロジェクトの大小を問わず、それぞれ特定個人が責任者にアサインされ、プロジェクトの推進や必要なリソースの確保といったことに責任を持ちます。そのように担当を明確にしないと、いわゆる「ボールが落ちた状態」になることがあるからです。担当者がいくらたくさんいても、誰もが最終的な責任者ではないと考えていれば、物事の進捗は止まりがちになります。中途半端な状態を成果として出すことにストップをかける人もいません。品のない言葉ですが、DRIは日本語だと「ケツを持つ」と言い換えられるかもしれません。ただ漠然とした「トップが責任を持つ」という話とは違い、粒度を細かくしてタスクやイニシアティブについて責任者を明確にする、というのがポイントだと思います。

DRIの発展型として、RACI(レイシー)というフレームワークも良く使われます。私は大組織の中の6人のチーム(+社内の他部署関係者)で使ったことがありますが、膨大なタスクと錯綜する役割がクリアに可視化できる便利なものだなと感じていました。

RACIは、Responsible(実行責任者)、Accountable(説明責任者)、Consulted(協議先)、Informed(報告先)の頭文字をとった略語ですが、それぞれのプロジェクトやイニシアティブに対して4つの役割別に人をアサインするやり方です。実行責任を負う人は1人ですが、それに加えて説明責任を負う承認者、専門家として協議するものの実行自体や成果の責任を負わない人、進捗報告を受ける人といった4種の役割をアサインします。必ず全部埋める必要はありません。

なぜ「データ分析力」ではなく「データ活用力」が必要なのか? これから身につけるべきスキルとは

グーグルが報告した手練れのハッキング集団、実は欧米の工作員

グーグルは、世界で最も評価の高いサイバーセキュリティ事業を複数展開している。例えば「プロジェクト・ゼロ(Project Zero)」はまだ発見されていない強力なセキュリティ脆弱性を発見するチームであり、「脅威分析グループ(Threat Analysis Group)」は北朝鮮や中国、ロシアなどの政府が支援するハッキングに対し、直接対抗措置を取るチームだ。これら2つのチームが、最近、思いがけず大物を捕らえた。11件の強力な脆弱性を悪用してiOSやアンドロイド、ウィンドウズ・デバイスを危険にさらす、「手練れ」のハッキング集団だった。

MITテクノロジーレビューは、問題のハッカーたちが、実際には対テロ作戦を積極的に実施している欧米政府の工作員である事実を突き止めた。グーグルがその攻撃を阻止して公表すると決定したことについては、グーグル社内でも反発が起こり、米国と同盟国の諜報コミュニティ内部からも疑問の声が上がっている。

Goに三項演算子が採用されない理由

なるほど。

それはさておき、Pythonの三項演算子なんとかしてもらないだろうか...

我々世代が、技術の進化とともに学んできた内容が、教え子たちにとっては「基礎知識」として一気に...

1980年代半ばからプログラマやってて、1998年から専門で教え出したんですが…

我々世代が、技術の進化とともに学んできた内容が、教え子たちにとっては「基礎知識」として一気に学ばなきゃならない。

正直、可愛そうでした。

クラサバやDBなんて1998年でも専門技術だったのに、今じゃ基礎中の基礎。

@eldritch8

それはどんな分野でも同じだからなぁ

新感覚!メソッドチェーンでアニメーションがスラスラ書ける「Tween24.js」を作りました

「課題解決」を目指すと「個人の能力不足」に焦点が当たるのでメンバーシップ雇用では色々厳しい

なんで「課題解決」よりも「お気持ち」が重視されるのかなーと考えてた

- 人事権が無く、解雇規制も厳しい(と勘違いしている)ので、不和になった人を部内に抱え込むと生産性が激減する

- メンバーシップ型雇用で人事異動で横滑りしてくる人は専門家ではないので、仕事ができないのが当たり前

@tokoroten

メンバーシップ型雇用で横滑り人事異動してくる環境では、「仕事ができないのが当たり前」であり、この環境においては、「課題解決」を目指した瞬間に人事制度が崩壊する

メンバーシップ型雇用の人事制度をアンタッチャブルだと思いこんでいると「課題解決」よりも「お気持ち」になる

こんな感じ?

@tokoroten

横滑り人事異動で「仕事ができないのが当たり前」の環境で「課題解決」を目指したら、問題の原因の大半が、個人の能力不足に帰結されちゃうんだよ

そりゃ、課題解決を目指した瞬間にチームに不和が生まれて、生産性が激減する

だから、消極的に何しない現状維持による時間解決が好まれる

@tokoroten

「心理的安全性」という言葉は誤解を招くという話

心理的安全性、名称が誤解を招きやすいと思っていて、事実ベース会話耐性みたいな感じだと、わかりやすそう。

@kaerusanu

名前的に感情側面なんだけど、タフネスだったり踏み込みだったりが必要な感じ。

@kaerusanu

論理タイプからの見え方すぎて誤解しかない感じ。

@kaerusanu

仲良くなると事実を話せるタイプと、仲良くなると相手の気持ちいいことを話したいタイプがいるから認知ずれに気がつかない

@kaerusanu

仲良くなったからなんでも話せる(気持ちいい事を)というタイプはかなり多いかと

@kaerusanu

相手へコミットとして、相手が高まる会話をするので、事実ベースタイプと話すとずれるずれる

@kaerusanu

事実ベース会話可能関係性かな…長い

@kaerusanu

事実ベース対話可能心理的安全性かな

@kaerusanu

問題解決マンは、会話の目的が自動的に問題解決に設定されるんですが、ほとんどの人はそもそも目的が違うのです。仲良くなりたいとかだと、そもそも話がずれていく。

@kaerusanu

私も、問題解決か、概念の発見みたいな目的設定がされることが多く気をつけようと思っています。

@kaerusanu

この話の終着点は、ロジックバンザイ!事実ベースの会話が正しいという話ではなくて、感情も含めた現実をどうすれば認知できるのか、上手くプレイングができるのかです。

@kaerusanu

GPUに比べて最大15倍高速な市販CPU向けのディープラーニングアルゴリズムが開発される

Shrivastava氏率いる研究チームはディープラーニングの学習を「ハッシュテーブルで解決できる検索問題」と捉え直すことによって、演算自体を市販CPUに最適化した学習アルゴリズム「Sub-Linear Deep Learning Engine(SLIDE)」を開発。このSLIDEがGPUベースの学習よりも優れたパフォーマンスを発揮することを示しました。

研究チームはCPUこそがコンピューティング関連で最も普及しているハードウェアである点に触れて、CPUを用いた機械学習にはコスト面の利点があると指摘。「行列の演算に固執しないSLIDEを使った場合、GPUの4~15倍速い学習速度をCPUで達成した」と語りました。

1 番「軽い」やつはどれか? Kubernetes ディストリビューション比較

・k3os 上で動く k3s はメモリ 1 GB で動いたので最軽量。専用 OS もあり設定も簡単。

・k0s はメモリ 1.5 GB で動いた。充分に軽い。設定は簡単だが、 Alpine の場合がやや面倒だった。

・minikube はデフォルトでメモリ 2.2 GB 。何も設定しないでコマンド1つインストールできるのは一番楽。

なるほど

仕様整理のためのテスト設計入門をJaSST'21 Tokyoで発表しました

『データ分析のための統計学入門』PDFが無料公開 データサイエンティストたちが執筆

MSA化レベル定義 - 低レベルなマイクロサービスはただのファイル連携と見分けがつかない

未経験にRailsをお勧めしてた企業の方や個人事業主の方々...

未経験にRailsをお勧めしてた企業の方や個人事業主の方々。

発言の責任取って、彼らを採用してあげて。

なんかそろそろヤバい空気漂ってる気がしてきたわ。界隈。

@WjgotINrU14Z1fB

NEXT PHPとかNEXT VB6の称号はRoRに頭上に輝くのだ

マイクロサービス時代のセッション管理

2. 中央集権型

①の独立型と似ていますが、セッションストアを共通化したパターンがこちらです。認証サービスがユーザー認証情報をセッションストアに保存し、各マイクロサービスはセッション ID を用いてセッション情報をストアから読み出します。この場合クライアントから見たログイン回数は1度になるほか、セッション ID のリボークも容易になるため、セキュリティインシデント時の対処もしやすいです。一方セッションストアは多くのサービスからのリクエストを受けるため、高い可用性が求められます。

社内システムor限定されたユーザーに提供するシステムなら中央集権型システムで十分だよなぁ

ソフトウェア開発は敗者のゲームです

発注側は無能になりやすい

最近の課題として「発注側は無能になりやすい」というのがあると思っていて・・・。

発注側は自分で作れない、考えられないから外に依頼するけど、良し悪しの判断やフィードバックする能力もない時が多いので、変な発注をしてしまったり、質を下げる方向に向かったりしてしまうという。

@kensuu

一方で、受注側はお金をもらっているので、最終的にはクライアントのやりたいようにする、というのが一番になってしまう、と。

このあたりを解決するヘルシーな方法ないかなーと考え中です。

@kensuu

プロジェクト初期は理想日見積もりし、徐々に相対見積もりへ移行する

パフォーマンスが5倍の難易度高めな言語を選択するよりも、採用の裾野が広いメジャー言語を選択して...

パフォーマンスが5倍の難易度高めな言語を選択するよりも、採用の裾野が広いメジャー言語を選択してインフラは金で殴る戦略が好きです

※水平スケーリングが適用できるアーキテクチャに限る

@andoshin11

同意

データガバナンスとは?DX推進のために取り組むべき実践集

  • 1.データガバナンスとは?
    • 1-1.データガバナンスは、データ利活用の推進にあたり守るべきルールををつくり、守らせること
    • 1-2.データガバナンスなしではデータのサイロ化が起きてしまい、DX推進が出来なくなる
  • 2.データガバナンスの実践に役立つフレームワーク3選
    • 2-1.DMBOKホイール(Data Management Association International)
    • 2-2.データガバナンス成熟度モデル(Gartner)
    • 2-3.データマネジメント成熟度モデル(CMMI Institute)
  • 3.いますぐ取り組むべきデータガバナンスの実践例10選
    • 3-1.重要なKGI/KPIは自由な集計を禁止とし、ユーザーにはBIシステムを使わせる
    • 3-2.ユースケースが曖昧なメタデータは整備させない
    • 3-3.データ品質の要求を5W1Hで定義し、むやみにデータ品質管理ツールを導入させない
    • 3-4.データ品質を破壊する社内外のシステム変更をコントロールする
    • 3-5.データモデリングには口出しせず、データが検索できることを担保させる
    • 3-6.データの可用性・完全性・性能をレポートさせる
    • 3-7.個人情報の流出への対策を最優先で実行させる
    • 3-8.データ利活用のために収集したデータの統合先(サーバー、ストレージ等)を1箇所に限定する
    • 3-9.個人情報がどこに保存されているか台帳で管理する
    • 3-10.マスタデータ管理は真っ先に取り組む
  • 4.まとめ

ER図でもUMLでも、ホワイトボードやその辺の裏紙や紙ナプキンに手描きするのが本来の使い方なので...

ER図でもUMLでも、ホワイトボードやその辺の裏紙や紙ナプキンに手描きするのが本来の使い方なのであって、立派なツールを使って清書するように描くからガンとハードルが上がって、遂には手段と目的が入れ違うのですよね。

@ohtsuka

「UMLを使うこと」自体が目的になってしまっていて、UMLの細かい記法に関する指摘ばかりで本質的なレビューをしてくれない人結構いた。

決着したと思われていたSCO・Linux論争が再燃

筆者には、SCO GroupがIBMに対して起こした、IBMがUNIXのソースコードを違法にコピーしてLinuxで使用したと主張する訴訟について17年以上に渡って取材を行ってきた。この訴訟やその関連訴訟については、これまでに500本以上の記事を書いてきた。筆者はこの問題は既に終わり、過去のものになったと思っていた。しかしその考えは間違っていた。2011年にSCOのUNIX製品と知的財産を買収したXinuosが、IBMとRed Hatを相手に「Xinuosのソフトウェアコードを違法にコピーして自社のサーバーOSに使用した」と主張して訴訟を起こしたのだ。

UnXis(現在は社名がXinuosに変更されている)は当時、SCOが行っていた無意味な訴訟には関心がないと明言していた。2016年には、同社の最高経営責任者(CEO)であるSean Snyder氏が「私たちはSCOではない。私たちは投資者として製品を買収しただけだ。IBMに対して訴訟を起こす権利を買収したわけではないし、それには全く関心がない」と述べている。

しかし今や、同社は苦境に立たされているようだ。Snyder氏は「当社の『OpenServer 10』のようなFreeBSDベースのシステムは、市場から排除されてしまっている」と述べている。

現在のSnyder氏は公式声明の中で、「本件はXinuosと当社の知的財産の盗難に関するものだが、消費者や競合他社、オープンソースコミュニティー、そしてイノベーションそのものに損害を与えた市場操作に関するものでもある」と主張している。

IBMの広報担当者であるDoug Shelton氏は、これに対して「Xinuosの著作権に関する主張は、破産に至って同社に著作権を売却した先行者の陳腐な主張を焼き直したものであり、無価値な議論だ。IBMと世界最大のオープンソース企業であるRed Hatに対して提起されたXinuosの反トラスト法に関する申し立ても、同様に論理的ではない」と反論している。

実に見苦しい

[速報]10年にわたる著作権訴訟でGoogleがオラクルに勝訴、米連邦最高裁判所で判決。Java SEのコードの...

オラクルがGoogleに対して、Android OSがJavaの著作権を侵害しているとして訴えていた裁判で、米連邦最高裁判所はGoogleが著作権侵害をしていないとの判断を示し、Googleが勝訴しました。

よかったよかった

〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録

求人サービス「engage」の画像・動画が全て消失、復旧できず 原因は不正アクセス

エン・ジャパンは4月2日、求人サービス「engage」が不正アクセスを受け、サーバ内の画像・動画ファイルを保管するフォルダが何者かに削除されたと発表した。データの復旧も不可能としている。

engageは、求人サイトの作成などが行える企業向けサービス。消失したデータの件数や不正アクセスを受けた時間帯は非公開だが、すでに外部からのアクセスは遮断済みという。個人情報を管理しているサーバにはアクセスされておらず、情報漏えいは確認していないとしている。

エン・ジャパンは今後、第三者機関と共同でセキュリティ対策を確認する他、データの定期的なバックアップなどを行い、再発防止に努めるとしている。ユーザー企業に対しては、画像や動画の掲載状況を確認し、必要があれば再設定するよう呼び掛けている。

あらら...

プログラマがコードだけ書いてりゃ良い時代は、とうの昔に終わったからねぇ

プログラマがコードだけ書いてりゃ良い時代は、とうの昔に終わったからねぇ。

ドメイン知識が無い人は、市場で値段つかないよ。

偏差値なるものに翻弄されてきた学生さんたちには、ピンとこないかもしれないけれども。

@monamour555

特定派遣/SES界隈ですらそれこそ20年近く前から言われている話で今更感がある。

その界隈では「業務SE」みたいな謎の呼称だったけど。

これは、その界隈で使われる技術がコモディティ化して人材が飽和してくると「業務」に詳しいことが差別化や有用性のアピールになるという話でしかない。

そもそも「プログラマがコードだけ書いてればいい」という世界観自体20年〜30年は遅れた感覚で、20年前でさえアジャイル開発で顧客と一緒に開発を進めようとか、内製回帰みたいな話はずっとあった。

エンジニアって単価や給料が上がれば上がるほど労働の辛さが逆に下がるバグある

俺の経験則でしかないがエンジニアって単価や給料が上がれば上がるほど労働の辛さが逆に下がるバグある

儲かってる良い会社だと、もはや労働の辛さより面白さが上回ることもある

つまり、単価や給料の安い会社はカス

@yamaemon_jp

最新の技術やアーキテクチャへの挑戦はエンジニアにとっての福利厚生である。そして、福利厚生は儲かってる会社ほど潤沢に投資できる。更に本業が儲かっているなら挑戦が少々失敗しても「戦略的投資」で片付けることができるのでシビアに評価されることもない。

というわけで、利益は全ての痛みを麻痺させてくれるのである。

Front-End Study #5「2020年代のフロントエンド」

よいミーティングの作り方

プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ

これは確かにその通りである。

抽象化を理解できないプログラマはいつまで経っても初心者レベルから脱却できないという話

しばしば「初心者向けの言語」と宣伝される言語がある。 たとえば、BASIC, HSP, PHPなどがそれにあてはまるようだ。

これらの言語にはなんらかの共通項があって「初心者向け」と考えられている のだと思う。つまり、初心者にアピールする特質を抽出できれば、 その特質を他の言語に付与することも、あるいは可能かもしれない。

で、これらの言語の仕様(文法や組み込みの機能)について思い返してみると

  • 機能は手続きベースでフラット
  • データ構造をユーザー定義する機能がない、または強調されない
  • モジュール化機能がない、または強調されない

というような感じに思える。PHPに関しては最近はオブジェクト指向機能も備えて Java化しつつあるけど、機能が関数ベースでフラットな点は依然として事実だ。 また、PHP使いには「関数化すること」や「オブジェクト指向機能を使うこと」への 抵抗感が強い人がそれなりに観測されるようだ。

ここから「初心者向け言語が避けていること」言い替えれば 「初心者が苦手なこと」が何であるかだいたいわかる。 彼らは「抽象化」が苦手なのだ。

関数がなければ、あらゆる機能はプリミティブの組み合わせをたどっていくだけで (原理的には)理解できる。ある意味、安心だ。

私がなにか大きな買い物をするとしよう。 平均的サラリーマンが購入する一番高額なものといえば住宅なので、 家を買うことを考えよう。 新築であれば、土地と建物で3000万とか4000万とかかかるのではないだろうか。

では、私はこの家を素人に立ててもらいたいだろうか。 現場に行ったら職人がどれもこれも、専門教育も受けていません、修行もしていません、 先月までは関係ない職業でした、とかいうような人の集まりだったら。

私はイヤだ。

が、ソフトウェア開発ではそれに近いことが平気でまかり通っている。 ソフトウェア開発現場には「自称初心者」がたくさんいるし、 そのような人でも開発に投入するために「初心者向け言語」が重宝される。

本当はそんな初心者を現場に投入してはいけないはずだ。 建築業界でもあまり良くない噂を聞くことはあるが、 それでもここまでではないはずだ。 ソフトウェアを設計するのに「建築士」のような資格は不要だし、 大工や左官に比べてソフトウェア開発者の技能のありなしを明確に判別する手段もない。

コミット対象をよりわけるのをやめてみよう

テストの自動化とテスト駆動開発

実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜

エンジニアにロジカルな人は多いか?

そんなにエンジニアの人ってロジカルか?人によると思うんだけど。

相手に話が通じないのを、自分がロジカルだから相手はロジカルじゃない、って思ってるのかな。

@bombombomb2017

自分の印象としてもロジカルな考え方をするエンジニアは少ないように見える。

少なくともロジカルに根拠を説明できる人は希少。

大抵はネットや書籍の情報をコピペしてきているだけで、「何故そうするのか」「他に方法は検討したのか」というような質問をするだけでバグってしまう人が多い。

だから有効な議論が成立せず、感情的になってしまうか、そもそも議論には参加しない(聞いてるだけ)な人が多い印象。

Elasticsearchで関連キーワード機能がどれだけ低コストで実装できるかの旅路

トーバルズ氏が考える、LinuxにおけるRustの居場所とは

privateメソッドをテストしたい

ユニットテストを書きたいほどprivateメソッドが育ってしまったら、自分なら別クラスとして独立させるかな。

privateクラスのロジックは切り出したクラスに移植&委譲させて、テストは新しく作ったクラスで行う。

ブリッジパターンとかストラテジーパターンみたいなイメージだ。

デジタル化の流行と「上流工程」の終焉

pipとpipenvとpoetryの技術的・歴史的背景とその展望

とりあえずはpoetry使っとけばよさそうなのね

メルカリのデータドリブン文化を支える、データプラットフォームとデータマネジメントの話

PHPerKaigi 2021 スライドまとめ

あとで目を通そう

真面目なこと言うと、プログラミング初心者はC言語とJavaをマスターすれば、他の言語を...

真面目なこと言うと、プログラミング初心者はC言語とJavaをマスターすれば、他の言語を学ぶ時に応用が効くのがおすすめ

@SymboliRudolf6

開発環境を用意するにしても中古のWindowsマシンでメモリ16GB積めば問題なく開発できるし、統合開発環境がタダで使えるのがありがたい

@SymboliRudolf6

専門的な話をすると、C言語で構造化プログラミング、Javaでオブジェクト指向型プログラミングがそれぞれ学べるので、SI系&Web系どちらにも潰しが効くので、駆け出しさんでも家電量販店送りになることなくプログラマーになれる。

@SymboliRudolf6

【おすすめの技術書】

>C言語

1.新・明解C言語 入門編

2. 新・明解C言語 中級編

>Java

1. 新・明解Java入門 第2版

2. 新・明解Javaで学ぶアルゴリズムとデータ構造 第2版

どっちもAmazonで買えます

@SymboliRudolf6

あまり同意できない。

C言語はポインタで躓く人が多いし、SI系やWEB系では最早使われていないように思うのだが。組込み開発系の現場に叩き込まれることを想定しているのだろうか?

Javaについてはまぁいいのではと思うけどそこは別にPHPでもいいんじゃねという気はする。

案件の数を考えてもとりあえずPHP覚えておけばエンジニアとしてキャリアを始めることはできそう。

自分ならSI/WEBどちらにも対応できるという点を考慮したとしてもPHPとJavaScriptを勧めるかな。

機械データ向けの分散型SQL「CrateDB」がオープンソースに

CrateDBは”機械データ向けのSQL”を標榜する機械データ向けに構築したデータベース。NoSQLの柔軟性と拡張性とSQLの使い勝手を加えたもので、ANSI SQL、JSON、全文検索、ダイナミックスキーマなどの機能を持ち、データやユーザーの増加に合わせた拡張性を備える。Azure IoT Hub、メトリックを収集するTelegrafなどのツールと統合できる。これを利用して、大量のデータの処理、保存、クエリ、分析などがリアルタイムでできるという。自己実装の他、オンプレミス、Microsoft AzureやAmazon Web Servicesなどの任意のクラウドで実装できる。

ふーむ

ブラウザ上でCSVファイルをパースする

へー

面接される/する両視点からみる エンジニア面接

マンガではわからない ソフトウェア開発の真理

プロダクトマネジメントと事業開発に関する私的な振り返り

力作だ

レビュアーにやさしいリファクタリングPRを作る

サイズ小さめで目的がはっきりしたPRを作るというのは理解できるんだけど、そのPRをマージした後はどうしているのだろう?

即座にテストとリリースまで持っていくのか? それともリリース予定ブランチ的なところへキープしてある程度溜まったら or 何かしらの機能リリースと一緒にリリースするのか?

後者の場合、masterブランチなどにマージする際はコードレビュー不要? それとも別の観点(マージされるファイルに過不足がないなど)でレビュー?

複数のPRの変更が集められるなら結局はそれら全体の整合性を確認する為のコードレビューが必要になるのでは? そうなると結局は巨大なPRになるので、小さなPRを作った意味とは? みたいになる気がする。

リモート会議は最大30分にしよう

確かにアジェンダが事前に共有されていれば30分で終わるようなことばかりだし、会議でダラダラ議論する意味もない。

リモート会議事前にアジェンダを共有し、会議が不要なものは会議前に回答しよう

会議の前にはアジェンダを共有せよ

会議の所要時間を決めて効率化を図っているように見えますが、「会議の趣旨を伝えずに始めてしまう」ということがあるあるのようです。「事前にアジェンダを共有する」などの準備作業が欠落している場合が多く、テーマの共有から始めなければいけなくなって、必然的に質の低下を生んでしまいます。

オフィスにいないことが災いして、一方的に「とりあえず会議の時間は確保しておいてね」の一言で準備なしにスタートしてしまうと、その場でアイデアをゼロベースから練るなんてこともしばしば。ゴールまでの道筋をみんなで追うための会議なのに、その意義が薄れてしまっているような気がします。逆に、「チャットで済んだ話なのに、議題に挙げた意味があったのか?」のような肩透かしを喰らうこともあります。

チャットで解消される疑問だったにもかかわらず、会議という「時間設定されたもの」になることでタイムラグも生じるとなると、リモートワークの進め方としては建設的ではないなと感じてしまいます。

ほんまこれ

IT業界を始めとした多重下請け構造で、中抜きしている企業の業務、存在価値は何ですか?

そのような構造にすると営業がしやすいです。

多数で多様な最終顧客に新規営業をして、要件を聞き、見積をして、価格や機能を交渉して、契約をまとめて、納品するまでの数ヶ月から数年待って回収するため、そのための資金の手当をするのは大変です。

大規模なシステムを提供しようとすると最初の1円が入ってくるまでに半年とか1年とかを使ってしまいますし、作ったところで回収できるかどうかも定かではありません。

多重請負構造の下請け企業は少数の話の通じる会社にだけルート営業をしてだいたい相場で労働力を売ることができ、すぐ回収できますので安定した経営が可能になります。安定してるので求人をかけることができます。求人広告はSESの企業であふれかえることになります。

技術者としても、話す相手が技術者になるので気楽です。同業者同士で事情を理解してて言葉も通じるほうが仕事がやりやすい人も多いです。

私の会社は、私が多重請負構造は嫌いなので、下請けの仕事は義理でもなければやらないですし外注に出すこともしません。企画から運用まで一貫してやります。

つまり、営業でも技術者でも、イヤなら別にあなたがそんな構造につきあう必要はないです。そういうことをしてる人たちがいるというだけのことです。

過大評価されるDDD(ドメイン駆動設計)

DDDの戦略的次元では、最も頻繁に使用されるツールは、コンテキスト境界(bounded context)という概念です。それぞれが小さいユニットに割り当てられるべきという概念です。これは素晴らしいアイデアです。これも(もちろん)DDDの発明ではありません。単純にモジュール設計であり、文字通り何十年にもわたって大規模なシステムを設計してきた人たちによって適用されてきたものです。それはつまり、コンテキスト境界(bounded context)の概念に何か間違った点があるということでしょうか。いいえ。実際には、しばらくの間存在し、その価値を証明してきたものに名前をつけるのがパターンの目的です。私は、コンテキスト境界というものには欠点があるということを言っているのではありません。私が指摘しているのは、誰かがこの特定のラベルを使わずに、あるいはこの特定のラベルを知らずに、システムのために素晴らしいデザインを作ったかもしれないということです。

LabTech企業の初代PMになってやってきたこととこれから

useEffect完全ガイド

データサイエンティストの終わりなき戦い

  1. データサイエンティストvs神エクセル
  2. データサイエンティストvsゴミデータ
  3. データサイエンティストvsパワーポイント
  4. データサイエンティストvs有効数字
  5. データサイエンティストvs外部とのデータやり取り
  6. データサイエンティストvs聴衆の背景知識
  7. データサイエンティストvs不正行為

“手法の戦争”と“手法の監獄”から抜け出す ソフトウェア開発の本質を捉えるEssenceとは

【解説】IKE(IIJ Kubernetes Engine):= Vanilla Kubernetes + 何?

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

個人的には、ドメイン層のファサードとしてのServiceとアプリケーション層のファサードとしてのServiceが混在してしまうのがよくない点と感じている。

Serviceはドメイン層のファサードに徹するべきで、アプリケーション層の仕事は別の名前を与えるべきではないかなと。

とはいえ、何がドメイン層で何がアプリケーション層なのか明確に分解できないものはそこそこあって、それが話をややこしくしているわけで。

現状では「これはドメイン層の仕事ではないかな?」と思えるものはメッセージキューに投げてサブシステムに逃がしてしまうのが現実的な落とし所ではないかと思っているのだが。

関連

Essential UML とか

この辺の話ってその後どうなったんだろうか...?

ミニマルなソフトウェア開発管理

わたしも何だかんだでキャリアが10年を超えてしまい、いろいろなソフトウェアの開発管理を見てきたが、上手くいったときの体験を思い出して、最低限これだけやっとけばいいんじゃないかというポイントが見えてきたように思う。世間にはいろいろな管理手法が提案と実施されているが、どれも大袈裟だと感じていた。上手くいくために最低限必要な要素を押さえて、30分くらいで理解と実施ができるミニマルな手法をここでまとめてみたい。

何れにせよ、見習いレベルに到達するだけでも、色々とやることは多い。

何れにせよ、見習いレベルに到達するだけでも、色々とやることは多い。

@ellnore_pad_267

で、枝葉の技術(フロント周り)ばっかやってて、

SQL解らんデータモデル解らんデータフローガン無視でドキュメンテーションも疎か。

そんな奴正直開発メンバとして入れたくないってのが本音。

@ellnore_pad_267

なぜGoogleはメインの開発言語をHaskellではなくGoに替えようとしているのでしょうか?Goには大した利点...

Goは、原始的な静的型付けの言語ですが、シンプルで徹底的に実用性を重視した言語です。

乗り換え

C系列の言語なので、C++/Java/PythonからのGoへの切り替えは長くてもせいぜい数週間です。Heskellへの乗り換えには比較的長い時間がかかります。

自社による管理と社内テスト

GoogleはGoを所有しているので、言語を思い通りに変更できます。

互換性

GoはJavaをシンプルにして並列性を高めたものです。静的型付けによりパフォーマンスが向上し、Pythonよりもリファクタリングがしやすいです。Goのほうが開発者人口が多いです。gofmtはコーディングスタイルのつまらない議論に浪費する時間を減らし、高速なコンパイル時間は巨大なソースコードの開発サイクルを早めます。

GoogleがHaskellを使うと何がよいのでしょうか?

ジェネリクスですか? Googleは社内で広くプロトコルバッファを使用しており、恐らくごく一部のオブジェクトのインターフェイスだけがブルートフォースできるでしょう。

正確さですか? Googleは、厳しい人材採用基準、テスト、コードレビュー、インフラ計測など、他の様々な方法で正確さを確保しています。

一方で、Haskellにはスペースリーク、出来の悪いツール(相対的に見て)、遅延評価の問題、無駄なコーディングスタイル論争の機会、開発者の学習カーブの高さなどの問題があります。

Googleは社内で広く使う言語を変えることに関しては非常に保守的です(たくさんのドメイン固有言語DSLを作っていますが)。スティーブ・エッゲはGoogleでRubyを使おうとして それを痛感しました。

要するに、開発に使用する言語の数を絞るというGoogleの決定は、実はとても賢い選択です。最初の数週間はストレスがたまるかもしれません(お勧めしませんが、(現在他社で働いている)私に履歴書を送ってみませんか?)、そして私のような不器用な人間には納得するまでに時間がかかるかもしれません。しかしプログラミング言語には誰もが知っているコアとなる基本機能があり、そして不明瞭なセマンティクスをその後に学んでいくことになり、だんだんと理解が難しくなっていきます。Perl、Python、Rubyなどの類の、オブジェクトの定義が事前に定まらない動的言語は特に難しいです。Googleは言語数を慎重に絞ることで、選んだ言語の専門家集団を社内に作り上げることができます。

また言語の異なるコンポーネントの互換性を確保するために必要な組み合わせの爆発を抑える必要もあります。私がこれまでに在籍していた会社はこれが大きな負担になっていましたが、Googleではこれをほぼ最小限に抑えることができています。

Googleは開発者がグループやオフィスを非常に簡単に移動できる環境を整えています。もちろん大人の対応が求められ、ピンチだからといってチームを見捨てて別のチームにさっさと逃げたりしないようにしないといけません。しかしそんな子供っぽいことをしないのであれば、いつでも好きな時にチームを変えることができ、それで業務が止まってしまうようなことはありません。私がこれまでに在籍した別の会社にはこのようなポリシーがありませんでした。

Google社内にHaskellファンがいないということはありませんが[0]、単にHaskellではGoogleの問題に対処できないのです。

許可ではなく謝罪できるチームへ

結構な割合で責任逃れの為に許可を求める人がいるからなぁ

「許可を取ったのだから失敗しても自分の責任ではありません」的な。

また、許可不要とは言え自分のやってることの目的やスケジュールを説明する説明責任は常にあることを忘れてはいけない。

許可が不要であるという事は義務と責任も委譲されたという事なのだ。

20年代のオブジェクト指向言語

まず、新しいOO言語が持つべき、いくつかの明白な譲れないものがあります。

  • null安全
  • 安全なキャスト
  • オプショナル名前付き引数
  • ジェネリクス
  • デフォルトでイミュータブル

これらのテーマについてはすでに十分語られているので、今日はあまり説明する必要はないでしょう。

ここでは、私が個人的に新しいOO言語に望む、あまり目立たない選択肢をいくつか紹介します。

  • クラスに基づく発見性
  • 多重継承
  • ミニマル構文
  • 高階型
  • 例外がない
  • 統合されたクラスと型クラス
  • 破壊せずにパターンマッチング

これら共通しているのは、言語を純粋にOO(「マルチパラダイム」ではない)に保つことですが、関数的な機能を型システムに統合し、OO的な方法で実装することです。

Raspberry Pi 2のケースを自作する

必要部材リスト

  • 天板 個数 1
    • アクリル t3
  • 下板 個数1
    • アクリル t3
  • Raspberry Pi2支え用中空スペーサ 個数 4
    • プラスティック φ5 長さ5 mm
      • 参考: wilco製CPE-2605 スペーサー 丸型中空
  • Raspberry Pi2固定用プラネジ 個数4
    • M2.6 長さ8 mm
      • 参考: wilco製PE-0308 なべ小ねじ
  • 下板-天板支え用両メネジ x 4
    • M3 φ6 長さ25 mm
      • 参考: wilco製ARU-325 スペーサー 丸型両メネジ
  • 下板-天板接続用ネジ x 8
    • M3 長さ 8 mm
      • 参考: wilco製USLC-0308 六角穴付きスーパーローヘッドボルト

関連

ユーザーの個人情報に関する一部報道について

チームをマネジメントするときにやることの備忘録

逸脱事例を含めてすべてをレールに乗せる

抽象化の破れを発生させない・コントロールするという考え方なんだろうか

ウォーターフォールを世に広めたとされる米軍がアジャイルに移行中という話

ざっとまとめると、

コード自動生成、自動生成したものをさらに編集する運用になるとかえって面倒になるな…

コード自動生成、自動生成したものをさらに編集する運用になるとかえって面倒になるな…

思っていたほど良いものではない

@d_horiyama_web

自動生成したコードを編集してはいけない(戒め)

自動生成したコードを拡張/変更したい場合は、そのコードをラップするレイヤーを設けて自動生成されたコードには手を入れないようにするべき。

GenerationGapパターンとかAdaptorパターンなどが当てはまる。

ただし、scaffold的な雛形を生成するものはまた話が別である。

参考

Closure Design Patterns

クロージャデザインパターン

Rust風にデザインパターン23種

クロージャがあればそもそも必要ないパターンも多い。

古典的なGoFデザパタは古いJavaの言語仕様に引きづられているところが多いという問題がある。

バグを直すときに、コミットをさかのぼって、どのバージョンで入ったか確認して。どういう変更で入ったか...

バグを直すときに、コミットをさかのぼって、どのバージョンで入ったか確認して。どういう変更で入ったか確認する作業をしていた。これって本当に必要なのだろうか?

@ledsun

金融とか保険界隈のSIerがやりたがりそうな話だけど、それで意味のある教訓は得られるとは思えないんだよなぁ

精々「勘違いしてました」とか「テストケース漏れてました」とか「仕様が変わってました」程度の話で、その調査工数がそれ以降の品質向上にプラスに働くことはなさそう。

NEXT