I've been using it with vagrant. It's an amazing file sync between host and guest. Avoids so many of the annoyances of nfs et al
21 karma · joined September 4, 2014
Assuming that there's a stationary obstruction that you must come to a complete stop.
According to [1] the stopping distance of a car travelling at 70mph is 245ft (75m).
A car travelling at 70mph is doing approx 31m/s.
With a 0.5s reaction time, the car would travel only 90m, or; With a 200m range, the car would have 4s to initiate an emergency breaking manoeuvre.
[1] http://www.government-fleet.com/content/driver-care-know-you...
I only discovered the dashboard recently after using github for years!
Having the overview was actually the missing piece in getting control of my workload & priorities. -- So Thank you!
When the tabs receive the event, they each wait X milliseconds. The first timer to expire marks the event as "played". Other tabs receive this event, and abort their timers.
If a "leader" disappears, it will simply fall to a tab with a larger delay.
[1] Something like, rounded to 50ms increments, in a range, 100 - 1000ms. Avoiding collisions / ensuring uniqueness is left as an exercise for the reader.
While this article provides some metaphorical fish - I found the Design of everyday things helps you become a fisherman.
EDIT: Swapped the order of references.
[1] http://www.amazon.com/Design-Everyday-Things-Revised-Expande...
[2] http://blog.codinghorror.com/recommended-reading-for-develop...
Until now, I think Meteor wasn't on message for the experienced developer market.
It's a mistake to sell a technical product with the pitch "Look at what you can do with just a few lines of code!!!". And/ Or over simplified demos.
We want to see more articles like this- So now we know how it works - what are the limitations? What are the problems scaling? etc.
I was asking to see if there was any crucial evaluation I had missed putting MongoDB into production.
Below are a few replies to the points you raised:
---------
Data Loss:
Agreed this is a big cloud over the head of MongoDB -
Is it still notorious for this in recent times? Hopefully DBA's for Mongo now have more experience, and the software has matured enough that this isn't a common problem. - or more than it would be for any database.
Even then, you can only fall so far if you take regular backups, and have a fail-over & data recovery plan.
--------
"SQL is hard":
I get your point - a lot of people don't like or understand SQL. However, you seem to lump them with everyone who would appreciate an alternative interface.
Personally, I quite like SQL - some would call me an SQL-ninja. However, I don't think we should be limited to SQL as the one-true-way for accessing data.
Sometimes these new "NoSQL" interface allows new technologies to emerge. For example, the reason MongoDB is being used with Meteor is two-fold:
1. Minimongo - A wholly javascript based mongo query engine. It would be a much harder engineering problem to build a similar tool for SQL / PostgreSQL. 2. Logical Replication - A Meteor instance is effectively a logical replica of the Mongo Database - only for "live" queries, which it interprets using (1)
(1) Means that queries/ their surrounding code can be isomorphic (same on client and server). To replicate this for SQL would be a huge engineering challenge. How would you even replicate complex joins etc?
(2) Logical replication was only made available in PostgreSQL 9.4 - but without a pluggable query interpreter [even for join-less queries], it still wouldn't work.
----------
Relational Data:
Agreed, that data itself is best decomposed into fully-normalised form (Even up to 6th Normal form if you like temporal data). This allows for single-location, conflict-free and consistent updates/inserts/deletes.
But data usage is inherently document based - and the generation of those documents from fully normalised data, on huge data sets with complex relations, is a massive problem!
Until we have better tools for managing documents made of relational data - eg. PostgreSQL materialised views, but update only invalidated rows, - there will still be a drive to store data (& maintain) in the format that it is read.
Unlike the poor children of the world - Koch's decisions are wholly responsible for his current predicament.
The "market" doesn't care about individuals like Koch, and he chose to continue despite his efforts not being reciprocated/acknowledged.
I'd like to say that Koch should have abandoned the project, and if the market saw that maintenance/development of GPG was important, it would have happened.
However, it's not a perfect world - and there are probably plenty of pieces of critical software installed on our systems that are no longer maintained.
Would GPG have become one of these unmaintained codebases had Koch acted in his own self interest?
Or, would have another organisation/individual funded someone else to maintain and develop it?
Personally, the lack of transactions & ACID compliance bother me - but Mongo 3.0 (Coming in March) should alleviate those concerns. [1]
You can query data from SQL; just include necessary NPM driver and you're away. It wont be "Realtime" though.
Other NoSQL Support: The realtime driver is the problem here.
Meteor creates "live queries" by tailing the MongoDB oplog. This works in part because "Minimongo" a javascript based mongo query engine can examine the oplog and determine what does & doesn't match a live query.
To support another NoSQL solution, this huge engineering effort would need to be reproduced.
To support "Realtime" SQL, they'd need to hook in to something like PostgreSQL 9.4's logical replication, and have a javascript based query-compiler & interpreter. (Or provide a mongo-like interface to SQL.) Not impossible, but not easy by all means.
I somewhat agree with the Grandparent (re: Firebase/Parse) - However, I'd like to see the Meteor team have their own realtime database; as the realtime paradigm changes how a lot of it would be built.
If there were a wage involved, potentially more of the original applicants could afford to go through the hiring process.
At least the modern standard is to pay the potential hire as a contractor / consultant to do a few small projects, and then decide if you'd like to hire them on as an employee.
It would be great as a web app too. I'd like to post on my linkedIn / personal sites / profiles:
"Want to meet me for lunch? join me via colunchers.com/########"
They could see what public lunches I was hosting / attending . Or create a lunch and invite me.
I think you need to take your curiosity to google (or the real world), and do your own research.
You can only view & modify data on the client that has already been published.
Data that you don't publish / is server only, will remain so.
Low latency (real-time) can be an important part of effective and engaging communication.
Sure, it's not for everything; I wouldn't want my email communicating word by word to my recipients as I typed.
However, enterprises usually involve a lot of communication - with team members, stakeholders, and clients. - there are many opportunities to spice things up and make them more engaging & effective.
There's also the opportunity to instantly communicate non-prose - manipulating datasets, images, graphs and charts in real time.
We've built an enterprise/b2b app on meteor, and even through all of the hard yards, it's been a success & the right choice for us.
When I first heard about meteor, back at v0.5 or v0.6 - I watched the video from their home page, and thought it was full of buzzword bullshit. I didn't have a clue what it did.
I then ended up reading about how their latency-compensation API system worked [Meteor Methods]; And instantly knew that it was for me.
Having an API that simulates itself on the client, while simultaneously performing the same work on the server, is freaking awesome. (And then rolls back automatically if they don't agree).
If you are building a real-time, collaborative tool. Meteor is the framework.
That being said, there are a few questions about integration & scalability.
Opportunities to use Meteor:
* If you can make something small, eg. an internal tool [Free mobile app with cordova!]
* If it matches a certain feature of your app - and you can segment it based on URL (eg, it's a separate app)
* You're a sadist, and you're going to port your whole app to meteor...
* You're writing an MVP and you're going to scrap it later
* You're product has realtime/ collaborative elements that are a SELLING feature [not just for your personal enjoyment].
Scalability:
* Client are always connected via websocket. Great for realtime data (no polling), crap for a website.
* As meteor instances are single threads, you can run multiple instances on the one server. Design you code for this (eg, don't store state in regular JS variables on the server - all has to be in the database). Load balance between them.
* Once the "client" has booted up. You can then connect to as many other DDP servers [backed by their own mongo instance, or the same mongo instance] as you like. This gives you the ability to segment your application based on your core feature. EG; if you're a monitoring app, shard your data by client, if you're a document app, shard by project. Have a central listing which tells them which server to connect to.
* Perform heavy lifting somewhere else. Plenty of "web workers" out there, or roll your own using Celery & Meteor-Celery package [shameless plug].
All in all. Meteor is great at what it does; and what it does, is going to be the next generation of web apps.
The main points I see in the article, are that weak labour = weak market, and not every country can be an exporter.
It seems that pressure to increase profitability, ends up exerting itself by reducing labour utilisation (via efficiencies or other means). Which (can eventually) in turn, exert further pressure to increase profitability (due to a weaker market).
What I find disheartening is, the current tools governments have to improve the situation are hamstrung in a global environment.
* Corporate Taxation wont work without global reform
* Minimum wages, employment conditions, and other regulations don't work if the job can be outsourced / performed overseas
* Import tariff's on the former, usually result in your own exports being penalised (in retaliation)
* Existing players wish to maintain the status quo
The other issue, is "free time". There could be a considerable portion of the labour market are willing to take a part time-job "for the love of it" with their free time. Effectively volunteering or taking a "token" wage.
Industries accessible to hobbyists / free timers, will suffer a further devaluation of labour, if they haven't already. Anecdotally, it appears this has already started for some roles like teaching / professorships.
The odds seem firmly stacked against a good percentage of the global population. Hopefully those capable of making lasting change do so, before it's too late.
and
> You can't rely on others to sell the product you built.
Agree 100%, we had the same epiphany a 6 months ago; actually _selling your product_ is one of the most important jobs as a founder.
Also, I don't think you can [reasonably] pay someone a salary, and expect the same level of understanding & drive that the founders posses. And, it also seems that understanding & drive are much more important than clever marketing plans when selling B2B software.
Funnily enough, we're selling to the same market, although we help with the estimating & quantifying side of dealing with Blueprints - https://groundplan.com/