図とか表は説明の補助であってメインじゃない。
そういう仕事ある。
そういうのやっていく。
ダイエットしたらいいとか、英語を勉強したらいいと同じなのか、やれば確実に誰でもできる仕事で、そのリターンも確実にあるのに誰もやらないよね。
overflow:hidden VS scrollto だとスクロールするね。これはこれで便利だな。
実際テトリスみたいにブロック積んでくし。
HTML CSS での Webサイト作りはおそらくぷよぷよだと思う。答えが完全にわかっている膨大な定型のパターンがあって、あとはそれを明確なゴールに向かって膨大に素早く処理していくだけ。
測量野帳にWebサイトの仕様をびっちり書いていくとこれだけで仕事した気になってよろしくないが、必要なのだよね。
rebase は歴史改変になるので基本的にやっていいのは誰にも共有されていない個人のブランチだけです。
rebase は歴史改変になるのでそれを嫌うという人はいるかとは思う。
試行錯誤が終わったあとのソースコードの整理が心地よい。
なんかボトルワークをやってるみたいになって「キーーッあｑｗｓでｆｒｔｇｙふじｋ」となる。
WordPress の CSS が挿入される順番とか、Tomcat の Filter が挿入される順番とか、ああいうの
プログラミングで詰まったところ思い出した。
「何がどの順番でいつ動くのかわからない」→「動きを追うのをあきらめる」
これ。
プログラミングの設計テクニックは複雑な汚いゴミをどこにうまく押し込むかのような気がしている。ゴミがなくなるわけじゃない。
テスト書く時は、そういう仕様なんだから、これはチェックしないとダメ。コストが掛かる仕様だからコストを掛けていると考えて書いている。
なぜ(Web)デザインを言語化したくないのかね・・・。レイヤーとか色に名前をつけないというのはそういうことなんだと思うよ。
rebase は外部の変更を取り込んだ場合に自分のローカルがそれに追従するために使う。そうすると commit が発生しないので、純粋に意味のある commit が積み重ねることががきる。逆に言うと変更をローカルに取り込む際に merge すると取り込んだタイミングで merge コミットが発生して開発の共有している本線がmerge commit だらけになってしまう。 merge は「ここでこの機能が入りましたよ」という印が commit という形で残るので、プルリクは merge で開発中のローカルでは rebase でやるというのが普通。
複数人開発では rebase 必須です。
平成バブルよりも令和の今は貧しくなったって凹むのって、三丁目の夕日的な郷愁バイアス入ってるんじゃないの、賃金は別として生活は今のほうがいいだろ普通に。
高速で安いネットとかどこでも繋がるスマホとかそういうの無しにできるか？
自分もテキストにまとめるのがライフワークになっている。おそらく死ぬまでまとめ続けると思う。