JJUG CCC 2018 Spring 参加報告

JJUG CCC 2018 Spring

今回

今回は、登壇者としても参加しました。
OCJP SE 8 Gold合格までに取り組んだこと というやつ。

大勢の人前で話すのは、小学校以来かな？
やっぱり、人前で話すのは難しい。。。

なお、ツイッターの視聴者の感想は、怖くて見てない。

参加セッション

• JavaでWebサービスを作り続けるための戦略と戦術
• Pivotal認定講師が解説！ReactiveだけじゃないSpring 5 & Spring Boot 2新機能解説
• Spring Boot と一般ライブラリの折り合いのつけかた
• JavaエンジニアのためのDocker入門 〜 仮想開発・テスト環境構築 〜
• アンカンファレンス3
• JDBC APIもそろそろ非同期の波に乗りたいらしい

メモ

JavaでWebサービスを作り続けるための戦略と戦術

• 開発環境とは、動くソフトウェアで進捗を測る場所
• やったこと
  • 開発環境の構築手順書は廃止して、スクリプトで作成できるようにした。
  • サーバー郡は、仮想OSの中に仮想OS作るようにした。
  • docker使わなかったのは、当時のmacのdockerが不安定だったから
• dockerfileを書くのは、アプリエンジニアの担当。知見は集めておいたほうがいい。
• eclipse -> intellij に移行
  • プロジェクトが増えると、eclipseでの表示はキツイ。。。
• maven -> gradle に移行
  • 数が増えると、カスタマイズしたいことが発生するので、柔軟なgradleへ
  • xmlよりソースを見たほうが、理解しやすかった。
• jenkins 1 -> 2 にバージョンアップ
  • mavenよりこっちを先に実施。
  • jenkinsfileにスクリプト書いて、両方に即時対応できるようにして、移行がすぐできるようにした。

最終的な目標として、プルリクエストに１つに対して開発環境が自動生成されるようにしたいらしい。
環境による制約で、時間を無駄にすることをなくしたいとのこと。

• 老朽化した技術からの脱却
  • インストール型のTomcatはオワコン。newするもの
  • jasperreportはオワコン
    • java8化を阻害するボトルネックになっていた
    • 現場なりの地雷がある。
  • jsessionidはオワコン
    • 開発環境を複数起動すると、jsessionidがバッティングする
    • 開発者にとっては、非常にネック
  • sticky-session-id
    • sticky-session-idを使っているとawsのLBが片方にしか振り分けなくなる。。。
    • だからやめて、spring-sessionに変えた
  • jspはオワコン
    • ゴミが溜まる。
    • webapp下の配置は、おく意味がないので、resources配下においたほうがいい
• フロントエンジニアと仲良く
  • swagger
    • 見やすいドキュメントがすぐにできる
• テストコード
  • プルリクエストで自動テスト実行
  • 自動テストが通らなければ、マージできないようにしたいらしい。
• 脆弱性を無視していると、どこかのタイミングで地雷を踏む
  • ちょっとずつバージョンアップするしかない
• ビックリライトは難しい
• やるならリファクタリング
  • リファクタリングを支えるのは、テストコード、環境の自動構築
  • こまめなバージョンアップがセキュリティリスクを低下させる

感想

dockerは、アプリエンジニアの担当。。。
概要把握で満足していたが、きちんと内容を把握しないと。。。
３万行のソース削除のプルリクは、初めて見た。たぶん、もう２度と見ることはないだろう。

ビックリライトは、難しいというのは同意。
ビジネス的にも、その判断を下すのは難しいと思う。
リライトは、ハガレンのＯＰで十分である。

Pivotal認定講師が解説！ReactiveだけじゃないSpring 5 & Spring Boot 2新機能解説

• core
  • jdk8ベース
  • JDK9/10対応
    • 対応しているが、しばらくの間は、jdk8で使うのが無難
  • ロギング
  • ビルド時のコンポーネントインデックス作成
    • spring-context-indexer
      • コンポーネントスキャンの遅さを解消
      • コンポーネントスキャンするリストを自動生成して、必要なものだけコンポーネントスキャンする
      • 大きいプロジェクト向け。小さいプロジェクトだと、かえって遅くなる
  • 新規アノテーション @NunNull @Nullable
    • nullの可能性を示すためのもの
    • IDE上で検知できるようになる
      • 検知できるもので、代入できなくなるものではない
• web
  • https/2対応
    • pushBuilderを引数で貰える
    • サーバーがhttp2に対応している必要がある
  • bean validation2対応
  • webMvcConfigurerAdapterの非推奨
  • イミュータブルなフォーム
    • 変更はしてはいけないので、本来はイミュータブルであるべき
    • Boot2+mavenで、デフォルト有効
    • まだバグあり。。。
  • 例外処理の便利機能
• data
  • 破壊的変更あり。互換性なし
  • Spring data jdbc
    • IFを定義するだけで、追加・更新・削除ができる
    • 実装は、起動時に動的に生成される
• securty
  • oauth2.0対応
  • delegatingPasswordEncoder
    • DBに保存する際、ハッシュをかけて保存する
• test
  • junit5対応
• Boot
  • spring5対応
  • jdk8対応
  • セキュリティ簡素化
    • java configに一本化
  • Actuator
    • /info, /health以外は公開されなくなった。
    • 公開するには、設定が必要
  • プロパティ名
    • リアクティブ対応で変わった
    • 移植用のツールが用意されている。

感想

Spring data jdbcが気になった。
そういえば、Javaやってた頃は、１リクエストで、検索か更新か削除のどれかをやる感じだから、毎回アクセス用の実装を作るのは、不便だと思っていた。
気になるのは、自動生成で意図せぬバグが入り込まないか。ソースの自動生成は、内容を分かってないと、ハマるポイントになったりするから、それだけが気になった。

SpringBootの進化が早い。。。
JDK9ベースになったら、さらに進化が加速しそうな気がする。

Spring Boot と一般ライブラリの折り合いのつけかた

• DIはなるべく使う
  • 使えない場合は、factoryクラスを作って対応する
• プロパティファイル
  • getter/setterは。@ConfigrationPropertiesで解決可能

途中でついていけなくなってしまったのです。。

JavaエンジニアのためのDocker入門 〜 仮想開発・テスト環境構築 〜

dockerは、アプリエンジニアの担当 ってワードが耳に残って拝聴

• docker特徴
  • 起動が早い
  • リソースを共有しているのでリソースが節約されている
• dockerのメリット
  • 環境を使い捨てできるので、サーバー設定関連が必要なテストがやりやすい
  • どこでもビルド環境ができるかもしれない
  • 環境を配布・構築が楽になる
  • だれか一人が苦労してくれれば、すべて楽になる

まずは、自分の開発環境から試してみる。

• 適用について
  • 無理に利用する必要はない
  • 手短なところや、利用したら便利そうなところ
  • 使い捨て前提やる（データとか残したい場合は考える）

感想

誰か一人が苦労するのが、俺なのは嫌だな～という感覚をもってしまうのは、僕だけではないはず。
環境構築が楽なのは、なんとなく分かっているが、実際にやってみないと、真に理解しているかは怪しいかも。。。

環境を使い捨てる感覚を持つってのは、意外と難しい。
せっかく作った環境を、役立てようとする意識があるから。。。
環境が楽になれば、その感覚は消えると思う。
まずは、dockerの便利さを味わうことが大事かもしれない。

アンカンファレンス3

情報収集・欲しい記事・教育について討論。

情報収集

• webでの情報収集が多い
• rss使う人は、思ったより少ない

流行の抑え方

• 勉強会で流行を抑える
• カンファレンスの動画
  • youtubeで英語の字幕を見て、単語から流行を探る
• Safari Books Online（オライリー）
  • 本・動画が引っかかる
  • 有料サービス
  • 障害調査とかでも使える（横断検索）

思うこと

動画の情報収集が発展しそうとあったけど、個人的には無理な気がする。
なぜなら、動画は情報にアクセスするまで時間がかかると思うから。
あと、繰り返して情報を読み取るのに適していない。
わかった気になりやすいと感じている。

情報を引き出すなら、たぶん、直接あったほうが楽だと思う。

Safari Booksってのに興味を持ったけど、$399は、さすがに、キツイ。。。

あと、以外だったのは、RSSを利用している人が少ないこと。
全員RSSだと思っていた。。。
僕は、feedlyにRSSを突っ込みまくって、外出先で、スマホを使ってニュースをフィルタして、pocketに一時保存する。価値ある情報であれば、さらにそこから深掘り調査って感じ。
ただ、問題があって、登録したサイトが馬鹿みたいに多いと、情報をさばけず、フィルタリング作業がパンクするという。。。
情報をサマリできないか、手探り状態。
誰か、いい方法を知っていたら教えて欲しい。

教育

大学の方が、学生に何を期待しているのかを聞いていた。

結論的には、言語問わず、汎用的な知識が必要って意見に落ちた認識。

思うこと

話を聞いていたが、業務知識を学生が覚えるべきだと聞こてた。
それは、少し酷な話のような気がする。
現場によってマチマチなので、学生としてやって欲しいことではない気がする。
むしろ、それは現場が教えるべきことだし、それができないってのは、何を考えて仕事しているの？って感じた。
学生は、専門用語でも意思疎通が取れるレベルになっているくらいでいいと思う。
後は、トレース能力とか。

個人的には、謙虚さがあれば、問題ないと思う。
結局のところ、素直に学ぶ姿勢を示せることができれば、案外、この業界の人は協力的なので、勝手に成長していくと思う。
その方が、たぶん、現場の受けもいいと思う。

懇親会

speakerだと、風船をつけるのだが、風船をつけると特別視されて、話しかけてくれる人が多いんだな～って感じました。
有料なのに、人が意外と多い。。。
人混みは、苦手なのです。。。
寿司とか、人が密集していて、なかなか取りに行けなかった。。。

人混みで思い出したが、満員電車に乗ろうとした時、中の男が「無理無理」ってDIO並に連呼してきたから、乗るのを辞めたのだけれど、後ろから若そうな女性が乗り込もうとした。
その時、中の男は何も言わないんだな。死ねばいいのに。
この恨み、まだ覚えてる。

登壇について

登壇してみての反省・感想

• 時間を余らせててしまった。。。練習のときは２０分オーバーだったんだが。。。
• 開発者ノートが見えれていれば、もっと時間をかけてできたかも
• 他の人のセッションを見てわかったが、最後にまとめを持ってくることで、時間調整を可能にしている？時間がなければハショるし、あれば、話を盛って話して延命処置をすればいい。
• 試験対策資料が公開されているらしいが、知らなかった。。。オラクルのサイト見ず、ピアソン経由で試験受講は終わるので、目につかずに終わってしまう気がする。

思い通りにやれなかった。。。。
練習不足か、資料の作り方が悪いかのどちらかだろう。。。
あんまり文字は入れたくない派だけど、喋らなきゃいけない内容が覚えられないということがわかった。
やっぱり、人前に出ると、頭がホワイトアウトします。

全然時間が経たないのだな。。。
心拍数が上がっていたから、体感時間が早かったのかもしれない。

登壇して良かったこと

• オラクルの認定試験作っている人に会えた
  • java8の次はどうするか、検討中らしい
  • 個人的な予想だと、次は、Java9かLTSのバージョン(java11)になりそうな気がする。

typescriptの自動インポートでハマった話

きっかけ

自動インポートを使っていたが、とある問題があったので、辞めた。 ちなみに、使っているのは、VisualStudioCode。
拡張機能は、名前忘れた。。。

起きた問題

自分は、コード上にないものでもタイピングして、インテリセンスを使ってコードをある程度生成させる手法をよく使う。
しかし、クラス上にはないけど、プロジェクト内で定義されているものがあった場合、勝手にインポートされて、定義した型が予期しない型になっていた。。。
reduceとか、foreachの繰り返しで、定義した型に変換するときに、定義してないハズの値がないって言われて、１日くらい悩んでた。。。

原因は、自動インポートされているせいで、余計な型情報が読み込まれ、勝手に型情報が拡張され、予期しない状態となっていた。。。
コードが追加されたってことを知っていれば、即気づいたと思うのだが、静かにコード追加されるのは、意図しない悪影響がある。

今回から得た考察

自動でコード生成されるのは、危険。
ＩＤＥ側は、コード補完する場合は、ユーザ許可を求めるような作りになってないと、意図しない実装で開発者を困らせることがある。

感想

マジでくだらないことで悩んでしまった。。。
俺って能力ないのかな？って思ったけど、そもそもの原因は俺じゃないから、こんな拡張機能を作ったひとが悪いと思うようにしてます。

Java Day Tokyo 2018 参加報告

Java Day Tokyo 2018｜日本オラクル

参加セッション

• Java Day Tokyo 2018 基調講演
• Java in a World of Containers
• Project Valhalla
• Java in Serverless Land
• Java SE 10、そしてJava SE 11への移行ガイド

本当は、17:20-18:10は、Project Loom を見たかったけど、満員だから諦めた。。。

感想

Java Day Tokyo 2018 基調講演

去年と似た感じの流れ。
実績紹介からデモ、日本横断の内容紹介、JJUGの紹介で締めくくり。

聞いていて驚いたのは。JDK10日本語ドキュメントを公開したこと。

概要 (Java SE 10 & JDK 10 )

前聞いたときは、日本語を公開できるかは分からない的なことを言っていたと思うのだが、頑張ったんだな。

気になったのは、mission controlleのパフォーマンス測定のデモ。
見た感じ、かなりスッキリした感じの画面だったので、早めにキャッチアップしたい。

Java in a World of Containers

• 今は無秩序な拡張がドンドン広まっている。環境はバラバラなものが多い。そんな時代だから、Javaは重要。
• linuxのイメージサイズが、javaより少なくできる。
  • alpine linuxとか言ってたかな？
• イメージを小さくするには、静的クラスの共有がネックになってくる。
• 静的クラスを共有することで、プロセス間でデータを共有できる＆スタートアップ時間の現象の恩恵が得られる。

linuxイメージが無茶苦茶小さくできることに驚いた。
要領で行ったら、５０MBいかないくらいだから、ポケモンGoのアプリより少ないってことだぜ？
そう考えると、イメージを小さくするのは、かなり研究が進んでいる気がする。
小型化は日本の専売特許だと思っていたが、日本のプログラミング能力は低すぎやしないかと危機感を覚える。

Project Valhalla

• 命名由来が、valhara が value type に似ているかららしい。。。
  厨二的な心を揺さぶる由来があるかと思ったのだが、ガッカリだよ。。。
• Javaは、オブジェクト型だけにすればスッキリしたが、パフォーマンスの問題があったので、プリミティブ型が入った。
• 従来のレイアウトは、メモリ使用量が多く、格納場所がメモリ上で離れた場所になる可能性があり、パフォーマンス劣化の可能性があった。当初はそんなに問題にならないだろうと思っていたとのことだが、予想に反して大きくなってきたので、今回の対応が入った。
• クラスの構成がプリミティブ型に近いものになる。
• 今回の対応で、クラスのような実装だが、intのように振る舞うようにするのが目標
• 一番の問題はジェネリック
• ジェネリック対応ができれば、プリミティブに特化したStreamは不要になる
  • 学習コストを減らせる
  • 余計なことを覚えなくていい
• valharaはパフォーマンスメインだけど、使い勝手も良くなるはず
• ジェネリックをどうやって実現するかは、悩んでいる状態。any型をいれるかどうかってのが話題になっているらしい。

プリミティブ特化のStreamが無くなるのは、喜ばしい。
あれ、いちいち面倒くさい変換したり、学習コストをかけるのは、ものすごい馬鹿らしかったからな。

Java in Serverless Land

Fnの紹介だったな。
翻訳機？を借りるのを忘れて、何を言っているのか、あんまり把握できなかった。。。
英語使えるようになりたいなぁ。。。

Java SE 10、そしてJava SE 11への移行ガイド

黒魔術で死にそうなJavaコードを動かそう的な感じだった。
できることなら使わないほうがいいですよってことだったから、内容はあんまり覚えてない。
だいたいコマンドラインオプションでどうにかするのが多かったが、java9からはモジュールの公開範囲の概念が入って、module-infoの扱いがネックになる気がしました。

思ったこと

jdepsがいたるところで耳に入ってきた。
受けたセッションがそれ系が多かったかも知れないが、今後、jdepsが重要なツールになりそうな気がする。
今年もクラウド推しが強い。
今後のスキルセットを考えたら、今のうちにクラウド系のサービスを利用しといたほうがいいかな？って思いました。

タスク

• mission controlle
• カスタムイメージを作ってみる
• jdepsについて調査
• fn試す
• java11の情報収集

tsifyでout of memoryが発生した時に対応したこと

きっかけ

金曜日の夜に、現場のGitリポジトリに修正内容をプッシュしたら、ビルドエラー通知が飛んできて、ビルド時にメモリ不足が指摘された。
一応対処はしたけど、原因究明はまだできてないが、忘れそうなので、記録に残しておく

余談

問題発生タイミングが最悪。
なんで、よりによって金曜の定時後に発生するん？
起こしたのは俺だけどさぁ。。。

メンバーが残り少ない状態で発生して、かなり焦ったわ。

詳細

対応

gulpのタスクに、--max-old-space-size=4096 を追加した。
なぜ発生したのかは分からない。
月曜、調査しないといけない。。。

たぶん、クラス情報をコンパイル時にメモリ保持していると思うのだが、たぶん、大量にクラスを作ってたから起きたんだろうと勝手に予測。
月曜に本格的に調べる。

悩んだこと・詰まったこと

node のコマンドに --max-old-space-size=4096 って付けたんだけど、効果がなくてかなり迷った。
gulpは別プロセスで起動するのだろうか？とりあえず解決したからあまり調べなかったけど、後々になって気になった。

ついでに覚えたこと

--max-old-space-size で指定するサイズは、MB。

反省

手元ではメモリ不足になることは分かってなかったですわ。。。
そもそもマージしただけで、マージ元でエラーなかったし、先でもエラーなかったから大丈夫だろうって思ってたら、コレですわ。。。
ちゃんとプッシュ前にビルド通るかきちんと確認しておけば良かった。。。

参考サイト

Node.js の out of memory エラー回避方法 : まだプログラマーですが何か？

Gulp で process out of memory が出た時の解決方法 | フロントエンドの道標

最近気づいた恥ずかしい話 Javaのインスタンスメソッド参照

きっかけ

Javaは得意分野だけど、知らないことが合ったので、無知を減らすために晒す。
戒めの意味も込める。

導入

はい、タイトル通りでぇーす。
最近知りました。

static(クラス)メソッド参照、コンストラクタ参照は知ってましたが、普通のメソッドも参照できるとは思わなかった。。。。

サンプルコード

とりあえず、実験のため、コード書いてみる。

import java.util.stream.Stream;

public class Test {

    public static void main(String[] args) {
        Stream.of(1,2,3).map(MethodRed::new).forEach(MethodRed::exec);
    }

}

class MethodRed {

    private int target;
    public MethodRed(int target) {
        this.target = target;
    }

    public void exec() {
        System.out.println("test:" + target);
    }
}

やっていることは、Streamに 1~3 の数値を流して、それをもとにMethodRed を生成して、exec メソッド呼び出しているだけ。

こんな使い方できるんだなぁ～って最近知った。

念のため、実行した結果も確認

test:1
test:2
test:3

想定通り。

考察

本当は、stream内であんまり呼び出さないほうがいいのだろうと感じる。
状態が変わるようなら、別インスタンスでやったほうがいいですからね。。。
やる場合は、メソッドが状態を切り替えたりしないような実装とメソッド名にしておかないと、ソフトウェアとして成長する過程で、変な依存を生んでバクを作り出すような気がしました。

あと、これ知ったときは脳天を叩かれたくらいの衝撃が走りましたわ。。。
己の無知を恥じるばかりである。

ちなみに、知ったキッカケは、IntelliJ IDEAのヒント。
マジ、IntelliJ賢いな。
俺より賢い。

指示語が指すものを判別する その２

前回記事

suzaku-tec.hatenadiary.jp

今回、書くに至ったきっかけ

よくよく考えたら、同じ文でも指示語の対象があるな～と思い、ちょっと考えなした。

詳細

例えば、以下のケース

机の上に本があり、それは、母が読んでいたものだ。

前回の実装だと、前の文から探しにいくので、何も設定されない。
だが、この場合の それ は明らかに文章内にある 本 を指している。

解決方法

まず、同一文内で、指示語より前にある主語があれば、それを適用するようにした。
倒置法だったらどうするのって思ったけど、その場合は、指示語を使えないハズなので、考慮の対象外にした。

問題点

上記の解決方法で全部なんとかなるだろうと思ったけど、上手くいかなかった。。。
なぜかと言うと、分単位で位置を特定しているため。。。。

もう少し詳しく説明する前に、ちょっと導入説明。
形態素解析には、kuromojiを使っているのだが、その解析単位は、分単位でしている。
下記を例にする。

企業は自動車やテレビや冷蔵庫など新らしい製品が次々と発売する。それらを買うためには古い製品を捨てなければならず捨てたものの大半がゴミになる。

この場合、文は、企業は自動車やテレビや冷蔵庫など新らしい製品が次々と発売する。 と それらを買うためには古い製品を捨てなければならず捨てたものの大半がゴミになる。 になる。
その文単位で形態素解析をしているため、形態素解析した結果のトークン情報の位置情報が、文ごとにリセットされている。
最初から、全部一緒に形態素解析すればいいじゃんって思ったけど、そうすると、段落毎の関係性の解析、文書間の関連性の解析が難しくなるのと、長文の場合、位置情報がオーバーフローすると感じたため。
kuromojiの位置情報は、int型なので。。。
今作っている文章解析のライブラリは、長文が前提にあるので、避けたかった。

長くなったが、そういう理由があって、分単位で解析していた。

結構、これに気づくのに時間がかかったわ。

解決方法

もう、どうしようもないので、全部位置情報でなんとかするのは諦めた。

問題は分割して解決するようにした。

どうしたかというと、まず、同一文章内で指示語がないかを、位置情報で解決するようにした。
それで見つからない場合、全文の主語をあてがうようにした。

今後の問題点

ある程度、思い描いたことができるようになってきた。

ただ、まだ動作がおかしい感じがするわ。。。
喋り言葉は、ほぼＮＧなんだよね。。。。
きちんとした文章なら、きちんと解析できるんだけど。。。
文章の正確さによって、解析結果があてにならなくなったりするのが辛い。。。
今後は、そこら編の精度を高める必要があると感じている。
もしかしたら、アプローチ変える必要があるかも知れない。

プログラミングの初心者を抜け出すための習慣の感想と要約

きっかけ

ソニックガーデンの倉貫のブログはよく見る。
かなり感心したので、自分の考えと経験を踏まえてまとめてみる。

感想

エラーが出ても慌てず、メッセージを読もう

エラーをググって、解決法を片っ端から試すってことを、初心者のうちはよくしてたなぁ～って思い出す。
本当にやるべきは、吐き出したエラーの意味を理解して、正しく対処すること。

書いている意味がわからない状態だと、ググって調べた解決法を試して、さらなる深みにハマることが多々ある。

ググるってのが、さらなるエラーを呼び出す可能性を忘れてはイケない。

ネットの情報を鵜呑みにしない

エラーが出ても慌てず、メッセージを読もう と同じ。
ネットの情報を鵜呑みにした結果、さらなるエラーを呼び出す可能性が高い。

状況を理路整然と書いてあるかどうかも分からない。
特に多いのが、環境情報をまったく書いてないこと。
だから、読み間違うことが多い。
ブログ書く場合は、環境情報をきちんと書く必要がある。

公式ドキュメントから読もう

難しいね、これは。
ボリュームもそうだが、言い回しが面倒なときもあるんだよね。。。

あと、意外と知りたいことが書かれてないこともある。
たまに、分かっている前提の記載がある気がするわ。

ギャグセンスも必要だと思うんですよ。ドキュメントってのは。
面白くかけるかも、ドキュメントには必要だと思うのです。

当てずっぽうで試していかない

エラーが出ても慌てず、メッセージを読もう と同じですね。
あとは、ログをちゃんと読んで、時系列と動作状況を認識しないと、いろんなひとを誤解させてしまう。

未知のものは、まっさらな環境で試そう

不穏分子があると、未知はより大きな未知になる。

なるべくクリーンな環境を作る必要がある。
あと、そのクリーンな環境を簡単につくる方法を用意しておくと良いだろう。

ライブラリを見つける力と目利きを鍛えよう

プログラミングは、何かしらのライブラリを使うことが多い。
俗に言う、「車輪の再発明」をしないため。

だから、ベストな開発をするためにも、便利な環境が必要だと思う。

大雑把に理解できる力を身に付けよう

なんでも全部調べていたら、キリがないのです。
必要な知識レベルを見計らって、適度な内容で撤退するのも、時間をうまく使うという意味ではあり。

深入りする前に、本当にそこまで必要なのか、考えても良いでしょう。

一度に大きく作ろうとせず、小さく進めよう

これな、一気にやろうとして、どこまでできていたのか分からんパターン。

だいたい、自分に自信があるやつが陥るパターンやで。
昔の俺がそうだった。

自尊心が高いやつほど、気をつけないといけない。

「正しく動く状態」をキープするってのが大切。

コミットする前には、動作確認しよう

コミット前にはテスト。

正しい状態を保つための基本

最初にTODOリストを作ってから、始めよう

だいたい、一つのことに熱中すると、やることは大抵忘れる。
だから、TODOリストは必要なのだ。

頭で理解しきれないなら、絵にしてみよう

字にしても、関係性は見えてこないことがある。
イメージに落とし込むことで、理解が簡単になることもある。

字ってのは、頭のメモリをいっぱい使うので、注意が必要なのだ。

メンテナンスの前に、コードを読み込もう

内容理解してからやらないと、オヤシロ様の祟りが起きます。本当です。