Я бы поостерёгся покупать в интернет магазине, который бы заявлял, что он зарегистрирован в зоне .com из-за того, что владелец не хочет показывать свой паспорт.
BA screws Virgin — такого типа заголовки и у нас в жёлтой прессе любят. Типа «Дмитрий Медведев пойдёт под суд» (в статье выясняется, что речь идёт вовсе не о президенте, а о каком-нибудь бомже-однофамильце, укравшем мобильник).
Ну правильно, они контролируют весь оборот наркотиков, пресекая криминальные случаи. Например, врач в больнице получает на законных основаниях какие-то объёмы наркотических средств. Однажды он подделывает документы и получает большее количество, чем требуется больнице и использует излишек в своих целях. Агентство, контролируя ЗАКОННЫЙ оборот наркотиков, выявляет этот случай НЕЗАКОННОГО оборота и пресекает его. Поэтому оно и называется агентством по контролю оборота наркотиков.
Всё-таки, мне кажется, было бы удобнее и правильнее, если бы плееры поддерживали бы режим обратной совместимости, считывая из .swf файла информацию, на какую максимальную версию плеера он рассчитан.
Adobe уже не первый раз осложняет жизнь разработчикам апдейтами своего флеш плеера. Где-то полгода назад был выпущен апдейт, который у многих пользователей установился криво, в результате, скрипты, типа SWFObject, который определяли версию установленного Flash player'a перестали правильно работать (http://groups.google.com/group/swfobject/browse_thread/thread/7011649009c33bed). Причём проблему можно было решить только полным uninstall Flash плеера (что тоже была нетривиальная задача, и разумеется нереально было заставить всех клиентов сделать это) и установкой заново, либо отказом от проверки версии плеера на странице.
SSL Web certificate стоит $249. В каких-нибудь вьетнамских донгах эта сумма может выглядеть внушительно (4 127 175 VND), но вообще, для компании это копейки.
В качестве «шаблонизатора» данных в HTML он не очень подходит, а используют его, потому что «XML — это круто».
Категорические утверждения редко бывают верными.
А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.
Мне, как разработчику, в принципе, всё равно какой именно протокол выбран IT сообществом стандартом (или одним из стандартов). Для меня имеет значение, что этот стандарт начинает поддерживаться в самых разных системах, что позволяет мне эффективно эти системы объединять в рамках одного проекта.
Например, используя XML я могу получить данные из хранимой процедуры в MS SQL 2005 в виде XML документа, затем применить к полученным данным XSL шаблон и получить XHTML документ, который посылается пользователю. В данном случае, производители БД, серверных библиотек и клиентского браузера поддержили один и тот же стандарт, что позволяет мне делать сложные вещи просто.
Если бы это был бы не XML, а JSON или вообще какой-то бинарный протокол, я бы не возражал, главное чтобы стандарт поддерживался как можно более большим количеством участников IT индустрии.
Разумеется, выбирая что-то в качестве стандарта для широго круга задач, невозможно выбрать что-то, что будет наиболее оптимальным для каждой конкретной задачи. Это может дать возможность говорить, что этот стандарт «плохой», а повсеместное использование стандарта называть «помешательством», как вы изволили написать выше, но я бы обратил внимание, что именно повсеместное использование и делает стандарт стандартом и позволяет единообразно работать с довольно разными системами.
Прошу прощения за въедливость, но я бы ещё добавил, что в ТЗ не должно быть грамматических ошибок, таких как в этом тексте:
попробывать, распологаться.
Что касается реализации асинхронных методов в С++ и Object Pascal, то мне кажется, это вызвало бы больше вопросов, чем каких-то удобств. Поддержки многопоточности на уровне языка в этих языках нет, а асинхронный вызов подразумевает либо использование дополнительных потоков, либо передачу управления из основного потока в какие-то моменты времени в эти "помещённые в очередь вызовов" функции.
Что это за потоки, какие это будут моменты времени, как всем этим управлять непонятно.
А самое главное если смотреть шире, то сообщения между объектами, это всего лишь частный случай паттерна проектирования event dispatcher/subscriber. Не очень понятно, чем этот паттерн лучше всех остальных, чтобы его реализовывать на уровне конструкций языка, когда его можно реализовать имеющимися средствами, имея в результате бОльший контроль над получившейся системой.
SSL Web certificate стоит $249. В каких-нибудь вьетнамских донгах эта сумма может выглядеть внушительно (4 127 175 VND), но вообще, для компании это копейки.
Категорические утверждения редко бывают верными.
А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.
Мне, как разработчику, в принципе, всё равно какой именно протокол выбран IT сообществом стандартом (или одним из стандартов). Для меня имеет значение, что этот стандарт начинает поддерживаться в самых разных системах, что позволяет мне эффективно эти системы объединять в рамках одного проекта.
Например, используя XML я могу получить данные из хранимой процедуры в MS SQL 2005 в виде XML документа, затем применить к полученным данным XSL шаблон и получить XHTML документ, который посылается пользователю. В данном случае, производители БД, серверных библиотек и клиентского браузера поддержили один и тот же стандарт, что позволяет мне делать сложные вещи просто.
Если бы это был бы не XML, а JSON или вообще какой-то бинарный протокол, я бы не возражал, главное чтобы стандарт поддерживался как можно более большим количеством участников IT индустрии.
Разумеется, выбирая что-то в качестве стандарта для широго круга задач, невозможно выбрать что-то, что будет наиболее оптимальным для каждой конкретной задачи. Это может дать возможность говорить, что этот стандарт «плохой», а повсеместное использование стандарта называть «помешательством», как вы изволили написать выше, но я бы обратил внимание, что именно повсеместное использование и делает стандарт стандартом и позволяет единообразно работать с довольно разными системами.
попробывать, распологаться.
Что это за потоки, какие это будут моменты времени, как всем этим управлять непонятно.
А самое главное если смотреть шире, то сообщения между объектами, это всего лишь частный случай паттерна проектирования event dispatcher/subscriber. Не очень понятно, чем этот паттерн лучше всех остальных, чтобы его реализовывать на уровне конструкций языка, когда его можно реализовать имеющимися средствами, имея в результате бОльший контроль над получившейся системой.