I put GitHub Copilot to the test by generating a full-stack project—a .NET Web API and an Angular frontend. The results? A mix of efficiency and reminders that best practices and patterns still matter.

💡 Observations:
✅ Copilot will generate the simplest implementation unless you prompt it with clear, structured instructions.
✅ Without guidance, it might use incompatible syntax.
✅ Everything in one file? Yep, it put the entire C# API in Program.cs and the Angular app in AppComponent.
✅ It passed objects around directly in the API, skipping best practices like DTOs.
✅ It applied inline styles in the Angular template instead of using proper CSS or component styling.
✅ The CSS it generated had duplicate entries for the same class, leading to unnecessary bloat.
✅ It actually walked me through setting up CI/CD with GitHub Actions and how to configure a DigitalOcean Droplet for deployment.

The takeaway? AI-assisted coding is powerful, but best practices, patterns, and SOLID principles still matter. We need to understand the tools, refine our prompts, and guide AI to build maintainable solutions.

🔧 Keep learning. Keep improving. AI won’t replace good developers—it will amplify the ones who know how to use it effectively.

#AI #GitHubCopilot #DotNet #Angular #SoftwareEngineering #GitHubActions #DevOps #DigitalOcean #KeepLearning

Check out the revamped site: https://cozyweather.com

I could reduce the costs in a number of different ways. Probably the easiest is by scaling down the service plan that the site is running on to have fewer resources.

The chart below shows that I was getting pretty similar charges for US east and central last month (the donut chart in the bottom middle), which is surprising to me. I thought my scale out settings were set to only run one node, so I expected to only see charges for US east.

After digging into a little more, I'm thinking the load from the new monitoring service wasn't the source of the increased costs. I think I made some other inadvertent change to the service around the same time, that made a second node spin up in US central. Not good!

This is corrected now and I'm only seeing charges for US east now. I've added a hard budget for the Azure subscription and have setup email alerts at 75% and 95% of the budget, so I shouldn't get any surprises going forward.

I think it's time to setup infrastructure automation with Terraform[1] to keep tighter control on what's deployed and to reduce point-and-click mistakes.

Lesson learned!

[1] https://docs.microsoft.com/en-us/azure/developer/terraform/overview

Putting this together made me realize that at some point I need to get serious about thinking about a theme and style guide... things that a designer would normally do. But in the meantime, the site is just going to be a little embarrassing and cringey :)

This whole project started out as an educational endeavor. I noticed that Microsoft gives out a pretty healthy Azure cloud benefits budget to nonprofit organizations for free. What if I open sourced the project, dropped the ads, set up a non profit, and personally contributed charitable donations to it? 🤔

Weather for the people, not for profit!

It seems like I’d be able to sit down and bang out v1 of my app, but it’s really not that simple.

How do you take a high level idea and break it down into tangible requirements? One way is to capture use cases. I took a pretty interesting course through Udemy which was basically a refresher of other software requirements classes I’ve taken before.

I love the idea of just thinking through a user journey or scenario and capturing a high level summary. Another concept they went into is performing an event-response analysis to find requirements.

I just jotted down a few things of the top of my mind to capture areas I need to go back and break down in more detail. Some of these might never make it into v1. And there might be others that I haven’t uncovered yet.

I’m starting a 4 week UX design class through Coursera / Google soon. It should be interesting (and very new for me) to take some of these ideas and get them down onto a mobile canvas.

https://www.coursera.org/professional-certificates/google-ux-design

Process can be a pain. And with a solo project? I guess I could skip process completely and just go. Or I could just go with process I'm familiar with. But hey, I'm working on building a new kind of weather app to jump start professional development, so why not try a new process while I'm at it? Enter "Lean Startup".

Interestingly the Lean Startup agile technique is only coming in as being used by 1% of all respondents in the "State of Agile Report ."

When looking around online for tactics on "how" to work with this technique, it's not so straightforward. The official website seemed to be more about selling books than sharing hands-on tips http://theleanstartup.com/. I don't know, maybe I didn't dig deeply enough?

I did find that Atlassian acknowledges Lean Startup, but only very superficially https://www.atlassian.com/software/jira/align/lpm.

All good -- I'm just going to roll with it.

For the weather app I'm working on, I documented plan A using leanstack. It's really interesting because in a few minutes of discussion with my son, I discovered that plan A isn't going to work. He told me that he wouldn't use the app as I had envisioned it. We dove into the problem space and went through pain points together:

• everyone has their own comfort zone (what feels cold to me might not feel cold to him) so he doesn't want to wear a coat just because someone or something told him to
• forecasts can be hard to understand
• mornings are busy

What he told me next really surprised me:

• needs to feel like a game; must be fun with leveling up
• needs to be customizable
• graphics are important

Wait a second, I thought we were building a weather app and now we're building a game?! I'll have to think on that, but one thing that really stood out to me here was the idea of personal temperature profiles. If HE built his own profile, he might trust it and learn to associate the somewhat abstract concept of a temperature number with a feeling of hot or cold. This is starting to feel more like a science class learning tool than a weather app...

It seems like there might be two parallel tracks emerging:

• hammer out the concepts with the concierge MVP model (not actually building the app, to begin with, but rather manually figuring out what the app needs to do)
• put basic infrastructure in place (select architecture, setup basic project template, setup cicd pipeline, plug-in analytics tooling, plug-in feature flipper tooling, etc)

Then once those are basically in place:

• build the minimum feature set to get the app up and going
• then finally continue to iterate as described here: https://www.ycombinator.com/library/62-how-to-build-product-as-a-small-startup

It's actually been harder to get to this point than I thought it would be, but this has been pretty fun so far :)