С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом.

Вся книга будет доступна на GitHub: CLR Book. Так что Issues и Pull Requests приветствуются :)

Это — выжимка из главы про структуру типов и их VMT.

Структура объектов в памяти

До сих, говоря про разницу между значимыми и ссылочными типами, мы затрагивали эту тему с высоты конечного разработчика. Т.е. мы не смотрели на то как они в реальности устроены на уровне CLR, как сделаны те или иные механики внутри каждого из них. Мы смотрели фактически на конечный результат. Однако, чтобы понимать суть вещей глубже и чтобы отбросить в сторону последние оставшиеся мысли о какой-либо магии, происходящей внутри CLR стоит заглянуть в самые ее потроха.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

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

Но все начинали с малого, и мы считаем, что любой заинтересованный человек способен создать приложение в финансовой сфере. Попробуем разработать собственное небольшое приложение, которое станет полезным для пользователей уже через полчаса.

Все мы ходили по собеседованиям, разговаривали с представителями компаний и постоянно встречаемся с особенностями, которые рекрутеры либо культивируют, обучая друг друга, либо не обращают внимания, но при этом выглядят отталкивающими — со стороны человека, пришедшего в компанию. В моей 10-летней карьере я сменил порядка 10 компаний (в последней — Luxoft — уже 3 года, так что практику перебежчика закончил). И за это время провел как около 100 собеседований на стороне соискателя, так и порядка 150 — на стороне собеседующего, что дало мне возможность собрать Топ5 ошибок рекрутеров, которые могут так испортить собеседование, что я больше не захочу идти в компанию.

В этой статье мы рассмотрим распространённые виды утечек памяти в клиентском JavaScript. Также мы узнаем, как их обнаружить с помощью Chrome Development Tools.

В этой статье я решил собрать более чем 20 AngularJS инструментов, которые ежедневно облегчают мой процесс разработки на AngularJS вот уже на протяжении нескольких лет. Когда я перешел с чистого JavaScript на AngularJS, я хотел быть в курсе всех новинок AngularJS и для этого я сделал исследование. Для меня было очень важно быть на правильном пути. По моему опыту когда ты знаешь и пользуешься всеми новинками то освоение этого JS фреймворка идёт быстрее. После всего этого исследования на протяжении двух лет я успел попробовать следующие инструменты. Здесь вы найдете инструменты для тестирования, front-end разработки, IDE, текстовые редакторы, библиотеки, модули, расширения, генераторы кода, Grid-инструменты и другое.

Перейдем к списку.

В начале я бы хотел ознакомить вас с тремя, на мой взгляд, лучшими AngularJS инструментами для тестирования:

1. Karma



Karma один из моих любимых AngularJS инструментов для тестирования. Он обеспечивает идеальную среду для тестирования, что позволяет протестировать приложение в реальных браузерах и реальных устройствах, таких как телефоны и планшеты.

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

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

Недавно я озадачился поиском б.у. автомобиля, взамен только что проданного, и, как это обычно бывает, на эту роль претендовали несколько конкурентов.

Как известно, для покупки авто на территории РФ существует несколько крупных авторитетных сайтов (auto.ru, drom.ru, avito.ru), поиску на которых я и отдал предпочтение. Моим требованиям отвечали сотни, а для некоторых моделей и тысячи, автомобилей, с перечисленных выше сайтов. Помимо того, что искать на нескольких ресурсах неудобно, так еще, прежде чем ехать смотреть авто “вживую”, я хотел бы отобрать выгодные (цена которых относительно рынка занижена) предложения по априорной информации которую предоставляет каждый из ресурсов. Я, конечно, очень хотел решить несколько переопределенных систем алгебраических уравнений (возможно и нелинейных) высокой размерности вручную, но пересилил себя, и решил этот процесс автоматизировать.

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

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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Привет, Хабрахабр! Мы долго думали, чем порадовать крупнейшее Dev-комьюнити рунета, и решили, что русскоязычные подкасты про Android-разработку от лучших разработчиков в индустрии — самое то. Собрать спикеров, подготовить темы и найти площадку для размещения было непросто, но мы справились. Встречайте!

Привет, это снова Без слайдов. Я Алексей Федоров, и на этот раз в гостях у меня побывал Сергей Шкредов, руководитель всего .NET-направления в компании JetBrains.



С Сергеем мы говорили:

• о последних релизах ReSharer;
• о новой схеме подписок и лицензий;
• про непростые отношения с Microsoft;
• о рантайме и развитии языка;
• о том, как поменял ситуацию выход Roslyn;
• о работе с фидбеком пользователей для улучшения продукта;
• о планах развития других продуктов .NET стека;
• о важности внутриотраслевого общения и обмена опытом;
• про разработку продуктов для С++;
• немного о ReSharper C++, на который должны подсесть даже разработчики Microsoft;
• О том, как пользователи почувствуют изменения;
• Как ReSharper будет развиваться дальше.

Вот видео



Под катом — текстовый вариант интервью.

Это шестая статья из цикла «Теория категорий для программистов». Предыдущие статьи уже публиковались на Хабре:
0. Теория категорий для программистов: предисловие
1. Категория: суть композиции
2. Типы и функции
3. Категории, большие и малые
4. Категории Клейсли
5. Произведения и копроизведения

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

Рассмотрим подробнее место произведения и копроизведения типов в программировании.

Произведение типов

Каноническая реализация произведения типов в языках программирования — это пара. В Haskell пара является примитивным конструктором типов, а в C++ это относительно сложный шаблон из стандартной библиотеки.

Строго говоря, произведение типов не коммутативно: нельзя подставить пару типа (Int, Bool) вместо (Bool, Int), хотя они и содержат одни и те же данные. Однако произведение коммутативно с точностью до изоморфизма, задаваемого функцией swap, которая обратна самой себе:

swap :: (a, b) -> (b, a)
swap (x, y) = (y, x)

Можно рассматривать такие пары как различные форматы хранения одной и той же информации, как big endian и little endian.

Если вы хотите научиться программировать первоклассные игры, вам просто необходимо изучить язык С++. Эта книга поможет вам освоить разработку игр с самых азов, независимо от того, есть ли у вас опыт программирования. Гораздо интересней учиться, когда обучение превращается в игру. Каждая глава книги описывает самостоятельный игровой проект. В заключительной главе вам предстоит написать сложную игру, которая объединяет все приемы программирования, рас-смотренные в предыдущих главах. Книга идеально подойдет для начинающего программиста, планирующего не только как следует освоить непростой язык С++, но и поупражняться в программировании игр. Цель данной книги — познакомить вас с языком С++ в контексте программирования игр. Хотя невозможно представить себе такую книгу, которая сделала бы вас мастером в двух столь объемных темах, как программирование игр и язык C++, это издание пригодится вам в качестве вводного курса.

Хотелось бы добавить по поводу высоконагруженных систем на java относительно этой статьи. В комментариях писать слишком много, поэтому напишу отдельно. Подход не совсем программиста, но может кому пригодится. Это только мое мнение, возможно, оно где-то неверно.

Платформа JEE

Конечно на стандартной java ваше приложение будет работать быстрее, потреблять меньше памяти, и вы можете сделать архитектуру именно такой, как вам нужно. Но это при том условии, что у вас неограниченное количество человеко-часов, и вы каждый день пишете такую ерунду как приложение на 100к клиентов. В противном случае для этого потребуется очень много времени и итераций, и в итоге все равно получиться чуточку хуже, чем то, как это реализовано в современных JEE серверах. Все промахи всплывут только под реальной нагрузкой, и архитектуру приложения придется переделывать не один раз.

Наша команда занимается разработкой продукта для поиска удаленных разработчиков. По смыслу это не аналог upWork (ex-oDesk), а скорее, Uber: сервис за минимальное время находит на проект программиста, подходящего по локации, языку, компетенциям и стоимости.



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

Обладая большим опытом «селекции» разработчиков, мы систематизировали свои знания и столкнулись с задачей идеального профиля программиста, по-настоящему удобного не только нам, но и широкой аудитории.

Итак…

В преддверии Java-конференции Joker 2015, которая начнется уже завтра, я публикую большое интервью с Алексеем Шипилёвым, инженером команды Java Performance Team из Oracle, одним из самых крутых и известных во всем мире специалистов по производительности. Ну и конечно, прекрасным спикером.

С Алексеем мы подробно поговорили:

• про грядущие изменения в классе String;
• про то, кто же на самом деле разрабатывает OpenSource;
• про системных разработчиков и их карьеру;
• про обмен технологиями, «научную» и «продуктовую» разработку;
• про сложность низкоуровневых задач;
• про развитие Java-сообщества и бенчмарк-войны;
• про mutable vs immutable;
• про Unsafe;
• про JMH, бенчмарки и узкую специализацию.

Вот видео нашего разговора. Больше часа длиной, можно слушать в дороге.



Ниже под катом — расшифровка нашей беседы для тех, кто видео не очень.

Уже несколько месяцев использую docker для структуризации процесса разработки/доставки веб-проектов. Предлагаю читателям «Хабрахабра» перевод вводной статьи о docker — «Understanding docker».

Что такое докер?

Докер — это открытая платформа для разработки, доставки и эксплуатации приложений. Docker разработан для более быстрого выкладывания ваших приложений. С помощью docker вы можете отделить ваше приложение от вашей инфраструктуры и обращаться с инфраструктурой как управляемым приложением. Docker помогает выкладывать ваш код быстрее, быстрее тестировать, быстрее выкладывать приложения и уменьшить время между написанием кода и запуска кода. Docker делает это с помощью легковесной платформы контейнерной виртуализации, используя процессы и утилиты, которые помогают управлять и выкладывать ваши приложения.

Один технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой

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

В этой статье я бы хотел прояснить различия между DTO (Data Transfer Object), Value Object и POCO (Plain Old CLR Object), также известным как POJO в среде Java.