Big Data глазами разных индустрий — это очередная мечта о Граале, который решит, спасет и защитит! В жизни всё точностью до наоборот: Big Data — это совершенно новые задачи, свертывания застойных проектов и увольнения неперестроившихся специалистов. Предлагаем цикл статей по практике реального применения неструктурированных Big Data в разных индустриях, становлении новых специальностей, которым еще только придумываются названия — аналитик и социолог Big Data, HiLoad-лингвист, журналист-трендист (от слова трЕнд, а не трЫндеть), — и, надеемся, плодотворных обсуждений куда должна привести новая большая дорога.

На конференции connect(), мы объявили, что .NET Core будет выпущен полностью как программное обеспечение с открытым исходным кодом. В этой статье мы сделаем обзор .NET Core, расскажем, как мы собираемся его выпускать, как он соотносится с .NET Framework и что это все означает для кросс-платформенной разработки и разработки с открытым кодом.

Добрый день, коллеги!

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



В этой статье я продолжаю давать определения терминам в рамках логической парадигмы. Я развиваю мысль о том, что такое реальность и о том, как мы ее моделируем. Я подчеркиваю тот факт, что мир, в котором мы живем, — это иллюзия. Мы даже не знаем, есть ли мы на самом деле, или наше существование — тоже иллюзия. Наше «Я» думает, что существует, но существует оно в мире иллюзий. Все, что мы видим, и что моделируем, — мы видим иллюзию и моделируем иллюзию.

В качестве реакции на мой предыдущий пост о защитном программировании, один из моих читателей прислал мне такой вопрос:

[Один] очень известный сценарий защитного программирования встречается, когда входным параметром является

IEnumerable




public class Publisher
{
    public Publisher(IEnumerable<Subscriber> subscribers)
    {
        // defensive copy -> good or bad?
        this.subscribers = subscribers.ToArray();
    }
    //  …
}

В этой статье я хочу рассказать о проблемах использования интерфейса IEnumerable. Мы рассмотрим, какие проблемы может принести использование этого интерфейса, когда его на самом деле нужно использовать, и чем его заменить.

А начать статью я хотел с пары примеров кода, а точнее с пары багов, встречавшихся мне в реальных проектах.

Для начала несколько вещей о которых вы могли не слышать:

• Идентификаторы в C# могут включать в себя escape-последовательности Unicode символов (как например \u1234).
• Идентификаторы в C# могут включать в себя Unicode символы категории Cf (other, format), но при сравнении идентификаторов на идентичность эти символы игнорируются.
• Символ «Монгольский разделитель гласных» (U+180E) в зависимости от версии Unicode принадлежит либо категории Cf (other, format), либо категории Zs (separator, space).
• В .NET хранится свой собственный список Unicode категорий, независимый от оных в Win32.
• Roslyn является .NET приложением, и поэтому использует Unicode категории, прописанные в файлах .NET. Нативный компилятор (csc.exe) использует либо системные (Win32) категории, либо хранит в себе копию таблиц Unicode.
• Никакая из таблиц Unicode символов (ни .NET, ни Win32) точно следует какой-либо из версий стандарта Unicode.
• Компиляторы могут иметь баги.

Из всего этого вытекают некоторые проблемы…

Во всём виноват Владимир

Все началось с обсуждения на собрании технической группы ECMA на прошлой неделе. Мы рассматривали «нормативные ссылки», и в частности какую версию стандарта Unicode мы будем использовать. На тот момент спецификация ECMA-335 (4-ое издание) использует Unicode 4.0, а спецификация C# 5 от Microsoft использует Unicode 3.0. Я точно не знаю, учитывают ли разработчики компиляторов такие особенности. На мой взгляд было бы лучше, если ECMA и Microsoft не указывали конкретную версию Unicode в своих спецификациях. Пусть разработчики компиляторов используют самую свежую версию Unicode, доступную на текущий момент. Однако тогда компиляторы должны будут поставляться со своей личной копией таблицы Unicode, что немного странно, на мой взгляд.

В рамках моей «работы» над стандартизацией C# 5 в технической группе ECMA-334 TC49-TG2 мне посчастливилось увидеть несколько интересных способов, которыми Владимир Решетников проверял C# на прочность. В данной статье описана одна из проблем, которые он поднял. Разумеется, она, скорее всего, никак не затронет 99.999% C#-разработчиков… но разобраться все равно любопытно.

Спецификации, используемые в статье:

• Стандарт Unicode 7.0.0 – в особенности, глава 3
• C# 5 (Документ Word)
• ECMA-335 (Спецификация CLI)

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

Как бы вы объявили тип string (или System.String)? Я могу предположить несколько вариантов ответа на данный вопрос, от расплывчатых до довольно конкретных:

• «Какой-нибудь текст в кавычках»
• Последовательность символов
• Последовательность символов Юникода
• Последовательность 16-битных символов
• Последовательность слов UTF-16

Только последнее утверждение полностью верно. Спецификация C# 5 (раздел 1.3) гласит:

Обработка строк и символов в C# использует UTF-16. Тип char представляет слово UTF-16, а тип string – последовательность слов UTF-16.

Пока всё в порядке. Но это C#. А как насчет IL? Что используется там, и имеет ли это значение? Оказывается, что имеет… Строки должны быть объявлены в IL как константы, и природа этого способа представления важна – не только кодировка, но и интерпретация этих закодированных данных. В частности, последовательность слов UTF-16 не всегда может быть представлена в виде последовательности слов UTF-8.

Мы продолжаем наши еженедельные публикации учебных материалов Технопарка. Предыдущие лекции были посвящены web-технологиям в целом, а также алгоритмам и структурам данных. В третьем блоке лекций рассказывается о языках С и С++.

Лекция 1. Язык С. Основы организации и использования оперативной и сверхоперативной памяти

Лекция начинается с введения в язык С: рассказывается об истории его появления, особенностях, преимуществах и недостатках, о сферах применения. Описываются основы препроцессорной обработки, рассматриваются вопросы управления памятью (модели управления памятью, области видимости объектов хранения) и производительность программ на языке С. Обсуждается связывание объектов хранения и их инициализация. Затем рассказывается о классах памяти в языке С. Следующая часть лекции посвящена проблематике указателей, а также работе с одномерными массивами. В заключение рассматривается стандарт POSIX и вопросы переносимости.

Вслед за Банком Англии, американский технический гигант IBM планирует создать аналог биткоин для традиционных валют, используя блокчейн-технологию, сообщает агентство Рейтер.

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

В статье объясняется: ”Все сделки будут находится в блокчейн (открытой бухгалтерской книге) в валюте определенной страны, например, в долларе или евро.



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

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

Довелось как-то раз отлаживать вот такой код на C#, который «на ровном месте» падал с NullReferenceException:

	public class Tester {
		public string Property { get; set; }
		public void Foo() {
			this.Property = "Some string"; // NullReferenceException
		}
	}

Да, вот на этой самой строчке с присвоением свойства падал NullReferenceException. Что за дела, думаю — неужели рантайм перестал проверять наличие экземпляра перед вызовом экземплярных методов?

Как оказалось — в некотором роде да, перестал. Правда, и компилятор оказался не тем, за кого себя выдаёт, да и проверки вовсе не гарантированы рантаймом… Подробнее — под катом.

Предлагаю читателям «Хабрахабра» перевод публикации «100 Prisoners Escape Puzzle», которую я нашел на сайте компании DataGenetics. Все ошибки по данной статье присылайте, пожалуйста, в личные сообщения.

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

Что такое фильтры исключений?

Фильтры исключений (Exception Filters) — новая фича C# 6, которая позволяет устанавливать специфические условия для блока catch. Этот блок будет исполнятся только в случае, если указанные условия выполнены. Проиллюстрируем синтаксис небольшим фрагментом кода:

public void Main()
{
  try
  { 
    throw new Exception("E2");
  }
  catch(Exception ex) when(ex.Message == "E1")
  {
    Console.WriteLine("caught E1");
  }
  catch(Exception ex) when(ex.Message == "E2")
  {
    Console.WriteLine("caught E2");
  }
}

Устраиваясь на новую работу, я придумал новый вопрос для собеседования. Хочу задать его и вам.

Пусть у нас есть конкретная машина. КОНКРЕТНАЯ! Не тип и не класс машин, А именно конкретная машина, на которую я указываю своим указательным пальцем. Хозяин этой машины утверждает, что его машина состоит из множества компонентов, в том числе из колес. Он говорит, что его машина состоит из пяти колес (одно запасное). Замечу сразу, что хозяин говорит: «состоит из», а не «включает в себя».

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



Или то, что машина состоит из класса колес?

Привет, Хабр!

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

• С чего начать обучение программированию?
• У вас есть курс по Java для новичков, но я слышал, что нужно изучать Python, правда ли это?
• На других сайтах все просто и понятно, а у вас какие-то компиляции и тесты!
• Непонятно зачем нужен этот ваш курс по алгоритмам, в реальной жизни все алгоритмы уже реализованы в стандартных библиотеках

Но сложнее всего объяснить новичку, грубо говоря, во что он ввязывается. Благодаря очень простым, игровым образовательным проектам многие считают, что программирование это очень легко, а наши виртуальные машины, где нужно запускать тесты и компилировать код – это надуманная сложность. Давно хотелось найти такой материал, который бы подготовил новичка к длинному и сложному пути к карьере программиста. И недавно наши коллеги из Viking Code School такой материал написали! А мы его перевели для вас.



Квинси Ларсон был просто “офисным парнем в костюме”. Он решил научиться программировать. Начал спрашивать людей вокруг. Изучил немного Руби, потом быстренько посмотрел на другие языки вроде Scala, Clojure и Go. Он изучил Emacs, а потом Vim, а потом раскладку Dvorak. Он втыкал в Линукс, копался с Лиспом и кодил на Питоне, и жил при этом в командной строке больше полутора лет.

Его швыряло туда-сюда как листочек в торнадо. Каждый совет, который он слышал, тащил его то в одну, то в другую сторону, до тех пор пока он не прошел “каждый онлайн-курс по программированию во вселенной”. В конце концов, не смотря на то, что он получил работу разработчика ПО, Квинси:

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

Ох. Звучит знакомо?

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

Мы в Хекслете недавно запустили новую версию, ключевой особенностью которой стали практические упражнения по программированию в браузере. В связи с этим мы стали получать еще больше писем от начинающих программистов с вопросами вроде «с чего начать». С одной стороны, они хотят выложить бета-версию приложения в app store через неделю. С другой стороны, мы понимаем, что за такой короткий срок, наверное, можно научиться кодить приложения, но нельзя научиться программировать. И сложно решить, что лучше: как можно быстрее научить созданию простых приложений без реального понимания программирования, алгоритмов и их вычислительной сложности, а потом начать знакомство с этими важными темами, или начать «с начала», и органично придти к созданию приложений и продуктов после освоения фундамента.

В 2001 году, Эдсгер Дейкстра написал письмо экономическому совету университета Техаса. В нем знаменитый ученый призывает членов совета задуматься о смене языка программирования для вводного курса. К сожалению, язык был заменен на Java. Примерно в то же время MIT сменили язык курса «Структура и интерпретация компьютерных программ» с функционального Scheme (диалекта LISP) на Python.

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

Членам Экономического Совета

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

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

Ни до, ни после 1997 года поединки между компьютером и человеком не привлекали к себе такого общественного внимания.

Ошеломительный результат воспринялся широкой общественностью как начало эры новых чемпионов.

Примечание переводчика: я заменил оригинальные обозначения сторон монеты head/tail на аверс/реверс, чтобы не вносить путаницу русскоязычными орёл/решка. На иллюстрации выше слева аверс (head), справа реверс (tail).

Спасение невозможно?

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

В нашей статье об эффективных ревью кода мы рекомендовали использовать чеклист. Чеклисты (контрольные списки) — это великая вещь в ревью: они гарантируют, что ревью действительно прошло через вашу команду. Также они способствуют выявлению и решению общих трудностей.

Исследование, проведенное Software Engineering Institute, показывает, что программисты делают 15-20 распространенных ошибок. Добавив такие ошибки в чеклист, вы можете быть уверены, что заметите их в момент появления и поможете от них избавиться надолго.

Чтобы вам было от чего отталкиваться, вот вам список типичных пунктов:

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

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

Но прежде, чем «запустить» материал, еще небольшое отступление. О том, почему вообще я все это писал. Дело в том, что у нас в странах бывшего СССР с образованием в области IT очень туго. С одной стороны нет программ обучения, которые подготовят специалистов на должном уровне (наверное, за очень редкими исключениями, которые можно отнести к погрешности). С другой стороны, из-за широких возможностей самообразования, программисты и не спешат учиться в ВУЗах — все стремятся начать практиковать как можно раньше. Часто изучается только одно направление (например PHP+Mysql — самое популярное) и в бой. Причем, на этом все заканчивается. В итоге у нас огромное количество программистов, которые и базовых вещей не знают. Отсюда вытекают проблемы с качеством кода, и с эффекивностью алгоритмов, с велосипедированием.

Но программирование — это полноценная область знаний, которая требует в том числе и инженерной подготовки. Точно так же, как строительство или телекоммуникации. Да, построить дом (особняк) можно своими руками и без образования. А поднять большинство сайтов можно прочитав пару книг по PHP и HTML. Но многоэтажку без специальной подготовки не построишь, как и Гугл не напишешь, не зная основ.

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

Поехали.

Введение

Хочу заметить, что тем, кто пользуется терминами ООП, будет очень трудно понять меня. Дело в том, что ООП подменил понятия. В ООП под классом понимается не множество, как обычно принято в математике, или лингвистике. В ООП классом называют тип объектов, как у Аристотеля. Было бы правильно в ООП вместо термина класс объектов использовать термин тип объекта. Однажды, съехав с правильной терминологии, вернуться в лоно правильных терминов оказывается очень трудно. В данной статье я попробую помочь тем, кто желает разобраться с терминологической кашей, заваренной ООП. В своих рассуждениях я буду использовать термины в их первоначальном смысле, а не в смысле ООП. Термин класс будет взят из логической парадигмы моделирования предметных областей, которая, в свою очередь, заимствовала этот термин из теории множеств. Термины тип и экземпляр будет взят из теории типов, построенной на парадигме Аристотеля о существовании типов.

Адепту ООП очень трудно понять, что термин экземпляр класса в русском языке указывает на класс объектов, а не на созвучный этому термину элемент класса – объект класса. Для многих, кто изучал ООП, термины экземпляр и элемент – неразличимы. Давайте разберемся с этими терминами внимательно.