Вашему вниманию предлагается небольшой обзор возможностей векторизации алгоритмов в .NET Framework и .NETCORE. Цель статьи познакомить с этими приёмами тех, кто их вообще не знал и показать, что .NET не сильно отстаёт от "настоящих, компилируемых" языков для нативной
разработки.
Разработчик
Системный архитектор: первый после Бога
"Правильно мыслить более ценно, чем многое знать"
Джон Локк
Системный архитектор – интересная и крайне важная профессия в современном мире, имеющая отношение отнюдь не только к миру ИТ. Как сегодня, так и в обозримом будущем системные архитекторы будут наиболее востребованным и весьма дефицитным ресурсом в любой быстро развивающейся отрасли. И обязательно в сфере системной интеграции. Причем по степени и качеству использования системных архитекторов можно судить по зрелости управления в организации. И по соответствующей оценке их труда тоже. Во многом именно поэтому в получении информации о профессии системного архитектора заинтересована значительная часть молодых специалистов, у которых все еще впереди. А что именно?
Если вы считаете, что Создатель не был первым системным архитектором, то можете не читать дальше эту статью.
Кроссплатформенная новогодняя демка на .NET Core и Avalonia
"ААА! Пришло время переписывать на .NET Coreǃ", говорили они, WPF в комментариях обсуждали. Так давайте же проверим, можно ли написать кросс-платформенное GUI приложение на .NET / C#.
Новогоднее настроение навеяло идею сделать анимацию падающего снега. Были такие демки под DOS, горящий огонь, фракталы, снежок, падающий на ёлочку, и так далее.
Как увидим ниже, это не только весело, но и позволит испытать ключевой функционал UI фреймворка. Поехали!
Мир, в котором IPv6 придуман хорошо
BaumankaCoin – велосипед в 3000 строк или блокчейн на пальцах
Про Blockchain сегодня не пишет только ленивый. Существует огромное количество статей разной степени понятности и полезности. Это очередная из них. Нам захотелось создать максимально простой, но работающий блокчейн и написать кратко, но понятно для неспециалистов, как же эта собака этот блокчейн работает. Так родился проект BaumankaCoin, исходники которого можно загрузить c GitHub-а.
Многие люди представляют себе технологию блокчейн и криптовалют как некий мега rocket science. Безусловно, чтобы понять все тонкости и нюансы – потребуется потратить много времени; но в действительности данная технология, если разобраться, оказывается гораздо более простой для понимания, чем принято считать. Реализовав свой coin мы намеревались помочь людям понять "на пальцах" устройство данных технологий.
Введение в архитектуры нейронных сетей
Григорий Сапунов (Intento)
Меня зовут Григорий Сапунов, я СТО компании Intento. Занимаюсь я нейросетями довольно давно и machine learning’ом, в частности, занимался построением нейросетевых распознавателей дорожных знаков и номеров. Участвую в проекте по нейросетевой стилизации изображений, помогаю многим компаниям.
Давайте перейдем сразу к делу. Моя цель — дать вам базовую терминологию и понимание, что к чему в этой области, из каких кирпичиков собираются нейросети, и как это использовать.
План доклада такой. Сначала небольшое введение про то, что такое нейрон, нейросеть, глубокая нейросеть, чтобы мы с вами общались на одном языке.
Дальше я расскажу про важные тренды, что происходит в этой области. Затем мы углубимся в архитектуру нейросетей, рассмотрим 3 основных их класса. Это будет самая содержательная часть.
После этого рассмотрим 2 сравнительно продвинутых темы и закончим небольшим обзором фреймворков и библиотек для работы с нейросетями.
Моноиды, полугруппы и все-все-все
Если ты на практике используешь ООП, то хорошо разбираешься в таких вещах, как «паттерны проектирования». А знаешь ли ты, что есть множество полезных паттернов, которые не укладываются в этот стандартный список? К сожалению, многие из них связаны с «функциональным программированием», которое, согласно легенде, сложное и заумное. Если десять раз сказать слово «моноид», можно вызвать Дьявола.
Mark Seeman расскажет о функциональном программировании просто и быстро. Для этого он начал писать цикл статей, посвященных связи между паттернами проектирования и теорией категорий. Любой ООПшник, у которого есть 15 минут свободного времени, сможет заполучить в свои руки принципиально новый набор идей и инсайтов, касающихся не только функциональщины, но и правильного объектно-ориентированного дизайна. Решающим фактором является то, что все примеры — это реальный код на C#, F# и Haskell. Этот хабрапост — перевод самого начала цикла, первых трех статей, слитых воедино для удобства понимания.
Кроме того, с Марком можно пообщаться вживую, посетив конференцию DotNext 2017 Moscow, которая состоится 12-13 ноября 2017 г. в Москве, в «Славянская Рэдиссон». Марк прочитает доклад на тему «From dependency injection to dependency rejection». Билеты можно взять здесь.
Дата-майнинг 10 000 актёров порно
Вокруг adult киноиндустрии существует много мифов и заблуждений. Например, многие склонны думать, что типичная актриса — блондинка с пышными формами. На самом деле это далеко не так. Джон Миллворд (Jon Millward) осуществил дата-майнинг кинематографической базы Internet Adult Film Database и проанализировал информацию о 125 тыс. фильмах, которые содержат информацию более чем о 115 тыс. актёрах. Для статистического анализа были сделана выборка 10 000 человек.
Архитектурная пирамида приложения
Разбираясь со всем этим по отдельности, меня заинтересовал вопрос — как они взаимосвязаны? Пытаясь выстроить иерархию и вдохновившись небезызвестной пирамидой Маслоу, я построил свою пирамиду «архитектуры приложения».
О том, что из этого вышло — читайте под катом.
Практика формирования требований в ИТ проектах от А до Я. Часть 6. Поведение системы. Совершенстваоние требований
Часть 2. Цели и Потребности
Часть 3. Функции системы и Границы проекта
Часть 4. Бизнес процессы, автоматизируемые системой
Часть 5. Сущности предметной области и немного о стратегиях
Часть 6. Поведение системы. Совершенстваоние требований
Часть 7. Передача требований в производство. Заключение
IX Определение поведения системы.
В очень многих случаях поведение … только потому кажется смешным, что причины его, вполне разумные и основательные, скрыты от окружающих.
Франсуа де Ларошфуко
После того как мы определились с перечнем основных сценариев и сущностей предметной области, необходимо сопоставить их друг с другом.
Цель данной группы работ: на основании выявленных сущностей и процессов, разрабатываемого целевого продукта спроектировать поведение системы, распределив ее по классам.
Создание архитектуры программы или как проектировать табуретку
К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».
Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.
Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.
M в MVC: почему модели непоняты и недооценены (перевод)
Многие из вас наверняка заметили, что я пишу книгу о Zend Framework. Недавно я закончил черновики двух глав: «Архитектура приложений на Zend Framework» и «Понимая Zend Framework». В первой главе объясняется архитектурный шаблон Model-View-Controller (MVC) и причины, по которым он стал стандартом де-факто для веб-приложений. Во второй исследуется связь MVC с компонентами Zend Framework, их структурой и взаимодействием.
Завершив обе главы я осознал, что большую часть времени описывал модель и ее фактическое отсутствие в Zend Framework. На самом деле ни один веб-фреймворк не предлагает нам полноценную модель (по причинам, которые я объясню чуть позже). И ни в одном из них не дается внятного объяснения этому обстоятельству. Вместо этого они последовательно связывают понятие модели с родственным, но не идентичным понятием доступа к данным, что изрядно всех запутывает.
Эта сторона фреймворков никогда не привлекала особого внимания. И все же именно она лежит в основе целого класса проблем в тех приложениях, которые пытаются использовать MVC по образу и подобию фреймворков для веб-приложений. Более того, попытки донести идею модели до других разработчиков нередко напоминают битье головой о стену. Я не хочу сказать, что все разработчики тупые или не понимают саму идею, просто никто из них (вне зависимости от того, работают они с PHP или нет) не связывает модели с той областью, которая наделяет их смыслом — принципами объектно-ориентированного программирования.
Охота на мифический MVC. Построение пользовательского интерфейса
Детектив по материалам IT. Часть вторая
В этой части я покажу как изначально выглядело деление пользовательского интерфейса и что из себя представляли Вид и Контроллер. Попробую рассказать почему в современных GUI библиотеках используется их объединение и какие вообще интересные решения можно найти в этой области на сегодняшний день. Ссылки на первоисточники приведены в начале первой части.
Начну с Вида. Не смотря на то, что Вид определяется как модуль, отображающий Модель – "а view is a (visual) representation of its model", на практике к Виду, как правило, просто относят все графические элементы GUI, то есть Видом считается все то, что мы видим на экране ЭВМ.
Понятно, что тут содержится некое противоречие, поскольку такие графические компоненты как меню, кнопки, тулбары служат не для отображения информации о системе, а прежде всего для управления системой. Клавиатура и мышь всегда были средством управления программой и находились в «ведомости» Контроллера (как бы его не трактовали). Поэтому кажется нелогичным и странным, что кнопки, сделанные из пластмассы, считаются элементами управления и относятся к Контроллеру, а кнопки, нарисованные на экране, и по сути выполняющие те же самые функции (производить входящие события), почему то относят к Виду.
Охота на мифический MVC. Обзор, возвращение к первоисточникам и про то, как анализировать и выводить шаблоны самому
— Не понимаю, почему люди так восхищаются этим Карузо? Косноязычен, гугнив, поёт — ничего не разберешь!
— А вы слышали, как поёт Карузо?
— Да, мне тут кое-что из его репертуара Рабинович напел по телефону.
Детектив по материалам IT. Часть первая
Я осознаю, что писать очередную статью на тему Модель-Вид-Контроллер это глупо и вредно для «кармы». Однако с этим «паттерном» у меня слишком личные отношения – проваленный проект, полгода жизни и тяжелой работы «в корзину».
Проект мы переписали, уже без MVC, просто руководствуясь принципами – код перестал быть похож на клубок спагетти и сократился наполовину (об этом позже, в обещанной статье про то, как мы применяли «принципы» в своем проекте). Но хотелось понять, что же мы сделали не так, в чем была ошибка? И в течении долгого времени изучалось все, что содержало аббревиатуру MVC. До тех пор пока не встретились исходные работы от создателя – Трюгве Реенскауга…
И тогда все встало на свои места. Оказалось что фактически на основе принципов мы пере-изобретали «original MVC». А то, что зачастую преподносится как MVC, не имеет к нему никакого отношения… впрочем также как и к хорошей архитектуре. И судя по тому сколько людей пишет о несостоятельности «классического MVC», спорит о нем и изобретает его всевозможные модификации, не одни мы столкнулись с этой проблемой.
Более 30 лет собранные в MVC идеи и решения остаются наиболее значимыми для разработки пользовательских интерфейсов. Но как ни странно, несмотря на существующую путаницу и обилие противоречивых трактовок, разработчики продолжают довольствоваться информацией «из вторых рук», черпая знания о MVC из википедии, небольших статей в интернете и фреймворков для разработки веб-приложений. Самые «продвинутые» читают Мартина Фаулера. И почему-то почти никто не обращается к первоисточникам. Вот этот пробел и хотелось бы заполнить. И заодно развеять некоторые мифы.
Как делать свои игры бесплатно? Руководство по разработке инди-игр от T3
Парсер математических выражений C# — опыт дилетанта
Компьютер и человек — как сложно нам понять друг друга. По сути, процесс программирования — это объяснение машине то, что ты от неё хочешь на понятном ей языке.
В качестве введения
По своей работе, да и в качестве хобби, я связан с процессом написания кода, связанного с математическими вычислениями. Одной из последних задач было написание ПО, в котором пользователь имел бы возможность самостоятельно вводить и использовать при расчёте, визуализации данных и оптимизации некоторых математических выражений. А учитывая свою природную лень и нежелание постоянно дополнять библиотеку кода специальных математических функций пришла в голову мысль — а почему бы не реализовать бредовую студенческую идею, и не изобрести велосипед парсера математических выражений.
Генерируем на .Net
- Reflection Emit. Доступен с версии .Net 1.0.
- CodeDom. Позволяет создавать динамический код из представления CodeDom или напрямую из исходников, написанных на одном из высокоуровневых языков, например C#, VB или JScript. Доступен с версии .Net 1.0.
- Expression trees. Доступен с версии .Net 3.5. Позволяет создавать динамический код из представления Expression.
В этой статье я хочу рассказать про технику кодогенерации с использованием Reflection Emit.
Троичный компьютер в браузере
000. Предыстория
В 1959 году Н. П. Брусенцов разработал для МГУ уникальную вычислительную машину «Сетунь». Она была основана на троичной системе счисления и хотя элементная база была частично двоичной, что приводило к перерасходу деталей, машина зарекомендовала себя как экономичная и надёжная. Сегодня троичную машину можно увидеть разве что в музее, двоичный код победил.
Но, как я говорил ранее, всегда найдутся люди, готовые сохранять технологии прошлого в виде эмуляторов.
15 советов и хитростей инструментов разработчика Chrome, которые вы обязаны знать
Задача о 64 монетах, двух заключённых и одной шахматной доске
Примечание переводчика: я заменил оригинальные обозначения сторон монеты head/tail на аверс/реверс, чтобы не вносить путаницу русскоязычными орёл/решка. На иллюстрации выше слева аверс (head), справа реверс (tail).
Спасение невозможно?
Это одна из тех типичных загадок о заключённых, в которых вы приговорены к смерти и можете спастись, только если докажете свои умственные способности тюремщику. Вы и ваш друг были заключены в тюрьму. Ваш тюремщик предлагает вам испытание. Если вы его выполните, вы оба будете освобождены.
Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Date of birth
- Registered
- Activity