TL;DR: Нет

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

Почему? Давайте разбираться.

Обратная связь в компании, как Бэтмен в Готэме. Все ждут, что она прилетит и всех спасёт, направит на путь истинный. Но иногда, судя по ощущениям, вместо Бэтмена прилетает Джокер и рушит ваш проект.



Для нас, как и для большинства современных компаний, вопрос обратной связи стоит довольно остро: когда, кому и как её правильно давать. Мы пробуем разные подходы. Недавно нашли интересный материал, которым делимся с вами. Под катом про принцип обратной связи «10/50/99», как помогать и не рушить.

---

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

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



Джон Уиллис — один из отцов DevOps. За плечами у Джона — десятки лет работы с огромным количеством компаний. В последнее время Джон стал для себя замечать специфические паттерны, которые имеют место быть в работе с каждой из них. Используя эти архетипы, Джон наставляет компании на истинный путь DevOps-трансформации. Подробнее об этих архетипах — в переводе его доклада с конференции DevOops 2018.

Релиз .NET Core 3.1 — хороший повод мигрировать свой проект с Framework на Core. Во-первых, это отполированная версия с долгосрочной поддержкой (LTS), т.е. её можно смело использовать в продакшене. Во-вторых, в третьей версии добавили поддержку WPF и WinForms, так что теперь появилась возможность мигрировать и десктопные приложения.

Мне стало интересно, какой прирост производительности можно ожидать от Core в самых базовых классах, которые максимально часто используются в коде. Например, коллекции List, Array и Dictionary.

Если вам тоже интересно, как и почему изменилась производительность основных коллекций в Core 3 — прошу под кат!

Однажды на заводе, где я работал ИТ-директором, готовили отчетность к какому-то очередному мероприятию. Надо было рассчитать и предоставить показатели по выданному перечню, среди них затесалась текучесть кадров. И тут оказалось, что у меня она равна нулю.

Из руководителей я был такой один, тем самым привлек к себе внимание. Ну и сам удивился – оказывается, когда от тебя не уходят сотрудники, это странно и необычно.

В сумме я работал руководителем лет 7-10 (точно не знаю, какие периоды сюда включать), но нулевая текучка сохранилась. Никто никогда от меня не уходил, никого никогда я не выгонял. Только набирал.

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

Disclaimer: Я высказываю свое субъективное мнение на базе доступных данных. Мнение профессиональных вирусологов и эпидемиологов может отличаться от моего. В любой непонятной ситуации обращайтесь к материалам ВОЗ.

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

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

Дальше я приведу несколько наборов слов, сгруппированных по типовым ошибкам. К каждому слову будет приложена транскрипция, приблизительная транскрипция на русском и ссылка на более детальную информацию в словаре. Так как большинство IT компаний все-таки работает с Северной Америкой, то транскрипции будут из US English.

Для проверки текстовых полей на валидность обычно используют регулярные выражения. Существует несколько наиболе распространенных видов таких даных, как например номер кредитки, дата в определенном формате и т. д. На сайте html5pattern.com собирается коллекция регулярных выражений для таких данных (там это позиционируется, как возможное содержимое html5-атрибута pattern у inpit-элементов, но эти регулярные выражения можно использовать и для привычной валидации с помощью javascript). Актуальные для российской аудитории примеры, вместе с соответствующими регулярными выражениями вы можете посмотреть под катом.

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

А недавно ко мне подошли коллеги и спросили “Ты понимаешь как работает квантовый компьютер? Можешь нам рассказать?” И тут я понял, что проблема со складыванием в голове целостной картинки есть не только у меня.

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

Писать ответы на статьи легко и приятно. Не надо часами корпеть над структурой статьи, достаточно следовать чужому плану и лишь внятно изложить мысли на бумаге. Тем не менее, рискну предположить, что критический взгляд «с другой стороны» на проблемы, поднятые в статье "Страх и ненависть в IT" уважаемым eugene_crabs, все же будет интересен. В роли адвоката дьявола, защищающего бесчеловечную системы выступаю сегодня я.



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

В конце статьи, по традиции, есть краткое содержание.

Вы читаете книги по саморазвитию, бизнесу или повышению эффективности? Нет? Прекрасно. И не начинайте.

Всё-таки читаете? Не делайте того, что в этих книгах предлагается. Пожалуйста. Иначе станете наркоманом. Как я.

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

Предлагаю вашему вниманию перевод статьи "Too Clean?" автора Robert C. Martin (Uncle Bob).



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

Глава 2. Марсианская мечта

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

В прошлый раз мы остановились на том феномене, что игра, которая изначально задумывалась как кооператив (например, D&D или многопользовательская песочница типа Space Station 13), почему-то может использоваться игроками совершенно по другому назначению, становясь пространством насилия и травли. Сегодня, соответственно, будем разбираться в том, как устроена детская (и не только детская) агрессия, как работает формат песочницы, что делает агрессия в песочнице (и вообще в игре) и как можно ей управлять.

Физика эмоции

В дальнейшем изложении мы будем использовать гидродинамическую модель эмоции. Представим себе, что, например, гнев – это жидкость. Чем больше накапливается гнева, тем сильнее становится напор жидкости в трубе – отдельно взятом индивидууме. На выходе есть два вентиля. Один соответствует внутреннему тормозу – представлению, например, о том, что обижать других людей дурно, некрасиво, недостойно… Второй соответствует внешнему тормозу – страху перед наказанием или какими-то другими негативными последствиями. Что будет, если давление жидкости нарастает, а вентили (хотя бы какой-то один из них) намертво закручены?

Недавно я прочёл запись в блоге одного парня, который жаловался, что на интервью его попросили написать функцию, которая должна скопировать файл. Нет, я понимаю, как можно взъесться на такое задание, но если бы в подобной ситуации оказался я… уж я бы оторвался по полной:

---

Кандидат: Что конкретно Вы имеете в виду, говоря «скопировать»?
Интервьюер: Ну… создать новый файл, содержимое которого является копией содержимого исходного файла.

Эванс написал хорошую книжку с хорошими идеями. Но этим идеям не хватает методологической основы. Опытным разработчикам и архитекторам на интуитивном уровне понятно, что надо быть как можно ближе к предметной области заказчика, что с заказчиком надо разговаривать. Но не понятно как оценить проект на соответствие Ubiquitous Language и реального языка заказчика? Как понять, что домен разделен на Bounded Context правильно? Как вообще определить используется DDD в проекте или нет?

Последний пункт особенно актуален. На одном из своих выступлений Грег Янг попросил поднять руки тех, кто практиукует DDD. А потом попросил опустить тех, кто создает классы с набором публичных геттеров и сеттеров, располагает логику в «сервисах» и «хелперах» и называет это DDD. По залу прошел смешок:)

Как же правильно структурировать бизнес-логику в DDD-стиле? Где хранить «поведение»: в сервисах, сущностях, extension-методах или везде по чуть-чуть? В статье я расскажу о том, как проектирую предметную область и какими правилами пользуюсь.

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

А еще там разбирается характер персонажей на примере сторонников теории плоской Земли.


Сценарий фильма «Апокалипсис сегодня» (1979) по мотивам книги Джозефа Конрада «Сердце тьмы» (1899)

Алгоритм Wave Function Collapse генерирует битовые изображения, локально подобные входному битовому изображению.

Локальное подобие означает, что

• (C1) Каждый паттерн NxN пикселей в выходных данных должен хотя бы раз встречаться во входных данных.
• (Слабое условие C2) Распределение паттернов NxN во входных данных должно быть подобным распределению паттернов NxN в значительно большом количестве наборов выходных данных. Другими словами, вероятность встречи определённого паттерна в выходных данных должна быть близка к плотности таких паттернов во входных данных.

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.
Вторая часть доступна здесь

Необходимость делать что-то асинхронно, не дожидаясь результат здесь и сейчас, или разделять большую работу между несколькими выполняющими ее единицами была и до появления компьютеров. С их появлением такая необходимость стала очень ощутимой. Сейчас, в 2019, набирая эту статью на ноутбуке с 8 ядерным процессором Intel Core, на котором параллельно этому работает не одна сотня процессов, а потоков и того больше. Рядом, лежит уже немного потрепанный, купленный пару лет назад телефон, у него на борту 8 ядерный процессор. На тематических ресурсах полно статей и видео, где их авторы восхищаются флагманскими смартфонами этого года куда ставят 16ти-ядерные процессоры. MS Azure предоставляет менее чем за 20$/час виртуальную машину со 128 ядерным процессором и 2 TB RAM. К сожалению невозможно извлечь максимум и обуздать эту мощь не умея управлять взаимодействием потоков.

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

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

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

1. Структура и схема.
2. Представление и доступность.
3. Выбор используемых графиков.
4. Усовершенствование контекста.

Часть 1. Структура и схема

Давайте для начала остановимся и зададим себе два вопроса: кто наша целевая аудитория и каковы её цели?

Знание своей целевой аудитории и её задач критически важно для остальной части работы. Если ваша ЦА — руководители разработки, которым нужно знать высокоуровневую информацию о функционировании системы, то нужные им данные будут сильно отличаться от тех, которые необходимы приходящему инженеру.

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