Свою написал) Вообще, мне довольно редко требуется делать интерфейсы, но я каждый раз страдал от несовершенства архитектуры MVC. Пока не попробовал Лисп в этом плане. У меня интерфейсы чисто программные, без HTML, все элементы создаются динамически. Перезагрузок страницы нет, браузер выступает в роли эдакого продвинутого терминала, куда бэкенд засылает JS-код, который тупо исполняется через eval. JS компилируется из Лиспа на лету. Таким способом я обхожусь вообще без протоколов, если мне нужно изменить что-то на странице, я просто вызываю функцию, которая исполняется в браузере.
Лисп для фронтенда подходит замечательно, в виду своей гибкости. Его "костылеустойчивость" позволяет легко решать задачи типа "передвинуть вот эту кнопку вот сюда, а вот эту надпись сделать сиреневой по понедельникам в полнолуние" без полного перекраивания всей архитектуры проекта)
Я всегда относился к Фортрану как к "ассемблеру с формулами", чем он, собственно, изначально и являлся. В этом смысле 77-й идеален. А для сложных алгоритмов придумали Lisp)
А что помешает олигарху, живущему во дворце, заключить контракт с одной или несколькими женщинами и произвести себе потомков, которым, опять же, по контракту, передать дворец во владение?
Cтранно, всегда их называли нитями, насколько я помню. А про "волокна" впервые слышу. В Novell Netware 3-4 версий, например, их тоже называли "нитями", как ни странно, хотя там была невытесняющая многозадачность.
Периодическое pg_basebackup, например, раз в неделю
Инкрементальный бэкап всего сохраненного куда-то вовне, скажем, раз в сутки, а также полный бэкап каждый раз после pg_basebackup. Рекомендую duplicity для этого.
Непрерывная синхронизация журналов тоже куда-то вовне.
Периодически проверять, что:
Бэкап действительно происходит
Данные можно восстановить
Иметь где-то на внешней машине готовые скрипты для восстановления:
Последней копии, подтягивание в том числе "живой синхронизации" на момент сбоя
Восстановления на нужный момент времени, с созданием отдельной БД, на случай, если что-то произошло с базой и нужно достать неиспорченные данные.
ггг, я помню этот момент. Бумаг стало во много раз больше! Ну сколько той бумаги могла напечатать несчастная машинистка? А вот принтер железный, ему только бумагу загружай))
Они же и будут класть. В итоге способность ИИ к кодингу будет постепенно деградировать, из-за обучения на сгенерированных данных, так что, в какой-то момент внезапно снова появится потребность в живых программистах! Но их уже не будет.
ггг, всё так. Недавно коллеги меня попросили написать простую программку (должен был писать другой человек, но немного не осилил), делать выборки из каталога звезд, при этом нужно было прореживать выборку так, чтобы плотность звезд была меньше заданной, выкидывая самые слабые. Ну, первым делом я выяснил, что решение зависит от формы и размера тестовой площадки. Нашел экстремальные случаи, когда площадка задает ограничение на существование решения. Сильно задумался над единственностью решения при заданной площадке, но ни к чему определенному не пришел. Попробовал решить частную задачу -- просто построить распределение плотности, выяснил, что оно кусочно-постоянное, состоит из "островков" сложной формы. Сильно задумался о том, как определить форму этих "островков". Тут внезапно выяснилось, что дедлайн через два дня, так что пришлось наступить себе на горло и выдать решение, не идеальное, но достаточное для исходной задачи)
С чтением из памяти понятно, а вот как выгоднее писать? Когда все ядра пишут в одну область памяти или в разные? Допустим, чтение и запись не перекрываются.
Если программисту 47 лет, у него в телефонной книжке минимум десяток телефонов людей, любому из которых можно позвонить, пригласить по пивку и спросить, не задолбали ли его уже джуны на сеньерских позициях)
О, они таки выпускают Эльбрус с собственным набором команд? Я не очень в курсе, раньше, слышал, у них был блок аппаратной эмуляции x86, под которым был скрыт их VLIW. Отличная новость, если так!
У меня тоже два минуса с таким же обоснованием. Похоже, на сайте есть два (или один с двумя аккаунтами) участника, проминусовавших всех авторов сезона.
Свою написал) Вообще, мне довольно редко требуется делать интерфейсы, но я каждый раз страдал от несовершенства архитектуры MVC. Пока не попробовал Лисп в этом плане. У меня интерфейсы чисто программные, без HTML, все элементы создаются динамически. Перезагрузок страницы нет, браузер выступает в роли эдакого продвинутого терминала, куда бэкенд засылает JS-код, который тупо исполняется через eval. JS компилируется из Лиспа на лету. Таким способом я обхожусь вообще без протоколов, если мне нужно изменить что-то на странице, я просто вызываю функцию, которая исполняется в браузере.
Лисп для фронтенда подходит замечательно, в виду своей гибкости. Его "костылеустойчивость" позволяет легко решать задачи типа "передвинуть вот эту кнопку вот сюда, а вот эту надпись сделать сиреневой по понедельникам в полнолуние" без полного перекраивания всей архитектуры проекта)
Я всегда относился к Фортрану как к "ассемблеру с формулами", чем он, собственно, изначально и являлся. В этом смысле 77-й идеален. А для сложных алгоритмов придумали Lisp)
Как показала история, тоталитарные режимы нежизнеспособны. Так что власть ИИ не продлится долго :)
Возможности это проконтролировать, без полностью тоталитарной системы, нет никакой.
А что помешает олигарху, живущему во дворце, заключить контракт с одной или несколькими женщинами и произвести себе потомков, которым, опять же, по контракту, передать дворец во владение?
В студенчестве мы на longjmp даже вытесняющую многозадачность делали, под MSDOS)) А вот в Turbo Pascal приходилось примерно то же делать ассемблером.
Cтранно, всегда их называли нитями, насколько я помню. А про "волокна" впервые слышу. В Novell Netware 3-4 версий, например, их тоже называли "нитями", как ни странно, хотя там была невытесняющая многозадачность.
Резервное копирование по-взрослому, это:
Включение архивации журнала
Периодическое pg_basebackup, например, раз в неделю
Инкрементальный бэкап всего сохраненного куда-то вовне, скажем, раз в сутки, а также полный бэкап каждый раз после pg_basebackup. Рекомендую duplicity для этого.
Непрерывная синхронизация журналов тоже куда-то вовне.
Периодически проверять, что:
Бэкап действительно происходит
Данные можно восстановить
Иметь где-то на внешней машине готовые скрипты для восстановления:
Последней копии, подтягивание в том числе "живой синхронизации" на момент сбоя
Восстановления на нужный момент времени, с созданием отдельной БД, на случай, если что-то произошло с базой и нужно достать неиспорченные данные.
Не спрашивайте, как я пришел к такой схеме :(
ггг, я помню этот момент. Бумаг стало во много раз больше! Ну сколько той бумаги могла напечатать несчастная машинистка? А вот принтер железный, ему только бумагу загружай))
Будут брать в штат ИИ, очевидно же!
Они же и будут класть. В итоге способность ИИ к кодингу будет постепенно деградировать, из-за обучения на сгенерированных данных, так что, в какой-то момент внезапно снова появится потребность в живых программистах! Но их уже не будет.
ггг, всё так. Недавно коллеги меня попросили написать простую программку (должен был писать другой человек, но немного не осилил), делать выборки из каталога звезд, при этом нужно было прореживать выборку так, чтобы плотность звезд была меньше заданной, выкидывая самые слабые. Ну, первым делом я выяснил, что решение зависит от формы и размера тестовой площадки. Нашел экстремальные случаи, когда площадка задает ограничение на существование решения. Сильно задумался над единственностью решения при заданной площадке, но ни к чему определенному не пришел. Попробовал решить частную задачу -- просто построить распределение плотности, выяснил, что оно кусочно-постоянное, состоит из "островков" сложной формы. Сильно задумался о том, как определить форму этих "островков". Тут внезапно выяснилось, что дедлайн через два дня, так что пришлось наступить себе на горло и выдать решение, не идеальное, но достаточное для исходной задачи)
С чтением из памяти понятно, а вот как выгоднее писать? Когда все ядра пишут в одну область памяти или в разные? Допустим, чтение и запись не перекрываются.
Но помнят его никнейм в IRC!
Если программисту 47 лет, у него в телефонной книжке минимум десяток телефонов людей, любому из которых можно позвонить, пригласить по пивку и спросить, не задолбали ли его уже джуны на сеньерских позициях)
Пропустил, наверное. Но про то, что они умеют x86 я знаю, новость для меня, что они открывают доступ к собственной системе команд.
О, они таки выпускают Эльбрус с собственным набором команд? Я не очень в курсе, раньше, слышал, у них был блок аппаратной эмуляции x86, под которым был скрыт их VLIW. Отличная новость, если так!
Это точно не от 1 апреля новость?
У меня тоже два минуса с таким же обоснованием. Похоже, на сайте есть два (или один с двумя аккаунтами) участника, проминусовавших всех авторов сезона.