Вас это сильно напрягает, как я погляжу? :)))

Т.е., необходимость учиться на чужих ошибках не очевидна? Но вот тут есть другая проблема. Мне приходится заниматься этим самым пресловутым «энтерпрайзом», о котором много, долго и нудно рассказывают иной раз на страницах ЛОРа. И a priori не интересны создатели студенческих hello_world. Вот и приходится равняться на лучших, анализируя их промахи. Причины такого подхода могут быть Вам не очевидны, но я и не надеюсь... :))) Да и по барабану как-то... :)))

Эммм... А что, предлагаете на Ваших? :)))

Думаю, у Вас их нет. Ибо still do nothing... Просто по факту того, что где-то на первой-второй странице Вы узнали зачем нужна одна из версий этого Вашего Ребе. Но я терпелив. Я... подожду... :)))

Вот и приходится равняться на лучших

Вот и приходится имитировать деятельность

анализируя их промахи

сочиняя ерунду

Fixed

анализируя их промахи

Копец.. на это кто-то покупается что ли. Т.е. вместо решения проблем пользователей вы анализируете проблемы фейсбука.. а почему не каменные лица на марсе?)

Производился анализ ряда пакетов по заказу. Что именно искалось — дело десятое. Где именно (какие именно пакеты попали в «прозекторскую») — то же.

Повторюсь — общие фразы не нужны. Если ваши «80 процентов» были взяты с потолка, так и скажите.

Нет, я все понимаю, не нужно мне объяснять как важно анализировать ошибки фейсбука и каменные лица на марсе.

Все ок.)

А кто Вам это сказал? :)))

Вы по себе что ли судите? Ну... По себе других не судят. :)))

Перечитайте ещё раз. :)

Сделайте милость. Там приведен ответ на Ваш же вопрос как именно проводился анализ. Приведен пример аналогичного. Смелее! У Вас все получится. Если сможете найти результат, отличный от моего, то опубликуйте его?

Ну элементарно же, где ваше великолепное ПО, решающее проблемы пользователей. Сначала я говорил, что вы медленно пишете, а теперь я вижу, что вы и этого не делаете. Проблемы пользователей не решены. Это поправимо, но не вами.

Вышел JRuby 1.7.0 (комментарий) — вот в этом сообщении вы утверждаете, что C является лучшим выбором для решения любой задачи в 80 процентах случаев.

Для того, чтобы доказать такое утверждение, следует для начала привести выборку из задач и определить критерии «лучшести» решения задач.

Вы же зачем-то пытаетесь рассуждать об особенностях PHP.

Будет ли твоя java популярна через 5-10 лет. А через 20.

Может уж сразу через 100? )))

Jenkins/Hudson, CruiseControl, TeamCity

Угу, redmine с одной стороны

Все понятно, вместо Jenkins они используют Redmine и github «с другой стороны» )))

Притом, я, так понимаю, что перечисленное тобой заточено под java

Почитай на досуге, что такое Сontinuous Integration (если пишешь что-то более серьезное чем hello world)
затем тебе туда http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software

Aptana написана не на JAVA

vim

Т.е. У source forge страничка убогая, но когда дело доходит до программирования, вместо Eclipse ты берешь Vim. )))

PS Повеселил, спасибо ))))

Нет. Вы либо не поняли, либо и не хотите понимать. :)

Хорошо. Еще раз и снова.

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

1. Проводим анализ кода. Как я уже показал — трассировка. Цель трассировки — определить как именно используются системные вызовы в конкретных приложениях. Насколько они востребованы?

2. Анализируем полученные результаты и понимаем что процентов 80 в так называемых «современных средствах разработки» это обёртки над существующими системными вызовами (пример похапе самый яркий, по этому на него и ссылаюсь). Под «системным вызовом» в данном случае понимается именно обращение к функции из системной библиотеки. Оставшиеся процентов 20 это именно то, что программист реализовал в логике своего приложения, но используя те механизмы, которые есть в его распоряжении (читай — основанные на обёртках).

3. Вспоминаем что наиболее простой путь использовать системные вызовы — использовать С. В частности — стандартную библиотеку С. Например, вместо того чтобы устраивать содомию с похапе, просто считать через getenv() (http://pubs.opengroup.org/onlinepubs/009696799/functions/getenv.html) нужную переменную и проанализировать ее (да просто распарсить). И, далее, работать без проблем с результатами.

Та же картина наблюдается с (опять-таки пример) с регулярными выражениями. Есть два варианта — из GNU C Library или из pcre. Имеет смысл выбрать http://www.gnu.org/software/libc/manual/html_mono/libc.html#Regular-Expressions потому как вероятнее всего есть в системе. Сразу.

4. PROFIT. Становится понятным почему разработчики GTK+/GNOME выбрали С как основной язык реализации.

В общем, как-то так. Если не дойдет и на этот раз, то заранее прошу прощения — из меня фиговый объясняльщик. Проще просто ткнуть пальцем, как в приведенной выше цитате.

страничка убогая,
vim прекрасен,
eclipce не нужен для ruby (к тому же страшен и тормознут),
необходимость IDE - недостаток языка,
необходимость Сontinuous Integration - недостаток языка.
Такая вот фишка, недостатки выдаем за достоинства, лол.

Писать код на руби быстрее и приятнее. Благодаря архитектуре руби Сontinuous Integration может быть обеспечена элементарнейшим скриптом, запускающим тесты.

недостатки выдаем за достоинства

помоему это девиз энтерпрайза..

Нет, писать на java можно и нужно, но это подвиг. А написать достойное пользовательское приложение это подвиг в квадрате (так никем и не достигнутый похоже). Поэтому лучше писать на java основы, такие как jruby:)

основанные на обёртках

Вы так говорите, как будто это чем-то плохо. Не надо компилировать (часами/днями), проще отлаживать, меньше кода => меньше ошибок. Быстрее сделано, лучше результат.

PROFIT. Становится понятным почему разработчики GTK+/GNOME

Т.е. все это сделав, вы поняли разработчиков gnome.. молодцы. Профит должен был быть: мы за N лет переписали систему на си и она стала работать на 0.5 % быстрее в 3% случаев (как-то так). Опять же видна имитация.

0. Давайте рассмотрим веб-приложения, но на Ruby, чтобы попытаться спасти тему от злостного оффтопа.

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

2. Если бы в Bell Labs не считали, что с помощью высокоуровневых абстракций можно решать задачи эффективнее, то C никогда бы не появился. Совсем без оберток будет не DRY'вово.

Наверное, просто PHP сделан несколько странным образом.

3. Это не означает, что нужно писать весь проект на C. Можно использовать его только для тех частей, где это оправдано. Здесь хорошим примером будет Unicorn. Этот веб-сервер использует форки и C-шные расширения.

https://github.com/defunkt/unicorn/blob/master/HACKING

4. Неясно, какое отношение GTK+/GNOME имеют к веб-приложениям на PHP, которые вы рассматривали.

Скорость разработки? Думаете? :)

Боюсь, что скорость разработки критически важна разве что для проектов типа Ребе. :))) Не важно что там в предыдущей версии изваяли (быстро), в последующей будет столь же быстрый почти повальный рефакторинг и лихорадочный фикс ошибок. Веб-приложения же пишутся как правило, из расчета их длительного использования и там ошибку найдут и очень быстро. Заказчик будет недоволен. Однако если заказчик видит требования к системе, которые раза в два ниже, чем среднерыночные, то он будет рад заплатить.

Про поддерживаемость кода. А что с нею не так? Да, похапешника или рубиста на такое дело не поставишь. Но это уже не мои проблемы и не проблемы заказчика. Толкового программиста на С найти сложно. Но можно. Хотя, большая часть наших заказчиков склонна к длительным и прочным отношениям.

По поводу GTK+/GNOME. Это была полу-шутка. На самом деле, для С не важно что на нем писать. Для хорошо подготовленного программиста — тоже. Скорость приложения будет как правило на высоте. И, повторюсь, не важно что это — веб-приложение, десктопное приложение или что-нибудь все из себя серверное.

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

Боюсь, что скорость разработки критически важна разве что для проектов типа Ребе. :)))

Что вы имеете в виду?

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

Похоже на описание веб-разработки без BDD и TDD.

Скорость приложения будет как правило на высоте. И, повторюсь, не важно что это — веб-приложение, десктопное приложение или что-нибудь все из себя серверное.

Покажите пример полезного(не hello world) веб-приложения на C, что ли. Действительно интересно было бы взглянуть.

Для java такими костылями являются всевозможные ide, по моему мнению.

Это просто безграничный оптимизм )

скорость разработки критически важна разве что для..

Скорость разработки важна если делаешь хоть что-то, если не делаешь, то не важна.

в последующей будет столь же быстрый почти повальный рефакторинг

С одной стороны, с чего. Быстро не значит впопыхах (впопыхах это на пхп))) А с другой стороны.. - да, почему нет. Ведь один из принципов экстремального программирования - не писать хуе^W лишний функционал - т.е. только то, что нужно сейчас, т.е. время от времени, действительно, придется что-то рефакторить, но это будет четкий целенаправленный рефакторинг, что здесь казалось бы плохого (но я догадываюсь в чем дело). Дело в том, что рефакторинг на руби, и рефакторинг на сях - это абсолютно разные вещи. На руби изменил код, прогнал тесты - все, об ошибках интерпретатор скажет довольно конкретно. На сях нужно компилить (это долго), если рефакторинг затрагивает (пусть даже по не многу, но) весь проект, то нужно компилить весь проект. Проганять тесты и снова компилить. Отлов ошибок так же далеко не такой тривиальный как на руби (например для коммитеров рубиниуса сняли длинное видео по отлову ошибок интерпретатора, с кучей всяких тулз и телодвижений). При слове рефакторинг вас бросает в дрожь. Естественно это накладывает отпечаток и на архитектуру проекта, ведь мы живем в реальном мире, где время имеет значение. Это лишний функционал, структура файлов такая, чтобы как можно меньше компилить, нежелание рефакторить, желание все предусмотреть заранее (и как следствие - фейл). Отсюда понятно почему на выходе такая хрень. Почему свистелки вызывают лютую ненависть - откуда у вас на них возьмется время, боже упаси что-то менять.

Скорость приложения будет как правило на высоте

Разве что во снах, компилится и ладно! Но это ваши проблемы.

А вот нам нужен четкий маркетинг, демонстрирующий очевидные недостатки низкоуровневых языков и методик разработки на них.

По веб-приложению на С.

В данном треде уже упоминался UMN MapServer. В свое время я использовал этот сервер картографии, когда были задачи, с нею связанные. Использовал его в виде CGI под Apache, точнее FastCGI по причине того, что данные лежали в PostGIS и сервер FastCGI работал на отдельной машине, переводя данные картографии и нужные пользователям данные в png. Пользовательское приложение было написано на JavaScript, что давало мне «скорость разработки», да и использовать «просто браузер» весьма хорошая замануха для заказчика. :) Несмотря на то, что в принципе все хорошо и просто, мне пришлось немного потрахаться с реализацией по причине того, что у заказчика возникли дополнительные хотелочки в части отображаемых данных (а их собирал в базу то же наш софт). Просто источников данных было до... много, короче. И данные были весьма разнородны. Это не fleet management system, все несколько сложнее, это наложило отпечаток на используемую СУБД. Мы использовали PostgreSQL, храня там и картографический материал и данные.

Собственно, про мапсервер (что он позволяет делать и его архитектуру) написано хорошо, много и с картинками вот тут — http://mapserver.org/introduction.html#anatomy-of-a-mapserver-application . дополнительно хочу заметить что данный продукт поддерживает посредством библиотек OGR/GDAL порядка 42 картографических форматов (в том числе и Oracle GIS и нужный мне в тот момент PostGIS). Но есть возможность собрать его так, чтобы убрать все лишнее и оставить только то, что нужно. Код на С, что тут скажешь. А! Если интертесны именно примеры работы, то всяких разных демок по Сети много было. Поищите.

По поводу «процесса разработки»... Вот Вы пишете — нет BDD, нет TDD... А вот мне кажется, когда я смотрю на современные продукты, что не только их нет, а еще не совсем ясно чем там злоупотребляют разработчики. Мне уже начинает казаться что по их коду, если на него глянуть, то можно диагностировать конкретную зависимость. В принципе, при скорострельном ваянии программ, это допустимый подход. Разработка на С изрядно дисциплинирует разработчика — за лишнее рукоблудие в коде придет тимлид и задницу рашпилем обработает. :) Да и программирование на С начинается, как правило, не с редактора, а с листка бумаги... Впрочем да... Я же ретроград и старпер. :)))

мАлАдой чИ-лА-вЭЭЭк!

Я понимаю — до Вас не доходило, не доходит, да я уже и не надеюсь на то, что дойдет что код, который написан программистами всегда более оптимален, чем код, который написан рукоблудами. Вместо того, чтобы разводить тут словоблудие, Вы бы глянули на код того же UMN MapServer (про который Вы же в треде и ляпнули, дескать с ним работали). У Вас бы, наверное, резко отвалилось желание к высокохудожественному бреду, которым Вы тут злоупотребляете.

В то же время, Вам не понравилась страничка по статистике с соурсфорджа. Дескать, оформление некузявое и без CSS-рюшечек. А, на мой взгляд, там дело не в оформлении, а в том, что пальма первенства за С и java. Все остальные, ориентированные не на нужды «ынтерпрайзоф» этих ваших (не люблю это модное словечко «энтерпрайз», уж простите великодушно) — в заднице. Собственно, и не удивительно. Ни кому не нужен софт в виде затычек-тампаксов. Типа — чего-то наскоряк изваяли, дырдочку заткнули, а дальше хоть потоп.

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

Ну и наконец. Что? У Вас проблемы со скоростью разработки и маркетином? Скажу сразу и честно. Я знаю как это лечится. Вам следует немедля забросить этот ваш Ребе и бросить свои силы на освоение битрикс. Слышите? Не-мед-ля! А что? Там мегов 300 всего, что только может понадобиться, скорость разработки просто охеревающая и с маркетингом все хорошо, есть где разгуляться. Что, Вам не нравится пыхпых? А, простите, who's care? До Вас так и не доходит что на Ребе покамест почти ни фига не написано (и не дойдет почему). Когда до человека не доходят такие простые вещи, то это интеллектуальный уровень среднестатистического пыхера.

Еще раз говорю — проверьте на чем написано то, чем Вы пользуетесь ежедневно и задайте вопрос — а сколько тут Ребе? Второй вопрос, который Вы можете себе задать при желании — а почему его так мало за столько лет?

Пользовательское приложение было написано на JavaScript, что давало мне «скорость разработки»

Каким образом происходило взаимодействие с заказчиком? Были ли написаны acceptance tests? У вас что, действительно не было дедлайнов?

Вопрос есть. Хоть и не по JRuby, а по Ruby, но все же.

Смотрел как-то на Ruby. Показался сильно недоделанным. Взяли концепцию управления блоками и остановились на первом шаге. Его еще развивать и развивать.

Но вопрос не о Ruby а о рельсах. Когда я смотрел они были на Ruby 1.8. А в нем, помню хрень с юникодом была. Ее решили в Ruby 1.9. Так вот вопрос. Точнее 2 вопроса:

1) Есть ли новые рельсы на Ruby 1.9?

2) Раньше Ruby 1.9 считался веткой разработки, совместимость в которой могут в любой момент ломать. Это изменилось?

Смотрел как-то на Ruby. Показался сильно недоделанным. Взяли концепцию управления блоками и остановились на первом шаге. Его еще развивать и развивать.

Неясно, что вы имеете в виду. Что именно вам не нравится в блоках в Ruby?

1) Есть ли новые рельсы на Ruby 1.9?

Да.

2) Раньше Ruby 1.9 считался веткой разработки, совместимость в которой могут в любой момент ломать. Это изменилось?

Это какая-то ерунда, откуда такая информация? Код, который написан для 1.8, будет работать и на 1.9.

Неясно, что вы имеете в виду. Что именно вам не нравится в блоках в Ruby?

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

1) Есть ли новые рельсы на Ruby 1.9?
Да.

Это хорошо.

2) Раньше Ruby 1.9 считался веткой разработки, совместимость в > которой могут в любой момент ломать. Это изменилось?

Это какая-то ерунда, откуда такая информация? Код, который написан для 1.8, будет работать и на 1.9.

А вот это ложь.

Пример: http://habrahabr.ru/post/144258/

И еще нашел: 1.9.0 (development) 25 декабря 2007 Изначально экспериментальная ветка созданная для практической проверки ряда нововведений. 1.9.3 (stable) 31 октября 2011 Последняя ветка на данный момент (10 сентября 2012 года). Соответственно, модификации также выходят до сих пор. Отличия от 1.9.2 — существенны.

Значит сделали стабильной. Хорошо.

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

Возникает вопрос: как отличить логически законченную концепцию от не законченной?

http://habrahabr.ru/post/144258/

Это специфический случай, когда в файле присутствуют не-ASCII символы. В комментариях указали на это.

Возникает вопрос: как отличить логически законченную концепцию от не законченной?

Насколько я знаю, не я один это заметил. Значит мне не привиделось.

Логическая законченность концепции никак не влияет на работу того, что есть. Ее незакнченность означает, что когда-нибудь, кто-нибудь может значительно улучшить то что есть. Потенциал развития не просто виден, он стоит перед глазами и руки чешуться глядя на него.

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

Это специфический случай, когда в файле присутствуют не-ASCII символы. В комментариях указали на это.

Опять же. Это не важно. Работает только в частном случае. В более общем случае - нет. В частном случае и программа написанная для python 2 работает на python 3. Но в общем случае такое утверждение - ложь.

* И про него можно забыть.

Имел ввиду про потенциал можно забыть. Не про Ruby, конечно. :)

А так придется жене рекомендовать. Она просила совета чем бы занятся в свободное время. Дьянго или рельсами. ;)

:)

Это была адова работенка. Все начиналось в 2006г., если не ошибаюсь, году, когда заказчик задал простой вопрос — «нам нужно средство отображения данных с привязкой к карте». Естественным ограничением стало то, что ни гугль, ни яндекс использовать нельзя, хотя руки и чесались (уж больно хорош у гугля API для карт, но геореференсинг для РФ не очень). Геореференсинг здесь подразумевается по координатам дать нас. пункт и адрес в нем. Такого картоографического материала в свободном доступе нет, все что крупнее 1 к 500000 ЕМНИП, это либо ДСП либо секретка. Но это проблемы заказчика.

Исследование провели, заключение дали. Могем, дескать. Это был первый этап. Дальше у заказчика спросили — чего изволите? Ибо можем изваять клиент на java (есть такое решение для мапсервера, надо поискать, сейчас не помню), можем изваять клиента на С/С++ ибо интегрировать в приложение что WebKit, что эксплорер — раз плюнуть. А можем написать некую оболочку на javascript, которая не будет зависеть от браузера. Пока заказчик думал, изваяли на javascript прообраз и скрестили пальцы на удачу. Заказчик согласился, выдал ТЗ. К слову сказать, у меня четко выстроена модель взаимодействия — я прошу все, вплоть до дизайна приложения. Потому как вот есть в штате криптоаналитик с 15-летним стажем, а вот экстрасенсов нет ни одного, дизигнеров — тоже. И угадывать как именно должно выглядеть приложение я не собираюсь. Это решает тот, кто будет моим приложением пользоваться. Заодно у меня пропадают проблемы с тем, что если функционал есть, а интерфейс говно, то как объясняться с заказчиком.

Дальше мы сделали рабочую версию, уложились раньше срока. Заказчик посмотрел, одобрил и выкатил дополнение, где указал что именно мы должны собирать, как обрабатывать и как отображать. Сделали. Потом еще и еще. Учитывая то, что структура проекта для нас прозрачна и полностью модульна, нужно было просто реализовать все аггрегаторы в виде отдельных демонов. Что, собственно, и было сделано. Сам по себе демон (каждый) очень прост. Его работоспособность отследить просто. Либо нет данных в БД, а есть запись в логах (демон упал), либо данные в БД есть, но они полне говно (Вы их воочию увидите на экране, в браузере), либо все хорошо. Все косяки вылезают на этапе написания/внутреннего тестирования.

В таком подходе acceptance tests это примерно пол-года работы заказчика с живой системой, которая уже развернута на его площадке и к которой уже написано руководство пользователя и пользователям показали что к чему (и посмотрели на их первую реакцию на систему, она всегда показательна). Если нареканий нет, то все хорошо. Если есть, то какие именно? А дальше — расчехляем vim и поехали править. Но случаи нареканий крайне редки, т.к. в С очень хорошо. Если уж ошибка сделана, то голову она оторвет сразу и вполне очевидным образом еще на этапе внутреннего тестирования. Это закладывается еще на этапе анализа ТЗ, когда задача раскидывается на более мелкие подзадачи и определяется кто и что будет делать в команде. Да. Это требует своей, если угодно, культуры разработки и жесткого взаимодействия всех звеньев. Но нам не привыкать, ибо «погоны» в прошлом. Между собой мы всегда договоримся.

На С писать легко и просто, если знать и уметь как. Ну и если каждый член команды в ладах со своей головой.

пальма первенства за С и java

Нет))) это лишь сорсфорж. Кому нужен ваш сорсфорж, все давно переехали на github (внезапно, написанный на руби). Коммитов на github гораздо больше. Проекты на github, восновном руби и js. На самом деле сложно найти задачи, где бы си и руби конкурировали друг с другом. java - да, .net - да, си - нет. Си - это для небольших низкоуровневых штуковин.

код, который написан программистами всегда более оптимален

Так эти ваши программисты ясновидящие)) А понятия «минорный релиз» и рефакторинг, и вовсе фантастика.. ну и сказочник же вы.

Т.е. ваша работа был собрать мапсервер без «лишнего» (интересно зачем), но молодцы, чо.

интегрировать в приложение что WebKit

Зачем же, пишите на си)) А то говорим си, а оказывается это и не си вовсе, а js)) А сервер отдает себе картинки. Типичнейшая картина. Сервер (мапсервер) не трогаем (ибо сложно), весь функционал на тонкий клиент. Если бы был сервер на руби, а мапсервер использовался в только в качестве рендера (через руби, а не мертвый-древний cgi), было бы проще и эффективнее.

В этом вашем примере, вся ваша суть)) Где можно используете винтаж ака хипстер, а где приперло так, что нельзя, там можно что-нить нормальное взять (WebKit например). А на выходе, конечно же гомно.

пс
Причем, полагаю ваш js - то еще зрелище не для слабонервных :))

битрикс

Кстати да, что такое «битрикс»?

Да... Внезапно...

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

Ваш более трезво мыслящий коллега просил показать ему веб-приложение на С. Ну я и ткнул пальцем в общедоступное. Слегка коснулся общей архитектуры проекта, которая выходит далеко за пределы мапсервера. Впрочем, Вы не разочаровали меня и на этот раз... :))) Реакция вполне ожидаемая.

Я представляю то, что с Вами бы случилось,

если бы Вы вкурили тот код. Для Вас было бы потрясением то, что через XMLHttpRequest данные можно забирать с выхода persistent web application... И уж совсем было бы прикольно посмотреть на Вашу реакцию, когда бы Вы увидели на чем то веб-приложение (точнее, их там несколько, каждое отвечает за свою часть вывода, но это не столь суть — аггрегация данных куда как интереснее) писано... :))) Впрочем, лично мне для ржача и текущей Вашей реакции достаточно. :)))

/* После шашлычка с хорошим вином так приятно по-троллить апологета Ребе, что не грех это даже в Шаб субботу сделать... */

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

точнее, их там несколько, каждое отвечает за свою часть вывода

О, у меня уже потрясение)
Вместо нормального веб-приложения вы создали монстра, с переплетением js и си) монстр ползал, умоляя избавить от мучений, пока в один день про него не забыли навсегда, но вы еще с ним встретитесь;))) Это все от незнания. Нужно сделать приложение для конечного пользователя, но на си не пишут приложений для конечных пользователей, соответственно приходится велосипедить и костылить. Из этого получаются.. велосипедные костыли!) Ну кто так пишет веб-приложения, да.. российские сишьники впереди планеты всей..

Или вас обидело, что я не заметил ваш «собиратель данных», ну простите уж, меня это не очень впечатляет, т.к. с ПД и СК работал много, и сам такую штуку писал (на руби разумеется) так же в постгис кстати (из отечественной ГИС через com объект). До сих пор работает и в нете присутствует.

/* Позевывая и потягиваясь появляется анонимус. */

Меня?!? «Обидело»??? :))) Нет. Вы не правильно истолковали мою реакцию. Меня искренне забавляет Ваше нежелеание воспринимать что-то, что не укладывается в Вашу убогую модель мировосприятия. Поверьте, я редко даю советы. Тем более писать на битрикс. Но это как раз Ваш случай. Убожество просто обязано тянуться к такому же убожеству... :)))

Опять же. Вы вот недоумеваете — как так, правоверные сычи, а javascript используют. Ну а почему нет? Впрочем, видимо Вы столько сил убили на этот свой Ребе, что не удосужились прочесть в качестве стартовой точки для десктопных приложений под GNOME например вот это — http://developer.gnome.org/gnome-devel-demos/unstable/message-board.c.html.en Да. Это пример интеграции «современных веб-технологий» в современную DE на С. Что не так? То, что Вы не понимаете что мне например пофиг что именно писать, потому что необходимые библиотеки либо самопальные, либо предоставляемые сообществом у меня уже есть? На С все легко и просто. Если не верите, то задумайтесь — на фиг нужны JNI в java и почему это интерфейс к С/С++, а не этому вашему достославному Ребе? Как там с этим вашим Ребе, я не знаю. Тыкать в это палочкой у меня желание отпало. А вдруг это заразно? :)))

Не знаю что Вы там писали (но охотно допускаю что все именно так, как Вы говорите, пусть даже через ж... эээ... СОМ-объект). Видимо, сдампить оттуда картографический материал и сконвертировать его сразу в постгис была не судьба? Впрочем, ладно, не буду докапываться. Но те реализации, основанные на мапсервере, которые я видел в российском сегменте Сети в данный момент вызывают у меня два замечания. Во-первых, страничка с соурсфорджа, о которой мы говорили выше, должна была бы у Вас вызвать дрожь восхищения. То, что я видел из реализаций в нашем сегменте это... П*Ц! Даже для меня, ни фига не дизигнера, это было слишком.

Во-вторых, если говорить о реализациях, то что я смотрел, было сделано на основе чистых CGI. Само собой, такой вариант исполнения мало пригоден для продакшона. Проблема в исполнении CGI, при которой при каждом запросе, веб-сервер должен стартовать мапсервер и передавать ему параметры. Но, если Вы говорите, что у Вас был постгис, то в таком случае получается что при каждом старте мапсервер должен заново логиниться в постгрес и вот только потом начинать выбирать данные по соответствующим слоям. Вы уверены в том, что это операция, которая не стоит слишком дорого (я про логин)? Про попытки кешировать хоть что-либо в случае с CGI я и не говорю — о них можно не думать. Мы изначально использовали мапсервер как FastCGI — http://mapserver.org/optimization/fastcgi.html (обратите внимание на директиву для Mapfile под названием PROCESSING). И, кстати, именно по-этому собирали мапсервер крайне внимательно, а вовсе не потому что Вы там что-то подумали. :))) Теперь я понял почему те реализации, которые я видел в российском сегменте Сети сыпались на 20-30 параллельных запросах.

Вывод подтвержден — пишите на битрикс. Уверяю Вас — если вы на этом вашем Ребе пишете таким образом, что готовы испоганить вполне работоспособный продукт, то для всех будет лучше, если Вы прекратите это делать. Думаю, «отряд» (индустрия) не заметит потери бойца...

Вы вот недоумеваете — как так, правоверные сычи, а javascript используют. Ну а почему нет?

Да не умеете потому что. Собственно так же как и на си. Собственно, я не думаю, что вы программист))

Это пример интеграции «современных веб-технологий»

Адресом ошиблись с таким определением)) Это пример встраивания браузера в гуи приложение. Фишка в том, что оно вам не поможет:)

Вы не понимаете что мне например пофиг что именно писать

Совершенно понимаю, дилетант умеет все)

на этом вашем Ребе пишете таким образом, что готовы испоганить вполне работоспособный продукт

Вы ведь понятия не имеете о чем говорите, и 8/10 вы вообще не имеете понятия о чем говорите))

отзывы про GitLab в соседней ветке как-то настораживают
GitHub и про GitLab. Но только вот кажется мне что проблемы и там и там сходные.

Ну-ну. Не читал, но осуждаю))

Вот и приходится равняться на лучших, анализируя их промахи.

Ах, моська — знать, она сильна! коль лает на слона))

То, что я видел из реализаций в нашем сегменте это... П*Ц!

Видимо до конца не решили на кого равняться: «лучших», или соседей по «сегменту» (что там у вас за сегмент такой..х_х), но выбрали явно второе)))

То что вы тут описали про мапсервер, кстати, похоже на правду и является образцом беспомощности как на клиенте, так и на сервере. История интересная, буду знать.

Нет-нет-нет. :)))

Упаси меня Бог от того, чтобы стать таким же «программистом» как Вы. С неодолимой склонностью к маркетингу и скорострельному ваянию кода. Которому вдобавок приходится объяснять что то самое веб-приложение (на С, кстати написанное), он еще вдобавок и криво использовать умудрился. Это тоже понятно — в стране «технического английского» прочесть документацию аборигены эээ... «программисты» :))) удосужатся только после ласкового и нежного пинка в нее.

У нас различные точки зрения на сам по себе процесс. Дело в том, что Ваше поколение выбрало «Пепси», а мы на безальтернативной основе — квас и «Байкал». :))) По этой причине Ваше поколение склонно к быдлокоду без анализа происходящего. А мы как писали, так и пишем. Да вокруг себя поглядываем. ;)

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

В остальном, ввиду полной бесперспективности и самого Ребе и его апологетов, я, пожалуй, позволю себе откланяться. Надоело чувствовать себя человеком, отнимающим у ребенка конфету. :)))

Всем удачи.

Но саммое важное что теперь, в случае набора людей, дам команду смотреть чтобы в резюме кандидата не было слова «ruby».

Это, зря. Ruby хорош для умных конфигов. Как и все скриптовые языки.

А так да. Толку от него - только рельсы.

Это 1ce

Как и все скриптовые языки.

А зачем тебе рельсы, фигач на си, как вышеуказанный знаток «интеграции современных веб-технологий»))