Все, что написано про права, строится на том самом ложном допущении, что продается "твит", а не "NFT со скриншотом твита". Поэтому эти рассуждения не имеют никакого смысла.
NFT не плох и не хорош, это просто токен. Все зависит от того, как и для чего его использовать. В покупке/продаже коллекционных NFT смысла не больше и не меньше, чем в покупке/продаже марок – там тоже никакой художественной ценности, как правило, нет, и стоимость ее искусственная на 100%. Только NFT проще верифицировать (опять же, надо понимать что проще верифицировать сам NFT, а не тот контент, на который указывает ссылка).
То, что тут много мошенников, охотников за халявой, любителей легкой наживы – это ж не вина NFT, как будто в том же самом коллекционировании марок подобных товарищей мало. Но NFTи все, что с ним связано, еще слишком молодо, и люди разбираются в этом отвратительно. Проблема в том, что люди делятся как минимум на 2 категории – "я в этом не разбираюсь, поэтому деньги вкладывать не буду" и "я в этом не разбираюсь, но все говорят, надо брать, поэтому потрачу последние деньги".
Ну и спекуляций на картинках с сомнительной художественной ценностью область применения NFT не ограничивается.
например, теперь уже печально известную «Солану».
Если вы про скандал с утекшими деньгами с тысяч кошельков, то вины Соланы в этом нет – там разработчики одного конкретного криптокошелька плейнтекстом отправляли и хранили сид-фразу от кошельков пользователей.
Это говорит о том, что клиент совершал операции не в целях конвертации валюты для личного использования, а в целях получения прибыли и неосновательного обогащения
то получается, что все зависит от того, ограничена ли законом или договором цель обмена валюты. Если нет, то ошибка банка – это проблема банка. Если "получать прибыль" нельзя, то, скорее всего, заставят вернуть.
Я имел в виду адаптирование большого монстра hh к новому фреймворку
Ну тогда это "адаптация hh под jetpack compose". Но звучит все равно так себе.
приспособление Compose-а внутри нашего приложения
Ну вот после такого заголовка я и ожидал, что вы сам Compose будете как-то "адаптировать". Вы же его совершенно не изменяли, о какой адаптации может идти речь? В общем, выбор слова выглядит неудачным и неподходящим.
Но вообще нормальная позиция должна идти от обратного - компания решила нанимать джунов как долговременную инвестицию, ибо не может позволить себе нанимать нормальных миддлов в команду.
Имхо, это как раз ненормальная позиция. Если компания не может себе позволить нанимать нормальных миддлов, то она тем более не потянет нанимать и растить джунов.
Из моего опыта, если завязываться на долгосрочную перспективу, схема должна быть такой: на старте компания берет только сеньоров, чем больше вырастает, тем менее опытных людей может себе позволить.
Я, разумеется, говорю про ситуацию, когда работа идет над более или менее сложным продуктом, и целью является написание и долгосрочное его сопровождение. Компаний с политикой "денег нет, наймем одного джуна и пусть он будет фуллстэком, а там разберемся" я стараюсь избегать.
У флаттера для веба весьма ограниченный юзкейс – по крайней мере, пока. Он не для "сайтов", он для "приложений". Упрощенно говоря, если у вас не PWA, то Flutter for Web вам, скорее всего, не подойдет.
Эту книгу стоит прочитать хотя бы ради альтернативного взгляда на "состояние потока", в которое так стремятся впасть многие разработчики. Мне было приятно узнать, что не я один считаю это состояние скорее вредным.
Тестовое задание - это дешевый и неэффективный HR инструмент, по сравнению с большинством применяемых на рынке.
Если правильно готовить, тестовое задание – это прекрасный инструмент для обеих сторон.
Для нанимателя:
посмотреть на живой код кандидата (как минимум, что он в принципе умеет что-то писать вменяемое; как максимум – какие библиотеки и архитектурные подходы он применяет). Приходили ко мне кандидаты на сеньорскую позицию с тестовым заданием, которое просто не работало. Я не хочу работать с людьми, которые даже не проверяют работоспособность своего кода;
увидеть, как он реагирует на критику в code review (ведь вы же делаете code review и в реальной работе?);
на следующем созвоне обсудить разные подходы на конкретном примере / коде.
Для кандидата:
получить фидбэк на реальный код (особенно актуально для джунов);
посмотреть, что обычно проверяют в компании на code review;
оценить, собственно, вменяемость этих code review (если вам завернут тестовое с формулировкой "у вас запятые неправильно расставлены", то надо радоваться, что вы сэкономили себе время и не устроились туда работать);
на следующем созвоне обсудить разные подходы на конкретном примере / коде.
Как я уже писал, для этого не нужно сложное задание, и для этого даже не обязательно свое тестовое, если у кандидата есть свой проект или другое тестовое, то можно отталкиваться от него.
Неудачный у вас опыт, видимо. Я, например, даю тестовое задание и прекрасно знаю, какой должен быть результат. Только его не надо угадывать – мне важно посмотреть, как человек пишет и мыслит, какие допускает (или не допускает) ошибки.
Тестовое задание у нас довольно простое, только люди с разным опытом и выполняют его по-разному.
При этом, если у кандидата есть что показать (личный проект, другое тестовое), я никогда не настаиваю, чтобы он выполнил именно наше задание. Да, для меня это означает больше работы, поскольку мне надо будет вникать в незнакомый проект, но я готов на это пойти.
Кроме того, мы всегда даем обратную связь по итогам задания (по сути, делаем код ревью с созвоном после проверки, если кандидату это интересно).
Все, что написано про права, строится на том самом ложном допущении, что продается "твит", а не "NFT со скриншотом твита". Поэтому эти рассуждения не имеют никакого смысла.
NFT не плох и не хорош, это просто токен. Все зависит от того, как и для чего его использовать. В покупке/продаже коллекционных NFT смысла не больше и не меньше, чем в покупке/продаже марок – там тоже никакой художественной ценности, как правило, нет, и стоимость ее искусственная на 100%. Только NFT проще верифицировать (опять же, надо понимать что проще верифицировать сам NFT, а не тот контент, на который указывает ссылка).
То, что тут много мошенников, охотников за халявой, любителей легкой наживы – это ж не вина NFT, как будто в том же самом коллекционировании марок подобных товарищей мало. Но NFTи все, что с ним связано, еще слишком молодо, и люди разбираются в этом отвратительно. Проблема в том, что люди делятся как минимум на 2 категории – "я в этом не разбираюсь, поэтому деньги вкладывать не буду" и "я в этом не разбираюсь, но все говорят, надо брать, поэтому потрачу последние деньги".
Ну и спекуляций на картинках с сомнительной художественной ценностью область применения NFT не ограничивается.
Если вы про скандал с утекшими деньгами с тысяч кошельков, то вины Соланы в этом нет – там разработчики одного конкретного криптокошелька плейнтекстом отправляли и хранили сид-фразу от кошельков пользователей.
Ну так правильно, это же получается работа инструктором автошколы (только там еще ограничения по скорости и дорогам есть).
Ну там вполне может быть конкретный пункт про обмен валюты, à la "клиент обязуется не использовать банк как биржу и не заниматься спекуляцией".
Если у них позиция строится на
то получается, что все зависит от того, ограничена ли законом или договором цель обмена валюты. Если нет, то ошибка банка – это проблема банка. Если "получать прибыль" нельзя, то, скорее всего, заставят вернуть.
А сколько можно сэкономить, если вообще все репозитории удалить...
Ну тогда это "адаптация hh под jetpack compose". Но звучит все равно так себе.
Ну вот после такого заголовка я и ожидал, что вы сам Compose будете как-то "адаптировать". Вы же его совершенно не изменяли, о какой адаптации может идти речь? В общем, выбор слова выглядит неудачным и неподходящим.
Так а при чем тут адаптация? Может, все-таки интеграция?
Имхо, это как раз ненормальная позиция. Если компания не может себе позволить нанимать нормальных миддлов, то она тем более не потянет нанимать и растить джунов.
Из моего опыта, если завязываться на долгосрочную перспективу, схема должна быть такой: на старте компания берет только сеньоров, чем больше вырастает, тем менее опытных людей может себе позволить.
Я, разумеется, говорю про ситуацию, когда работа идет над более или менее сложным продуктом, и целью является написание и долгосрочное его сопровождение. Компаний с политикой "денег нет, наймем одного джуна и пусть он будет фуллстэком, а там разберемся" я стараюсь избегать.
У флаттера для веба весьма ограниченный юзкейс – по крайней мере, пока. Он не для "сайтов", он для "приложений". Упрощенно говоря, если у вас не PWA, то Flutter for Web вам, скорее всего, не подойдет.
Состояние потока контрпродуктивно; несмотря на то, что кода в таком состоянии можно написать больше, далеко не факт, что он будет лучше.
Это, по сути, такое мини сужение сознания, общая картина воспринимается и анализируется гораздо хуже.
Для каких-то задач (где не надо думать) ничего плохого в ней нет, но для чего-то выходящего за рамки конвейерной работы я ее не рекомендую.
Эту книгу стоит прочитать хотя бы ради альтернативного взгляда на "состояние потока", в которое так стремятся впасть многие разработчики. Мне было приятно узнать, что не я один считаю это состояние скорее вредным.
С чего это вдруг оно единственное? Выше уже привели рабочие решения:
не ломать семантику GET-запроса и использовать POST для подобных действий;
проверять User Agent.
И оба этих решения лучше, чем костылить JS, который:
Не будет работать у пользователя, если у него отключен JS.
Не факт, что остановит бота. Бот вполне себе может поддерживать JS.
Так для нерегулярных программистов есть помесячная оплата.
Вот именно поэтому (в том числе) GET-запрос не должен ничего изменять.
Оверинжиниринг – это беда миддлов.
Т.е. по вашему, все люди с > 7 годами опыта в одном "направлении трудовой деятельности" находятся в застое?
Да, действительно, забыл дописать еще одно преимущество: "Позволяют быстро отсеять кандидатов, для которых тестовое задание – это плевок им в лицо".
Если правильно готовить, тестовое задание – это прекрасный инструмент для обеих сторон.
Для нанимателя:
посмотреть на живой код кандидата (как минимум, что он в принципе умеет что-то писать вменяемое; как максимум – какие библиотеки и архитектурные подходы он применяет). Приходили ко мне кандидаты на сеньорскую позицию с тестовым заданием, которое просто не работало. Я не хочу работать с людьми, которые даже не проверяют работоспособность своего кода;
увидеть, как он реагирует на критику в code review (ведь вы же делаете code review и в реальной работе?);
на следующем созвоне обсудить разные подходы на конкретном примере / коде.
Для кандидата:
получить фидбэк на реальный код (особенно актуально для джунов);
посмотреть, что обычно проверяют в компании на code review;
оценить, собственно, вменяемость этих code review (если вам завернут тестовое с формулировкой "у вас запятые неправильно расставлены", то надо радоваться, что вы сэкономили себе время и не устроились туда работать);
на следующем созвоне обсудить разные подходы на конкретном примере / коде.
Как я уже писал, для этого не нужно сложное задание, и для этого даже не обязательно свое тестовое, если у кандидата есть свой проект или другое тестовое, то можно отталкиваться от него.
Неудачный у вас опыт, видимо. Я, например, даю тестовое задание и прекрасно знаю, какой должен быть результат. Только его не надо угадывать – мне важно посмотреть, как человек пишет и мыслит, какие допускает (или не допускает) ошибки.
Тестовое задание у нас довольно простое, только люди с разным опытом и выполняют его по-разному.
При этом, если у кандидата есть что показать (личный проект, другое тестовое), я никогда не настаиваю, чтобы он выполнил именно наше задание. Да, для меня это означает больше работы, поскольку мне надо будет вникать в незнакомый проект, но я готов на это пойти.
Кроме того, мы всегда даем обратную связь по итогам задания (по сути, делаем код ревью с созвоном после проверки, если кандидату это интересно).
И я не думаю, что мы одни такие :)
Да, только это здесь не при чем.
Хорошо, но к расширяемости кода это не имеет отношения.
Если подходить с позиции: "Я художник, я так вижу", то да, всё так, и смысла дискутировать нет.