Voyages of a Software Dev Intern Thru The Early Years

I've said it before, I kinda know what this program needs to do. Translating that into C# objects that will interact with each other intelligently and efficiently...that's a whole 'nother can of worms that I personally find easier as a visual. I know Students will have courses. Courses will have evaluations (like quizzes and tests). Evaluations will have Scores. Deciding how that works, from a database perspective, will help ensure I'm configuring my code to back into the correct place and identify ways to simplify the data layer--storing instructors in their own table will allow possible features down the road of letting students see how many A's a teacher hands out historically, for instance, but also makes me decide if my entity should have an instructor object attached, or should that be a domain model thing? I'm a very goal-oriented person in that if I know there's a river to cross 500 miles from now, I want to plan the next 500 miles of route t...

One of the things I learned from revisiting C#II's project, eDevices was that planning out what your database schema is going to look like is pretty key to determining how easy your life is going to be down the road. In C#II, the focus appeared to be on breaking up the bigger project into smaller iterations that were built on organically--which was GREAT until I tried to implement a feature that hadn't been planned for in an earlier iteration, one that required changing one of the fields on the Policy entity. I managed to break all functionality because the Policy entity no longer matched what was expected, and I had to completely redesign 90% of my application's business logic to account for this new feature. This led to further frustration when I realized that I didn't properly manage my code first migrations for this series of changes--again, they happened organically during the class without any thought or discussion as to how to go back and make changes. Had t...

As mentioned in the previous post , I kinda adore the sequence diagram. For me, it's the single piece that really allows one to translate the idea of a program into code. It's not exactly where the rubber meets the road, but more like the rim the tire is mounted on. Let's segue away from that odd analogy to the diagram in question. Lookit that. The simplicity. The beauty. Setting aside the fact I'm still not 100% on entity framework and have serious questions about how to implement it, I know what's going on here. I can see what gets input by the user, how it gets passed to the controller, where it goes from there, and at what point the entity gets converted to a domain model (is that a service function, or an interactor function? Hm...) and then a view model. I could sit down and write out almost everything based just on this png file right here. The trick is keeping the sequence, or unit, simple. Otherwise, you can't really break it apart and see it ...

The activity diagram is all well and good, and can even be super useful in a lot of cases. But for my money, so far in my limited experience, the sequence diagram is where you really start to get a handle on what you need to do as a programmer. Before the sequence diagram, you're dealing with steps in a process. What needs to happen, in what order, and you could just as easily be talking about employees or way stations or widgets or nothing at all. They're really about systems analysis--that high level, what needs to happen kind of stuff. Really important work, but totally dull from a programmer standpoint. The sequence diagram is where we start seeing method names and parameters being laid out. The interaction between classes and layers. You start to see what methods you'll need, in what classes, and get a feel for what properties those classes will need. You can see the flow of the data from the start of the operation to the end, note the inputs and the outputs. I...

I mentioned it earlier at some point, but I'm not following the traditional method of system analysis and design as taught in my class. I'm skipping quite a few steps, and really what I'm planning to end up with is a little disjointed. However, I have some reasons for that--namely that in a situation like this, I feel going whole hog on the discovery phase is redundant. For instance, domain model and entity relationship model. If a student had come to me and described the problem and asked for a solution? Yes. Absolutely. I would need to sketch this out--what things am I working with? Which things are going to live in the database? Does a course have a grade like a planet has a moon, or is a course and a grade more like Mars and Uranus? These are important questions that need answered before you can get into the meat and potatoes. But...I already did that. Months ago. Before I knew what a domain class model even was, but I have the relationships and the entities all l...

I don't think I'll be posting about every diagram I do--they're not great works of art the world must see, and if you really wanna see them they'll be in the Github repo. But I did want to post something project specific for each piece of theory here. Thus, please see below. I think this is pretty self explanatory, even to the uninitiated. Black dot with no ring is the start point, black dot with a ring is the end of the use case. In this case, we can end the use case by just...stopping, or by going on to the "create course" use case. Which will be a diagram I can link to, hence that weird symbol after the Create Course block. As an aside, I'm using a program called Violet to do my diagrams, and have been for about a year now. It may not be as fancy as Visio or several online subscription options, but I'm honestly more interested in being able to get something on paper (so to speak) quickly, so I can start messing with it. I need to understand...

So I've got use cases figured out. Not all of them--only a fool or a genius thinks he can sit at a desk away from the end user and think he's got all the use cases figured out (and a genius would never truly believe it). But you can't sit around trying to anticipate every possible use case before you start, so once we have enough to cobble together a complete program or part of one we can move on for a bit. Side note, this is the beauty of the agile approach: "Yeah, we know we gotta go to the moon. But we have to do it in 10 years, so we can't spend 5 years thinking up every problem we might need to solve before we start solving them. How about we start with 'design a rocket that reaches orbit without killing anyone' and build on that when we finish?" That's called an iteration, but more on that later. Fleshing out what that use case needs is the next step, and there are a couple tools I remember being taught. One of them is the activity diagra...

So last time we covered the really high level theory behind use cases and why planning them is kind of important when writing a program. This is the part where I tell you I've changed my mind, I'm just going to totally wing this project since I landed an internship and I don't actually need this program to be professional looking. PSYCH--did you even read how I closed the last post? That was hilarious. But anyway. I didn't actually go through the full CSCI-1275 "discovering your use cases through '20 Questions,' rune reading, and chasing clients for interviews" approach. We spent close to a month on use cases in that class--how to identify them, how to define them, how to model them, and a little on how to prioritize them. The bulk of the class was use cases, and like I said...I get it now. But that doesn't mean I'm doing to sit and actually write out a full CRUD technique analysis of all the ways a single user will interact with a ...

They told me in my CSCI-1275 Systems Analysis and Design course there's a tendency for programmers to just start coding stuff without thinking, and this was nigh on tantamount to total catastrophe. I didn't fully understand this until a little later in the semester. We had just learned about arrays and collections in my CSCI-1630 C# Programming I course, and I found this to be a perfect excuse to write a little application that would synthetically divide polynomials . (That's a really great way to master synthetic division, actually, if you're interested in brushing up on that skill. Although my wife still insists the time would have been better spent putting more time into my algebra homework. Two types of people...). At any rate, long story short: I made the program work perfectly, for 3rd degree polynomials that divided evenly. Then I realized it broke when I tried a polynomial of the 4th degree. And then again when the 3rd degree polynomial had a remainder. ...