Category: Blog

Rails Ajax Image Uploading Made Simple With JQuery

Rails Ajax Image Uploading Made Simple With JQuery

Last week, as part of getting Bloggity rolling with the key features of WordPress, I realized that we needed to allow the user to upload images without doing a page reload. Expecting a task as ordinary as this would be well covered by Google, I dutifully set out in search of “rails ajax uploading” and found a bunch of pages that either provided code that simply didn’t work, or claims that it couldn’t be done without a Rails plugin.

Not so. If you use jQuery and the jQuery-form plugin.

The main challenge in getting a AJAX uploading working is that the standard remote_form_for doesn’t understand multipart form submission, so it’s not going to send the file data Rails seeks back with the AJAX request. That’s where the jQuery form plugin comes into play. Here’s the Rails code for it:

<% remote_form_for(:image_form, :url => { :controller => "blogs", :action => :create_asset }, :html => { :method => :post, :id => 'uploadForm', :multipart => true }) do |f| %>
 Upload a file: <%= f.file_field :uploaded_data %>
<% end %>

Here’s the associated Javascript:

$('#uploadForm input').change(function(){
 $(this).parent().ajaxSubmit({
  beforeSubmit: function(a,f,o) {
   o.dataType = 'json';
  },
  complete: function(XMLHttpRequest, textStatus) {
   // XMLHttpRequest.responseText will contain the URL of the uploaded image.
   // Put it in an image element you create, or do with it what you will.
   // For example, if you have an image elemtn with id "my_image", then
   //  $('#my_image').attr('src', XMLHttpRequest.responseText);
   // Will set that image tag to display the uploaded image.
  },
 });
});

And here’s the Rails controller action, pretty vanilla:

 @image = Image.new(params[:image_form])
 @image.save
 render :text => @image.public_filename

As you can see, all quite straightforward with the help of jQuery. I’ve been using this for the past few weeks with Bloggity, and it’s worked like a champ.

More to read: 6 Guidelines for choosing the best SEO Agency in Australia

Continue Reading

Rails 3 Autoload Modules/Classes – 3 Easy Fixes

Rails 3 Autoload Modules/Classes – 3 Easy Fixes

Judging by the number of queries on Stack Overflow, it is a very common problem for folks using Rails 3 that they are not getting the modules or classes from their lib directory loaded in Rails 3, especially in production. This leads to errors like “NoMethodError,” “No such file to load [file in your lib path],” and “uninitialized constant [thing you’re trying to load].”  From the information I canvassed trying to solve the problem this morning, there are three common reasons (and one uncommon reason) that this can happen. I’ll go in order of descending frequency.

1. You haven’t included the lib directory in your autoload path

Rails 3 has been updated such that classes/modules (henceforth, C/M) are lazy loaded from the autoload paths as they are needed.  A common problem, especially for the newly upgraded, is that the C/M you are trying to load isn’t in your autoload path.  Easy enough fix:

config.autoload_paths += Dir["#{config.root}/lib/**/"]

This will autoload your lib directory and any subdirectories of it. Similarly, if you have model subdirectories, you may need to add

config.autoload_paths += Dir["#{config.root}/app/models/**/"]

To your application.rb file.

See also: 6 Guidelines for choosing the best SEO Agency in Australia

2.  Your C/M is not named in the way Rails expects

Rails has opinions about what the name of your C/M should be, and if you name it differently, your C/M won’t be found.  Specifically, the namespace for your C/M should match the directory structure that leads to it.  So if you have a C/M with the filename “search.rb” in the lib/google directory, it’s name should be “Google::Search.”  The name of the C/M should match the filename, and the name of the directory (in this case “Google”) should be part of the namespace for your module.  See also this.

3.  Your application is threadsafe.

This was one that was hard to find on SO or Google, but if you have configured your application to be threadsafe (done by default in production.rb), then the C/Ms you have, even if they exist in your autoload path, will not be defined until you require them in your application.  According to the Rails docs, there is apparently something not threadsafe about automatically loading the C/Ms from their corresponding files.  To workaround this, you can either require your individual library files before you use them, or comment out config.threadsafe!

4.  (Esoteric) You have a model in a subdirectory, where the name of the subdirectory matches the name of the model.

Yes, this is another error we actually had when upgrading from Rails 2 to 3:  as of Rails 3.0.4 there is a bug wherein, if you have a directory app/models/item and you have the file “item.rb” in your app/models/item directory, then you will get errors from Rails that your models are undefined (usually it picks the second model in the item subdirectory).  We fixed this by just renaming our subdirectories where appropriate.  Hopefully in one of the next versions of Rails this will get fixed and no longer be a possible problem.

Had other reasons why C/Ms failed to load for you?  Do post below and we can gather up all the possibilities in one tidy location.

Continue Reading

Set/Increase Memory Available in Rubymine

Set/Increase Memory Available in Rubymine

I did not find anything to love about the results I was getting searching for queries like “Increase rubymine memory” and “set rubymine memory”. Here’s the location of the file that dictates Rubymine memory usage in my Ubuntu install:

[RUBYMINE_DIRECTORY]/bin/rubymine.vmoptions

Inside you can specify lines like:

-Xms800m
-Xmx1200m
-XX:MaxPermSize=1000m
-ea

These declare maximum memory usage, maximum sustained memory usage, and, uh, some other stuff.

[Hops onto soapbox]
I love Rubymine, but I sometimes wish that instead of adding a ridiculous number of new features, they’d just make the damn thing run consistently fast, and not make me worry about memory usage. I know that with my web site I always have a preference toward adding cool new stuff, but responsible thing to do is often to perfect the pieces that are already there. Almost everything negative I’ve heard about Rubymine (which isn’t all that much) is along this same vein, but I’ve never heard the Rubymine team admit that it wishes that the product ran faster or its memory management were better.

For my money, still definitely the best choice for Linux IDEs.

More to read: Certified SEO Agencies for your writing business

Continue Reading

Linux touchpad like a Macbook: goal worth pursuing?

Linux touchpad like a Macbook: goal worth pursuing?

Following is my proposal to improve the state of Linux touchpad drivers. It’s a cause I have spent almost a year of my spare time researching in depth. The first section, below, surveys the landscape of today’s available Linux touchpad drivers. The second section (“The Journey Here“) gets into greater depth describing the current failings of available choices. The third section (“The Path Forward“) proposes my best ideas for how we might be able to realize a Linux touchpad driver with polish level matching a Macbook Pro.

A survey of today’s Linux touchpad drivers

For the last 6 months, I’ve been trying to configure a Dell Precision laptop running Arch to get the same feel as the Macbook Pros I loved until the Touchbar Era. I started with the Arch default, libinput. I gave up on it in about a week, when I determined that something as simple as controlling the two-finger scroll speed was not included in the available options. The default was about 3x faster than the comfortable speed I’ve grown to love with my Macbooks. Had I not been disuaded by scroll speed, I might’ve still abandoned ship for the lack of scroll gliding (a feature I never knew I’d been using until it was taken away), which apparently I have Strong Opinions about.

More to read: Affordable and best SEO experts in Australia

Linux being Linux, I figured that I’d have a universe of touchpad drivers to choose from, each with its own awkward UI that would be confusing and painful to use, but ultimately get the job done. What I discovered instead was all of three options: one of which I had just eliminated (libinput), one that has been abandoned by its maintainers in favor of libinput (synaptics), and a third that was also abandoned by its maintainers, with zero graphical UI left behind (mtrack).

I’m writing this blog because I appreciate the nuances of how the Macbook touchpad performs, but the Touchbar Era has taught me that it sucks to have my user experience tied to the whims of a singleminded hardware company. I want to be part of the solution to create a Linux touchpad driver that’s indistinguishable from the Macbook, and has at least a minimal UI to accommodate the most common differences in user preference. I believe this would bring Linux hardware a big step closer to owning the same panache that makes the Macbook experience special. All evidence collected to date suggests that my mission may well prove quixotic. But if other people care about this, it could get done. I posit my ideas on a path forward here. If you’ve got time and want to learn more about what informs my opinions on the best path forward, read on…

The Journey Here

After realizing libinput wasn’t going to work for me, I found this blog post, whose title seduced me (“The perfect (almost) touchpad settings on Linux”). I went on to write my own follow up blog post, after discovering that the initial blog post left much to be desired compared to the Macbook standard I longed for. When it came to scroll speed and scroll glide, mtrack performed like a champ. Graphical UI be damned, I spent minutes — eventually hours — parsing the documentation. Between the 1,001 options available, I was optimistic about my prospects to recreate my Macbook utopia. And I would’ve done it, if not for the wretched nuisance I’d come to call “Cursor Nudge.” In a nutshell, “Cursor Nudge” is the phenomenon by which the center point of your depressed thumb will glide by a few millimeters as a natural effect of transitioning from the “move cursor” position to the “depress” position. None of mtrack’s 1,001 options could conquer Cursor Nudge, and eventually I grew weary of clicking right next to my target.

Down to my final shot, I really wanted synaptics to work. Yeah, it was abandonware, but it was abandonware that had been forsaken due to its multitude of options. A multitude of options seemed to be what I needed to replicate the Macbook. Initial results were promising: Cursor Nudge was not an issue with Synaptics. In fact, for my first few days using it, I found it pretty bearable. I wouldn’t confuse it with Macbook — not without the smooth acceleration and deceleration. Not with only the slighest twinge of scroll glide. Not with the need to click in the bottom right corner to effect a right click. But it was… probably satisfactory. If not for the bugs. About once or twice a day, when I put my thumb down to click or start scrolling, my open document would jerk toward the bottom of the scrollable viewing area. I Googled it. I installed the xinput listener, captured all my tracking input into logs, and tailed the logs to look for patterns that preceded the bug. And then I wondered, “does Apple still sell the pre-Touchbar Macbook?” Turns out, in what I can only interpret as tacit admission of their wrongdoing, they do. It doesn’t have enough RAM, and much of its technology is 10 years old. But its polish level remains eons beyond what I can replicate with Linux, and I refuse to carry around a mouse.

As a last resort, I emailed the maintainer of libinput (previously maintainer of Synaptics). I asked him what it would take to write a Linux touchpad driver that would approach parity with the Macbook. His take wasn’t optimistic (“unless you raise enough money to hire at least one full-time developer there’s little point”). I have to imagine this is what naturally happens to a developer that has spent large swaths of a career worrying about backwards compatibility and subtle hardware differences. It sounds like a special type of hell, and I appreciate the heroics that have gone into making a variety of Linux touchpad drivers almost good enough. But, even though I did eventually cave and buy new old Macbook, I’m not resigned to the imperfections of the current Linux touchpad landscape. A friend of mine who doesn’t even work in tech pointed out to me a month ago that he was reading a random post where they linked to my first blog post pursuing a Macbook-equivalent Linux driver. Somebody besides me cares about this.

The Path Forward

Wherein it becomes apparent that the author doesn’t yet know the best solution.

I think a polished driver could only be delivered within a narrow range of parameters. It probably isn’t going to support laptops older than 3-5 years old. It isn’t going to offer 1,001 options. It may or may not be continuously supported. It may use one of the existing drivers as a starting point, even if that starting codebase isn’t “clean” or well-documented.

Could we build something that works better than existing solutions for 95% of users (= developers) for less than $100k? Probably. Do users (or companies) feel enough pain with the Linux touchpad solutions that they’d donate money (or time) to tackle an esoteric issue? That is what I need to find out.

With a sufficiently enthusiastic response to this blog (todo: define sufficient), I would volunteer my own time to spearhead the non-development aspects of a solution [1]. I could create a Kickstarter page, or help PM or QA development efforts on a driver built to mimic Macbook on the widest possible range of modern laptops. I could donate time to whatever better idea you present. But, first I need a hand to determine: does this actually matter?

Continue Reading
Back to top