> Предположим, у Вас в телевизоре есть почтовый клиент.
А это удобно, читать почту с расстояния в несколько метров? Учитывая, что айпад уже чуть ли не у каждого второго есть? Я думаю, вам не нужен почтовый клиент в телевизоре. Ну а если такая необходимость все же была бы, проще залогиниться с компьютера в телевизор и там нажать большую такую кнопку «отправлять почту в мой телевизор» (и там же можно подключить твиттер, вконтактик и фейсбучек), чем с пульта вводить пароль из 20 сложносочиненных символов.
> float amplitude = sample / 32768f;
> float level = Math.Abs(amplitude); // от 0 до 1
В вашем примере, вы находите непонятно что. Чтобы найти громкость звука (без учета чувствительности уха в разных частотных диапазонах), надо складывать квадраты значений. После чего величину пронормировать и взять логарифм от нее (получится величина в децибеллах).
При этом, я подозреваю, сначала надо избавиться от постоянной составляющей (найдя среднее значение и вычтя его из каждого отсчета).
Значит, Гугл думает, что он лучше знает, что показать пользователям. Мне например, не нравится, когда меня молча редиректят на другую страницу, или подсовывают мне вместо качественных английских статей некачественные русские в результатах поиска, но видимо этот подход работает.
> Вполне логично возвращать указатель на данные либо NULL в случае ошибки.
Это глупое решение. Этот ваш NULL может обойти полпрогграммы, прежде чем дереференсится, и вы будете сидеть с полной памятью нуллов и думать, в каком месте возникла ошибка. Ну-ну, удачи.
Это мне напоминает яваскрипт, там, например, если опечататься в имени поля объекта (object.fieldNmea), то ничего не выбросится, а просто вернется undefined, этот undefined при сложении/умножении так же молча превратится в NaN и счастливо изгадит половину объектов и DOM-элементов. Приходится на каждый чих ассерты ставить. Фу, не люблю эту особенность яваскрипт. Чем быстрее программа падает, тем проще найти ошибку.
Таким образом, если функция может вернуть NULL, вы *обязаны* после каждого вызова ставить if (x != NULL), и, естественно, не можете использовать конструкции вида a(b(), c())
У Апача есть интересная особенность — если у файла несколько раширений, и ему незнакомо последнее, он для определения типа берет предпоследнее, потом предпоследнее, и т.д. Таким образом, если в дефолтном конфиге Апача не описан mime-тип mp3 (тут я не уверен, так это или нет), то файл So-much-I.love.php.mp3 будет им воспринят как PHP файл и выполнен с помощью интерпретатора. А код проверки вроде «файл должен заканчиваться на .mp3» такой файл пройдет. И проверку «является ли файл mp3-файлом по содержимому» — тоже.
Это объяснение «для чайников», нормальное описание для специалистов можно почитать в мануале Апача в разделе mod_mime и content negotiation. Эта фича была задумана, чтобы например можно было сделать файлы index.php.de, index.php.en и подключать их в зависимости от языка, но открывает возможности для взлома сайтов. Например, формат rar мало известен на западе, и его нет в конфиге Апача, потому если сервер разрешает закачку .rar файлов, то (иногда) можно залить туда file.php.rar и благополучно его выполнить.
C картинками, например, такой трюк не пройдет, так как расширения png/jpeg/gif описаны в дефолтном конфиге и файл image.php.jpeg будет воспринят именно как картинка.
Чтобы не палиться со словом php в имени файла, иногда можно использовать менее известное расширение .phtml (на некоторых серверах оно тоже запускает php).
Правильный способ борьбы с такими уязвимостями (по моему не-экспертному мнению) — закачивать файлы в недоступную извне папку, вне корня сайта и отключать интерпретатор PHP насовсем в папке с пользовательскими файлами. Ну и не копипастить конфиг сервера из интернета, а внимательно составить самому, прочтя доукментацию. Ага, кто-то так будет делать.
Замечу, что никто не запрещает в комментарий настоящего, проходящего все проверки, mp3 файла засунуть PHP-код, и при определенном условии он будет выполнен (если на сервере Апач).
> Но мне нужны аргументы, которыми я смогу отбиваться от «зачем мне все эти ваши HTML5, если у меня в IE6 все едет.
А мне кажется, главная задача верстальщика — сделать, чтобы страница отображалась и работала наилучшим образом на устройствах пользователей (ну и еще хорошо бы сделать ее логичной и поддерживаемой для дальнейшего развития), а не использовала максимальное количество новомодных технологий. Пользователю неинтересно, какую версию языка вы используете. И если бы эту задачу лучше всего решала табличная верстка, стоило бы ее использовать (на самом деле, даже ИЕ6 поддерживает CSS2, и в нем выгоднее использовать дивы). И наоборот, если использование article вместо div давало бы выгоду, стоило бы использовать эти теги. Но я пока этой выгоды не вижу и у меня такое ощущение, что их используют только ради того, чтобы поставить модный значок HTML 5 (5 — это же круче, чем 4, скажет любой маркетолог). Ололо, некоторые верстальщики даже с float и clear разобраться не могут, зато пишут на HTML 5 и CSS3.
Ну а пересаживать людей — это смешно. Если какой-то мелкий сайт говорит, что он не хочет работать в моем браузере, мне проще зайти на аналогичный, но нормально отображающийся, чем скачивать и что-то устанавливать. Менее квалифицированные пользователи тем более делать это не станут (тем более, что в последнее время «обновить Оперу» предлагают в основном разработчики троянов).
> Я только не понял насчёт книги Фаулера и фабрик объектов: паттерны проектирования в контексте веб-разработки чем-то радикально отличаются от тех, что принято использовать в иных контекстах, и те фабрики, что я писал на С++, мне в вебе не помогут?
Ничем не отличаются. Веб-приложения — точно такие же приложения, только с HTTP-интерфейсом.
> В идеале хочется достичь такого уровня компетенции, который позволил бы грамотно создавать с нуля веб-сервисы любой степени сложности.
Я так понял, что вы хотите сами все уметь делать, а для этого надо начинать именно с основ. И естественно, нужна практика (в том числе написание 3-страничных приложений для начала). И естественно, надо много времени. Но если вас интересуют технологии с точки зрения руководителя или архитектора, то тут другая ситуация. Попробую пояснить на примере:
Что касается проектирования архитектуры приложений (в которой вы наверняка хотите разбираться), то типичные подходы и их недостатки уже изучены и опубликованы. Например, в известной книге Фаулера «Patterns of Enterprise Application Architecture» (есть в переводе). Но я не уверен, что вы ее сможете понять, если вы в жизни не писали ни одной фабрики объектов и не сталкивались с приложениями, где нужен ORM. То есть, я не уверен, что вы поймете эту книгу без соответствующего опыта написания кода. Книгу вы может попробовать почитать и сделать вывод сами, достаточно у вас знаний или нет.
Или, другой пример, наверняка вы бы хотели знать, какую СУБД (или библиотеку) лучше выбрать для приложения, и какие вас могут при этом ждать подводные камни. Ответ на этот вопрос, мне кажется, может дать только человек, который имеет опыт работы с этими СУБД и опыт их использования в большом проекте, и уж точно не статья какого-нибудь восторженного юноши с Хабра, который хранит в этой БД все 3 статьи из своего никому не нужного бложика. Ну или вы можете узнать сами про подводные камни, если попробуете использовать эту СУБД или библиотеку в своем проекте. Это тот вид знаний, который из книг не узнаешь.
Впрочем, ценная (практическая) информация в стиле «опыт использования бибилиотеки X» встречается в разных презентациях с конференций, с яндекс-субботников и гугловских мероприятий, но это надо все читать, анализировать, опять же большой объем информации и много времени.
Потому, что касается вопроса, хватит ли «изучение теории один на один», я думаю, нет. Это как если бы вы учились, допустим, управлять гоночной машиной исключительно по учебникам, ни разу за руль не взявшись. В вашем случае, наверно, лучшим будет метод «проб и ошибок» в сочетании с обзором разных технологий и библиотек, которые можно будет применить.
Значит получается, что Гугл не хочет тратить оплачиваемое время своих сотрудников на разбор жалоб, которые не грозят им юридическими последствиями. Такая же политика, например, у Яндекса — они не принимают абузы на многие свои сервисы с пользовательским контентом.
А это удобно, читать почту с расстояния в несколько метров? Учитывая, что айпад уже чуть ли не у каждого второго есть? Я думаю, вам не нужен почтовый клиент в телевизоре. Ну а если такая необходимость все же была бы, проще залогиниться с компьютера в телевизор и там нажать большую такую кнопку «отправлять почту в мой телевизор» (и там же можно подключить твиттер, вконтактик и фейсбучек), чем с пульта вводить пароль из 20 сложносочиненных символов.
Почта в телевизоре, дожили.