style: add checkmark icon to Panel

Author: eottabom

posts/clean-code/comments.mdx

@@ -813,16 +813,16 @@ public void onMouseMove(Widget sender, int x, int y) { .. }
 
 :::success
 <b> 개인적인 생각 & 정리</b>
-의무적인 Javadoc 은 없어도 된다. <b> (Clean Code Bad Comments 6, 7, 18) </b>
-API 중에서 특수한 경우 (parameter 에 대한 주석이 필요할 때) Javadoc 으로 작성하면 가독성이 좋다.
+✔ 의무적인 Javadoc 은 없어도 된다. <b> (Clean Code Bad Comments 6, 7, 18) </b>
+✔ API 중에서 특수한 경우 (parameter 에 대한 주석이 필요할 때) Javadoc 으로 작성하면 가독성이 좋다.
 → (반드시 best practices 를 따를 필요는 없으므로!!)
-설명이나 정보를 알려주는 주석은 반드시 필요하다. <b> (Clean Code Good Comments 2, 3, 4) </b>
+✔ 설명이나 정보를 알려주는 주석은 반드시 필요하다. <b> (Clean Code Good Comments 2, 3, 4) </b>
 → 혼란을 야기하는 내용은 안된다. <b> (Best Practices for writing code comments 규칙 4) </b>
 → 너무 많은 정보를 담지 않아야 한다. <b> (Clean Code Bad Comments 15) </b>
-TODO 주석은 필요한 경우만 달자. <b> (Clean Code Good Comments 6) </b>
-참고한 코드의 링크를 추가하는 것이 좋다. <b> (Best Practices for writing code comments 규칙 6, 7) </b>
-버그로 인한 수정할 때 주석을 추가 하자. <b> (Best Practices for writing code comments 규칙 8) </b>
-변수 명이나 메서드 명을 명확히 한다면 주석을 작성하는 일이 줄어 들 것 같다...!
+✔ TODO 주석은 필요한 경우만 달자. <b> (Clean Code Good Comments 6) </b>
+✔ 참고한 코드의 링크를 추가하는 것이 좋다. <b> (Best Practices for writing code comments 규칙 6, 7) </b>
+✔ 버그로 인한 수정할 때 주석을 추가 하자. <b> (Best Practices for writing code comments 규칙 8) </b>
+✔ 변수 명이나 메서드 명을 명확히 한다면 주석을 작성하는 일이 줄어 들 것 같다...!
 :::
 
 

posts/clean-code/why-new-line.mdx

@@ -81,8 +81,8 @@ Preference > Editor > General > On Save > Ensure every saved file ends with a li
 
 :::success
 <b>개인적인 생각</b>
-알고 쓰는 것과 모르고 쓰는 것은 차이가 있다고 생각한다.
-POSIX 명세에 의해서 표준 기능과 호환 되도록 만들기 위해서 따르는 일련의 규칙과 지침을 잘 따라보자!
+✔ 알고 쓰는 것과 모르고 쓰는 것은 차이가 있다고 생각한다.
+✔ POSIX 명세에 의해서 표준 기능과 호환 되도록 만들기 위해서 따르는 일련의 규칙과 지침을 잘 따라보자!
 :::
 
 <br/>

posts/ddd/ddd-core-concept.mdx

@@ -163,8 +163,8 @@ DDD 의 적용 흐름 사이클은 애자일 방법론과 매우 밀접하게 
 
 :::success
 <b>정리</b>
-DDD 는 복잡한 도메인을 코드로 명확하게 표현하기 위한 사고방식이다.
-도메인 모델과 코드 모델의 일관성 유지, 불변식 보장, 행위 중심 모델링이 핵심이며, 패턴을 무조건 따르기보단 <b>상황에 맞는 유연한 적용</b>이 중요하다.
+✔ DDD 는 복잡한 도메인을 코드로 명확하게 표현하기 위한 사고방식이다.
+✔ 도메인 모델과 코드 모델의 일관성 유지, 불변식 보장, 행위 중심 모델링이 핵심이며, 패턴을 무조건 따르기보단 <b>상황에 맞는 유연한 적용</b>이 중요하다.
 → 오버엔지니어링을 경계 해야 한다.
 :::
 

posts/ddd/ddd-fact-misunderstanding.mdx

@@ -241,11 +241,11 @@ DDD 의 철학은 **소프트웨어가 도메인을 정확하게 반영해야 
 
 :::success
 <b>정리</b>
-DDD 의 핵심 철학은 비즈니스 도메인을 깊게 이해하고 소프트웨어에 정확히 반영하는 것이다.
-DDD 는 모든 프로젝트에 적용해야만 하는 것은 아니고, 비즈니스 복잡성에 따라 적절히 활용하는 것이다.
-핵심 도메인에 집중하고, 변화에 유연하게 대응할 수 있도록 설계하는 것이 철학이라고 볼 수 있다.
-DDD 를 적용한다면 모든 문제를 해결할 수 있다는 것은 잘못됐다. 왜냐면 DDD 는 철학과 사상에 가깝기 때문이다.
-도메인 전문가와 개발자가 끊임 없이 협력 유비쿼터스 언어로 소통하고 발전해나가는 것이 중요하다.
+✔ DDD 의 핵심 철학은 비즈니스 도메인을 깊게 이해하고 소프트웨어에 정확히 반영하는 것이다.
+✔ DDD 는 모든 프로젝트에 적용해야만 하는 것은 아니고, 비즈니스 복잡성에 따라 적절히 활용하는 것이다.
+✔ 핵심 도메인에 집중하고, 변화에 유연하게 대응할 수 있도록 설계하는 것이 철학이라고 볼 수 있다.
+✔ DDD 를 적용한다면 모든 문제를 해결할 수 있다는 것은 잘못됐다. 왜냐면 DDD 는 철학과 사상에 가깝기 때문이다.
+✔ 도메인 전문가와 개발자가 끊임 없이 협력 유비쿼터스 언어로 소통하고 발전해나가는 것이 중요하다.
 :::
 
 ---

posts/java/try-with-resources.mdx

@@ -184,8 +184,8 @@ Closeable : AutoCloseable 의 하위 인터페이스로 주로 I/O 클래스에
 
 :::success
 <b>정리</b>
-try-with-resources 를 이용하면 AutoCloseable 인터페이스를 구현한 자원들은 try() 구문에서 자동으로 close() 된다.
-finally 블록 없이 간결한 코드를 작성할 수 있고, 리소스 누출 가능성을 줄일 수 있다.
+✔ try-with-resources 를 이용하면 AutoCloseable 인터페이스를 구현한 자원들은 try() 구문에서 자동으로 close() 된다.
+✔ finally 블록 없이 간결한 코드를 작성할 수 있고, 리소스 누출 가능성을 줄일 수 있다.
 :::
 
 

posts/spring/jpa-determine-entity-is-new.mdx

@@ -176,9 +176,9 @@ Database 에는 해당 ID 가 존재하지 않지만, 신규 Entity 임에도 
 
 :::success
 <b>정리</b>
-Spring Data JPA 는 내부적으로 isNew() 를 통해서 신규 Entity 여부를 판단한다.
-ID 는 존재하지만 실제 DB 에 없는 경우 SELECT + UPDATE 후 merge 를 하므로 정합성이 떨어질 수 있고, 비효율적이다.
-ID 를 직접 설정했을 경우는 Persistable + isNew() 로 명시하는 것이 필요하다.
+✔ Spring Data JPA 는 내부적으로 isNew() 를 통해서 신규 Entity 여부를 판단한다.
+✔ ID 는 존재하지만 실제 DB 에 없는 경우 SELECT + UPDATE 후 merge 를 하므로 정합성이 떨어질 수 있고, 비효율적이다.
+✔ ID 를 직접 설정했을 경우는 Persistable + isNew() 로 명시하는 것이 필요하다.
 :::