critium · HackerTrans

critium

no profile record

Submissions

Disney Prevails in Hunt for Fox as Comcast Drops Bid

1 pointsby critium8 lat temu1 comments

Vim 8.0 Released

groups.google.com

1 pointsby critium10 lat temu0 comments

comments

17 dni temudiscuss

Disney | Senior Software Engineer, Backend | ONSITE, NYC | Full Time The Subscriptions team is looking to expand our team in the NYC office. We are a dynamic team of engineers that support all your Disney, ESPN and Hulu subscriptions at scale! We solve problems at internet-scale that only a handful of teams ever reach.

* FP Scala is our main programming language. Apply if you have FP experience - we consider other language backgrounds but if you have FP experience, you will be strongly considered.

* Strong collaborator - this team is very social and we keep each other honest.

* Passion in maintaining high code quality.

* AI Enabled but not dependent.

* Our backends are global scale built on AWS and K8S.

If you are comfortable with these technologies, please apply below!

https://www.disneycareers.com/en/job/new-york/senior-softwar...

w zeszłym miesiącudiscuss

We do but I don't want to over promise here since that's not my area. My best recommendation is to apply if it looks like a fit.

w zeszłym miesiącudiscuss

Disney | Senior Software Engineer, Backend | ONSITE, NYC | Full Time

The Subscriptions team is looking to expand our team in the NYC office. We are a dynamic team of engineers that support all your Disney, ESPN and Hulu subscriptions at scale! We solve problems at internet-scale that only a handful of teams ever reach.

* FP Scala is our main programming language. Apply if you have FP experience - we consider other language backgrounds coming in but you will be doing FP Scala, so expect an FP style interview.

* Strong collaborator - this team is very social and we keep each other honest.

* Passion in maintaining high code quality.

* AI Enabled but not dependent.

* Our backends are global scale built on AWS and K8S.

If you are comfortable with these technologies, please apply!

https://www.disneycareers.com/en/job/new-york/senior-softwar...

3 lata temudiscuss

Also see second system syndrome/effect:

https://en.wikipedia.org/wiki/Second-system_effect

2.0 is the hardest version to write.

8 lat temudiscuss

From the Article

>>> A top U.S. Justice Department official, Makan Delrahim, praised the deal as being carefully sculpted to avoid antitrust concerns, signaling federal regulators were unlikely to block it. That stance is all the more notable given his continued efforts to kill on antitrust grounds the AT&T acquisition of Time Warner, a combination of a telecoms giant and an entertainment powerhouse that have little overlapping commerce. The Justice Department is appealing a judge's ruling that swept aside all objections to the AT&T/Time Warner merger.

9 lat temudiscuss

Im curious as to how he's using vim + ensime. I've been trying off and on for the last 2 years to figure out a good workflow using ensime but i typically end up just turning it off after a few days. EnType only works for me when its completely obvious. EnImport seems kind of useless. After these 2, i just give up, tbh.

Still, I wont give up my text editor :) Any emacs folk like to comment on its usefulness? Its seems more fully implemented there.

9 lat temudiscuss

would that happen to include scala?

10 lat temudiscuss

Space Data Centers -- we got tons of power, just need to figure out how to vent all that heat.

10 lat temudiscuss

this reminds me of the post about the jvm code cache a few days ago where if they had left the jvm to optimize the code cache by itself, the would not have ended up with the problem situation where the had to spend time to figure it out their optimization was the cause of the problem.

-- sorry for the run on sentence.

10 lat temudiscuss

My posit was that 80% of the software an engineer will write will not require optimization and based on the responses i've been getting I should have used "rule of thumb" vs mantra. My intention was to warn the ones that read this and say, oh i gotta do all of this for every piece of software that I write, which will undoubtedly lead to overly complex code when a simple solution would have worked just as well.

  "Know your performance goals going in and code accordingly."

I this is key sentence here and its worth repeating. Know your performance goals before your fingers touch the keyboard.

10 lat temudiscuss

absolutely agree with your last sentence. But thats not a majority of software written in my experience.

  "If you really need *high performance*, you need to design for high performance, not just leave it as an afterthought."

Emphasis, mine.

10 lat temudiscuss

While this article is itself worth a read, remember the programming mantra:

  * Make it Work
  * Make it Right
  * Make it Fast

And this is the last step. While this does not apply to all projects but it does apply to the majority.

10 lat temudiscuss

For the release notes see:

https://raw.githubusercontent.com/vim/vim/master/runtime/doc...

10 lat temudiscuss

I would add to the list;

* If you have transactions, keep your transactions to a single machine/instance/db as much as possible. Muti-machine or software transactions are the LAST solution you should try.

* Pay attention to payload sizes. Make sure you dont come close to saturating the network. Which leads to weird "app is slow" problems.

* Design for testability and diagnosability of production systems. If this is java, use JMX extensions EVERYWHERE for EVERYTHING.

* Time (and timing) is your enemy. Make it your friend.

EDIT: Side note. IMO, JMX extensions are one of the most under-appreciated things that java and jvm devs have but keep forgetting about but its so powerful.

10 lat temudiscuss

While I agree deeply nested calls are bad, I've also had the pleasure of inheriting a an application with several, muti-thousand line functions and those are not fun either.

In code as in life, all in moderation.

10 lat temudiscuss

I suspect the bugs like this come about because of a patch not because of the original development. Devs and dev teams tend to get sloppy after the first push and budgets tend to shrink dramatically.

One time I found a bug that was running for a few years and the result of it was the company was under reporting by millions of dollars per quarter (the running total was near to $100mm, and im sure it crossed it after my contract ended).

This was VERY well tested software in the beginning (one of the best test suites i've seen actually) and audited up to high heaven. The problem started when the patches rolled in and those, are not tested anywhere near as much.