throughtheether

У меня была такая ситуация, косяки и затыки в проектах были постоянно. Решил просто: выучил программирование. Теперь:
1. Если программист заламывает высокую цену - приземляю его
2. Если программист говорит долгие сроки - ускоряю его
3. Читать код можно только научившись писать код
4. Я разбираюсь в архитектуре систем и оцениваю предлагаемые решения грамотно
5. Ваша идея ничто, всем пох на неё

Почитайте мой вопрос полугодовой давности, я не послушал всех этих людей и не жалею Можно ли стать эффективным менеджером проектов без знания программирования? и вообще слушайте тех у кого есть деньги, а не тех у кого их нет ))

В твоем случае лучше взять на фрилансе менеджера проектов и оставить ему технические вещи.

Объединить вместе в один массив точки начал (с доп.полем "+1") и концов (с доп.полем "-1") отрезков и отсортировать его по координате :
[11,+1],[17,+1],[21,-1],[32,+1],[37,-1],[42,-1]
А затем один раз пройтись по нему накапливая сумму доп.поля.

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

На типовые задачи конечно лучше snmp - быстрее ввод, на выходе уже почти структурированная информация. На по сложнее ssh/telnet. Но это если надо будет запускать всякие трейсерты, lookupы, пинги...

Скорее всего - это баг маршрутизатора, меняйте частоту \ обновляйте прошивку \ меняйте режим с n на g и потом проверьте.

Лучше поставить скорость wifi пониже (допустим 25MB в режиме G).

Т.е. происходит ошибка определения скорости соединения или расстояния до клиента (скорее всего) и за-за этого роутер пытается подстроить скорость линка и всё ломается.

Никаким, вот прямо так, работа компрессоров требует больших вычислительный ресурсов, для маршрутизаторов это недопустимая роскошь, в них стараются использовать минимум программной и максимум аппаратной логики. Можно конечно использовать приоретизацию трафика (QoS), но в вашем кейсе она также будет бесполезна, просто расширьте канал.

Может этот компьютер в целях экономии электроэнергии выключает сетевой интерфейс?
Попробуйте выключить эту функцию:

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

Методом Ньютона (либо же касательных) будет категорически быстрее чем половинным делением, при том, что код будет совсем незначительно посложнее.

Из того, что вы написали:
1) сделаете из пары роутеров протоколами резервирования
2) смотрим таблицу router perfomance
3) BGP умеет практически каждый роутер, если конечно не нужен full view
4) ACL тоже умеет каждый железный роутер

От себя, если с баблом проблем нет и не нужен full view, возьмите что-нибудь из 3900. А если совсем денег не жалко, можно смотреть дороже.

Резервирование на железном уровне внутри одного роутера - миф. Ставьте два отдельных и включайте балансировку.

Python / Django.

Мода на Ruby / Rails прошла. Владельцу проекта нужна предсказуемость и прозрачность работы фреймворка, на котором построен его проект. Этого достаточно сложно добиться с "магией" Ruby, которую понять то сложно, если пришел с других языков. Это первое.

Второе, как ни крути но Ruby медленный. Да я пробовал последний Ruby 2.1 с последними Рельсами, и говорю он медленный. Да я знаю, что можно запускать Рельсу на всяких passanger, thin и unicorn. Знаю что есть JRuby и прочие реализации. Знаю что можно закешировать все что можно. Я это пробовал. И все равно, Руби - медленный. К слову реализаций Python тоже много, есть и Jython, PyPy, Stackless Python. Django на фоне Rails выглядит просто молнией, быстрый старт и прозрачность работы. Нет никакой магии, все понятно как работает от начала и до конца.

Третье, Django достаточно консервативный фреймворк. В него никогда не добавят какую-нибудь сомнительную фичу, как это бывает в Rails (например никому не нужный turbolinks). Скоро выходит версия 1.7. Где достаточно много плюшек действительно нужных.

Вам будут говорить про разветвление Python на версию 2 и 3. Что все плохо. Не верьте. Это все ерунда. В настоящее время большинство популярных библиотек уже давно на Python 3. Django, Flask уже давно. Мы все новые проекты начинаем на Python 3 и проблем никаких нет.

На счет NodeJS. Использовать можно, но... Неудобно. Переносимость кода client side < - > server side по факту равна менее 10%. Сейчас большинство используют NodeJS как платформу для запуска нужных тулз для сборки фронтэнда, например Grunt / Gulp, Bower и прочее. Конечно пакетный менеджер npm.

Надеюсь ответил на ваш вопрос.