Presentation Practices and Final

Hi,

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:

Presentation:

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

Demo:

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

Thanks,
Ian

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.

Fifth Client Meeting

Hi,

Well, actually, the meeting went better than I had previously expected.  However, there was a LOT that could have gone better.

Notably, the serializer and deserializer worked pretty well, with issues.

Somehow, the parser didn't work at all.  This is problematic, particularly since I didn't change the code since last night, when it did.  This means that someone changed the code so that it's passing in garbage to the parser, so it either gives a warning and crashes, or produces erroneous output.  I was very disappointed in this.  It should have worked perfectly, and I was looking forward to showing it off.

That said, at least internally, we have a proof of concept.  As a group, we know all of the technology in play will be fundamentally valid.  It's just a matter of getting it to work properly.

Let's do this.

Ian

Updates

Hi,


So, the serializer and renderer are not completed.  Those were my areas of responsibility.  While I think that the fact that they are not yet completed is a product of factors that aren't all of my doing, I personally said I would get these done, so it's ultimately my fault.  If worst comes to worst, I'll take the blame for it.

Now.  Not all is lost, of course.  The deserializer is coming along.  That will need to be finished.  The serializer *should* be done already.

As far as rendering, I am pleased to announce that the key link between GWT's retarded API and my HTML parser has been discovered (albeit through some particularly nasty recursion)!  As a result, the renderer can now take a canvas and spit out HTML that corresponds to it.  It's not perfect, but I think it will satisfy for tomorrow (next client meeting).  As proof, see this HTML file from the generator: http://cs.unm.edu/~imallett/other/460/Untitled-2.html.

Thanks,
Ian

Serializer and Converter

Hi,

I finished the basics of the serializer.  It serializes all children.  A couple of fields are still incorrect, but they're not as important.  I subsequently released control of the module to the group to improve.

Now, as far as the HTML converter is going, it's not.  Don't get me wrong; the parser, formatter, and synthesizer described here: http://iancs460.blogspot.com/2012/03/revised-parser.html are all working perfectly!  The renderer just isn't.  Right now, all that's happening is the renderer is calling "canvas.getElement().getInnerHTML()".  This produces the final output:

<html>
  <head>
    <title>
      [PAGE TITLE HERE]
    </title>
  </head>
  <body>
    <div id="isc_7P" eventproxy="isc_WebPage_0" class="normal" style position: relative; z-index: 201872; visibility: hidden; background-image: url(http://1.bp.blogspot.com/-h-aleanaggc/tcbtz8mgaai/aaaaaaaaalq/hofsrycnkle/s320/checker.png); overflow-x: visible; overflow-y: visible; left: 5px; top: 5px; width: 1373px; height: 936px; background-repeat: repeat repeat; onscroll return isc_webpage_0.$nd()>
      <div id="isc_7Q" eventproxy="isc_WebPage_0" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201872;CURSOR:default;">
        &nbsp;
        <div id="isc_7R" eventproxy="isc_Canvas_17" class="normal" style="POSITION:absolute;LEFT:0px;TOP:0px;WIDTH:1373px;HEIGHT:902px;Z-INDEX:201890;OVERFLOW:visible;" onscroll return isc_canvas_17.$nd()>
          <div id="isc_7S" eventproxy="isc_Canvas_17" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201890;CURSOR:default;">
            &nbsp;
          </div>
        </div>
        <div id="isc_7T" eventproxy="isc_Canvas_16" class="normal" style position: absolute; z-index: 201908; overflow-x: visible; overflow-y: visible; left: 0px; top: 0px; width: 1373px; height: 936px; onscroll return isc_canvas_16.$nd()>
          <div id="isc_7U" eventproxy="isc_Canvas_16" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201908;CURSOR:default;">
            &nbsp;
            <div id="isc_7V" eventproxy="isc_WebPageCanvas_3" class="header" style position: relative; z-index: 201926; overflow-x: hidden; overflow-y: hidden; left: 0px; top: 0px; width: 1373px; height: 135px; onscroll return isc_webpagecanvas_3.$nd()>
              <div id="isc_7W" eventproxy="isc_WebPageCanvas_3" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201926;CURSOR:default;">
                &nbsp;
              </div>
            </div>
            <div id="isc_7X" eventproxy="isc_WebPageCanvas_4" class="body" style position: relative; z-index: 201944; overflow-x: hidden; overflow-y: hidden; left: 0px; top: 10px; width: 1373px; height: 722px; onscroll return isc_webpagecanvas_4.$nd()>
              <div id="isc_7Y" eventproxy="isc_WebPageCanvas_4" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201944;CURSOR:default;">
                &nbsp;
              </div>
            </div>
            <div id="isc_7Z" eventproxy="isc_WebPageCanvas_5" class="footer" style position: relative; z-index: 201962; overflow-x: hidden; overflow-y: hidden; left: 0px; top: 20px; width: 1373px; height: 45px; onscroll return isc_webpagecanvas_5.$nd()>
              <div id="isc_80" eventproxy="isc_WebPageCanvas_5" style="POSITION:relative;VISIBILITY:inherit;Z-INDEX:201962;CURSOR:default;">
                &nbsp;
              </div>
            </div>
          </div>
        </div>
      </div>
    </div>
  </body>
</html>

This looks pretty good, but it doesn't render anything else.  I suspect this may be due to it's not calling the same on its children?  In which case, the fix might be simple.  If not . . .

See also: http://stackoverflow.com/questions/9855735/get-smartgwt-canvas-as-html

Ian

Progress

Hi,

Well, we're making progress.  On the serializer, the correspondence between the input and the output is nearly one-to-one in the ways that matter.  The problems are the "left" data field is not being set, and the children are not being serialized.

I don't know why the first is the way it is, but the second is due to me simply not implementing it yet because it's hard.  However, I'm about to go do that now.  Hopefully by tonight or tomorrow evening the "serializer"/"deserializer" will do everything it needs.

I'd also like to note that Nialls has done a nice job improving our home page.  There are now joke testimonials and a cleaner layout.  I think I might like to work on some web design soon, seeing as the algorithms section of this project is nearly wrapped up.

Ian

"Serializer" Hacks

Hi,

Well, GWT is broken and buggy as ever.  For instance, the methods .getEdgeSize() and .getExtraSpace() both fail on a newly created canvas with a NullPointerException.  Turns out that typing too fast (e.g., my auto log-on script) can crash GWT, as well as certain properties.  GWT at least catches errors and gives you nice feedback if you do some things (like call some methods after construction).  Though, I'm not sure how you call a message before construction?  And yes, GWT still crashes every now and again, which is . . . disconcerting.

The API is inconsistent between the getters and setters, which made matching everything up a huge ordeal.  Not to mention that the API has (literally!) about 200 getters and setters.  Not all of them are necessary, probably--but how am I to know?  The code is horribly messy (notably because Java doesn't have function pointers, nor macros) too.

It does kinda remind me, though, of how slow the whole thing is.  GWT takes forever to start, then the website has to load up.  Then you have to click login, wait for the window to come up, enter your username/password, click send, wait for that to go through, open a new project, and *then* you can click "save", and actually run a single test!  Our code isn't exactly slow per-se; the process to do something is just soooo long!

In any case, after much complaining and whatnot, the serializer/deserializer kinda works.  A canvas can be taken in, serialized, and then deserialized.  I don't know if the correspondence is one-to-one in the important ways (except for what I know isn't, like recursively evaluating children), but it's a strong start.

Tomorrow (today) I'll finish it up.  I DO have other classes too, so I'll need to work on that as well.  It's just about 1:45AM, so, knocking off for the night.  See you bright and early.

Ian

Serialization Update 2

Hi,

Well, the serialization fiasco has mostly been figured out.

It turns out that yes, my serializer does work.  Moreover, it works perfectly, and everything would be good . . . except that the deserializer does not.  As it happens, Java's deserialization is, put simply, broken.  There's nothing for it.  In real life (C++) I'd use a copy constructor, and that would be the end of it, but Java apparently can't handle that.

Unfortunately, the deserializer doesn't, and can't work, unless the GWT designers had thought of it, which they didn't.  We'd be stuck, except Joe Collard put into words what I was coming to the realization was necessary (on same post by Nialls mentioned previously, here): "see if you can write a wrapper that contains all of the things you will want saved".

Essentially, the idea boils down to: write your own serializer.  It's bloody messy, but Java's (de)serialization is broken and reflection isn't supported by GWT.  So, we have to go with it.

No private/protected fields can, of course, be serialized.  Hopefully this shouldn't be an issue.  It appears to have worked for Joe's group, so hopefully it will work for ours.

Ian

Serialization Update

Hi,


So, when running the serializer, GWT will produce errors:

[ERROR] [web_final] - Errors in 'file:/C:/dev/Java/CS%20460%20Project/Web_Final/src/cs460/webdnd/client/utilities/serialization/serializer.java'
 [ERROR] [web_final] - Line 24: No source code is available for type java.io.ByteArrayOutputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 25: No source code is available for type java.io.ObjectOutputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 39: No source code is available for type java.io.InputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 39: No source code is available for type java.io.ByteArrayInputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 40: No source code is available for type java.io.ObjectInputStream; did you forget to inherit a required module?
 [ERROR] [web_final] - Line 47: No source code is available for type java.lang.ClassNotFoundException; did you forget to inherit a required module?


In response to this, Nialls took over serialization/deserialization using code he found online.  This code produces tons of errors, as he writes here: http://niallsc.blogspot.com/2012/03/canvas-serialization-status-failed.html.


However, this misses something--my serializer worked.  It produces this output (if you add a print statement):

Now, this looks to me like taking a canvas and serializing it (and I can get a canvas back, deserializing it).  I'm not sure what the problem is with Nialls's code, but mine seemed to work.

I feel somewhat accused, but I submit the above as evidence that the code I wrote is working properly.  There were limited tests with more complex canvases (nested, with content, etc.) that were conducted some time ago, successfully.  It is possible that there is some new problem (like maybe a certain component can't be serialized) which can be solved in the same way as the canvas's serialization was.

Now, I don't know what to say.  Maybe there's something subtle going on that I'm missing.  Maybe I don't know what I'm talking about.  Maybe there's a fundamental flaw in this that really will somehow prevent this from working.  I welcome explanations.

Regardless, I think it's a good idea to meet Sunday as Nialls suggested to work this out.  For the good of the project, it needs to be solved sooner rather than later--and I had already thought it was solved.

Thanks,
Ian

Serializer/Deserializer

Hi,

So, since last time, I have added a new class "CanvasSerializable", which is a direct subclass of "Canvas", except it adds support for serialization.  If every canvas is serializable, then making the serializer work properly is much easier, and allows for better design.

The changes affected a lot of the project, so I changed every single reference to Canvas to CanvasSerializable, and then converted things back that just flat out couldn't be (e.g., GWT callbacks return Canvas[], so I can't upcast them to CanvasSerializable).

This seems to have had an effect already.  The serializer appears to be working properly.  There's still some problems on the server-side (I think) so serializing doesn't quite work.  Because there's no serialized data, naturally, the deserializer doesn't work either.

Hopefully, over the next few posts, the serializer module may be completed!

Ian

RSA Cryptography

Hi,

I wrote a little cryptography module.  It implemented a (theoretically) fully secure RSA cryptosystem.

This turned out to be harder than anticipated.  In addition to jogging my memory of RSA, implementing it in Java is a nightmare (exercise of actual real programming).

It turns out that there are two different APIs for this.  The one most directly implemented by Java has a bug that prevents it from working except when writing to a file.  The second is also too buggy to use.

So, I decided to write my own implementation.  It turns out that there are a number of (buggy) Java implementations.  These fail in a number of cases, (usually when a message is too long).  Obviously, real RSA doesn't crash.  I ended up basing my solution on an existing RSA implementation and then rewriting half of it to actually work.

In the process, I also tried compressing the RSA output stream.  It turns out that the Java "Inflate" class has a bug that causes it to hang on the general kind of data that can be produced by compressing an RSA stream.

I can't really do anything about that, because if I were to try to fix all the bugs in the JRE, I should at least get paid--and anyway, at this time, there are more pressing matters, such as serialization, updates concerning which should appear on the next post.

Ian

Compression

Hi,

Well, I took a little break from doing parsing and serialization whilst I wait for others to get set up to use the serializer/deserializer.

Some, especially Alex, expressed concern that serialized data or the generated HTML would be very large and difficult to send.  So, I wrote a compression wrapper around Java's Inflate/Deflate APIs.  It turns out that Java's String.getBytes(...) method is broken, which made this difficult.  After some false starts, I finally just gave up trying to work around their bugs and just wrote out what the methods were supposed to do myself.

The algorithm is the standard ZLIB compression algorithm, which should be able to achieve very good compression rates.

I may try writing an encryption algorithm as well.

Ian