In which we stand up the project
In episode 1, we talked about the general parameters for the project: the reason it exists and how/why it's supposed to work. At the end of that, we decided that we were three hours in already, dang it! It was time for our first user story.
A famous Marine said we learn by engaging with the enemy, not by sitting on the ship planning, and the same goes for developing tech. You can spitball and blue-sky all day long. It's when you actually try to deliver something of value to the user that you really start figuring out what's important and what's not. It doesn't even matter what the value is. At first we're trying to do something, anything. We struggle, then we generalize, then we regulate, then we automate. Such is the path of enlightenment.
So our first story was as simple as possible: take a file as input and repeat it back to me. Doesn't matter what the file is. If you can do that, then take a list of files -- either separated by spaces or as a directory name, and concatenate them together into one file. In general, work like GCC (a C compiler), just don't compile anything. This is our "do something, do anything" story.
Even with a 4-hour limit, I spent a lot of time deciding where stuff goes and why. Since this is version 3, anywhere there was a mess in the other versions I want to make sure we have clean separation of concerns. (Separation of concerns does not equal separation of code in functional programming, a story for another day.) There were several things I wanted working differently from the old framework to the new one. Little stuff like field names being PascalCase, or the file name and module name matching up for libraries.
VS Code continued to be more and more enjoyable the more I used it. I also love the dotnet tooling system, but it's still quite incestuously locked together with a bunch of GUI stuff. It's a legacy both the system and app coders are going to have to live with for a while. Without getting into too much detail, it should be that the CLI concerns/paradigm comes first, then everything else build off of that. Instead, there are pieces of the stack all over the place and your app, whether CLI or not, could be integrating with it. Or not. dotnet core helps some here over .NET, because it's being designed to do that. But it's not clear to the user what's coming from where and what's going to where. That's whack.
Having given all of that praise, VS Code is ---- quirky. I build the app. Ok. But then it was showing me errors in the problem tree even after I built again. Close Code then re-open? It catches up. Meh. Sometimes Intellisense worked, sometimes it didn't. I would get error messages that linked to the wrong spot in the code. Many times I'd get an indication that it was looking something up? But nothing ever happened. Or the wrong thing came back. Still needs work. That's cool, but it needs saying. I built directly from the command line quite a bit, ignoring whatever Code was going on about.
I think one of the biggest things I missed from Visual Studio was my Ctrl-R, Ctrl-R variable renaming across the project.
I didn't get all the organizing I wanted done, and I failed in my story delivery, but the project is still young. Failing at stories now is actually a positive indicator -- as long as you're failing in very small increments!
It's not always true, but in this case, failing=learning.
Now I'm going to take another run at this story using another 4-hour chunk. I believe I will need a bash script to test, since it's measurable completely outside the code. We'll see. Can't wait to see how it all turns out!
Interested in background on this series/project? Here are some links:
Change Your Paradigm
(Obligatory promotional video. We're building the compiler to support this book.)