Poetry of Programming

Its about Ruby on Rails – Kiran Soumya


New View for my blog

Stand Apart From the Crowd…!


J2 Y-u-m-m-y points to be noted…

Fallacies of J2ME

The list of fallacies, according to Eric, are:

  1. Java programs “will just work” on J2ME
  2. KVM == J2ME
  3. KVM == CLDC and CVM == CDC
  4. J2ME replaces WAP

Fallacy 1: Java programs “will just work” on J2ME

Realistically, don’t expect to be able to run your existing Java applications unchanged on any J2ME platform. Apart from some technical issues (such as the CLDC 1.0 not supporting floating point), there will usually be two barriers: missing classes and resource problems. Not only do J2ME platforms subset the J2SE core classes, but they add some of their own unique classes as well. But even if you write code that only uses classes common to all the platforms you’re interested in, chances are that you’ll still have some work to do to optimize your application so that is uses less memory and has acceptable performance. Good design and modular programming will help a lot in this area.

This isn’t to say that you can’t reuse any code, just don’t expect to reuse it all.

Fallacy 2: KVM == J2ME

Many people use KVM and J2ME synonomously. They’re different things. The KVM is a Java virtual machine. J2ME is a set of specifications. Not every J2ME platform uses the KVM. The CDC, for example, uses the “classic” VM, not the KVM.

Fallacy 3: KVM == CLDC and CVM == CDC

In a similar vein, others use KVM and CLDC synonomously, or the CVM and CDC synonomously. Again, they’re different. The KVM and CVM are Java virtual machines, the CLDC and CDC are J2ME configurations.

The CLDC has specific requirements for its underlying VM, and the KVM can be configured to be that VM. The KVM in fact forms part of the reference implementation of the CLDC. However, there’s nothing preventing a specific CLDC implementation from substituting its own VM not based on the KVM source code. IBM’s J9 VM, used in recent Palm devices, is one such example. So is Research In Motion’s VM for the BlackBerry handhelds.

Similarly, the CDC has specific requirements for its underlying VM, and the CVM can be configured to be that VM. And yes, it too forms part of the reference implementation of the CDC. But CDC implementations can use their own VM, just like IBM uses its J9 VM in its CDC-based J2ME implementations.

Don’t get all worked up about which VM is used. As long as it passes the compatibility tests and meets the appropriate specifications, it generally doesn’t matter to you, the developer. The only time it matters is when performance is an issue and you’d like to switch to a faster VM. That said, remember that most handheld devices are closed platforms and only the platform vendor can actually install a different VM.

Cookie Caching

BES have the ability to handle cookies on behalf of client applications. In other words, any Set-Cookie headers sent back in HTTP responses can be intercepted by the BES (which is acting as a web proxy server) and stripped out of the response sent back down to the client. The cookie is then automatically inserted into subsequent requests by the client app when its request passes through the BES (again, in its capacity as a proxy server).

This cookie handling feature is not a feature but a bug according to Eric’s opinion. The basic problem is this: if a session cookie is used, there’s no way for the application to signal the BES that the “session” is finished. The normal behavior is for the client to clear session cookies when the session terminates. In a browser, this usually means when the browser is exited. In a J2ME application, the application simply stops sending the cookie in subsequent requests.

But since the BES is handling the cookies for you, when exactly does the “session” end? It doesn’t! So what happens is that you get a stale cookie being appended to your app’s requests.

The best solution? Turn off the BES-level cookie handling and let the application do the cookie handling by itself. All you do is set this property in the configuration file:

application.handler.http.CookieSupport = false

You can also set it directly from the BES management console.

Fallacy 4: J2ME replaces WAP

WAP is a set of technologies for wireless communication. It includes a markup language called WML for writing browser-based applications. You can find out more about these technologies at WirelessDevNet.com.

WAP and J2ME are different things, and each has its place when it comes to application creation and deployment. WAP (or really, WML and WMLScript) lets you build browser-based, thin-client applications optimized for wireless delivery. J2ME lets you build “thicker” client applications with more sophisticated logic and the ability to run in an “offline” mode. It’s really like trying to say: “which is better, a page of HTML or a Java applet?” Both are different, and both have their uses. Hopefully, though, J2ME won’t suffer the same problems that caused applets to fall out of grace so quickly. This is why the standardization process, industry support, and compatible implementations are so important for the success of J2ME.


MARCH marches on…

Time marches on and on,

And waits for None.

Happiness marches on and on,

With all the fun arouN(d).

Dreams marches on and on,

With all the trust and confidence Lights ON.

Learning marches on and on,

With all the new breaking technologies… go on!

Life in INXS marches on and on,

With a sweet remembrance of joining date on ….

20th March…!



Vizag Beach From Kailashgiri

Some more Good Pics





Why did the Tower of Babel Fail?

Now the whole earth used only one language, with few words. On the occasion of a migration from the east, men discovered a plain in the land of Shinar, and settled there. Then they said to one another, “Come, let us make bricks, burning them well.” So they used bricks for stone, and bitumen for mortar. Then they said, “Come, let us build ourselves a city with a tower whose top shall reach the heavens (thus making a name for ourselves), so that we may not be scattered all over the earth.” Then the Lord came down to look at the city and tower which human beings had built. The Lord said, “They are just one people, and they all have the same language. If this is what they can do as a beginning, then nothing that they resolve to do will be impossible for them. Come, let us go down, and there make such a babble of their language that they will not understand one another’s speech.” Thus the Lord dispersed them from there all over the earth, so that they had to stop building the city.

The Tower of Babel project failed because of lack of communication and of its consequent, organization.

“Schedule disaster, functional misfit, and system bugs all arise because the left hand doesn’t know what the right hand is doing.” Teams drift apart in assumptions.
Teams should communicate with one another in as many ways as possible: informally, by regular project meetings with technical briefings, and via a shared formal project workbook. [Or by electronic mail.]


History of Ruby on Rails

Many web-based software systems contain a number of common types of components and functionality.
Calling application code based on HTTP posts, performing database transactions, rendering HTML
responses, and putting all of the system’s functionality into a scalable, extensible architecture are all common concerns in these applications. Because of the prevalence of web applications in today’s world, these problems are faced by many developers worldwide on a daily basis. Clearly, when facing such a task, a prudent software engineer would seek a common framework for web application development that could reduce the need to reinvent existing solutions, create a common base architecture for a number of different applications, and provide a ready-to-go solution for as many of the requirements as possible.

This solution to the problem is not a new one. Frameworks like Microsoft’s .NET or Sun’s Java 2
Enterprise Edition (J2EE) are widely used to satisfy the needs of developers creating large scale service
oriented architectures for web deployment. These systems have been tried and tested many times and are well known for the robust solutions they can provide. Unfortunately, with such a robust architecture seems to come an inherently large amount of overhead in terms of configuration and setup. In addition, there tends to be a large learning curve to understand the architecture and all of its variants. In particular, J2EE has many different technologies that can be glued together within it, including Struts, Hibernate, and Spring.

Enter Ruby on Rails. Ruby on Rails is an open-source web application framework designed to make the
job of the developer easier by providing everything one needs to create web-based, database-driven
applications easily while focusing on the idea, not the technology behind implementing the idea. It is
designed to be a marriage of the “quick-n-dirty” camp of PHP web developers and the “slow-n-clean”
methodologies of the old enterprise architecture crowd. Many proponents of the framework will be quick to tout quotes saying that it can make developing web systems ten times faster than performing similar tasks with competing, more complex frameworks like J2EE.

Rails was developed while its creators were building a real life system with it. This allowed them to test
out their ideas as they were putting them in to production, along with allowing them to drive the
development of the framework based on the actual needs of a real project.

The creator of Ruby on Rails, David Heinemeier Hansson of 37signals, will tell you that some of the
framework’s power comes from the fact that it follows the mantra of “convention over configuration.”
This means that instead of allowing an ultimate amount of flexibility in what a developer can do with a system, there are limits imposed. While this may sound like a bad thing, it actually allows for a much
easier time in creating the types of solutions that it is specifically designed for. In David’s words, “If you
are happy to work along the golden path that I’ve embedded in Rails, you gain an immense reward in
terms of productivity that allows you to do more, sooner, and better at the application level.” Basically,
because assumptions are made on the part of the framework about how the developer will be doing things, the developer doesn’t have to tell the framework how those things will be done. This means less time spent writing configuration files and more time working on the idea of the product.

A high-level view of the Rails architecture makes it look very much like other web application
frameworks. Its architecture is based on MVC, designed to separate concerns and reduce the coupling
between disparate functionality. Part of Rails’ power comes from the fact that this architecture is
connected through an auto-generated code base structure. The developer can set up a project and then
make changes to the model directly and observe the results without a lot of work to set up every part of
getting that data propagated throughout the rest of the system.

The entire benefit of using Ruby on Rails is in many of the small things it does to benefit the developer in
ways that other similar frameworks do not. These little things collectively work together to create a
development experience which overall seems much more agile and less cumbersome than the process
involved in working with other large and robust web development architectures.

In mid-2003, a small web development firm called 37signals was starting development on Basecamp, a
web-based project management tool. For several years, they had been using PHP for their applications
and trying to build up a reusable framework.
Unfortunately, their PHP framework failed to provide maximum productivity, and the programmers were
growing increasingly frustrated with their development experiences. PHP offered a quick and dirty approach to web applications, but 37signals was rapidly pushing the limits of what PHP reasonably
accomplish. On the other end of the spectrum, J2EE offered a slow and clean approach. The approach
was too slow, however, and unreasonably complex. In order to combine the best of both worlds into a
quick and clean approach, a new framework was needed. This framework would facilitate rapid
development with a focus on producing results, while also incorporating design patterns and best

Basecamp would be 37signals’ first product offering, and the project marked their transition from
consulting to product development. It was clear that if the company wanted to deliver an effective
product line without significantly expanding their resources, they would need a software platform to build on.

As a result, two primary goals emerged. First, 37signals needed an extensible, modifiable web
application framework that could be used to create Basecamp and future products. The framework would
promote code reuse and provide libraries of common functionality. Second, the framework itself needed
to make development enjoyable for the programmers, making the programmers extremely productive.
With increased productivity, 37signals could accomplish more work without hiring more developers.

To achieve the second goal and provide a starting point, Ruby was chosen as the programming language
for the web framework. The dynamic, powerfully expressive nature of Ruby along with its extensive
metaprogramming features ensured an enjoyable, fruitful development experience with plenty of
flexibility. By designing the framework to take advantage of Ruby’s unique traits, a clean productive
development was guaranteed.

Since Ruby was selected and established as a foundation, David could then address his first goal of
creating an extensible web framework. However, he did not build the framework upfront. Instead, he
proceeded to build Basecamp, and the framework that grew out of Basecamp became Ruby on Rails.
Unlike web frameworks like J2EE and .NET, which were developed to specifications designed to suit the
needs of all possible users, Ruby on Rails was extracted from a complete product. As a result, the
framework reflects the real needs of a real project, and contains no extraneous or unnecessary features for the average developer. Thus, when developing a future 37signals product, David could reuse Rails,
without being hindered by unnecessary components, and spend most of his time focusing on application
specific functionality.

Despite the fact that Rails began as a proprietary framework, a decision was made to avoid including
business logic and application-specific features. Originally, the scope was constrained simply to make the framework manageable and to guard against feature creep. When Rails was publicly released as open source, the lack of business logic left the framework as a powerful, general solution that the majority of programmers could reuse.

From its inception, the Rails framework has been driven by pragmatic, minimalist decisions. It uses
proven techniques from real-world applications, meaning that the framework is a reflection of the way
programmers actually work.


Best Article in November,2006!

Today I happened to visit a good article, David H. Hansson on the Future of Rails, where the InfoQ editor asks David about the future of rails in enterprises, the scalability and comparision of Java with Rails.

His interview teaches every developer how to really proceed to a project. Implement all ideas without really worrying about performance/scalability. This is like “Concentrate on Application but not bugs at first!” Then sort out pointing exactly where is the bottleneck? Then get that solved… coz every problem has solution.(Nothing is impossible)


Y do I like Scriptaculous?

Many doubt… Y do I like Scriptaculous?

I like Scriptaculous coz… I like Ajax…

mmm now don ask me Y do I like Ajax!

Scriptaculous demonstrates the usage of Ruby on Rails with AJAX helpers, and I luv all the script.aculo.us effects, drag-and-drop, Puff, Fade & Appear, Shrink & Grow… In-place Editor… etc etc. Everything… each n everythin…

I really cant stop thanking my young Guru, who introduced me to this.

And ofcourse, without Rails concept, all these effects wouldnt have been easily learnt! Like a curry(Rails) with all the spices(Scriptaculous) in it!

Rails is good! Ruby on Rails is the Best!

Ajax is Superb! Scriptaculous is Amazing and Fantastic!


What’s Web 2.0?

Starting from the static page, Web 1.0 has been turned to dynamic contents (like Google, yahoo etc), where users can interact with web pages, by providing instructions and contents through graphical interfaces. In short web 1.0 dealt with human-machine communication through web, accessible through wide range of operating system platforms, which was been possible by using http and html. Besides human to machine communication, the concept of web 2.0 concentrates on the following issues, that I have learned so far

  1. Machine to machine communication. You publish your content in one site, which has been automatically shared by thousands of web pages among other servers. This becomes possible through RSS. As a user, you can get updates of a web site contents, through using a RSS feeder.

  2. Human to human communication. For example point to point network, social community network etc, where pictures, emotions, biography, music etc personal resources can be shared with friends and friends community can be grown via friends of friends.

  3. Rich user experience. Using AJAX (Asynchronous JavaScript and XML), it becomes possible to send web requests from the client side to server side, through XHTTPRequest method call from browser end, which enables an user NOT to wait to work, until the reply of this web request returns back from the web server. One simplest example can be given as, in Gmail, we can attach as much as files and after then we can begin typing the mail. Lets say this type includes 6 minutes. By this time, Gmail starts sending the attachments to the server, lets say it takes 5 minutes. When my type finishes, the total process takes only 6 minutes, while not using AJAX it would take simply 11 (6+5) minutes. Web 2.0 sites provide, although NOT exactly, but a sort of much similar rich user experience like desktop application. Well one important thing to note, Ajax is not actually new technology, but uses old and very well known technology (JavaScript, xml etc) in new approach.

  4. Personal contribution over web content. Web 2.0 encourages personal contributions of the users over the web content. Blog is such a thing, which is called “Online diary”, where a person can enter his words, in daily basis. Each entry is specifically mentioned and maintained regarding it’s publish date. Several blogs in online has some common features, like archives, track back etc. Blogs has become popular, than the web 1.0 style “Persona web site”, as blog includes more personal touch. Another popular web 2.0 concept is wiki, which is called as “Online Encyclopedia”, where people can edit or contribute their knowledge there. Book marking is another web 2.0 features, where URL book marks can be saved and shared with others. Basically blog, wiki, url booking marking are the things are conceptual than latest technology and considers social aspect to share personal contents. These type of ideas encourages “tagging”, where any item can be tagged with one or more categories(in some cases these tags are being used in RSS feed).


Web 2.0 on Rocket Fuel

Ruby on Rails 1.1 is described as Web 2.0 on Rocket Fuel.

The much-anticipated new version 1.1 of Ruby on Rails hit the streets with fanfare a couple of days ago. And while even I am wary of the hyperbole that sometimes surrounds Ajax and Web 2.0, I’m very pleased to say that Ruby on Rails is the genuine article. Rails has become one of the real success stories in Web development in just the last year. Built by 37signals’ charismatic David Heinemeier Hanson and a host of contributors, Ruby on Rails has ascended to near-mainstream status nearly overnight.

For those of you not familar with Ruby on Rails, and a lot of you won’t be or have just barely heard of it, Ruby on Rails is a complete, open, and free application stack based on the Ruby programming language . This means it provides a complete solution for creating great online Ajax-based software of the kind that’s pouring out on the Web these days . Rails includes advanced Ajax support, Web services, an amazingly taut and clean model-view-controller implementation, and automatic object-relational mapping. Rails even includes seamless script.aculo.us and Prototype integration, as well as support for just about any database you will need.

Ruby itself is one of the interesting stores in software development lately because it’s a dynamic language, meaning that it isn’t compiled and is somewhat more akin to Perl and Javascript than a traditional hardcore language like Java or C++ . But that’s where similaries to Javascript end since Ruby is an elegant object-oriented language designed to make programming easy and make routine software development tasks almost effortless. In fact, when I did my C#, Java, and Ruby Web services development comparison last year, Ruby won hands down in development time, compactness, and generated by far the most readable code, even though it was the very first time I’d used it.
Ruby on Rails 1.1

Rails is a natural extension of these concepts in that it adds a framework to Ruby to make it maximally easy to build Web-based online software, with the single-minded intent of pushing complexity out to the edge cases. To get a sense of how powerful Ruby is, my recent discussion (video here) with David Heinemeier Hannson at Real-World Ajax revealed that 37signals not only built their 5 world-class online applications purely with Ruby on Rails, but they support almost 400,000 users on just 13 servers.

Dion Hinchcliffe and David Heineimeier Hansson discuss Ruby on Rails 1.1But there are dozens and dozens of Web development products out there, many of them very good, so what makes Ruby on Rails so special? One is that the Rails’ design focuses on trying to make the common Web development tasks fall-down-the-stairs easy, and it invariably succeeds. Like the Rails home page says, “Ruby on Rails is an open source Web framework that’s optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.” Rails proponents are reknowned for their plain spokeness and directness and the result of this attitude is clear throughout the framework.

Another real advance in Rails is the fact that it considerably reduces something called abstraction impedance. Abstraction impedance is a fancy $20 phrase that describes the barrier that exists when crossing from one way of thinking to another. Say the barrier of going from objects to databases, or Javascript to Ruby. Abstraction impedance is a productivity killer that sucks up programmer time doing things that don’t matter to what the application does. So instead of providing solutions to your users, you’re spending time converting information from one form to another. Rails makes this go away by giving the programmer plain old objects to deal with, no matter if you’re dealing with XML, relational database data, and now even Javascript in the browser.

This takes us to the new features in Ruby on Rails. As its biggest new feature, version 1.1 actually allows you to write your browser-side Javascript in Ruby. Javascript is a notoriously finicky language that doesn’t make it easy to create sophisticated Ajax appliations and that’s why IDEs, frameworks, and tools are springing up everywhere to make it simpler. Now Rails has just dropped one more complexity out of the process of building Web 2.0 software applications with RJS, the Ruby to Javascript compiler.

Web 2.0 software development has its own set of expectations and best practices: rapid feature evolution, real-time feature monitoring, all functionality available in both the GUI and as Web services so others can use them in their own apps, and more. Rails makes all of these easy to do using one of the highest productivity languages out there. That’s not to say Rails is perfect, it’s so new it couldn’t possibly be fault-free, but there is clear evidence today of its reliability, scalability and ease-of-use (once you get past a brief learning curve.)

What’s New In Rails: (complete list here)

  • RJS – Write your Ajax application’s Javascript in Ruby
  • ActiveRecord++ – Rails’ ActiveRecord is a powerful, automatic Object/Relational Mapping tool. It gets a major steroid boost in Rails 1.1.
  • API Support – Adding an API for your Web 2.0 software is now even easier
  • New Integration Tests – Rails understands testing and adds even more automatic test support
  • Backwards Compatibility – Even with 500 new changes, old Rails apps will almost universally run in Rails 1.1

If you’re interested in picking up Ruby on Rails, here are twelve excellent tutorials (http://www.digitalmediaminute.com/article/1816/top-ruby-on-rails-tutorials) that can get you started. And finally, if you haven’t bought all of this yet, take a look at this screencast. It shows step-by-step how to develop a working blog application in Rails from scratch in just 15 minutes, complete with comments and an administration interface. That’s the power of Rails, it really does let you focus on delivering great online software and not get mired in details that don’t matter. In any case, Rails is so new it has almost no enterprise penetration. But as the next generation of programmers uses it more and more, expect that to change, along with the way enterprises develop with Web technology.


Script.aculo.us 1.6.4 Released on 6th September.

Thomas Fuchs has sync’d up to the latest Prototype adding features along the way:

* Update Prototype to V1.5.0_rc1 (read more on Justin Palmer’s blog)
* Add experimental alternate syntax for unit tests (Behaviour Driven
* Merge assertElementsMatch and assertElementMatches from Prototype’s
[4986] unittest.js [Sam Stephenson]
* Add assertRespondsTo and shouldRespondTo assertions

// object var testObj = { isNice: function() { } } // test assertRespondsTo(’isNice’, testObj);

* Make Sortable.serialize handle DOM IDs like “some_element_1” correctly, fixes #5324
* Add support for onStart, onDrag and onEnd events directly on Draggables (invoked from the Draggables.notify), fixes #4747 [thx scriptkitchen]

new Draggable(’some_id’,{ onStart:function(){ /* … / }, onDrag:function(){ // }, onEnd:function(){ / … */ } });

* Add autoSelect option to Autocompleters to auto select an entry if only one is returned, fixes #5183 [thx cassiano dandrea]
* Added delay option to Draggables and Sortables, see test/functional/dragdrop_delay_test.html for usage, implements #3325 [thx lsimon, tomg]
* Add version and timestamp to indvidual library files for easier identification (the files are preprocessed by the Rake fresh_scriptaculous task), fixes #3015 [thx Tobie]
* Add assertIndentical and assertNotIdentical unit test assertions, which test for equality and common type, fixes #5822 [thx glazedginger]
* Add integration test for Ajax autocompleter for results with no linebreaks, #4149
* Added a custom exception to all base effects when used on non-
existing DOM elements, added a assertRaise method to unit tests
* Add element shortcuts to Builder that can be activated by calling Builder.dump() (see the unit test), fixes #4260 [thx napalm]

Builder.dump(); var element = DIV({id:’ghosttrain’},[ DIV({style:’font-size: 11px; font-weight: bold;’},[ H1(’Ghost Train’), \”testtext\”, 2, 3, 4, UL([ LI({onclick:’alert(’test’)’},’click me’) ]), ]), ]);

* Make Effect.Puff work correctly for floating elements, fixes #3777
[thx michael hartl]
* Fix selection of correct option in SELECT element generated by
InPlaceCollectionEditor for indexed option arrays, fixes #4789 [thx
* Fix an issue with redrawing ghosted draggables that are inside a
scrolled container, fixes #3860 [thx gkupps, tsukue]
* Fix autoscrolling inside scrollable containers when window is
scrolled too, fixes #5200 [thx wseitz]
* Fix autoscrolling when dragging an element unto a scrollable
container, fixes #5017 [thx tomg]
* Fix a condition where overriding the endeffect on Draggables without
overriding the starteffect too leads to a Javascript error [thx
Javier Martinez]
* Fix a possible error with the drag/drop logic (affects the solution
to #4706)
* Fix various issues with IE detection and Opera, and setOpacity, fixes
#3886, #5973
* Remove revert cache code obsoleted by #4706, fixes #3436 (again) [thx]


Why Ruby on Rails?

The stack on the left is the Java books, the stack on the right is the Ruby books. The same breadth of material is covered. Well almost, there are on-line references for things like XSL, not covered in the Ruby books. But other than that the functionality is the same. So which stack will be easier to keep in my head? The choice is easy.

Check this url: http://www.garbett.org/?q=node/25#comment-13
Shawn gave a great comparision of Rails with Java.


Rails’ time extensions ported to JavaScript

Ström have ported Rails’ Numeric Time extensions to JavaScript since he needed to do some date calculations for a project. Now one should be able to calculate dates in JS like this:
(5).seconds() // => 5000
(2).weeks() + (2).hours() + (15).seconds() // => 1216815000
(1).week().fromNow().toDate() // => Fri Sep 22 2006 19:16:32 GMT+0200 (CEST)
var date = new Date(2000, 11, 18, 18, 15, 23);
(2).years().since(date).toDate() // => Thu Dec 19 2002 06:15:23 GMT+0100 (CET)
Thought it could be useful for others as well.
You’ll need the latest prototype and scripta.culo.us libraries, unit tests are included.


How to stop search engines from indexing your pages.

Got something you want to put online, but you don’t really want it showing up in search engine results? Here are two quick and easy solutions.
Use a specific meta tag

For each page you don’t want to appear in search engine results, have only one tag. Not a description, not some keywords, just a single tag for robots.

meta name=”robots” content=”noindex,nofollow,noarchive” />

Pop that into the of each page, and you’re telling search engines not to index the page, not to follow any links from the page, and not to archive the page.
Create a robots.txt file

If your pages are all in a separate directory, you can also block search engines by using a robots.txt file.

Create a text file and, in it, disallow all the directories you want protected:

User-agent: *

Disallow: /nameofdirectory

Disallow: /anothernameofdirectory

Do it for all the directories you want, then save the file as robots.txt, and upload it to your main directory. The search engine robots will hit the robots.txt, find out which directories you don’t want them sniffing in, and skip them.

So there you go. Two little things that can save you a world of trouble.

However, these aren’t completely effective solutions. If you really want to block search engines from accessing your pages, you can either password-protect your pages, or keep them offline.

The choice is yours. Have fun!


Conditional periodically_call_remote in Rails

Loading new sections or pages in a Rails app using AJAX can do a lot to increase overall application snappiness and lengthen the life cycle of each page load, but if any of these pages use the periodicallycallremote helper, then these periodical calls may persist longer than you would like.

The trick to fix this is to note that in the documentation for periodicallycallremote, the options for defining the target URL and callbacks are the same for the link_to_remote helper, which include an option called :condition.

So if you want your periodical calls to cease when different pages in your app are loaded using AJAX, then use the :condition option to have periodicallycallremote check against a variable:

<%= periodicallycallremote(
:condition => “check_var == true”,
:update => “myupdatediv”,
:frequency => 20,
:url => { :action => “bar” }) %>

Then in your templates define check_var true or false depending on whether you want the periodical updates to take place:

< script type=”text/javascript”>

 check_var = true;

The :condition option can take any sort of JavaScript code, you can be as creative as you like in defining when and under exactly what conditions your periodical calls are made. Take back control!