As others have noted, there are tons of "USB Scopes" out there, from the ultra-cheap (and limited in numerous ways) to the very, very expensive. In fact, virtually all of today's "standalone" scopes are not much more than a specialize sampling interface connected to a custom embedded system. Usually that system runs anything from some embedded (or not) form of Windows, Android, Linux, VxWorks, or even a custom or customized real-time OS. If you go on Ebay or Amazon, and search for "USB Oscilloscope", you'll find a ton of options. If you google the same - again, you'll find plenty. Some of the more interesting ones are cheap Chinese things that don't cost a lot, but have a decent amount of bandwidth for hobbyist use - anywhere from 20-100 MHz on a single channel (usually half that on dual channels, if that is offered). Most of these also have a built-in signal generator, and an 8 or 16 input logic analyzer input. Most of the time the software is Windows-based, but some of them have Linux open-source ports available too. The downside of these cheap scopes is that the front-end - that is, the thing that samples and such - can leave a bit to be desired. If all you want is to check a basic signal level or maybe the frequency of a bit train or something, they are perfect for that. But if you are trying to figure out some kind of noise issue, the scope itself might have millivolts of noise on the output as-is, which is no good (so if you are doing serious work, pay for a serious scope). Other items you'll see out there are all manner of USB Logic Analyzers, which are basically multi-channel oscilloscopes designed to measure and show a set of digital signals, within a certain bandwidth. One well known (and expensive) set of models are made by Saleae - they also tend to be the most cloned set, as well (mainly because their software is so good). So you'll find their top-end models, plus counterfeits (some of them will be marketed as particular embedded dev systems - because really that's all the Saleae scope is, done up in a fancy case). Finally - if you continue to dig - you can find tons of articles, blog posts, Arduino forum musings, Instructables, and other instances of people showing how to build such scopes; everything from display on an LCD to dumping the data over USB and such can be found covered, using virtually every kind of embedded processor you've ever seen. And if you dig really far down, you'll find old text files on how to build such scopes using a PC, it's parallel port, and custom DOS softwa

I always wanted to email 'em back to let them know I already told my family and friends all the weird shit, pr0n, etc. /How do you stop the kidnapper? Shoot the hostage.

"But things like AI and serious DNN based speech recognition, which I am very interested in, I've dug into enough to know that I won't be able to go there. They are already too 'mathematics doctoral thesis'-like for me to take on in the time I have left, at least without completely discarding any existing obligations which ain't too practical." I think you might be selling yourself short there, unless by "time you have left" you mean "I only have 6-months to a year before I die" - even then, I'd still say to go for it. Really, it isn't as difficult as you think. With today's tools and frameworks, while you do need some understanding of what is going on under the hood, it's not like you need to have deep level calculus knowledge (that would really only come into play for implementing such frameworks). It's kinda like making a 3D game - you can either spend the time writing an engine, or just grab one already made (with scenegraph, etc) - and get down to writing your game. Personal anecdote: In the fall of 2011 it was announced that Stanford was sponsoring a couple of online learning classes, being taught by three top-tier instructors. These classes were called "AI Class" and "ML Class". I managed to get myself enrolled into both. It's been said that they didn't expect a huge amount of response from people to take these classes, but they were completely blown away by the number of people who eventually did enroll. The "AI Class" was being taught by Peter Norvig and Sebastian Thrun. The "ML Class" was being taught by Andrew Ng. Do any of these names seem familiar? They should... These online classes were not a new thing, but they did succeed in showing how to do it properly. Prior to this, online classes tended to be more ad-hoc affairs, cobbled together from pieces, or just courses uploaded for others to browse, but nothing structured properly, outside of a very few paid and expensive offerings. These two courses were really the pioneers of what we call MOOCs today. Anyhow, I took them. It was a struggle. To make a long story short, I completed the ML Class, and got about halfway thru the AI Class before I had to quit due to some personal issues that I won't go into. But I was doing well at that course (though it was right at the edge of my skill and knowledge base). As an example of what a student managed to accomplish via what they learned in the "ML Class": How I built a self-driving (RC) car and you can too.[

This is kind of triple-D I prefer; though I've never seen it put into practice, it seems like it would work in a reasonable manner - and really isn't far from what many of us do already: Meme Agora: D-Cubed[^] D^3 - Defect Driven Design It's an old idea (and unfortunately, the original source can't be found any longer), but if implemented properly, in theory it would always result in an application that is -exactly- fit to the requirements of the client. Essentially, you pretend your project is already in maintenance mode, and you're just fixing "bugs". Sooner or later, that's where you're going to end up anyhow, so why not start there at the beginning?

At my first employer as a very junior software engineer (though we called ourselves programmers back then - early 1990s), we used a variant of the PICK operating system called UniVERSE that ran on AIX. Our code was mainly in PICK BASIC, which was a "business BASIC" variant. With the version we were using, we'd sometimes run into bugs that would throw an error at runtime, but when you'd run it in the debugger (which was a nice step-wise debugger, with tons of nice features for the time), it would pass right by the line with the supposed error, and work just fine. Then you'd exit the debugger, run the same piece of code - and it would work perfectly! Think about that - it was a literal debugger! Even so, it was hella annoying...

As with all conventions, there are many: Where I work, we use _ to designate private stuff, and $ to designate DOM objects...

I don't think you're over-reacting, and after reading all of the replies and your's - well, you've already taken your action, so I'm not going to recommend anything else. But for what it's worth, I used to be in this position with my wife's family and friends. She could see how it frustrated me, so now she just tells people that I don't do that kind of stuff, that I don't know anything about windows or macs, etc. Basically, she tells them I'm incompetent around computers, despite the fact that I owned my first computer and was coding in assembler back in the 1980s as a kid. Anyhow - for a while she told them I only knew Linux, and nothing else; of course all that is a fat lie, because I can find my way around any system you plop me in front of (ok - I might have difficulties with an old Vaxen or Symbolics Lisp machine - never touched either outside of a museum). But if it's anything consumer related made in past 20 years, I'll probably not have a problem. Heck, even an Amiga or older 8-bit machines aren't entirely out of the question either. But nope - all I know is Linux, stupid on anything else. But of course, now, I don't even know that (maybe I should have my wife tell 'em I only know TempleOS and it would be blasphemy to help unbelievers?)...

Yeah, I really hate those dispensers. They expect you to pull on something with wet hands that is just going to tear easily once you grab it. It's gotta be the worst design on the planet. What the hell ever happened to just keeping things simple? Maybe you remember or maybe you don't, but there used to be towel dispenser that had a crank with rollers. Just grab the crank, rotate it out for the amount of paper you want, then tear it off. Easy, simple, mechanically robust, always worked. For a lot of stuff, the problem is two fold: First, they gotta make things break so you'll have to buy more of 'em, and second, they have to constantly change things on them (usually to worse solution) to make you either have to buy the new model because old consumables are no longer available or no longer fit - or just to make you think that if you keep the old stuff around, you are no longer "cutting edge" or whatnot. Basically the automotive sales model.

Dontcha just hate it when you open your mouth and the words just tumble out, and even as you say 'em, you can hear yourself and something is scream "HEY IDIOT STOP SPEAKING" - but you don't...and you end up here. Like word vomit or something...

Yeah, those emails are hilarious. They make the assumption that "omg, people are going to find out I looked at pr0n!". I once emailed 'em back and told 'em to go for it - I shot the kneecaps of the hostages a long time ago, nothing embarrasses me on that front. Not that it really mattered - they assume you're running Windows or such; I've been on Linux here since 1995 or so - and I don't have a webcam hooked up to my box, so there's that, too.

Hey man, the 1980s are calling, they want their "insult" back...

"request quote" I'm sure that'll be inexpensive for home use. Right.

On my last PC build my collection of old crap saved me some heartache... I had bought an AMD motherboard that could take a regular AMD CPU - or an APU. The APU provides the on-board graphics output, but I didn't need that, so I bought just a regular CPU without that extra stuff. I was going to use my NVidia GPU instead. I thought I'd plug the card in, plug the CPU in, then boot up and the BIOS would auto-recognize it didn't have an APU, and use the PCIx slot instead where my GPU was... Nope. So there I am - my options being: Buy a different CPU or buy a different motherboard. I couldn't return either of the ones I had because they were long out of the return window. Sigh. What to do? Hmm - well, the motherboard had an empty PCI slot - so I dug thru my pile and found an old 8 meg PCI graphics card. I hoped it would work...and it did! Booted up into the BIOS, changed the defaults to use the PCIx slot for video, then rebooted and all was fine. Had I not had that old video card, I would've been out a couple hundred dollars or more. I keep all kinds of old "junk" - because I never know when I will need it. It's saved my bacon so many times in the past.

VS Code is a standalone editor; it doesn't install .NET, it is not based on .NET. It's actually based on Electron[^], and was originally written as a competitor to Atom[^], which of course was written and released by the team at Github. As you know, Microsoft acquired Github fairly recently - so now (more or less) they are supporting two different Electron-based cross-platform editors (Atom and VS Code). One or the other is likely to die or be merged into the other; my bet is on VS Code being the "winner". VS Code as an editor - just like Atom - can be expanded upon using plug-ins and extensions. But right out of the box, it is geared toward code editing; it has "built-in" support for Git, for instance. But all of this can be extended and expanded to make the editor into virtually a full-fledged IDE. Most of the plug-ins, etc are similar to (or even the same) as the ones available for Atom - though there are a few out there that don't cross eco-systems. Even so, you can usually find one that'll work similar to the other, so if you have a favorite plug-in on Atom, switching to VS Code isn't too much of a headache. So if both editors are so similar - why switch, or why use one over the other? Well - that's only a decision you can make for yourself, but there is one area where (I have found) VS Code shines over Atom: Time to startup. VS Code is simply the fastest. I am not sure why. Basically, if I am editing a text file, I want it up as quickly as possible after clicking on the file to open it. With Atom, I was looking at several seconds; I never timed it, but it felt like an eternity. Once loaded, though, I never experienced any other issues, and opening further files was fast. It was just that initial startup. With VS Code, though - you click on your file, and it is up almost instantly; maybe a 1-2 second lag at most. But that's a really niche use-case; if you have the editor start up when you log in to your system, right off the bat, then it kinda negates the issue. I'm not always editing a file though, and so I don't have anything auto-start (at least at home - at work it's a different story). As far as .NET development - if you need or want a cross-platform dev environment geared to that, then grab a copy of MonoDevelop[

I think what both of you are describing is: Rubber duck debugging - Wikipedia[^] ...it's interesting when it happens, and it happens often; the very act of actively explaining the problem out loud tends to lead you to the solution, without the other person (or rubber duck) having to say a word!

I can't tell you how to fix things, but I can tell you how to make things better going forward:

0. Never do fixes on PROD.
1. When you need to do a fix (unless it's a quick one - even then, consider carefully!), create a new branch off of DEV. Where I work, we give the branch the same name as the JIRA ticket (so if the project is named PROJECT, and the ticket number is 123 - then the branch becomes PROJECT-123); use what works best for your team, but BE CONSISTENT.
2. Do the fix on that branch. Check it in, issue PR, do review, etc.
3. Ideally, it should merge cleanly back in with the DEV branch - but if not, fix your merge conflicts and finish the merge.
4. On a set schedule, merge DEV into PROD.
5. You may want to branch PROD into releases at this point (so every merge from DEV to PROD causes a new "PROD release branch"). This isn't absolutely necessary, of course.

You can of course expand on the above to add in a QA or TEST branch area.

I'm not a git "master" (small pun?) but every place I have worked that has implemented a system like the above, it has been pretty smooth sailing. It won't stop all problems, you might still have "recovery disasters", and it won't bake bread, but it might be better overall in the long run.

YMMV and all that...

I can't tell you how to fix things, but I can tell you how to make things better going forward:

0. Never do fixes on PROD.
1. When you need to do a fix (unless it's a quick one - even then, consider carefully!), create a new branch off of DEV. Where I work, we give the branch the same name as the JIRA ticket (so if the project is named PROJECT, and the ticket number is 123 - then the branch becomes PROJECT-123); use what works best for your team, but BE CONSISTENT.
2. Do the fix on that branch. Check it in, issue PR, do review, etc.
3. Ideally, it should merge cleanly back in with the DEV branch - but if not, fix your merge conflicts and finish the merge.
4. On a set schedule, merge DEV into PROD.
5. You may want to branch PROD into releases at this point (so every merge from DEV to PROD causes a new "PROD release branch"). This isn't absolutely necessary, of course.

You can of course expand on the above to add in a QA or TEST branch area.

I'm not a git "master" (small pun?) but every place I have worked that has implemented a system like the above, it has been pretty smooth sailing. It won't stop all problems, you might still have "recovery disasters", and it won't bake bread, but it might be better overall in the long run.

YMMV and all that...

I can't tell you how to fix things, but I can tell you how to make things better going forward: 0. Never do fixes on PROD. 1. When you need to do a fix (unless it's a quick one - even then, consider carefully!), create a new branch off of DEV. Where I work, we give the branch the same name as the JIRA ticket (so if the project is named PROJECT, and the ticket number is 123 - then the branch becomes PROJECT-123); use what works best for your team, but BE CONSISTENT. 2. Do the fix on that branch. Check it in, issue PR, do review, etc. 3. Ideally, it should merge cleanly back in with the DEV branch - but if not, fix your merge conflicts and finish the merge. 4. On a set schedule, merge DEV into PROD. 5. You may want to branch PROD into releases at this point (so every merge from DEV to PROD causes a new "PROD release branch"). This isn't absolutely necessary, of course. You can of course expand on the above to add in a QA or TEST branch area. I'm not a git "master" (small pun?) but every place I have worked that has implemented a system like the above, it has been pretty smooth sailing. It won't stop all problems, you might still have "recovery disasters", and it won't bake bread, but it might be better overall in the long run. YMMV and all that...

If you're delivering good quality software solutions to business problems in a timely and budget friendly manner, then you are probably a good developer. That said - how do you become a great developer? First - develop your communication skills, both written and verbal. If you can't articulate your questions about the problems at hand, in a manner non-peers (or even peers in software development, for that matter) can understand, you're going to have a tough time delivering solutions. Furthermore, people will question your ability to deliver those solutions, if you can't speak about them in an intelligent and clear manner. So cultivate and nurture your speaking and writing skills. Also, for both, a bit of advice: Think before you speak. Pause, think about your answer or question, then communicate it. Don't just blurt out the first thing that comes to your mind as quickly as possible - some people won't understand it, and in many cases, it will be the wrong thing to say. Second - develop your skills in understanding the business you are creating solutions for. If you don't understand the business, how will you know if the solution is correct for the problem? Furthermore, how will you know if the solution fits the problem at all, or whether there is a more holistic solution at hand - if you don't understand how the parts of the business fit together. Remember, sometimes the best solution to a problem involves the least amount of code. Also, more code means more stuff to break. Always look to simplify the problems and solutions. Third - simple code is better code. It may not be sexy, it may not show "the world" your coding prowess, but it will be maintainable - both by future you, and other programmers who come after you leave. Strive to make your solutions as simple, and to the point as possible. Your goal should be writing less code. Your goal should also be to refactor old code to use less code (assuming you understand why the old code does what it does - which may or may not always be clear - don't ever remove or change code unless you know exactly what it was originally doing). Fourth - don't get hung up frameworks or technologies. If you want to stay marketable, stay flexible: Strive to understand the common principles that underlie those frameworks and technologies. In many cases, most of them are reinventing the wheel - sometimes because of the famous "not invented here" syndrome. Don't succumb to the allure of that syndrome, either (at least with an employer - do what you want on your own time): In

As others have pointed out - and as you surmised - graphical/diagramatical/flow programming isn't anything new, and has been tried in many variations in the past - and present. But don't let that stop you; maybe you'll come up with a new concept or way to get around certain issues all of those have suffered from. Way back at the beginning of Java - before it was popular and widely used - there was a graphical language for it, called (IIRC) "Java Beans" - which had nothing to do with what are today known as "Java Beans"! Basically, various nodes each contained executable code, and parameters and i/o were passed via links between nodes. Another long-lived and widely used system of a similar nature is LabView. Someone else mentioned Simulink. There's also Max - aimed at musicians: Max (software) - Wikipedia[^] Octoblu is in IoT platform by Citrix [^] that has it's own drag-and-drop, connect the nodes, add code, etc - designer software. It's actually pretty amazing (before they were acquired by Citrix, they were a startup here in the Phoenix area hacking on this stuff). So all I can say is have fun with this! And to answer your direct question, yes, there have been similar times for myself - and probably every software developer - where an idea was come up with that was seemingly outlandish or crazy, but needed to be tried. Heck, I would imagine that's how many of the breakthroughs are accomplished. Good luck with your project!