I studied meteor.js for about 10-12 hours last weekend.
Sharing my impressions:
FAST DEVELOPMENT – if it can work for your project, you can develop in maybe half the time as say angular/django or django by itself even. Maybe even faster than that. Seriously. Watch the short screencast on their home page to get a feel for it: https://www.meteor.com/
Basically it mirrors a lot of the datastore in the client and seamlessly keeps the two in sync. So you don’t have to worry as a developer about the backend as much – no writing api endpoints, no writing the code gluing front and back together, etc. Validation code can be written once and used both client and server side. Cool latency compensation. User accounts already plug and play – no big hassle getting that set up, one liner and you are good to go, which is sweet time saver. Community contribs get you CRUD admin with a one liner, and reactive forms that save a lot of work. Read full list on their front page of cool features.
short learning curve – it is easy to learn and would be ideal for situations like BCF’s where we need to get student programmers up to speed quick.
Based on Mongo – this is part of why it is fast dev. But also the big down point. Schema free document store for persistence makes things go faster in dev, but you really have to know your use cases, queries needed, etc up front. In some ways it is not as amenable to change as a relational data store (in other ways it is totally pliable). And can have issues with relational integrity.
Meteor is not at 1.0 yet. And they are adding support for other backends, like MySQL is likely usable now, and will get even more robust quickly. I think another 6 months and meteor is going to be getting huge attention when they release 1.0.
The ecosystem is surprisingly extensive with tons of community contributions. As extensive as angular’s it seemed to me.
Looks like WebRTC is getting here good enough that we should add it to our arsenal.
Not available yet for Safari or IE (except through Chrome Frame, being discontinued)
There are companies making it easier sort of like twilio makes voip and sms easier. I think I even read twilio was messing with adding it to their apis:
and meteor and angular folks are playing with it:
and lots of competition already if you want to create that great webex solution / skype replacement:
but I suppose we could create one geared to use by researchers…
Testing and Django links:
1. Why and When To Use Test-Driven Development Effectively
2. Getting started with automated testing
3. Testing and Django
So in the past I have gotten logos done via here: http://logotournament.com/
Just found this for going beyond logos:
icons, everything, you name it.
cryptographic signing – perhaps to generate one-time url for results download
more encrypted fields:
but once encrypted, then cannot query or sort
so presumably use two stage system:
stage 1 – intake, more open access, collects data over https, encrypts into postgres, then transferred to stage 2 – only current data and only certain fields kept post transfer to stage 2
So if comprised, limited data exposed.
stage 2 – not encrypted, limited access
So quarantine and encryption doing the protection.
stage 2 could be encrypted, but then for client use all data would need to go to client and sorting / filtering happens in client. seems just as secure overall to just limit access in stage 2.
How to manage transfer process? Add a succession number to track which items have been transferred. do transfers on cron schedule, or everytime new data comes in to stage 1. need a policy for expiration at stage 1.
What about overall security model?
another slightly more sophisticated approach:
From Client-side Encryption to Secure Web Applications by
Submitted to the Department of Electrical Engineering and Computer Science on April 24, 2013, in partial fulfillment of the
requirements for the degree of
Master of Science in Computer Science and Engineering
This thesis presents an approach for designing secure web applications that use client-side encryption to keep user data private in the face of arbitrary web server compromises, as well as a set of tools, called CryptFrame, that makes it easier to build such applications. Crypt- Frame allows developers to encrypt and decrypt confidential data in the user’s browser. To ensure an adversary cannot gain access to the decryption keys or plaintext data, CryptFrame provides a browser extension that stores the keys and allows only sensitive regions in the web page to access them. CryptFrame performs templatized verification of sensitive regions to grant small amounts of trusted client-side code access to plaintext data in the browser. Finally, CryptFrame provides a principalgraph to help users safely change permissions on shared data in the presence of active adversaries. We use CryptFrameto modify several existing Django-based applications, requiring few source code modifications and incurring moderate performance overhead.
Thesis Supervisor: Nickolai Zeldovich Title: Associate Professor