Neil Gershenfeld is responsible for two of the best courses at MIT: "How to Make (almost) Anything" and "The Nature of Mathematical Modeling". Neither are compatible with healthy sleep habits, but both are transformative. I took NMM and, to this day, one my biggest regrets is never taking "How to Make (almost) Anything."
It's a good point and since journalists are already asking about it, I now wish I hadn't even posted it. I think Apple is not trying to hide the fact that they are looking for search and machine learning people, but the press will surely get it wrong trying to triangulate a vague one-liner from a recruiting email.
I don't think email is considered confidential by default. Had this recruiter made any confidentiality request, I would have tried my best to honor it. Instead, he seemed more interested in spreading the word that they were entering the search game. Also, Apple has not been exactly hiding their growing interest in search. They rarely let their engineers speak in public, but they were on stage this year at Lucene Revolution giving a number of details about how they are using Solr.
FWIW, an Apple recruiter approached me about working on a new Search-related thing. He used the following enticement in the initial email: "We are building the future of search for the best user experience (unadulterated by advertising for the first time in history)." So as best I can tell, a search experience without advertising is very much on their mind.
The biggest difference is that Hound uses an inverted index to support regular expression searches. This is a technique borrowed from the original Google Code Search. The details are discussed on Russ Cox's site (http://swtch.com/~rsc/regexp/regexp4.html). With this technique, you can generally avoid even opening the vast majority of the files you are "grepping" (the number obviously depends on the pattern). To give you a sense, I just searched for a particular method name in several repositories totally several 100k of files and the search only had to open and search 9 files.
The point is that changing the service location is not covered in the contract. I wrote the article to warn people that Comcast believes this is covered in the contract and will enforce it. So we fundamentally disagree here on whether I'm changing the terms of the agreement. Maybe my expectations are misguided, but I would expect that conditions where they do not give me service and I continue to pay (especially a common one like moving an office to a non-servicable area) it would be explicitly included in the ToS. This is the reason that I think warning people is a legitimate thing to do.
Not sure if I'm answering the right question. I moved out of the service area (not realizing I was out of the area until I called). I tried to have my service moved and was told they could not give me service (because of the area). To be clear, I wanted to continue my service. What surprised me is they claim that their terms of service says that if I relocate to a non-service area, I still have to continue to pay. I've read the terms of service and cannot find this clause. I assume they are referring to one of the more general clauses in the ToS.
I'm not at liberty to give details and I know very few of them after early 2012, but this doesn't seem accurate to me. The original design of Inbox was the work of Michael Leggett (https://www.linkedin.com/in/leggett) and while the project has always targeted the power user, its evolution was not so straight-forward as this article suggests.
If you are interested in a slightly less heavy-handed approach. I wrote this to steer me away from the distractions. Just click the browser button to "block" new domains. You can unlock a page, but you only get a 5 minute window. This works well for me and most of my colleagues are using it as well.
I mean no offense to the author, but speaking of the DOM as if it is uniform in terms of performance seems silly. Pretty much every piece of API in the DOM has its own semantics and performance expectations (even if it's presented as a JavaScript property). Reading Element.offsetLeft, for instance, is a whole different world from reading Node.nodeType.
Just looking at their implementations in WebKit should tell you why:
(1) Developers do A LOT of style tweaks using the dev tools. In Chrome, this flow has gotten smoother and smoother. For example, the little of feature of having key handlers to jog numeric style properties is huge as it allows you to look at your page and not the value you are changing. Along these lines, here are some things that would go beyond what is currently offered.
- Allow me to easily get a diff of the styles that I have changed. I tweak a lot of styles and then I painfully bounce back and forth between my editor trying to make sure I have everything updated. When I forget something, it's lost. (Another angle on this would be to keep a history of the styles that were tweaked so I can get that back after refresh).
- You have the beginnings of an awesome z-index debugger with the 3d-view. Make it more interactive. I really want to see the page from the side with the z-index values somehow visible. Debugging z-index issues are a royal pain in the ass and you have a great opportunity to be awesome here.
(2) Your network level debugging needs a lot of work to even reach par with WebKit browsers. There is a great opportunity here as well. Even with the features that Chrome offers, I still resort to a debugging proxy for many tasks. Specifically, I use Charles for throttling to test timing on slow networks, replace network resources with a copy on disk (for in the field debugging), visibility into compression and a lot of cache related issues. In fact, tooling that gives visibility into caching behavior would be great. Another area lacking for browsers these days is debugging WebSocket traffic. Chrome's WebSocket visibility doesn't give me the real time visibility I need for message-style traffic.
(3) Performance visibility. I worked on the performance related tools in Chrome for a while. In fact, I landed the instrumentation that gave developers visibility into reflow/layout. I want visibility into what is going on in the browser: Reflow, compositing, parsing, HTML tokenization, image decoding, message passing queues. I want to be able to see it all.
(4) Expand Scratchpad. I basically want to be able to write a user script without ever having to install anything or open a file. Let me open the scratch pad, write some code and check "run this when example.com/ loads". I have a lot of debugging-in-the-field issues where I end up jumping through hoops to get some custom script to run at startup.
Ok, that's a quick 4 off the top of my head. Hope this helps.
from Email Landing Page:
"Increase your chances of winning the Pack Share something about us: [twitter button]"
from Front Page:
"we will randomly select 250 lucky startups that will get the Pack."
If this is not a biased random sweepstakes, I would remove that wording. I know nothing about US sweepstakes laws, but I think biased random is (at best) a gray area.
You are going to make me give away my future punchline. ;-) The short story is that innerText will include the line breaks that are introduced by text layout. A lot of people call innerText when what they actually want is textContent (which doesn't layout because is just a concatenation of the descendent text nodes)
I can relate to this during my time at MIT. It isn't that students are unaware that MIT is an immensely talented community and just fail to put their own relative difficulties into perspective. There is a strong desire to feel like you belong among your peers. Yet there is always someone doing something that seems out of your reach, which amplifies those lingering internal questions of whether your actually good enough to be there.