rzimmerman

I'd guess the sail orientation is not changing relative to the sun, so at perigee this provides an acceleration (because it's mostly in the velocity direction), which raises apogee. At apogee it provides deceleration (because it's in the anti-velocity direction), which lowers perigee. There are also probably other effects depending on the sail orientation that muck with the inclination and other elements. It's a little different than drag which is always anti-velocity.

I have limited KSP experience and an aerospace degree, so I'd defer to someone with more KSP experience.

I love running with audiobooks. People I talk to are initially thrown off (don't you need high-tempo/"pump" music?) but if you're get into the habit and don't push yourself too hard it's easy to listen to fiction 20-40 minutes at a time while doing cardio. It's positive feedback, too - I look forward to running because I get to listen to my book. And I like my book because (after getting into a routine) running makes me feel good.

That's a good point - the "waste" heat from an RTG (which is only about 5% efficient) is very useful in those extreme cold temperatures.

A flying drone is a really solid idea for a Titan lander for a couple reasons:

* The surface atmosphere density is higher than Earth's (1.5 atm)

* Gravitational force is much lower (0.15g)

* We don't know a lot about the surface composition or topography, so wheels and motors represent a challenge

* Visibility may be poor, making visual navigation tricky (though that's also a problem for a flying vehicle I suppose)

I've heard people ask about "why a nuclear power source?" Saturn is 10x as far from the sun as Earth, so sunlight is about 1/100th as bright. In addition, Titan's atmosphere blocks most of that. There really isn't any other realistic option.

I hope it works and they take videos.

Building the wheels in a build container and copying in the wheelhouse is a great idea. Thanks for posting this.

I dislike using MCO as an example of why engineers should standardize units/use metric. This was one of the first NASA projects to be done using metric units with this exact goal in mind. The more interesting part about MCO is that it's actually a pretty compelling story about engineering culture interacting with management and how risks and problems are handled. It's not as simple as "NASA messed up metric" at all and people could learn a lot by reading the whole story.

The loss of MCO is actually a very interesting story about both engineering culture (engineers noticed a problem but the organization didn’t respond to investigate/fix it) and the conversion to metric. The root came from NASA deciding to use metric on this project and a contractor using the wrong units. But it’s the kind of thing that the process should be able to catch and handle. It bugs me to dismiss this failure as “haha why doesn’t NASA use metric” because not only is it a direct result of NASA switching to metric, there are really good engineering lessons that get ignored.

Interestingly the concern from the FDA was not whether or not soy leghemoglobin is safe generally, but whether or not it’s a potential allergen. Given that chemically equivalent ingredients are found in all kinds of food already, it’s a shame this got held up so long in a process that a lot of food additives skip entirely. But I’m happy that really solid beef alternatives are starting to become available.

I developed a fear of flying in my late 20s. My doctor prescribed me a low dose of Xanax specifically for flying. I take it about 1-1.5 hours before takeoff and it significantly reduces my anxiety about flying.

All the techniques listed here are helpful and may solve your problem in the long term. But honestly there's nothing wrong with taking medicine, especially if it's just when you fly and it makes the experience tolerable. The only potential negative is you can't mix it with alcohol on the plane.

If the extent of your anxiety boils down to "I take Xanax when I fly" then it sounds like you're doing fine!

GPS satellites are in an unusual orbit (between LEO and geosynchronous) where there is not a lot of debris. They’re also highly redundant and the constellation can lose several satellites without dropping service. Jamming is honestly more of an issue than debris.

mypy has gotten a lot better and I wouldn't discount it because of one bad use case. I went through the exercise of applying type hints to a large code base and uncovered several latent bugs.

That being said, mypy supports type hints in Python 2 code, so that really just adds to your argument.

I think this hits the real point. The expected value of the number of advanced civilizations may be high, but that could mean a very small probability of billions of advanced civilizations complemented with a very large probability of zero, one, or just a few.

Probably named after the Howey Test (https://consumer.findlaw.com/securities-law/what-is-the-howe...) which is pretty clever.

I think there are advantages and disadvantages to developing a project in a statically typed language just like there are for a dynamically typed one. For a lot of projects, Python makes sense because of the very deep and rich set of packages out there. It's also much easier to make something quickly if you're not fighting the compiler or a type checker.

But it's not binary and there are plenty of good reasons to have static type checking. I personally went through an exercise where I applied type annotations to a large Python project and found a good amount of bugs just by type checking.

I think having the flexibility to add type annotations later, only apply to parts of a code base, and allow some violations is a great middle ground and makes Python a much more attractive option for large code bases.

Yeah it’s a bunch of inside jokes from building spacecraft the same way many times with varying degrees of success. There is little to no practical advice. The bit about never exceeding the requirements is great if you want to build something once and wash your hands of it. The “advice” on not building new launch vehicles sounds like someone had a bad time building a launch vehicle and I guess we should double down on the shuttle?

Not everyone can post their work on GitHub, so I only look at their profile if they list it on their resume. I figure if you put it there, you want me to see it.

For early-career people (with limited work experience in the field) I look to see what tutorials they've done. I don't expect high code quality, but active engagement instead of copy-paste is nice to see.

If they've contributed to any OSS projects I look at things like:

- How they interact with maintainers and other people

- The quality of their PRs if any

- How well they communicate issues and file bugs. Attitude

matters a lot (offering helpful ways to reproduce it and suggestions rather than attacking the project for faults)

If they have any of their own projects I look at code quality. I deal mostly with Python and it's pretty easy to tell from a glance how experienced the person is. Things like following lint/style and style guides but also readability in general. You can smell out a C/JS programmer who just learned Python pretty easily (lots of for loops with indexes, for example).

If they collaborate on projects with others that's a huge plus. I look for signs of active collaboration, like PRs with good code review.

Basically I want to make sure:

- They're not exaggerating their experience (though GitHub profiles can be out of date)

- They work well with others

Again, just because a GitHub profile is sparse or missing some of these things isn't a signal. Not everyone does their work on GitHub. But if you list it in your resume, expect me to read it.

Honestly Uber's response to all of these seems pretty professional and reasonable. The submitter was hard to work with and seemed pretty eager to jump to conclusions about the Uber team's motivations. I haven't seen the details of the JavaScript XSS one but given the past behavior I'd understand some skepticism.

Their response to the Microsoft Store lack of cert-pinning seems fair (though disappointing for the submitter): https://hackerone.com/reports/293358

> This limitation is already known to us and as such we'll be closing this duplicate per our program guidelines.

to which he replies:

> Cute. Big surprise.

They should link to a submission if one exists, but it's possible and reasonable they already had an internal ticket.

The second issue, not revoking tokens on the server side after logout, the Uber rep replied:

> Thanks for the report, but after looking into it, this is a known limitation of our legacy authentication system and we're actively working on a new system that will replace these long-lived tokens with a more mature bearer token. Currently, the value associated with the x-uber-token HTTP header is a token that is only changed upon password reset.

The submitter added a long list of CWE items for OAuth, one of which was relevant (CWE-613: Insufficient Session Expiration). The Uber rep replied:

> Closing it Informative is not a judgement on the validity of the report -- it simply indicates we already knew about this and are actively addressing it already.

Seems reasonable that Uber's team knows their tokens don't expire and that it's not a good practice.

The rate limiting on the promo code endpoint report is the worst. It looks like Uber actually forwarded this one on to an internal expert, who replied with:

> we would consider the lack of multi-factor authentication a best practices concern, out of scope for our bug bounty program. Additionally, Uber tokens (UUIDs) are made up of 128-bit highly entropic values, making them very difficult to guess or brute force. We’ll be closing this report Informative, as this does not pose a security risk in itself. We wish you the best of luck on your next report!

Which is completely fair (you'd have to try ~10^29 values to get a valid token assuming a billion accounts, which would take millions of years at 1 trillion requests per second). The submitter argued their PRNG might be broken but provided no evidence that was the case. The submitter then posted some very hateful personal attacks against the people responding, including:

> Oh my God. Are you seriously the Program Manager for Uber's Security Division, with a 2013 psych degree and zero relevant industry experience other than technical recruiting? LULZ

I can understand feeling less than obligated to give a payout on these.

I think you make a very interesting point that the direct election of senators removed an important protection by effectively shifting representation in the senate away from state governments directly to the people. Direct election was opposed when writing the US Constitution for this very reason.

Planet | SF | System Testbed Engineer | ONSITE | https://www.planet.com

Planet designs, builds, and operates the world's largest fleet of earth observation satellites. In this role, you will lead test and validation efforts to improve quality and drive development speed through testing and validation. You will work closely with cross-functional team members to develop and maintain a test infrastructure and to test new hardware designs and software products.

You will work in a lab environment with exposure to hardware, ground support equipment, and test equipment. Our system testbed is a new and growing project, so you would be responsible for gathering customer requirements from other hardware and software engineers and building infrastructure from the ground up.

The Must Haves:

* Experience working in a lab environment and building/maintaining test hardware fixtures for spacecraft and/or embedded devices

* 3+ years of experience with Python and embedded C programming

* Experience with verification and validation of systems that include embedded software

* Comfortable in a Linux environment

* Experience with continuous integration, automated testing, and build systems

The Nice-to-Haves:

* Experience with AWS, Docker, Jenkins

* Aerospace experience, especially with power systems, ADCS, or flight software https://techcrunch.com/2017/02/15/earth-imaging-company-plan.... Apply at: https://www.planet.com/company/careers/jobs/?gh_jid=587830

If anyone would be helped by an example, I worked on this recursive descent-based compiler a few years ago with a focus on clarity and readability:

https://github.com/rzimmerman/kal

The actual parsing is here: https://github.com/rzimmerman/kal/blob/master/source/grammar...

It's somewhere between a toy language and something professional, so it could be a helpful reference if you're doing this for the first time.

Beware, the project is no longer maintained and probably doesn't work with modern node.js runtimes.

I used these blue bikes for a couple months and eventually gave up because the stations in SoMa were invariably full. I'd have to wander around with a heavy bike looking for somewhere to park it and it made my commute unreliable. This was 2014, so maybe it's improved.

Planet | SF | System Testbed Engineer | ONSITE | https://www.planet.com

Planet designs, builds, and operates the world's largest fleet of earth observation satellites. In this role, you will lead test and validation efforts to improve quality and drive development speed through testing and validation. You will work closely with cross-functional team members to develop and maintain a test infrastructure and to test new hardware designs and software products.

You will work in a lab environment with exposure to hardware, ground support equipment, and test equipment. Our system testbed is a new and growing project, so you would be responsible for gathering customer requirements from other hardware and software engineers and building infrastructure from the ground up.

The Must Haves:

* Experience working in a lab environment and building/maintaining test hardware fixtures for spacecraft and/or embedded devices

* 3+ years of experience with Python and embedded C programming

* Experience with verification and validation of systems that include embedded software

* Comfortable in a Linux environment

* Experience with continuous integration, automated testing, and build systems

The Nice-to-Haves:

* Experience with AWS, Docker, Jenkins

* Aerospace experience, especially with power systems, ADCS, or flight software

https://techcrunch.com/2017/02/15/earth-imaging-company-plan...

Apply at: https://www.planet.com/company/careers/jobs/?gh_jid=587830

Another (real) story of my own:

We had a piece of software that would present a dialog for the user to select a file, then parse and send the contents to an embedded device. This software was an internal tool and not very reliable, so it would crash if you selected a file with invalid contents.

Two engineers, Dan and Brian, came to me with a tricky problem. Every time Dan would open a specific file everything would work fine. Every time Brian selected the same file the program would crash. I was obviously skeptical and went to watch. We tried it 10-20 times and sure enough, it always failed for Brian and worked for Dan. I watched them perform the exact same steps.

Eventually I gave it a try myself and realized what was going on. Dan would click "open", select the file, then click OK. Brian would click "open" then double click the file.

Oh, sorry, I never bothered to change the function name. It's just an interesting loop.

The first GPS satellite was launched almost 40(!) years ago (https://en.wikipedia.org/wiki/GPS_satellite_blocks#Block_I_s...)

Galileo's actual value has always been murky. It's use case has changed a lot over the years. Originally it was meant to be a navigation system free of GPS's Selective Availability "feature" that diluted precision for civilian use. The Clinton administration effectively killed SA (http://www.gps.gov/systems/gps/modernization/sa/) in 2000. Galileo was sold as a higher precision civilian alternative that was going to be commercially viable and make money. A few years later the US made improvements to the GPS ephemerides and effectively increased precision of GPS, making the benefits less obvious. The new block of GPS satellites offers even better precision and a lot of the Galileo features (like multiple civilian frequencies). It's honestly quite hard to compete with a free alternative that the US government throws billions of dollars at. Still, GPS can't hit sub-meter accuracy any time soon, so there's a real potential use case emerging for autonomous cars and aircraft.

If you're excited and interested in Galileo it's really worth reading up on how GPS works and was built. The first satellite was launched almost forty years ago and it was operational in the 1980s. It's truly one of the coolest and most amazing things made by humans.

The article was a little unclear. Originally Galileo was supposed to use the same frequency band as GPS which would prevent the US from jamming it without also affecting GPS.

Try with gcc 6.2 options -Ofast -march=native:

  int square(int num) {
    int a = 0;
    for (int x = 0; x < num; x+=2) {
      if (!(x % 2)) {
        a += x;
      }
   }
    return a;
  }

All kinds of loop unrolling and vector instructions. Now remove the "!"

A lot of the issues in this article seem to stem from running Docker on old kernel versions.

> We are using Debian stable with backports, in production. We started running on Debian Jessie 3.16.7-ckt20-1 (released November 2015). This one suffers from a major critical bug that crashes hosts erratically (every few hours in average).

If you're stuck on an older system that's poorly supported by Docker then it may be a bad choice for you.

I've worked a bit with "the big monorepo" (though nothing like Google scale) and my impression is that a lot of the benefits fall apart if you don't have people working to maintain the build environment, automated tests, developer environments. When it takes hours or more to run tests and produce a build it can really slow the team down. The ability to force updates on dependencies in a single big commit can be really worthwhile as long as you're willing to spend the time to build the tools and do the maintenance.