So we've been noticing some pretty odd things with BackgrounDrb lately. In spite of our previous fixes to BackgrounDrb, we've decided to give up on it. Why? Simply put: It's not working properly.
We've been checking the logs recently, and we've noticed way too many calls to our scheduled tasks. On the odd days, we'll get 3 or 4 extra calls when only 1 was scheduled. I don't know how to explain this, nor do I wish to find out, because frankly, I'm fed up with this.
I admit, it really was my fault for trying to use an overly complicated program to run something very simple. KISS - I know. I'm kicking myself in the ass for this now! Anyways, simple solution: cron. It's the most basic of basic schedulers. You can't go wrong here.
Luckily, all our functions were encapsulated in the models, so the logic didn't need to be changed. We ripped out the stuff in the BackgrounDrb worker and placed them in a rake file. We then called the rake tasks from the cron.
Very simple. Very clean.
Bye Bye BackgrounDrb!
W
Showing posts with label Dislikes. Show all posts
Showing posts with label Dislikes. Show all posts
Tuesday, September 9, 2008
Tuesday, August 26, 2008
Geokit: Oddities
1. When using Geokit + Google, sometimes, giving a valid postal code will fail. It's a very random thing. I'm not sure if it's just Google, but sometimes, it fails, even with a valid postal code. I'm guessing it has something to do with the network or perhaps they limit how many you can ask for in a period of time so you don't overload their server.
2. If you add :within to your find, Geokit doesn't recognize that :within => nil means not to add :within. Sometimes, you have a variable that may or may not be nil, and this controls whether you want to search using a distance. The :origin key works fine with nil, but :within does not. It blindly adds the distance calculations to the find. I had to hack acts_as_mappable.rb a little bit in order to get it to work.
In the apply_distance_scope(options) function, I have:
distance_condition = "#{distance_column_name} <= #{options[:within]}" if options.has_key?(:within) && !options[:within].nil?
distance_condition = "#{distance_column_name} > #{options[:beyond]}" if options.has_key?(:beyond) && !options[:beyond].nil?
and
[:within, :beyond, :range].each { |option| options.delete(option) }
This will take the :within => nil into account and skip the adding of the distance calculations out of the find and remove the useless keys.
3. In the Geokit README, there is a section about using :includes. However, there isn't a section on using :joins. Apparently, when you use :joins, things can screw up. For instance, if I have
Shop.find(:joins => "INNER JOIN products where products.shop_id = shops.id", :conditions => ..., :origin => ..., :within => ...)
You would expect a Shop object to be returned. This is true, but I found a small error. The Product id replaced the Shop id, leaving me with a Shop object with an id of the Product id.
I traced this down to the function add_distance_to_select(...). In this function, it blindly sets the :select option in the find to "*" if it isn't already defined. I'm guessing, because both Shop and Product have ids, they get mixed up somehow.
In order to fix this, I needed to add :select => "shops.*".
Hopefully, this info helps those that are having the same problems. If you have a better solution, feel free to share!
W
2. If you add :within to your find, Geokit doesn't recognize that :within => nil means not to add :within. Sometimes, you have a variable that may or may not be nil, and this controls whether you want to search using a distance. The :origin key works fine with nil, but :within does not. It blindly adds the distance calculations to the find. I had to hack acts_as_mappable.rb a little bit in order to get it to work.
In the apply_distance_scope(options) function, I have:
distance_condition = "#{distance_column_name} <= #{options[:within]}" if options.has_key?(:within) && !options[:within].nil?
distance_condition = "#{distance_column_name} > #{options[:beyond]}" if options.has_key?(:beyond) && !options[:beyond].nil?
and
[:within, :beyond, :range].each { |option| options.delete(option) }
This will take the :within => nil into account and skip the adding of the distance calculations out of the find and remove the useless keys.
3. In the Geokit README, there is a section about using :includes. However, there isn't a section on using :joins. Apparently, when you use :joins, things can screw up. For instance, if I have
Shop.find(:joins => "INNER JOIN products where products.shop_id = shops.id", :conditions => ..., :origin => ..., :within => ...)
You would expect a Shop object to be returned. This is true, but I found a small error. The Product id replaced the Shop id, leaving me with a Shop object with an id of the Product id.
I traced this down to the function add_distance_to_select(...). In this function, it blindly sets the :select option in the find to "*" if it isn't already defined. I'm guessing, because both Shop and Product have ids, they get mixed up somehow.
In order to fix this, I needed to add :select => "shops.*".
Hopefully, this info helps those that are having the same problems. If you have a better solution, feel free to share!
W
Tuesday, June 24, 2008
Ubuntu Gutsy Update + VMware Server
Sorry for not posting anything for quite a while now. Been super busy with some other stuff.
Just wanted to vent a little. I believe yesterday, or the day before, there was an update to Ubuntu Gutsy. All is well, except when I tried to run VMware Server today, it wouldn't start! I checked the logs and said there was something to do with /dev/vmmon. After a quick Google search, I discovered that the new update had broken VMware Server! NOOOOOOOOOOOO!!!!!! This sucks!
A solution I found was to not use the repository version of VMware Server, as it is old anyways. I'm not sure if I want to go through the trouble of reinstalling it manually on a 64-bit machine though... I guess I'll wait and see how long it takes them to fix it T.T
W
Just wanted to vent a little. I believe yesterday, or the day before, there was an update to Ubuntu Gutsy. All is well, except when I tried to run VMware Server today, it wouldn't start! I checked the logs and said there was something to do with /dev/vmmon. After a quick Google search, I discovered that the new update had broken VMware Server! NOOOOOOOOOOOO!!!!!! This sucks!
A solution I found was to not use the repository version of VMware Server, as it is old anyways. I'm not sure if I want to go through the trouble of reinstalling it manually on a 64-bit machine though... I guess I'll wait and see how long it takes them to fix it T.T
W
Wednesday, June 4, 2008
Ubuntu + AMD64 + Flash
Well, apparently, this combination just doesn't go well together. I'm running Gutsy right now, and having a horrible time with Flash. I've already tried using the install script given in the Ubuntu forums, only to have it half working. Sometimes, everything plays, sometimes, nothing plays. I can usually get YouTube working, but there are some Flash sites that just don't work.
I was recently trying to play a .swf file by simply dragging it into FireFox. To my dismay, I ended up with a gray screen. Sucks!
I finally found a workaround... at least for .swf files. I downloaded the Windows Flash Player 9 Projector content debugger (standalone player) from the Adobe site. I then created a launcher using the command:
wine /path/to/standalone_player
BAM! It works wonderfully. However, still no hope for the stuff that is online T.T
W
I was recently trying to play a .swf file by simply dragging it into FireFox. To my dismay, I ended up with a gray screen. Sucks!
I finally found a workaround... at least for .swf files. I downloaded the Windows Flash Player 9 Projector content debugger (standalone player) from the Adobe site. I then created a launcher using the command:
wine /path/to/standalone_player
BAM! It works wonderfully. However, still no hope for the stuff that is online T.T
W
Tuesday, May 6, 2008
CSS: z-index
I ran into this problem with stacking order. It seems pretty simple to me, but Internet Explorer has managed to screw it up... again! I don't blame them if IE6 has problems, but for goodness sakes, fix it in IE7!! But alas, that's not to be and I'm stuck here with some crappy options. Actually, I don't mind... my users will though.
Basically, I have a few divs, and they're going to overlap. With proper z-index, everything is fine. However, without it, I can't implement what I want to do. So in the end, it's the users who suffer... that is if they use IE. I ended up using conditional comments (awesome stuff!) to do what I want to do if the user is not on IE.
Apparently, they say that IE8 fixes this and that it will be completely standards compliant, but my question is when will that be released and when will all the users no longer be using anything earlier than IE8... it's definitely going to be a long wait...
Damn IE sucks!
W
Basically, I have a few divs, and they're going to overlap. With proper z-index, everything is fine. However, without it, I can't implement what I want to do. So in the end, it's the users who suffer... that is if they use IE. I ended up using conditional comments (awesome stuff!) to do what I want to do if the user is not on IE.
Apparently, they say that IE8 fixes this and that it will be completely standards compliant, but my question is when will that be released and when will all the users no longer be using anything earlier than IE8... it's definitely going to be a long wait...
Damn IE sucks!
W
Wednesday, February 27, 2008
Ubuntu Freeze Ups
In case anyone is running a dual core 64-bit machine with a nVidia graphics card, check out this bug:
https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/145112
You just might end up with system freezes... T.T
W
https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/145112
You just might end up with system freezes... T.T
W
Friday, February 15, 2008
Ubuntu Screensavers
It's usually very normal to use a screensaver... they're pretty! Well... don't try with Ubuntu's pre-installed screensavers. There may be incompatibility with my computer which caused this, but I'm not sure.
What happened was that when I set my screensaver to braid (I was browsing the screensavers), my Ubuntu froze. I couldn't do anything. Not even Ctrl + Alt + F1 would bring me to a console. I ended up having to press the Shutdown button on my computer! Then when I got back in and tried to change the screensaver back to blank, it would freeze because it was generating the preview for braid... ARGH!!! Also, whenever the screensaver would come on, it would also freeze Ubuntu!
I spent a while trying to figure out how to change the screensaver back to blank... with no luck, but at least I found many people were having the same problems. I then decided to just look around myself and BINGO!
> gedit ~/.gconf/apps/gnome-screensaver/%gconf.xml
Change the screensaver property back to:
screensaver-none
This changes the screensaver back to blank... which I had no problems with to begin with... never touching this thing again unless I know it's ok.
W
What happened was that when I set my screensaver to braid (I was browsing the screensavers), my Ubuntu froze. I couldn't do anything. Not even Ctrl + Alt + F1 would bring me to a console. I ended up having to press the Shutdown button on my computer! Then when I got back in and tried to change the screensaver back to blank, it would freeze because it was generating the preview for braid... ARGH!!! Also, whenever the screensaver would come on, it would also freeze Ubuntu!
I spent a while trying to figure out how to change the screensaver back to blank... with no luck, but at least I found many people were having the same problems. I then decided to just look around myself and BINGO!
> gedit ~/.gconf/apps/gnome-screensaver/%gconf.xml
Change the screensaver property back to:
screensaver-none
This changes the screensaver back to blank... which I had no problems with to begin with... never touching this thing again unless I know it's ok.
W
Saturday, February 2, 2008
IE 6 Hidden Inputs
There are often times when you need to use hidden inputs, whatever the reason is. As the name suggests, these are hidden inputs, and should NOT be displayed.
However, as usual, IE 6 decides to go against common sense and do something strange. In this case, IE 6 seems to reserve some space for hidden inputs. You end up with odd blank spaces here and there, depending where you put your hidden inputs.
It took me a while to figure out it was the hidden inputs (after pulling out my hair several times). I used a very simple hack to get rid of them afterwards:
position: absolute;
left: 9999px;
That zips the hidden inputs off the page and out of sight, even in IE 6!
W
However, as usual, IE 6 decides to go against common sense and do something strange. In this case, IE 6 seems to reserve some space for hidden inputs. You end up with odd blank spaces here and there, depending where you put your hidden inputs.
It took me a while to figure out it was the hidden inputs (after pulling out my hair several times). I used a very simple hack to get rid of them afterwards:
position: absolute;
left: 9999px;
That zips the hidden inputs off the page and out of sight, even in IE 6!
W
Thursday, January 31, 2008
IE 6 Minimum Height
IE is such a wonderful browser... *cough* Anyways, I found a slight display problem with divs in IE 6. Apparently, the div will only shrink to a certain height before it stops shrinking. From experimenting, I found the height to be around 20px.
Anything larger than 20px, IE 6 will display properly. However, anything below 20px, such as 15px, IE 6 will continue to display as 20px. Frustrating huh?
I found a hack to get around this, which is to set the div to:
overflow: hidden;
This will allow the div to shrink to any height, and hide the content inside the div that goes over the specified height.
Annoying.
W
Anything larger than 20px, IE 6 will display properly. However, anything below 20px, such as 15px, IE 6 will continue to display as 20px. Frustrating huh?
I found a hack to get around this, which is to set the div to:
overflow: hidden;
This will allow the div to shrink to any height, and hide the content inside the div that goes over the specified height.
Annoying.
W
12 Hour Time
RoR comes with many fantastic helpers for the view. However, there is one helper that is definitely lacking some features. Perhaps it is purposely missing features because of its complexity and range of customization. What I'm referring to is the DateHelper.
Firstly, when selecting a date, having selects as inputs just outright sucks! It's very hard for the user to visualize such a layout. We are used to seeing calendars. In what real world situation do you ever look at dates in a select box format... none that I can think of. But calendars, that's another story. Calendars are so normal to users that without them, we're lost! Unfortunately, RoR does not come prepackaged with a calendar format for dates. But luckily, RoR is extendable through plugins! We're currently testing out which one works best for us, and we'll let you know when we've come to a decision.
The second problem with the prepackaged helper is the fact that when selecting times, we're forced to take the inputs based on a 24 hour clock... EWWW!!! No body works on a 24 hour clock (except if you're in the military...) The usual person just isn't used to seeing a 24 hour clock. That's where plugins come in again!
I found a plugin that worked very well and required very little modifications:
12_hour_time
This plugin allows you to add an option to your current time selects to make them based on a 12 hour clock:
:twelve_hour => true
The rest (frontend and backend) are automatically handled for you!
Brilliant!
W
Firstly, when selecting a date, having selects as inputs just outright sucks! It's very hard for the user to visualize such a layout. We are used to seeing calendars. In what real world situation do you ever look at dates in a select box format... none that I can think of. But calendars, that's another story. Calendars are so normal to users that without them, we're lost! Unfortunately, RoR does not come prepackaged with a calendar format for dates. But luckily, RoR is extendable through plugins! We're currently testing out which one works best for us, and we'll let you know when we've come to a decision.
The second problem with the prepackaged helper is the fact that when selecting times, we're forced to take the inputs based on a 24 hour clock... EWWW!!! No body works on a 24 hour clock (except if you're in the military...) The usual person just isn't used to seeing a 24 hour clock. That's where plugins come in again!
I found a plugin that worked very well and required very little modifications:
12_hour_time
This plugin allows you to add an option to your current time selects to make them based on a 12 hour clock:
:twelve_hour => true
The rest (frontend and backend) are automatically handled for you!
Brilliant!
W
Monday, January 21, 2008
DRYing Up YAML Fixtures (except for PostgreSQL!!!)
When creating YAML fixtures, there are many records that have many repeated values. For example:
user_1:
name: john
is_active: true
user_2:
name: billy
is_active: true
Here, the is_active field is repeated many times and has the same value true. This may be a default for many records. YAML allows you to set defaults:
defaults: &defaults
is_active: true
user_1:
name: john
<<: *defaults
user_2:
name: billy
<<: *defaults
Obviously, this simple example doesn't save us any time. However, if our defaults include many columns, this can save a lot of typing and headaches when default values need to be changed.
All this is wondeful... EXCEPT when your using PostgreSQL, and it's driving me NUTS!!! For some reason, this DRY method doesn't work. I haven't figured out why yet and my search for the answer has been rather futile. If any one has an answer, I'd like to know the reason.
W
user_1:
name: john
is_active: true
user_2:
name: billy
is_active: true
Here, the is_active field is repeated many times and has the same value true. This may be a default for many records. YAML allows you to set defaults:
defaults: &defaults
is_active: true
user_1:
name: john
<<: *defaults
user_2:
name: billy
<<: *defaults
Obviously, this simple example doesn't save us any time. However, if our defaults include many columns, this can save a lot of typing and headaches when default values need to be changed.
All this is wondeful... EXCEPT when your using PostgreSQL, and it's driving me NUTS!!! For some reason, this DRY method doesn't work. I haven't figured out why yet and my search for the answer has been rather futile. If any one has an answer, I'd like to know the reason.
W
Wednesday, January 2, 2008
Radio Buttons
RoR is lovely when it comes to supplying frontend helpers. For example, if you want to create a form for a particular object, it's very simple:
<% form_for :user, :url => new_user_path do |f| %>
...
<% end %>
Inside "...", you can add all your fields, such as:
However, our topic for today is actually radio buttons. Many times, we want to use radio buttons to select some sort of true/false field. It is possible to do this with checkboxes, andRoR is wonderful with this. However, sometimes, 2 radio buttons are better. This is where I ran into some problems. Reading the API, I came up with 2 radio buttons as follows:
<%= f.radio_button :is_good, true %>
<%= f.radio_button :is_good, false %>
I thought that this would generate two radio buttons with values true/false respectively. However, it didn't! The first generated one that had a value of "true" and was checked. But the second generated a radio button with no value! I then changed the given values from booleans to strings:
<%= f.radio_button :is_good, 'true' %>
<%= f.radio_button :is_good, 'false' %>
Everything worked fine now, but given a model that held data, neither radio buttons were checked! This is due to the fact that the model holds boolean values, whereas the radio buttons use string literals. Saving was fine because we were using prepared statements, which automatically convert the string literals to boolean. I was completely stumped on the displaying of data though. I came up with a quick hack using virtual attributes, but it's ugly:
def is_good_temp=(is_good_temp)
@is_good_temp = is_good_temp
if @is_good_temp == 'true'
self.is_good = true
else
self.is_good = false
end
end
def is_good_temp
@is_good_temp.nil? ? 'true' : @is_good_temp
end
def is_good
@is_good.nil? ? true : @is_good
end
def is_good=(is_good)
@is_good = is_good
end
and changed the radio buttons to:
<%= f.radio_button :is_good_temp, 'true' %>
<%= f.radio_button :is_good_temp, 'false' %>
So basically what I did was create a virtual attribute to deal with the radio buttons using string literals, and have that convert the string literals to booleans and assign it to the actual variable. To be noted is that there is no nice function object#to_b to convert a string literal to boolean. There are nice functions like object#to_s and object#to_i, but not to boolean.
This is one disappointment from RoR. I have searched around and could find no solution to this. Perhaps I am doing this wrong, but for now, it works.
Any ideas would be appreciated, and I'll update if I find a better solution.
W
<% form_for :user, :url => new_user_path do |f| %>
...
<% end %>
Inside "...", you can add all your fields, such as:
First name: <%= f.text_field :first_name %>
Last name: <%= f.text_field :last_name %>
...
<%= submit_tag 'Update' %>
However, our topic for today is actually radio buttons. Many times, we want to use radio buttons to select some sort of true/false field. It is possible to do this with checkboxes, andRoR is wonderful with this. However, sometimes, 2 radio buttons are better. This is where I ran into some problems. Reading the API, I came up with 2 radio buttons as follows:
<%= f.radio_button :is_good, true %>
<%= f.radio_button :is_good, false %>
I thought that this would generate two radio buttons with values true/false respectively. However, it didn't! The first generated one that had a value of "true" and was checked. But the second generated a radio button with no value! I then changed the given values from booleans to strings:
<%= f.radio_button :is_good, 'true' %>
<%= f.radio_button :is_good, 'false' %>
Everything worked fine now, but given a model that held data, neither radio buttons were checked! This is due to the fact that the model holds boolean values, whereas the radio buttons use string literals. Saving was fine because we were using prepared statements, which automatically convert the string literals to boolean. I was completely stumped on the displaying of data though. I came up with a quick hack using virtual attributes, but it's ugly:
def is_good_temp=(is_good_temp)
@is_good_temp = is_good_temp
if @is_good_temp == 'true'
self.is_good = true
else
self.is_good = false
end
end
def is_good_temp
@is_good_temp.nil? ? 'true' : @is_good_temp
end
def is_good
@is_good.nil? ? true : @is_good
end
def is_good=(is_good)
@is_good = is_good
end
and changed the radio buttons to:
<%= f.radio_button :is_good_temp, 'true' %>
<%= f.radio_button :is_good_temp, 'false' %>
So basically what I did was create a virtual attribute to deal with the radio buttons using string literals, and have that convert the string literals to booleans and assign it to the actual variable. To be noted is that there is no nice function object#to_b to convert a string literal to boolean. There are nice functions like object#to_s and object#to_i, but not to boolean.
This is one disappointment from RoR. I have searched around and could find no solution to this. Perhaps I am doing this wrong, but for now, it works.
Any ideas would be appreciated, and I'll update if I find a better solution.
W
Subscribe to:
Posts (Atom)