We Keep Coding

Meteor trigger event on server collection change

I would like to trigger an event on a meteor server when a document on my collection changes to a specific value, say some field changes from false to true.
I am familiar with binding events to the client; however, I want this event to only be called when the server state changes, specifically the value of a given document in my collection. I want to trigger an external HTTP call from the server when this happens, as I need to message external applications.

Seems like this is an old post. For the benefit of others.
Peerdb package seems to do some of the tasks you are looking for.
https://atmospherejs.com/peerlibrary/peerdb

Also a bit late, but the most classic solution to this type of problem is using the very popular meteor-collection-hooks library. In particular, you'd probably want to use the .after.update hook (click link for full documentation), which allows you to hook into a particular collection after an update is made to a document and compare before and after by comparing doc (doc after update) to this.previous (doc before update).

Writing to a Firebase from within a Polymer element

I am working on an assignment for a course in "Coding the Humanities" which involves writing a custom web component. This means I am required to use Polymer even though as far as I can see there is absolutely no added value to doing so.
I want to create a literal chat "room" in which users input a character to identify themselves and can walk around the room bumping into one another after the fashion of robotfindskitten.
My idea was to write each character and its position to a Firebase location, updating everyone's positions in real time, so I need the Firebase JS client- using core-ajax for REST requests isn't fast enough.
The GitHub readme for the core-firebase element consists of a link to a less than helpful component page.
Looking at the core-firebase element itself, I don't see anything that corresponds to the 'value' event; locationChanged has a 'child-added' event handler, but that's it.
Am I crazy for thinking the core-firebase element is just very incomplete? Should I try to write my own 'value' handler? If so, do I just add it to the locationChanged property of the object passed to Polymer()? I'm very confused - I know enough JS that what's happening in the core-firebase code is straddling the limits of my comprehension. (Which might have to do with the this keyword, I don't know.) Any input here would be appreciated. (And yes, I've already remarked to the instructor that I could have handled this using plain old jQuery and Firebase if I didn't have to use Polymer. No word as yet on that.)

Looking at the commits for core-firebase it looks like it's had about two days work on it plus some maintenance, so it wouldn't be surprising if there are missing features.
One nice part about Polymer is that it interops very well with other ways of writing apps. It's totally reasonable and supported to use jQuery and Firebase directly to read from firebase and react to changes. You can still make good use of polymer's templating and databinding by doing this within an element of your own and using Polymer's data binding, templating, and plain old DOM events to propagate those changes throughout your app and render them onto the page.

Instant update backend with Knockoutjs

I am trying to create a web page with form that once user change any field, the validation and update commit immediately rather than letting user to click on submit button. I am using Knockout.js and mapping plugin. I know I can achieve this by creating a computed field for each original fields, but this kind of work is tedius and dumb, is there good practice to create a general listener to listen on any changes in any fields and update backend respectively?

In order to subscribe to any change you could use ko.toJS() method. Actually it allows to walk through object graph and unwrap observables. As your probably know when you use ko.computed it subscribes to all reads of observables fields and re-evaluate on every change. So if you use code like this:
ko.computed(function() {
ko.toJS(viewModel);
// update data on server
});
Also you should pay attention that this piece of code will update data on server right after initialization. It could be easily avoided. Please checkout this example: http://jsfiddle.net/UAxXa/embedded/result/
Also I think you might want to send only changed data to server. You could incorporate ko.editbales plugin ( https://github.com/romanych/ko.editables ) and some KO under-hood knowledge. Please checkout this sample: http://jsfiddle.net/romanych/RKn5k/
I hope it could help you.

You've got several options but if you want a single listener, one good way is to use the same code I used to create a change tracker. It simply listens for the observable changes. Its about 19 lines of code. You can grab this and instead of using it for change tracking, just wire in a method that saves the changes when they occur.
NuGet http://nuget.org/packages/Knockout.ChangeTracker
Codeplex http://kochangetracker.codeplex.com/
To Setup change tracking, add this tracker property to your view model:
viewModel.tracker = new ChangeTracker(viewModel);
Hook these into your view to determine when changes occur:
viewModel.tracker().somethingHasChanged();
Hook this into your view model when you want to reset state in functions (ex: load, save):
viewModel.tracker().markCurrentStateAsClean;
Optionally, you can pass your own hashFunction for state tracking, too.

Where should I write common javascript code related to controls

I am in a situation to write some client side validation. For example, in a page I use a Repeater control which creates a list of item. There we could select number of items using a check box (in the first column). So if I click 'Delete' button, the selected cases will be deleted. So I need to check if the selected item's count is zero or not. So my question is, where should I write this kind of validations ? In a common .js file or in the page itself.

This should be done in a separate file. You will encounter times when you will need to have the id of the control being validated for one reason or another so you should provide a manner within that file to receive those ids (parameter name in a function, global variable (not recommended), custom namespace object).

Definitely in a separate js file. Then you could reuse the logic on another similar page.

Best practice suggests that you should place this in a separate file. Personally, I would always write this kind of validation server-side, not javascript, especially if the resulting action is a delete.
I would use javascript to allow for a "select all" feature and I would use jQuery to create an "Are you sure" prompt.

addeventlistener for 'keypress' = captcha alternative?

Am I right in thinking that spam bots can't simulate the 'keypress' event, and thus I can't get spammed if I require a keypress for each field in my contact form before being able to submit it?
Is this a good alternative to captcha, etc. if I don't care whether or not my viewers have JavaScript enabled?
Wizards, set me right.

I'm unsure if they can generate the keypress event "natively" (I think you might be right that they can't, but it wouldn't surprise me to learn that there's some edge case whereby this is possible).
However, I don't think they would have a problem merely executing element.onkeypress() directly. If the bot can determine that it needs to press a key to advance, then what that actually boils down to is that a particular event handler method needs to be invoked - and the bot can do the latter. It can create its own fake Event object too containing the keycode, and then pass this in and/or set it on window.event.
In theory you might be able to detect this by being very strict about instrospecting the event object in your handler. I don't think that the bot would easily be able to create a native-equivalent event object, so perhaps by inspecting the prototype chain you could distringuish between the two. However, this would almost certainly be too fragile for general use, and is not going to reliably work across different browsers/environments/plugins/etc.
Thus I don't think this is a fruitful path, because you can't tell in an event handler whether the event is "real" or not. Browser-native code is different, since bots cannot actually trigger a click event, but within Javascript I don't see a simple way to prevent your method from simply being called.

The current implementations of spambots might not be able to do that. But it's not that hard to simulate keypresses. If you're only a small website the bot author might not do the work to circumvent your system, but if it large enough for the auther to care your system will be broken really quick.