Может, потому что в нем невидимые символы являются значимыми лексемами?
Вообще диаграмма крайне холиварная, в отношении того же erlang. (например строка = список чисел).
С производительностью тоже не всё в порядке — все интерпретируемые языки на картинке по оверхеду самого языка на производительность плюс-минус однохренственны, больше зависит от решаемой задачи и используемой библиотеки.
Если <id, запись> не подходит — можно либо попробовать вычитку по внутреннему уникальному id записи в базе, (если это возможно для myssql, для pg насколько я знаю — варианты есть).
Но самый лучший способ — просто положить в обычный файл на диске и читать со смещением по строкам в памяти.
Странная задача.
Можно сгенерировать весь набор доступных логинов на стороне вашего языка, 700кк это не много, и перемешать случайной сортировкой, например взяв md5 от логина. Положить их в базу и отдавать новый по порядку.
Последнего не занятого хранить в потокобезопасном кэше.
Собственно говоря, можно обойтись даже без базы, просто файликом и читать его со смещением по памяти на нужную строку. Благо длину строки можно сделать стандартной.
Если для вас 700кк 8ми символьных строк — это много, можно выбрать несколько произвольных диапазонов и по мере нужды генерить новые диапазоны.
готовые (анонимизированные) датасеты с реального объекта
собственно говоря, где?
Если они анонимные, почему бы их сразу не выложить в паблик?
Если у каждой команды будет свой набор данных — напишите уж об этом.
Скорее всего, имелось ввиду (a != 1 || a != 2) либо его производные выражения через отрицание.
always true/always false, зачастую встречается даже в серьезном коде, те же resharper/студия( в c#) сильно не всегда отлавливают, особенно если предикат длинный.
Большой объем и частота обмена данными по сети между внутренними сервисами.
А серваков не так много.
Выручают фичи, о которых Encarmine написал ниже — бинарная сериализация и замыкание сервисов на одной машине через pipes.А для удобства использования теми, с кем обмен данными пожиже — конечные точки с удобными клиентам интерфейсами.
Да и для моих задач soap оказался удобнее.
В wcf есть REST-вариант службы. И работу чисто по http можно настроить.
Вроде бы, можно даже json-сериализацию прикрутить при отдаче ответов.
Просто wcf слишком тяжел, монструозен и сложно настраиваем для большинства программистов.
Ну и просто уже не модно.
К сожалению, я не пишу и не писал код с контрактами. Не сложилось.
А как стал бы использовать — контракты на отлавливание пограничных ситуаций вида
1) выбрасывание исключений
2) возврат/не возврат null
3) ограничение области определения закодированной функции до некоторого реального подмножества.
(Пример — не может в вашей модели сепаратор вращаться со скоростью >1кк оборотов в минуту.
Ну и отсеките нереалистичные цифры контрактом)
«u. тесты — верификация того, что ты написал то, что собирался написать, а не то, что получилось»
т.е. обязательно — happy path, ветвления программы, циклы. (дешево)
крайне желательно — таблицу истинности всех логических предикатов (дорого)
параллельное программирование — корректность состояния, действия при тупиках и гонках. (очень дорого)
По последнему пункту — полный отказ от состояния и реактивность бывают очень дороги по производительности/пониманию происходящего.
Состояние конечно зло, и функциональный подход крут, но от некоторых «точек синхронизации» тяжело отвязаться.
Как пример — почтовый ящик процесса в Erlang.
Как ни крути, это область памяти процесса, в которую возможна многопоточная вставка, и либо нужно предоставлять доступ к ней, как к критической секции — одному потоку, либо использовать какие-либо варианты синхронизации.
P.s. это моё мнение, оно явно подлежит дискуссии, но холивары на эту тему мне уже настолько надоели, что вызывают тошноту.
Используйте любой метод доказывания корректности программы, который может сработать автоматически. Чем раньше будет отловлена ошибка — тем лучше.
Если вы не используете никаких методов — начните использовать любой, вызывающий у вас меньше всего неприятных эмоций.
Не надо холиварить, какие тесты лучше — функциональные, юнит или регрессионные, сначала напишите любой, позволяющий доказать корректность и соответствие требованиям.
Ожидал функционального программирования / контрактного программирования, формальной спецификации и верификации программ, детального юнит-тестирования.
По факту — пара советов из начала любой книги о «правильном и красивом» программировании.
Так не будет. Производители браузеров опять пойдут «кто в лес, кто по дрова» в плане поддержки стандартов.
Уже не один раз пройдено.
Мне кажется, что корень проблемы в том, что браузер — очень сложная программа, особенно в плане поддержки обратной совместимости, и цена внесения изменений — крайне высока. Поэтому мы опять получим две-три разные реализации, только теперь для WebAssembly и WebGL(или нового варианта разметки).
Похоронить же сейчас все текущие технологии интернетов ради нового стандарта — нереал, как в старой картинке о 20+ стандартах.
musicriffstudio золотое правило —
делай ссылки — ссылками
кнопки — кнопками, а не , не div, не <что-то>.
список- списком.
таблицу — таблицей.
блок — блоком, абзац абзацем.
Делая, например, таблицу — дивами можно сломать голосовые браузеры, «семантичную верстку», испоганить клавиатурные эвенты — например переход табом между блоками, и.т.п.
С другой стороны, если политика вашего веба — ради 5% пользователей — не запариваться, то да, конечно, можно верстать как хочешь.
Так бизнес отжимают, где продвигая вот такие законы, где подставляя под силовиков.
Примерно также отжали «вконтакте», сконцентрировав крупнейшие соц сети у одного «своего» человека.
Ну, собственно говоря, такое может произойти с любым бизнесом в России.
Не так уж давно Яндекс пытались отжать, но тот сам лёг под государственных людей.
Вообще диаграмма крайне холиварная, в отношении того же erlang. (например строка = список чисел).
С производительностью тоже не всё в порядке — все интерпретируемые языки на картинке по оверхеду самого языка на производительность плюс-минус однохренственны, больше зависит от решаемой задачи и используемой библиотеки.
Но самый лучший способ — просто положить в обычный файл на диске и читать со смещением по строкам в памяти.
Можно сгенерировать весь набор доступных логинов на стороне вашего языка, 700кк это не много, и перемешать случайной сортировкой, например взяв md5 от логина. Положить их в базу и отдавать новый по порядку.
Последнего не занятого хранить в потокобезопасном кэше.
Собственно говоря, можно обойтись даже без базы, просто файликом и читать его со смещением по памяти на нужную строку. Благо длину строки можно сделать стандартной.
Если для вас 700кк 8ми символьных строк — это много, можно выбрать несколько произвольных диапазонов и по мере нужды генерить новые диапазоны.
Я, конечно, новичок в этом вопросе, но
собственно говоря, где?
Если они анонимные, почему бы их сразу не выложить в паблик?
Если у каждой команды будет свой набор данных — напишите уж об этом.
always true/always false, зачастую встречается даже в серьезном коде, те же resharper/студия( в c#) сильно не всегда отлавливают, особенно если предикат длинный.
А рекламу ребята на этом себе сделают. Почему бы и нет.
А серваков не так много.
Выручают фичи, о которых Encarmine написал ниже — бинарная сериализация и замыкание сервисов на одной машине через pipes.А для удобства использования теми, с кем обмен данными пожиже — конечные точки с удобными клиентам интерфейсами.
Да и для моих задач soap оказался удобнее.
Вроде бы, можно даже json-сериализацию прикрутить при отдаче ответов.
Просто wcf слишком тяжел, монструозен и сложно настраиваем для большинства программистов.
Ну и просто уже не модно.
В самом эрланге к механизму потоков доступ не получишь, т.к. еденица исполнения — процесс внутри вм.
До первого случая потери денег > твоей зарплаты.
Или до первой человеческой жизни.
А как стал бы использовать — контракты на отлавливание пограничных ситуаций вида
1) выбрасывание исключений
2) возврат/не возврат null
3) ограничение области определения закодированной функции до некоторого реального подмножества.
(Пример — не может в вашей модели сепаратор вращаться со скоростью >1кк оборотов в минуту.
Ну и отсеките нереалистичные цифры контрактом)
«u. тесты — верификация того, что ты написал то, что собирался написать, а не то, что получилось»
т.е. обязательно — happy path, ветвления программы, циклы. (дешево)
крайне желательно — таблицу истинности всех логических предикатов (дорого)
параллельное программирование — корректность состояния, действия при тупиках и гонках. (очень дорого)
По последнему пункту — полный отказ от состояния и реактивность бывают очень дороги по производительности/пониманию происходящего.
Состояние конечно зло, и функциональный подход крут, но от некоторых «точек синхронизации» тяжело отвязаться.
Как пример — почтовый ящик процесса в Erlang.
Как ни крути, это область памяти процесса, в которую возможна многопоточная вставка, и либо нужно предоставлять доступ к ней, как к критической секции — одному потоку, либо использовать какие-либо варианты синхронизации.
P.s. это моё мнение, оно явно подлежит дискуссии, но холивары на эту тему мне уже настолько надоели, что вызывают тошноту.
Используйте любой метод доказывания корректности программы, который может сработать автоматически. Чем раньше будет отловлена ошибка — тем лучше.
Если вы не используете никаких методов — начните использовать любой, вызывающий у вас меньше всего неприятных эмоций.
Не надо холиварить, какие тесты лучше — функциональные, юнит или регрессионные, сначала напишите любой, позволяющий доказать корректность и соответствие требованиям.
По факту — пара советов из начала любой книги о «правильном и красивом» программировании.
Мне кажется, или выделенные фрагменты противоречат друг другу?
Но видимо нет, сынок, это фантастика.
Уже не один раз пройдено.
Мне кажется, что корень проблемы в том, что браузер — очень сложная программа, особенно в плане поддержки обратной совместимости, и цена внесения изменений — крайне высока. Поэтому мы опять получим две-три разные реализации, только теперь для WebAssembly и WebGL(или нового варианта разметки).
Похоронить же сейчас все текущие технологии интернетов ради нового стандарта — нереал, как в старой картинке о 20+ стандартах.
делай ссылки — ссылками
кнопки — кнопками, а не , не div, не <что-то>.
список- списком.
таблицу — таблицей.
блок — блоком, абзац абзацем.
Делая, например, таблицу — дивами можно сломать голосовые браузеры, «семантичную верстку», испоганить клавиатурные эвенты — например переход табом между блоками, и.т.п.
С другой стороны, если политика вашего веба — ради 5% пользователей — не запариваться, то да, конечно, можно верстать как хочешь.
Примерно также отжали «вконтакте», сконцентрировав крупнейшие соц сети у одного «своего» человека.
Ну, собственно говоря, такое может произойти с любым бизнесом в России.
Не так уж давно Яндекс пытались отжать, но тот сам лёг под государственных людей.