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

Эта статья является продолжением материала "Дефицита нет, платить не нужно".

Этот текст я пишу из лучших побуждений, безо всякой иронии, снобизма и насмешки. Хочу сберечь время и нервы тем, кто поддался на «войти в айти» и прямо сейчас учится сортировать массивы, парсить строки и верит в «да-да, этим ты и будешь заниматься на работе».

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

Я опишу типичные ошибки тех, кто не выжил. И, соответственно, не вошёл в ИТ. Всё из опыта личных наблюдений.

Да, если «тут всё неправда», «а вот мой друг Коля успешно…» или «а у меня получилось» - прекрасно, текст не про вас и не для вас. Вы и ваш друг Коля – выжившие.

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

Современное коммьюнити больного человека - это когда голддиггеры из Индии, вайтишники из СНГ, карьеристы-неудачники из стран золотого миллиарда, а также просто любители потусоваться собираются в одном месте. Что из этого получается? Да вы не хуже меня знаете. Но давайте повторим перед школой.

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

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

Всем привет, на связи MediaMetriqa, и сегодня мы поговорим о, наверное, самой хайповой теме в крипте в последние месяцы. Арбитраж.

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

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

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

Сегодня мы займёмся распаковкой данной ниши. Посмотрим, что находится внутри этих самых курсов и "продуктов" тех, кто называют себя лидерами этого рынка, объясним, что такое P2P-арбитраж, откуда образуется разница ценности активов, какие существуют подводные камни со стороны банков, налоговой и государства, из чего состоит рабочая связка и многое другое, о чём арбитражники в своих прогревах молчат. Поехали!

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

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

Он много чего наплёл, но одна тема меня прям сильно заинтересовала – обучение программистов, которое парень превратил в какой-то бешеный бурлящий поток. Я выпытал всё, что смог, и спешу рассказать вам.

Да, всё как всегда у того парня – не на десятки процентов, а в разы.

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

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

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

Привет! 

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

Не забываем, чтобы работать по Agile, в первую очередь важно придерживаться Agile-манифеста и его ценностей. Не достаточно просто работать в таск-трекерах и применять Kanban и Scrum.

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

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

В первую очередь нужно сказать пару слов про Agile. 

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

Есть разные методики управления проектом: Kanban и Scrum. 

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

В ходе пентеста веб-приложений специалист по тестированию на проникновение достаточно часто сталкивается с необходимостью тестировать API. Как правило это REST API, про тестирование которого написано уже много. Однако все чаще и чаще встречается API на основе GraphQL.

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

Привет! Это Анна из click.ru с очередным рассказом на тему личной (не)эффективности. Когда я впервые услышала про когнитивные искажения, я усмехнулась: «Ну, я-то мыслю рационально, в отличие от Васи, который делает из всего катастрофу». Наступил 2022-й, и однажды, после очередного приступа под девизом «Всё пропало!», я внезапно почувствовала духовное родство с Васей...

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

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

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

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

Итак, что бы кто сейчас ностальгически не утверждал, в реальности СССР (да и досоветская Россия тоже) по технологической культуре отставал от передовых стран мира кардинально. Дело в том, что ни в царской ни в советской России не умели создавать ТЕХНОЛОГИИ, а подавляющее большинство технологий, используемых в России на всех исторических этапах её существования были иностранными копиями. А поскольку самой школы создания собственных технологий в России так и не возникло, то отсутствовала методология передачи технологических знаний. Вернее, то, что за такую методологию выдавалось, было очень плохой копией оригинальной методологии. Те, кто в теме науки и техники, согласятся со мной, что советские и российские тематические учебники предназначены для чего угодно, но только не для передачи практического знания. Причина проста, на мой взгляд, в отечественной технической литературе отсутствует чёткая иерархия знания. Вместо этого знания подаются, как некая куча слабо связанных между собой фактов. Историческая привязка знаний тоже отсутствует (отчасти из за того, что бы не педалировать заслуги иностранных учёных и инженеров, которые обычно подавляющие). Ещё хуже в СССР обстояли дела с т.н. "инструкциями по эксплуатации" выпускаемых приборов, производственных линий и прочего. Эти "произведения" вообще никуда не годились, кроме как для сдачи в макулатуру. Что в результате? А то, что российский технический специалист часто работает на высокотехнологичном производстве методом проб и ошибок (ещё это называется "метод научного тыка"), и методом "ничего тут не трогайте, так как потом никто не сможет наладить!" В результате значительные вложения (материальные и просто человеческие) советского индустриального скачка были потрачены в большой мере впустую, так как после превращения в металлолом не оставили после себя научно-технологического задела вообще.

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

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

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

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

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

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

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

Сегодня я расскажу о пластичности нашего мозга, почему и какая настройка ему нужна. А в продолжении — какими техниками можно настроить себя на нужное состояние. Видео моего выступления на конференции DevOps Live 2020 можно посмотреть здесь.

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

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