Окей, простой пример: есть два интернет-магазина, которые их владелец решил слить в один. Магазины написаны на каком-нибудь Django, для работы с БД используется ORM. Никто просто не заморачивался с настройкой какого-то глобального sequence для обоих баз, да и вообще не планировалось никакое взаимодействие между этими базами. В результате получаем огромный геморрой… которого можно легко избежать, используя UUID.
Ну и при использовании UUID не нужно предварительно делать никакую вставку (которая в первую очередь является усложнением кода). Просто генерируем новое значение и используем его, а затем в одной транзакции вставляем данные в базу.
Извините, но нет. Если сначала получать идентификатор из сиквенса, а потом сохранять запись, то это будет лишний запрос к базе. Разные множества — это дополнительная настройка, причем если использовать те же целочисленные ключи, это не гарантирует невозможности коллизий. Что то, что другое выглядит откровенно костыльно.
При использовании UUID в качестве первичного ключа есть еще пара преимуществ:
Бывает такой относительно редкий кейс, когда нужно слить две базы данных. При использовании serial скорее всего будут коллизии ключей, и придется долго и муторно изменять значения у первичных и внешних ключей одной из баз. С UUID такой проблемы нет, коллизия оооочень маловероятна.
Более удобная подготовка данных. В случае с serial мы можем получить идентификатор записи только при запросе к базе — то есть нужно все операции оборачивать в транзакцию и выполнять последовательно, что в некоторых случаях может привести к долгим транзакциям в БД. В случае с UUID можно заранее сгенерировать случайный идентификатор и использовать его везде, где нужно, и только потом сохранить пачку уже полностью подготовленных данных в базе.
Есть небольшой забавный момент.
Если генерировать .xlsx или .ods файл полностью на лету (формируя XML и сразу сжимая его в ZIP), получившийся документ будет нормально открываться во всех офисных пакетах, кроме MS Excel. Последний выведет окошко с ошибкой и предложит восстановить файл, правда после восстановления тоже нормально его откроет.
Смысл в том, что MS Excel не может открыть ZIP-файлы, у которых заранее неизвестен размер запакованных данных (т. е. в которых используется структура data descriptor). Если же сначала полностью сгенерировать XML, чтобы размер был известен, а потом запаковать, то все будет нормально. Только такой вариант явно не «на лету» :)
Согласен, перепутал. Тем не менее задалбывает лазить по чужим исходникам в попытках понять, какой аргумент и какого типа должен быть передан в функцию.
Мне кажется, самая большая «сокрытая драгоценность» — это строгая типизация. Она тоже есть в документации, про нее говорят и все такое, но блин, в подавляющем большинстве библиотек и приложений ей даже не пахнет. В том же Flask зачатки строгой типизации были добавлены всего месяц назад, в Django ей даже не пахнет. А ведь она появилась пять лет назад, в 2015 году, позволяет избежать огромной кучи ошибок и дает огромное преимущество при подсказках в IDE.
А мне очень «нравится», что когда отваливается X-сервер, отваливаются также все запущенные приложения и сеанс полностью начинается сначала.
В той же винде при аналогичной ситуации (критическая ошибка композитора либо explorer) перезапускается лишь отвалившийся процесс, все остальные приложения этого практически не замечают. Ах, да, а еще в винде можно поменять драйвер видеокарты на лету, без перезапуска всего и вся.
Проект DO-RA был рождён в марте 2011 г. после ядерной катастрофы на АЭС Фукусима в Японии и задумывался в виде гаджета – персонального дозиметра-радиометра работающего с одноименным ПО – DO-RA.Soft на любом смартфоне под мобильные платформы: iOS, Android, WP и др., а также на стационарных платформах: Windows/Linux/MacOS.
В конце 2017 года в рюкзаке китайского туриста из Шеньчженя в Москву прибыл десяток долгожданных образцов тестовой партии DO-RA.Q, произведённых на основе нашей конструкторской документации (КД) в Китае. Кстати, КД тогда было поручено разрабатывать крупнейшему Дизайн-Центру в Восточной Европе — компании ПРОМВАД. Всё было сделано чётко, в формате IPC, на хорошем английском, в том числе для роботизированного производства электронных изделий за рубежом.
Вы уже определитесь, а? То ли вы в той статье дали неверную информацию, то ли в этом комментарии.
Вполне интересны — хотя бы тем, что это будет первая реальная информация с вашей стороны.
И блин… Шесть лет на разработку прототипа, два года на разбан в Apple… Хотя чему я еще удивляюсь?
Я довольно многому научился, делая модицикации к игре Teeworlds — клиент-серверному взаимодействию, работе с юникодом, отправке HTTP запросов ручками, внедрению скриптов на Lua, написанию игровых ботов со сложной логикой (моего бота на замкнутых картах ненавидели, он играл на уровне выше среднего игрока… правда на картах с дырками упорно в них падал).
Вы сейчас этим комментарием малость опозорились (хотя куда уж еще позориться-то, после всего сказанного...)
Количество активных устройств — это одно. Количество конкретных устройств — это другое. Количество устройств с конкретной версией ОС — это третье.
Официальных данных по использованию конкретных версий ОС нет, только для пары последних версий. Есть сторонняя страничка, на которой собрана эта кратная официальная информация за несколько лет. Начинается она с 2016 года и iOS 8, и уже в то время только 5% устройств использовали более раннюю версию.
Есть небольшая статистика по одному приложению от его разработчика. Приложение не сильно популярное, 0.1 процент — это одна-две установки.
Еще существует инструмент для аналитики iTunes Connect. Сам не пользовался им (не разрабатываю под iOS), но судя по скриншотам, информация о версиях в нем присутствует. И судя по этим скриншотам, процент устройств на версии ниже iOS 8 катастрофически мал.
Пожалуйста, если я не прав и у вас есть действительно есть активные клиенты с устройствами 2012 года и версиями iOS ниже 8, приведите хоть какие-то реальные данные. Я понимаю, что значит понятие «коммерческая тайна» и не прошу полных данных по количеству всех клиентов — только по устаревшим версиям. Пока что все, что от вас слышно, это пустые и противоречивые слова да завуалированные оскорбления.
2. Для подобного существует сторонняя телеметрия. Достаточно однократно отправлять обезличенную инфомацию об устройстве (при его первом запуске).
3. Не помню, чтобы вы осуществляли краудфандинг.
4. Очень даже принято.
5. Оу. Если уж приводить цитаты невпопад… Ой, вообще, наверно, это от перцу люди делаются вспыльчивые, — продолжала она, очень довольная, что сама обнаружила вроде как новый закон природы, — а от уксуса делаются кислые… а от хрена — сердитые… а от… а от… а вот от конфет-то дети становятся ну прямо прелесть! Потому их все так и любят! (Алиса в стране Чудес, другая сказка)
Проект DO-RA был рождён в марте 2011 г. после ядерной катастрофы на АЭС Фукусима в Японии и задумывался в виде гаджета – персонального дозиметра-радиометра работающего с одноименным ПО – DO-RA.Soft на любом смартфоне под мобильные платформы: iOS, Android, WP и др., а также на стационарных платформах: Windows/Linux/MacOS.
В конце 2017 года в рюкзаке китайского туриста из Шеньчженя в Москву прибыл десяток долгожданных образцов тестовой партии DO-RA.Q, произведённых на основе нашей конструкторской документации (КД) в Китае. Кстати, КД тогда было поручено разрабатывать крупнейшему Дизайн-Центру в Восточной Европе — компании ПРОМВАД. Всё было сделано чётко, в формате IPC, на хорошем английском, в том числе для роботизированного производства электронных изделий за рубежом.
Если у вас первая тестовая партия появилась через 6 (sic!) лет после рождения идеи, о каких конкурентах тут можно говорить? Если в 2011, после ваших первых постов, люди хотели купить подобное устройство, то теперь уже есть куча аналогов.
К примеру, устройство Flipper Zeroбыло презентовано в конце 2019, а в текущий момент (судя по постам на Хабре) оно готовится к релизу.
Извините, но с таким подходом к бизнесу — шесть лет до производства, обвинения Apple в своих косяках, наезды на всех подряд, — вы действительно обвиняете конкурентов в сливе кармы?
Окей, простой пример: есть два интернет-магазина, которые их владелец решил слить в один. Магазины написаны на каком-нибудь Django, для работы с БД используется ORM. Никто просто не заморачивался с настройкой какого-то глобального sequence для обоих баз, да и вообще не планировалось никакое взаимодействие между этими базами. В результате получаем огромный геморрой… которого можно легко избежать, используя UUID.
Ну и при использовании UUID не нужно предварительно делать никакую вставку (которая в первую очередь является усложнением кода). Просто генерируем новое значение и используем его, а затем в одной транзакции вставляем данные в базу.
Извините, но нет. Если сначала получать идентификатор из сиквенса, а потом сохранять запись, то это будет лишний запрос к базе. Разные множества — это дополнительная настройка, причем если использовать те же целочисленные ключи, это не гарантирует невозможности коллизий. Что то, что другое выглядит откровенно костыльно.
При использовании UUID в качестве первичного ключа есть еще пара преимуществ:
serialскорее всего будут коллизии ключей, и придется долго и муторно изменять значения у первичных и внешних ключей одной из баз. С UUID такой проблемы нет, коллизия оооочень маловероятна.serialмы можем получить идентификатор записи только при запросе к базе — то есть нужно все операции оборачивать в транзакцию и выполнять последовательно, что в некоторых случаях может привести к долгим транзакциям в БД. В случае с UUID можно заранее сгенерировать случайный идентификатор и использовать его везде, где нужно, и только потом сохранить пачку уже полностью подготовленных данных в базе.Если генерировать .xlsx или .ods файл полностью на лету (формируя XML и сразу сжимая его в ZIP), получившийся документ будет нормально открываться во всех офисных пакетах, кроме MS Excel. Последний выведет окошко с ошибкой и предложит восстановить файл, правда после восстановления тоже нормально его откроет.
Смысл в том, что MS Excel не может открыть ZIP-файлы, у которых заранее неизвестен размер запакованных данных (т. е. в которых используется структура data descriptor). Если же сначала полностью сгенерировать XML, чтобы размер был известен, а потом запаковать, то все будет нормально. Только такой вариант явно не «на лету» :)
В той же винде при аналогичной ситуации (критическая ошибка композитора либо explorer) перезапускается лишь отвалившийся процесс, все остальные приложения этого практически не замечают. Ах, да, а еще в винде можно поменять драйвер видеокарты на лету, без перезапуска всего и вся.
И блин… Шесть лет на разработку прототипа, два года на разбан в Apple… Хотя чему я еще удивляюсь?
Количество активных устройств — это одно. Количество конкретных устройств — это другое. Количество устройств с конкретной версией ОС — это третье.
Официальных данных по использованию конкретных версий ОС нет, только для пары последних версий. Есть сторонняя страничка, на которой собрана эта кратная официальная информация за несколько лет. Начинается она с 2016 года и iOS 8, и уже в то время только 5% устройств использовали более раннюю версию.
Есть небольшая статистика по одному приложению от его разработчика. Приложение не сильно популярное, 0.1 процент — это одна-две установки.
Еще существует инструмент для аналитики iTunes Connect. Сам не пользовался им (не разрабатываю под iOS), но судя по скриншотам, информация о версиях в нем присутствует. И судя по этим скриншотам, процент устройств на версии ниже iOS 8 катастрофически мал.
Пожалуйста, если я не прав и у вас есть действительно есть активные клиенты с устройствами 2012 года и версиями iOS ниже 8, приведите хоть какие-то реальные данные. Я понимаю, что значит понятие «коммерческая тайна» и не прошу полных данных по количеству всех клиентов — только по устаревшим версиям. Пока что все, что от вас слышно, это пустые и противоречивые слова да завуалированные оскорбления.
3. Не помню, чтобы вы осуществляли краудфандинг.
4. Очень даже принято.
5. Оу. Если уж приводить цитаты невпопад… Ой, вообще, наверно, это от перцу люди делаются вспыльчивые, — продолжала она, очень довольная, что сама обнаружила вроде как новый закон природы, — а от уксуса делаются кислые… а от хрена — сердитые… а от… а от… а вот от конфет-то дети становятся ну прямо прелесть! Потому их все так и любят! (Алиса в стране Чудес, другая сказка)
Цитата и другой вашей статьи:
Если у вас первая тестовая партия появилась через 6 (sic!) лет после рождения идеи, о каких конкурентах тут можно говорить? Если в 2011, после ваших первых постов, люди хотели купить подобное устройство, то теперь уже есть куча аналогов.
К примеру, устройство Flipper Zero было презентовано в конце 2019, а в текущий момент (судя по постам на Хабре) оно готовится к релизу.
Извините, но с таким подходом к бизнесу — шесть лет до производства, обвинения Apple в своих косяках, наезды на всех подряд, — вы действительно обвиняете конкурентов в сливе кармы?