А почему бы не разрешить IT‑шникам просто писать дипломные работы по своим IT‑проектам? И если проекты действительно демонстрирует их знания, умения и навыки, то давать им за это официальный диплом.
Чтобы стать рыцарем, мало сходить к пещере и завалить дракона. Надо ещё научиться стихосложению и игре в шахматы или хотя бы в шашки.
На Perl можно было писать по-разному. Можно так "оптимизировать" программу, что она будет похожа на обфусцированный код. А можно выбрать такой стиль, что она будет выглядеть уж никак не хуже программы на Python.
А зачем для поддержки старого программного обеспечения развивать язык, на котором оно написано, добавлять в него новые конструкции? Можно было бы ограничиться доработкой существующих реализаций: исправлением ошибок, повышением производительности и т. п.
Вспомнилась голландская селёдка капитана Врунгеля, которую никто кроме голландцев не мог поймать. Пробовали ловить шотландцы, но у них всё шотландская попадалась. Норвежцы пробовали, но у них только норвежская ловилась. И только голландцам повезло с настоящей голландской селёдкой...
... Они почему-то решили показать мне свой код, и он был написан на испанском. Прямо буквально. Я очень удивился, потому что меня учили, что код надо писать только на английском, а всё остальное — извращение. Спустя несколько лет на собеседовании в российской компании мне тоже показали свой код. Он был написан на русском. Я был в шоке.
Учили писать, наверное, англичане? И всё же, я надеюсь, не код, а комментарии к нему? Или прямо идентификаторы (Java, кажется, такое допускает)?
В любом случае, если программа пишется для локального применения, то использование национального языка вполне приемлемо.
Современная — да, но по поводу отказоустойчивости мнения пока что самые разные. Даже в документации Arch предупреждается, что btrfs пока что в активной разработке. Вроде бы при «обычном» использовании уже достигли определённой стабильности, но с ext4 всё-таки не сравнить. И важно понимать, что в случае критичной проблемы можно потерять все данные, со всеми «снимками» сразу. Поэтому надо обязательно делать резервные копии важной информации на других носителях.
Потому что swap в btrfs - это отдельное увлекательное приключение. Интересно, зачем новичку btrfs? Могу предположить, что для решения проблем, присущих самому Arch — для восстановления из снимков после сбоев, возникших при обновлении.
Вот документация у Arch Linux действительно достойная. Почти всегда нахожу в ней полный, понятный и технически грамотный ответ на возникший вопрос. Хоть и пользуюсь в основном другим дистрибутивом.
Поддерживаю. Инструкции вообще (а для новичков тем более) должны давать единственный максимально прямой и короткий путь достижения цели. А разнообразие вариантов, их сравнение с указанием достоинств и недостатков - это уже другой жанр.
Только не надо забывать о естественном "слепом пятне", хорошо описанном Я. Перельманом в "Занимательной физике":
... Этот опыт, впервые произведенный в 1668 г. (в несколько ином виде) знаменитым физиком Мариоттом, очень забавлял придворных Людовика XIV. Мариотт проделывал опыт так: помещал двух вельмож на расстоянии 2 м друг против друга и просил их рассматривать одним глазом некоторую точку сбоку, — тогда каждому казалось, что у его визави нет головы.
Вечерами наблюдал, как над клубом в небе лазер рисует узоры, и как-то не задумывался над возможными инцидентами. Лучше уж просто закатом любоваться, а чудеса техники пусть эксплуатируются в более осмысленных мирных целях. Хотя человеку свойственно искать приключения на свою голову: те же салюты и коктейли с жидким азотом отнюдь не безопасны...
У "этой" трансляции к названию канала после "SpaceX" добавлены пробелы, на чём и строится коммерческий расчёт его создателей. Убедиться, что компания SpaceX не ведёт прямой трансляции, проще всего, зайдя сначала на её официальный канал, который несложно идентифицировать по количеству подписчиков. Ну, а значительная часть прогрессивного человечества наблюдала событие на весьма неплохой трансляции "Ежедневного Астронавта".
Если не ошибаюсь, в итоги запуска можно добавить пункт об успешном повторном запуске/остановке двигателей Starship на орбите. В третьем испытательном полёте от демонстрации этого номера программы испытатели отказались.
Можно, но без толку. Символы-заменители из таблицы Unicode на глаз не отличит даже эксперт. А выполнение всей процедуры по предложенному автором статьи списку просто остановит работу. Можно, конечно, возложить почётную обязанность по предварительной проверке входящей почты на департамент ИБ, но мне кажется, что они будут не в восторге. Хотя толковый сотрудник найдёт повод для этого повод:
Рабочий способ привить сотрудникам привычку проверять письма только один — регулярно обучать и тренировать людей через имитированные атаки, чтобы они не открывали реальные фишинговые письма и не заражали свои системы. А при любых подозрениях — отправляли письмо команде безопасности.
Наивно полагать, что рядовой сотрудник выявит фишинговое письмо, которое пропустили современные хорошо настроенные технические средства защиты. Но с точки зрения назначения виновного вменить ему в обязанность такую проверку надо обязательно.
Даже 20 лет назад Gentoo был довольно экзотическим дистрибутивом. Но в то время Интернет был дорогой, и за пределами мегаполисов найти хоть какой-нибудь дистрибутив было удачей. Сейчас же начинать с Arch Linux просто жестоко.
Чтобы стать рыцарем, мало сходить к пещере и завалить дракона. Надо ещё научиться стихосложению и игре в шахматы или хотя бы в шашки.
На Perl можно было писать по-разному. Можно так "оптимизировать" программу, что она будет похожа на обфусцированный код. А можно выбрать такой стиль, что она будет выглядеть уж никак не хуже программы на Python.
А зачем для поддержки старого программного обеспечения развивать язык, на котором оно написано, добавлять в него новые конструкции? Можно было бы ограничиться доработкой существующих реализаций: исправлением ошибок, повышением производительности и т. п.
В примере конвейер лишний. И лучше использовать режим добавления, чтобы не стереть комментарии, имеющиеся в шаблоне файла:
Встречаются ещё такие перлы:
Вспомнилась голландская селёдка капитана Врунгеля, которую никто кроме голландцев не мог поймать. Пробовали ловить шотландцы, но у них всё шотландская попадалась. Норвежцы пробовали, но у них только норвежская ловилась. И только голландцам повезло с настоящей голландской селёдкой...
Учили писать, наверное, англичане? И всё же, я надеюсь, не код, а комментарии к нему? Или прямо идентификаторы (Java, кажется, такое допускает)?
В любом случае, если программа пишется для локального применения, то использование национального языка вполне приемлемо.
Современная — да, но по поводу отказоустойчивости мнения пока что самые разные. Даже в документации Arch предупреждается, что btrfs пока что в активной разработке. Вроде бы при «обычном» использовании уже достигли определённой стабильности, но с ext4 всё-таки не сравнить. И важно понимать, что в случае критичной проблемы можно потерять все данные, со всеми «снимками» сразу. Поэтому надо обязательно делать резервные копии важной информации на других носителях.
Потому что swap в btrfs - это отдельное увлекательное приключение. Интересно, зачем новичку btrfs? Могу предположить, что для решения проблем, присущих самому Arch — для восстановления из снимков после сбоев, возникших при обновлении.
Вот документация у Arch Linux действительно достойная. Почти всегда нахожу в ней полный, понятный и технически грамотный ответ на возникший вопрос. Хоть и пользуюсь в основном другим дистрибутивом.
Поддерживаю. Инструкции вообще (а для новичков тем более) должны давать единственный максимально прямой и короткий путь достижения цели. А разнообразие вариантов, их сравнение с указанием достоинств и недостатков - это уже другой жанр.
Он нужен только для BIOS-компьютеров с GPT-разметкой загрузочного носителя. Для UEFI+GPT ничего такого не надо. Как и для BIOS+MBR.
Только не надо забывать о естественном "слепом пятне", хорошо описанном Я. Перельманом в "Занимательной физике":
Ну, снег в яркую погоду у многих вызывает "спецэффекты". Может, это и не из-за лазера. Хотя я уже понял, что с лазером шутки плохи.
Вечерами наблюдал, как над клубом в небе лазер рисует узоры, и как-то не задумывался над возможными инцидентами. Лучше уж просто закатом любоваться, а чудеса техники пусть эксплуатируются в более осмысленных мирных целях. Хотя человеку свойственно искать приключения на свою голову: те же салюты и коктейли с жидким азотом отнюдь не безопасны...
Интересно, а что тогда происходит с глазами у посетителей таких мероприятий?
У "этой" трансляции к названию канала после "SpaceX" добавлены пробелы, на чём и строится коммерческий расчёт его создателей. Убедиться, что компания SpaceX не ведёт прямой трансляции, проще всего, зайдя сначала на её официальный канал, который несложно идентифицировать по количеству подписчиков. Ну, а значительная часть прогрессивного человечества наблюдала событие на весьма неплохой трансляции "Ежедневного Астронавта".
Если не ошибаюсь, в итоги запуска можно добавить пункт об успешном повторном запуске/остановке двигателей Starship на орбите. В третьем испытательном полёте от демонстрации этого номера программы испытатели отказались.
Можно, но без толку. Символы-заменители из таблицы Unicode на глаз не отличит даже эксперт. А выполнение всей процедуры по предложенному автором статьи списку просто остановит работу. Можно, конечно, возложить почётную обязанность по предварительной проверке входящей почты на департамент ИБ, но мне кажется, что они будут не в восторге. Хотя толковый сотрудник найдёт повод для этого повод:
Рабочий способ привить сотрудникам привычку проверять письма только один — регулярно обучать и тренировать людей через имитированные атаки, чтобы они не открывали реальные фишинговые письма и не заражали свои системы. А при любых подозрениях — отправляли письмо команде безопасности.
Наивно полагать, что рядовой сотрудник выявит фишинговое письмо, которое пропустили современные хорошо настроенные технические средства защиты. Но с точки зрения назначения виновного вменить ему в обязанность такую проверку надо обязательно.
Даже 20 лет назад Gentoo был довольно экзотическим дистрибутивом. Но в то время Интернет был дорогой, и за пределами мегаполисов найти хоть какой-нибудь дистрибутив было удачей. Сейчас же начинать с Arch Linux просто жестоко.