Сайт (и мобильную версию, и десктопную) делал я, так что вопрос по адресу. Я купил готовый шаблон в соответствии со своими представлениями о его функциях и удобстве, и немного адаптировал его для нашего содержания. Я же тестировал его на доступных мне телефонах. Плашка и размер текста тоже немного смутили, но критичной проблемы не увидел, поэтому оставил. Все-таки, профессиональные дизайнеры делали. В общем, спасибо за отзыв, подумаю, как это можно исправить и сделать лучше.
Для этого есть интеграции с другими системами. Остатки мы можем забирать из API маркетплейсов, выгружать из 1С, забирать из произвольных файлов в соответствии с тем, как это настроил пользователь. Например, типичный случай: продавец не весь ассортимент держит у себя на складе, часть - берет у поставщиков или партнеров. Те регулярно присылают ему на почту файл с информацией, что у них есть, в каком количестве, по какой цене. Наша система автоматически проверяет почту, разбирает новые файлы и обновляет информацию о ценах и наличии товаров. Я бы не сказал, что это именно складской учет, он сложнее. Скорее - единое окно для работы с максимумом доступной информации.
У меня были в последние лет 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% этот код никому нужен не будет в скором времени.
Подумайте над такой вещью: если вы регулярно встречаете проекты, где разработчики никак, блядь, не научатся, и эти проекты живы и разрастаются - можно ли предположить, что эти разработчики и их менеджмент, напротив, что-то такое умеют, что приводит их в эту точку развития?
Кстати, а много вы встречали проектов с хорошей по вашим критериям архитектурой, которые разрастались и гладко масштабировались без существенных изменений? Это были стартапы или кровавый энтерпрайз?
Сайт (и мобильную версию, и десктопную) делал я, так что вопрос по адресу. Я купил готовый шаблон в соответствии со своими представлениями о его функциях и удобстве, и немного адаптировал его для нашего содержания. Я же тестировал его на доступных мне телефонах. Плашка и размер текста тоже немного смутили, но критичной проблемы не увидел, поэтому оставил. Все-таки, профессиональные дизайнеры делали. В общем, спасибо за отзыв, подумаю, как это можно исправить и сделать лучше.
Для этого есть интеграции с другими системами. Остатки мы можем забирать из API маркетплейсов, выгружать из 1С, забирать из произвольных файлов в соответствии с тем, как это настроил пользователь. Например, типичный случай: продавец не весь ассортимент держит у себя на складе, часть - берет у поставщиков или партнеров. Те регулярно присылают ему на почту файл с информацией, что у них есть, в каком количестве, по какой цене. Наша система автоматически проверяет почту, разбирает новые файлы и обновляет информацию о ценах и наличии товаров. Я бы не сказал, что это именно складской учет, он сложнее. Скорее - единое окно для работы с максимумом доступной информации.
А ссылки на фиктивные судебные решения - это разве не оно?
Ну как минимум на неуважение к суду тянет, если не на что-то большее.
namespace Microsoft;
public lang C# {}
У меня были в последние лет 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 МВт.
Хотя, конечно, скорее всего под самой мощной молнией не буквально мощность подразумевалась.
Возможность соединить кривой - это линейная связность, односвязность - это про стягивание петель в точку.
Спасибо, теперь стало понятно.