ITSSUE ITSSUE

원문 : 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은 당시로서는 놀라운 기계였습니다. 뉴욕 포킵시에서 제작되었으며 무..

원문 : 모든 소프트웨어는 지저분하고 뼈대가 있습니다 (vadimkravcenko.com) Every software is messy and has skeletons You need to accept one truth - every shop is messy and every app has its skeletons. Period. Welcome to the backstage of the software world, where the vadimkravcenko.com 모든 소프트웨어의 제작과정은 동일합니다. 그것을 극복하는 단 한가지, 바로, 휴먼파워 입니다. 모든 상점은 지저분하고 모든 앱에는 뼈대가 있다는 한 가지 진실을 받아들여야 합니다. 마침표. 거대 기술 기업의 매력과 개발 참호의 냉혹한 현실이 만..

원문 : 데이터베이스 기술은 '있으면 좋은' 것이 아닙니다. (renegadeotter.com) Your database skills are not 'good to have' And a hateful ode to Object-Relational Mappers renegadeotter.com Database 전문가는 ORM을 싫어합니다. TDD 개발자는 ORM을 좋아합니다. 누군가는 그 둘을 모두 싫어합니다. 사라져가는 SQL의 기술 지난 몇 년 동안 나는 소프트웨어 엔지니어들이 이국적인 "행성 규모"를 사용하기를 열망하는 불안한 추세를 알아 차렸다 매우 초보적인 문제에 대한 데이터베이스이지만 동시에 매우 강력한 문제를 잘 파악하지 못합니다. 관계형 데이터베이스 엔진은 기술의 고급 및 유용한 기능을 이해하..

파트 1에서는 웹 개발에 기본적으로 알아야 할 사항들과 서버 분산에 대해 다루었다. 파트 2에서는 데이터베이스 다중화를 다루어 보고자 한다. 앞서 설명했든 데이터베이스 다중화는 현대의 클라우드 시대에는 그 의미가 많이 퇴색될 수 있다. 데이터베이스 다중화는 프로덕션 레벨에 있는 시스템에는 반드시 필요한 부분이다. 데이터베이스 또한 완벽한 솔루션은 아니라서 각종 장애와 사용자 실수에 따른 문제가 필연적이고 시스템은 한번 프로덕션에 진입하면 멈출 수 없기에 다중화는 선택이 아닌 필수다. 필자는 아래와 같이 표현한다. "하나의 시스템이 프로덕션 단계로 진입하여 하루 매출이 10억이라면, 그때부터 시스템은 코드덩어리가 아니라 사람과 같이 피가 흐르게 된다. 어떠한 경우도 멈출 수 없고 죽일 수도 없다." 이 지..