mfenniak

How is it monetized? The beacon is free to the business, the customer doesn't pay Facebook to view the business's page.

Except Canadians.

Unless they're NEXUS pass holding Canadians, in which case they have been fingerprinted. I just got fingerprinted this weekend for a NEXUS pass; my fingerprints are apparently "perfect". The US CBP agent taking them advised me not to take up a life of crime, as I would be caught very quickly. Or at least to wear gloves.

Totally. There's much more to the world than the US. Use your differences to your advantage -- you can be more localized.

For example, I'm working in a little niche with some US competitors. But my partners have found that being "Made in Canada" is actually helping us sell to our local Canadian small businesses. Additionally, we're going to do a French Canadian version of our app and market in Quebec -- our US competitors haven't touched multiple language support. These small differentiators will help make us a successful business; not a Google or an Apple, but, a source of revenue that we built by ourselves out of nothing.

Competition is a sign that you're on the same track others have identified as being viable. It's much better to have competition than to be all alone.

And to take this example to Spotlight, when I search for "used iPhone" with Spotlight today I get.... absolutely nothing of value. The top hit on my Mac is an Ember.js JavaScript file. Certainly not what I wanted. Paid used iPhone ads would be infinitely more valuable, as they actually have some value.

Could Apple compete with Google in search? Yes. Are they today? Not really.

Semi-monthly paydays for people on salary are pretty common. I have, in fact, never worked at a job that doesn't pay according to that schedule (in Canada).

The app can support IPv6 while not actually using it for communication. This would be a matter of allowing people to enter IPv6 addresses, websites, e-mail addresses, etc; logging, and displaying IPv6 addresses rather than hard-coding IPv4-only approaches, etc. Basically, prepare your app so that if your backend supports IPv6, your app already does.

It would be bigger news if iOS 9 required all apps to support not having access to IPv4.

Yes, it builds upon it. It's a fork with some pretty large incompatible changes, based upon this proposal: https://github.com/square/dagger/issues/366

The documentation seems to still be in-flux, but there's some information about migration here: https://google.github.io/dagger/dagger-1-migration.html

Huh. Localize.js sounds really cool. Fantastic idea.

Can you explain your example a little more? What would translators see in this case for Arabic; would they need to provide three translations? And if there were two variables, nine translations?

"Localization" also implies a lot more than just translation. Does Localize.js handle work like culture-specific number and date formatting? Different collation of records for different languages? How does it identify application-generated text versus user data (eg. on a blog, does it translate blog comments entered by readers, or just text like "Please enter a comment below")?

There are a few posts on the pgsql-hackers mailing list that have some more detailed information, for anyone interested in reading more about the approach taken: http://www.postgresql.org/message-id/5CFE0CA1-E5CC-4CD1-9D0B...

I think this is a fascinating approach to improving query speed. It certainly won't be applicable to every use-case, but it seems like there's a lot of value in it.

Oh, weird in what way? I was considering using it for horizontal redis scaling recently, under the impression that redis cluster was further away from release than it seems to be.

I have very little evidence to support this, but they probably use twemproxy. twemproxy is a proxy for redis that automatically manages routing commands to multiple redis servers efficiently.

They definitely don't use redis cluster, because redis cluster requires explicit client-side support. That support is only available in a limited number of clients today.

I would've thought the opposite. The default subs have large numbers of subscribers (of course), but I feel like they don't have strong communities, or specific themes, that would appeal to an advertiser. Like... /r/funny? /r/creepy? /r/DIY? /r/IAmA? What would compel someone to advertise on those?

On the other hand, there are a good number of non-default subs that have strong themes that I'm certain advertisers would want to tap into. For example, city-specific subs, or /r/bodyweightfitness (105,212 subscribers), or /r/bicycling (126,713 subscribers). These communities are so specific that advertising seems like it would be more effective in those areas than any other. Of course... it needs to be done in a way that isn't intrusive or damaging, and that's probably a bigger challenge in a smaller community.

The human skull does seem like a solid symbol of death, but that doesn't prevent us from turning something like the Catacombs of Paris into a tourist ground (http://en.wikipedia.org/wiki/Catacombs_of_Paris). The intent here seems to require more than just a symbol of death.

Rejecting an improvement because it's just "too much code" is... brilliant, disciplined, and extremely difficult to do. Such a high percentage of software development is maintenance, and it's easy to underestimate that long-term maintenance cost.

Hm... I've been quite happy using an Open Source tool called FreeMind. It seems to be a "tree editor", although I'm not sure it quite satisfies what this author is looking for.

Screenshot: http://freemind.sourceforge.net/wiki/index.php/File:FreeMind...

Website: http://freemind.sourceforge.net/wiki/index.php/Main_Page

It's actually worse than this when you consider that aircraft become more fuel efficient the longer they fly, because they're not carrying around the fuel they've already burnt. An electric aircraft would presumably have a constant weight (stuff + batteries).

I've heard good things about Apigee. My understanding is that their backend-as-a-service is built upon the acquired and open-sourced usergrid technology, which leaves you the option of hosting it yourself in the event they ever go ahead and terminate their own service. That's not a bad out to have.

> Foreign keys don't need indexes on the from side

Yes, they're not a hard requirement. However, be aware that any field with a foreign key constraint will be searched during a DELETE that affects the related table, to check RESTRICT DELETE or CASCADE DELETE constraints. It can be very beneficial to performance to have an index on that field for those internal database searches.

The same is true for an UPDATE that affects the PK, but that's relatively rare if you're using surrogate primary keys.

Amazon success is a strong indicator: RESTful APIs don't really matter. You can build a very successful business without focusing on the format of your APIs, as long as you build something valuable.

There are a few advantages to being completely managed, rather than using native code. Portability (eg. mobile devices, different OSes), and functional code access security are two reasons that come to mind for me.

Go errors are machine-readable data.

Most modules expose variables with the naming convention Err... that represent the errors that they can return. The errors can be compared with those values (eg. err == os.ErrPermission). Some modules also define error types that provide additional error data, such as net.OpError; a type-cast can be used to check if the error is of that type, and then access the data within. As a fallback, all errors implement the Error interface which allows you to display them as a string if you can't handle them based upon their type.

It's not unlike exception handling by exception type, although it's definitely more of a manual process because Go doesn't give you specialized syntax for it.

Hm, "signing up" by providing read-only OAuth access to my GitHub account is... fascinating. :-)

Very clever way to make signups easy, relevant to the interest you're trying to gauge, and gather far more information about me than just my e-mail address (eg. my activity level on GitHub, the type of projects I'm involved in).

Well, how would you feel if your death on a plane crash was actually the responsibility of an Air Traffic Controller on the ground, and not the pilot of your aircraft (who also may or may not have perished)? Seems like you could already be in this situation, as there have been some very serious accidents caused by ATC error.

That is a pretty steep rate, but I figure you'd treat their storage like an "INBOX" and grab images through the API and put it into your own persistent storage. So, the 5GB free component should probably cover a good number of use-cases.

Reliable Pricing: Send pictures for 2¢/message and receive pictures for just 1¢/message.

Storage: Store 5GB of pictures you send and receive for free, then just 20¢ per additional GB.

I believe the fear here is that if you can guess URLs, and one of those URLs works and provides you with a script that contains an API key, you could use that API key to perform other, non-Longview-related API calls to Linode's management API.

That's a pretty decent fear. I don't know if there's any other controls on the API key that prevent it from being as vulnerable as this suggests...

A decent approach to doing this in the Windows world would be to use PsExec.exe (http://technet.microsoft.com/en-ca/sysinternals/bb897553.asp...).

Absolutely agree, I have dozens of unopened e-mails right now because I'm saving them for the weekend (and it's only Wednesday). I think that just highlights how Jaana felt that her launch had failed, even though it was completely illogical at that point. :-)

It looks like someone is working on building a service provider for RethinkDB: https://www.rethinkdbcloud.com/

I think the answer is yes, it performs the calls asynchronously. I've been searching through the source code for the postgres module (https://github.com/FRiCKLE/ngx_postgres), and it appears to use the libpq asynchronous API (http://www.postgresql.org/docs/9.2/static/libpq-async.html).

Of course, one could easily use the async API in a non-async manner, so I'm not 100% certain.