Я написал своё первое одностраничное веб-приложение на Javascript в 2005 году, сразу после того, как узнал о XMLHttpRequest и до появления серьёзных фреймворков. Я оставил профессиональную веб-разработку примерно в 2009 году (а начал её в 1997 году с WebObjects), а последний десяток лет своей карьеры занимался мобильными.

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

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

Во многих мошеннических схемах используется очень простая и действенная идея: когда человек вкладывается во что-то, это что-то обретает для него ценность, даже если по факту это пустышка. Например, всякие фейковые опросы, где человек тратит 2 часа времени, чтобы ответить на 500 вопросов, потом в личный кабинет падает 300кк рублей, но нужно заплатить 500р "комиссии" за вывод средств. Никто никогда бы не поверил в эту чушь, но когда потрачено 2 часа и кажется, что от награды отделяет самая малость... Или же человек играет в покер и проиграл уже все деньги, дом и кота, но нужно продолжать, потому что "столько проиграно, нужно отыграть".

Вчера я чуть не попался на это. Не на мошенничество, нет - я чуть не попал в упомянутую психологическую ловушку "слишком много вложил, чтобы бросить", которую сам себе и построил. Но моя история совсем не уникальна, поэтому помимо неё я собрал тут коллекцию историй и применил ORDER BY scale ASC, чтобы вы оценили: эта ловушка живёт на всех масштабах - от маленьких сиюминутных решений до целых жизней.

Когда я был маленький, то на меня снизошла милость божЫя и ниспослала мне две книжки. Одна книжка была про бейсик для студентов каких-то там ВУЗов, а вторая - «Паскаль в иллюстрациях». По одному из абзацев первой книжки я в принципе научился программировать в пятом классе - там был мозголомающий отрывок с программой, заставляющей нолик летать по экрану, отталкиваясь от стенок. Вторая книжка, отданная мне соседом-алкашом, познакомила с алгоритмами. На дворе стояли 90-е — начало компьютерной эры человечества. Компьютера у меня при этом не было — я видел его пару раз в неделю на компьютерном кружке, ведущей которого была вчерашняя или даже сегодняшняя студентка, отпирающая и запирающая дверь — большего от неё нам и не требовалось.

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

Только на этой неделе бахнули два громких скандала, связанных с отмыванием денег: досталось и швейцарцам из Credit Suisse, и незадачливому крипто-хакеру из России, закрысившему $4,5 миллиарда. В этой статье разбираем нюансы превращения грязных денег в чистые, а также кекаем над теми, у кого это получилось не очень!

v-agent ориентированное программирование (VAOP) - это методология программирования, основанная на представлении алгоритма в виде v-agent script, который позволяет программному агенту, получившему название v-agent, выполнять операции закодированные в модулях v-agent box.

Идеологически v-agent ориентированное программирование - добивается того, чтобы алгоритм был записан в одном месте в виде, понятном всем - заказчикам, программистам и исполняющей среде (компьютеру), что улучшает процесс взаимодействия всех при создания программного продукта и, что особенно важно, существенно снижает затраты на этапе поддержания работы и адаптации к изменению внешних условий в Будущем.

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

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

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

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

В этой статье я хочу описать (часть) моего опыта взаимодействия со структурой, именуемой в дальнейшем «яндекс», с точки зрения работника. Опишу собеседования и этап «входа».

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

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

Позвольте мне выразить эту мысль более кратко:

мейнтейнер > автор

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

Первые два года

Вот один из карьерных путей в разработке ПО:

1. Проведите несколько первых лет в небольшой компании, не понимающей технологий. Теперь вы единственный программист или один из немногих.

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

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

4. Освойтесь в устранении неполадок и в возврате системы в строй. Получите несколько повышений в зарплате и должности, пока в ней не появится слово «Senior»; скорее всего, это произойдёт не позже чем спустя три года после того, как вы начнёте устранять неполадки системы.

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

6. Каждые несколько лет получайте ещё одно повышение и красивое дополнение к названию должности.

Предисловие Около года назад я задался целью получить оффер от FAANG. Как следствие, постоянной частью моей жизни стали тематические форумы, площадки и вся сопутствующая атрибутика. Спустя какое-то время я попробовал себя на собеседованиях в околоFAANGoвые компании: Lyft, Spotify, Booking и т. д, где-то успешно, где-то не очень. В это же время мне порекомендовали попробовать пройти собеседование в Тинькофф банк, который внедрил схожий процесс. После стандартного общения с HR менеджером была получена ссылка на описание процесса собеседования. “Хм, почти что FAANG + тех. интервью по Primary Skill”, - подумал я и сказал, что готов приступать. В тот же час было назначено 2 интервью: техническое и coding, а вот 3 этап, system design, нужно было заслужить успешным прохождением первых двух. Почему именно эти 2 части являлись основополагающими, осталось неясным.

Акт первый, технический

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

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

Для меня, как человека, который верил в то, что учебное заведение призвано ОБУЧАТЬ, это было, мягко говоря, шоком.

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

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

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

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

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

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

Я берусь доказать, что основной тезис ошибочен. В РФ нет дефицита кадров. 

Со всех сторон интернета слышу: персонала нет на рынке труда, людей в целом мало — не рождаются, умирают, мол, демографическая яма, работать некому, и всё в таком духе. Кадровый голод в промышленности достиг нового рекорда. Дефицит кадров испытывают 42% предприятий, показал июльский опрос Института Гайдара. На момент предыдущего опроса в апреле о нехватке работников заявляли 35% компаний.А теперь главный вопрос — это физически людей не хватает или просто на ту зарплату, что предлагают, никто не хочет идти?

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

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

Сегодня я расскажу о замечательном инструменте под названием GOST. Не пугайтесь, он не имеет никакого отношения к ГОСТ-шифрованию или чему-то подобному, на самом деле это Go Simple Tunnel. Он действительно simple (простой) в использовании и настройке, но при этом невероятно мощный, поскольку поддерживает огромное количество протоколов и транспортов, из которых вы при желании сможете построить самые упоротые и бронебойные комбинации, а именно...