プロジェクトのキックオフMTGでこの辺を共通認識にしておく感じの。
■目的
・プロジェクトの目的、必要性
■目標
・プロジェクトの完了条件、成果物
■スケジュール
・納期、マイルストーン
■前提条件/制約条件
・ビジネス的な面からの要求、法的規制、社内事情など
■予算
・いくら使えるのか、誰に確認するのか
■予測されるリスク
・プロジェクトに影響を及ぼし得る外部要素
■体制
・PM、メンバー
・責任範囲
PHP を好む理由:
- ステートレスで運用が楽
- ゆるさと堅さの選択肢が広い
- composer の秀逸さ
- コミュニティ内の価値観が多様
まちがい:
- 人材確保が簡単で単価も安い
(↑安易に安い人に任せるのまじどうなっても知らんで。多様性があるってことはピンキリの振れ幅がすごいあるってことやで)
Python を好む理由:
- おぼえることが少ない
- 基礎をおさえるのに過不足がない
- 高度なことでも組み合わせでてきて楽しい
- 用途が広いので興味が広がる
- 泥沼化した案件で使ってた思い出から悪口を言い出す人が少ない
まちがい:
- これだけで機械学習できる
- 平均年収が高い
エンジニアから経営者にならねばならない、みたいな論調が大嫌いだ。
結局PG/SE/PMルートと同じだしなぁ。
それがあるのは否定しないし、それを選んだ人の努力や経験は素晴らしいと思う。それを唯一絶対の正解かのように語るの、ほんと、なんていうか。
全ての労働者が経営者視点を持つべき、それが唯一絶対の正解だ、みたいな論調は確かに反吐が出る。
一方で、「見識を広げていった結果、そのようになった」というのは尊ばれることだ。
要するにエスカレータ式の学校とかサラリーマンの出世街道みたいなノリで雑にまとめられるのが気に喰わないわけで、そんな脳死した連中と同じ扱いを受けることにプライドやら何やらが反発しているわけだ。
そして、それがエンジニアのあるべき資質でもある。
"技術的な判断は、チームが協同的に下すように求められています。プロダクトの判断も同じでよいのではないでしょうか？"と問いかけている。
スクラムの創始者であるJeff Sutherland氏がツイートした記事のひとつには、従来型の組織構造にアジャイルを当てはめようとしてアジャイルを破壊している組織によって、役割が歪められている傾向が強調されている。
さまざまな見解を要約すると、アジャイルの規模が拡大し、その利用がごく普通のことになっている一方で、プロダクトオーナという役割には明確なニーズがない場合や、明らかに状況に適合しない場合がある、ということだ。
命題を一般化して、「全てのアジャイル開発チームはプロダクトオーナー無しでも機能するべきだ」と考えると、確かにその通りかもしれん...と思ってはしまう。
開発チームがそこまで自律的に機能するならそれはひとつの理想ではある。
とはいえ、常にそこを求めるべきかと言うと人材の問題や学習コストもあるし...ってことで、まず最初から選択肢に挙がらない。
エンジニアの視点から考えてもプロダクトの意思決定に必要な情報や組織内の調整諸々にまで手を出したくない（手に余る）ものがある。
プロダクトを極めるより先に転職したくなる可能性の方が高いのでプロダクトはプロダクトオーナーに任せたい感はある。
"マサカリ来るとメンタルがやられます"と繊細さん。そういう人は無茶したらダメ。僕は極端な話、自分も含めて人に興味がなくシステムや仕組みにしか興味ない。そのシステムがより良くなるならマサカリは必要。良くなるなら朝令暮改すればいい。プライドないんすか？それでシステムがよくなりますか
自分もこういうタイプではあるが、その一方で自分一人でできることに限界もあるので意識して他者を「接待」しないといけないのがつらいところである。
それとは関係なく、ただ知識をひけらかしてマウント取りたいとか、気に喰わないから当て擦りをするみたいなムーブは害悪でしかないので絶対に許してはならない。
DDD本で一番きらいな言葉は「コアドメイン」だな。気持ちはわかるけどね。
知識領域に関して中核とか周辺とかは無い。その時々で優先順位が移り変わっていくだけだ。領域に軽重をつけていると、その変化を見逃す。
ビジネス機能が大事な時もあるがテクノロジーが重要な時もある。
本来は、その時々の優先順位の問題に過ぎないのに、それを、ある知識領域と別の知識領域の重要度の差と見てしまう（そしてたぶんそれぞれを担当する人々の発言権の差とも）。
これはいわゆる「認知的不協和」以外の何者でもない。
これはわかる。
「コアドメイン」なるものは、ある局面において注視すべき要素であって、常に核心的な価値を持つわけではない。まさに文脈（コンテキスト）依存。
とはいえ、そのシステムが直面する状況の7割以上の局面で中核的な価値を持つなら、便宜的にも実質的にも「コアドメイン」と呼ぶしかないのは確かだったりする。
自分もプログラマなのでIT技術者の給与が上がるのは望ましいことなのだが、一方で企業の経営事情や利益構造とマッチした報酬になってるのかというと、今は若干給与が高過ぎるんじゃないかという気もする。人を育てる再現性が無く、ベテランを奪い合う状況がそれに影響している感じがしなくもない。
これは思う時はある
JavaScriptの日付操作ライブラリ「Moment.js」の開発チームは9月15日、プロジェクトのステータスとしてプロジェクトはメンテナンスモードに入り、代替ライブラリへの移行を推奨している。
これらの問題について議論した結果、新機能の追加は行わない、バージョン3はなく大きな変更を加えない、APIをimmutableに変更しない、サイズ問題にも対応しない、と決定したという。重要なセキュリティ問題への対応などは行う。また、新しいプロジェクトが使用することを推奨せず、Luxon、Day.js、date-fns、js-Jodaなどを代替として推奨することにしたと報告している。
「Zigからの発展」ページにおいて、コネクトフリー社はZenはZigバージョン0.3.0から独立して進化してきたとしており、またZigの貢献者である「No.5」と「No.2」はコネクトフリー社の従業員であり、「No.5」はコネクトフリー社創設者のクリストファー・テイト氏であると述べています。この他に、このページではZenがZigと比較してどのような点で優れているかというバリュー・プロポジションと、開発チームのある種の正統性——彼らが信頼に値する存在だということを示そうとしているようです。
Zenが独立的に進化してきたという主張については、私どもはクローズドソースであるコンパイラの内部実装についてはコメントできないものの、Zen標準ライブラリのソースコードはZenリリースの度にまだ入手可能です。このソースコードを読むと、コネクトフリー社がZigプロジェクトからいまだに多くのコードを借用していることが簡単に分かります。ほとんどの場合、彼らの命名規則に合わせるために非常に小さな変化を適用しているに過ぎません。この一例として「async/await」機能があります。この機能はZigバージョン0.6.0 (バージョン0.3.0の約1年半後) で導入されましたが、コネクトフリー社によってZenに実質的に全く変更なくコピーされました。もう一つの例として、こちらのリンクから二つのイベントループ実装の比較をご覧いただけます。
開発チームについてのお話をしましょう。「No.5」(すなわちクリストファー・テイト氏) はZigプロジェクトの公共の場であるGitHubとIRCで繰り返し問題のある行動を行ったため、プロジェクトから追放されなければならなくなりました。こうした経緯があることをコネクトフリー社は明らかにしていません。その後、テイト氏は「No.2」をZenコンパイラに取り組ませるために雇いましたが、この契約にあたってプライベートな時間で作られたものも含め「No.2」が書いた全てのコードの所有権がコネクトフリー社にも帰属するという契約内容について適切に明確化することを怠りました。その時以来「No.2」はコネクトフリー社の職を辞めましたが、契約の中に示されている「競業避止義務」条項のために、Zigプロジェクトにしばらくのあいだ貢献することもできません。さらに、テイト氏はいくつかのZigコミュニティで宣伝活動を行い、複数のZigコントリビュータをメール経由でスカウトしようとしていたことが知られています。おそらく「No.2」と同じ契約条件で雇おうとしていたものと考えられます。
コネクトフリー社の創設者であるテイト氏は、不完全な技術論により彼自身の行動を正当化しようとすると同時に、契約条項を利用してZigの貢献者がこのオープンソースプロジェクトに更に貢献する事を阻止しています。また、コネクトフリー社のZenはZigを表面的にリブランディングしたものに過ぎません。このようなテイト氏の過去と現在の振舞いから、日本の専門家や会社がこうしたクローズドソース製品に頼り生計をたてようとするのは、私どもの良識としてはお勧めできません。
Zig言語からforkしたZen言語についてZigコミュニティが苦言を呈している。
現在の人類の叡智がまだそこに至っていないというだけの話で、本来テスト書かなくてもいいならテスト書かないに越したことはない。現在の人類の叡智がまだそこに至っていないのでテスト書くしかないという話になってしまうのだが。
早くエンジニアの仕事を代替するAI作られてくれ
SOLID原則は、語呂合わせの勝利みたいなとこはあるわな。
どの原則もオブジェクト指向プログラミングの核心ではなく、一般論すぎる原則と、特定の場合だけの原則とがまぜこぜになって、全体として整合していない。
オブジェクト指向プログラミングを学ぶなら、むしろ遠ざけた方がよい。
例えばリスコフの置換原則の議論は彼女の業績の中では枝葉末節に近い。
リスコフに学ぶべきは、データ抽象によるモジュール化という、それまでになかったプログラミングのアプローチの可能性を明確に打ち出したこと。
データ抽象はオブジェクト指向プログラミングの核心の原則
SRPも本人曰くメイヤーに影響を受けたらしいけど、おそらくクラス設計の一貫性の箇所か、単一責任選択の箇所あたりに何か感じたんだろうけど、どちらもSRPよりも、もっと具体的なクラス設計の原則を語っている。
OCPの原則も、メイヤーから取りれたんだろうけど、これもメイヤーの主張とはだいぶ違う。
メイヤーの場合は継承のメリットとして強調しているんだけど、現在のオブジェクト指向プログラミングでは、実装継承は、むしろアンチパターンに近い。
Railsに限らずform objectの概念は適用できると思う（Rails以外ではActive〜の支援を受けれない問題はある）。
日本の SIer はまず監視をちゃんとするというところから始めるといいと思うんですよ
❌なんでもかんでも同じ基準を当てはめる
・ログ監視 (ERRORと出たら都度問い合わせるとか💢
・メモリ使用量監視
・CPU使用量監視
⭕サービスの正常性を定義してから必要なものを監視する
ログの一覧をくれ
プロセスの一覧をくれ
データベースのテーブル一覧をくれ
設定項目の一覧をくれ
こういうのが無限に来るのは日本の SIer からだけですよ。
まぁ、どうせ下請けに投げるんだから個別にチマチマとやりとりするよりは、まとめて一覧もらった方が（SIerには）効率的ではあるんだよな。
こういうことも起きるのか
プロジェクトマネージャーのルール100個じゃ辛いんで10個自分で書いてみた。
(1) いつも健康でいる
(2) 良いことは褒めて喜び、悪いことは責めずに冷静に
(3) 成功はメンバーの成果、失敗はPMの責任。他責にしない
(4) 方向性を繰り返し示す
(5) 現実を直視する。淡い期待に逃げない
(次に続く)
続き
(6) Howはメンバーに任せる
(7) 意思決定は素早く。多くの意思決定はやり直せる
(8) 情報はオープンにする
(9) Noをきちんと言う。八方美人をしない
(10) ときにはプロジェクトをやめる決断をする
この件で受注したベンダー（その下請け達）は大変なことになってるだろうけど、増田あたりに怪文書でも流してくれないだろうか
データディクショナリとは、重要単語や指標とその定義のリスト、つまりビジネス用語集です。というとあまりにシンプルでつまらないものに思えるかもしれませんが、ビジネスに協調性をもたらし混乱を回避する効果は絶大です。実のところ、データディクショナリはデータチームがビジネスに提供できる成果物の中で最も価値のあるものの一つかもしれません。
この記事では、データディクショナリに関連するいくつかのベストプラクティスと、作成プロセスの一例について詳しく述べます。決してこのプロセスが唯一の正解というわけではありませんが、少なくとも私の場合は上手くいっています。ここでは、BIチームがこの作成プロセスを推進していると仮定します。私の考えでは、データディクショナリとBIツール内に実装される指標はともにBIチームが管理すべきだと思います。
データフロー図を作れるツールみたい
データモデルと呼ばず永続化モデルと呼べば何か解決するかもしれない
この手の呼び換えは往々にして何か解決する一方で新しい問題が持ち込まれるのだけどね……
一応この「永続化モデル」は実績があって。データモデルと呼んでるうちはメモリ上のモデルも一緒くたに考えてたのを引き剥がせたし、UPDATE一択だったのを追記型が検討できるくらいにはなってくれた。新しい問題は観測できてないから知らない。
なるほどね
モノを作る上で障害になると思う性質：
①完璧主義／リスク忌避性向
②原理主義
③自身の美意識がない
④ルサンチマン
⑤自意識過剰。自分と作品を区別できない
⓺世界に対する無関心。自分が好きなだけ
⑦怠惰と過剰な勤勉
⑧責任の線引きが好き
「Clean Architecture」というアーキテクチャがあるって読み方されちゃってるけど、違うと思う。きれいなアーキテクチャっていうのはこういうものですよっていうのが書かれてるだけなはず。Clean Code も Clean Coder も固有名詞ではないのに Clean Architecture だけ固有名詞にするのは間違ってるよ。
アーキテクチャをクリーンに保つための方法ではあるけど、アーキテクチャのことではないんだよ。重厚長大なアーキテクチャの話ではなくて、どうやってスケールさせていくかっていう話。
ほんまこれ。
「Clean Architecture」に準拠することが目的になっていて、そもそも「よいアーキテクチャとは何か？」という本質から目を背けてる人多すぎ問題がある。
本当にそのレイヤー必要でした？ とかこの規模感でDI使う価値ありました？ みたいな話。
でもそういう話をするとムスッとされがちなんだよな。
logspoutは，ホスト内で動かした全てのDockerコンテナの出力を集約して，好きなところに飛ばす（ルーティングする）ためのツール．開発者はDokkのJeff Lindsay．
あとで試してみよう
リモートワークに憧れてる駆け出しエンジニアさんいるけど、控えめに言って未経験でリモワとか地獄以外のなにものでもないと思うのよ。 技術を盗めるパイセンも横にいないし、チャットベースでやりとりしようにも用語わからんから意思疎通できないしエラーでても気軽に聞けないし…
これは確かに
ビジネスに価値を提供するための設計のアプローチ
① コードに責任を持つ開発者が事業活動に関心を持ち、要件定義に関与すること
② ドメインロジックを中心に考え、画面と永続化はドメインロジックとの関係で組み立てること
③ 値の種類ごとにクラスを作り、手続き的なクラスをつくらないこと
アンチパターン
① コードに責任を持つ開発者が事業に関心を持たず、要件定義に関与しない
② 画面と永続化を中心に考え、画面や永続化との関係でドメインロジックを組み立てる
③ 手続き的なクラスを作り、値の種類ごとのクラスはつくらない
多くの開発者は、アンチパターンのアプローチが当たり前の環境で仕事をしている。
つまり、多くのソフトウェア開発は、ビジネスに大きな価値を提供できていない。
ビジネスに価値を提供するために、設計のアプローチをかえる。
本来あるべき姿のチケット管理では、チケットに変更管理や進捗管理というフローの側面と、成果物の構成管理や課題や作業の履歴管理というストックの側面を故意に持たせることで、スムーズに運用させる。
一方、Excel帳票でそれらを管理しようとすると、フローの側面のExcel帳票と、ストックの側面のExcel帳票の2種類に必ず分かれてしまう。 なぜなら、ステータスだけ管理したいExcel帳票と、リリース対象の成果物として厳格に構成管理したいExcel帳票は、管理方法が大きく異なるので、具体的な実体として分けざるを得ないからだ。
すなわち、Redmineのチケット駆動開発は、2種類のExcel帳票の具体的な実体が1つのチケットに合体されている。
チケットに対するフローの側面を意識し始めると、ストックの側面を忘れてしまう。
チケットのストックの側面こそが重要なのに、その部分が軽視された運用になってしまうのだ。
ガントチャート重視のチケット駆動開発が、空っぽのチケットを大量発生させるアンチパターンはまさにそれだ。
一方、ストックの側面ばかり強調すると、チケット入力の運用のコストが上がってしまう。
チケットは手軽に起票して、記録して欲しいのに。
誰も更新しなくなるRedmineは、ゴミ箱と同じ。
だから、チケット管理の運用では、フローの側面を強調しすぎると空っぽのチケットが増えて破綻するし、ストックの側面を強調しすぎると、誰もチケットに起票しなくなって破綻する。
チケットの2重性という奇妙な性質を活かすには、そのバランスが重要だ。
フローの側面だけ、ストックの側面だけ、という運用では、チケット駆動のあるべき姿を実現できないし、チケット駆動の効果が得られない。
うーむ...
WBSは別途Excelなんかで管理するという方法も無くはないけど、WBSとチケットの同期で疲弊して放棄される可能性が高そう。
チケットはそれなりに細かい粒度で作成して欲しさあるので、必ずしもWBSの粒度と合致するわけでもない。
WBSは成果物の定義のみに割り切る方法もありそうだけど、それで上手くいくのか？ という疑念は晴れない。
全体像を把握して進める必要があるプロジェクト（新規開発とか）はWBSを作った方がよくて、現在動いているシステムの保守運用・改修みたいな感じだとチケット駆動で進めた方がよいという話か。
シンプルに一ヶ月以上かかりそうな場合はWBSを作るとしてもよいかもしれない。
「計画できることはWBSで。計画できないことはチケットで」というのが僕の主張です。
これは確かに納得感ある。
1. WIP(仕掛り中)の同時許容個数を減らす
個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。
2. タスクの切り替えが減る
一節によればタスクの切り替えは20%程度のムダが発生するとも言われています。 ちなみにタスクの切り替えはトヨタ生産方式における7つのムダのうち運搬のムダに該当します。 WIPを制限すればタスクの切り替えが減ります。
3. サイクルタイムが短くなる
サイクルタイムとは、繰り返し行われるプロセス（仕事、タスク、ジョブなど）においてその1回に要する時間のことです。 WIPの制限によってタスクの切り替えが減り、同時に多くのことを行わずに限られたことに集中して取り組むので早く完了します。 早く終わるということは早期に終わったものから価値を得ることが可能であるとともに、長い時間をかけてしまうことによって変更が入ってしまう余地が少ないということでもあります。
4. フィードバックが増える
サイクルタイムが長い場合フィードバックを得ようとしても、タスクの開始時点で何を考えていたのか覚えていないこともあるし、そもそも何のためにそのタスクが必要だったのかすら分からなくなってしまっていることもあります。 ウォーターフォールにおける大きな問題の1つは、要件を決めてから納品されるまでのサイクルタイムが長すぎて、効果的なフィードバックが得られないことにあります（フィードバックを得た場合でも既に対応できなくなってしまっている場合も多く、フィードバックのインセンティブも働きません）。 サイクルタイムが短くなるとフィードバックの頻度が増えます。
5. 品質が向上する
万が一誤りがあったとしても小さい単位で完了していくので、早い段階で誤りを検知できます。 誤りの検知は早期ほど修正のコストが低く、遅くなればなるほど修正のコストが高くなります。
6. チームの成熟度があがる
チームの成熟度はチーム自身によって継続的に自分たちのプロセスを改善することによってのみ向上します。 WIPの制限値を適切に制限していくのも改善のひとつです。
しかし、運用と開発を同じチームでやっている場合、割り込みは発生するものだし、そういうのはどうしたらいいのだろうか。
ソフトウェア作りに才の無い人は、コードを書くことを少し覚えると、こうすれば簡単に書けるとか、一律に書けるとかいったことばかり考えだす。
才のある人は、こんなことが出来るなら、こんなことだって、さらにはあんなことだって、できるはずだ、と妄想を膨らませ始める。
確かにあまりセンスの無い人ほど共通化や簡略化に走って結果的に無用な複雑化を生じさせるものだけど。
とはいえ、こういうマウンティングはちょっと痛いかな。
もし Ruby on Rails が型がないからダメなんだと仮定したら、型のある Rails として Yii 2 や CakePHP 4 (と静的型解析の組み合わせ) がもっと評価されてもおかしくないんだけど、そうじゃないということは、今のトレンドを考えるうえで、仮定が間違っているということですよね
なので、Rails が解決した問題と直交する問題のウェイトが増してきたと考えるほうが合ってて、それは何かというと、ソフトウェアは所詮データの入力と出力だ (それでしかないのになぜこんなに記述が多くエラーが出るのか) という物理軸から、そうでない無形の意味を生む世界への着目だと思ってる
初見では単なるCRUDなアプリのように見えても実態はそうではないことの方が多いのだ
これ。Go言語が顕著ですが
「綺麗にコードが書ける言語」と思われているのがその実、「その言語を導入している現場はそもそも人材のレベルが高いし、設計やリファクタリングにコストを投入できる余裕があるだけ」みたいな統計の錯誤はけっこうありがちですよね。
Go の平均が高いのは Go そのものが高級だからじゃなくて、Go のパフォーマンス特性がぴったりハマる規模のアクセスをさばく種類の事業における普通のエンジニアの待遇だからで、そこでは同じ待遇で PHP エンジニアがより変化に強いモデリングとスケールアウト考えて仕事してるはずです
ほんまこれである。
・配列はUsersというように複数形で表す
・日付カラムはatをつける
は常識！知らない時点でレベル低い！みたいな扱いなのに
・文字列変数は最初にstrをつける
・boolean変数は最初にbをつける
みたいな直球の奴はダサくて無意味！ってなるのは自称Web系の悪い癖。エレガントなコード(笑)みたいな。
Web系だと、↑にあげたようなRails系の命名規則は言語に問わず普及して共通パターン化しているけど、別に「その記法が優れているから」と言うほどではなくて、単にそれを見慣れている人が多い、という文化の違いに過ぎないって話ですね。
これは確かに。
というか、RoR式の複数形テーブルはもうやめたい感はある。
Webエンジニアの採用面談においては「PJであなたはどんな開発をしたか(純粋なスキル)」以上に「そこであなたはどんな事を考えたか(価値観／指向性)」により重点をおいて話す事が重要です。
特に正社員採用の場合、スキルは多少足りなくてもなんとかなるけど、価値観のズレは即離職につながるので。
言い換えると、
「面談はソフトスキルの見極めが８割」
だと考えてくれてもいいと思います。
というより純粋な技術力は経歴みりゃ大体わかるし、突っ込んだプログラミングスキルを問いたいならコーディングテストなり技術課題なら別の方法もありますしね。
ソフトスキルをもう少し現場目線で噛み砕くと
「この人はあのチームに放り込んだら、うまく馴染んでくれそうか、コンフリクトを起こさないか」
がまずあるし、more better観点だと
「今チームに足りないピースを補って、抱える課題点の解決を進めてくれる人か」
だ問われていると思って下さい。
チームメンバーと喧嘩してさっさと辞められちゃうと採用コストもチームの慣熟コストも無駄になっちゃうしね。
しかし一方で、これは逆に言うと新しく入ってくるメンバーとコンフリクト起こしかねないネガティブな因子を持つ既存メンバーはさっさと放逐した方がよいという話でもある。
新しく入る人間に我慢だけを強いるならいずれ袂を分かつ事は明白なのだから。
上記のPRでWebpackで内部的に使用するハッシュアルゴリズムをmd5からmd4に変更しようという提案がなされた模様。
当然コメント欄は「Why？」の嵐。
開発者によると
ということらしい。
元々暗号強度が問題ではなく単にハッシュ値を計算したかっただけという理由でmd5を使っていたのだから、より高速性を求めてmd4を使ってもいいじゃないかという発想なのか。
一瞬ギョッとするけど理屈は通っている。
心理的安全性、一人でも卑屈な性根の人間が混じってると瞬時に崩壊するのでかなり実現が難しい代物だってわかってきた
エンジニアの採用をしていると、フリーランスで稼いでいるけど年収下げてでも社員になりたい人が一定数いる。リーダー経験が積めないのと、技術力を上げづらいというのが主な理由。自己研鑽力が高くないとフリーランスを続けるのは難しいと思う
これは実際ある。
フリーランサーの人で結構ありがちな「○○ならできます（○○はRoRやLaravel、WPなど）。他はできません」というパターン。
責任持って仕事を完遂させないといけない以上、扱う技術で冒険できず保守的になってしまうのは仕方ないのだけど、結果的に変化に追随できなくなって長期的には詰んでしまう。
会社組織のいいところはそういう技術的投資案件に関われるところというのはある。
その辺りがフリーランスにあまり魅力を感じない所以ではあるな。
重複については、先の抽象化の話と共通しますが、2つのロジックが重複しているかどうかはコードの見た目で判断すべきではありません。 同一のロジックが同一のユースケースで利用される場合もしくはユースケースとは関係なく単純な演算処理を行うコードが複数回出現する場合に限り重複と判断すべきです。
ロジックの見た目は似ているが実はユースケースが違うコードはそれぞれ独立した責務1をもつ場合が多いです。 一方のユースケースだけに変更が必要になった場合2、共通化を剥がす作業が必要になります。 ただ単に制御フローや処理内容が同一であるからという理由で重複と判断すると、逆に過剰な結合の原因となってしまいます。
早まった共通化はメンテナンス性に致命傷を与えるので本当に気を付けなくてはならない
概念モデリング、見せられても何を読み取ればいいのかよくわからないし、書けと言われても困っちゃうんだよなぁ
VScodeのRemote Container使ってみるかなぁ
コード書く時に、いちいち名前が必要なのが何だか不自由に思える。絵具で絵を描く時に、別に何かを宣言したりしない。グラフィックデザインツールでも色や形に名前をつけることはあるけど、別にレイヤー156 とかでも問題ない。名前ではなくて形で識別するから。赤ん坊だって名前は生まれた後につける。
そもそもソフトウェア開発は絵画やグラフィックデザインではないので異なるのは当然のことである。
ソフトウェア開発はどちらかというと建築に近い。建築においては家を建てる際はそれぞれの建材を役割毎に識別できるようにするものである。ソフトウェア開発もそれと同じということだ。
更に言うと、赤ん坊の名前云々は本論と関係ない話をしているだけでしかない。
ちなみに実装コスト以前の問題として、「ロジックに誤りがないとはどういうことか」を人間が認識するところがボトルネックになりがち。訓練されていない人間は本人が思っている以上に、頭の中にある仕様を検証可能な形で表現することができない。
1.「組織の細分化、階層化をやめる」
マネジャーが増えるということは、ゲームの作り手が一人減るということ。優秀な人間がマネジャーになるほど、アプリの制作力は低下する。
2.「職種別の目標設定をやめる」
プログラマー、企画など職種別に目標を設定すると、自分の担当部分しか見なくなる。評価はまずそのアプリの完成度に注目。その中で自分がどれだけ貢献したかというポイントに変更した。
3.「作業量の見積もりをやめる」
作業する本人が3日間徹夜で仕上げるつもりでも、上司はバッファを見て一週間と報告してくることが多い。どんどん仕事を依頼し、本人が「ここが限界」と自己申告すれば、そこまでにする「ギブアップ申告制」に変更。
4.「スケジュール管理をやめる」
スケジュールありきだと、だれもがクオリティーよりスケジュールを優先してしまう。スケジュール表をまとめただけで仕事をした気になってしまうのも問題。
5.「データ分析をやめる」
過去のデータを分析しても新しいアプリは生まれない。消去法でアプリを作成すると、センスのある人間の意見がつぶされてしまう。
6.「お客様のご意見どおりのアプリ変更はやめる」 お客様のご意見は、あくまでもアプリに問題があるかどうかのバロメーターとする。
7.「メンバーの教育はやめる」
優秀な人間を教育担当にするほどチームの制作力は低下する。
8.「承認はやめる」
「○○さんがいいと言ったので」という甘えを断ち切る。常に危機感のある状況にする。
9.「アドバイス／助け合いはやめる」
分かっていない人間に理解させるより、分かっている人間が作業したほうが早い。問題点は「ここがよくない」とストレートに事実だけを伝える。
10.「会議をやめる」
時間の無駄。制作チーム同士の席を近くするだけで問題ない。
11.「報告書をやめる」
自分自身がプロジェクトの進行具合を知りたい担当者のところに、知りたいタイミングで歩いていけばいいだけ。
昔見た記事に再び巡り合ったので記念に。
短期で成果を出さなければならないスマホゲームならではの事情もあるから、一般的なWEB開発にそのまま適用するのは若干危険だったり、的外れなものある。
とはいえ、この辺は試してみてもいい気がする。
1.「組織の細分化、階層化をやめる」
2.「職種別の目標設定をやめる」
3.「作業量の見積もりをやめる」
4.「スケジュール管理をやめる」
8.「承認はやめる」
エンジニア派遣界隈滅ぶべし
偽装うんぬんの前に、人材会社から送られてくる経歴書、「やったこと」が書かれているだけで「できること」とは限らないから事実上情報が少なくてなにも判断できん。
なんかもうちょっと具体的な実績が書かれたポートフォリオが欲しい。2019年5月~11月 Java, MySQL とかだけ書かれても...
ほんまそれよね
シンタックスは好みだが、殆ど名前を聞かないということは流行ってなさそうな気配
公開されたのは2019年か。まだ普及段階なのかもしれないが。
IT人材会社「スカイテック」（東京都千代田区）が顧客企業に示した技術者の職務経歴書に、実際とは違う経歴が記載されているケースがあることがわかった。複数の同社関係者によると、技術者の大半は中国人で、同社は経験や能力が豊かなように経歴書を偽り、東証1部上場企業などに送り出してきたという。
取材に対し、同社の潘小華（はんしょうか）社長は「そういうことは一切ない」と否定した。一方、技術者の一人は自らの経歴書は「年齢も業務歴も全部ウソ」と認めている。
同社はシステムエンジニアやプログラマーを顧客に紹介し、その技術者らが顧客の職場で情報システムの開発や保守を支援するサービスを展開。顧客には、技術者が過去に日本や中国で従事したとする業務の期間、内容、使ったプログラム言語などを時系列で記した経歴書を提示している。
朝日新聞は、約40人の同社の技術者の経歴書のコピーなどを入手した。複数の同社関係者は取材に、これらの経歴書について、従事していない業務を偽って経験年数を長くしたり、十分に習得していない言語を使えることにしたりしてあるものが多くある、と証言した。
特定派遣界隈では当たり前のように行われていたことだけど、この企業だけピックアップされるのは何か不自然な感じではある。
ともあれ、SESやら人材派遣界隈は滅ぶべきなのだ。
まずCDDLとは何かというと、CBORのデータ構造を記述するためのスキーマ記述言語です。 CDDLを使うことで、プロトコルで使われるCBORデータのフォーマットを曖昧さなく記述でき、あるCBORデータが記述されたフォーマットに従っているかどうかを検証できるようになります。
また、CBORで利用できるデータ型はJSONで使えるデータ型のスーパーセットになっているため、CDDLはJSONのスキーマ記述にも利用できるとされています。 以降、CDDLの使い方や記述の仕方について簡単な例を元に説明したいと思います。
CDDLの文法としてはBNFに似ているところがあり、ルールの宣言を並べることによってスキーマ全体が表現されます。 BNFを知っている方は特に違和感なく読めるのではないかと思います。
CDDL、Pythonのライブラリなさそうだな
DMM meetup #17の講演資料
こういうのサクッとセルフホスティングできるようになってた方がいいと思うんだけどな
業務フロー図(アクティビティ図)では複雑な分岐や反復は、いったん描かずに基本の流れを押さえる。
分岐や反復は状態遷移モデルで描く。時系列の関心は意識的に持ち込まない。サブ状態は、いったん別の遷移モデルに切り出して単純化する。
モデル間の整合性はユースケースと管理番号で検証する。
シーケンス図とかもそうだけど、ループや分岐を「描くことができる」がいつの間にか「描かなくてはいけない」みたいにすり替わっている人を多く見かける。
とにかくツッコまれないように詰め込めるものは詰め込むという発想なのだろうけど、結果として本質的ではない情報（ノイズ）が多い理解が難しい図が生成されてしまう悲劇。
「足し算ではなく引き算で考える」とは至言であるな。
これ↓にも通ずる話だ。
ここで議論されているのは例えば「status」カラムに保存される値をそれぞれ意味を持たせた数値で表現するか、論理名的な文字列で表現するかという話であるが。
数値で表現する場合:
0 // 未審査
1 // 審査中
2 // 登録完了
3 // 却下
みたいな感じで数字がそれぞれの状態と対応することになる。
このようにデータを持つ場合、プログラム側でコード値と文字列を対応させる必要が出てくる。
文字列で表現する場合:
'UNEXAMINED' // 未審査
'REVIEW' // 審査中
'COMPLETE' // 登録完了
'REJECTED' // 却下
という感じになる。
以下メモ書き。
結論としては、文字列表現の方がメリットがデメリットを上回っているように思える。
マジックナンバー int だらけのレガシーなデータベースを Laravel でさばく方法
1. Eloquent Model に
public const MODE_FOO = 1;
のように定数を定義
2. JsonResource に
public const MODES = [
Model::MODE_FOO => 'foo',
];
みたいなマッピングを定義
FormRequest では Rule::in(JsonResource::MODES) でバリデーション可能，そのあと array_search($this->input('mode', JsonResource::MODES) で数値化できる
JsonResource::toArray() では static::MODES[$this->resource->mode] で文字列化できる
これはあくまで既存の闇データベースを新規 API で綺麗に見せるときのテクニックです。
新規データベースに関して Excel で数値と意味の対応表を作っているエンジニアが居たら爆破しましょう。
社内の文化的に普通に数値でDBに入れてるな……(DBに文字入れちゃうと名前変えずらくなるし)
(Enum使って変換かけてるから気になったことないし……)
「名前を変えづらい」
と
「数値に変な欠番とか飛び番ができる」
「バックエンドとフロントエンドでの変換ロジックの共通化が難しい」(TypeScript 以外)
のトレードオフ。命名しっかりしてれば前者のほうがマシかと思ってる
データ量が多くならない想定で、多言語対応もなく改修もあまり見込まれないプロダクトならあり。
それ以外だと躊躇するなぁ。
個人的にはフロントでそのまま表示できる文字列で保持するのがわかりやすくて好きやけど、経験則としてはコード値(整数)で保持したい人が多かったかな。
クエリの速度的な意味でそうしてるのかと認識してるけど、ユーザーの操作でレコード増えないのでわかりやすさ優先で良いと思ってる。
・Aurora みたいな分散データベース使ってたらストレージ使用量のことはほぼ気にしなくていい
・フィールドには英語を書くんじゃなくて論理名を書くだけなので多言語対応の有無は全く関係ない
なのでむしろ特別な理由なくフロントエンドを苦しめやすい数値を使うほうが躊躇する
これなんで伝わらないんですかね？（否定的な反応に困惑）
個人的には「文字列が良いに決まってる」くらいの感じなんですが
変数名に「1」とか「2」とか付けたら後から把握大変だよね？と同じような話だと思っています
この辺で「綴り間違えたデータがまぁまぁ散見された」とか「日本語で入ってるんだけど、長音の文字コードが複数散らかってた」とか色々見てるから、文字列は文字列で、わりと躊躇するんだよなぁ………
パラゴンソフトウェアは以前から、NTFSの商用ドライバーをLinuxやその他のプラットフォームに提供していました。しかし、NTFSが他の先進的なファイルシステムに機能的に追い越されている状況を鑑みて、自らのコードをLinuxカーネルに統合し、コミュニティに貢献しようと考えたとのこと。これまでLinuxでNTFSに対して書き込みを行う場合はNTFS-3Gというソフトウェアを用いるのが一般的でしたが、提供されたパッチが採用されれば、書き込みも含めた完全なNTFSの機能をLinuxカーネル単体で利用できるようになります。
しかし、パラゴンソフトウェアによるパッチの提供方法は、少々問題がありました。パラゴンソフトウェアはカーネルパッチを提供する際、2万7000行ものコードをひとつのファイルに記述してメーリングリストに送信。NTFSの完全な実装を歓迎する声ではなく、「この化け物をどうやってレビューするんだ？」という返信が、パラゴンソフトウェアのパッチに対する開発者の最初の反応でした。
www
誰が開発してるのかと思ったらコネクトフリーという企業が開発している模様。
class 教えないで済むだけでプログラミングの基礎のスコープがだいぶ小さくなるし、class がモデル抽象の唯一の解で銀の弾丸みたいな人が減ってほしいと思っています…
class がモデル抽象の唯一の解で銀の弾丸みたいな人なのでどうすればclassを無しに凝縮度を高められるのか気になる
class一切使わずに関数型までたどり着いたみたいな人が居て、そういう人からリアルな感想が出てこないと「クラスOOPで洗礼を受けた人からの押し付け」にならない？
手続き型のコード愚直に書きまくってる人から見て、副作用の排除なんたらうるさい言語で適切なモデリングまで学ぶ余裕あるんだろうか？
クラスOOPのモデリング、愚直な手続き型からのステップアップとして、関数型よりはだいぶ直感的だと思うんだけど
関数型プログラミング的な方法論、理解が難しいねん...という問題を何とかしないとなぁ
エンジニアは数年で転職するので、会社内評価よりも労働市場評価を上げる方が価値が高い。なので労働市場評価を上げられない会社は優秀な人から辞めていってしまう。エンジニアが定着しない会社は事業都合を強く押し付けているケースが多い。事業都合と労働市場都合のバランスが経営者の腕の見せ所