Counterargument: Obtaining the usually-excellent reliability and stability that Google usually offers would be time-consuming, difficult, and a distraction. Sure I could set up a server with Postfix et al, but there's no way I'd be more reliable than Google without investing a substantial amount of time, money, and energy.
I don't want to spend my time maintaining a mail server. Let someone else do that.
I 100% agree with you, which is why I use them for email. But if they were to drop my business off the Internet for days at a time and make it impossible for me to get in touch with them, I'd be a little more concerned with that than with sporadic email downtime.
Agreed. I was in the process of moving our small set of users to Google Apps Premier. The phone support and quick response time was crucial to convincing my boss to allocate the funds. I think such a change:
I'm confused. The links and text in the page you link to all say that Phone support is still available, just you have to login to a support page and enter some pin and then you get the number. Is this not true?
> the usually-excellent reliability and stability that Google usually offers
This is most of why I put aside my reservations and used them as a registrar intermediate. I am quite sure I said to myself, "well, you can trust Google".
My domain expires in March. Bad news for me. Bad news for Google too. I can't trust them implicitly any more. I'm sure anyone else who is in the crosshairs on this issue feels the same.
I agree. It never occurred to me that Google would manage to screw something up as fundamental as making sure domain renewals worked properly. Of course, given the recent issues we've seen reported with SSL certificates being allowed to expire (GrandCentral comes to mind), maybe we should be more worried.
I have one domain registered with them, and supposedly I should be able to transfer the domain to another one of my registrar accounts (I can unlock the domain and receive the authorization code, transaction ID, and security code), but something keeps rejecting the transfer. Let's see how long it takes to work through this!
Ten months, seven trips to MSU, six blown fuses and about $60,000
later, I'm proud to introduce you all to Snakebite: The Open Network!
A network of around 37-ish servers of all different shapes and sizes,
spread over three sites, specifically geared towards the needs of
open source projects like Python.
Every CPython, Jython, IronPython and PyPy committer will have access
to every development server on the network. I've also extended the
offer to prominent Python projects like Django and Twisted.
Eventually, I'll invite other open source projects to participate
(Apache, Subversion, MySQL, Postgres, etc), but the network is my
gift to All Things Python, first and foremost, so Python projects
will always get preferential treatment.
The general idea is worthwhile, but not to the extreme the author suggests:
> Maintainability isn't a factor. Best practices don't
> matter. Design patterns don't matter. All that matters
> is getting things done.
Naturally, you must find a happy medium. Go for maintainability and best practices wherever possible, but don't lose sight of your goal: create your product.
That said, the author did acknowledge the need for moderation toward the end. Best practices are thusly named for a reason.
He is a bit over the top. Use best practices, but dont create an interface for only one class dont create an abstract class for only one subclass, dont create a data only class where a HashMap will work. All this extra code has to be maintained by someone. In fact the essence of maintainability is to have less code.
Another thing the author does not mention is that many of these things you can make very habitual and even into zero cost macros (especially if using a mature IDE).
A habitual extra 15 seconds spent minding something that requires no 'real thought' because you do it all the time can have an enormous long-term organizational impact.
Everybody writes shit code when they implement something new to get it working as quickly as possible. What matters is spending an extra 10-30 minutes before checking your code in to turn that sloppy code into a work of art.
Yes, I mean it's not unusual to take the shortcuts described in the article to produce working code. Even the very best programmers who turn in immaculately maintainable software do not just sit down at their desk and type perfect code into their editor.
First you write a really bad version that mostly works. Then you go back and fix that abomination before anybody else sees it. You don't want everybody else to think you suck at programming, right? :)
It seems to be mostly about patents. The H.264 patent pool contains hundreds of patents owned by 23 organizations. Many of them appear generic enough that any new codec would run a serious risk of infringing them. For example, one of H.264's major improvements over previous codecs is the use of arithmetic coding, and there's a patent in the pool concerning a "method and apparatus for binarization and arithmetic coding of a data value".
Worse, there's the possibility of submarine patents that are not included in the H.264 pool. Qualcomm has already attempted to sue Broadcom for making H.264-compliant products that allegedly infringed Qualcomm patents (which Qualcomm had not disclosed when H.264 was being developed). They lost the case, but the US Court of Appeals specifically limited the scope of those patents' unenforceability only to products which are covered by a H.264 license. That means Qualcomm is still free to sue for any independently developed non-H.264 codecs that might be similar enough.
YouTube uses a Flash embed to stream videos from their servers. It's their own proprietary player SWF, but anyone could theoretically create something similar. Flash (the software) contains built-in templates for such a thing.
But this requires the Flash plugin, hence the desire for a <video> element and such (as we'll see in HTML5).
I once used Spirit successfully, even though at the time I was not as well-versed in C++ as I should have been. I tend to like boost, because it makes a lot of things easy that would otherwise be difficult and/or time-consuming to write in C++.
