Бактерии не могут свободно перемешиваться с воздухом, водой и почвой. Многим из них нужны определенные условия для выживания. Потому, если Вы поцеловались, то можете заселить свой ЖКТ определённым видом, а если 3 ч. сидели рядом на спектакле, то не заселите.
Переваривание -- не вульгарная химреакция соединения кислорода и водорода. (Иначе бы уже было известно какое вещество добавить к полиэтилену, чтобы он разложился. Тогда бы его и не начали использовать, т.к. химвещества, в отличие от бактерий, легко перемешиваются с воздухом, водой и почвой.)
В статье и написано, что один из вариантов --- исследовать способ переваривания полиэтилена в жир внутри этих личинок.
В статье про это и написано, что это один из путей. Только чисто химическим путем тут ничего не добьешься, т. к. в статье же написано, что полиэтилен весьма устойчивое вещество. Потому попытки найти биологический механизм переваривания внутри этих личинок --- вариант, как пишут в статье. У насекомых "переваривание" частенько с помощью бактерий-симбионтов происходит, ввиду незначительных размеров.
Поучиться университету --- всегда почётно! Согласен!
Однако, есть моноформаты (быстрые в программировании), а есть контейнерные форматы, типа TIFF, позволяющие кодировать любые сеточные (растровые) структуры любыми кодеками. Мы обменивались, например, с заказчиками полями, где каждая ячейка была вещественным (Sic!) числом в начале 90-х. Это было уже в стандарте. )) Да, и изучал я это в университете, который до моды 90-х назывался институт. ))
Кто знает отличия институтского образования от университетского (до момента, когда все стали университетами из-за моды западной) смогут тут Вам подсказать.
Автору советую прочесть спецификацию формата TIFF. Можно будет почерпнуть много интересного. А, для работы с ним есть открытые библиотеки на C++ --- тоже можно посмотреть, как делается код.
Если интерес останется, то предложил бы ему вступить в группу разработчиков TIFF, куда и предложить какие-то вещи.
Т. е. для общества и самого автора ценнее будет расширить tiff, чем пилить вещь в себе.
Молодец. С чего-то надо начинать.
Мы в 16 тоже написали компилятор для Си с ассемблерными вставками для архитектуры PDP 11, (было реализовано подмножество Си), не все команды), что потом сильно помогало. Интернет тогда был не в свободном доступе, потому пилили автономный проект. Сейчас же можно работать с мировым сообществом, а не отдельно в пещере программировать.
Не скажите! В школе как-то (класс 7-8) увлеклись с другом в 80-е. БК 0010 сильно помогал в визуализации наших исследований. На миллиметровке, конечно, интерес бы скорее затух. А, так, до конца школы складывали / раскладывали функции.
А, почему воксели, а не вокселы. Воксел же, а не воксель. +Параграф 40 Розенталя постулирует фонетическое заимствование в русском языке, а мягкого знака в английском нет. ))
Параграф 40 Розенталя постулирует фонетический способ заимствования иностранных слов в русском языке. Мягкого знака в английском нет. В науке и технике используют: пиксел, воксел... Неграмотный журналист, когда в 90-х хлынула волна двумерной графики, использовал "пиксель". И... понеслось. 3-мерная графика пока не популярна у бабушек и нет её на всех компах. Потому пока воксел, а не воксель. ))
Кстати, др. неграмотный журналист в Штатах также познакомился с индустрией, но перепутал хакеров с крекерами, потому там тоже понеслось... про злых хакеров. Хотя этот термин обозначает крутого разработчика, а не киберпреступника.
А, какую функцию тут выполняют пальцы? Представление и память или суммирование, а результат можно где-то в другом месте держать (в уме, на бумаге, в голограмме...)?
Да, не. OLTP --- это совершить транзакцию, т. е. группу операций, представляющих логически единое действие, по изменению данных в БД так, чтобы сохранилась целостность. Это программист делает --- пишет SQL-скрипт. Вы так и написали. А, как это сделать с приемлемой скоростью в реальной системе -- это уже задача инженеров и админов.
Программист может разрабатывать скрипт на однопользовательской СУБД, крутящейся на его рабочей станции, с небольшой тестовой БД. Инженеры же развернут систему на кластере серверов аппаратных с балансировщиком нагрузки, проиндексируют нужные таблицы, разобьют их на части, поколдуют с настройками, чтобы добиться нужной производительности. К самому скрипту, реализующему логику работы системы по принципам OLTP, это отношения не имеет.
Вот, о чём я.
На практике, конечно, бывает нужно и денормализацию провести с дублированием данных, чтобы повысить производительность. Тогда инженеры и программисты вместе решают эти вопросы, т. к. скрипт придётся переписывать.
OLTP --- это про логику обработки данных: запись, изменение, удаление, как правило, в плоские таблицы. Так же, как и OLAP --- про логику обработки, но уже в виде анализа какого-нибудь гиперкуба.
А скорость --- это уже особенности конкретной реализации.
Никто не запрещает построить OLTP-систему на базе бумажных журналов, человеков-операторов и телефонной или голубиной связи. Логика системы от такой реализации не пострадает. Быстродействие и надёжность --- да. Но, как говорит Каневский, "это уже совсем другая история".
Корм животным или сами умирают через три дня, пишут в статье.
Свечи в основном из стеарина начали делать где-то с XIX века, если не раньше...
Бактерии не могут свободно перемешиваться с воздухом, водой и почвой. Многим из них нужны определенные условия для выживания. Потому, если Вы поцеловались, то можете заселить свой ЖКТ определённым видом, а если 3 ч. сидели рядом на спектакле, то не заселите.
Переваривание -- не вульгарная химреакция соединения кислорода и водорода. (Иначе бы уже было известно какое вещество добавить к полиэтилену, чтобы он разложился. Тогда бы его и не начали использовать, т.к. химвещества, в отличие от бактерий, легко перемешиваются с воздухом, водой и почвой.)
В статье и написано, что один из вариантов --- исследовать способ переваривания полиэтилена в жир внутри этих личинок.
В статье про это и написано, что это один из путей. Только чисто химическим путем тут ничего не добьешься, т. к. в статье же написано, что полиэтилен весьма устойчивое вещество. Потому попытки найти биологический механизм переваривания внутри этих личинок --- вариант, как пишут в статье. У насекомых "переваривание" частенько с помощью бактерий-симбионтов происходит, ввиду незначительных размеров.
Поучиться университету --- всегда почётно! Согласен!
Однако, есть моноформаты (быстрые в программировании), а есть контейнерные форматы, типа TIFF, позволяющие кодировать любые сеточные (растровые) структуры любыми кодеками. Мы обменивались, например, с заказчиками полями, где каждая ячейка была вещественным (Sic!) числом в начале 90-х. Это было уже в стандарте. )) Да, и изучал я это в университете, который до моды 90-х назывался институт. ))
Кто знает отличия институтского образования от университетского (до момента, когда все стали университетами из-за моды западной) смогут тут Вам подсказать.
До сих пор на смартфоне играю, и внуков подсадил на неё. )))
Лоде Рунеров, Сокобанов, Тетрисов и разных Ксониксов/Антиксониксов было на всех платформах полно. Может, ТС хотел именно эксклюзивы указать?
За FAR'ом тогда уж. ))
1, 10, 11, 100, 101... Вышел зайчик погулять. ))
Да! Аналогично. )) Великая картинка правды. Смеяться над ней по настоящему могут не только лишь все. Мало, кто это может.
(Лишь познавшие.)))
Автору советую прочесть спецификацию формата TIFF. Можно будет почерпнуть много интересного. А, для работы с ним есть открытые библиотеки на C++ --- тоже можно посмотреть, как делается код.
Если интерес останется, то предложил бы ему вступить в группу разработчиков TIFF, куда и предложить какие-то вещи.
Т. е. для общества и самого автора ценнее будет расширить tiff, чем пилить вещь в себе.
Молодец. С чего-то надо начинать.
Мы в 16 тоже написали компилятор для Си с ассемблерными вставками для архитектуры PDP 11, (было реализовано подмножество Си), не все команды), что потом сильно помогало. Интернет тогда был не в свободном доступе, потому пилили автономный проект. Сейчас же можно работать с мировым сообществом, а не отдельно в пещере программировать.
Не скажите! В школе как-то (класс 7-8) увлеклись с другом в 80-е. БК 0010 сильно помогал в визуализации наших исследований. На миллиметровке, конечно, интерес бы скорее затух. А, так, до конца школы складывали / раскладывали функции.
А, почему воксели, а не вокселы. Воксел же, а не воксель. +Параграф 40 Розенталя постулирует фонетическое заимствование в русском языке, а мягкого знака в английском нет. ))
https://ru.m.wiktionary.org/wiki/воксел
Эффективные менеджеры умеют поставить дело! )))
IBM PC вышел в 1981, советский ДВК --- в 1983. Потом, и куча бытовых у нас была: Микро, Радио, БК 0010...
Лично в 80-х работал на куче разных социалистических персоналок: и наших, и стран --- членов СЭВ.
Режим CGA 640x200 --- бинарный. Цветные индексированные --- 320x200, что посчитали мало для GUI.
Параграф 40 Розенталя постулирует фонетический способ заимствования иностранных слов в русском языке. Мягкого знака в английском нет. В науке и технике используют: пиксел, воксел... Неграмотный журналист, когда в 90-х хлынула волна двумерной графики, использовал "пиксель". И... понеслось. 3-мерная графика пока не популярна у бабушек и нет её на всех компах. Потому пока воксел, а не воксель. ))
Кстати, др. неграмотный журналист в Штатах также познакомился с индустрией, но перепутал хакеров с крекерами, потому там тоже понеслось... про злых хакеров. Хотя этот термин обозначает крутого разработчика, а не киберпреступника.
Жуткий текст!
А, какую функцию тут выполняют пальцы? Представление и память или суммирование, а результат можно где-то в другом месте держать (в уме, на бумаге, в голограмме...)?
Да, не. OLTP --- это совершить транзакцию, т. е. группу операций, представляющих логически единое действие, по изменению данных в БД так, чтобы сохранилась целостность. Это программист делает --- пишет SQL-скрипт. Вы так и написали. А, как это сделать с приемлемой скоростью в реальной системе -- это уже задача инженеров и админов.
Программист может разрабатывать скрипт на однопользовательской СУБД, крутящейся на его рабочей станции, с небольшой тестовой БД. Инженеры же развернут систему на кластере серверов аппаратных с балансировщиком нагрузки, проиндексируют нужные таблицы, разобьют их на части, поколдуют с настройками, чтобы добиться нужной производительности. К самому скрипту, реализующему логику работы системы по принципам OLTP, это отношения не имеет.
Вот, о чём я.
На практике, конечно, бывает нужно и денормализацию провести с дублированием данных, чтобы повысить производительность. Тогда инженеры и программисты вместе решают эти вопросы, т. к. скрипт придётся переписывать.
OLTP --- это про логику обработки данных: запись, изменение, удаление, как правило, в плоские таблицы. Так же, как и OLAP --- про логику обработки, но уже в виде анализа какого-нибудь гиперкуба.
А скорость --- это уже особенности конкретной реализации.
Никто не запрещает построить OLTP-систему на базе бумажных журналов, человеков-операторов и телефонной или голубиной связи. Логика системы от такой реализации не пострадает. Быстродействие и надёжность --- да. Но, как говорит Каневский, "это уже совсем другая история".