I have one that's about 4 years old, and I love it. Expect to make a lot (and I mean a lot) of mistakes. You'll have prints fail for no apparent reason, and gravity is a thing that must be respected. Learn about how the printer actually works. Unlike a normal printer, you will probably have to pull the print head apart and re-build it multiple times, especially as parts wear out. I use OpenSCAD to create my files. They export into STL's which I then load into the FlashForge slicer program. I then set up any supports, chose the extruder to use (I have a dual head, so I can print two filaments at once, I use it to create panels with clear plastic sections for back lit designs), and press the "make it so" button. I've only downloaded a couple of things from thingyverse, I mostly make my own designs. Prints can take anywhere from 5 minutes to 24 hours to run through, depending on the size, the quality and the complexity, although the software I have can usually guess within a few minutes how long the print will actually take. I also tend to slice larger designs by using cut outs and other guides to help me line up multiple pieces. It's surprisingly difficult to get two pieces of a single 3d print to line up nicely if you've simply slice a model in two. Read reviews, work out what you want to use it for, since different printers will have different dimensions, and little point getting a large printer to only print out 1 inch / 2cm figurines. Good luck

Member 14840496 wrote:

But since pair programming IS part of Agile, not practicing it means that one is not doing pure Agile.

Pure "Agile", there is a laugh. So many flavors, so many opinions on what Agile is you can do almost anything and call it "Agile"

It only works because the senders are using white tracking pixels. Do an invisible tracking pixel (aka a png with zero alpha channel) I strongly suspect light or dark mode, you won't see the tracking pixel. The safest way is to simply block all images from downloading without permission, and then assume that if you give the images permission to download, then the other side knows you've read the email.

I agree 100%, having seen the damage done to IT by Bean Counters. I once worked in an organization where the Bean Counters refused to replace a faulty air-conditioner in our server room. Their argument was it would cost $100,000 to do, and no amount of logic or reason could convince them to release the money. Here is the kicker, after the inevitable outage whereby some of our servers literally cooked themselves, which cost the company $250,000 in lost hardware and productivity (and that was just an afternoon), the Bean Counters still refused to release money to fix the air-conditioning because we'd just lost $250,000 and they didn't want to add another $100,000 on top. The real ironic thing was this was in an IT company. Perhaps the weirdest thing was I was at a party about 6 months later, and I was talking to a Bean Counter (not in our company) about what happened, and he was justifying that the way our Bean Counters had approached things was correct, and yet his justifications had no concept of the real world.

I've also seen enough var x = 1; var y = 2; var z = 3; type code in methods to know that single letter / acronym variable names can be bad, especially that method has grown a little too big. Whilst variable names should never be war and piece, they should be somewhat descriptive enough so that as a developer you know what values you're likely to see in there, and how they should be used. That said, I'll happily use for (var i = 0; i < 10; i++) {} without thinking twice, so you know I'm not 100% dedicated to the no small variable names cause.

We have a rule, if an acronym is well known, then we use it (eg url rather than universal resource locator), otherwise we spell out the full words. A few years ago we where working on a system which had a limitation on some names, but we needed those names to be descriptive of the keys. We ended up with a jumble of 3 letter acronyms everywhere. Sure enough, the parts we touched frequently where easy enough to deal with, but gee looking at some of the sections which remained fairly static was a nightmare to determine what was going on and what held what data.

They have implemented SSL inspection on their Firewall (or Proxy). Basically the connection is secure between the website you're visiting and their edge device but they failed to provide you with a copy of the root certificate used by their edge device. Once you have the root certificate (and you actually trust the customers IT) then you'll cease getting that warning. At the same time however they have effectively man-in-the-middle attacked your connection, so what goes through that connection is a secret between you, the website your visiting, and your customer. Be wary of doing anything you'd actually want security for (eg Internet Banking).

I've had many an argument against "tech enthusiasts" about how useless VPN's truly are at protecting your data. People seem to think that they are a magic block everything bad technology, rather than simply redirecting a pipe through someone else's server first technology. So yes, I've certainly seen lots of "False advertising" from VPN providers. Side Note: Only twice I've seen a useful use for a VPN: 1. Get Netflix content from other countries 2. Getting internet access from the wrong side of the Great Firewall of China.

How quickly do you want to make this change, and how much effort are you willing to do? It might be an idea to get yourself involved in some medium to high profile open source projects first before attempting to turn it into a job. Being knowledgeable in an open source product is likely to open more doors than simply saying "I've done a C# boot camp". To be honest, the code itself is easy enough to learn (if you've got the right mindset), the difficulty is never explaining what 'var i = 1;' done. The difficulty comes from trying to get a person into a coding mindset which works well with others (rarely are projects done in total isolation). As for choice of language, look at the job boards and determine what people are hiring. Talk to those in the industry in your area. Just because C# / Java / "insert cool language here" is popular on a world wide scale, doesn't mean that "insert legacy language here" isn't the language of choice in your city. Finally, are you really sure you want to be a programmer? The IT industry has our fair share of boring soul crushing jobs just ready to put a warm body into for 6 months. You might not find the grass as green over here as you first hoped. Whilst my first job was interesting (and I was lucky to fall into that job) it took me a good 4 years to move into something that was both interesting and paid a half decent amount. Whilst I don't know your age (extrapolating from what you've said, I'd guess early 50's at the youngest) you may find that you don't hit any of the really interesting jobs before it's time to retire. As others have said, ageism is rife in the industry and you may find that doors are closed even after you've put in the work to get into the industry.

1. Have an agenda and stick to it. 2. Be ready to say "let's take this off-line". 3. Document everything, and send around meeting notes. a. If done right, this may have even stopped your boss from wanting to sit in in the first place. 4. Finally be open to listening what your boss wants, and don't forget that they are the boss. Be prepared, that last point is probably going to be the hardest one for you to follow. You made mention that the is more management than programming, the fact is the best programmers not only have good technical skills, they also have good soft skills such as managing people, and that goes both ways.

I use OpenSCAD, it's a coding like language for creating 3d objects. As a software developer by day, I find it rather easy, simply because I understand methods, loops, if's and objects. To give you an idea of the language, something like this: for(i = [0:9]) { translate([i * 10,0,0]) cylinder(d = 5, h = 50, $fn=50); } would give you 10 identical 5mm wide by 50mm high cylinders, at 10mm distance apart on the x axis. It can generate stl files for passing to the slicer. I have yet to have a problem with the slicer thinking the internals of any object is empty, and I have no problem in overlapping objects (I commonly place objects 0.1mm inside each other). I also like that I can split complex parts into their own modules (methods) and then preview the entire printed object inside openscad, then print off each section by itself. I've found I've been able to do joins between components far better and more accurately than by simply slicing a model into two using the slicer. To make things easier, there is also a community of people who design parts inside OpenSCAD. From simple libraries like a triangles library, to more complex libraries like gears, which can all be downloaded for free as well. As for what I'm doing with the pieces I print, well I'm building a full sized functioning jumbo jet (boeing 747-400) simulator. I'm printing panels, controls, buttons and switches (the sort that you can't just get at your local electronics stores), and every piece has been designed with OpenSCAD.

Salting is something different. The issue is that without salting (aka adding some random data into the password), then it's very easy to reverse hashed but not salted passwords back to plain text using things like rainbow tables. It also stands out if anyone gets hold of the password hashes if default passwords have been used. For example if you see every third account stating it's password is "B2E98AD6F6EB8508DD6A14CFA704BAD7F05F6FB1" it doesn't take long to realise that every user have all entered the same password. In this case Password123. If you want to see a rainbow table in action, do a google search for it, and enter in the above hash and you'll see what I mean. (I won't provide a link, because like all cracking websites, I would suggest being very careful using it, and I'm not willing to post a URL that turns out to be bad). As far as I know, salts can be stored safely with the hash (although I'm all ears if a security person wants to tell me otherwise). Edit - just to answer the actual question: yes, collisions are still technically possible with salted hashes. But again it's not if a collision is technically possible, but rather is there a known way you can cause a collision with two different piece of data.

H.Brydon wrote:

If the hash is shorter than a "really long" password such as yours, then there will be guaranteed collisions

Yeah, this is not a concern. The issue with collisions has to do with can you force a collision. So for instance, it's possible to create two completely different PDF documents, both which come up with the same MD5 hash. Obviously this is a problem if using an SSL certificate. But a password, hashed with a current secure hash, you've got as much chance of finding a valid collision with "Password" as you do with "GuessThisReallyLongPassword".

Kirk 10389821 wrote:

For the record, this should have been designed INTO the product in the first place, in general. Nobody should have to remember "codes"

You've obviously never worked on some of the old mainframe systems. When your paying big dollars per KB, you're not going to waste it by putting in "helper" type messages when a piece of printed paper with values for lookup codes will do. Many of the "codes" we see in modern systems are often a legacy from the time when every bit was precious.

Whilst I don't disagree with you re:CSS, in that example you've given it could be easily achieved using JS / jQuery. It's simply a case of picking the right language for the job. Of course as others have picked up on, doing that might cause all sorts of strange behavior once you start looking at the various sizes of screens your page may show up on, from 1 inch watches to 100 inch projectors. You just can not be sure of the scale your user will be using.

Ah, yes, I can relate to that sort of silliness.

Whilst I can understand there may be restrictions on simply downloading (or worse simply referencing an external 3rd party site), surely there is a mechanism to obtain an external library under controlled circumstances? Personally I see it no different than choosing a piece of off-the-shelf software. Go through the standard checks you would do before deploying any other 3rd party piece of software and you'd be fine. I've written parsers in the past (albeit XML). I spent weeks accounting for our specific use case scenario, it wasn't even fully featured. All it would take was the external source of the XML to decide to implement something that my parser hadn't included and the system would have fallen over. So I would be going to your higher-ups with the following three arguments. 1. A custom JSON parser is likely to take weeks to develop and test 2. A custom JSON parser has potential to not correctly implement the full set of JSON rules, thus would be a risk to the project. 3. Evaluating JSON parser options for suitability and security would be a quicker, cheaper, and potentially more secure option than attempting to build your own parser (since it's is possible to embed executable code into JSON)

Mircea Neacsu wrote:

Same applies to programmers and specially to 10x ones: by the time you are 40 you start becoming a 5x, 3x,.. 0.1x :)

Speak for yourself. It's attitude, not age that defines a career. Young people tend to be vibrant, know every modern framework, and open to new idea's, however they are missing the business knowledge, the "why" things are done in a certain way. I've lost count of the number of "up and comers" who are ready to "change the world" who get knocked back within their first year because whilst they knew the technologies, they didn't understand the business need. If you want to continue having a "10x career" after you're no longer young and vibrant, make sure you have that business knowledge as well as the technical, plus the right attitude.

Microsoft was offering "no code database development" in Visual Basic 3, and that was released in 1993. It's true, using VB3 you could build a database system by doing nothing more than dragging and dropping controls onto a form and clicking the property showing where you'd like to source the data from. Yet here we are, 27 years later, and I'm continuing to have a good career as a software developer specializing in databases. No code systems will continue to exist, they will continue be used by "Power users" who all have varying degree of skill, and they will continue to be the bane of the real IT professional who is asked to come up and fix the mistakes of the "Power user", usually after data is lost or a business critical limitation is reached.

Yes, the 1000 year disc, or so the manufacturer says. I would be skeptical on that sort of longevity outside of archival conditions. (I'm skeptical on that number even in archival conditions, especially as they invoked "trade secrets") Keep in mind that proper archives store things inside carefully temperature and humidity control rooms as well as been very rarely disturbed, things that people who throw disks into desk draws / filing cabinets are usually lacking. No doubt, the manufacturer will be quoting 1000 years based on perfect archival conditions. Personally I would be trusting an actual archive to tell me about long term storage than manufacturers claims when trying to sell consumer grade technology.