what the clueless developer says: it's concurrent

what the clueless eng manager says: the same code can run on the server and client. no more front end hiring hell!

The ability to deploy the same code to front end and back, for me anyway, works out quite well. With browserify, I can write common utilities and require the code using the commonJS module system. It's pretty seamless. Doesn't change the skill set necessary for front end development in any way though.

even big publishers like Yahoo can't do that because there's an average of 20 companies between then and the brands advertising. publisher would love to be alone in the field and pocket the .20 per click. but ad agencies go a long way to doubt the publisher reports etc and try to pay less.

every month a new layer show up, with the sole promise of allowing the ad vendor to pay less for the publisher. the fad du jour is viewable.

But the other way could work. A service like Cloudflare could become an ad network and inject ads in transit.

while this is true, there was always transitional periods that you ignore.

paper was once issued by a bank clerk while taking your gold or other goods. the govt started to issue them and allowed you to exchange back to gold at any time. eventually they undid all that.

checks and credit cards also are tied very closely to existing monetary concepts to start off.

bit coin start alone. that's why most people consider it crazy. when money was being adopted, if it failed you could still use the coin metal or exchange it to metal. if bit coin fail, though luck.

in Portuguese you have two translations for excuse me. one means sorry "desculpa", the other means get out of the way "com licença". the later when used forcing your way thru a door at the same time as somebody else is extremely rude. and that's how Portuguese speakers hear excuse me in this situations.

> serving drinks to everyone before filling your own glass

this happens in almost every culture but Americans, British and Germans.

Koreans even have extra rules (it must be the older person at the table).

As a Brit who lived in Germany for a while, a lot of Brits and Germans will fill each other's glasses before their own when sharing wine or water. Can't say anything about Americans though.

When I'm out with friends and we order a larger bottle of beer (like chimay) or get a pitcher the person who grabs the pitcher usually pours for others before themselves. It's pretty informal though, other times we just pass the pitcher around and wait for everyone to get their drink before starting. I'm in the southeast, not sure what the manners are like for the rest of the country.

I'm Norwegian and have lived in London for 15 years now, and I can't say I've ever noticed Brits pouring their own glass before others. I think I'd have noticed, as I would have found it quite rude if people served themselves first.

in California bars sell only 600ml glasses that are individual.

my Californian American friends when in Brazil said he was very disturbed by our "communist" approach to beer

There are California bars that sell pitchers of beer.

Germans don't? I live next to Germany (even our language is mistaken for German a lot of times, it's pretty close) and here everyone does that. It seems weird to me that a few kilometers east people wouldn't anymore... I'm going to ask some friends from there!

Honestly, in my experience it is pretty rare that people share a bottle in the US at all except wine and then there is usually a waiter who pours it.

Germans do it, British people do it, Americans do it. Weird point.

yet another duct tape kind of feature, from people already too corrupted by js, that will be further abused and cause yet more duct tape features in ES7.

this is nothing but a more convoluted way of the pattern that sets a unique object as a unique value for comparison. well, it adds a label for easy debug. hooray.

No, also symbol keys don't pollute for-in, Object.keys or Object.getOwnPropertyNames so they are effectively non-global.

As long as you don't use Symbol.for() that is - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

(I do think symbols are useful though, replied for correctness.)

Symbols created with `Symbol.for` don't pollute any of those things, either.

  let x = Symbol.for("omghax");
  let foo = Object.create(null)
  foo[x] = 'bar';
  Object.keys(foo).length // returns 0

there was already a solution for that: .style in dom elements. it is a place where you dump style properties ad-nausea.

Why not simply add a single new property to Object? It would do the very same thing, would not change the language. it would be readily available to all browsers if you just added that single new key in your logic as you already do with .style and others, and everyone would move on with their lives.

I have to agree this is a duct tape by people thinking they know language design. Now i will have to wait until all browsers have this before i can use. and then i will still have to worry about older browsers (oh android, the IE6 of moment). Not to mention the time browser developers would waste actually improving things will be wasted on that syntax sugar.

Symbols are used all the time in Ruby (and a bunch of other languages), not as duct tape but as a very core feature of the language. Why should it be different in JavaScript?

The most simple way to use them is to replace definitions like this one

    var north = 1;
    var south = 2;
    var east = 3;
    var west = 4;
    var direction1 = north;
    var direction2 = south;
    direction1 === direction2 ? "ops" : "ok";

The programmer is doing the work of the interprer/compiler here and make sure to pick unique values for all the constants that are going to be compared together. With symbols that becomes

    var north = new Symbol();
    var south = new Symbol();
    var east = new Symbol();
    var west = new Symbol();
    var direction1 = north;
    var direction2 = south;
    direction1 === direction2 ? "ops" : "ok";

which is an improvement even if it is (in a traditional JavaScript way) so much more verbose than Ruby's

    direction1 = :north
    direction2 = :south
    direction1 === direction2 ? "ops" : "ok"

I just wish they'll add some syntactical sugar to do without that "new Symbol()" thing and create symbols as needed like Ruby does.

Unfortunately, from https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...

    Symbols and JSON.stringify()

    Symbol-keyed properties will be completely ignored when using JSON.stringify():

    JSON.stringify({[Symbol("foo")]: "foo"});                 
    // '{}'

We're going to manually serialize them when they leave the RAM.

The base use case for JS symbols is not the same as Ruby symbols: regular strings will work just fine for that.

Symbols in ruby might have the same name but are fundamentally different. E.g. in ruby `:foo` and `:foo` are the same thing. In JavaScript, they are quite explicitly not the same thing. They share little in common (in terms of how they work and what they are designed to do) but the name.

N, E, S, W? I think you want an enum for that.

It was an example of replacing constants with symbols when the value of the constant really doesn't matter. Purposely not fancy stuff. I understand the advantages of enums (among the others, their values are constrained) but does JS have enums?

> does JS have enums?

No, but TypeScript and Dart do.

Enums don't really work without types.

But using Symbols for fake enums is probably a good idea.

    class Enum {
      constructor(...props) {
        props.forEach(p => this[p] = Symbol(p));
      }
    }
    const dir = Object.freeze(new Enum(...'NESW'));
    console.log(dir.E === dir.E); // true
    console.log(dir.E === dir.N); // false

Slightly awkward, but this might be about as good as it gets.

I should have used Object.freeze(this) in the c'tor.

that's very similar the home computer boom. if you look at the offerings at the time, everyone was running in a different direction. so many wonders. and in the end, cheap and available won.

you mean, just like a dvi port?

but with awful aim

> model S cost 40k and the next will be half of that

the cloud only exists because storage is cheap.

it should actually kill the cloud because storage is cheap. but all cloud providers go out of their way to make their platform painful to use without their cloud.

Apple makes backing up photos with iphoto annoying. Google makes backing up photos via an app much easier than via usb or rsync on your home network... etc

Storage in terms of raw bytes really is dirt cheap, but storage in terms of erasure encoded, encrypted, multi-homed, highly-available file systems isn't. Just buying a hard drive isn't going to get you very far. The durability of a file on a cloud service is going to far outstrip that of your local hard drive or even a fancy NAS.

Cloud services outliving my (not so fancy) NAS. So, where's my Webshots account? (since we're talking photos, let's take a photos example. It shouldn't be hard to find an example of a dead web service for any other kind of data, either)

_My_ datastore still exists and proudly provides those files from my redundantly stored, checksummed, auto-repairing local filesystem. No, I don't have an off-site backup. But neither had Webshots once they decided to shut down.

At least you generally get a warning for a cloud service going down. Then it's around as much hassle as a single component of the NAS failing.

I'm not sure what's more likely, a trustworthy-looking service disappearing out of the blue, or a RAIDed NAS being damaged in a way that data is lost.

As per Wikipedia (https://en.wikipedia.org/wiki/Webshots):

"By 2004, Webshots was grossing $15M/year, had more than 200,000 paid subscribers, and was the #1 photo sharing site and top 50 media property per ComScore. In the same year, Alexa ranked Webshots the second largest English language privately held Web media property (behind weather.com)."

Other photo-storage sites that are no longer around include Streamload, Kodak Gallery, Nirvanix, Snapjoy and Everpix.

I won't count Twitpics as it was a posting service, not a storage service, but I expect there are a few closures I've missed....

What auto-repairing filesystem do you use?

ZFS

A $500 Dell T20 Xeon has ECC memory for FreeBSD and ZFS, with room for four drives.

Let's pretend for a moment that this is even a good idea. The $500 server you mention has one (1) 1TB hard drive. Let's suppose you add another one for $75. Now you have a total of 1TB of raw space at a capital cost of $600 and unknown operating costs, let's say $160/year in electricity.

1TB of space on Google Drive is only $120/year in opex and zero capex.

True, but 1TB is probably the absolute worst spot on the capacity/price curve for a home server. For 4TB of space on a home server, your opex costs are identical ($160/yr) and your capex costs are only $120 higher. Yet 4TB on Google drive runs $480/yr. Go beyond that, and the cost delta continues to improve. That Dell server takes 4 drives for 12TB of usable space for a total capex of $1,000, and $160/yr in opex, compared to $1,440/yr in opex at Google. You break even in the first year!

There are plenty of places where self-hosting makes sense. 1TB is not one of them, but many other sizes are.

If you are price sensitive, use a Synology NAS, which has a variety of options for lower opex and capex, and mobile apps that can sync photos to your NAS.

Different people put different market values on privacy of data from 3rd-party cloud providers.

In the market segment which includes HP MicroServer and Dell T20, capex and opex can be amortized over other workloads, using virtualization for NAS VM, router VM, desktop VM, etc. People in this segment may have sunk costs in existing hard drives.

Google drive will limit when and how you can get the data out.

it will limit how you can use that space. (file size limit, etc)

it will require spyware apps to be able to upload photos