Для нормального человека наличие договора и гарантии вселения это естественная необходимость, не требующая вопросов и обсуждений. Достойно восхищения, что Вы считаете эти вопросы к Вашему агенту необходимыми и первоочередными. Это все равно что уточнять какой именно свежести осетрина на прилавке.
Плюс следует напомнить Вам, что агент в самой сделке никак не участвует, договор заключается между хозяином квартиры и съемщиком, поэтому комиссионные агента это единственный реально объективный фактор, которым есть смысл заранее интересоваться у агента. А если агент рассказывает сказки о гарантиях вселения от себя или договоре в котором он лично что-то гарантирует, то надо носить с собой вилочку для снимания лапши с ушей. Особенно когда на вопрос о комиссии отвечают долгим проникновенным постом на тему "нормальный человек о комиссии не спрашивает".😂
Советуем сюда подать объяву http://www.tsn.spb.ru/ - фактически все варианты (заявки в т.ч.) что попадают в агенства - попадают и туда. Звонков достаточно (лучше купить отдельную симку, иначе на годы заспамят). Какой именно агент и/или агенство позвонят - по большому счету все равно, т.к. договор Вы будете заключать с хозяином квартиры. Главное не вестись на "информационные агенства", которые будут трясти денег за список якобы сдающихся квартир - никаких денег до проверки документов и подписания договора, вот и всё.
id ip id_channel time 1 70.88.31.247 613 1261099440 2 95.70.82.140 1016 1261099633 3 95.01.82.140 1016 1261099645 4 67.190.111.224 1388 1261099674 5 77.88.31.247 1315 1261099850 6 67.190.111.224 1502 1261099937 7 77.88.31.247 1715 1261099951 8 95.135.36.200 561 1261099988 9 77.88.30.247 1099 1261099995 10 90.71.02.140 1016 1261100724 11 95.71.82.140 1016 1261100731
select count(*), id_channel from table group by id_channel order by count(*) desc limit 1
Во-первых, лимиты для анонимов достаточно большие, поэтому заголовок и обсуждение "обязательной идентификации" как-то странно звучит. Не обязательная она, до сих пор добровольная, просто лимиты побольше с ней.
Во-вторых, что-то нам подсказывает, что идентифицированный юзер превысивший лимит для "анонимов" получит "письмо счастья" от налоговой, с просьбой объяснить свою деятельность. Что с одной стороны хорошо, т.к. теперь ясно что именно нужно не превышать, что бы не запалиться. С другой стороны плохо, т.к. становится понятно, что при нормальных объемах яндекс сам стуканет.
Вывод напрашивающийся и самоочевидный. На фига нужна идентификация, если ей не пользоваться? Тем более тут в темах уже пробегала инфа, что в налоговую дергали из-за яндекса (искать лениво).
Во всем этом интересно как поступит вебмани. Они хоть и из Белиза, но на их же сайте появилась за последний год куча информации на тему "как надо декларироваться", через ГА выводить уже мало кто хочет опять же из-за налоговой. Т.е. ВМ конечно может наплевать на этот бодрый закон, с одной стороны. А с другой стороны может просто не афишировать не наплевательство, и вот тогда будет засада.
Не, это Вы плохо понимаете в работе альфаклика:)
1) По смс приходит пароль для входа.
2) По смс приходит пароль для проведения операции. При чем в смс видно ФИО кому и сумма. И без этого кода никуда ничего не уйдет, сколько бы троян запросов на перевод не сделал. Какой троян может заставить ввести код пришедший по смс на операцию в пользу левого человека?:)
У вебманей есть смс извещения об операциях (насколько мы помним). Так что система уже отработана по сути. Осталось только прикрутить ее так, что бы она была превентивной, а не пост-фактум, т.е. допустим что бы вместо граф.кода протекции при переводе, нужно было бы вводить код присланный по смс. Цены на смс-ки у ВМ весьма бюджетные, не разоришься. Ну а кто не хочет - мог бы и не включать эту систему.
Вообще реально. ОЧЕНЬ напрягает в вебманях то, что нельзя отвязать подтверждение операций от компьютера полностью. Вход входом, но как правильно отмечено выше, после входа - делай что хочешь. Как вариант видим смысл работать через xml интерфейсы, а классик вообще снести, но это не для всех операций годится. Хотя для большинства все-таки да.
ООПисты настолько часто аргументируют переменными вида $xx_aaa_zz_bbb_ccc , нахваливая var::$server->http_host, что возникает острое ощущение, что о массивах им не известно, а идея называть переменные понятно в голову не приходит:)
Чем $var['server']['http_host'] хуже var::$server->http_host ? Или опять же то же vars('get','server','http_host') если хочется использовать функции и завернуть переменные?
Учите матчасть.
опкоде кэшеры убыстряют код в целом, так что хотя они must been, но проблему-то на самом деле не отменяют. А иногда даже подчеркивают, за счет того, что на фоне уменьшения времени загрузки - время выполнение кода в процентном соотношении становится заметнее.
Хам и лгун.
С собачьими сайтами намутили Вы, непонятно зачем притянув за уши надпись из нашей подписи.
Про трехкратное увеличение скорости мы опять же не говорили, и не отмазывайтесь кавычками.
То что Вы не знаете что такое оптимизация и бенчмарки - нас не удивляет.
А вот на скобочках у Вас определённо пунктик.
А, религиозный фанатик. Микрософт святая икона и "4мб enough for everyone".
Симптомы на лицо:
1) В теме уже приводилась ссылка на java.sun
но Вы старательно изображаете, что о существовании java.sun не знаете, ведь это не микрософт.
2) Нелепый вывод в адрес скрипта. Вы понятия не имеете что за скрипт, но заранее говорите что он кривой. ЧИсто совковое "Не читал, но осуждаю" (с) с примесью телепатии.
Процедурки все-таки быстрее:) Вопрос в том, что не всегда они настолько быстрее, насколько ООП нужнее.
Забудем на секунду об ООП. Мы несколько лет назад занимались оптимизацией одного скриптика. Из изначальных 0.5-1 секунд на генерацию страницы в среднем сделали 0.01-0.02 секунды (и за счет кода и за счет кэширования) при сохранении совместимости. И что? Думаете это кому-то сильно надо? Реальная необходимость была дай бог у 1% из тех, кто его ставил. При этом все у кого были проблемы с нагрузкой на прежней версии, имели уже достаточный доход, для аренды сервера. Поэтому смысла особого не было в этом, и проект мы забросили.
Face the truth - никому не нужна скорость работы в стандартных скриптах. То о чем Вы говорите - это "premature optimization - root of evil":)
Если скрипт общего назначения и нужна скорость - приходит оптимизатор, бенчманкирует и улучшает. Если индивидуальный - да изначально делается шустрый индивидуальный проект. Но это когда скорость реально необходима, а не просто "на всякий случай". При чем оптимизируют "плохие" места, а не делают изначально "ляпоту".
Как мы уже сказали выше - в узких местах или небольших скриптах - можно получить хороший прирост по памяти и заметный по скорости за счет процедурок. Но это такой же уровень как... ну цепляние сишного кода в пхп (в виде модулей например) или асма в сях (в т.ч. инлайнового). Т.е. вещь полезная безусловно, но узкоприменимая и надо иметь голову на плечах что бы это грамотно использовать.
Конечно, только поэтому заказчик и выбирает фреймворки, что бы потом послать программиста (ирония моде он).
Ведь совсем не бывает ситуации, когда программер по тем или иным причинам исчезает, это ж такая фантастика. И совсем фантастика когда программер нужный оказывается занят в других проектах и у него нет времени. И просто абсолютно невероятно, что бы проект разросся так, что бы понадобилось еще 1-2 программера, которым прийдется втыкать в этот индивидуальный код.
Вы серьезно в это верите? Собственные решения для любых задач? Но не фреймворки, без граблей и без лишнего кода? Как-то даже руки опускаются это комментить. Покажите хотя бы пару таких, а? Может их купить можно? Не, не продают? Они такие секретные? Ах да, они такие совершенные, что их кому-то показывать или упаси боже продавать ни в коем случае нельзя:)
Если речь о паре десяток строк - может быть и не стоит. Если речь о паре сотен, то возможно jquery получится компактнее. Честно говоря нам с трудом вспоминается проект, в котором яваскрипт ограничивается парой десятков строк.
Фактически Ваша аргументация сводится к тому, что "надо выбирать свое потому что оно свое" (с). Умные жквериписатели НЕ будут редактировать код жквери. Потому что это либа и она должна быть неизменной. И вся суть фреймворков в том, что бы уметь использовать их АПИ, а не лезть внутрь.
Напомним, php сам по себе в общем-то фреймворк. Надстройка над c. А cи надстройка над асмом.
Перфекционизм зло. Если проект хоть сколько-то важный, он будет меняться. Если он будет меняться, то важна динамика. Пока Вы пишите выхолощенную гостевую книгу версии 2.0, конкуренты в это время напишут ... ну скажем амазон.ком.
$("#tab1").slideUp(slow) - вот эту "фантазию" мы можем пойти и найти в мануалах по jquery. При чем наверняка 50% прогеров эти мануалы уже читает и знает. А вот malls("tab1").DoSomethingBeautiful извините в мануалах Вы не найдете. И Ваш пример с аяксом выше что Вы приводили - просто шикарен. Потому что в Вашу функцию надо сидеть и втыкаться, пусть и не долго. А $("form").post понятно и так.
Почти так.
1) Если нужны ООП-шные фичи в проекте, то используется ООП.
2) Если не нужны ООП-шные фишки в небольшом проекте, то по фиг что использовать.
3) Если проект делает команда, то только ООП.
4) Узкие места или небольшие скрипты в случае критичности использования памяти и проца - лучше делать на процедурках
Раз пошла такая пьянка, то спасибо за разрешение и тоже отметимся и в этом топике:)
Медленно и печально покупаем ЯД за вмз и вмр. Можно сказать постоянно, т.к. поменять надо не очень мало. Обязательные условия: перс.аттестат у Вас (или нормальный профиль на форуме здесь как минимум или хотя бы на фри-лансе.ру), ЯД Вы переводите первыми (можно с протекцией, но все равно Вы первыми), примечание указываем какое мы скажем. Курс - 1 вмр за 1.05-1.07 (в зависимости от) яда.. и на вмз - разный (сейчас 33.48-33.98 в зависимости от ).
Обращаться - только в асю, сразу говорить где нашли объяву, сколько есть яда и свой вмид(или кошелек).
Все примеры - это любая вводная глава по ООП и описание отличий от процедурного подхода. Копипастить?
Более точно будет сказать, что "в интернете не все используют форматирование кода которое Вам нравится". Вы действительно настолько не знакомы с разными стандартами, что считаете скобку на след. строке единственно правильным решением?
Вообще "Холивар" про скобочки порадовал. Мы даже сейчас не будем говорить о том, что оба подхода со скобками имеют право на существование. Но господи боже, переформатировать код под удобное восприятие это 2-3 кнопки в бьютифайере каком-нибудь. Что за прошлый век?:)
Кгм. И каких проблем ждать при засорении глобальной области видимости? Аргумент притянут за уши.
Заводим переменную типа $secure_data и спокойно таскаем ее где надо. Проблем при многократном вызове ровно столько же, сколько при ООП-шном vars::$secure_data->variable1 .
Хотите на процедурке упаковать переменные - да нет проблем, function get_var($variable,$value) { static $vars=array(); и все.
Нас вообще удивляет иногда аргументация ООП-шников на тему "а вот это в процедурном не сделаешь". Такое впечатление, что где-то раз и навсегда вызубрили несколько преимуществ ООП из плохой книжки и подумать ну никак:) Описанный "пацанчег" из нашего первого поста сделает любым из вышеперечисленных способов, а потом выдумает еще 2. Вопрос нужно ли это? Ответ неоднозначен. На большом проекте - да, нужно для унификации. На маленьком - а надо ли выпендриваться?
И вот здесь Вы нас окончательно испугали. Настоящий специалист не имеет "стандарта" мышления. Он может спокойно пользоваться любым из подходов, выбирая тот, который лучше подходит к конкретной ситуации. А уж если специалист не только не может обоими подходами оперировать, но и с коллегами на тему другого подхода затрудняется общаться, то это вообще какой-то бардак.
Нам трудно отвечать за людей, у которых возникнет такое впечатление:) Из наших слов совершенно не следует, что скрипт в целом будет работать в 3 раза быстрее за счет смены стиля.
Кроме того, мы прекрасно знакомы с аргументом "кривой цикл замедлит все куда быстрее чем стиль кодинга и т.д.". Он неплох для тех, у кого кривые циклы:) Если циклы не кривые, то он уже не действует.
Но мысль мы уловили, требуется развернуть исходную фразу, да?
1) Бенчмарки. Посмотреть бенчмарки не сложно, достаточно взять любой простой класс или любой набор функций, переписать их и протестить оба варианта:) У нас точных цифр сейчас нет, но мы это делали.
2) Абсолютные цифры. Ну, как бы понятно что если класс состоит из 1 функции, которая берет 500мб файл, парсит его и возвращает результат, то особой разницы между процедурками и ооп не будет. Но опять же, какой смысл в таком тесте?
3) Сравнение ооп и процедурок по памяти и скорости. Тут имеет смысл что-то выжимать, если вызывается много раз одна функция и/или класс достаточно объемный. Например небольшой скрипт счетчика (да, мы знаем что для счетчиков и прочего в таком стиле пхп не идеален) изначально был на классах, имел честь кушать 8мб и работать около 0.12секунды. На процедурном подходе стал кушать 4мб и работать около 0.08секунды. Просто за счет тупой смены стиля. С нашей точки зрения это worth it. Понятно что на скрипте типа vbulletin такой разницы от смены подхода не будет, будет допустим 128мб и 1секунда против 126мб и 0.99 секунды:) Но опять же, bottle neck можно учитывать, иногда, в меру, не увлекаясь.
А вот здесь согласимся на все 100. Правда немного с другой стороны.
Яваскрипт, особенно аяксовый, очень хорошо подходит для объяснения сути ООП. Когда на странице 20 объектов кнопка, и к каждому по 3 метода - онклик, онмаузовер и онмаузаут и у каждого набор свойств... то достаточно легко становится понятно зачем нужны объекты "элемент страницы", и набор методов и свойств для них. Это просто логично.
В пхп даже процедурный-то стиль не всегда нужен, иногда достаточно "flat coding". Т.к. редко есть объекты, которые нужны по несколько раз и могут по разному вызываться.
p.s.: больше всего любим зендовский бьютифаер. Во первых он 100%-но встроенный и нажатием одной комбинации делается "всё клево". Во вторых у него нравящиеся нам настройки по умолчанию. Второй из любимых - polystyle, но он standalone и его пришлось долго настраивать, юзаем его т.к. изначально встроен во второй наш любимый иде phped от nusphere.
Сапе клиентской класс конечно нужен как зайцу стоп-сигнал ... с одной стороны, а с другой стороны - чем мешают-то? Ничем. Поэтому в данном конкретном примере - с сапой - разницы нет.
В общем скучный холивар-то Вы затеяли, опоздали с ним лет эдак на 7 минимум:)
Задайте себе вопрос - как появляются классы в проекте если взять некоего абстрактного программера.
Сначала он пишет на функциях, потом ему нужны доп.фишки, он их начинает реализовывать опять же на функциях "с хитринкой". Потом он все усложняет это... и докатывается до того момента, когда его "хитринки" реализуют 90% того, что реализовано в ООП изначально. Тут он втыкает что умнее использовать классический ООП, который всем понятен и известен, а не свой велосипед. И становится ООП-шником.
Если пацанчег умный, то он помнит, что там где "доп.фишки" не нужны - достаточно использовать функции и не надо заниматься оверкиллом. Вот и всё. Холивар закончен.
Это что касалось чисто программинга. Плюс ООП безусловно имеет ряд преимуществ в больших проектах. Сопровождать "классные" проекты намного удобнее. Опять же, все "удобные" классные фишки в смысле сопровождения можно было бы сделать и на функциях... но... это был бы опять же велосипед. К тому же есть поддержка классов во многих ИДЕ средах. Если допустим у Вас 200 функций, то это естественное разделение их по блокам - по классам.
И еще небольшой довесок - приемы программирования. Разбуди ООПшника ночью и спроси что такое синглтон или фабрика - он оппа и воткнет о чем речь. А функциональнику Вы будете 2 часа сначала объяснять что это такое и как надо реализовывать и почему. Сокращает время.
Тут главное чувство меры на самом деле.
Принципиальной разницы - нет. Но иногда в проекте нужны ООП-шные доп.фишки. И тогда глупо не выбрать его.
Если конечно не идет речь о мегаскорости и мегапроизводительности. Потому что функции все-таки жрут в случае пхп раза в 2-3 меньше памяти в целом и все-таки быстрее чем классы.
Вебманям от этого стало лучше.
Обменники имели некоторый "иммунитет" против грязи. Т.е. им достаточно было подать информацию в СБ и никто их не блочил за получение грязных денег. А вебманям приходилось расковыривать цепочки, блочить всех, натыкаться на анонимный яд.
Сейчас каждый кто меняется - меняется на свой страх и риск. И если получил грязь, то ССЗБ и можно не морочиться с тем, что бы разобраться в том, что это типа был обмен, а сам человек не при делах и искать кого-то дальше по цепочке. Можно просто поблочить до возврата и всё.
Не исключено что и яду стало от этого лучше. Раньше в него скидывали деньги что бы вывести, по сути отмывали, оно ему надо? А что бы платить за что-то - перекидывали в вебмани и платили уже там, да и хранили тоже в вебмани. А теперь если получил яд от кого-то, то уже 20 раз подумаешь - надо ли перегонять яд в вебмани, или умнее заплатить что-то в партнерский магазин или вывести через ядовские механизмы. По сути бОльшая закрытость яда может сыграть ему на руку, вместо того что бы выводить из него деньги в вебманьки - будут платить в партнерские магазины. И реже будут перекидывать в ВМ для хранения.
И даже другим платежным системам стало лучше. ЯД меняют на ВМ в частности через РБК, или через альфу, или через другие промежуточные валюты.
В общем на самом деле стало лучше всем, кроме пользователей:)
