Извиняюсь, за возможно глупый, вопрос, просто нет компетенций в blockchain/etherium/smart contracts. А какого практическое применение сей связки? Как бы посыл понятен и понятно что сделано. Но не очень понятно, как это может применяться?
Молодой японец Мития Исии прилетел в Москву на учебу и первый же таксист довез его из Шереметьево до общежития за 34 000 рублей. А когда Исия понял, что его обманули, обратился в юридическую контору, сотрудники которой поступили также, как и таксист, правда, сумма увеличилась в 10 раз.
Проблема более глобальна. Эти данные централизованы. А значит и без дыры их можно продать/украсть/конфисковать и т.д. По факту, у нас в стране, технический взлом (как у вас не без помощи удачи) происходит гораздо реже...чем социальная инженерия. И рано или поздно мы бы всё равно увидели эту базу в сети :)
Чёт даже читать не стал… Токсично как-то стало. Я думаю каждый имеет право на личное пространство. Если сотрудник опаздывает, но делает работу хорошо, качественно и в срок — пусть опаздывает. К тому же у каждого свои временные рамки (совы/жаворонки)… В общем проблема из сериии: «как работать на заводе») Я помню после института устроился на завод местный — там если к 8-ми не пришёл — ворота закрываются и тебя уже не пропустят. И начинается новый квест — в виде звонка начальнику, тот должен кучу бумаг написать объяснительных и в итоге всем хорошо (кто привык не работать) — а пинать за деньги. Собственно, наверное, поэтому и минусят…
Со всех сторон кидалово. Никому в этой стране не нужны не инновации, ни инженеры... Потом удивляются почему уезжают люди. Автору скорее всего надо на какую-нибудь мировую площадку вроде кикстартера. Ну или привлекать к сотрудничеству забугорные компании. По самим изобретениям сказать ничего не могу - т.к. не знаю насколько это востребовано и далёк от области медицины.
Самое главное перед внедрением код-ревью в командах: это чтобы все члены команды понимали правила как делать код-ревью (на хабре есть статьи...и про то, как писать комментарии правильные и про скоупы для ревью и т.д.). Если понимания такого у других участников нет - вы можете апеллировать к руководству, на конкретном примере. Как правило многие внедряют код-ревью и думают, что их код сразу станет лучше, но на деле - это приводит к множеству конфликтов/споров и даже механизмов манипуляций.
Я проходил случаи и нарушения проведения код-ревью (к примеру ревьюер оставлял комментарий на чужой код), и случаи когда ревью занимается один человек, но его компетенции, как разработчика значительно ниже и умеет убеждать руководство (тоже плохо, руководство не понимает) и даже, когда код ревью тормозит срок выполнения задачи (типа накидывают косяков, которые в принципе для исправления надо переписывать чужие вещи).
В общем важно понимать, что код-ревью - это такая же условность и соглашение в команде, как и все остальные соглашения. При правильном подходе - это работает. При неправильном - порождает только массу проблем.
Я думаю не только «я» этим страдает… сейчас все с ума сошли и просто наглым образом обманывают: вайлдберриз, опсосы… Все «кладут болт на человека». [sarcasm_mode_on]Во всём виноват коронавирус[sarcasm_mode_off]. В целом я всегда против всяких обучающих курсов… понятно же на что это расчитано — на извлечение прибыли да и только. Сейчас, как верно подметили выше, человеку ничто не мешает развиваться самому… читать лекции, практиковаться и тт.д.
Автор, у меня теже мысли теже проблемы, что и у тебя. Просто наблюдая, как «болтуны» становятся победителями по жизни — как то грустно и руки опускаются. Я для себя понял одно — современным компаниям нужны «удобные» люди, а не технически-подкованные. И это удобство — оно и в умении произвести впечатление на других людей, общаться на разные темы, заранее подготовиться на список одних и тех же вопросов ашэров и т.д. (софт скиллы, корпоративная культура и бла-бла-бла) Мне это не нравится и не интересно. Люди мне в принципе не нравятся. И я каждый раз допускаю одни и те же ошибки и уже смирился с тем, что никогда не стану руководителем или управленцем. Просто пишу код и грущу, когда выслушиваю на очередном митинге от руководителя «какие мы молодцы и всё хорошо сделали») Просто пишешь код и получаешь бабки. «Хорошо» значит «хорошо») На самом деле плохо. «Набор» как правило идёт болтунов и людей, умеющих себя показать или ответить на вопрос «расскажите о себе»)
Грустно всё это. Я думаю процесс найма технических специалистов далёк от того, как он реально должен быть. Потому и в нашей отрасли проявляет себя принцип Парето.
Да я и не критикую статью. Я думаю, что она будет полезна многим. Просто посчитал своим долгом сделать акцент на «нюансах» этой новой функциональности. На которой сам же и «обжёгся», хотя я сам и есть источник своих проблем — надо было сначала прочитать доку полностью — потом внедрять ;)
Всё это здорово, но сам Google рекомендует использовать эту фичу весьма аккуратно. Смысл в том, что есть квота и просто добавить кнопку и на неё навесить — app review не очень хорошая идея. Сам на это наткнулся. Поэтому буду возвращать назад на ссылку в Google Play. Фича подойдёт тем, когда требуется разово показать review с растянутым по временем процессом (например, после прохождения всех уровней игры). Подробнее об этом тут: developer.android.com/guide/playcore/in-app-review#quotas
У меня был Zyxel Omni 56k PCI. Тоже копил на него. Ну и всё остальное о чём тут говорили — бонусом к нему (лишения сна, ожидание соединения, баснословные деньги, планирование «куда и зачем», скачивание mp-3-ки несколько часов и т.д.).Поколению-Z вообще не понять) Ностальгия!
С этим я не поспорю. Я к тому, что для того, чтобы архитектору дать временную оценку и все прочие оценки, ему надо иметь чёткое представление о том, как это лучше сделать. Зачастую, этих представлений нет в связи с ограниченностью времени архитектора, которое он тратит на корректировку таких оценок :)
Спасибо! Лайкну пост и оперативный ответ.
Извиняюсь, за возможно глупый, вопрос, просто нет компетенций в blockchain/etherium/smart contracts. А какого практическое применение сей связки? Как бы посыл понятен и понятно что сделано. Но не очень понятно, как это может применяться?
какие-то несерьёзные суммы, относительно зарплат)
В смысле сказочно...
С этого момента сразу возникает куча вопросов.
Трудяги) Всё делают, чтобы жизнь была лучше (но это не точно).
Ох, как хорошо) ждал этот комментарий.
Молодой японец Мития Исии прилетел в Москву на учебу и первый же таксист довез его из Шереметьево до общежития за 34 000 рублей. А когда Исия понял, что его обманули, обратился в юридическую контору, сотрудники которой поступили также, как и таксист, правда, сумма увеличилась в 10 раз.
Да тут проблема даже не в дыре...
Проблема более глобальна. Эти данные централизованы. А значит и без дыры их можно продать/украсть/конфисковать и т.д. По факту, у нас в стране, технический взлом (как у вас не без помощи удачи) происходит гораздо реже...чем социальная инженерия. И рано или поздно мы бы всё равно увидели эту базу в сети :)
Ты им наработки, они тебе деньги/рынок сбыта, а себе разницу в деньгах и авторство ) типичный российский к
упи-продайбизнес.Со всех сторон кидалово. Никому в этой стране не нужны не инновации, ни инженеры... Потом удивляются почему уезжают люди. Автору скорее всего надо на какую-нибудь мировую площадку вроде кикстартера. Ну или привлекать к сотрудничеству забугорные компании. По самим изобретениям сказать ничего не могу - т.к. не знаю насколько это востребовано и далёк от области медицины.
Я думаю понятие "глубинка" для IT это не та история)
Самое главное перед внедрением код-ревью в командах: это чтобы все члены команды понимали правила как делать код-ревью (на хабре есть статьи...и про то, как писать комментарии правильные и про скоупы для ревью и т.д.). Если понимания такого у других участников нет - вы можете апеллировать к руководству, на конкретном примере. Как правило многие внедряют код-ревью и думают, что их код сразу станет лучше, но на деле - это приводит к множеству конфликтов/споров и даже механизмов манипуляций.
Я проходил случаи и нарушения проведения код-ревью (к примеру ревьюер оставлял комментарий на чужой код), и случаи когда ревью занимается один человек, но его компетенции, как разработчика значительно ниже и умеет убеждать руководство (тоже плохо, руководство не понимает) и даже, когда код ревью тормозит срок выполнения задачи (типа накидывают косяков, которые в принципе для исправления надо переписывать чужие вещи).
В общем важно понимать, что код-ревью - это такая же условность и соглашение в команде, как и все остальные соглашения. При правильном подходе - это работает. При неправильном - порождает только массу проблем.
Грустно всё это. Я думаю процесс найма технических специалистов далёк от того, как он реально должен быть. Потому и в нашей отрасли проявляет себя принцип Парето.
developer.android.com/guide/playcore/in-app-review#quotas
Посмотрите вот этот комментарий: habr.com/ru/post/517442/#comment_22022990
Человек, мудро описывает решение данной ситуации.