Комментарии 44
Больше пятничной драмы!
Сколько стульев сгинуло в адовом пламени на пути к решению данной проблемы?
Сколько мегатонн поноснолучевого эквивалента было излучено в предполагаемом направлении офиса разработки данного приложения?
Сколько стульев сгинуло в адовом пламени на пути к решению данной проблемы?
Сколько мегатонн поноснолучевого эквивалента было излучено в предполагаемом направлении офиса разработки данного приложения?
Шутка про серийного программиста
Плохой программист Джон сделал ошибку в коде, из-за которой каждый пользователь программы был вынужден потратить в среднем 15 минут времени на поиск обхода возникшей проблемы. Пользователей было 10 миллионов. Всего впустую потрачено 150 миллионов минут = 2.5 миллиона часов. Если человек спит 8 часов в сутки, то на сознательную деятельность у него остается 16 часов. То есть Джон уничтожил 156250 человеко-дней ≈ 427.8 человеко-лет. Средний мужчина живет 64 года, значит Джон убил примерно 6 целых 68 сотых человека.
Как тебе спится, Джон — серийный программист?
Как тебе спится, Джон — серийный программист?
несколько дней назад она была в посте на хабре, про говнокод, потом попала на пикабу, и в паблики вк оттуда. Теперь ее вообще везде постить будут?
Очень ущербная шутка, особенно её форс и «гениальные» выводы, сделанные на ее основании.
Почему ущербная? Очень правильная. Время и нерные клетки — это самое ценное что у нас есть, и это печально когда миллионы людей страдают из-за одного криворукого… Его работа — облегчать жизнь миллионам людей.
А почему нет?
Часто вы видели программистов, делающие ошибки целенаправленно?
И кто сказал что программа, задерживающая на 15 минут для обхода ошибки не позволяет сэкономить лишь на 15 минут времени меньше, но не потратить 15 минут?
Часто вы видели программистов, делающие ошибки целенаправленно?
И кто сказал что программа, задерживающая на 15 минут для обхода ошибки не позволяет сэкономить лишь на 15 минут времени меньше, но не потратить 15 минут?
Часто вы видели программистов, делающие ошибки целенаправленно?
Да, часто. Большинство таких программистов не понимают что это ошибки и да, такие штуки сделаны целенаправленно. Я более чем уверен что для описанного в статье адка есть несколько оправданий и вообще — это не баг а фича, а пользователи криворукие и должны учиться пользоваться таким замечательным продуктом, ведь эта ситуация четко описана в 1527 параграфе справки, а если разобраться в коде, то все очень логично. И так много где.
По поводу 15 минут меньше: это похоже на оправдание для какого-нибудь плохого автомобиля — подумаешь, что нужно кривым стартером 15 минут поработать, чтоб завести его, зато можно доехать на 15 минут раньше чем пешком дойти. И вообще кривой стартер полезен для здоровья и так специально задумано чтоб сэкономить 100 рублей на стартере.
Часто вы видели программистов, делающие ошибки целенаправленно?
Зато я каждый день вижу программистов, целенаправленно их не фиксящих.
Плохой программист Вася написал ущербный текст «ни о чём», из-за которого каждый пользователь был вынужден потратить в среднем 15 минут времени на прочтение текста и коммантарий к нему. Пользователей было 10 миллионов. Всего впустую потрачено 150 миллионов минут = 2.5 миллиона часов. Если человек спит 8 часов в сутки, то на сознательную деятельность у него остается 16 часов. То есть Вася уничтожил 156250 человеко-дней ≈ 427.8 человеко-лет. Средний мужчина живет 64 года, значит Вася убил примерно 6 целых 68 сотых человека.
Как тебе спится, Вася — серийный писака?
Как тебе спится, Вася — серийный писака?
А вы не знаете, какой ключик реестра при этом правится?
ProcessMonitor должен увидеть, если действительно правится.
хороший вопрос
Это скорей всего свойство параграфа. А документ этот создал пользователь, у которого установлен азиатский язык и стоит эта галка.
Ирония в том, что файл создавался на том же компьютере, но он генерировался спец.утилитой.
Генерировался не пойми чем, а виноват Офис? Скачал файл, сбросил стиль у абзаца и всё заработало.
Не работает.
Без добавления азиатского пакета никакие манипуляции с настройками параграфа не изменяли ситуацию.
Попробуйте сами — это работает и в обратную сторону — ставите эту птичку и наслаждайтесь.
Без добавления азиатского пакета никакие манипуляции с настройками параграфа не изменяли ситуацию.
Попробуйте сами — это работает и в обратную сторону — ставите эту птичку и наслаждайтесь.
Вопрос только один: кто и как смог вообще найти такое решение?!
Сразу подумал на китайский язык, но что его сперва нужно добавить, это неожиданно.
Если я правильно понял — речь об отсутствии автоматических переносов.
У вас ведь на одном из рисунков показано, что эта опция отключена и её надо было просто включить (она кстати, связана с языком, ну русский язык и так у вас уже имелся — включите её, настройте переносы в том же пункте — и работайте.
Первая же ссылка в гугле по запросу «microsoft mid word unconditional wrap» выдаёт нужное решение.
</thread>
</thread>
А какой у вас офис? Ни разу с таким не сталкивался. Приложили бы doc/docx для воспроизведения :)
2013. Но, по-моему, это не привязано к версии — на старых тоже должно воспроизводиться.
Для примера вот файлик.
Для примера вот файлик.
Занятным образом, это напоминает алгоритм удаления из списка языков дефолтного английского в macOS.
В старых версиях офиса, на сколько я помню, было понятие — язык текста, т.е. можно было написать по русски и указать что это английский язык, и тогда ничего языкозависимое работать не будет, ни проверка орфографии ни переносы. Даже помню обсуждение по поводу какая раскладка должна стоять, если вставляешь русский текст, если будет английская — то можно было получить проблемы.
Что то мне говорит что это свойство у текста осталось но в новых версиях офиса я не нашел ничего похожего на эту опцию. Утилиты генерации наверняка не установили корректно это свойство или еще хуже, установили на явно не русскую версию. А добавление языкового пакета (любого) скорее всего меняло что то в умолчаниях и это исправляло ситуацию.
Что то мне говорит что это свойство у текста осталось но в новых версиях офиса я не нашел ничего похожего на эту опцию. Утилиты генерации наверняка не установили корректно это свойство или еще хуже, установили на явно не русскую версию. А добавление языкового пакета (любого) скорее всего меняло что то в умолчаниях и это исправляло ситуацию.
Так вроде очистка стиля помогает убрать эти переносы, или нужно было сохранить стиль?
Ну, может быть я не совсем профи, но с sample.docx я решил довольно просто — Save as RTF, отрываю в Wordpad-e, переносы работают. Ну там какие-то изменения, сохранить, открываю в офисе — все работает. Конечно, если документ большой и какое-то сложное форматирование — может и не сработать…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MS Office переносит слова на новую строку по буквам