Sunday, May 6, 2012

Presentation Practices and Final


So, we spent the remaining in-class time doing presentation practices.  On the big day, we presented, and it went splendidly, all things considered.  The only thing I think could have been improved was that Nialls's speech could have been more polished.  Anyway, I'm glad it all worked out.

For posterity, here are my revised notes from the first presentation practice round:
From all the presentations, I have distilled the following ideas:
--Introduction (e.g. "Hi, my name is . . .")
--Introduce the concept immediately.  Explain motivation, what this product does.  Be concise!
--Address Marketing: Accessibility, Business/Pay model, Address Competition.  Mention that we're free and don't own any of the user's works.  Market toward the general population.  Mention professional web developers (there are two approaches: our product can be their starting point, or their replacement).
--Formality/Do not doubt yourself/Never admit to a bug/Do not cheer for basic functionality
--Make sure what you're doing in the presentation is actually visible.
--Watch the time
--Present tense!
--No one cares about technical details
--Practice everything. 
--Practice setup (e.g. monitors, internet, etc.)
--Jump right into the demo right after the concept is introduced
--Show the "dragging" in the drag-and-drop website developer
--Make a website in five clicks, if you say that you can.
--Show theme-based version first.  Actually, probably don't need to show anything else.
--MUST practice.  Choreograph every single thing you do.  EVERYTHING.  DO IT.
--Video so that no problems possible?

Recommendation for overall structure:
1. Intro: "Hi my name is . . .", introduce motivation, introduce concept.
2. Begin a pre-planned, COMPLETELY choreographed demo.  Speaker continues, talking about things you can do with the website maker while the demo matches, doing everything in real-time behind him.
3. Demo continues, and a whole website is built while speaker addresses marketing, competition, etc.
4. The website, which has been being made throughout the talk, is exported and shown on a server.
5. Talk concludes, questions commence
It should be noted that I took more notes the second time, but they said essentially the same thing.  I didn't send them to the group either, so they're basically irrelevant.


Wednesday, April 25, 2012

Midterm Evaluations


I got the midterm evaluation from Ackley back.  I'm honestly not too psyched.  I'd like to take this opportunity to reflect on the comments he provides.  He rates things on a 5 point scale.

Attendance, classes     |...xx|
Not entirely sure about this.  I've attended every class.  I'll take this not perfect score to mean my being late on a couple occasions for academic advisement--although that only happened the second half of this semester, so it doesn't really apply to the midterm evaluation . . .

Attendance, meetings    |....x|
Participation, classes  |..xx.|
Arguably I probably could have participated more in class.

Participation, meetings |..xx.|
Actually this should probably be lower.  Particularly of late, I let everyone else do the talking.  I suppose since this is the midterm evaluation, maybe it's fair.

Proposal draft          |x....|
Really?  When he gave the initial evaluation, it was a 1.5/5.  I guess he rounds down.  But honestly, it wasn't so bad.  It met the length requirements, and discussed everything it needed to.  It was rough around the edges, sure, but not that rough.  See also my overall reaction to the reviews.  I can only assume he's judging me against everyone else, and that mine was on the lowest end.

Proposal revision       |xx...|
Again, seriously?  I thought that, even if the original proposal was bad, the revised proposal was much much better.  It addressed literally everything that anyone complained about!  It was more clear, concise, and explained the idea better.  I worked hard on this, and it was most certainly not an incremental change.

Proposal reviewing      |..xx.|
This is about accurate I feel.  Maybe a solid 4 would be nice, but I *could* have reviewed more than two proposals, I guess . . . ?

Proposal pitch          |..x..|
What was wrong with it?  On Ackley's scale, this was "okay".  I memorized my presentation, practiced it extensively, and presented it next to flawlessly.  I even got some laughs from the audience, which very few other people did.  I even dressed for the occasion!

Proposal impact         |.x...|
Arguably correct.  It was a computer game, which isn't too important in the grand scheme of things.

Blogging                |...x.|
Also about accurate.  My blogging is pretty decent, if not stellar.

Interim self-evaluation |...x.|
Impact (Jan-Mar)        |..x..|
Overall (interim)       |.xx..|


Proposal draft undercut itself right out of the gate.  Revision
improved in some aspects but doubled-down on the essential problem of the draft.  Pitch was mostly okay, given the content issues, if a bit weak on delivery.
As before, the delivery was pretty awesome I thought.  Maybe I just didn't project an aura of confidence or something.  I didn't stutter or pause or talk at my feet or any of the stuff you're not supposed to do, and I hit the time goal within 5 seconds, so Ackley, some clarification, perhaps?  I like to think of myself as a decent public speaker.  Ackley, if you have any suggestions, please let me know!

Also, on an accusatory note, I feel like my performance in the first part of the class is being judged based on Ackley's dislike of my proposal idea.  I understand that computer games aren't everyone's cup of tea, but that doesn't mean my proposal, reviews, and presentation of it necessarily sucked.  I'm trying to be tactful, but I'm not seeing any other way to explain these reviews.

Blogging has been a relative[ly] bright spot.  Quantity has held up overall, and posts are fairly often contentful, if fairly often blatantly self-serving as well.
I mostly agree with this.  I wouldn't call them self-serving.  As above, they're showing content, and if that content happens to paint me in a favorable light, so be it.  I'm not going to try to argue that I didn't focus on the best of my work, though, so maybe in some sense you could call it self-serving . . . ?

There is a lesson in continually getting the feeling that for some reason one's code is inherently better than code produced in the "real world".
Yeah.  I catch the double meaning; there are two lessons for me.  The first is: "I'm a pompous jerk.".   The second is: "Maybe I'm employable anyway."

Self-eval has lots of data.
Good.  I was hoping I was doing it right.

The utter absence of any interpersonal aspects in the self-eval areas for improvement is telling.
That's my bad.  I'm going to assume "intrapersonal" was intended (though both are applicable for this criticism).  I was under the impression I wasn't supposed to discuss my personal thoughts.  Though, it was a "self-eval".  I focused more on my achievements or lack thereof.  For the final self-eval, I will be sure to add this in.  It may not be telling in the way he thinks it though; the lack of interpersonal aspects is probably a manifestation of my psychological condition.  Really though, in the form given, it says to "focus on your achievements".  So, I don't know . . . ?

Overall: It really is good to be brashly self-confident; it really can be a valuable trait, but it also gets very old very fast -- when working with other people -- unless it is coupled with a willingness to listen and hear, to share credit generously where possible, and to take blame squarely and without weaseling when justified.
Sarcasm aside, I think this is valid criticism.  I am very confident in my abilities.  Part of that is justified by successful experience.  As far as my group is concerned, I certainly take my share of flak, and I like to think I do it honorably.  Let's face it--I'm a horrible liar, so I can't weasel out of anything by blaming it on other people, and I'm generally personable once you get past my outer, defensive shell of self-confidence.  Maybe that should go in my next self-evaluation.


Code Review


So, I made a huge code review wherein I addressed all the issues I found within the project.  I looked for code-quality issues and bugs.  The process took at least 6 hours (which happened last Sunday, if I recall correctly; I really don't, nor do I want to).  The final code review was 61/2 pages and just about 2000 words long.

I sent the code review out to my group members, who had mixed reactions.  Luckily though, as a direct result of the review, a number of bugs were fixed.  Also, other people started reviewing each others' code, which I think can only be to the good.


Thursday, April 19, 2012

Eighth and Final Client Meeting, and Menu Serialization


We had out eighth client meeting.  It went pretty well.  There was some consternation at a few things, but overall the demo succeeded.  Ackley also told us that this would be the final client meeting; that classes resume normally next week.

There's not much to say other than that the functionality is complete, and it's just bugfixes.

One issue popped up for the serializer/deserializer.  It appears that the menu objects are represented as Java objects (as they probably rightly should be).  The issue is that their internal representation is a canvas.  So, when we serialize the webpage, we serialize that canvas.  But, when we deserialize it, the canvas is deserialized, but the menu's object is not recreated.

I was not aware of this problem, and my group members only let me know about it around 10pm or so Tuesday night (the night before the client meeting).  I wondered why this was.

But, in any case, there wasn't time to fix it.  My solution was to deserialize normally, and then simply pick the canvas out, and add it to a new menu object.  However, Theo proposed treating the menu canvases as special primitively serializable types (like Integer and String).  I objected, but we eventually went with Theo's plan.  Ackley independently suggested the two solutions and made effectively the same value judgments we had about them.

So, we're working on the deserialization of menus.


Monday, April 16, 2012

Minor Serialization Update


So, apparently, there was a minor problem with the deserializer in that it would set fields to null.  Apparently, SmartGWT seems to think that setting a String field to null is actually setting it to a value.  The practical upshot is that if you set a String field to null, SmartGWT will think that that null value is important in a way that it wouldn't be had you not done anything at all.

This resulted in some stupid problems, like hovering over elements giving null, and some warnings in the console. It fell on me to fix.

So, this morning, I wrote a Python script that converted the code to check for setting things to null.  The code worked perfectly the first time it ran.


Sunday, April 15, 2012

Cleaned up Code


Well, I made a lot of the code prettier (i.e., it looks more simple).  I also renamed everything so that it's in standard Java conventions.  It irks me--because I'm a language purist--but the majority is always right, I suppose.  There's not really much else to say--as far as I know, all of my functionality is accomplished, and it's just bugfixes and code maintenance from here on out.

I'm pleased to boast that (nearly) all errors in my code were either due to a failing of GWT, or a use of the code for a purpose it was not designed.  I am not aware of any bugs in the current version of the source.  As far as I'm concerned, about the only thing left to do is to run through everything and make sure it looks nice.

I volunteered to examine everyone's code for bugs and other issues.  I will do this when I have more time and the code is more complete.  Group, if you need me to do anything in addition to this, let me know.


Wednesday, April 11, 2012

Seventh Client Meeting


Well we had our seventh client meeting.  I think it went best out of all our meetings thus far.

As an aside, it should be mentioned that I changed a few things in light of slightly shifting requirements and fixed a few bugs since last time.  They took some time, but they're pretty uninteresting to discuss--and no design issues came up anyway.

One issue that came up was how I had changed a lot of fields from private to protected.  I explained that this is because those fields were used in an inner class, which technically doesn't have rights to private members.  However, the Java specification allows this (see 8.8.9), but it's technically discouraged.  If you set your compiler warnings high enough, you'll get it.

The other issue was the code review.  Ackley looked almost exclusively at Alex's code, so I felt kinda bad for him when Ackley ragged on it.

However, his complaints were pretty trivial, and were mostly stylistic (lowercase class names, e.g.).  I think this is overreacting and irrelevant.  If we want to use a different coding style, it should be up to us, really.  Coming from a strong C background, all my classes are lowercase; both myself and the rest of the group were therefore pleased that Ackley didn't happen to see any of my code.

In addition (and despite my denial of this), my code is apparently very dirty looking.  That's probably because it implements the most complex algorithms, is poorly commented, and makes non-standard use of syntax.  For next week, my primary concern will be to change my code so as to look simpler than it really is--because that's apparently what is expected of Java programmers.  Also, by fiat, I'm changing my code to use standard Java naming conventions.