Pull to refresh
0
Каукин Игорь @Zanak

Backend и все что с ним связано. Немного — фронт.

Send message
Соблюдение национального законодательства — это не столько про свободу, сколько про престиж страны.
Франция буквально в прошлом году штрафовала корпорацию добра на 50 лямов европейских денег за нарушения регламента ЕС по работе с персональными данными.
Были претензии и со стороны других стран ЕС.
Америка вообще на раз выписывает штрафы всем, кому считает нужным.
Чем мы хуже? Да, введение ограничений — это сложная техническая задача, и с первой попытки ее может не получиться решить качественно. Значит ли, что ее не надо решать? Я думаю надо. Если сказали А, надо говорить и Б. А иначе ерунда получается. Главное — чтобы решение было современным и качественным, а не сделанным на коленке группой пионеров.
Вряд ли он будет полезен на что — то более, чем упражнение для реализации, но придумал алгоритм для поиска четных совершенных чисел (понравилась задачка, вот и уделил ей пару часов):
— в левой колонке выписываем степени двойки, 1, 2, 4, 8,…
— последовательно перебираем строки сверху вниз
— для текущей строки, правую колонку начинаем заполнять снизу вверх.
— первым выбираем максимальное простое число, не превосходящее следующую по порядку степень двойки.
— в ячейку выше помещаем число, равное удвоенному текущему. продолжаем заполнять до верху.
— считаем сумму, и проверяем текущее полученное число.
— повторяем для остальных степеней двойки.
Для 496 должно быть как — то так:
1 — 496
2 — 248
4 — 124
8 — 62
16 — 31

PS. Возможно алгоритм уже давно описан, хотя гугление сходу ни чего не показало, на всякий случай, прошу прощения за самопиар. Придумывание алгоритмов не является моей профессией.
Как мне кажется, чтобы придумывать интернет заново нужно, для начала, рассмотреть прежние use cases и как они реализовывались на практике. После этого, стоит попытаться сформулировать новые, которые отвечали бы современным запросам, прежде всего, потребителя. При этом, нужно четко разделять инфраструктурные вещи, например, протоколы передачи данных или стандарты разметки, которые должны понимать браузеры, пользовательские потребности, то, зачем сейчас он приходит в сеть и что ожидает получить, и поддержку разработчика, который вдохнет в инфраструктуру жизнь и представит ее пользователю.
Совсем кратко, чисто для примера, потому что тема гигантская, и во многих моментах холиварная:
— если не ошибаюсь, то, до 3 версии html вообще картинки не поддерживал и ориентировался только на текстовую информацию. это наложило свой отпечаток и на протокол http. да, он, в последствии, был дополнен, но может стоит попробовать сделать лучше? или подумать об использовании 2 протоколов, для текста и для потоковых данных? (инфраструктура)
— месенжеры сейчас уступают по изобразительным возможностям полноценным браузерам, возможно стоит задуматься и сделать более интерактивным браузер, добавив ему такой вид ресурса, как канал месенжера и позволив посетителю параллельно взаимодействовать и с тем и с другим. (возможности для пользователя, возможности для владельцев ресурса)
— современные фреймворки, вроде vue или react, пользуются большим вниманием со стороны разработчиков. возможно стоит попытаться понять, чтем это вызвано, и предложить им поддержку со стороны браузера для ускорения, и загрузки, и работы страницы? (разработка)
— стилевые фреймворки, взять тот же бутстрап или квазар, для примера, предлагают достаточно единообразное оформление, чтобы вы могли сосредоточится на взаимодействии с пользователем. нужно попробовать понять, означает ли это появление нового вида приложений, взамен обычной desktop программы и можно ли как — то позволить им безопасно создавать файлы и получать доступ к оборудованию пользователя. как мне кажется, это может быть интересно и пользователям, ты не покупаешь программу навсегда, а берешь в краткосрочную аренду, просто позволив ей исполняться на твоем устройстве, и разработчикам, заставить человека за раз достать 1000$, как мне кажется, сложнее, чем заставить его 10000 раз достать по 10 центов. (инфраструктура, разработка, пользователь, бизнес)
Если бы я решил придумать интернет заново, то я думал бы в какой — то подобной манере.

Ага, наши пытались технику победить, а амеры с правильной стороны подошли, Дурова за кошелек потянули, ну он и обмяк.


PS Сорри, шел мимо, за комментарий глаз зацепился, ну и вырвалось.

Веб, как информационный контент, и способствовал развитию сети, как средства его доставки. Не придумай в свое время народ соединить компьютеры сетью, придумывать веб потребности и не возникло бы, а вот когда веб придумался — то рост его количества и стал главным мотиватором развития сети. Впрочем, это напоминает спор, что было раньше, курица или яйцо, предлагаю его не начинать.
Я все таки не склонен драматизировать. Дождемся окончания перемен в мире. Думаю, к этому времени и с интернетом станет понятнее. Как знать, возможно связность станет не горизонтальной а вертикальной, и передачу данных будут обеспечивать спутники, а последнюю милю будет накрывать 5G, или даже 6G.

Почему обязательно печальное? Точнее не так. Почему все обязательно должно идти по пути деградации? На мой взгляд, развитие интернета — это процесс сугубо прагматический.
Оглянитесь на технологии. От интернета, в том виде как он был придуман, мало что осталось. Сайты, из вороха страниц с перекрестными ссылками стали полноценными приложениями. Изменились изобразительные возможности браузеров. Я уж молчу, как сильно поменялся бэкенд.
Поменялась и ситуация. Всемирное разделение труда, потребностям которого интернет, на мой взгляд, достаточно успешно соответствовал, усиленно ломают. Чем это кончится — время покажет. Пока предсказывать не берется ни кто.
Политика сильно влияет на интернет, но она влияет на него здесь и сейчас. Чем на более долгую перспективу мы будем пытаться смотреть, тем чаще будем обнаруживать влияние абсолютно практических вещей. По крайней мере мне так кажется.

Шифры замены — это не все симметричные шифры.

Баловство все это.
Может кроме метаклассов. Да и они большинству разработчиков не известны, и это к счастью.
Почему это плохо:


  • если вам нужна подобная магия, вам стоит подумать над проектом еще раз
  • чем грозит использование eval и ему подобных вызовов (в разных языках они называются по разному) для безопасности в истории есть достаточно примеров, особенно для сервисов
  • вам нужно корректно отрабатывать ошибки, начиная с банальных опечаток, нюансов разных версий синтаксиса и отсутствия зависимостей или их некорректную версию
  • вы теряете оптимизацию самого питона. он не зря сохраняет байткод. компилировать свой код налету — это может быть очень дорого и долго.

PS. По поводу, если не создания, то динамической привязки методов, поищите информацию об unbound методах в питоне. В тройке от них отказались, оставив bounded и static, но зато вы окажитесь рядом с информацией, как добавить в класс метод даже не прибегая к метапрограммированию.

  1. Смысл в том и есть, что вы неверно выделили объекты для реализации. Отсюда все противоречия. Если взять "источник питания" со свойством "напряжение", "нагрузку" со свойством "сопротивление" и объект "электрическая цепь", который будет содержать инстансы первых двух как свойства, то ваши 3 формулы станут методами последнего, и я не понимаю, что по вашему не так с ООП в данном случае.
  2. Сражение за Измаил часть более крупной системы под названием русско-турецкая война, где есть масса взаимодействующих объектов и условий. У вас возникло противоречие, потому что вы результат, в общем — то побочный, объявили главным, и кроме этого, вы его рассматриваете вне контекста системы. Битва за это место шла, потому что с него удобно атаковать неприятеля, или наоборот, защищаться. Здесь вообще могло не быть города.
  3. Здесь, наверное, был не прав, когда исключил кота из рассмотрения. Кот имеет свою реализацию важных методов "этоЕдаДляДанногоКота()", "требоватьЕдыОтХозяина()" и свойства "съедает за раз". Человек имеет свою реализацию метода "повестисьНаТребованияЭтойСкотины()". Миска вряд ли имеет важное значение и потребует реализации, главное, чтобы она была (ну или бог с ней, пусть будет). А вот корм скорее всего придется выделить ради хранения величины его запаса, только это будет не пакет, а корм как таковой. При желании можно пересчитывать в пакеты, килограммы, или миски. Естественно корм должен удовлетворять критерию "этоЕдаДляДанногоКота". Ну и нужен объект, который объединит все это в композицию, конечно, если вы не собрались прикармливать чужого кота, назовем этот объект "Семья". "Семья" корректно свяжет кота со своим хозяином и местом для хранения запаса кормов. Тогда реализация метода хозяина "покормитьСкотину()" станет простым перемещением количества корма в миску, в объеме который определяется потребностями питомца.
  4. Здесь прям не знаю что сказать. Для нужд игровой логики нужно хранить одни величины, например запас патронов, для нужд визуализации — другие, например, если вы в бою, то оружие может быть испачкано кровью. Что отнести к состоянию игрока, а что к его амуниции, наверное программисту виднее, вряд ли здесь все так уж однозначно можно расписать.
  5. Чтобы прикоснуться к предмету, он должен обладать поверхностью, ну или чем — то, что можно ею счесть (по этой причине, прикосновение к свету скорее всего невозможно, а прикосновение к воде можно принять с некоторыми оговорками). Раз уж мы собрались все трогать руками, они у нас должны быть. Прикосновение — это приведение расстояния между какой — то частью поверхности предмета и какой — то частью поверхности руки к нулю. Чтобы описать это, вам потребуется описать геометрическую форму руки и форму предмета. Какие нафиг интерфейсы!?!?
1. Закон ома определяет не способ вычисления, например, силы тока через 2 оставшиеся, а взаимосвязь между величинами. Поэтому наличие 3 формул уместно.
2. Стать хозяином Измаила не метод, а результат действия «победить в сражении».
3. Действие происходит между человеком и пищей, человек перемещает пищу из холодильника в тарелку. Мотивация — это относится к бизнес логике, кормить кошку, кормить собаку, кормить себя.
4. Вы напутали с интерфейсами. Выстрел — это часть интерфейса «стрелковое оружие». Для ножа говорить о выстреле, как и об оставшихся патронах неуместно.
5. Чтобы что — то потрогать руками нужно, чтобы они у вас были, и объект, который вы собираетесь потрогать допускал это (попробуйте потрогать свет :)). Если эти 2 требования выполнены, то реализация операции «прикосновение» становится достаточно простым делом.
Как уже вам и советовали, для начала, напишите парсер чего нибудь попроще, ini, csv, json, yaml или xml. Попробуйте улучшить, например, по потреблению памяти, и/или скорости работы.
После этого, попробуйте разбирать известные языки, минимальное подмножество Си или паскаля, например.
Уже на этом этапе у вас появится пища для размышлений, и, возможно, вы захотите уделить время теории.
Вы взялись за непосильную, для вас, а потому и бессмысленную работу. Будьте последовательны и терпеливы. Я искренне желаю вам удачи.
Реинкарнация mod_perl?
Дурацкий вопрос — а зачем? Как только народ начнет накручивать логику на подобные сценарии, он наступит ровно на те же грабли, что возникали с mod_perl. Разве нет?
Боюсь, автор много кармы на этой теме не заработает.
Сама идея, взять инуитивно всем знакомое понятие и попытаться дать ему свою формулировку ни к чему кроме споров ни приведет. И дело даже в правильности или нет еще одного определения. В зависимости от того, с какой стороны на данное понятие смотреть, то или иное определение может точнее отражать суть.
Например:
  • описание задачи и получения результата с точки зрения математики является алгоритмом? почему нет! последовательность шагов задается формулами, исполнителем является человек.
  • конвейер по сортировке, например, яблок на фабрике по их упаковке/переработке чем не механический компьютер со специальной программой (меньше размера А — отправить на корм скоту, меньше размера Б — на сок, меньше размера В — на пюре, ...)?
  • электронные устройства взаимодействуют с человеком, под час достаточно сложным образом (у меня микроволновка знает рецептов приготовления блюд больше чем я), всегда ли речь идет о присутствии процессора и программы как таковой? не уверен. хотя само взаимодействие вполне может подчиняться интуитивно понятному алгоритму.

На счет ценности контента я не сомневаюсь. Я о другом.
За все время своего существования html, css и js поменялись не особо сильно, особенно если сравнивать с инструментами и технологиями, которые появились рядом с ними.
Typescript принес новые возможности, свойственные "настоящим" языкам, но в итоге он все равно транслируется в js. React и vue сделали более удобным переиспользование кода и реактивность, но все это опять приходит к html+css+js.
Говорить о смерти современного веба можно будет тогда, когда будут исчерпаны все возможности тройки html+css+js и будет разработано что-то не менее гибкое, и не менее удобное. А пока сети расширяются, ресурсы компьютеров растут и всего этого хватит еще лет на 5 точно.

Современный веб будет жить и здравствовать еще лет 5, а то и 10. Пока технологическая сложность не превысит разумных пределов. Уже сейчас мало знать html+css+js. Все чаще встречается TypeScript, да и react или vue, это уже совсем не то, что придумывали отцы основатели. Думаю дальше будет только хуже. По этой причине, уже существующие технологии будут выжимать по максимуму.

Почему — то вспомнился анекдот:


  • вопрос, сколько нужно сотрудников компании майкрософт чтобы поменять одну лампочку.
  • ответ, ни сколько. компания объявит темноту новым стандартом.

Ну а если серьезно, давайте отменим все нормы морали и нравственности, не будем соблюдать их сами, и не будем учить этому наших детей. Только что вы будете делать, если эти нормы начнут нарушать в отношении вас?

Сам факт, что данные по США из 2 источников различаются еще ни чего не значит. Ни чего не сказано про методы сбора информации. Да и вообще, смертность от вируса — это вопрос политический, особенно в США.


По поводу претензий к ВОЗ: разве не национальные правительства принимают решения на своей территории, прислушиваясь, или игнорируя, рекомендации ВОЗ?


Что, на мой взгляд, является достоверными и неоспоримыми фактами, важными для обывателя:


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

Все остальное, вроде ответа на вопросы "кто виноват" и "что делать" — это удел профессионалов в предметных областях, и хочется верить, что они правильно расставят приоритеты и обязательно дадут своевременные ответы на них.

Думаю, автор не разобрался в сути вопроса и не корректно раскрывает тему.
Дезинформация — это есть умышленное искажение/сокрытие объективной, или распространения ложной, информации для облегчения достижения манипулятором своих целей во взаимодействии с аудиторией.
Первый вопрос — цель, в дезинформации населения об эффективности масок? Профилактика паники и связанного с ней дефицита масок? Бред. Если меня убедить в бесполезности масок, сколько бы их ни было в аптеке, я ее ни когда не одену.
Второй вопрос — выбор источников. NY Times точно не является авторитетом в микробиологии. Личность профессора тоже вызывает сомнения, раз он не пошел со своей "ценной" информацией в более специализированные издания и организации, где пришлось бы подкреплять свои слова реальными фактами.
Третий вопрос — аналогия с простудными заболеваниями. Я не медик, и не микробиолог, просто, краем уха слышал, в сети или по ТВ, что "выхлоп" одного простуженного может разлетаться на 4 — 5 метров и проходит время, прежде чем он осядет, а окажись это правдой, то дискуссия о масках теряет свою значимость, потому что важна комплексная гигиена, ношение маски, мытье рук и лица, ношение верхней одежды вне дома и правильное с ней обращение в жилище.
Четвертый вопрос — автор совсем не допускает, что истина может быть где — то посередине? Кто хоть раз надевал маску на достаточно длительный срок знает, что, чем больше маска находится на лице, тем чаще хочется ее поправить, или на время снять. Моя мысль: новая маска работает хорошо, чем дальше, тем больше маска провоцирует прикосновения к лицу и самой маске руками, что, в случае с "короной" не есть хорошо.


Если коротко, то как — то так.

Будущее давно предсказано. У Айзека Азимова есть коротенький рассказ, называется "Чувство силы". По моему, как раз про это.

То, как я услышал сказанное автором: мы собираемся сделать нечто, работающее само по себе, выяснить, чем на самом деле занят ваш компьютер вы не сможете, вмешаться — в случае возникновения проблем — тоже, заботиться о ваших данных на компьютере вам тоже не придется, вы просто не будете иметь к ним доступа.
Примеры реализаций "все в одном месте" мы видели и продолжаем наблюдать: Windows, есть еще Apple, Google со своим андроидом, яндекс, который свою ОС пока не запилил, но со своим браузером столько г… а на компьютер засовывает. Я не спрашиваю "зачем", как на этом зарабатывают большие корпорации — это более или менее понятно, просто, есть большие сомнения что вы это сможете, прежде всего финансово.
Да и сама идея "ОС, как платформа для интеграции, максимально защищенная от вмешательства пользователя" плоха. Мы каждый день сталкиваемся с разного рода интеграторами, оператор связи постоянно "возникает" со своими предложениями по голосу/интернету/тв, банки, рекламные/информационные конторы, магазины ...., список у каждого свой. Сомнительно, что вам удастся внушить доверие потенциальным пользователям.

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity

Specialization

Backend Developer, Fullstack Developer
Middle
From 120,000 ₽
Python
PHP
PostgreSQL
MySQL
Golang
Git
Docker
Nginx
Linux
Perl