Добрый день.
Спасибо за статью, но я не понял практический смысл интерфейсов. Поправьте меня, пожалуйста:
1. Go — интерфейс не может содержать данные, только методы.
2. Go — интерфейс привязывается неявно (duck typing).
Т.е. если я создаю структуру, которая должна реализовать методы интерфейса, но забываю реализовать метод Render(), то:
— При попытке вызвать метод, я огребаю ошибку, что нет метода. Как собственно и без интерфейса.
— Если я вдруг явно не вызываю метод, то мне и компилятор не сообщит об ошибке, что метод не реализован. Явной же привязке к интерфейсу нет.
В итоге мне сейчас видеться, что интерфейсы — это некая лишняя абстракция. Я понимаю что ваш пример из статьи упрощен, но он легко работает и без интерфейса: play.golang.org/p/9yvjWwqtTAv.
Единственное достойное применение — это случай, описанный у вас с «MyString и MyFloat». Во всех остальных случаях, вроде как, интерфейсы излишни.
Или я ошибаюсь? Приведите, пожалуйста, еще примеры.
Я понимаю разницу.
Видать в контексте «надо блокировать», «ставьте блокираторы» и все в том же духе, у меня сложилось впечатление, что народ пытается поставить софт, который будет просто блокировать куки.
У меня есть такого типа «Танграм» — достаточно удобно.
Я видел где-то в магазине расходных материалов для полиграфии тонкие магнитные листы. Можно на орокале распечатать что-нибудь и наклеить на такую ленту. В целом не дорого.
Анонимно не получиться. Да и не анонимно тоже трудно. Расскажу свою историю двух месячной давности.
Позвонили мне из некой компании из Новосибирска (сам живу в Уфе) и сказали Олег Александрович (номер телефона и ФИО в купе — уже персональные данные), так и так, у вас накопилось за 2016-2018 года более 2000 бонусов, давайте откроем вам карту. Я спросил, а откуда баллы то. Девушка говорит — ну вы же платили по картам в этом периоде, вот и накопились (т.е. потенциально у них есть данные по моим транзакциям по банковским картам, а может просто маркетинг — мало кто сейчас не пользуется картой).
Я как-то поднапрягся и решил под видом того, что не доверяю первому встречному-поперечному узнать побольше о звонивших. Узнал город и название, которых оказалось два и девушка сама путалась от какой же компании она мне звонит. В итоге я дошел до ИНН, говорю, что хочу быть уверенным, что у вас нет проблем по налогам и т.д. (на сайте ФНС по ИНН можно получить открытые данные по ЮЛ и ИП). На этом вопросе девушка тупо положила трубку. На обратный звонок никто уже не ответил.
Я решил пожаловаться на эту всю историю — откуда у них мои ПД. На сайте РосКомНадзора есть для этого специальная форма (с ней была отдельная веселуха, но к сути не относится). Тут-то и надо раскрывать свою личность, иначе все дальнейшее не имеет смысла. Через час мне пришло письмо, что мое заявление передано в местные инстанции (ФСБ и РосКомНадзор по Башкирии).
Еще через месяц мне пришло два письма от указанных служб. В одном (от ФСБ) было про закон о рекламе. Что я должен им предоставить подтверждающие документы, что я отписался от рекламных рассылок, а они все равно мне приходят, иначе они не могу продолжить расследование.
Во втором (от РосКомНадзора) было сказано, что я должен предоставить подтверждающие документы, что я направил в звонившую организацию (напомню, у меня были только телефон и два названия, и если органы могут пробить, какой компании принадлежит телефон, то я нет) требование об уничтожении своих ПД, а они их не уничтожили (как это узнать вообще не понятно).
Итог получается такой, что по факту даже если ваши ПД продали и используют третьи лица, то вы ничего с этим не сделаете. Да закон есть, но он не работает (точнее узко работает для ограниченного количества лиц, которые хотя обелить себя в интернете).
Непорочное зачатие — случаи единичные, но все же медициной описанные. Когда в утробе матери начинают развиваться два эмбриона, а потом один поглощает другой. Сиамские близнецы из этой же оперы.
Касательно компьютеров из бумаги. Еще в 90х, где-то на просторах fido, находил информацию про «компьютер» для игры в крестики-нолики, состоящий из спичечных коробков и бусин. Получалась некая обучающаяся система — там был свод правил о поощрении и наказании «машины» в случаи победы и проигрыша соответственно.
Фремворки, абстракции, паттерны это все хорошо и это все правильно — надо знать и уметь применять.
Но разница между знать и уметь применять — огромна. Для решения конкретной задачи надо использовать подходящие для этого инструменты (чужие или свои — не суть).
Если задача стоит только написать HW, то я сделаю наитивно echo 'HW';. На кой сюда совать ООП, MVC и еще кучу всякой-всячины? В частности, зачем тут БД и симфони (да и вообще любой другой фрейиворк)?
Я конечно понимаю, что болт забитый молотком держится лучше чем гвоздь завернутый гаечным ключом…
Мое личное мнение — код должен быть максимально простом, но при этом он должен удовлетворять требованиям системы в целом. Тогда этот код проще сопровождать и сложнее сломать.
Другое дело, если бы вы написали, что у меня вот такая-то система, заложены такие-то требования к фронту и беку, и надо сделать то-то. Возможно, тогда ваш код имел бы место быть.
С автором соглашусь в одном — нужно владеть как можно большим числом инструментов. Но также надо уметь правильно ими пользоваться.
А магия исчезновения писем исправлена?
У меня были проблемы с отправкой писем на mail.ru в двух форматах (text/plain и text/html) — Все почтовики нормально видят. Ваш не показывает письма, даже в спам не приходят.
Писал вам в ТП. Мягко послали на… В соц сетях отписался — менеджер попросила переслать письмо с проблемой по другому адресу.
Через два месяца мне пришел ответ с вопросом, цитирую:
«Ваша проблема еще актуальна?»
Решение проблемы:
Сейчас в магазине переделал авторизацию и регистрацию по номерам телефона. Обзваниваю всех клиентов, у которых указана почта на одном из ваших сервисов, и рекомендую указать другую.
Новые технологии и платформы попадают в риски по одно простой причине — не зная их вы не сможете дать адекватную оценку сроков реализации задачи в рамках этих систем. Поэтому оценка ведется на основе статистики ранее освоенных платформ, плюс закладываются повышенные риски.
Такой метод подойдет для оценки трудоемкости (а как следствие себестоимости) любых задач. Для решения задачи вам в любом случаи нужно будет решить все подзадачи, не важно можно ли их решать параллельно или последовательно.
Для оценки сроков выполнения задачи, если вы работаете один, то тоже не суть важна зависимость между подзадачами.
А вот если над задачей работают более одного человека, то да, можно и даже нужно построить такой граф. Хотя для управления проектом он будет более актуален, чем при оценке времени.
По терминологии (чтобы лучше понимать друг друга):
Под временем выполнения задачи — я понимаю как раз ее трудоемкость.
Под сроком выполнения задачи — период времени от начала разработки до реализации (запуска).
Спасибо за статью, но я не понял практический смысл интерфейсов. Поправьте меня, пожалуйста:
1. Go — интерфейс не может содержать данные, только методы.
2. Go — интерфейс привязывается неявно (duck typing).
Т.е. если я создаю структуру, которая должна реализовать методы интерфейса, но забываю реализовать метод Render(), то:
— При попытке вызвать метод, я огребаю ошибку, что нет метода. Как собственно и без интерфейса.
— Если я вдруг явно не вызываю метод, то мне и компилятор не сообщит об ошибке, что метод не реализован. Явной же привязке к интерфейсу нет.
В итоге мне сейчас видеться, что интерфейсы — это некая лишняя абстракция. Я понимаю что ваш пример из статьи упрощен, но он легко работает и без интерфейса: play.golang.org/p/9yvjWwqtTAv.
Единственное достойное применение — это случай, описанный у вас с «MyString и MyFloat». Во всех остальных случаях, вроде как, интерфейсы излишни.
Или я ошибаюсь? Приведите, пожалуйста, еще примеры.
Думаю, тут лучше перевести как: «приводит к сильному связыванию классов».
Видать в контексте «надо блокировать», «ставьте блокираторы» и все в том же духе, у меня сложилось впечатление, что народ пытается поставить софт, который будет просто блокировать куки.
Я видел где-то в магазине расходных материалов для полиграфии тонкие магнитные листы. Можно на орокале распечатать что-нибудь и наклеить на такую ленту. В целом не дорого.
О я тут нашел уже с клевым слоем — prntscr.com/mghk20
Позвонили мне из некой компании из Новосибирска (сам живу в Уфе) и сказали Олег Александрович (номер телефона и ФИО в купе — уже персональные данные), так и так, у вас накопилось за 2016-2018 года более 2000 бонусов, давайте откроем вам карту. Я спросил, а откуда баллы то. Девушка говорит — ну вы же платили по картам в этом периоде, вот и накопились (т.е. потенциально у них есть данные по моим транзакциям по банковским картам, а может просто маркетинг — мало кто сейчас не пользуется картой).
Я как-то поднапрягся и решил под видом того, что не доверяю первому встречному-поперечному узнать побольше о звонивших. Узнал город и название, которых оказалось два и девушка сама путалась от какой же компании она мне звонит. В итоге я дошел до ИНН, говорю, что хочу быть уверенным, что у вас нет проблем по налогам и т.д. (на сайте ФНС по ИНН можно получить открытые данные по ЮЛ и ИП). На этом вопросе девушка тупо положила трубку. На обратный звонок никто уже не ответил.
Я решил пожаловаться на эту всю историю — откуда у них мои ПД. На сайте РосКомНадзора есть для этого специальная форма (с ней была отдельная веселуха, но к сути не относится). Тут-то и надо раскрывать свою личность, иначе все дальнейшее не имеет смысла. Через час мне пришло письмо, что мое заявление передано в местные инстанции (ФСБ и РосКомНадзор по Башкирии).
Еще через месяц мне пришло два письма от указанных служб. В одном (от ФСБ) было про закон о рекламе. Что я должен им предоставить подтверждающие документы, что я отписался от рекламных рассылок, а они все равно мне приходят, иначе они не могу продолжить расследование.
Во втором (от РосКомНадзора) было сказано, что я должен предоставить подтверждающие документы, что я направил в звонившую организацию (напомню, у меня были только телефон и два названия, и если органы могут пробить, какой компании принадлежит телефон, то я нет) требование об уничтожении своих ПД, а они их не уничтожили (как это узнать вообще не понятно).
Итог получается такой, что по факту даже если ваши ПД продали и используют третьи лица, то вы ничего с этим не сделаете. Да закон есть, но он не работает (точнее узко работает для ограниченного количества лиц, которые хотя обелить себя в интернете).
Про шашки и не знал )
Касательно компьютеров из бумаги. Еще в 90х, где-то на просторах fido, находил информацию про «компьютер» для игры в крестики-нолики, состоящий из спичечных коробков и бусин. Получалась некая обучающаяся система — там был свод правил о поощрении и наказании «машины» в случаи победы и проигрыша соответственно.
Надо бы поискать материалы.
И что там работало и не работало?
Однако, статья называется «Hello (real) world» на php. Значит у нас возникает первое ограничение системы — язык php. ))
А вообще, я бы считал эту статью неким «пятничным стебом» и пародией на статью про JS и JS-сообщество (https://habrahabr.ru/post/312022/).
Но разница между знать и уметь применять — огромна. Для решения конкретной задачи надо использовать подходящие для этого инструменты (чужие или свои — не суть).
Если задача стоит только написать HW, то я сделаю наитивно echo 'HW';. На кой сюда совать ООП, MVC и еще кучу всякой-всячины? В частности, зачем тут БД и симфони (да и вообще любой другой фрейиворк)?
Я конечно понимаю, что болт забитый молотком держится лучше чем гвоздь завернутый гаечным ключом…
Мое личное мнение — код должен быть максимально простом, но при этом он должен удовлетворять требованиям системы в целом. Тогда этот код проще сопровождать и сложнее сломать.
Другое дело, если бы вы написали, что у меня вот такая-то система, заложены такие-то требования к фронту и беку, и надо сделать то-то. Возможно, тогда ваш код имел бы место быть.
С автором соглашусь в одном — нужно владеть как можно большим числом инструментов. Но также надо уметь правильно ими пользоваться.
Небольшая правка моего комментария. За пол года в голове две проблемы сложились в одну.
1. Проблема потери писем (не приходили даже в спам, хотя сервер отвечал ок — отправлено). Проблема уже не актуальна с учетом того, что проект закрыт.
2. Проблема с отправкой писем в двух форматах (Content-Type: multipart/alternative). Проблема актуальна и если мы сможем ее решить, я буду очень рад.
У меня были проблемы с отправкой писем на mail.ru в двух форматах (text/plain и text/html) — Все почтовики нормально видят. Ваш не показывает письма, даже в спам не приходят.
Писал вам в ТП. Мягко послали на… В соц сетях отписался — менеджер попросила переслать письмо с проблемой по другому адресу.
Через два месяца мне пришел ответ с вопросом, цитирую:
«Ваша проблема еще актуальна?»
Решение проблемы:
Сейчас в магазине переделал авторизацию и регистрацию по номерам телефона. Обзваниваю всех клиентов, у которых указана почта на одном из ваших сервисов, и рекомендую указать другую.
Криво? Да криво, но как по другому?
но синий лучше
Особенно это актуально для самописных систем.
Такой метод подойдет для оценки трудоемкости (а как следствие себестоимости) любых задач. Для решения задачи вам в любом случаи нужно будет решить все подзадачи, не важно можно ли их решать параллельно или последовательно.
Для оценки сроков выполнения задачи, если вы работаете один, то тоже не суть важна зависимость между подзадачами.
А вот если над задачей работают более одного человека, то да, можно и даже нужно построить такой граф. Хотя для управления проектом он будет более актуален, чем при оценке времени.
По терминологии (чтобы лучше понимать друг друга):
Под временем выполнения задачи — я понимаю как раз ее трудоемкость.
Под сроком выполнения задачи — период времени от начала разработки до реализации (запуска).