Вот сразу интересно стало, а у кого нынче НЕ печальные пириспиктивы?
У программистов что ли?) Да такая же батва ниразумная, такое же а-ля кольцо на кольцо и т.д.
И так у всех, не?
Господа, ну что вы в самом деле…
Кому положено платить — ну будут платить) А кто не хочет — получит «бесплатно» от третьих лиц. Эти же «третьи лица» расколупают вам все что угодно, или вовсе уберут какие-то там непонятные 7 гигов, а оставят как обычно только «заглушки» и т.д. и т.п.
Это как?) Если есть математическое доказательство, то оно и доказывает что-либо. И по другому никак. Если его нет — значит его и нет.
А кто там что считает или как вы выражаетесь, «считается» — вообще никого из вменяемых не парит.
Отсюда вывод: если есть мат.доказательство, доказывающее абсолютную крипт.стойкость — то так оно и есть, и по-другому никак. Ессно до тех пор, пока (условно) «другая» математика не появится или что-то еще экзотическое, типа квантовых кампутеров и т.д.
На одной из фоток кульман Роботрон Ряйс, замечательный оппорат, только мыть его нельзя) У него все покрытие от дсп отклеивается. И линейки у него алюминиевые, на деревянные или пластиковые менялись они. При этом сам кульман конструкционно очень точный. Я на таком мелочовку на СибМоторе набразывал походя. Вытащили его из какого-то гаража, я его отмыл и регулярно мыл и поставил прям в нашем цеху в уголку, что бы чертить что-то не шибко трудоемкое не на коленке, и всем разрешил им пользоваться)
Хорошая статья. В очередной раз посмотрел что в этой стране ничего не меняется. Как был совок, так им и остался. Спасибо.
Зачем ждать два года? Есть методики искусственного старения, и что бы что-то состарить — нагрейте. Все что вы видите вокруг — стареет исключительно и по одной причине — из за температуры, и все что вы видите вокруг — это химические реакции. Возьмите банального Вант-Гоффа, и он вам расскажет почему курица в холодильнике не тухнет. Конечно это в некоторой степени притянуто заушы, и в некторых биологических реакциях оно не работает, но в подавляющем большинстве методики старения неорганики основываются именно на повышении температуры. Само собой методики не простые, составляются очень сложно, применяется тут очень сложная «наука») Я лично видел формулы, по которым рассчитывают искусственное старение. Сказать что они монструозные — это ничего не сказать… Но это все возможно, и используется да почти хоть где. Например на СибМоторе я жог двигатели пачками, по специально составленной методичке. Тупым и контролируемым нагревом работающие двигатели работая три месяца работали как бы три года)) И ровно такие же методики, но со своими приколами разрабатываются на все. На винт такую методику составить тоже в общем-то не проблема, да и 100% они в природе существуют) На заводах точно есть.
У меня нет предложения поправить дизайн, вы с чего это взяли? Так называемый «дизайн», если то что вы называете «дизайном» — поправить в принципе невозможно, т.к. он отсутствует) А как можно поправить то, чего нет? Абсолютно не хочется писать тут о дизайне, потому как надо полагать из вашего написанного — вы в нем разбираетесь как свинья в апельсинах) Дизайн — это искусство, соединенное с неким инженерным и прочим решением/функционалом и т.д., а т.к. искусство неотделимо от человека, то соображая дизайн, который должен соображать дизайнер, а не вы — нужны кучи процессов с этим связанных и т.д. и т.п.)) Про это можно тут начать расписывать со ссылками на вменяемых, но естественно это не «в коня овёс» абсолютно. Так что извините, дизайнеров ищите вменяемых, они вам разъяснят как и что, а мне за это никак не платят совершенно. И да, приличные дизайнеры больших денег стоят, а у вас их нет. Под дизайнеров преогромное тз писать нужно, и вообще подключать с самого начала проектирования вообще-то и прочее прочее прочее…
На вертексе четвертом прям щяс сижу и с этого кампа и пишу сюда)
Работает уже хз сколько, здоровье 92% поглядел только что, винт 120гб, куплен я уже и не знаю когда, лет семь назад что ли, а может быть уже и больше…
Когда ж ты сдохнешь-то зараза!!! Пока не сдохнет, я ж новый винт брать не буду)))
Так же в наличии разнообразный парк мошын, во всех без исключения воткнуты интелы и самсунги. Отказов ноль, проблем ноль.
До меня стояли какие-то убогие ссд-шки — все повылетали, поголовно все. А вполне себе живые и тоже всякие совсем ненужные hdd-шки я вытащил и снес оптом в кантору, торгующую б/у. Такие дела)
Что значит возможно? И что значит хочет/не хочет? Есть мануалы и прочие доки, где указано как и что лепить в иос. Общий вид компонентов здорово стандартизован. А в таком случае зачем делать кастомные «свистелки и перделки от якобы дизайнера»? Смысл же отсутствует. Напрочь отсутствует. Может «якобы дизайнера» носом тыкнуть в мануалы по иос, ну что бы уже не лепил никогда никому непонятную хрень?
Шта? Кампьютеры пользователей были настолько слабыми, что я им сувал xml-ки в чистом виде, вот прям в наичистейшем виде, которые юзеры открывали прям в браузере, содержащие исключительно и только данные, с поверх навернутыми xslt-шаблонами с вообще любой версткой какой захочу, и html-дерево влет строилось у них на клиентских кампах, причем само, причем само смотрело что за данные и применяло нужный шаблон. Это был насколько помню 2003-2004 год, если не ошибаюсь. И подгружались прочие динамические шматки так же, тока через аякс ессно, но исключительно и только подгружались новые шаблоны, абсолютно понятные для понимания. А то что xslt имел зачатки ооп, и на основе шаблонов можно было влет городить производные шаблоны — про это вообще наверное знают единицы) Сайты строились наура, данные были сами по себе и это было изумительно, шаблоны были идеальные, строилось все на ооп и это было изумительно, верстка вообще никого не колыхала, с верстальщика оно бралось и в шаблоны вставлялось влет. Юзер же получал все это и обрабатывал у себя в итоговый html и это было изумительно.
Это я про то, как оно вообще-то на самом деле все вменяемо начиналось на стороне клиента, и в какое унылое гавно превратилось в итоге.
Понимаю) Но я не пишу манифестов, и многое не учитываю, в писанине. А на самом деле я ВСЕ учитываю, я ж специалист теории информации. Другое дело, что описать сразу и все — невозможно. Но разве «в природе» это что-то меняет?) Оно как двигалось только в одном направлении — т.е. по манифестам — так и будет двигаться.
Напишите проще, даже можете добавить в манифест, если хотите. Ну что-то типа того: юзайте уже известные, дишовые и проверенные технологии, и на основании уже «железобетонного» городите новые. Другое дело, что поиск из сонма имеющихся технологий наиболее подходящщих для поделок — это не тривиальная задача конечно же, ну так это детали)
Смешно думать, что написание в этом манифесте тезиса «надо обеспечить отказоустойчивость 99,9%» сразу эту отказоустойчивость обеспечит.
Смешно. И не смешно. Объяснюсь. Это ж манифест у вас) Не стесняйтесь. Пишите как оно ДОЛЖНО быть. И да, 99.9% — это смешно)))) Не стоит так писать. Надо писать 100%. Ибо 99.9 в периоде — это прошлый век. Уже прошлый. ДА, ПРОШЛЫЙ. Нынешний век — это век криптографии. А как «всем известно» [впрочем опять же далеко не всем], любая система отказоустойчивая на 100% только в одном случае — если она криптографически отказоустойчивая и это математически доказано) Смотрите, у вас есть винчестер, как бы вы не корячили наработку на отказ и прочее-прочее-прочее «прошлого века» — ничо не выйдет) Вы получите 99.99..., но применив криптографию — вы и получаете «винчестер самсунг» 100% отказоустойчивый) Я не про то, что он не ломается, я про другое. Я про то, что данные «туда-сюда» на винт перемещаются с помощью пары глобальных технологий. «Старые» технологии отказоустойчивости — это 99.9, новые, как раз таки доводящие «систему» до 100% — это криптография) И без криптографии никак. Хотите 100 — только криптография, без вариантов. Но это никак не отменяет старых глобальных и великолепных технологий, типа наработок на отказ и т.д.
Вырисовывается еще один пункт в таком случае. Что-то типа: объединяйте технологии, юзайте их совместно) И на самом деле, я даже примеры знаю и много — даже казалось бы необъединимое — можно объединить, и получаются в итоге такие грандиозные «штукенции», что диву даешься)) Но конечно же это все нетривиально, а в итоге просто)
И еще момент: есть теория типов, ну или логика высших порядков, или теория абстракций — называйте как хотите.
Так вот я бы обозначил следующее: все что не делается, должно в итоге описываться меньшим кол-вом абстракций, чем было «до». Про сложность абстракций я ничего не говорю. Вообще ничего. Сложность абстракций должна быть соизмеримой. Я говорю про их кол-во.
На пальцах: для юзера что-то описывалось пятью абстракциями, вы искусственно усложнили, и в итоге это усложненное стало описываться тремя абстракциями, причем реализацию усложнения юзер конечно же не видит. Для юзера было пять, стало три. Причем эти «юзерские» абстракции по сложности должны быть соизмеримы. В итоге для юзера выйдет проще? Да! Отчасти похоже на ооп не так ли?) А так и должно быть. Действуйте)
Вообще, теория простого и сложного — это «краеугольный камень» этого всего)) Попытайтесь объяснить что это. Не все это понимают к сожалению. И, возможно, непонимание этого — и приводит к невменяемым поделкам в итоге. И да, теория простого и сложного — это как раз таки пункт номер ноль вашего манифеста. А все остальное что вы написали — это «всего лишь» следствие пункта 0. Забавно же?)
На самом деле — это не так. На самом деле все как раз работает по манифесту, или же подобным манифестам. И всегда будет работать только по ним. Док-во?) Легко.
Оглядитесь вокруг. Все что сделано вокруг — ИСКУССТВЕННО УСЛОЖНЕНО. Именно так. Потому что проще делать как было 100 лет назад. А еще проще как делали 1000 лет назад)
Но зачем-то, на длинных временах все это усложнили. Да, проще прибить гвоздями три кривых доски. Но почему-то грандиозно заморочились, применили лютую химию, физику и даже математику, и всем выдали очуменной [я еще раз подчеркиваю] ОЧУМЕННОЙ СЛОЖНОСТИ шкафчики. В обычных шкафчиках применены сотни технологий. Зачем это?) Это же сложно!
Тут момент в том, что вы к этому привыкли и считаете уже как должное. Но отбери у вас эти шкафчики и выдай вам три доски сколоченных гвоздями — вы же начнете вопить, не так ли?))
Так прибавляет эти самые плюсы для пользователей искусственное усложнение? Вы же пишите что незначительно прибавляет? А выясняется что очень даже значительно, ага?
Выводы:
На короткую перспективу вы правы.
Но на длинную перспективу — абсолютно не правы.
Мир только и делает, что катастрофически усложняет сам себя, только лишь затем, что бы в итоге было проще, надежнее, понятнее, геморроя меньше, проблем меньше, и да, не забывайте про искусство, и оно тоже учитывается)
ВСЕ ЭТО ВОЗМОЖНО, ЕСЛИ СОБЛЮДАТЬ ПОДОБНЫЕ МАНИФЕСТЫ НА ДЛИННОЙ ПЕРСПЕКТИВЕ, и по-другому никак. Ничего другого пока не придумали.
И да, еще момент. На длинную перспективу работают 5%, а на короткую 95%))))) И это тоже нормально. Выбор за вами) Или вы делаете однодневки. Или же делаете как бы пафосно оно не прозвучало, да пусть — «вещи» мирового масштаба) Выбирайте. Вас никто ни к чему не принуждает вовсе.
Автор, да то что вы написали применимо ко всему. Например к программированию. Или к дизайну например. Другое дело, что всем на это плевать)
Да, плевать. Да, всем. Читающий — тебе на это тоже плевать) Иногда ты этого хочешь, но сам ты для этого ничего не сделал. И ты сидишь и ждешь, пока тебе это сделают другие, правда же?
Выводы.
Почему бы и нет?) Ну присылают ему какой-нить жава-покет на обновление, он его обновляет по инструкции, запускает все что надо для проверок и прочих тестов и на этом все) Например у нас в Томске ровно так же в ЦБ постоянно ищут якобы программистов, причем зп в районе 70 тыров, в общем-то ни за что. Люди не идут на такую якобы работу, там же делать нечего. И почти такая же работа якобы программистами в газпромах и прочих канторах. Собственно даже если вы и захотите попрограммировать — так не дадут, и в общем-то оно и правильно) Программируют наверху, чаще заказывают, потом тестят и спускают вниз. Ессно могут быть варианты, но небольшие. Так что программирования оное не касается совсем)
Поймите правильно, я вообще против любого регулирования, и отчасти даже против законов. Но в данном случае я например за то, что бы профилактически рубить внешний нет на новый год например) Слушайте, как удобно будет тестить все что можно а? И даже считать тех, кто написал сам, а кто тупо купил ага?
И еще. Есть некоторые небезосновательные мысли по поводу того, что большая чать орущих встревожены таки не гос.регулированием в принципе, а тем что их отрубят от халявы, и придется все писать самим) Уж извините, но выходит вот так...
Ну вот так. Не нужны никому. У меня все всегда упирается в производительность и только. Если вы на семи тыщах запросов получаете готовые валидные имена из готового массива запросов имен — семьтыщпервый которого нет — роли не играет совсем.
Для этого есть очень мелкая обычная динамическая база, все при этом ага тормозит, загружаются штатные средства, персонаж с редчайшим именем гургениус отправляется туда. При этом, за этим в общем-то следим, и если гургениусы по какой-то причине поперли — ну тогда можно пересобрать статическую базу на массиве и добавить гургениуса. Впрочем, насколько я помню, за 20 лет таких случаев не было) Обычной стандартной статической базы на 7к имен хватает всем. Что-то появляется левое периодически в базах у клиентов, но этого левого — единицы в прямом смысле этого слова, опять же насколько помню, хотя тут могу ошибаться, статистику надо уточнять. И да — эта «динамическая» база — обычный текстовый файлик) Без выкрутасов. Зачем они?
))))
Проход по всем символам — это сборочная либа) Вы этой либой собираете готовый код, и вставляете на уровне исходников в продакшн-либу) Копипастой)) Собираете массив и втыкиваете его ручьками в плюсную либу — абсолютно ничего хитрого.
Можно автоматизировать, а зачем? Оно пересобирается раз в год.
То что пересобирается редко — можно пересобрать и ручками.
В этой либе МАША с пробелом маппится как маша.
Пробел с МАШЕЙ тоже маппится как маша.
МА пробел ША все та же маша.
Вообще без разницы на пробелы, табы и прочую непотребщину)
Вы смысла не уловили.
Вся база в виде готового массива готового к употреблению зачитывается в оперативку целиком.
Это по-сути массив не имен, это массив всех вариантов символов, которые маппятся в ужатом виде в абстракции имен. Индекс массива — это имя, битовые данные соответствующего элемента — это все атрибуты этого имени полностью.
Оверхед на массив конечно есть, но есть ли?)
Если вы запустите то же самое на скюеле убогом — вот это будет лютый оверхед.
Мой же оверхед — это совсем так себе…
Насколько я помню что-то около 7к элементов база, это ни о чем же абсолютно.
Пустая строка в моем случае — это элемент моего массива с индексом [0], смапленная автоматом заранее в например ПУСТОЕ_ИМЯ. Все зависит от реализации.
Какие такие пустые строки мне проверять тогда? Зачем?) В продакшн-решениях этого нет и не будет никогда. У меня не будет.
Да оно запросто может быть) Все это слегка обговаривается в конкретной реализации с заказчиком.
Иногда заказчику вовсе и не нужно иметь весь спектр ошибок пустых полей. Выбирают себе нужные, и на основании этого пересобирается массив бд.
Более менее универсальный подход — это перед началом пользования массива бд — переписать идентификаторы ошибок под себя. Условно говоря в статическую переменную емптиНейм пихаете ПОАТИЛОРУ или что хотите, и все элементы массива с ПУСТОЕ_ИМЯ перезапишутся на новое значение.
Не придирайтесь)) Это всего лишь формальности, и они давно учтены. Только ими никто не пользуется… Нафиг оно никому не надо, такова статистика. Всех устраивает как есть.
Общее тз на эту либу аж на 15 страницах описано вообще-то) Но используется юзерами от этого всего ну максимум процентов 10% функционала.
База имен возможна. Невозможна общая база имен на всех языках, тем более с переводами. И имен не так и много. Насколько помню 15к женских и 10к мужских в русском, могу посмотреть. У нас же используется вообще где-то процентов 30% от общего корпуса. Любой корпус или почти любой все имена содержит. Даже такие о которых вы не слышали ни разу, и я тоже) Ессно все это представляет частотный словарь в разных вариациях. И конечно же редкоупотребительные имена выносятся, они ж не нужны никому. И в автозаполнении которое ну очень легко прикрутить — используется релевантность, как раз таки на частотном словаре. Цифры частот тоже вставлены в массив. Вообще, все что есть вставлено в один массив. Зачем много массивов-то?)) Это лютое зло. Дерганье готовых элементов из разных массивов всегда хуже, чем дергать сборный элемент из одного. Иногда сильно хуже по скорости. Все зависит от реализации опять же.
Нет, не проверяю. Потому что я не знаю как проверить) Вы знаете? Нет.
Объясню.
Ваши проверки проверяют строки, а не имена. Вы абстракции путаете. И это нормально. Но вам нужно же проверять имена, а не строки. Это принципиальная разница, которую не улавливают.
Отсюда следует, что я не знаю что такое пустая строка в контексте имени) Имя может быть пусто? Почему нет? Все зависит от реализации же. Где то это нужно, а где-то не нужно. Проверять строки на пустоту? А что это гарантирует валидность имени? Выясняется что нет. По этому поняв что имя это вовсе не строка [ну вот так вот оно получается, я что могу поделать], и выбран принципиально иной подход. В разряженный массив закидываете ужатые имена, сразу получается список валидных имен, с доступом по индексу массива. Вы вводите в форму символы, символы битовыми сдвигами преобразуйте в индекс массива и вы получите сразу бит валидности, и имя) Поиск О(1). Проверка валидности которая на самом деле не нужна — О(1), и т.д.
Что делать с якобы пустыми строками? А ничего не делать))) Потому что вы не знаете что это. И знать не хотите. Вам зачем это нужно? Пробел — это пустое имя? А три пробела? А пустое имя корректно? Иногда да, иногда нет. От реализации зависит. Но вам до этого дела быть не должно) Ваши имена в любом случае пустыми не будут. Потому что в разряженном массиве элемент на три пробела покажет ПУСТОЕ_ИМЯ. Вы в массиве так и напишете, сами. Вот так и запишите в массиве — ПУСТОЕ_ИМЯ) Если нужно, ну там где оно нужно — запишите НЕКОРРЕКТНОЕ_ИМЯ.
И вы сразу получаете вменяемый вид данных, который однозначно можно понять. Т.е. все эти проверки строк они вообще не нужны. Вы из массива будете получать данные типа:
САША
МАША
ПУСТОЕ_ИМЯ
НЕКОРРЕКТНОЕ_ИМЯ
И вы наконец-то от строк перейдете к именам. Именно к вменяемым абстракциям. Без оверхеда. Абсолютно. Он не нужен.
А уже логику имен как абстракций — корректные они или не корректные — проверяйте как хотите. Не в потоке формы конечно же)))
В потоке формы у вас должен быть прикручен массив, по символам вводимого в поле формы вы получите абстракцию имени. Мгновенно. А уже с этими данными, т.е. уже с абстракциями имен делайте что хотите, но в другом потоке желательно.
Это все уже 20 лет назад оттестировано и работает ну я уже не знаю в скольких проектах) Абстракций как таковых минимум, а точнее две. Оверхед напрочь отсутствует. Зачем он мне?
В зависимости от формы вы можете менять логику имен, т.е. по сути нужно сменить массив готовых данных и все.
Ну как это где?) Все что писано быстрого в этом мире, а не в параллельной вселенной — оно писано на плюсах) Достаточно цифр? Вы прямо щяс пользуетесь тысячей библиотек, написанных на плюсах, и ни одной на расте. Достаточно цифр? Покажите мне базовые вещи, каторые переписаны на раст, и оно вот прям поперло по всему миру, и из каждого утюга поют про то какой раст крутой, быстрый и удобный, и что на нем пишут кодеки, архиваторы, ворды, опирационки, браузеры и ваще все что вы видите вокруг. Достаточно цыфр или еще?) Я могу еще, скажите, я продолжу запросто.
Вот вам искусственный пример
Это не пример, это называется трюкачеством. Любой компилятор имеет кучи подобных трюков в рукавах. Максимальное количество таких трюков — например в фортране. Минимальное — в шарпе. Но на самом деле — это всего лишь трюки, и к компилированию они отношения не имеют. Я ж еще раз говорю. Напишите разархиватор на расте))) Уже давно пора. Что толку от ваших искусственных примеров? И вы не понимаете простой вещи. Ну подкинули вы в раст что он обштопал и обхлопал наура. Но таких вещей он может на всем вашем коде обштопать и обхлопать всего лишь процент. А 99% кода на расте как останется тормозным унылым гавном — так им и останется) Потому что на 99% этого вашего кода трюков уже нет. Извините, но… Их нет.
Ваша проблема в том, что вам в глаз Java и C# попали. Это плохие примеры. Мы здесь не об этом.
Как это не об этом? И кто такие мы? Извините, я сам по себе) Статья о том, что бы поднять флаг, и с этим флагом под бой барабанов бежать по плонете и пихать очередной никому не нужный оверхед во все щщели. Или я ошибаюсь?
Чушь здесь только вы несете. Ну у вас и картина мира.
Изините, что моя картина мира вменяемая))) И я пользуюсь только быстрыми языками в продакшене)
Гуглите Zero-Cost Abstractions, короче, надеюсь на лучшее.
Давайте так. Проще. На реальных примерах. А не на расте, каторый у вас.
Там где-то ниже — супер-пупер что-то типа а-ля зеро-кост, когда имя проверяют на пустоту. И да, я неверно говорю)) Потому что строку проверяют на пустоту, каторая имя.
Слушайте, вы что правда не понимаете, что это сказочное идиотство?)) Вот у вас есть строка. Ага. Строка может быть пустой. А может быть и нет. Ух ты)) Ахаха! Ну ладно. Если не пустая — а давайте проверим ее на валидные символы. Нуничоссеее… Ага ага) А первый символ же должен быть заглавной буковкой, так? Ну а как? А если имя двойное — ну значит нужно это тоже проверить. И вот такое вот убогое мышление щяс поголовно у всех)
Особо одаренные нафигачат аж пятиуровневые абстракции на это все. Понакрутят еще и абстракций функциональных, как то регулярки и прочее дерьмо.
Слушайте, этот пример ниже В МОЕЙ РЕАЛЬНОСТИ вообще не встречается))) Я не знаю зачем мне строки проверять на пустоту))) Вот понимаете, я не знаю зачем мне это) Все только потому что я отбросил нафиг оверхед абстракций. Зачем он? Он не нужен. Абсолютно.
Решение: берете базу имен, запихиваете в разряженный массив и все) Причем каждый символ в имени это шесть бит))) В случае английских имен вообще пять.
У вас вмиг исчезают всякие пятиуровневые абстракции и оверхед вместе с ними, какие-то непонятные проверки на строки и прочее дерьмо. Вы по индексу массива стразу получаете валидное имя. ВСЁ!))
И сотрите уже скюель. Уже убейте эту парашу насмерть. Ваши базы не настолько крутые, что бы в обычный массив не влезли.
И НЕ НАДО ПОСТОЯННО ИЗ РАЗА В РАЗ ПОДГРУЖАТЬ ШРИФТЫ! ЧТО ЗА БРЕД ВЫ ГОРОДИТЕ??? Вы запрашиваете в форму имена вася-петя-маша-саша. ДА УЖЕ ОТРЕНДЕРЬТЕ ЭТИ ИМЕНА ОДИН РАЗ, И СЛОЖИТЕ ИХ СПРАЙТАМИ В БИТМАП НА ВИНТ! Юзера на атоме вам огромное спасибо скажут)))
Блин, да с кем я говорю вообще… Человек на расте пишет… Извините, я пожалуй с этой темки навсегда удалюсь) Смысл отсутствует напрочь…
Вы что правда не понимаете, что вы даже не в состоянии корректно и быстро форму ввода имени написать????
У программистов что ли?) Да такая же батва ниразумная, такое же а-ля кольцо на кольцо и т.д.
И так у всех, не?
Кому положено платить — ну будут платить) А кто не хочет — получит «бесплатно» от третьих лиц. Эти же «третьи лица» расколупают вам все что угодно, или вовсе уберут какие-то там непонятные 7 гигов, а оставят как обычно только «заглушки» и т.д. и т.п.
А кто там что считает или как вы выражаетесь, «считается» — вообще никого из вменяемых не парит.
Отсюда вывод: если есть мат.доказательство, доказывающее абсолютную крипт.стойкость — то так оно и есть, и по-другому никак. Ессно до тех пор, пока (условно) «другая» математика не появится или что-то еще экзотическое, типа квантовых кампутеров и т.д.
Хорошая статья. В очередной раз посмотрел что в этой стране ничего не меняется. Как был совок, так им и остался. Спасибо.
всё, побыстрее пойду пожалуй отсюда, извините)
Работает уже хз сколько, здоровье 92% поглядел только что, винт 120гб, куплен я уже и не знаю когда, лет семь назад что ли, а может быть уже и больше…
Когда ж ты сдохнешь-то зараза!!! Пока не сдохнет, я ж новый винт брать не буду)))
Так же в наличии разнообразный парк мошын, во всех без исключения воткнуты интелы и самсунги. Отказов ноль, проблем ноль.
До меня стояли какие-то убогие ссд-шки — все повылетали, поголовно все. А вполне себе живые и тоже всякие совсем ненужные hdd-шки я вытащил и снес оптом в кантору, торгующую б/у. Такие дела)
Это я про то, как оно вообще-то на самом деле все вменяемо начиналось на стороне клиента, и в какое унылое гавно превратилось в итоге.
Напишите проще, даже можете добавить в манифест, если хотите. Ну что-то типа того: юзайте уже известные, дишовые и проверенные технологии, и на основании уже «железобетонного» городите новые. Другое дело, что поиск из сонма имеющихся технологий наиболее подходящщих для поделок — это не тривиальная задача конечно же, ну так это детали)Смешно. И не смешно. Объяснюсь. Это ж манифест у вас) Не стесняйтесь. Пишите как оно ДОЛЖНО быть. И да, 99.9% — это смешно)))) Не стоит так писать. Надо писать 100%. Ибо 99.9 в периоде — это прошлый век. Уже прошлый. ДА, ПРОШЛЫЙ. Нынешний век — это век криптографии. А как «всем известно» [впрочем опять же далеко не всем], любая система отказоустойчивая на 100% только в одном случае — если она криптографически отказоустойчивая и это математически доказано) Смотрите, у вас есть винчестер, как бы вы не корячили наработку на отказ и прочее-прочее-прочее «прошлого века» — ничо не выйдет) Вы получите 99.99..., но применив криптографию — вы и получаете «винчестер самсунг» 100% отказоустойчивый) Я не про то, что он не ломается, я про другое. Я про то, что данные «туда-сюда» на винт перемещаются с помощью пары глобальных технологий. «Старые» технологии отказоустойчивости — это 99.9, новые, как раз таки доводящие «систему» до 100% — это криптография) И без криптографии никак. Хотите 100 — только криптография, без вариантов. Но это никак не отменяет старых глобальных и великолепных технологий, типа наработок на отказ и т.д.
Вырисовывается еще один пункт в таком случае. Что-то типа: объединяйте технологии, юзайте их совместно) И на самом деле, я даже примеры знаю и много — даже казалось бы необъединимое — можно объединить, и получаются в итоге такие грандиозные «штукенции», что диву даешься)) Но конечно же это все нетривиально, а в итоге просто)
И еще момент: есть теория типов, ну или логика высших порядков, или теория абстракций — называйте как хотите.
Так вот я бы обозначил следующее: все что не делается, должно в итоге описываться меньшим кол-вом абстракций, чем было «до». Про сложность абстракций я ничего не говорю. Вообще ничего. Сложность абстракций должна быть соизмеримой. Я говорю про их кол-во.
На пальцах: для юзера что-то описывалось пятью абстракциями, вы искусственно усложнили, и в итоге это усложненное стало описываться тремя абстракциями, причем реализацию усложнения юзер конечно же не видит. Для юзера было пять, стало три. Причем эти «юзерские» абстракции по сложности должны быть соизмеримы. В итоге для юзера выйдет проще? Да! Отчасти похоже на ооп не так ли?) А так и должно быть. Действуйте)
Вообще, теория простого и сложного — это «краеугольный камень» этого всего)) Попытайтесь объяснить что это. Не все это понимают к сожалению. И, возможно, непонимание этого — и приводит к невменяемым поделкам в итоге. И да, теория простого и сложного — это как раз таки пункт номер ноль вашего манифеста. А все остальное что вы написали — это «всего лишь» следствие пункта 0. Забавно же?)
Оглядитесь вокруг. Все что сделано вокруг — ИСКУССТВЕННО УСЛОЖНЕНО. Именно так. Потому что проще делать как было 100 лет назад. А еще проще как делали 1000 лет назад)
Но зачем-то, на длинных временах все это усложнили. Да, проще прибить гвоздями три кривых доски. Но почему-то грандиозно заморочились, применили лютую химию, физику и даже математику, и всем выдали очуменной [я еще раз подчеркиваю] ОЧУМЕННОЙ СЛОЖНОСТИ шкафчики. В обычных шкафчиках применены сотни технологий. Зачем это?) Это же сложно!
Тут момент в том, что вы к этому привыкли и считаете уже как должное. Но отбери у вас эти шкафчики и выдай вам три доски сколоченных гвоздями — вы же начнете вопить, не так ли?))
Так прибавляет эти самые плюсы для пользователей искусственное усложнение? Вы же пишите что незначительно прибавляет? А выясняется что очень даже значительно, ага?
Выводы:
На короткую перспективу вы правы.
Но на длинную перспективу — абсолютно не правы.
Мир только и делает, что катастрофически усложняет сам себя, только лишь затем, что бы в итоге было проще, надежнее, понятнее, геморроя меньше, проблем меньше, и да, не забывайте про искусство, и оно тоже учитывается)
ВСЕ ЭТО ВОЗМОЖНО, ЕСЛИ СОБЛЮДАТЬ ПОДОБНЫЕ МАНИФЕСТЫ НА ДЛИННОЙ ПЕРСПЕКТИВЕ, и по-другому никак. Ничего другого пока не придумали.
И да, еще момент. На длинную перспективу работают 5%, а на короткую 95%))))) И это тоже нормально. Выбор за вами) Или вы делаете однодневки. Или же делаете как бы пафосно оно не прозвучало, да пусть — «вещи» мирового масштаба) Выбирайте. Вас никто ни к чему не принуждает вовсе.
Да, плевать. Да, всем. Читающий — тебе на это тоже плевать) Иногда ты этого хочешь, но сам ты для этого ничего не сделал. И ты сидишь и ждешь, пока тебе это сделают другие, правда же?
Выводы.
Почему бы и нет?) Ну присылают ему какой-нить жава-покет на обновление, он его обновляет по инструкции, запускает все что надо для проверок и прочих тестов и на этом все) Например у нас в Томске ровно так же в ЦБ постоянно ищут якобы программистов, причем зп в районе 70 тыров, в общем-то ни за что. Люди не идут на такую якобы работу, там же делать нечего. И почти такая же работа якобы программистами в газпромах и прочих канторах. Собственно даже если вы и захотите попрограммировать — так не дадут, и в общем-то оно и правильно) Программируют наверху, чаще заказывают, потом тестят и спускают вниз. Ессно могут быть варианты, но небольшие. Так что программирования оное не касается совсем)
Поймите правильно, я вообще против любого регулирования, и отчасти даже против законов. Но в данном случае я например за то, что бы профилактически рубить внешний нет на новый год например) Слушайте, как удобно будет тестить все что можно а? И даже считать тех, кто написал сам, а кто тупо купил ага?
И еще. Есть некоторые небезосновательные мысли по поводу того, что большая чать орущих встревожены таки не гос.регулированием в принципе, а тем что их отрубят от халявы, и придется все писать самим) Уж извините, но выходит вот так...
Для этого есть очень мелкая обычная динамическая база, все при этом ага тормозит, загружаются штатные средства, персонаж с редчайшим именем гургениус отправляется туда. При этом, за этим в общем-то следим, и если гургениусы по какой-то причине поперли — ну тогда можно пересобрать статическую базу на массиве и добавить гургениуса. Впрочем, насколько я помню, за 20 лет таких случаев не было) Обычной стандартной статической базы на 7к имен хватает всем. Что-то появляется левое периодически в базах у клиентов, но этого левого — единицы в прямом смысле этого слова, опять же насколько помню, хотя тут могу ошибаться, статистику надо уточнять. И да — эта «динамическая» база — обычный текстовый файлик) Без выкрутасов. Зачем они?
Проход по всем символам — это сборочная либа) Вы этой либой собираете готовый код, и вставляете на уровне исходников в продакшн-либу) Копипастой)) Собираете массив и втыкиваете его ручьками в плюсную либу — абсолютно ничего хитрого.
Можно автоматизировать, а зачем? Оно пересобирается раз в год.
То что пересобирается редко — можно пересобрать и ручками.
В этой либе МАША с пробелом маппится как маша.
Пробел с МАШЕЙ тоже маппится как маша.
МА пробел ША все та же маша.
Вообще без разницы на пробелы, табы и прочую непотребщину)
Вы смысла не уловили.
Вся база в виде готового массива готового к употреблению зачитывается в оперативку целиком.
Это по-сути массив не имен, это массив всех вариантов символов, которые маппятся в ужатом виде в абстракции имен. Индекс массива — это имя, битовые данные соответствующего элемента — это все атрибуты этого имени полностью.
Оверхед на массив конечно есть, но есть ли?)
Если вы запустите то же самое на скюеле убогом — вот это будет лютый оверхед.
Мой же оверхед — это совсем так себе…
Насколько я помню что-то около 7к элементов база, это ни о чем же абсолютно.
Пустая строка в моем случае — это элемент моего массива с индексом [0], смапленная автоматом заранее в например ПУСТОЕ_ИМЯ. Все зависит от реализации.
Какие такие пустые строки мне проверять тогда? Зачем?) В продакшн-решениях этого нет и не будет никогда. У меня не будет.
Иногда заказчику вовсе и не нужно иметь весь спектр ошибок пустых полей. Выбирают себе нужные, и на основании этого пересобирается массив бд.
Более менее универсальный подход — это перед началом пользования массива бд — переписать идентификаторы ошибок под себя. Условно говоря в статическую переменную емптиНейм пихаете ПОАТИЛОРУ или что хотите, и все элементы массива с ПУСТОЕ_ИМЯ перезапишутся на новое значение.
Не придирайтесь)) Это всего лишь формальности, и они давно учтены. Только ими никто не пользуется… Нафиг оно никому не надо, такова статистика. Всех устраивает как есть.
Общее тз на эту либу аж на 15 страницах описано вообще-то) Но используется юзерами от этого всего ну максимум процентов 10% функционала.
База имен возможна. Невозможна общая база имен на всех языках, тем более с переводами. И имен не так и много. Насколько помню 15к женских и 10к мужских в русском, могу посмотреть. У нас же используется вообще где-то процентов 30% от общего корпуса. Любой корпус или почти любой все имена содержит. Даже такие о которых вы не слышали ни разу, и я тоже) Ессно все это представляет частотный словарь в разных вариациях. И конечно же редкоупотребительные имена выносятся, они ж не нужны никому. И в автозаполнении которое ну очень легко прикрутить — используется релевантность, как раз таки на частотном словаре. Цифры частот тоже вставлены в массив. Вообще, все что есть вставлено в один массив. Зачем много массивов-то?)) Это лютое зло. Дерганье готовых элементов из разных массивов всегда хуже, чем дергать сборный элемент из одного. Иногда сильно хуже по скорости. Все зависит от реализации опять же.
Объясню.
Ваши проверки проверяют строки, а не имена. Вы абстракции путаете. И это нормально. Но вам нужно же проверять имена, а не строки. Это принципиальная разница, которую не улавливают.
Отсюда следует, что я не знаю что такое пустая строка в контексте имени) Имя может быть пусто? Почему нет? Все зависит от реализации же. Где то это нужно, а где-то не нужно. Проверять строки на пустоту? А что это гарантирует валидность имени? Выясняется что нет. По этому поняв что имя это вовсе не строка [ну вот так вот оно получается, я что могу поделать], и выбран принципиально иной подход. В разряженный массив закидываете ужатые имена, сразу получается список валидных имен, с доступом по индексу массива. Вы вводите в форму символы, символы битовыми сдвигами преобразуйте в индекс массива и вы получите сразу бит валидности, и имя) Поиск О(1). Проверка валидности которая на самом деле не нужна — О(1), и т.д.
Что делать с якобы пустыми строками? А ничего не делать))) Потому что вы не знаете что это. И знать не хотите. Вам зачем это нужно? Пробел — это пустое имя? А три пробела? А пустое имя корректно? Иногда да, иногда нет. От реализации зависит. Но вам до этого дела быть не должно) Ваши имена в любом случае пустыми не будут. Потому что в разряженном массиве элемент на три пробела покажет ПУСТОЕ_ИМЯ. Вы в массиве так и напишете, сами. Вот так и запишите в массиве — ПУСТОЕ_ИМЯ) Если нужно, ну там где оно нужно — запишите НЕКОРРЕКТНОЕ_ИМЯ.
И вы сразу получаете вменяемый вид данных, который однозначно можно понять. Т.е. все эти проверки строк они вообще не нужны. Вы из массива будете получать данные типа:
САША
МАША
ПУСТОЕ_ИМЯ
НЕКОРРЕКТНОЕ_ИМЯ
И вы наконец-то от строк перейдете к именам. Именно к вменяемым абстракциям. Без оверхеда. Абсолютно. Он не нужен.
А уже логику имен как абстракций — корректные они или не корректные — проверяйте как хотите. Не в потоке формы конечно же)))
В потоке формы у вас должен быть прикручен массив, по символам вводимого в поле формы вы получите абстракцию имени. Мгновенно. А уже с этими данными, т.е. уже с абстракциями имен делайте что хотите, но в другом потоке желательно.
Это все уже 20 лет назад оттестировано и работает ну я уже не знаю в скольких проектах) Абстракций как таковых минимум, а точнее две. Оверхед напрочь отсутствует. Зачем он мне?
В зависимости от формы вы можете менять логику имен, т.е. по сути нужно сменить массив готовых данных и все.
Там где-то ниже — супер-пупер что-то типа а-ля зеро-кост, когда имя проверяют на пустоту. И да, я неверно говорю)) Потому что строку проверяют на пустоту, каторая имя.
Слушайте, вы что правда не понимаете, что это сказочное идиотство?)) Вот у вас есть строка. Ага. Строка может быть пустой. А может быть и нет. Ух ты)) Ахаха! Ну ладно. Если не пустая — а давайте проверим ее на валидные символы. Нуничоссеее… Ага ага) А первый символ же должен быть заглавной буковкой, так? Ну а как? А если имя двойное — ну значит нужно это тоже проверить. И вот такое вот убогое мышление щяс поголовно у всех)
Особо одаренные нафигачат аж пятиуровневые абстракции на это все. Понакрутят еще и абстракций функциональных, как то регулярки и прочее дерьмо.
Слушайте, этот пример ниже В МОЕЙ РЕАЛЬНОСТИ вообще не встречается))) Я не знаю зачем мне строки проверять на пустоту))) Вот понимаете, я не знаю зачем мне это) Все только потому что я отбросил нафиг оверхед абстракций. Зачем он? Он не нужен. Абсолютно.
Решение: берете базу имен, запихиваете в разряженный массив и все) Причем каждый символ в имени это шесть бит))) В случае английских имен вообще пять.
У вас вмиг исчезают всякие пятиуровневые абстракции и оверхед вместе с ними, какие-то непонятные проверки на строки и прочее дерьмо. Вы по индексу массива стразу получаете валидное имя. ВСЁ!))
И сотрите уже скюель. Уже убейте эту парашу насмерть. Ваши базы не настолько крутые, что бы в обычный массив не влезли.
И НЕ НАДО ПОСТОЯННО ИЗ РАЗА В РАЗ ПОДГРУЖАТЬ ШРИФТЫ! ЧТО ЗА БРЕД ВЫ ГОРОДИТЕ??? Вы запрашиваете в форму имена вася-петя-маша-саша. ДА УЖЕ ОТРЕНДЕРЬТЕ ЭТИ ИМЕНА ОДИН РАЗ, И СЛОЖИТЕ ИХ СПРАЙТАМИ В БИТМАП НА ВИНТ! Юзера на атоме вам огромное спасибо скажут)))
Блин, да с кем я говорю вообще… Человек на расте пишет… Извините, я пожалуй с этой темки навсегда удалюсь) Смысл отсутствует напрочь…
Вы что правда не понимаете, что вы даже не в состоянии корректно и быстро форму ввода имени написать????