Probably one of the easiest things you'll ever do with gpg
Install Keybase: https://keybase.io/download and Ensure the keybase cli is in your PATH
First get the public key
keybase pgp export | gpg --import
Next get the private key
Probably one of the easiest things you'll ever do with gpg
Install Keybase: https://keybase.io/download and Ensure the keybase cli is in your PATH
First get the public key
keybase pgp export | gpg --import
Next get the private key
# The fundamantal design opinion is that a Stock Return has many Returned Items | |
# Each Returned Item effectively has one of 3 actions associated with it return, exchange OR replace | |
# Any of these action can involve a refund, although the most common is that a return involves a refund | |
# You may wish to refund a replacement Or exchange to maintain customer relations | |
# | |
# Once all Returned Items and their actions have been set then you can commence to attempt to process the Stock Return | |
# Processing the Stock Return will automate the Order Adjustments, Addiitonal Shipments and any Refunds / Payments | |
# It should be exstensible so that developers can easily implement their own behaviour here | |
# | |
# It could be that a developer can extend this to Create New Orders instead of Additional Shipments under certain scenarios: |
Capybara.add_selector :record do | |
xpath { |record| XPath.css("#" + ActionController::RecordIdentifier.dom_id(record)) } | |
match { |record| record.is_a?(ActiveRecord::Base) } | |
end |
#order model decorator | |
Order.class_eval do | |
accepts_nested_attributes_for :line_items, :allow_destroy => true | |
def self.build_from_api(user, params) | |
order = create | |
params[:line_items_attributes].each do |line_item| | |
order.add_variant(Spree::Variant.find(line_item[:variant_id]), line_item[:quantity]) | |
end |
# As root user | |
sudo su | |
# Update the OS | |
sudo apt-get update -y | |
# Add this to ~/.bashrc to remove timezone warnings | |
echo 'export LC_ALL="en_US.UTF-8"' >> ~/.bashrc | |
source ~/.bashrc |
# Rails developers have long had bad experiences with fixtures for | |
# several reasons, including misuse. | |
# | |
# Misuse of fixtures is characterized by having a huge number of them, | |
# requiring the developer to maintain a lot of data and creating dependencies | |
# between tests. In my experience working (and rescuing) many applications, 80% | |
# of fixtures are only used by 20% of tests. | |
# | |
# An example of such tests is one assuring that a given SQL query with | |
# GROUP BY and ORDER BY conditions returns the correct result set. As expected, |
With Rails 3.0 released a few weeks ago I've migrated a few apps and I'm constantly finding useful new improvements. One such improvement is the ability to log anything in the same way that Rails internally logs ActiveRecord and ActionView. By default Rails 3 logs look slightly spiffier than those produced by Rails 2.3: (notice the second line has been cleaned up)
Started GET "/" for 127.0.0.1 at Mon Sep 06 01:07:11 -0400 2010
Processing by HomeController#index as HTML
User Load (0.2ms) SELECT `users`.* FROM `users` WHERE (`users`.`id` = 3) LIMIT 1
CACHE (0.0ms) SELECT `users`.* FROM `users` WHERE (`users`.`id` = 3) LIMIT 1
Rendered layouts/_nav.html.erb (363.4ms)