ITSSUE ITSSUE

이벤트란 사전적으로 특별한 일이나, 특정 사건을 말한다. 따라서 이벤트라는 메뉴 또는 기능을 만든다면 행위 또는 발생한 사건의 기록을 의미하므로 기록,즉, 연속된 사건의 히스토리이다. 근래들어 이러한 기능을 개발하면서 누군가는 이것을 집계로 본다.모든 사건들의 최대값을 기록하는 것을 이벤트라고 한다면 사건의 기록은 어떻게 되는가? 집계와 기록은 다른 것인데,이것을 동일 선상에 놓고 본다면 당연 틀린 것인데... 이런게 개발하면서 힘든거 아닐까 한다.

개발자는 종종 코너에 몰리곤 한다. 기획대로 개발했고 처음에는 모든게 순조로워 보인다. 하지만, 시간이 지남에 따라 예상과 다르게 흘러가는 중에 코너에 몰리게 된다. 성능은 떨어지고 속도 문제가 발생하고 각종 트러블에 정합성이 깨지고 문제가 어디서 발생하고 무엇인지도 모르는 상태가 계속된다. 이와중에 개발팀장이나 책임있는 사람들은 문제를 해결하지 못하고 퇴사하고 뒷 감당은 모두 남겨진 사람의 몫. 인력을 갈아 넣어서 해결될 일이였다면 문제가 되지 않았을 것이다. 서버에 막대한 비용을 투입하고도 해결하지 못 하는 상태가 되면 회사는 비용과 인력에서 모두 손해를 보게 된다. 결국, 서비스는 종료하게 되고 해당 인력은 정리해고 당한다. 위와 같은 일은 스타트업이나 중소기업에서 흔하게 발생하는 경우다. 심지어 ..

개발자는 언제나 화면을 만든다. 언제나 개발자 곁에는 GUI 도구들이 있었고 사용자를 위해서는 UI가 필요하다. 그렇다면 좋은 관리 UI란 무엇일까? 먼저, 화면 동작에 대한 시나리오이다. 목록 ----------------> 상세 -------------------> 입력 | | | -------------------------> 수정 | | | -------------------------> 삭제 -----------------------> 삭제 모든 화면은 목록을 통해서 진입해야 한다. 그림으로는 아래와 같다. 물론 모든 화면이라는 표현이 맞지는 않지만 일반적으로 위와 같은 시나리오 이다. 상세는 어떨까? 상세는 RTL에 따라 우측 상단과 하단에 각각 버튼이 배치 된다. 상단 우측에 배치되어야 하는..

원문 : RTO는 회사 가치를 향상시키지 않고 직원을 비참하게 만듭니다. 아르스 테크니카 (arstechnica.com) RTO doesn’t improve company value, but does make employees miserable: Study Data is consistent with bosses using RTO to reassert control and scapegoat workers. arstechnica.com 데이터는 RTO를 사용하여 통제권을 강화하고 작업자를 희생양으로 삼는 상사와 일치합니다.

대부분의 개발자는 단위 모듈, 단위 화면 중심에 개발을 진행하게 된다. 즉, 모든 구성 요소가 존재하는 상태에서 요구사항과 화면에 필요한 구성요소를 가지고 개발을 하게 된다. 왜 계정 시스템을 꼭 만들어 보아야 할까? 계정 시스템을 개발해 보지 않고는 절대 단위 모듈과 화면 개발에 대한 근본적인 사고를 할 수 없기 때문이다. 우리가 단순히 계정 시스템은 로그인과 로그아웃, 회원가입과 인증만 처리하는 것으로 생각하기 쉽다. 계정시스템은 단순히 위 기능을 넘어서 모든 단위 개발에 기초가 시작되는 지점이다. 또한 계정계를 어떻게 개발했는지에 따라 단위 개발에 개발 편의성이 달라진다. 웹 개발에 있어 로그인 이후에 벌어질 이후를 생각해 보자. 로그인 이후에 단위 개발자는 로그인한 유저가 누구이고 소속과 일부 개..

빅테크의 임팩트 기반 성과 평가는 끔찍하다 (pcloadletter.dev) Impact-based performance evaluation in big tech is terrible Impact-based performance evaluation in big tech is terrible My theory is that some performance consultants got paid a lot of money one day for a single word: "impact." If you have worked in big tech, you're probably all too familiar with this word because www.pcloadletter.dev 위 컬럼을 읽고 느끼는 소회는 아..

출처 : 개발자의 행복을 파괴하는 10가지 방법 | 인포월드 (infoworld.com) 10 ways to destroy developer happiness Nothing hurts developer productivity like bad management. Keep your dream team motivated by avoiding these common mistakes. www.infoworld.com 우리는 매년, 매번, 매순간 같은 일을 당하고 있습니다. 직장에서 개발자를 불행하게 만드는 10가지 방법 많은 회의 개최 후프를 뛰어 넘게하십시오. 학습 기회를 제공하지 않는다 건강한 일과 삶의 균형을 제공하지 마십시오. 불분명한 기대치 설정 무의미한 프로젝트에 할당 도구를 엉망으로 만드십시오. 그..

원문 : GM-NAA I/O 및 SHARE의 역사 (abortretry.fail) The History of GM-NAA I/O and SHARE The Birth of Computer Operating Systems www.abortretry.fail 메인 프레임 시대에 대해 설명합니다. 오늘날의 컴퓨터 사용자가 1950년대와 1960년대 초반으로 시간을 거슬러 올라간다면 컴퓨팅이 완전히 낯설다는 것을 알게 될 것입니다. 당시는 메인프레임 머신의 시대였습니다. 상업적으로 판매된 IBM의 첫 번째 기계는 1952년 5월 21일에 발표된 701이었습니다. 이 기계는 1년 전에 출시된 UNIVAC 1103과 경쟁했습니다. IBM 701 701은 당시로서는 놀라운 기계였습니다. 뉴욕 포킵시에서 제작되었으며 무..