[jifty-devel] Google Summer of Code Proposal

[Jason May]

Hello,

I am applying for Google Summer of Code and have completed my
application/proposal. I am at the point where I want to gather input
from the mailing list. Thank you.

My application:


Jason May

jason.a.may at gmail.com

"Improving Jifty with Morphic Database Schemas"


Synopsis

Having worked with Jifty and its method of database upgrading, specifying the
database version for each new column that was added has become a chore. I
propose that morphic schemas can be completed in a summer's worth of full-time
work, and I would be fit to do the job.


Benefits to the Perl/Open Source Community

Everyone using the Jifty framework will benefit from these features.  Morphic
database schemas would eliminate the tedium of upgrading an application's
database schema.


Deliverables

When the project is complete, morphic database schemas will be fully
functional, as well as a large library of "validators" and "canonicalizers" as
a supply for the virtual models.

Project Details

Currently, Jifty automatically upgrades the database, but only when the
developer orders it.  When a column in a model is modified or added, the
developer has to explicitly tell Jifty which version of the database this
change occurred in by adding a "since" attribute to the column.  Otherwise the
database will not update the changes when you command Jifty to update the
schema.

After some investigation into the development history of Jifty, I discovered
that Jifty already has a branch devoted to auto-versioning. Unfortunately, due
to lack of time, the developers have not done much work on it.  I would
therefore like to devote my entire summer to make morphic database schemas a
reality.

Jesse Vincent (the lead developer of Jifty) pointed out that using virtual
models might help with auto-versioning, and that there is already a
virtual-models branch of Jifty which stores the model definitions in the
database.  However, according to Andrew Hanenkamp, the virtual-models branch is
not very popular in production.  In fact, the only person that uses the branch
in production is himself.  However, it would certainly help implementing
morphic database schemas by updating the version automatically with SQL as
opposed to having the barrier of having the database version marked in Perl
code.

Another approach I came up with is to represent model definitions partially in
a database for anything that we would want to be automated.  The rest of the
model definition can reside in the Perl code.  Since there's already a
virtual-models branch, though, this may not be necessary.

Using virtual models would likely require me to create an isolated library of
built-in canonicalizers and validators designed for the virtual models.  Since
the models will be in a database, there will not be a lot of room to create
complex models using Perl.  For instance, suppose a Jifty user implements an
input for a phone number which needs to be canonicalized a certain way for the
database.  Something other than the model would have to canonicalize the entry,
since the model is completely virtual.  Attributes such as zip codes and
email addresses would need external validations as well.  There would be
many possible validations for different types of entries that I haven't yet
considered.

My primary plan is to start with the morphic database schemas before I begin
working on the canonicalizer/validator library in case any snags occur. The
library is not necessary for the morphic database schemas. It would just be the
immediate step after the morphic database schemas is complete. In the worst
possible case, I will work with the library after the deadline as my own
personal contribution outside of the Summer of Code program.


Project Schedule

May 26:    Failing tests for the morphic database schemas will begin.

June 2:    Failing tests will be written for morphic database schemas, and the
           coding of the functionality will start.

July 7:    Morphic database schemas will be functional. Writing failing tests
           for the library of canonicalizers and validators will begin.

July 14:   Failing tests will be written. Coding for the canonicalizers and
           validators will begin.

July 21:   Integration of the canonicalizer/validator library with the
           morphic database schemas will begin.

July 28:   Integration will be complete. More tests and code will begin to be
           written for the canonicalizer/validator library.

August 11: Work on the canonicalizer/validator library will be complete.


References and Likely Mentors

I contacted Shawn Moore about possible ideas for Jifty. I also contacted Jesse
Vincent about ideas. I also talked to Andrew Hanenkamp about the idea of using
the virtual-models branch, which was very helpful in consolidating my thoughts
for the auto-versioning creation process.

As the pilot of the entire project, Jesse was the most prominent resource. He
helped me with priorities for the timeline and informed me of the available
development branches in Jifty that would aid in my development.

Shawn Moore offered to mentor me for this project. I am willing to work with
any mentor that is assigned for the project.


Bio

Perl was my language of preference during high school.  When I graduated high
school in 2005 I noticed that I was lacking experience in the business aspect
of IT, so I enrolled in Information Sciences and Technologies at Penn State
University.  My campus is a Microsoft-oriented environment, but I continued
working with free and open source software outside of school.  I discovered
that I had a true love for open source and I became a part-time college student
so I could devote more time to working with open source.  Although this was a
good experience, I plan to go back to school full time to complete my studies
in the fall after a summer of dedicated open source work.

I gained a lot of web programming experience from various part-time desk jobs,
contracting jobs, an internship, and a non-profit organization.  At my desk
job I was a help desk consultant with the extra responsibility of being on
the special projects team, which consisted of programming help desk
applications.  As a contracted programmer I worked with a team of seven
coders and collaboratively used PHP and MySQL.  I have been an intern as an
assistant web developer for the Penn State York Campus where I researched
various web frameworks and made updates to the campus website.

I began working with SQL in a college class my freshman year, and I haven't
stopped since: SQL played a large part in many of the applications I wrote
since then.  Some examples of the SQL-driven applications I wrote was a
web-based registration form for SCROUNGE (a non-profit organization that
refurbishes and donates donated computers), a web-based interface for
IRC log statistics compilation, and web-based data collection and reporting for
HVAC manufacturers, consumers and regulatory organizations. All applications
required extensive SQL.

I recently discovered Jifty and used it to build various small applications.
Having also worked with a few other popular web frameworks, I found Jifty to be
my favorite due to Perl's flexible nature.  Because I was interested in the
source, I started following the Jifty mailing list and contributing various
suggestions and security fixes to the main branch.

My open-source contributions have recently been focused on Jifty, and this
internship would provide me with an opportunity to focus on it even more.
Hopefully the internship could also motivate me to possibly contribute to other
organizations, whether they are directly related to Jifty or not.

Implementing morphic database schemas to the Jifty framework would be one of
the largest accomplishments in my life, and would be very effective in finding
a job by showing The Perl Foundation my abilities and potential to learn.