|
> OAM is a specification for describing applications so that the application description is separated from the details of how the application is deployed onto and managed by the infrastructure.
Wow. So it's a description for describing descriptions that have no information on deploying and managing the application.
Is there a YouTube video I can watch instead? 
|
|
|
|
|
Cybercriminals have multiple markets to get illicit goods and prices on these underground forums are likely driven by supply and demand, just like in the legal economy. So, I'm not worthless?
|
|
|
|
|
Kent Sharkey wrote: I'm not worthless?
Don't get confused... you are worth the same... it is your data what has value for them  
But for what is worth... you are very valuable for us. Life would be a bit more boring without your news and comments  
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.
|
|
|
|
|
Not totally worthless.
You contain a few liters of water, a few kilograms of common organics, and a few kilograms of even more common inorganics. I'd set your value at $4.99 (Canadian dollars, that is). 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
My credit is so bad that I get sent a bill when someone steals my identity
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
Gilbert Levin, a NASA engineer who worked on the Viking missions, says he’s “convinced we found evidence of life of Mars in the 1970s.” "Oh man, wonder if he'll ever know, he's in the best selling show"
|
|
|
|
|
Note that extraordinary claims require extraordinary proof.
The Viking landers did find signs of life, but the results were ambiguous. Of the four separate experiments designed to detect life or disprove its presence, one (Labeled Release, or LR) was a strong positive, one (Gas Chromatography/Mass Spectrometer) was a strong negative.
In 1980-81, I was a lab assistant on a NASA-sponsored project that tried to see if the LR results could be produced in other ways. To summarize and simplify, we discovered that finely-ground clay, with no organic matter whatsoever, could cause a similar release of CO2. Given that Mars has regular dust storms that would create such finely-ground particles, this introduced enough "reasonable doubt" that they could not say that life had been discovered.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: The Viking landers did find signs of life, but the results were ambiguous.
Well they did first visit the north of England...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Mars was not called the red planet because of Eric the Red. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Novel algorithms are secure like blockchains, but simpler, faster, and more energy-efficient Is it just a linked list?
|
|
|
|
|
I thought Bitcoin Mining was going to be the new heating for the house of the future... 
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.
|
|
|
|
|
“BriansClub,” one of the largest underground stores for buying stolen credit card data, has itself been hacked. "There's no honor among thieves."
Seems a pretty big, "good news/bad news" situation, but I guess more good news?
|
|
|
|
|
Finding #3: Developers spend more time maintaining, testing and securing existing code than they do writing or improving code. "You need not wonder why there's no time left for you"
|
|
|
|
|
Thanks God they didn't consider CP in that list... ![Jig | [Dance]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/jig.gif)
we are safe (for now  )
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.
|
|
|
|
|
Writing new code - most of the time, we can't write new code because management can't "quantify a business need", unless and until they realize that the current code stack is a steaming pile of crap.
Improving existing code - 95% of the time, optimization results in errors because the improvement didn't account for subtle (and cumultaive) side-effects. Side effects occur because they architecture isn't designed/implemented properly (concerns that were separated have reconciled and are living like hippies in a commune, intermixing and interbreeding to produce the hell spawn that is your existing code base).
Fixing bugs (maintenance) - any semi-significant change to an app that deviates from the original intent/design is guaranteed to break something. This is a direct side effect of "writing new code" or "improving existing code.
As the code quality degrades, the time spent in meetings increases. When a project first starts, you may have a weekly 15 minute status meeting. Once it's deployed, you have 1-2 hour meetings every day, discussing the problems (because testing was not thorough enough) or your "code improvements" went sideways on you.
Security issues arise because some assh*le in some 3rd world shith*le has discovered an obscure exploit that makes the security nazis go into a frenzy of "omg! are we doing this? omg!". The result is that someone higher up decides you need to take "proactive steps" to prevent "security issues", and plunks down a crapload of cash for apps like Fortify. Using Fortify takes time away from devs because they have to write memos and attend meetings defending their code and explaining why the Fortify scan is full of sh|t.
After more than 40 years as a dev, all this crap is pretty obvious to me, and I don't need some snot-nosed kid to conduct a pointless survey to illustrate why devs don't spend enough time writing code. The truth is that they're piling on non-dev tasks and concerns (DevOps), and we don't have the f*ckin time to write code. And don't get me started on employee retention.
".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
modified 16-Oct-19 8:16am.
|
|
|
|
|
You do know that there's a "Rant" button, right?
It's difficult to rewrite software because the cost of doing so has to be recovered over the product's remaining lifetime. Its lifetime might be extended by rewriting it, but it's difficult to prove this to management. If the existing code isn't too hopeless, it may be possible to improve it through refactoring rather than totally rewriting it.
Customers also want new functionality, so the product will require two teams: the first one to support the existing software and add the critical features that customers demand, and the second one to do the rewrite. The second team will also have to catch up to what the first team manages to add.
The team rewriting the software may also have no adequate product specification from which to work. They will then inadvertently change some of the product's behavior, resulting in customer complaints when it eventually rolls out.
How much will the rewrite improve quality and time to market? The organization already created one mess, so what will prevent the rewrite from becoming a second one? The culture and process may need to change, and there must be a visionary (or a few of them) with a clear idea of what the design should be, with the ability to keep it on track.
All of these issues make rewrites challenging, which is why so many of them fail. Before embarking on a rewrite, a team needs to have a good idea as to how it will address these issues.
|
|
|
|
|
After I left a company they decided to rewrite one of my programs that was the primary product bringing in millions in software lease dollars. I had worked on it for seven years, with occasional contributions from other developers who came and went, with myself always in control. Another developer had started it and left to do more fun things like writing video codecs. He helped me through the first couple of months unofficially because he was a friend of mine - and proud of what he had started.
It was an extremely complex C++ (and some assembler) automation platform with multiple mainframe and other console emulations, a Rexx control language built-in, and lots of other bits and bobs (telephone interaction support, stuff like that). It could talk to most devices in some way, often via RS-232, TCP/IP and similar. It was pretty comprehensive because it had been built based almost entirely on customer feedback.
They eventually had a team of six new developers and one consultant who had worked on the original code (who's updates had constantly to be corrected) working on it. In the meantime the customers kept using my "old, obsolete" version quite happily because it worked, worked fast, did everything they wanted and had a UI that made sense.
The new team spent most of a year developing a "new, improved, more aesthetically pleasing" UI and deciding to use Java to implement it.
Into the second year they were able to start testing some components of it. They spent months setting up appropriate testing environments, even writing a brain-dead "mainframe simulator" to allow them to generate stuff to test against. They had lots of fun! After another year or so they had all (except the consultant) left and been replaced once or twice because they couldn't get any of it to work, either at at the necessary speed to be properly responsive or just to work at all! The consultant was still there because he was the company president's part-time lover - or love-child - we could never quite work out which and anyone who asked about him got fired.
After nearly four years the rewrite project was dropped. The company went in a different direction with other (less successful) products but still kept my "old, obsolete" program (unchanged after several years) which continued to bring in 90% of the company's income! 
I spoke to the director of sales the other day and he is still bringing in the occasional new client for my program - this is nearly seventeen years after I left! We lost a few clients but some of the bigger ones are still using it to automate their data-centers.
Rewrites aren't always a good idea.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I'm working on code that is seven years old, and was written with now long-outdated libraries (for instance, Kendo UI when it was still free), using ASP.Net. Part of the problem is that someone in the distant past thought it would be a good idea to combine kendo ui and jquery into a single MINIFIED code file. This means that we cannot update either the Kendo stuff OR jquery, without possibly causing massive side effects, because...
This composite file is used across more than a dozen (web) apps. If we try to update ANYTHING in this file, we would descend into regression testing hell - so we leave it the hell alone, and simply deal with the fact that we're using a severely outdated version of jquery (and Kendo).
The backend is even more exciting - the original sql was developed with SQL 2005, and some of the tables have sql code in the columns, and one table has over 120 columns that are added to when necessary (which happens every few months). We have a job that runs a stored proc which itself runs stored procs defined in a table. This makes deployments exciting because we have to update that table's data quite often.
To add to the fun, we use a home-grown DAL via windows services installed on the web server. The team lead wants to get rid of this mechanism because it adds complexity to the apps, and to deployment of those apps.
The flagship app has been worked on over the last seven years by over a dozen different contractors who never bothered to ask if code was already available/written that they could use in the common assemblies, and as a result came up with their own "solutions", and cowboy code is evident throughout the code base.
Finally, after seven years of experience, we know what kind of changes we will be making, and where, so we can now redesign the back-end (that's where 95% of our changes are made) to be more efficient and maintainable.
A rewrite is necessary *for every app*. That is not an exageration.
To that end, I developed (on my own time) a MVC5 project template that takes care of most of the minutia that most/all of our apps deal with, makes deployments simpler, and uses the latest versions of various libraries. I've also created tools to go along with it that help the lift-and-shift processes faster/easier to deal with. It's all right there, ready to be put to use when the team lead says "go".
---
Rewrites can be executed with a solid, dedicated team of devs that are already familiar with the legacy system and are willing to put in the extra hours, despite what management dictates or pays for. A properly designed and managed architecture makes refactoring a simpler process when it needs to happen. It can be done, and it can be done cost-effectively. If the rewrite is a success, management can (and should) award the team with bonuses and/or time off as performance-driven compensation, especially if the team spent personal time working on the product. In other words, trust and support the developers. They're the reason the company is making money.
".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
|
|
|
|
|
#realJSOP wrote: I'm working on code that is seven years old, and was written with now long-outdated libraries (for instance, Kendo UI when it was still free), using ASP.Net. Part of the problem is that someone in the distant past thought it would be a good idea to combine kendo ui and jquery into a single MINIFIED code file. This means that we cannot update either the Kendo stuff OR jquery, without possibly causing massive side effects, because...
This composite file is used across more than a dozen (web) apps. If we try to update ANYTHING in this file, we would descend into regression testing hell - so we leave it the hell alone, and simply deal with the fact that we're using a severely outdated version of jquery (and Kendo).
I think I'm missing something here. If the problem is that CombinedWtf.js is used in too many applications that would need test/updated simultaneously if anything was changed, why can't you update sites individually replacing the combined file with the legacy versions of all of its components, and then update them one at a time on the individual sites to keep the testing load under control?
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
It's due to our deployment process (which I am not entirely privvy to). All of the apps use the same file, so if we change that file, all apps have to be regression tested. We have neither the time, nor the manpower to do so.
In the new project template, we eliminate the dependency on the monolithic file, and each app is responsible for its own jquery/Telerik use, allowing us to update one app without affecting all the other ones. We all realize that it's a giant duplication of code, but that's a trade-off we're willing to absorb in the interest of not breaking everyone else's app when someone needs a new version of jquery (or telerik).
Finally, our flagship app is HUGE, and regression testing that app would take at least two weeks all on its own. And that's just testing for the developers. The testers would take at least that long, and probably longer.
".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
|
|
|
|
|
.NET Core 3.1 will be a small release focused on key improvements in Blazor and Windows desktop, the two big additions in .NET Core 3.0. It will be a long term support (LTS) release with an expected final ship date of December 2019. Because it's been weeks since you had a new version to play with
|
|
|
|
|
I suppose they use the same team to update .Net Core as per to update Windows...
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.
|
|
|
|
|
Program Manager Immo Landwerth made the announcement in the form of an issue on GitHub (where else?) and stated that the gang had reached the point where it reckoned that everything needed for "modern workloads" had been ported. Sad news for those Windows Workflow apps you wanted to migrate
I'd add "both of them" to that, but I really wonder if there are two out there.
|
|
|
|
|
So where is the list of stuff NOT ported to .Net Core?!
".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
|
|
|
|
|
#realJSOP wrote: So where is the list of stuff NOT ported to .Net Core?!
For headline library type items:
The Register: Web Forms, WCF sever and Windows Workflow,
Outside of those; the two I'm aware of are AppDomains, and the .net 1.x non-generic collection classes. (Which for anyone unable to update to fully typed collections for some reason could at least be patched around easily enough with List<object>, etc.)
The newer version of C++.Net just got added to the being ported list a few weeks ago; which makes me suspect that the first version is also on the regarded as dead and never to be ported list.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
