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

Старт системы

Полностью компьютер выключен когда он отключен от питания и конденсаторы на материнской плате разрядились. До эры смартфонов мобильные телефоны часто глючили и если перезагрузка не лечила проблему, то приходилось доставать батарею и ждать 10 секунд, потому что сбрасывалось программное состояние ОС, в то время как чипы на материнской плате и контроллеры устройств оставались активными сохраняя состояние, драйвера ОС к ним просто реконнектились. 10 секунд — время на разрядку конденсаторов, состояние чипов сбрасывается только при полном отключении.
Если же ПК подключен к розетке или батарее, то он находится в режиме Stand-By, это значит что по шине питания подаётся маленькое напряжения (5В) от которого запитываются некоторые чипы на материнке. Как минимум это системный контроллер, по сути это мини-компьютер запускающий большой компьютер. Получив уведомление о нажатии кнопки Power он просит блок питания/батарею подать больше напряжения и после инициализирует весь чип-сет, в том числе и процессор. Инициализация включает в себя перекачку кода и данных прошивки материнки (BIOS/UEFI) в оперативную память и настройку CPU на её исполнение.
Думать что кнопка Power это рубильник который подаёт электричество на CPU и тот начинает исполнять с заранее известного адреса прошивку BIOS неправильно. Возможно старые компьютеры так и работали. Кнопка включения находится на своей плате, вместе со светодиодами состояний и к материнке она подключается через специальный разъём. На картинке ниже видны контакты для кнопки Power, Reset, а также светодиодов с состоянием Power и чтения жёсткого диска. Нажатие кнопки включения переводится в сигнал на контакты материнки, откуда он достигает системный контроллер.

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

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

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

Приветствую, Хабр! Предлагаю вашему вниманию небольшую пятничную статью про Java, Scala, ненормальных программистов и нарушенные обещания.

---

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

Вот, к примеру, простой и внешне, пожалуй, даже тривиальный факт, гласящий, что в Java можно расширять любой не-final класс и любой интерфейс в области видимости. И другой, тоже достаточно простой, гласящий, что Scala-код, скомпилированный для JVM, может использоваться из Java-кода.

Сочетание этих двух фактов, однако, заставило меня задаться вопросом: а как поведёт себя с точки зрения Java какой-нибудь класс, который в Scala является sealed, т.е. не может быть расширен внешним относительно его собственного файла кодом?

Декомпилированный Scala-класс в представлении художника. Источник: https://specmahina.ru/wp-content/uploads/2018/08/razobrannaya-benzopila.jpg

В качестве подопытного кролика я взял стандартный класс Option. Скормив его декомпилятору, встроенному в IntelliJ Idea, получаем примерно следующее:

// опустим импорты, они сейчас не слишком интересны
public abstract class Option 
implements IterableOnce, Product, Serializable {
    // кучка реализаций методов
    public abstract Object get();
    // ещё кучка реализаций методов
}

В современных музеях и архивах древние тексты, рукописи и книги хранятся в определенных условиях, что позволяет сохранить их первозданный вид для будущих поколений. Самым ярким представителем нетленных рукописей считаются свитки Мертвого моря (Кумранские рукописи), впервые найденные еще в 1947 году и датируемые 408 годом до н. э. Некоторые из свитков сохранились лишь фрагментарно, но есть и практически не тронутые временем. И тут возникает очевидный вопрос — как же людям более 2000 лет тому назад удалось создать манускрипты, дожившие до наших дней? Именно это и решили выяснить в Массачусетском технологическом институте. Что нашли ученые в древних свитках и какие технологии использовались для их создания? Об этом мы узнаем из доклада исследователей. Поехали.

Совсем недавно мы опубликовали статью с описанием проблем одной из самых популярных технологий, используемых в IT, и на наше удивление она вызвала достаточно живой интерес (во всяком случае для технической статьи). Поэтому мы решили на этом не останавливаться, и сегодня мы «идем в гости» к одному из самых популярных продуктов на российском рынке разработки бизнес-приложений — платформе 1С.

Так сложилось, что на хабре многие 1С не любят, но порой складывается впечатление, что немногие из этих людей хорошо понимают, за что они его не любят. Этой статьей мы восполним этот пробел и убьем сразу двух зайцев: с одной стороны, расскажем, как в 1С все устроено изнутри, а с другой стороны — почему это все работает не так как нужно / хотелось бы. Надо сказать, что 1С многими своими решениями смог реально нас удивить, впрочем, не будем забегать вперед.

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

Сделал подборку книг по Machine Learning для тех, кто хочет разобраться, что да как.
Добавляйте в закладки и делитесь с коллегами!

Книги по машинному обучению на русском

1. «Математические основы машинного обучения и прогнозирования» Владимир Вьюгин.

О чем

Сначала изучите азы статистической теории машинного обучения, игр с предсказаниями и прогнозирования с применением экспертной стратегии. Их основы прекрасно объясняет автор книги, доктор физико-математических наук Владимир Вьюгин. Пособие рассчитано на студентов и аспирантов и в доступной форме излагает математические основы, необходимые для дальнейшей работы с машинным обучением.

2. «Верховный алгоритм» Педро Домингос.

О чем

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

Сегодня мы публикуем четвёртую часть перевода руководства по Node.js. В этом материале мы начнём разговор об npm а также рассмотрим особенности файлов package.json и package-lock.json.

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3
Лекция 9: «Безопасность Web-приложений» Часть 1 / Часть 2 / Часть 3
Лекция 10: «Символьное выполнение» Часть 1 / Часть 2 / Часть 3
Лекция 11: «Язык программирования Ur/Web» Часть 1 / Часть 2 / Часть 3
Лекция 12: «Сетевая безопасность» Часть 1 / Часть 2 / Часть 3
Лекция 13: «Сетевые протоколы» Часть 1 / Часть 2 / Часть 3
Лекция 14: «SSL и HTTPS» Часть 1 / Часть 2 / Часть 3
Лекция 15: «Медицинское программное обеспечение» Часть 1 / Часть 2 / Часть 3

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Недавно мне довелось побывать на встрече участников проекта FreeCodeCamp в Сан-Франциско. Если кто не знает, Free Code Camp — это сообщество, нацеленное на изучение JavaScript и веб-программирования. Там один человек, который готовился к собеседованиям на позицию фронтенд-разработчика, попросил меня подсказать, какие вопросы по JavaScript стоит проработать. Я немного погуглил, но не смог найти подходящего списка вопросов, на который я бы мог дать ссылку и сказать: «Разбери эти вопросы и работа твоя». Некоторые списки были близки к тому, что мне хотелось найти, некоторые выглядели очень уж простыми, но все они были либо неполными, либо содержали вопросы, которые вряд ли кто станет задавать на реальном собеседовании.

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

Дано: собственные и аутсорс-проекты, некоторые участники работают удаленно.

Требуется: необходимо быстро назначать задачи исполнителям, планировать спринты, трекать выполнение и статусы, визуализировать процессы и делиться результатами с заказчиками.

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

Изначально сервисов было более 100, но постепенно список сокращался, и мы остановили наш выбор на трех, удовлетворяющих вместе наши нужды лучше всего: Jira, Slack и GanttPro. Но, если вдруг эти сервисы не помогут вам в планировании задач и работы с командой, делюсь с вами полным списком:

Процесс поиска очень часто усложняется тем, что все сервисы, как один, пишут «Лучший сервис, помогающий превратить ваши идеи в реальность и реализовать ваши проекты. Сегодня.». Так, а что вы делаете-то? Поэтому в этом списке без лишних эпитетов, только что какой сервис умеет. :)

Slick — это не только фамилия одной из величайших солисток всех времён, но и название популярного Scala-фреймворка для работы с базами данных. Этот фреймворк исповедует «функционально-реляционный маппинг», реализует реактивные паттерны и обладает официальной поддержкой Lightbend. Однако отзывы разработчиков о нём, прямо скажем, смешанные — многие считают его неоправданно сложным, и это отчасти обоснованно. В этой статье я поделюсь своими впечатлениями о том, на что стоит обратить внимание при его использовании начинающему Scala-разработчику, чтобы в процессе написания запросов случайно не открыть портал в ад.

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

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

«Пусть тахорги в страхе воют,
Издавая визг и писк!
Ведь на них идет войною
Структуральнейший лингвист!»

• Очень жесткий правдоруб.
• Мог бы стать физиком-теоретиком (как Ричард Фейнман, который тоже родился 11 мая), но выбрал несуществующую на тот момент профессию — программист.
• Носит имя алгоритма поиска кратчайшего пути. Алгоритм был создан при решении железячной задачи «О нахождении оптимального пути передачи электрического тока всем существенным элементам цепи, минимизируя при этом расход меди».
• Непримиримый враг goto.
• Инициатор мема Considered harmful. «GOTO Statement Considered Harmful», "„GOTO Considered Harmful“ Considered Harmful", «„«GOTO Considered Harmful» Considered Harmful“ Considered Harmful?»
• Автор концепции семафора.
• Разработчик операционной системы THE (Technische Hogeschool Eindhoven).
• Стоял у истоков структурного программирования и распределенных вычислений.
• Не написал ни одной статьи на компьютере.

В обычной жизни Э.В.Дейкстра был чудаком: предпочитал простую ручку компьютеру, в его доме не было телевизора, он не пользовался мобильным телефоном, не смотрел кино. Когда его коллеги подготовили и издали к 60-летнему юбилею специальный сборник, Дейкстра ответил каждому из них личным благодарственным письмом, написанным от руки (61 адресат). Ученому его уровня и положения полагался секретарь, но Дейкстра отказался от этой привилегии и все предпочитал делать сам. Любил музыку и был хорошим пианистом.

Под катом несколько цитат Дейкстры, пара сокращенных эссе и список статей на русском языке.

Обработка ошибок в JavaScript — дело рискованное. Если вы верите в закон Мёрфи, то прекрасно знаете: если что-то может пойти не так, именно это и случится! В этой статье мы рассмотрим подводные камни и правильные подходы в сфере обработки ошибок в JS. А напоследок поговорим об асинхронном коде и Ajax.

Я считаю, что событийная парадигма JS добавляет языку определённое богатство. Мне нравится представлять браузер в виде машины, управляемой событиями, в том числе и ошибками. По сути, ошибка — это невозникновение какого-то события, хотя кто-то с этим и не согласится. Если такое утверждение кажется вам странным, то пристегните ремни, эта поездка будет для вас необычной.

Все примеры будут рассмотрены применительно к клиентскому JavaScript. В основу повествования легли идеи, озвученные в статье «Исключительная обработка событий в JavaScript». Название можно перефразировать так: «При возникновении исключения JS проверяет наличие обработчика в стеке вызовов». Если вы незнакомы с базовыми понятиями, то рекомендую сначала прочитать ту статью. Здесь же мы будем рассматривать вопрос глубже, не ограничиваясь простыми потребностями в обработке исключений. Так что когда в следующий раз вам опять попадётся блок try...catch, то вы уже подойдёте к нему с оглядкой.

Когда-то компьютеры были женщинами, калькуляторы работали на электромоторах, вместо учебников были чертежи, а программисты выглядели вот так:


ENIAC girls

Во время второй мировой войны каждое орудие требовало собственной баллистической таблицы и рассчитывались они для каждого отдельного типа снаряда и орудия перед отправкой на фронт, и при различных комбинациях множества параметров (температура воздуха, скорость ветра, плотность почвы под орудием, возвышение ствола, скорость снаряда, температура ствола орудия). Этими вычислениями занимались 75 молоденьких девушек-выпускниц.

Одна из них, Бетти, вспоминает:

«В то время у нас были механические калькуляторы, на шестеренках и с электроприводом, которые могли выполнять простейшие арифметические операции. Вы выполняли умножение и записывали ответ, чтобы потом его заново ввести в машину. Мы готовили баллистические таблицы для каждого орудия, примерно для 1800 траекторий. Чтобы вычислить вручную одну траекторию требовалось 30-40 часов просиживания перед столом с листиком и калькулятором. Название моей профессии для баллистического проекта было „компьютер“. Идея была в том, что я не просто выполняла арифметические операции, а принимала решения, что делать на следующем шаге. ENIAC сделал меня, одну из первых „компьютеров“, устаревшей технологией.»

Просто «El clasico»

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

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

Средства массовой информации не перестают освещать тему нехватки квалифицированных программистов («программистов», «кодировщиков», «разработчиков ПО», поскольку все термины означают одно и тоже, я буду использовать из как взаимозаменяемые). Постоянно ведутся споры по поводу низкого уровня квалификации программистов. По сути мы просто не в состоянии подготовить кадры, соответствующие «солидным запросам завтрашнего дня». Вот что пишет The Telegraph:

«Согласно данным Научного Совета, к 2030 году количество специалистов в сфере информационно-коммуникационных технологий вырастет на 39%, а в отчете О2 за 2013 год отмечалось, что для удовлетворения спроса на такого рода специалистов в период до 2017 года потребуется порядка 745 000 новых сотрудников.

Кроме того, по результатам исследований, проведенных в прошлом году City & Guilds, три четверти работодателей из сферы IT, компьютерных и информационных услуг отметили явную нехватку квалифицированных кадров, в то время как 47% опрошенных заявили о неспособности действующей системы образования подготовить хороших специалистов».

Всем привет!

Мы, Денис Бесков (beskov) и Илья Поляк (ilyap1) начинаем публикацию цикла статей, посвящённых процессу проектирования веб-сервисов. Цикл построен вокруг 3-хуровневого процесса, в котором явным образом выделяются уровни анализа и проектирования:

1. Бизнеса
2. Продукта
3. Технологий

Здесь, на хабре, достаточно хорошо освещается тема проектирования на уровне технологий. Мы хотим показать взаимосвязь этого уровня, видов работ и проектных решений с вышестоящими уровнями на примере сквозного демо-кейса — проектирования веб-сервиса бронирования билетов в кино, в разработке которого участвовал пару лет назад один из авторов.

Цикл статей построен вокруг избыточной документации по проекту (требования), которую разрабатывают внутренние сотрудники компании, содержит краткое описание теоретических аспектов и помогает ответить на следующие вопросы, которые могут у вас возникнуть в работе:

1. Какими способами можно описывать требования к ПО?
2. Какие из требований к системе обязательно необходимо включать в ТЗ, а без каких можно обойтись?
3. Какие могут быть варианты при выборе форматов описания требований?
4. Как зависит выбор вида описания требований от параметров (продолжительности, рисков и др.) проекта?
5. Какого рода решения помогают принять соответствующие виды требований?

В цикле не рассматриваются аспекты заказной разработки ПО. Статья рассчитана на пользователей, которые работают в некорпортивной среде, т.е. не привязаны к каким-либо регламентам.