A bit of a ramble-y blogpost, mostly because it's fairly late as of writing this. Hopefully, that's okay. Many will shun the Not Invented Here mindset. It's not hard to see why. Many corporations will spend hours upon hours of creating their own implementation of something that has one or more publicly available implementations. It's often compared to reinventing the wheel. It's seen as an outdated and closed minded mindset, something that should be disposed of along with the rest of the 20th century's many interesting quirks, such as 70s retrofuturism or cathode ray tubes. Hopefully obviously, not everyone thinks this way, and there are valid criticisms towards NIH. This is just a rough generalization of remarks made towards NIH that I've found. It's also a fairly closed-minded view of NIH. Let me explain why. Perhaps the weakest argument I have is that it's sometimes necessary to go with a NIH approach. While it's nice to know we have so many libraries these days that can do everything for you, such as FLTK, Node.js, and SDL2, there are times you will come across something you need to implement, but cannot. Often times, this is because the implementation, whether it's the best or not, is copyrighted or simply not for public use. Adobe is infamous for copyrighting many of the implementations they made themselves for their products, such as Photoshop. While this is perfectly fine, and I have no problem with them profiting from their hard work, it does put you into a tricky situation when you want to implement a similar feature in your own product. Therefore, your only option is to invent it again, yourself. This, to many, doesn't qualify as NIH, however it does to me, as it fulfills the requirement of "we won't use it because it was not invented here." A stronger argument can be made for practice and training. While using someone else's implementation can be incredibly expedient, writing your own implementation not only gives you a deeper understanding of the lower levels of what you are using, but also can act as a way to teach yourself new concepts. When you go to implement something, you typically start at writing a general description of what you'd need. Once you've written this down, you go into researching what the math would be behind it. This engages you to learn the mechanics behind what you are implementing, and lets you find clever new solutions, or be Mr. Carmack and simply look up the best equations once you have a grasp of what you need. However, you still need to transfer the math to the programming language. As with most cases when looking to do something new, you will likely begin to look through the documentation of your language, and this will cause you to absorb new knowledge and have new concepts click. Doing this is especially useful during company training, as it promotes learning and understanding the language that you will be using.
On a side note, many will say that it's fine to make your own things, if you don't use it in production. I'm not entirely sure what the argument is supposed to be, I suspect something with security and optimization, which are both bollocks. Computers are unreasonably powerful these days. Even if you need to optimize because your program is suffering, you likely will have to redo the implementations of anything else as is. Likewise, most security vulnerabilities are going to crop up no matter what. It's impossible to have the perfect program, even a hello world file will have some sort of security vulnerability. Even if, say, a library has perfect security, the mass majority of applications probably aren't being used on a massive scale, and if they are, on average these applications aren't seeing networked use. Additionally, many security flaws can be solved by simply sanitizing input, which is something you should probably pick up even if you are using this "perfectly secure library." Besides, destandardizing security sounds like a better idea, as it would mean hackers would have to figure out a new standard for every hack they want to do. I can see why this would be completely unrealistic however. Imagine a web browser having to support 2,800 security standards and somehow having to discern them. The only decent argument I can think of is that using a NIH library may confuse other developers who were not given good documentation, or were not introduced to the library prior. This is a fair and reasonable complaint. Though this can be mitigated, especially in corporations where little is not documented and almost everyone working on the project knows about these libraries, it can still easily come up if, say, external contractors are brought in, or a new team is assigned to the code. Finally, on the personal side of things, you may just not like the implementation of something. For example, I don't like GNU make. It just never appealed to me, and though I know it's user error, I have never successfully gotten something to compile from a makefile. So, I have a completely different implementation I like to go with, where my entire project can be compiled from starting with one file. Infact, I made a Batch specifically for this. It does the things I want it to do. I drag, I drop, it compiles after asking me a question on which compiler option, and then immediately executes it. It doesn't matter what you don't like about it, I personally think that if you don't like it, you're more than welcome to make your own replacement, no matter what it is. We arguably would not have any of Chris Sawyer's many games if someone didn't go out of their way to do their own implementation of something they didn't like. There's also a sense of accomplishment just not found if you use a premade program or library. It's indescriable to stare at something and go "I made that happen. I did all of that." Sure, getting SDL2 running is great, but knowing that EVERYTHING underneath is yours, and that you made a concerted effort to improve gives you a satisifcation unlike any other. If there's anything you can take from this, I'd take that you should go out and make your own small scale project, completely from scratch. It'll give you a lot of insight, and also help you determine if it's worth the satisfaction, or if you'd rather just stick to what's already made. There isn't a wrong answer here, so long as you try.
This post devolved the moment I started writing it. I could use an servant whose sole purpose is to remind me not to do late night blogposts.
This is my first ever blog post, so I'll try to keep this brief. Today, I got to see the SpaceX Starship test, the one that was delayed from yesterday and finally launched after an hour's delay. I'm rather glad it got delayed, because I would've completely missed it if it hadn't. I wasn't even awake by the time it was originally supposed to launch! So there I was, watching my television in awe, chromebook hooked up to it, waiting for the launch. Let me tell you, my anticipation was GROWING, but so was my anxiety. I was thinking that, maybe, they were going to cancel it again due to another Raptor engine failure, or it might blow up before launch! You never know what could happen with these types of launches, it is a prototype afterall, that's WHY they're testing it. Much to my glee though, I saw the holy flame that graced the concrete as it began to lift off from the ground with a tremendous roar! Although my worst fear about it blowing up hadn't come to pass yet, it did fill me with a lot of hope that the Starship serial number 8 decided to take off for the second time in its career. This was the very first landing test, complete with a nosecone, and it looked just as good as any render would make it out to be. It of course did not take long for my fear of it not blowing up before lift off came to pass, as its mighty triplet engines shoved that grain silo far into roughly the same position as any of the two previous hop tests would do.
It flew for about a minute before anything really happened, and the entire time I was practically dancing in my seat, filled with glee at this stainless steel rocket reaching altitudes never seen before by any of the previous rockets. I had a brief scare with one of the engines cutting off, and especially when there was a mild problem directly after the shut off, but then after the second engine shut off, I realized that the shut offs were intentional. The fire, on the other hand, although unintenional, didn't appear to be a problem. It seemed to have just burnt off some sort of cleaning material, and nothing else. At around T+5:22, the dive was performed, and it was everything I wanted and more! Seriously, look at it! It's such a ridiculous look that you just HAVE to love it! The fins moved quickly for adjustment, which was really cool to look at. I'm completely impressed. You need to watch it yourself! I've attached a video below of the livestream. It flipped over just in time to light its engines, and it NEARLY made a landing, but all of a sudden, the flame on one of the engines turned green! What in the world!? Well, according to this tweet from Elon Musk, "fuel header tank pressure was low during landing burn..." Now, I'm no rocket engineer, but this almost looks like an engine rich exhaust event. However, given this new information, I have an idea on what this could actually mean for the engine(even though it is now lost). Essentially, when the fuel header tank pressure went low, more oxygen went to one of the engines. The interior of the Raptor engines is unknown, but if I could put two and two together, my guess is that a lot of oxygen went to a copper-rich environment, presenting a new, sickly green flame. I'm essentially suggesting that the engine burnt itself because of extra oxygen. Another potential is, because one of the engines failed to kick on, the engine with a green flame used its innards to try to compensate for the one that failed to turn on, but I believe this to be much less likely.
Fuel header tank pressure was low during landing burn, causing touchdown velocity to be high & RUD, but we got all the data we needed! Congrats SpaceX team hell yeah!!
Of course, in the end, as the tweet said, there was a Rapid Unscheduled Disassembly on the landing pad. Although the explosion was really cool, my hopes were, for a moment, vanquished in the bright orange flames produced from escaping methane. But it soon returned, because by all accounts, that was an AMAZING test! You'll never see something like this from a traditional company, or Blue Origin, because they don't have the balls to do something like this, and it seriously shows in their slow innovation! So, here we are. Am I disappointed? Yes. Do I think that space travel has no chance thanks to it? Nope! I actually think the failure helps them work out the kinks even more than a successful landing would've! I'm still hyped up for the next launch, and given that Starship serial number 9 is already mostly flight ready, I suspect we'll be seeing another launch, potentially before new years eve! But, there's also the potential that it doesn't happen. Whatever the case, Mars 2024, despite Elon's slight pessimism, is looking more and more realistic by the minute with SpaceX!
amused
accomplished
