Posted about 1 year back at InfoQ Personalized Feed for unregistered user - Register to upgrade!
Quite often performance problems will be reported with some very antidotal comments that do nothing to help you understand where to start looking. Faced with this dilemma, it is not uncommon for teams to start guessing at the root cause. Now enter "the box", a little diagram that is an abstraction of a complete system. The box is a reminder of the true cases of performance bottlenecks.
Posted about 1 year back at InfoQ Personalized Feed for unregistered user - Register to upgrade!
Ted Neward shares his thoughts on the roles and responsibilities of the Software Architect, discussing what an architect does, how to approach the role, and if architects are still relevant.
Posted about 1 year back at Ruby on Rails Podcast
Christian Neukirchen, Ruby veteran and inventor of the tumblelog.
Posted about 1 year back at Ruby on Rails Podcast
Christian Neukirchen, Ruby veteran and inventor of the tumblelog.
Posted about 1 year back at Ruby on Rails Podcast
Christian Neukirchen, Ruby veteran and inventor of the tumblelog.
Posted about 1 year back at The Hobo Blog
So after highlighting the fact that documentation is now soooo important, you must all be thinking “OK, so…?”. The current situation is this. The Hobo team is getting towards the end of a large development project, and all going well we should have a decent chunk of time to give Hobo some TLC in November. So, no guarantees, but you can look forward to a much higher level of docs, and maybe even some shiny new screencasts towards the end of November.
Posted about 1 year back at Loud Thinking
If you don't like something new that's getting a lot of attention, you call it out as being all hype propelled by fanboys enamoured by an immature solution.
If you like that something new, you say it has momentum that's being accelerated by passionate advocates of a fresh approach.
Posted about 1 year back at Loud Thinking
If you don't like something new that's getting a lot of attention, you call it out as being all hype propelled by fanboys enamoured by an immature solution.
If you like that something new, you say it has momentum that's being accelerated by passionate advocates of a fresh approach.
Posted about 1 year back at Loud Thinking
If you don't like something new that's getting a lot of attention, you call it out as being all hype propelled by fanboys enamoured by an immature solution.
If you like that something new, you say it has momentum that's being accelerated by passionate advocates of a fresh approach.
Posted about 1 year back at O'Reilly Ruby
Anyone else think that Godwin’s Law should be amended to include Rails?
Just a thought.
Posted about 1 year back at InfoQ Personalized Feed for unregistered user - Register to upgrade!
Charles Simonyi (recent space tourist, and ex-Microsoft lead architect of Word & Excel) presented Intentional Software at the JAOO conference today. Intentional is building a domain language workbench, which allows business experts write domain code in their own familiar notations, that code then being used to generate the rest of an application.
Posted about 1 year back at Moves On Rails
We love REST. It's simple and clean, and combined with ActiveResource it is certainly the best app to app bridge we've worked with so far. But...
What if you want to have more freedom? Say we want to build a database based on a REST webservice. Now imagine we don't want any info about the service in the ruby program that actually builds the db.
We are facing two major problems:
- We don't know which resources are available.
- We don't know the fields and types of the resource in advance.
The first problem will eventually be solved with WSDL 2.0 or if you need a solution right now: by a default listing resource.
# Our default object is called a Resource, on the server we have
# a Resource object that just returns each resource we have in
# a string array.
resources = Resource.find(:all)
=> ["address","person","country"]
# Now we can do all kinds of crazy stuff :)
resources.each do |resource|
name = resource.capitalize.to_sym
new_resource = Object.const_set(name, Class.new(ActiveResource::Base))
new_resource.site = Resource.site
end
After this little piece of code we have a full dynamic set of ActiveResource classes ready to be used :)
The second problem we face is much more interesting. Normally some kind of resource definition would be applied like XSD. But native ruby XSD support is kind of lacking (it sucks) and more importantly it doesn't feel like a rails solution.
We wanted a cleaner, simpler and more elegant (more RESTy) solution. How about Person.schema?
It returns an ActiveResourceSchema object:
Person.schema.fields
=> { :name => FixNum, :date_of_birth => DateTime,
:parents => [{ :id => FixNum }] }
What happens is actually quite simple. When the Resource objects receives the schema method call it calls find(:first, :params => { :schema => true }).
The server responds to this param with a sample record, with just the field names and types. We build an ActiveResourceSchema object to wrap those and return a nice array of fields :)
Note: These code snippets are just examples, we are currently building this. If there's enough interest we might submit it as a plugin/patch for ARes.
Posted about 1 year back at Ryan's Scraps
Hot on the heels of the in-depth look at Rails security options comes the addition of the CsrfKiller plugin into rails core.
The CsrfKiller plugin adds a unique session token field to all forms that is checked on every non-GET request. This ensures that the request received is in fact coming from the session of the authorized user (check out wikipedia’s CSRF article if you need more details on the technique).
All you need to do to enable this protection is to add a protect_from_forgery statement in your controller that takes the familiar :except or :only option along with salt to use when generating the unique token:
And now this is the default functionality. No need to specify anything if you want the default behavior. You can still override as in the following examples, however.
1
2
3
4
5
|
class PostsController < ApplicationController
protect_from_forgery :secret => '2kdjnaLI8', :only => [:update, :delete, :create]
...
end |
If you’re already using edge Rails’ default cookie session store then you don’t have to specify the :secret key.
|
protect_from_forgery :only => [:update, :delete, :create] |
If you’re not on a cookie session store you can also change the digest method used to generate the unique token (the default is ‘SHA1’).
|
protect_from_forgery :secret => '2kaienna9ea90djnaLI8', :digest => 'MD5' |
If a request comes in that doesn’t match the request forgery protection token for the current session then an ActionController::InvalidAuthenticityToken exception will be thrown. Perhaps a good place to try out the new exception handling syntax ?
Caveats: The request forgery protection only kicks in in the following scenarios:
- Non-GET requests, so make sure the only requests that modify state are your
PUT/POST/DELETE requests.
- On html and ajax requests. Override
verifiable_request_format? if you want to expand that.
tags: ruby,
rubyonrails
Posted about 1 year back at Ryan's Scraps
Hot on the heels of the in-depth look at Rails security options comes the addition of the CsrfKiller plugin into rails core.
The CsrfKiller plugin adds a unique session token field to all forms that is checked on every non-GET request. This ensures that the request received is in fact coming from the session of the authorized user (check out wikipedia’s CSRF article if you need more details on the technique).
All you need to do to enable this protection is to add a protect_from_forgery statement in your controller that takes the familiar :except or :only option along with salt to use when generating the unique token:
And now this is the default functionality. No need to specify anything if you want the default behavior. You can still override as in the following examples, however.
1
2
3
4
5
|
class PostsController < ApplicationController
protect_from_forgery :secret => '2kdjnaLI8', :only => [:update, :delete, :create]
...
end |
If you’re already using edge Rails’ default cookie session store then you don’t have to specify the :secret key.
|
protect_from_forgery :only => [:update, :delete, :create] |
If you’re not on a cookie session store you can also change the digest method used to generate the unique token (the default is ‘SHA1’).
|
protect_from_forgery :secret => '2kaienna9ea90djnaLI8', :digest => 'MD5' |
If a request comes in that doesn’t match the request forgery protection token for the current session then an ActionController::InvalidAuthenticityToken exception will be thrown. Perhaps a good place to try out the new exception handling syntax ?
Caveats: The request forgery protection only kicks in in the following scenarios:
- Non-GET requests, so make sure the only requests that modify state are your
PUT/POST/DELETE requests.
- On html and ajax requests. Override
verifiable_request_format? if you want to expand that.
And what to do if you want to disable CSRF protection? Just add this to whatever controllers you don’t want to be affected:
|
skip_before_filter :verify_authenticity_token |
And if you want to disable this site-wide, just add this to application.rb:
|
self.allow_forgery_protection = false |
tags: ruby,
rubyonrails
Posted about 1 year back at Ryan's Scraps
Hot on the heels of the in-depth look at Rails security options comes the addition of the CsrfKiller plugin into rails core.
The CsrfKiller plugin adds a unique session token field to all forms that is checked on every non-GET request. This ensures that the request received is in fact coming from the session of the authorized user (check out wikipedia’s CSRF article if you need more details on the technique).
All you need to do to enable this protection is to add a protect_from_forgery statement in your controller that takes the familiar :except or :only option along with salt to use when generating the unique token:
1
2
3
4
5
|
class PostsController < ApplicationController
protect_from_forgery :secret => '2kdjnaLI8', :only => [:update, :delete, :create]
...
end |
If you’re already using edge Rails’ default cookie session store then you don’t have to specify the :secret key.
|
protect_from_forgery :only => [:update, :delete, :create] |
If you’re not on a cookie session store you can also change the digest method used to generate the unique token (the default is ‘SHA1’).
|
protect_from_forgery :secret => '2kaienna9ea90djnaLI8', :digest => 'MD5' |
If a request comes in that doesn’t match the request forgery protection token for the current session then an ActionController::InvalidToken exception will be thrown. Perhaps a good place to try out the new exception handling syntax ?
Caveats: The request forgery protection only kicks in in the following scenarios:
- Non-GET requests, so make sure the only requests that modify state are your
PUT/POST/DELETE requests.
- On html and ajax requests. Override
verifiable_request_format? if you want to expand that.
tags: ruby,
rubyonrails
1 ... 519 520 521 522 523 ... 634
