Расскажите, кому и как пригодилась топология. Не геометрия, а именно то, что изучается топологией.
Не хочу сказать, что она не нужна, просто интересны её области применения. Про дифференциальную геометрию тоже не прочь услышать.
В статью особо не вчитывался, поскольку она о Джаве, от которой я далёк и не знаю роли фреймворков в ней.
Но, по-моему, (для client-side и jQuery, в частности) проблема не столько во фреймворках, сколько в людях, пишущих на них. Фреймворки сильно снижают порог вхождения, скрывая сложность многих действий от пользователя. Взять, например, те же CSS селекторы в jQuery: если бы пользователь реализовывал выборку нужного элемента вручную (DOM traversing), он бы знал, чего это стоит браузеру и кешировал узлы в переменных вместо повторной выборки каждый раз.
Но суровая реальность такова, что зачастую люди начинают знакомство с языком с библиотеки / фреймворка, что влечёт, например, такой синдром как jQuery головного мозга. В особо запущенных случаях больные считают jQuery и JS совершенно разными языками и зачастую спрашивают, как портировать какой-либо функционал (скажем, сопоставление адреса страницы с регэкспом) с JS на jQuery.
Начинать знакомство с языком с фреймворка, я считаю, строго противопоказано.
Если же у нас есть p процессоров, то разобъём список x на p равных частей xi и с помощью левой свёртки для каждого xi вычислим h за время Cn/p, а затем за время Clog2p вычислим окончательный результат.
Вы предлагаете вычислять каждую часть последовательной свёрткой? Почему бы и дальше не разбивать каждую часть на p частей (которые ещё на p частей и т.д. до достижения списков длины 1)? Тогда мы должны получить асимптотику O(logpn).
Обычно они мотивируют это тем, что через JS нельзя отправить POST запрос на другой домен. Это действительно так (по крайней мере при обычных условиях).
Всё же, как показывает пример с фреймом, POST запрос на другой домен отправить-то можно, но вот ответ получить не получится.
Да, забыл про это.
Но это кривой способ, потому что файл на сервере нужно будет считывать из входного потока. Да и дополнительные параметры POST'ом не передать.
Помимо самого D&D важен также способ отправки файлов. Стандартный XHR не умеет отправлять файлы (равно как и обычный JS даже не подозревает о существовании файлов), а стандарты пока находятся только в процессе разработки.
Так, например, в FF3.6 единственный способ отправить файл — отправить его содержимое в виде данных обычного (не multipart!) запроса (т.е. нужно получить весь файл одой строкой). Как результат — передать файл в 500мб, как минимум, затруднительно, т.к. чревато огромными затратами памяти.
Только плюсы можно ставить в течение двух дней с момента публикации. Часто у хороший статей плюсов меньше, чем число человек, добавивших статью в избранное.
Я обычно плюсую статью уже за то, что она заинтересовала меня. А если была полезной, то автору плюс и в карму поставлю (благо, это можно сделать всегда).
Не хочу сказать, что она не нужна, просто интересны её области применения. Про дифференциальную геометрию тоже не прочь услышать.
Но, по-моему, (для client-side и jQuery, в частности) проблема не столько во фреймворках, сколько в людях, пишущих на них. Фреймворки сильно снижают порог вхождения, скрывая сложность многих действий от пользователя. Взять, например, те же CSS селекторы в jQuery: если бы пользователь реализовывал выборку нужного элемента вручную (DOM traversing), он бы знал, чего это стоит браузеру и кешировал узлы в переменных вместо повторной выборки каждый раз.
Но суровая реальность такова, что зачастую люди начинают знакомство с языком с библиотеки / фреймворка, что влечёт, например, такой синдром как jQuery головного мозга. В особо запущенных случаях больные считают jQuery и JS совершенно разными языками и зачастую спрашивают, как портировать какой-либо функционал (скажем, сопоставление адреса страницы с регэкспом) с JS на jQuery.
Начинать знакомство с языком с фреймворка, я считаю, строго противопоказано.
Но это кривой способ, потому что файл на сервере нужно будет считывать из входного потока. Да и дополнительные параметры POST'ом не передать.
Так, например, в FF3.6 единственный способ отправить файл — отправить его содержимое в виде данных обычного (не multipart!) запроса (т.е. нужно получить весь файл одой строкой). Как результат — передать файл в 500мб, как минимум, затруднительно, т.к. чревато огромными затратами памяти.
Я обычно плюсую статью уже за то, что она заинтересовала меня. А если была полезной, то автору плюс и в карму поставлю (благо, это можно сделать всегда).
Если нужно передавать помимо файла другие значения, я бы посоветовал использовать FormData.