Egret Breakthrough

The company I am volunteering for outside of work has been using a flat-file database I will call Gold Digger for fun and because it’s a play on the title of the software. Just within the past half hour I was able to export data from one of their main modules in Gold Digger as a CSV file and was able to import this into the PostgreSQL database, Egret. My strategy was to build a migration table in Egret that would match the column names in the CSV. Because the CSV is all text, trying to import “-80.50” into a numeric field just blows the frick up, so I decided I would make the migration table columns all text. I will have to explore more to find a quicker method to perform these migrations, but the next step will be to insert into the Inventory table a selection from the migration table and get fancy with the data format functions (currently unknown to me) in order to match the datatypes properly.

Three hours Tuesday night taught me some major differences between Oracle and PostgreSQL. I think I would struggle to be a DBA because I always have to know why, and so much about databases seems to be ad-hoc.  In Oracle, a user is typically a schema, but in Postgres users are now Roles (with login privileges). Which is really interesting, because you can also have multiple databases in one “database”, but the users are separate from those databases. It’s weird. Now, what’s going to be really fun is building the user functionality and learning how to establish encryption over an intranet. Well, I won’t worry about that yet. A journey of a thousand miles begins with a single step.

Fire

“I…have made fire!”

By this I mean to say that I’ve connected to a Postgresql database with C# and printed some content to the console, marking the third time I have used the connected layer of ADO to retrieve database information.

You have to realize, at my last job, all of this was abstracted from us. ADO is the beast I’ve been learning on my own for the past several weeks. I took a guided, 200-page tour, and now I’ve been doing more hands-on, which is so important. Most tutorials use Sql Server, but last week I had some down time to connect to one of our development Oracle databases, and now I’ve connected to my Postgres database. So that’s the power of using interfaces to achieve similar functionality across providers.

To be fair, I’ve had to reference my C# book for each occasion, as I keep forgetting that damn DataReader object, but I’m pretty stoked I got this to work. It’s scary to think how much more there still is to learn about ADO and Entity Framework, which leads me to my next thought.

Entity Framework still confuses me. I was thinking about doing the Egret database code-first, but I’m so new to EF that my brain starts to freak out when I think about the database structure in C# code. I’ve done so much with SQL over the years, it just feels better. Not having had experience on the job to teach me which is better, I may just build out the rest of the database in Postgres for expediency and peace of mind, then pull in the classes from the database. Unbeknownst to me at the time, the original data I received for the database was not the complete copy, and I only received the complete copy last month, which changes everything in my models, but I am desperate for visible progress. I can’t take the tutorials anymore: it’s sink or swim now, and some good people are relying on me to swim.

This is probably the most study I ever done over these past 6 months. The pace feels painfully slow, but 700 pages of brute C# is not to be dismissed, and I’ve dramatically surpassed the knowledge I had last year. But I’m going to count this victory and call it a night. I’ll push onward tomorrow.

MVC Adventures Part 3

Oh, the horror! C# uses a lot of boilerplate. I reached the section where a connection through Entity Framework gets setup, and everything has fallen apart there.

I kinda feel like an idiot. There is so much to learn here. Not having had to write much OOP on the job, I sometimes find myself reeling from all the unexplained object references, but my brain is finally started to wrap itself around how to really use interfaces. There are so many rote configurations to memorize, it’s a very different beast from “understand what this program is doing” when it is written in the raw. What’s a DbContext? “Oh, don’t pay attention to that! We’re programmers, we just rely on abstraction!” I die a little inside every time I have to forgo the full explanation, but I suspect this is just inexperience. After all, Python hides most of the details, it just doesn’t feel that way.

I am learning! I feel much more at home in Visual Studio and with the files. I generally get what MVC is doing. And I would probably be surprised just how much progress I’ve made. I got a simple list to output in html using Razor, building the values off of a subset of the Product Categories for my inventory system. Sometimes I still feel tempted to switch to Django, but there are things I really enjoy about C# and it’s far more common. Never give up, never surrender!

MVC Adventures Part 1

I had just started to learn Asp Core MVC last fall, but my new job uses Python and PL/SQL so I haven’t touched MVC since. However, the time has come to start building the middle-tier for my friends in Nepal, so I’m diving back in.

I have to keep this short because it is definitely bedtime. I started a blank MVC project in Visual Studio and *gasp* forgot to check that little checkbox that pulls in the default MVC assemblies. So of course all my references in the Controller were off. Sane people would just scrap the project and start over, but I lack this desirable quality and decided to tough it out. That’s really the only way to learn, especially in systems like Visual Studio where you have training wheels Frankenstein’ed all up in your business. Point-n-click for WebForms just killed me, I just died inside, I had to blank-slate my way through every asp tag attribute before I felt I wasn’t a complete idiot with what I was doing. Anyway, after several headaches, I finally figured out that if I browse the offline packages in NuGet (what an idiotic name…), I could get Microsoft.AspNetCore.MVC installed, my references would resolve, and I could start the page with the debugger. Of course, I’m still missing tons of packages, and don’t know how to specifically get the Tools assembly from Microsoft.AspNetCore.Razor (I’m referencing another project that shows which packages are normally created when you check the checkbox), but hey, it doesn’t die.

And you want to know something fun? Currently, my page is not loading. But that doesn’t stop MVC from loading a page with nothing other than “Hello World!” in text on it. Somewhere deep in that system it is defaulting to that. Which is retarded because that defeats the entire purpose of doing “Hello World”. “Gee, you screwed up, so we’re going to tell it Hello World for you!” But if you couldn’t get it to work, that is failure, that is not “Hello, World!”

Ok, despite my frustrations, THAT IS HOW IT IS DONE!!! You can’t ever hope to really understand Visual Studio until you can bootstrap the defaults yourself. Ye-ah! Anyway, there will be a part 2.

Unit Testing for Life

My grand C# project as of late has been a WPF Powerball simulator. I once hacked it up with WinForms and got everything to work by smearing public modifiers all over the place and ignoring good practice, but now that it really matters, I have taken the more professional approach.

At first, things were working great. The code behind was executing flawlessly, and the last thing to do was implement the payout logic. That’s when it occurred to me that my code behind was getting sloppy, and I wanted to pull out the logic into a separate class file. The moment I did, all functionality broke, as I no longer had access to the Window instance. Thus began a two day journey to learning bindings and MVVM, and I cannot honestly say there are any truly good tutorials out there on it.

Just a few minutes ago, I finally got the Powerball values to start populating. You see, I’ve learned so very much in the past two days, but what I learned actually had little to do with WPF. Sure, there has been a lot of confusion about the ICommand interface and how in the world to get events to work as bindings, but I learned that a { get; set; } declaration is required even on public properties when you want to access them from outside, that one should be really careful not to mistake an object for one of its properties, and that using constructors properly is very important for getting things to work they way you want. This is OOP in the trenches.

My greatest mistake has been trying to convert my application all at once. Without finding simple ways to understand bindings, I found myself flinging solutions at the whole thing, and it turns out what primarily kept my application from working was a mistaken understanding of how to pass values between the model and viewmodel. I suspect that one of the best ways to learn is to bite off one piece at a time, similar to unit testing. If you can get that basic piece to work, they you are far better equipped to to solve the next larger piece, and so on until you can isolate bugs to the newest features and their implications to other elements of the application. I’ve never thought about actually approaching learning from this perspective.

Next steps are to get those commands to work, but after a very long day, it’s time for a movie.

Visual Studio Woes

allthethings

I put my old Powerball Simulator up on GitHub today, and started to continue working on the newer version that uses WPF. I decided to rename the namespace I was working in as I wanted to tame all of the elements in the solution, and came face-to-face with my greatest frustration with Visual Studio: the absolute ubiquity of configuration and code behind files, which nest and hide references everywhere.

See, I come from a Python background. As long as the program is in your path, all you have to do is insert an import statement to pull in other libraries, type your program, then you type “python yourfile.py” on the command line and BOOM, you have a working program. C#? You have debug directories, assembly directories (because apparently the system doesn’t know where to find System.Core etc.), and God forbid you write a simple program that doesn’t have a “code behind” to match every other file in your program. It took me a good half hour just to figure out what was causing my program to die because that old namespace was referenced in five places I never manually typed it out.

I do appreciate how much Visual Studio automates, especially with XAML presentations, but I wish I understood why all of the things in place are there. Long ago, I opted to learn ASP.NET by manually typing the aspx file and discovering what worked, what did not work, what was required in the declaration, and what I could safely exclude which VS  otherwise automatically supplies. That was great. It will take time and experience to really figure out whether I even need all of this messy configuration for other programs.

Rant over.

//——————————————————————————
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.42000
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//——————————————————————————