I went through something similar building my first PC. I had worked a summer job just to be able to afford one, researched all the parts obsessively, and slowly waited for all of the parts to be shipped to rural Alaska. I put the all of the components in the case, flipped the PSU switch, pressed the power button, and -- nothing, not even a BIOS screen. Five red LEDs were lit on the motherboard, indicating a major hardware fault: CPU, motherboard, RAM, or PSU. Well, there was nothing else for it but to start replacing the parts one by one to see what was broken. It would take a day or two to get the Return Merchandise Authorization, and two weeks shipping time in either direction, so every month or so I would get a new part in to try to get this machine to work.
That went on for about five months. I was crazed with frustration, and a growing pile of electronics boxes, tools, and testing devices filled the corner of my room. I had a collection of components which I was sure were working: the system at least appeared to boot to BIOS when lying on the workbench, but when all the parts were hooked up inside the case, we got five red lights again: major hardware fault. Finally, at the limits of my frustration, I turned to my brother for aid: "It works on the bench, but not in the box. I don't know why. You figure it out."
He returned not five minutes later with the widest grin you can imagine. I was incredulous, and this was a better practical joke than he could ever have devised. He showed me that having the case's reset button (correctly) connected to the motherboard caused the error condition. I was so thankful that I almost didn't want to strangle him!
I've seen situations such as that. Working outside the case, but not in the case is usually points to a short of the motherboard through the case (of course, assuming it is wired correctly).
As I recall, it took me a considerable while to determine that the equipment worked outside the case. I think I tried replacing the RAM, CPU, and PSU before doing the mobo, and unless you have an idea that the case itself might be the issue, well, why would you take the rest of the machine apart? And even if you suspected a board short, you might easily be misled into thinking that it was a part of the case touching the mobo inappropriately, and leave the reset/power leads connected: it's a lot easier to punch the case reset button than to use the tiny one built into the board. And of course, figuring out that the system works without the power switch connected is not super useful in itself: that is something of a necessary component.
I'm just still amazed that he figured it out that quickly; I really didn't tell him much about what had happened, and I'd hardly had time to leave the room before he'd solved it. What a jerk :)
"If the doors of perception were cleansed every thing would appear to man as it is: Infinite. For man has closed himself up, till he sees all things thro' narrow chinks of his cavern."
More to the point, however, I think that human minds often handle perception in general, but the problem of objectively observing the subjective is somewhat less tractable.
> Mathematics, so useful a tool in the past, cannot describe this situation. The only way to describe this system is by using the system itself; there are no shortcuts.
> Math, philosophy, reason and order are inapplicable because they are only rules-based approximations of a chaotic state.
This is really a superlative cop-out. "My theory is so genius that math, philosophy, reason, and order are insufficient to describe it."
Tesla is a bad example for almost any given point, but in this case it's relevant to note that he was not a scientist, and his funding model did not work.
Ruby is a heavily idiomatic language. It's strongly advised to use rubocop or a similar style guide -- and to temper that with good judgment, at least when it recommends avoiding `!!`.
In addition to the Pickaxe book, I recommend Metaprogramming Ruby by Paolo Perrotta, and potentially the sequel to that book (which I have yet to read).
Ruby lends itself to a very fluid style. One of the things that you may find less common is explicit variable assignment within a method: most of the time your assignment will be in method signatures and block declarations. The following code is illustrative of technique, but not recommended practice:
This generates "non-words", which are guaranteed not to exist in the (Unix) system dictionary, without using explicit assignment. First it creates a (lazy) generator object which yields random "words" of varying length. In Ruby, if you are calling a method with only one argument in an inner loop, you can avoid writing the loop explicitly, which is nice here because it also avoids the performance hit of reading the dictionary file repeatedly. The `method` method lets us pass an object-method pair, to be evaluated later, and the '&' there is a sort of cast-to-block, and you'll see that used in other contexts. So, at that point, we have a lazily-evaluated collection of lazily-filtered strings, and we can take an arbitrary number of these out and print them.
The nice thing about Ruby is that you can probably express what you want in one statement. This does come at the cost of a fair amount of idiom. Some of it is functionally important, some of it is convenient (like using the `*` operator to destructure ranges), and some is pure window dressing, but enforced by convention just the same. The Pickaxe book is better than anything else that I am aware of for describing Ruby idioms. I'm not sure how well it has aged. It's probably recommended to do a lot of pair programming and code review. At times I have mentored others on the website Exercism, and I would recommend that or a similar site.
I had decided against a somewhat stronger statement; I didn't want to bash Pickaxe unnecessarily, particularly as I don't have a lot of better suggestions. I'm fairly inclined to write a book myself to address the situation, but not any time soon.
The Shuttle was designed for a use-case that evaporated, and it's not necessarily inaccurate to suggest that it was manufactured so as to spread "pork" to as many Congressional districts as possible. However, wasting money on space is not necessarily a waste, particularly if no one else is doing it. And for all their faults, the Shuttles flew high, and accomplished much.
I patched my firmware and installed GalliumOS[0], which is basically a tweaked version of Ubuntu. I was previously using crouton[1], which functions similarly[3] to Crostini. On ChromeOS, I was using the Cloud9 Web IDE (which has since become an Amazon service), and on the Crouton/GalliumOS side of things I've been using ST2/3, but have essentially switched completely to SpaceVim[3].
ChromeOS is fine for web development, except that it started killing tabs after you open ten or more. I liked Cloud9 for the most part, particularly that it saved its state all the time: you could close your browser window, and come back to that project a few days later, and all of the same files would be open, and any terminal commands still running.
Both NetBeans and Atom were painfully slow, regardless of system configuration.
Switching to a docker-centric (i.e. HDD-heavy) workflow has meant switching to a remote server -- for now, a VPS, at least until I get my local server a new HDD. So ChromeOS is perfect for my needs, in that it has a full-color terminal with ssh, and a web browser for documentation. However, that's kind of a low bar. On the plus side, ChromeOS is quite secure. On the minus side, it's not "real" Linux in some relevant senses. Auto-updating is nice, and also being able to unbox a new machine, sign in, and automatically have your local apps and files start appearing. Heavy Google Apps integration is probably more of a feature than not. However, the rate at which the OS would kill tabs (including the terminal!) made the system quite unpleasant to use. Yes, the problem here is me: the hardware can't easily handle a large number of tabs, and it's a perfectly valid decision to kill tabs quickly rather than let the system become unresponsive. Probably it was even mostly effective at that. Probably a better-spec'd machine would have fewer memory issues. However, I have consistently gone to considerable lengths to avoid using ChromeOS: replacing the firmware requires disassembly and the removal of an internal screw, and risks bricking the machine. Enabling developer mode prevents the system from booting normally: instead, a white screen appears after power-on which says something like "Press spacebar to restore ChromeOS". I believe that it does let you know that this will wipe the user partition, after you've started. It does not tell you the key combination required to boot the machine. Loaning out a Chromebook in developer mode is therefore not recommended.
I'm shopping for a replacement for the chromebook I'm typing this on. It cost $115, I've used it for a couple years, the second power cord seems to be giving up, and the screen is partially held together with electrical tape: I think it gives it a bit of character. I've had at least two other (cheap) Chromebooks before this. I don't think I'm in the market for another. At the moment, I'm probably looking for a (Linux) Dell XPS 13, or similar: I would appreciate any suggestions.
Tabs being killed is most likely due to the low RAM on your Chromebook. I've been having 100+ open tabs for several weeks on my 8GB RAM Pixelbook, without problems.
That went on for about five months. I was crazed with frustration, and a growing pile of electronics boxes, tools, and testing devices filled the corner of my room. I had a collection of components which I was sure were working: the system at least appeared to boot to BIOS when lying on the workbench, but when all the parts were hooked up inside the case, we got five red lights again: major hardware fault. Finally, at the limits of my frustration, I turned to my brother for aid: "It works on the bench, but not in the box. I don't know why. You figure it out."
He returned not five minutes later with the widest grin you can imagine. I was incredulous, and this was a better practical joke than he could ever have devised. He showed me that having the case's reset button (correctly) connected to the motherboard caused the error condition. I was so thankful that I almost didn't want to strangle him!