Жил был моряк. У него было две любимых женщины в разных портах, и он хотел детей – вот только не решил, одного или двух. Он решил кинуть монету. Орел – будет один ребенок от одной из женщин (к которой первой зайдет в порт по работе – это уж как получится), решка – сделает по ребенку каждой женщине. Неизвестно, как выпала монета, и как его бросала судьба по миру, но вы – его ребенок. Какова вероятность, что вы – его единственный ребенок?

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

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

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

Как с этим жить — чтобы оставалось время на жизнь вне работы? И можно ли применить какие-то рабочие алгоритмы менеджмента в повседневной, бытовой жизни? 3 месяца назад я кардинальным образом поменял всю систему постановки задач и контроля за ними. Хочу рассказать, как я к этому пришёл и что в итоге получилось. Пьеса будет в 2 частях: в первой — немножко про, если так можно выразиться, идеологию. А вторая — целиком про практику.

Жил на свете такой человек – Стивен Кови. Однажды он решил написать книгу о личной эффективности. Теперь эту книгу знают все, она называется «Семь навыков высокоэффективных людей». Она считается классикой, постоянно переиздается во всех мыслимых странах мира, за годы существования продано несколько десятков миллионов экземпляров. Сам Стивен Кови настолько разобрался в личной эффективности, что его личными консультациями не преминули воспользоваться несколько президентов, в т.ч. США.

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

Но я не про книгу хочу поговорить, а про неожиданное открытие, которое сделал Стивен Кови, когда ее писал. Он это явление назвал «социальный аспирин».

Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.

После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.

Оценка сроков в 95 % случаев. Спасибо, xkcd.

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

Сейчас объясню, как это работает.

Пост-ответ на статью "Иди-ка ты на !@# со своей "токсичностью"".

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

Однако это не помогло бы донести мою мысль. Поэтому давайте разберем поподробнее.

Всем привет! Меня зовут Анатолий Панов, я работаю в ИТ уже больше 15 лет. За это время прошел путь от разработчика до руководителя тимлидов. Работал в таких компаниях как Badoo, Lazada. С начала этого года я в Авито. Руковожу разработкой новых проектов и разработкой для вертикалей Авто и Недвижимость.

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

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

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

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

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

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

Самое большое препятствие улучшения образования для детей (с компьютерами или без них) — это совершенно обедневшее воображение большинства взрослых.
— Алан Кей

Откопал статью Алана Кея 2009 года. Содержание — бомба и напалм, особенно на фоне большинства сегодняшних ИБД в области образования.

Вопрос: Вы часто говорите, что компьютерная революция еще не произошла. Что вы имеете в виду?

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

Большинство школ определяют компьютерную грамотность как умение использовать Microsoft Office и, возможно, немного заниматься веб-дизайном. Они упускают суть. Это все равно что сказать: «Если вы знаете, за какой конец книги нужно держаться, и вы знаете, как перейти к третьей главе, тогда вы грамотны».

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

«Божественный» код — громкий термин, который может показаться желтым заголовком, но всё же именно о таком коде будет идти речь: из каких частей он состоит и как его писать. Это история о моих стараниях сделать так, чтобы задачи не возвращались с code review с пометкой: «Всё хе*ня — переделать».

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

Техника из Китая миллионами посылок разлетается по миру, Xiaomi волнует всех: от диванных до ведущих аналитиков, DJI рвёт рынок новинками. Потрясающе! Но это всего лишь потребительский восторг. За всеми этими гаджетами стоит огромная, трагическая, яркая история огромной страны и её народа. В этой истории всё: от лидерства до падения и смерти науки, от дешёвых имитаций до самых передовых инноваций. И эту историю нужно знать, хотя бы вкратце — может быть, просто для того, чтобы она не повторилась. Пройдёмся сквозь время?

Представляем вторую часть цикла, посвященного типичным уязвимостям, атакам и проблемным местам, присущим смарт-контрактам на языке Solidity, и платформе Ethereum в целом. Здесь поговорим о некоторых особенностях EVM и о том, какими уязвимостями они могут обернуться.

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

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

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "A Deeper Look at Different Smart Contract Platforms".

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

В этой статье мы рассмотрим одну из новых платформам смарт-контрактов Cardano и посмотрим, в чем ее отличие.

Прежде чем мы это сделаем, давайте зададим себе вопрос.

Что такое смарт-контракты?

Смарт-контракты автоматизированные контракты. Они самоисполняются с конкретными инструкциями, написанными на языке программирования, которые выполняются при выполнении определенных условий.

Если вы прочитаете документацию по PHP, вы узнаете о массе операторов. Если вы не знаете ещё PHP-операторы, сперва изучите их, а потом вернитесь к прочтению этой статьи.

Только ленивый сейчас не думает о том, как бы выйти со своей идеей на ICO, и оказаться на гребне волны с такими успешными проектами как Tezos, Bancor, SONM и др. Судя по рассказам и статьям, все должно быть очень просто — как по взмаху волшебной палочки, после того, как Вы озвучиваете свою идею, к Вам слетаются инвесторы со всего мира, чтобы дать денег на реализацию Вашего гениального плана. Если смотреть издалека, без очков (наличие близорукости в данной ситуации обязательно) и не учитывать тонну работы и бессонные ночи, то в предыдущем предложении напрягает лишь одно слово “озвучиваете”. После того, как Вы произнесли в голове это слово, мозг тут же начал анализировать и задавать вопросы — где, кому, когда (конечно, мы исходим из того, что ЧТО озвучивать у вас уже есть). Так вот, за месяц до пресейла (который показался нам мгновением), к нам наконец-то пришло осознание того, что у нас есть идея, есть ее изложение в презентации, даже написан приличный White Paper, но некому это показывать…

Добрый день.

Представляю на суд общественности материал о том, как я за четыре месяца получил визу, переехал в Германию и нашел там работу.

Считается, что для переезда в другую страну нужно сначала долго искать работу удаленно, потом, в случае успеха, ждать решения по визе, и лишь после паковать чемоданы. Я решил, что это далеко не оптимальный способ, поэтому пошел другим путем. Вместо того, чтобы искать работу удаленно, я получил так называемую «визу на поиск работы», въехал в Германию, нашел здесь работу и уже после подал документы на Blaue Karte. Во-первых, в этом случае документы не ездят из страны в страну, и время ожидания визы значительно уменьшается. Во-вторых, поиск работы на месте радикально повышает ваши шансы, и это тоже заметно ускоряет процесс.

UPDATE 2018-02-04: Еще одна мудрость со временем накипела: если хочется полной свободы выбора компаний любого размера, то лучше сразу говорить, что вы нашли хорошую компанию по релокейту и всё, что требуется, это финансовая поддержка. Деньги тут есть (особенно у страртапов), а времени — нет.

UPDATE 2017-03-19: По опыту двоих приятелей из Берлина (из России и Коста-Рики) могу обнадёжить, голубую карту могут сначала не дать, а через полгода таки дать прямо в Германии. Немцы тоже люди и их чиновники тоже умеют и искренне заблуждаться, и нарочно упираться.

UPDATE 2017-01-08: год спустя поимел опыт поиска и найма фронтендеров для двух компаний. Заявляю, что хорошего кандидата, подписавшего договор, готовы ждать месяц-два. Меня один средних размеров стартап согласился ждать 4 месяца после очного интервью. Так что заехать себя показать, а потом начать удаленно и через пару месяцев перебраться — вообще шоколад.

UPDATE 2016-09-02: полгода спустя немного подросла нижняя планка з/п для голубой карты, а остальное пока в силе.

UPDATE: по просьбе chilicoder добавляю ремарку: «автор смог переехать и найти работу даже без признанного диплома».

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

Наш мозг — удивительная система, которая постоянно показывает занятные фокусы. Знаком ли вам эффект «красной машины»? Человек покупает красную машину и вдруг начинает все время видеть на улице красные машины. Такое искажение называется «иллюзия частоты» или «феномен Баадера-Майнхоф» и происходит из-за селективного внимания мозга и склонности всегда подтверждать свою точку зрения (confirmation bias). 

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

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