Максим Дьяченко

Библиотеку в сети выложите. Пусть даже непублично. Не думаю что будут запрещать интернетом пользоваться.

Я варвар, я в таких случаях сервак перегружаю. Или как минимум httpd

SpartAdmin

Физически обмен как реализован?
С семеркой незнаком, но в восьмерке я бы сразу грешил на механизм синхронизации или битые пакеты.
т.е. если синхронзируем по ОЛЕ, то смотрим что с кодом для синхорнизации, если фтп то проверяем пакеты на валидность…
внимательно читаем логи обмена. Там иногда бывают интересные вещи. У меня к примеру на одном сервере регулярно пропадает кудато мс-хмл…

Ну и да, раз уж ушли от темы «неожиданно ПРАВИЛЬНОЕ», в сторону просто ошибок, то вот еще пример:
в 2006 году, когда под пхп5 уже начинал писать, но еще так, чтобы пхп4 работал…
Писал библиотеку авторизации.
И мучали меня сомнения… но так и не придумал почему мне все-таки не использовать $_REQUEST вместо $_GET + $_COOKIE.
Не придумал. Написал.
Сейчас библиотека сдохла. Почему? Оказывается в 5.3 появилась request_order.
====
Вот здесь как раз я признаю нарушение самого главного правила разработки: «Слушай свою жопу. Если она говорит не делай — не делай». А все остальное — общие слова. :)

Это неразрывный пробел.
non-breaking space — пробел, причем если он стоит между словами, они всегда будут на одной строке.

Вероятно они таким образом хотят гарантировать, что текст будет выглядеть именно так как выглядит когда вы его редактируете.
Варианты:
1 — забить. Пусть лучше не расползается.
2 — искать настройки с этим связанные, если они есть (понимаю что вы именно это спрашивали, но я не знаю).
3 — регулярки.

3D требует экрана. Кустарная покраска «специальной краской» теоретически возможна, а практически — а где ее взять, как ее проверить и т.п.? Да и чем стену красить уж дешевле таки экран взять.
Для плоского кино можно и без экрана обойтись. Эффект примерно как между просмотром при свет и в темноте — даже пикопроекторы в принципе видны на стене. Хуже но видны.

Ни один оператор не сможет гарантировать быструю доставку СМС.
Даже у опереаторов которые работают с несколькими SMSC периодически бывают задержки.
НИКТО не даст вам гарантий на оперативную доставку в новогоднюю ночь.
идеальный вариант это: по основным направлениям смс приходят в основном очень быстро".
Даже если Вы будете скидывать свои сообщения по SMPP на SMSC оператора который обслуживает конкретный номер, то у него все равно будет своя очередь.
А реально у многих операторов сообщения идут не напрямую а через некоторые «транзитные» SMSC.

Итог — либо мирится с тем что может и не прийти/опоздать или делать контроль по дозвону.
Есть сервисы которые звонят (в смысле к которым по get/post обращаетшься а они звонят). Можно Астериск тот же поднять.
Идеально — получать статус сообщения, и если в течении некоего времени нет статуса «доставлено», то контролировать звонком. Но тут оператор должен быть надежный. Чтобы инфу не на глазок брал, а таки от SMSC конечного оператора.

Вы уверенны, что это необходимо? Как-то видел как программист потратил три дня на оптимизацию кода, который должен был выполнится ОДИН РАЗ. Время работы кода сократилось с 10 минут до пяти.

Вообще действительно человека тут не переубедить. Каждый программист должен пройти через стадию «Какой мудак писал этот код???? Ой, это же я… вот мудак!»

Если можете сказать: «ты должен писать вот так-то, потому, что я так сказал», то скажите.
Если нет — смиритесь :)

Вообще главный виновный это конечно Вы. Какого черта бэкапов нет У ВАС?
Ну да ладно, на будущее будете умнее.
Что касается хостера — если бэкап заявлен, то пишите им официальное письмо с требованиями.
Посылаете через почту или как оно там у вас делается, чтобы был корешок.
когда они не ответят или ответят отказом подаете в суд.
Еще Защита прав потребителя есть.
Наличие лицензий и их необходимость проверить тоже не помешает.

Ну не ИП, а ФОП (СПД по старому) какая разница? :)
Нет деятельности — нет ответственности.
Есть деятельность — берете ТОВ (ООО) или ПП (ЧП).

СПД под сложное что-то лучше не использовать.
Большие договора, НДС — могут иметь проблемы.
К сожалению видел как СПД после тупого наезда налоговой выводит активы (квартиру на родителей, долю в ООО на партнера машину по доверенности.....) и судится по несколько лет с налоговой.
Но повторюсь — нет тела, нет дела. Если у вас будут мелкие договора по текущей деятельности, то переживать не о чем. И СПД только чистый единый брать. Никаких там НДС и прочей муры.

По юрикам — вам стоит определиться с налоговым планированием.
Я не знаю какую схему налогообложения минимизации вы планируете.
В первую очередь вопрос с НДС, и расходной частью.
Из общей информации: Вы можете взять НДСного юрика для того, чтобы копить НДС и убытки получаемые во время запуска проекта. Это уменьшит налоги в будущем, но вызовет некоторые вопросы от налоговой. Но НДС сейчас получить сложно — налоговая «просит» показать оборот перед получением свидетельства.
С другой стороны вторая вводная — бухгалтерское обслуживание фирмы без оборотов == 300грн в месяц. Директор == учредитель и находится в неоплачиваемом отпуске лишь изредка выходя из него что-то подписать.

В общем мало информации. Если сферическую фирму для сферического стартапа, то думаю лучше вообще не открывать ;)

Качать торренты через прокси это паранойя.
Для нормального серфа, даже для просмотра небольших роликов — вполне реально делать каскады.

Если вы и.о. Бена Ладена, то купите себе немного зомби у ддосеров. Буквально по тысяче у десятка зомбоводов, и ВДС в китае, на который все будет стекаться. Вы будете стоять за китайцем, а на фронте возьмите ВДС в москве или киеве для того, чтобы иметь статический айпи. Примерно две трети зомби должны будут гонять левый траффик, строиться в цепочки и распадаться, для конспирации. Основной пулл соберите в несколько десятков цепочек по десять узлов в каждом. Трафик по ним гоняйте параллельно. Обязательно отдавайте симметрично левого траффика чтобы невозможно было без расшифровки понять — вы конечная точка этой сети или такой же зомби как и все. Ну это так, если вдруг найдут китайца. Цепочки естественно сортируем по провайдерам, чтобы усложнить задачу отслеживания. В принципе этого будет достаточно ;)

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

Вообще один туннель довольно неплохо себя ведет. Пинг выростает в среднем процентов на 30%, если сервер правильно расположен (если в основном траффик российский и сервер в М9, то пинг сильно не пострадает). Скорость у меня была 600-800 килобит, что вполне неплохо для серфинга. Двойные и тройные каскады не делал.

Скажу по собственному опыту — когда берешь собственный код который ты несколько лет не видел, то иногда при плохой комментируемости проще переписать заново :)
Конечно с ростом профессионализма код становится все более читабельным, но мое скромное мнение — описание должно быть всегда. Тем более что часто из одного названия переменной не всегда можно понять что она означает. Умолчания у всех людей разные.

Очень много нюансов.
Память на старой машине медленнее. Да, но и обращается к ней целых четыре ядра.
На новой платформе рейд, но при большом количестве малых файлов вполне вероятна ситуация когда будет сильно много сиков, да и от структуры рейда зависит — головы будут гулять параллельно или независимо?
Все VDS на нодах с рейдом поднимают, но частенько бывает, что перемещения головок оказываются узким местом…

Одна и таже информация на диске будет дублироваться на КАЖДОМ жестком.
В зависимости от типа нагрузки это может быть как плюсом так и минусом.

Помню оочень давно писал одно прикладное решение под экселем. Сделал на рекурсивных формулах. Спустя полгода я открыл для себя что в экселе есть вижуал-бейсик и я полностью переписал логику на нем.
Результат до сих пор вспоминаю — на одной машине второе решение работало раз в семь быстрее, а на другой раза в три МЕДЛЕННЕЕ. Различное количество оперативной памяти и различные процессора были. У одной больше проц, у другой больше память. К чему я? К тому что данная задача не сферическая совсем. Мало данных. По разному может быть.

Единственное что можно сказать, так это то, что четыре сферических компа будут есть больше сферического электричества.

Ограничение в кол-во потоков существует, хотя вроде как не все современные браузеры его выполняют. Так что при большом кол-ве больших картинок выигрыш будет.

Но вообще советую не заморачиваться нанооптимизацией, и лучше займитесь контентом (в том числе и картинками) и раскруткой.

Utel хороший вариант если Вы много времени находитесь в зоне стабильного приема. Покрытие слабое, но там где оно есть и хорошее, там пинг и канал отличные. Отчасти недостаток компенсируется национальным роумингом, но опять таки если Вы будете все время в роуминге то смысл?
IT все-таки лучше всего чувствует себя у нас в Одесской области. Практика показывает, что он сильно чувствителен к тому какое покрытие в конкретном месте. Опыт немного противоречит теории, но на стационарных точках я применяю 1х-модемы там где 1х, и EVDO там где есть EVDO. Вот реально чувствуется разница.
Пипл вообще не тестировал, МТС в руках держал, но небольшой опыт меня разочаровал. Возможно так сложились звезды, не знаю.

Постановка задачи слишком размыта.
Вполне может оказаться, что в Вашем случае лучшим будет даже EAV.
Вообще общий подход — составляем несколько списков полей для разных видов данных.
Потом находим общие поля, пытаемся максимально объединить.
Имеем некий «родительский класс» и некий набор расширений.
Далее что у нас в каждом поле лежит? Не целесообразно ли из этого сделать справочник? (например сотрудники, районы, виды недвижимости и т.п.). На самом деле вопрос не очевидный. Иногда проще сделать перечисление или текстовое поле.
Некоторые поля из разных «классов» можно хранить в одном и том же поле базы если это не противоречит логике поиска (К примеру название поставщика или его ФИО в случае Юрлица или Физлица как правило является одним полем).
Когда мы получаем некий каркас надо трезво посмотреть на этот ужас и ответить — а все ли они нам нужны?
Если по полю не будет поиска или сортировки, то возможно стоит несколько таких полей объединить в одно поле «описание» которое заполняется по шаблону при вводе, или содержит сериализованный массив.

Часто целесообразно общую часть данных вынести в общую таблицу, а для каждого «класса» сделать отдельную таблицу со ссылкой на главную. Типа «объекты недвижимости, подробности квартир, подробности домов, подробности участков земли».