Skip to main content

Joyous Happy Updates

The Old Goal, Revisited

Quick redirect (more to refresh myself than anyone who is going to read previous posts and then this one without feeling any gap in time--kinda like binge watching an older show on Netflix wondering why the season in 2007/8 was only 1.5 real episodes): This blog was initially created to serve in an alternate timeline where I did not have an internship over the summer. My goal was to develop a web and/or mobile app from scratch, as a way to keep my skills sharp and prepare for graduation in December. This blog was supposed to be a way to document to potential employers "Hey look--I can do the things, even if no one has paid me to yet! And I can write about them, with personality even!"

 So What Changed?

A late but extremely welcome change to this plan was an offer to intern at OrangeBoy, Inc here in Columbus--an exciting small firm that combines a software-as-a-service platform called Savannah with public service consulting expertise to help libraries and similar institutions engage their customers. I should take this moment to expressly state anything you read here, or in any other space in the internet, is my own happy thought that I alone am responsible for and has absolutely nothing to do with OrangeBoy.

So I find it amusing that my last post was on 6/4, the day before I started there. It's been a wild, informative, career-choice-affirming ride that I'm lucky enough to continue through fall semester--but, of course, a job plus school doesn't mean we give up on our side projects. Oh no. Far from it--the job and the homework and all the lessons learned have sharpened the focus and given new purpose to the side projects--an opportunity to build a better clock.

"I am not reading that article--what the hell does building clocks have to do with programming?" -- several readers, probably. 

The short version? Jim Collins explains it thusly:
"Imagine that you met a remarkable person who could look at the sun or the stars and, amazingly, state the exact time and date. Wouldn’t it be even more amazing still if, instead of telling the time, that person built a clock that could tell the time forever, even after he or she were dead and gone?"
Collins uses it to explain business leaders--flashy CEOs with vision to personally drag their company to greatness, but fail to instill that vision in an institutional memory so it will run with or without them. I think it's an even better analogy for software developers.

What do I mean by that? Well...maybe that's better saved for for a new post.

Comments

Popular posts from this blog

Use Cases: The Theory

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. ...

Activity Diagram: Theory

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...

Activity Diagrams: Pertaining to the Project

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...