Статья отличная, спасибо. А нет ли рекомендаций по книжкам? Хотелось бы что-то вроде Фейнмановских Лекций по подаче, но в разрезе математики. С постепенным усложнением, и проходом по основным разделам в логичном порядке. К сожалению, после курсов и вузов цельная картинка никак не хочет собираться и хотелось бы это исправить.
PS
Отличное замечание про квантор всеобщности в речи. Я не настоящий сварщик, но регулярное использование всуе — раздражает.
Потолок — xiaomi philips zhirui e14 (6 шт.).
Стены — Xiaomi Yeelight — (2 шт.)
К Yeelight претензий никаких, а вот из e14 — одна лампочка издает слабый треск на низкой яркости. Но «мигать» не начинает (во всяком случае, заметить это сьемкой на 960 к/сек не получилось). И результатов тестов этих лампочек, я, к сожалению, не нашел.
Но, на момент покупки это были единственные e14 лампочки с адекватной (750р) ценой. Другой вариант был e14 от филипса — 4к за лампочку, неработающую без гейтвея (еще примерно 5к), что совсем негуманно, если тебе нужна люстра из 6 штук.
Я всю комнату обставил умными лампами и написал им имитацию рассветов (каждое утро в 9, переход за 6 минут красный-оранжевый-желтый-дневной) и закатов (по кнопке, обратный порядок), плюс переход в ночной режим (теплый желтый свет) каждый вечер в 22.
Через какое-то время заметил, что стал стабильнее ложиться спать, в промежуток с 12 до часу, хотя раньше имел обыкновение сидеть до двух-пяти. Просыпаться тоже стал в промежуток с 8:30 до 10, зачастую без дополнительной помощи будильников.
Помог ли свет, или так сложились обстоятельства — не берусь судить, двойного слепого плацебоконтролируемого не проводил. (Интересно, кстати, как с доказательной базой эффективности таких вещей быть. Мне сложно представить нормальное исследование, как это делается с лекарствами. Дать бутафорский «светобудильник», так чтобы участник не заметил, что он не работает — довольно сложно)
-Вы, наверное, еще и верите что снег белый?
-Ну да.
-А вас не смущает, что Гитлер тоже считал, что снег белый?
Вашу статью можно использовать для тренировки навыков поиска типичных ошибок аргументации. Апелляция к авторитету, использование приемов вроде этого: «Но понятно, что если бы без них можно было обойтись, отцы-основатели их бы и не вводили.» и критика личностных качеств представителей другой точки зрения. Собери их все!
Я прочитал статью, а также изучил сайт вашего языка.
У меня есть для вас совет. Он относится к тому как писать, но не программы, а тексты.
Вместо оценочных суждений давайте людям факты.
В IT, по моим наблюдениям, работают люди, которым тяжело пустить в глаза пыль низкопробными «маркетинговыми» фразами.
«На мой взгляд у меня имеется неплохое резюме с кучей ачивок и хороший скилл, который я день за днем совершенствую последние 8-9 лет
…
, а я на данный момент только выпустился из 11-го и сдаю один за другим экзамены.»
— Почему резюме хорошее? Что говорит о том что у вас хороший скилл? Какие конкретно ачивки?
И да, как уже писали выше, когда ты видишь фразу про 8-9 лет, то ты воспринимаешь это как-то странно в статье про стажировку.
Что мешало написать: «К концу 11 класса я запилил свой небольшой язык и компилятор.»? Или еще что-то чем вы гордитесь. Это бы сказало читателю о вашем опыте больше, чем «резюме, ачивки, скилл и 9 лет некоммерческого программирования». И, лично у меня, создало бы хорошее впечатление.
«Быстрый! Производителен и поддерживает многопоточность “из коробки”.» — быстрый насколько? По сравнению с чем? В каких задачах? Как вы вообще это узнали?
«Мой язык дернул C++ в таких-то тестах, вот код» — это скажет мне о том, что язык быстрый, намного лучше любых прилагательных.
IT — это не только алгоритмы, паттерны, фреймворки и т.д. IT это люди, и умение работать с ними. Стоит уделить внимание этой области. Этот текст, как вы могли заметить по отзывам выше, не создал о вас впечатление «человека, с которым будет комфортно работать». Код — тоже, по нему уже сказали комментаторы выше.
А почему вы предпочли выпускать книгу через издательство? Просто в статье я этого момента не нашел, а было бы интересно увидеть анализ выбора «способа издачи».
Наверняка есть какие-то альтернативы, например аутсорсная редактура и выпуск через типографию, с использованием краудфайндинга для минимизации рисков. И у них наверняка есть свои плюсы (например то, что права на книгу остаются у вас и вы вольны делать с нею все, что хотите, без «костылей»).
Можно действовать по аналогии с алгоритмической сложностью.
Если вы определите какой результат вы хотите получить от действий с кодом/любой другой системой, введете «элементарные» по какому либо критерию операции над ней, и скажете что разницей в их сложности вы пренебрегаете — у вас появится инструмент для оценки сложности в контексте какой либо задачи — это просто количество элементарных операций для получения результата.
К сожалению с человеческими мозгами сложно определить множество элементарных операций и саму задачу. Все зависит от информации, которая содержится в этих мозгах.
Например, если вы занимаетесь дебаггингом, то в случае если вы знакомы с этим участком кода и знаете как оно должно работать, то ваша задача выглядит как: «Понять, что работает неправильно.» А еще вам будет легко «навигироваться» в этом участке.
Если вы не знаете как он работает, то к этому добавлятся: понять как работает код на этом участке и каковы ожидаемые результаты его работы. И навигация по коду, пока вы это делаете, уже не будет такой простой, вам придется тратить дополнительные силы на то, чтобы изучать новые для вас объекты и зависимости.
Уменьшение количества зависимостей тоже не всегда будет работать. Простой пример — если вы соберете все классы в один god object — вы уменьшите количесво зависимостей, так как сможете напрямую работать со всеми сущностями. Уменьшит ли это сложность?)
В целом, это даже возможно проиллюстрировать в тексте:
168150320941
168-150-320-941
Сообщение минимальной длины и колмогоровская сложость тоже работают не для всех типов задач, примерно по той же причине.
Я как-то пытался все это математически описать.
В общем, сложность в контексте взаимодействия человека и чего-либо — это очень сложно)
upd:
Хотя, у меня есть одна мысль как можно очень грубо описать нашу проблему. Представьте, что у вас очень маленькая оперативка, которая умеет хранить только примерно 4-8 указателей на области памяти, а все операции производятся на харде и только для двух областей памяти в один момент времени.
А, и да, результат операций, через некоторое время откатывается, поэтому для его сохранения надо переодически его повторять. Но есть вероятность, что он все же в какой-то момент сохранится.
Если интересно, можете почитать подробнее: en.wikipedia.org/wiki/Long-term_depression en.wikipedia.org/wiki/Long-term_potentiation
Вот примерно с такой «вычислительной машинкой» в виде мозга нам и приходится жить. Еще раз повторяю, это очень грубая и неточная аналогия, но помоему она дает некоторое представление.
Т.Е. у строк нет какого-нибудь rowNumber, по которому ее можно выбрать не зная о ее содержании?
Я просто очень давно не работал с таблицами.
Тогда вы правы и у них нет «порядка», но из этого будет следовать неразличимость двух строк с одинаковыми значениями. Если это так — описывать их кортежем избыточно, можно использовать мультимножество.
Если и для столбцов порядок избыточен, то и там не нужен кортеж. Можно описывать как множество пар, если названия столбцов уникальны — мы гарантируем уникальность каждой пары из набора.
Таким образом в случае когда порядок не важен (т.е. мы не можем сказать «столбец номер такой-то» и «строка номер такая-то») получим мультимножество множеств пар.
Для того, что вы пытаетесь описать, существует специальный термин — Кортеж.
Кортеж — это упорядоченный набор элементов.
Я попробую внести ясность во всю эту дискуссию.
Первое. Автор поста прав в утверждении, что множество не может содержать повторяющихся элементов. By defenition.
И запись {1,1,1} — действительно некорректна, если {} — обозначает множество, то это множество может быть ТОЛЬКО {1}
Второе, из того, что автор прав в предыдущем пункте не следует, что он сделал правильный вывод. Таблица — это множество. Но не совсем обычное.
На основе понятия «множество», можно построить другие объекты, которые так же будут являться множествами, но при этом иметь другие свойства. С их помощью и можно описать таблицу.
Например, уже упомянутое мультимножество, в котором элементы имеют кратность. Для нашей задачи оно не подойдет, в таблице важен порядок.
Однако, еще немного математических преобразований позволяют получить такой объект как "кортеж". Кортеж — это упорядоченная последовательность элементов. И да, он может быть выражен используя только определение множества, и сам является множеством. Обозначение: "()", и судя по всему это именно то, что вы пытались выразить своим примером. Правильная запись «различных единиц» будет выглядеть как: (1,1,1,1)
Частным случаем кортежа является такой объект как "пара" — это просто кортеж из двух элементов.
На примере пары можно показать как получается упорядоченность. Пара (a,b) выражается через множество как { {(a)}, {(a), b} }, где (x) = {{/}, {/, x}}, {/} — пустое множество. Соответственно пара (b, b) -> { {(b)}, {(b), b} }. В русской википедии на этом месте ошибка, но можно глянуть в английскую.
А теперь давайте выразим таблицу, с помощью элементов выше.
В таблице есть строки и столбцы.
У каждого столбца есть имя, например «id», «name». Если вы хотите взять значения столбцов по определенной строке то вы получите набор пар:
((id: 1), (name: «Vasya Pupkin»)) — строка таблицы.
Но разумеется, у нас много строк, и их порядок важен. Поэтому в целом таблицу можно выразить как кортеж кортежей пар (название столбца, значение):
(
((id: 1), (name: «Vasya Pupkin»)),
((id: 2), (name: «Nikita Twink»)),
((id: 10), (name: «Petya Petechkin»))
)
И да, этот кортеж все еще можно выразить с помощью одного только понятия «множество». Но правильная запись займет весьма значительный объем (почему — можно узнать в уже упомянутой статье Tuples, английской википедии).
Разумеется, это всего один из способов описать таблицу математически через теорию множеств, но он самый интуитивно понятный, на мой вкус.
Насколько я знаю все еще забавнее.
Когда вы видите (например, пейзаж) — активация подсетей вашей зрительной коры происходит «принудительно», за счет сигналов от глаз (упрощенно, разумеется там куча промежуточных стадий). Поскольку «подсети» активируются «одновременно», то меняются синаптические связи между ними, и они приобретают возможность активироваться «совместно» (т.е. в случае активации одной из них — активируются все).
Когда вы «запоминаете» пейзаж — вы сохраняете стейт синаптических связей.
И когда вы его вспоминаете — вы даете стимул в одну из «связанных» областей, по которому происходит «восстановление», того состояния которое «отображало» ваш пейзаж.
И во всем этом есть интересный момент — под ваше «воспоминание», никто не выделял отдельный участок. Поэтому оно меняется не просто при каждом обращении к нему, а при каждой «операции чтение/запись» любой из учавствующих в отображении воспоминания подсетей.
На примере: Если в вашем «запомнившемся» пейзаже был лес из хвойных деревьев, а потом вы убили полтора года на рисование берез, то вы с хорошей вероятностью посадите в лес из своего воспоминания намного больше берез, чем там на самом деле было. А если вы еще и не запоминали что лес был «хвойным», то он вполне может превратиться в вашей памяти в лиственный.
Хочу дополнить свой предыдущий комментарий, тем, что пока у меня есть доступ к коду, я в целом являюсь царем и богом продукта который я делаю.
Я уверен, что если я залью в репозиторий используемый проектом копию какой-нибудь библиотеки, которую я сам немного подредактирую для сбора пользовательских данных, и наш билд сервер подтянет эту «исправленную» библиотеку как зависимость — у меня будет огромное количество времени до обнаружения того что данные куда-то утекают, и еще большее до локализации причины утечки.
Я не могу придумать как сделать так, чтобы человек, который написал код продукта не имел 1000 и 1 относительно легкого способа узнать ваши ПД.
Простите, но сейчас вы говорите о совсем другой новости.
«Амазон нарушил свое лицензионное соглашение» — это действительно новостной повод и ОГРОМНЫЙ КОСЯК.
«Амазон НИКАК не деперсонализировал данные» — тоже.
Только вот, я до сих пор не вижу новости о миллиардном иске в Амазон, а это означает, что ни нарушения соглашения, ни нарушения порядка использования данных либо не было, либо они не доказуемы (как минимум, не доказуемы легко). Это означает, что оба этих факта являются вашими предположениями, на основе этой статьи. Более того, она написана так, чтобы подтолкнуть вас к этому выводу.
Но, если бы этот факт действительно имел место быть, то я считаю маловероятным, что для его обнародования была бы написана статья, которая лишь на него намекает, да еще и в таком «желтом» формате. Намного более вероятно, что мы бы увидели статью: «Нарушение соглашения/порядка использования пользовательских данных обойдется Амазон в *n* миллиардов долларов».
"
«Странно думать, что если ты пользуешься каким-то продуктом, то у его разработчиков нет доступа к твоим данным.»
Тут имеется некоторая разница в менталитете. В exUSSR считается, что все друг друга хотят обмануть,… "
Причем тут exUSSR? Наш заказчик, кстати не из exUSSR, дал девелоперский доступ мне и другим разработчикам к консолям аналитики. Appsee, Firebase, Crashlytics… Этот доступ необходим для настройки и поддержания интеграций в рабочем состоянии, отлова багов и прочего. Так же я уверен, что небольшой соц-инжиниринг — и у меня будет доступ напрямую к production серверу. Возможно он у меня и так есть, но я это не проверял. В любом случае, он есть у команды доставки, разворачивающей сервак.
И как вы в таких условиях собираетесь защитить данные пользователей от разработчиков продукта? И главное — во сколько вам это встанет и чего вы этим добъетесь?
P.S.
Нет систем, которые не ломаются. Есть системы которые слишком дорого ломать. И с ПД действует аналогичный принцип.
6 вхождений подстроки «украин» и 4 вхождения подстроки «киев», на короткий текст из 8 абзацев (абзацы на одно предложение я не считал).
Если бы я увидел тот же текст, где «украин», и «киев» были бы заменены на «американ/голланд/британ/...» и «Нью-Йорк/Амстредам/Лондон/...», соответственно, то я бы задал точно такой же вопрос сменив название города и страны.
Суть вопроса в том, что любое отделение может иметь доступ к этим данным. И совершенно непонятно, почему рассматривается одно конкретное.
Но тогда новости не будет, потому что эта информация описывается фразой формата:
«Разрабочики продукта, для того, чтобы улучшать продукт, используют данные полученные при работе этого продукта у реальных пользователей! Какой кошмар! Негодяи! Не могут все тестировать у себя, а информацию от пользователей держать приватно?»
И если вы действительно не понимаете, каков ответ на последний вопрос, то могу поделиться тайной: Вообще-то и правда могут. Просто после этого вам придется заплатить за ring… Ну, где-то в 100-1000 раз больше. Для получения продукта того же качества. Или годами ждать патчей.
Вы можете купить отдельный роутер под умный дом (или заблочить доступ умным девайсам во внешний интернет на уже имеющемся) и поднять Home Assistant локально, например на raspberry.
Не знаю насчет всех устройств, но Xiaomi Smart Home (лампы, робот пылесос, очиститель, увлажнитель) можно заставить функционировать полностью, без физического доступа к внешнему интернету.
Я делал это не из соображений безопасности, а потому что меня бесил долгий отклик и перебои в работе серверов xiaomi.
Правда, для этого придется повозиться. У меня ушло 3 дня на первоначальную настройку, и я все еще не полностью продублировал все возможности MiHome. Зато я смог настроить группировку ламп намного более удобным способом, нежели это было возможно в оф. приложении.
Мне показалось или суть новости в том, что
«ШОК! РАЗРАБОТЧИКИ ПРОДУКТА ИМЕЮТ ДОСТУП К ДАННЫМ СОБИРАЕМЫМ ПРОДУКТОМ КОТОРЫЙ ОНИ РАЗРАБОТАЛИ! И СРЕДИ РАЗРАБОТЧИКОВ ЕСТЬ УКРАИНЦЫ!»
Почему так сильно выделена украина? Я уверен, что другие филиалы Ring имеют такой же доступ. А еще у меня есть подозрение, что в соглашении прописано, что ты сам сознательно отдал все видео с собой в Ring, вплоть до того, что компания может выкладывать самые смешные видосики на ютубчик, если замажет тебе лицо.
«Взлом сети. Для доступа к домашней видеосъёмке конкретного американца не нужно ломать сервера Amazon, а достаточно проникнуть в сеть киевского филиала Ring, что, очевидно, проще.»
Откуда такая уверенность? Они что, себе одновременно выкачали ВСЕ видео и хранят их локально, а не грузят их с удаленки, размечают и удаляют? Сказано, что им был предоставлен доступ к файлам. Он например может быть по паролю и ключику в виде публичного сертификата, с проверкой параметров машинки, с которой ты заходишь.
Ну и да, о том, почему проникнуть в Киевское отделение Ring проще — ни слова.
Короче, утверждения сомнительные, а сама новость ни о чем. Странно думать, что если ты пользуешься каким-то продуктом, то у его разработчиков нет доступа к твоим данным.
Извините, но это уже похоже на полную кашу в голове. Что такое сложность Rk или Ok? Набор O дан свыше или мы можем его вычислить? Как его вычислить? Если набор дан, то кто гарантирует, что в нем есть Ok, на котором достигается минимум сложности? Если набор О дан, то можем ли мы показать, что он полный, то есть никаких других интересных Ok быть не может?
Я пытаюсь вам объяснить, что вы ставите другую задачу. Вы говорите о вычислении наилучшего из возможных вариантов, и говорите о том, что это невозможно, и это математически доказуемо. Я это понимаю.
Но я решаю другую — я хочу найти хоть какой-то критерий, который будет описывать реальность лучше, чем имеющиеся у нас (например, лучше чем количество строк кода), для того, чтобы мы могли сравнить хотя бы ограниченное множество вариантов. Сейчас у нас нет инструмента даже для такой задачи.
Разговоры о редизайне предполагают, что оптимизируется сложность изменения в том числе. В примере с простыми числами под сложностью дополнительно понимается сложность алгоритмическая (один алгоритм быстрее) и сложность для понимания (выбор из массива проще, чем алгоритм).
Да, предполагают. Вопрос в том, а надо ли их учитывать, если вероятность редизайна — 60%? Окупится ли это?
Знаете, я отнюдь не уверен, что в примере с простыми числами лучше всегда использовать уже посчитанные значения.
Для первых ста простых я бы так делать не стал. Но я могу ошибаться.
В определении выше A полагался единственным, потому что A: Ok -> Rk. Но если их много, то говорить о том, что Ok отображается в Rk с помощью A уже нельзя. Далее — можете ли вы показать, что у всех людей одинаковый A?
Нет, А будут разные. Давайте предположим, что есть некое множество A, каждый алгоритм из которого встречается с вероятностью Pn. Короче — задали распределение. Ну ок, из этого можно получить дискретное распределение сложностей для каждого O, и получить такое же распределение R — для каждого из алгоритмов. Тут все получается интереснее, например мы можем получить невалидные R_kn для некоторых А_n на некоторых O_k. Ну окей, мы возьмем O_k, который будет соответствовать условию что мы получаем нужный результат с вероятностью больше, скажем 98.5% и при этом минимальной сложностью. Или придумаем еще какое-нибудь условие, которое нам подходит.
Вы можете найти какой-то алгоритм А или даже множество алгоритмов А, Но вы не можете в общем случае знать минимальный ли он/они, оптимальный ли он/они.
В моем примере — они с высокой вероятностью не оптимальны. Люди плохо читают, нам бы не помешала пара плашек озу, с ECC) Проблема в том, что вы не можете изменить то, как записывается информация в вашем мозгу. Поэтому приходится подставлять костыли, с которыми нам будет удобно работать.
Мы и так этим постоянно занимаемся. Я просто пытаюсь найти способ делать это более осмысленно, и делюсь своими мыслями по этому поводу.
Если вы не против, давайте перейдем в ЛС. Вы задаете интересные вопросы, и подкидываете мне интересные мысли. Я, кажется, понимаю, что вы хотите сказать, и понимаю, в какой части у нас возникает недопонимание, но пока что у меня не получается придумать способ донести свою мысль.
Непонятно сложность чего выше — алгоритма вычисляющего простое число или алгоритма выбирающего простое число из массива?
Вот! И мне тоже!
Мой опыт подсказывает, что если я буду считать небольшие простые числа — то лучше вариант с алгоритмом, т.к. я потрачу на него меньше времени. Но если мне нужны большие простые — то лучше взять уже посчитанные, опять же потому что мне понадобиться меньше времени.
Я хочу узнать прав ли я, и если да, то в каких условиях какое из решений предпочтительнее.
Немного не так:
Есть набор систем O={O1,...,On}. Есть уже заданный алгоритм А. Алгоритм принимает Ok и дает результат Rk. Так же у вас есть результат R — тот к которому мы стремимся.
Задача — найти такое Ok, которое при выполнении на нем A, будет давать Rk, такое что R принадлежит Rk, и при этом будет иметь наименьшую сложность.
Пример:
Ваш заказчик просит вас сделать кнопочку. В залогиненом состоянии на кнопочке один текст, в незалогиненом — другой. Кнопки делают разные вещи в этих состояниях. Скажем, когда вы не залогинены — предлагают залогиниться, а когда залогинены — посмотреть данные аккаунта.
Это ваш R.
У вас есть два варианта решения:
Первый — сделать две разные кнопки и подставлять их в зависимости от состояния.
Второй — сделать одну кнопку, но менять у нее текст и действие при нажатии.
Эти варианты: ваши O.
Вы знаете, что у вас 3 коллеги, они будут читать этот код. Еще вы знаете, что возможно у вас будет редизайн через полгода и вы оцениваете его вероятность в 60%.
Это, кхм… Варианты действий с вашим кодом. Я пока не знаю их алгоритмы (А), и моя задача — их найти.
Вопрос — какой из вариантов лучше?
Моя мысль — если мы узнаем алгоритм действий «прочитать код» и «внести изменения в код» — мы сможем ответить на этот вопрос. Если он есть — то оценка сложности не будет отличаться от оценки сложности любого другого алгоритма.
Люди читают примерно одинаково, это задано на уровне того, как устроен их мозг. Отличия между ними обуславливаются разным опытом, а не тем, что их мозги работают по разным принципам. Следовательно — можно попробовать составить алгоритм так, что он будет параметризоваться от «опыта» человека.
Простите, я все еще не понял, откуда вы сделали такой вывод.
По вашему примеру:
У вас есть система А, система Б. У них есть общая подсистема C. Ваша задача — посчитать сложность чтения их человеком. Если вы прочитали А, то вы прочитали C. Поскольку эта информация у вас уже есть, то вам не нужно будет перечитывать C, когда вы будете читать Б. Вы уже о ней знаете.
Почему вы решили, что сложности общих частей должны складываться?)
В моем тексте складываются сложности действий. И в примере выше действий для прочтения Б стало меньше после прочтения А.
PS
Отличное замечание про квантор всеобщности в речи. Я не настоящий сварщик, но регулярное использование всуе — раздражает.
Стены — Xiaomi Yeelight — (2 шт.)
К Yeelight претензий никаких, а вот из e14 — одна лампочка издает слабый треск на низкой яркости. Но «мигать» не начинает (во всяком случае, заметить это сьемкой на 960 к/сек не получилось). И результатов тестов этих лампочек, я, к сожалению, не нашел.
Но, на момент покупки это были единственные e14 лампочки с адекватной (750р) ценой. Другой вариант был e14 от филипса — 4к за лампочку, неработающую без гейтвея (еще примерно 5к), что совсем негуманно, если тебе нужна люстра из 6 штук.
Через какое-то время заметил, что стал стабильнее ложиться спать, в промежуток с 12 до часу, хотя раньше имел обыкновение сидеть до двух-пяти. Просыпаться тоже стал в промежуток с 8:30 до 10, зачастую без дополнительной помощи будильников.
Помог ли свет, или так сложились обстоятельства — не берусь судить, двойного слепого плацебоконтролируемого не проводил. (Интересно, кстати, как с доказательной базой эффективности таких вещей быть. Мне сложно представить нормальное исследование, как это делается с лекарствами. Дать бутафорский «светобудильник», так чтобы участник не заметил, что он не работает — довольно сложно)
Вашу статью можно использовать для тренировки навыков поиска типичных ошибок аргументации. Апелляция к авторитету, использование приемов вроде этого: «Но понятно, что если бы без них можно было обойтись, отцы-основатели их бы и не вводили.» и критика личностных качеств представителей другой точки зрения. Собери их все!
Тема поднята интересная, реализация — подкачала.
У меня есть для вас совет. Он относится к тому как писать, но не программы, а тексты.
Вместо оценочных суждений давайте людям факты.
В IT, по моим наблюдениям, работают люди, которым тяжело пустить в глаза пыль низкопробными «маркетинговыми» фразами.
«На мой взгляд у меня имеется неплохое резюме с кучей ачивок и хороший скилл, который я день за днем совершенствую последние 8-9 лет
…
, а я на данный момент только выпустился из 11-го и сдаю один за другим экзамены.»
— Почему резюме хорошее? Что говорит о том что у вас хороший скилл? Какие конкретно ачивки?
И да, как уже писали выше, когда ты видишь фразу про 8-9 лет, то ты воспринимаешь это как-то странно в статье про стажировку.
Что мешало написать: «К концу 11 класса я запилил свой небольшой язык и компилятор.»? Или еще что-то чем вы гордитесь. Это бы сказало читателю о вашем опыте больше, чем «резюме, ачивки, скилл и 9 лет некоммерческого программирования». И, лично у меня, создало бы хорошее впечатление.
Тоже самое касается вашего сайта:
«Быстрый! Производителен и поддерживает многопоточность “из коробки”.» — быстрый насколько? По сравнению с чем? В каких задачах? Как вы вообще это узнали?
«Мой язык дернул C++ в таких-то тестах, вот код» — это скажет мне о том, что язык быстрый, намного лучше любых прилагательных.
IT — это не только алгоритмы, паттерны, фреймворки и т.д. IT это люди, и умение работать с ними. Стоит уделить внимание этой области. Этот текст, как вы могли заметить по отзывам выше, не создал о вас впечатление «человека, с которым будет комфортно работать». Код — тоже, по нему уже сказали комментаторы выше.
Наверняка есть какие-то альтернативы, например аутсорсная редактура и выпуск через типографию, с использованием краудфайндинга для минимизации рисков. И у них наверняка есть свои плюсы (например то, что права на книгу остаются у вас и вы вольны делать с нею все, что хотите, без «костылей»).
Если вы определите какой результат вы хотите получить от действий с кодом/любой другой системой, введете «элементарные» по какому либо критерию операции над ней, и скажете что разницей в их сложности вы пренебрегаете — у вас появится инструмент для оценки сложности в контексте какой либо задачи — это просто количество элементарных операций для получения результата.
К сожалению с человеческими мозгами сложно определить множество элементарных операций и саму задачу. Все зависит от информации, которая содержится в этих мозгах.
Например, если вы занимаетесь дебаггингом, то в случае если вы знакомы с этим участком кода и знаете как оно должно работать, то ваша задача выглядит как: «Понять, что работает неправильно.» А еще вам будет легко «навигироваться» в этом участке.
Если вы не знаете как он работает, то к этому добавлятся: понять как работает код на этом участке и каковы ожидаемые результаты его работы. И навигация по коду, пока вы это делаете, уже не будет такой простой, вам придется тратить дополнительные силы на то, чтобы изучать новые для вас объекты и зависимости.
Уменьшение количества зависимостей тоже не всегда будет работать. Простой пример — если вы соберете все классы в один god object — вы уменьшите количесво зависимостей, так как сможете напрямую работать со всеми сущностями. Уменьшит ли это сложность?)
В целом, это даже возможно проиллюстрировать в тексте:
168150320941
168-150-320-941
Сообщение минимальной длины и колмогоровская сложость тоже работают не для всех типов задач, примерно по той же причине.
Я как-то пытался все это математически описать.
В общем, сложность в контексте взаимодействия человека и чего-либо — это очень сложно)
upd:
Хотя, у меня есть одна мысль как можно очень грубо описать нашу проблему. Представьте, что у вас очень маленькая оперативка, которая умеет хранить только примерно 4-8 указателей на области памяти, а все операции производятся на харде и только для двух областей памяти в один момент времени.
А, и да, результат операций, через некоторое время откатывается, поэтому для его сохранения надо переодически его повторять. Но есть вероятность, что он все же в какой-то момент сохранится.
Если интересно, можете почитать подробнее:
en.wikipedia.org/wiki/Long-term_depression
en.wikipedia.org/wiki/Long-term_potentiation
Вот примерно с такой «вычислительной машинкой» в виде мозга нам и приходится жить. Еще раз повторяю, это очень грубая и неточная аналогия, но помоему она дает некоторое представление.
Я просто очень давно не работал с таблицами.
Тогда вы правы и у них нет «порядка», но из этого будет следовать неразличимость двух строк с одинаковыми значениями. Если это так — описывать их кортежем избыточно, можно использовать мультимножество.
Если и для столбцов порядок избыточен, то и там не нужен кортеж. Можно описывать как множество пар, если названия столбцов уникальны — мы гарантируем уникальность каждой пары из набора.
Таким образом в случае когда порядок не важен (т.е. мы не можем сказать «столбец номер такой-то» и «строка номер такая-то») получим мультимножество множеств пар.
Кортеж — это упорядоченный набор элементов.
Я попробую внести ясность во всю эту дискуссию.
Первое. Автор поста прав в утверждении, что множество не может содержать повторяющихся элементов. By defenition.
И запись {1,1,1} — действительно некорректна, если {} — обозначает множество, то это множество может быть ТОЛЬКО {1}
Второе, из того, что автор прав в предыдущем пункте не следует, что он сделал правильный вывод. Таблица — это множество. Но не совсем обычное.
На основе понятия «множество», можно построить другие объекты, которые так же будут являться множествами, но при этом иметь другие свойства. С их помощью и можно описать таблицу.
Например, уже упомянутое мультимножество, в котором элементы имеют кратность. Для нашей задачи оно не подойдет, в таблице важен порядок.
Однако, еще немного математических преобразований позволяют получить такой объект как "кортеж". Кортеж — это упорядоченная последовательность элементов. И да, он может быть выражен используя только определение множества, и сам является множеством. Обозначение: "()", и судя по всему это именно то, что вы пытались выразить своим примером. Правильная запись «различных единиц» будет выглядеть как: (1,1,1,1)
Частным случаем кортежа является такой объект как "пара" — это просто кортеж из двух элементов.
На примере пары можно показать как получается упорядоченность. Пара (a,b) выражается через множество как { {(a)}, {(a), b} }, где (x) = {{/}, {/, x}}, {/} — пустое множество. Соответственно пара (b, b) -> { {(b)}, {(b), b} }. В русской википедии на этом месте ошибка, но можно глянуть в английскую.
А теперь давайте выразим таблицу, с помощью элементов выше.
В таблице есть строки и столбцы.
У каждого столбца есть имя, например «id», «name». Если вы хотите взять значения столбцов по определенной строке то вы получите набор пар:
((id: 1), (name: «Vasya Pupkin»)) — строка таблицы.
Но разумеется, у нас много строк, и их порядок важен. Поэтому в целом таблицу можно выразить как кортеж кортежей пар (название столбца, значение):
(
((id: 1), (name: «Vasya Pupkin»)),
((id: 2), (name: «Nikita Twink»)),
((id: 10), (name: «Petya Petechkin»))
)
И да, этот кортеж все еще можно выразить с помощью одного только понятия «множество». Но правильная запись займет весьма значительный объем (почему — можно узнать в уже упомянутой статье Tuples, английской википедии).
Разумеется, это всего один из способов описать таблицу математически через теорию множеств, но он самый интуитивно понятный, на мой вкус.
Когда вы видите (например, пейзаж) — активация подсетей вашей зрительной коры происходит «принудительно», за счет сигналов от глаз (упрощенно, разумеется там куча промежуточных стадий). Поскольку «подсети» активируются «одновременно», то меняются синаптические связи между ними, и они приобретают возможность активироваться «совместно» (т.е. в случае активации одной из них — активируются все).
Когда вы «запоминаете» пейзаж — вы сохраняете стейт синаптических связей.
И когда вы его вспоминаете — вы даете стимул в одну из «связанных» областей, по которому происходит «восстановление», того состояния которое «отображало» ваш пейзаж.
И во всем этом есть интересный момент — под ваше «воспоминание», никто не выделял отдельный участок. Поэтому оно меняется не просто при каждом обращении к нему, а при каждой «операции чтение/запись» любой из учавствующих в отображении воспоминания подсетей.
На примере: Если в вашем «запомнившемся» пейзаже был лес из хвойных деревьев, а потом вы убили полтора года на рисование берез, то вы с хорошей вероятностью посадите в лес из своего воспоминания намного больше берез, чем там на самом деле было. А если вы еще и не запоминали что лес был «хвойным», то он вполне может превратиться в вашей памяти в лиственный.
Я уверен, что если я залью в репозиторий используемый проектом копию какой-нибудь библиотеки, которую я сам немного подредактирую для сбора пользовательских данных, и наш билд сервер подтянет эту «исправленную» библиотеку как зависимость — у меня будет огромное количество времени до обнаружения того что данные куда-то утекают, и еще большее до локализации причины утечки.
Я не могу придумать как сделать так, чтобы человек, который написал код продукта не имел 1000 и 1 относительно легкого способа узнать ваши ПД.
«Амазон нарушил свое лицензионное соглашение» — это действительно новостной повод и ОГРОМНЫЙ КОСЯК.
«Амазон НИКАК не деперсонализировал данные» — тоже.
Только вот, я до сих пор не вижу новости о миллиардном иске в Амазон, а это означает, что ни нарушения соглашения, ни нарушения порядка использования данных либо не было, либо они не доказуемы (как минимум, не доказуемы легко). Это означает, что оба этих факта являются вашими предположениями, на основе этой статьи. Более того, она написана так, чтобы подтолкнуть вас к этому выводу.
Но, если бы этот факт действительно имел место быть, то я считаю маловероятным, что для его обнародования была бы написана статья, которая лишь на него намекает, да еще и в таком «желтом» формате. Намного более вероятно, что мы бы увидели статью: «Нарушение соглашения/порядка использования пользовательских данных обойдется Амазон в *n* миллиардов долларов».
"
«Странно думать, что если ты пользуешься каким-то продуктом, то у его разработчиков нет доступа к твоим данным.»
Тут имеется некоторая разница в менталитете. В exUSSR считается, что все друг друга хотят обмануть,… "
Причем тут exUSSR? Наш заказчик, кстати не из exUSSR, дал девелоперский доступ мне и другим разработчикам к консолям аналитики. Appsee, Firebase, Crashlytics… Этот доступ необходим для настройки и поддержания интеграций в рабочем состоянии, отлова багов и прочего. Так же я уверен, что небольшой соц-инжиниринг — и у меня будет доступ напрямую к production серверу. Возможно он у меня и так есть, но я это не проверял. В любом случае, он есть у команды доставки, разворачивающей сервак.
И как вы в таких условиях собираетесь защитить данные пользователей от разработчиков продукта? И главное — во сколько вам это встанет и чего вы этим добъетесь?
P.S.
Нет систем, которые не ломаются. Есть системы которые слишком дорого ломать. И с ПД действует аналогичный принцип.
Если бы я увидел тот же текст, где «украин», и «киев» были бы заменены на «американ/голланд/британ/...» и «Нью-Йорк/Амстредам/Лондон/...», соответственно, то я бы задал точно такой же вопрос сменив название города и страны.
Суть вопроса в том, что любое отделение может иметь доступ к этим данным. И совершенно непонятно, почему рассматривается одно конкретное.
Но тогда новости не будет, потому что эта информация описывается фразой формата:
«Разрабочики продукта, для того, чтобы улучшать продукт, используют данные полученные при работе этого продукта у реальных пользователей! Какой кошмар! Негодяи! Не могут все тестировать у себя, а информацию от пользователей держать приватно?»
И если вы действительно не понимаете, каков ответ на последний вопрос, то могу поделиться тайной: Вообще-то и правда могут. Просто после этого вам придется заплатить за ring… Ну, где-то в 100-1000 раз больше. Для получения продукта того же качества. Или годами ждать патчей.
Не знаю насчет всех устройств, но Xiaomi Smart Home (лампы, робот пылесос, очиститель, увлажнитель) можно заставить функционировать полностью, без физического доступа к внешнему интернету.
Я делал это не из соображений безопасности, а потому что меня бесил долгий отклик и перебои в работе серверов xiaomi.
Правда, для этого придется повозиться. У меня ушло 3 дня на первоначальную настройку, и я все еще не полностью продублировал все возможности MiHome. Зато я смог настроить группировку ламп намного более удобным способом, нежели это было возможно в оф. приложении.
«ШОК! РАЗРАБОТЧИКИ ПРОДУКТА ИМЕЮТ ДОСТУП К ДАННЫМ СОБИРАЕМЫМ ПРОДУКТОМ КОТОРЫЙ ОНИ РАЗРАБОТАЛИ! И СРЕДИ РАЗРАБОТЧИКОВ ЕСТЬ УКРАИНЦЫ!»
Почему так сильно выделена украина? Я уверен, что другие филиалы Ring имеют такой же доступ. А еще у меня есть подозрение, что в соглашении прописано, что ты сам сознательно отдал все видео с собой в Ring, вплоть до того, что компания может выкладывать самые смешные видосики на ютубчик, если замажет тебе лицо.
«Взлом сети. Для доступа к домашней видеосъёмке конкретного американца не нужно ломать сервера Amazon, а достаточно проникнуть в сеть киевского филиала Ring, что, очевидно, проще.»
Откуда такая уверенность? Они что, себе одновременно выкачали ВСЕ видео и хранят их локально, а не грузят их с удаленки, размечают и удаляют? Сказано, что им был предоставлен доступ к файлам. Он например может быть по паролю и ключику в виде публичного сертификата, с проверкой параметров машинки, с которой ты заходишь.
Ну и да, о том, почему проникнуть в Киевское отделение Ring проще — ни слова.
Короче, утверждения сомнительные, а сама новость ни о чем. Странно думать, что если ты пользуешься каким-то продуктом, то у его разработчиков нет доступа к твоим данным.
Я пытаюсь вам объяснить, что вы ставите другую задачу. Вы говорите о вычислении наилучшего из возможных вариантов, и говорите о том, что это невозможно, и это математически доказуемо. Я это понимаю.
Но я решаю другую — я хочу найти хоть какой-то критерий, который будет описывать реальность лучше, чем имеющиеся у нас (например, лучше чем количество строк кода), для того, чтобы мы могли сравнить хотя бы ограниченное множество вариантов. Сейчас у нас нет инструмента даже для такой задачи.
Да, предполагают. Вопрос в том, а надо ли их учитывать, если вероятность редизайна — 60%? Окупится ли это?
Знаете, я отнюдь не уверен, что в примере с простыми числами лучше всегда использовать уже посчитанные значения.
Для первых ста простых я бы так делать не стал. Но я могу ошибаться.
Нет, А будут разные. Давайте предположим, что есть некое множество A, каждый алгоритм из которого встречается с вероятностью Pn. Короче — задали распределение. Ну ок, из этого можно получить дискретное распределение сложностей для каждого O, и получить такое же распределение R — для каждого из алгоритмов. Тут все получается интереснее, например мы можем получить невалидные R_kn для некоторых А_n на некоторых O_k. Ну окей, мы возьмем O_k, который будет соответствовать условию что мы получаем нужный результат с вероятностью больше, скажем 98.5% и при этом минимальной сложностью. Или придумаем еще какое-нибудь условие, которое нам подходит.
В моем примере — они с высокой вероятностью не оптимальны. Люди плохо читают, нам бы не помешала пара плашек озу, с ECC) Проблема в том, что вы не можете изменить то, как записывается информация в вашем мозгу. Поэтому приходится подставлять костыли, с которыми нам будет удобно работать.
Мы и так этим постоянно занимаемся. Я просто пытаюсь найти способ делать это более осмысленно, и делюсь своими мыслями по этому поводу.
Если вы не против, давайте перейдем в ЛС. Вы задаете интересные вопросы, и подкидываете мне интересные мысли. Я, кажется, понимаю, что вы хотите сказать, и понимаю, в какой части у нас возникает недопонимание, но пока что у меня не получается придумать способ донести свою мысль.
Вот! И мне тоже!
Мой опыт подсказывает, что если я буду считать небольшие простые числа — то лучше вариант с алгоритмом, т.к. я потрачу на него меньше времени. Но если мне нужны большие простые — то лучше взять уже посчитанные, опять же потому что мне понадобиться меньше времени.
Я хочу узнать прав ли я, и если да, то в каких условиях какое из решений предпочтительнее.
Есть набор систем O={O1,...,On}. Есть уже заданный алгоритм А. Алгоритм принимает Ok и дает результат Rk. Так же у вас есть результат R — тот к которому мы стремимся.
Задача — найти такое Ok, которое при выполнении на нем A, будет давать Rk, такое что R принадлежит Rk, и при этом будет иметь наименьшую сложность.
Пример:
Ваш заказчик просит вас сделать кнопочку. В залогиненом состоянии на кнопочке один текст, в незалогиненом — другой. Кнопки делают разные вещи в этих состояниях. Скажем, когда вы не залогинены — предлагают залогиниться, а когда залогинены — посмотреть данные аккаунта.
Это ваш R.
У вас есть два варианта решения:
Первый — сделать две разные кнопки и подставлять их в зависимости от состояния.
Второй — сделать одну кнопку, но менять у нее текст и действие при нажатии.
Эти варианты: ваши O.
Вы знаете, что у вас 3 коллеги, они будут читать этот код. Еще вы знаете, что возможно у вас будет редизайн через полгода и вы оцениваете его вероятность в 60%.
Это, кхм… Варианты действий с вашим кодом. Я пока не знаю их алгоритмы (А), и моя задача — их найти.
Вопрос — какой из вариантов лучше?
Моя мысль — если мы узнаем алгоритм действий «прочитать код» и «внести изменения в код» — мы сможем ответить на этот вопрос. Если он есть — то оценка сложности не будет отличаться от оценки сложности любого другого алгоритма.
Люди читают примерно одинаково, это задано на уровне того, как устроен их мозг. Отличия между ними обуславливаются разным опытом, а не тем, что их мозги работают по разным принципам. Следовательно — можно попробовать составить алгоритм так, что он будет параметризоваться от «опыта» человека.
По вашему примеру:
У вас есть система А, система Б. У них есть общая подсистема C. Ваша задача — посчитать сложность чтения их человеком. Если вы прочитали А, то вы прочитали C. Поскольку эта информация у вас уже есть, то вам не нужно будет перечитывать C, когда вы будете читать Б. Вы уже о ней знаете.
Почему вы решили, что сложности общих частей должны складываться?)
В моем тексте складываются сложности действий. И в примере выше действий для прочтения Б стало меньше после прочтения А.