Zyst

Google to see who handles github.io, one figures all sorts of bad crap must be going on in their subdomains, even if they do try to police it.

This seems like an awfully important cause! Why are they sitting and hoping someone will do it selflessly? That is risky, I feel.

Why not instead have, say, the government or a charity pay someone with this profile 100k a year to go donate blood once a week?

Yes, hopefully someone would just do it, but it does feel like the upside is strong enough that investing some money would be worthwhile. Hell, I hate needles with a passion but I would sign up for donating weekly for the rest of my life for 100k a year, I am sure orhers would as well.

Maybe a patreon or a gofundme or something?

I just ran this on windows, what's the problem you had with it?

Poster here, I have nothing to do with the person who made this, but I saw it in the morning and I thought it was super cool.

My Japanese is mediocre so I might've read it wrong, but it seems the person who made this dropped out of school, here's their Github:

https://github.com/yuki540net

If someone's in Japan you should hire them.

Did you read the end of the article? I mean I get what you are talking about, but I think the author went out of his way to say that he doesn't think FP is going to be a silver bullet.

I didn't even know Go had a logo, so long as they aren't touching the Gopher I honestly don't care.

In fairness I think that would look a bit more like this:

    const getDate = (date) => {
      switch (date) {
        case 1:
          return 'mon'

        case 2:
          return 'tues'

        default:
          return 'wed'
      }
    }

    let date = getDate(1)

Which is, of course, still less terse. What I normally use when I have cases like this is an object-as-a-map. IE:

    const dates = {
      1: 'mon',
      2: 'tues'
    }

    let day = dates[3] || 'wed';

That's the up side.

On the flipside, if the person who has a 401k finishes it, and has no more money they will then have to depend on their descendants for their livelihood.

Which can make the living standards of the descendant lower, because now they are taking care of their parent for the rest of their life. Which only gets more expensive the further they go (IE: Illnesses)

This article is, from what I can tell, genuinely well informed.

Throughout the last few years I've read around 8 books on Buddhism, Meditation as a practice, and Zen Buddhism. And some of the differences that popped up were bizarre to me. Incredibly so in the Tibetan side of the literature. Even more so because I started with a very westernized view: The Zen Programmer.

It took me over a year of some non-focused research to get a general idea of what was going on, and I feel this article actually summarizes, and ties it together pretty well. It is fairly simplistic of course, but you can't go too in depth in a handful of pages.

I do feel they explained the situation more eloquently than I would have.

Not at all, I'd argue this whole Tabs/Spaces, bracket placement, single/double quote discussion should be getting killed by code formatters.

At the end of the day you can do whatever you want with the code you're writing, and some pre-commit hook can run go fmt/prettier/whatever and then it'll all get standardized.

I've become a very heavy proponent of code formatters (I added prettier to the entire team) and I truly believe that talk about code formatting will never really die off, but at the end of the day you can do whatever you want on your side but still have a standardized looking codebase, and that feels extremely liberating to me.

As a PS: If you are a diehard tab proponent/different bracket placement/whatever but your team formatter configuration uses spaces instead then you can also use code formatters to do spaces -> tabs locally, say, on file open. Once you commit your file your precommit falls back to the team configuration, which removes your tabs. Everyone is happy.

As a side note: The TDD-ish alternative to this, which I also use sometimes is just adding a test where you pass in undefined on your optionals, and then iterating until the test stops throwing.

For the most part I feel that for 99% of problems types just “get in my way”.

It feels like I already know what is going to go in where, and having to type it is just a waste of time.

That said, when I have to work with APIs that can not guarantee their data integrity throwing in a quick @flow annotation of top of the file, and taking the time to write out what is optional has proven very valuable to make sure my functions, and subsequent code is not going to throw.

Another reason I like flow more is because I don’t need to convonce my team to use it, I can just use it myself, and then delete it after I am done writing my code.

I think its more likely that once Waymo has a complete plan they will switch to partnering with existing brands, many of which might not have gotten their own self driving efforts to a point where they can compete.

At least I have not seen any signs of Waymo aiming for car mass production.

I’ll be 100% honest even though it might not be applicable for you:

One of the most valuable things I look for is someone who has already worked remotely.

From my personal point of view not everyone is suited to doing remote work.

* Some people cannot work up the motivation to get stuff done when the bar for others realizing they are slacking off is a lot higher.

* Some people realize they miss the meatspace interaction and decide to quit after three months which you mostly spent ramping them up, so not quite their full potential.

* And some others realize they cannot really focus at home for a plethora of reasons.

Anyway, hiring someone with no remote experience always feels like a risk. Perhaps you could find a way to assuage those concerns, and improve your chances that way.

Can someone illuminate me as to what are some of the reasons that would make someone style with CSS Grid with a Fallback to Bootstrap?

Considering you are already writing Bootstrap due to compatibility concerns why not just keep using that? I feel like adding another dependency like this would just create a risk of having design differences pop up over time.

Mind you, I don't hate CSS Grid. I really enjoyed learning it, and I look forward to be able to use it in a few years.

I'd recommend reading the code[0], it's pretty short, and can help as a good introduction if you want to get a bit more into VanillaJS.

0: https://github.com/roecrew/zam/blob/master/zam.js

From someone who doesn't use Rails day-to-day: It's still about as relevant as it used to be before, for the same reasons it was relevant then.

In summary: If you need to get shit done fast, it's a good bet.

It isn't as hyped as it used to be 5 or so years ago, and if hype cycles are relevant to you, you likely already know your answer.

As to whether you are asking whether learning it would make you unemployable, by no means. RoR is still going strong, at least in my country.

LSP seriously gives me hope for the future. It is an awesome project, and I'm looking forward to seeing more widespread editor support for it.

It's still fairly new so most solutions I've seen that use it still have some sharp edges.

I basically exclusively do gods tangentially related to the thing I'm making.

Some document virtualization thing became Enki, some anti procrastination became Aergia, and so on and so forth. I actually quite like that.

I've heard the most common 2000 words in languages tend to make up the bulk of written, and spoken communication. Don't quote me on it though, since I don't have any real sources on this.

It reminds me of an editor that was submitted once in Show HN, that only lets you type the most common 1000 words[1].

[1] https://github.com/mortenjust/cleartext-mac

I've always had sub second startup times. With text rendered within the first 1.5-2 at most. Time to "Actual interactivity" usually takes around 3-5 seconds, but that's mostly due to my plugins. I could start typing per-se, just not in Vim mode.

I mostly leave the editor permanently open on the project I'm working on, so I guess I don't really notice it much either way. And using the integrated terminal to change one dir back and switch to another project, then opening it with code . is a pretty good flow so I don't feel stifled in that sense either.

Writing this from my phone so I cannot be as verbose as I want to be.

I can not speak for every case, so I will talk about why I sometimes use it in React:

First off, there is a synergistic effect where React handles data coming from above in the hierarchy, which Redux facilitates.

Secondly, it can be very hard to keep track of what components are handling what logic in large applications so having it abstracted away in an easy to test way is considered a win for many.

That is the good overview I feel, there's also that popular Dan Abramov medium post[0] that deals with it. I do believe redux is overused, and people would benefit from weighing whether simple react is good enough for a project, buy I understand the risk you feel you take on if the scope runs away and suddenly you need to do a costly migration to redux later on in the project where it can be a lot harder to do so.

[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

It's important to not disregard the expertise of a fellow developer before you have decisive proof that their approach is genuinely poorly thought out. That is to say: Give people the benefit of the doubt.

As an outsider the big amount of dependencies look daunting, but the tendency in JavaScript as of late has been to use small libraries that do one thing, do it well, and play well together with others (Composable is the buzzword). Whereas Java and C# for instance tend to have macro libs that "Have it all bundled in".

It's different approaches, and you might not _need_ absolutely everything, then again you might, and you are in a much worse position to evaluate that as an outsider than the developer who made it.

All in all, I quite like the JavaScript approach where pieces are just that, instead of a pre-built lego set which I'll have to study to build, I have small pieces which give me more flexibility to take my project where I want to take it. The tradeoff, and they naturally exist, is that dependency maintenance is substantially more difficult, and the likelihood of something you use being straight up abandoned raises for each dependency you add. Which might lead to having you either maintain that piece yourself, or abandon it, and add another piece that fulfills a similar role.

Good post. For me what helped most is definitely to get into the habit of reading more code.

It is not something I did all the time previously. But coming in with a goal and then just reading code tends to help a lot, whereas I normally lean more on my coworkers when getting familiar with a new codebase (where do we do X?) simply getting into the habit of reading more code helped.

I think an important realization is that there is (hardly ever) a deadline. You can take your time to get as comfortable as you wish with the code before you start.

As a PS: I have seen this blog a few times, I gotta say I love the orange bars around the post.

I actually go the completely opposite way, and I'm the happiest person I know.

I own everything, everything that happens to me, everything that goes wrong around me, I take my share of responsibility in it. Analyze what I can do to improve it, and do it.

When I think like what you mentioned I tend to lose control of my emotions, I feel angrier, I feel sadder. When I own what happens to me, I feel peace. I know almost everything can be improved. Maybe not short term, but eventually.

Coming back to the other side, I think the core of it is that thinking that stuff is happening to me makes me feel like a victim. I don't take responsibility for anything, thus it must be the fault of some external factor. I try to rationalize and assign blame. All in all, it's a much more negative experience for me.

How about an artificially anonymized process. HR does know, or assumes, your gender from receiving your CV. But from that point onward your identity is anonymous.

For instance, HR creates a throw away email which will be used during the hiring process to coordinate the rest of the tasks. The coding interviews could use one of the many platforms we have for shared/same space coding with an added chat box for talking your way through the problem so to say.

And so hiring decisions are done by interviewers without knowing the gender or how the candidate looks.

I think this would allow for a good level of blind testing, but would provide some downsides in the side of cultural fit screening. It's a lot easier to pretend you're not an asshole in asynchronous text-only communications.

I guess everything carries a trade off.

Agreed. If it were a list I'd gladly tick it over. But I am hesitant to add a new extension.

Oh I misread the "Direct access to game API section", I thought they meant making it so that the machine can only see "what's on their screen", so if someone were to cast a long range skill for instance they wouldn't get that information. Which is a distinct advantage for machines.

That is indeed, by no means trivial. I do think it's pointless though, that's just another exercise for the sake of making it another exercise.

Raw screen is not as big of a deal as it would seem, in DotA and Starcraft you can glimpse most of the information you can see on a screen through the minimap.

You made a claim you didn't have the facts right on.

If someone without the relevant information reads it your comment could thus spread misinformation.

And so people downvote. The other replies that got downvoted after that I don't know about though.