인코딩은 어떤 데이터를 원하는 포맷으로 변경시키는 것을 말한다. 만약 string을 base64로 변경시켜야 하는 경우 string을 b64로 인코딩한다고 한다. 반대 방향의 변환은 디코딩이라고 부른다. 정확히는 방향이 반대일 때 디코딩은 아니고, 주체가 어떤 것이냐에 따라 다르다고 할 수 있다. 예를 들어 b64를 디코딩하여 문자열을 만들 수 있고, 또 b64를 문자열로 인코딩할 수도 있을 것이다. 두 연산의 결과는 같겠지만. 아무튼 go에서는 encoding/hex패키지에서는 다음과 같은 함수를 제공한다. func Encode(dst, src []byte) int // Hello Gopher! -> 48656c6c6f20476f7068657221 func Decode(dst, src []byte) int, error // 48656c6c6f20476f7068657221 -> Hello Gopher! Encode를 사용하여 문자열을 hex string으로 변경한다. 반대로 Decode를 사용하여 hex string을 다시 문자열로 변경한다. Read more

위키에 쓸까 며칠 고민했는데, 이 정도는 간단하게 블로그에 적어도 되지 않을까 싶어서 여기에 쓴다. 얼마 전 회사에서 어떤 분이 질문하기를, Go에서 fmt.Println()으로 time.Now()를 찍으면 나오는 m=+0.xxxxx와 같은 수치가 뭐냐고 물어 보았다. 그냥 프로그램 실행 이후 경과된 시간을 알려주는 것이라고 간단하게 대답했는데, 대답을 들었던 분이 이게 왜 필요한지를 정확히 이해하지 못한 것 같았다. 그렇지, 일반적으로는 실행했을 때 시간을 알면 현재 시간에서 빼기만 해도 바로 경과 시간을 알 수 있으니까 말이다. package main import ( "fmt" "time" ) func main() { now := time.Now() fmt.Println("now?: ", now) time.Sleep(time.Millisecond * 454) fmt.Println("after?: ", time.Now()) } 위 코드의 출력은 아래와 같다. m 필드를 보면 454 밀리세컨드를 sleep했더니 m도 454만큼 증가되었다. Read more

최근 새롭게 라즈베리 파이를 사용하여 만든 시스템이 너무 마음에 든다. 기존과 대비해서 장점이 너무 많은 것이다. 하나를 꼽아 보자면 성능이 확연히 차이가 날 정도로 더 좋다는 것인데, 기존에 사용했던 ODROID-U3는 출시일이 대략 20132014년 사이니까 벌써 10년전 제품이다. 라즈베리 파이 4로 말하자면 출시된 지 길어야 12년이니 아무래도 성능이 차이가 날 수밖에 없는 것. 기존 시스템에서 힘들었던 것으로 어플리케이션의 속도가 느리다는 것이었다. 개인 코드 저장소로 사용하는 gogs가 너무 느리고, 특히 커밋이 많은 코드일수록 더 느려진다. 링크 클릭 한 번에 3초 가량을 기다려야 했으므로 gogs의 좋은 기능을 더 쓰고 싶어도 그럴 수가 없었다. 그러나 이제는 이슈 트래커 기능까지 빠르게 사용할 수 있다. gogs로도 체감 성능이 굉장히 많이 빨라졌으므로 내친 김에 코드 기여와 개선 속도가 gogs대비 매우 빠른 gitea로 마이그레이션까지 진행했는데, 절차가 굉장히 복잡하고 직접 DB 필드를 수정하거나 업데이트한 것도 있어서 쉽지 않았지만 다 옮기고 나니 생각보다 더 만족스럽다. Read more

어떤 일들은 반드시 일을 시작하기 전, 처음에 해야만 한다. 그런 일들은 만 명중 만 모두 동의하는 것이기도 하고, 또 모두가 동의하지 않아 우선순위에서 밀리는 것들이 있기 마련이다. 어느새 일을 시작한 날이 오래되어 많은 사람들과 일하면서 느낀 것이 있는데, 사람들이 생각하기에 중요한 일은 다 중요한 일이 아니고 대강 이렇게 두 가지가 있다고 믿는 것 같다. 중요하고 필수적인 것, 그리고 중요하지만 필수적이지는 않은 것. 그렇기 때문에 전자의 경우 처음에 진행하는 것에 아무런 이견을 달지 않지만, 다른 일은 반대하는 사람들이 생긴다. 여기서 포인트는 전자나 후자 모두 그것이 중요하다는 것에는 한결같이 동의한다는 것이다. 다만 각각이 생각하는 우선 순위가 다른 것. 회사일로 따지면 보통 중요한 것 중, 그중에서도 중요하다고 여기는 것들은 결과물을 낼 수 있는 프로그래밍 코드나 컴파일된 바이너리가 조금 더 그런 경향이 있는 것 같고, 그 이외의 것들, 예를 들어 배포 시스템이 중요하지만 우선순위가 낮다고 생각하는 것 같다. Read more

위키를 업데이트했다. 기존에는 Dokuwiki 기반의 사이트였는데, 이번에 블로그와 같이 hugo를 사용하기로 했다. 도쿠위키, 생각해보면 도쿠위키가 진짜 애매한 것이 아닌가 싶다. 파일 기반으로 위키를 관리하면서 정적 페이지도 아니고, 그렇다고 뭔가 현란한 기능이 있는 것도 아니고. 처음에 위키를 만들 때 어떤 솔루션으로 할지 신중하게 고민했던 기억이 있다. 그러면서 어떤 것이 장점이 되고 단점이 될지 여러 위키 엔진을 비교하며 결정을 했는데, 그 때 도쿠위키를 선택한 이유는 크게 이런 이유들이었다. 파일 기반이라 데이터베이스가 필요없다 php기반이므로 잡다한 권한 관리가 될 것이다 … 블로그를 hugo로 변경하니, 위키도 정적 페이지로 만들어볼만 하겠다는 생각이 들었다. 파일 기반으로 위키를 만들 것이면서 굳이 php를 사용할 필요가 있나 싶은 것이다. 데이터베이스에 접근하는 것도 아니고, 그렇다고 뭔가 리치 텍스트나 복잡한 내용을 쓰는 것도 아니고. 거기다 플러그인을 통해 작성도 마크다운으로 했으니까, 생각해 보면 굳이 사용할 필요가 없었던 것. 또 복잡한 권한 관리가 가능하지 않을까 싶었는데, 애초에 나에게는 권한 관리가 필요 없었던 것이다.혼자 작성하는데. Read more