I find that if I have to put too much parametric data in my GET implementation for some particular endpoint/route, it's usually because I'm trying to do too much with that that method. For example, I have to work with an old system that has a non-standard API where the read methods often require eight or nine parameters where half of those parameters are complex types with a dozen properties each, many of which are collections. It's not a RESTful, web-based API, just a .NET library, but it's simply because of rather than coming up with many simple methods, they use a few methods that have virtually countless option combinations. The point being is that the S in SOLID can help by just keeping API endpoints simple in that they have one job. Besides, how do you get the same endpoint/route to handle two different jobs for the same verb? With some option flag as an extra parameter or data in the post body? Sounds unnecessarily complex. Besides, if we want an API that doesn't require tight guidelines and has a built in metadata exchange endpoint, let's use SOAP.

I think it was about the same time that we became "Entrepreneurs" rather than "Unemployed". also: https://2l90qdgid4-flywheel.netdna-ssl.com/wp-content/uploads/2017/11/linkedin2.jpg[^]

I programmed in a new language called C# almost twenty years ago when it first came out. I don't miss it though. I still use it nearly every day.

Now this person watches The Twilight Zone.

Perhaps you're confusing the terms nature and science. Nature, specifically how the natural universe works, never changes, but science, how we perceive and model it, changes constantly including how we use models that might be in disagreement to each other but work within their respective contexts. Even so, what makes something that doesn't change more important than something that does change? (Psst, you don't have to answer that; it was just rhetorical.)

Internet of Shit (@internetofshit) | Twitter[^]

Well, if you do the math, it's about the same whether you buy a new version of Office every few years or just spread that over month to month for the time that you use Office 365. I don't know about the shrinkwrap version, but I know that w/ 365 you can install on a lot of machines including MacOS for five users anywhere and you also get to use the Store versions on large screen devices and you get a lot of OneDrive storage. I still would dump my subscription and just use the online version of office, but my dad enjoys using it, my wife insists on using Outlook instead of Outlook.com or Windows mail, and I need all that OneDrive space. It's like cutting the cord: I pay nearly as much for Internet and streaming subscriptions than I did for cable.

Keep in mind that anyone w/ a OneDrive account can use Office online and it will update old files: Microsoft Word Online - Work together on Word documents[^] I would dump my Office 365 account and use that, but then I wouldn't have all that OneDrive storage.

Delusional would be making all of those changes and then when someone asked you how the unit tests went, you say, "What's a unittest?" or "Unittesting is a waste of time."

I hate the term dead, because webforms & Jquery are supposedly dead, but they are still everywhere and some groups will just not let them go. But I would focus on either AngularJS or React/Redux. I just recently was writing a small app in Razor Pages (as opposed to ASP.NET MVC) and I needed a bootstrap time picker which I found in NPM, (record scratch noise) but the Razor Page project isn't really optimized for using NPM whereas the a fore mentioned JS frameworks are. The more I code w/ JS-based client-side frameworks, the less I like frameworks like Razor, PHP or HAML in Ruby where you write HTML, but every once in a while you break it open and stuff some imperative code in the middle of it. And let's face it, AJAX is a pain in Razor and feels like a hack whereas Angular and React handle it differently. Lastly, Razor is a Microsoft thing, React and Angular are not even though VS supports both frameworks (particularly in .NET Core projects). Learning React and Angular allow me to feel like I'm not so locked into VS much less Windows.

I recently started an amazing position where we are using VSTS. I say it's amazing because they really just want to reboot their whole enterprise application effort and they told me that they want Microsoft and the cloud. So we are using VSTS, Azure, Azure Active Directory .NET Core, EF Core, Web API, SQL Server and React (?). Yes, MS is supporting Angular and React in .NET Core projects but they use TypeScript. We are a small group and are leveraging VSTS as much as possible at this time: task and SW bug management, Git-based source control, builds and deployments to Azure. Like someone else here said, VSTS works very well with Azure. VSTS allows you to link source control branches with tasks and bugs. We still use an issue management system for tracking issues the the whole company so we can track non sw bugs (like pencil sharpener is full !!) but for sw bugs we keep them in VSTS. If you're going to use VSTS, I recommend that you use Git. In fact, if you code anything, I recommend that you use Git. I will leave that there and if you want more info, let me know. Another great benefit of VSTS is that being SaaS, it doesn't require VPN. I love not having to connect to VPN nor bringing my laptop home to do something. I just log onto VSTS/Azure on a different computer and I'm on my way. And we are using Azure Active Directory, so we SSO w/ our Active directory account, and we're in, and we are using that for our new enterprise apps. Again, allowing users to log on from anywhere w/o VPN and w/ any OS because everything we are writing now is SaaS.

Isn't RPG like that too?

I'm sorry. Not for my reply, but that you have to use TFS source control :(( I always found branching a nightmare in TFS SC.

I started using Git about five years ago and have never looked back. It's great for teams and individuals. It's great for working offline or online. It's great for any language, and it works great on various OSs. Microsoft has embraced it both by offering integration with VSTS, Visual Studio and all code samples being on GitHub. (i.e. I can use Git integrated in VS w/ any Git repo like GitHub, BitBucket, VSTS, etc.) Git is great for individuals because it doesn't require a server. And when you do want to move to another computer, you can just copy the folder that represents your repository to the other computer. But why wouldn't you use one of the many free servers like VSTS so that you can keep your code backed up in the cloud? You can pull any repo to any computer and then just checkout whatever branch in the repo that you were working on. (ie. you should never work in the dev or master branch!) My advice is to do a few tutorials. Learn the CLI first, and then download a GUI, or just use Team Explorer in VS. But don't freak at how much there is to learn. It's very intimidating, but you'll find that you rarely have to do much other than add, stage, commit fetch push and pull. And when you do get stuck, you just google it. Every once in a while someone who wants to get into programming asks what language they should learn, and I say whichever one you want as long as learn Git first. It’s the gateway to keeping code safe, collaborating, and keeping your development from going down the rabbit hole.

Check out the dev branch. Create a new local branch for that feature. Start working on a new feature You're asked to fix a bug on the same project not related to the feature you're adding. Commit your work for the new feature to the local feature branch. Checkout the local dev branch. Pull to get anything from origin that has been done since you started working on that new feature. Create a new local branch for that bug. Fix said bug. Commit your work to the local bug branch & push that bug local branch to origin and start a pull request. While a peer or lead checks over you code in that origin/bug/branch, you checkout your local feature branch. Continue working on feature. Reviewer tells you that you should change something. You grab a stress ball in one hand while reading their review all the while thinking, "Who is s/he to suggest that it could be better...," until you see the glaringly obvious bug. Commit your work for the new feature. Checkout the local bug branch. Implement the suggested code fix. Commit and push (to the origin/bug branch.) Re-request pull. Pull goes thru and is merged to dev on the server. Checkout local dev branch. Pull from origin. Checkout local feature branch. Merge from dev. Delete local bug branch. Continue working on feature until finished or you get another, "If you could fix this bug (and by bug they mean that they want a font size change), that would great..." Then restart the cycle started in step 5. If feature branch is done, commit & push that branch to origin, ask for a pull request for that branch. Do anything to implement any feedback from pull request until is right. And then see what they want you to work on next. No one needs to know how many local branches you're working with. We are talking about Git, right?

I used to consider myself one, but there are never any opportunities, so I've had to go web. What's funny is your comment about applicants no reading the job requirements. Because I don't think that I've met a recruiter who has read my resume before calling or emailing.

I completely agree, but for those out there considering getting into Git, learn the CLI. You're never going to memorize everything, but get the basics and concepts down and remember like everything today, you can find out the exact syntax online. I have to look up stuff for Git (and others things) all the time. I have found many integrated Git GUIs like in VS can't handle certain things well, and I have to open up the CLI to see what's really going on. However, when it comes to merging files that Git can't handle, I'll take a GUI any day.

I'm a long time Microsoft programmer who grew up on Visual SourceSafe and then TFS. I had tried SVN, Mercurial, and a couple others, however. One day, I got a new boss who said, "Thou shalt use Git." It is very different from the centralized systems and required a lot of reading/watching vids, and even now, I still have to look up non day to day commands, but I admit that I have to do that for just about anything now including .NET because I've moved to .NET Core... But I love it and would never go back to anything. During recent interviews, I always ask what kind of source control they're using, and if it isn't Git, the job don't fit. (Sorry, O.J.) Another thing about Git is when people talk about getting into programming or ask, "What language should I learn first?" I say, "Any one you want as long as you learn Git first."

Are You A Code Poet? - I'm silently reviewing your code T-Shirt | Teespring[^]

Free (or nearly free) education already exists. Debt comes from wanting a piece of paper that implies you're smart.

— Bored Elon Musk (@BoredElonMusk) July 29, 2016