Офисный владелец так и сказал - гони к нам, но поскольку там щас смена руководства, то не факт что новые ребята не начнут мутить воду и не войдут с вымогателями в долю. Ну да это пока беспочвенные страхи. Представиться он как то странно что-то пробормотал, лениво так цедя слова. Но была хреновая связь плюс я такие вещи сдуру не запоминаю, хоть записывай все на диктофон. Письма никакого не было, кстати я об этом тоже подумал, спасибо за подсказку.
Семен Семеныч, подобных вещей можно найти много, вопрос в том относится ли это к компании которая не занимается производством? Например, она предоставляет услуги по вывозу дайверов на рыбалку :). Также из перечисленного совершенно непонятно - инструктаж я могу проводить сам по себе, либо мне все же для этого ученая степень нужна?
Касательно "огнетушитель должен быть" крамольный вопрос - какой размер? Нормативы наверное должны быть?
dspu, помещение снимается, то есть не собственное. В офисном центре есть все - автоматы пожаротушения, дымные конденсаторы на потолке и все остальное вплоть до громкоговорящей связи на потолке которую они третий день тестируют в рабочее время :). Таблички на стенах с эвакуацией в коридорах есть, а в каждом квадратном помещении с одной дверью они тоже должны интересно быть?
Цифры размыты, глаза устают быстро если денежек много. Особенно неудачная единица, пятерка хреновая (тонкая очень вертикальная линия) и ноль тоже плохой. Остальное еще куда ни шло. Правда семерку не видел, а лезть в ЯКА лениво.
Почитал ради интереса комментарии в блогах (оказывается тема про Гордона-Задорнова какой-то день на главной Яндекса висит). Что повеселило несказанно - лейтмотив подавляющего большинства сообщений. Типа "Задорнов мракочачит мозг дуракам, которых у нас 90%, образования нет и они все это примут за чистую монету". Какой гад!
"Блоггеры" (это те которые по команде из ящика посты строчат) вероятно думают что они в эти 90% не входят.
Ну фиг с ним, наукофилов с бородами понять можно. Мы типа жизнь положили на отвоевывание своих член-корреспондентских билетов "окодемийнаук" от конкурентов, а тут пришел клоун типа и ну давай поперек батьки крамольные мысли вслух говорить на всю страну. Задорнова понять можно - у него хлеб такой - публичные провокации интеллектуальные устраивать. Кто не поймет - может почувствует себя лучше от "приобщения к истине" и еще раз на концерте забашляет. Умный дядька, примерно как Жириновский (тоже умнейший манипулятор). Хотя тут по всему видно на его имидже нажиться хотели, он то ничего нового не сказал. Ну еще можно понять тех кто во всем видит еврейский заговор и тех кто наоборот. Им положено.
Но тех кто сидит и пишет в своем очередном фрэнкоблоге пост про то, что видел по зомбоящику в стиле "люблю-ненавижу"... Не понимаю пользы обсчеству.
У меня вот доска объявлений по свадебным платьям, в порядке эксперимента. В день до 10 объявлений о продаже Б/У свадебных платьев. Пишут бывшие невесты, понятно. Аудитория специфичная. Так вот из 60 объявлений за последнюю неделю только одно (!) можно было размещать на сайте без корректуры. В остальных можно было насчитать от 3 до 20 (локальный рекорд) ошибок по одной только орфографии, про запятые и прочие тонкости оформления молчу. Я конечно понимаю, что в школе наверное слова "кринолин" и "корсет" вероятно на "русском языке" не проходят, но когда "бисер" с двумя "с" пишут становится не по себе. Повторюсь - это не единичный случай, это системный сбой.
Я так думаю что прежде чем болтать о происхождении языка его выучить для начала нужно. Чтобы хотя бы на троечку, но на твердую.
Чтобы зеленый лук не горчил его нужно подавить толкушкой, поэтому он обычно идет первым ингредиентом и оказывается на дне кастрюли (где его собственно и давят).
Как минимум изменился HTML код выдачи, у меня в HTML пропали все закрывающие тэги </li>. Пришлось подправлять парсер позиций.
pauk, ты неправ. Тему эту поднимали, уже мильен раз. Нельзя так однозначно говорить о CMS без СУБД, у любого решения есть плюсы и минусы. На файловых CMS эффективно работают многие крупные сайты. Перенос данных из движка без СУБД и с СУБД принципиально ничем не отличается по сложности.
Для CMS, в классическом понимании СУБД совершенно точно не необходима по двум простым причинам:
- база данных сайта на 95% работает на чтение, и только на 5% на запись. А организовать эффективное чтение данных даже из файлового хранилища - достаточно просто на алгоритмическом уровне. И, кстати, это организовать можно более эффективно, чем в известных СУБД по ряду параметров, например по расходу памяти. Просто нужно понимать алгоритмическую специфику конкретной CMS и уже создавать под это наиболее эффективный алгоритм работы с данными. Что касается записи данных в базу, то тут могут быть проблемы при необходимости много и часто данные апдейтить. Но стоит заметить, в большинстве случаев CMS без СУБД не являются супермногофункциональным инструментом, они заточены под определенный класс задач, с которым справляются лучше остальных.
- все что не является простым списком (страницы сайта, форумы, каталоги) в реляционной СУБД хранить неудобно, они просто не предназначены для удобного хранения иерархических структур или графов. Приходится пихать в дополнительные таблицы и поля лишнюю информацию, соответственно, повышаются вычислительные затраты на выборки и пр.
Говоришь сложно понять разработчиков? Тогда нужно посмотреть на выгоды, которые дает движок без СУБД разработчику и конечному потребителю (клиенту-владельцу сайта).
1. Простота инсталляции и низкие системные требования. Дешевизна хостинга.
2. Простота переноса сайта с девелоперской площадки на хостинг и обратно, высокая скорость переноса (простое копирование файлов по FTP всегда проще таскания базы с машины на машину).
3. Отсутствие затрат на системное администрирование базы. Для крупных проектов на MSSQL и Oracle есть отдельные люди только под администрирование и оптимизацию СУБД.
4. Выигрыш в скорости работы при выполнении определенных задач.
5. Возможность разработчику при разработке CMS выбирать на свое усмотрение между затратами памяти и скоростью работы при реализации тех или иных частных задач.
6. Отсутствие проблем при локализации контента под разные языки.
7. При необходимости данные легко можно поправить "ручками" с помощью обычного текстового редактора.
Из недостатков для разработчика могу назвать только два:
1. Отсутствие некоторых механизмов, которые могли бы делать операции в фоновом режиме по таймеру (jobы). Правда это и так присутствует не во всех СУБД.
2. Необходимость реализации полнотекстового поиска по базе "руками".
В нашей "Twilight CMS", например, не используется СУБД в общепринятом смысле (MySQL, M$SQL, Oracle и т.п.). Но это не означает, что не используются те же алгоритмы поиска, сортировки, вставки данных, которые используются в этих продуктах, индексы и прочее. А это определяет основные потребительские свойства - скорость работы и надежность.
Похоже я первый проголосовал "нет" :).
У меня правда был один опыт. Сайт на 4000 страниц, внутрь боты не ходили. Сайтмэп был сгенерирован через Sape. Положен и прописан в robots.txt. Google пришел его попробовать через день. Яндекс через 8. Прошел месяц, толку не было никакого совершенно, как боты внутрь не шли, так и не шли. Поменял стратегию именования URL - убрал sitemap совсем - через примерно 2 недели почти все страницы появились в индексе.
Правда была одна штука... Яндекс уже после опыта почему то отдельно анонсировал что теперь умеет читать sitemap.xml, хотя на нем же самом была инструкция и уверения что он все умеет значительно раньше. После этого не проверял.
Для сайтов в 15 страниц сайтмэп не нужен вообще, его и так пауки просканируют за один-два захода (если отклик нормальный).
Из своего опыта - подобную фишку опробовал (в ограниченных масштабах) пару лет назад. Скрипт пишется за минут 10. Результат не очень хороший, поскольку в любом случае статистику смотрит очень ограниченное число народа, по реферерам тоже мало кто ходит. Трафик получаемый таким образом на мой вгзляд совершенно нецелевой и бессмысленный. Хотя, наверняка кому-то и такой сгодится. Но по затратам времени и трафика на простукивание чужой статистики ИМХО это один из самых бессмысленных методов привлечения посетителей.
Ой зря вы так. Во-первых, это совсем недавно было. Во-вторых, если недостаточно можно и более свежих событий найти, которые тоже тогда были в порядке вещей, а сейчас воспринимаются как жуть какой бред. Вплоть до расстрела белого дома из танков, когда несколько десятков человек так и не нашли до сих пор.
Общественное сознание очень пластично и быстро перестраивается. Причем скатить его до "бей не наших" гораздо проще чем поднять до "возлюби ближнего своего".
Ну, тут я маху дал :). Просто в последнее время у меня много было подобных задач с обычными полями, потому у меня там всегда связки были onkeypress+onchange, ну я и...
Но если по onchange работает то уже дело.
Да он не об этом, а о том что путь то есть, только картинку по нему показать будет якобы нельзя. Насколько я понимаю, превьюшка локальная, doggystyle, то есть пользователь со своего винта будет выбирать файл и сразу видеть его в превью после выбора. Все прекрасно будет работать, не торопитесь называть это бредом. Другое дело что я не совсем понимаю зачем это нужно, поскольку если пользователь не знает какое содержимое картинки которую выбирает - он в Explorer включит режим просмотра тамбнейлов. А если знает - то показывать её после выбора будет правильно наверное только с точки зрения эстетики. А для удобства пользования это будет наверное не очень (лишняя информация). Хотя если форма длинная, или что-то типа анкеты с фотографией делается, чтобы типа визивига было... В общем нужно пробовать, такие неоднозначные вещи только экспериментально проверяются на предмет удобства.