И mov с кодами 88-89 (я тоже не помню уже коды по памяти) — это две разных команды, которые пойдут на разные группы транзисторов в процессоре.
Группа команд одинаковая «mov», а вот тип команды да — разный. Как уж там куда в процессоре пойдет — зависит от того, как конвеер сделан, например mov для регистр-в-регистр, ЕМНИП, будет выполнятся одинаковым конвеером (ну или транзисторами :))
А Долан как раз про это и писал — по сути группа mov — это отдельный ассемблер в ассемблере )
И, кстати, вы же рассматриваете всерьез идею перейти только на mov-инструкции по причинам, которые перечислены в статье?
Я это рассматривал как один из вариантов обфускации ну и просто как забавный факт.
Ну во-первых, здесь пока говорится только про x86.
И про обычный (а не макро) ассемблер, у которого каждая мнемоника имеет вполне четкий байт-код, т.е. мнемоника (ну или команда, или инструкция) — это просто название для соответствующей кучки кодов, в которую она всегда однозначно превращается, и по которой и работает процессор.
Поэтому мнемоника mov имеет вполне четкое отражение 1-в-1 в машинном коде. посмотрите на дамп вверху (думал что там коды, а это адрес :)).
Если взять код программы уже в mov-ах, то там будет постоянно повторятся один и тот-же код каждую новую строчку — это и есть код мнемоники mov, а дальше будут идти ее аргументы.
Это если просто, а если сложно, то код mov в x86 тоже не постоянный и варьируется, т.к. это указывает на тип mov операции, например «88» это «mov [di],dl» а «89» это «mov [si],cx» (коды по памяти, могу ошибаться с точным значением).
Т.е. в обычном асме одна команда = одному набору кода + коды аргумента.
Просто конкретно для mov — это интервал кодов, т.к. туда зашит тип mov — пересылка ли из регистра в регистр, или, например, косвенная пересылка и тд.
Обычный асм — только для конкретной системы, пример — аналог команды асма «mov» x86 для Z80 будет «ld» с абсолютно другим кодом — т.е. и код будет отличаться и мнемоника.
А вот макро-ассемблеры и тд — там уже да, может быть и под разные системы и т.д.
Однако, есть описание и стандарт на DOM где указано, что там и как возвращается и как должно интерпретироваться.
А в вашей вселенной это будет другое описание и стандарт.
И чтобы не порождать всякую магию — достаточно чуть-чуть знать стандарт, с объектами и свойствами которого ты работаешь. И тогда не будет живых/мертвых/дохлых коллекций, а будет четкое представление, что это.
Ну самое забавное — видеть эту дичь в блоге HTML-academy.
В случае с обращением к DOM вы берете ссылку на коллекцию, естественно внутри нее все меняется в зависимости от состояния самой коллекции.
А querySelectorAll возвращает каждый раз новую коллекцию с DOM элементами внутри. Это другое состояние. Грубо говоря это список того, что вы запросили, и он, естественно, никак не связан с DOM, хотя его элементы — связаны.
А я надеялся на ответ типа: «В следующей статье, я как тех.лид, расскажу о стэке технологий, применяемой у нас, и о проектах в рамках нашей сферы деятельности и вы измените свое мнение о нас»
… но нет.
Но сейчас уже третий эшелон переходит на собственную разработку.
Ага, но разработка эта все еще такая-же, да, новее, чем в нулевые, но все также безнадежно отсталая и оторванная от всего остального.
А затолкать все в одну статью нереально.
А вы меньше воды лейте — у вас вся статья — одна вода. Ни тех подробностей, ни стэка — НИЧЕГО.
но где эта самая «сладкая муть»
Вот:
Наши банки быстро поняли плюсы удаленной работы с клиентами
тащиться в отделения теперь ну просто дурной тон
Появилась здоровая конкуренция за клиента.
А оплата услуг кого-то, кто кроме работы программиста оплачивает еще и протирание штанов 5-6 менеджеров на совещаниях, стала казаться избыточной.
Нужно было делать продукт, который удовлетворит всех, и желательно, если он вместе с этим даст уникальный, никем еще не растиражированный опыт.
В общем, легко найти проект по душе и максимально полно применить свои скиллы
И самое сладкое:
В общем, гоу к нам — мы создаем. Потому что мы можем.
Еще надо? — я тогда всю вашу статью на цитаты растащу.
Вы считаете, что телефонный спам это «конкуренция за клиента»? Или может быть тащится по каждому чиху не надо? Не смешите. Вы используете другие технологии для этого и не абузите чужое время? Так и напишите тогда про это.
Вы хотели привлечь технарей к вам маркетинговой статьей, серьезно?
Еще раз — начинать надо было с того, о чем я выше писал — со стэка, с технологий, с того, ради чего было-бы интересно к вам пойти.
А так вся ваша статья может быть заменена одной фразой: «Мы стали другими, у нас тут горы работы всякой (мелким текстом: оставшейся со времен когда мы были прежними), приходите разгребать наши авгиевы конюшни!» — и конечно, это прямо привлекательно и продающе! — и народ ломанулся вам в HR-отдел звонить…
Это все еще верно для большинства банков, за исключением сильно прогрессивных, коих единицы. И ваш, ИМХО, в них, увы, не входит. Во всяком случае пока.
Именно поэтому у них давно нет никаких «мы преодолеем», там абсолютно другой подход.
Хотите показать, что Вы — другие? Тогда вместо маркетинговой чуши опишите реальные задачи, которыми занимались, что делали, как изменили, какие технологии — это да, интересно, это может повлиять на кредит доверия.
А пока что, судя по тексту, полностью состоящему из сладкой мути и полному отсутствию конкретики, все точно такое же как и во всей вашей сфере — только сладкие да красные словца и надувание щек, а на деле — пузыри с метаном.
Прямо сахарной маркетинговой ватой потянуло, настолько все приторно. Прямо красный стоп сигнал из цикла «У нас есть печеньки!».
В здравом уме люди пойдут работать к вам в банк только если будут ну ооочень хорошие плюшки.
Потому что большинство банков — это заросшее болото легаси с плавающими кусками всего, что только было (и микросервисов, и порталов и других веб-кусков и сервисов), иногда уже полуразложившихся, потонуть которым мешает материал, из которого они сделаны.
И попав в такое болото один раз, скиллы, в нем полученные, пригодятся только в этом самом или подобном болоте.
Вы размер сегментов и их количество тоже учитывайте. ЕИнк при статике не жрёт вообще ничего — а это его обычное состояние на ценнике. Кроме того, ЕИнк матричный, а матричный ЖК будет жрать очень много в сравнении.
Расскажите, что за интегратор такой ответственный? :D
Я не встречал, а знаю разных — от ИРБИСа до КРОКа.
Да, сотрудники там действительно грамотные.
Но в большинстве случаев оно работает абсолютно не так, как Вы описываете.
А так (приводу пример ЛИЧНО подслушанного разговора):
Сотрудник: Я обсудил проблему заказчика с коллегами, мы пришли к мысли, что очень хорошо им подойдет технология X...
Проджект: Сколько мы сможем срубить, продав им это решение?
Сотрудник: Она бесплатна, Apache Foundation...
Проджект: Ненене, мы это все поддерживать не хотим и не будем, есть коммерческие имплементации?
Сотрудник: Да, но они тяжелые и очень дорогие и предназначены для куда более тяжелых и общных задач...
Проджект: ОООТЛИЧНО!
Вобщем, интегратор практически всегда (речь идет о российских интеграторах, на западе все куда интересней — там есть страховка от факапа и интегратор обязан взять ее из банка и предоставить — таково их юр. право) пытается не нести ответственность за свои решения и внедерения и всеми способами увиливать от гарантийного обслуживания, если оно не несет мат. выгоду.
Естественно, это не означает, что нет неадекватных клиентов — их тоже хватает. Но вот адекватных интеграторов я у нас не встречал.
Я встречал их более-менее адекватные интеграции, но их было гораздо меньше, чем тех, которые делались по тому принципу, что я выше описал. Иногда было и просто неверное решение — возможно связанное с очень узкой спецификой задачи и отсутствия нужной компетенции у сотрудников интегратора в принципе.
Встречал я и достаточно кабальные договора для интеграторов со стороны клиента, которые вынуждали последних нести гарантийные и пост-гарантийные обязательства надлежащим образом, но было это не в айти, а на производстве — но там несколько проще с оговором факапа и его проверкой. А интегратор брался за них, так как по цене они были очень заманчивые, правда потом они хватались за голову, потому как «наговнокодить» там куда сложнее, за последствия можно схлопотать срок, а стоимости отдельных узлов сильно отличаются от пузырей в айти и их «не прожать».
По-сути, наш интегратор в большинстве случаев — это перекуп со своим отделом консалтинга и пресейла, все. У КРОКа и по-моему у еще одного большого интегратора из Мск (забыл название) есть еще лаборатория — для нестандартных решений, но решения оттуда всегда получается совсем не адекватными по цене. Но зато это «свои» решения — это куда лучше, чем просто перекупить, ИМХО.
Опыт очень многих людей и в том числе и меня, утверждает следующее — если можно обойтись без интегратора — лучше без него обойтись.
Возможно это будет дольше, но продукт будет лучше, четче подходить под задачу и куда более предсказуем. При этом сторонние вендоры, чьими решениями вы захотите воспользоваться, будут вам в этом очень сильно помогать, так как заинтересованы в распространении и поддержке своих продуктов. А если привлечь двух или более конкурирующих — вы еще и решение получите по лучшему соотношению цена/качество, ну или по крайней мере будете понимать, что упустили, в отличии от интеграционного «черного ящика».
Впаривание происходит на высших кругах менеджмента/директорства с вливанием меда в уши по цене, о которой там договорятся и рыноком там даже и не пахнет.
Причем, зачастую, решение интегратора оказывается далеко не лучшим на рынке.
Разгребать конюшни потом приходится локальному IT-отделу, потому что у интегратора — лапки, и вообще — акты уже подписаны.
А когда узнаешь, сколько интегратор выставил за перекупленное не свое решение, тихо охреневаешь и думаешь — хочу работать у интегратора :D
По факту вообще оказывается, что все сделали другие ребята, а интегратор — это просто прокладка, которая и ответственности не несет, да и не делала ничего — просто нашла на рынке и перепродала.
А те, кто обожглись на таком раз, начинают не доверять вообще айти в целом, хотя IT-то и не виновато вовсе.
Я потому и пытался узнать здесь стоимость решения у КРОКа — но видимо это настолько секретные (или фантастические) данные, что они даже написать ничего не могут.
Но можно уточнить у корейцев, чьими ценниками они пользовались — я уже им написал.
Вангуется мне, что раз они не отвечают на этот вопрос — впарили они свое решение ритейлу в тридорога, как обычно интеграторы и делают. При этом кроме инфраструктуры и одной обработки для 1С (возможно даже не их, а какого-нибудь 1С аутсорсера), они больше ничего и не делали, а подается это с таким пафосом, как-будто они орбитальный комплекс сами лично построили и запустили.
А Долан как раз про это и писал — по сути группа mov — это отдельный ассемблер в ассемблере )
Я это рассматривал как один из вариантов обфускации ну и просто как забавный факт.
И про обычный (а не макро) ассемблер, у которого каждая мнемоника имеет вполне четкий байт-код, т.е. мнемоника (ну или команда, или инструкция) — это просто название для соответствующей кучки кодов, в которую она всегда однозначно превращается, и по которой и работает процессор.
Поэтому мнемоника mov имеет вполне четкое отражение 1-в-1 в машинном коде.
посмотрите на дамп вверху (думал что там коды, а это адрес :)).Если взять код программы уже в mov-ах, то там будет постоянно повторятся один и тот-же код каждую новую строчку — это и есть код мнемоники mov, а дальше будут идти ее аргументы.
Это если просто, а если сложно, то код mov в x86 тоже не постоянный и варьируется, т.к. это указывает на тип mov операции, например «88» это «mov [di],dl» а «89» это «mov [si],cx» (коды по памяти, могу ошибаться с точным значением).
Т.е. в обычном асме одна команда = одному набору кода + коды аргумента.
Просто конкретно для mov — это интервал кодов, т.к. туда зашит тип mov — пересылка ли из регистра в регистр, или, например, косвенная пересылка и тд.
Обычный асм — только для конкретной системы, пример — аналог команды асма «mov» x86 для Z80 будет «ld» с абсолютно другим кодом — т.е. и код будет отличаться и мнемоника.
А вот макро-ассемблеры и тд — там уже да, может быть и под разные системы и т.д.
Вот такая вот штука.
Эта программа переводит .c код (или обычный машинный код) в машинный код, который состоит только из одной команды move но с разными аргументами.
И штука реально прикольная )
Однако, есть описание и стандарт на DOM где указано, что там и как возвращается и как должно интерпретироваться.
А в вашей вселенной это будет другое описание и стандарт.
И чтобы не порождать всякую магию — достаточно чуть-чуть знать стандарт, с объектами и свойствами которого ты работаешь. И тогда не будет живых/мертвых/дохлых коллекций, а будет четкое представление, что это.
Ну самое забавное — видеть эту дичь в блоге HTML-academy.
А не «коллекция, привязанная к дереву узлов».
children никуда не привязана — она и есть часть дерева.
Какие живые / неживые?
В случае с обращением к DOM вы берете ссылку на коллекцию, естественно внутри нее все меняется в зависимости от состояния самой коллекции.
А querySelectorAll возвращает каждый раз новую коллекцию с DOM элементами внутри. Это другое состояние. Грубо говоря это список того, что вы запросили, и он, естественно, никак не связан с DOM, хотя его элементы — связаны.
Вот так из-за незнания и появляется магия...
Которая затем несется в массы.
«В следующей статье, я как тех.лид, расскажу о стэке технологий, применяемой у нас, и о проектах в рамках нашей сферы деятельности и вы измените свое мнение о нас»
… но нет.
Как вы там в статье-то написали: "НЕТЪ", спасибо.
А вы меньше воды лейте — у вас вся статья — одна вода. Ни тех подробностей, ни стэка — НИЧЕГО.
Вот:
И самое сладкое:
Еще надо? — я тогда всю вашу статью на цитаты растащу.
Вы считаете, что телефонный спам это «конкуренция за клиента»? Или может быть тащится по каждому чиху не надо? Не смешите. Вы используете другие технологии для этого и не абузите чужое время? Так и напишите тогда про это.
Вы хотели привлечь технарей к вам маркетинговой статьей, серьезно?
Еще раз — начинать надо было с того, о чем я выше писал — со стэка, с технологий, с того, ради чего было-бы интересно к вам пойти.
А так вся ваша статья может быть заменена одной фразой:
«Мы стали другими, у нас тут горы работы всякой (мелким текстом: оставшейся со времен когда мы были прежними), приходите разгребать наши авгиевы конюшни!» — и конечно, это прямо привлекательно и продающе! — и народ ломанулся вам в HR-отдел звонить…
Именно поэтому у них давно нет никаких «мы преодолеем», там абсолютно другой подход.
Хотите показать, что Вы — другие? Тогда вместо маркетинговой чуши опишите реальные задачи, которыми занимались, что делали, как изменили, какие технологии — это да, интересно, это может повлиять на кредит доверия.
А пока что, судя по тексту, полностью состоящему из сладкой мути и полному отсутствию конкретики, все точно такое же как и во всей вашей сфере — только сладкие да красные словца и надувание щек, а на деле — пузыри с метаном.
В здравом уме люди пойдут работать к вам в банк только если будут ну ооочень хорошие плюшки.
Потому что большинство банков — это заросшее болото легаси с плавающими кусками всего, что только было (и микросервисов, и порталов и других веб-кусков и сервисов), иногда уже полуразложившихся, потонуть которым мешает материал, из которого они сделаны.
И попав в такое болото один раз, скиллы, в нем полученные, пригодятся только в этом самом или подобном болоте.
Вы размер сегментов и их количество тоже учитывайте. ЕИнк при статике не жрёт вообще ничего — а это его обычное состояние на ценнике. Кроме того, ЕИнк матричный, а матричный ЖК будет жрать очень много в сравнении.
Я не встречал, а знаю разных — от ИРБИСа до КРОКа.
Да, сотрудники там действительно грамотные.
Но в большинстве случаев оно работает абсолютно не так, как Вы описываете.
А так (приводу пример ЛИЧНО подслушанного разговора):
Сотрудник: Я обсудил проблему заказчика с коллегами, мы пришли к мысли, что очень хорошо им подойдет технология X...
Проджект: Сколько мы сможем срубить, продав им это решение?
Сотрудник: Она бесплатна, Apache Foundation...
Проджект: Ненене, мы это все поддерживать не хотим и не будем, есть коммерческие имплементации?
Сотрудник: Да, но они тяжелые и очень дорогие и предназначены для куда более тяжелых и общных задач...
Проджект: ОООТЛИЧНО!
Вобщем, интегратор практически всегда (речь идет о российских интеграторах, на западе все куда интересней — там есть страховка от факапа и интегратор обязан взять ее из банка и предоставить — таково их юр. право) пытается не нести ответственность за свои решения и внедерения и всеми способами увиливать от гарантийного обслуживания, если оно не несет мат. выгоду.
Естественно, это не означает, что нет неадекватных клиентов — их тоже хватает. Но вот адекватных интеграторов я у нас не встречал.
Я встречал их более-менее адекватные интеграции, но их было гораздо меньше, чем тех, которые делались по тому принципу, что я выше описал. Иногда было и просто неверное решение — возможно связанное с очень узкой спецификой задачи и отсутствия нужной компетенции у сотрудников интегратора в принципе.
Встречал я и достаточно кабальные договора для интеграторов со стороны клиента, которые вынуждали последних нести гарантийные и пост-гарантийные обязательства надлежащим образом, но было это не в айти, а на производстве — но там несколько проще с оговором факапа и его проверкой. А интегратор брался за них, так как по цене они были очень заманчивые, правда потом они хватались за голову, потому как «наговнокодить» там куда сложнее, за последствия можно схлопотать срок, а стоимости отдельных узлов сильно отличаются от пузырей в айти и их «не прожать».
По-сути, наш интегратор в большинстве случаев — это перекуп со своим отделом консалтинга и пресейла, все. У КРОКа и по-моему у еще одного большого интегратора из Мск (забыл название) есть еще лаборатория — для нестандартных решений, но решения оттуда всегда получается совсем не адекватными по цене. Но зато это «свои» решения — это куда лучше, чем просто перекупить, ИМХО.
Опыт очень многих людей и в том числе и меня, утверждает следующее — если можно обойтись без интегратора — лучше без него обойтись.
Возможно это будет дольше, но продукт будет лучше, четче подходить под задачу и куда более предсказуем. При этом сторонние вендоры, чьими решениями вы захотите воспользоваться, будут вам в этом очень сильно помогать, так как заинтересованы в распространении и поддержке своих продуктов. А если привлечь двух или более конкурирующих — вы еще и решение получите по лучшему соотношению цена/качество, ну или по крайней мере будете понимать, что упустили, в отличии от интеграционного «черного ящика».
Но все ИМХО, конечно.
Впаривание происходит на высших кругах менеджмента/директорства с вливанием меда в уши по цене, о которой там договорятся и рыноком там даже и не пахнет.
Причем, зачастую, решение интегратора оказывается далеко не лучшим на рынке.
Разгребать конюшни потом приходится локальному IT-отделу, потому что у интегратора — лапки, и вообще — акты уже подписаны.
А когда узнаешь, сколько интегратор выставил за перекупленное не свое решение, тихо охреневаешь и думаешь — хочу работать у интегратора :D
По факту вообще оказывается, что все сделали другие ребята, а интегратор — это просто прокладка, которая и ответственности не несет, да и не делала ничего — просто нашла на рынке и перепродала.
А те, кто обожглись на таком раз, начинают не доверять вообще айти в целом, хотя IT-то и не виновато вовсе.
Я потому и пытался узнать здесь стоимость решения у КРОКа — но видимо это настолько секретные (или фантастические) данные, что они даже написать ничего не могут.
Но можно уточнить у корейцев, чьими ценниками они пользовались — я уже им написал.
Вангуется мне, что раз они не отвечают на этот вопрос — впарили они свое решение ритейлу в тридорога, как обычно интеграторы и делают. При этом кроме инфраструктуры и одной обработки для 1С (возможно даже не их, а какого-нибудь 1С аутсорсера), они больше ничего и не делали, а подается это с таким пафосом, как-будто они орбитальный комплекс сами лично построили и запустили.
Я так понимаю, за вами была инфраструктура и методы выгрузки из RETAIL-систем учета (1C/SAP).
Ну, один вопрос все еще актуален — так сколько все-таки получилась стоимость решения?
Чтобы прикинуть окупаемость не нужна большая точность.
Стоимость ценника и его расстановки — это прикинет сам продавец.
Вопрос тут точно такой-же как и мой ниже — какова стоимость вашего решения?