ekatek f4563457e8 fix the update server package data unit test
Rewrote parts of the update server package data unit test to compare a pre-sync and a
post-sync catalog, rather than the output of package client's attempts to contact the server.
This is because in the new world, there is no accurate output, and instead, the function
modifies the catalog in place. Additionally, removed the old function that read from
data.json, since it was not used anymore, and cleaned up some comments and return values in
package-client. We no longer claim to return the contents of data.json, instead we return
an object that signals if we should reset the entire catalog, and/or if our connection to the
server flat-out failed. I am not sure that this is the best abstraction for this piece of code
(why does package-client modify the catalog, but not reset it, for example? Since resetting
has consequences, in the ideal world, the package-client would only have the logic to get data
from the server and it would be up to the catalog to figure out how to insert it into sql lite,
I think, maybe. Regardless, now is not the time to do that refactoring.)

The test is a little odd in the following ways. First, comparing every record ever published is
something that is already significantly harder than it used to be, and will get only harder from
there. (However, the test claims to check that no data has been erased, so we need to check it).
We check the vague existence of most records, on the theory that it is unlikely that
we only got a portion of the record in, rather than the entire thing. Second, it doesn't check the
actual contents on disk, because I wasn't sure about writing another interface to sqllite this
late in the game. There are some ways to get around this -- we could be sneaky and submit a non-blank
syncToken in some way (faking a previous sync), so we only get the packages touched since (time X).
Usually, that might violate some internal consistency, but we only care about the contents at this stage.
Second, we should probably write some method on the catalogs to compare themselves instead of making
and querying a copy.For now, though, I think that this is sufficiently expedient.

Also, the test publishes 5 packages. That's a lot of packages, so I marked it as slow.
2014-09-29 22:16:32 -07:00
2014-09-25 19:45:48 -07:00
2014-09-26 23:03:20 -07:00
2014-09-29 08:48:08 -07:00
2012-03-21 19:41:06 -07:00
2014-08-14 21:39:14 -07:00
2014-09-23 23:07:41 -07:00
2014-06-24 09:29:52 -07:00

Meteor

Meteor is an ultra-simple environment for building modern web applications.

With Meteor you write apps:

  • in pure Javascript
  • that send data over the wire, rather than HTML
  • using your choice of popular open-source libraries

Documentation is available at http://docs.meteor.com/

Quick Start

Install Meteor:

curl https://install.meteor.com | /bin/sh

Create a project:

meteor create try-meteor

Run it:

cd try-meteor
meteor

Deploy it to the world, for free:

meteor deploy try-meteor.meteor.com

Slow Start (for developers)

If you want to run on the bleeding edge, or help develop Meteor, you can run Meteor directly from a git checkout.

git clone git://github.com/meteor/meteor.git
cd meteor

If you're the sort of person who likes to build everything from scratch, you can build all the Meteor dependencies (node.js, npm, mongodb, etc) with the provided script. This requires git, a C and C++ compiler, autotools, and scons. If you do not run this script, Meteor will automatically download pre-compiled binaries when you first run it.

# OPTIONAL
./scripts/generate-dev-bundle.sh

Now you can run meteor directly from the checkout (if you did not build the dependency bundle above, this will take a few moments to download a pre-build version).

./meteor --help

From your checkout, you can read the docs locally. The /docs directory is a meteor application, so simply change into the /docs directory and launch the app:

cd docs/
../meteor

You'll then be able to read the docs locally in your browser at http://localhost:3000/

Note that if you run Meteor from a git checkout, you cannot pin apps to specific Meteor releases or run using different Meteor releases using --release.

Uninstalling Meteor

Aside from a short launcher shell script, Meteor installs itself inside your home directory. To uninstall Meteor, run:

rm -rf ~/.meteor/
sudo rm /usr/local/bin/meteor

Developer Resources

Building an application with Meteor?

Interested in contributing to Meteor?

We are hiring! Visit https://www.meteor.com/jobs/working-at-meteor to learn more about working full-time on the Meteor project.

Description
No description provided
Readme MIT 202 MiB
Languages
JavaScript 91.1%
TypeScript 3.9%
Shell 0.9%
Java 0.7%
Swift 0.7%
Other 2.5%