Author: Ward

In my first implementation of password reset, a user just entered their email address and they were sent a new password.  Unfortunately, this meant that an unsavory person could just keep entering your email into the application, resetting your password and by-and-large being, well, an unsavory person.

Originally I had intended next implement security questions in order to allow users to reset their passwords.  However, I had a lot of design decisions about how to support and implement this both in terms of functionality and usability.  While I think security questions are ultimately a superior approach, I opted for an easier approach.  

The current solution is to send user’s reset password confirmation key to their email account.  Upon receipt, they can return to the site and with their email address and confirmation key in hand request their password be reset.  At this point the original flow is followed; namely, we create a random password and send it to you in email.

The advantage to this approach is that it leveraged extant functionality in the user model, thus requiring a minimum of coding.  However, the one down-side is that resetting your password requires you to use both Kotoba and you email client.  Security questions would obviate the need for email and make the whole user experience better.

Nevertheless, expediency won the day.  For now.

Kotoba‘s user authentication and registration are functionally complete.  This includes account creation confirmation using a key that is sent to your email address.  If you forget your authorization key or need to reset your password, both of these can now be done from the web-site.

The next step will be to allow security questions for resetting your password, as this will minimize (eliminate) other persons from resetting other users’ passwords.

Also in the works is the ability to import JMDict/EDict XML files directly into the dictionary.  Once this importation is complete the real work can begin.

As of this evening I have re-done Kotoba using ActiveScaffold.  I have also updated the application to use Rails version 2.2. All in all, I am extremely happy with the level of sophistication that ActiveScaffold allows me.  At this point the entire application is created via declarations; there is not a single line of code, as it were.

Some minor issues cropped up on migrating to Rails 2.2 and ActiveScaffold, though.  First, the mysql gem is no longer a part of Rails; this requires a separate install.

$ sudo gem install mysql -- 

--with-mysql-config=/usr/local/mysql/bin/mysql_config

You will need to ensure you are using the 32-bit version of MySQL 5.x, though.  Currently the gem does not know how to support x64.  Sadly.

Additionally, ActiveScaffold appears to cause some interesting issues with DB migrations.  At present, the easiest work-around is to update your Rail apps impacted environment(s) (e.g. config/environments/production.rb) with the following:

config.cache_classes = (File.basename($0) 

== "rake" && ARGV.include?("db:migrate")) ?  false : true
 

I did try some various localization ideas, but none of them as of yet have yielded much fruit.  The most promising is Rails upcoming support of i8ln.  For now I will continue to focus more on functionality till localization is more readily accessible.

Kotoba is very much a work-in-progress Japanese vocabulary system for students learning Japanese.  While there are a lot of other pieces of software out there for studying foreign languages, even specifically Japanese, none of them are, in my opinion, functionally complete.  

This project encompasses my own years of studying Japanese, incorporating approaches and techniques that I have found useful.  At present I am targeting myself as the sole user; however, as time progresses I hope to include community-based features.

Please do not hesitate to contact me if you have any suggestions or ideas.