Программист
Большинство статей и лекций рассказывают о DDD как о неком ремесле, доступном не многим, в котором самое важное это проектирование модели и всё вокруг этого. И проблема тут в масштабе — мы говорим чаще о безусловно важных вещах кирпичиках, но не ландшафте целиком.
Под катом я хотел бы рассказать о том, что составляет масштаб, почему Эванса нужно дочитать, почему предметно-ориентированному проектированию 100 лет в обед и кое-что от себя.
Человека далёкого от клиентской разработки на Windows все эти термины определённо путают. И даже среди MS-сообщества регулярно возникают споры жив UWP или мёртв. Причем главный вопрос в этом споре - а что же такое UWP?
Вот уже года 3 Microsoft проводит "рефакторинг" в своём "королевстве". Несколько устав видеть одни и те же споры в твиттере, и оставлять одни и те же комментарии на хабре, я решил расписать как же многочисленные UI-фреймворки MS соотносятся между собой. Кто из них больше мёртв. Возможно, кому-то это поможет в выборе технологии для будущего проекта.
Меня зовут Назим Гафаров, я разработчик интерфейсов в Mail.ru Cloud Solutions. На дворе 2020 год, а мы продолжаем обсуждать «нововведения» ES6-синтаксиса и преимущества MobX над Redux. Существует много причин использовать Redux в своем проекте, но так как я не знаю ни одной, расскажу о том, почему мы выбрали MobX.
Это продолжение текста про архитектуры интерпрайз-систем. Рассуждения это хорошо, но какой в них толк без практического применения. Я покажу свой фреймворк в деле.
Всё началось с того, что я рассказывал про проблематику проектирования приложений на .NET и ныл про нелёгкую жизнь в кровавом интерпрайзе. Затем я описал решение, которое сам придумал и реализовал — Reinforced.Tecture. То была теория, концептуальные рассуждения, визионёрство и снова нытьё. На этот раз о том, что на дворе 2020 год, а HKT в C# так и не завезли.
Сегодня я продемонстрирую свой подход в действии на примере простенького проекта и покажу профиты, которые он даёт: от сокращения количества кода до автоматизации тестирования и оригинального подхода к документации. Как советовал старина Торвальдс: "Болтовня ничего не стоит, покажите мне код".
Чуть больше года назад выкладывал свой скрипт по автоматизации настройки Windows 10. Давеча переписал Windows 10 Sophia Script в виде модуля на 10 000+ строк. Под катом — всегда самое интересное!
Всем привет! Сегодня я расскажу вам о моем опыте с ВК, найденных багах, об отношении к пользователям и, собственно, как получить аудиозаписи вк, пользуясь "не багами а фичами", как меня заверяли сотрудники данной корпорации. Итак, приступим!
«… истинное место судна хотя и неизвестно, но оно не случайно, оно есть, но неизвестно в какой точке» Алексишин В. Г. и др. Практическое судовождение, 2006. стр. 71
«С двух краев галактики вышли пешеходы...» (С) Сергей Попов (Астрофизик)В свете новых тенденций
В интернете есть много статей с описанием алгоритма градиентного спуска. Здесь будет еще одна.
8 июля 1958 года The New York Times писала: «Психолог показывает эмбрион компьютера, разработанного, чтобы читать и становиться мудрее. Разработанный ВМФ… стоивший 2 миллиона долларов компьютер "704", обучился различать левое и правое после пятидесяти попыток… По утверждению ВМФ, они используют этот принцип, чтобы построить первую мыслящую машину класса "Перцептрон", которая сможет читать и писать; разработку планируется завершить через год, с общей стоимостью $100 000… Ученые предсказывают, что позже Перцептроны смогут распознавать людей и называть их по имени, мгновенно переводить устную и письменную речь с одного языка на другой. Мистер Розенблатт сказал, что в принципе возможно построить "мозги", которые смогут воспроизводить самих себя на конвейере и которые будут осознавать свое собственное существование» (цитата и перевод из книги С. Николенко, «Глубокое обучение, погружение в мир нейронный сетей»).
Ах уж эти журналисты, умеют заинтриговать. Очень интересно разобраться, что на самом деле представляет из себя мыслящая машина класса «Перцептрон».
Я не гарантирую, что изложенные здесь трактовки общепринятых терминов и принципов совпадают с тем, что изложили в солидных научных статьях калифорнийские профессора во второй половине прошлого века. Я не гарантирую, что мои трактовки полностью разделялись или разделяются большинством IT-профессионалов в отрасли или научной среде. Я даже не гарантирую, что мои трактовки помогут вам на собеседовании, хоть и предполагаю, что будут небесполезны.
Но я гарантирую, что если отсутствие всякого понимания заменить моими трактовками и начать их применять, то код вами написанный будет проще сопровождать и изменять. Так же я прекрасно понимаю, что в комментариях мной написанное будут яростно дополнять, что позволит выправить совсем уж вопиющие упущения и нестыковки.
Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.
Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.
