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

Это перевод самого недавнего поста Кевина Келли, со-основателя журнала Wired, писателя, фотографа, футуролога.

---

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

• Научитесь учиться у тех, с кем вы не согласны, или даже тех, кто вас раздражает. Нет ли истины в их убеждениях?
• Энтузиазм эквивалентен 25 баллам IQ.
• Всегда требуйте дедлайн. Дедлайн избавляет от лишнего и заурядного. Он останавливает попытки достичь совершенного, поэтому вам приходится делать необычное. Необычное лучше.

Пару недель назад я играл в A Plague Tale студии Asobo Studio (и прошёл её). Меня очень захватила эта игра, благодаря не только красивой графике, но и сюжету с локациями. Я решил немного изучить технологии, использовавшиеся при её разработке, и был удивлён, обнаружив, что игра создавалась на собственном движке относительно небольшой студии. Я знаю, что некоторые компании используют собственные движки, но очень сложно найти подробное маркетинговое исследование с подобной информацией. Поэтому я написал эту статью.

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

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

Это расшифровка выступления на DevOps-40 2020-03-18:

Начиная со второго коммита любой код становится legacy, т.к. изначальные задумки начинают расходиться с суровой реальностью. Это не хорошо и не плохо, это данность с которой сложно спорить и необходимо уживаться. Частью этого процесса является рефакторинг. Рефакторинг Infrastructure as Code. Да начнется история как отрефакторить Ansible за год и не слететь с катушек.

В детстве читал рассказ Г. Майринка с таким названием. Восточный князь организовал в европейском городке представление. По сюжету известный всей публике житель городка находится на сцене в большой бутылке. Довольно быстро он начинает делать публике какие-то знаки, махать руками. Стёкла бутылки искажают черты его лица, получается очень смешно. Публика умирает со смеха, князь сидит на бутылке. Скоро человек в бутылке падает на дно и затихает. Князь ускользает в удобный момент, публика пытается понять, что это было. Оказалось, что в бутылку не поступал воздух. Их знакомый умер. У них на глазах. Знаками пытаясь объяснить, что нечем дышать. А они все при этом покатывались со смеху.

Little did I know, что сам попаду примерно в такую же ситуацию. Будучи честным преподом, годами пытался с помощью своих статей воевать с продуктами жизнедеятельности сотен языковых школ – застрявшей в головах людей рекламной демагогией. Кричал, махал руками… Часто не хватало авторитета заставить прочитать даже людей, изучающих английский. Печально, конечно, что в 21-м веке эти вещи всё ещё приходится объяснять, а люди, часто даже неглупые, продолжают вестись на чудодейственные методики, «снять языковой барьер» и прочий английский с носителями…

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

Меж тем, именно левый график получен при помощи «честного» генератора случайных чисел. Правый график тоже содержит сплошь случайные точки; но эти точки сгенерированы так, чтобы все маленькие квадраты содержали равное количество точек.

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

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

Эта статья написана как ответ на статью «Собеседование в Додо Пиццу» со стороны разработчика с опытом синьора. Я не претендую на истинность суждений, мне хотелось бы выразить довольно популярное среди моих знакомых мнение о процессе найма в частности и жизни разработчика в целом.

Примерно 80% из нас, кто заканчивает университет с какой-либо IT-специальностью, в итоге не становится программистом. Многие устраиваются в техническую поддержку, системными администраторами, мастерами по наладке компьютерных устройств, консультантами-продавцами цифровой техники, менеджерами в it-сферу и так далее.

Эта статья как раз для таких 80%, кто только закончил университет с какой-либо IT-специальностью и уже начал мониторить вакансии, например, на должность системного администратора или его помощника, либо выездного инженера в аутсорсинговую фирму, либо в техническую поддержку 1-й/2-й линии.

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

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

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

Именно поэтому я решил собрать основные темы в одну статью и объяснить их как можно проще «на пальцах».

Дима: Читал эту статью? (Разработчики — никакая не элита, а голые короли индустрии). Что скажешь?

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

Дисклеймер

1. Несмотря на то, что есть, о чем сказать, постараюсь не превратить своё повествование в безумный лонгрид
2. Мы немного коснёмся рыночных и экономических отношений, но давайте постараемся не удариться в политическую дискуссию
3. Это моя первая статья на Хабре. Почти уверен, что совершаю “литературное” самоубийство, но хочется ответить на некоторые вопросы как минимум самому себе

Разработчики действительно УЖЕ не элита

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

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

Недавно посмотрела выступление одного scrum-мастера и stand up комика по совместительству. Выступление оказалось эмоциональное, с большим количеством непечатных слов и долей здравого смысла.

В каждой шутке только доля шутки, но все же прошу не относиться к этому материалу слишком серьезно. Предлагаю для ознакомления свое изложение в «очищенном» формате. Увидеть полное выступление Ильи Якямсева «Эффективность не работает» на конференция FrontDays 2018 можно по ссылке.

Эффективность не работает

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

Я работаю менеджером проекта. Начинал я в Тольятти, в 96 году, на должности «эй, пацан, принеси пиво». С 99 года я начал программировать front, тогда это называлось «верстак». Потом я открыл контору, закрыл ее, многое произошло, и сейчас я менеджер проектов.

Мой доклад называется «Эффективность не работает». И я объясню почему.

Жизнь после 30

Дело в том, что мне сорокет в этом году. Я работаю в основном с людьми помоложе себя, и они у меня часто спрашивают: «Илья, как она жизнь в IT после 30? Ну, то есть, что с ней происходит?». Я отшучиваюсь: как говорится, баб поменьше, детей побольше. 



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

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

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

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

Привет! Меня зовут Дмитрий Ли, я тимлид одной из команд разработки бэкенда в Badoo.

Когда я впервые стал тимлидом, я стал активно посещать конференции и читать умные книги об управлении командой. Однако в моей работе после этого менялось немногое. Я читал о том, каким я должен быть, в чём должен развиваться, но мне было неясно, что конкретно для этого нужно делать.

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

Рецепты, которыми я хочу поделиться, в большей степени пригодятся начинающим тимлидам: я записал их как своеобразное наставление себе самому несколько лет назад. Эта статья написана по мотивам моего доклада на TeamLeads Conf.

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

Несколько лет назад, когда я искал пути из программистов 1С в Java developer'ы — я бродил впотьмах, пытаясь нащупать дверь, в существовании которой был не уверен. Я пытался найти истории успеха, но кроме пары комментариев ничего не нагуглил. Мир Java выглядел огромным, а количество фрэймворков бесконечным. Было совершенно непонятно: что учить, что не учить, что нужно в работе, а что никто не использует. Если ты хочешь в Джаву, теряешься в бесконечных названиях технологий и фрэймворков и хочешь узнать какие же из них надо изучать, а на какие не обращать внимания — эта статья для тебя!

На Хабре много статей о том, как самостоятельно изучать английский язык. Но вот вопрос, а как оценить свой уровень при самостоятельном изучении? Понятно, что есть IELTS и TOEFL, но эти тесты почти никто не сдает без дополнительной подготовки и эти тесты, как говорят, оценивают не сколько уровень владения языком, а скорее умение проходить эти самые тесты. Да и использовать их для контроля самообучения будет накладно.

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

Всем привет. Я — обычный программист, носящий лычку сеньора в одной обычной продуктовой компании. Я занимаюсь коммерческой разработкой около 10 лет, начинал с разработки прошивок для небольших железок, а сейчас изготавливаю бекенды различной степени сложности преимущественно на модных нынче Java/Kotlin. Эту профессию я выбрал по призванию — будучи ещё школьником все время что-то паял, программировал на бумажке (компьютера не было) и всё такое. Дальше шли профильное образование, работа в различных компаниях — именитых и обычных, зарубежных и отечественных. Поэтому я могу сказать, что являюсь идейным программистом. И никогда не понимал людей, которые ждут пятницу — всегда с удовольствием ходил на работу, какой бы ад там не творился. Так было по-крайней мере до недавнего времени. С какого-то момента я “сломался” и с трудом мог заставить пойти себя на некогда любимую работу. Меня и раньше что-то смущало, но теперь, когда мысли до конца оформились в голове — я могу сказать, что же не так с моим некогда уютным IT-мирком.

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

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

Дерьмовое утро удалёнщика всегда начинается одинаково. Если детский плач не смог вытащить меня из кровати, то нытье жены сделает это с гарантией. Сумасшедшие девять утра, через час дейли-синк-ап, а за вчера, как всегда, сделано нихрена. Быстро варю кофе и за комп. За пять минут до созвона пулл реквест с кодом энтерпрайзного качества увесисто встал в очередь на билд. Иду курить, но по дороге телефон заорал — я зачем-то установил на него скайп, и теперь работа может добраться до меня где угодно. Курение откладывается, я готовлюсь возмущаться, что мне позвонили раньше положенного. Напялил наушники, принял вызов. Вместо привычной девушки менеджера созвон начал какой-то незнакомый мне чел. «Всем привет, Аня заболела, я буду её замещать». Окей, кому какое дело, с таким же успехом они могли бы прислать нам в качестве менеджера собаку — ничего бы не изменилось.