Tuesday, July 24, 2012

... the other half is maintenance

This morning I arrived at work early - I was hoping to complete a mail-merge before my morning meetings and my afternoon with the kids.  But I made the fatal mistake of pulling up my email to make there wasn't anything more important/pressing.  Lo, and behold, I needed to finish some edits on the CASA Annual report.

I pulled up the report from the email, added an explanation about why our calculated retention rates for orientation attenders and first year freshmen do not match exactly Institutional Research's numbers (we include some students that begin in the summer and some populations that are excluded for state reporting purposes), moved some graphs around and other minor edits.

Next, I pulled a list of the remaining assignments to an advisor who left the university - a flaw in the current system is that when an advisor is inactivated, other departments can no longer look at his list - I have to use the historical database to pull that information (one of many reasons that assignments are due for a re-write).  

I answer a couple more emails.  Time for my 8am meeting with ACNS/the Library.  Walk around construction on campus and into the Library.

Today's topic is the MOU (Memorandum of Understanding) on CASA taking over daily management of the laptop checkout program in the Behavioral Sciences Building.  For the past year, it's been a joint venture where Undeclared Student Tech Fees have paid for machines and our lab staff have worked equal hours along with Library student staff to checkout the machines.  The Library did all the maintenance and setup of machines.

So, now we will take over
  • 10 Macbooks and 15 Dell laptops paid for by Undeclared Student Tech Fees
  • 18 Macbooks and 20 Dell laptops paid for by University Tech Fees
We'll continue to use the library system to checkout laptops for convenience and to charge students who checkin items late and damage/destroy machines.

We (Undeclared Student Tech Fees) are augmenting the laptops with 18 Macbook Pros.

We are adding printers in the area and two printing kiosks.  Students will be able to use the laptops and webprint to print using quota on http://acnspapercut.colostate.edu:9191.  Quota can be added by transferring money from  http://ramcash.colostate.edu.

The Library added surveillance cameras over the checkout desk and will continue to handle the study rooms and seating, and the checkout program is still an extension of Library Technology Services.

We'll be extending hours and having two students watch the desk, hopefully filling the student technical needs even better than we did in the just-in-May-closed-Durrell-lab.

I setup a new Orientation Graduate Assistant whose first day is today.  I talk about technology at CSU, what we provide, and an overview of how technology supports the CASA units.  We provision his account meaning I give him access to:
  • A CASA account and ability to login to machines on the CASA domain
  • Access to install programs on his assigned office machine
  • An exception so that he can have an exchange account on mail.colostate.edu
  • Access to edit portions of the Orientation and Transition Programs website
  • Access to Lighthouse, Leave, Timesheets, and the Orientation Reservation system
  • Access to InvolveNet, the tracking system for First Year Mentor Programs
  • Membership in the appropriate Exchange groups for Calendar management and Distribution Lists
  • The ability to remotely login to his office machine
Head over from Aylesworth to TILT.  Finish moving a few items between rooms.  The computer staff moved across the hall from our former office into the former resource room.  Yesterday, the computer staff moved a fridge out and a bunch of desks, computers, monitors, etc into the new space.

*Found the door to our office unlocked.  Old habits die hard - someone unlocked it in the morning, but now there is no reason for it to be unlocked when no one is there.  So, I updated the sticky note on the door.  We'll see if people read.*

Move a bunch of stuff around.  Pulled the black crates and laptops that need to be moved back to Aylesworth.  Promptly forgot them for the rest of the day.

Met with TILT staff about the Great Hall - we have added printers up there and a single machine for printing.  Worked out lots of logistics, and attempted to add the printers to the machines already in place.  Determined I'll need to work with their IT folks to install Papercut Client on laptops.  Lots of documentation needs to be written!!!  

The printers will work just like the BSB printers - purchasable quota can be used to print at any of the locations - Library, BSB, TILT Great Hall.  Housing is also adding printers in several of the residence hall main offices.  *Note to self - order the test printer for housing*

Rush home to spend the afternoon with my wonderful kids.  It's library day!

Now, here I am during quiet time - Tristin is sleeping, Collin is watching Spiderman on TV, Marcia has been learning Photoshop drawing using a Bamboo drawing tablet (and is now starting dinner), and I am adding way too much detail to this blog.

Gotta go back to work after the kids go to bed.  Still didn't get that mail-merge done.

Just another typical (a-typical?) day in the life of a University IT Geek Father.

Monday, July 23, 2012

Smooth Operator

Creating a scrolling box is harder than you might think.

Matt did most of the work on this, but I thought I would write it up in case anyone else finds it handy.  Final Game Maker Studio code will be included at the bottom.

So, scrolling.

When you click on a series of items, you expect a certain behavior when you move your finger or mouse.  You are clicking and dragging a set of items.  Here's the diagram:

The measurements given are arbitrary, but useful because they are concrete and can be generalized later.  The red regions indicate where the list item should be hiding behind the border (not quite possible with GMS - you can draw a portion of a sprite [the list item background], but not part of text).

You touch somewhere (hit) and drag to another location (drag), which creates a distance to travel (trav).

The list of items should follow proportional to how far you moved, and stop according to the velocity when you lift your finger.  That is, if you click and continue to hold the finger at the end, it should move proportionally and then stop.  If you end with a flick, it should keep scrolling.

Still with me?

So, the coordinate system is expressed as y increases as you go down the screen.  Standard for graphics work.  In the diagram, the boundary box that will contain the list items is from (50, 113) to (350, 377).  To simplify the diagram, I left the x coordinates out and will leave them out from now on.  So the box where the list items are shown is from y = 113 to y = 113 + 264 = 377.

The list itself might be any size, but in this diagram is 318 tall, and trying to fit into 264 space.  So, some things will be hidden.  That's the easy part.

The hard part is controlling when the list should move, how much, and when it should stop.

When you touch the screen and move, your movement is being sampled 60 times per second, so 60 times per second, trav is calculated.  If you touch on the screen within the list box, say at y=300 and drag up to y=210 in a half second, this results in an average speed of -90 (distance) / 30 (samples in .5 seconds) = -3.  So, each list item should move that distance per step as well.

Anytime your finger is moving, trav is being recalculated.  When you lift your finger, trav stops being recalculated.  One of the cool things is that if you keep trav as it last was, that is, you keep moving all the list items at the same rate as was last calculated as trav, "fling" magically works.  Greater distance travelled in less time and those list items can really move!

So, here's where the problems begin.

There is no deceleration yet.  So you "fling" and the list items just keep moving.  And, while it's fun to watch a to do list disappear off the screen, and then fling in the other direction and seconds later watch it disappear the other way, it's not practical.  Additionally, it takes one step to establish the initial speed, so it will be laggy and appear to "jump" at times.  The first solution is to add acceleration and deceleration.

(Pictures to be added)

Ideal movement accelerates and decelerates
Slower movements move the list items much more slowly and quick movements move the list items very fast, and then they slowly come to a stand still.  There are several ways to do this.  I think the solution settled on was to multiply the current moving speed of the list items by .92 per step.  So after 0.5 seconds, the list items are traveling .92^30 = 0.0819662036 times their original speed.  Fairly fast deceleration.  When the items are traveling less than 1px per step, the speed is set to 0 and they stop moving.  Acceleration can be applied similarly, but I think the solution in this case was to judge the magnitude of trav and set the speed of the list items to ratios according to pre-defined regions.

Boundaries should keep list items filling the box:
When you fling up, the list items should stop moving when the last one is fully displaying at the bottom of the box.  Similarly, fling down and it will stop when the first list item is fully displayed at the top of the box.  It should 'stick' until moved by the finger again.

This is where calculations come in.  You can calculate from the first list item, the last list item, or both.

Both approach:
If the first list item's y value > surrounding boxes top y, then all the list items need to travel back to the surrounding boxes y.  If ( (y-27) > 113 ) then trav = 113 - y + 27.  Funny thing though.  Applying just this equation causes the list to become a slingshot as you use your finger to draw the first list item down below the top of the box, because trav can become HUGE!

So you apply damping when the list is within, say, 5 pixels of where it's supposed to be and just set the trav to 0.  If (abs( y - 27 - 113) < 5) then trav = 0.

And you would think you could do the same thing for the bottom item...
If the last list item's y value < surrounding boxes bottom y, then all the list items need to travel back.  So, If ( (y+28) < 377 ) then trav = 377 - y - 28.  Again, dampen it within 5 pixels.  If (abs( y + 27 - 337) < 5) then trav = 0.

There are more potential problems!  
  • The list items can stop too early, off screen.  The solution?  add another condition so the abs() functions only check on one side.  That is, If (y > 113 && abs( y - 27 - 113) < 5) then trav = 0.
  • The list might 'bounce' back and forth if trav is much greater than your tolerance.  This shouldn't happen with the out of bounds correction and the buffer, but if you choose to not move the list items the full distance to the end when the first item goes past the top, smooth acceleration can cause bouncing.
  • Rounding errors!
  • The list might 'get stuck' depending on the order of the statements.

Anyone else care to venture a guess at the methods based just on the first element or just on the last element?


s = ds_list_size(lone.lil);

if dropdown.shift != 0
hoverbox = false;
fade = 0;

if hoverbox = true
    if fade < 1
        fade += 0.05;
    fade = 0;

if itemnumber = (s-1) //checking to see if last item in list
    global.bottom = y; //get grabbed by scroll bar

    if dropdown.shift > 0 && abs(distance_to_point(x,dropdown.y+400-34)) < 5 //
        dropdown.shift = 0;

    if y+17 < (dropdown.y+400)
        dropdown.shift = ((dropdown.y+400)-(y+17));
    if abs(dropdown.shift) > 1
        if room_speed > 30 //deceleration based on room speed
            dropdown.shift = ((dropdown.shift * 0.98)); //deceleration
            dropdown.shift = ((dropdown.shift * 0.96)); //deceleration
        dropdown.shift = (0);


if itemnumber = 1

    if dropdown.shift > 0 && abs(distance_to_point(x,dropdown.y+18)) < 100-70
        dropdown.shift = 5;
    if dropdown.shift > 0 && abs(distance_to_point(x,dropdown.y+16+35)) < 5
        dropdown.shift = 0;
    if (y-17) > (dropdown.y+18)
       dropdown.shift = ((dropdown.y+18)-(y-17)+0); ///////


On Teaching... without any students

So, I've been attending Okinawan Karate Club for over a year.

I started at Chung Fu Do about 10 years ago, got my yellow, orange, and green belts there.  CFD was headed by Sensei Wilkewitz, and was one of three sister schools along the front range of the same lineage teaching Shudokan Karatedo.  Sempai Fussman went from brown to black belt.  Class was held above the Rio downtown and we had about 25 regular attendees.  I started attending because my mom and sister were having fun with it.  I kept going because of the incredible amount of fun and fellowship.  Every class, I said, "I was having trouble getting motivated to go work out, but I am so glad I went.  I learned so much!  The people are fantastic."

Then about five years ago, Sempai Fussman had been leading almost every class and Sensei Wilkewitz was unable to participate as much.  So Sempai Fussman started Warrior Gate and became Sensei Fussman.  I followed and obtained my purple belt after a couple prolonged breaks.  Class at Warrior Gate was excellent as well.  I watched Sensei Fussman become a true leader and skilled teacher.  We studied Chi Sao and I learned to connect all my movements to my center and through that manipulate my opponent/partner's center.

But life happens, and Warrior Gate closed, so I joined my third Shudokan line school with Master Shafer.  And it has been an excellent move - we think very similarly and he has spent over 25 years analyzing every aspect of the art.  I find my desire to learn met, and have picked up more history and the why it all works than I thought I ever would.  I know why he is a Master - he demonstrates a well planned and executed curriculum for all levels.  There's only one problem.  Right now, I am a brown belt and that is primarily a teaching rank.  There are no students of lower rank actively participating right now.  I need someone to teach!

[Shameless plug] - come learn from me and from Master Shafer and Sankyu Deb Shafer (Master Shafer's wife, and the dojo Sempai - head student)

Here's the card:

Tonights class discussed the Regulatory Path, the areas we study to establish finer awareness and therefore finer control as we progress through the ranks, starting with body (balance, coordination, speed, force, etc...), breath, mind and so on.  Great discussion.  We are a pretty geeky school at heart.

So, no students, but we (Sempai Shafer and I) are learning about the logic behind each of the drills, and the sequencing and order that is used to mutually reinforce growth so that a brown belt is attainable in 2-3 years and a black belt within four years.  I personally still prefer a slower pace, but it is really cool to see all the pieces fit together.  And I believe I have learned more about pedagogy and teaching through karate than through my time working for CSU in assessment.

Wednesday, July 18, 2012

Dev time?

So, writing apps really isn't my full-time day job.  It's my passion.

We started using Game Maker Studio to try something that produces android and iOS native apps so we can have a snazzy check-in app for student coming into CASA for an advising appointment.  Get them engaged, ask some basic questions, and invite them to start exploring majors and creating their story, interactively, before their appointment, so they come to the advisor excited and ready to discuss options.

Today I found this article:

So, it looks like GMS isn't ready for prime time (something we already knew from issues with the http_get method failing).  But the developers seem to be working on it at a quick rate.  And it IS an excellent rapid prototyping system.  If we need to re-write apps for release, so be it.  All the resources will be ready, as well as a lot of the logic.

Besides, I'm quite enjoying this.

BUT!  Today I won't have a chance to work on it.  Today, working on a mail-merge, lots of meetings, and completing the Student Advising Notebook application written in C# MVC 3.0 - want to release that as soon as possible so that advisors have a chance to try it and provide feedback.

Tuesday, July 17, 2012


This weekend was obnoxious.  I caught something from Collin, and it was not fun.  Had to miss a BBQ and doing much away from the house.  At least I didn't throw up like Collin did.

The worst part about being sick is how you feel like you are missing everything and that life will pass you by while you are recuperating.  Then you realize, hey, my body is probably telling me something (I haven't been getting enough sleep), and to enjoy everything else, I first need to be in good health.

So I polled my facebook friends, and apparently they only want to hear about unicorn poop and rainbows.  Which is retarded.  It's what my almost three year old would ask for.  Well, he'd ask just for the poop part and then I'd remind him again that people don't like it when he talks about poop all the time and could he talk about rainbows instead?  So where do the unicorns come in?  I don't know.

Speaking of, Collin is very clever.  He can make up stories now.  He told one last night about spiders he found out in the garden.  They climbed up their web, up and up, until they were at the top.  Then (according to mr. almost-three) they pooped and it went on everything and everything turned into poop.  And Collin should have ended up in time-out for that one.

So, ummm, technology?

Matt and I have been working on GMS - list maker application.  Friday we got GMS to run a game on iPad, and over the weekend Matt and Mike got scroll working more nicely and the ability to dynamically create lists and add new items to lists.  Yesterday we figured out how to restrict the width of a field so that text typed in does not overflow the box but instead hides text.  Some progress.  Marcia created her first seamless tile, which we will probably use in the list program.

Restricting text basic methodology:

  • A user types on their keyboard and as they type a string buffer is filling.
  • The string buffer is drawn on the screen in the location of the focused text box, offset a tiny bit to center it.  Naturally, since the 'text box' is just a sprite on the screen, when the text being drawn on top of it overflows, it just keeps going
  • Instead, check the length of the string.  If the string length is larger than the box, set the string to be displayed to cut off the first character.  Keep cutting characters until the text fits.  
  • Viola!  The text stays in the box

Thursday, July 12, 2012

Apparently, I love to work

Today's list of completed tasks:

  • Pull a list of currently enrolled students
  • Attend Coordinating Council where we interviewed a candidate for Business Manager and Data Analysis
  • Reviewed annual reports from other CASA units
  • Fixed Pidgin not connecting on two computers
  • Worked with Matt on scrolling with acceleration in GMS
  • Answered 22 emails and deleted over 100
  • Added advisors to Animal Sciences advisor list
  • Fixed Reisher Scholars Committee app to display all students that applied
  • Pulled lists of Transfer Students in particular classes for targeted recruitment into Transfer Mentor groups
  • Dropped of projector with all cords located in the bag, picked up kids toy workbench
  • Attended karate class
  • Fixed orientation housing rate breakdown to reflect new tax distribution - adapted reports to have multiple rates per program per year, differentiated by date.  We can make deposits again!
Today I discussed:
  • Genetically modified crops
  • Physics
  • Quantum Physics
  • Teaching Multiple to Orange belts
  • Tai Chi Soft-Hands vs. Wing Chun
    • These are both "soft" arts which focus on relaxation, compared to Karate which is a "hard" art and driven by tension.  Of course, all styles use both relaxation and tension, so perhaps it's better to consider as "more yin" or "more yang".  Tai Chi soft hands has as a goal to connect and continue/redirect the motion where Wing Chun is more spring-board using their energy to strike.

Foothills of Technology

Rainbows after much needed rains - the High Park fire was about 12 miles outside of Fort Collins.  The Poudre has black-water rapids today.

It was not the beginning, but it was a beginning...

I am beginning this blog to chronicle my development process and anything I happen to be thinking about as I begin a new project.

The project: learn to create mobile applications.  Make things I want to use.  Kinda like Jim Butcher writes the kinds of books he would like to read.

About a week ago, I started learning Game Maker Studio.  I followed the basic tutorial and had that clown running all over the place.  Collaborating now with several others on two projects that are still in their infancy:

  • list management
  • clockwork faeries story/game
Because I really want them both, I am going to share details throughout the design process.  This transparency might enable others to "steal" the ideas, but we all might benefit from that as well.  Of course, not sure that my collaborators would feel the same way...

So, as I have time throughout the day, I'm going to write this stuff down.  Make it a habit, several times a day and I hope the habit sticks!

Now, off to finish 89 emails for my job here at CSU.