Традиционно женщины воспитываются как слабый пол. Если физически это ещё логично (статистически женщины слабее), и разгружать вагоны им действительно сложнее, то в профессиях, для которых нужен только мозг, они ничуть не хуже. Проблема в другом — женщина из-за преобладания других гормонов будет реже хвастаться своими достижениями, хуже «толкаться локтями» в коллективе, реже переходить на личности, а также более чувствительно реагировать на критику, принимать всё на личный счёт и т.д. Это делает её менее заметной «серой мышкой», позволяет заваливать её рутинной работой, делает уязвимой в спорах и т.д. Плюс социальный аспект — если женщина начинает вести себя по-мужски, её тут же называют стервой, что тоже малоприятно. По сути, это всё не имеет ничего общего с профессиональными умениями. Если построить коллектив с учётом всех этих особенностей женщин (уважительно относиться, давать возможность высказаться, в спорах не выходить за рамки техники), девчонки ничем не уступают нам.
Эмм, я не говорил, что священную корову надо на мясо. Мы не дети, вроде, понимаем, что хабру зарабатывать надо. Пусть публикуют рекламные посты на хабре, почитаем уж. Тем более, что иногда и что-то полезное бывает.
Во-первых, спасибо за шаг в правильном направлении!
Мне вообще нравится идея с отделением от хабра обзоров телефонов, новостей IT и прочей шелухи. Единственное, выбранный критерий определения шелухи не очень верен. Вы попробовали провести водораздел по линии «программирование / не программирование», и это не очень хорошо сработало, потому что с водой выплеснули нескольких младенцев типа электроники, DIY, робототехники, частично космонавтики и т.д. С одной стороны, я понимаю, почему вы так сделали. Большинство статей — это статьи про «вышел новый процессор Intel» или «разработана новая технология памяти» — это слишком замусоривало хабр. Но при этом ушли и статьи про разработку электроники, что намного более интересно, полезно и вообще более в духе хабра.
Как мне кажется, я нашёл критерий, по которому разделение будет гораздо более простым и правильным: статьи, полезные для тех, кто что-то делает сам, идут на хабр. Статьи для потребителей — на гиктаймс. Вы, сталкиваясь со сложностями в классификации хабов, уже пользуетесь этим принципом — например, раздел «Игры» есть и на хабре, и на гиктаймс, но в первом всё касается разработки игр (пусть даже это и не программирование, а скажем гейм-дизайн), а в другом — про «вышла игра для Linux», «игры — добро или зло» и т.п. Этот критерий простой, его будет очень легко довести до аудитории, а главное, хабр станет интереснее, если на нём будет появляться больше интересных статей, которые сейчас просто теряются на сателлитах.
Если сообщество эту идею поддержит и вы её реализуете, от этого выиграют все, включая рекламодателей.
При том, что я с вами согласен (в плане оценки коллег), я бы хотел ещё одну мысль в копилочку добавить: язык программирования задаёт рамки, которые могут затруднить или облегчить написание трудночитаемого кода. Go не даёт писать хитрый, сложный, нечитаемый код просто потому, что из него изъяли кучу конструкций, и этим он хорош.
А как по поводу оценок дела обстоят? Когда я учился (начало 2000-х), слышал, что университетам начали оплачивать бесплатные места в зависимости от числа студентов, устроившихся потом по специальности. Мы ещё потом справки с работы носили, чтобы это подтвердить. Чем, на мой взгляд, создали очень мощный повод не отчислять студентов, даже если они плохо учатся. Если это так, то это страшная жесть, которой можно объяснить нынешнее состояние образования. У меня нет данных, чтобы проверить эту гипотезу. Вам как преподавателю не давали инструкций в том или ином виде не зверствовать на экзаменах и зачётах? Что вообще должен делать преподаватель, если ему достался слабый поток — стрелять на поражение или тянуть любыми силами?
Господи, какая каша. Пароль загрузчика (grub2) спрашивается до загрузки ядра. Его и только его можно обойти в результате бага.
Потом грузится ядро, монтирует корневую фс, и только после этого загрузочные скрипты могут спросить пароль root. Перед монтированием корневой фс часто сначала монтируется initramfs, которая может например пароль на расшифровку фс спросить.
Вообще я не понимаю, почему уязвимость критической назвали. Чтобы это хоть какой-то вред нанесло, надо чтобы у злоумышленника был физический доступ к клавиатуре, но при этом не было возможности загрузить компьютер с другого носителя (флешки, cd/dvd, другого жёсткого диска и т.д.) Защита от младшего братика?
Не знаю. Не готов спекулировать на эту тему. Есть очевидный факт: договор подписан и в одностороннем порядке нарушен. Получается, пацан слово дал — пацан слово взял.
Российские законодатели недавно публично положили на эту логику. Закон 54-ФЗ от 30.03.1998 (http://www.echr.ru/documents/doc/12011157/12011157.htm) принят Думой и подписан Президентом. Россия ратифицировала Конвенцию о защите прав человека и основных свобод. В том числе статью 46 (http://www.echr.ru/documents/doc/2440800/2440800-003.htm), обязующую Россию признавать решения ЕСПЧ. Ситуация однозначнее некуда — подписали — будьте добры исполнять. А не исполняют.
Комментарий в таком духе — это, в первую очередь, неуважение к автору кода. Я такого ни разу не встречал. Обычно все комменты очень логичные и содержательные. Если что-то конкретное непонятно, то спрашивается, что именно. Например: «почему ты здесь делаешь X, если в других аналогичных местах везде делается Y?» И автор, если он действительно делал X намеренно, может оставить комментарий в коде: «Здесь X, потому что Z». Тогда следующий читатель кода не будет голову ломать, почему. Как-то так.
Разумеется замечания должны быть конкретными, показывающими, что сломается, испортится, будет неудобно, слишком сложно и т.д… Если нет резонных аргументов, то на нет и суда нет.
Может быть мы о разных вещах говорим. Я имею в виду не вкусовщину, а именно ошибки проектирования архитектуры. Например, «смешивание модели данных с их представлением затруднит в будущем написание мобильного приложения». Можно сразу автора «обрадовать» и попросить переделать, а можно дать ему закоммитить это безобразие, а потом кому-то привалит «счастье» распутывать всё.
Если бы вы объяснили, каким сущностям реального мира соответствуют вершины и ребра графа, статья стала бы гораздо понятнее. Могу предположить, что вершины — это операторы кода, а ребра — возможные переходы между ними, но это только догадки.
И ещё дополнение. Если ревьюеру что-то не понятно в коде, автор должен не лично ревьюеру это объяснить, в комментах к ревью и т.д., а либо упростить код и сделать его более понятным, либо привести текстовые объяснения прямо в коде в виде комментариев языка программирования. Ибо если ревьюер чего-то не понял, то и следующие N человек, кому надо будет разобраться, тоже не поймут.
А я бы и по поводу архитектурного дизайна докапывался. Это как раз то, что «отливается в граните» навеки. Неудачное решение лучше переделать сразу, чем дать ему укорениться в проекте.
Автор кода должен был сначала все продумать и обсудить архитектуру с коллегами, провести дизайн-ревью. На этом этапе все поменять было бы элементарно. И только потом садиться писать код.
Человек явно ориентирован на энтерпрайз. Банки, логистика, ритейл — для них всех действительно айти выполняет вспомогательную функцию. Он им и продаёт свои продукты. У тех, кому айти приносит деньги, совсем другая экономика.
В Google Inbox есть возможность отложить пришедшее письмо до наступления события — или по времени, или по геопозиции.
Типичные юзкейсы — написать кому-нибудь запрос и отложить на неделю. Если на письмо ответят, то вся ветка всплывет сразу. Если не ответят, то всплывет через неделю, и я смогу «пнуть» получателя. Или наоборот, мне прислали письмо, а я сейчас не у компьютера. Тогда откладываю «до дома» или «до работы», и оно всплывет, когда я на месте буду. В итоге я перестал забывать то, о чем меня просят, и о чем я прошу.
Ни один мессенджер (насколько мне известно) аналогичный функционал предоставить не может.
Это не формальный математический термин. Я имел в виду разложить метрики по группам по принципу, что самые близкие (с высокой степенью корреляции) будут в одной группе. Тогда, если найдётся доминирующая огромная группа, то она, скорее всего, соберёт метрики, действительно описывающие коррупционера. Им можно будет доверять больше.
А вы не думали, как можно проверить достоверность модели? Развесить ярлыки просто, а понять, насколько они соответствуют жизни, куда сложнее.
Мне первое, что приходит на ум — если чиновник коррупционер, то у него несколько признаков будет. Можно посчитать попарно корреляцию между метриками, кластеризовать их (метрики), найти ядро, и потом назначить всем метрикам веса, соответствующие их близости к ядру.
А если ядро найти не удастся, у меня плохие новости про все исследование :)
А ещё — что за дырка была, какие меры предприняли, чтобы такого больше не повторилось — какие изменения в модель угроз внесены, какие технические и организационные меры и т.д.
Без этого статья ни о чем — у нас завелась крыса, мы ей прищемили хвост. А ведь могли и голову оторвать. Ай-ай-ай, крыса.
Вообще, если вы такие вещи пишете о компании, потенциальные клиенты могут или испугаться иметь с вами дело (инсайдеры могут деньги украсть), или наоборот (компания учится на ошибках, делает выводы, и я могу быть уверен, что такое не повторится).
Мне вообще нравится идея с отделением от хабра обзоров телефонов, новостей IT и прочей шелухи. Единственное, выбранный критерий определения шелухи не очень верен. Вы попробовали провести водораздел по линии «программирование / не программирование», и это не очень хорошо сработало, потому что с водой выплеснули нескольких младенцев типа электроники, DIY, робототехники, частично космонавтики и т.д. С одной стороны, я понимаю, почему вы так сделали. Большинство статей — это статьи про «вышел новый процессор Intel» или «разработана новая технология памяти» — это слишком замусоривало хабр. Но при этом ушли и статьи про разработку электроники, что намного более интересно, полезно и вообще более в духе хабра.
Как мне кажется, я нашёл критерий, по которому разделение будет гораздо более простым и правильным: статьи, полезные для тех, кто что-то делает сам, идут на хабр. Статьи для потребителей — на гиктаймс. Вы, сталкиваясь со сложностями в классификации хабов, уже пользуетесь этим принципом — например, раздел «Игры» есть и на хабре, и на гиктаймс, но в первом всё касается разработки игр (пусть даже это и не программирование, а скажем гейм-дизайн), а в другом — про «вышла игра для Linux», «игры — добро или зло» и т.п. Этот критерий простой, его будет очень легко довести до аудитории, а главное, хабр станет интереснее, если на нём будет появляться больше интересных статей, которые сейчас просто теряются на сателлитах.
Если сообщество эту идею поддержит и вы её реализуете, от этого выиграют все, включая рекламодателей.
Потом грузится ядро, монтирует корневую фс, и только после этого загрузочные скрипты могут спросить пароль root. Перед монтированием корневой фс часто сначала монтируется initramfs, которая может например пароль на расшифровку фс спросить.
Вообще я не понимаю, почему уязвимость критической назвали. Чтобы это хоть какой-то вред нанесло, надо чтобы у злоумышленника был физический доступ к клавиатуре, но при этом не было возможности загрузить компьютер с другого носителя (флешки, cd/dvd, другого жёсткого диска и т.д.) Защита от младшего братика?
Автор кода должен был сначала все продумать и обсудить архитектуру с коллегами, провести дизайн-ревью. На этом этапе все поменять было бы элементарно. И только потом садиться писать код.
Типичные юзкейсы — написать кому-нибудь запрос и отложить на неделю. Если на письмо ответят, то вся ветка всплывет сразу. Если не ответят, то всплывет через неделю, и я смогу «пнуть» получателя. Или наоборот, мне прислали письмо, а я сейчас не у компьютера. Тогда откладываю «до дома» или «до работы», и оно всплывет, когда я на месте буду. В итоге я перестал забывать то, о чем меня просят, и о чем я прошу.
Ни один мессенджер (насколько мне известно) аналогичный функционал предоставить не может.
Мне первое, что приходит на ум — если чиновник коррупционер, то у него несколько признаков будет. Можно посчитать попарно корреляцию между метриками, кластеризовать их (метрики), найти ядро, и потом назначить всем метрикам веса, соответствующие их близости к ядру.
А если ядро найти не удастся, у меня плохие новости про все исследование :)
Без этого статья ни о чем — у нас завелась крыса, мы ей прищемили хвост. А ведь могли и голову оторвать. Ай-ай-ай, крыса.
Вообще, если вы такие вещи пишете о компании, потенциальные клиенты могут или испугаться иметь с вами дело (инсайдеры могут деньги украсть), или наоборот (компания учится на ошибках, делает выводы, и я могу быть уверен, что такое не повторится).