Шесть советов тем, кто хочет выучить язык и переводить.



Авторы Хабра, которые переводят статьи, делают большое дело — они преодолевают за других большущий языковой барьер, это я говорю без иронии. Одновременно я регулярно вижу самодельные или сделанные фирмами программы для запоминания слов, и это я считаю не самым полезным делом. Да, конечно, карточки полезны. На начальном этапе, уча с полного нуля, первые 50 слов можно ими выучить. Дальше слова лучше учить в контексте.

Мой первый совет и главное, что стоит запомнить из заметки — бросьте запоминать слова. Учите грамматику.

Примечание переводчика: хоть статья довольно старая (опубликована 2 года назад) и носит громкое название, в ней все же дается хорошее представление о различиях реляционных БД и NoSQL БД, их преимуществах и недостатках, а также приводится краткий обзор нереляционных хранилищ.

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

Если это правда, значит ли это, что могучие реляционные БД стали уязвимы? Значит ли это, что дни реляционных БД проходят и скоро совсем пройдут? В этой статье мы рассмотрим популярное течение нереляционных баз данных применительно к различным ситуациям и посмотрим, повлияет ли это на будущее реляционных БД.

По следам недавнего топика «Обработка больших объемов данных в памяти на C#» представляю перевод упоминавшейся там статьи о структурах.

Структуры являются фундаментальными типами данных в C# и большинстве других современных языках программирования. По своей сути структуры просты, но вы можете удивиться, насколько быстро работа с ними может стать сложной. Чаще всего проблемы возникают, если вы должны работать со структурами, созданными в других языках и сохраненными на диске или полученными в результате вызова функций из библиотек или COM-объектов. В этой статье я подразумеваю, что вы знакомы с понятием структуры, умеете определять их и владеете базовыми навыками работы со структурами. Предполагается, что вы имеете представление о том, как вызывать API функции с использованием p/Invoke, а также что такое маршалинг. В случае неуверенности в своих знаниях вы можете обратиться к документации.
Множество техник, описанных в данной статье, могут быть расширены и применены к любым типам данных.

Паттерн Singleton появился, пожалуй, как только появились статичные объекты. В Smalltalk-80 так был сделан ChangeSet, а чуть в самых разных библиотеках стали появляться сессии, статусы и тому подобные объекты, которых объединяло одно — они должны были быть одни-единственные на всю программу.

В 1994 году вышла известная книга «Паттерны проектирования», представив публике, среди 22-х прочих, и нашего героя, которого теперь назвали Singleton. Была там и его реализация на C++, вот такая:

Постановка задачи

В этой статье я опишу механизм создания DTO, реализованный в одном из проектов нашей компании. Проект состоит из серверной части и нескольких клиентов (Silverlight, Outlook, iPad). Сервер представляет собой ряд сервисов, реализованных на WCF. Раз есть сервисы, то надо обмениваться с ними какими-то данными. Вариант, когда клиенты знают о сущностях доменной области и получают их с сервера, отпал сразу по ряду причин:

1. Не все клиенты реализованы на .NET
2. Возможные проблемы сериализации сложных графов объектов
3. Избыточность передаваемых данных

В принципе, все эти недостатки давно известны и для их устранения умные люди придумали паттерн Data Transfer Object (DTO). То есть, классы сущностей доменной области известны только серверу, клиенты же оперируют классами DTO и экземплярами этих же классов обмениваются с сервисами. В теории все прекрасно, на практике же среди прочих возникают вопросы создания DTO и записи в них данных из сущностей. В небольших проектах с этой работой отлично справится оператор "=". Но, когда размер проекта начинает расти и повышаются требования к производительности и сопровождаемости кода, возникает необходимость в более гибком решении. Ниже я опишу эволюцию механизма, который мы используем для создания и заполнения DTO.

В этом посте я рассматриваю концепцию и ее реализацию (пока в начальной, но рабочей стадии), которая с недавних пор стала меня сильно привлекать. Опыта в программировании на сигналах у меня ранее не было, поэтому что-то мог упустить или неоптимально продумать, потому и пишу сюда. Надеюсь на квалифицированные отзывы и советы. Несмотря на то что библиотека только начала развиваться, я уже начал ее использование в реальных проектах, на реальной нагрузке, это помогает быстро понять что действительно нужно и куда двигаться дальше. Так что весь приведенный код находится в рабочем состоянии, компилируется и готов к использованию. Единственное все делается на Framework 4.5, но не думаю что это будет для кого-то препятствием, если же идея окажется стоящей, пересобрать под 3.5 проблем не будет.

Что же не так с текущей парадигмой

Устройство обычного приложения на .NET подразумевает что у нас есть набор классов, в классах есть данные, и методы которые эти данные обрабатывают. Также нашим классам надо знать друг о друге, о public методах, свойствах и событиях. То есть у нас сильносвязная архитектура. Конечно мы можем уменьшить связность, построить взаимодействие исключительно через интерфейсы и фабрики (что увеличит размер кода раза в два, и существенно усложнит читабельность), можем убрать открытые методы и стоить все на событиях, придумать можно много чего, но перейти к слабосвязанной архитектуре все равно не выйдет, получим в лучшем случае «среднюю» связанность.

Да, и еще есть такая вещь, которая с развитием процессоров становится все более актуальной, это асинхронность, microsoft делает много хорошего в этом направлении, тот же PLINQ, всякий сахар вроде await, но все это делается все равно в привычных рамках ООП, и нам все еще приходится самим создавать потоки, пускай и в виде тасков, но самим. Нужно отслеживать окончание исполнения задач, чтобы определить когда рессурсы станут ненужными.

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

Генерировать код на .Net можно несколькими способами:

• Reflection Emit. Доступен с версии .Net 1.0.
• CodeDom. Позволяет создавать динамический код из представления CodeDom или напрямую из исходников, написанных на одном из высокоуровневых языков, например C#, VB или JScript. Доступен с версии .Net 1.0.
• Expression trees. Доступен с версии .Net 3.5. Позволяет создавать динамический код из представления Expression.

В этой статье я хочу рассказать про технику кодогенерации с использованием Reflection Emit.

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

Прошу принять во внимание, что это пилотный проект. А так конструктивная критика приветствуется, пожелания принимаются.
Приносим извинения за качество звука, смотреть лучше в HD и погромче.

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

Хотите знать, как я обычно участвую в таких спорах?

— Так какие же тесты пишешь ты сам?
— Мнэ-э…

— Когда же ты пишешь тесты?
— Мнэ-э…

— Ты вообще тесты пишешь?
— Мнэ-э…

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

Но как раз сейчас у меня, кажется, есть эта парочка часов.

Впервые прочитав знаменитую статью Джоша Смита WPF Apps With The Model-View-ViewModel Design Pattern я был очень вдохновлен философией MVVM и решил все будущие проекты писать исключительно с ее использованием. По мере «внедрения» MVVM я столкнулся с определенными трудностями и недостатками (на мой субъективный взгляд). В одном из проектов мне был необходим UserControl, который бы позволял авторизироваться на веб-сервисе. При попытке забиндить свойство ViewModel к элементу управления PasswordBox я получил такую ошибку:
A 'Binding' cannot be set on the 'Password' property of type 'PasswordBox'. A 'Binding' can only be set on a DependencyProperty of a DependencyObject

Всегда приятно делиться хорошей новостью. И сегодняшнее утро я как раз и хочу начать именно с хорошей новости.

Доступен новый практический обучающий курс по Windows Phone 8 на русском языке. Для нетерпеливых — сразу ссылка на заглавную страницу курса: aka.ms/wp8labs.

Данный курс предполагает, что вы уже знакомы с разработкой под Windows Phone. Если это не так, можно начать с курса по Windows Phone 7.5 msdn.microsoft.com/ru-ru/ff380145 или книги.

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

Когда-то я собрала набор простых правил, которые помогают избежать 80% самых распространенных ошибок, касающихся построения интерфейсов. Решила расшарить их для хабрасообщества.
Кому интересно — добро пожаловать под кат.

Друзья, рады поделиться с вами несколькими тематическими примерами приложений для Windows 8, от которых вы можете отталкиваться в своей работе. Все примеры размещены на CodePlex и доступны для загрузки с исходным кодом.

Перевод статьи Random numbers широко известного в узких кругах Джона Скита. Остановился на этой статье, так как в своё время сам столкнулся с описываемой в ней проблемой.

---

Просматривая темы по .NET и C# на сайте StackOverflow, можно увидеть бесчисленное множество вопросов с упоминанием слова «random», в которых, по сути, поднимается один и тот же извечный и «неубиваемый» вопрос: почему генератор случайных чисел System.Random «не работает» и как это «исправить». Данная статья посвящена рассмотрению данной проблемы и способов её решения.

В предложенной статье рассматривается решение задачи параллельной синхронной обработки IEnumerable, а также откуда такая задача вообще взялась.

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

7. Производительность скалярных UDF оставляет желать лучшего

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

Посмотрите этот пост о принудительном использовании параллелизма – в частности, список того, что приводит к генерации «однопоточного» плана выполнения запроса. Скорее всего, использование скалярных UDF (прим. переводчика: а для серверов младше 2008 R2 и не только скалярных) приведёт к тому, что ваш запрос будет выполняться в одном потоке (*грустно вздыхает*).

Содержание

I. Описание проблемы
II. Обзор существующих решений
III. Вариант решения без применения аспектов.
IV. Решение на AspectJ
V. Динамические аспекты
VI. Послесловие.
VII. Ссылки и литература

С выходом .NET Framework 4.0 в состав BCL была добавлена библиотека Task Parallel Library (TPL), реализующая параллелизм на основе задач. В основе библиотеки лежат типы Task и унаследованный от него тип Task. Эти типы являются обёртками для асинхронных операций; они позволяют абстрагироваться от таких технических деталей, как, например, потоки и синхронизировать асинхронные операции друг с другом.

В этой же версии .NET Framework появился мини-framework для кооперативной отмены асинхронных операций. Состоит он из всего трёх типов:

• CancellationTokenSource — создаёт маркёры отмены (свойство Token) и обрабатывает запросы на отмену операции (перегруженные методы Cancel/CancelAfter).
• CancellationToken — маркёр отмены; позволяет несколькими способами отслеживать запросы на отмену операции: опросом свойства IsCancellationRequested, регистрацией callback-функции (через перегруженный метод Register), ожиданием на объекте синхронизации (свойство WaitHandle).
• OperationCanceledException — исключение, выброс которого по соглашению означает, что запрос на отмену операции был обработан и операция должна считаться отменённой. Предпочтительный способ генерации исключения — вызов метода CancellationToken. ThrowIfCancellationRequested.

Механизм отмены через CancellationToken является стандартным для TPL — есть перегрузки методов, принимающих CancellationToken, исключения OperationCanceledException специальным образом обрабатываются и т.д. Однако, как и в любом другом API, есть свои тонкости, хитрости, best practices.

Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

Все мы знаем как хорошо и похвально принимать участие в разработке открытых проектов.
К тому же потом можно мерятся количеством коммитов в rails и зарплату попросить побольше.

А что если вы решили написать свой open source проект?