HN user

legomaster

519 karma
Posts9
Comments11
View on HN

OmniSharp powered intellisense and other features are easy enough to stick in VS Code. It's easier to package and deploy than MonoDevelop. Much easier (at least for me) to write extensions for VS Code. I see it as a win-win. MonoDevelop has always been a frustrating experience for me. While VS Code isn't perfect, I'm less frustrated using it than MonoDevelop.

I wonder if it means a transition to Visual Studio Code at some point. I doubt it would happen soon, but I feel like there's a lot more support behind that IDE than MonoDevelop.

I agree, I think SpaceX will have re-usable rockets with the Falcon 9 long before this is working. But I believe you could extend the jet-powered-rockets to larger launch vehicles than you could the tech in the Falcon 9. Plus, the tech might be able to be extended to have cheaper super-sonic flights. But that's long ways down the road.

A company in the UK is working on a multithrust rocket/launch vehicle that would be reusable. It mixes a super-cooled jet engine with a rocket booster. For once you get beyond enough air pressure for the jet engine.

https://en.wikipedia.org/wiki/SABRE_(rocket_engine) https://en.wikipedia.org/wiki/Skylon_(spacecraft)

Something like this, that's reusable, would allow small (but larger than cubesat) payloads into orbit for what should be a reasonable price. 200 launch lifetime on the vehicle is the plan.

Topshelf's documentation does need some more TLC -- if there's something specific you thought was lacking I can take a look at updating it.

I'm glad to hear you're getting value out of it! Last place I was at, we had about 30 distinct services running. It was a huge bonus to have Topshelf.

You can, though you doing get to do it by using the ref/pull/## trick. That's just a connivence, you can get CI to do about anything.

Talking to a lot of people at conferences and similar events, rebasing against the target branch before merging is pretty uncommon. Few people think a clean history is that important.

Personally I think, rebase + auto-squash/auto-fixit makes the history a lot easier when it's time to look back. It just happens so rarely I wonder if it's really worth the effort I expend on it.

It seems like the example of double fixing the calculation is a great reminder of the value of unit tests. Even if both commits added a unit test in slightly different ways so they didn't conflict, you'd just end up with a failing build and know something got screwed up.

As someone who used to write a lot of LaTeX documents, this just isn't up to snuff yet. It's slow (which they can fix) but what would make it really helpful is hints in LaTeX commands and support for packages. I haven't tried any complex documents yet, hopefully a full 200 page doc with biblo and index would render correctly as well. It's cool though, I hope it does end up working well.