mcgwiz

Use the widest established terms possible: "tap", and "tap and hold".

1. Observe that the feedback bar above the blue area is orange.

2. Tap and hold the blue area.

3. While still holding, tap and hold a different part of the blue area with a second finger.

4. Observe that the feedback bar is now green.

5. While still holding with the first finger, stop holding with the second finger.

6. Observe that the feedback bar is now orange.

7. While still holding with the first finger, again tap and hold a different part of the blue area with the second finger.

8. It is expected that the feedback bar be green at this point. However observe the feedback bar actually remains orange.

The thing they will (should) appreciate the most, and the thing that will keep the bridge most intact after leaving, is to be generous in the advancement of your notice. This honors the trust they put in you as an employee with significant responsibilities by affording them the valuable time to absorb the impact to their company in a managed way. Since two weeks is customary, something on the order of 4 weeks would be in good faith of the trust between you.

Some might say by giving extra notice you risk "showing your hand" and being fired prematurely. However, if you have a good personal relationship, this is unlikely to happen.

I haven't used browserify so I may be wrong, but because browserify is not AMD compatible and depends on a build step, the advantage of RequireJS appears to be slightly faster/simpler (or just different) development experience.

It looks like with browserify you only ever reference a single script file in your HTML, regardless of development or production environments. While this unifies HTML rendering across development and production environments, during development every time you change a module you must rebuild that script file. In actuality, this is not much of a problem since browserify appears to have a "watch" mode to do this automatically. If you have a huge codebase, building could take a noticeable amount of time.

With RequireJS, this build step is not needed during development. When you save module changes and reload your browser (with caching disabled), the changed module will be delivered. If you have a huge codebase, no time-consuming build step is required. Of course in production you want to deliver only a single file, and RequireJS can be used to build this. However, depending on your overall build, you may need to conditionally render different script tags for production and development, which is a tiny but not insignificant bit of complexity.

To allow RequireJS to load node (CommonJS-based) modules the module needs to be wrapped in a special function call. RequireJS supplies tooling to help with this. Alternatively, RequireJS can be used in node to load AMD modules, to allow modules to be used client- and server-side.

If you have a small codebase and use the same modules in node and in the browser, browserify seems to be the way to go. For large codebases, browserify is only an option if you have lots of modules being used in node and in the browser and find RequireJS' tooling inadequate. Otherwise, RequireJS' flexibility seems to make it the preference.

I wonder how much money they burned to get that domain name. Overall, this seems to be a production that feels much glossier and slicker than other technology "debuts". Is this the new way to launch a technology? Razzle and dazzle the programmer into the latest cargo cult... :/

My workaround, whenever I can't tether to my mobile phone and must use an untrusted hotspot, is to route all traffic over OpenVPN to the server running in my home.

Is that with your entire working data set loaded in memory?

Most of your issues are addressed by the Base Class Library (BCL), which is provided by the runtime itself. You cannot use C# without the BCL, so why evaluate it without the BCL? How do the following sit with you?

- Events, i.e. the observer pattern, are indeed supported first class by way of the `event` keyword and BCL `Delegate` type. And the whole point of properties is to be syntactic sugar to hide implementation details by surfacing state accessors with field-like mechanics. If you need a quick and easy way to reference a "getter method", you're breaking the abstraction and shouldn't use properties. That's the trade off.

- The BCL provides multiple generic, high-performance `Tuple` types.

- Destructing. Memory management is handled by the GC, so what would destructing even mean? The `using` keyword along with BCL type `IDisposable` provides a very usable mechanism for releasing non-memory/unmanaged/OS resources.

- This is mostly valid. That said, `ICloneable` can get you most of the way w.r.t. the copy ctor. As far as the numeric generic, one is required to make do with type-specificity and method overrides, since the numeric types were written without generics in mind. Or you can implement your own numeric type system. Do that once and you can write numeric generics to your heart's desire.

- How could this work with auto-properties?

- Trivial to implement a `NonNull<T> where T : class`. But because of other language constructs (`??` operator) idiomatically `null` references are not considered the end of the world. Design by contract support in the BCL `Contract` type alleviates this as well.

edit: expanded property method explanation.

The submitted link goes to the second page of the article. Here's the first page: http://venturebeat.com/2012/02/27/a-classic-startup-horror-s...

The long term effect would be that websites can no longer use referrer as a metric. What difference would that make? HTTP resources (webpages) shouldn't change semantic meaning depending on the referrer anyway. Doing so is arguably an unintended use (or abuse) of HTTP.

It all depends on how you look at the overall system Google has created. If one considers the entirety of Google+ to be a mere component of Google Search (like the now-extinct Friends section of Netflix was), then one can better reconcile this situation with supposed fairness. After all, what's to stop Bing or Yahoo from creating a social component to their products which affect search?

So the issue in is not one of ethics, but of how Google is marketing Google+. When all that existed was the +1 button, no one complained about ethics. Nothing has changed since then except a reworking of the information architecture of the same +1 data and processes. Google seems to believe that Google+ needs to exist independently of Search. If they're gonna stick with that route, they need to open the Search platform to 3rd party integration.

Out of desperation, Google's gone evil. For all of the shady things that Google had done in the past that people said were evil, nothing approaches the infection of their search service with Google+ rankings. Google had always largely maintained the integrity of their search product which, despite minor adulterations added over the years, was still essentially based on little more than a strict, normative interpretation of the HTTP and HTML standards. By doing so, they maintained the integrity of the company itself. The standards now take a back seat to Google+.

The author is spot on about this. It's evil. In my estimation, it's disrespectful to users. And it therefore creates a huge opportunity for Bing, et al. What remains to be seen is whether, on balance, this degradation of the search service is significant enough to drive away a substantial number of users.

To generalize this to other industries, the subsidy model I detailed can be described simply as offering reduced service quality at a reduced cost. This is a universal strategy of marketing.

I'm unaware of any ISP offering priority transport in any form, including the consumer subsidy model I've described above. But if regulations were put in place, it would be illegal even to experiment with business models such as this.

There are other possibile outcomes to tiered access that are not being discussed. Offering tiered service to content publishers does not mean that traffic from those publishers must be prioritized for all consumers. Specifically, tiered publisher access can subsidize a new level of "subsidized" internet service, with price Y that is lower than the "neutral service" price X. More households will be able to access the internet as a result. Those households that prefer to continue receiving all publisher content in a "neutral" way may continue to do so (at the same price X).

Creative consumer education (as implied by Ofcom) can assist in this. ISPs are incentivized to do this because they can reach more consumers this way, ultimately increasing their bottom line. ISPs that do not pair prioritized publisher service with subsidized consumer service (as described above) will whither in the face of competition from ISPs that do.

Regulation cannot be considered without acknowledgement of the potential to stifle innovation in the internet service business and related technologies.

A better title might be "simplicity is used as an excuse for creating worthless software."

But anyway, Spolksy basically advocates finding the "elegant" solution, which is the one that incorporates useful features in an easy-to-use way. Hardly a controversial position. However his use of the word "simple" consistently conflates feature-poorness (lack of features) with ease-of-use. So when he says focusing on simplicity results in worthless software (as indicated by actual sales), he appears to attack ease-of-use. He's not. He's only attack feature-poorness. Cue confusion and controversy.

This was implied by Duff's use of the word "necessary" [sic]. I believe his point was that it's possible to have features and complexity.

So although you're right that providing both simplicity and feature-richness is not free, the companies that can afford both (assuming the features address actual problems, or even just pain points, that customers have) are going to fare better than those that don't.