"So, how does this work? Project FaceWeb is an extension of this progressive enhancement idea. So, instead of the phone saying I am rendering for a WebKit browser, we send an agent that says you are going to be rendering for a WebKit UI WebKit view inside the iPhone app. So, what you have to do is detect that, style a Web code to make that work, build a bridge between the things that you want to write to interact natively with the Objective-C, say in Javascript, then build HTML pages for Facebook in the iPhone. So, you build much smaller native goop instead of having to build over and over again.... HTML5 is probably the way that we should have done it."
If you think that's an HTML5 approach, I have some lean agile behavior-driven coaching hours for which I'd like to bill you.
been doing some Agile/XP work recently complete with Continuous Integration. we write website code and not box code, so might be a special case here, but our CI server builds in about 13 minutes. we have a production branch of the code monitored by CI so if/when we make a patch, it's immediately tested and built and ready for deployment. so if it's just an easy fix, it might be as quick as 30 minutes that we could deploy it out to the production website.
I also recall an experience I had with an open-source project in which I requested a somewhat trivial feature. the author added it to scm, sent me a patch file, and it was in the next nightly build as well. so that took about 12-24 hours.
in light of these experiences, 48 hours doesn't seem unreasonable to me, but I also agree with previous comments - it's a highly relative thing to judge. the best you can do is keep your code maintainable and try to reduce red-tape, I guess.
Why exactly is LeFou off topic here? He's linking to a site with the goal of uncovering and analyzing the likely list of Microsoft patents. Since Redmond won't tell, why not just make the list ourselves and shred it to pieces.
I dunno... programming puzzles can be a double-edged sword. They will weed out technically inept people, but they may also weed out technically adept people who are put off by programming puzzles as a gateway to an interview. I talked to a startup a while back that wanted me to go thru a programming test and sign an NDA before they would even reveal what the startup was working on. (For intellectual property risk reasons - in hindsight, this should have been a clue about the viability of the startup.) So I had to take 3 separate occasions to meet with them, and in the end I found that they had basically stumbled onto a neat but tame feature on which they were going to base their entire business.
Since then, I've been put off by gateway programming challenges...HOWEVER, when I joined SF.net (Disclaimer: Ross, who wrote this question, is my boss), I was eager to take on the pre-interview programming puzzle because I'm very passionate about the SF.net site and helping the open source community at large. In that case, I dove right into the challenge and was extremely excited thru the entire interview process, and I still am!
So I think some very talented programmers don't want to work at just "a[ny] prominent website." But that same programmer would want to work at "a prominent website they can be passionate about." If a programming puzzle helps to filter out the former, it could be weeding out highly-skilled programmers - who just aren't very passionate about the company.
Except that all of MY code is totally free, and I'm fine with that. Someone else, for whatever reason, might need or want to close off certain portions of their code. My software is free for those users.
I would call myself a free software advocate, but I release my code under the LGPL because I want give the users of my software the freedom to include it in non-free software. I guess I just say make free software, where the FSF seems to say make software free only to certain users.
That's like saying that advocates of free speech should impose restrictions on the speech of advocates of censorship.
I'd like to respectfully disagree with you here, using my own personal example...
I need my system to interoperate with a customer's system. I need to receive an electronic PO from them, acknowledge it, do our internal business process, send an invoice, receive acknowledgement, then wait for electronic payment. if we can get our systems to electronically interoperate in this way, we can save over a dozen man-hours/week spent on paperwork.
my system is a mix of ColdFusion pages on Windows 2000, PHP scripts on Red Hat Enterprise 3, and Informix 9.1 on Solaris. amongst the scripts and stored procedures is a lot of proprietary business logic for determining prices, markups, profit/loss figures, etc.
their system uses Oracle (both database and business apps), and webMethods, and maybe a slew of other languages/platforms on whatever operating system(s) they use, and it probably contains their own proprietary business logic as well.
in this situation, not only would opening up the source code be a privacy concern, but it would also do no good for me to see their Oracle or webmethods or "programming language X" code, unless I spent hours trying to figure it all out.
so opening code in this situation is not the best interoperability solution, and in fact, it would be a very BAD approach.
but, your title/comment is 95.8333% correct. "The best interoperability...Still occurs when your software...protocols are open, and I can look at them and 'interoperate' with them at will." I removed the "AND" because it is really only important for the protocols to be open.
and in this respect as it applies to my example, I'm sorry, but Mr. Gates's approach is 100% correct - XML. by establishing a protocol based on XML, ie. SOAP, the systems can easily interoprate without having to see the code underneath. this is indeed what we did and what we do with many partners, and it takes about 30 minutes to get the systems talking. no source code exchanged at all.
as for Mr. Gates's other assertion, that open-source development encourages "permutations" which cause interoperability problems, I can't really speak to it. I haven't used enough open-source applications to experience it.
even if it is true, and open-source applications fork and become disparate, XML can still be used to integrate these similar-but-incompatible systems, just as it is now being used by Microsoft to integrate their similar-but-incompatible, spaghetti-code product line!
the great thing about XML is that it is not Microsoft-specific. in fact, it transcends nearly all platforms.
by using open-source software, you get a huge range of options in products, meaning you can choose the best application for your needs. by using XML for interoperability, you get to use that best application with all the other best applications you've chosen. Open-Source and XML is the best of both worlds.
sorry to go off on such a tangent, but if open-source software is going to really progress in the interoperability area, it would do so best by letting go of the idea that interoperability is everywhere and always best addressed at the source code level. it's just not universally true.
letting go of this impractical ideology towards interoperability will be ANOTHER good step in making open-source development models viable for traditional commercial enterprises.
Slashdot Mirror
http://www.readwriteweb.com/mobile/2011/09/how-facebook-mobile-was-design.php
TL;DR:
If you think that's an HTML5 approach, I have some lean agile behavior-driven coaching hours for which I'd like to bill you.
Mozilla *is* hiring aggressively - http://careers.mozilla.org/ - *and* actively recruiting more community contributors - https://developer.mozilla.org/en/Introduction. There's no such thing as "____ is not part of Mozilla's ____" because we can all be part of Mozilla. See washort's link to https://bugzilla.mozilla.org/show_bug.cgi?id=744193
doesn't it say the guy fell onto a safety air cushion? 'murderous' may not have been the intent
all those paul supporters must have been spam. cyborgs, no doubt.
been doing some Agile/XP work recently complete with Continuous Integration. we write website code and not box code, so might be a special case here, but our CI server builds in about 13 minutes. we have a production branch of the code monitored by CI so if/when we make a patch, it's immediately tested and built and ready for deployment. so if it's just an easy fix, it might be as quick as 30 minutes that we could deploy it out to the production website.
I also recall an experience I had with an open-source project in which I requested a somewhat trivial feature. the author added it to scm, sent me a patch file, and it was in the next nightly build as well. so that took about 12-24 hours.
in light of these experiences, 48 hours doesn't seem unreasonable to me, but I also agree with previous comments - it's a highly relative thing to judge. the best you can do is keep your code maintainable and try to reduce red-tape, I guess.
Why exactly is LeFou off topic here? He's linking to a site with the goal of uncovering and analyzing the likely list of Microsoft patents. Since Redmond won't tell, why not just make the list ourselves and shred it to pieces.
I dunno ... programming puzzles can be a double-edged sword. They will weed out technically inept people, but they may also weed out technically adept people who are put off by programming puzzles as a gateway to an interview. I talked to a startup a while back that wanted me to go thru a programming test and sign an NDA before they would even reveal what the startup was working on. (For intellectual property risk reasons - in hindsight, this should have been a clue about the viability of the startup.) So I had to take 3 separate occasions to meet with them, and in the end I found that they had basically stumbled onto a neat but tame feature on which they were going to base their entire business.
Since then, I've been put off by gateway programming challenges...HOWEVER, when I joined SF.net (Disclaimer: Ross, who wrote this question, is my boss), I was eager to take on the pre-interview programming puzzle because I'm very passionate about the SF.net site and helping the open source community at large. In that case, I dove right into the challenge and was extremely excited thru the entire interview process, and I still am!
So I think some very talented programmers don't want to work at just "a[ny] prominent website." But that same programmer would want to work at "a prominent website they can be passionate about." If a programming puzzle helps to filter out the former, it could be weeding out highly-skilled programmers - who just aren't very passionate about the company.
My $0.02Except that all of MY code is totally free, and I'm fine with that. Someone else, for whatever reason, might need or want to close off certain portions of their code. My software is free for those users.
I would call myself a free software advocate, but I release my code under the LGPL because I want give the users of my software the freedom to include it in non-free software. I guess I just say make free software, where the FSF seems to say make software free only to certain users. That's like saying that advocates of free speech should impose restrictions on the speech of advocates of censorship.
I'd like to respectfully disagree with you here, using my own personal example... I need my system to interoperate with a customer's system. I need to receive an electronic PO from them, acknowledge it, do our internal business process, send an invoice, receive acknowledgement, then wait for electronic payment. if we can get our systems to electronically interoperate in this way, we can save over a dozen man-hours/week spent on paperwork. my system is a mix of ColdFusion pages on Windows 2000, PHP scripts on Red Hat Enterprise 3, and Informix 9.1 on Solaris. amongst the scripts and stored procedures is a lot of proprietary business logic for determining prices, markups, profit/loss figures, etc. their system uses Oracle (both database and business apps), and webMethods, and maybe a slew of other languages/platforms on whatever operating system(s) they use, and it probably contains their own proprietary business logic as well. in this situation, not only would opening up the source code be a privacy concern, but it would also do no good for me to see their Oracle or webmethods or "programming language X" code, unless I spent hours trying to figure it all out. so opening code in this situation is not the best interoperability solution, and in fact, it would be a very BAD approach. but, your title/comment is 95.8333% correct. "The best interoperability...Still occurs when your software...protocols are open, and I can look at them and 'interoperate' with them at will." I removed the "AND" because it is really only important for the protocols to be open. and in this respect as it applies to my example, I'm sorry, but Mr. Gates's approach is 100% correct - XML. by establishing a protocol based on XML, ie. SOAP, the systems can easily interoprate without having to see the code underneath. this is indeed what we did and what we do with many partners, and it takes about 30 minutes to get the systems talking. no source code exchanged at all. as for Mr. Gates's other assertion, that open-source development encourages "permutations" which cause interoperability problems, I can't really speak to it. I haven't used enough open-source applications to experience it. even if it is true, and open-source applications fork and become disparate, XML can still be used to integrate these similar-but-incompatible systems, just as it is now being used by Microsoft to integrate their similar-but-incompatible, spaghetti-code product line! the great thing about XML is that it is not Microsoft-specific. in fact, it transcends nearly all platforms. by using open-source software, you get a huge range of options in products, meaning you can choose the best application for your needs. by using XML for interoperability, you get to use that best application with all the other best applications you've chosen. Open-Source and XML is the best of both worlds. sorry to go off on such a tangent, but if open-source software is going to really progress in the interoperability area, it would do so best by letting go of the idea that interoperability is everywhere and always best addressed at the source code level. it's just not universally true. letting go of this impractical ideology towards interoperability will be ANOTHER good step in making open-source development models viable for traditional commercial enterprises.