Если сразу не отключил то уже телефон а базе, сейчас уже бесполезно отключать.
В мессенджере претендующим на безопасность это очень серьезный баг. Об этом должны думать разработчики, а не пользователи. Если разработчики делают так, что их мессенджер сливает данные по умолчанию всем желающим, то у меня нет никакого доверия этим разработчикам.
Какие? Вроде в статье написано, что никакого серьёзного аудита не проводил и багов и закладок (их там нет) не выявил.
В текущей версии протокола о багах ничего не известно, но в предыдущих версиях они были выявлены. Это не случайность а закономерность. Это говорит о их подходе. Приватность и защищённость только на словах, на деле базы пользователей продаются в интернете.
После того как в телеге можно пробить любого пользователя, продаются базы номеров телефонов юзеров и Павел отказался считать это багом, плюс баги (или закладки?) в протоколе шифрования, плюс возможность пробить адрес у кого включена функция «люди поблизости» или как ее там.
С таким подходом к безопасности и приватности, у меня большие вопросы к секретным чатам.
Signal в этом плане намного лучше. Взять хотя бы самоудаляющиеся сообщения и возможность верифицировать пользователя (view safety umber). Плюс у обоих пользователей должны быть номера телефона друг друга, поэтому перебор номеров телефонов не работает. Видно, что разработчики работают над защитой ваших данных не только на словах в твиттере.
Позвольте поинтересоваться, вы в туалете я так понимаю тоже дверь не закрываете? Нечего же скрывать. Может быть выложите всю вашу переписку из всех ваших соц сетей и мессенджеров на всеобщее обозрение.
Сомневаюсь, что просто случайно забыли.
Вероятно специальные люди в штатском приходят к ним и просят во имя добра, демократии, борьбы с терроризмом и защиты детей, вставить пачку бакдоров. Ну один нашли, ок, а сколько их осталось и сколько добавилось в новой прошивке? Где-то так тупо зашит логин с паролем, где-то специально допущена уязвимость, где-то генератор случайных чисел, оказывается вовсе не случайным.
Могут, но скорее через год или два.
Мне одна крупная контора в которую я не прошел собеседование в 2011 году пишет, звонит каждые пол года.
На собесе мне морочили мозг 3 часа идиотскими задачками или оторванными от реальности вопросами по языку программирования и не дали никакого фидбэка. После этого у меня не возникало желания туда идти.
Почему бы и нет. Конторы ведь именно так и деляют.
Мне приходилось проходить собеседования, в которых собеседователи даже сами не знали нужен им сотрудник или нет. Т.е. тратили зря мое время и морочили мне голову.
Был и в обратной ситуации когда я собеседовал людей, а потом начальство сказало, что они уже не хотят никого нанимать, потому что гладиолус.
Часто конторы просто собеседуют всех подряд, чтобы иметь контакты на случай если вдруг у них откроется позиция. А соискатели, потом переживают, что их не взяли на работу.
У нас нет строгого требования, чтобы это не было django-приложение — то есть это не критерий отбора — но практически все, кто связывается с django, тратят существенно больше времени на задание.
Раз многие так делают, возможно стоит понятнее сформулировать этот момент.
С тестовыми всегда сложность в том, что не понятны требования и критерии оценки.
Буду ли оценивать, что решение работает, или красивость кода или паттерны или наличии тестов или что применен какой-то специфический инструмент или применение специфического алгоритма.
А уточнять это через HR, как правило, мертвое дело.
Условно ваш пример с переворачиванием данных из файла.
Джун думает, ну вроде все понятно все просто. Пишет 2 строчки за 2 минуты и готово.
А сеньор начинает думать, а что если файл не влезет в память, а что если файл текстовый, а что если бинарный, а что если файл занимает больше половины свободного места на диске, а может быть нужно как-то оптимизировать по скорости. Ну не просто же так на сеньорскую позицию дали такое задание, наверняка там куча проблем. В итоге решает, что на это надо 3 дня потратить и закрывает вашу вакансию.
Может быть наоборот, тех кого они называют сеньорами просто толковые джуны.
Я не преуменьшаю значимость ревью, если речь идет о реальном долгосрочном проекте. Но тут ведь речь о тестовом задании.
Ну это больше похоже на предупреждения из серии «все персонажи вымышлены, все совпадения случайны». Это больше похоже не отмазку от ответственности. Тем более это где-то в конце и не заметно.
Да, это долгий процесс — может занимать 3 часа у кандидата. Как сделать, чтобы он не бросил эту затею? Мы заранее говорим, что все работы будут оценены вручную, и по каждой из них будет сделан детальный code review. И мы делаем, причём каждый такой ревью занимает в среднем 40 минут — но тем не менее мы не игнорируем ни одного кандидата. Это мотивирует, потому что даже если кандидата завернут, он точно будет знать, почему и над чем нужно работать.
Какая причина может заставить сеньора делать тестовое задание на 3 часа, тем более в маленькую компанию?
Ревью кода? Джуну может быть. Но я уверен что большинству опытных программистов ваше ревью просто не интересно.
Не надо прыгать с языка на язык. Выбрать один язык и одну платформу и потихоньку осваивать. Это будет долго и порой мучительно, но только так можно освоить на достаточном уровне. В идеале сразу устроиться на работу на данный стек.
Этот пункт не является действительным, т.к. противоречит ТК. Но конечно прямо на хабре писать наверно не стоит. Но некоторые даже в часной беседе боятся этого пункта, а зря.
Кто-нибудь может объяснить чем микросервисы отличаются от SOA (сервис ориентированная архитектура)?
SOA известна десятки лет и вокруг нее нет никакого хайпа, а вокруг микросервисов до сих пор нездоровый хайп и молодежь думает, что это новое уникальное изобретение.
Вы правы, но средних и мелких проектов намного больше чем больших. Для большинства проектов никогда не понадобиться горизонтальное масштабирование. Проблема микросервисов не в том что они плохие, а в том что их применяют там где они не нужны, не только не приносят, пользу но и создают проблемы.
Хотя я вижу, что это происходит с каждой модной технологией.
Да и причины в принципе понятны.
На больших крутых проектах нужны микросервисы, значит нужно добавить в резюме микросервисы.
Не важно что условный Вася работает над сайтом с 1000 визитов в день.
Он должен внедрить туда микросервисы, докер, машинное обучение, NoSQL, очереди и все другие модные слова, которые могут спросить у него на собеседовании у крупную модную компанию. Кто будет это поддерживать после Васи, конечно же не важно.
Если сразу не отключил то уже телефон а базе, сейчас уже бесполезно отключать.
В мессенджере претендующим на безопасность это очень серьезный баг. Об этом должны думать разработчики, а не пользователи. Если разработчики делают так, что их мессенджер сливает данные по умолчанию всем желающим, то у меня нет никакого доверия этим разработчикам.
В текущей версии протокола о багах ничего не известно, но в предыдущих версиях они были выявлены. Это не случайность а закономерность. Это говорит о их подходе. Приватность и защищённость только на словах, на деле базы пользователей продаются в интернете.
С таким подходом к безопасности и приватности, у меня большие вопросы к секретным чатам.
Signal в этом плане намного лучше. Взять хотя бы самоудаляющиеся сообщения и возможность верифицировать пользователя (view safety umber). Плюс у обоих пользователей должны быть номера телефона друг друга, поэтому перебор номеров телефонов не работает. Видно, что разработчики работают над защитой ваших данных не только на словах в твиттере.
Есть еще Status не привязан к номеру.
Вероятно специальные люди в штатском приходят к ним и просят во имя добра, демократии, борьбы с терроризмом и защиты детей, вставить пачку бакдоров. Ну один нашли, ок, а сколько их осталось и сколько добавилось в новой прошивке? Где-то так тупо зашит логин с паролем, где-то специально допущена уязвимость, где-то генератор случайных чисел, оказывается вовсе не случайным.
Мне одна крупная контора в которую я не прошел собеседование в 2011 году пишет, звонит каждые пол года.
На собесе мне морочили мозг 3 часа идиотскими задачками или оторванными от реальности вопросами по языку программирования и не дали никакого фидбэка. После этого у меня не возникало желания туда идти.
Почему бы и нет. Конторы ведь именно так и деляют.
Мне приходилось проходить собеседования, в которых собеседователи даже сами не знали нужен им сотрудник или нет. Т.е. тратили зря мое время и морочили мне голову.
Был и в обратной ситуации когда я собеседовал людей, а потом начальство сказало, что они уже не хотят никого нанимать, потому что гладиолус.
Часто конторы просто собеседуют всех подряд, чтобы иметь контакты на случай если вдруг у них откроется позиция. А соискатели, потом переживают, что их не взяли на работу.
Раз многие так делают, возможно стоит понятнее сформулировать этот момент.
С тестовыми всегда сложность в том, что не понятны требования и критерии оценки.
Буду ли оценивать, что решение работает, или красивость кода или паттерны или наличии тестов или что применен какой-то специфический инструмент или применение специфического алгоритма.
А уточнять это через HR, как правило, мертвое дело.
Условно ваш пример с переворачиванием данных из файла.
Джун думает, ну вроде все понятно все просто. Пишет 2 строчки за 2 минуты и готово.
А сеньор начинает думать, а что если файл не влезет в память, а что если файл текстовый, а что если бинарный, а что если файл занимает больше половины свободного места на диске, а может быть нужно как-то оптимизировать по скорости. Ну не просто же так на сеньорскую позицию дали такое задание, наверняка там куча проблем. В итоге решает, что на это надо 3 дня потратить и закрывает вашу вакансию.
Я не преуменьшаю значимость ревью, если речь идет о реальном долгосрочном проекте. Но тут ведь речь о тестовом задании.
Какая причина может заставить сеньора делать тестовое задание на 3 часа, тем более в маленькую компанию?
Ревью кода? Джуну может быть. Но я уверен что большинству опытных программистов ваше ревью просто не интересно.
Этот пункт не является действительным, т.к. противоречит ТК. Но конечно прямо на хабре писать наверно не стоит. Но некоторые даже в часной беседе боятся этого пункта, а зря.
SOA известна десятки лет и вокруг нее нет никакого хайпа, а вокруг микросервисов до сих пор нездоровый хайп и молодежь думает, что это новое уникальное изобретение.
Хотя я вижу, что это происходит с каждой модной технологией.
Да и причины в принципе понятны.
На больших крутых проектах нужны микросервисы, значит нужно добавить в резюме микросервисы.
Не важно что условный Вася работает над сайтом с 1000 визитов в день.
Он должен внедрить туда микросервисы, докер, машинное обучение, NoSQL, очереди и все другие модные слова, которые могут спросить у него на собеседовании у крупную модную компанию. Кто будет это поддерживать после Васи, конечно же не важно.
скорее даже так — очень редко где надо и почти всегда где не надо
Можно ведь await поставить перед Promise.all и тогда не будет портянки then/catch.
В любом случае в приведенном выше коде не кажется, что нужны промисы.