vijayaggarwal

> In a circular linked lists you can have easy access to end of the list.

This is not true for circular linked lists in general. A few special cases where this is true:

1. If the list is doubly linked.

2. If the list maintains pointers to both head and tail nodes (trivial).

3. If the list maintains a single pointer but uses it to refer to the tail node instead of the head node. Head node can then be easily reached as tail->next.

Of course, data structures can be tweaked in innumerable ways to add special properties. So one cannot possibly list all ways of adding easy tail-node-access to circular linked lists.

Whoa, did Super Mario Bros have a palette of just four colors? Amazing!

Around 8 years ago (the age of Google), perpetual beta was in vogue. So, the answer would have been always. These days (the age of iPhone, since iPhone is largely responsible for raising the bar of UX very high), we hardly see a public beta. So, I guess you should be in (private) beta to collect some feedback and then quickly act on it with the aim of making a public launch without the beta tag.

Read about the life and works of Alan Turing [1]. Not only did he do seminal work for invention of general purpose computer, he actually went on to study the limitations of this theoretical computer even before it became a practical reality. Every time you see a captcha, recall that CAPTCHA = Completely Automated Public Turing test to tell Computers and Humans Apart.

[1]: http://en.wikipedia.org/wiki/Alan_Turing

Once, during an interview, the interviewer started asking me solutions to very real-world problems which I could immediately understand they must have been facing at that time. A high level discussion was fine to judge my ability, but he started getting deep into the implementation details. I got the sense that he is trying to get a solution to his problem in the pretext of interview. I gave him the solutions as I would have anyway done so had anybody asked for help. I have since then thought many times but could not decide if it was unethical or just a harmless stroke of creativity.

OPs case certainly seems to have cross the limit of ethics though.

Google has been adding lots of widgets to email recently, like RSVP on invitations, itinerary on flight booking emails, etc. These are pretty useful features and I believe a lot more are possible with the APIs being opened.

However, I feel the access control is very coarse grained. For example, RSVP widget needs access to only event related emails and itinerary needs only travel booking emails, but the API spec does not allow for such fine grained control.

IMO, given that google is able bucket-ize emails into travel booking, event, etc., and even user-defined labels for any custom grouping, allowing access on such buckets would be nearly as useful and much more user-privacy friendly. For example, an accounting app could still access invoices from my inbox to update my accounts automatically. Google could even push for microformats kind of annotation to make emails semantically richer.

According to RFC 2617[1], Both Digest and Basic Authentication are very much on the weak end of the security strength spectrum.

[1]: http://tools.ietf.org/html/rfc2617#section-4.4

Thanks! MongoDB and NodeJS are fairly big projects and take some experience to fully appreciate. Even Angular vs Ember is not a trivial decision and its better to have some experience with both. I agree with czbond's suggestion of starting with smaller projects. It will also reduce abandonware risk.

Again, I don't know much about Express though microframework seems to be the right term to me. Hopefully, other community members will shed some light on this. Regarding MongoDB, an ORM is technically not needed as mongo is not relational. In fact, mongo treates its records as first class JSON objects and therefore is very object-oriented natively.

Oh yes, I also used to make casual games in flash for social platforms like facebook back in 2009. These days it's OpenGL and mobile. The market size is bigger and user experience better. Btw, 5m accounts in three months despite so many launch issues is not bad.

Since there are a lot of components involved, let's consider them separately instead of discussing the bundle as a whole. This also helps as M-E-A-N are very independent by design and can be used independently. In fact, we are currently using AngularJS at frontend and PHP at backend.

MongoDB: is a NoSQL database designed for handling huge amounts of non-relational data. In comparison, MySQL excels at handling relational data but does not scale as well. If you need a lot of joins (relationships, user roles, etc.) then MySQL will be better and if you can benefit from the ability to keep arbitrary columns in your database tables without the need for running ALTER commands or other database hacks (CMS fits very well as most CMSs hack MySQL a lt to get the fleibility they need) then MongoDB will suit better.

ExpressJS: is akin to Django. While I am not experienced with ExpressJS, it seems more oriented towards single-page apps. Django has some good support for templating which comes in very handy for traditional websites. Single page apps don't fetch a lot of HTML from backend anyway, so this capability is not of much use.

AngularJS: has no direct counterpart in LAMP stack with Django. Angular is a frontend framework used for building single page apps. In fact, if you are building a single page app, you would want to use a frontend framework like Angular or Ember even if you use Python/Django/MySQL at backend. As mentioned earlier, we have recently built a single page web app with Angular at frontend and LAMP(PHP) at backend.

Node.js: is actually (to some extent) a counterpart of apache server and not python or django. nodejs is a performance oriented server with asynchronism at its core. While it is definitely desirable for high workload applications, it does take some getting used to. For example, even though you I was quite comfortable with AJAX at frontend, writing database queries in an asynchronous mode felt quite unnatural at first.

Overall, depending on the kind of application to develop and the kind of time luxury to learn new things, you may want to adopt MEAN partially if not fully. If constraints permit, spending some time with M/E/A/N should be intellectually and professionally rewarding.

Disclaimer: I work for Visual Website Optimizer (VWO). Still, I will try to be as neutral as possible.

> Bandit tests allow you to run as many variations at the same time as you want, versus A/B testing, which you limits to two.

True that the phrase A/B Testing in a strict sense considers only two variations, but almost all tools allow something called A/B/n Testing which allows for multiple variations. The mathematical foundations of A/B/n testing are as well established as that of A/B testing.

> But there's a deeper, less obvious benefit. Had we run these social button variations as a series of A/B tests, we'd be at much greater risk of reaching a local maxima. That is, the odds of us missing the best performing variation in favor of one that's merely adequate would be higher.

Again, there is another concept called Multivariate Testing to be used for testing multiple changes per page. MVT is also offered by many online A/B testing tools. Again, the theoretical foundation is very well established.

> So I'd have to be on top of my game to make the code-changes as soon as the Chi Squared value was high enough.

Good A/B testing services do this automatically for you. Losing variations are automatically stopped and winning variations are automatically given 100% traffic. Of course, you have a choice to enable/disable this behavior.

> there's nothing stopping you from tuning a bandit test to behave exactly like an A/B test.

Yes of course. Because multi-armed bandit (MAB) is another strategy of running A/B tests (more generally A/B/n tests, even more generally multivariate tests). So, technically, you can't beat A/B tests with MAB as your article's headline suggests, because MAB is itself a strategy of running A/B tests. What you can try to beat is classical strategy used by most tools today. Here, the post by VWO linked in your article clearly details the pros and cons of both approaches and establishes why a head to head comparison is, in fact, inappropriate.

> ...the critique is utterly ridiculous

As this point talks direct about VWO, I would take a break from my attempt at neutrality. tuning a bandit test to behave exactly like an A/B test was not the point of our article, and it is not the point of your article either. We have both attempted to compare the two approaches (MAB vs classical) to A/B testing. I do not mind your criticizing our article, but it would only be appropriate to substantiate your criticism with facts. Criticism without facts does not help the cause of discourse. I am fairly well versed with the theory of A/B testing and happy to take any questions here.

> http://domains.google.com

> http://domains.google.com/

> https://domains.google.com/

> http://domains.google.com/about/

> https://domains.google.com/about/

> https://domains.google.com/about//

Seems like HN should add a few lines of code to its duplicate url check.

In my original comment, I was not talking about poor service experience of domain name registrars. I was instead talking about the difficulty faced by an average SME owner in setting up DNS to point a domain to a hosted website. Visual website builders allow them to build decent websites without understanding a word of HTML. But when it comes to pointing their websites to chosen domain names, they have to get into DNS settings interfaces of their respective domain registrars and deal directly with terms like IP address, A-record, CNAME, MX, etc. While google does offer instructions for major registrars, it would be much better experience for these people if google does the domain mapping itself instead of them having to read through technical guides to do things they don't quite understand.

Here in India, and probably in other developing countries too, google is making efforts to get small and medium businesses online. While it has offered easy website creators, the hassles of purchasing a domain name make the task difficult. This service will probably be used for offer integrated website creation service. Of course, these websites will then be potential customers of AdWords.

Particularly interesting for game developers who can use it deeply customize maps to fit well into their gaming experience. I am tempted to build a monopoly-like game with the real world up for sale and purchase. And one like Need for Speed with real-world traffic. Even one for amateur marathon runs on countryside terrains.

There are so may factors at play in determining the amount of gain from using such a service, e.g.,

1. How widespread the usage is. The more widespread it is, the better the chance of finding the resource in the browser cache itself, instead of having to make external request.

2. Geo distribution of resource by the CDN. The closer the nearest CDN server to the end user, the quicker the delivery.

3. Popularity of CDN domain used to serve the resource. Since a DNS request is potentially involved in fetching the resource, the domain name should be widely used to keep the DNS cachces warmed up.

I am especially skeptical towards adding DNS calls to my page. One for HTML and one-two for static resources is what I have seen works best in practice, especially with modern browsers that do not have the two parallel downloads per domain limit.

[Edit]: added comment on Mozilla Persona.

I would disagree. It's common knowledge (backed by many A/B tests) that shorter sign-up forms see less traffic drop. So, if OAuth can replace a number of things (name, email, password, email verification, and so on) by a couple of clicks, I as a website owner will be very happy. Also, when sending interesting emails to inactive users, I see quite a few come back but drop again after a few unsuccessful login attempts. Again, OAuth will help.

The reasons website owners (at least I) don't use facebook or google's OAuth are following:

1. They brand their service too much. The button itself says Login with Facebook/Google. I don't want my users' mind share to be consumed by them. Everything from login/logout to account management happens on pages in the context of their brand. Browser/OS providing this service is much less problematic, and even they should have pluggable services for replacing their default implementations, just like the ability to change the default browser on any OS.

2. They own the data and not the user. I have faced an incident in the past where one of my games was blocked by facebook because they thought it was gambling. I lost 95% of my users in one stroke. It took me two weeks haggling with FB to get my game whitelisted again. Still, the damage was done and we could never fully recover. The data must be owned by the end user and stored in open format so that user can take it freely from one place to another, just like I can take my contacts in vCard format to wherever I like.

3. Any such solution (especially when so heavily branded) will naturally turn other big players hostile. for example, facebook and google will have their own separate implementations instead of having a common one. This will almost ensure that standardization will hot take place. One button each for signup with Facebok/Google/LinkedIn/OpenID/... doesn't make for great UX and it's unnecessary overhead for website owners.

Mozilla persona is a good initiative. Hope they prefer standardization over trying to use it to promote their own browser.

FxA is primarily for Firefox's own products and services. Mozilla Persona (confusing name - personas is what they called firefox themes as well) is closer.

We already have a fairly good solution to this problem in OAuth. However, current popular implementations of OAuth are third-party owned which is not desirable for many reasons (for example, google won't use facebook owned OAuth, and vice-versa).

Ideally, we should have a self-owned OAuth service implemented by browsers or operating systems. And the APIs of this service should be standardized. Also, the storage should be locally available with remote sync optionally available for backup and cross-device syncing.

You can still do Integration Testing with the system as a whole, although it is supposed to be done after Unit Testing. The disadvantage due to absence of Unit Testing will be that it will be difficult it isolate bugs found during Integration Testing. For websites, we use Selenium all the time.

It depends a great deal on what's your near-term and long-term professional goal. The first one will advance your career in engineering, and the second one will further you on the path of entrepreneurship. That said, these two paths are not so far apart that you cannot switch from one to the other later on in life. In fact, you easily can.

If you are not very clear of your medium-term/long-term goal, let me invoke Jobs' advice[1] that you should follow your heart and let the dots connect backwards.

[1]: http://news.stanford.edu/news/2005/june15/jobs-061505.html

I want to build a variant of TypeScript for a personal project. This seems pretty useful for that.

Big retail chains in India are finding it difficult to compete with mom-and-pop stores primarily because of two reasons - 1) mom-and-pop stores operate at very low profit margins, and 2) weak taxation enforcement for small business owners.

Big businesses have much more potential in disrupting wholesale space as that is very fragmented and therefore inefficient in India.

Good share. I've been part of multiple scrum environments and I've always found daily meetings to last much longer than they should. Did you face this problem? If yes, how did you solve it?

I listen to Vedic chanting. Even though I understand nothing (I know very little of Sanskrit language), the music itself is very relaxing and helps concentrate.

I've seen both sides of the story - both successful and unsuccessful. Following are some points that distinguish between the two:

1. Keyword research: understand the search volume and competition level for each target keyword before you start your campaigns. Having an estimate of CPC before you start is critical to right planning. If you operate in an industry where search volumes are less and/or competition is high, you should perhaps not depend on search engine are your primary traffic source.

2. Contextual relevancy of keywords: the more relevant the keyword is, the lesser price you pay as you drive more CTR. Google charges lower CPC for higher CTR ads. SEO directly helps SEM.

3. Catchy headlines, good description: ad making is an art. Even text ads. Test multiple copies for each keyword group and see which one does best. See if having FREE in the heading helps, try adding phone number, etc. Again higher CTR implies lower CPC.

I've seen many things in my 10+ years of coding, Here are some favourites:

* No authentication check on any page after login page. (You could type in any URL in browser address bar and gain access).

* GET request updating home page related content in database. (A few of these GET request was picked up by Alexa bot and we hard our home page content change randomly for many days. We had a real hard time troubleshooting this one).

* Use of mysql_query() in PHP. (Deprecated mote than 10 years ago. Opens doors for SQL injection).

* Use of loop variables i,j,k,l,m for 5-level nested loop. (Too error prone and difficult to read).

* Unit testing applied to a highly monolithic code. (The hacks for isolating code units produced more garbage than the code itself). It was a legacy code and the management blindly ordered writing of unit tests when a few bugs were caught in production.

Here's what I had in mind. Let's say class S is subclass of class C. Now,

var myVariable = S()

when changed to

var myVariable = C()

will not cause any compiler error in rest of the code. Still, it may be a logical requirement for myVariable to hold instances of type S only. Yes, the programmer can explicitly declare type if s/he wants to, but I guess apple APIs will promote the culture of using type inference. Though hopefully apple will set the best tone possible of swift coding style in their APIs.

> Please keep in mind that we will be able to link the content back to your account, in cases of spam, harassment and such.

And on request by The NSA.

Explicit optionals are great. But I feel some of the other convenience features like type inference, trailing closures, different copy behavior of arrays, and operator overloading have the potential of being abused to produce cryptic code. What's your opinion?