윈도우 파일 강제 삭제 방법 - CMD

윈도우 명령 프롬프트에서 DEL(파일), RD(폴더) 명령 사용

Windows 시스템으로 이동해 아래에 있는 명령 프롬프트 아이콘에서 마우스 오는쪽 버튼을 클릭해 ‘관리자 권한으로 실행’을 선택합니다.

파일 삭제 – 명령 프롬프트에서 ‘DEL /F /Q /A’ 명령 사용

우선 지워지지 않는 파일을 지우기 위해서는 DEL /F /Q /A ‘파일 경로’를 입력합니다.

• DEL : 말 그대로 삭제 명령어
• /F : 읽기 전용 파일을 강제 삭제 명령
• /Q : 삭제 확인을 하지 않음
• /A : 숨김 파일같이 특성을 가진 파일에도 적용하라는 의미

DEL /F /Q /A '윈도우 파일 경로'

폴더 삭제 – 명령 프롬프트에서 ‘RD /S /Q ‘ 명령 사용

특정 파일이 아니라 폴더를 통째로 삭제하려는 경우는 명령 프롬프트에서 RD /S /Q ‘폴더 경로’를 입력해서 특정 폴더를 강제로 지울 수 있습니다.

• RD : 폴더를 삭제하는 명령어, Remove Directory
• /S : 하위 폴더와 파일을 모두 삭제
• /Q: 확인없이 삭제 의미

RD /S /Q '폴더 경로'

[python] perfect way to learn python in 10 days 

Day  1 : Programming Lang & its application
Day  2 : Basic concepts. Operators & more
Day  3 : String & variables
Day  4 : Exception & files
Day  5 : Function & modules
Day  6 : Control Structures
Day  7 : More Types
Day  8 : Functional programming
Day  9 : OOP concept
Day 10 : Revise DAY 1 to DAY 9

jupyter에서 출력을 하려고 실행을 했더니

'IOPub data rate exceeded' 라 하면서 뒤에 주저리주저리 뭐가 붙는 경우가 있습니다.

출력 데이터 rate 초과시 발생하는 오류인데 Juptyer의 환경설정에서 고칠 수 있습니다. 

'NotebookApp.iopub_data_rate_limit = 1000000' 으로 써져있는 곳을 바꾸면 되는데 복잡합니다.

환경설정 자체를 건드려 보겠습니다.

앞으로 모든 환경에서 초과 오류가 나오게 하고 싶지 않다면 이 방법으로 해결하면 됩니다.

cmd나 파워쉘을 켜서 다음을 입력합니다.

jupyter notebook --generate-config

그러면 경로가 하나 보입니다. 

저 경로로 찾아가 jupyter-notebook_config.py 파일을 메모장으로 엽니다.

그리고 NotebookApp.iopub_data_rate_limit 를 찾습니다. 저는 data_rate로 찾아서 아래와 같이 찾았습니다.

여기서 #을 지우고 뒤에 1000000을 1.0e10으로 고칩니다.

저장을 하고 메모장을 끕니다. 

https://seong6496.tistory.com/98

http://www.digitaltoday.co.kr/news/articleView.html?idxno=465649 

코드 리뷰 단점

• 긴 피드백 루프
• 대기 중
• 완료되지 않은 여러 작업
• 서면 의사 소통에는 시간이 많이 걸립니다.

"코드 작성 -> 검토를 위해 보내기"를 의미하는 전형적인 프로그래밍의 날입니다. 지금은? 어… 또 다른 작업. 작업은 쉬웠습니다. 세 번째 작업을 시작하겠습니다. 그리곤 리뷰의 필요성을 재촉하고, 잠시 기다렸다가 혼자 리뷰를...
마지막으로 두 번째 과제 리뷰! 아니요, 동의하지 않습니다. 제대로 대답해야합니다… 한 시간 후에 나는 논증 요약을 마치고 다음 날 동료가 OK라고 대답합니다. 뭐? 그냥 OK?!

코드 리뷰의 가장 중요한 문제는 상당히 어려운 질문/답변의 비동기식 핑퐁입니다. 이는 비효율적일 뿐만 아니라 사람들을 좌절하게 만듭니다.

또 다른 접근 방식은 가능한 한 빨리 코드 검토를 수행하는 것입니다. 이 접근 방식을 적용하면 결국 일주일 내내 코드 검토를 하게 됩니다. 그리고 그것은 과장이 아닙니다. 코드 리뷰를 많이 할수록 더 많은 요청을 받습니다. 이것은 다시 좌절로 이어집니다.

코드 리뷰의 목표

코드 리뷰의 이점은 무엇입니까?

• 지식 공유
• 책임 공유
• 코드 구조 개선
• 학습

좋은 코드 리뷰는 이러한 모든 측면을 다룹니다. 그러나 코드 검토는 도구일 뿐이며 더 나은 도구를 찾을 수 있다면 코드 검토를 버릴 수 있습니다.

마피아 프로그래밍

모브 프로그래밍 은 모든 팀원이 한 화면 앞에 동시에 존재한다는 것을 의미합니다. 또는 공유 화면에서 원격으로 작업할 수도 있습니다. 제 경우입니다.

저는 4명으로 구성된 팀에서 일하며 Mob 스타일로 하루에 5~6시간 정도 일합니다. 처음에 우리는 작업을 결정하고 가능한 경우 운전 세션에서 회전합니다.

세션이란 한 명의 드라이버(타이핑/클릭하는 드라이버)와 네비게이터(네비게이터)가 드라이버에게 무엇을 해야 하는지 알려준다는 의미입니다. 다른 팀원 2명은 계속 주의를 기울이다가 네비게이터가 잘못된 방향으로 갈 때만 끼어듭니다. 내비게이터는 3분 동안 탐색합니다. 실제로는 3분만 탐색한 다음 회전합니다.

회전은 운전자가 이제 탐색한다는 것을 의미합니다. 다음 단계를 알아야 하고, 내비게이터는 휴식을 취하고, 2마리의 몹 드라이브 중 하나가 필요합니다. 그리고 3분 후 또 다른 회전, 그리고 다시, …

이 회전 스타일은 강렬합니다. 항상 주의를 기울여야 합니다. 그렇지 않으면 몇 분 안에 탐색해야 하고 어떻게 탐색해야 할지 모를 것입니다.

몸매를 유지하기 위해 우리는 화장실/커피를 위한 규칙적인 휴식을 취하고 물론 점심을 위한 긴 휴식을 취합니다.

코드 보기의 목표가 달성됨

지식 공유 는 즉각적입니다. 모든 팀원은 정신적 과정을 따르고 수행한 이유를 알고 있습니다.

내 의견에 책임을 완전히 공유 합니다. 저는 언제든지 "동의하지 않습니다" 또는 "더 나은 아이디어가 있습니다"라고 말할 수 있으므로 우리가 생산하는 모든 것에 대해 책임을 집니다.

코드 구조 는 모든 팀원이 동의하므로 일관성이 있으며 최고의 팀원이 할 수 있습니다.

학습 은 다시 즉각적이고 강렬합니다. 네비게이터가 좋으면 무엇을 해야할지 뿐만 아니라 어떻게 하면 효율적으로 할 수 있는지도 불러줍니다. 나는 날마다 더 나은 소프트웨어 아키텍처, 더 나은 테스트 전략, IDE를 효율적으로 사용하는 방법을 배웁니다. 내비게이터가 내가 놓친 부분을 알고(및 공유) 하기 때문입니다.

대체로 Mob은 모든 측면에서 코드 검토보다 우수합니다. 그리고 코드 검토 탁구 좌절.

몹은 비효율적이어야 합니다.

처음 몇 주 동안 나는 Mob이 비효율적이라고 생각했습니다.

팀이 정착 중이거나 팀 구성원이 아직 언어와 도구에 대한 경험이 없을 때는 확실히 그렇습니다. 그 기간 동안 Mob은 학습에 대해 매우 중요합니다.

그러나 팀이 초기 몇 주를 지나면 매우 달라집니다.

거의 매일 나는 혼자 있을 때 해결하는 데 적어도 한 시간(또는 몇 시간)이 걸리는 문제를 경험합니다. 하지만 우리는 4명이 있고 보통 다른 사람이 몇 분 안에 문제를 해결하는 방법을 알고 있습니다. 내 동료들은 그들도 같은 경험을 하고 있다고 확인합니다. 그들은 무엇을 해야 할지 모르고 다른 누군가는 즉시 그것을 압니다.

모든 팀원은 또한 다른 분야에서 더 우수하거나 전문가입니다. 하나는 DB에 좋고, 하나는 우리가 사용하는 프레임워크에 있고, 하나는 예입니다. 의사결정을 잘함. 따라서 내비게이터가 막혔을 때 이 "전문가" 한 명이 장애물을 극복하는 데 도움을 줍니다. 그리고 그것은 즉시 발생합니다.

몹 요구 사항

모브 프로그래밍은 모두를 위한 것이 아닙니다.

처음에는 같은 시간에 함께 있을 수 없으면(원격은 괜찮음) 작동하지 않습니다.

폭도는 좋은 의사 소통 기술이 필요합니다. 수동적 공격성을 위한 공간이 없습니다. 또는 오만함. 당신이 당신의 동료보다 낫다는 것을 보여주고 싶다면 당신은 Mob의 후보가 아닙니다..

폭도는 인내와 존중이 필요합니다. 모든 사람이 항상 최상의 모습과 상태를 유지하는 것은 아닙니다. 당신이 해결책을 서두르는 것을 좋아하고 동료를 지도/가르치는 데 관심이 없다면 마피아는 작동하지 않을 것입니다. 당신의 동료는 나아지지 않을 것이고 팀은 나아지지 않을 것입니다.

그게 다야. 같은 시간(멀리 떨어져 있어도) 함께 있을 수 있고, 참을성이 있고, 새로운 접근 방식에 관심이 있고, 동료가 비슷한 관점을 가지고 있다면 그렇게 하세요. 몹이 길이다!

Mob 대 코드 검토

Mob과 코드 리뷰를 비교하면 웃을 수 밖에 없습니다.

코드 검토 스타일에서는 몇 시간 동안 문제를 해결하기 위해 고군분투한 다음 코드 검토에 솔루션을 보낸 다음 기다렸다가 검토자가 변경 사항을 제안하고 내 솔루션에 대해 논쟁하거나 코드를 변경합니다. 2-5일 후에 병합할 코드가 준비되지만 병합 충돌을 해결해야 합니다!

Mob 프로그래밍에는 그런 것이 없습니다.

• 투쟁은 팀원의 경험에 의해 제한됩니다.
• 대기 없음
• 즉각적인 인수/코드 변경
• 병합 충돌 감소

Mob은 훨씬 더 많은 이점을 가지고 있으며 저에게 가장 중요한 것은 나와 동료 간의 관계를 개선하는 것입니다. 프로그래머도 사회적인 생물이고 Mob은 많은 도움을 줍니다.

Mob 프로그래밍이 피드백 루프를 극적으로 단축하고 놀라운 결과를 가져온다는 점을 요약하고 싶습니다.

아이디어를 찾기 위한 세 가지 조언

마이크 세이블은 문제를 제대로 발견하기 위해 방법으로 이런 세 가지 조언을 했어요.

1. 무엇이 좋은 문제이고 나쁜 문제인지를 미리 알고 있어라.

대개 사업 아이디어는 자리에 앉아서 머리를 쥐어싸매고 고민하면 잘 떠오르지 않아요. 아까 말씀드린 SISP 가 나올 경우가 많죠. 진짜 좋은 아이디어는 경험을 하는 와중에 떠오르게 됩니다. 그러기 위해서는 무엇이 좋은 문제이고 나쁜 문제인지를 처음부터 알고 있는 것이 중요합니다.

1. 어떤 분야든 현업에서 일하면서 경험을 쌓아라.

개인적인 차원에서 문제를 찾아내는 것에서 시작하려면 당연히 여러 가지를 경험해봐야 문제를 마주할 가능성이 높아지겠죠? 이런 점에서 IT나 소프트웨어에서 일하는 사람보다 전통적인 산업계에서 일하는 사람이 '진짜 문제’를 발견할 가능성이 높아요. 그 문제는 다른 사람들은 발견하지 못했을 수도 있으니까요.

많은 예비창업자들이 스타트업에서 일하면서 경험을 쌓는 이유. 대기업에서 일하는 것보다 훨씬 많은 경험을 하고 더 많은 문제를 목격할 수 있기 때문이죠.

1. 무의식적인 필터링(검열)을 피하라.

창업자들은 무의식적으로 어떤 것은 되고 어떤 것은 안 된다는 자기 검열을 하게 된다고 해요. '이미 시장점유율이 높은 대기업이 있다'던지, '시장이 너무 작다'던지와 같은 것입니다. 하지만 이런 필터링이 좋은 아이디어를 걸러내 버릴 수도 있습니다. 

전 세계에서 가장 큰 커뮤니케이션 서비스 중 하나면서 커뮤니티로 성장한 디스코드는 게임을 만드는 회사가 게임에서 사용하는 음성 채팅 서비스를 개선하려다가 등장했어요. 당시 스카이프처럼 게임용 메신저 서비스가 이미 있었죠. 하지만 게이머들의 만족도는 낮았습니다. 여기를 공략하고 들어가자 디스코드는 순식간에 세계적인 메신저 서비스로 성장할 수 있었습니다.

문제를 발견하는 건 모두에게 중요하다

스타트업들이 창업 아이디어를 얻는 과정이 기존 대기업에서 신사업을 찾고자하는 분들에게도 참고할만한 부분이 있을 것 같아요.

첫째, 타이밍이 중요하다.

한 가지 문제에 진득하게 달라붙어 모든 것을 올인하는 데다가 성공할 경우 창업자에게 막대한 보상이 돌아가는 것. 그것이 스타트업이죠? 그 문제를 해결하는데 있어서는 스타트업보다 대기업의 소규모 부서가 불리한 것이 현실이에요.

그런 스타트업조차 타이밍이 성공의 중요한 비결이었어요. 새로운 기술과 트렌드가 나왔다면 대기업도 빠르게 시도해보고 어느 정도 발을 걸치고 있어야하는 이유입니다.

둘째, 현업에서 사업의 기회를 발견하라.

대기업이라면 어느 곳이나 이미 하고 있는 기존 사업이 있을 것 같아요. 그리고 거기서 해결해야하는 문제들을 발견할 수 있겠죠? 그런 문제가 무엇인지를 발견하는 것만으로도 신사업을 찾아내는데 도움이 되지 않을까요? 

하지만 그런 아이디어가 회사 경영진에게 전달되지 못하고 있다면,

1) 현업과 경영진간의 커뮤니케이션 문제가 있을 것 같아요. 이 문제는 내부 절차뿐만 아니라 기업문화 측면에서 많은 노력을 기울어야할 것 같아요. 

2) 우리 회사가 바로 그 문제 자체인 경우가 있겠죠. 우리 회사가 문제의 원인이라는 것은 아무도 모르면 좋겠지만.. 🙄 경쟁자나 스타트업들이 끊임없이 그 문제를 파고들려고 할 것 같아요. 그렇다면 우리가 주도적으로 해결해나가는 것이 좋겠죠? 

많은 대기업/중견기업들께서 오픈 이노베이션 사업을 스타트업들과 하고 계신데요. 이런 오픈 이노베이션 프로그램이 위의 두 가지 문제를 해결하는데 도움이 될 수 있을 것 같아요. 스타트업들은 문제에 해결책을 찾고자 하는 이들이고, 이들과 협업을 하다보면 현업의 문제가 효과적으로 경영진에게 전달될 수도 있을테니까요.