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

Был у меня в жизни такой опыт автоматизации, за который долгое время было стыдно. Не потому, что система плохо работала, или метаданные кривые были, или ТЗ не соответствовала — ровно наоборот. Все красиво, быстро, с полным внедрением во всей компании. С точки зрения формальных критериев это был полный успех.

Но компанию, ее культуру это внедрение превратило в ад — бюрократический, системный и бессмысленный.

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

Обо всем по порядку.

Предлагаю вашему вниманию перевод очень крутой статьи по анимации интерфейса.
The ultimate guide to proper use of animation in UX автора Taras Skytskyi.



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

Пару недель назад на проекте появилась задача генерации PDF.
Разумеется, я, как разработчик WPF UI, сразу был против сурового подхода кодирования отрисовки всех примитивов PDF в коде C#.
И заказчик был непротив покупки некоего платного конвертера из HTML в PDF, например.
Вроде бы все просто — генерируем строку с HTML-разметкой, используя DotLiquid для шаблонизации, и конвертируем в PDF с помощью одного из множества платных конвертеров.
Единственная засада — плохая совместимость HTML со страничной структурой PDF-документа.
Только я начал закапываться в поисках решения этой проблемы, как один коллега поделился ссылкой на статью с альтернативным решением.
Из статьи я узнал, что есть возможность сгенерировать PDF из XPS-документа (этот формат поддерживается в WPF FlowDocument).
К тому же, для генерации использовалась бесплатная библиотека PDFSharp.

Исходники можете скачать с GitHub.

UPD: уже не первый раз наблюдаю как статью плюсуют (первые минусы были сразу после публикации и вряд ли относятся к основному контенту), при этом сливая карму. Мне интересна мотивация, обратная связь. Отпишитесь, кто чем недоволен / доволен, если не затруднит.

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

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


Сцена из Minecraft, до и после добавления нескольких шейдеров.

Задача этого туториала

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

Озарило меня еще в колледже, когда нужно было сдать огромную исследовательскую работу сразу после ноябрьского Дня благодарения. «Без проблем, — думал я, получая задание. — Впереди еще больше двух месяцев!» Да и начиналось все отлично: я быстро выбрал тему и закончил свое исследование задолго до ноября. А потом наступила прокрастинация…



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

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

• 85% респондентов прокрастинируют, по крайней мере, иногда.
  
• Около 25% респондентов прокрастинируют часто или очень часто.
  

Относитесь ли вы к этим 85% — или даже к 25% самых заядлых прокрастинаторов? Вы в хорошей компании.

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

Переведено в Alconost

Хочу поделиться списком полезных образовательных ресурсов, среди которых каждый найдет для себя что-то интересное и новое. Главное рассмотрим в начале — IT и иностранные языки. А следом будет подборка сервисов и ютуб-каналов, связанных с наукой, образованием в целом, бизнесом и творчеством.

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

Исходный код написанного мною синтезатора доступен на GitHub'е.

Блокировки в общем и мьютексы, как их частная реализация, имеют давнюю историю неправильной оценки скорости их работы. Ещё в 1986-ом году в одной из Usenet-конференций Matthew Dillon написал: «Большинство людей ошибочно уяснили себе, что блокировки работают медленно». Сегодня, спустя многие годы, можно констатировать, что ничего не изменилось.

Действительно, блокировки могут работать медленно на некоторых платформах, или в сверх-конкурентном коде. И, если вы разрабатываете многопоточное приложение, то вполне возможно, что рано или поздно натолкнётесь на ситуацию, когда какая-нибудь одна блокировка будет съедать очень много ресурсов (скорее всего из-за ошибки в коде, приводящей к слишком частому её вызову). Но всё это частные случаи, не имеющие в общем случае отношения к утверждению «блокировки работают медленно». Как мы увидим ниже, код с блокировками может работать весьма производительно.

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

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

171 слово, которое должен понимать любой программист

Лицензия MIT – самая популярная лицензия для программ с открытым кодом. Здесь приводится одно из её прочтений, с построчным разбором.

Читаем лицензию

Если вы разрабатываете программы с открытым кодом, и не читали эту лицензию подробно – а она состоит всего из 171 слова – вам нужно этим заняться. Особенно, если вы не занимаетесь лицензиями на ежедневной основе. Отметьте всё, что вам непонятно. А я повторю все эти слова, по порядку и по кусочкам, вместе с контекстом и комментариями. При этом важно представлять себе её целиком.

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

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

Помимо статей о непосредственно программных продуктах и методах их внедрения, я также интересуюсь и другими аспектами бизнеса. Как консультант я изучил работу значительного числа компаний, которые работают в самых разных сферах. И по этому вопросу я также пишу статьи. Я изучал причины неудач, и написал статью “Как теряют бизнес”, изучал методы злоупотребления в различных компаниях, и также написал статью в помощь бизнесменам “10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы”, есть у меня и статьи, посвященные сложностям сотрудничества IT-компаний и бизнеса, например, “Посредники или почему в России всегда «виноват» исполнитель на примере IT проекта”, а также описания негативного влияния на бизнес злоупотреблением дружескими и родственными связями “Родственники и друзья в бизнесе”.

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

Перевод поста Stephen Wolfram "Who Was Ramanujan?".
Выражаю огромную благодарность Полине Сологуб за помощь в переводе и подготовке публикации

---

Содержание

Удивительное письмо
Начало истории
Кем был Харди?
Письмо и его последствия
Стиль работы Рамануджана
Видеть то, что важно
Истина или объяснение
Переход в Кембридж
Рамануджан в Кембридже
Что было дальше
Что стало с Харди?
Математика Рамануджана
Факты — случайные или нет?
Автоматизация работ Рамануджана
Современные Рамануджаны?
Что было бы, если бы у Рамануджана была Mathematica?

---

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

Удивительное письмо

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

Около 31 января 1913 года математик по имени Харди из Кембриджа, Англия, получил пакет документов с сопроводительным письмом, которое начиналось так: "Дорогой сэр, хочу представиться вам: я клерк из бухгалтерии порта в Мадрасе с зарплатой £20 в год. Мне 23 года....». И продолжал: писал о том, что достиг «поразительного» прогресса в теории расходящихся рядов по математике и решил давнишнюю проблему распределения простых чисел. Сопроводительное письмо заканчивалось словами: "Я беден; если вы решите, что здесь есть что-нибудь ценное, я хотел бы, чтобы мои теоремы были опубликованы… Я неопытен, и любые ваши советы ценны для меня. Прошу извинить меня за доставленные неудобства. Искренне ваш, с уважением, С. Рамануджан".

Предлагаю читателям перевод статьи «Why Some People Get Promoted (And Others Don’t)» за авторством Janet Coi.


Успех не линеен. Терпение и труд, конечно, всё перетрут, но сами по себе они не обеспечивают дальнейшего логического развития.

Заметьте, как часто люди, ужасно выполняющие свою работу, не теряют её, – а даже получают повышение! – пока остальные находятся в ступоре или уходят из-за того, что не могут продвинуться. Здесь имеют место несколько факторов. Даже прежние заслуги не имеют такого определяющего значения, так что все награды можно поставить на полочку.

И снова здравствуйте, уважаемые читатели.
Начатый в предыдущих трех частях разговор о форматах хранилищ NVRAM, используемых различными реализациями UEFI, подходит к своему логическому концу. Нерассмотренным остался только один формат — NVAR, который используется в прошивках на основе кодовой базы AMI Aptio. Компания AMI в свое время смогла «оседлать» практически весь рынок прошивок для десктопных и серверных материнских плат, поэтому формат NVAR оказался чуть ли не распространённее, чем оригинальный и «стандартный» VSS.
Если вам интересно, чем хорош и чем плох формат хранилища NVRAM от AMI — добро пожаловать под кат.

Медленно, но неотвратимо наступает смена решений SSO на основе SAML на решения OpenID стека. С недавних пор компания Google реализовала поддержку OpenID Connect протокола на своих серверах. Насколько он может быть приемлем для Вашего проекта и как с ним работать, оценить по спецификации протокола довольно трудно. Немного облегчить это решение должна статья одного из авторов спецификации в своём блоге, перевод которой я и предоставляю аудитории хабра. В целях упростить понимание, некоторые моменты были добавлены от себя, таким образом, чтобы не приходилось обязательно читать ссылки на используемые технологии, но ознакомится с некоторыми из них всё же я рекомендую.

Когда вы читаете спецификацию по OpenID Connect, вы можете испытывать довольно неприятные чувства от лёгкой испуганности до полнейшего разочарования. Всё это происходит потому, что они написаны на “сухом” языке спецификации, и по большей части они описывают граничные случаи, исключения и т.д. Тем не менее, когда вы переводите их на нормальный человеческий язык и переключаетесь на конкретные случаи, всё становится довольно очевидно. Итак, давайте приступим! (Ремарочка: большая часть текста совпадает с первоначальным предложением, написанным Дэвидом Рекордоном. В основном, мои правки затронули лишь некоторые из имен параметров и другие мелочи)

Здравствуйте, уважаемые читатели. Когда-то очень давно, почти 3 года назад, я написал пару статей о форматах данных, используемых в UEFI-совместимых прошивках. С тех пор в этих форматах мало что изменилось, поэтому писать про них снова я не буду. Тем не менее, в тех статьях был достаточно серьезный пробел — отсутствовали какие-либо упоминания об NVRAM и используемых для её хранения форматах, т.к. тогда разбор NVRAM мне был попросту неинтересен, ибо те же данные можно получить из UEFI Shell на работающей системе буквально одной командой dmpstore.
По прошествии трех лет выяснилось, что хранилище NVRAM умеет разваливаться по различным причинам, и чаще всего это событие приводит к «кирпичу», т.е. воспользоваться вышеупомянутой командой уже не получится, а данные (или то, что от них осталось) надо доставать. Собрав пару развалившихся NVRAM'ов вручную в Hex-редакторе, я сказал "хватит это терпеть!", добавил поддержку разбора форматов NVRAM в UEFITool NE, и решил написать цикл статей об этих форматах по горячим следам и свежей памяти.
В первой части поговорим о том, что вообще такое этот NVRAM, и рассмотрим формат VSS и его вариации. Если интересно — добро пожаловать под кат.

Продолжаем разговор о форматах NVRAM в UEFI-совместимых прошивках, начатый в первой части. На этот раз на повестке дня форматы блока Fsys из прошивок компании Apple, блока FTW из прошивок, следующих заветам проекта TianoCore, и блока FDC, который можно найти в прошивках, основанных на кодовой базе компании Insyde.
Если вам интересно, зачем нужны и как выглядят не-NVRAM данные, которые можно обнаружить рядом с NVRAM в прошивках различных производителей — добро пожаловать под кат.

Я ничего не смыслю в электронике, никогда не работала с платами и микроконтроллерами, не паяла, но посмотрев The Maker Show, я уже подумываю, а не заказать ли мне Arduino или Raspberry Pi.
Рекомендую это шоу тем, кто только начинает изучать тему Интернета вещей. Для вас я сделала обзор основных выпусков шоу.

1. Введение в электронику

Как заставить светодиод светиться с помощью лимона?

Технологический евангелист Microsoft Дэвид Крук проводит несколько экспериментов, иллюстрирующих основы электроники.

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

Исследователи обнаружили ошибку в микрокоде процессоров AMD, эксплуатация которой может позволять злоумышленникам проникать в хост-систему гипервизора из запущенной на нем виртуальной машины. Этой уязвимости подвержены компьютеры, использующие процессоры AMD Piledriver CPU (например, линейка чипов Opteron 6300) и микрокоды версий 0x6000832 и 0x6000836.

FLIF (Free Lossless Image Format) — это новый свободный формат сжатия без потери качества, который превосходит PNG, lossless WebP, lossless BPG, lossless JPEG2000 и lossless JPEG XR по степени сжатия.

Как показало сравнительное тестирование (результаты), файлы FLIF в среднем:

• на 14% меньше, чем lossless WebP,
• на 22% меньше, чем lossless BPG,
• на 33% меньше, чем PNG с брутфорсом через ZopfliPNG,
• на 43% меньше типичного PNG,
• на 46% меньше PNG, оптимизированного алгоритмом образования чересстрочного изображения Adam7,
• на 53% меньше lossless JPEG2000,
• на 74% меньше lossless JPEG XR.