freeCodeCamp's Medium publication collects programming tutorials and essays on JavaScript, React, Node.js, Go, and software practice from many contributors.
HN commenters link it for specific posts, such as a TypeScript currying guide, a CSS breakpoints piece they call restoring common sense, and a debated 'REST Is the New Soap'.
> Free users don't care if you tell them to fuck off.
You don't have to and shouldn't respond in any specific time period. Even if you're the sole maintainer of a critical project and you imagine the world wants your head, the world has to wait sometimes.
However, users may abandon projects where support tickets go untended, maybe even writing a post about it in the process[1], so try to respond when you can, unless you've abandoned the project.
As a representative for a FOSS project or even a bystander commenting on a PR, respond professionally and succinctly.
If you shouldn't accept a PR, don't.
If it's a request that seems hostile to the project, and you have time, either leave it for a little while to cool off, try to serve it with professionalism without getting off-topic, or at worst close it.
If needed, add a "code of conduct"[2] so that you can "encourage a pleasant and productive environment by responding to disruptive behavior in a fast, fair way"[3]. Note that instituting one before it's needed, while seeming proactive, may put off some users.
If you screw-up, apologize briefly, then fix it or move on.
[1]- https://medium.com/free-code-camp/why-im-not-using-your-github-repository-2dff6c7ac7cf
[2]- https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/adding-a-code-of-conduct-to-your-project
[3]- https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/about-community-management-and-moderation
Stats from the experts show that even great engineers fail technical interviews [1]. Anecdotally: I've bombed interviews myself! Sometimes due to anxiety (a real problem for some of us), sometimes because the problem was difficult. So false negatives are very common. Especially if you are interviewing 200 people - you are wasting SO MUCH TIME. I simply can't believe that you're actually getting that 1 in 200 dev. Why?
Because devs also pass interviews they have no business passing. You get a technical question that you already know the answer to and so you get through it easily (this has happened to me as well). I'd consider this a false positive. And today, I suspect this is just as likely as a false negative - we have many books on coding interview prep, probably hundreds of sites with coding problems to practice. Are you getting a good dev or are you getting someone that practiced 20 questions on the same subject last week so they happen to know exactly how to solve your interview problem?
And the worst types of false positives are not ineptitude, in my opinion. I can make a mediocre dev (or a dev who is bad at algorithms) into an excellent dev. But there are a lot of devs who are very smart, but very lazy or toxic. And those people will sometimes impress you the most in interviews... because they have to do it a lot because they don't last.
If anything, if the industry insists on technical coding challenges, we should stop the random bullshit and commit to a…
Original article from Apr 26, 2018, and it's here with comments:
https://medium.com/free-code-camp/i-built-a-pwa-and-published-it-in-3-app-stores-heres-what-i-learned-7cb3f56daf9b
What has changed since, is that https://www.pwabuilder.com also has template for iOS App Store app, etc. But I have not tried that iOS template yet, publishing to iOS requires so many more steps.
I'm maintainer of WeKan Open Source kanban https://wekan.github.io , source code for all platforms at https://github.com/wekan/wekan .
I created PWA apps for Play Store, Windows Desktop MS Store, and Ubuntu Touch OpenStore. In my experience, publishing to Play Store and MS Store required payment. Publishing to OpenStore was free.
Links to PWA apps here:
https://github.com/wekan/wekan/wiki/Browser-compatibility-matrix
Easiest was to OpenStore. No payment required. Source code here:
https://github.com/wekan/wekan-openstore
In that Open Store app, no need to compile anything. It's just plain text, HTML, etc. URL to website is here:
https://github.com/wekan/wekan-openstore/blob/master/wekan.desktop#L3
If PWA app is not in some store, or WeKan (or other) app is self-hosted, it's possible to create app icon this way:
https://github.com/wekan/wekan/wiki/PWA
Additionally, PWA app requires web.manifest textfile, different icon sizes for different app stores, those files are at root of PWA website like https://app.example.com/web.manifest , like these files…
I like the "do" notation in Haskell because it boils down the meaning of monads to the following:
Monads let you break the functional programming paradigm that a function should have the same value each time it is called. e.g.
do {
x <- getInput
y <- getInput
return x+y }
here getInput is called two times and each time it has a different value. When you now think about how this can happen in a functional language you have to understand what a monad does.
The heureka moment came when I learned about the flatMap in scala which is nothing else but the bind function in haskell ("just flatmap that sXXt") and voila thats how to use monads.
See the following explanation:
https://medium.com/free-code-camp/demystifying-the-monad-in-scala-cc716bb6f534
Maybe my choice of the word "comfortable" was incorrect (although I would say "grok" was a spot on word choice in this context). It took me a good while to get the point where no matter what I encounter in TS, I feel pretty confident I can arrive at understanding it. The type system is very powerful and there are some deep rabbit holes you can find yourself in.
For example, if you can follow this blog post after only two weeks then you are much smarter than me: https://medium.com/free-code-camp/typescript-curry-ramda-types-f747e99744ab. This is a pretty extreme example, but sometimes you hit crazy types or crazy type errors like this.
But I would agree it doesn't take all that long to feel comfortable enough with TS to be productive with it.
Discussed at the time: https://news.ycombinator.com/item?id=15937448
His follow-up article https://medium.com/free-code-camp/follow-up-to-rest-is-the-new-soap-the-origins-of-rest-21c59d243438 is not quite as bombastic and somewhat more mature, although IMHO it has errors too.
My own complain about REST is not about REST itself (because I think it’s great) but about the fact that it has come to mean ‘anything with HTTP and JSON.’ As the follow-up article notes, a really RESTful interface is going to define its own MIME types. Now, they might be JSON (or something cleaner, like S-expressions …), but they needn’t be. REST is about data and operations on data and data about operations — it’s not about JSON.