We recently had an issue on our site printing user resumes. Resumes that should have been multiple pages were only being printing the first page in Internship Explorer (and the bottom of the page even printing Page 1 of 1 – so clearly IE thought that there was only one page). The issue seemed to the be the fact that our print.css file was using absolute positioning on an element. Although Chrome and FireFox were able to print correctly regardless of this styling; IE was not.

@media print {
  .main-content {
    position: absolute; top: 0; left: 0;
  }
}

Removing the absolute positioning caused IE to recognize the other pages. Of course we had to readjust our css so that the printing styles still looked how we wanted. Hopefully this helps you solve any similar issues you maybe be having.

If you are using Amazon AWS for cloud hosting without support added to your account, then every once in a while you will have to deal with an instance that has become unresponsive (can’t connect to it and it won’t respond to reboot, stop or force stop). If you don’t have support you are essentially stuck to posting on their forum’s asking Amazon to reboot your instance for you. Here is a link to a forum post I made in April 2013 you can use as a sample if you ever run into this issue:

https://forums.aws.amazon.com/message.jspa?messageID=440609

Hope this helps you out!

I was recently trying to find a good solution for deleting old IIS logs files for our windows servers. I searched the web for anything equivalent to logrotate on linux for a Windows machine but had no luck (actually there was IISLogs, which was something you had to pay for). After much searching I stumbled across this Stackoverflow post which gave the simplest solution to the problem I was facing (we just needed to delete old log files).

forfiles /p "C:\inetpub\logs\LogFiles" /s /m *.* /c "cmd /c Del @path" /d -7

This answer was posted by Reditus Solutions, LLC.

One issue I faced when creating a scheduled task with this command was the command would bring up prompts which would never receive a response and the task would just hang. You can add the /p flag (which silences all prompts) to the Del command: “cmd /c Del @path /p”

The sunspot_test gem allows you to add a tag to a describe/context block automatically starting and stopping a Solr instance within that context.

describe "searching", search: true do
# some code
end

The sunspot_matchers gem provide custom RSpec matchers that you can use to verify that the search you are running using sunspot is correct.

The goal of these matchers are to make it easier to unit test search logic without having to construct the individual fixture scenarios inside of Solr and then actually perform the search against Solr

The gem essentially decorates the Sunspot.session to intercept calls made to it. In order to use it you will have to add the following to your spec_helper.rb file:

config.before do
  Sunspot.session = SunspotMatchers::SunspotSessionSpy.new(Sunspot.session)
end

This is perfect for unit tests since they will not need an actual Solr instance to work and therefore will be much faster. You use the custom RSpec matchers such as be_a_search_for or have_search_params to verify that the Solr query your code will execute is correct. Then, in your integration tests you can actually do an end to end test with an instance of Solr.

This is exactly what I set out to do, however the config.before block in the spec_helper.rb file intercepted the Sunspot.session and always returned an empty array (even in integration tests). Since I was using the sunspot_test gem which requires adding a tag (search: true) to your describe block I used the following approach to tell RSpec that for these tagged blocks use the actual Solr.session.

config.before do
  Sunspot.session = SunspotMatchers::SunspotSessionSpy.new(Sunspot.session)
end

# SunspotMatchers will keep a reference to the original session so we can access it like so
config.before(:each, search: true) do
  Sunspot.session = Sunspot.session.original_session
end

In this way, anytime we tag a block with search: true we will be using the actual Solr session. Hope this helps someone :-).

I just updated Looksy, https://github.com/aboghosian/looksy, a gem I developed to add a caching layer between your ActiveRecord models that represents look up tables in your database. Originally the gem added the following methods:

1. #fetch_all – retrieves all records from cache
2. #fetch_by_id(id) – retrieves record by id
3. #fetch_by_attribute(‘value’) – retrieves first record matching attribute (can supply multiple attributes by separating with _and_; #fetch_by_this_and_that(‘this’, ‘that’))
4. #fetch_all_by_attribute(‘value’) – retrieves all matching records (can supply multiple attributes as above

A few new methods have been added and here they are:

1. #fetch_first – retrieves the first record
2. #fetch_last – retrieves the last record
3. #fetch_last_by_attributes(‘value’) – retrieves the last matching record (the opposite of using #fetch_by_attribute and supports multiple attributes separated by _and_

To use the gem simple include the Looksy::Cacheable module in your ActiveRecord class (or any class that responds to .all).

class JobType < ActiveRecord::Base
  include Looksy::Cacheable
end

And just like that these methods are added to your class. By default the gem will attempt to use the caching store of Rails.cache if you are using Rails and if not it will default to Looksy::NullCache which essentially does not caching (lol). You can substitute your own cache and set other options the following way:

class JobType < ActiveRecord::Base
  include Looksy::Cacheable

  self.cache_store = MyCacheStore.new
  self.cache_key = 'MyKey'
  self.cache_options = { expires_in: 30.minutes }
end

The gem was a by product of some coding I did at work to cache our look up tables so we didn’t have to hit the database each time to get the data (which changed infrequently). Hope you enjoy and I appreciate feedback (this is my very first gem I’ve published).

I published my very first gem on RubyGems today and the source code is located on GitHub at https://github.com/aboghosian/looksy. Check it out when you get the chance. The gem is the result of a project we were working on in which we wanted a centralized way to cache our look up tables so we didn’t have to hit the database each time to retrieve them (mainly because they changed very infrequently).

Looksy allows you to place a caching layer between your look up tables and ActiveRecord classes. Here is how it works:

class PaymentType < ActiveRecord::Base
  include Looksy::Cacheable
end

# retrieves all records from cache or populates cache from db
PaymentType.fetch_all

# retrieves record matching id
PaymentType.fetch_by_id(id) 

You also get dynamic methods just like ActiveRecords dynamic finders, except instead of using find to prefix your method calls you use fetch.

class PaymentType < ActiveRecord::Base
  include Looksy::Cacheable

  # attributes include :name and :status
end

# retrieve record by name
PaymentType.fetch_by_name("CreditCard")

# retrieve all records by status
PaymentType.fetch_all_by_status("active")

You can chain multiple attributes together as well.

class Coupon < ActiveRecord::Base
  include Looksy::Cacheable

  # attributes include code, status and association_type
end

# retrieve record by code and status
Coupon.fetch_by_code_and_status('100PERCENTOFF', 'active')

# retrieve all records by status and association type
Coupon.fetch_all_by_status_and_association_type('inactive', 'whitelist')