|
What, exactly, are "engineer leads"?
And why should developers even worry about what engineers think?
I've never liked the "DevOps" category. the two disciplines, "dev" and "ops", should never have been combined.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
A new report from Netwrix shows that cybersecurity risks related to insiders are now more common than external threat actors. More proof you need to keep users off your system
|
|
|
|
|
Kent Sharkey wrote: More proof you need to keep users off your system Or your devs happy
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
"four of the top six types of cybersecurity incidents they experienced have been caused by internal users. These are: accidental mistakes by admins (27 percent), accidental improper sharing of data by employees (26 percent), misconfiguration of cloud services (16 percent) and data theft by employees (14 percent)."
0) Mistakes by admins, 27% - Well, there's your problem. Hire better admins, and not only will that mitigate that problem, but it will also resolve a significant portion of the other 3...
1) improper sharing of data by employees, 26% - that would have happened in the office too. There is no end to the amount of stupid that comes from end users.
2) mis-configuration of cloud services, 16% - this is intentionally skimping on available services to save a butt-load of money. This isn't "mis-configuration" - it's "comprimise".
3) data theft by employees, 14% - once again, hiring better admins will mitigate this, but the REAL problem is that "management" doesn't think security rules should apply to them, so they create holes in the security system (to accommodate management) that have the nasty side effect of allowing intrusion and exploitation.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
he goal of the “busy beaver” game is to find the longest-running computer program. Its pursuit has surprising connections to some of the most profound questions and concepts in mathematics. So that explains Windows' search program
|
|
|
|
|
|
I've created infinite loops many times, and a former manager created an infinite messaging loop between two entities, which was discovered in the field for a high availability product.
I could also comment on the term busy beaver but will exercise restraint.
|
|
|
|
|
The regulator criticised the firms for not getting consent before placing the trackers Anyone misusing cookies deserves to have the book thrown at them
A cookbook, of course.
|
|
|
|
|
There were night clubs in Spain braking some laws and everytime the police came and sued them, they laughed their asses off, because the fine was not even a 10% of what they additionally earned in one night not following the rules...
In other words:
€135M ??? That's peanuts to them...
They should get 50% of a month revenue, then... it might even call their attention.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Are you going to be writing code anytime soon in assembly? Maybe not, as it has very niche use cases. Because you never know when you might have to debug the machine code for a website
|
|
|
|
|
I wouldn't say it should be a must, but I do think it would help a bit.
I have been many years programming PLCs in something similar to assembly and the PLCs did have limited resources (current ones not that limited though). My senior says, I again and again blown his mind off because I find simpler ways to do things he would have never thought of.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Me too. My first job out of school was programming PLCs and I couldn't stand it so I branched out. Back then, PLCs didn't have descriptive tags and labels for registers. Everything was a number so you had to keep a notebook of what all your registers did. It was a serious PITA.
I school I had a few courses that used microcontrollers in the labs so we worked with their assemblers. 8051s and 8048s and a few others. Intel was close by so we had bunch of their development equipment. Fun stuff.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
|
I started working on Allen Bradley 2/30 and Modicon 584s. Later, when I was writing comm drivers to talk with PLCs, Siemens PLCs became my second least favorites to deal with. Allen Bradleys are my least favorite now. I like PLCs with very simple protocols like GE, Omron, and Modbus.
Here's something kind of funny. At my previous company we worked on systems that weren't very fast and we could get by with fairly slow scan times so we removed nearly all logic from the PLC and did it in the computer. The PLC became a smart I/O device. This allowed us to have portable control logic that could work with any I/O. We ended up doing retrofits on systems with a bunch of different types of PLCs and I wrote the drivers for almost all of them - we found some freeware for a Step-7 driver.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Interesting
In my case it was more like...
Phase 1: C++, Borland C++ Builder, VC++ 6,
Phase 2: Step 5, Protool, iFIX (SCADA), Step 7, Win CC Flex, Kawasaki Robots, Reis Robotics, Kuka, Allen Bradley...
Phase 3: BuR, TIA Portal, C#, Back to C++ ...
Biggest was Phase 2 up to now. Interactions with PC in several ways, all kind of peripherical systems... Most of the times my sps was the master and did / coordinated everything.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 11-Dec-20 19:43pm.
|
|
|
|
|
I have worked with many robots too but I never actually programmed one. I have always done the communication part or interfaces and often the coordination. Fun stuff. For a while I worked at a company that made robots - Intelledex.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Rick York wrote: I have worked with many robots too but I never actually programmed one. I have always done the communication part or interfaces and often the coordination. Fun stuff. Using them could be interesting and big fun too, but one must be very careful, once they "go", they can be pretty dangerous, so if the programmer is not experienced, better take cover when testing starts.
Trying to optimize the paths to win some milliseconds (or even seconds) per cycle was really challenging in some of the projects I worked.
When time is not that important, then it might very comfortable and one can concentrate in doing parametrizable programs to reduce complexity and improve maintenace comfort.
Rick York wrote: For a while I worked at a company that made robots - Intelledex. Never seen them. I didn't even knew that name.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
With the year's Visual Studio release train coming to an end with the new VS 2019 v16.9 Preview 2, I took a look at Microsoft's Developer Community site to see what top feature requests have been filed to perhaps peek at what's in store for next year. I thought they were all still stuck in vi?
Or maybe that's the problem - they can't get out, so they need VS to edit their files?
|
|
|
|
|
CLion is pretty good.
That said, Visual Studio is amazing and has a kick ass debugger.
|
|
|
|
|
vi. It's remarkable what people put up with.
|
|
|
|
|
Suffering leads to purity (or something - I never understood the attachment myself)
TTFN - Kent
|
|
|
|
|
Kent Sharkey wrote: Suffering leads to purity
I believe it was 'salvation.' But in the case of vi, suffering leads to pleas of 'Save Me!' (At least for those who aren't masochists.)
|
|
|
|
|
That's why I switched to vim years ago
|
|
|
|
|
I must keep it in mind if I start using Linux. I had to look it up, and it looks good. Originally developed on an Amiga, no less! I had one and still remember it fondly.
|
|
|
|
|
Visual Studio will never run on Linux unless they port WPF over to Linux, which will never happen (at least, not from Microsoft).
Look at WINE. VS used to run in Wine, until they moved to WPF (2010), and then it went to hell in a handbasket. WPF uses DirectX, and that doesn't live on Linux.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|