Рубрика «опрос» - 9

Здравствуйте, уважаемые читатели “Хабра". В конце 2014 года мы устроили опрос для фрилансеров, чтобы определить средние часовые ставки. В опросе приняли участие 23000 человек из разных стран мира.
Читать полностью »

Будучи IT компанией, мы не можем не замечать изменения глобального IT рынка, в целом, и рынка автоматизации, в частности. Предыдущий опрос, проведенный нами, показал, что профессиональные интеграторы систем «Умный дом» или уже используют устройства из «Интернета вещей», или планируют это делать. Поэтому мы обратились к нашим постоянным клиентам – профессиональным инсталляторам с вопросами на тему: «Как рост IoT повлияет на рынок профессиональных инсталляций «Умный дом?» Кроме этого, нам стало интересно, является ли это общемировой тенденцией или есть какие-то географические границы? Поэтому мы проводили опрос на английском и русском языках. Вот, что у нас получилось.

image
Читать полностью »

В начале февраля мы провели опрос по автоматизированному тестированию для выявления изменений, произошедших за последние 5 лет в этой области. В качестве сравнительной базы использовались результаты нашего исследования «Инструменты автоматизации тестирования», проведенного в 2011г. Читать полностью »

Здравствуйте, уважаемыее!

Нашему издательству вновь требуется помощь зала по вопросу издания амбициозной книги.

Эта непростая книга называется «Создание микросервисов», автор — Сэм Ньюмен.

Создание микросервисов - 1

Предварительное изучение темы (а также выложенных отрывков книги) позволяет предположить, что перед нами – очередная инкарнация философии Unix, которая теоретически избавлена от недостатков и громоздкости SOA, ориентирована, в первую очередь, на работу с распределенными системами.

Вашему вниманию предлагается перевод аннотации этой книги:

«За последние 10 лет распределенные системы стали гораздо более филигранными, эволюционировав от тяжеловесных монолитных приложений до небольших самодостаточных микросервисов. Однако разработка таких систем связана с целым комплексом специфических проблем. Эта книга, содержащая множество примеров и практических рекомендаций, дает целостный обзор различных тем, которые заинтересуют системных архитекторов и администраторов, задумывающихся о построении, поддержке и развитии микросервисных архитектур.

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

• Изучите, чем микросервисы могут быть полезны при разработке систем и достижении целей вашей организации
• Познакомьтесь с вариантами интеграции нового сервиса в существующую систему
• Последовательно разберите, как следует разбивать на блоки монолитные базы кода
• Развертывайте отдельные микросервисы методом непрерывной интеграции
• Изучите сложности тестирования и отслеживания распределенных сервисов
• Обеспечивайте безопасную работу между пользователями и сервисами, а также между сервисами, взаимодействующими друг с другом
• Изучите проблемы, связанные с масштабированием микросервисных архитектур

Здесь располагается интересная статья, анализирующая суть концепции микросервисов и помогающая представить, с чем ее едят.

Потенциальный недостаток книги — узость целевой аудитории, которая, к тому же, массово читает по-английски. Также смущают претензии микросервисов на роль очередной серебряной пули, которая на деле вполне может оказаться алюминиевой. Приглашаем обсудить эти вопросы и аннотацию книги в комментариях, а также поучаствовать в уже традиционном опросе:
Читать полностью »

Всем привет,

пару месяцев назад я немного опросил людей из IT по поводу изменений курса валют и заработной платы. Прошло пару месяцев, открылись новые вакансии, а потому интересно узнать: а что поменялось на рынке труда в IT?
Читать полностью »

Началось голосование за новые функции браузера Vivaldi - 1Всем привет!

Несколько дней назад мы собрали из блогов и форумов пожелания пользователей по добавлению новых функций в браузер Vivaldi или по улучшению уже существующих. Список оказался огромным — более 90 функций и улучшений. Мы убрали из него то, что уже реализовано или находится в процессе реализации, а также пока удалили из списка функции, реализация которых в ближайшее время невозможна по различным причинам. Финальный список насчитывает 48 пунктов, именно они и представлены на странице голосования.

Правила голосования просты: вы можете отметить три самых важных на ваш взгляд функции, которых очень не хватает браузеру Vivaldi. Таким образом разработчики смогут добавить их в свои планы в зависимости от приоритетности. Также помните, что данное голосование первое, но далеко не последнее — в дальнейшем оставшиеся в списке функции будут добавляться в новые опросы, которые планируется проводить после каждого важного релиза браузера Vivaldi.

Спасибо за вашу поддержку и добро пожаловать на страницу опроса!
Читать полностью »

5 недопустимых ошибок при сборе отзывов о продукте - 1

В начале работы над проектом или на этапе радикальных изменений в продукте трудно удержаться от искушения опросить всех своих пользователей, чтобы определиться с положением дел. Обычно это ошибка. Вообще-то есть целый ряд общих ошибок, которые происходят снова и снова. Мы в Alconost перевели для вас пять подсказок по сбору отзывов о продукте.
Читать полностью »

Здравствуйте!

В этой статье речь пойдет о книгах, а точнее о профессиональной литературе.

Я много читаю с самого детства. Закончив институт и начав строить карьеру, я понял, что непрерывное развитие — залог успеха. И книги — самый доступный инструмент развития.

С этого момента моя домашняя библиотека стала пополняться профессиональной литературой. Однако, тут я столкнулся с некоторыми проблемами.

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

image

Читать полностью »

Предлагаю не совсем стандартный опрос по платформе .Net. Спойлерами раскрыты ответы на вопросы, но все-таки прошу сначала самим ответить на опросник, после чего идти и смотреть ответы :)

Когда вызывается статический метод, то JIT...

JIT компилирует вызов прокси-метода, который делает безусловный переход на компилятор необходимого и тот заменяет адрес перехода в прокси на новое тело метода. Это делается по нескольким причинам.

Изначально, когда методы компилируются, все точки вызова других методов указывают не на скомпилированное тело, а на кусочек ассемблерного кода фиксированной длинны и содержащий одни и те же инструкции для любого метода. По сути меняется только адрес, на который происходит jmp. До того как метод скомпилирован, адрес указывает на компилятор этого метода (потому при первом вызове происходит компиляция). Далее, когда компиляция закончена, аргумент команды jmp меняется с адреса компилятора на адрес целевого, уже скомпилированного метода. Плюсы очевидны: т.к. прокси — содержит одно и те же инструкции, то группу методов можно рассматривать как таблицу с двумя полями: Код и Адрес Перехода с одной стороны и не менять адреса у инструкции вызова метода — с другой.

Что происходит при кастинге к классу

Приведение типа к базовому — не происходит ничего, приведение к отнаследованному — для начала проверяется возможность приведения и работа с объектом будет идти по той же таблице виртуальных методов, что и раньше

Приведение к типу — синтаксический сахар языка, который не имеет почти ничего общего на уровне строения объекта в памяти. Поскольку объект состоит из полей + SyncBlockIndex + MethodsTablePtr, где MethodsTablePtr отвечает за указатель на описание типа объекта, то при помещении указателя на объект в переменную другого типа с объектом не происходит ничего (тип объекта же не меняется). Вызывается доп проверка при приведении вверх, т.к. на этапе компиляции заранее не известно, что вверху, какие типы. Необходимо проверить. Проверка осуществляется через уход в таблицу методов и проход по цепочке указателей ParentClassMethodsTable, пока не встретится либо Object (тогда кастинг не возможен) либо пока не встретим указатель, равный тому, который мы ищем. Как осуществляется вызов виртуального метода, хорошо описано тут: Wiki

Что происходит при приведении типа к интерфейсу

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

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

В чем разница между Implicit и Explicit интерфейсами?

И те и другие выделены в словарь интерфейсов, однако Explicit методы не находятся в таблице виртуальных методов класса, только в словаре интерфейсов

И действительно, поскольку методы implicit интерфейсов являются частью иерархии наследования класса и могут быть вызваны отдельно от приведения к типу интерфейса, они должны присутствовать в таблице виртуальных методов класса. Однако, есть еще и Explicit реализации, когда методы отделены от класса. Такие методы не присутствуют в таблице виртуальных методов класса. Однако для обоих случаев мы имеем право кастить к интерфейсу и работать через него. А это значит что в карте интерфейсов обоих типов они присутствовать будут, причем вместе со всеми базовыми типами — интерфейсами.

Потоки в .Net

являются платформенными потоками MS Windows, потому цена переключения между потоками равна общей цене по Windows

Тут, в общем, без комментариев. GC не может встревать в общий процесс обслуживания многопоточного кода. Приложения .Net работают как обычные приложения Windows

Generic типы

JIT создает никак не связанные между собой классы под каждый параметр типа

Поскольку JIT не может ничего знать о логике приложения, он не может строить доводов что

 IEnumerable<object> a = new List<int>() 

должно как-то работать. потому имплементация под каждый конкретный набор generic аргументов компилируется в отдельный код.

Как происходит вызов экземплярных методов - this

this — первый параметр метода, который для целей синтаксического сахара не показывается

Если представить себе вызов метода, то на уровне процессора он будет происходить по нотации fastcall: первые два параметра метода уйдут в регистры, а остальные — в стек. если ничего дополнительно не передавать, то получится что внутри метода мы понятия не будем иметь, для какого объекта нас вызвали. чтобы исправить ситуацию, мы первым параметром всегда передаем this, а в языке программирования (например, C#) его просто не показываем, введя локальную переменную this, которая присутствует всегда, вне зависимости от желания программиста. Это и есть на самом деле первый параметр метода.

Value и Reference типы. В чем разница?

Value типы лежат и в стеке и в куче, а Reference — только в куче. Отличаются тем, что value — передаются по значению, а Reference — по ссылке

Огромный процент разработчиков на собеседованиях говорят первый вариант ответа. Причем на самом деле он их не устраивает, поскольку если Value тип является полем класса, в рабочем стеке его значение находиться ну никак не может, поскольку при выходе из метода, который его создал фрейм, его содержащий перестал бы быть валидным с правильными данными. Поле класса (даже если это Value тип) всегда находится в куче. Разница между Value и Ref типами в том, что при копировании у Ref типов копируется ссылка, а у Value — полностью вся структура. Второе отличие: у незабокшенных Value типов отсутствует поле MethodsTable и SyncBlockIndex.

Где лежат статические переменные?

Лежат во внутренних массивах и обращение идет по ссылке на массив + индексу

Это просто сакральное знание. Просто сделано так и все.

Как вызываются виртуальные методы?

JIT создает для типа таблицу виртуальных методов, через которую идет вызов с заранее подсчитанным индексом
При наследовании и наличии виртуальных методов получается так: от класса к классу они могут только прибавляться в наличии, не пропадая в никуда. причем в каждом последующем классе гарантированно будут присутствовать все методы всех базовых. С одним отличием — при наследовании метод можно переопределить. Потому при построении таблицы методов для какого-то класса, методы базового класса должны находиться по тем же индексам, что и в таблице базового класса. Если метод не переопределен, то и адрес тела метода в таблице будет совпадать с адресом этого метода в таблице базового класса. Если метод переопределен, то значение будет другим. После всех методов базовых классов будут находиться методы ткущего класса. А сам вызов будет происходить так:

  • Загрузить адрес таблицы вирт методов.
  • Сместиться до начала списка методов
  • взять адрес метода по индексу (например) 1
  • Вызвать его.

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

Читать полностью »

Всем привет,

Недавно мне попалась на глаза статья о том, что в IT компаниях готовятся к небольшим кадровым проблемам из-за того, что заработная плата в РФ немного упала в долларовом эквиваленте. Несмотря на это, доход компаний, работающих на экспорт, не сильно менялся (опять-таки, если смотреть в долларах), а таких около 80% компаний. То есть, цена на одного разработчика в РФ стала меньше раза в два, чем была где-то год назад. Логично, что в этом случае вероятен рост спроса на разработку в РФ (а также в соседних странах), что может повлиять на кадровый рынок IT.
Очень похожая ситуация с валютой случилась год назад на Украине, где в итоге заработная плата в IT сфере выросла, по сравнению со среднерыночной по стране. Опять-таки, логично предположить, что заработная плата в IT отрасли в РФ сделает похожий финт (то есть вырастет на величину, пропорциональную роста доллара по отношению к рублю).

Следовательно, у меня вопрос к читателям: а как обстоят дела в Ваших компаниях? Собираются ли они индексировать зарплаты? Увеличилась ли текучка кадров? Стали ли набирать они новых сотрудников?

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js