Hi,
As catchup from last time:
-With the parser complete, serialization and deserialization of raw Canvas-es is next. This is necessary for saving and loading.
-The parser may not actually be complete; more formatting may be required and there are other issues.
-Had a client meeting. It went poorly.
The serialization and deserialization is pretty straightforward so far. It uses a slightly modified version of the standard Java serialization routines. It's not fully functional (it doesn't reconstruct everything properly yet), but it's in-place and a good start. Nialls will pass it the actual canvases, and then the real fun will begin: getting it working with "real" data.
The parser is annoying me. It turns out I actually wrote pure XML parser instead of an HTML parser. So I'll need to make some *significant* changes. I'm thinking of resurrecting regular expressions. I'm dedicating this afternoon/evening to doing this.
We also had our fourth client meeting. Honestly, I think it went the worst out of all client meetings thus far.
I think a lot of this had to do with the group not being very productive over Spring Break. I freely admit that I definitely slacked, and I feel bad about it, particularly since my modules were least integrated out of everyone's.
I feel like I didn't get credit for making the serializer/deserializer from Ackley. Yes, it wasn't fully integrated, but *it worked*. I also feel like Spring Break ought to be a break. I know that the reality of it is that work happens over Spring Break and that I'm expected to do things. But I still think it's problematic to call it a "break" if it really isn't to our society. Same applies to Christmas Break, for year-long classes. In the extreme, Summer, for some summer assignments.
So, for next time, the serializer/deserializer, and a revised parser.
Ian
Wednesday, March 21, 2012
Friday, March 16, 2012
Parser Complete
Hey,
I'm pleased to announce the alpha version of the parser! The parser can take any GWT canvas and convert it into HTML, the formatting of which can be adjusted to as desired. Additionally, it can take HTML and make inferences to make it valid HTML (this is important because GWT outputs non-standards-compliant HTML).
Currently, the parser can be customized to output/not output newlines and pipe characters (for viewing alignment) and whether tags are capitalized/not. I didn't really know what other options to add, but it should be trivial to add them.
The thing is pretty robust, in that it will take any HTML you could possibly throw at it. It will even detect some problems (e.g., "<div class=a=b>") and let you know about them. I can't yet give it my (imaginary) gold seal of approval, but it's definitely solid enough for alpha.
Anyway, this concludes my original goal of getting the parser working. The parser is fully integrated into Web_Final, and is ready for use. All changes have been committed.
TODO:
1. parser does not attempt to find redundant or useless code (e.g., "<div></div>" . . . I (think?) is useless).
2. Do we, or do we not want HTML to GWT conversion? Depending on the answer to 1., this may be as simple as removing the useless code and then feeding the generated HTML back into a canvas object. But I honestly haven't looked into it.
Thanks,
Ian
I'm pleased to announce the alpha version of the parser! The parser can take any GWT canvas and convert it into HTML, the formatting of which can be adjusted to as desired. Additionally, it can take HTML and make inferences to make it valid HTML (this is important because GWT outputs non-standards-compliant HTML).
Currently, the parser can be customized to output/not output newlines and pipe characters (for viewing alignment) and whether tags are capitalized/not. I didn't really know what other options to add, but it should be trivial to add them.
The thing is pretty robust, in that it will take any HTML you could possibly throw at it. It will even detect some problems (e.g., "<div class=a=b>") and let you know about them. I can't yet give it my (imaginary) gold seal of approval, but it's definitely solid enough for alpha.
Anyway, this concludes my original goal of getting the parser working. The parser is fully integrated into Web_Final, and is ready for use. All changes have been committed.
TODO:
1. parser does not attempt to find redundant or useless code (e.g., "<div></div>" . . . I (think?) is useless).
2. Do we, or do we not want HTML to GWT conversion? Depending on the answer to 1., this may be as simple as removing the useless code and then feeding the generated HTML back into a canvas object. But I honestly haven't looked into it.
Thanks,
Ian
Sunday, March 11, 2012
Project Mid-Semester Self-Evaluation
Hi,
I wrote my self-evaluation.
I honestly only see a marginal purpose in it: I understand the rationale for a self-evaluation, but I somewhat object to the notion of it being the programmer doing it (I was under the impression that evaluation was a function of a manager. Am I doing a manager's work?). Putting it in writing is also annoying, although I do recognize the force of having something in that medium to refer back to later as a concrete reference.
In any case I gave it a go, and, as near as I can tell, executed the assignment well. If the client has any problems with what I did, I'd appreciate knowing about it in advance so that I may fix them (although I understand if that's unreasonable).
Thanks,
Ian
I wrote my self-evaluation.
I honestly only see a marginal purpose in it: I understand the rationale for a self-evaluation, but I somewhat object to the notion of it being the programmer doing it (I was under the impression that evaluation was a function of a manager. Am I doing a manager's work?). Putting it in writing is also annoying, although I do recognize the force of having something in that medium to refer back to later as a concrete reference.
In any case I gave it a go, and, as near as I can tell, executed the assignment well. If the client has any problems with what I did, I'd appreciate knowing about it in advance so that I may fix them (although I understand if that's unreasonable).
Thanks,
Ian
Scratch Regular Expressions
Hi,
We had another group meeting this Sunday, and we got everyone on the same page for the project. In particular, we fixed a lot of issues pertaining to project setup that were preventing most people from getting anything working. Apart from a delay due to DST, the meeting went well.
I have been working on the regular expression matcher--or, more precisely, I was. I decided that regular expressions are messy and overkill for the application (purpose being merely to reformat the GWT output).
Instead, the new plan is to use a simple algorithm (string search) to find and format tags. This is simpler and cleaner. In addition, it has the advantage of being strongly linear time (which is only the best case for regular expressions). I could throw in some flak about Java not supporting pointer arithmetic, but at this point, I'm just glad that I'm writing algorithms :-)
Additionally, there will need to be a formatter API for the parser. This is implemented as a simple class that can (optionally) be passed to .generate(...). The class is analogous to a "struct", in that the point is to set various data fields, with others being set to defaults, and then pass it to a function.
I'm not entirely satisfied with this implementation, because the "struct" needs a public method ".apply()", which applies the struct's data values to an input string. It's paradoxical because this method must be public so that the parser can call it, but only the parser needs it. So, I'm violating encapsulation. Yet, I can't just move the .apply() method to be a private method of the parser because that violates encapsulation (the method really should be a method of the "struct"). In C++, I'd make parser a friend class, but in Java . . .
Final notes:
-I'm creating a new project wherein I can test my parser separate from the other modules of the program. Normally, I wouldn't care, but GWT is too unreliable and slow to fit my mandate of obscene amounts of runtime testing. It's a code quality thing.
-I'm working on the project mid semester self-evaluation (http://cs.unm.edu/~Ackley/460/selfEvaluation.html). I'm . . . not psyched.
Ian
We had another group meeting this Sunday, and we got everyone on the same page for the project. In particular, we fixed a lot of issues pertaining to project setup that were preventing most people from getting anything working. Apart from a delay due to DST, the meeting went well.
I have been working on the regular expression matcher--or, more precisely, I was. I decided that regular expressions are messy and overkill for the application (purpose being merely to reformat the GWT output).
Instead, the new plan is to use a simple algorithm (string search) to find and format tags. This is simpler and cleaner. In addition, it has the advantage of being strongly linear time (which is only the best case for regular expressions). I could throw in some flak about Java not supporting pointer arithmetic, but at this point, I'm just glad that I'm writing algorithms :-)
Additionally, there will need to be a formatter API for the parser. This is implemented as a simple class that can (optionally) be passed to .generate(...). The class is analogous to a "struct", in that the point is to set various data fields, with others being set to defaults, and then pass it to a function.
I'm not entirely satisfied with this implementation, because the "struct" needs a public method ".apply()", which applies the struct's data values to an input string. It's paradoxical because this method must be public so that the parser can call it, but only the parser needs it. So, I'm violating encapsulation. Yet, I can't just move the .apply() method to be a private method of the parser because that violates encapsulation (the method really should be a method of the "struct"). In C++, I'd make parser a friend class, but in Java . . .
Final notes:
-I'm creating a new project wherein I can test my parser separate from the other modules of the program. Normally, I wouldn't care, but GWT is too unreliable and slow to fit my mandate of obscene amounts of runtime testing. It's a code quality thing.
-I'm working on the project mid semester self-evaluation (http://cs.unm.edu/~Ackley/460/selfEvaluation.html). I'm . . . not psyched.
Ian
Wednesday, March 7, 2012
Third Client Meeting
Hi,
Well, the third client meeting has come and gone. Honestly, once again, I think it went pretty well. I think we've got the presentation format down fairly solidly: a brief summary of last week's accomplishments, and focus for future work in the coming time ahead, followed by a demo with specific questions deferred to those who know best.
As for me, the parser is functionally complete. It parses all GWT canvases into HTML flawlessly, as far as I can tell. The only drawback is that the generated HTML is horrible. I decided to forgo recursive descent parsing in favor of letting GWT do the heavy lifting. Ultimately, this should (maybe? I don't know, given GWT's robustness record) be more stable and resilient to improvements group members add that take advantage of more features of GWT. However, in classic GWT bloatedness, the HTML has only limited customization options--and nothing is able to resolve redundant and useless code (e.g. "<div></div>").
My solution? Write a regular expression meta parser/converter for the HTML parser's output! This should at least be interesting, and will have the benefit that we will have beautiful control over the generated HTML. In contrast to GWT, I will ensure that there is a clean API for this.
By next time, I hope to have at least a start on doing this.
Other notes on the meeting:
-User stories appear to be wanted.
-I speculated that perhaps we could serialize and deserialize Canvases to save them and restore them. This may not be possible, although I don't know why you can't just subclass Canvas and add "implements Serializable". Maybe some internal thing?
Ian
Well, the third client meeting has come and gone. Honestly, once again, I think it went pretty well. I think we've got the presentation format down fairly solidly: a brief summary of last week's accomplishments, and focus for future work in the coming time ahead, followed by a demo with specific questions deferred to those who know best.
As for me, the parser is functionally complete. It parses all GWT canvases into HTML flawlessly, as far as I can tell. The only drawback is that the generated HTML is horrible. I decided to forgo recursive descent parsing in favor of letting GWT do the heavy lifting. Ultimately, this should (maybe? I don't know, given GWT's robustness record) be more stable and resilient to improvements group members add that take advantage of more features of GWT. However, in classic GWT bloatedness, the HTML has only limited customization options--and nothing is able to resolve redundant and useless code (e.g. "<div></div>").
My solution? Write a regular expression meta parser/converter for the HTML parser's output! This should at least be interesting, and will have the benefit that we will have beautiful control over the generated HTML. In contrast to GWT, I will ensure that there is a clean API for this.
By next time, I hope to have at least a start on doing this.
Other notes on the meeting:
-User stories appear to be wanted.
-I speculated that perhaps we could serialize and deserialize Canvases to save them and restore them. This may not be possible, although I don't know why you can't just subclass Canvas and add "implements Serializable". Maybe some internal thing?
Ian
Monday, March 5, 2012
Mid-Parser and the Importance of Software Engineering
Hi,
The parser proceeds well. I'm currently refactoring the code to be more modular and robust, as well as cleaner. I have my own subpackage in the solution, and I'm going to fill it with as many files as I need to make the architecture pretty.
In terms of functionality, I wasn't able to accomplish anything over the weekend. If you must know, I instead wrote a GPU raytracer for rendering 3D fractal geometry, complete with distance estimators, Phong shading, and frustum clipping. Woe that this isn't a graphics project.
However, I had planned on doing that; the parser will still be advanced in time for the next client meeting on Wednesday. Positioning will be in place. In fact, I anticipate, the way things are going, for the parser to be just about completed, with minor functionality to be added as new features are made accessible by the GUI.
Meanwhile, GWT is being snarky again. Actually, strictly speaking, not "snarky". That word is closer to "sassy" or "cheeky", and at least implies some level of sophisticated defiance. No, GWT is being outright stupid. My primary complaint right now (because I'm not so directly working with it) is that it's not robust. It takes like ten seconds to start up, and when it does, half the time there's some internal error. I've found that restarting Eclipse usually helps. But, I am frustrated that something that's supposedly super-awesome can't even get out the starting gate when you try to use it. And, I'm immediately suspicious of something that runs differently each time. It brings to mind thread contention issues and broken dependencies. And I'd be worried about that except GWT is necessarily single-threaded. . . . which still leaves the question: why can't GWT work perfectly every time? Is that too much to ask?
It brings up an interesting point about software engineering. I consider myself much more a computer scientist and programmer, instead of a software engineer. The difference is subtle, but I talk about it a bit here.
Nevertheless, I continually get the feeling that for some reason my code is inherently better than code produced in the "real world". It is endlessly annoying to have to work around someone else's bug in a library, or to write wrappers around broken APIs so that they're usable. Yet somehow, for some reason, my code always manages to be fast, flexible, and, above all, robust. I frequently (weekly or so) receive emails from satisfied users of my libraries praising their "beautiful API[s]" and robustness. In one coder's words:
The point is not to demonstrate that I'm a better person or something--the issue is one of design. Better-designed code tends to work better. Do I just pay more attention to that than other people? These questions go through my head rather more often than I'd normally care to admit, and they are of particular relevance as I rework the parser. Group members: you may expect robust, powerful, and well-designed code.
But it all brings me back to GWT. I'm not going to speculate on why it can't reliably start, but it suffices to say that it makes debugging extremely annoying, so long as "extremely" is VERY strongly emphasized. I think I may start a separate project, and run the parser on GWT objects that have been saved out and serialized. I wager it would be faster--though, the way things are going, I wouldn't be (too) surprised if GWT has some meaningless constraint that prevents you from doing this.
So, project-wise and in sum: the parser will be next to done by Wednesday. Furthermore, it will live up to my standards of design. GWT is annoying. We'll see how it plays out.
Ian
The parser proceeds well. I'm currently refactoring the code to be more modular and robust, as well as cleaner. I have my own subpackage in the solution, and I'm going to fill it with as many files as I need to make the architecture pretty.
In terms of functionality, I wasn't able to accomplish anything over the weekend. If you must know, I instead wrote a GPU raytracer for rendering 3D fractal geometry, complete with distance estimators, Phong shading, and frustum clipping. Woe that this isn't a graphics project.
However, I had planned on doing that; the parser will still be advanced in time for the next client meeting on Wednesday. Positioning will be in place. In fact, I anticipate, the way things are going, for the parser to be just about completed, with minor functionality to be added as new features are made accessible by the GUI.
Meanwhile, GWT is being snarky again. Actually, strictly speaking, not "snarky". That word is closer to "sassy" or "cheeky", and at least implies some level of sophisticated defiance. No, GWT is being outright stupid. My primary complaint right now (because I'm not so directly working with it) is that it's not robust. It takes like ten seconds to start up, and when it does, half the time there's some internal error. I've found that restarting Eclipse usually helps. But, I am frustrated that something that's supposedly super-awesome can't even get out the starting gate when you try to use it. And, I'm immediately suspicious of something that runs differently each time. It brings to mind thread contention issues and broken dependencies. And I'd be worried about that except GWT is necessarily single-threaded. . . . which still leaves the question: why can't GWT work perfectly every time? Is that too much to ask?
It brings up an interesting point about software engineering. I consider myself much more a computer scientist and programmer, instead of a software engineer. The difference is subtle, but I talk about it a bit here.
Nevertheless, I continually get the feeling that for some reason my code is inherently better than code produced in the "real world". It is endlessly annoying to have to work around someone else's bug in a library, or to write wrappers around broken APIs so that they're usable. Yet somehow, for some reason, my code always manages to be fast, flexible, and, above all, robust. I frequently (weekly or so) receive emails from satisfied users of my libraries praising their "beautiful API[s]" and robustness. In one coder's words:
". . . the API is cleasn[sic], crisp[,] and compact--yet still powerful. Your code is astoundingly bug-free and my only problem[s] come from me being completely retarded. Using your code is like breathing freely."I myself hardly ever have the opportunity to send such mails. I typically send bug reports.
The point is not to demonstrate that I'm a better person or something--the issue is one of design. Better-designed code tends to work better. Do I just pay more attention to that than other people? These questions go through my head rather more often than I'd normally care to admit, and they are of particular relevance as I rework the parser. Group members: you may expect robust, powerful, and well-designed code.
But it all brings me back to GWT. I'm not going to speculate on why it can't reliably start, but it suffices to say that it makes debugging extremely annoying, so long as "extremely" is VERY strongly emphasized. I think I may start a separate project, and run the parser on GWT objects that have been saved out and serialized. I wager it would be faster--though, the way things are going, I wouldn't be (too) surprised if GWT has some meaningless constraint that prevents you from doing this.
I also found a curious little method Canvas.getInnerHTML(), which appears to return a whole lot of nonsense. It looks like some of it might be useful, but it's clearly no substitute for real parsing. Which reminds me, back to that design thing: one good design principle is to avoid name collisions. I solve this with namespaces, and by naming my functions and classes intelligently. At the very least, prefixing with some easy to recognize identifier. In Java, the evidently accepted solution is to use different capitalization, because apparently that's so much cleaner. On right, what Eclipse has to say about the unrecognized symbol "HTML". Terse and uniform APIs? Mmmmm no. |  |
So, project-wise and in sum: the parser will be next to done by Wednesday. Furthermore, it will live up to my standards of design. GWT is annoying. We'll see how it plays out.
Ian
Friday, March 2, 2012
Second Client Meeting
Hi,
Well, in contrast to last time, our presentation this time went very well. We were much better organized and we covered the material linearly and logically.
However, I also think that there were some issues. The most noticeable was our use of time. We were cut somewhat short on time. I was under the impression that we had 15 minutes. Apparently, we have 10.
In any case, Ackley apparently doesn't care about PowerPoints. That's fine; we can work with that.
Solution: future presentations will be all demo, and as we show various sections, group members will discuss their contributions. This should be more entertaining and make better use of time.
Ian
Well, in contrast to last time, our presentation this time went very well. We were much better organized and we covered the material linearly and logically.
However, I also think that there were some issues. The most noticeable was our use of time. We were cut somewhat short on time. I was under the impression that we had 15 minutes. Apparently, we have 10.
In any case, Ackley apparently doesn't care about PowerPoints. That's fine; we can work with that.
Solution: future presentations will be all demo, and as we show various sections, group members will discuss their contributions. This should be more entertaining and make better use of time.
Ian
Subscribe to:
Posts (Atom)