If you find any problems, please let me know here. Thanks for continuing to support J-Ongaku!

If you have any problems with the new registration system, please let me know and I’ll get right on it! Thanks!

Again, thank you for your support!

Thank you for supporting us!

Update: I won a year of free hosting from WebFaction so I decided to move J-Ongaku there, so stuff like this won’t happen again. The DNS for the domain is resolving as we speak, so hang tight!

That is all. Thanks for your continued support!

Everything seems to have been fixed, and I profusely apologize for the downtime! Thank you for your support!

The problem seems to have been fixed, but I shall keep monitoring the database to make sure nothing else funky happens. My apologies for the downtime!

There was some downtime last night as I changed our web serving software from Apache to a lighter, faster and better-on-memory one called, nginx. If you have no idea what I’m talking about, no problem, just know that the site should be responding a lot faster now. :3

I’ll be tweaking it over the next few days, since I’m a bit new to serving web pages in this manner.

After Jen and I decided to start J-Ongaku, I made a vow to make sure we would be completely transparent about everything we’re doing. On Jen’s end that would consist of connecting with the community and make sure that we’re helping you produce the best content possible as easily as possible. On my end, I’m tasked to make sure that the site only goes down when it has to and to fix any problems before they become something that can take down the site.

With that in mind, I thought I’d take a minute to talk about what powers J-Ongaku. First off, J-Ongaku is a project of Revyver, a company that Jen and I have been spending our waking hours taking care of. Revyver owns a grid of 7 severs at Slicehost, a developer-focused host based in St. Louis, Missouri. J-Ongaku is spread on two of those 7, running a PostgreSQL database back-end on one and PHP on the other. Without getting too geeky, there are two benefits.

1. There’s no single point of failure. If the server running the site goes down, it doesn’t affect the database. Your data will be safe.
2. PostgreSQL by design is more reliable in a production situation than MySQL. It doesn’t corrupt data as easily as MySQL seems to, and I make sure multiple backups are made nightly.

I’ve gone as far as I have because I’m a bit OCD when it comes to servers, even though I’m a designer by trade. Again, with all the ups and downs that have happened lately, I wanted to take no chances. Finally, you’ll see that I’ve added an uptime graph to the blog. This’ll show our uptime for the last 30 days courtesy of the awesome monitoring service, Pingdom. When it comes to downtime, you’ll always find out about it on this blog, or on the wiki itself.

I’m committed to making sure that you’re comfortable spending your time helping us build J-Ongaku. Please don’t hesitate to contact either Jen or I if there’s anything else we can do.

first of all, i apologize for my inability to explain things efficiently. xD; i ramble a bit and tend to make things sound more confusing than necessary, so feel free to re-write these in a more efficient way (since these will have to go on the wiki at some point). in fact, i encourage you to! the more comprehensive the rules sound, the better.

while these rules are not 100% final and i am open to discussion about them, i am also aware that no matter what i do or don’t do, i will not make everyone happy. so feel free to make your argument for/against (in a constructive and civilized manner.. comments like “that sucks” will not be helpful to you or to myself), and i will weigh them with what other people think and come to a conclusion after weighing both sides fairly. that means that some people won’t be happy, but please keep in mind that my job is to go with what will work better for the majority, which is not necessarily the most vocal group (so polls may be implemented at some point).

that being said, here are the rules that i’ve come up with so far:

1. Discography tables should have the same categories. that is: number, title, first week sales, total sales & oricon ranking. this is for consistency, and encouraging members to fill in information where there is none. this is for main discographies, things like digital singles and miscellaneous types of releases need not include the categories that obviously don’t apply.

2. romaji text should come before Japanese text. this is because most visitors are not fluent in Japanese, so it doesn’t make sense to have to go down a list reading what’s written at the end of a line. that is not to say that the Japanese title is not important, just not what the visitor should see first. having the romanized title written first makes it easier to skim down a list.

3. on a CD’s page, the Track List should be the first section after the description. it is the most important information and the one most people are looking for when they visit the page, so all other information should be placed *after* the Track List.

4. something i always loved about ThePPN, capitalization of titles should be copied from the official romanization used in Japan (when applicable). this means that titles written in all uppercase or all lowercase on a PV or  CD cover, for example, should be reflected as such in the Discography & Track list sections (though not in paragraphs such as History/Information sections, where ease of reading should take priority).

5. when romanizing Japanese text, the first letter of important words should be capitalized. Katakana should NOT be written in uppercase because this rule is not followed consistently. it does not do to pick and choose when to write a Katakana word in all caps, and therefore it’s better not to follow that rule at all.

6. First/Last names in Kanji should not be separated by spaces. if you need help figuring out where a family or given name starts/ends, i suggest using Jim Breen’s WWWJDIC Translate Words section. it’s very helpful!

7. translations of Japanese text should be included on its most specific page (for example, on the Single’s page instead of on the Discography page), so that the more general page(s) doesn’t get crowded with too many words.

8. single songs should not have their own page unless there is sufficient information to include on the page. for example, the composer/arranger information is not enough to put on a song’s page, since that information can be included on a single/ablum’s page. only if a song has history, or many versions that need to be listed, or has been covered by many artists, etc, should a song have its own page.

since J-pop is my main thing, i realize that a lot of other categories (actors, dramas, etc.) may need rules that i wouldn’t think of including. so feel free to let me know about things that!

oh, also. some general CSS will be implemented to help keep a consistent look on things like tables. while i don’t want to give SO MANY rules that it drives people crazy just trying to remember them, i do want to aim for a consistency that is usually hard to find in wiki’s, wherever possible. but this will mainly depend on contributors and trusting them not to make things different just for the sake of being different, so i’ll talk about that once we’ve gotten somewhere with the actual rules.

anyway, discuss and suggest away! and remember to keep things constructive. :3 and err, suggestions should have a purpose, obviously. xD; “it should be this way because of these reasons” will hold more water than “i like it better when it’s..” lol.