I have been getting intermittent segfaults with Ruby Enterprise Edition 2010.01 on both Mac OSX Snow Leopard 10.6, and Centos 5.3 with LibXML:
See the LibXML Rubyforge page more details, but the solution is to code your document finders as below...
I have been getting intermittent segfaults with Ruby Enterprise Edition 2010.01 on both Mac OSX Snow Leopard 10.6, and Centos 5.3 with LibXML:
See the LibXML Rubyforge page more details, but the solution is to code your document finders as below...
After installing Ruby Enterprise Edition 2010.02 via RVM, I was getting seg faults in the native gems. The solution was easy:
I think i will be adding ARCHFLAGS="-arch x86_64" to my bash_login....
At Sharesight [www.sharesight.co.nz] we operate an online, subscription based portfolio management for DIY share market investors. For convenience, most of our customers choose to pay by credit card, and we bill them on a recurring basis, either monthly or annually. When customers subscribe, we make it clear to them that we will bill their card on a recurring basis (and, most importantly, we also make it easy for customers to cancel their subscription whenever they want).
We use the ActiveMerchant plugin (Ruby on Rails) to connect to the DPS Payment Express payment gateway. DPS connects to our BNZ Buyline merchant account which allows us to bill customers in both NZD and AUD. When we pass through a customer’s card details to DPS they return a billing token, and when we need to bill the card in the future, we simply send through the appropriate billing token to DPS along with the amount to be billed (this amount may change if customers upgrade or downgrade their accounts). This saves us from having to store our customers’ credit card details, and worry about the security issues that this entails.
Until now, the only real issue that we faced was the problem of expiring credit cards. Credit cards generally expire every two years (sometimes more frequently), primarily due to the fact that this is the life expectancy of the magnetic strip on the back of the card. When a customer’s credit card expired, they needed to provide us with the updated card details, otherwise when we tried to charge their card, we would receive a ‘card expired’ error back from DPS. Clearly this somewhat limits the convenience factor for our customers, in fact many customers told us so, pointing out that their card number hadn’t changed.
The solution, as it turns out, is a little known feature called the recurring billing flag. Essentially when a payment is sent through to the bank with the recurring billing flag set, they will (generally) ignore the expiry date when processing the transaction. I came across this feature via this blog post, but could not find it documented anywhere in the technical documentation provided by either the bank or DPS. A quick call to a knowledgeable staff member at DPS, confirmed that they could in fact set this flag for us provided that we obtained written permission from the bank. Luckily we had no problem in obtaining prompt approval from the BNZ, and we were able to have the recurring billing flag enabled on our transactions within a couple of days.
I hope this knowledge is useful for other SaaS vendors who bill customers on a recurring basis. From what I understand, the banks may have different policies on allowing the recurring flag to be set.
Please let us know your experiences.
Special guest post by Scott Ryburn.
He is a copy of my Oauth presentation [806 kB] from tonight's WellRailed group. I discussed Oauth from both a client and a server perspective. Plenty of examples from Sharesight, where we are building an API.
Here is the example test.rb
I also discussed LoadStorm.com, which has a free plan that allows up to 50 simultaneous users. I recommend you check them out.
With the Sharesight test suite (ruby/rails/mysql && rake test), i tested the performance of my the new MBP on Snow Leopard.
I save 16 seconds per run – its going to take a while to pay for itself…. But about 22% faster, which is not too bad.
Macbook Pro (March 06) 1.83GHz 2G Ram
real 1m29.464s
user 0m50.348s
sys 0m5.812s
Macbook Pro (Sep 09) 2.53 GHz 4G Ram
real 1m13.450s
user 0m43.662s
sys 0m3.280s
# first remove your copy and paste plugin….
git rm -r vendor/plugins/xxxxxx git commit
now you are ready to add the submodule
git submodule add git://your_git_repo/xxxxx.git vendor/plugins/xxxxx git commit
To load the submodule, you need to
git submodule init git submodule update
To deploy submodules using capistrano, capistrano needs to also do the submodule init and update.
# in deploy.rb set :git_enable_submodules,1
if you want to update the version of the submodule – or the branch
cd into the plugin, git pull or git checkout branch
then cd back to the containing project and git commit
yours.com/ --> served by rails yours.com/blog --> served by phpTo configure this in apache, The key is the PassengerEnabled – else passenger will try and serve the php content.
This is quite trivial and very easy. I wanted to use the same version of ruby on my mac as is running on our production servers (Ruby Enterprise Edition).
Firstly, do a
gem list
and keep this information. You will need to reinstall all your gems once you have successfully installed REE.
Download REE from http://www.rubyenterpriseedition.com/
tar xvfz ruby-enterprise-X.X.X
sudo ./ruby-enterprise-X.X.X/installer
I suggest changing the default location to just /opt/ruby-enterprise – as you are unlikely to need to roll back the symbolic links in your development environment.
Once it is installed, then you need to make sure that you use it for all your gems, ruby, rake tasks. To do this we will sym link in all the executables into /usr/bin
Find any previous versions of ruby
whereis ruby
and
which ruby
Cleanup – backup and remove any old versions and the associated ruby, gems, rake, irb, cap, capify, erb so they are not on your path.
Then sym link from /usr/bin to opt/ruby-enterprise/bin with all the executables that you may require….
sudo ln -s -f /opt/ruby-enterprise/bin/ruby /usr/bin/ruby sudo ln -s -f /opt/ruby-enterprise/bin/cap /usr/bin/cap sudo ln -s -f /opt/ruby-enterprise/bin/capify /usr/bin/capify sudo ln -s -f /opt/ruby-enterprise/bin/erb /usr/bin/erb sudo ln -s -f /opt/ruby-enterprise/bin/gem /usr/bin/gem sudo ln -s -f /opt/ruby-enterprise/bin/irb /usr/bin/irb sudo ln -s -f /opt/ruby-enterprise/bin/rails /usr/bin/rails sudo ln -s -f /opt/ruby-enterprise/bin/rake /usr/bin/rake sudo ln -s -f /opt/ruby-enterprise/bin/rdoc /usr/bin/rdoc
Do a gem list to see what ruby-enterprise came bundled with.
Now you will need to install all your gems again – that you noted earlier.
Just migrated a legacy database into a rails compliant database – and wrote this nifty DSL script to help out….
The rake task generates the Hash data for the table creation, data insert and rollback scripts.
Once you run the rake task, paste the output into the migration modify the update table and column names – then run the migration.
I had been getting some validation warnings when running some of my specs. The W3 validator confirmed that my xHTML was valid.
After some googling of the problem, it turns out there is a difference between how xhtml and html documents are handled. Essentially, you need to tell the parser that the document is xHTML rather than HTML. More details here, here, and here.
The solution is to tell RSpec that the document is XML based. The options given in the links above work for RUnit based tests. Taking a look at the rspec source, it is checking to see if the response is XML based by noting the Content-Type header record. So, here's the solution I used:
Now, when I run my specs, it correctly parses the response as XHTML and passes validation without any warnings.