Now: realtime Node.js deployments(zeit.co)
zeit.co
Now: realtime Node.js deployments
https://zeit.co/now
120 comments
> but there's just something weird about reusing package names for totally different projects...
Not only is it weird but it is inherently insecure.
Even NPM's solution:
> "If a package with known dependents is completely unpublished, we’ll replace that package with a placeholder package that prevents immediate adoption of that name. It will still be possible to get the name of an abandoned package by contacting npm support."
seems susceptible to social engineering. All it takes is for one heavily depended upon package to become compromised by a malicious actor, and the entire dependency graph is poisoned.
I'm not sure of a great solution, but it really makes you question the soundness of the NPM ecosystem.
Not only is it weird but it is inherently insecure.
Even NPM's solution:
> "If a package with known dependents is completely unpublished, we’ll replace that package with a placeholder package that prevents immediate adoption of that name. It will still be possible to get the name of an abandoned package by contacting npm support."
seems susceptible to social engineering. All it takes is for one heavily depended upon package to become compromised by a malicious actor, and the entire dependency graph is poisoned.
I'm not sure of a great solution, but it really makes you question the soundness of the NPM ecosystem.
I really see no good reason not to employ namespacing with immutable packages. If a package is dropped, all is well still. If readoption is needed, people can use the new package, similarly named. It obviously also allows for similar but different named packages to exist, which I don't see as a problem. I can usually find the top repo on github for instance, even with multiple forks. I worry about Rust since they have decided against namespacing, even though some suggested otherwise, early on..
I've had one of my package names transferred away from me with no warning, presumably after some period of inactivity. Npm as a repository seems to have gone totally insane, and I don't think I'll be publishing there anymore. I'll recommend people install my modules from a tag in the repo.
I hope they break the API and create proper namespacing. I recommend using the model from Composer/Packagist.
Needs more hashes
There should be at least some warning on the page that an earlier project with similar name was replaced with this package.
People make fun of Java's namespace conventions [1], but it goes to show the advantages of not having to have a central authority to decide on these matters.
https://docs.oracle.com/javase/tutorial/java/package/namingp...
People make fun of Java's namespace conventions [1], but it goes to show the advantages of not having to have a central authority to decide on these matters.
https://docs.oracle.com/javase/tutorial/java/package/namingp...
Had to read three pages and still haven't quite confirmed that this is node.js hosting. But based on the pricing page, I guess it is. Can you please just say that? Just say "It's node hosting and the deployment system is fast." You literally just stole some of my life.
Just to piggyback for people confused:
It's zero-configuration Node hosting, for permanent lightweight microservices or temporary Node projects that need to be accessible online.
In other words, it's as close to uploading PHP files to a server that you'll get with Node.
For people wondering, the creator is Guillermo Rauch, who is behind Socket.io and LearnBoost (the company that brought us Express, Mongoose, Stylus, Jade, etc... basically the entire Node stack)
It's zero-configuration Node hosting, for permanent lightweight microservices or temporary Node projects that need to be accessible online.
In other words, it's as close to uploading PHP files to a server that you'll get with Node.
For people wondering, the creator is Guillermo Rauch, who is behind Socket.io and LearnBoost (the company that brought us Express, Mongoose, Stylus, Jade, etc... basically the entire Node stack)
Why not just upload node files to a server?
For PHP, you upload index.php, go to yoursite.com/index.php, and it works. Node isn't like that at all. For example, here's the "Hello World" guide for getting Node started:
https://www.digitalocean.com/community/tutorials/how-to-set-...
This is basically the problem `now` is solving... "what if Node was as easy as PHP?"
https://www.digitalocean.com/community/tutorials/how-to-set-...
This is basically the problem `now` is solving... "what if Node was as easy as PHP?"
> For PHP, you upload index.php
That's not inherent to PHP. It's just how most hosts are set up. The only major difference is the order in which things are done (and the necessity to have shell access to the host.)
The real comparison is this:
# PHP # 1. Install a server 2. (Possibly optional) Install a process manager 3. (Possibly optional) Configure the process manager 4. Configure the server 5. Start the server 6. Upload files
# Node # 1. Install Node 2. Upload files 3. Start the server
That's not inherent to PHP. It's just how most hosts are set up. The only major difference is the order in which things are done (and the necessity to have shell access to the host.)
The real comparison is this:
# PHP # 1. Install a server 2. (Possibly optional) Install a process manager 3. (Possibly optional) Configure the process manager 4. Configure the server 5. Start the server 6. Upload files
# Node # 1. Install Node 2. Upload files 3. Start the server
So you have 3 configuration steps for PHP and none for Node? You're completely full of it.
I suppose you could do that, but I reckon their main selling point is convenience. Same argument can be made for any cloud hosting service.
Why not just buy a VPS and set it up yourself, it's just more convenient for some people.
Why not just buy a VPS and set it up yourself, it's just more convenient for some people.
We'll add the keyword "hosting" in some of the explanations which should help. Thanks for the feedback!
it literally says "now: realtime node.js deployments" on the top on the page.
> You literally just stole some of my life. he absolutely did not! You decided to spend time investigating what now is, he did not steal anything from anyone.
> You literally just stole some of my life. he absolutely did not! You decided to spend time investigating what now is, he did not steal anything from anyone.
deployment != hosting.
Red Hat Openshift has a solid free tier, free SSL, git push deployments, node / ruby / python / java / php / etc., mysql / postgres, redis. Why would I use this over that?
https://www.openshift.com/
https://www.openshift.com/
This seems like a different use case than those solutions. This is if you're working on a project and you want to share the state of what you're working on across the net. Think of it like a point-in-time disposable link shortner but for a full node app.
http://ngrok.com - is pretty good for that, if the person you're sharing it with is available.
Checkout https://localtunnel.me
Our focus is on empowering the realtime JavaScript cloud with its rich module ecosystem.
With the advent of microservices, code will become more succinct. Your backends will be aggregations of small functions with clear inputs and outputs.
The syntactic differences between languages will matter less. Our bet is that JS has the largest and most prolific community!
With the advent of microservices, code will become more succinct. Your backends will be aggregations of small functions with clear inputs and outputs.
The syntactic differences between languages will matter less. Our bet is that JS has the largest and most prolific community!
> Our focus is on empowering the realtime JavaScript cloud with its rich module ecosystem.
I'm sorry, but that's just meaningless buzzword bingo.
I'm sorry, but that's just meaningless buzzword bingo.
translation: they use websockets on AWS with insane numbers NPM modules.
Actually, I think the issue is that you just don't understand the meaning of those words.
The "rich module ecosystem" he is speaking of refers to npm. With node and npm it is trivial to install a few modules from the command line, write up a custom server, and very quickly have yourself a dynamic web page or API.
The "realtime JavaScript cloud" is basically any node application running on a service like Heroku or with any number of hosts and providers ranging from self-managed VPNs to esoteric AWS services. Applications that run on this realtime JavaScript cloud are incredibly portable as engines can be fired up and torn down very quickly across both server-side and client-side environments.
This service that he has been a part of creating does exactly this. It empowers the user by streamlining existing development processes.
I would say that his sentence is rather meaningful contemporary industry jargon.
The "rich module ecosystem" he is speaking of refers to npm. With node and npm it is trivial to install a few modules from the command line, write up a custom server, and very quickly have yourself a dynamic web page or API.
The "realtime JavaScript cloud" is basically any node application running on a service like Heroku or with any number of hosts and providers ranging from self-managed VPNs to esoteric AWS services. Applications that run on this realtime JavaScript cloud are incredibly portable as engines can be fired up and torn down very quickly across both server-side and client-side environments.
This service that he has been a part of creating does exactly this. It empowers the user by streamlining existing development processes.
I would say that his sentence is rather meaningful contemporary industry jargon.
I do understand them exactly the way you explained.
However, they're still a buzzwordful, dodging, non-answer to the relative parents' very simple question. They're a reiteration of the most basic, marketing-level bulletpoints on why node.js and microservices are so wonderful! that barely scratch the surface of real-world software complexity.
However, they're still a buzzwordful, dodging, non-answer to the relative parents' very simple question. They're a reiteration of the most basic, marketing-level bulletpoints on why node.js and microservices are so wonderful! that barely scratch the surface of real-world software complexity.
I'm gonna go further: that is actually a fantastic mission statement!
I believe that it is very important to have goals that are simple in definition. It can really help the cause if the ultimate meaning is somewhat allusive. The act of interpreting the mission statement bakes in a dynamic element that can help keep an organization from getting stuck in place.
That I can interpret this mission statement in a verbose, complicated and applied manner is an example of its utility.
I believe that it is very important to have goals that are simple in definition. It can really help the cause if the ultimate meaning is somewhat allusive. The act of interpreting the mission statement bakes in a dynamic element that can help keep an organization from getting stuck in place.
That I can interpret this mission statement in a verbose, complicated and applied manner is an example of its utility.
How are you thinking about latency in an environment where there's a waterfall of Now function calls? Will Now functions calling over Now functions naturally get cached on the same server?
There's no explicit concept of "now functions". You simply deploy HTTP/2 services to the cloud.
HTTP/2 significantly improves performance by introducing multiplexing and header compression. There's no need to introduce new concepts or APIs. REST away!
HTTP/2 significantly improves performance by introducing multiplexing and header compression. There's no need to introduce new concepts or APIs. REST away!
I think this is a fantastic way to do code interviews who ask us to make an app n host it in a real URL for consumption. It's just one use case that can immediately think of.
Also, Openshift is only supporting Node O.10 right now...
Valid point, but there is a fairly robust open source community that provides many more packages (called cartridges in openshift lingo) than are officially supported [0]
[0] https://github.com/icflorescu/openshift-cartridge-nodejs
[0] https://github.com/icflorescu/openshift-cartridge-nodejs
Ah cool. Kind of like a Heroku build pack. Still more effort than 'just deploy' though.
Not quite. I'm currently using version 5.7 on openshift. You can define the node version in the .openshift/markers/NODEJS_VERSION file.
Docs here: https://blog.openshift.com/any-version-of-nodejs-you-want-in...
Docs here: https://blog.openshift.com/any-version-of-nodejs-you-want-in...
[deleted]
CEO of https://zeit.co here!
Happy to answer any questions throughout the day :)
Any chance of some clarification around the limits of the free tier?
> 20 FREE deploys per month
So I can only run the `now` command 20 times each month? What are you using to track how many times I've run it already? IP? NPM username? Package name?
>1MB size limit per file
Is this at deployment time or is this also enforced at runtime? If I deploy a 900kb sqlite file, then add 200kb of records to it at runtime, what's going to happen?
> Perfect for open-source demos, classrooms, tutorials & testing.
Are 20 deploys per month really enough to use in a teaching context? I'd love to use this tool in the web tech module I teach at my university, but I think most students would burn through 20 deploys in a week, let alone a month. Is there any chance this limit could be re-thought for teaching purposes?
I wouldn't mind if some of the other restrictions were changed, but free tiers that halt development til the start of next month don't sound great for learning to me.
> 20 FREE deploys per month
So I can only run the `now` command 20 times each month? What are you using to track how many times I've run it already? IP? NPM username? Package name?
>1MB size limit per file
Is this at deployment time or is this also enforced at runtime? If I deploy a 900kb sqlite file, then add 200kb of records to it at runtime, what's going to happen?
> Perfect for open-source demos, classrooms, tutorials & testing.
Are 20 deploys per month really enough to use in a teaching context? I'd love to use this tool in the web tech module I teach at my university, but I think most students would burn through 20 deploys in a week, let alone a month. Is there any chance this limit could be re-thought for teaching purposes?
I wouldn't mind if some of the other restrictions were changed, but free tiers that halt development til the start of next month don't sound great for learning to me.
Really cool website! I'm confused though exactly what is going on. Is this kind of like Heroku? What are the pros and cons of this service? For context, I'm currently running a production node/express/mongo service on Digital Ocean.
Compared to other providers, there's absolutely no setup involved. No Procfiles, ports, containers, dynos, processes, instances… Just type `now` where you have a `package.json`.
This is very cool. I'm excited to use this in my next project. I like the zero setup, no fuss, secure by default features. I guess 4 more questions:
1) Does "Dynamic Realtime Scaling" mean you spin up more clusters and do load balancing automatically?
2) Can your $15/month cost cover this? Or is that what the 50GB bandwidth cap is for?
3) The nature of this service means we need to use a DB service like mLab (mongoLab) or run our own DB server right?
4) What about production logs?
1) Does "Dynamic Realtime Scaling" mean you spin up more clusters and do load balancing automatically?
2) Can your $15/month cost cover this? Or is that what the 50GB bandwidth cap is for?
3) The nature of this service means we need to use a DB service like mLab (mongoLab) or run our own DB server right?
4) What about production logs?
How is there no port? I have to run my server on some port, are you saying I can choose whatever my port I want and your service detects that somehow? I don't need to use process.env.PORT ?
Cool. But what about persistence / choice of database and how can I scale up / down?
Curious about performance of npm install, seems like it's one thing that could make it not so snappy. For compiled modules, does it have a decent amount of memory/CPU on the instances? How about connectivity? Does it use a mirror for NPM? Might it in the future?
Our biggest focus is `npm install` performance. We have multiple caches to make it the best possible experience for you.
Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility.
Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility.
> Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility.
This is very confusing to me as these seem to be contradictory statements. Installing "from scratch" (I take this to mean, as if node_modules is an empty folder) is not a reproducible action, as all it takes is one sub-dependency releasing a new version to change your installation.
Can you clarify what you mean and resolve this seeming paradox?
This is very confusing to me as these seem to be contradictory statements. Installing "from scratch" (I take this to mean, as if node_modules is an empty folder) is not a reproducible action, as all it takes is one sub-dependency releasing a new version to change your installation.
Can you clarify what you mean and resolve this seeming paradox?
In order for you and your team to never rely on transient local state (either in the cloud or your own computer), we "start from scratch".
However, our process of starting from scratch is actually faster than running `npm install` on your own computer in many cases.
As an example, I've found myself getting into the habit of using `now` instead of `localhost`.
However, our process of starting from scratch is actually faster than running `npm install` on your own computer in many cases.
As an example, I've found myself getting into the habit of using `now` instead of `localhost`.
This doesn't address the poster's issue: If you reinstall every time, the results won't always be the same (not that I personally hold this as a big issue, I'd consider it on the programmer to freeze their package.json)
I think it's "reproducible" in the sense that it starts from scratch every time, rather than sometimes starting from scratch, and other times starting with a pre-populated node_modules. If you want actual versioning reproducibility, you'll need to put an npm-shrinkwrap.json in your root.
I see. They shouldn’t use the word “reproducible” then, because something is either reproducible or it’s not.
If they just mean, “We ignore everything but your package.json to generate a deploy,” say that, don’t mis-use the word “reproducible.”
(Heroku, for example, has put a lot of effort into making deploying to their platform actually, truly, really-the-same-years-into-the-future reproducible. `npm install`, especially without shrinkwrap -- and `now` doesn't seem to be using shrinkwrap -- will never get there.)
I’m still not 100% if I get what they are doing or not.
After all, I need some sort of index.js or dist/foo.js in my package, and if they aren’t using git or anything, then isn’t this by definition happening based on transient local state (my local files at `now`-time)?
If they just mean, “We ignore everything but your package.json to generate a deploy,” say that, don’t mis-use the word “reproducible.”
(Heroku, for example, has put a lot of effort into making deploying to their platform actually, truly, really-the-same-years-into-the-future reproducible. `npm install`, especially without shrinkwrap -- and `now` doesn't seem to be using shrinkwrap -- will never get there.)
I’m still not 100% if I get what they are doing or not.
After all, I need some sort of index.js or dist/foo.js in my package, and if they aren’t using git or anything, then isn’t this by definition happening based on transient local state (my local files at `now`-time)?
> `now` doesn't seem to be using shrinkwrap
They aren't? I haven't tried a deployment, but was hoping/assuming they'd upload a shrinkwrap along with everything else and that it would drive the install as per usual.
> I’m still not 100% if I get what they are doing or not.
I think their angle is to lower barriers to entry close to zero for cloud deployments, and thus drain a shallow ocean. "Shallow" in the sense that there are devs who are interested, but maybe not interested enough to buy into terminology like "dynos" or "cartridges" or "lambdas". "Ocean" in the sense that there are (supposedly) quite a few of these people.
They aren't? I haven't tried a deployment, but was hoping/assuming they'd upload a shrinkwrap along with everything else and that it would drive the install as per usual.
> I’m still not 100% if I get what they are doing or not.
I think their angle is to lower barriers to entry close to zero for cloud deployments, and thus drain a shallow ocean. "Shallow" in the sense that there are devs who are interested, but maybe not interested enough to buy into terminology like "dynos" or "cartridges" or "lambdas". "Ocean" in the sense that there are (supposedly) quite a few of these people.
I’m potentially one of those people, at least for personal projects and such. But I also need to understand what the hell I’m getting into before I make the leap.
I haven’t kept my personal site up with no linkrot for the past 10 years by making technology choices on a whim, you know?
I haven’t kept my personal site up with no linkrot for the past 10 years by making technology choices on a whim, you know?
So the deploys do not depends on npm infrastructure at all?
Something that’s bothering me is: Is there any way to deploy via `now` with secrets? You know: API keys or the like? `_src` is always public in the free plan and I don’t see any documentation around providing environment variables.
my guess is that for free tier, it's targeted at demo/tutorial so environment variables wouldn't be necessary. If you are serious about privacy then you have to upgrade to paid tier.
But heroku does offer environment variables to free tier and it is handy for database keys and 3rd part API keys, so I guess they will add that at some point through some user-facing web interface or just cli options.
But heroku does offer environment variables to free tier and it is handy for database keys and 3rd part API keys, so I guess they will add that at some point through some user-facing web interface or just cli options.
> so env variables would not be necessary
My initial thought as well — but it’s simply not true. Let's say you want to demo something that is using Firebase on the back end. You can't just give away your credentials or your demo may get very broken very quickly… and you’ll foot the bill
My initial thought as well — but it’s simply not true. Let's say you want to demo something that is using Firebase on the back end. You can't just give away your credentials or your demo may get very broken very quickly… and you’ll foot the bill
A couple questions:
(1) I notice that your pricing chart mentions storage. I'm wondering what that typically would consist of? Only thing I can think of are static assets as I imagine a codebase — even with a million npm module dependencies — wouldn't come close to 1GB let alone 100.
(2) Is it possible to back your apps with a database/datastore? Say I want to use MongoDB with my app. Would I need to purchase a third party service and set the MONGO_URL in the env? Are there any plans to offer database services as add-ons?
(1) I notice that your pricing chart mentions storage. I'm wondering what that typically would consist of? Only thing I can think of are static assets as I imagine a codebase — even with a million npm module dependencies — wouldn't come close to 1GB let alone 100.
(2) Is it possible to back your apps with a database/datastore? Say I want to use MongoDB with my app. Would I need to purchase a third party service and set the MONGO_URL in the env? Are there any plans to offer database services as add-ons?
A more techy question, how can you let anyone use any port, how will your proxy know where to redirect?
sudo netstat -plnt
Nice, is it meant for permanent hosting or just for prototyping and how does it compare to Cloudnode (https://cloudno.de)
Not received my confirmation email yet, it has been > 10 minutes
Excuse my ignorance, but could this work with Meteor?
[deleted]
I'm curious about the differences between hosting a node app on zeit vs heroku.
How do you plan to appeal to the enterprise/larger apps market?
Can this be used with a CI service very easily?
What's the difference with dokku?
The pricing structure is missing a couple of middle tiers and overall the service lacks useful features. For instance: I could buy a $5/mo droplet in Digital Ocean, one click install node, even use my own domain and manage deployments/restarts almost as easy. For that money I get 1TB transfer and 20GB ssd and many more features (b/c I basically get a VPS where I can do whatever). It takes me 10 min to setup the server and zero minutes to deploy each new version (I use deploybot so every git push is really a deployment).
Some things are not clear:
"Dynamic realtime scaling" Forever? Unlimited? Say 1MM concurrent API calls for $15/mo?
URLs change after each deployment? Do I need to update endpoints on all clients?
Some things are not clear:
"Dynamic realtime scaling" Forever? Unlimited? Say 1MM concurrent API calls for $15/mo?
URLs change after each deployment? Do I need to update endpoints on all clients?
This looks cool. It's like http://surge.sh but for the backend.
Off topic: Right when I saw the terminal, I instinctively typed "ls". Not sure now if that's what triggered the animation or not but regardless it was a neat occurrence (I also just want to leave it at that ;) ) Yayy muscle memory!
> You can think of 𝚫 now as a CDN for dynamic code (microservices and backends).
Mmmmmmmmmmmmmm not a CDN.
Mmmmmmmmmmmmmm not a CDN.
> NOTE: npm start has to listen on a port. It can be any port!
Does this mean you forward port 80/443 to whatever port the app is listening on, or I can have my app listen on random external ports?
Does this mean you forward port 80/443 to whatever port the app is listening on, or I can have my app listen on random external ports?
Yes. Just do `app.listen()` or pick `3000` or `8080` or `80` or…
What makes the deployment "realtime"? Is it just that you get terminal output of the deploy happening? That's been around for a while now. Or am I missing something?
[deleted]
This looks very promising for the node community. I was wondering which cloud infrastructure service they went with to power this. According to the FAQ, they don't rely on just one. Very cool, and if implemented correctly, more resilient.
Multi-cloud.
We don't depend on a single specific cloud provider, but abstract them instead.
Does this support native modules and is it running on Linux 64?
If so it'd be an interesting "hack" to have it run arbitrary code. You could have the default "npm run" script download a python/ruby/golang/foobar runtime and kick start an app on the expected port.
If so it'd be an interesting "hack" to have it run arbitrary code. You could have the default "npm run" script download a python/ruby/golang/foobar runtime and kick start an app on the expected port.
Are these zero downtime deployments?
They seem to be one-time deployments that never go away. Since there is no updating and no "down" at all, I think the answer to your question is "N/A."
But I may have it wrong. It’s a unique-seeming service, which can make the nuances hard to understand
But I may have it wrong. It’s a unique-seeming service, which can make the nuances hard to understand
Yes. There's no downtime whatsoever because you don't overwrite or take down anything. Your architecture is immutable.
You manage "upgrades" by changing pointers (aliases and DNS). We'll be exploring this in upcoming posts.
You manage "upgrades" by changing pointers (aliases and DNS). We'll be exploring this in upcoming posts.
It'd be so nice to have it automatically swap the DNS records over. Please consider that as you keep building.
No. For zero downtime deployments on AWS with blue/green deployments behind EIPs & ELBs, we at Boxfuse (https://boxfuse.com) offer a very easy solution for both Node.js and JVM apps based on immutable infrastructure.
Very cool! I was just saying how hard it is to get someone to deploy a quick node app. Trying it with a React + Express app right now. Taking a while to deploy but I assume you are getting hammered.
Once you've done it once it is very quick imo. Deploy 1 to Digital Ocean with Node/Express/Mongo took me a work-night and deploy 2 and 3 took me < 15 minutes.
it's easy on heroku. I haven't done it with native modules though
Looks neat for demo apps. I did try it out on one of my simpler express based apps and it failed during the npm install. Looks like this is possibly using ied?
20 free deploys a month? Is every update a deploy?
I think so, because I don’t think "updates" are a thing: https://news.ycombinator.com/item?id=11440659
But I wish they would clarify this, either way.
But I wish they would clarify this, either way.
Like these quick deployment solutions zeit.co/now and surge.sh Sacalbility and security is something that needs to be attested.
Does now only support HTTP/2 or could I also use TCP or WebSockets?
Can you have database dependencies? Like a full-fledged SQL database?
Seems cool.
After many years on node, and even writing a deployment service once (paastor) - just plain VPS, nar to make an executable, then scp onto an Ubuntu server, and scp a logrotate and upstart conf - that's all you need man.
What happened if you did a recursive now build?
Is the now cli not open sourced?
Fantastic intro write up to read in a mobile browser. Wish many products get to what matters like these in their descriptions. Interesting enough to try immediately!
Hey man, keep up the good work. I'm sorry this forum is so filled with trolls these days.
We detached this subthread from https://news.ycombinator.com/item?id=11440536 and marked it off-topic.
I'm sorry that you treat anyone with different viewpoints from yours as a troll. Don't worry, I'm not taking this personally.
That you can't see how much of a dick you're being when you accuse someone of playing "buzzword bingo" is proof to me that you can't be anything but a god damned troll. This isn't about having different viewpoints. This is about you objectively being an asshole.
Edit: Sorry, TRIGGER WARNING: Real things are being said.
Edit: Sorry, TRIGGER WARNING: Real things are being said.
If I were accused of buzzword bingo, i'd try to take it as good-natured criticism that what I said was perhaps a little too filled with lingo to have a solid meaning.
It's certainly possible to read this example as a trollish remark, there's also a perfectly valid reading which interprets it as an attempt to provide useful feedback. Since I assume neither of us knows q3k, we're not in a position to know which is true, except for q3k telling us.
It's certainly possible to read this example as a trollish remark, there's also a perfectly valid reading which interprets it as an attempt to provide useful feedback. Since I assume neither of us knows q3k, we're not in a position to know which is true, except for q3k telling us.
It becomes pretty clear that it's not a troll when one puts his/her best-effort to interpret "realtime JavaScript cloud". It's a critic with a very obvious point.
Oh yeah Einstein, what's the point he's trying to make then?
God, this forum is just like 100% assholes these days. You can't even fucking see it either, can you? When was the last time you interacted with normal people in society? Did you just start out with bitter criticism and attacking their vocabulary?
God, this forum is just like 100% assholes these days. You can't even fucking see it either, can you? When was the last time you interacted with normal people in society? Did you just start out with bitter criticism and attacking their vocabulary?
If it's possible to gently point out that you're repeating the behaviours you deplore, I'd like to do so.
We all get how encountering wrongness and badness on the internet can put one on tilt, and we've all been there, but it's necessary to stop.
We all get how encountering wrongness and badness on the internet can put one on tilt, and we've all been there, but it's necessary to stop.
Hey dude, follow the thread: I'm defending someone from a bunch of bullies.
I'm not repeating those behaviors at all. I'm just calling a spade a spade.
You seem to think that someone who picks a fight with a bully is somehow guilty of also being a bully.
All you end up doing is passive-aggressively condoning their bullshit behavior in the first place.
I'm guilty of being nothing more than a fed up son of a bitch with a rude attitude. I can live with that.
You're morally bankrupt. Can you live with that?
I'm not repeating those behaviors at all. I'm just calling a spade a spade.
You seem to think that someone who picks a fight with a bully is somehow guilty of also being a bully.
All you end up doing is passive-aggressively condoning their bullshit behavior in the first place.
I'm guilty of being nothing more than a fed up son of a bitch with a rude attitude. I can live with that.
You're morally bankrupt. Can you live with that?
This is way over the line of what we ban people for. I don't want it to seem personal (it isn't), so won't ban you, but if you keep doing this we'll have to.
The rule is "Be civil" and it applies regardless of what you think other people are doing.
The rule is "Be civil" and it applies regardless of what you think other people are doing.
I honestly think we should hash this out in person. I live in Bernal Heights in San Francisco. My email address is [email protected] - I'd love to buy you a coffee and a scone and talk about how differing cultures and classes in America have different definitions of "being civil".
I'm like a living Rosetta Stone for rednecks and yuppies. I guarantee you'll spend most of your time laughing and that you'll leave with a giant smile. Hell, I might even bring my guitar along and pick a few songs out for you!
I'm like a living Rosetta Stone for rednecks and yuppies. I guarantee you'll spend most of your time laughing and that you'll leave with a giant smile. Hell, I might even bring my guitar along and pick a few songs out for you!
Looking at the npm release history, versions <= 0.8.1 are the old project, and the new project picked up at 0.9.0 (should have been 1.0.0 I guess). This is consistent with npm's statements about package name transfers during the leftpad debacle, but there's just something weird about reusing package names for totally different projects...