Project Description: You may not have realized it if you browsed into this page from my resume, but the resume itself is a part of my portfolio! Wanting to demonstrate the power of XML and XSL and some practical applications thereof, I decided to change my resume so that it is completely XML-data driven. I arrived at this decision since I found myself not keeping my resume very current, since each change meant I had to track down all copies and formats of my resume and also make the same changes there. Now I can have even more formats, with one central location for the information. Isn't XML cool? The next part of this project was just completed also: make this portfolio itself XML / XSL driven. The information here is a good fit for XML. This whole effort took approximately 2-3 hours. I chose to only do HTML format for now.
Project Scope: XML creation, XSL to convert the XML to many formats, namely: HTML, plain text, and even PDF.
My role: I came up with the idea and was the sole implementer. (IE, this was no school project).
Successes: The HTML and plain text resumes were very easy - a few hours a piece. It helped that I already had my resume in these two formats, and was able to simply write the XSL to mimic them. I also had already gone through the XSL learning curve with my work on the Serac Mountaineering web page. I hadn't gone through the XSL:FO learning curve yet, however.
Failures: I need to do some non-XSL post processing on the plain text version, to do good line wrapping.
What I Learned: FOP is not as difficult as it seems, there are just an overwhelming number of options available to use. I learned a lot more about the correct use of recursive templates in XSL. Also, while writing the text file wrapper to make the plain-text resume look good, I was able to apply and be convinced of the value of TestFirst. I used JUnit as my unit testing framework, wrote failing tests first, then created code to make the tests run. I found this improved my code design, forcing me to think through all of the issues. Also, once the code was finished, I had a high degree of confidence in it. I also was able to refactor the code without fear of breaking it. (and I probably will do this again and again as I think of more efficient word-wrapping algorithms). I did this due to XP (eXtreme Programming, not Windows XP) being on my brain a lot lately. Also, while doing the portfolio part of this project, the correct method of XSL design really "clicked" in my brain. The whole XSL sheet includes no looping or if statements, yet only outputs some tags conditionally. I still have many, many things to learn about XSL, but it is great to have conquered the general programming paradigm that is used in XSL.
Source Code:Note: all of the XSL files referenced here are actually "txt" files, since my free web hosting company thinks I am actually trying to run the XSL scripts, not offer them for your viewing enjoyment. (It's a complicated mime-type thing). You'll just need to know that if you shift-click on them and save them off.
Note: These require an XSL parser. I use xalan. Also, the PDF XSL sheet requires FOP. Note that the HTML resume and portfolio XSL stylesheets actually create XML; you need to run these intermediate files through template.xsl to get HTML output. I use this pattern often so that the look and feel of the site is changeable without needing to change every source document. The template.xsl file above is that for my personal web site.
You may also note that I have RTF and DOC versions of my resume, but there is no corresponding XSL sheet for those types. I cheated here a little, and let Microsoft Word(Office 2000) do the work for me. I created a macro that saves out a document to RTF and DOC format then exits. Then I start up word with the HTML form of my resume, executing the macro (command line switch, "/mmacroname"). Maybe I should have done that with the text version, to get the line wrapping for free, but the technology demo was worth it. (And, I cannot control how Word presents my resume in plain text).
Project Description: With my work, I have had the opportunity to work with a few of the Open Source Projects in the industry. And, with some luck, I'll have some of my submissions taken in. Primarily I have been working with JBoss, a J2EE Application Server, and with the Jakarta Ant build tool.
Project Scope: With Ant, I have been porting the core file-system touching pieces to support Novell NetWare. I also recently had the opportunity to provide an XSL script for one of the optional Ant Tasks (JDepend, a code quality tool).
My role: With the JDepend piece, there was already an XSL sheet that produced one large HTML document that summarized the results. Some of the other similar reporting XSL sheets (for the JUnit task, mmaudit, etc) outputed to a "JavaDoc" or framed output. This greatly improves navigation through the results. One of the Ant contributors posted that he wished such a thing existed for JDepend and, realizing I had the abilities and the time, I hammered out just such a stylesheet.
Successes: I was able to create a very easy to read and simple to use HTML form of the JDepend results that will be useful for a long time to come. The first OSS submission of mine with my name down as the author! (Other file system contributions were simply edits to existing files)
Failures: I didn't realize that a different CSS stylesheet was necessary to make it look more "Jakarta-like", since I just used the existing CSS in the non-frames version. But, Stefane Baillez fixed that up for me upon committing my file.
What I Learned: I learned a lot about the XSL redirect extension function, which this makes good use of.
Source Code:Commited to ant source - jakarta-ant/src/etc/jdepend-frames.xsl. Go to jakarta.apache.org/ant/ and get the source code, or get it from the CVS repository.
Hopefully this won't be my last OSS submission.
Project Description: A finite element analyzer -- allows a user to enter 2D points, then those points are connected with elements. Then forces are added to different places on the elements. Then the result of such forces being applied was analyzed by an analysis engine(not mine), and the results were graphically displayed. This was a project for my class "CE 571 - Advanced Computer Graphics. In later years the students were allowed to choose more pure computer graphics projects, but unfortunately I had to do something very Civil-Engineering specific. But, the graphical pre-and post processing techniques are universal.
Project Scope: GUI interaction, 2D coordinate systems, interfacing to an analysis engine, graphical visualization of returned data.
My role: This project was not a team project, so I had the responsibility of creating the whole program myself.
Successes: It took a lot of work, but fortunately it worked as designed!
Failures: I didn't have time to make the program 3D.
What I Learned: Design it right the first time. I didn't take many issues into account the first time through the code, so I ended up redoing a lot. I also wish I would have designed the program to work with 3D coordinates right from the very start, since that wouldn't have been too much extra work, and would have yielded a very useful engine that I could reuse for many other things.
Source Code:Note: This will NOT compile without the Owenlook libraries, which are currently not publicly available. Also, some EMRL copyrighted math libraries are missing. Sorry!
Project Description: A program to help LDS "Elders" manage their "Home Teaching" -- basically every LDS male is paired up with another in the congregation to go out and teach 2 to 3 families once a month. Would be a very successful and uplifting idea if everybody did it every month. :) Being in an LDS community, and going to an LDS university means that such projects are possible in a CS / C++ class!
Project Scope: Manage records for a whole congregation -- who every person is assigned to teach and who they are teaching with. Monthy reports on whether they fulfilled their assignments, as well as other statistics. Organization of individuals into groups called "districts" to facilitate reporting.
My role: One of three on a team -- we completed the design together and then divided up the classes to be implemented between us, coordinating our efforts periodically with meetings. The plan was to first define all interfaces to all of the classes so that we could all "use" each other's classes before they were all written.
Successes: We got quite a fair amount of the code written in time.
Failures: It didn't run. But, this was the predicament of 99% of the class, since we were given this assignment in the last few weeks of the class. The teacher had changed curriculum suddenly, and the new course we took would have been perfect, if only it had begun at the start of the semester. As it was, we had less than a week to implement the whole project. Being the last week of the semester, all of our other classes were just as demanding and producing working code turned out to be impossible. I think we got quite far though.
What I Learned: What I have learned since about why our code didn't run: Use delegation instead of inheritance when objects serve dual roles. In the C++ class(CS 240), we were never taught some of the basic object oriented "patterns" that seem to be the norm in industry now. The pattern of delegation alone would have gone quite a ways. Using inheritance, we had too closely-coupled classes that we couldn't compile in the end.
Source Code:coming soon
Project Description: A program that assembles DLX assembly code, and one that runs the said assembled code, simulating a DLX platform. For the compiler, we use lcc, which has a reconfigurable backend. This assignment was the lab of EE 528, "Advanced Processor Design".
Project Scope: Reconfiguring lcc to output suitable DLX(very MIPS-like) assembly. Interpreting each of the assembler codes into a suitable binary format, including both data and instructions. Running the binaries with correct output. This is called the "Baseline" project. The rest of the semester was then spent making our platform "Superscalar" and implementing various state-of-the-art techniques to increase CPI.
My role: One of two on the team, we tag-teamed the assembler and simulator, then I continued on fixing up the baseline as my lab partner implemented Tomosulo's algorithm.
Successes: Our baseline eventually worked well, and quickly. Briton was quite adept at giving us a great version of Tomosulo's Algorithm within a very short time.
Failures: Despite implementing a unique processor architecture, we didn't get into anything superscalar.
What I Learned: Don't take the two hardest lab classes in the department in the same semester if you want to finish both! Also, exact attention to detail would have paid off. In the assembler, Briton and I had slightly different ideas on how it was to work, and so we made some subtle mistakes in the code that were hard to find. A little more depth in our design would have paid off.
Source Code:Coming soon
Project Description: A very fun and exciting project -- a raytracer, incorporating many of the best techniques in the field of raytracing. I had always wanted to implement a raytracer, so the CS 555 project helped me accomplish this feat.
Project Scope: First basic raytracing, then super-sampling, as well as hierarchical bounding volumes and finally we added in multiple levels of reflection and refraction, as well as shadowing.
My role: Another solo project, I did the whole thing on my own.
Successes: I was able to produce some very cool images, incorporating all of the design requirements into the program.
Failures: It took a while for multiple polygons to look correct. Also, at the first turn-in of my basic raytracer(one to each "pixel", only spheres), my lighting model was slightly off. Fixing this yielded far better images. I'm not sure if my mapping ever was exactly perfect, but it seemed to do quite well.
What I Learned: To be finished later...
Source Code:To be finished later...
Project Description: There are many ways to do texture mapping, each method having is pros and cons. Typical bit map texture mapping, where you "wrap" an image around an "object" leaves artifacts - places where the texture is stretched, or places where the texture edge meets another edge and there is a mismatch in pixels. One possible solution to some of the problems with this is to do "solid texturing" (sometimes AKA 3d texturing). Think of it like "carving" the "object" out of a material. So, the trick is to create a mathematical representation of that "solid" material, from which you can retrieve pixels to map. So, you would mathematically determine what a solid 10x10x10 block of granite would look like, then for translate your graphical object's pixels into this 10x10x10 cube of information to figure out what color to make each pixel. This really produces some stunning effects.
Project Scope: Since this fit very nicely into my ray tracer, I decided to use that as the base of my code, simply adding support for 3d/Solid texturing.
My role: Solo project
Successes: I produced some very stunning images that, with the raytracing lighting effects added, were astounding
Failures: There are at least two primary methods of 3D Solid Texture modelling, one of them very trivial but with excellent visual results, the other complex, using a Fourier analysis of a 2D image to determine the solid texture characteristics. I had set my sights on the second method, but was only able to get around to the first one. So, although my program produced really great "eye candy", it lacked the technical merit it could have had. So, while my images impressed fellow students, the teacher was (rightly) not extremely impressed. Spectal analysis just turned out to be too big a task with the time on hand.
What I Learned: A lot of cool "leading edge" graphics concepts.
Source Code:I finally found some of my images that I had turned in for this project, so they are posted here. Some of the following links only send an email to me to request these items. All of the graphics links actually show the pictures. Lossless formats are also available for any of these.
Project Description: To be finished later...
Project Scope: To be finished later...
My role: To be finished later...
Successes: To be finished later...
Failures: To be finished later...
What I Learned: To be finished later...
Source Code:To be finished later...
Project Description: To be finished later...
Project Scope: To be finished later...
My role: To be finished later...
Successes: To be finished later...
Failures: To be finished later...
What I Learned: To be finished later...
Source Code:To be finished later...
Project Description: I am an officer in the Serac Mountaineering club, based in Orem, UT. We eventually had a desire to have a presence on the web, so a friend and I threw some pages together late one night. Eventually I realized that this simple site was not going to cut it in the future and needed a facelift. The site that is out there now was my new and improved redesign.
Project Scope: Redesign the whole site, making it data driven, with "upcoming trips" lists never out of date. Give it a better look and feel, make it more navigatable. Prepare for later stages of the club where there will be increased site participation by members and officers
My role: Being the only web guy I know in the club, I was the sole designer and creator of the site, taking me most of an extended Christmas vacation to complete!
Successes: From feedback, it seems that I got the look and feel and navigation done well. It also has saved me literally hours of time in site upkeep. Everything is a simple XML data file, and information flows throughout the site quite well. Automation on the client side make site regeneration automatic and very simple.
Failures: Not enough time to add in more dynamic features such as web-based administration by club officers. That will have to wait for rev 2. The method I used of non-server-side XML is great except it might make fully dynamic content a little harder. One potential failure point is the complexity of XSL - will the next webmaster be able to handle the site? At least, I could give him/her an HTML snapshot of the pages, and let them loose, I guess.
What I Learned: XSL. Ins and outs of good web site design. Color scheme design. How to put an overall look and feel onto a site using a two pass XSL transformation. (One to format the stuff in the middle of the page, the other to slap on the site look and feel - meaning header and footer, as well as CSS stylesheet).
Source Code:Project Description: Automatically generates a thumbnail gallery. I really wanted to take a list of pictures and descriptions of those pictures and automatically make a thumbnail image gallery out of them, to speed the posting of some of our Mountain club trip images. What resulted is this script. Several variables are tweak-able, including the number of columns of thumbnail images, as well as the main title, and titles on the large image pages. One can edit the code that displays the single image to be anything at all - a separate window, a window with an ad above or below, etc.
Project Scope: Make gallery creation consistent, and "automated"
My role: I was the sole inventor and creator of this idea. My friend Ammon helped me decide and pin down some of the Javascript details.
Successes: More standardization as to look and feel of galleries
Failures: Implemented as a Perl Script, so you need a perl interpreter. That is not too much of a problem on most web servers. Also, this script does not generate the thumbnail images themselves, you have to do that yourself, naming them with the same name as the original image in a separate directory. Alternately, you can suffix them with a letter("t" is highly recommended).
What I Learned: I learned a lot about javascript, mainly how to not require an HTML file for every image, yet still have all of the images look consistent. Though I later scrapped this project, it was a very good solid base for the XSL version.
Source Code:Don't forget to replace references to our clubs home pages with your own in the .pl file.
Project Description: Automatically generates a thumbnail gallery. Eventually we needed a more consistent look and feel among all of our galleries on the Serac mountaineering web site. They were kind of hodge-podge, since they were all created with a different version of the above-mentioned imgallery.pl gallery script. Since the whole site was being redesigned using XML and XSL, and since that was an extremely good fit for the image galleries also, a rewrite of the gallery script was performed. I used the same pattern as I had previously, having a "gallery.html", and a "servepics.html". This separate servepics.html is what allows you to have each individual image set in a good looking background document, but it does not require a separate HTML file for each image. The (potential) disadvantage is that it requries JavaScript to be enabled.
Project Scope: Rewrite imgallery.pl as a set of XSL scripts, rewrite all of the old data input files as XML files
My role: Sole inventor, designer, and creator
Successes: Every gallery on the site is now 100% consistent and professional. I could change the entire look and feel of the galleries(or the site, for that matter) in a matter of minutes now. Pretty cool.
Failures: I had to hard-code a tag called "displayrow", and also "photonumber". I think I could easily get around the photo number, but the display row would be tricky. It came down to the fact that I could not spend any more time on the galleries, having the rest of the site to create in a short amount of time, so I left those two tags in as "good enough". It actually works very well, I am very pleased with the galleries as a whole.
What I Learned: See "Things Learned" in the description of the web site generation project, since this was just a subproject of that process.
Source Code:Note: all of the XSL files referenced here are actually "txt" files, since my free web hosting company thinks I am actually trying to run the XSL scripts, not offer them for your viewing enjoyment. (It's a complicated mime-type thing). You'll just need to know that if you shift-click on them and save them off.
If you go to the galleries using the link below and click on an individual gallery, Note that the "Other Galleries" box on the right hand side of the screen is never out of date. All galleries know about all other galleries. This is one thing XML-based technology buys you. Using the excellent Mihov Image resizer, some java code I wrote to extract image sizes, and a good editor, I can create a gallery in about 15 minutes. Hopefully someday I'll be able to automate and web-ize this process.
Oh, and if you use the arrows, be aware that I did not create them myself, but rather stole them from somewhere (eGroups, I think).