While that certainly does seem appealing, zombie projects can have serious impact elsewhere in the company. For instance, if a security bug is found in some piece of common infrastructure, you'll have to pull the update and deploy the new code. Seems simple, but in the months or years since the last deploy, many other pieces of infrastructure have changed and now you have to integrate, test and safely deploy a product for which nobody is familiar.
This is not just speculation, either. The project I worked on at Google had to deal with such zombie products all the time, and they were a HUGE drain on productivity for us.
There's also the whole problem where there is no love for maintenance work, and you have to create massive new systems to get anywhere. This biases things towards creation, deployment, and then flying the coop. The zombie projects which follow are inevitable.
The whole thing about "the one which is deprecated and the one which isn't ready yet" is rooted in reality.
You really think it takes 1 person to maintain iGoogle? In a corporate environment with so many users, business rules and systems/infrastructure I'd imagine it is quite a few.
No way. I'd be exceptionally surprised if more than one developer is dedicated to it. All the components inside iGoogle are already supported by their respective teams. News, Calendar, Finance -- in iGoogle these services are accessed by RSS or JSON API's that already exist.
It should theoretically be possible to make iGoogle a 100% client-side one-page app and require zero maintenance, or additional resources.
I have sites that run for years without me editing a single line of code or any other sort of maintainance. Backups run automatically, so do regular clean-ups of the database and certain directories.
What sort of maintainance would you say a largely client-side application like iGoogle does require?
Edit: anybody care to explain the random downvoting?
Are your sites written in C++ and being attacked by China and Russia? Do they have plug-ins for several hundred apps, many of which work with ever changing external websites? Do your sites integrate with critical email and advertising accounts? I would not be surprised to learn they were burning $1M a year on iGoogle.
Re. random downvoting, it happens on tablets. Chill, somebody else will be along shortly to vote the comment up out of the gray.
It is client side in the www.google.com domain. Meaning it can potentially attack other services in that domain like, oh, most other Google services. You'd want more than just a lone intern watching over it in his spare time.
Indeed, 1 google developer is going to be north of $100K/year, and if you're going to trust them to run a project, even a zombie one, probably significantly higher. Even worse is the loss of their expert advice and productivity on projects that actually deserve it.
They are living in some fantasy land. I know tons of people who use iGoogle and even if overall not that many people are, that doesn't mean it isn't valuable for what it does.
I'd love to see screenshots of how they imagine people now have access at their fingertips to summaries of all this information.
Going to each site individually or keeping things open in 20 tabs is a crap solution.
I would not be surprised if they integrated igoogle services into google plus somehow. perhaps a split newsfeed+widgets service. it would be an effective way to drive a nontrivial amount of traffic to google plus.
OMG so boring. Google needs to learn how to put on a show.
Also, Hangouts is G+ best feature but sadly it is really hard to get people together on it. Why when I invite someone do they not get an email or IM?? They only get notified within g+ itself and it isn't easy to find the invite. On recent jobs several times I've tried to get meetings together on g+ only to resort back to conference calls (!!? WTF??) every time because people couldn't get on the Hangout. That is a real shame.
Head mounted cameras with live video streaming and two way audio, over commercial cellular networks, using commodity hardware (well, prototype commodity hardware), is still a thing. I'm more into the thing as a compute device than headmount camera, but until they come up with a good audio UI or chording keyboard (ideally as glove), they'll be really limited on input, so video recording is probably the best use case.
(I worked for a guy who was doing this in the 1980s, with ~50 pounds of equipment in a backpack, a 5W radio transmitter on his head, etc.)
That part is cool, but it's also "FaceTime with a head-mounted camera". They spent most of their time showing something that is better but not unique. I was under the impression that Glass is supposed to put a UI in your field of vision, yet the entire presentation focused on the camera.
Project Glass is interesting ... but this demo didn’t show anything new.
But when Apple copies Android's notification center (which has now been massively bumped in JB) that is a huge thing and everyone is up in arms about what sort of geniuses the people at Apple are.
They released the next step in their roadmap. The device will be released to US developers in the IO audience who pre-order and they will be able to hack on it at the beginning of 2013.
What hasn’t happened? live video streaming and two way audio, over commercial cellular networks, using commodity hardware?
I have been doing that with my phone for a few years.
Also, look at the part of the glasses behind the ear, now look at any recent smartphone teardown and see how they compare in size.
I’m sure Project Glass will eventually be interesting, this demo was really cool, but hardly a technological achievement. You can do the same thing by strapping a phone to your helmet.
I'm referring to the "shrinking at will." If you can back, well, anything you're saying up about how Glass isn't impressive beyond "lol open up a phone," I'd love to hear it!
> I’m sure Project Glass will eventually be interesting, this demo was really cool, but hardly a technological achievement. You can do the same thing by strapping a phone to your helmet.
Yeah... you don't see any technical challenges going from the latter to the former? Sounds like you made up your mind a "years ago" when this apparently already existed.
Apple ask everyone to turn of wifi at WWDC to make their iPad work and that is awesome.
Live, two-way audio/video-streaming from AR computer glasses during a freakin' parashoot jump over regular cellular networks however, that is not really that much of a big thing?
Excuse me. What standards are you applying to whom where?
Glass was the "one more thing..." moment for sure; heard that there was a long line to purchase them for $1500 per -- any comments from HN owners?
Met with GOOG employees today who were testing newer versions, better resolution & new comms. I wasn't allowed to wear it but it looks bulkier than I imagined.
The odd thing is, during a meeting with an employee who was wearing Glass, it was hard to figure out where to focus my eyes on their face -- it was like talking to someone with a lazy eye.
I don't actually get the IM or the notification on my phone. Strange.
In any case, 99% of the designers I work with and 75% of the developers have iPhone/Mac and don't use either Android or gchat although they all have gmail/google accounts. So if they got an email they would be notified, otherwise, they never know.
Without the link it is also really hard to just tell people to go to G+. The way to join the hangout if you don't have a link is hard to find
This is not just an opinion, like I said, I actually tried to set up hangouts several times and these are the reasons it failed. Just my experience.
I get either a G+ or GTalk notification on my phone, it pops up if I have Google+ open and if not, I get a GTalk notice in Gmail. Otherwise I'm displayed as offline.
Also, I don't know what you found boring. Did you want more faux wood and plastic or more fancy words? I mean, I cringed enough at "buttery", I couldn't have handled the "magic" of alternative presentation styles.
I feel pretty safe in saying that IO is... pretty geeky.
I'm confused by their description of templates as "messy" and their decision to use laconic. Not an opinion that I think is widely held and definitely doesn't make sense to me. (by html templates do they specifically mean ejs/erb type templates versus jade/haml??)
Using html templates is good separation of concerns and js just isn't very good at expressing html structure. Jade would have been a much better choice IMO. Laconic does a good job of minimizing the problems with using js to programatically build dom in js but still doesn't come close to a proper templating language.
Client side templates are a hack, presently speaking. They are inserted into a script tag in the head (usually), so if you are working a single page app you need to include every template for your entire site in the head of the document. It works, but man is it ugly.
Then you have to include some bulky library that parses these scripts and compiles them to a function that you'll use later. All this happens pretty fast, but not any faster than just using the DOM apis.
I can't find the link, but I believe there is a proposal to standardize client side templating, so hopefully that will make the process a bit cleaner.
Something like this may unclutter the situation, just use xmlhttprequest to get the templates on demand:
//synchronous
body.innerHTML = render('blog.html',data)
//asynchronous
render('blog.html',data,body)
render=function(url,data,obj){
if url in cache: use cache
var http = xmlhttprequest()
http.get(url,obj?async:sync)
http.onready:
parse data in html
if obj: obj.innerHTML = html
else: return html
}
I like that, except that templates are used on demand, so onload would be useless. A better way would be to put an id on them and defer their load for when really needed.
But still, we don't want to load 50 templates at the same time if the app is big then use one or two in that session, that's why loading them on demand with httprequest might be a better solution.
*Besides, being static in nature they would be cached on the server and client for instant access.
Ideally you would preprocess your assets server-side (e.g Jammit), so templates end up being just another script to load.
This is still ugly, in that debugging templates is an impossible pain the arse because there's no useful line information. On the plus side they're much easier to read than a chain of DOM manipulations.
It's arguable whether this is "better". I usually have to interact with the DOM programmatically anyway (attaching events, for example), so why not build the DOM in javascript as well?
I use eco templates (CoffeeScript in HTML) that do not need a library to be interpreted once they are preprocessed server side. You minify them and save them as a variable in your source. No clutter, works nicely.
I realize that templates are a popular choice for many, but I view them as an unneccesary layer of indirection. Sort of like printing out an email, hand writing a response, and scanning it back in as a reply. Once your markup has been converted to a document object model, why not embrace it?
I think it's kind of like the difference between writing in assembly and C.
Using a bunch of calls to appendChild() and setAttribute() results in code that is difficult to read, because it's so low-level. You can't "see" the generated HTML, just like in assembly you can't really "see" the code structure.
Whereas using templates lets you "see" your HTML, with an easy-to-understand structure. So it's the natural, default choice for ease-of-use and maintenance.
I really like this style of templating, it's pretty close to how Seaside generates it's HTML, but more direct since it manipulates the dom directly. Also using the DOM directly is very fast.
I'm at peace with the upgradablity issue. It is personal taste so whatever. I agree with others that it is a silly debate and that the author is overly butt-hurt.
However, his "rebuttal" completely ignores the 2nd half of the original article's point: the new macbooks, and all ipad, are not recyclable despite what Apple says.
Not that Apple has a monopoly on callously diluting terms like "all natural", "recyclable", "free range", etc to increase profits and mislead consumers, thereby, eh, destroying the...EARTH. But still, even as the norm, it's pretty f-ing evil.
The attitude of the author is irritating and all too common in people in love with a self image of being an intellectual.
"In the absence of rigorous experimental evidence, I’m quite skeptical." - This is not logic. This is an arrogant and out of hand rejection of a hypothesis that has not yet been proven or disproven.
" “expert” who “totally believes” you’re a “different person” for having read books even if you don’t retain anything, with some flimsy feel-good reasoning such as the “extraordinary capacity for storage” that our brains have"
This is better reasoning than that put forth by the author by far. I love the quotes around "expert". WTF? Does he mean the PhD in Neuroscience and Prof at Tufts? That "expert"? The one who actually has studied this subject in depth?
As many other poster point out, we don't even remember most of our own lives but it is totally absurd to say our life experiences therefore don't influence us and that we shouldn't try to fill our lives with pleasurable moments.
It is unfortunate he defends working to remember more of what he reads with such a flawed and irritating argument because trying to remember what you read is an awesome and worthwhile pursuit. There is no need however to bash all of literary fiction and the reading 99.9% of people on this earth enjoy.
Not to mention that his same arguments can be applied to all fiction (movies, plays, etc) and music ('fleeting entertainment' which you don't jot down for use elsewhere). The author sounds like a tedious, trite person that wouldn't be much fun to be around.
Similarly, while he's trying to pose as an intellectual as you say, he misses the point that we learn things in multiple layers. Rememberance of the literal wording is only one layer. Witness Romeo and Juliet, a classic story which most people are familiar with, but extremely few would be able to quote a line from. Reading this guy's essay was like listening to those insufferable fresh graduates who claim 'but I never learned anything at university'.
On the one hand I get why people are excited about this and why people like coffeescript, especially when source maps start working in inspector/firebug. You can write web apps in the language you love and know. Cool!
On the other hand, this really sucks. Javascript is just maturing to where it is really awesome! And there is a ton of collaboration among app developers because javascript was the only game in town for so long.
Of course people will continue to collaborate but not, I fear, at the same level. 3rd party libraries will continue to be available, but not as many will fit in so neatly with people coding in other languages.
This has already come up a few times with coffeescript and in a couple years when it is truly easy for people to work in other languages, we'll have a tower of babel effect.
JS is really good. It isn't that hard to learn if you already know other languages. It has warts but it is also very powerful so often it is worth it (check out the lines of code and speed vs other languages):
I think that NaCl is more geared towards being a target of a port for an existing application thats been written (like the supreme commander game that google managed to coerce a studio to port to NaCl).
I htink the pie is big enough for both NaCl and javascript apps.
> It is, but you can also port existing applications to JS.
You can't just port things to JavaScript the same way. JavaScript is a very different sort of language. "porting" something to JavaScript pretty much always means remaking the whole thing from ground up and hoping that your pixel pushing in canvas runs at an acceptable speed.
It's not orders of magnitude slower, most benchmarks have it 2x-6x slower. It's rarely slower than 10x (one order of magnitude). And that is before JS engines even start to optimize for it.
I have written a lot of JS since my humble beginnings in 1997 where I wrote an "ajax" chat system running down to Netscape 2 and IE3.
There's no point in dismissing JS due to simple lexical issues; those have in no way prevented us from maturing the language use through idioms, patterns, tools and collective knowledge.
JS is more than good enough as a basis for CoffeeScript and Emscripten - so why should we care whether scope context or a lack of block scope can be initially confusing?
I'ver never understood how the "this" thing actually brings possibilities. If anything, it introduces unnecessary confusion about scoping/binding. Python and Ruby don't have "this" and do just fine.
But Python's methods already have self curried in. Class.foo(self, x) takes two arguments, but instance.foo(x) already has self bound, and only takes on argument.
This lets you do bar = instance.foo; bar(x) and it'll still work. Much more consistent.
Just leave it up for christs sake. I wonder if this isn't about forcing people to other services.
Take the developers and let it keep going. No new commits, it works!