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

Лекции по курсу «Управление Техническими Системами», читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки», факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность.

Данные лекции только готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика привествуется.

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

Собеседование — это экзамен

Ведущий — строгий учитель, а кандидат — студент. Классический сеттинг. Обычно проходит так. Спросили откуда ты, что ты, и потом пошло техническое собеседование.

Начинается с простых вопросов на раскачку, примерно таких:

Я пишу сайты на asp.net mvc. В этих 16 главах я хочу рассказать, как я это делаю. Это некий учебник-справочник всех тех знаний, которые я накопил в течение трех лет.

Почему именно asp.net mvc

ASP.NET MVC я люблю потому что:

• Это .net. Я знаю .net и С#.
• Это компилируемый код.
• Это не ASP.NET WebForms, я работаю с html-кодом.
• Используется MVC-паттерн.
• Visual Studio – самое популярное средство разработки, в котором есть IntelliSense.
• Отличные инструменты отладки.

Позвольте небольшое предисловие — обозначу в нём цель статьи.
Я по субботам студентам младших курсов преподаю введение в шаблоны проектирования. Вот, хочу поделиться опытом, описать план нескольких первых лекций. Большинству читателей, я полагаю, сам излагаемый мной материал давно знаком, но, возможно, порядок и способ изложения покажутся любопытными.
Слишком часто, увы, нам рассказывают что-то, но не говорят, зачем это нужно, или говорят даже, но будто вскользь. Скажем, обыкновенно, говоря о C#, расскажут, что такое базовый класс и интерфейс, каким синтаксисом нужно пользоваться, чтобы написать их, приведут пример, где базовым будет класс «Птица», а наследниками «Утка» и «Орёл», но зачем всё это нужно, какая от всей — потенциально сложной — иерархии классов достигается польза, не говорят: это будто бы в тени, подразумевается само собою. И вот потому у многих учеников, ещё не успевших набить свои шишки, в голове перевёрнутая картина мира — они неплохо представляют, что за инструменты даны им в руки, но зачем они изобретены и к чему применимы, понимают смутно.
Вот поэтому я сочинил несколько учебных примеров, на которых можно показать зачем нужны некоторые подходы. Правда, придётся принять условность — будем бить из пушки по воробьям, а то и по воображаемым мишеням. Зато пристреляемся и уж во вражеский бруствер точно попадём, случись что.
Сразу скажу, что от вопросов совсем простых мы быстро перейдем к довольно сложным (ну, скажем, к компоновщику), потому читайте до конца, если уж не с начала.

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

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

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

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

Вступление

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

• Скачать пример (EF4, C#) — 1.03 MB
• Скачать пример (EF4, C#, separating data layer from the UI layer) — 120 KB
• Скачать пример (EF4, VB, provided by Mr 'VBForever') — 946 KB
• Скачать пример (EF5, C#) — 1.3 MB 
• Скачать пример (EF6 C#) = 1.3 MB  

На сегодняшний день Winforms все еще остается платформой для многих бизнес-приложений, ориентированных на работу с данными, и привязка данных является неотъемлемой частью разработки для Winforms. Если вы использовали стандартные классы ADO.NET для работы с данными, то вы знакомы с инструментами, используемыми для создания классов DataSet и связывания этих классов во время разработки с помощью их свойств DataSource, DataMember или Binding.

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

Хорошая новость заключается в том, что с помощью библиотеки EFWinForms можно легко выполнить привязку данных и создать повторно используемый компонент для привязки данных в Winforms. В библиотеке есть два компонента:

• EntityDataSource: компонент, который инкапсулирует модель сущности данных и представляет его элементы в качестве источников данных, пригодных для связывания, с полной поддержки во время разработки.
  
• EntityBindingNavigator: элемент управления, который обеспечивает навигацию для просмотра и предоставляет пользовательский интерфейса для добавления и удаления записей, сохранение или отмены изменений в базе данных.
  

От переводчика: прочитав статью, начал было отвечать в комментариях, но решил, что текст, на которую я собирался ссылаться, достоин отдельной публикации. Встречайте!

Если вы знаете, как валидировать email-адрес, поднимите руку. Те из вас, кто поднял руку — опустите её немедленно, пока вас кто-нибудь не увидел: это достаточно глупо — сидеть в одиночестве за клавиатурой с поднятой рукой; я говорил в переносном смысле.

До вчерашнего дня я бы тоже поднял руку (в переносном смысле). Мне нужно было проверить валидность email-адреса на сервере. Я это уже делал несколько сот тысяч раз (не шучу — я считал) при помощи классного регулярного выражения из моей личной библиотеки.

В этот раз меня почему-то потянуло ещё раз осмыслить мои предположения. Я никогда не читал (и даже не пролистывал) RFC по email-адресам. Я попросту основывал мою реализацию на основе того, что я подразумевал под корректным email-адресом. Ну, вы в курсе, что обычно говорят о том, кто подразумевает. [прим. перев. Автор имеет в виду игру слов: «when you assume, you make an ass out of you and me» — «когда вы (что-то) подразумеваете, вы делаете /./удака из себя и из меня»]

И обнаружил кое-что занимательное: почти все регулярные выражения, представлены в интернете как «проверяющие корректность email-адреса», излишне строги.

Мне хотелось бы рассказать о своём опыте пусконаладки и разработки промышленного программного обеспечения. При чтении статьи просьба учитывать, что дело происходило почти два года назад, и с того времени уже многое поменялось.

Итак, ранней весной 2014 года я поднялся на третий этаж бетоносмесительного узла одного завода. В моём распоряжении были два планетарных бетоносмесителя фирмы Wiggert, линия адресной подачи Kubat на два монорельса и полностью разбомбленный цех внизу, в который надо было выдавать бетон. В перспективе.

В чём заключался хитрый план? Мы должны были с нуля наладить производство пустотного настила в одном пролёте цеха и стеновых панелей — в другом.

Вот так выглядит пустотный настил в разрезе:


Фото с сайта echo.co.za

Представляю вашему вниманию перевод документа "Coding Guidelines for C# 3.0, 4.0 and 5.0".

Целью создания этого списка правил является попытка установить стандарты написания кода на C#, которые были бы удобными и практичными одновременно. Само собой, мы практикуем то, что создали. Эти правила являются одним из тех стандартов, которые лежат в основе нашей ежедневной работы в AvivaSolutions. Не все эти правила имеют четкое обоснование. Некоторые из них просто приняты у нас в качестве стандартов.

Статический анализатор кода VisualStudio (который также известен как FxComp) и StyleCop могут автоматически применять многие из правил кодирования и оформления путем анализа скомпилированных сборок. Вы можете сконфигурировать их таким образом, чтобы анализ производился во время компиляции или был неотъемлемой частью непрерывной или ежедневной сборки. Этот документ просто добавляет дополнительные правила и рекомендации, но его вспомогательный сайт www.csharpcodingguidelines.com предоставляет список правил анализа кода, необходимых в зависимости от того, с какой базой кода вы работаете.

В этой небольшой статье хотел бы с вами поделиться парой забавных багов (или особенностей) Visual Studio\.NET и возможно услышать от вас о некоторых других. Конечно же самих багов в вышеупомянутых продуктов на самом деле было (есть) много и найти их можно на специализированном сайте connect.microsft.com. Я же хотел рассказать о самых забавных на мой взгляд.

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

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

Доброго времени суток!
Model-View-Presenter — довольно известный шаблон проектирования. С первого взгляда все выглядит просто: есть Модель (Model), которая содержит всю бизнес-логику экрана; Вид/Представление (View), который знает, как отобразить те или иные данные; Представитель (Presenter), который является связующий звеном — реагирует на действия пользователя во View, изменяя Model, и наоборот.
Сложность начинается, когда количество форм в проекте становится более одной.
В данной статье рассматривается:
— немножко теории;
— общие проблемы реализации MVP (а именно Passive View) под Windows Forms;
— особенности реализации переходов между формами и передача параметров, модальные окна;
— использование IoC-контейнера и шаблона Dependency Injection — DI (а именно Сonstructor Injection);
— некоторые особенности тестирования MVP приложения (с использованием NUnit и NSubstitute);
— все это будет происходить на примере мини-проекта и постарается быть наглядным.
В статье затрагивается:
— применение шаблона Адаптер (Adapter);
— простенькая реализация шаблона Контроллер приложения (Application Controller).
Для кого эта статья?
Главным образом для начинающих разработчиков на Windows Forms, которые слышали, но не пробовали, или пробовали, но не получилось. Хотя уверен, что некоторые приемы применимы и для WPF, и даже для веб-разработки.

Дело было так… мне понадобился односторонний биндер. Только не от контрола к источнику, а наоборот. Я в коде сто тыщ раз меняю значение источника — и не хочу, чтоб голова болела о всяких там textbox'ах. Хочу, чтоб они сами обновлялись…

Вообще-то, у буржуев уже есть встроенный биндер, очень мощный и крутой. Настолько мощный и крутой, что почти без документации. Точнее, ее черезмерно много — и везде невнятно, нечетко. Короче, плюнул я на буржуйские технологии и решил ВОТ ЭТИМИ РУКАМИ запилить свой биндер… Теперь вот показываю новичкам — наверно, кому-то пригодиться для расширения С#-кругозора.

В этом году в качестве курсовой работы мне нужно было написать несложную медицинскую информационную систему (МИС) для небольшой частной клиники по лечению эпилепсии.

База данных пациентов в клинике уже была, написана она была еще в далеком 1998 году в Microsoft Access того времени (причем даже с красивым пользовательским интерфейсом), но вот работала она только в одном месте — на компьютере заведующего, да еще и поддерживать ее стало совершенно невозможно. Значит, давно назрела необходимость внедрять что-то новое!

Сказано — сделано. Работать надо было быстро (все-таки сдавать курсовую пора) и при этом хотелось сделать работу максимально интересной для себя. Я давно хотел разобраться с ASP.NET MVC, был немного знаком с C# и общими принципами MVC, поэтому скачал последнюю Visual Studio 2015 RC и принялся за работу.

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

Я бы хотел обсудить принцип разделения ответственности (Separation of Concerns, SoC) в контексте ORM, а также посмотреть почему этот принцип так важен. Также мы рассмотрим примеры нарушения границ ответственности между доменной логикой и логикой сохранения данных.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

От переводчика: англоязычные it-блоггеры обычно начинают такие статьи со слов I'm so excited. Про Wix# я узнал совершенно случайно и спешу поделиться этим открытием с хабрасообществом, т.к. каждый, кто имел дело с «голым» WiX, знает, насколько неприятным может быть этот процесс. И вот теперь можно сделать msi-дистрибутив, написав всего лишь несколько строчек на C#! По-моему, это круто! А относительно недавно (4 дек 2014) автор Wix# Олег Шило дал интервью изданию InfoQ. Перевод этого интервью я и представляю вашему вниманию. И прошу не судить строго за кальку некоторых слов — тот же «деплоймент» мне как-то ближе, чем «развертывание».

Изучая язык программирования C#, я сталкивался с особенностями как самого языка, так и его средой исполнения, *некоторые из которых, с позволения сказать, «широко известны в узких кругах». Собирая таковые день за днем в своей копилке, что бы когда-нибудь повторить, чего честно сказать еще ни разу не делал до этого момента, пришла идея поделиться ими.

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

Привет всем!
Работаю в компании. 1500+ активных пользователей.
Организован ХелпДеск, сотрудники регистрируют тикеты в системе, но, как-то так получается, что часть из юзеров забывают указывать имя пк, за которым они находятся.

Для выяснения этой информации (по телефону/email/экстрасенсорные способности) девочки из поддержки тратят драгоценное время, которое они могли бы уделить свежей чашке кофе или разговорам о новом платье (шутка). Наши сотрудники постоянно заняты своей непосредственной работой.

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

В этом году, согласно федеральному закону Российской Федерации от 21 июля 2014 г. N 248-ФЗ, в закон об истечении времени под номером N 107-ФЗ от 3-го июня 2011 года, были внесены некоторые изменения (о самих изменениях немного ниже), в связи с которыми 26 октября 2014 года осуществляется перевод часов и устанавливаются соответствующие часовые зоны и значения времени.

Следовательно, корпорация Microsoft не заставила себя ждать и 23-го сентября этого года выпустила очередной патч, предназначенный для учета текущих изменений в порядке исчисления времени, благодаря которому в операционные системы Windows будут внесены соответствующие правки. Этот патч (под номером KB2998527) можно проинсталлировать практически на все актуальные операционные системы Windows.

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

Начнем мы с