Researching Edo Period Japan

Aug 05, '13 books, writing, affiliate-links

I've been working on a fantasy story set in Japan in the 1700s, known as Edo Period Japan. There's a lot of stuff on the internet about that era but most of it is depressingly topical. You don't get a lot of feel for the culture.

As an entry into your own research, I'm going to recommend a book, a documentary, and a Wikipedia article to start with. Together, they made it possible for me to imagine a fantasy Japan set in the late 1700s. I'll also cover some additional internet resources that you can use to flesh out your own story.

Everyday Life in Traditional Japan (Book)

This is basically a small textbook. It's pretty small at 208 pages. Easy finished in a couple of evenings. It's a bit hit or miss topic wise.

Starts off with some history and then dives into the different social classes, and then meanders into random facts. There's a lot of nice little details on how farming was done, how houses were laid out, and some details on the food of the time. I found meals to be especially interesting. Ideally they are silent, quick, and boring affairs. Talking during a meal in the Edo Period is rude. This isn't medieval Europe with roaring fires, groaning banquet tables, and busty tavern wenches!

Japan: Memoirs of a Secret Empire (DVD)

Made up of 3 hour-long documentaries, it's pretty easy to set through. The voices of the narrators, readers, and professors are pleasant to listen to unlike some other PBS productions.

The documentaries evenly cover a mixture of history, politics, and culture. It paints with a much broader brush than Everyday Life in Traditional Japan. At the same time it covers topics the book doesn't mention in detail such as the toll roads and geisha.

Shinto (Wikipedia)

Neither the book nor the documentary really cover the Shinto religion in any great detail. It's a huge influence on Japanese both now and in the 1700s. I recommend reading this after seeing the two resources above. This wikipedia article fills out some of the gaps in understanding specific rituals like the tea ceremony.

Reading about the tea ceremony without a cultural background isn't going to do much for your story. It's not just having a beer on the porch!

Other Resources

Now that you have a baseline to start from, here's some articles I think you would find useful or at least interesting. You can skip the food ones if you don't plan on covering meals in detail. Remember, meals are boring!

Female Characters

Women in the Edo Period weren't valued as much as they were in previous or later periods. They really don't have much information on them. I was forced to look at other eras for what a woman in my story could look like.

Simple Paste

Jul 27, '13 programming

I made a little afternoon project called Simple Paste. It's a pastebin for plain text instead of code. I was sick of trying to use gist or for plain text. Neither of them handle plain text nicely. Simple Paste simply escapes all special characters and applies no formating other than a tiny bit of css.

I wrote it in php so I could host it on my VPS which already has php installed for dokuwiki. The source is available on GitHub.

New Blog using Middleman

Jul 20, '13 programming, new-blog

Last week I completely rewrote the backend for my blog. It's still static files. I got rid of octopress and switched to middleman instead.

The rewrite allowed me to split my writing and my blog articles into separate sections. I've been wanting to do this for a long time but octopress and jekyll don't support multiple blogs or splitting a single blog into multiple sections. However, middleman has an undocumented and unfinished multiblog feature in the master branch. With a little effort I got it to work. I'll write something up about that later. The source for the blog is available on github if you want to try to figure out what I did.

I wish I could take complete credit for the snazzy new theme but I started with the css from as a base and the cute little wolf in the header is a stock image I paid for. The majority of the css is written by me, I just can't claim complete credit for it.

Singleforest and litsocial down

Jan 10, '13 irl

♦ Update 2013-01-19: Both sites are back online.

I had to disable and There's a extremely bad security bug in rails I haven't had time to patch. The bug is already in metasploit which means an automated attack could compromise my servers.

I'll be working over the weekend to patch my applications. I have several applications at my current job that are going to need emergency patches.

Why autosave doesn't work on belongs_to associations

Jul 15, '12 programming

This post relates to Rails 3.2. It probably applies all the way back to Rails 2 but I make no guarantees of past or future applicability.

The rails docs on association autosave for belongs_to currently reads

If true, always save the associated object or destroy it if marked for destruction, when saving the parent object. If false, never save or destroy the associated object. By default, only save the associated object if it’s a new record.

ActiveRecord::Associations::ClassMethodsRails docs

Clear enough. So you would expect this code to work.

class Story < ActiveRecord::Base
  belongs_to :user
  belongs_to :series

  # nested_attributes_for doesn't work on belongs_to association
  # so we duplicate a subset of that behavior for new records
  attr_accessor :series_title 

  before_save :save_series_title, if: ->(o){ o.series_id.nil? && o.series_title }

  def save_series_title
    self.series = user.series.find_or_initialize_by_title(series_title)

What the documentation doesn't tell you is that this autosave for a belongs_to association is implemented as a before_save callback. This is obviously going to throw a wrench in things. Other associations like has_may and has_one are implemented in a after_create/after_update callback.

The solution for the example is rather simple.

def save_series_title
  self.series = user.series.find_or_initialize_by_title(series_title)
  # Need to manually save since the autosave callbacks have already been called.

Calling save at the last line of the function will maintain the same functionality of the autosave callbacks. If the association fails to save, the callback returns false, the save is aborted and the transaction is rolled back.

Why this behavior exists

The save order for belongs_to callbacks is different for a very simple and logical reason. The foreign key for a belongs_to association is on the record that is being saved. So the association needs to to be saved before the record it's on so it can set the field before the query is executed. For the same reasons has_many and has_one associations save after the query executes since those associations need to wait for the record to have an id before they can be saved.

Net::HTTPBadResponse: wrong status line: ""

Dec 06, '11 programming

If you ever see: Net::HTTPBadResponse: wrong status line "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">"

Then you probably forgot to use ssl with your request to port 443. Apache coughed up a 400 error page over ssl in a way that caused the ruby standard library Net::HTTP to vomit exceptions all over your application.

This behavior was discovered on with Ruby 1.8.7 patch level 352. Judging by how it affected all the development system at my work, it affects all Ruby 1.8.7 patch levels equally. I have no ideal what happens with Ruby 1.9.

Singleforest Beta Soon (for real)

Apr 14, '11 singleforest

So close, I can taste it. Singleforest is nearly ready for beta. I've hammered the most the major bugs I'm aware of.

What's left before launch?

  • Some of the custom logging code is storing passwords. That needs to get fixed before the site can go live.
  • Moving the server from Rackspace to WebbyNode. Waiting on WebbyNode to get debian 6 out. Will go with Ubuntu in a pinch.
  • Need to write up Terms of Service and Rules documents.

Some of the issues getting the site ready:

  • Getting SSL/nonSSL redirection working properly was not happening.
    • Moved the entire site to ssl instead. Easier and more secure anyway.
  • Getting tests written for some of the code. RSpec fought me every step of the install process.
    • Releasing the beta with only minimal test coverage, will add tests as bugs pop up.
  • Writing my own css was taking way too much time.
    • Purchased a theme for $20
    • Will fix some of the icky coloration later. (background too bright, link color too light)
  • Event system was pretty complicated and was breaking a lot of code
    • Stripped events and notifications to the minimum that was required and stopped trying to ensure they get saved.
  • Spending too much time making the ajax stuff nicer
    • Stopped working on writing my own widget library and settled on a just works solution for now.

I can't wait to for this thing to be live. It's been way too long.

Why I'm Using Rails 3 and SQL

Jan 10, '11 singleforest

Anyone who has followed my modest blog will be familiar with the various frameworks and databases I have tried using for Well, I have finally come to a conclusion. A real conclusion this time. Since August 2010 I have been working with Rails 3 using SQLite3 as a database backend. For anyone on Hacker News that has met me in Chicago, this is the version I demoed on my iPad at the Publican.

I would like to review the frameworks and database previous iterations of used and why I am not using them today.


Rails 2

I originally started coding with rails 2. It was an easy decision to make since I had learned rails during my internship and I had continued to use it after the end of my internship. The first rails 3 beta was released early in my development process. I found rails 3 to be cleaner than earlier versions. The routing api was elegant instead of clunky. (Yes, specifying :controller and :action for every route is clunky even if you can scope them.) The addition of AREL to active record was also important once I started using sql databases, my current code base relies on it for automatic sorting and pagination. As a result I made several attempts to use rails 3 which resulted in enormous amount of pain. During the betas several key gems such as authlogic, formtastic, and various active record gems were either not compatible or buggy. I was forced back to rails 2 until rails 3 was out of beta. Once 3 was out of beta I switched back to it.


I had given Django some thought initially. I had played around with Django before and found it to be at least as large of a framework as Rails. I went with rails because of ruby. I hadn’t used python for almost a year when I started and I was looking at the start of a new semester in a few weeks.


During my fights over whether to use Rails 2 or Rails 3, I decided to give a python framework a try. I dismissed Django for the same reasons as before, it’s too large of a framework to learn quickly. I figured I would be up to relearning python since I had enough free time between classes. Turns out relearning python wasn’t the problem, the documentation on pylons was. At the time I was learning pylons, the available documentation on the internet was out of date and pydoc refused to build the documentation for the version I was using. The only decent tutorial I could find was a half finished book on the previous version. I quickly ran into issues with the book. A quick trip to irc revealed to me there was no authoritative documentation, no tutorials for the current version, and no one had any idea how to actually build a pylons project from scratch. I was told to download a sample application (the pylon’s project website) and modify that. Upon doing that I found out I now had three different version of pylons on my system and all of them hated each other. I also had issues with python’s tooling. (Pydoc, virtualenv, and multiple package managers) In the end I went back to rails because I didn’t have the patience or time to deal with a pylons.



What’s not to love about CouchDB? From a system administrative perspective it’s the most awesome database ever. It’s crash-only, you can back it up with rsync, and it scales like nuts. From a programming perspective it’s a little more work. You need to define every query you will ever do before you do it. It’s not as bad as you think. CouchDB has a development mode that will run any query you want without an index. Slow as hell but flexible, you just have to define the indexes before you deploy. I can live with that. Data is stored as json documents in a single silo. I can live with that. For an old version of my application it would work fine. I would have loved to use it.

Why didn’t I? I need joins in the future. CouchDB could work if I was willing to make trade offs on future design. I plan to add groups to singleforest. The queries I would need can’t run on couchdb without a lot of denormalization. Adding and removing users from groups and calculating activity on groups would be expensive and require cron jobs. Ironically, groups wouldn’t be able to scale on CouchDB.


I liked using mongodb but the tradeoffs make me uncomfortable from a system administration perspective. MongoDB plays fast and loose with data to get high speeds as a result, it requires two servers for data safety. I don’t currently have the resources to deploy two database servers. I did not feel comfortable trying to maintain a single server against strong recommendations not to. Later I found another reason not to use MongoDB: I need joins.

In Conclusion

Since rails 3 has matured it has been an absolute joy to work with. I do not regret having spent so much time switching between databases and frameworks. It’s given me a better appreciation for the tools I’m using now. Learning to model data in json has allowed me to model data better in sql. Fighting with python’s toolset has made me thankful for ruby version manager and bundler.

Project Update

Screenshots of the current version available on my deviantArt account.

« Newer Older »