vi ~/.gitconfig [user] name = user1 email = user1@gmail.com [credential] # wsl 환경인 경우 helper = /mnt/c/Program\\ Files/Git/mingw64/libexec/git-core/git-credential-wincred.exe username = user1 [includeIf "gitdir:user2"] path = ./user2.gitconfig # user2.gitconfig [user] name = user2 email = user2@gmail.com [credential] username = user2 지금까지 저장소마다 usehttppath로 삽질한 게 무의미해졌다. 커밋 저자 이름을 바꾸는 건 어쩔 수 없이 경..
Introducing Hooks(번역문)란 글이 있었고 반박으로 The Ugly Side of React Hooks(번역: React Hook의 어두운면)란 글이 나왔으며 그 번역문을 보고 작성했습니다. 훅에 관한 건 요새 뜨거운 감자로 보입니다. 이걸 도입하는 게 타당한 트레이드인지 따지기 어렵다는 방증으로 보입니다. 훅에 맘에 안 드는 점이 있긴 한데 까더라도 제가 까고 싶어서 올려봅니다. 글쓴이가 훅을 잘 서술했다고 생각하지 못했거든요. 언젠가 봤다가 언어장벽으로 반 정도 읽다가 말았는데 역자분의 고생을 생각해봅니다. 이유 1: 클래스는 헷갈린다 hook 함수는 클래스가 아니며, 함수와 클래스의 그 중간 어딘가에 있는 것이다 타당한 지적입니다. 훅은 그 자체로 필요한 제반 지식이 상당하고 언어 차원..
빠른 요약 주의사항. 실제 익숙한 곡으로 플레이하면서 조절하기. 싱크 화면 자체는 정확하지 않아 보인다. 1. 싱크 설정 두번째 화면에서 조절 후 음악없이 플레이 +값은 판정선이 아래로 내려가는 효과, -값은 올라가는 효과가 있다. 보통 +값으로 설정한다. 음악없이 화면에서 노트가 떨어지는 것만 보고 터치했을 때 판정선이 위로 올라간 느낌이면(미리 쳐야하는 것 같으면) +값으로 조절해주면 된다. 2. 싱크 설정 첫번째 화면에서 조절 후 음악을 들으며 플레이 여기는 화면을 가능한 무시하고 음악에 맞춰 터치했을 때 곡이 좀 밀려있다면(늦게 쳐야 맞는데 일찍쳐야 득점하는 것 같다면) +값으로 조절해주면 된다. 3. 재조절 보통 첫번째 화면(오디오)에서 정확한 값을 찾았다면 두번째 화면 값은 한 단계씩 +하다보..
원문: https://a16z.com/2020/01/13/game-design-not-gamification/ 잊지 않기 위해 요약할 가치가 있는 글이라고 느꼈다. 게임 디자인 ≠ 게임화 보상을 얘기하지 않았을 때 아이들이 그림을 그리는 데 투자한 시간이 더 길었다고 한다. 연구자들은 내재적/외재적 동기의 차이라고 설명했는데 그렇다면 게임화의 보상을 설정하는 부분은 핵심 요소가 아니라는 얘기가 된다. 목표, 감정, 컨트롤, 장난감, 몰입 그렇다면 게임을 어떻게 디자인하면 된다는 건가라는 질문에 대한 대답이다. 원칙 1. 구체적, 실현 가능, 보람있는 목표 잡기 일감 목표의 대부분은 분명하지 않거나, 분명하더라도 보상이 없거나 실현 불가능하다고 한다. 그러면 분명하고 실현 가능하게 만들고 보상을 주면 된다..
sudo pacman -Sy bluez bluez-utils # 안 그렇겠지만 만약 블루투스 커널모듈이 활성화되어있지 않다면 # sudo insmod btusb # 이 시점에서 plasma 에러 문구는 'no bluetooth adapters found' sudo systemctl enable bluetooth.service sudo systemctl start bluetooth.service # 블루투스 장치가 페어링까지 되지만 연결에 실패함. # Failed to connect: org.bluez.Error.Failed sudo pacman -S pulseaudio-bluetooth pulseaudio -k pulseaudio --start # clementine이든 vlc든 설치해 실행
원문, 번역문 목mock이 안 좋다는 인식은 알고 있었어도 그게 단순히 목 라이브러리를 쓰지 말라는 이야기는 아닐 거란 생각에 제대로 알아보는 차원에서 검색해보았다. 그리고 나도 테스트를 제대로 활용하고 있는지 의구심도 들었기에. TDD로 더 나은 디자인을 이끌어내야 한다 DI는 목을 가져온다. 하지만 DI 없이도 분리된 코드를 짤 수 있다. 코드 커버리지를 무작정 늘리는 것은 프로그램 코드를 복잡하게 만들어 더 많은 버그를 도사리게 한다. 이 소제목 이전의 내용이 목이 필요하다는 건 추상화 표면, 즉 코드를 사용하기 위해 알아야하는 지식이 너무 많은 걸 의미해서 좋은 설계가 아닐 수 있다는 듯. 때문에 독립적인 유닛 테스트에 목킹이 필요하다는 건 사실 그 유닛이 독립적이지 않다는 걸 의미할 수 있다고...
- Total
- Today
- Yesterday
- Qt5
- WSL
- SHAREX
- error highlighting
- software compraison
- MSVC2013
- React
- Deemo
- Notion
- Code Snippet
- MSVC 2017 RC
- Kotlin
- coroutine
- V3 Lite
- gram
- Authentication
- intellisense
- C++11
- Rust
- game design
- CLion
- novel review
- C/C++
- MSVC
- hooks
- JWT
- getch()
- Haskell
- Windows Defender
- IntelliJ
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |