Но так как это своё будет работать только на своих мобилах, то программы писать будет не так интересно, как на Андроид. Кроме того, Баде, как я понимаю, ещё до релиза очень далеко.
Bada основана на Linux. Так же, как и Android и Nokia Maemo. Так что работать — теоретически — может не только на самсунге
SDK Bada уже зарелизен, первый телефон и AppStore ожидается в первой половине 2010
Впрочем, если Самсунг, один из партнёров Гугла по Андроиду, собирается разрабатывать свою систему и делать девайсы с ней, то это лишь ещё один повод для Гугла входить в партнёрсво с каким-нибудь HTC и вступать с ним привелигированное сотрудничество.
Уход имеющего опыт работы с Андроидом Самсунга на свою ОС может говорить о том, что лицензировать Андроид — не выгодно.
Samsung, Motorola, LG итд., как члены Open Handset Alliance, будут раздражены, но Android уже успел завоевать сердца людей, в AppStore тысячи удачных приложений — куда они денутся? Свою систему начнут разрабатывать, лучше чем iPhone и Android? Не смешите
Уже начали. Тот же Samsung на прошлой неделе презентовал свою платформу Bada. И там есть чем заинтересовать разработчиков. Например тех, кто разочаровался в Android'овском Market'e.
Минималистический вариант - старый добрый <input> + input masking, отображающий требуемый формат даты в этом же поле и "на лету" фильтрующий вводимые данные. Пример - тут (закладка Demo).
Что касается "а вот как скоро появится поддержка сего замечательного чуда в самом ИЕ", "IE может оказаться несовместим" и прочего хаянья IE... Поддержка нового тега элементарно реализуется с помощью существующего в IE вот уже лет 8 как замечательного механизма Behaviors, с помощью которого разработчики сами могут дефайнить нужные им теги (и вообще создавать полноценные реюзаемые DHTML-компоненты, что в остальных браузерах - не смотря на десятки появившихся последнее время фреймворков - до сих пор делается через одно место).
"Например, количество прерываний/сек — не важно для веб-приожений :)"
Это у вас наверное не было высоконагруженных серверов с гигабитным интерфейсом. Там вот кол-во генерируемых этим интерфейсом прерываний очень даже заметное влияние на производительность системы оказывает.
Да. http://msdn2.microsoft.com/en-us/library/ms525885.aspx
"почему это не единый инструмент. Потому что программы могут быть (и реально являются) от разных разработчиков"
И что, что от разных ?
В Windows разработчик стороннего продукта может:
1. Сделать метрики своего продукта доступными PerfMon'у.
2. API для управления программой сделать доступным через стандартный же WMI.
3. Для управления через GUI вместо написания отдельного приложения сделать snap-in для системного mmc.exe.
В результате на Windows я могу, например, за 2 минуты сконфигурить PerfMon (или загрузить существующую конфигурацию), создать (или опять же загрузить готовые) нужные мне паттерны нагрузки с помощью Microsoft WEFT и посмотреть, как меняется поведение всех компонентов системы (память, I/O, база и т.д.) при той или иной нагрузке. В динамике, замечу, т.е. с возможностью:
а) посмотреть ситуацию на любой момент времени
б) графической визуализации изменений
Предложенный выше вариант (десяток консолей с mysql, top, systat) такого просто не позволит. Известные мне попытки реализовать подобную функциональность на *NIX - Cacti, Nagios - тоже для этого слабо подходят (они годятся для сбора метрик в течении долгого времени, но практически неприменимы для оценки изменений параметров в реальном времени).
Пока разработчики Линукс боролись за рынок десктопов, они потеряли значительную долю на рынке серверных систем. И продолжают терять. Приведенный выше пример с мониторингом и автоматизацией управления - просто демонстрация одной из обьективных причин, по которым это происходит.
"архитектура того же Apache и IIS, способы настройки, логические шаги администратора — разные. И лично я действительно нахожу более простым прочитать один конфигурационный файл, который могу легко отредактировать руками, нежели ходить по сотне окон."
Во-первых - никто не мешает править один конфигурационный файл и в случае IIS. Этот файл - MetaBase.xml. А поскольку в нем используется стандартный XML, то его еще и инструментальными (например, XML Spy) и программными (парсеры XML есть для всех языков) просто редактировать.
А еще IIS'ом можно рулить (например, менять настройки - без перезагрузки сервера) через API. Очень полезно для автоматизации типовых задач.
"Мне удобнее и понятнее видеть чёткий мгновенный отчёт server-status."
Ну так сделайте его себе на IIS с помощью стандартного системного perfmon.exe. Аналог server-status - самое простое, что им можно сделать. А еще им можно вывести одновременно текущее кол-во запросов к серверу, активных рабочих процессов веб-приложения, соединений с БД, используемой памяти и CPU (и еще СОТЕН возможных показателей). Вобщем тех данных, которые при профайлинге веб-приложения _действительно_ актуальны. Если нужно - для нескольких серверов одновременно.
А можете назвать инструмент для Linux/BSD, который позволяет делать хотя бы половину перечисленного ?
"при серьезной работе можно заметить что сессии мешают делать масштаб. Что если у вас в локалке несколько php тачек и сверху над ними какой-либо лоадбалансер? Ничего не остается как писать свою версию сессий через базу. "
Естественно, если не знать возможностей платформы, которую используешь, то "прийдется самому писать". Знающие используют session.save_handler.
Вообще вместо переопределения exit можно обернуть цикл accept в функцию, обьявить обработчик END и вызывать эту функцию из него.
Просто END { goto &loop } у меня отрабатывало только 2 запроса (т.е. после первого запроса END срабатывал, после остальных - нет. Интересная особенность, кстати. Нормально заработало вот так:
sub loop {
eval "END { goto &loop }";
while (accept) { .... exit ... }
}
loop();
END { goto &loop; }
Единственное - при таком раскладе выйти по last в accept не получится, но это уже решается элементарно.
И еще - при использовании любого из описанных способов (включая этот) нужно очень внимательно следить за памятью, очень вероятны утечки.
Самый правильный способ завершить текущий запрос - метод FCGI Finish().
Но это этого нужно иметь возможность обращаться напрямую к обьекту FCGI, что при использовании более высокоуровневых интерфейсов (того же CGI::Fast) может быть затруднено. В этом случае можно для выхода посылать самому себе сигнал. После обработки сигнала происходит выход из цикла accept, обратно можно возвращаться через тот же goto. Выглядит это примерно так:
$SIG{USR1} = sub { $LAST_SIGNAL = shift; ... };
FASTCGI_NEXT_REQUEST:
while (my $q = new CGI::Fast) { ... }
if ($LAST_SIG eq 'USR1') { goto FASTCGI_NEXT_REQUEST}
"Подозреваю что опасность также в том что у вас может бить открыта сессия авторизации на неком сайте. И когда злоумышленник через ваш браузер запросит данные с некого сайта, тот их послушно предоставит, для вас!" ---
Такой опасности в данном случае как раз нет.
Описанное тобой называется CSRF-атака. Это когда злоумышленник заставляет броузер выполнить запрос (например, создав в странице форму и вызвав сабмит на атакуемый сайт). Если для этого сайта есть актуальные куки, то в запрос они будут подставлены самим броузером.
В случае же DNS rebinding злоумышленник получает возможность отправить _самостоятельно сформированный_ запрос. Поскольку он формируется вручную, куки в него подставлены могут быть только если злоумышленник уже их знает - а это совсем другая история :)
Естественно, компилятор не может оптимизировать то, чего нет на этапе компиляции - так что фолдинг не будет работать для динамически генерируемых функций (подозреваю, что и для XS тоже).
Вариант с readonly-переменными я тоже предлагал выше, ибо TMTOWTDI, но у него есть один очень серьезный недостаток: переменные, даже readonly, все-таки можно переопределить, причем случайно (что мешает мне обьявить my $O_NONBLOCK ?) - и компилятор/рантайм не выдаст при этом никаких сообщений! При переопределении же constant sub (не важно, через sub CONST {} или *CONST = sub) получим предупреждение: Constant subroutine main::CONST_NAME redefined (в случае sub CONST - еще на этапе компиляции).
1. "ОО в Perl это на самом деле не более чем bless-нутые ссылки и немного синтаксического сахара" - интересно, что это "не более чем" дает возможность реализовать больше ОО-фичей, чем в любом другом мейнстримном языке: от множественного наследования до использования prototype-based обьектности вместо class-based.
2. Со счетчиком ссылок все просто: при необходимости используйте средства для создания weak references (ссылок, не инкрементящих счетчик). Стандартно - Scalar::Util::weaken().
5. "Здесь же, вместо мелкого выигрыша, perl, интерпретатор, получает непотребный удар по производительности." - это заблужение. Действительно, use constant создает функциии (сделано это, чтобы не вводить доп. сущностей в язык). Но: умный компилятор инлайнит функции, возвращающие константное значение (не важно, созданные ли через use constant или вручную), так что при операциях с ними работа идет непосредственно со значением, вызова функции не происходит. Кроме того, в качестве констант можно использовать readonly переменные.
6. Непонятно, зачем определять тип переменной вместо того, чтобы просто использовать ее в нужном контексте. Впрочем, если есть необходимость, можно напрямую обратиться к IV или строковому значению SV. Пример:
use B;
my $x = "string"; $x = 10;
my $xb = B::svref_2object(\$x);
printf "%s, %d",$xb->PVX,$xb->IV;
use fields в помощь. Проблему с аutovivification решает, да еще и проверки будут не в рантайме (как с решениями на основе tie и пр.), а еще при компиляции.
В дополнение к уже сказанному (насчет удобного синтаксиса и диалекта) - в Перле регекспы проходят проверку синтаксиса на этапе компиляции. Это очень удобно.
Уход имеющего опыт работы с Андроидом Самсунга на свою ОС может говорить о том, что лицензировать Андроид — не выгодно.
Уже начали. Тот же Samsung на прошлой неделе презентовал свою платформу Bada. И там есть чем заинтересовать разработчиков. Например тех, кто разочаровался в Android'овском Market'e.
Это у вас наверное не было высоконагруженных серверов с гигабитным интерфейсом. Там вот кол-во генерируемых этим интерфейсом прерываний очень даже заметное влияние на производительность системы оказывает.
Да. http://msdn2.microsoft.com/en-us/library/ms525885.aspx
"почему это не единый инструмент. Потому что программы могут быть (и реально являются) от разных разработчиков"
И что, что от разных ?
В Windows разработчик стороннего продукта может:
1. Сделать метрики своего продукта доступными PerfMon'у.
2. API для управления программой сделать доступным через стандартный же WMI.
3. Для управления через GUI вместо написания отдельного приложения сделать snap-in для системного mmc.exe.
В результате на Windows я могу, например, за 2 минуты сконфигурить PerfMon (или загрузить существующую конфигурацию), создать (или опять же загрузить готовые) нужные мне паттерны нагрузки с помощью Microsoft WEFT и посмотреть, как меняется поведение всех компонентов системы (память, I/O, база и т.д.) при той или иной нагрузке. В динамике, замечу, т.е. с возможностью:
а) посмотреть ситуацию на любой момент времени
б) графической визуализации изменений
Предложенный выше вариант (десяток консолей с mysql, top, systat) такого просто не позволит. Известные мне попытки реализовать подобную функциональность на *NIX - Cacti, Nagios - тоже для этого слабо подходят (они годятся для сбора метрик в течении долгого времени, но практически неприменимы для оценки изменений параметров в реальном времени).
Пока разработчики Линукс боролись за рынок десктопов, они потеряли значительную долю на рынке серверных систем. И продолжают терять. Приведенный выше пример с мониторингом и автоматизацией управления - просто демонстрация одной из обьективных причин, по которым это происходит.
Во-первых - никто не мешает править один конфигурационный файл и в случае IIS. Этот файл - MetaBase.xml. А поскольку в нем используется стандартный XML, то его еще и инструментальными (например, XML Spy) и программными (парсеры XML есть для всех языков) просто редактировать.
А еще IIS'ом можно рулить (например, менять настройки - без перезагрузки сервера) через API. Очень полезно для автоматизации типовых задач.
"Мне удобнее и понятнее видеть чёткий мгновенный отчёт server-status."
Ну так сделайте его себе на IIS с помощью стандартного системного perfmon.exe. Аналог server-status - самое простое, что им можно сделать. А еще им можно вывести одновременно текущее кол-во запросов к серверу, активных рабочих процессов веб-приложения, соединений с БД, используемой памяти и CPU (и еще СОТЕН возможных показателей). Вобщем тех данных, которые при профайлинге веб-приложения _действительно_ актуальны. Если нужно - для нескольких серверов одновременно.
А можете назвать инструмент для Linux/BSD, который позволяет делать хотя бы половину перечисленного ?
Естественно, если не знать возможностей платформы, которую используешь, то "прийдется самому писать". Знающие используют session.save_handler.
Просто END { goto &loop } у меня отрабатывало только 2 запроса (т.е. после первого запроса END срабатывал, после остальных - нет. Интересная особенность, кстати. Нормально заработало вот так:
sub loop {
eval "END { goto &loop }";
while (accept) { .... exit ... }
}
loop();
END { goto &loop; }
Единственное - при таком раскладе выйти по last в accept не получится, но это уже решается элементарно.
И еще - при использовании любого из описанных способов (включая этот) нужно очень внимательно следить за памятью, очень вероятны утечки.
Но это этого нужно иметь возможность обращаться напрямую к обьекту FCGI, что при использовании более высокоуровневых интерфейсов (того же CGI::Fast) может быть затруднено. В этом случае можно для выхода посылать самому себе сигнал. После обработки сигнала происходит выход из цикла accept, обратно можно возвращаться через тот же goto. Выглядит это примерно так:
$SIG{USR1} = sub { $LAST_SIGNAL = shift; ... };
FASTCGI_NEXT_REQUEST:
while (my $q = new CGI::Fast) { ... }
if ($LAST_SIG eq 'USR1') { goto FASTCGI_NEXT_REQUEST}
Такой опасности в данном случае как раз нет.
Описанное тобой называется CSRF-атака. Это когда злоумышленник заставляет броузер выполнить запрос (например, создав в странице форму и вызвав сабмит на атакуемый сайт). Если для этого сайта есть актуальные куки, то в запрос они будут подставлены самим броузером.
В случае же DNS rebinding злоумышленник получает возможность отправить _самостоятельно сформированный_ запрос. Поскольку он формируется вручную, куки в него подставлены могут быть только если злоумышленник уже их знает - а это совсем другая история :)
Больше вроде бы нигде не встречается (хоть и очень удобно), поправьте, если не прав.
Вариант с readonly-переменными я тоже предлагал выше, ибо TMTOWTDI, но у него есть один очень серьезный недостаток: переменные, даже readonly, все-таки можно переопределить, причем случайно (что мешает мне обьявить my $O_NONBLOCK ?) - и компилятор/рантайм не выдаст при этом никаких сообщений! При переопределении же constant sub (не важно, через sub CONST {} или *CONST = sub) получим предупреждение: Constant subroutine main::CONST_NAME redefined (в случае sub CONST - еще на этапе компиляции).
2. Со счетчиком ссылок все просто: при необходимости используйте средства для создания weak references (ссылок, не инкрементящих счетчик). Стандартно - Scalar::Util::weaken().
5. "Здесь же, вместо мелкого выигрыша, perl, интерпретатор, получает непотребный удар по производительности." - это заблужение. Действительно, use constant создает функциии (сделано это, чтобы не вводить доп. сущностей в язык). Но: умный компилятор инлайнит функции, возвращающие константное значение (не важно, созданные ли через use constant или вручную), так что при операциях с ними работа идет непосредственно со значением, вызова функции не происходит. Кроме того, в качестве констант можно использовать readonly переменные.
6. Непонятно, зачем определять тип переменной вместо того, чтобы просто использовать ее в нужном контексте. Впрочем, если есть необходимость, можно напрямую обратиться к IV или строковому значению SV. Пример:
use B;
my $x = "string"; $x = 10;
my $xb = B::svref_2object(\$x);
printf "%s, %d",$xb->PVX,$xb->IV;
(Вообще-то исторически так сложилось, что принятые в народе обороты и грамотная речь заметно друг от друга отличаются).