> как вообще будет одновременно работать сразу 2 сервера например?
Здесь я имел в виду два железных/виртуальных сервера, т.е. две разные машины. Теоретически конечно можно настроить и две экземпляра веб-сервера на одной машине, возможно это подойдет для вашего сценария с деплоем. Но устойчивости к сбоям это прибавит немного. Обычно, если простой во время деплоя достаточно критичен, то уж тем более критичен простой из-за поломки сервера, и поэтому сразу заботятся о проблеме дублирования серверов и распределения нагрузки.
Само собой, вам нужно будет продумать механизмы исключения серверов из ротации, чтобы тот же nginx не пытался передать запрос к серверу, который сейчас деплоится и который трогать нельзя.
Vlad Harbarchuk
> TypeScript :)
вполне себе решение, только тогда получается что JS - это какой-то промежуточный язык. Потому я и обрадовался WebAssembly - сколько можно мучать JS, минифицировать его и uglify-ить.
Vlad Harbarchuk
> ну так для клиентской разработки есть js \ фронтенд разработчики
вы так говорите будто это рабы какие-то)). Ну вот кстати и объяснили, почему среди фронтендеров так много молодых людей - 70-80% это те, кто сразу начал JS и ему стало хорошо. Только это какое-то неправильное направление развития технологий - если я хочу стать фронтендером, значит мне надо полностью переосмыслить мои умения по моделированию мира? Или нужно на государственном уровне поддерживать нужную концентрацию JS-разработчиков, чтобы было кому делать фронтэнд?))
Если б это "переосмысление" было нужно для работы с каким-нибудь искусственным интеллектом (как было, когда создавали Пролог) - тогда другое дело, но для анимирования многострадальных div-ов и span-ов это как-то слишком).
Идеальный выбор - это когда язык подбирается по конкретной задаче+мышлению разработчика (как сейчас на дотнете - есть ООП-шный C#, есть более функциональный F#, есть даже IronPython), но уж никак не под целевую платформу (неважно - аппаратную или виртуальную).
> играет злую шутку с теми, кто уже знает несколько языков
куда более злую шутку он играет с менеджерами проектов, которые считают, что можно тех же людей, что делали десктопный клиент пару лет назад, приспособить для разработки веб-клиента. И они искренне не понимают, почему это невозможно. Я вот в принципе тоже не понимаю, как мы к этому пришли)). Брать других людей и переписывать клиент почти заново - это такое было в 60-х годах с операционными системами, до того как придумали Си и ядра ОС писались на асме - приходилось переписывать почти все заново для поддержки новой архитектуры.
Vlad Harbarchuk
Но эти попытки писать "java-style" в JS напоминают как человек из винды переходит на мак
действительно, но человека, вероятно, никто не заставлял перейти нам мак (ну мне не встречались такие случаи, что кто-то бы это делал вынужденно), если ему удобно - он останется на винде. А с JS выбора как бы и нет. Точнее он есть только за счет compile-to-js языков.
Поэтому я и говорю, что у js сейчас роль ассемблера для веба: не РАЗРАБОТЧИК выбирает этот язык, его выбрали за разрабочтика случай и история. Это все равно что под десктоп или на бэкенде нужно было бы разрабатывать на асме под конкретную аппаратную платформу, а не на любимом ОО/функциональном/процедурном языке. Конечно, сравнение на совсем точное - JS гораздо более высокоуровневый язык (даже слишком высокоуровневый - проекты asm.js и WebAssembly это подтверждают), и как бы можно разрабатывать непосредственно на нем, но если тебе в нем что-то не подходит - ситуация с ассемблером повторяется.
Я вот к тому же не перевариваю динамические языки. Просто не в состоянии их нормально использовать. Для меня отсутствие таких базовых проверок на стадии компиляции, как проверка типов - сущий адъ. Мне нужно хорошенько выспаться, чтобы суметь написать адекватный код на динамическом языке, и не накосячить. И это вопрос уже куда более серьезный, чем прототипное vs классовое ООП. Что же мне делать с JS?
@SilvaGT
> Да и сахар классов уже в ES6 есть.
я поэтому ES6 и упомянул
> проблема JS вся в том, что люди пытаются впихнуть туда философию к которой они привыкли
да, конечно в этом проблема. Хотя нет, не совсем в этом - проблема в отсутствии выбора.
Одно дело - упираться рогами и говорить "Кобол - лучший", не пытаясь выучить хотя бы один современный язык, а другое дело - когда тебе (и многим другим людям) удобно пользоваться некоторым способом представления мира, но пользоваться нормально ты им не можешь, т.к. со стороны языка он не поддерживается. Абсолютно аналогичная ситуация складывается и при использовании чисто функциональных языков в задачах, которые плохо ими моделируются. Эта проблема нисколько к JS не привязана, и называется "выбирай подходящий инструмент".
А вот реальная проблема - это необходимость использовать JS при клиентской веб-разработке. Ее и фиксят языки, компилящиеся в JS. Переучиваться думать и пытаться решать старые задачи совершенно новым способом только потому, что тебе НУЖНО разрабатывать на каком-то языке - это один из самых эффективных способов приблизить производительность любого программиста к нулю. Выучивать "новую философию" хорошо только тогда, когда это твоя первая философия. Когда она не первая, и ты уже решил 1000 и одну задачу на C++/C#/Java/VB/... и познакомился с нужным тебе количеством языков разных парадигм, то учить ЕЩЕ один набор парадигм захочется не каждому.
Николай
> Brackets - написанн на HTML, CSS и JavaScript
И поэтому я его снес почти сразу как поставил)) То же и с VS Code. Атом, который первым появился, может и достоин быть в своей нише, но все эти его бесконечные клоны... О боже, за что нам это.
Vlad HarbarchukПума Тайланд
Чего вы за ассемблер схватились? Возьмите Лисп)) На нем тоже можно много написать, чуть ли не все на свете, только чет никто не хочет. Vlad Harbarchuk
Тут особо объяснять нечего, сейчас JS это нечто среднее между нормальным языком и ассемблером для веба. Я тут не случайно Лисп вспомнил - как и его, джаваскрипт надо "допиливать" код-стандартом, условностями и договоренностями, чтобы нормально с ним работать. Ситуацию немного исправляет ES6, но все равно мало. Вот скажите, почему, когда я прихожу в крупный проект на JS, я должен спрашивать, как команда пользуется понятием "класс"? Почему я должен выяснять, что мне искать в тексте - SomeThing.prototype.method = function() { .. } или SomeThing.extend({ ... })? Или может быть обе конструкции прменяются одновременно?
Ах да, ребята оказались не пальцем деланные, и решили взять TypeScript (CoffeeScript/etc, нужное подчеркнуть), чтобы не решать такие вот вопросы. Стоп, а зачем нам еще один язык, который компилится в JS? Я не помню такого с C#. Вспоминается разве что генерация lexer-ов и parser-ов из какого-нибудь DSL, но это отдельная история, так все делают.
Выводы просты и очевидны: 1) в языке должны нативно поддерживаться конструкции, удобные для людей, на нем разрабатывающих (иначе зачем нам нужно 10 000 языков? Ради разного синтаксиса??); 2) чем больше в языке способов решить одну и ту же простейшую задачу - тем хуже. Когда каждая команда изобретает свой способ имитации классов поверх прототипной модели - это, простите, п....ц.
iegor в основном потому, что определение адресов вызовов кода и чтения/записи данных происходит во время выполнения, а не компиляции (которой как таковой может не быть). Почитайте про раннее и позднее связывание.
Если уж иерархию доменов вводить - тогда можно просто subdomain вместо com.youtube.subdomain) А если еще и com.youtube разбить надвое, то можно отказаться от разворачивания наоборот
logosan в вашем случае поступить проще так: ViewModel_1 должна отдавать ViewModel_2, например в виде одного из свойств, View_1 должна переключаться на View_2, плюс DataContext для View_2 нужно перед Navigate установить во ViewModel_2.
Тогда ViewModel_1 сможет создать и настроить ViewModel_2 так, как ей захочется (например, передать нужные значения в конструктор ViewModel_2 или присвоить значения свойствам..)
jonasas
> А где будет оказываться результат перекодировки каждого байта koi8?
А возвращаемое значение функции для чего сделано?) Там как раз uint32_t, т.е. 4-х байтовый инт. Это символ Юникода "как есть", в кодировке UTF-32 (она же UCS-4). Цитирую википедию (https://en.wikipedia.org/wiki/UTF-32):
> UTF-32 (or UCS-4) stands for Unicode Transformation Format 32 bits. It is a protocol to encode Unicode characters that uses exactly 32 bits per Unicode code point. This makes UTF-32 a fixed-length encoding, in contrast to all other Unicode transformation formats which are variable-length encodings
Вот тут как раз и написано, что кодировка дает постоянный размер символа в 4 байта (32 бита) в отличие от остальных.
Чтобы перевести в UTF-8 вам теперь нужно ЗАКОДИРОВАТЬ ваш набор uint32_t уже ДРУГИМ ковертером в UTF-8 с помощью www.boost.org/doc/libs/1_55_0/libs/locale/doc/html... - вот смотрите, она делает все с точностью до наоборот - принимает символ Юникода (uint32_t) и пишет его по указанным адресам (она-то вам и запишет 2 байта для каждого символа кириллицы), и возвращает либо количество записанных БАЙТ (т.е. на сколько вы должны сместить указатель begin при следующем вызове функции), либо ошибку.
@jonasas
> Если он конвертирует single character, то для чего ему тогда длина строки?
разумеется потому что single-character Юникода может представляться несколькими байтами. char в C++ - это БАЙТ. Unicode может кодироваться по-разному, но в том же UTF-8 длина ОДНОГО символа юникода может варьироваться от 1-го до 4-х байт (или даже до 6, не помню точно). Сохраните русский текст в UTF-8 и посмотрите HEX-редактором содержимое такого файла. Там каждая расская буква будет кодироваться ДВУМЯ байтами. Поэтому функция и принимает указатель на конечный символ (чтобы знать, до какого места можно идти при поиске верной последовательности в исходной кодировке, чтобы не проехаться по чужой памяти). Конечно в koi8-r символы будут однобайтовыми, но это ж общий интерфейся для всех кодировок.
ОДНАКО функция перекодирует только ОДИН юникод-символ, и если она находит валидную последовательность байт, то сдвигает первый аргумент на начало следующей последовательности (если вы внимательно посмотрите, первый аргумент передается по ссылке, что как бы намекает).
Таким образом, рецепт очень простой: берем байты строки в исходной кодировке, передаем в эту функцию два указателя - первый будет переменным - функция будет САМА его двигать в процессе перекодирования, второй - постоянным - это будет конец исходного байтового буфера. Далее в цикле вытаскиваем по одному символу, пока а) функция возвращает НЕ ошибку (т.е. валидный символ) б) строка не закончилась, т.е. первый указатель не равен второму (конечному). Вот и все.
> собирается очень напряжно и очень долго
серьезно? о.О Вы про саму либу или про проекты с ней? Если про либу - ну да, это плюсЫ, шаблоны и так далее, да и какая разница, если ее один раз собрать надо. Если про проект, который ее инклудит - не знаю как у вас, у меня тот же JSON Spirit отъедал гораздо больше времени компилятора, пока мы его не вынесли в .lib
Ifry если вам эллипсы только "для рисования", и их надо много - правда подумайте о другом API, как AxisPod посоветовал. WPF идеален для случаев, когда много контролов или полуинтерактивных элементов, т.е. когда нагрузка по отрисовке и обеспечению интерактивности примерно одинаковы (например, вам нужно, чтобы все эти эллипсы выделялись). А вот когда нужно очень много отрисовать, а интерактивность вам не нужна для каждого элемента (как, например, в видеоигре), то лучше брать более никзоуровневые API, тот же Direct3D или OpenGL. Если еще ими и правильно пользоваться (например, заранее готовить наборы примитивов для отрисовки), вы ими отрисуете и миллион эллипсов.
Распределение с помощью DNS: https://en.wikipedia.org/wiki/Round-robin_DNS
> как вообще будет одновременно работать сразу 2 сервера например?
Здесь я имел в виду два железных/виртуальных сервера, т.е. две разные машины. Теоретически конечно можно настроить и две экземпляра веб-сервера на одной машине, возможно это подойдет для вашего сценария с деплоем. Но устойчивости к сбоям это прибавит немного. Обычно, если простой во время деплоя достаточно критичен, то уж тем более критичен простой из-за поломки сервера, и поэтому сразу заботятся о проблеме дублирования серверов и распределения нагрузки.
Само собой, вам нужно будет продумать механизмы исключения серверов из ротации, чтобы тот же nginx не пытался передать запрос к серверу, который сейчас деплоится и который трогать нельзя.