Well, that is self plagiarism. Although I don't agree with the question or how that was handled, it is using your previous work without citing that you had previously written it.
I guess the corollary would be a baker asking a potential apprentice to bake a baguette and send a photograph. Sending a photo from your blog of a baguette you cooked a year ago might still be considered disingenuous, even if it shows capability.
Well, no, because a code snippet is the same every time you write it, whereas an apprentice may, even while following the same recipe, produce variations in the result due to the nature of baking.
Alas they'll attempt to justify it by saying they want your capability now, not X years ago. Maybe it's not entirely unjustified -- I have some old mathematical code on github that I don't think I could explain the technical details of without many hours of review, I wouldn't want to be hired to produce more code of that sort without an understanding that ramp up will be needed to return to my previous level. Given something like quicksort, though, I'd just get the feeling of "dance, monkey, dance".
Generally speaking tunnels are much safer than outside due to the lack of falling debris. And the fire issue is solved my any half decent sprinkler / ventilation system.
True. My concern (as a former Angelino) is what a ~2+ inch shear on the track would do to a vehicle traveling over 100mph. Lots of LA is on some fault or another that can cause these shears.
Maybe it’d just be a big thud and the car goes into limp mode. Worth modeling and having risk assessment on either way.
No, for a battery fire it's quite the opposite. It's going to release all of that stored energy and burn up the electrolyte one way or another. Flooding it with water is the best way to deal with all of that energy.
Releasing highly flammable hydrogen gas is definitely not "dealing with the energy". Both electrolysis and the reaction of water with lithium release plenty of it.
You're mistaken on that. Electrolysis is going to be far too slow to actually amount to any substantial amount of hydrogen and even if that wasn't the case burning all of that hydrogen would release only as much energy as it already took away from the reaction. Burning 100% of the hydrogen produced would still put you at a net 0 change in energy. For every joule worth of hydrogen that escaped without burning that's a joule of energy that you no longer have to deal with. Also it's a shorted out battery pack we're talking about. The voltage potential isn't going to be anywhere near as high as it would normally and if it was they you wouldn't have a flaming battery pack in the first place.
As to the notion that there's lithium metal in the batteries that could react with the water, you're thinking of non-rechargeable lithium batteries. Lithium ion cells use a lithium compound, not just pure elemental lithium. The formulation might be something like LiFePO4 but the point here is that it's not just lithium metal sitting around inside of it.
Also Tesla has an emergency response guide that includes instructions on fighting a battery fire. It's on page 22 (23 of the PDF) and it makes it clear that you want to douse the thing in as much water as possible and keep dousing it until it's totally gone. Tons of water is exactly what's called for when fighting these kind of fires.
> It also comes with a client implementation of the roughtime protocol in Go - initially I was not aware that there already was a Go implementation, but that also is not go-gettable. Either way, it was fun to implement it myself :)
So I don't know what this is doing. But I know that microsoft is developing WPF to run in a fulled contained .NET Core binary. Meaning that there is no requirement of having any preinstalled software when running it. I would assume this technology to be translated into most any .NET core app.
Yes, any .NET Core app can already be 'published' as a self-contained app. That basically means it ships along with the .NET Core files (there are a lot of them), so you don't need to have a globally installed .NET Core to run it.
What Warp does is act like a packer, creating a thin, native executable that compresses and embeds all the files required to run your app, then decompresses them to disk the first time the app is executed.
That's indeed true for the default interface implementation, but I believe for nullability it's just compiler warnings. At runtime, nothing will be left in the IL for this. It just isn't possible to do that and maintain backward compatibility
the resharper plugin to visual Studio or the rider ide will both do this. Only builds the projects required and doesn’t need to build dependent projects unless a signature changed.
It's not comparable whatsoever to how much faster Java is. In Eclipse it basically compiles in the background right after saving a file so you never feel the impact of compilation.
I'm not sure now, but 10 years ago I was really feeling the impact of compilation in eclipse.
On a big project that I was working on it was taking about 20 minutes for a full build and I had to disable the background compilation because it always messed up stuff and my code would be out of synch.
I think that in general Java compilation feels a bit faster, but for sure you can't say that you don't feel it at all in big projects.
Well that's def not true: Tableau, Rover, OfferUp, and countless more http://www.geekwire.com/startup-list/ and that's with only 2.61% of venture investment.
