Midterm Evaluations

Hi,

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


Comments:


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.

Thanks,

Ian

Code Review

Hi,

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 6¹/₂ 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.

Thanks,
Ian

Eighth and Final Client Meeting, and Menu Serialization

Hi,

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.

Ian

Minor Serialization Update

Hi,

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.

Thanks,

Ian

Cleaned up Code

Hi,

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.

Thanks,
Ian

Seventh Client Meeting

Hi,

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.

Ian

New Combination Logic

Hi,

Well, I got a lot done.

The group decided that we'd go with combining everything into a single hierarchy.  This has a few disadvantages, but as it happened it worked out well.

With respect to the new algorithm, it turns out that:

1. The algorithm is (genuine surprise) simpler.  This is partly because:
2. Positioning no longer needs to be changed explicitly.
3. Technically, the first two levels of hierarchy are combined, instead of merely the first, just because of how SmartGWT implements it.
4. In the rendered HTML, the page's canvas cannot have its own background color differing from the template's.  To do this, you will now need to make a div the size of the canvas and then fill it with color.  This is a direct consequence of merging the hierarchy, and is one of the disadvantages.  It may be necessary to try to merge the page's and the template's top level hierarchies, instead of just choosing one.  I may need some help with the HTML.
5. The renderer will now attempt to figure out if something has a menu or not--no more passing in flags.  The algorithm checks for menus in the template AND in the page and will move them up (in the event of more than one menu being found (which shouldn't happen, I hope), the menus will have the same z-index and will be on top of each other).
6. The algorithm *should* be safe on all valid data (e.g., you shouldn't be able to crash it by typing "<" in a string or something).
7. The algorithm still fails if the canvas has overflown, because of a bug in SmartGWT.  The rest of the group should have been fixed already, but somehow, that's still happening.
8. The spacing between the header, body, and footer, is not yet adjustable.  When I hear back from the group members on a desired API, I'll implement it.
9. If you have more than 1000 different elements at the top level hierarchy, the Z-indexing won't move a menu past the first 999.  This makes the implementation cleaner, and it shouldn't be a problem.

As final points:

• With the code review starting next Wednesday, we need to get the commenting and unit testing up to snuff.
• If the template canvas overflows, it doesn't change the size of the index's canvas, so the two are different sizes.  This may be desirable for the footer, but I suspect it will ruin the alignment (which is relative, if you recall) if the overflow happens elsewhere.
• I fixed all the warnings in the client package.

Thanks,
Ian

Sixth Client Meeting

Hi,

We had our sixth client meeting.  It went pretty well, actually, all things considered.  Importantly, the renderer worked exactly as expected.

There was some misunderstanding about the method of moving the template's menu to the front (a problem we had encountered that I had quickly written a fix for).  Ackley suggested that the template simply be moved in front.  The issue, as I (incoherently) attempted to explain, is that the template's parent could contain other things that shouldn't be in front.  I drew a pseudocode diagram as follows:

//template's div
<div ...stuff...
    -images
    -text
    -menu
//page's div
<div ...stuff...
    -images
    -text

My current algorithm is simply to take the menu out of the first div and add it into the second.

Ackley suggested simply changing the z-index of the menu instead.  Unfortunately, HTML doesn't work this way, so that wouldn't change anything.  Then, he suggested removing both div tags so as to put all the components into the same level.  I objected that this would raise positioning problems.  This is true, but as Ackley pointed out, those are workable and just because something is hard doesn't mean it's not the right solution.  What I was intending to say was more that those div tags contain important information (among which are positioning).  This includes backgrounds, images, etc. that the page really does need to override.

Now, again, that's not to say that this is impossible.  In subsequent discussions with Theo, we established that removing the top level hierarchy is indeed possible functionally--it's just not as simple as Ackley thought.  You can't just delete the top level hierarchy.  SmartGWT adds it in for a reason, and it's more subtle than just setting up styles and positioning.  Like I said, it's not impossible to remove, but it's not something that necessarily improves the result in terms of sensibility.

This brings up another point.  The current algorithm works and could be trivially generalized for anything else we want to move.  However, it maintains the current hierarchy.  We could also do (a version of) what Ackley suggests and remove the hierarchy (or at least combine it).  Doing anything else, Ackley calls "a hack"--but I definitely think that's too narrow of a perspective.  I'm not sure what the "right" solution is--and the current algorithm has intrinsic merit--you're separating the template's stuff from the page's stuff--transferring to the page everything that really should be there in the first place, so it makes sense.

I'll admit that don't know what the "correct" algorithm is, in terms of sensibility.  But, I will be discussing this with the group, and I will ensure that we have that algorithm for next week's meeting.

Ian

Renderer Fixes and Positioning

Hi,

I looked through the renderer. The reason it was crashing was because someone passed in an incorrect URL as its final parameter. This caused an out-of-bounds error. I refactored that code so that that's outside of the renderer itself, so now it's more clear what's going on. The baseurl is a directory of the .CSS files. I don't know what that should be, because whatever it was before got changed.

Secondly, this fix automatically makes the renderer work again. However, it would still output nothing if nothing substantial is passed into it. This can happen, for example, after the renderer has already been called once (the canvases seem to get screwed up still). I can't say that was *entirely* not my fault, because half of the problem had to do with an undocumented bug in GWT, which in turn caused a problem in my code. Anyway, I fixed it, and the output corresponds to the input in all test cases I've tried.

However, someone changed the positioning to relative positioning, so the positioning-hack for superimposing the template and pages doesn't work anymore. I understood this was going to happen eventually, so it's not unexpected. I then figured out an algorithm to get relative positioning working. It's pretty simple, and I kept the old algorithm just in case. It correctly positions both the headers and footers. There's still a problem, though. The height of the template's footer is 34px. The height of other pages' footers is the default, 100px. I suspect this to be a bug somewhere else. Once this is fixed, I'll finish up the position algorithm by getting the footers' positioning working.

Thanks,
Ian

P.S.: The whole thing about the (de)serializer and renderer changing the editor afterwards? It turns out that new canvases don't go away unless you explicitly kill them with .destroy()--garbage collection evidently doesn't do anything. This was news to me, anyway. I haven't observed the problem with the (de)serializer, so perhaps Theo figured this out too. Anyway, I've also added fixes to the renderer to solve that as well.