The cartoons in schematics are very much a product of their time - they were hand-drawn by skilled draftsmen who enjoyed drawing. I suspect most of them had a spare pad of doodles next to their work table.
If you compare this to the schematics of more modern electronics, they are often madness. Even though it is far simpler to re-arrange schematics using EDA, it clearly isn't done a lot, because parts are sprinkled around randomly, everything is just on one enormous sheet or everything is randomly split up across sheets with numbered net names making connections etc.
The places I've worked have pretty rigorous style guides, and I personally try my best to make schematics readable and understandable. I suppose this is the same thing as code quality guidelines: you can set expectations and examples, but folks don't necessarily have to follow them.
My cooler projects are all stashed away somewhere in a company drawer, but here's one that I did early on:
- psu drawing: no left-to-right flow, connector names are numbered, output connector (CONN2) is just floating around on the left and connected via net names. Same pretty generic net name ("out") is used as in the main amp.
- amplifier drawing: the main feedback loop is obscured because it's only connected via net names, connectors are again just stashed of somewhere to the side and only connected by name and not labelled. I would also point out that each op-amp of the quad-op-amp U1 shares the same designator, so you can't talk about U1a, U1b etc., which you actually do in the text.
The left half of the schematic is arranged pretty neatly and logically, but the discrete output stage is pretty cramped over there (clearly limited by the fixed sheet size), though standard arrangements of the building blocks make it quite clear what everything is (U1c U/I conversion, current mirror to the top rail, mirrored back to the bottom rail with an x3 CM, resistive load to the top, emitter follower output stage, CCS as load, off to the output).
But, Wolfspeed's SiCFETs /do/ have a published SOA (see fig 22), so maybe I should revisit this...
 Figure II-3: "Visual Image of the IRF1405Z failure. This type of visual pattern is more attractive when observed on the surface of the moon, instead of on the surface of parts that are trying to land there." http://www.irf.com/technical-info/appnotes/an-1155.pdf
1. We can ensure that they won’t explode when we use them.
(admittedly I understood very little after that ;P)
Wikipedia has a list of software easter eggs, let's see if we'll discover more of them as time goes on.
Larry Osterman says it even better: https://blogs.msdn.microsoft.com/larryosterman/2005/10/21/wh...
no. Easter eggs show lack of "zero tolerance" corporate posturing. Which isnt to say that such posturing isnt important part of the security theater.
The cartoons, easter eggs, etc. is a "human touch", a sign that the product is done by people who love (or at least feeling something toward) their job, not by drones. Modern corporate environment is based on droning and has naturally extinguished that human culture.
So, coming from Microsoft, it's easy to dismiss the entire article based on its initial premises.
For those less familiar, feel free to browse adequacy.org, or just read this gem:
I understand the concept that maybe certain classes of software (say, medical or military software) shouldn't have eggs, or perhaps that certified eggless versions of software should be available in situations involving contracted software. But would you say the same thing about game software? Hobbyist software? Easter eggs aren't always bad.
if anything, i think that Excel would have much more bugs, and would have much tougher time taking off :)
Evil usually comes from above.
That was an eons ago different era.
Go's gopher cartoons are a nice touch, too.
etch their name into history ;-)
From the comment sections, it appears to me that Hacker News has no shortage of hobbyists and professional electronics engineers, but when I search relevant terms like "Tektronix", "oscilloscope", "spectrum analyzer", or "SPICE", there's no much information here, only two or three top articles. I guess it's unfamiliar to the Silicon Valley CS majority who doesn't have enough appreciate of hardware engineering. I'll try to post more of them in the future.
Hikaru's diary on learning to solder. A short story about soldering, from basic tools and safety precautions for getting started to solder things, good and bad solder joints, and the purpose of flux, it later goes on to explain how simple and thermal-regulated irons and how their heating elements work, point soldering and drag soldering techniques for SMD components, wave soldering and reflow soldering, and finally SnPb and lead-free alloy.
We were simple people then finding amusement in the smallest things