Шахматы это игра в которой большое значение имеет интеллект и опыт, удача же в целом не влияет ни на что.
В трейдинге, же удача стоит на первом месте. Слишком много факторов которые не известны и полностью просчитать рынок как минимум обычному человеку нереально в принципе. Сравнение с рулеткой кстати очень подходит, ведь и с рулеткой Теоретически можно учесть силу броска шарика, скорость вращения колеса и т.д. Добавляя изображение с шахматами в топик по трейдингу вы по сути вводите подсознание читателя в заблуждение «читай, изучай, практикуйся и ты Точно победишь».
Скорее всего проблема в самих банерах, обычно об их оптимизации никто не задумывается и засовывают внутрь флеша кучу всяких сложных эффектов, то что они начинают выполнятся почти одновременно, усугубляет проблему.
Но по-моему это само по себе очень нехорошое занятие — повесить на одну страницу кучу флеш-банеров и секундная задержка тут уже роли для пользователя не сыграет :)
Это скорее по большей части не по вредоносный код, а про то как не надо делать, чтобы не огрести от коллег.
Вредоносный код то обычно стараются сам по себе сделать незаметным, а как он потом уже будет вызываться — уже не так важно, его ищут с другого конца. Вот «Бонус трек» уже под это подходит.
>> В PHP и HTML в блокнотике написал, в готовый сервер залил
Вы это сейчас о чем вообще? Мы вроде о разработке говорим.
У вас очень странная логика, если на .Net или Java вебстраничку с hello world сделать сложнее, то уже и зарплаты будут заметно выше? Еще вы верстку тут приплетаете зачем-то, а на Java, .Net хтмл вообще совсем не нужен в веб разработке?
Ну и да кстати, исходя из Практики это от PHP волосы седеют, ибо 100500 фреймворков, 100500 велосипедов и 100500 способов нарукожопить.
Так а зачем запрашивать еще какие-то данные на стороне? У вас есть настройки которые вы уже вставили на страницу и есть один запрос к вашему яваскрипту — вот там уже все данные должны придти, хотя даже при очень хитрых банеров можно обойтись без динамического яваскрипта. Если речь идет об изображениях, которые должны загрузится и уже зачем-то только после этого отрисоваться, то у них тоже есть событие загрузки.
Вообще какой-либо запрос еще один вам мог быть бы нужен только в одном случае, если вы загружаете динамический яваскрипт в первый раз, который получает какие-то данные со страницы, ну например парсит текст и потом бекенд решает какой ему баннер отрисовать.
А почему PHP, JavaScript считаются простыми платформами? И по сравнению с чем? Python Ruby сложные? И в чем заключается простота? Так то можно обидеть злых рубистов, если окажется что на руби писать сложнее :)
>>тогда нужно подождать и повторить попытку чуть позже по таймеру. Но, обычно, до загрузки страницы эти данные уже приходят.
Ужас.
>>Общее у этих подходов то, что баннеры загружаются по мере загрузки страницы и, если что-то будет тормозить, затормозит вся страница.
Вы владелец баннера или баннеры вставляют к вам и вы просто советуете?
Так-то владельцу баннера важно чтобы он как можно быстрее появился. А тормозить не должно, если бекенд нормально сделан.
Поэтому и запрос еще один через JSONP делать очень нежелательно.
По-моему это все-таки довольно спорная штука. Я вот например, подумав что я обычно читаю, не до конца понял практическую пользу и сферу применения.
Если брать техническую литературу, документацию и т.д. — не применимо, т.к. очень часто приходится возвращаться к прочитанному ранее абзацу, например, чтобы переосознать. Да и скорость тут ограничивается не чтением, а пониманием.
Если брать художественную литературу — то какая разница какая скорость чтения, ведь читаем для удовольствия, и по-моему на удовольствие количество прочитанного влияет не сильно.
При всем этом, у людей которые читают быстро — у них патерны не на уровне слов, а на уровне словосочетаний уже. Я вот например не заметил, что скорость сильно возросла.
По мне — оно может быть полезно только на каких-то маленьких устройствах типа часов, при приеме например длинного сообщения.
Я начинал на паскаля, там было разделение процедур и функций) Поэтому подсознательно я это называю так) Хотя вы правы, не стоит отходить от общепринятых терминов, спасибо.
Сомнительны цифры в 50% производительности разработчиков, ООП не панацея, писать понятно красиво и быстро можно и в функциональном стиле.
Как показывает практика 90%++ кода которое использует синтаксис классов на PHP не ООП ни разу, а всего лишь некоторое подобие неймспейсов и странные попытки упоротых абстракций. А там такое можно накрутить, что ой ой ой, и что лучше бы уж сборники функций. Уж времени на разбор кода тратилось бы меньше, а значит и производительность была бы выше.
Да и наверняка дело не в производительности и экономии серверов, а во времени отработки скриптов и отдачи данных пользователям.
Ностальгия, табличечки… Кстати к нам это все пришло позже и было актуальным и в начале 00-х
Помню как меня удивила особая магия — таблица с ячейками в 1px, хитрый яваскрипт и в результате эдакая совсем неторопливая реализация нынешнего canvas.
А fronpage`ом у нас вроде не любили пользоваться, больше сохраняли ворд документы как веб страницу :)
Кеширует если настроить — проверено. Натсройка всего там строчек на 10, разобраться по документации очень просто.
Просто решение совершенно безгеморойное. Можно например настроить 1 сервер для кучи проектов, сделать там поддомены img.site1.com img.site2.com.
А далее обращаться как-то вот так: img.site1.com/200x400/background_big_image.jpg и все остальное разруливать яваскриптом.
Хотя конечно это все не прокатит, если речь идет о куче мелких сайтов, которые просто передаются заказчику.
Уже даже фоты этой странной неумной противной тети вызывают брезгливый негатив.
Складывается стойкое ощущение, что интернет она видела только в виде распечатанных скриншотов, которые ей подтаскивают хитрые пацанчики, проталкивающие хитрый и выгодный им бред.
Человек выше в первую очередь писал про объем памяти и аккумулятор. На счет же размеров — везде в обсуждении нота найдется кто-то кто вспомнит слово лопата, видимо ему даже в голову не приходит, что кому-то и 5.7 мало :) А на счет даром не даром? а вы пробовали? хотя бы две недели при активном использовании?
В трейдинге, же удача стоит на первом месте. Слишком много факторов которые не известны и полностью просчитать рынок как минимум обычному человеку нереально в принципе. Сравнение с рулеткой кстати очень подходит, ведь и с рулеткой Теоретически можно учесть силу броска шарика, скорость вращения колеса и т.д. Добавляя изображение с шахматами в топик по трейдингу вы по сути вводите подсознание читателя в заблуждение «читай, изучай, практикуйся и ты Точно победишь».
Но по-моему это само по себе очень нехорошое занятие — повесить на одну страницу кучу флеш-банеров и секундная задержка тут уже роли для пользователя не сыграет :)
Вредоносный код то обычно стараются сам по себе сделать незаметным, а как он потом уже будет вызываться — уже не так важно, его ищут с другого конца. Вот «Бонус трек» уже под это подходит.
Вы это сейчас о чем вообще? Мы вроде о разработке говорим.
У вас очень странная логика, если на .Net или Java вебстраничку с hello world сделать сложнее, то уже и зарплаты будут заметно выше? Еще вы верстку тут приплетаете зачем-то, а на Java, .Net хтмл вообще совсем не нужен в веб разработке?
Ну и да кстати, исходя из Практики это от PHP волосы седеют, ибо 100500 фреймворков, 100500 велосипедов и 100500 способов нарукожопить.
Вообще какой-либо запрос еще один вам мог быть бы нужен только в одном случае, если вы загружаете динамический яваскрипт в первый раз, который получает какие-то данные со страницы, ну например парсит текст и потом бекенд решает какой ему баннер отрисовать.
Ужас.
>>Общее у этих подходов то, что баннеры загружаются по мере загрузки страницы и, если что-то будет тормозить, затормозит вся страница.
Вы владелец баннера или баннеры вставляют к вам и вы просто советуете?
Так-то владельцу баннера важно чтобы он как можно быстрее появился. А тормозить не должно, если бекенд нормально сделан.
Поэтому и запрос еще один через JSONP делать очень нежелательно.
Очешуеть… Интересно как такие 15% вообще хоть какие-нибудь кадры находят.
Если брать техническую литературу, документацию и т.д. — не применимо, т.к. очень часто приходится возвращаться к прочитанному ранее абзацу, например, чтобы переосознать. Да и скорость тут ограничивается не чтением, а пониманием.
Если брать художественную литературу — то какая разница какая скорость чтения, ведь читаем для удовольствия, и по-моему на удовольствие количество прочитанного влияет не сильно.
При всем этом, у людей которые читают быстро — у них патерны не на уровне слов, а на уровне словосочетаний уже. Я вот например не заметил, что скорость сильно возросла.
По мне — оно может быть полезно только на каких-то маленьких устройствах типа часов, при приеме например длинного сообщения.
Как показывает практика 90%++ кода которое использует синтаксис классов на PHP не ООП ни разу, а всего лишь некоторое подобие неймспейсов и странные попытки упоротых абстракций. А там такое можно накрутить, что ой ой ой, и что лучше бы уж сборники функций. Уж времени на разбор кода тратилось бы меньше, а значит и производительность была бы выше.
Да и наверняка дело не в производительности и экономии серверов, а во времени отработки скриптов и отдачи данных пользователям.
Помню как меня удивила особая магия — таблица с ячейками в 1px, хитрый яваскрипт и в результате эдакая совсем неторопливая реализация нынешнего canvas.
А fronpage`ом у нас вроде не любили пользоваться, больше сохраняли ворд документы как веб страницу :)
Просто решение совершенно безгеморойное. Можно например настроить 1 сервер для кучи проектов, сделать там поддомены img.site1.com img.site2.com.
А далее обращаться как-то вот так: img.site1.com/200x400/background_big_image.jpg и все остальное разруливать яваскриптом.
Хотя конечно это все не прокатит, если речь идет о куче мелких сайтов, которые просто передаются заказчику.
Складывается стойкое ощущение, что интернет она видела только в виде распечатанных скриншотов, которые ей подтаскивают хитрые пацанчики, проталкивающие хитрый и выгодный им бред.