I disagree that the author considers "real world knowledge" the only kind of useful knowledge. If you read the preceding entry on "The Agony of Grad School" it clarifies that the main problem here is this person has a really high cost for context switching, plus a really low tolerance for distraction. That's a bad combination, because you end up thrashing all the time. In the preceding entry, he talks about how he wants to know what's going on in a theory of programming languages course (not really "real world knowledge" ;) but he can't due to the context switch overhead from real analysis.
It sounds like the author unfortunately hit a place that requires more classes and teaching before getting to the point where research becomes the full time 100% job.
It also sounds like the author was trying to take several courses and be a teaching assistant at the same time. That's a lot of work for anyone, even people who are good at multi-tasking.
From the article:
"Ph.D. students should spend most of their time doing real, publishable research alongside their professors, working as apprentices."
Most computer science PhD programs I know of have as a goal to get you to this point. Well, sometimes you end up working alongside your peers instead of seeing your professor. Different places do have different ideas about how early in grad school you finish classes and how many you need, but after that research is your full time job.
If this works out, this is a big breakthrough. One of the encryption schemes described in the paper also looks like it should be reasonably efficient to implement (the scheme "E_1"). That scheme doesn't give you everything you'd need for fully homomorphic encryption, but it is part of the way there.
"tos_msg" -- interesting that Google is picking up on TinyOS and suggesting the term accordingly. May be an indication that they weight universities highly, since TinyOS started as a university project?
I've heard many people quote Hamming about "work only on important problems," but fewer seem to notice the caveat he has in the talk:
"We didn't work on (1) time travel, (2) teleportation, and (3) antigravity. They are not important problems because we do not have an attack. It's not the consequence that makes a problem important, it is that you have a reasonable attack."
This makes the notion of "important problem" specific to you. In other words, dependent on your particular skills and interests, not on some external measure of worth. So even if you are working on something more "modest," say, what scat tells us about migration patterns of bobcats, that still counts as an "important problem" since you have an attack and can solve it.
Under this reading, Hamming's advice is close to the other famous nugget, "do only what only you can do" (Dijkstra). That is never the way I see it being used in conversation, however. Usually I see it in the context of encouraging people to work on some Big Problem that may not be a good fit for their skills and interest -- which is one of the quickest ways to encourage failure.
The "special extra credit" makes me think this question is fishing to see whether the candidate can step back and look at the big picture. That's part of the job of being in R&D, no matter where you stand on the research to development spectrum. One of the reasons companies keep R&D departments is to have people around who are technically knowledgeable _and_ who have the vision to think ahead about where the company should go next.
The fact that it's about code quality is an artifact. Yes, as others have pointed out, a question about code may not be so relevant if your candidate is a theorist or will have a role with no development. Still, because most or all candidates will have experience with bad code, and because fewer will have intimate knowledge of the business at hand, it's a better question than "so, where do you think our company should go in three to five years?"
Suggest working on how you're going to meet people now -- figure out which events you'll want to go to, which places to hang out, etc. That will help with contacts, which in turn should help with picking up consulting or a formal internship. You can then use this to help plan where you want to live and whether you need a car. Also, as pointed out in the thread, some venues are regrettably 21+.
In particular, a lot of events happen on the peninsula in the Palo Alto/Mountain View area. For example, SuperHappyDevHouse is something you probably want to attend, and it's recently been at places like Sun. While getting there by CalTrain is possible, you can't stay late without being badly stranded. So if you find yourself wanting to visit places in that area, you will want access to a car. Bringing your own is an option, there's also car sharing services like ZipCar or CityCarShare.
You might also find it fun to drop by Noisebridge, a hacker space near 16th and Mission, to see what's happening. Circuit hacking every monday!
http://www.noisebridge.net
(disclosure: I'm the secretary and a member)
Overall, you are not crazy, but do some prep work by reaching out to potential contacts, setting up meetings, and figuring out the right events now. While the Bay Area _is_ the kind of place where you can walk into a cafe, meet someone random, and then walk out with an incredible conversation that leads to your next opportunity, you will get a lot more out of your summer if you work it ahead of time. Posting here is a good start, but you probably want to do some investigation more closely targeted to your web project idea.
Oakland is a fine place to live, and I live there, but you have to watch the transit situation when living there. If you are too far from a BART or an express cross-bay bus, you will burn a lot of time waiting for bus transfers. See 511.org or Google Transit when researching potential places to live.
0) Stylish sunglasses that act like the spexware in Bruce Sterling's stories, or like the smart glasses in Charlie Stross's _Accelerando_. I'd love heads up displays showing me peoples' names, maps, appointments, and all the stuff for which I currently rely on my phone.
The hardware is there if you're willing to pay. I recently learned about research in this direction aimed at helping patients with Alzheimer's (they also use audio prompts, as well). I don't know of anyone who has packaged up everything and written software to make this seamless, easy, and fun.
I like the approach of showing the assumption that "factoring is hard" implies a statement that at first blush has nothing to do with computational difficulty. That is, the number of solutions for a particular Diophantine equation doesn't immediately look like it should have anything to do with the running time of an algorithm. Wonder if the approach could be pushed further to other areas of mathematics that are even further afield, e.g. analysis?
One neat thing about R is that it's become standard in academic statistics to include an R implementation of your new idea with a journal paper. For example, Gareth James and his colleagues came up with a new method called the Gauss-Dantzig estimator for doing prediction in the case where the number of parameters is much larger than the number of data points. You can download the R code from his research web page here:
http://www-rcf.usc.edu/~gareth/research/
This makes it much, much easier to try out new prediction methods on your own data. No more having to write code from the paper's description and hoping (praying) that you got it not entirely wrong! Instead you can use the researcher's own code to quickly figure out if the new method is better or worse than previous methods on your own data.
That being said, R does take a lot of getting used to. Graphics in general are tricky, although the ggplot2 package makes some things easier and can produce pretty results:
http://had.co.nz/ggplot2/
There also isn't a great story for using R on massive data sets which don't fit in main memory, so far as I know. It doesn't take much before you start hitting data for which an algorithm that requires O(n^2) memory will eat > 15 GB of RAM. At that point you're out of the territory of Amazon instances you can rent cheaply and into building a box just for R, or you're into refactoring your data so you can do the computation in pieces. So you do have to watch out for that a bit when using the default packages.
Responding to your footnote [2], it would be interesting to hear what obstacles are in the way of doing a start-up in India. Are they the kind of things that can be worked around once and then the effort amortized over multiple start-up companies? If so, maybe there is an opportunity for something like YC in India that guides early stage people through the hoops required to start their own companies.
So the problem is that the people on the rotations are too lazy to fill out the review forms? The problem is not that they are afraid the reviews will bite them later?
If so, sounds like you could try offering rewards of some type. What I've seen in the past is a raffle for an iPod or similar, you must enter a review to win.
Also, if the dean is really serious about wanting this feedback, then he or she could require filling out reviews as part of a successful away rotation. Suggest keeping this as a last resort, since it could lead people to resent your project. Plus then people will do the bare minimum review.
On the "attention supply side," can you do something like instead of having one big review at the end, many micro-reviews during the rotation? For example, you could ask them every day "what was the best thing about your away rotation?" or you could give them a Twitter account and show the tweets relevant to the away rotation.
So if the title of the story for the URL were more descriptive, you'd find the site stickier? Do you think this is the kind of thing that could be sent to Mechanical Turk?
For how I heard about putting it up for sale, I follow the author's twitter stream, @jstrellner. He announced that Twitturly was for sale on 17 September 2008:
http://twitter.com/jstrellner/status/925586511
Yes, I think Twitturly is interesting as well, although it has not yet made it into my list of things to check every day. It is the kind of site that might make sense to acquire.
That being said, Twitter had an opportunity to buy Twitturly recently -- the author was trying to sell the site. As I understand it none of the offers met his reserve price. So does that mean Twitter wasn't interested (or wasn't aware), that they are interested but are waiting to see if it takes off, or that the didn't have the cash at the time?
This makes it hard to build your own analytics service.
The XMPP "firehose" would help, but it is only available to specific partners, as well. While part of this is for scalability and performance, it offers Twitter a way to screen what sort of services people build on top of the data stream. So if they didn't like an analytics service as a competitor, they could just turn them off.
There's integration with gnip as well, but I don't know what the exact features or limitations it has. Again, though, that feed is controlled by Twitter, so they could perhaps direct gnip to cut off a service they don't like.
If you're curious, there are periodic discussions at the Twitter development google group on the effect of API limits. Sometimes these include ideas for reducing the number of API calls required to do something:
http://groups.google.com/group/twitter-development-talk
That being said, Twitter has enough capital to acquire companies. Summize is now search.twitter.com, for example. Would not be surprised if some of that most recent $35MM is earmarked for buying companies that provide the next "big" twitter-driven service, whether that's analytics or something else. I'd guess they would try to go that route first, rather than take the bad PR from terminating a competitor.
Do you use the same secret for each page generated? If so, checking that the hash verifies with your secret key alone does not prevent a cut and paste attack where an adversary asks for a web page with the SHA1 digest of an item worth '1.00' and then pastes that item into the web page for an item worth '19.95'. You need some additional checking that the "forSale" supplied not only was created by you, but was created by you for use in this particular page and context.
A separate issue is that using this hash(message, secret) construction has problems if the underlying hash function has chosen-prefix collisions. MD5 has this problem already. While no one knows how to generate such collisions for SHA1, the fact that its design is close to MD5 is cause for concern. In contrast, if you use HMAC, you have confidence that the data was generated by you with much weaker assumptions on the hash function. The wikipedia page for HMAC has some useful discussion here and pseudocode:
http://en.wikipedia.org/wiki/HMAC
Have had this discussion occasionally with friends of mine.Always a little confused where they are coming from, since where I sit in academia most of the innovation I see is built on open source.
In particular, open source software tools provide platforms for experimentation that would not otherwise be available. For example, the Linux and BSD kernels made it possible for operating system researchers to try out lots of different ideas on everything from security to memory management with real hardware and real workloads. Without this open source software, your options are 1) write everything yourself, 2) license a kernel from someone, or 3) go work for a company that writes a kernel (e.g. Microsoft, Wind River, Green Hills).
For another example, the Valgrind memory checking tool includes a platform for binary analysis and translation. That platform has let people innovate by building tools that run on large, real Linux programs. I know of at least two academic theses that build on Valgrind (including mine), and there's now three community-contributed data race detection tools.
Both of these areas also have closed source software with innovations, of course. Still, they seem like cases where the open source software platform has lowered the barrier to entry and made it possible for a wider range of people to contribute, therefore spurring innovation.
So I don't buy the broad claim that "open source" software fails to innovate. Maybe we could talk about more specific segments, like office software or microblogging to focus the discussion?
So the point of this post is that if the idea has zero chance of success, then you shouldn't work on it for equity. That's cool but Bill is such a caricature that the result seems obvious. Maybe a more interesting question: what bar would Bill have to cross before you would consider taking equity in whole or in part as compensation?
Would he have to show customers in the pipeline, for example? Interested in peoples' opinions and experiences recruiting others. If you were in Bill's position and convinced someone to work for equity, what put you over the top with the potential hire?
For my case, I have done a cash/equity split in cases where I know the people involved and trust their competence. I haven't pushed on the business model at that point, since I have figured that usually it's hard to predict how the market would react to a product/service at early stages.
It sounds like the author unfortunately hit a place that requires more classes and teaching before getting to the point where research becomes the full time 100% job. It also sounds like the author was trying to take several courses and be a teaching assistant at the same time. That's a lot of work for anyone, even people who are good at multi-tasking.