オープンソースソフトウェアの脆弱(ぜいじゃく)性に関する論文の執筆のため、Linuxカーネルに既知のバグを含むパッチを送信したことを理由に、ミネソタ大学に対して「Linuxカーネル開発への貢献の禁止」、つまり出禁措置が行われました。
つまり、オープンソースソフトウェア（ここではLinux）に対して意図的に悪意あるコードを貢献という形で組み込めるかという研究がやりたくて、実際にLinuxカーネルメンテナで試したら即バレして出禁になったという感じか。
当然の結果だし、Linuxカーネルメンテナのレビューは適切だったという実績になるんだな。
最初にクソコードを書いた者はどんな立派な方法論者よりも偉大である。誰も表現しなかったドメインを稚拙ながらどうにか表現したのだから。最後にクソコードにクソを継ぎ足した者はどんな言い訳をしようと最低である。病人に言われるがまま酒を勧めた考えなしと同じだから。
対症療法しかできん場合もあるからなぁ
確かにコードを「しっかり」読めて、全体の整合性保全に貢献できるエンジニアは貴重。
多くの場合、ビッグバン結合キメてそこで発生した細々した問題に都度対応していくというアプローチを取りがちだけど、実はそれってかなりハイリスクなんだよな。
「保守コスト低めで生き続けるコードにしたい」
っていう意図で Go を選択するのはかなり正しいと思っている
PHP も部分的には適格だけど， Laravel を選ぶと死ぬ（PHP が +10 してくれたのを Laravel が -1000 ぐらいもっていくイメージ）
go言語の人々、見てると「とりあえず...」という感じでクリーンアーキテクチャ風の構成にしたがるけど、「それ、本当に保守コスト低くなります？？」ってなるんだよな
それなりのキャリアになると、好きか嫌いかとかカッコいいかダサいかとかじゃなく、目標に対してやるべきかやらざるべきかで考えることの方が圧倒的に多い。
ほんまこれ
HTMLの断片をAjaxで取得してページに埋め込む手法、昔はPjaxと呼ばれてた気がするなぁ
そういや，僕が関数型プログラミングで一番意味がわからないところは，「関数型プログラミングは数学的な意味での関数を使用することでプログラミングを行うこと」という感じの説明がされてると思うんですけど，Printf.printf とか数学的な意味での関数じゃねえじゃんってなるとこなんですよね...
関係データベースでも似たような話があって、RDBモデルは数学の集合論に基づいていてだから「正しい」のです、みたいな雑な主張を見かけたことがある
数学がそれ単体で工学的な正しさを証明するということはありえないはずなんだけど、なんとなく理論が数学的に整備されていることがハロー効果的にもっともらしい印象を与えてしまっているところがありそう
そんな雑なまとめ方する奴おるんか...？
では、どこに原因があるのか？
１つの観点として、そういう人たちは、PERT図を描いた経験がないのだろうと思う。
つまり、タスクの全体の構造が見えていない。
タスク同士の因果関係、タスク同士の依存関係が見えていない。
たとえば、ガントチャートを作る前にタスクをExcelで洗い出すだろう。
しかし、Excelで縦列に並べたタスクを見ても、その先行・後続の関係や優先度はそれぞれ違う。
それらをつなげて一つのガントチャートを作った、という経験がないようだ。
確かにそこまで教えられたことはないな。ちまたのプロジェクトマネジメント入門的な書籍もWBSまでで終わってることが多い。
進捗管理の基本はクリティカルパスをきちんと管理することだ。
クリティカルパスとなるような重要なタスクさえ抑えれば、他のタスクはクリティカルパスから追跡できる。
そういう考え方をしていないリーダーがいた。
つまり、Excel上で、タスク一覧をこねくり回しても何も進まない。
では、どうやると治療できるのか？
一つの案では、連関図法のように、タスクを付箋紙で全て書き出して、グルーピングして、先行・後続でつなげていく、という作業を何度か経験すればいい。
そうすれば、タスクをグルーピングして依存関係を考えるうちに、このタスクも必要だから付け足そう、このタスクは他のグループにまとめたほうがいい、とか、これらのタスクは並行で稼働させたらメンバーを有効活用できる、とか、色々気づくはず。
あるいは、インフラ担当のメンバーが１人しかいないので、彼のタスクは全てクリティカルタスクになってしまう、とか、担当者のタスクが溢れている、とか分かれば、早めにメンバー確保するとか、色々対策を打つはず。
なるほど。次の機会で試してみたい。
最近わかってきたけど、どうもある種の人には専門家が「それは～の理由でできないんです」と丁寧に説明してもそれは善意でいってるのではなく「やりたくないから誤魔化しているだけだ」と捉える部分があって、そういう人はどんな適当な方法でも「私ならできます」という商売人の方を好むんだろうという
この発想のお陰でとんでもない事になっているシステムは結構ある印象。
プロは軽々しくできるって言わないのだ。
でも、プライムをやるって、こういうことなんだぞ、ということを間近に見れたし、もし仮に自分がプライムをやるのならばそうしようというモデルも学べた。もうあの体験は一度だけでいい。知ると知らないのでは大違いだ。だから、プライム案件、顧客と直接契約し、構築案件をやりきる企業というのは、そういう矜持を持っているのが前提であり、そうでなければ、プライムベンダーなど目指すべきでもないし、いずれ炎上案件にぶちあたり、できないで逃亡するのがオチなんだろうと思う。
これは確かにそうかも
・function vs. アロー関数 -> アロー関数
・型は基本的に VFC でつけて、 children が欲しい場合は明示的に props に追加する
・return を省略するか -> しない
・props を destructure するか -> しない派だったけどした方がいい気がしてきた
「今から無理してVimやEmacsを使うと消耗するから素直にVSCodeやJetBrainのIDE使ったほうがいい VimやEmacsの宗教戦争をするのは馬鹿馬鹿しいのでやめろ」というかなり本質的なガイダンスを受けて感動し、この教員を全面的に信頼していくことを決意
昔から使っていて既に馴染んでいるみたいな事情もないのに、Vim/Emacsを使い始めるのはただのイキりでしかないし、正直イタいだけなので止めた方がいい。
インターフェイスだけ理解して、実装は極力読まないことが巨大なコードベースの理解には必要ということだな。
そこらへん意識していないと、ついつい全部読もうとして「無理です」ってなっちゃう。
コナーセンス（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)
複数のコンポーネントが、個別具体のインスタンスを共有している状態
ヤバい現場から生き延びたサバイバーが多いからでは。
最近まで心理的安全性を担保された状態で優秀なエンジニアになれるような就業環境がほとんどなかった。
最近思うことは性格の悪い人がエンジニアになるのかエンジニアをやってると性格が悪くなるのかが疑問です。
何故かちゃんとエンジニアやってる人って効率重視だからなのか分からないんですが偉い口調強かったし高圧的だったり出来ないだけで煽ってきたりみたいな人多いんですよね。なんででしょうね？
性格がいい奴は他人のお守りでしゃぶり尽くされて早々に退場するからでは？
一方、アップルではスティーブ・ジョブズの時代から「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テクノロジーレビューは、問題のハッカーたちが、実際には対テロ作戦を積極的に実施している欧米政府の工作員である事実を突き止めた。グーグルがその攻撃を阻止して公表すると決定したことについては、グーグル社内でも反発が起こり、米国と同盟国の諜報コミュニティ内部からも疑問の声が上がっている。
1980年代半ばからプログラマやってて、1998年から専門で教え出したんですが…
我々世代が、技術の進化とともに学んできた内容が、教え子たちにとっては「基礎知識」として一気に学ばなきゃならない。
正直、可愛そうでした。
クラサバやDBなんて1998年でも専門技術だったのに、今じゃ基礎中の基礎。
それはどんな分野でも同じだからなぁ
なんで「課題解決」よりも「お気持ち」が重視されるのかなーと考えてた
- 人事権が無く、解雇規制も厳しい(と勘違いしている)ので、不和になった人を部内に抱え込むと生産性が激減する
- メンバーシップ型雇用で人事異動で横滑りしてくる人は専門家ではないので、仕事ができないのが当たり前
メンバーシップ型雇用で横滑り人事異動してくる環境では、「仕事ができないのが当たり前」であり、この環境においては、「課題解決」を目指した瞬間に人事制度が崩壊する
メンバーシップ型雇用の人事制度をアンタッチャブルだと思いこんでいると「課題解決」よりも「お気持ち」になる
こんな感じ？
横滑り人事異動で「仕事ができないのが当たり前」の環境で「課題解決」を目指したら、問題の原因の大半が、個人の能力不足に帰結されちゃうんだよ
そりゃ、課題解決を目指した瞬間にチームに不和が生まれて、生産性が激減する
だから、消極的に何しない現状維持による時間解決が好まれる
心理的安全性、名称が誤解を招きやすいと思っていて、事実ベース会話耐性みたいな感じだと、わかりやすそう。
名前的に感情側面なんだけど、タフネスだったり踏み込みだったりが必要な感じ。
論理タイプからの見え方すぎて誤解しかない感じ。
仲良くなると事実を話せるタイプと、仲良くなると相手の気持ちいいことを話したいタイプがいるから認知ずれに気がつかない
仲良くなったからなんでも話せる(気持ちいい事を)というタイプはかなり多いかと
相手へコミットとして、相手が高まる会話をするので、事実ベースタイプと話すとずれるずれる
事実ベース会話可能関係性かな…長い
事実ベース対話可能心理的安全性かな
問題解決マンは、会話の目的が自動的に問題解決に設定されるんですが、ほとんどの人はそもそも目的が違うのです。仲良くなりたいとかだと、そもそも話がずれていく。
私も、問題解決か、概念の発見みたいな目的設定がされることが多く気をつけようと思っています。
この話の終着点は、ロジックバンザイ！事実ベースの会話が正しいという話ではなくて、感情も含めた現実をどうすれば認知できるのか、上手くプレイングができるのかです。
Shrivastava氏率いる研究チームはディープラーニングの学習を「ハッシュテーブルで解決できる検索問題」と捉え直すことによって、演算自体を市販CPUに最適化した学習アルゴリズム「Sub-Linear Deep Learning Engine(SLIDE)」を開発。このSLIDEがGPUベースの学習よりも優れたパフォーマンスを発揮することを示しました。
研究チームはCPUこそがコンピューティング関連で最も普及しているハードウェアである点に触れて、CPUを用いた機械学習にはコスト面の利点があると指摘。「行列の演算に固執しないSLIDEを使った場合、GPUの4～15倍速い学習速度をCPUで達成した」と語りました。
・k3os 上で動く k3s はメモリ 1 GB で動いたので最軽量。専用 OS もあり設定も簡単。
・k0s はメモリ 1.5 GB で動いた。充分に軽い。設定は簡単だが、 Alpine の場合がやや面倒だった。
・minikube はデフォルトでメモリ 2.2 GB 。何も設定しないでコマンド1つインストールできるのは一番楽。
なるほど
未経験にRailsをお勧めしてた企業の方や個人事業主の方々。
発言の責任取って、彼らを採用してあげて。
なんかそろそろヤバい空気漂ってる気がしてきたわ。界隈。
NEXT PHPとかNEXT VB6の称号はRoRに頭上に輝くのだ
2. 中央集権型
①の独立型と似ていますが、セッションストアを共通化したパターンがこちらです。認証サービスがユーザー認証情報をセッションストアに保存し、各マイクロサービスはセッション ID を用いてセッション情報をストアから読み出します。この場合クライアントから見たログイン回数は1度になるほか、セッション ID のリボークも容易になるため、セキュリティインシデント時の対処もしやすいです。一方セッションストアは多くのサービスからのリクエストを受けるため、高い可用性が求められます。
社内システムor限定されたユーザーに提供するシステムなら中央集権型システムで十分だよなぁ
最近の課題として「発注側は無能になりやすい」というのがあると思っていて・・・。
発注側は自分で作れない、考えられないから外に依頼するけど、良し悪しの判断やフィードバックする能力もない時が多いので、変な発注をしてしまったり、質を下げる方向に向かったりしてしまうという。
一方で、受注側はお金をもらっているので、最終的にはクライアントのやりたいようにする、というのが一番になってしまう、と。
このあたりを解決するヘルシーな方法ないかなーと考え中です。
パフォーマンスが5倍の難易度高めな言語を選択するよりも、採用の裾野が広いメジャー言語を選択してインフラは金で殴る戦略が好きです
※水平スケーリングが適用できるアーキテクチャに限る
同意
- 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でも、ホワイトボードやその辺の裏紙や紙ナプキンに手描きするのが本来の使い方なのであって、立派なツールを使って清書するように描くからガンとハードルが上がって、遂には手段と目的が入れ違うのですよね。
「UMLを使うこと」自体が目的になってしまっていて、UMLの細かい記法に関する指摘ばかりで本質的なレビューをしてくれない人結構いた。
筆者には、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の反トラスト法に関する申し立ても、同様に論理的ではない」と反論している。
実に見苦しい
オラクルがGoogleに対して、Android OSがJavaの著作権を侵害しているとして訴えていた裁判で、米連邦最高裁判所はGoogleが著作権侵害をしていないとの判断を示し、Googleが勝訴しました。
よかったよかった
エン・ジャパンは4月2日、求人サービス「engage」が不正アクセスを受け、サーバ内の画像・動画ファイルを保管するフォルダが何者かに削除されたと発表した。データの復旧も不可能としている。
engageは、求人サイトの作成などが行える企業向けサービス。消失したデータの件数や不正アクセスを受けた時間帯は非公開だが、すでに外部からのアクセスは遮断済みという。個人情報を管理しているサーバにはアクセスされておらず、情報漏えいは確認していないとしている。
エン・ジャパンは今後、第三者機関と共同でセキュリティ対策を確認する他、データの定期的なバックアップなどを行い、再発防止に努めるとしている。ユーザー企業に対しては、画像や動画の掲載状況を確認し、必要があれば再設定するよう呼び掛けている。
あらら...
プログラマがコードだけ書いてりゃ良い時代は、とうの昔に終わったからねぇ。
ドメイン知識が無い人は、市場で値段つかないよ。
偏差値なるものに翻弄されてきた学生さんたちには、ピンとこないかもしれないけれども。
特定派遣/SES界隈ですらそれこそ20年近く前から言われている話で今更感がある。
その界隈では「業務SE」みたいな謎の呼称だったけど。
これは、その界隈で使われる技術がコモディティ化して人材が飽和してくると「業務」に詳しいことが差別化や有用性のアピールになるという話でしかない。
そもそも「プログラマがコードだけ書いてればいい」という世界観自体20年〜30年は遅れた感覚で、20年前でさえアジャイル開発で顧客と一緒に開発を進めようとか、内製回帰みたいな話はずっとあった。
俺の経験則でしかないがエンジニアって単価や給料が上がれば上がるほど労働の辛さが逆に下がるバグある
儲かってる良い会社だと、もはや労働の辛さより面白さが上回ることもある
つまり、単価や給料の安い会社はカス
最新の技術やアーキテクチャへの挑戦はエンジニアにとっての福利厚生である。そして、福利厚生は儲かってる会社ほど潤沢に投資できる。更に本業が儲かっているなら挑戦が少々失敗しても「戦略的投資」で片付けることができるのでシビアに評価されることもない。
というわけで、利益は全ての痛みを麻痺させてくれるのである。
これは確かにその通りである。
しばしば「初心者向けの言語」と宣伝される言語がある。 たとえば、BASIC, HSP, PHPなどがそれにあてはまるようだ。
これらの言語にはなんらかの共通項があって「初心者向け」と考えられている のだと思う。つまり、初心者にアピールする特質を抽出できれば、 その特質を他の言語に付与することも、あるいは可能かもしれない。
で、これらの言語の仕様(文法や組み込みの機能)について思い返してみると
- 機能は手続きベースでフラット
- データ構造をユーザー定義する機能がない、または強調されない
- モジュール化機能がない、または強調されない
というような感じに思える。PHPに関しては最近はオブジェクト指向機能も備えて Java化しつつあるけど、機能が関数ベースでフラットな点は依然として事実だ。 また、PHP使いには「関数化すること」や「オブジェクト指向機能を使うこと」への 抵抗感が強い人がそれなりに観測されるようだ。
ここから「初心者向け言語が避けていること」言い替えれば 「初心者が苦手なこと」が何であるかだいたいわかる。 彼らは「抽象化」が苦手なのだ。
関数がなければ、あらゆる機能はプリミティブの組み合わせをたどっていくだけで (原理的には)理解できる。ある意味、安心だ。
私がなにか大きな買い物をするとしよう。 平均的サラリーマンが購入する一番高額なものといえば住宅なので、 家を買うことを考えよう。 新築であれば、土地と建物で3000万とか4000万とかかかるのではないだろうか。
では、私はこの家を素人に立ててもらいたいだろうか。 現場に行ったら職人がどれもこれも、専門教育も受けていません、修行もしていません、 先月までは関係ない職業でした、とかいうような人の集まりだったら。
私はイヤだ。
が、ソフトウェア開発ではそれに近いことが平気でまかり通っている。 ソフトウェア開発現場には「自称初心者」がたくさんいるし、 そのような人でも開発に投入するために「初心者向け言語」が重宝される。
本当はそんな初心者を現場に投入してはいけないはずだ。 建築業界でもあまり良くない噂を聞くことはあるが、 それでもここまでではないはずだ。 ソフトウェアを設計するのに「建築士」のような資格は不要だし、 大工や左官に比べてソフトウェア開発者の技能のありなしを明確に判別する手段もない。
そんなにエンジニアの人ってロジカルか？人によると思うんだけど。
相手に話が通じないのを、自分がロジカルだから相手はロジカルじゃない、って思ってるのかな。
自分の印象としてもロジカルな考え方をするエンジニアは少ないように見える。
少なくともロジカルに根拠を説明できる人は希少。
大抵はネットや書籍の情報をコピペしてきているだけで、「何故そうするのか」「他に方法は検討したのか」というような質問をするだけでバグってしまう人が多い。
だから有効な議論が成立せず、感情的になってしまうか、そもそも議論には参加しない（聞いてるだけ）な人が多い印象。
ユニットテストを書きたいほどprivateメソッドが育ってしまったら、自分なら別クラスとして独立させるかな。
privateクラスのロジックは切り出したクラスに移植＆委譲させて、テストは新しく作ったクラスで行う。
ブリッジパターンとかストラテジーパターンみたいなイメージだ。
とりあえずはpoetry使っとけばよさそうなのね
真面目なこと言うと、プログラミング初心者はC言語とJavaをマスターすれば、他の言語を学ぶ時に応用が効くのがおすすめ
開発環境を用意するにしても中古のWindowsマシンでメモリ16GB積めば問題なく開発できるし、統合開発環境がタダで使えるのがありがたい
専門的な話をすると、C言語で構造化プログラミング、Javaでオブジェクト指向型プログラミングがそれぞれ学べるので、SI系&Web系どちらにも潰しが効くので、駆け出しさんでも家電量販店送りになることなくプログラマーになれる。
【おすすめの技術書】
>C言語
1.新・明解C言語 入門編
2. 新・明解C言語 中級編
>Java
1. 新・明解Java入門 第2版
2. 新・明解Javaで学ぶアルゴリズムとデータ構造 第2版
どっちもAmazonで買えます
あまり同意できない。
C言語はポインタで躓く人が多いし、SI系やWEB系では最早使われていないように思うのだが。組込み開発系の現場に叩き込まれることを想定しているのだろうか？
Javaについてはまぁいいのではと思うけどそこは別にPHPでもいいんじゃねという気はする。
案件の数を考えてもとりあえずPHP覚えておけばエンジニアとしてキャリアを始めることはできそう。
自分ならSI/WEBどちらにも対応できるという点を考慮したとしてもPHPとJavaScriptを勧めるかな。
CrateDBは”機械データ向けのSQL”を標榜する機械データ向けに構築したデータベース。NoSQLの柔軟性と拡張性とSQLの使い勝手を加えたもので、ANSI SQL、JSON、全文検索、ダイナミックスキーマなどの機能を持ち、データやユーザーの増加に合わせた拡張性を備える。Azure IoT Hub、メトリックを収集するTelegrafなどのツールと統合できる。これを利用して、大量のデータの処理、保存、クエリ、分析などがリアルタイムでできるという。自己実装の他、オンプレミス、Microsoft AzureやAmazon Web Servicesなどの任意のクラウドで実装できる。
ふーむ
サイズ小さめで目的がはっきりしたPRを作るというのは理解できるんだけど、そのPRをマージした後はどうしているのだろう？
即座にテストとリリースまで持っていくのか？ それともリリース予定ブランチ的なところへキープしてある程度溜まったら or 何かしらの機能リリースと一緒にリリースするのか？
後者の場合、masterブランチなどにマージする際はコードレビュー不要？ それとも別の観点（マージされるファイルに過不足がないなど）でレビュー？
複数のPRの変更が集められるなら結局はそれら全体の整合性を確認する為のコードレビューが必要になるのでは？ そうなると結局は巨大なPRになるので、小さなPRを作った意味とは？ みたいになる気がする。
会議の前にはアジェンダを共有せよ
会議の所要時間を決めて効率化を図っているように見えますが、「会議の趣旨を伝えずに始めてしまう」ということがあるあるのようです。「事前にアジェンダを共有する」などの準備作業が欠落している場合が多く、テーマの共有から始めなければいけなくなって、必然的に質の低下を生んでしまいます。
オフィスにいないことが災いして、一方的に「とりあえず会議の時間は確保しておいてね」の一言で準備なしにスタートしてしまうと、その場でアイデアをゼロベースから練るなんてこともしばしば。ゴールまでの道筋をみんなで追うための会議なのに、その意義が薄れてしまっているような気がします。逆に、「チャットで済んだ話なのに、議題に挙げた意味があったのか？」のような肩透かしを喰らうこともあります。
チャットで解消される疑問だったにもかかわらず、会議という「時間設定されたもの」になることでタイムラグも生じるとなると、リモートワークの進め方としては建設的ではないなと感じてしまいます。
ほんまこれ
そのような構造にすると営業がしやすいです。
多数で多様な最終顧客に新規営業をして、要件を聞き、見積をして、価格や機能を交渉して、契約をまとめて、納品するまでの数ヶ月から数年待って回収するため、そのための資金の手当をするのは大変です。
大規模なシステムを提供しようとすると最初の1円が入ってくるまでに半年とか1年とかを使ってしまいますし、作ったところで回収できるかどうかも定かではありません。
多重請負構造の下請け企業は少数の話の通じる会社にだけルート営業をしてだいたい相場で労働力を売ることができ、すぐ回収できますので安定した経営が可能になります。安定してるので求人をかけることができます。求人広告はSESの企業であふれかえることになります。
技術者としても、話す相手が技術者になるので気楽です。同業者同士で事情を理解してて言葉も通じるほうが仕事がやりやすい人も多いです。
私の会社は、私が多重請負構造は嫌いなので、下請けの仕事は義理でもなければやらないですし外注に出すこともしません。企画から運用まで一貫してやります。
つまり、営業でも技術者でも、イヤなら別にあなたがそんな構造につきあう必要はないです。そういうことをしてる人たちがいるというだけのことです。
DDDの戦略的次元では、最も頻繁に使用されるツールは、コンテキスト境界(bounded context)という概念です。それぞれが小さいユニットに割り当てられるべきという概念です。これは素晴らしいアイデアです。これも（もちろん）DDDの発明ではありません。単純にモジュール設計であり、文字通り何十年にもわたって大規模なシステムを設計してきた人たちによって適用されてきたものです。それはつまり、コンテキスト境界(bounded context)の概念に何か間違った点があるということでしょうか。いいえ。実際には、しばらくの間存在し、その価値を証明してきたものに名前をつけるのがパターンの目的です。私は、コンテキスト境界というものには欠点があるということを言っているのではありません。私が指摘しているのは、誰かがこの特定のラベルを使わずに、あるいはこの特定のラベルを知らずに、システムのために素晴らしいデザインを作ったかもしれないということです。
- データサイエンティストvs神エクセル
- データサイエンティストvsゴミデータ
- データサイエンティストvsパワーポイント
- データサイエンティストvs有効数字
- データサイエンティストvs外部とのデータやり取り
- データサイエンティストvs聴衆の背景知識
- データサイエンティストvs不正行為
個人的には、ドメイン層のファサードとしてのServiceとアプリケーション層のファサードとしてのServiceが混在してしまうのがよくない点と感じている。
Serviceはドメイン層のファサードに徹するべきで、アプリケーション層の仕事は別の名前を与えるべきではないかなと。
とはいえ、何がドメイン層で何がアプリケーション層なのか明確に分解できないものはそこそこあって、それが話をややこしくしているわけで。
現状では「これはドメイン層の仕事ではないかな？」と思えるものはメッセージキューに投げてサブシステムに逃がしてしまうのが現実的な落とし所ではないかと思っているのだが。
この辺の話ってその後どうなったんだろうか...？
わたしも何だかんだでキャリアが10年を超えてしまい、いろいろなソフトウェアの開発管理を見てきたが、上手くいったときの体験を思い出して、最低限これだけやっとけばいいんじゃないかというポイントが見えてきたように思う。世間にはいろいろな管理手法が提案と実施されているが、どれも大袈裟だと感じていた。上手くいくために最低限必要な要素を押さえて、30分くらいで理解と実施ができるミニマルな手法をここでまとめてみたい。
何れにせよ、見習いレベルに到達するだけでも、色々とやることは多い。
で、枝葉の技術（フロント周り）ばっかやってて、
SQL解らんデータモデル解らんデータフローガン無視でドキュメンテーションも疎か。
そんな奴正直開発メンバとして入れたくないってのが本音。
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の問題に対処できないのです。
結構な割合で責任逃れの為に許可を求める人がいるからなぁ
「許可を取ったのだから失敗しても自分の責任ではありません」的な。
また、許可不要とは言え自分のやってることの目的やスケジュールを説明する説明責任は常にあることを忘れてはいけない。
許可が不要であるという事は義務と責任も委譲されたという事なのだ。
まず、新しいOO言語が持つべき、いくつかの明白な譲れないものがあります。
- null安全
- 安全なキャスト
- オプショナル名前付き引数
- ジェネリクス
- デフォルトでイミュータブル
これらのテーマについてはすでに十分語られているので、今日はあまり説明する必要はないでしょう。
ここでは、私が個人的に新しいOO言語に望む、あまり目立たない選択肢をいくつか紹介します。
- クラスに基づく発見性
- 多重継承
- ミニマル構文
- 高階型
- 例外がない
- 統合されたクラスと型クラス
- 破壊せずにパターンマッチング
これら共通しているのは、言語を純粋にOO(「マルチパラダイム」ではない)に保つことですが、関数的な機能を型システムに統合し、OO的な方法で実装することです。
必要部材リスト
- 天板 個数 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 六角穴付きスーパーローヘッドボルト
ざっとまとめると、
コード自動生成、自動生成したものをさらに編集する運用になるとかえって面倒になるな…
思っていたほど良いものではない
自動生成したコードを編集してはいけない（戒め）
自動生成したコードを拡張/変更したい場合は、そのコードをラップするレイヤーを設けて自動生成されたコードには手を入れないようにするべき。
GenerationGapパターンとかAdaptorパターンなどが当てはまる。
ただし、scaffold的な雛形を生成するものはまた話が別である。
バグを直すときに、コミットをさかのぼって、どのバージョンで入ったか確認して。どういう変更で入ったか確認する作業をしていた。これって本当に必要なのだろうか？
金融とか保険界隈のSIerがやりたがりそうな話だけど、それで意味のある教訓は得られるとは思えないんだよなぁ
精々「勘違いしてました」とか「テストケース漏れてました」とか「仕様が変わってました」程度の話で、その調査工数がそれ以降の品質向上にプラスに働くことはなさそう。