Planet LittleChina

helder2: Dynamic Error Pages in Rails 3 with Goalie

Mon, 09 Aug 2010 13:57:00 +0000

As part of my work on Shapado in the Google Summer of Code, I just released a Rails3-compatible little gem (called Goalie) that makes it easy to have custom error pages with dynamic content. It is still very early-stages and I would like your feedback. Here’s the release README. Enjoy!

Goalie

Goalie is a flexible dynamic error response renderer for
Rails built on Rack and Rails Engines. It provides the same
default error pages as Rails, but allows you to easily customize
them with dynamic content. This means you can use your
application layout, have different error pages for different
subdomains, and do all sorts nice things.

Installation

WARNING: at this point, Goalie is highly experimental and
should not be used in production!! Everything can and probably
will change before it is ready for production. Install it only if
you want to play with and/or contribute to it.


gem install goalie

After you install it and add it to your Gemfile , you have to require it together with Rails’ frameworks
at the top of your config/application.rb file:


require 'goalie/rails'

This will remove Rails’ default exception renderer middleware
( ShowExceptions ) and use Goalie’s
instead. Unless you have custom static pages in your public directory (which we plan to support later), this
will be a drop-in replacement.

Customization

Controllers

The public (production) rescuing of errors is done by the
PublicErrorsController found in Goalie’s app/controllers directory. If you create a controller
with the same name, it will automatically be used instead of
Goalie’s. All it needs to do is support the following actions:

internal_server_error
not_found
unprocessable_entity
conflict
method_not_allowed
not_implemented

If you don’t actually need a separate action for each of
these errors, you can redirect them to others, for example, with:


def unprocessable_entity
  render :action => 'internal_server_error'
end

Views

You can also customize only the views and use Goalie’s
default controller. All you need is to have inside app/views/public_errors views with the same names as the
actions listed above. Besides the standard stuff that Rails makes
available to views, you will also have access to the following
instance variables:

Be VERY careful when using this in production, as you could
expose sensitive information inside the request and
exception. Generally, you probably shouldn’t use these variables
at all. The only place it makes sense is to have a more detailed
error screen for admins or other high-level users.

Credit

Goalie copies a lot of code and ideas from:

* Rails’ ShowExceptions middleware
* Rails’ default error views
* Rails’ exception_notification plugin

Which are mostly the work of
Joshua Peek , with help from various contributors. We’re
highly indebted to them and thank them a lot for their work.

Contributions

Any form of feedback, patches, issues, and documentation are
highly appreciated.

License

mbelluzzo: Desbugando o Planet Littlechina

noreply@blogger.com (belluzzo) — Tue, 03 Aug 2010 13:47:24 +0000

Because I'm awesome. (ou não)

mbelluzzo: Relatividade

noreply@blogger.com (belluzzo) — Tue, 03 Aug 2010 13:11:35 +0000

Eu definitivamente não consigo entender essa desgraça.

lfelipe: Canolas new release

Wed, 28 Jul 2010 16:40:52 +0000

After working on Canola for the past couple of months, finally we get to see it released. Hopefully people will like this new version, which is both faster and more stable (or less stable, I’m never quite sure which one we picked). We’re now back following the latest revision of the Enlightenment Foundation Libraries, which allowed us to make the UI experience alot smoother (check it out by going to the Photos section). Also there are a bunch of new features and lots of bugs fixed, so try it out yourself and tell us what you think. Hopefully now development of Canola will get back to more regular releases, and we’ll start seeing more external plugins being developed (such as the flickr plugin being done by Thomas Schimdt, available here).

For this release we went above and beyond the call of duty, doing tests that no one had ever done before (at least to our knowledge). That’s why we can say, with much confidence, that Canola works perfectly while drinking in Buenos Aires:

Canola in Buenos Aires

Testing in other capitals will ensue. Cheers !!!

helder2: Seeing production error pages in Rails 3 on local machine

Mon, 26 Jul 2010 01:43:25 +0000

So you’re programming on Rails 3 and you want to see how your 404 or 500 error page looks like to the end user. You think “that’s easy, all I have to do is run in production mode”, right? Yo do that, run to your browser, type in a bogus address and voilà… A stack trace! Wha..? I thought I was in production mode, shouldn’t I see the red default error page that comes with Rails (or your custom one)? Well, you are, and yes, you should. But that’s not how things work right now.

What happens is that, even in production mode, Rails shows you the stack trace if it sees that the request is coming from localhost. Previously, on Rails 2.x, this was decide by the method local_request? which lived in ActionController::Base, so all you had to do (according to the docs) to fix that was to override it on your application controller with something like:


def local_request?(*args)
  RAILS_ENV == 'production' ? false : true
end

But on Rails 3 (since this commit), exception handling isn’t done inside the controller anymore, it’s Rack-based, and so is the local_request? method. That means you can’t override it from inside your application controller anymore. And there isn’t properly-exposed API or documentation for how to work around this, so you’re screwed!

Oh wait, it’s Ruby, right? What’s another monkey-patch anyway?

So here it goes:


# Put this at the end of config/environments/production.rb

class ActionDispatch::ShowExceptions
  def local_request?(*args)
    false
  end
end

Hopefully this will be more properly configurable in the future.

padovan: ProFUSION on the kernel development statistics for 2.6.35

Fri, 23 Jul 2010 22:30:07 +0000

A recent article from lwn.net shows ProFUSION in the most active employers for networking stuff in the 2.6.35 release cycle. That was due to the work we did in the Bluetooth stack implementing the L2CAP Extended Features (see older post in this blog to learn about L2CAP Extended Features). Nice!

lfelipe: Enlightenment running on an Efika MX

Thu, 22 Jul 2010 15:44:18 +0000

As part of the Power Developer developer’s program, I received from Genesi one of their amazing Efika MX nettops. Other people have already posted about the unboxing process (for example darkside or brunocardoso), but I still want to throw a few screenshots to show it.

Efika booting

Recently there were big improvements made to the EFL on ARM platforms, but even without those optimizations and running on a 1680×1050 screen, E17 is running perfectly fine. Here are a couple of screenshots I made (the second one was taken with a camera phone, so it’s slightly worse to look at, I’ll try to put a video showing how well it’s performing on youtube later):

One of the initial versions of the Efenniht theme, with the obligatory Flame/Penguins/Snow modules enabled

Latest Efenniht version, with the Everything module on the center

I’m going to setup daily builds of the EFL running on it (plus weekly Ubuntu packages) so that it can help out stabilizing the arm port. The static analysis runs with clang of the EFL code that I’ve been doing are now on a new location, and I’ll also be running them directly from the Efika.

I’ll soon update the blog with more cool stuff I’ll be doing here (got an OE build for it about half done), but for now I just want to thank the folks at Genesi for this opportunity, and I’m eagerly waiting to try out the Aura firmware they are working on.

brunocardoso: EfikaMX impressions!

Tue, 20 Jul 2010 02:34:47 +0000

Hey everyone, it’s being a while since my last post. On 5th March 2009, I submitted a proposal to Power Developers to actually improve the ARM Cortex A8 support into the LLVM Compiler. The proposal was accepted in 24th August 2009, and the board arrived in late December.

Fresh new Fedex shipment with a EfikaMX board

After opening the Fedex box, this is what we found:

Unpacked efika board

The surprising news here, is that when I received the board all the improvements I had in mind and proposed to the Power Developers had already been implemented by other LLVM developers. Things not always go in the way we want to, but looking into the bright side I had a new shinning board to play with, and compiler backends always have room for small improvements.

So, first of all, lets look how this beautiful toy looks like. The “genesi” name actually reminds me of my good old sega genesis (good old times), but getting back to what matters, here is how it looks attached to an external monitor (using the HDMI port) and booting linux.

Attached to an external monitor

After booting up and gathering information about the system, I installed gnome and did play with some applications to see how efficient it was. It surprised me, it was faster than I expected, even without the proprietary drivers needed to use the video decoding processor. This is an album with all pictures I took from EfikaMX, they were all taken in the day I received the board back in 9 December 2009.

Before talking about what my current plans are I do have some greetings to do: Thanks very much to Genesi U.S.A., Inc and to Raquel and Bill @ Genesi, to being so kind providing a board and making llvm developers happier. Also I would like to apologize to them by the time I took to give them a feedback, sorry for taking so long

I’m currently in the USA doing a summer internship and my board is at Brazil right now, so until October I don’t have any way to give it attention, but at the EfikaMX/llvm/ARM side of things, these are future plans:

Set-up EfikaMX as a linux ARM backend test machine, so we can run llvm test suite on it and be sure it gets working for linux (we don’t have that for linux in the moment)
Consider the possibility to implement random small optimizations aimed to ARM/linux, as for example this gcc bug.

padovan: L2CAP Enhanced Retransmission Mode getting stable

Thu, 15 Jul 2010 23:47:26 +0000

After more than 4 months working daily at ERTM, here at ProFUSION, we have now a functional and much more stable implementation. Several potential crashes have been fixed, and missing features were added. Also the code was checked against the Profile Tuning Suite(PTS) test software. That software is the official test software from Bluetooth SIG to qualify Bluetooth stacks and the result is that right now we are also passing all PTS tests.

On the bug fixes front, beside the kernel crash fixes, a lot of ERTM behavior bugs have been found and fixed. Some of them made ERTM flow crazy, but we have been able to discover and fix them all. Obviously there might be other bugs in the code, but I haven’t found them yet. ;)

New code added: All missing events and actions from the ERTM spec were implemented, they should be working properly now. Among them we have the Local Busy handling, Invalid Frame detection, etc.

The PTS software helped a lot with the ERTM development, I’m sure that we are much more compatible with others stacks now after fixing L2CAP to pass all tests for Enhanced Retransmission Mode, Streaming Mode and FCS.

Now I’m aiming at make the code base even more stable looking on the mainlining of this new part of the L2CAP code inside the Linux stack. All the code should be available and enabled by default on the 2.6.36 release. If you wanna help testing use the for-next branch of my git tree:

http://git.kernel.org/?p=linux/kernel/git/padovan/bluetooth-testing.git