함수형 프로그래밍에 중점을 둔 스칼라 책들은 훌륭한게 많지만 초심자부터 전문가까지 단계별로 가이드할 수 있는 커리큘럼을 추천하려고한다.
| // One of my new favorite React Hook patternms is to create handler | |
| // functions for a custom hook using `React.useMemo` instead of | |
| // `React.useCallback`, like so: | |
| function useBool(initialState = false) { | |
| const [state, setState] = React.useState(initialState) | |
| // Instead of individual React.useCallbacks gathered into an object | |
| // Let's memoize the whole object. Then, we can destructure the | |
| // methods we need in our consuming component. |
가끔 kubernetes 같은건 너무 무거워서 단일 호스트에 docker만 띄워서 운영하는 경우같은걸 고민 하게 됩니다. 하지만 그냥 docker만 가지고 사용하면 컨테이너가 죽었을때 관리해 줘야 하는 불편함과 같이 기능을 보다 더 필요로 하게 됩니다. 그래서 이 방법을 소개해 드립니다.
이건 standalone kubelet 이라고 불리는 master 없이 node만 관리해주는 kubelet을 이용해서 container를 관리하는 방법입니다. 이건 k8s 초기 부터 원래 존재했던 컨셉이나 많이 알려져 있지 않아서 모르시는 분들이 많아서 이글을 작성해 봤습니다.
이 방법을 이용하면 실제 master 없이 kubelet 만으로 서비스를 할 수 있습니다. 컨테이너 자동 재시작, port forwarding, resource limit 등 기본적인 kubelet에서 제공하는 다양한 방법으로 컨테이너들을 관리 할 수 있습니다.
A slightly modified version of standard ReScript's Js.Promise module.
Key differences are:
Promise.result and Promise.wait (which is what I want most of the time in apps)Soundness is on the same level as in the original bindings.
If you want more safety, consider reason-promise.
| // when T is any|unknown, Y is returned, otherwise N | |
| type IsAnyUnknown<T, Y, N> = unknown extends T ? Y : N; | |
| // when T is never, Y is returned, otherwise N | |
| type IsNever<T, Y = true, N = false> = [T] extends [never] ? Y : N; | |
| // when T is a tuple, Y is returned, otherwise N | |
| // valid tuples = [string], [string, boolean], | |
| // invalid tuples = [], string[], (string | number)[] |
Note: Since writing this, I've been pointed to some exciting new research/tooling called Project Cambria https://www.inkandswitch.com/cambria.html I'll likely have to rewrite this article taking that into account. Leaving this up for posterity's sake.
(This series isn't meant to be a primer/tutorial, though we might do something regarding it in the future. For official documentation and starters, see https://developers.cloudflare.com/workers/learning/using-durable-objects.
Further - these are my personal views; I expect to be wrong about a lot of them. Indeed, I'm not paying much attention to presenting these well at the moment, simply writing down thoughts. As such, expect these writeups to change often, particularly as the platform takes shape. I'm also mostly a front end guy, so don't get mad if I get it very wrong. Give me feedback! Always happy to learn and make changes.)
Durable Objects are a fascinating new storage primitive from cloudflare for their workers platform. There's a lot of 'cool'
At the beginning of 2030, I found this essay in my archives. From what I know today, I think it was very insightful at the moment of writing. And I feel it should be published because it can teach us, Rust developers, how to prevent that sad story from happening again.
What killed Haskell, could kill Rust, too
What killed Haskell, could kill Rust, too. Why would I even mention Haskell in this context? Well, Haskell and Rust are deeply related. Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time). Much of the style of Rust is similar in many ways to the style of Haskell. In some sense Rust is a reincarnation of Haskell, with a little bit of C-ish like syntax, a very small amount.
Is Haskell dead?
I write a lot, a lot of personal journals in a plain text. They contain a lot of dates and times, many of them should be ideally tracked automatically (like, if I've written "15:00 tomorrow" some software ought to alarm at that time), so they should be written in a consistent manner. So far I've used ISO 8601 date and time format (e.g. 2020-09-05 or 11:30) and a bunch of natural extensions (e.g. tomorrow, last Sun).
And folks, it's verbose or often ambiguous to other plain text! For example I tend to schedule things in a multiple of hours so :00 is not necessary, but a single number 15 would be less recognizable as hours. Many systems will helpfully try to recognize at 15 or 3pm, but how would you know that at 15 is not a part of at 15 km/h or similar? Also my journals are in Korean anyway, and such workarounds tend to not work well crosslingually. How about the intervals like 15:00 thru 18:30? ISO 8601 interval 15:00/18:30 would be particularly problematic because a
| package main | |
| import ( | |
| "context" | |
| "crypto/tls" | |
| "encoding/binary" | |
| "errors" | |
| "io" | |
| "log" | |
| "net/url" |
This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.
I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.
But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.
If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.