Молодой японец Мития Исии прилетел в Москву на учебу и первый же таксист довез его из Шереметьево до общежития за 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 вообще не понять) Ностальгия!
С этим я не поспорю. Я к тому, что для того, чтобы архитектору дать временную оценку и все прочие оценки, ему надо иметь чёткое представление о том, как это лучше сделать. Зачастую, этих представлений нет в связи с ограниченностью времени архитектора, которое он тратит на корректировку таких оценок :)
Действительно, удаленка много что показала. И хорошее и плохое. Есть такое хорошее утверждение — звездный час менеджера тогда, когда все плохо. А тут были целые недели. Многие зайцы сдохли. Быки выживали за счет жирка. Но народились новые зайцы, для которых этот «постапокалиптический» мир все, что они знают. Ладно, довольно метафор.
Быки всегда выживают, за счёт жирка. И за счёт коррупции в стране.
Так что изменил ковид? И опять все просто. Он не дал иных путей как меняться. Все ли изменилось? Нет конечно. Огромная кипа документов ждет людей в офисах. Даже в период жесткого карантина не было тотальной удаленки.
Вспомнилась шутка: «В России даже, если внедрят электронный чип, при приходе куда-то всё равно потребует бумажную копию этого чипа».
Проведут оценку и посмотрят результат. Если компания действительно смогла перестроиться и получила от этого выгоду (например экономия в аренде), то почему нет? Но подавляющее большинство вернется на начало.
Опять с этим не поспоришь. Более того, выгоду получили компании, которые завязаны на должностях, бумажной волоките и прочим коррупционным составляющим. А настоящий бизнес — «малый и средний», не зависящий от званий, выслуги лет и гособеспечений — меняет вектор бытия) Т.к. пункт выше.
В крупной компании есть процессы, которые очень затруднительно вынести на удаленку. И это не совещания. С ними как раз все норм. Это документооборот. А также работа с персональными данными, коммерческой тайной и т.п.
Всё давно решаемо. Самое главное, чтобы все это понимали. Включая людей, от которых зависит принятие решений. К сожалению, в большинстве — эти решения далеки от реальности.
Подитоживая: я просто высказал своё мнение. Возможно оно «недальновидное», но поживём — увидим. Ни в коим случае своими рассуждениями никого не хотел обидеть. Это всего лишь субъективное мнение. Да к тому же, возможно, неверное (ибо я не архитектор).
Доля правды есть в ваших словах. Я уверен, что, к примеру в таких компаниях, как Google или Amazon — архитекторы тоже есть, и тоже двоякое мнение по поводу них у разработки) И я уверен, что у них те же проблемы… Что и у нас. Более того, после просмотра фильма Дудя про силиконовую долину я в принципе расстроился во всём :)
НО. Например, возьмём принципы разработки ПО. В какой то момент, вдруг все поняли, что монолит можно разбить на мелкие части и поддержка будет проще. Далее, тоже самое делается и с бизнесом — вдруг гиганты начинают понимать, что микрокоманды — приносят профит лучше, чем огромная машина. Едем дальше. Ковид показал, что удалённая разработка — ничем не хуже, чем офисная… И гиганты в этом убедились. И сейчас удалённой разработкой уже никого не удивишь.
Я уверен, следующим этапом — будет переход к более свободному духу разработки. Свободный — это когда нет жёстких требований и жёстких указаний. Когда фриланс может быть полезнее, чем несколько архитекторов. Про то, что конкурсные основы (по типу таких, которые устраивает Паша Дуров) — принесут профита больше, чем содержание штата ну и т.д. Когда ответственность несёт команда, а не отдельные должности, и команда же и рискует, предлагает решения, самоорганизовывается… Развивать мысль далее, я не буду. Но смысл в том, что всё меняется…
Наверняка хороший архитектор будет в цене. Но «хорошесть» должна базироваться на фактическом опыте выполнения проектов. На том, что реально было сделано и принесло ли профит.
Не только. К примеру, у меня на текущей работе получается так, что бизнес сам до конца не знает, что ему хочется. И этот конец растягивается по времени. Интерфейсы дают абстрагироваться от конкретной реализации и не тянуть резину и ждать конца того, что им хочется, а писать частично-рабочий код. А когда они определяются — реализовывать. И таким образом, интерфейсов становится больше, даже «не на стыке модулей». Интерфейсы дают гибкость разработки… в условиях современной разработки, учитывая специфику бизнес-требований (которые далеко не идеальны).
В смысле сказочно...
С этого момента сразу возникает куча вопросов.
Трудяги) Всё делают, чтобы жизнь была лучше (но это не точно).
Ох, как хорошо) ждал этот комментарий.
Молодой японец Мития Исии прилетел в Москву на учебу и первый же таксист довез его из Шереметьево до общежития за 34 000 рублей. А когда Исия понял, что его обманули, обратился в юридическую контору, сотрудники которой поступили также, как и таксист, правда, сумма увеличилась в 10 раз.
Да тут проблема даже не в дыре...
Проблема более глобальна. Эти данные централизованы. А значит и без дыры их можно продать/украсть/конфисковать и т.д. По факту, у нас в стране, технический взлом (как у вас не без помощи удачи) происходит гораздо реже...чем социальная инженерия. И рано или поздно мы бы всё равно увидели эту базу в сети :)
Ты им наработки, они тебе деньги/рынок сбыта, а себе разницу в деньгах и авторство ) типичный российский к
упи-продайбизнес.Со всех сторон кидалово. Никому в этой стране не нужны не инновации, ни инженеры... Потом удивляются почему уезжают люди. Автору скорее всего надо на какую-нибудь мировую площадку вроде кикстартера. Ну или привлекать к сотрудничеству забугорные компании. По самим изобретениям сказать ничего не могу - т.к. не знаю насколько это востребовано и далёк от области медицины.
Я думаю понятие "глубинка" для IT это не та история)
Самое главное перед внедрением код-ревью в командах: это чтобы все члены команды понимали правила как делать код-ревью (на хабре есть статьи...и про то, как писать комментарии правильные и про скоупы для ревью и т.д.). Если понимания такого у других участников нет - вы можете апеллировать к руководству, на конкретном примере. Как правило многие внедряют код-ревью и думают, что их код сразу станет лучше, но на деле - это приводит к множеству конфликтов/споров и даже механизмов манипуляций.
Я проходил случаи и нарушения проведения код-ревью (к примеру ревьюер оставлял комментарий на чужой код), и случаи когда ревью занимается один человек, но его компетенции, как разработчика значительно ниже и умеет убеждать руководство (тоже плохо, руководство не понимает) и даже, когда код ревью тормозит срок выполнения задачи (типа накидывают косяков, которые в принципе для исправления надо переписывать чужие вещи).
В общем важно понимать, что код-ревью - это такая же условность и соглашение в команде, как и все остальные соглашения. При правильном подходе - это работает. При неправильном - порождает только массу проблем.
Грустно всё это. Я думаю процесс найма технических специалистов далёк от того, как он реально должен быть. Потому и в нашей отрасли проявляет себя принцип Парето.
developer.android.com/guide/playcore/in-app-review#quotas
Посмотрите вот этот комментарий: habr.com/ru/post/517442/#comment_22022990
Человек, мудро описывает решение данной ситуации.
Быки всегда выживают, за счёт жирка. И за счёт коррупции в стране.
Вспомнилась шутка: «В России даже, если внедрят электронный чип, при приходе куда-то всё равно потребует бумажную копию этого чипа».
Опять с этим не поспоришь. Более того, выгоду получили компании, которые завязаны на должностях, бумажной волоките и прочим коррупционным составляющим. А настоящий бизнес — «малый и средний», не зависящий от званий, выслуги лет и гособеспечений — меняет вектор бытия) Т.к. пункт выше.
Всё давно решаемо. Самое главное, чтобы все это понимали. Включая людей, от которых зависит принятие решений. К сожалению, в большинстве — эти решения далеки от реальности.
Подитоживая: я просто высказал своё мнение. Возможно оно «недальновидное», но поживём — увидим. Ни в коим случае своими рассуждениями никого не хотел обидеть. Это всего лишь субъективное мнение. Да к тому же, возможно, неверное (ибо я не архитектор).
НО. Например, возьмём принципы разработки ПО. В какой то момент, вдруг все поняли, что монолит можно разбить на мелкие части и поддержка будет проще. Далее, тоже самое делается и с бизнесом — вдруг гиганты начинают понимать, что микрокоманды — приносят профит лучше, чем огромная машина. Едем дальше. Ковид показал, что удалённая разработка — ничем не хуже, чем офисная… И гиганты в этом убедились. И сейчас удалённой разработкой уже никого не удивишь.
Я уверен, следующим этапом — будет переход к более свободному духу разработки. Свободный — это когда нет жёстких требований и жёстких указаний. Когда фриланс может быть полезнее, чем несколько архитекторов. Про то, что конкурсные основы (по типу таких, которые устраивает Паша Дуров) — принесут профита больше, чем содержание штата ну и т.д. Когда ответственность несёт команда, а не отдельные должности, и команда же и рискует, предлагает решения, самоорганизовывается… Развивать мысль далее, я не буду. Но смысл в том, что всё меняется…
Наверняка хороший архитектор будет в цене. Но «хорошесть» должна базироваться на фактическом опыте выполнения проектов. На том, что реально было сделано и принесло ли профит.