Владимир Чернышев

1. Туда (в рамках желаемой профессии), где платят больше меня не берут

2. Видимо, неконкурентоспособность, прежде всего отсутствие опыта, особенно хоть как-то подтвержденного и не 20 лет назад.

3. Пожалуй, стабилизировался после резкого падения 5 лет назад (уволился и перешёл на «вольные хлеба»)

Мой опыт показывает, что если вопрос ставится так, то не нужно, а скорее всего будет только хуже :) Проверено и не раз, что пересборка ради пересборки (читай — ради понтов: «я тру-линуксоид»), без особого понимания что изменяемые параметры компиляции изменят, профита не приносит, а проблемы создаёт на равном месте (самая простая из них сложность с автоматическим обновлением).

По идее, согласно Закону «О рекламе» от 13.03.2006 N 38-ФЗ

1. Распространение рекламы по сетям электросвязи, в том числе посредством использования телефонной, факсимильной, подвижной радиотелефонной связи, допускается только при условии предварительного согласия абонента или адресата на получение рекламы. При этом реклама признается распространенной без предварительного согласия абонента или адресата, если рекламораспространитель не докажет, что такое согласие было получено. Рекламораспространитель обязан немедленно прекратить распространение рекламы в адрес лица, обратившегося к нему с таким требованием.

Доказать наличие согласия адресата без его персональных данных вообще говоря затруднительно. Но почему именно с НГ — не нашёл ничего подобного, разве что «испорченный телефон»:- весной следующего года возможно будут внесены в Госдуму поправки в УК, Законы о ПДн и рекламе — www.rb.ru/topstory/business/2010/12/02/093631.html

Структуру кадров и системы управления я бы не стал относить к отличительным признакам (то есть к достаточным условиям, да и к необходимым сложно). Электронные коммуникации являются, скорее необходимым условием, но не достаточным. Да и вообще, по-моему, достаточных условий, чтобы считать бизнес интернет-бизнесом, кроме основных каналов взаимодействия с контрагентами, нет. Принципиально ничем не отличаются от обычных компаний, занимающихся, например, посылочной торговлей по каталогам/«телемагазинов» или работающих на рынке контента для мобильных телефонов (без интернет-каналов их представить сложно, но вполне возможно).

Отпишитесь потом как успехи :)

LWin — США, RWin — Рус

Привыкать запаристо, особенно если постоянно приходится набирать на чужих компах под чужими настройками. Но оно того стоит, имхо — когда привыкнешь полностью забудешь о проблеме неправильной раскладки.

Вот это не пройдёт в вашем случае?

Создание произведения в жанре литературной, музыкальной или иной пародии либо в жанре карикатуры на основе другого (оригинального) правомерно обнародованного произведения и использование этой пародии либо карикатуры допускаются без согласия автора или иного обладателя исключительного права на оригинальное произведение и без выплаты ему вознаграждения.

Планшет хочу (с буком пролетел в этом году), но вряд ли это будет iPad — по-моему из-за денег вложенных в его раскрутку и общей ценовой политики Apple его ТТХ не стоят своих денег (то есть или можно найти за те же деньги машинку помощнее, или с такими же характеристиками купить подешевле).

Очень интересно, только вчера компилился всю ночь mono 2.8.1 (пакетов под debian/buntu не нашёл, те что в репах не захотели с linq работать), завтра буду последний monodevelop собирать, потом собирался разбираться как это хозяйство запустить под nginx без apache.

Особо интересует какие подводные камни могут быть при переносе как проектов (веб), так и сборок туда-сюда (прежде всего сборок из моно/линукс в нет/самизнаетечто — достаточно ли будет избегать каких-то либ и соблюдать какие-то правила (именование путей?, кодирование перевода строки?), чтобы гарантированно запустилось приложение или нужно обязательно тестировать)

Mongo или Couch (да и наверняка многие NoSQL) для хранения данных, которые естественно представляются в виде XML/JSON (дерево значений с атрибутами) подходит идеально. Хранить и работать с деревьями в SQL вообще не сахар, а уж когда жёсткой схемы нет…

Пытались внедрить авторизацию работников по их рабочему графику (сутки через трое):
— работники считают возможным поменяться сменами никого не уведомив (должно решаться административными методами, но...)
— передачи смены часто выходит за регламентированное время (в том числе по объективным причинам типа «клиент всегда прав» и «свет отключили»)
— несколько раз возникали форс-мажоры по срочной смене сотрудников в течение смены (грустные истории)
-…
В общем несколько раз нормальная работа была сорвана и это при возможности удаленного администрирования (смены графика уж точно) несколькими людьми, в том числе в расчёте на мобильный интернет.
В итоге отказались, ограничившись контролем по IP для сотрудников не имеющих права входить в систему не с рабочего места, для остальных никаких ограничений

Имхо, следует, прежде всего для разработчиков социальных сетей (необязательно наемных, кстати) — предупреждён, значит вооружен :)

Можно, но с полной историей изменения в публичном доступе — страна должна знать своих героев :)

Пробовал решить схожую задачу:
— данные хранятся на сервере, шифруются на клиенте, сервер даже об алгоритме шифрования не знает, хотя вообще алгоритм симметричный, ключ один и закрытый как следствие
— необходимо было реализовать автодополнение на AJAX (строки относительно короткие, ФИО в общем)

Выкрутился пока так:
— при сохранении поля клиент шифрует данные и помешает в основную таблицу
— дополнительно для каждой подстроки (первая буква, две первых буквы, три первых буквы, ..., всё ФИО) формируется хэш (с солью) и помещается в другую таблицу, связанную с основной (много хэшей для каждой записи в основной)
— при вводе новой записи пользователем клиент отправляет хэш введенных букв на сервер, тот выдаёт зашифрованные записи для которых этот хэш есть (например, все записи, которые начинаются с 'А')
— клиент расшифровывает записи, уникализирует (дубли есть даже на относительно небольшой базе, в теории полных тёзок очень много) и показывает пользователю часть из них (на начальных буквах все показать если и реально, но смысла нет)

Глобальный недостататок:
— большая нагрузка на клиента, когда надо расшифровывать порядка пары сотен записей (при базе в 3000 человек) после ввода первой буквы — на JavaScript это, мягко говоря, не быстро, генерация порядка 20-40 хэшей при сохранении на этом фоне мелочь, как и несколько лишних килобайт на запись в хэше. Что будет когда возвращаться будут тысячи записей для расшифровки — страшно подумать, надо думать над тем, как ограничивать и уникализировать записи на сервере и как из JS браузера вызывать нативные библиотеки шифрования типа mhash и mcrypt

elgg пробовали — не устроило, какой-то он невнятный, как и многие другие варианты (одно из требований — гибкое управление правами в «группах» и гибкая же настройка видимости графов). Сейчас свою «соцсеть» заморозили, но «в фоне» приглядываемся или к Drupal, или к написанию своей на базе фреймворков (чтобы не тратить время на базовый функционал приложения)

where (to_days(now() — to_days(p.data)) <= 10 OR (to_days(now() — to_days(p.data)) IS NULL

Когда-то (но это было давно и не правда) решил схожую подзадачу так: в GUI формировался запрос (дерево либо с листьями «параметр, операция, значение[, значение2[, значение3[ ...]]]]», либо поддеревья с «корнем» «И»/«ИЛИ», после нажатия кнопки «Сохранить» или «Выполнить» он сохранялся как дерево для последующего редактирования и дополнительно рекурсивно преобразовывался в SQL выражение (подзадача была сделать конструктор отчётов по довольно обширной БД анкет, спрятав от пользователей SQL да и вообще табличную природу БД). Если у вас выражения не в SQL в итоге преобразуются, а язык интепретируемый, то можно воспользоваться схожим принципом — получать в виде дерева от интерфейса, если нужно хранить для последующего редактирования/вывода, то сохранить дерево, а главное сгенерировать на вашем ЯП выражение, а потом выполнить его через функцию, во многих языках называемой eval().

Я бы сделал первый вариант, но немного изменил поведение: при заходе на страницу панель развёрнута, через несколько секунд сворачивается (желательно, чтобы она была поверх основного контента страницы) — пользователь успевает получить представление о том, что там есть (в отличии от первого варианта), но и не надо лишний клик делать, чтобы глаза не мозолила (в отличии от второго). Более того, такое поведение может привлечь к ней дополнительное эмоционально положительное внимание, а бегущие строки на страницах (а тем более в статусбаре :) ) многих, включая меня, раздражают, хотя и тоже внимание привлекают.

До релиза IE9 и FF4, имхо, рано, но готовиться можно начинать.