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."
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.
He said it was the recruiter's initial e-mail. If someone e-mails you out of the blue with details like that I think you're more than allowed to tell others about it.
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.
It's not clear-cut, that's for sure. I just wanted to post a different perspective.
Thing is, if you asked the sender for permission to post pieces of their email, they'd probably say no. It seems a bit gauche to say posting is okay because "nobody told me not to."
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.
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.
> I wrote the article to warn people that Comcast believes this is covered in the contract and will enforce it
But they aren't enforcing the service ___location, they're enforcing your minimum term, which is covered in the contract. You can continue to receive service at the current service ___location if you wish. Instead you're trying to terminate the contract early.
> 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.
Then what happens if someone starts a new service, Comcast pays the installation costs, and then that individual moves a month later. Comcast would be out the full cost of the installation.
Now, 36 months is absolute greed on Comcasts part, I'm sure they recoup the cost of installation after less than a year. However in principle Comcast deserve to get reimbursed for the full cost of the installation regardless of if someone moves or not.
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:
The DOM is a failed institution trying to grab on the the ledge before it falls into the abyss. W3C should be disbanded and HTML5 abandoned. JavaScript and it's ilk should be boycotted by users as well. This kind of complexity should exist on the server, not in the browser. I understand that people want to run complex apps in the browser. It's a bad idea in general but where it's needed, it should be PLATFORM DEPENDENT, implementing the tools that keep that platform safe. ie iOS, Windows, whatever. We are still in the browser wars, why are we so keen to adopt standards that aren't standard?
DOM Lvl 4 even features GC! Can we not see why this is a bad idea?!? Keyboard bindings also do not belong in a "standard". I wish this would get more attention by serious developers, but I think that most people who know better wouldn't care and aren't interested in understanding and digging into a lame standard. It's a land grab, only enterprises can and will ever be able to implement it correctly and completely, as the standard spreads to consume more of the user's space.
WTF is this? I don't even know where to begin with this crackpot of a post. You suggested nothing of value and just spout a bunch of FUD.
To your friends that agree with you from 2009, use `querySelectorAll` for a non-live NodeList, assuming he has kept up with JS actually having evolved and converging on standards.
I bet you flip your lid, too, to learn your server-side-only dystopia is running on top of JS (Node) services.
To the Hellbanned user who replied: Well look what "good enough" has brought us now on the web. Constant security issues and a outbreak of for profit blackhats.
(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.
An additional point on (2). One thing Firebug does right that neither chrome nor the built in tools does is show a decoded version of the JSON for both the send and receive sides of a connection. I love being able to click the request in the console and drill down into the JSON tree.
If you're dead set on replacing firebug with the built in tools, they need this feature!
