Pull to refresh
0
@SSSurkvread⁠-⁠only

User

Send message
начнём с того что эти люди должны быть. Если их нет то их надо нанять либо заказать эти услуги у стороннего исполнителя. Нужна стратегия оплаты/премирования за лишние рабочие часы и тоже самое за невыполнение работы (с планом исправления ошибок). Это всё территориально от Калининграда до Владивостока. Школ несколько десятков тысяч, все различаются по доступности и оснащённости
Это серьёзные проекты уровня государства. С огромными суммами.

И, пожалуйста, без этого типового «ха, надо просто скачть дистрибутив поновей». Просто печать сд-образов и рассылка их во все школы рф это уже серьёзная логистическая задача (нисколько не програмастская).
эта строчка есть в каждой шапкозакидательской статье про бесплатнокрутоопенсорсно.

В РФ в образовательной системе пытались перейти с микрософтовской продукции на опенсорс. В китае на госпредприятиях вводили. Много ещё где. Но получилось далеко не у всех. Именно поэтому строчка от тех у кого получилось

«Выяснилось также, что в пятилетней перспективе остаться с Windows выходит дешевле.»

требует к себе повышенного внимания. И ознакомления с методикой оценки.
Выяснилось также, что в пятилетней перспективе остаться с Windows выходит дешевле.

— вот главная строчка в тексте.
Конечно нет. Разложить дерево значений в таблицу это слишком простая задача чтоб реализовывать её отдельным модулем.
нужно взять SQLite раз он подходит и написать скрипт/программу которая раскладывает свойства жаваскриптовых объектов на таблицу связанную саму с собой (т.е. дерево). Делается такое за неделю со всеми тестами и проверками на рабочих обхёмах данных и в сходном с рабочим окружении.

Делал так не раз.
сколько не видел носкльщиков, всегда одно и то же
1. сначала начинают проект на NoSQL бд т.к. SQL это непонятно и сложно
2. появляются проблемы и выясняется что требования к ссылочной целостности и строгость схемы в SQL-серверах не просто так
3. пытаются изобрести велосипед и воссоздать всё это средствами выбранного NoSQL решения
4. выясняют что фишки которые способствовали выбору NoSQL-решения (типа вывод в JSON или XML) для обработки данных вообще малозначны
5. переписывают под нормальный SQL-сервер (ну или проект загибается)
тогда какой смысл выпускать проект? Можно делать бесплатные опенсорсные игры как хобби.
мне кажется подобные статьи редко затрагивают наиболее важную сторону монетизации:

стоимость мобильных игр ничтожна.

Что такое типовые 100 рублей? Пачка сигарет, бутылка пива/лимонада, проезд в метро туда-обратно.

Водораздел проходит по странам в которых привыкли платить или нет. У нас в стране сама возможность оплатить карточкой или другим способом появилась не так давно. До конца 90-х вообще в РФ софт не поставлялся и попадал исключительно в виде пиратских версий.

Поэтому и возникают вопросы о моральности платей, всё ж всегда бесплатно было а тут, гады, денег хотят, ненавистьненависть. В той же, скажем, Аргентине (более бедной чем РФ) к оплате относятся спокойно. Жалко тратить на ерунду — не купят. Понравилось — купят. Никого морализаторства, разработчиков не обвиняют в смертном грехе.
Также интересовал этот вопрос. Вот обсуждение
stackoverflow.com/questions/17549478/how-to-disable-home-and-other-system-buttons-in-android

после того как один из участников добавил призовую карму, более-менее внятные пути решения сразу нашлись (без этих «блокировать экран неправильно и невозможно»)
ну и в чём разница? Только в том что SQL-сервер выполнит запрос мгновенно а все известные мне XML-движки дадут огромный провал в производительности.
нормально всё будет. Добавится ещё условие и всё

select price.goods_id
	from parameters price
	join categories priceCategory 
		on priceCategory.id=price.category_id 
		and priceCategory.name="Цена" 
		and price.numericValue>100.0 and price.numericValue<200.0
	join parameters color
	join categories colorCategory 
		on colorCategory.id=color.category_id 
		and colorCategory.name="Цвет" 
		and (color.stringValue="Поносный" or color.stringValue="Жёлтый")
	join parameters kind
	join categories kindCategory 
		on kindCategory.id=kind.category_id 
		and kindCategory.name="Изделие" 
		and (kind.stringValue="Чайник" or kind.stringValue="Самовар")
млять, носом тя тыкал, кусок вырезал со ссылкой
A perfect hash function for a specific set S that can be evaluated in constant time, and with values in a small range, can be found by a randomized algorithm in a number of operations that is proportional to the size of S
Тот же подсоленный хеш встречается часто и всегда различается для одинаковых экземпляров (обычно паролей)
нет, млять, одно и то же оффтопить будет.

Хватит. Это просто пример чтоб не удивлялись.
хватит спорить не о чём. По ссылке ясно сказано что в ряде случаев для вычисления хеша используется случайное число (можно опротестовать статью в вики, если уж неймётся). Так это или не так конкретно в Андроиде неизвестно, наряду с этим есть ещё масса вариантов испоьзования случайных чисел и в UI, и в гугловых картах, и в других местах.
значит надо лучше искать:

There's no requirement that hash values be consistent between different Java implementations, or even between different execution runs of the same program, and while two unequal objects having different hashes is very desirable, this is not mandatory (that is, the hash function implemented need not be a perfect

и далее по ссылкам.

В любом случае это просто пример применения случайных чисел. Один пример из множества возможных внутри Андроида. Чтоб не удивлялись.
он может использоваться в зависимости от реализации виртуальной машины, см. ссылку. Хотя может и не использоваться. Как я сказал, генератор случайных чисел используется много где, необязательно в одном месте проблема.
не обязательно UI. В Java любой экземпляр любого класса имеет hashCode, для вычисления которого используется и генератор случайных чисел.

Ну или взять карты гугла — они кешируются и для каждого скачанного куска используется случайное имя, например.

Если посмотреть что внутри, выяснится что генератор случайных чисел очень много где используется, как бы странно это не казалось непрограммистам.
а чем плох EAV?

Простая реляционная структура типа goods<-parameters->categories. Запросы вполне наглядные, будут выглядеть примерно так:

select price.goods_id
	from parameters price
	join categories priceCategory 
		on priceCategory.id=price.category_id 
		and priceCategory.name="Цена" 
		and price.numericValue>100.0 and price.numericValue<200.0
	join parameters color
	join categories colorCategory 
		on colorCategory.id=color.category_id 
		and colorCategory.name="Цвет" 
		and (color.stringValue="Поносный" or color.stringValue="Жёлтый")


т.е. выбрать иды товаров с ценой от 100 до 200 и цветом «Поносный» либо «Жёлтый». Компактные запросы вполне поддающиеся оптимизации и разграничению прав на элементы справочника параметров. И просто и работает быстро.
неверный выводы т.к. план запроса строит оптимизатор а он учитывает не только наличие/отсутствие индексов (например он может брать данные из кеша, частично индексировать на лету, повторно использовать результаты предидущих запросов и т.д.).

— индексы нужны всегда и почти везде (ваш К.О.)
— на скорость вставки индексы влияют всегда (не всегда значительно)
— при выборке большого количества строк непосредственно чтение результата займёт больше времени чем сам поиск
— не знаю что такое вычислимые поля но выигрыш индексирования зависит от типа поля

об этом учебники пишут. В таком виде статьи скорей вредны чем полезны.

1
23 ...

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity