Как стать автором
Обновить

Комментарии 113

Какой автомобиль лучше для перевозки людей:
Mercedes S500
Audi A100
BMW x6
Ford Mustang
Daewoo Matiz
БТР 90
А где вариант «Другой»?
Я бы за БТР проголосовал вне зависимости от контекста :P.
БТР — и ты не заметишь пробок.
зато расходы на топливо. И если все пересядут на бтр — преимущество потеряется.
Если ты на БТРе, то проблемы заправки для тебя не стоят — кто будет с тобой спорить?

А все не пересядут — БТРов на всех не хватит.
Т-90 :)
КАМАЗ с отбойниками вместо бамперов, чтобы по пробкам идти напролом :-)

А по теме: тот язык лучше, который знаешь лучше всего. Сам по себе язык — это не серебряная пуля.
Единая Россия
Python без джанги
Tornado, не?
Во, я уже и забыл, что в питоне существует целый зоопарк на любой вкус.
bottle?
ну иногда бывает что вся прилага умещается в
def handle(start_response, evn): bla bla

Но минимум werkzeug все таки стоит использовать чтобы базовую обработку запроса иметь.

Но реально конечно flask пока самый удобный на мой взгляд — минималистичный, но полнофункциональный. Работает без лишних телодвижений и поверх gevent или tornado.

Впрочем быстро что то накидать на коленке с готовой админкой не рассчитывая на высокие нагрузки то django самое оно.

Есессно деплоймент всего это добра через wsgi сервер: uwsgi или gunicorn
Поддерживаю python + flask
Чем это лучше ruby + sinatra?
Лично для меня тем, что питон я знаю лучше, чем руби :)
Ни питон, ни руби не лучше друг друга.
Тут каждый выбирает для себя. Питон для тех, кому нужна ясность кода, а также тех, кто исповедует принцип «это можно сделать одним очевидным способом», а руби для любителей эзотерики и приверженцев «это можно сделать многими способами».
В качестве небольшого отступления: в питоне тоже можно одно и то же сделать многими путями и порой через одно место, просто есть некоторые рекомендуемые подходы :)
Можно, но чем мне питон нравиться, если решение не красивое, не pythonic way, это видно сразу.
… если глаз набил :)
C++, с библиотекой Wt
Смотря какие приложения… Веб он ведь не только на Инстаграмах разного рода жив.
.Net + Java FTW :D
Скала с Play тоже интересно смотрится, но голову требует сломать после явы очень сильно.
Вообще практически любой язык общего назначения подходит для веб. Меня просто интересуют доли веб-разработчиков (конкретно Node.js).
Ну веб приложения (из заголовка опроса) и обобщение «веб» (некоторые могут подумать что просто сайты) это все же наверное разные вещи, в моем понимании приложения должны предоставлять некоторые сервисы, выполянть бизнес логику, иметь задел на расширение функционала, код должен быть способным подвергаться авто-рефракторингу, и тд. Например использовать JS со всем его прелестями еще и на серверной стороне я бы не стал.
Опрос для этого не подходит. Я вот выбрал Rails, но де факто использую сейчас Perl Catalyst и ранее Node.JS, к примеру. Нет множественности выбора.
Я пишу сервер на php, а клиент (70% кода) на JS. Что мне выбрать тоже не понятно. Поставил php как серверный язык.
Поддерживаю, как правило пользую perl Catalyst + в зависимости от настроения и сложности задачи любой JS FW
Под JVM не обязательно на джаве писать, есть такие замечательные языки, как Groovy, Scala, JRuby
тот, который лучше всего знаете.
А большинство на хабре знают PHP (вроде опрос был)
PHP как таковой — не проблема. Проблема именно вот эти самые знания, которых часто нет.
Увидительно видеть JavaScript отдельным пунктом, обычно без него не обойтись на стороне фронтенда каким бы другим языком не пользовались.
Другое дело писать на JS серверный код. По мне так как минимум не очень дальновидно, да наверно это модно, для души например блог смастерить или todo'шку, но жертвы тоже нужно учитывать (писать большой проект разношерстной командой используя динамический язык программирования как основу серверного кода наверное весело).
Я имел такой опыт. Этаписец.
а пилить годами ентерпрайз проекты на Java под glassfish/tomcat?
Ну, глассфиш — это не тот аппсервер, который я бы стал рекомендовать использоватью. По моему мнению, глассфиш — тормозное г*но, извините за резкость. Мы используем томкат, иногда его недостаточно. В этих случаях я бы рекомендовал использовать в зависимости от потребностей TomEE или JBoss AS 8.

И уж всяко разрабатывать энтерпрайз на джаве (сильно типизированной) проще чем на JS (слабо типизированном).
Если разработка под томкатом тоже кажется слишком медленной, то есть еще два вариант:
1) Jetty (не уверен, что это эффективно)
2) JRebel — это эффективно даже на глассфише. Позволяет избежать 9/10 редеплоев.
Я тоже шефу сказал что глассфиш уныл и грустен, но упертость его и двух говнокодеров что г-но ваш томкат (ну да, девы на нем даже приложение без моего участия развернуть не смогли) составило у меня опередённое мнение про квалификаию шефа как админа и девов как знаюших инструментарий.
Я могу в цифрах показать, почему глассфиш не очень хорош — давайте оценим время запуска по сравнению с тем же JBoss AS 8.
Действительно, есть случаи, когда EE сервер необходим — например в них уже написаны Transactio Manager'ы — самому такой написать ой как непросто. Хотя для большинства веб приложений это не нужно и там хватит тривиального джетти/томката.
Я не программист аж никак на Java, мне хватило субьективно того, что глассфиш падал при каждом втором деплое небольшого приложения и сответственно мне пришлось дать девам судо на рестарт глассфиша.
ы.
Я все сказал.
Имхо, главное для большого проекта, это поддержка модульности. В JS, афаик, на уровне языка этого нет, в других популярных динамических языках в том или ином виде есть.
Согласен, модульность, использование классового подхода и тому подобное (в общем определенная строго стандартизированная структура проекта) в некоторой степени нивелируют неудобства динамических языков. В таком стиле должна работать вся команда.

Но все равно нужно предварительно дать себе отчет (и наверно не только себе), насколько целесообразно использовать JS или другой динамический язык на серверной стороное, перекроют ли плюсы минусы (в том числе такие особенности как недостаток опытных разработчиков в той или иной области).
Не думаю, что при оценке есть необходимость разбивать языки на статически и динамически типизируемые. Вот есть шесть «мэйнстримовых» языков для сервер-сайда веб-приложений (C#, Java, JavaScript, PHP, Python, Ruby) — оценивать нужно каждый отдельно, не группируя их по какому-либо признаку.
Node.js — серверная реализация языка программирования JavaScript, основанная на движке V8. © Википедия
asp.net — c# точно, остальные под сомнением, mvc — уже фреймворк…
Справедливо заминусовали — я не уточнил, что имею в виду языки .Net — VB, F#/J# и остальное в контексте того — можно ли на них писать под вед, а не то, что считаю php/perl/pynton/ruby/etc гадостью, на которой нельзя писать под веб — не беря классификацию программистов на этих языках (т.к знаю как хороших професионалов, так и г-кодеров)

Искренне прошу прощения у всех, кого обидел.
Javascript, один язык для фронтенда и бэкенда.
Это и есть node.js, как я понимаю.
НЛО прилетело и опубликовало эту надпись здесь
Руби-руби-руби!
НЛО прилетело и опубликовало эту надпись здесь
Почему не слово о технологии .NET (ASP.NET/MVC)?
Откуда такая ирония и отношение ко всему что связано с Microsoft?
Если опрос про мобильные системы то только iOS, Android, нету Windows Phone.
Если опрос про языки программирования то только Java, Python, Ruby, C/C++… все кроме C#.
Кто говорит сервелат вместо силверлайт, нокла вместо Нокиа.
Все начали винить Microsoft при малейших ошибках в Skype, когда еще только начали ходить слухи о покупке последнего.

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

А WP ничего так, существенных недостатков по сравнению с остальными системами немного (самой системы, а не экосистемы вокруг), есть преимущества, поддержу рублем.
Если проект большой, то стоимость лицензий — ничто. Что бы избежать оверхэда — Core режим. Если компания молодая — BizSpark. Еще и Azure c кучей плюшек.

Java и .Net нет смысла использовать для простых проектов ИМХО.
Как это стоимость лицензий ничто? Вот взять проект 50 серверов. Серверы многопроцессорные и много-много ядерные, следовательно лицензии соотвествующей стоимости (особенно, СУБД). Мало того что за эти лицензии можно еще штук 5 серверов купить, так еще и приходится копаться с бумажками, доказывать ДЦ что я не верблюд пират, разбираться в ньюансах ограничений разных типов лицензий и т.д.

Зачем мне это все вообще нужно? На oss выйдет дешевле и существенно проще. В корпоративном секторе, возможно, совсем другие понятия, но если говорить о массовых сервисах, то так оно и есть. Не говоря уже об отсутствии определенного серверного софта под саму Винду.

BizSpark это хорошо, чтобы не покупать продавцам Винду с офисом (пока компания не сможет себе с легкостью это позволить). А рассчитывать на него в продакшене проекта это попасть в ловушку «дешевле купить лицензии, чем переписать под *nix», после того как 3 года закончатся.

Самый главный останавливающих фактор для меня — возня с лицензиями. Я безмерно рад тому, что в своих 50+ серверах я ставлю что хочу и как хочу. Так, переход с 16ти поточного сервера на 32 поточный занял 10 минут (перекинуть винты). База автоматом начала работать в 2 раза быстрее. И я уверен, что я всегда смогу дать делать, а не буду кроме процессоров отдавать такую-же сумму за лицензии, ждать пока пройдут платежи и прочее (в то время, когда проект захлебывается от нехватки ресурсов).

У меня часто бывает так, что мы ставим до 10 серверов в неделю. Ставим 5, этого не хватаем, добиваем еще тремя, к выходным рост нагрузки съедает и это, мы оперативно добавляем еще пару. На сколько бы затянулся процесс, если бы я при этом 3 раза покупал лицензии, даже боюсь думать.

Я даже винду скачал с торрента, потому что МС предложил обновление за 15$, и заставил для апгрейта висеть больше 2х часов на телефоне, ничего в итоге не сделав.
Стоимость самих проектов составляет 99% бюджета=) И покупать софт без суппорта никто не будет.
Даже Linux будет платный Red Hat Enterprise Linux Server.

У МС есть разные способы лицензирования, думаю если засуммонить кого-нибудь из МС, то подскажут. У нас как-то все разобрали и админы особо не нервничают.

А в облака не пробовали переносить? ИМХО проще будет с таким типом нагрузок.

Кстати забыл еще про производительность: IIS + WAS, если мне память не изменяет, работают на уровне ядра ОС, даже не выходя в User-mode, то есть по сути сама винда — сервер приложений над железом.

Что такое стоимость самих проектов? Если вы имеете в виду разработку, то это не так. По крайней мере, если речь опять-таки не о корпоративном софте. А когда речь о не особо объемном, но довольно посещаемом проекте, то это не так.

Стоимость серверов в моем случае — сотни тысяч долларов. Тогда как разработка за последний год до сотни. Вся разработка ведут 5 человек, 2 из которых на аутсорсе и подключаются периодически. А серверов, даже если ничего не разрабатывать, мы еще на миллион за год легко сможем утилизировать.

За поддержку ОСС продуктов мы не платим. Да и мало кто не из сектора корпоративного софта, платит.

Зачем мне вообще свзязываться с МС и забивать себе этим голову? Я не вижу, где он мне хоть что-то сможет улучшить (ну может Visual Studio удобнее текущих сред разработки, я давно не пользовался). А проблем создаст массу.

Облака это у меня вообще не вариант. Мы их используем для 0.01% задач. Если туда перенести все, то в месяц обслуживание проекта обойдется более, чем в 100 раз дороже (если посчитать то, что мы сейчас тратим на закупки и размещения). Да и в нашем проекте они не справятся в принципе, такая уж его специфика.

Производительность я меряю не так. Заставить достаточно слабый сервер выдавать 20Гбит трафика на линуксе получилось с полпинка. В продакшене. Лишь немногим меньше в режиме медиасервера, а не просто раздачи файлов (уперлись в процессор, на другой платформе выжали бы 20 и в таком режиме). На винде я о таком даже нагуглить не смог, даже в синтетике.
Стоимость: ФОТ, стоимость того же железа, маржа. Допустим проект стоимостью 10 млн. р. — Несчастные 100 тыс. р. на лицензии — капля в море. Кстати VS2012+Resharper — конфетка =)

The Fastest Webserver? =) Сравнивать трудно, так как только IIS имеет доступ к ядру, а все остальные идут лесом. И является не только Web, но и App сервером(+WAS). Еще 2010 году был интересный топик на RSDN: IIS vs nginx

Все зависит от задач. Судя по вашим объемам — либо скорее всего видео раздаете или файловый хостинг. Тут я бы и сам не стал Винду использовать =)
У нас как раз один сервер на Винде выдерживает адовые нагрузки(OLTP), а пара шпарит не напрягаясь.

По поводу нагрузок еще можно посмотреть на, набивший оскомину в этих вопросах, Stack Overflow или Curse.com Platform Migration.

Просто сейчас серверный стек Винды не тот, что был во времена 2003 сервака, я до сих пор радуюсь что мы больше не поддерживаем IIS6.
Мы ж не аутсорсеры и не интеграторы, у нас нет фиксированной стоимости проекта. Сколько надо, столько и вкладываем. Лицензии откушают минимум 10% при наших текущих затратах, не говоря уже о юридическом и бухгалтерском геморрое. Я лучше бонусов больше сотрудникам дам или больше запаса серверной мощности обеспечу на эти деньги.

Вашим тестам я не верю. Не то, чтобы они были куплены, просто они синтетические и там данные для гигабита, что не серьезно, учитывая что мы сейчас под 40Г сервер проектируем, а 20 делаем с десктопа (серверный корпус, но i7 3770K). Гигабитная нагрузка у нас кушает 1-2% процесора, но для этого надо, конечно, правильно все настроить. Под линукс много кто раздавал порядка 10Г и больше с сервера на продакшене, потому мы без особых переживаний взялись за настройку. Повторюсь о подобных успешных попытках под Виндой я даже не слышал.

У нас есть как медиафайлы (мало запросов -> много-много трафика), так и рекламная сеть (много-много запросов, достаточно много трафика). Однако, ни там ни там я не вижу преимуществ ни у Винды ни у облаков, даже если убрать из уравнения стоимость лицензий.

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

В линуксе стек тоже отлично развивается. Когда был заметно слабее freebsd'шного, сейчас на голову выше. Собственно, под фрей 20Г на том-же железе, с которого такой трафик идет у нас, выжать практически невозможно (и это был весомых аргумент потретить много времени но перевести сервера на linux. Был бы такой для технологий МС, гляди к ему иначе бы относились).
Есть не только аутсорс и интеграция… Есть еще коробочные продукты=)

Презентация как раз о переезде на Asp.Net стек. Там много вони было в то время, так как этот проект до определенного момента часто приводился в качестве примера HighLoad на Python. Так же надо учитывать что Java и .Net на серверах дадут фору любому кроме разве что C/C++ с точки зрения эффективности.

Еще раз повторюсь, если нужна раздача контента, то проще поставить Linux, если у вас начинается что-то посложнее, то WinServer вполне торт. Если интересны примеры проектов, напишите в личку =)

Зачем мне примеры? Я вижу что продукты анаголичные моим делаются на asp, разве кто-то с этим спорит? Критичные highload части у меня работают не медленее, чем на java/.net потому, что я их транслирую в C++ код (автоматическим транслятором) и компилирую потом. А в админке все равно все работает со скоростью запросов к базе, да и там это не критично.

8 млн хитов в качестве highload проекта это такой себе пример.
Тем более, если вернуться к началу нашей дискуссии — все возможно на MS стеке, просто разные зоны комфорта и условия=)
Я и говорю, что разве что C/C++ могут фору дать.

У нас считаются не хиты, а проведенные транзакции… =)

PS. Не могу отвечать быстро. Слили карму. Даже подискутировать не дадут цивилизованно =)
Ну и что? Критичные куски как правило можно оптимизировать до уровня почти С++ (автоматический транслятор это не полная скорость С++, но близко). Та даже просто переписать на плюсах можно, если самая критичная часть небольшого объема.

Весомых преимуществ нету. Ну таких, чтобы даже на сложности со всм этим лицензированием забить. А при прочих равных, oss стек удобнее, как минимум отсуствием лицензирования. Потому, большинство веб-разработчиков выбирают его.
Опять же есть разный веб. И там, где вам необходима поддержка вендора (а такое может быть), то будут лицензии либо от RedHat, либо от Oracle, либо от MSFT, либо IBM.

Мы с вами говорим про разные типы проектов. Просто серебряной пули нет. И аналоги наших продуктов сидят под той же WebSphere. И тут ценник на столько разный, что лицензии от MSFT просто копейки, которыми можно пренебречь. Опять же — разные задачи, разные требования. Поэтому однозначно сказать, что Windows — какашка нельзя. Для определенного круга задач — это очень классная ОС с шикарным инструментарием.
Видимо, такие задачи среди посетителей Хабра не очень популярны (судя по результатам опросов).
Логично. По тем же вопросам безопасности вообще нескем поговорить. За 4 года собеседований не встретил ни одного человека, который бы мог предметно поговорить по SAML, WS-Trust, WS-Fed и тд.

Но такие системы есть, и они подчас выполняют очень тяжелые и критичные задачи. Только никто этого не видит =)
У меня есть друзья безопасники, они иногда бывают на Хабре. В данном случае, малая популярность ms стека объясняется в принципе малой популярностью его при разработке веб-приложений. На Си тоже не очень много сайтов делают, и потому он тоже ушел в «разное» )
Usage of web servers for websites

Доля IIS около 16%. Вполне достаточно для того, что бы попасть в список =) Так как по сути Топ 3: Apache, IIS, NGINX.
ну-ну=) могли бы уже 50 написать, чего стесняться, то;)

Если судить не о каких-то там сайтах, а на чем активно разрабатывается сейчас, то я не вижу у МС и 10% процентов. IIS наверное берет свою долю за счет крупных шаредов, типа godaddy, где сайты с одним хостом в день, но в общую стату попадает.

Если бы 16% было, то категория «другое», куда кроме МС еще много чего входит, набрала бы куда больше 11%
Как ни странно, достаточно небольшое кол-во разработчиков на .Net читают Хабр. Сейчас на собеседованиях спрашиваю есть ли учетки на Хабре, Github, SO и любимые блоги. Что бы не соврать, в прошлом месяце был человек, который предоставил учетку на SO =). Многие проекты просто не афишируют свой стек технологий. Хотя было бы интересно посмотреть. Тот же Azure вполне набирает обороты. Вон iCloud туда запихнули =)

Когда одно время фрилансил, наблюдал картину, что 90% заказов — допилить что-нибудь на Друпале и других CMS. На .Net было значительно меньше проектов, но это были долгосрочные контракты под разработку порталов и веб приложений для бизнеса ;-)
>Несчастные 100 тыс. р. на лицензии

на что? 100 к.руб — это 3 килобакса, на которые можно купить вполне приличный 1U-сервер.
Точнее, не так: на 2500k$ покупается сервер, на оставшиеся 500$ хорошие карточки, вроде двухпортовых на 82576.
>Кстати забыл еще про производительность: IIS + WAS, если мне память не изменяет, работают на уровне ядра ОС, даже не выходя в User-mode, то есть по сути сама винда — сервер приложений над железом.

http.sys, вы о нём? Но оно не умеет вебсокеты(точнее, умеет но с IIS8, который только вышел/выйдер).
Если вы захотите на своем сайте SPDY, то тоже мимо, потому что http.sys его не умеет :)

Т.е. чтобы добавить какой-то новый протокол MS вынуждена переписывать кусок ядра(ну и все прелести написания драйверов, где цена ошибки — BSOD или повреждение памяти ядра).

По факту IIS — это мультиплексор внутри ядра + утилиты по управлению процессами-воркерами.
IIS8 уже вышел =)

SPDY — пока не стандарт и даже переживать не вижу смысла. Сейчас и так бурлят говны по части HTTP 2.0.

Добавьте к нему AppFabric и WAS и все станет гораздо веселее =) Тут на днях в WebPI приехал ServiceBus 1.0 который раньше только для Azure был…

>Тут на днях в WebPI приехал ServiceBus 1.0 который раньше только для Azure был…

оок.

1)как использовать service bus из проекта на node.js/ruby/python/php?
2)правильно ли я понимаю, что оно использует soap 1.2 и со всем вытекающим счастьем(а именно, сериализация в xml? )
3)судя по описалову, там есть pub/sub. умеет ли оно рассылать сообщения мультикастом?
4)что у него с производительностью? 1млн сообщений в секунду сможет?

1. Вроде как можно. В Azure можно. Using Windows Azure Service Bus from Ruby Apps
2. Возможна бинарная сериализация: Service Bus Bindings (NetTcpBinding). В соапе кстати в таких сценариях ничего плохого нет. Мне будет весьма интересно посмотреть на сценарий федерации с несколькими секьюрити доменами на уровне сервисов без него.
3. Умеет. Multicast with the .NET Service Bus (Видео туториал)
4. Тут еще сам не гонял. Так что не скажу. В облаке вроде на 1 сообщение у них уходит 2.1 микросекунды.
Если не секрет, какая шина может 1 млн. сообщений в секунду отослать? И на каком железе?
>1. Вроде как можно. В Azure можно. Using Windows Azure Service Bus from Ruby Apps

500 (Internal Server) Error
...that we're working furiously to correct. Things will be up and running again soon. Thanks for your patience.

>2. Возможна бинарная сериализация: Service Bus Bindings (NetTcpBinding).

в каком формате? спецификация на него есть?

>В соапе кстати в таких сценариях ничего плохого нет.

soap плох тем, что это xml(и все бонусы в виде дикого оверхеда).
ну и костылик в виде WSSE.

>Мне будет весьма интересно посмотреть на сценарий федерации с несколькими секьюрити доменами на уровне сервисов без него.

вы сейчас о чём вообще? ну т.е. слов умных много, а смысл фразы мне не понятен. обычно так маркетологи говорят.

>3. Умеет. Multicast with the .NET Service Bus (Видео туториал)

А не в варианте RPC оно умеет? мультикаст там в каком виде? просто IP или же в UDP?

>4. Тут еще сам не гонял. Так что не скажу. В облаке вроде на 1 сообщение у них уходит 2.1 микросекунды.

2.1 микросекунды на что? на сериализацию? вот смотрите, отправку можно разбить на несколько этапов:

1. сериализация
2. формирование сообщения для выбранного транспорта
3. прохождения всего этого счастья через ip-стэк хоста
4. отправка сетевой карточкой.

вообщем, я слабо верю в 2.1мкс.

>Если не секрет, какая шина может 1 млн. сообщений в секунду отослать? И на каком железе?

www.zeromq.org/results:10gbe-tests-v031

Box 1:

8-core AMD Opteron 8356, 2.3GHz
Mellanox ConnectX MT25408 in 10GbE mode
Linux/Debian 4.0 (kernel version 2.6.24.7)
ØMQ version 0.3.1

Box 2:

8-core Intel Xeon E5440, 2.83GHz
Mellanox ConnectX MT25408 in 10GbE mode
Linux/Debian 4.0 (kernel version 2.6.24.7)
ØMQ version 0.3.1

подозреваю, что более свежем железе и ядрах цифры будут поболее.
там ещё есть тесты на infiniband.

1. Погуглите на тему Azure ServiceBus and Ruby etc. С этим проблем нет. У меня ссылка открывается.
2. Там стандартный бинарный сериализатор. Вроде позиционный если мне память не изменяет.
Оверхед для одних, и убер штука для других. Еще раз — как вы будете делать федерацию между несколькими секьюрити доменами? У кого-то есть необходимость и подписывать сообщения и шифровать, а еще аутентифицироваться через керберос.
3. Сейчас рассматривают UDP. Думаю впилят, так как в WCF есть поддержка.
Бэнчмарк Windows Azure показал высокую производительность для масштабных вычислений
4. Добавьте подпись, шифрование, гарантию доставки и цифирьки скукожатся.

Кстати Pub/Sub with ZeroMQ on Azure

Так что никто не мешает и на Винде поднять, если не надо тех вещей, которые предоставляет сервисная шина, например How to integrate a WCF Workflow Service with Service Bus Queues and Topics
>2. Там стандартный бинарный сериализатор. Вроде позиционный если мне память не изменяет.

ок. в каком виде там хранятся int? LE/BE? как кодируется float? какие структуры данных поддерживаются?

вообщем, чем оно лучше asn.1 или google protobuf?

>Еще раз — как вы будете делать федерацию между несколькими секьюрити доменами?

вы объясните, что вы под этим понимаете.

>У кого-то есть необходимость и подписывать сообщения и шифровать

в чём проблема? zmq предоставляет базовые элементы из которых собирается любой мыслимый(и не мыслимый) MQ. если вам так хочется иметь брокера, то есть amqp и rabbitmq/qpid.

Кстати, о лимитах:

msdn.microsoft.com/en-us/library/windowsazure/ee732538.aspx
msdn.microsoft.com/en-us/library/windowsazure/hh694235.aspx

>With Service Bus Queues, each message stored in a queue is comprised of two parts: a header and a body. The total size of the message cannot exceed 256 KB.

>It is also important to remember that messages in Service Bus queues are comprised of two parts: a header and a body. The total size of the entire message (header + body) cannot exceed 256 KB. The Service Bus brokered messaging API uses binary XML serialization (not text XML), which reduces the output size of the serialized payload, and while this in turn enables storing messages slightly larger than 256 KB, you must test the reduction in size that you see for your own application.

Calculating the Capacity of Service Bus Queues and Topics
Let’s look at the basic algorithm to calculate the size of messages, and therefore what kind of Service Bus queues or topics you might need for your application.

An empty message has a body size of 1024 bytes and default header size of 156 bytes; including other elements, this rounds out to a total of 1635 bytes in a message with no custom headers or properties and an empty message body.

т.е. в сетях без jumbo frames 1 сообщение не будет помещаться в 1 tcp-сегмент.

>4. Добавьте подпись, шифрование, гарантию доставки и цифирьки скукожатся.

затормозить можно всегда. а вот разогнать — нет. нужна гарантия доставки — используйте tcp.

>Так что никто не мешает и на Винде поднять, если не надо тех вещей, которые предоставляет сервисная шина

вот и возникает вопрос: зачем связываться с Service Bus?

пока я вижу очередную инкарнацию MSMQ. только её авторы посмотрели на AMQP и на ZMQ.
Никто не заставляет юзать MSSQL. Это так, к слову. У .net есть отличные коннекторы к любым популярным БД. И windows server не обязательно использовать, ибо Mono существует во вполне приличном состоянии. Так что лицензии остаются только за средства разработки, а это уже стоит того.
Ну знаю, я бы не стал так делать в продакшене. Вполне приличное состояние может обернуться суровым геммороем в самый неподходящий момент, когда народу на сайт ломится много, mono переклюнило и что делать вообще неясно.

Про php, python, perl и т.д. по крайней мере точно известно, что они готовы к очень большим нагрузкам при правильной архитектуре.
Есть Mono :)
Экспериментирую на темной стороне, vibe.d (D language) + Dart/JavaScript, но считаю, что такие извращения понравятся только таким «ценителям», как я.
Ууу, как круто, насколько D удобно для этого использовать? Никогда на нем под вебы не писал.
На удивление получается неплохо, сам фреймворк работает как роутер для адресов страниц и серверной логики (работа с бд, уровни доступа и т.п.), шаблонный движок jade используется для отрисовки, dart — для динамики фронтэнда. Главная проблема — все очень сыро и недоработанно, фреймворк еще на стадии беты.
Интересно, патылся ли кто-нибудь писать сетевые сервисы (в тч и web) на языке Go? Как ощущения?
Ощущения отличные, правда у меня в production еще ничего не пошло. Сразу рекомендую не использовать полновесные фреймворки, как Revel, а собирать приложение, используя отличную стандартную библиотеку GoLang'a и тулкит Gorilla.
C# (ASP.NET) + JavaScript (knockout.js)
twitter bootstrap активно использу + jquery
Для веб-ПРИЛОЖЕНИЙ — Java. Для сайтов — что угодно.
Именно, я тоже на это указывал выше, что сайт и приложение это большая разница.

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

Для себя и на перспективу — Ruby, т.к. нравится изначальная идеология, которую автор заложил.

Ну и для развлечений — ECMAScript на обоих сторонах :)
ну что значит чисто экономически?
Проекты разные, требования разные, бюджет разный.
Сайт визитку на java писать никто не будет. равно как и enterpirse level приложения на php.

Кроме того приличные програмисты что на php что на ruby или python стоят примерно одинаково.
Просто забейте в любом сайте о работе php / и прочее.

Плюс сравнение з.п. тута уже было — php меньше => выгоднее.

А меньше, т.к. зрз-стов больше. Тупо экономика.

ps: Я ни в коем случае не холиварю — это банальная констатация ситуации.
Кстати хотелось бы видеть мнение менеджеров на этот счет. Выбрали бы они «сомнительные/модные» языки как основу для серверного кода.
Ни за что :)

Выбор был бы исходя из доступности специалистов на рынке и экспертизы внутри компании. Какие-то специфические языки рассматривались бы только ну если совсем никуда без этого.

Скажем, из списка:

PHP — да
RoR — нет (мало спецов)
Python — скорее нет (мало спецов)
Node.js — нет (специалист по JS стоит в ~2 раза дороже php-шника)

Зато в список вариантов добавились бы пресловутые c# и java.
Затрудняюсь ответить. Про Node.js знаю, утрируя, только по статьям на Хабре, то есть плюсы, но не минусы :) PHP без фреймворков можно из подобных опросов исключать давно, либо не упоминать RoR и Django, имея в виду голые Ruby и Python (ну, с *GI). А так если выбирать PHP (sf2 или yii или ещё что-то в этом роде), Ruby (RoR) или Python (Django), то выбирал бы в зависимости от бюджета между PHP и Ruby. Ruby субъективно обойдётся дороже, но код будет более поддерживаемым (если не давать разработчикам увлекаться метапрограммированием и прочей эзотерикой :)
Если не секрет, то почему пыхтон вычеркнули из личного списка?
Не столько он, сколько Django. Сам Python нравится, пишу на нем всякие утилитки, но вот Django как-то мне не показался простым и логичным фреймворком. Частенько приходилось копипастить из интернетов код, толком не понимая что он делает. В общем не мог научиться его готовить.
Посмотрите в сторону Flask, возможно понравится, очень простой микро-фреймворк.
Главная фишка фласка не простота, а удачная и довольно продуманная архитектура.
Странно, ни слова про GWT, а ведь для больших веб-приложений Java + GWT используется нередко.
Для себя я выбрал Perl + Mojolicious
Что-то у меня стойкое ощущение того, что человек тут захотел получить в копилку инвайт, но темы патентной войны Эппла с Самсунгом или сравнение Android с iOS решил не использовать.
А почему выбирается только один ЯП?
Успешно можно использовать и node.js и PHP. Причем вместе.
Для отдачи статических страниц, PHP неплохо подходит. А вот для поддержки «online» и сложных каких-либо выполнений, вполне шикарен node.js.

А так все зависит от конкретной задачи. Понятие веб-разработки сейчас довольно таки широковато =)

Про фреймворки вопрос не задавался, тему значит и не буду раскрывать.
>Для отдачи статических страниц, PHP неплохо подходит
Серьезно?
Ога, а на javascript можно писать банковские приложения :)

Причем ихние корки — не фронты. И без тестов конешно же!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории