Здравствуйте, gandjustas, Вы писали:
S>>Сейчас существует уже очень большое количество готовых решений как кубики, которые может применять программист или даже администратор. Огромное количество работ это не написание кода, а адоптация уже готовых решений. К примеру, нужно в формочку вставить капчу: скачал модуль, вставил. Минимум кодирования. Для таких работ особые таланты не надо, как результат зарплаты неочень. G>Не очень понимаю к чему ты клонишь. Каждый раз капчу писать с нуля? G>Если "мерить в капчах", то пока CGI\C программист делает капчу, ASP.NET программист сдает уже второй проект.
просто одни пиушт капчи, другие используют их. что сложнее и высокоплачиваимей — угадай сам
Здравствуйте, senglory, Вы писали:
S>Здравствуйте, shrecher, Вы писали:
S>>К примеру IT-безопасность: дезасемблирование, анализ протоколов. Тут надо мозги. Кстати, одна из самых востребованных областей.
S>Где востребованных?
Because of the worldwide financial crisis, the firm expects spending on technology by enterprise companies to grow by just 2.6 percent next year compared with 2008.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, gandjustas, Вы писали:
S>>>Сейчас существует уже очень большое количество готовых решений как кубики, которые может применять программист или даже администратор. Огромное количество работ это не написание кода, а адоптация уже готовых решений. К примеру, нужно в формочку вставить капчу: скачал модуль, вставил. Минимум кодирования. Для таких работ особые таланты не надо, как результат зарплаты неочень. G>>Не очень понимаю к чему ты клонишь. Каждый раз капчу писать с нуля? G>>Если "мерить в капчах", то пока CGI\C программист делает капчу, ASP.NET программист сдает уже второй проект.
BZ>просто одни пиушт капчи, другие используют их. что сложнее и высокоплачиваимей — угадай сам
Те кто используют капчи не занимаются только использованием капчей.
Вообще создание приложения сложнее, чем создание компонент.
G>Для анализа протоколов асм не нужен. Насчет востребованности дизассемблирования у меня есть сомнения. Покажите вакансии где требуется дизасемблирование.
Здравствуйте, StandAlone, Вы писали:
SA>Писали же как-то сайты на CGI ( гугл, блин, со своей пикасой — upload.cgi)
Маненько в сторону — все эти расширения, типа .cgi, .pl, .aspx и прочие ничего гарантируют для внешнего наблюдателя — это может быть даже .exe, .pfd и я не побоюсь этого слова, .txt или .doc(x). А унутри у него реально будет, допустим, php.
Буквально одна строчка в конфиге (этот экстеншн обрабатывает такой-то обработчик). И у Apache и у IIS это конфигурируется.
CGI в первоначальной идее плохо отражается на перформансе, но, конечно прост с точки зрения интерфейса: вот тебе environment, вот stdin, давай что там у тебя получилось в stdout.
Это безотносительно наличия/отсутствия фреймворка и реально из чего этот cgi испечён (пёрл, си/си с крестиками или ассемблер). Это совершенно другой вопрос.
Прогресс ушел в сторону более простых средств (с точки зрения функционал/затраты на производство).
Примерно так.
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
Здравствуйте, shrecher, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Ну это только лаборатория касперского.
S>Да, но ты посмотри как они развиваются и расширяются ...
G>>А еще парочку контор, не AV направленности?
S>http://www.agnitum.ru/about/job/profile.php S>http://www.infowatch.ru/Vedrazr
S>Можешь еще поискать "intrusion prevention system", "firewall".
Там активно используется asm? Сильно сомневаюсь.
Всяческие анализаторы (как и любой алгоритмически сложный код) гораздо выгоднее писать на явзяках высокого уровня и переходить на более низкий уровень только из соображений быстродействия.
Ограничение сильные действуют для кода в режиме ядра, так только С, даже с++ с трудом работает.
А прогресс тем временем движется в направлении выноса некоторых ядерных функций в user-mode (в семерке что-тотакое придумали), таким образом все больший простор открывается для использования высокоуровневых средств в системном программировании.
"Вирусный аналитик". Совершенно гиблая профессия, чисто для восторженных вчерашних и нынешних студентов, фанатиков кода с горящими красным глазами.
Во всех остальных местах, включая упомянутое низкоуровневое программирование и драйвера, идет тенденция борьбы со сложностью системы путем повышения уровня абстракции(см. UMDF | KMDF). Компиляторы давно знают ассемблер лучше человека. А если где-то и хуже, то затраты на актуализацию знаний ассемблера неоправданно высоки.
Здравствуйте, WPooh, Вы писали:
WP>Маненько в сторону — все эти расширения, типа .cgi, .pl, .aspx и прочие ничего гарантируют для внешнего наблюдателя — это может быть даже .exe, .pfd и я не побоюсь этого слова, .txt или .doc(x). А унутри у него реально будет, допустим, php. WP>Буквально одна строчка в конфиге (этот экстеншн обрабатывает такой-то обработчик). И у Apache и у IIS это конфигурируется. WP>CGI в первоначальной идее плохо отражается на перформансе, но, конечно прост с точки зрения интерфейса: вот тебе environment, вот stdin, давай что там у тебя получилось в stdout.
Сложно даже представить, что же заставило гуглоидов пойти на такую военную хитрость и подсунуть php скрипт в cgi оболочке?
Меры против взлома?
Здравствуйте, StandAlone, Вы писали:
SA>Здравствуйте, WPooh, Вы писали:
WP>>Маненько в сторону — все эти расширения, типа .cgi, .pl, .aspx и прочие ничего гарантируют для внешнего наблюдателя — это может быть даже .exe, .pfd и я не побоюсь этого слова, .txt или .doc(x). А унутри у него реально будет, допустим, php. WP>>Буквально одна строчка в конфиге (этот экстеншн обрабатывает такой-то обработчик). И у Apache и у IIS это конфигурируется. WP>>CGI в первоначальной идее плохо отражается на перформансе, но, конечно прост с точки зрения интерфейса: вот тебе environment, вот stdin, давай что там у тебя получилось в stdout.
SA>Сложно даже представить, что же заставило гуглоидов пойти на такую военную хитрость и подсунуть php скрипт в cgi оболочке?
Вряд ли там php, вероятнее всего fastcgi + python\c++ с самописным фреймворком
SA>Меры против взлома?
Здравствуйте, StandAlone, Вы писали:
SA>Сложно даже представить, что же заставило гуглоидов пойти на такую военную хитрость и подсунуть php скрипт в cgi оболочке?
Это большая военная тайна. У них NDA, разве они расскажут.
Подозреваю, что там фарма на самом деле. Урлу, как обычно, для совместимости оставляют неизменной.
К этому моменту у меня внутри 0.5, 0.7, 0.33 (с) НС
Здравствуйте, gandjustas, Вы писали:
GZ>>Программирование Web и Толстых приложений — кардинально отличается. Когда попадаешь на web проект, нужно перекраивать голову. Все что учили в институте, в школе — нужно забывать. Тут нельзя хранить состояния, а постоянно приходится взаимодействовать с пользователем в режиме Request/Response, и учитывать что сервер может быть перезагружен в любой момент, независимо от твоего хочу/нехочу. G>Это как раз гораздо лучше ложится на концепцию бизнес-операций.
Очень громкое заявление! Когда нужен индуктивный интерфейс на коротких тразакциях — то оно конечно . Но вот когда нужен интуитивный интерфейс, к тому же когда бизнес-транзакции длинные — то уж позвольте подвинуться.
GZ>>Разработка Web приложения — более дорогое занятие(и не из-за зарплат). Ты не задумывался почему же заказчики идут на это?(и отнюдь не из-за рекламы) G>Статистика показывает обратное. Создание веб-приложения в среднем на 15% дешевле создания декстоп-аналога (правда это давно было, тогда не было ничего типа WPF)
Во первых, веб-приложения не могут полностью заменить толстяков чисто технологически. Во-вторых, если мы имеем ввиду, то что вы сказали: "Создание" — как постановку, архитектуру, кодирования, то пожалуйста ссылку.
Здравствуйте, StandAlone, Вы писали:
SA>Здравствуйте, shrecher, Вы писали:
G>>>Для анализа протоколов асм не нужен. Насчет востребованности дизассемблирования у меня есть сомнения. Покажите вакансии где требуется дизасемблирование.
S>>http://www.kaspersky.ru/vacancies?dept=151517973
S>>http://www.kaspersky.ru/vacancies?vacid=156056584
SA>"Вирусный аналитик". Совершенно гиблая профессия, чисто для восторженных вчерашних и нынешних студентов, фанатиков кода с горящими красным глазами.
Какая разница для фанатиков или уровновешенных кодеров? Главное, что платят и востребованы и этому нет конца-края.
SA>Во всех остальных местах, включая упомянутое низкоуровневое программирование и драйвера, идет тенденция борьбы со сложностью системы путем повышения уровня абстракции(см. UMDF | KMDF). Компиляторы давно знают ассемблер лучше человека. А если где-то и хуже, то затраты на актуализацию знаний ассемблера неоправданно высоки.
С/С++ аппаратно зависимый язык поэтому всегда неплохо знать какой код он генерит. Кстати, на мобильных платформах, которые в стадии еще разработки, копиляторы генерят код с ошибками, поэтому порой приходится читать сам асм и разбирать почему не пашет.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, gandjustas, Вы писали:
GZ>>>Программирование Web и Толстых приложений — кардинально отличается. Когда попадаешь на web проект, нужно перекраивать голову. Все что учили в институте, в школе — нужно забывать. Тут нельзя хранить состояния, а постоянно приходится взаимодействовать с пользователем в режиме Request/Response, и учитывать что сервер может быть перезагружен в любой момент, независимо от твоего хочу/нехочу. G>>Это как раз гораздо лучше ложится на концепцию бизнес-операций. GZ>Очень громкое заявление! Когда нужен индуктивный интерфейс на коротких тразакциях — то оно конечно . Но вот когда нужен интуитивный интерфейс, к тому же когда бизнес-транзакции длинные — то уж позвольте подвинуться.
Для длительных бизнес-транзакций лучше не хранить стостояние в памяти приложения, а использовать какой-либо явный процесс (WF например) с сохранением состояния в БД или другом внешнем носителе.
К интерфейсу это мало отношения имеет.
GZ>>>Разработка Web приложения — более дорогое занятие(и не из-за зарплат). Ты не задумывался почему же заказчики идут на это?(и отнюдь не из-за рекламы) G>>Статистика показывает обратное. Создание веб-приложения в среднем на 15% дешевле создания декстоп-аналога (правда это давно было, тогда не было ничего типа WPF) GZ>Во первых, веб-приложения не могут полностью заменить толстяков чисто технологически.
Единственное где толстые клиенты необходимы — это при наличии непостоянного содениения. остальные сценарии нормально покрываются HTML+JS+CSS\Silverlight.
GZ>Во-вторых, если мы имеем ввиду, то что вы сказали: "Создание" — как постановку, архитектуру, кодирования, то пожалуйста ссылку.
Не дам, я ссылки не храню.
Здравствуйте, gandjustas, Вы писали:
GZ>>Очень громкое заявление! Когда нужен индуктивный интерфейс на коротких тразакциях — то оно конечно . Но вот когда нужен интуитивный интерфейс, к тому же когда бизнес-транзакции длинные — то уж позвольте подвинуться. G>Для длительных бизнес-транзакций лучше не хранить стостояние в памяти приложения, а использовать какой-либо явный процесс (WF например) с сохранением состояния в БД или другом внешнем носителе.
Чаще проще и дешевле — хранить именно в приложении. G>К интерфейсу это мало отношения имеет.
Ты строил интуитивный интерфейс на вебе?(для справки, коренным отличием интуитивного, является возможность удобных для пользователя быстрых, часто повторяемых действий с некоторыми ответвлениями, которые чаще всего сопровождаются диалогами(которые в свою очередь реализованы на уровне HTML из рук вон плохо), быстрыми клавишами, и вообще плотным взаимодействием пользователя и программы).
G>Единственное где толстые клиенты необходимы — это при наличии непостоянного содениения. остальные сценарии нормально покрываются HTML+JS+CSS\Silverlight.
Добавлю. А также:
Ресурсоемких операций.
Операций связанных с безопасностью.
Операций связанных с графикой(как то сканирование, и разл. граф редакторы).
Операций связанных с окружением пользователя (меня умиляет что Microsoft для шарепоинта, поддержку оного вделали в офис, но это отнюдь не все редакторы)
Это то, с чем пришлось столкнуться на практике. А по факту можно придумать еще кучу.
Здравствуйте, gandjustas, Вы писали:
BZ>>просто одни пиушт капчи, другие используют их. что сложнее и высокоплачиваимей — угадай сам G>Те кто используют капчи не занимаются только использованием капчей.
но большинство-то из них занимаются достаточно простыми вещами.
G>Вообще создание приложения сложнее, чем создание компонент.
Здравствуйте, shrecher, Вы писали:
S>Какая разница для фанатиков или уровновешенных кодеров? Главное, что платят и востребованы и этому нет конца-края.
Платят? Килобакс в зубы и будь доволен. Никуда ты с подводной лодки не денешься.
Востребованы? Дай бог, если в десятке мест по всей России.
А разница огромная. Создавая что-то новое, ты постоянно развиваешь системное мышление, интеллект, обучаешься приемам и подходам.
Ковыряясь в дебрях бинарей, всего этого не получить.
SA>>Во всех остальных местах, включая упомянутое низкоуровневое программирование и драйвера, идет тенденция борьбы со сложностью системы путем повышения уровня абстракции(см. UMDF | KMDF). Компиляторы давно знают ассемблер лучше человека. А если где-то и хуже, то затраты на актуализацию знаний ассемблера неоправданно высоки.
S>С/С++ аппаратно зависимый язык поэтому всегда неплохо знать какой код он генерит. Кстати, на мобильных платформах, которые в стадии еще разработки, копиляторы генерят код с ошибками, поэтому порой приходится читать сам асм и разбирать почему не пашет.
Когда приходится разбираться с тем, какой код куда генерится, это верный признак того, что парой уровней абстракции выше допущена серьезнейшая ошибка.
Занятие это, возможно, и нужное. Но серьезным его назвать нельзя.
Здравствуйте, BulatZiganshin, Вы писали:
G>>Вообще создание приложения сложнее, чем создание компонент.
BZ>ага. давай архитектора с кодером сравнивать
На мой взгляд, кодер в чистом виде — уже некая сферическая абстракция.
Как правило, ситуации таковы — архитектор составляет ТЗ по функционалу и приблизительному дизайну.
Затем выбор конкретной платформы и технологий идет на совместном брейн-ринге.
И последующая реализация этой функциональности полностью up to u.
Как построишь, так и будет.
Разве что где-нибудь уткнешься в что-нибудь технологическое, тогда вновь беспокоится архитектор и итерация повторяется.
Как-то так.
Здравствуйте, GlebZ, Вы писали:
G>>Это как раз гораздо лучше ложится на концепцию бизнес-операций. GZ>Очень громкое заявление! Когда нужен индуктивный интерфейс на коротких тразакциях — то оно конечно . Но вот когда нужен интуитивный интерфейс, к тому же когда бизнес-транзакции длинные — то уж позвольте подвинуться.
Для этого придумано масса всего, включая сохранение состояния в БД.
GZ>>>Разработка Web приложения — более дорогое занятие(и не из-за зарплат). Ты не задумывался почему же заказчики идут на это?(и отнюдь не из-за рекламы) G>>Статистика показывает обратное. Создание веб-приложения в среднем на 15% дешевле создания декстоп-аналога (правда это давно было, тогда не было ничего типа WPF) GZ>Во первых, веб-приложения не могут полностью заменить толстяков чисто технологически. Во-вторых, если мы имеем ввиду, то что вы сказали: "Создание" — как постановку, архитектуру, кодирования, то пожалуйста ссылку.
Покане могут. Но технологии движутся вперед стремительно, и это можно только приветствовать.
Дабы не быть голословным : ribbon-like UI веб-приложения, уже давно реальность.
