Вот я не могу понять как раз, как это сделать. location же не знает про аргументы. Как разделить зоны (keys_zone) по $is_args — не знаю. Возможно, упускаю что-то очевидное…
сделал. Получил ip 192.168.147.138. Пингуется. И видно, что пакеты приходят в виртуальную «сетевуху». Пытаюсь достучаться телнетом на порты гостевого сервера: «Connection refused». Windows Firewall выключен. Не понимаю…
Внутри гостевой ОС по этому ip сервер нормально отвечает.
Не буду называть язык и организацию, чтобы обсуждение не происходило в духе «Ха-ха! Ну и идиоты у вас работают». Там разумные ребята, просто они немного потерялись во времени.
Да, компания упирается в старые неэффективные технологии (не только язык и CMS, но и сам подход к разработке). Да, мне хочется заюзать питон, т.к. он лучше (см. ниже) и с ним не будет проблем в ближайшем будущем. Есть и другие варианты, но нельзя заменить один язык на три языка — будет полный коллапс в производстве и поддержке. Нужна последовательность в выборе технологий.
Вот некоторые доказательства того, что наш язык плохо пригоден для разработки (кратко):
— нет и не может быть IDE, только подсветка синтаксиса в паре редакторов
— нет инструментов для отладки
— только cgi и только apache
— есть if, но нет else if
— нет массивов
— нельзя работать с бинарными данными
— очень маленькое сообщество, практически только из сотрудников компании
— нельзя построить цепочку вызовов методов
— нельзя прервать выполнение функции (нет return)
— обфускация на уровне синтаксиса
— нет внешних модулей и библиотек
— проблемы с юникодом
— огромное потребление памяти при попытке работать с пользовательскими объектами
Этого достаточно для доказательства неэффективности? Наш язык похож на российский автопром. Машины тоже имеют колеса, даже ездят. Покупать их очень патриотично. Но что-то в них не так…
Не на кого менять. В России действительно мало больших организаций, которые применяли бы готовые современные технологии. Если я ошибаюсь, скажите, где можно взять опровержение.
На деле: сделаны четыре проекта на питоне, три из них с использованием Django. Весь процесс «залогирован» в таск-менеджере. Мне говорят: «ну и что, на Brainfuck это можно сделать так же быстро», хотя я уверен в обратном. Делать большой проект на двух технологиях параллельно — нет времени.
На сервере? Тогда мы пойдем по пути GWT — крутой серверный код, который формирует нечитаемый JS. Не могу сказать, что это плохо… Но для наших задач хотелось бы с другой стороны зайти.
Нет. Мне нравится extJS, но в этом случае квадратно-гнездовое программирование мне не подходит. Представьте, что нужно сделать форму, где все элементы управления круглые. Вот это в первом приближении будет описанием моего интерфейса :-)
Мне кажется, в таких ситуациях необходимо в какой-то момент признать, что кто-то сделал лучше и перейти на более совершенную технологию. Иначе получится примерно как с российскими автозаводами.
Здесь важно не только уметь «написать хотя бы так же», но и уметь поддерживать свой продукт на уровне в течении продолжительного времени. Например, когда я выбирал sphinx в качестве внешнего индекса для базы данных, он не умел много из того, что мне было нужно. Но прошло два года и я с радостью удаляю свои «заплатки», потому что многие вещи теперь реализованы разработчиком.
Очевидно, что гугл имеет все возможности как для создания, так и для развития собственной файловой системы.
Тогда это действительно вина руководства. Мне встречались консервативные ребята, которые считают, что втроем можно создать язык программирования, ORM к нему, фреймворк и CMS. И все это будет сделано за год и лучше всех. Программисты копаются в своих многолетних наработках, даже выдают какие-то результаты. Все довольны. Этот маразм может остановить только давление рынка, который каждый год все больше подстегивает разработчиков: нужно делать более сложные продукты за все более короткие сроки. И это давление рынка может чувствовать только менеджмент. Из задача — поставить разработчикам правильные цели. Если бы я, как разработчик, был предоставлен сам себе, то, возможно, тоже делал бы какой-нибудь свой фреймворк или язык. Но рынок требует результатов, поэтому приходится пользоваться несовершенными, но готовыми решениями.
"proxy_cache_key" directive is not allowed here