In the department of things I've spent far too much time working on, I just wrote a vim script that allows you to automatically insert a random number into the file you're editing. It probably could use a little work, but does what I need it to do (easily generate random numbers for test fixtures). To use it yourself, add the following to your ~/.vimrc:
" generate random number at end of current line function! s:Rand(max) y a redir @b ruby << EOF rmax = VIM::evaluate("a:max") rmax = nil if rmax == "" printf rand(rmax).to_s EOF redir END let @a = strpart(@a, 0, strlen(@a) - 1) let @b = strpart(@b, 1, strlen(@b) - 1) let @c = @a . @b .s/.*/\=@c/g endfunction command! -nargs=? Rand :call <SID>Rand(<q-args>) nmap <F6> :Rand <CR> nmap <F7> :Rand 100<CR> nmap <F8> :Rand 100000<CR>
When using vim, simply enter command mode and type :Genrand <maxnumber> to generate a random number and insert it at the end of the line. Alternatively, simply hit <F7> to generate and insert a random number between 1 and 100.
So if you haven't noticed (eg if you're reading this via rss) I spent a while cleaning up and adding some useful features to this site. Unfortunately it took a little while to do so and involved some pain; you'd always hope that upgrading software and installing new plugins would be pretty simple and straightforward, but we all know how that goes.
I started this process looking for a good Ruby On Rails CMS webapp, as I'm far more familiar nowadays w/ Ruby and the Rails framework than I am w/ PHP. There are a few out there, including radiant and typo, but I don't feel like they currently meet my needs, and in addition I was having quite some trouble getting them up and running (especially Radiant; look out for a post in the very near future on installing Rails software on a webhost).
So I decided to stick w/ drupal for now. Changed the theme to a more configurable one. Indexed the site content & provided a search box (btw for those new to drupal, one can easily index your site content by navigating to http://sitelocation/cron.php, or setup a cron job to wget that url). Added a tag cloud (which required a hack that took a while to discover), code syntax highlighting support, and even a favicon (among other features).
I've also enabled anonymous comments again, having put in place various spam control measures.
As always if anything looks of or doesn't work, feel free to drop me an email and I'll look into it. And be sure to check back soon for new content!
[And for those drupal users who are still reading this far, a good tip to debug any module running on your system, without access to a debugger, is the use the 'watchdog' facility, that provides logger functionality. Results can be viewed in the Drupal admin reports interface which is populated from the Drupal db watchdog table].
Just figure I'd share a few steps which are useful in getting a RoR application up and running on a web hosting provider. Obviously the steps will vary depending on your specific provider, but most should be the same assuming your given access to a home directory on the web server under which public_html resides.
- Install your rails app in a location _not_ under ~/public_html. For example ~/rails/appname would be a good place
- Run through your application specific install instructions, configuring db if necessary
- Link the 'public' directory under the rails root, to the public_html directory, eg
ln -s ~/rails/appname/public ~/public_html/appname
- Edit .htaccess in the public directory, commenting out the following line and replacing it with:
# AddHandler fastcgi-script .fcgi AddHandler fcgid-script .fcgi
(at least I had to do this w/ my provider, I'm not sure how many this applies to)
- Add your gem path to ~/rails/appname/config/environment.rb like so:
Obviously your local and system wide gem paths will vary depending on your system. Use the 'gem environment' command to determine what they are.
- Finally you may also need to add the following to your ~/rails/appname/config/environment.rb:
config.action_controller.related_url_root = '/appname'
or if this doesn't work, add:
ActionController::AbstractRequest.related_url_root = '/appname'
This tells rails that our application is located under the '/appname' subdirectory of our webroot, eg in our case ~/public_html.
Though the process is pretty straightforward, since your not in control of the entire web server you may run into some tricky points as evident through the many related posts out there. Also your web application may have bugs of its own, further complicating the situation. Just stick to it and you should get it eventually.
It really surprises me that noone has done something like this before:
When you get down to it, this is just a FPS playing in a no gravity environment, with full 3-dimensional movement on demand (eg you have jet packs to move around w/ as opposed to having to used stationary objects such as walls to jettison yourself off of). I can't imagine gameplay for this is much harder than aiming to where you want to go/shoot using the right analog, and moving in that direction using left, with buttons to actually shoot and lock onto the nearest floor. Hell, were it not for that last 'locking' bit, this game might be easier to code than a traditional FPS because you don't need to worry about gravity at all, whether for the players or artillery.
Every creative and scientific work in history is the result of expanding upon whats there, and adding to the common body of knowledge and works as constructed by our ancestors. This game just goes to show that it doesn't take much to make some thing new and creative.
Simrpc is a simple rpc implementation written in Ruby, relying on Apache QPID for the transport mechanism. I modeled it after Apache QMF, though nowhere near as complex (simrpc is procedural based for example, with data structures only encapsulating data, and not methods), intended to be a placeholder until QMF becomes a bit more stable.
I was able to whip it up pretty quick, it only took me a week to write end-to-end, and thus I'm releasing it under the MIT License instead of my usual favorite, the AGPL. Eventually its a possibility that I might rewrite it in C++ as there isn't anything ruby-specific in it and I could easily then after write a Ruby wrapper (or any other).
Have at it!
Sometimes all you need is a good nights rest, I spent a considerable amount of time on this problem yesterday only to realize the solution was very simple.
Watch out when running the oVirt server on an vm, with your guest network set to the libvirt 'default' network on your host machine. The oVirt server depends on / will install libvirt and run libvirtd in your vm. Thus upon your first post-install restart, you will have the libvirtd default network interface, addressed at 192.168.122.1 running in your vm. Since various packets coming from the libvirt interface on your _host_ machine will have that same address, their responses will never make it back, rather they will goto the libvirt interface on your _vm_ and be subsequently discarded.
You most likely will notice this issue if you use tcpdump and you are receiving lots of ARP requests for your MAC from ip on your guest interface but no responses. Even running tcpdump on the libvirt network interface won't yield the responses, as even though their being sent there, that address just resolves to the local machine, and the kernel just processes the packets it already has.
To resolve this either just stop the libvirt daemon running on your oVirt vm (sudo service libvirtd stop) or use another network other than the "default" as one of the two for your libvirt server vm. Hope this helps!
Another caveat to look out for when using activerecord, especially for those of you who are using the nested set module and have optimistic locking turned on (which I'm guessing by the timestamp on that patch is making its ways to the Linux repos just about now).
It turns out when you go to destroy a model object in a nested set, it first updates the lft and rgt attributes before running the correct delete query against the db. eg
UPDATE "pools" SET lft = CASE WHEN lft > 13 THEN (lft - 2) ELSE lft END, rgt = CASE WHEN rgt > 13 THEN (rgt - 2 ELSE rgt END WHERE (1 = 1)
DELETE FROM "pools" WHERE "id" = 8 AND "lock_version" = 0
Unfortunately when optimistic locking is enabled (as it seems to be by default now), activerecord will detect the record has already been updated before it attempts to destroy it and will throw a "StaleObjectError" reporting "Attempted to delete a stale object". The object being used to perform the update, no longer reflects the current db state (granted it's only "lock_version", the db field used to perform lock checks, that is inconsistent, but that is enough to throw it off).
The only work around which I know of right now, save fixing ActiveRecord itself, is to use delete instead of destroy, which obviously is not optimal and doesn't work for all cases. I need to look into this issue some more myself, and will follow up with a better fix if I find it. Until then this also may help
Massive Attack (perhaps the best band in the world :-D) just released an EP in anticipation for their (hopefully) soon to be released LP (I say hopefully as they've been delaying the release for over 4 years now).
As with all their other work this latest EP, titled "Splitting The Atom" is phenominal. Check out the title track