Steve Ballmer has been CEO of Microsoft since 2000. During his tenure, Microsoft came out with Windows Vista, perhaps the most unsuccessful operating system in modern history (Windows ME doesn’t count, since Microsoft’s core customer base was using NT/2000); it tried a “Microsoft inside” strategy in digital music and, when that failed, launched the Zune, which also failed; it watched Firefox (and Safari and Chrome) eat a large chunk of its lunch in Internet browsers, the application most people use more than everything else put together; it launched Windows Live, a marketing strategy with no noun behind it, which completely flopped at whatever it was supposed to do; it got blown away in Internet search to the point where it had to re-launch as Bing, a plucky underdog; and in mobile phones, which everyone has known for a decade would be the next big thing, it stuck with its bloated, awkward Windows Mobile for far too long, letting everyone (RIM, Apple, Google, and even Palm) pass it by to the point where it has no customer base left. (BlackBerry rules the corporate market, Microsoft’s traditional stomping grounds.) Recently I saw a headline saying that Microsoft is going to try to relaunch Hotmail to make it cool. Really, why bother?
In Ubuntu 10.04 LTS we have launched a new music service called the Ubuntu One Music Store. It's a really cool place to go and buy tracks from the world's biggest bands. The Ubuntu One Music Store is a cloud-enabled digital music store. Purchases are first transferred to your Ubuntu One personal cloud and then automatically downloaded to all of your computers. We give all customers 2 GB of free cloud storage.
To contribute to the charity all you have to do is buy a track at the normal cost. That's it. Canonical will give away 50% of our take of the revenue up to a total of $1004. You can of course directly contribute to the charity if you prefer.
...удивительно. Похоже ОС как сервис - этот тренд надолго и всерьез. Хорошо хоть убунту пока держится - не навязывает AppStore-подобных решений (хотя что-то подобное потихоньку появляется, как я понимаю). Вот, сначала советуют откуда мне музыку качать (и как ее хранить), а потом traceroute придется за деньги ставить. :)
Since 1.2.16, SMTP over SSL is supported by setting SMTPProtocol to "smpts".
Oh, I just googled the idea : email any critical (and/or) improperly handled exception which your application raises. Criticals go immediately while mishandled ones get cached for a while before firing out. Seems that SMTP appender does that priority throttling and also supports SSL. Could it be any better? More related discussions on that below (assuming your webapp uses Spring Web MVC).
Spring provides HandlerExceptionResolvers to ease the pain of unexpected exceptions occurring while your request is being handled by a controller which matched the request. HandlerExceptionResolvers somewhat resemble the exception mappings you can define in the web application descriptor web.xml. However, they provide a more flexible way to handle exceptions. They provide information about what handler was executing when the exception was thrown. Furthermore, a programmatic way of handling exception gives you many more options for how to respond appropriately before the request is forwarded to another URL (the same end result as when using the servlet specific exception mappings).
Instead of only redirecting to an error page, you could also put these exceptions in a database, so you have a list of the most common ones that occur. Joel and Jeff mention that they do this for StackOverflow, and that list becomes part of their bugs-to-fix list.
«Product owner (он же Product Manager) - это человек, отвечающий за разработку продукта»
Что не может не радовать. Скажем так — это здорово и очень правильно выделять роль product manager. Многие методологии запросто игнорируют аспект управления требованиями, предполагая, что они, непротиворечивые и полные, как бэ даны нам свыше.
Что, естественно, нихрена не так. И даже - ровно наоборот. Термин «сбор требований», иногда встречающийся в литературе — отражает это недопонимание. Требования — не грибы, чтобы лениво разгуливая по лесу, увидев его, сказать: «О! Требование!», сорвать, и положить его в корзину. Они больше напоминают редкоземельный металл, добываемый нечеловеческим, рабским трудом в «этих проклятых рудниках» (кхе-кхе).
When the pressure is on to root out an elusive software or hardware glitch, what's needed is a cool head courtesy of a set of rules guaranteed to work on any system, in any circumstance. Written in a frank but engaging style, Debugging provides simple, foolproof principles guaranteed to help find any bug quickly. This book makes those shelves of application-specific debugging books (on C++, Perl, Java, etc.) obsolete. It changes the way readers think about debugging, making those pesky problems suddenly much easier to find and fix.
Illustrating the rules with real-life bug-detection war stories, the book shows readers how to:
* Understand the system: how perceiving the "roadmap" can hasten your journey
* Quit thinking and look: when hands-on investigation can't be avoided
* Isolate critical factors: why changing one element at a time can be an essential tool
* Keep an audit trail: how keeping a record of the debugging process can win the day
Some helpful patterns fell out of our experience, even though they weren't goals originally:
* Use aggressive timeouts to cut off the long tail.
You can't ever shake out all the unfairness in the system, so some requests will take an unreasonably long time to finish — way over the 99.9th percentile. If there are multiple stateless app servers, you can just cut a client loose when it has passed a "reasonable" amount of time, and let it try its luck with a different app server.
* Make every case an error case.
Or, to put it another way, use the same code path for errors as you use in normal operation. Don't create rarely-tested modules that only kick in during emergencies, when you're least likely to feel like trying new things. We queue all write operations locally (using Kestrel as a library), and any that fail are thrown into a separate error queue. This error queue is periodically flushed back into the write queue, so that retries use the same code path as the initial attempt.
* Do nothing automatically at first.
Provide lots of gauges and levers, and automate with scripts once patterns emerge. FlockDB measures the latency distribution of each query type across each service (MySQL, Kestrel, Thrift) so we can tune timeouts, and reports counts of each operation so we can see when a client library suddenly doubles its query load (or we need to add more hardware). Write operations that cycle through the error queue too many times are dumped into a log for manual inspection. If it turns out to be a bug, we can fix it, and re-inject the job. If it's a client error, we have a good bug report.
The Apple Human Interface Guidelines officially refer to it as the "spinning wait cursor". Its colloquial names include "spinning wheel of death", "beach ball of death", "hypnowheel", "spinning pizza", "spinning pinwheel", "pinwheel of death", "rainbow ball of doom", "the beach ball of hell", "spinning beach ball of death", "pin wheel of death", "rainbow wheel of death" and "marble of doom". The suffix "of death" in these names is a reference to Microsoft Windows' Blue Screen of Death (BSOD), which also leads to the acronym "SPOD" for "spinning pinwheel of death" or "spinning pizza of death," commonly used in mailing lists such as Mac-L. The suffix 'of doom' is also commonly used.