設計思想（Design Philosophy）とは何か | タイム・コンサルタントの日誌から
Kさん、久しぶりにメールありがとうございました。お元気とのこと、何よりです。ご活躍中の様子が、行間からあふれていました。生産管理の現業をかかえた上に、新規システム導入プロジェクトのメンバーの一員としてアサインされたとは、たしかに大変だろうとお察ししますが、それだけKさんが周囲から期待され一目置かれていることの証左だと思います。 ところで、Kさんからメールをいただくたびに、難しい宿題を投げられたように感じるのですが、今回は格別です。『設計思想に関して』のご質問とは！ なるほど、たしかに新しい基幹業務システムを考える出発点として、“その設計思想はどうあるべきか”を問うのは、とてもオーソドックスかつ当然の発想と思います。自分達が製品を設計開発するときも、成功した製品には明確な設計思想があった。だから、プロジェクトを成功させたければ、当然システムにも設計思想がなくてはならないはずではないか。－－設
なぜあなたのPull Requestは読まれないのか - Qiita
Pull Requestを出してレビューしてもらってから反映。 どこにでもあるありふれた開発フローに付きまとう、どこにでもあるありふれた問題。 「Pull Requestがレビューされない」 もちろん開発フローにレビューが含まれている以上、レビューをしないメンバーにも非がないとは言えませんが、多くの場合はレビューされないPRには問題があるものです。 デカい 兎にも角にもデカいPRは読むのがつらいです。 もちろん要件が明記されていないなど、他にもPRが読みにくくなる原因はたくさんありますが、一番はこれです。 極端な話、1行変更のPRは他に何も書かれていなくても実装内容を察することができますが、10ファイル100行の差分と箇条書き20点の要件が書かれたPRは内容を把握するだけで一苦労です。 しかし、このこと自体は数カ月でもコードを書いていれば自然と勘づくもの。 問題はなぜPRが大きくなってしま
kobito-oss のソースの読み方 - Qiita
メインの開発者として、備忘録を残しておく。 どんなものか試したい人は、 https://mizchi.github.io/kobito-oss/ で、IndexedDBの許す5MBぐらいまでは試せる。 一応言っておくと、これは僕が退職するんでOSS化ってわけではなく、元々あった計画の前倒しです。時期が早まったのはある。 以下、どのようにコードを読むか。 念頭に置くこと 2年前 の技術選定のスタック Mac版Kobitoと仕様が違う。Kobitoと同期しない、Inboxという仮グループがある。 mizchi/arda electron 以前の atom-shell 時代の互換コードが一部残ってる 細々とバグ対応はしつつ、あんまり依存パッケージのメンテ出来てなかった 公開にあたって、個別のタスクの綺麗さより、ビルドできるの優先した とりあえず yarn で固定して yarn upgrade-i
Complexity and Strategy | HackerNoon
Too Long; Didn't ReadI struggled with how to think about complexity through much of my career, especially during the ten years I spent leading Office development. Modeling complexity impacted how we planned major releases, our technical strategy as we moved to new platforms, how we thought about the impact of new technologies, how we competed with Google Apps, how we thought about open source and
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
