underscore

The paper is here, I think: http://ftp.cse.sc.edu/reports/drafts/2010-002-tpms.pdf

(I didn't see a link in the article)

I assume that your centralized repository of (email, id, provider) tuples wouldn't just spill out all of its contents to the world, preventing mass email harvesting. Instead, it would reply with the appropriate (email, id, provider) tuple when asked for an email (hashed or not) that it knows about, and return nothing or an error or whatever when asked about an email that it doesn't know about. In either case, as arethuza points about elsewhere in this thread, it is essentially an email address validity oracle for emails that it knows about -- hashed or not -- since a spammer can sit there all day and ask it about random email addresses and record its responses. If you hash an email address, the only thing you buy is to make the spammer add a line of code to their script. In short, I think that using a hash is functionally equivalent to not using a hash, at least for spam purposes. What do you think?

(note that a partial email validity oracle isn't necessarily a deal killer; PGP/GPG keyservers, for example, are partial email validity oracles, and have not only existed for years but have also gained acceptance amongst (some of) the security conscious and the paranoid)

(also note that a hash would be a safeguard (whose effectiveness is dependent on how resistant the hash function is to first preimage attacks and other factors) against disclosure following a compromise of the central database/authority, in addition to its questionable utility at fighting spam in normal situations)

I like the protocol-agnostic (and locally-stored) connection information, but I don't like the fact that I (I'm assuming) have to manually synchronize them between my devices -- if I understand right, if I friended someone on my phone, I'd have to somehow synchronize that information to my laptop if I wanted to use it there. Probably the provider would keep that information locally, and then prompt my browser to accept a new copy -- I know I wouldn't want to deal with anything much more fiddly than that. Is there a compelling reason to have that (edit: where "that" is the connection information stored in the browser, as suggested in the article when I wrote this) instead of a defined-in-the-protocol way of on-demand data export?

I guess the hash is just to fool spammers? It seems to add a fair amount of complication to the protocol to address just that one use case.

How do you define privacy? How does your protocol protect it?

edit: clarify clumsy wording

I think there's value in documenting and discussing this sort of thing.

If it won't always happen (or will always happen but is one of those things that earns a degree of passive (or active, depending on the example) condemnation when it does) and people don't like it, the discussion might bring about change. If it will always happen, or even if Tech NY doesn't change, it might still help the reader better understand the context, be it the NYC startup scene, their own tendencies and "tribes", or something else.

I'm not really familiar enough with the subject to know whether I should be. If there are any serious studies out there about gender and code quality, I'd love to read them. While gender itself may well be irrelevant when it comes to programming aptitude, the way that a society treats girls and women (and the fact that it may be (is, for mine) different than the way it treats boys and men) could influence how many/which women go into the world of programming, which might in turn influence the quality of what they produce.

I can't remember ever meeting a female programmer that I didn't later come to respect for their skill. Anecdotal evidence isn't really useful, though.

edit: Good point. I guess that if a correlation may exist for women by this logic, it may well also exist for non-mainstream sexual orientations.

I'm a gay programmer, and I'm not quite sure how my sexual orientation would affect how I code. If it is any help, most of the people around me seem to think I'm competent enough, at least to the point that they don't complain about what I write to my face. Perhaps they'll find this thread and respond.

The more interesting question, at least to me, would be about the experiences of gay programmers (I guess I'm biased). I can't speak for all gay programmers, but I know that my sexual orientation would certainly affect the people I choose to work for (e.g.: I'd like to work for someone who provided benefits for a same-sex partner, or who donated money to gay rights causes, while I'd probably not ever work for a company with a history of opposing (with policies or money) gay rights). It probably also affects the atmosphere of the place that I do work: perhaps co-workers deal with a gay colleague differently (not necessarily on a good/bad continuum: only differently) than they would a straight colleague. I could go on, but you probably get the idea.

Most of the replies present when I started this comment were skeptical of the possibility of a correlation between sexual orientation and code quality. I happen to agree. What about the correlation between sexual orientation and employment in certain industries (affecting what code we write)? What about sexual orientation and choosing to be a programmer at all?

I'm kind of hoping that this doesn't get downvoted to oblivion: it might make for an interesting discussion (or flame war).

The actual report is here: http://cups.cs.cmu.edu/soups/2008/proceedings/p117Falk.pdf

I wonder what sort of attack they had in mind to exploit the fact that contact information and security advice was on an insecure page? A man in the middle attack is what came to my mind, but it is early, and I may be missing something obvious. I skimmed the paper, but didn't see any specifics.

I'd think BofA were a lot cooler if they gave me the option to upload a PGP key, and then used it to encrypt any emails that they send my way. It'd solve the snooping email server admin problem, and, assuming that they signed their messages and kept their private key safe, would make it a lot easier to spot phishing. I guess there's not enough demand for that, though.

First: congratulations on getting far enough to feel comfortable sharing your work with us.

What sort of requirements do you have for email addresses? In help (/help.php) you say that users need an email address, but don't really go into specifics, which is fine. However, one of mine (message me outside the thread if you want specifics, I guess) failed as invalid when I tried to register.

The privacy policy (/privacy.php) mentions that users are encouraged to provide a corporate email address and (or?) linkedIn profile for verification. I didn't see any way to provide this when registering, nor do I see any way to provide this when I go to write a review. If you require this later (e.g., after I attempt to submit my review), it might be nice to say so somewhere. If not, it might be nice to remove that line from the privacy policy, at least until you add that bit of functionality, as it seems a trifle confusing, at least to me.

You're probably planning this already, but some sort of information on the number of reviews for a company in your company list would be nice (or a way to filter out companies that don't have any reviews).

Do you plan on encouraging users to give an overall rating in some easily displayed/read format for their employer (e.g.: the stars of coderific)? Most of the content, of course, is in the text, but I find myself missing the summary stars/number when skimming.

I do swear in code occasionally. If the cheap laugh is enough to make me realize that I need to step away from the computer and think about what is making me want to swear at it (stopping me from writing desperation code that breaks stuff and will get deleted later), then it is worthwhile, I think.

What are your feelings as a beginner in each language? Have you found any little design decisions that leave you scratching your head, or make you start cursing loudly at the computer? Have you built anything with them? If so, did you run into any issues that you feel were a result of the language?

I'm a bit of a hedonist, but if I were in your situation, I'd probably try to pick the one that was the most fun to work with. As you say, once you've started building, it won't be (or maybe for you it will be?) as easy to switch, and you probably don't want to figure out that you hate coding in whatever you've chosen while trying to finish your web app.

When in a variant of your situation (PHP/a PHP framework versus Python/Django), I chose Python. I'm not you, so we may have totally different tastes and may have come to a different conclusion given the facts. I've been pretty happy with my choice, though.

I think it is what you make of it (or, as you say, it is largely dependent on the kind of person you are, and your actions).

I don't doubt that there are lonely programmers. I think that you'd probably find lonely people for any X that people choose as a major pursuit in their life, though. I think that many (certainly most of the folks I know) programmers are programmers because of the fascination/cool factor/feeling of relative omnipotence/etc that comes along with creating and controlling processes that do cool things (whether for you or for millions of your friends). Within that, there's still a lot of diversity.

Also, you don't need to have a homogenous social circle if you don't want to.

I think the answer kind of depends on the nature of the project.

Re-writing something you have now in another language/framework can be (in addition to fun) a great way to learn the new language/framework. If this is just a fun project, well, cool - best of luck to you. If this is a business, something that you'd like to start making money (or at least getting press) from, then maybe the delay will hurt you more than the fun will help you.

In my case, the website was the online component of a small university department. I inherited a PHP codebase that worked, but that I really didn't like, and opted to re-write it in Python/Django. I'm really happy with the decision: I think it was a great way to learn the framework, and the result is a lot better than the PHP site that it replaced, but I don't think I would have done it if I hadn't had a working PHP site to placate students while I was working on it.

Good luck with whatever route you choose to go.

FreeBSD (6.3) on one, OpenBSD on another.

Both choices were made mostly for the fact that I'm familiar with them, and they seem trustworthy (reliable, lacking gaping security holes out of the box, though I'd hope the latter is the case for most Linux distros as well). While I'd probably enjoy spending time improving my sysadmin-fu, it wouldn't have been a wise way to spend time for either of these projects.