User:Hcurtis0010/GSoC14/proposal

Personal Information

Name: Henry Curtis

E-mail Address: hcurtis0010@kctcs.edu

IRC Username: hcurtis

Background Information

This summer, I hope to participate in GSoC for the first time. My background is a little unusual in that I worked in the advertising industry for 11 years before being downsized. Later, I was fortunate enough to be selected for a program called Code Louisville whose purpose was to increase the number of programmers in my area.

Code Louisville was a positive experience that led me to return to school full time in order to earn a programming degree. I am currently in my second year at Jefferson Community and Technical College, and my course work thus far has included C++, Java, HTML, CSS, JavaScript, and PHP. My GPA is 3.886.

Project Title

Creating a Geometry Conversion Library

Project Summary

A very typical use of BRL-CAD is the conversion of geometry data from one format to another. This is a task that all CAD software programs perform, and it is frequently one of the more difficult ones. BRL-CAD possesses a large assortment of geometric converters that are stand-alone tools; some are for import while others provide export functionality.

Many of these converters have the same or very similar code. Because a flaw in one instance of duplicated code must be fixed in all of its copies, duplication creates unnecessary maintenance hassles. For this reason, BRL-CAD needs a new programming library that provides a clean API for converting geometry between formats. Such a library will increase the maintainability and portability of the code.

Detailed Project Description

The Need for This Project The extensive collection of geometry-conversion importers and exporters that I mentioned above is one of BRL-CAD's main open-source assets. However, since converting between formats remains an ongoing headache for the organization, making this task easier is a top priority.

Project Scope and Approach I will be given a public API, and I will make the existing converter logic operate within that framework. Also, I will focus on the library and API themselves rather than on the formats that are to be converted.

At the same time, however, it is appropriate for me to specify STL, DXF, and STEP as the formats for which l will implement support. (Please note that these might change as I continue to gather information and consult with my mentors.) In any case, the library will allow formats to be added as input/output plug-ins.

Moreover, I will use a wide variety of resources to help me achieve my objectives. These will include my own knowledge, mentor feedback, books, articles, and online discussion spaces.

Finally, I will address additional issues as I encounter them. For instance, I will create patches, and if comments in the code refer to unimplemented elements, I will make a note of them.

My Preparation to Complete the Project I examined large amounts of BRL-CAD's source code, including the public API headers and the geometry converters.

I spent a lot of time in the IRC channel #brlcad, and there I monitored the conversation and asked questions.

I consulted with BRL-CAD mentors and with my fellow candidates. I received feedback from them and used it to improve my proposal.

I subscribed to the BRL-CAD mailing list, and I used it to share my background and interests with the community.

I created accounts on the BRL-CAD wiki and on Sourceforge.

I read as much as I could about library and API design and about CAD geometry conversion. My research materials included The Contributors' Guide to BRL-CAD and volume IV of the BRL-CAD tutorial, Converting Geometry Between BRL-CAD and Other Formats.

I researched many, many other relevant topics as needed, including Linux and Subversion commands, CMake, and virtual machines.

I prepared my compiler and ensured that it functions properly.

I created and submitted a patch.

Issues to Consider The ability to interpret error messages and compiler warnings is an important skill that I know that I will rely on throughout this project.

Also, I realize that the programs that I produce will need to function well across multiple platforms. I will bear this in mind as I work.

The Library Suitable for stand-alone distribution, the library that I will create will involve as few dependencies as possible. In connecting with outside programs, it will require only central BRL-CAD libraries such as libbn, libbrep, and libwdb.

The geometry formats that I will implement support for will extend the library without my needing to alter the public API. Likewise, each format will have its own subdirectory and will need very little additional initialization-function code in order to register itself.

APIs As far as APIs are concerned, I will receive a public one and will review and enhance a private one. Any APIs I that work on will be left well-organized and well-defined--in other words, clean. To that end, as I deal with the private API, I will adhere to the principle that a plug-in interface should be both simple and conventional.

First, I will ensure that the API limits the number of functions, symbols, types, and such that it declares. Also, I will confirm that it abides by the same pattern rules as other BRL-CAD files.

The fewer the features that an API possesses, the fewer the items that have to be altered when additional plug-ins are introduced. Because APIs streamline programs, they are important for the code's future extensibility and maintainability.

Before I improve and implement my API, I will need to understand its requirements and known issues. In order to achieve this, I will conduct requirement analysis, asking as many people as possible about what features they would like to see. Then I will write use cases. This will help prevent problems down the road and ensure that the implementation is able to adapt to the users.

In preparation for producing an implementation and reworking an API, I will write a few typical application-code snippets based on the requirement list I have made. In addition, I will locate high-quality APIs similar to that I want to create, and I will learn from their design.

An API and its semantics are the main product that a library provides. For the same reason that I will write code snippets against an API, I will specify the API and its semantics before I implement it.

I will refine my work if I find errors while I implement the API or write unit tests for my implementation. Moreover, I will show what I have accomplished to my mentors and peers and request feedback. The more information I possess, the more likely I am to create something of high quality.

As I improve the API, I will think of examples that would involve it. I will determine those examples based on the use cases I have written. I will also ask others to write examples using the API.

Finally, I anticipate that future maintainers of the API will add to it and sometimes deprecate portions of it. Likewise, users will write their own code to customize the behavior of its components. In order to plan for extensibility, I will imagine realistic problem scenarios and come up with possible solutions in advance.

Documentation An application's documentation is important because it influences the way in which that program will be utilized. Consequently, I will append Doxygen comments to my library and API files.

Deliverables A new programming library that provides a clean API for converting geometry between formats (specifically, STL, DXF, and STEP)

Development Schedule April 21-May 17 (Community Bonding Period) At this time, I will learn more about the way in which BRL-CAD conducts business. This will include coding standards and practices, license usage, and revision control. I will also develop a task list and make use of the valuable opportunities that I will have to interact with my teammates.

Moreover, during this phase I will be examining the source code, reading the documentation, and conducting research. Some of this investigation will be on STL, DXF, and STEP. Next will come in-depth analysis, algorithm creation, and coding.

Throughout this period, I will discuss with the mentors and the other developers how I can optimize the improvements I am incorporating and what the final plan for producing the deliverables will be. This will result in a well-considered course of action.

Week 1 (April 21-26): Collect information about the requirements for the library and the API; review the public and private API; develop a task list; acquire and try out the software, online accounts, and other tools that I will use to complete the project (these include GitHub and Doxygen) Week 2 (April 27-May 3): Continue researching the requirements for the library and the API; keep studying the public and private API; develop a step-by-step plan for implementing support for STL and DXF; finalize the task list Week 3 (May 4-10): Write use cases; obtain mentor feedback on the step-by-step plan for implementing support for STL and DXF; take final exams at school Week 4 (May 11-17): Create a design for the library; create a plan for improving the private API; ask mentors and peers to review my library design; ask mentors and peers to review my API-improvement plan; finalize the step-by-step plan for implementing support for STL and DXF

May 18-June 21 (Evaluation Period 1) Although there might be some additional research, analysis, and design during this phase, my principal focus will now be coding, debugging, and testing. The implementation of support for STL and DXF will be a part of this.

Throughout this period, I will check in often with my mentors, do the items on my task list, and record my daily accomplishments in a progress report and a development log. In addition, I will be creating documentation the entire time. By the end of this block of time, starter versions of the new library and the reworked API will have been created.

This phase will moreover involve activities such as the implementation of the new library's structures, the selection of functions' details (such as return types and parameters), unit-level testing, and code-coverage assessment.

Week 5 (May 18-24): Work on the library, using mentors' and colleagues' feedback to improve it; work on bettering the API, using mentors' and colleagues' feedback to do so; test the library; test the API; document the library; document the API; accomplish steps 1-5 of the plan for implementing support for STL and DXF; obtain additional feedback from mentors and colleagues; record progress daily in the progress report and the development log Week 6 (May 25-31): Continue working on the library, using mentors' and colleagues' feedback to improve it; keep working on the API, using mentors' and colleagues' feedback to improve it; test the library; test the API; accomplish steps 6-10 of the plan for implementing support for STL and DXF; record progress daily in the progress report and the development log Week 7 (June 1-7): Identify and address the most difficult aspects of the project; continue to test the library and the API; accomplish steps 11-15 of the plan for implementing support for STL and DXF; begin developing a step-by-step plan for implementing support for STEP; document any code that has been added; record progress daily in the progress report and the development log; obtain feedback on my work pace from my mentors Week 8 (June 8-14): Work on the library, using mentors' and colleagues' feedback to improve it; work on the API, using mentors' and colleagues' feedback to improve it; test the library; test the API; document the library; document the API; accomplish steps 16-20 of the plan for implementing support for STL and DXF; obtain mentor feedback on the step-by-step plan for implementing support for STEP; obtain from mentors and colleagues additional feedback about other relevant matters; record progress daily in the progress report and the development log Week 9 (June 15-21): Ensure that progress is still on schedule and is likely to remain so for the remainder of GSoC; continue testing the library and API; keep debugging the library and API; accomplish the remaining steps of the plan for implementing STL and DXF support; finalize the step-by-step plan for implementing support for STEP; record progress daily in the progress report and the development log; prepare for the midterm evaluation

June 22-July 26 (Evaluation Period 2) During this phase, I will continue coding, debugging, and testing. Of course, I will be checking in with my mentors and recording my progress as well.

In addition, I will implement support for STEP. This format is very complex, so it will take more time to work with than STL and DXF. That is the reason I plan to tackle STL and DXF during the first evaluation period but wait until the second half of GSoC to address STEP.

Although STEP is challenging, it is important to BRL-CAD, so I want to do what I can to help the organization work with it. By the time evaluation period two begins, I will be able to use what I will have learned from implementing STL and DXF support to do the same with STEP.

This project stage will be the one in which I finish the remaining things on my to-do list. I will moreover at this time incorporate error handling into my code and continue to add documentation. Incidentally, the documentation will appear not only on the BRL-CAD wiki but also in pdf files. By the end of July, all of my code's functionalities will have passed unit-level tests.

Week 10 (June 22-28): Incorporate evaluation feedback into my work practices; continue working on the library; keep working on the API; test the library; test the API; document the library; document the API; accomplish steps 1-5 of the plan for implementing support for STEP; continue obtaining feedback from mentors and other teammates; record progress daily in the progress report and the development log Week 11 (June 29-July 5): Keep working on the library and on the API; continue testing the library as well as the API; accomplish steps 6-10 of the plan for implementing STEP support; continue obtaining feedback from mentors and other teammates; record progress daily in the progress report and the development log Week 12 (July 6-12): Continue improving the library; do the same for the API; test the library; test the API; accomplish steps 11-15 of the plan for implementing support for STEP; continue learning from feedback from mentors and other colleagues; record progress daily in the progress report and the development log Week 13 (July 13-19): Keep working on the library; continue progress on the API; test both; document the library; document the API; carry out steps 16-20 of the plan for implementing STEP support; continue obtaining feedback from mentors and other teammates; record what I have accomplished daily in the progress report and the development log Week 14 (July 20-26): Begin planning for wrap-up of the work; keep testing and debugging my code and adding documentation as needed; accomplish the remaining steps of the plan for implementing support for STEP; continue obtaining feedback from mentors and other teammates; record progress daily in the progress report and the development log

July 27-August 2 (Week 15; Wind-Down) This is when I will tie up any loose ends. In other words, I will be scrubbing code, finalizing the documentation, and performing additional tests (including cross-platform tests). I also will produce demos for the new functionality and conduct performance analysis.

August 3-9 (Week 16; Delivery) I will put the final touches on the project and deliver it. Moreover, I will be thinking about the final evaluation.

Deadlines August 11: Recommended “pencils down” date August 18: Final “pencils down” date

Major Milestones By May 17: Devise a feasible action plan.

By June 21: Finish first versions of the deliverables.

By July 26: Complete unit testing of the library and API.

By August 2: Produce a near-final version of the project.

By August 9: Deliver the final products to my mentoring organization.

Time Availability

I will work on the project 40+ hours a week.

I will have no competing demands on my time during the Summer of Code.

I will not have any other jobs, and I will not be in school. (My finals end May 9.)

I am single and have no children.

I will not be taking any trips during the GSoC period. (My plans are completely firm on that.)

Also, once the Summer of Code ends, I will continue contributing to my project and to BRL-CAD. A future endeavor might entail the creation of learning materials for those using the new library and improved API.

Why BRL-CAD?

I appreciate how encouraging and helpful BRL-CAD’s mentors have been from the start. In addition, I like the very detailed and well-organized GSoC information that BRL-CAD has provided online. It is obvious that the mentors' level of sincerity and professionalism is very high, and this is a major reason that I am interested in working with them.

Moreover, I love geometry, and the technology behind CAD fascinates me.

Why Henry Curtis?

Although my programming skills are still developing, I can offer the team many strengths. I enumerate them below.

I am an experienced, mature worker who will have no problem putting in 40+ hours a week, following action plans, and meeting deadlines. I have had many years of full-time employment in which doing that was crucial for my success.

As I wrote before, I will have no competing demands on my time during the Summer of Code.

I have no problem receiving and offering constructive criticism.

I am a highly effective researcher.

I am an excellent communicator both orally and in writing.

I am organized and an outstanding planner.

I have extensive experience working in teams because of my many years in advertising (an industry in which teamwork is very important). Also, I have worked in collaboration with others on many school projects. My team experiences have helped give me the right attitude to succeed in open-source projects.

I enjoy learning new things, and I possess a naturally analytical mind.

As I mentioned earlier, I truly enjoy geometry, and I am very interested in CAD technology.

I love programming, and I believe deeply in the open-source philosophy.

Since both BRL-CAD and I are in the United States, coordinating schedules with mentors (if needed) would be easy.

Last but not least, because my background is a bit unusual, I would provide diversity and a unique perspective to the team.

Anything Else?

I am the kind of person who is passionate about doing a good job and who persists until the work is done. I feel fortunate to have found an organization that might be willing to give an entry-level programmer like me a chance. I promise you that if you select me, I will give this opportunity an all-out effort. You will not regret your decision to have me aboard. I am ready to serve.

Thank you very much for your consideration.