This week Nate rejoins the office hours after some busy weeks, not a moment too soon to answer some great DerbyJS questions!
model.at and model.context
Pavel asks whats the difference between model.at and model.context?
Nate explains that model.at makes a scoped child model with a path relative to the current model.
var user = model.at("comment.author");  
var name = user.get("name")  
There is also model.scope which is the same as model.at, but its an absolute path rather than relative.
var user = model.scope("users.123");  
This means you can access the root users collection no matter how many components deep the model you are manipulating is.
Even though it looks similar, model.context is quite different. It's a method for categorizing a set of subscribed documents so that you can clean them up easily when you need to.
For example the Lever app has a flyover, it will subscribe to a specific profile's documents, if you then change the profile being viewed we need to clean up (unsubscribe) the old profile's document. It is mostly used with model.unload (to release a context), if you dont specify a context you unload root, which is everything. Nate and Ian will make an article to explain it in more detail.

how do we do tests?

We currently use mocha to test backend node code. Following the standard pattern of defining test behavior in package.json so you can do:
npm install; npm test
We haven't done UI tests yet. While we'd like to, the kind of problem brought up in the question doesn't need UI tests since the problem is in the model and one can just run the tests from node.
We use travis to run the tests when published.
We are working on developing test framework for the database stack that will make it easier for people to test against livedb by creating temporary data environments. Currently it's a bit challenging to scaffold the testing environment for each test.

derby-stylus

Artur made a commit that fixes style loading for components, something Nate had meant to do but hasn't had the time to get around to.
Live reloading of styles doesnt work in development currently. There is a pull request from Pavel. Nate will take a look soon.
There is also some problems with components not updating their views in development, Nate is aware and will be looking into it.

component-examples

A few more components have been added to the component-examples gallery.
Pavel and team working on a video chat component with peerjs which sounds exciting!

d3.js and derby

Ian has promised to make a guide for combining DerbyJS and d3.js in the most effective way.

Teamwork

Osman asked about how Lever develops as a team, concerning fullstack engineers vs. frontend. We also touched on how our engineering works with design.
We have a "full stack" designer who can implement frontend code (HTML and CSS) and works closely with the engineers (who are all also fullstack). We like the current arrangement as we can move fast, but "project manager" Nate reminds the danger of designers knowing code. The danger is that it can lower the bar since they will start thinking in terms of what's possible (or convenient) rather than what's right.

compatibility issues between versions

How do we deal with compatability between the different version of DerbyJS?
First of all, dont use Derby 0.3, its a mess.
0.5 and 0.6 pretty close in compatibility. Derby templates got a rewrite, but most of the racer stuff stayed the same. 0.6 is a turning point in terms of stability, performance, code organization. We will work on a change log to make migrating to it easier.
Internally we count on node's semantic versioning system to manage changes in our software modules.

getAttribute vs. model.get

This aspect of accessing data in components is not as simple as wed like it. Interally the code for doing data bindings is not quite ideal, and is the next big problem Nate wants to address.
Attributes are passed in as templates (a type of object), if you model.get on the path for an attribute, you get a template.
getAttribute renders the template you would get from the path.
The rule of thumb is if you are passing in initial value or config, use getAttribute in init.
If you want to do a read-write thing like a textarea value, or a slider controlled bound value, you can use model.get or model.at.
If you are using a bound value just be aware you can't use expressions.
This is different from before, in 0.5 if it couldnt figure out the lookup it would set the rendered value which caused performance problems. it also limited some use cases.

singleton components

Nate still debating if its a good idea to have singleton components.
In Lever we have an identicon component that served as the inspiration. It is really lightweight in requirements, doesn't need all the data stuff.
A singleton component is like a class made just to collect some static methods. The other way to accomplish this would be to define functions at top level, but the component is nice to group things together. Nate is still thinking it thru.
It's possible to use this pattern for timestamps in something like chat. It was advised that it's probably better to just use a view function. The chat example in derby-examples doesnt render time on the server, renders it on the client.
That's all for this week! Tune in, same time same place. We announce the office hour time every week on the mailing list!