I will no longer be updating svn here at crudvision.com. I want to move Reve to git (at github). I won’t do it if I can fall back to svn, so I’m jumping ship.
Moving to github will also mean I can dump dreamhost as a host and move crudvision.com to my colocated machine to save money each month.
I’m sorry for the complete void in posting. I’ve been very busy with life, work and rock climbing. Yes, that’s right, rock climbing.
In early March I started a new job in Toronto for a gaming company (I’m not really allowed to talk about it much, unfortunately). I’m a sysadmin there and I love it. It’s much better than developing the same web applications over and over. I’m almost ready to resume programming for a hobby now that I don’t do it all day every day for pay.
And the rock climbing. My partner and I started climbing recently. We’ve noticed an unusual number of IT professionals that climb! It’s cool and odd at the same time.
I hope to post more, but the real goal of the post is to say that I’m ditching subversion, trac and intend to use github as the only source of documentation for Reve. (I just hope I can get traffic from github to this blog to pad my ego.)
James Harrison brought to my attention a couple of bugs in Reve and I’ve released a new gem of Reve to resolve the issues.
The fixes are:
* Soverignty now casts constellation_sovereignty to an integer (Fixnum)
* Conquerable Stations method now reports fields correctly.
* RDOC updated for the above
I’m still around. Busy with life and work and it’s left me in not much of a mood to code. I did, however, push a new release of Reve. Check it out!
In the past I mentioned some Pros and Cons of Jungledisk and Amanda and the one listed “con” for Amanda is that it periodically had issues with my buckets and the size of data stored therein.
It turns out that there was a bug with the Amanda S3 device: it had issues with buckets that had a lot of keys (files) in it. Due to the way Amanda works it makes one gig pieces of data on the holding disk and then the S3 device chunks them up smaller and puts them on the S3 device. When the tape/bucket was due to be resused the files in it had to be removed. Fetching the key list (file list) that could be rm’d had a buffer overflow.
I found this out with the awesome help of djmitche (and Freenode #amanda) who wrote a patch for me. I’m pretty sure the patch made its way into amanda trunk. In Gentoo the patch is in app-backup/amanda-2.6.0_p2-r1.
Since applying the patch I’ve had no problems with Amanda at all and it’s run perfectly for me.
Following up to Backing up to Amazon S3 using Amanda (June 28, 2008):
I’ve been having issues with both Amanda+S3 as well as JungleDisk. I’ll outline these here.
JungleDisk Problems
- JungleDisk sometimes destroys all of my data on S3 in the bucket JungleDisk uses and then on the next backup re-uploads all of the data! This is clearly a problem. Luckily I do not have more than a gigabyte of data thats backed up with JungleDisk. If I did this bug (or feature?) would be very expensive.
- JungleDisk doesn’t smartly handle moves. I’d like to be able to move things around on my local filesystem and have JungleDisk notice this and move them. Moving them over WebDAV isn’t feasible.
- JungleDisk scans individual files and doesn’t combine a whole bunch of them into one tarball. This gets very expensive! I wish they’d tar it all up first like Amanda.
Amanda+S3 Problems
- Sometimes the Amanda S3 device module has problems talking to S3. The only fix I’ve found so far is to destroy the bucket, remove it from the tapelist, readd the bucket, reidentify the bucket to Amanda and run amflush. This is clearly not good as it’s just as bad as Jungledisk destroying everything. I haven’t figured out why this happens yet.
Both products are still good and I’ll continue to use them. I’m considering using Amanda on my laptop, however, but this could cause problems in cases where it isn’t connected to the network at backup time.
I’ve begun playing with git over at github by importing Reve’s source.
Eventually I will do away with subversion and trac and move to github for Reve completely. Trac is not very good and often locks up.
As I’m still new with git and github I’ll have to keep contributions to a minimum since I don’t know exactly what I’m doing.
There’s a new revision of Reve that has just been uploaded to Rubyforge: Revision 99.
This includes a major change - Reve is now licensed under a proper license: the MIT License. The terms of the license are now distributed with the package and are.
There is also a fix for the character_id that came back from a market order request.
Why a new license now? Simply because I think it’s important to realise that it’s unlikely that anyone will use Reve to create some billion dollar enterprise that I could have got in on. Yeah, not everyone can be Delicious, Flickr or Facebook. ha ha.
So go forth, ye multitudes and fix, hax, and use. Ruby and Rails both use the MIT license so now Reve should be at home.
Today CCP announced the release of their MS SQL dump. Following in step with past conversions here is a Postgres version. Tested with 8.0.15 but should work on everything.
This dump is odd: CCP is using integers where they mean to use booleans. So in those cases remember 1 is true, 0 is false. Good luck.
Edit: As a note the Eve Online Database Viewer is updated with this dump.
Edit 2 (July 31, 2008): I nearly forgot to give props to bunjiboys for providing the .sql files from which the above dump is derrived.
If you've got a boat load of legacy fixtures laying around (and who doesn't?) it can be a pain now that Rails handles the ID of objects so you don't have to.
On the train back from holiday I wrote a snippet of code to migrate them:
RUBY:
-
def Util.real_yml(klass,col = 'name')
-
y = YAML.load_file(File.join(RAILS_ROOT,'test','fixtures',"#{klass.to_s.tableize}.yml"))
-
real_names = y.inject([]) { |names,(key,val)| names <<y[key][col] if y[key][col] ;names }
-
real_objs = klass.find :all, :conditions => [ "#{col} IN (?)",real_names ], :order => "#{col} asc"
-
yml = ""
-
real_objs.each do |real_obj|
-
yml += "#{real_obj.name.downcase.gsub(' ','_').gsub('-','')}:\n"
-
real_obj.attributes.each do |k,v|
-
if k =~ /_id$/ && real_obj.respond_to?(k.gsub(/_id$/,'').to_sym) && ! v.nil?
-
n_klass = k.gsub(/_id$/,'').camelize.constantize.find(v) rescue nil
-
key = k.gsub(/_id$/,'')
-
val = n_klass.name.downcase.gsub(' ','_').gsub('-','')
-
yml += " #{key}: #{val}\n"
-
else
-
yml += " #{k}: #{v}\n" unless k.to_s == 'id'
-
end
-
end
-
end
-
yml
-
end
The use is:
RUBY:
-
require 'util'
-
print Util.real_yml(Corporation)
Copy/paste into corporations.yml
So far it's working great!
Lately the rails-core mail list has declined in quality. Spammers have moved in and operate unfettered. Reporting offenders to Google does nothing.
In fact, in order to isolate my personal mail from spam and to keep dspam from getting very confused I've moved the rails-core list to a google mail account. It's a shame but I'm more interested in keeping my other mail free from spam and the dspam quarantine free from ham. Isolation of rails-core until Google can get the spammers off their lists will accomplish the goal.
