У меня были в последние лет 6 айфон X, самсунг M21 и пиксель 6a.
Не уверен, что мой опыт релевантный, потому что я обхожусь минимумом приложений и фотографирую в основном документы. С этим справляются все телефоны. Из синхронизаций - только гугл календарь.
Наиболее критичное для меня - время работы от батареи, тут самсунг лучше всех, айфон хуже всех, пиксель посередине. Пикселя и самсунга всегда хватает, айфон бесит тем, что быстро разряжается.
По количеству предустановленного мусора, который не удаляется штатными средствами, самсунг хуже всех, пиксель и айфон на одном уровне.
По фотографиям - пиксель 6a примерно на уровне айфона X. Деталей больше у пикселя, по цветопередаче айфон приятнее. Самсунг значительно хуже.
Конкретно у моего пикселя экран синит, у айфона и самсунга приятнее цвета.
По ценам - айфон в разы дороже, пиксель незначительно дороже самсунга.
В общем, пиксель - хороший телефон, и за свою цену один из лучших.
Мне показалось, что ситуация иная. API уже спроектировано до нас и не нами, и является частью некоторой системы. Мы же реализуем совместимую, насколько возможно, систему, которая этот API предоставляет, и хотим запускать на ней приложения, спроектированные для оригинальной системы. Но, как всегда, ресурсы ограничены, и чем-то нужно жертвовать. Автор рассказывает, как именно сделать заглушки для методов, которые мы не смогли или не успели реализовать.
В статье приведены примеры c оригинальной Windows и её версией для Xbox. Я бы их дополнил Windows и WINE, Windows и ReactOS, .NET и Mono (хоть это уже история), Windows и ExaGear.
Но вот реально нужно ли? Это переусложнение конструкции и дополнительные точки отказа в самой нагруженной и одной из самых критичных для безопасности системе.
На это можно посмотреть с другой стороны. SQL - декларативный язык, то есть, запрос буквально описывает "что должно быть в результате", а не "как получить результат". Ответ на вопрос "как" - задача SQL движка. Соответственно, в запросе не может быть никаких ошибок, кроме синтаксических (запрос не выполняется в принципе) и логических (запрос возвращает не то, что задумывалось).
В реальности же есть и "откровенно фиговые по производительности" запросы, и хорошо оптимизированные запросы. Но оптимизация производительности запросов - это, по сути, плата за неоптимизированность движка, за то, что концепция декларативного языка не реализована в полной мере.
Я не рассматриваю тут императивные возможности диалектов SQL, там пользователь сам себе злобный буратино.
Практического смысла никакого, просто наблюдение на тему статьи. Бывает, интересно заняться какими-нибудь упоротыми расчетами без практического смысла. Возможно, это интересно кому-то ещё.
Лихо вы эзотерику в один ряд с наукой, пусть и в популярном изложении, поставили. Да и биохакинг тоже. Есть же медицина, есть куча разделов биологии, вот они - науки. Если вдаваться в детали, да, есть некоторые проблемы с воспроизводимостью результатов. Но - там и методологии, и рандомизированные исследования, и метаанализы, и все вот это вот. А вы "биохакинг".
По ходу прочтения возникла интересная, как мне кажется, задача.
Вот после первого фильтра у нас поляризованный свет. Если попытаться повернуть угол поляризации сразу на 90 градусов, его интенсивность уменьшится до нуля. Если сделать это в два захода, поворачивая на 45 градусов за раз, останется 50% от интенсивности. Если повернуть три раза на 30 градусов, останется 65% от интенсивности (если я не ошибся в расчетах). А если взять предел, то получается, что угол поляризации можно менять произвольно без потери интенсивности.
бесконечное число фильтров
Задача становится интереснее, если учитывать отражения света на поверхности фильтра, но в общем виде с учетом всех переотражений я не готов сейчас её решить.
Есть большая разница между проектом для большой корпорации и стартапом. В первом случае - да, можно потратить миллионы человеко-часов и сделать так, чтобы вам ни в коем случае на ум эта фраза не пришла.
Что касается стартапов, то их выживает на промежутке в 10 лет, по одним оценкам, не более 10%, по другим - не более 5%. И в данном случае плевать на качество кода, главное экономическую модель найти. С вероятностью 95% этот код никому нужен не будет в скором времени.
Подумайте над такой вещью: если вы регулярно встречаете проекты, где разработчики никак, блядь, не научатся, и эти проекты живы и разрастаются - можно ли предположить, что эти разработчики и их менеджмент, напротив, что-то такое умеют, что приводит их в эту точку развития?
Кстати, а много вы встречали проектов с хорошей по вашим критериям архитектурой, которые разрастались и гладко масштабировались без существенных изменений? Это были стартапы или кровавый энтерпрайз?
Любая петля внутри кривой С стягивается в одну точку, а во внешней части есть петля, которая не стягивается (если "опоясать" область С)
В принципе, это понятно и даже интуитивно. Но раньше по тексту было
Более общее утверждение, получившее название теоремы Шенфлиса гласит, что две области, на которые делит плоскость замкнутая кривая, устроены одинаковым образом.
Если я правильно все понял, то 'устроены одинаковым образом' значит, что либо обе обладают односвязностью, либо обе ей не обладают.
Но тогда рисунок и его интуитивное понимание противоречат теореме. Ведь внутренняя область односвязна, а внешняя - нет.
Забавно, но похоже ответ на первый вопрос: никто не знает. По крайней мере, нет общепринятого объяснения. В общем случае получается нелокальное преобразование, которое становится локальным в случае с целым показателем. Это не соответствует ни известным физическим процессам, ни математическим вопросам.
Ниже я привел ссылку на видео по этой теме, ответ оттуда.
У меня были в последние лет 6 айфон X, самсунг M21 и пиксель 6a.
Не уверен, что мой опыт релевантный, потому что я обхожусь минимумом приложений и фотографирую в основном документы. С этим справляются все телефоны. Из синхронизаций - только гугл календарь.
Наиболее критичное для меня - время работы от батареи, тут самсунг лучше всех, айфон хуже всех, пиксель посередине. Пикселя и самсунга всегда хватает, айфон бесит тем, что быстро разряжается.
По количеству предустановленного мусора, который не удаляется штатными средствами, самсунг хуже всех, пиксель и айфон на одном уровне.
По фотографиям - пиксель 6a примерно на уровне айфона X. Деталей больше у пикселя, по цветопередаче айфон приятнее. Самсунг значительно хуже.
Конкретно у моего пикселя экран синит, у айфона и самсунга приятнее цвета.
По ценам - айфон в разы дороже, пиксель незначительно дороже самсунга.
В общем, пиксель - хороший телефон, и за свою цену один из лучших.
Мне показалось, что ситуация иная. API уже спроектировано до нас и не нами, и является частью некоторой системы. Мы же реализуем совместимую, насколько возможно, систему, которая этот API предоставляет, и хотим запускать на ней приложения, спроектированные для оригинальной системы. Но, как всегда, ресурсы ограничены, и чем-то нужно жертвовать. Автор рассказывает, как именно сделать заглушки для методов, которые мы не смогли или не успели реализовать.
В статье приведены примеры c оригинальной Windows и её версией для Xbox. Я бы их дополнил Windows и WINE, Windows и ReactOS, .NET и Mono (хоть это уже история), Windows и ExaGear.
Согласен, можно.
Но вот реально нужно ли? Это переусложнение конструкции и дополнительные точки отказа в самой нагруженной и одной из самых критичных для безопасности системе.
В шести направлениях? В нашем трехмерном мире всего шесть степеней свободы, три для поступательного движения и три для вращательного.
По сути, поступательное движение соответствует движению колеса вперед-назад и вверх-вниз, и вылету, а вращательное - повороту, сходу и развалу.
Вот реально этим всем нужно управлять в тачке независимо и динамически? Зачем? В какой ситуации потребуется двигать колесо вдоль автомобиля?
В статье прекрасно проиллюстрирована разработка в соответствии с принципами RDD, или resume driven development.
На это можно посмотреть с другой стороны. SQL - декларативный язык, то есть, запрос буквально описывает "что должно быть в результате", а не "как получить результат". Ответ на вопрос "как" - задача SQL движка. Соответственно, в запросе не может быть никаких ошибок, кроме синтаксических (запрос не выполняется в принципе) и логических (запрос возвращает не то, что задумывалось).
В реальности же есть и "откровенно фиговые по производительности" запросы, и хорошо оптимизированные запросы. Но оптимизация производительности запросов - это, по сути, плата за неоптимизированность движка, за то, что концепция декларативного языка не реализована в полной мере.
Я не рассматриваю тут императивные возможности диалектов SQL, там пользователь сам себе злобный буратино.
Практического смысла никакого, просто наблюдение на тему статьи. Бывает, интересно заняться какими-нибудь упоротыми расчетами без практического смысла. Возможно, это интересно кому-то ещё.
Лихо вы эзотерику в один ряд с наукой, пусть и в популярном изложении, поставили. Да и биохакинг тоже.
Есть же медицина, есть куча разделов биологии, вот они - науки. Если вдаваться в детали, да, есть некоторые проблемы с воспроизводимостью результатов. Но - там и методологии, и рандомизированные исследования, и метаанализы, и все вот это вот. А вы "биохакинг".
По ходу прочтения возникла интересная, как мне кажется, задача.
Вот после первого фильтра у нас поляризованный свет. Если попытаться повернуть угол поляризации сразу на 90 градусов, его интенсивность уменьшится до нуля. Если сделать это в два захода, поворачивая на 45 градусов за раз, останется 50% от интенсивности. Если повернуть три раза на 30 градусов, останется 65% от интенсивности (если я не ошибся в расчетах). А если взять предел, то получается, что угол поляризации можно менять произвольно без потери интенсивности.
Задача становится интереснее, если учитывать отражения света на поверхности фильтра, но в общем виде с учетом всех переотражений я не готов сейчас её решить.
Вы утверждаете, что предел суммы 1 + 1/4 + 1/9 + 1/16 + 1/25 + 1/36 + … меняется со временем?
У меня получается, что для других газов (пропан, бутан) объем продуктов должен быть больше объема реагентов.
На выходе все те же углекислый газ и вода, но в большем количестве в расчете на молекулу пропана или бутана.
Думаю, счет уже идет на миллионы человеко-часов.
Есть большая разница между проектом для большой корпорации и стартапом. В первом случае - да, можно потратить миллионы человеко-часов и сделать так, чтобы вам ни в коем случае на ум эта фраза не пришла.
Что касается стартапов, то их выживает на промежутке в 10 лет, по одним оценкам, не более 10%, по другим - не более 5%. И в данном случае плевать на качество кода, главное экономическую модель найти. С вероятностью 95% этот код никому нужен не будет в скором времени.
Подумайте над такой вещью: если вы регулярно встречаете проекты, где разработчики никак, блядь, не научатся, и эти проекты живы и разрастаются - можно ли предположить, что эти разработчики и их менеджмент, напротив, что-то такое умеют, что приводит их в эту точку развития?
Кстати, а много вы встречали проектов с хорошей по вашим критериям архитектурой, которые разрастались и гладко масштабировались без существенных изменений? Это были стартапы или кровавый энтерпрайз?
Ну хотя бы порядки величин дали бы. Типа молния обычной грозы - 10 кВт, молния суперячейки - 100 кВт, молния супервулкана - 1 МВт.
Хотя, конечно, скорее всего под самой мощной молнией не буквально мощность подразумевалась.
Возможность соединить кривой - это линейная связность, односвязность - это про стягивание петель в точку.
Спасибо, теперь стало понятно.
А можете пояснить этот момент?
В принципе, это понятно и даже интуитивно. Но раньше по тексту было
Если я правильно все понял, то 'устроены одинаковым образом' значит, что либо обе обладают односвязностью, либо обе ей не обладают.
Но тогда рисунок и его интуитивное понимание противоречат теореме. Ведь внутренняя область односвязна, а внешняя - нет.
Забавно, но похоже ответ на первый вопрос: никто не знает. По крайней мере, нет общепринятого объяснения. В общем случае получается нелокальное преобразование, которое становится локальным в случае с целым показателем. Это не соответствует ни известным физическим процессам, ни математическим вопросам.
Ниже я привел ссылку на видео по этой теме, ответ оттуда.
Недавно наткнулся на одно занимательное видео на эту тему. https://www.youtube.com/watch?v=2dwQUUDt5Is. Рекомендую посмотреть, очень наглядно все объясняется.
Если страховая будет сама определять, кого страховать и на каких условиях, для сомнительных банков стоимость страховки вырастет и уравновесит систему.