.NET developer with a passion for mobile and DevOps. I build cross platform apps using Xamarin, backend systems using Azure and GitHub Actions using Docker.
Nothing here yet.
In my opinion the best side projects are ones that you are interested in and will use yourself because that keeps you motivated. So for example, a Pokedex is a great project for a Pokemon fan but not a non-fan, and an Address Book is probably a bad side project for most people because it isn't very interesting and you probably already have an app for that.
Hi. The class that your compiler doesn't recognise should have a red squigly line under it. Mouse over that class and a light bulb should appear with a triangle. Click the triangle and it will offer to add the relevant using statement if that is what is needed. If installing a Nuget package is needed it may offer to install it and add the using statement. If that doesn't work then right click your project or solution in the Solution Explorer and click Manage Nuget Packages... in the menu to open the Package Manager. On the Browse tab you can search for public Nuget packages, search for the package you need and click on it in the list. On the right you will now see the projects in your solution, click the checkbox next to the project you need to install it in and then click Install . Clean & rebuild your solution (not always necessary but sometimes helps so I usually do it after installing a Nuget package) then try the light bulb again to add the required using statement.
Hi Chadwin. Some of your other points will help with a spec that is not defined 100%, particularly designing a system that is flexible to change and communication. If the system is easy to change then finding out you need to make a change at a late stage isn't as much of a problem and by communicating with the client often you should spot such things a bit earlier. Sometimes all you can do is know a particular client can be problematic and schedule extra time to deal with the inevitable changes.
Going forward, I would want the goals and outcomes to be defined and approved by all stakeholders, before a single line of code has been written. In my experience that is almost impossible to acheive. I think only one project I've worked on had defined goals and outcomes before the code was written that did not subsequently change and that was a very short contract making a small addition to an existing system. "No plan survives contact with the enemy" is as true today as it was in 19th century Prussia.
For those CAPTCHAs where the object is slightly in another square, you don't need that square. For most CAPTCHAs selecting 3 correct squares is enough to pass so for those traffic lights on long poles you don't even need to click the pole, just the main squares with the lights in them. And, if you're unsure click Skip until you get an image you're happier with. The biggest problem with CAPTCHAs is the complete lack of localisation, they are all based on USA culture. As a Brit I have no idea what a crosswalk looks like, can't find a single black cab in the picture when it wants me to click on taxis and they never contain anything that looks like a school bus to me.