Иногда нужно сделать так, чтобы был обычный стиль, но например с выравниванием по правому краю, если потом, обновить стандартный стиль и текст набранный им, то выравнивание пропадает. Я понимаю, что можно создать специальный стиль с выравниванием по правому краю. Но потом, все общие изменения менять в 2-3 стилях сразу. Это как дублирующийся код, который сам по себе работает, но изменения связаны с повышенной вероятностью ошибки.
Жизнь так сложилась, что поступил. Обучили хорошо. Никаких взяток. Единственно что людей со знаниями между 2 и 3 выпустили на ровне с остальными.
Не все так категорично.
Около года частично занят работой с цифровыми сигнальными процессорами, правда задачи небольшого масштаба решаю. Должен отметить что эта статья является очень полезной для меня, когда представляешь примерно о чем технология, но суть, способы использования и отличия для себя не раскрыл.
Видел интересную мысль на хабре по этому поводу. Своими словами могу сформулировать так: Правило одного нового. Команда делает или новый проект на известном стеке технологий, или команда делает типовой проект на новом стеке технологий.
Ниша латеха вроде как математическое сообщество, научное сообщество и типографии. Уровень пользователей можно назвать продвинутым. В качестве применимости для ваших задач(как я понял быстрый документооборот) я вижу что латех мало подходит. Но если захотите написать корпоративную книгу, то теперь вы знаете инструмент.
Говорят Латех Тьюринг полный язык имеет в редакторе, но это не значит что все делается удобно. Из коробки есть счетчики, ссылки на счетчики, хорошая поддержка математических формул, библиография. Можно закомментировать кусок текста и он никак не будет влиять. Чуть пошаманив можно наверно сделать по параграфную генерацию удобную для пользователя. Ссылки на другие документы я не видел, может есть специализированные пакеты для этого. К недостаткам можно отнести сложность формирования таблиц. Панацеей Латех не может быть, но он всегда выдает стабильный результат в соответствии с заданным стилем. Просто так не поедет межстрочный интервал. Всегда одинаковый формат подписи к рисункам рамки на тех документах не съезжают в сторону по случайному клику мыши. И т.д.
С другой стороны, сверхвысокие плотности энергии в атмосфере ионизируют воздух, а ионизированный газ может переотражать, рассеивать и поглощать энергию излучения. Даже при создании супер мощного рентген лазера у него будет потолок при использовании в атмосфере. Насколько знаю, часть лабораторий использует дистиллированную воду в качестве диэлектрика (правда в радиодиапазоне) как раз из-за проблем с атмосферными газами.
Нормальный вариант защиты от лазеров смерти на орбите — база с мощным массивом лазеров на луне (правда там тоже есть микроатмосфера, да и вообще пыли много), где-нибудь на границе тени, чтобы была возможность получать энергию солнца, но физически углов на землю не было.
Да, нож не пробьет бронежилет
очевидно что бронепластину пробить затруднительно, но кевлар замечательно пробивается ножом, единственным хорошим решением является кольчуга.
Мне кажется, для обозначенных проблем должен неплохо подходить Латех, но у него один большой недостаток: он не MS Word.
Из текста не понятно реализована ли данная система или это просто рассуждение о проблематике.
Осознание того, что система сделана в MS Word и вероятно под капотом крутится нечто непонятное из макросов python и visual basic вгоняет в тоску мысли о поддержке данной системы. Индивидуально для себя в принципе можно побаловаться.
Разработка качественного плагина с поддержкой, расширяемым функционалом и каким-нибудь более приличным дизайном не рентабельна (если вы не собираетесь сделать стартап по этой тематике, а потом продавать плагин по всему миру за 5 баксов/месяц).
Один раз разобравшись с современной ПЛИС от Xilinx можно работать на всей линейке ПЛИС Xilinx, конечно переход ISE -> Vivado не самый простой, но все же лучше чем выучить специфику работы на одном конкретном ЦСП, с одной единственной версией RTOS/BIOS и такими же единственными версиями пакетов (половину из которых еще надо правильно скомпилировать).
OpenMP вообще вещь сомнительная. Наши программисты её не используют.
Как стандарт вещь достаточно хорошая, но реализация от TI просто кошмар (и они вроде как достаточно сильно отстают от последней версии стандарта).
ARM + ПЛИС есть на рынке. Intel купил Altera, значит и ПЛИС с x86 архитектурой так же вполне вероятна. Если не ошибаюсь в последние 5 лет проскакивала новость про системы ARM + x86 для устройств с переменной производительностью. Современные плис содержат небольшие блоки DSP для быстрой обработки специфических задач (например обработка видео). ARM + x86 + ПЛИС как мне кажется дает слишком большой оверхед в плане процессорных ядер.
Делал диплом на C6678, реализация синтеза РЛИ. Программировать и в самом деле сложно. Запуск OpenMP, FFT и TCP происходит без проблем по отдельности, но если надо запустить их совместно, то появляется тонна проблем по совместимости версий пакетов + подсистемы RTOS в качестве прослойки + отсутствие документации. Плюс спец IDE является так же привередливой и забагованной.
Разработчики поддерживают Keystone2, так что ситуация со временем не улучшается.
В результате огромный объем времени занимает изучение особенностей одного конкретного ЦСП. Лучше бы я учился прогать под ПЛИС, там хоть знания можно переиспользовать.
Использовать чистые функции, все аргументы передавать в явном виде, а все взаимодействие с внешним миром оборачивать в монаду IO — не всегда возможно эффективно применить строгий функциональный подход, а где это возможно: лучше применять функциональные языки.
С другой стороны требовать применения правил, когда явных ограничений нет — бессмысленно.
Заставлять программиста придерживаться строгой чистоты в коде как парадигмы можно сколько угодно, но без кнута в виде компилятора/линтера, которые будут контролировать программиста просто бессмысленно.
Функционал контроля чистоты можно вывести в специальные директивы компилятора, в итоге язык выиграет в надежности, но потеряет в простоте, это выливается в вопрос "что важнее?".
Я не спорю, что практики описанные в статье имеют свои преимущества, но применять повсеместно их конечно никто не будет.
Всегда интересовал такой вопрос: Со временем накапливаются «мертвые» кошельки с некоторым количеством валюты. Что будет через условные 1-2 поколения, ведь выпуск ограничен сверху и станет достаточно малым?
На счет F# не знаю, но в Haskell вроде как есть возможность подключать высокопроизводительный код на c++. Аналогичную черную магию практикует питон. Из тех бенчмарков что я видел производительность хуже на 0-10%.
Так же есть так называемые «Небезопасные» функции для работы напрямую с памятью, думаю будет примерно то же самое.
Насколько мне известно фича picture in picture доступна только для стандартного проигрывателя «Кино и ТВ», очень расстроило, что в edge не добавили такое закидывание обычного ютуба.
Иногда нужно сделать так, чтобы был обычный стиль, но например с выравниванием по правому краю, если потом, обновить стандартный стиль и текст набранный им, то выравнивание пропадает. Я понимаю, что можно создать специальный стиль с выравниванием по правому краю. Но потом, все общие изменения менять в 2-3 стилях сразу. Это как дублирующийся код, который сам по себе работает, но изменения связаны с повышенной вероятностью ошибки.
Жизнь так сложилась, что поступил. Обучили хорошо. Никаких взяток. Единственно что людей со знаниями между 2 и 3 выпустили на ровне с остальными.
Не все так категорично.
Около года частично занят работой с цифровыми сигнальными процессорами, правда задачи небольшого масштаба решаю. Должен отметить что эта статья является очень полезной для меня, когда представляешь примерно о чем технология, но суть, способы использования и отличия для себя не раскрыл.
Видел интересную мысль на хабре по этому поводу. Своими словами могу сформулировать так: Правило одного нового. Команда делает или новый проект на известном стеке технологий, или команда делает типовой проект на новом стеке технологий.
Ниша латеха вроде как математическое сообщество, научное сообщество и типографии. Уровень пользователей можно назвать продвинутым. В качестве применимости для ваших задач(как я понял быстрый документооборот) я вижу что латех мало подходит. Но если захотите написать корпоративную книгу, то теперь вы знаете инструмент.
Говорят Латех Тьюринг полный язык имеет в редакторе, но это не значит что все делается удобно. Из коробки есть счетчики, ссылки на счетчики, хорошая поддержка математических формул, библиография. Можно закомментировать кусок текста и он никак не будет влиять. Чуть пошаманив можно наверно сделать по параграфную генерацию удобную для пользователя. Ссылки на другие документы я не видел, может есть специализированные пакеты для этого. К недостаткам можно отнести сложность формирования таблиц. Панацеей Латех не может быть, но он всегда выдает стабильный результат в соответствии с заданным стилем. Просто так не поедет межстрочный интервал. Всегда одинаковый формат подписи к рисункам рамки на тех документах не съезжают в сторону по случайному клику мыши. И т.д.
Нормальный вариант защиты от лазеров смерти на орбите — база с мощным массивом лазеров на луне (правда там тоже есть микроатмосфера, да и вообще пыли много), где-нибудь на границе тени, чтобы была возможность получать энергию солнца, но физически углов на землю не было.
Кстати да, в статье говорится
Мне кажется, для обозначенных проблем должен неплохо подходить Латех, но у него один большой недостаток: он не MS Word.
Из текста не понятно реализована ли данная система или это просто рассуждение о проблематике.
Осознание того, что система сделана в MS Word и вероятно под капотом крутится нечто непонятное из макросов python и visual basic вгоняет в тоску мысли о поддержке данной системы. Индивидуально для себя в принципе можно побаловаться.
Разработка качественного плагина с поддержкой, расширяемым функционалом и каким-нибудь более приличным дизайном не рентабельна (если вы не собираетесь сделать стартап по этой тематике, а потом продавать плагин по всему миру за 5 баксов/месяц).
Нужна электро-калина, а не электро порше 911
Один раз разобравшись с современной ПЛИС от Xilinx можно работать на всей линейке ПЛИС Xilinx, конечно переход ISE -> Vivado не самый простой, но все же лучше чем выучить специфику работы на одном конкретном ЦСП, с одной единственной версией RTOS/BIOS и такими же единственными версиями пакетов (половину из которых еще надо правильно скомпилировать).
Как стандарт вещь достаточно хорошая, но реализация от TI просто кошмар (и они вроде как достаточно сильно отстают от последней версии стандарта).
ARM + ПЛИС есть на рынке. Intel купил Altera, значит и ПЛИС с x86 архитектурой так же вполне вероятна. Если не ошибаюсь в последние 5 лет проскакивала новость про системы ARM + x86 для устройств с переменной производительностью. Современные плис содержат небольшие блоки DSP для быстрой обработки специфических задач (например обработка видео). ARM + x86 + ПЛИС как мне кажется дает слишком большой оверхед в плане процессорных ядер.
Делал диплом на C6678, реализация синтеза РЛИ. Программировать и в самом деле сложно. Запуск OpenMP, FFT и TCP происходит без проблем по отдельности, но если надо запустить их совместно, то появляется тонна проблем по совместимости версий пакетов + подсистемы RTOS в качестве прослойки + отсутствие документации. Плюс спец IDE является так же привередливой и забагованной.
Разработчики поддерживают Keystone2, так что ситуация со временем не улучшается.
В результате огромный объем времени занимает изучение особенностей одного конкретного ЦСП. Лучше бы я учился прогать под ПЛИС, там хоть знания можно переиспользовать.
Использовать чистые функции, все аргументы передавать в явном виде,
а все взаимодействие с внешним миром оборачивать в монаду IO— не всегда возможно эффективно применить строгий функциональный подход, а где это возможно: лучше применять функциональные языки.С другой стороны требовать применения правил, когда явных ограничений нет — бессмысленно.
Заставлять программиста придерживаться строгой чистоты в коде как парадигмы можно сколько угодно, но без кнута в виде компилятора/линтера, которые будут контролировать программиста просто бессмысленно.
Функционал контроля чистоты можно вывести в специальные директивы компилятора, в итоге язык выиграет в надежности, но потеряет в простоте, это выливается в вопрос "что важнее?".
Я не спорю, что практики описанные в статье имеют свои преимущества, но применять повсеместно их конечно никто не будет.
Так же есть так называемые «Небезопасные» функции для работы напрямую с памятью, думаю будет примерно то же самое.
P.s. Сам не имею опыта в таких вещах.