본문 바로가기

관심사

티스토리 에디터처럼 코드 하이라이트 변경하기 1. HTML에 아래의 코드를 추가한다. atom css 파일은 hilight.js에서 다운받은 후, 티스토리에 업로드해서 사용하면 된다. 2. 티스토리 CSS 변경하기 /* 문단 간격 */ .entry-content p { margin-bottom:30px; display: block; margin-block-start: 1em; margin-block-end: 1em; margin-inline-start: 0px; margin-inline-end: 0px; } /* code highlight */ .entry-content pre { background-color: #fafafa; padding:20px; font-size: 14px; padding: 15px; border-radius: 3px; f..
최범균 <DDD START! > 4-5장 요약 4장. 리포지터리와 모델 구현 별도 테이블에 저장하는 밸류 매핑 애그리거트에 속한 객체가 밸류인지 엔티티인지 구분하는 방법은 고유 식별자를 갖는지 여부를 확인하는 것이다. 하지만 식별자를 찾을 때 매핑되는 테이블의 식별자를 애그리거트 구성요소의 식별자와 동일한 것으로 착각하면 안된다. 별도 테이블로 저장되고 테이블에 PK가 있다고 해서 테이블과 매핑되는 애그리거트 구성요소가 고유 식별자를 갖는 것은 아니다. 보통 주문 애그리거트는 실주문을 의미하는 Order 테이블과 주문 품목을 의미하는 Order Lines 테이블로 구성되어 있다. 여기서 주문 품목(Order Lines)은 밸류이다. Order Lines 테이블도 고유 PK를 갖고 있지만, 주문 애그리거트를 식별하는 고유 식별자는 주문번호이다. (위 ..
(디버깅) Google Chrome 개발자콘솔로 프론트 통신상태 조절하기 Slow 3G으로 설정해주면, 통신상태가 불안한 상태에서 프론트가 처리되는 상태를 디버깅할 수 있다 👍
위르헌 아펄로 -Management 3.0 9. 제약 조건을 정렬하는 방법 여러분의 목표와 팀의 목표를 절충하자 팀과 목표가 부딪히면 그걸 해결해야 할 것이다. 팀의 결정을 무시하면 매우 갚기 어려운 동기 부채가 생길 것이고, 그건 상황을 더욱 어렵게 만들 뿐이다. 권한 경계 목록을 만들자 권한 경계 목록을 만들면 사람들이 전기 철조망에 뛰어들지 않아도 되기 때문에 사람들에게 동기를 부여하고 생산성을 유지할 수 있다. 10. 규칙을 만드는 기술 애자일의 맹점 애자일 선언의 애자일은 팀이 훌륭할 때만 훌륭하다. 애자일 선언이 역량 문제를 해결해주지는 않는다. 프로젝트의 치사율을 낮추고 싶은 애자일 관리자라면 아래의 기본 원칙을 응용할 수 있다. 문화 : 사회 시스템의 역량을 높이기 위해 어떤 방법을 적용하든, 결국 모든 것은 사람이 진심으로 관심이..
(온라인스터디) TELECONSOLE + teletype Atom 온라인 오픈소스 스터디할 때, 행아웃으로 화면공유를 하니까 잘 안보였다.그래서 터미널을 공유할 수 있는 프로그램인 TELECONSOLE과, ATOM 화면을 공유할 수 있는 teletype Atom을 써봤었는데, 신세계였다. 😻온라인으로 협업할 일이 있으면, 요 두개를 가져다 쓰면 완전 좋다. TELECONSOLE teletype Atom 텔레타입 아톰은 Host Atom에 게스트 Atom이 접속하는 개념인데, 읽기 권한만 있는 구글 드라이브 문서를 보듯.. 아톰 화면을 볼 수 있다.
<사이트 신뢰성 엔지니어링> - 2부 요약 본문 중에서...Chapter 6. 분산 시스템 모니터링 알럿 호출 방식 철학매번 호출기가 울릴 때마다 긴급한 상황임을 인지하고 그에 대응할 수 있어야 한다. 이러한 긴급 호출은 빈번한 호출로 인한 피로를 느끼지 않도록 하루에 단 몇번 정도만 발생해야 한다.모든 호출은 대응이 가능해야한다.호출은 새로운 문제나 지금까지 보지 못한 사건에 대한 것이어야 한다.호출에 대한 모든 대응은 이성적이어야 한다. 장기적 모니터링 장애 호출에 대해 이미 정해진 규칙에 의해 대응하는 것은 위험 신호다. 팀의 그 누구도 이런 호출에 대해 자동화를 할 의지가 없다는 것은 팀이 스스로 만든 기술 부채를 해소할 자신이 없다는 것을 암시한다. 한 걸음 더 나아가기 순수한 노력의 힘은 너덜너덜한 시스템을 고가용성을 갖춘 시스템으로 ..
제럴드 와인버그 <Quality Software Book : How Software Is Built > - 9장 요약 Chapter 9: Why It's Always Hard to Steer9.2.2 The history of software engineeringThe Size/Complexity Dynamic 은 문제의 크기가 커질수록 복잡도가 제곱으로 높아지는 문제 유형을 말한다.소프트웨어 역사를 보면, 성공하는 경험을 할 수록, 조직은 점점 더 어려운 문제를 찾고, 도전해왔다. 그러면서 소프트웨어가 발전해왔다. 위의 그림은 소프트웨어 개발에 대한 effect diagram이다.소프트웨어 조직이 성공을 경험하면 -> 도전적인 과제를 찾아서 -> 문제의 크기가 커져서 -> 솔루션의 복잡도가 높아진다.문제의 난이도가 높아지면, 처음에는 개발자수를 늘리고, 고급인력을 채용하면서 리니어하게 문제를 해결할 수 있다. 그런데 ..
(Draw.io) 온라인 다이어그램 툴 https://www.draw.io/여기 들어가서 그리면 된다 ㅎㅅㅎ XML으로 저장해두고, 나중에 재수정해서 쓸 수도 있다. 요런식으로 그려다가 쓰면 된다 ㅎㅅㅎ