iterati

As someone who worked as a software engineer in NYC for 6 years ~5 years ago, I couldn't disagree more strongly with your claim that the tech scene in NY is weak. It's second only to Silicon Valley when it comes to tech jobs.

I don't think it's reasonable to think that most people working at HQ2 would have been doing a reverse commute from Manhattan into LIC. It's equally likely that they would just be crowding the already crowded trains heading through LIC to Manhattan.

> The subway for people commuting into LIC for work is probably currently fairly empty, so the subway could accommodate them. (The same cannot be said of the reverse. Commuting from Astoria, Queens or Williamsburg, Brooklyn into Manhattan for work during rush hour is horrible).

I lived in Greenpoint and Sunnyside for 3 years ~5 years ago and either took a train from LIC into the city or through LIC. They were always busy. Just because no one is going to LIC for work doesn't mean that they don't have to use the same trains that would be used to go to LIC. The 7 is a crowded line as are the orange and blue lines that go through. The only line that wouldn't be incredibly crowded is the G, and even that isn't fairly empty going to Court as it's a popular way to get to midtown if you live near the G.

as-> is great for when you have to mix thread-first and thread-last.

cond-> is great for building maps where some keys might not be needed:

    (cond-> {:k1 v1}
      v2 (assoc :k2 v2)
      ...)

some-> and some->> I don't use as often, but when mixing in some java code that could throw an NPE, these will avoid that and just return nil early (they short-circuit when getting a nil value).

User isn't the same as customer, though. Evernote needs customers. They only have users.

This is actually why I love working in Clojure. There are a number of threading macros to make this pipeline stuff work in different scenarios (put the return value in as the first, last, or variable argument; stop and return nil if you ever get a nil to prevent NPEs from happening downstream; only do this step is a condition is met). A simple example:

    (-> id
        get-account-details ;; {:plan "premium"}
        :plan               ;; "premium"
        get-plan-details    ;; {:price "$100.00"}
        :price)             ;; "$100.00"

It's equivalent to something like this in Python:

    account = get_account_details(id)          # {"plan": "premium"}
    plan_name = account.get("plan")            # "premium"
    plan_details = get_plan_details(plan_name) # {"price": "$100.00"}
    return plan_details.get("price")           # "$100.0"

I played clash for 18 months. You even say yourself that it's p2w:

> (3) the 1v1 ladder is not a pure skill matchup but still finds everyone a range where they have essentially a 50% win rate based on a combination of progress and skill.

> (4) yes the top of the ladder players have almost all spent a lot of money but most of the playerbase of any game isn't serious about being on the very top of the leaderboard. A smaller factor is that the most talented f2p players are sponsored with max decks and stop grinding f2p challenges.

That's p2w. If you can't get to the top of the ladder without spending money, it's p2w. That's what p2w means. Just because there are modes that are not p2w doesn't mean it's not p2w. The drop rate of legenadaries is so low it took me ~5 months to get a bandit from a free chest. Rewards are also increased the higher your ladder ranking makes the p2w aspect even worse.

After 18 months I had 1 level 3 legendary with a smattering of level 1s and 2s. It would take me a few more YEARS to get one to max (level 5), and they were releasing more legendaries and epics than commons and rares further decreasing the odds of being able to level up cards that you use.

Also, it wasn't uncommon for newly released cards to be more powerful on ladder than their counterparts (executioner and night witch are big examples), encouraging people to level them up for money, before nerfing said cards when they became more common or other cards were being released.

They'd be fired.

I guess we will, but with the slow pace that any of this was (not) done over the last number of years, I'm not holding my breath.

> They lost me once for terrible, terrible performance. For a year or two until I really needed tree style tabs back. They need to prioritize. Deal with it.

I am dealing with it. I moved to a different browser.

> Also, since you're a power user, why don't you use that proposed API already? It seems you don't even need to compile the browser or anything, just enabling a flag and installing the API as an addon.

Simply not true.

> I've developed a couple of Firefox extensions. One of those was an e10s-compatible replacement for Vimperator, because Vimperator relied on XUL[0].

Replacement for Vimperator implies it's, well, a replacement for Vimperator.

> Did you not read the rest of the comment, where I explain why there is no feasible way that they could have offered any path to rebuild them?

I don't see how your addressed that. Yes, existing extensions that used XUL would have to be rewritten using new APIs. My issue is that those APIs don't even exist. That there are good reasons the old APIs aren't available anymore doesn't address the lack of new APIs that offer anything near equivalent functionality.

electrovim is in no way a replacement for Vimperator. It's a couple of keyboard shortcuts. None of the current vim-like plugins for FF57 match what vimperator/pentadactyl can do. The problem I have isn't that they broke legacy things, it's that they broke legacy things without offering a path to rebuild them.

In the mean time, they've lost one of those power users (likely more, going by some of the discussion in issues for various vim-like plugins) and will, in the future, need to do something to entice me back. This experience has left a bad taste in my mouth and I'm not going to be rushing to go back to a browser that breaks functionality on me without prompt.

Simply false. You don't appear to know what you're talking about, so maybe you should stop pretending.

https://bugzilla.mozilla.org/show_bug.cgi?id=1215061

Doesn't matter how technical it is, it's still pretty worthless.

The right thing to do would have been to work on those extensions BEFORE breaking users' experience.

You don't break something and then prioritize fixing it. That's backwards. If they knew it was going to break the proper thing to do it prioritize the fixes before it effects end users, not after. If I were to push up a breaking change this morning and just wait for bug reports, I'd be looking for a new job by this afternoon.

It's not too soon to judge - plugins I used no longer work unless I turn off auto-update or move to the LTS version. The team knew these were breaking changes for months or years, but the APIs to un-break things don't exist and aren't prioritized. It's discouraging to collaboration when you look at 2+ year old issues (https://bugzilla.mozilla.org/show_bug.cgi?id=1215061) that still haven't been properly addressed.

Less "dire warnings on forums" and more "slow development pace for required pieces to make my workflow even possible again".

Here's an issue opened June 9 that hasn't been addressed by the Mozilla team and hasn't had any updates in a month: https://github.com/cmcaine/keyboard-api/issues/1

Here's the request for a better keyboard API (referenced in the above) that's been open for over 2 years with no end in sight: https://bugzilla.mozilla.org/show_bug.cgi?id=1215061

I'm sure the new FF is going to make some users happy, but as you said, having your workflow broken is quite painful, and the Mozilla team has known about this for years but still not made the upgrade path bearable.

That's the issue - there's no real path to making these legacy plugins work. There are open issues for a keyboard api for FF that has had very little movement over months, so while I'm sure it'll eventually get to a point where I can use FF as I used to, that not being the case now has given me little reason to stay with FF and so back to Chrome I went.

I've tried Tridactyl, but the plugin not working on Firefox pages is the same frustration I had with vim plugins for Chrome.

If the vim stuff was the only plugin I needed, I'd move over in a heartbeat.

This is sadly true. I switched off Chrome 5+ years ago due to the "vim-like" plugins being much better on FF than Chrome (specifically, my keybindings not working on built-in pages) and since FF56, vimperator and pentadactly no longer function. There have been months of back-and-forth between some developers and the FF team, but the functionality required for these plugins has never been prioritized and I had to disable automatic updating and download FF54 so that everything would function. Today I just gave up caring and installed cVim on Vivaldi (https://vivaldi.com/) which is Good Enough for now.

So use @property then?

I was lucky enough to land a Clojure job (stitchdata.com, we're hiring!) before having to learn Clojure, because I had the benefit of experienced mentors helping me get to grips with lisps (which were alien to me) and a development workflow that leaned heavily on the REPL (emacs + cider). Clojure has changed the way I think about many programming concepts and has been a joy to learn. It has it's warts but the core is very well built and I find the documentation to be quite good once you understand the basics.

Who needs privacy when you have nothing to hide?

Yes, my level of respect for traders is exactly zero. There's a difference between investing and trying to make a profit off short-term trades, arbitrage, and other forms of financial practices that offer dubious value to anyone other than the trader.

The transit alerts for NYC are pretty brain dead. I get alerts at lunch alerting me that my commute home has service disruptions on the subway. I'm not leaving for 6+ hours so the notifications are useless.

> To summarize, Mel enabled the index register bit (despite not using the index register) to cause an integer overflow, and because the instruction was at the very top of memory, it had the side-effect of also incrementing the instruction’s opcode, modifying the instruction to change into a JUMP command, in order to exit an infinite loop.

Reading this made me thing of some of the crazy tricks I've pulled in TIS-100. And while it worked well in a game, it would be a nightmare for that to be my day job.

If your first inclination in marketing your project is to make it a terrible pun instead of something more descriptive and correct, you're doing it wrong.