Xml wasn't originally written for web service data transfer or serialization/deserialization. It was written by the W3c to replace Html but still be Html-like. Xml is a Mark-up language, hence it has mark-up. Mark-up makes it good for readability by humans but also a standard readable by machines. Xml was then hi-jacked to be used by SOAP web services with serialization/deserialization. Then someone realized that json was better for serialization/deserialization, especially since readability by both humans and machines wasn't necessary, it only needs to be read by machines. JSON also has room for improvement in verbosity and as soon as a good replacement exists, people will say the same things: why json when new-thing is better.

Won't be hard to take care of the plastic soon. [Plastic Eating bacteria](https://www.sciencealert.com/new-plastic-munching-bacteria-could-fuel-a-recycling-revolution) And I already covered water. There is plenty of that and always will be. Desalinization. Terraforming, creating a pipe or waterway flow to the Dead Sea and Death Valley and other below-sea-level areas. If we piped into Death Valley and back out, we could have a mini-ocean, as big as the Great Salt Lake. The air from the west rises over the Sierra Nevadas and drops all its humidity, and dry air travels over western California, Nevada, Utah, etc. That is why it is a desert. The air is dry and sucks up all the water. With Death Valley filled with water, that dry air would absorb water, and the entire Nevada and Utah deserts would begin to thrive. The rainfall and snowfall would increase in the Rocky Mountains, filling the lakes, rivers, reservoirs, etc. Creating more water for the entire South West with only the effort to build two pipes. More vegetation would grow in the area, which would aid in oxygen. Before we start declaring doomsday, we should have at least tried a few things first. Let wait to declare doomsday until all the coastal cities have desalinization plants and still lack water. As for now, other than building reservoirs, and dabbling in desalinization, what have we tried?

My company uses it for everything and we have a huge organization with code all over the place, including all the code for Mac and Linux and mobile. It is now more tied to Git than to TFS, so it really doesn't matter what you are coding. The web interface works, so you are no longer tied to only using Visual Studio's installed UI. Have the things compile and terraform to linux docker containers with .net core, so cross-platform is a cinch. Management, PMs, Devs, everyone is in it daily.

I laugh anytime I see people calling doomsday on planet earth. Do poeple who think we are destroying earth only live in highly dense cities? Most of the world is unoccupied, there is room to spare. In the US we call them Fly-Over states because there is nothing there and they are largest part of our country. We haven't even started trying to repair earth because it is not broken. There is no evidence it is dying, just warming. The world will change. It constantly changes. Temperatures and weather fluxuates, earthquakes happen, techtonic plates move, etc. We can now desalinize the ocean, but how many cities on the coast are actually doing this? Hardly any. We can pipe oil and gas around the world, but we haven't more than considered piping desalinized ocean water places. We haven't even tried to terraform. What would happen if we terraformed the Sahara desert into a lush green forest? How would that forest affect our atmosphere to have more forest. Lower our carbon ommissions is only part of it. Increasing the plant life is another part. Everything Nasa does will help us here on earth. The best part of trying to inhabit a planet such as the moon is we learn terraforming skills that we can apply to increase vegetation here on earth, thus lowering our carbon footprint. Imagine a 3d printer that is solar powered than can scoop silicates (dirt, sand, etc) from the ground and make an air-tight glass dome for places like the moon or mars. Imagine testing this in the Sahara and creating thousands of miles of glass domes to use a green houses to erase the desert and replace it with green life. We could create waterways to below sea-level zones, allowing ocean to flow in an out, such as the dead sea and death valley, which will add life, add moisture to the surrounding air and increase green life in those areas. What if we gain the technology to mine asteroids while trying to terraform the moon and mars, could we mine oxygen and other healthy air and return it to earth? The next two-hundred years is going to fun to be alive, to bad I'll only get about 50 more years of it.

If you have waited this long, you might as well wait one more year then move entirely off of JavaScript with Blazor. Of course, TypeScript will probably cut out JavaScript, as well, and switch to compile directly to WebAssembly, so you will still be off of JavaScript either way.

I have found the best success in having 1. A non-technical manager 2. A technical lead. The non-technical manager is an HR manager, the time off manager. They can help with sprints, and planning, but not costing, and not how to do something. Has one-on-ones. Keeps team unity. Plans activities. Helps keep communication open (especially with a bunch of introvert engineers) Tech lead - Is the mentor technically. Has technical one-on-ones to make sure each team member is increasing their skill level. The problems with a technical manager is that most engineers: 1. Don't have the skills to be a good manager, because it is hard, and takes a lot of training, and they are never trained. So it takes them three to five years to be any good and by then, they already have a bad rap. 2. Many will never have social skills to be a good manager. 3. As always there are exceptions to the norm. Great technical managers and great non-technical managers exist. But on average, I find the best harmony when a non-technical manager is combined with a tech lead.

Content creator. Is is an independent gig. It is not a job you get hired for, it is just a job you do. Like a author. Setup an account at to resell his content on Daz3d and Unity3d and start creating 3d content that he sells and gets a piece of. If he creates resellable 3d content for four years instead of going to college he will be better at 3d content creation than college could make him and have a massive portfolio and will make money instead of spend money (college isn't cheap). I would argue he is not skipping an education but choosing and alternate self-educating route. Add in custom content creation for a custom price and he will have a viable company.

How is this different from mail-in voting. With mail-in voting, you can have an overpowering partner standing over you forcing you to vote in a way you don't like. However, with online voting, using video for authenticaion, such as facial recognition and/or retina scanner, you could also require that the voter is alone in a room and require a quick panorama or the room to prove no one is there coerce you. Sure, one could "hack" the panorama but that is a lot harder compared to the options you have for protecting mail-in voting.

Security gets better, but the attack surface gets bigger. With voting on paper, your paper can be swapped out easily by unscrupulous vote counters. With voting on machines, the software could be tampered with, even post compile. I am for online voting if it requires multi-factor authentication, including facial recognition or retina scan, State Id (such as driver's license), social security number, etc. The misconception of online voting is that everyone has to do online. No. To start out, all the normal voting processes, such as paper or voting booths, still exists. However, to register online, you have to go to the DMV with your two forms of Id and register to vote, get facial recognition scanned, or retina scan or something etc. So anyone with a phone/pc with a camera, and a willingness to share their face or retina with the system can vote easily online. They log in. The camera scans both sides of the drivers license. The facial recognition or retinal scanner verifies who they are. Yes, retina scanner might be better cause if your looks have drastically changed (weight loss, beard, whatever) it might not work. But secure? It is pretty difficult to mimic both a valid drivers license, and facial or retina scan. Sure any one person could do it, but to do it in mass enough to affect an election is not likely. While not 100% secure, I would argue it is more secure than a pencil and a paper or a disconnected machine that could be tampered with.

Sorry, guys. I clicked "Reply" to the guy who posted about his visual drag'n drop programming language. I'm not sure how it ended up as a new post, although I remember being interrupted by a meeting and afterward the submit erroring out.

This is not new, however, while others have created a solution, few followed through on continual improvements. I also don't know of a good C# tool like this. I believe there were barriers to using this in the past, but many of those barriers are going away. Also, with kids learning to code with Blockly, future generations might be into accepting this. I believe this is the generation for this market to accept this.

Dropping Silverlight was a huge mistake. The adoption was crazy being it wasn't cross platform. Microsoft should reverse course here.

For this very reason, I am so happy with the GitHub era. Recently, when I have needed a library, I have found via NuGet and it's source was on GitHub. On a few occasions the library might be buggy. If it is on GitHub, I fork it, fix it, request a pull request. If they don't pull my change, no matter, because I have my own GitHub repo. I can move on with life.

I use WCF services for json web services with Rest and a simplistic ODATA response syntax. WCF Services are very easy to create. Fast and feature rich. I put a separate service in each dll. One primary project that rolls them up. Marc is right on to suggest you have layers and unit tests for each. You can use any database, by the way, not just EF with MS SQL. For the front end, it is all html/css/JavaScript getting data via rest calls. Also, if you research the ODATA standard, you will see this is the way to go. It is very easy to do. I find mixing front end and backend fine (ASP.NET MVC) but I prefer an architecture that does not mix them. I prefer the simplicity of knockout over the massive angular frameworks, and as you are not big on a SPA, then I would recommend it. However, angular with a SPA does provide a very good experience, if bloated. Architecture [ UI ]-- [ JS MVVM ] -- [ JS Service layer (ajax) ] -- [WCF Message inspector ] -- [ WCF Service call] -- [ Command Manager ] -- [ Repository ]

JavaScript is a terrible language and you have plenty of justification to hate it. It is only used because it is the only option on browsers. If another existing language was suddenly supported by all browsers today, it would probably take over JavaScript quickly. JavaScript is so terrible, many developers prefer not to code in it. Many are creating new languages such as CoffeeScript, TypeScript, etc., that compile to JavaScript. Many are writing compilers for known languages (python, C#, etc.) that compile to JavaScript. Even the most popular JavaScript libraries (Angular) are written in TypeScript, not JavaScript, and those libraries recommend that we do the same.

And we can all breath a sigh of relief. JSON is awesome for the things that it is awesome for. A config file that both humans and computers have to read is not one of those things.

Well, yes. I do happen to blog. Here is a 6 part series (using a Basic Authentication Token Service) that shows how to do JSON enabled web services. By part 3 you get the message inspector. Then in Part 6 you actually get an html/javascript client. [Authentication Token Service for WCF Services (Part 1)](http://www.rhyous.com/2015/02/05/basic-token-service-for-wcf-services-part-1)

Alive and growing. We are just switching to it for our JSON communication and love it. The configuration is pretty easy now. Used to be harder but now it is simpler. It also has cool AOP features, such as that ability to manipulate all packets before the WCF service even sees it with a message inspector. SignalR might be simpler at first glance, but does it have such AOP features? Can I authenticate all web services in one piece of code without adding a single line of code in each of my services? The feature set of WCF is huge and pretty much blows away anything else on the market.

In a big company you have to 1. Learn how to interact with different teams 2. Learn the policies 3. Learn your boundaries with your boss and many coworkers 4. Do you job well 5. Be careful not to step outside of your job responsibilities without permission. 6. Unless you are specifically hired to do exactly what you want to do, you struggle to find time to do what you want to do. 7. An extra side project that benefits the company is often a reason demote you as it shows you aren't focused on your current job. Unless you have permission. See #5. 8. You usually work 40 hours a week. 9. There is very little company recognition. In a small company you have to: 1. Learn how to interact with different people 2. Learn the politics 3. Learn your boundaries with your boss and your few coworkers 4. Do you job well 5. Be willing to step outside of your job responsibilities when needed as you be asked to do so often. 6. Unless you are specifically hired to do exactly what you want to do, you struggle to find time to do what you want to do. 7. An extra side project that benefits the company is often highly praised and heralded for years. 8. You usually work 45+ hours a week. 9. There is quite a lot of company-wide recognition for jobs well done.

It is on my list of required changes when setting up any pc. If you are just a home user, do it manually. If you are in an IT department, make it part of your image or a setting as part of your OS Deployment process.