Как я проработала 3 месяца в Я.Маркете и уволилась

Что умеют делать наручные часы кроме показа времени и как выбрать свои первые часы

+8

Со смартфоном есть небольшая засада. Когда его включаешь, чтобы просто посмотреть время, ты также видишь кучу уведомлений. Даже если сжал волю в кулак и не стал их открывать, ты всё равно потратил душевные силы на это. Более того, следующие несколько минут ты будешь лихорадочно прикидывать, вдруг там что-то срочное и важное. Смартфон — отвлекающий фактор #1 в современном мире. Каждый лишний взгляд на него — вычеркнутый кусок жизни. Небольшой, но всё же. Или большой, когда захотел узнать, не пора ли уже выходить, а очнулся через час, отсмотрев кучу мемов.
Старые добрые часы не показывают уведомлений. Никогда. Вскинул руку, узнал сколько времени, и продолжаешь как ни в чём не бывало заниматься своими делами.
А насчёт понтовости… Не знаю, не эксперт. У меня самого купленные 10 лет назад за 200 баксов абсолютно нейтральные по части понтовости часы.

И всё же C — низкоуровневый язык

+3
Никто не станет спорить с тем, что язык ассемблера находится на самом низком уровне.
У нас так не бывает, чтобы никто не спорил. Verilog и VHDL двумя уровнями ниже ассемблера.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
Молоток не моделирует забивание гвоздя, кастрюля не моделирует варку борща, автомобиль не моделирует перевозку пассажиров и грузов, самолёт не моделирует движение в воздушном потоке. Так почему программа должна моделировать ту область, в которой она применяется? Не является ли требование моделирования ничем в сущности не обоснованной обузой?

Мне кажется, весьма глубоко укоренившееся заблуждение насчёт моделирования возникло от того, что компьютер действительно является очень удобным инструментом для численного моделирования. Сначала в основном для этого компьютеры и использовались. Но сейчас времена уже давно как поменялись. Сейчас решение задач собственно моделирования занимает от силы 2% мировых вычислительных мощностей. Очень достойные и очень уважаемые 2%, но всё же 2%, если не меньше.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0

М.б. имеется в виду контроль единственности не объекта, а класса?

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
Складывается ощущение, что ребята традиционно исходят из неверного представления, что в базах данных хранятся объекты. Посмотрим конечно, но на их долгосрочные перспективы я не готов поставить ни цента.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

-1
Почему лишняя, если в реальности она «физически» существует в виде кортежа реляции?
Физически мы все состоим из атомов, но функционируем как единое целое. Аналогия понятна?

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
Последнее. Объекты мэппятся на отношения. Вы создаёте/правите структуру персистентных классов, и шайтан-фреймворк сам допиливает метаданные БД. Если сказать ему, что классы «Абонент» и «Номер» нужно отмэппить на одно и то же отношение, он решит, что разраб сошёл с ума и откажется так делать.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0

Аргумент "вы просто не умеете их готовить" не принимается. Извините.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

+1
NoSQL — зонтичный термин для всего, что «не только SQL». Кто-то из них схемный, кто-то бессхемный, кто-то вообще ничего персистентно не хранит, кто-то, говорят, без проблем только insert умеет делать, а update и delete долго и дорого, кто-то ACID, а кто-то нет.

Что касается схемы, то она есть всегда. Даже если база бессхемная. Только она не в метаданных в СУБД записывается, а где-то ещё. Хоть в коде программы, хоть на прибитой к стенке бумажке, хоть в голове у сотрудника.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
Ну это же халтура! Никому не нужен объект «Запись книжки». Когда ищу по имени, мне нужен список объектов «Абоненты», а когда приходит входящий звонок, отображается карточка объекта «Телефонный номер». Объект «Запись книжки» — лишняя сущность. Да ещё и снабжённая суррогатным ключом.

Прочувствуйте пожалуйста красоту идеи ситуационно-зависимого проецирования набора фактов на объекты, с которыми работает логика и пользователи. С одной стороны зашли — один набор объектов, с другой стороны зашли — другой набор, с третьей — третий. На одних и тех же фактах. Данные в базе хранятся естественным для них образом. Объекты выстраиваются опять же естественным для них, объектов, образом. То, что одно другому один-в-один не соответствует — да и не очень-то хотелось. ORM требует, чтобы соответствовало, и в результате у нас или база кривая, или миллион строк невменяемого кода, или и то, и другое вместе. Ребята, зачем?

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0

Это какая-то совсем чёрная магия. Для контроля типов и составления контекстной подсказки сгодится, но какое ожидать поведение от таких объектов?

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

-1

Вообще, контрагент — это покупатель ИЛИ продавец. А у Вас "И".


Что касается makemigrations/migrate, то оно по-любому не потянуло бы мою сложную переукладку данных. Всё равно пришлось бы собственно перенос данных рисовать вручную, и делался бы он не групповыми запросами, а пообъектно. То есть в десятки раз дольше. Или сотни.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

-1
А в каком виде держать данные в памяти, если вы запретили объекты?
Это где же я запрещал объекты? Более того, я специально акцентировал внимание на том, что они — наша неизбежность.

И как же частичная статическая проверка запросов компилятором и контекстные подсказки от IDE? Избыточно и совсем не нужно?
Это, конечно, вкусно, но честное слово, жить без этого можно. Впрочем, если следовать подходу «объекты как проекции фактов, а в базе факты», то будут вам и проверки компилятором, и подсказки от IDE.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

-1
ООП разве не построено на основе теории множеств?
Нет, не построено. В первом приближении класс — это множество, а экземпляр — это элемент. Но если копнуть глубже, начинаются чудеса. Например, оказывается, что у нас с операциями пересечения и объединения множеств? Вот есть, например, два класса — Customer и Vendor. Как их будем объединять и пересекать? Какие-то странные множества. Теория множеств, в которых определена только операция разбиения на подмножества (наследование). Немножко странно всё это.

Об ETL или об автоматическом апдейте структуры базы?
Второе
Вот я, например, пару недель назад учинил рефакторинг структуры базы (очень хотелось разогнать в пару десятков раз). Написание весьма хитрой миграции у меня заняло пару часов. Почему-то уверен, что через ковыряние во всяких миграционных тонких настройках в духе джанговского каталога «migrations» отняло бы гораздо больше времени, сил и нервов, и всё равно в результате не дало бы той стопроцентной уверенности, которую я получил вручную.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
Эта таблица имеет составной первичный ключ, в который входят обе колонки. Только не говорите пожалуйста, что так не бывает.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
Как построить объекты для приведённого издевательского примера про имена и номера телефонов? Объект «запись в книжке» в целом бесполезен. Полезные объекты — Абонент (у которого может быть несколько номеров) и Номер (который может использоваться несколькими абонентами). Ни одна ORM не потянет мэппинг двух классов на одну таблицу.
Вы скажете, что это извращение. Возможно, но в дизайне баз данных ещё и не такие извращения иногда доводится крутить, при этом, что характерно, оставаясь в рамках высочайших стандартов нормализации данных.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
Спасибо за интересную ссылочку. Хотя при прочтении этой статьи может возникнуть ложное ощущение, что проблема в том, что технология РБД лет на 40 отстала от прогресса.

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

безопасность запросов
Инъекции? Ну, не знаю. Как-то совсем давно не вписывал значения в прикладном коде прямо в SQL-строку, отправляемую на сервер. Что с ORM, что без. Как-то сразу приучил себя предохраняться.

оптимизация обращений к СУБД (каскадное конструирование запроса, отложенное выполнение)
Чисто по практике: рефакторинг с отказом от ORM зачастую в разы улучшает производительность именно за счёт более оптимизированной работы с СУБД.

миграции!
А что миграции? Вы о чём? Об ETL или об автоматическом апдейте структуры базы?

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
С нормализацией в данном случае, что удивительно, всё в порядке. Старая добрая веками прекрасно зарекомендовавшая себя технология бумажного блокнотика.
Несколько записей по одному и тому же имени абонента — нормальная ситуация. Нужно только исключить ситуацию, когда пользователь под именем «Маша» записывает десять разных Маш. Решается на уровне пользовательского интерфейса.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

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

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
Совершенно верно. Когда я, например, разбираюсь с тем, что там как разложено в NoSQL-базе, всё равно рисую старую добрую ER-диаграмму. Народ сначала смотрит дико, а потом втыкает, что это действительно удобно и наглядно.

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

0
В принципе, все технологии программирования, включая ОППшные, замкнуты друг на друга через Тьюринг-полноту. Впрочем, не суть, и Вы, наверно, не об этом.

Непростой принцип единственной ответственности

-1
Но системность от этого всё равно не появится. Будут только куча отдельных обёрнутых в функции строчек.

Непростой принцип единственной ответственности

-1
Сложность убивает, раздели ее на части и ты победишь
но потреяешь системность. То есть поделия будут не системами, а кучками разрозненного мусора. Собрать в единое целое в результате, конечно же, удастся, но только только ценой удесятирения объёма кода.

Менеджер по продукту: чем он занимается и как им стать?

-1

В статье много про то, какой Продакт умный, красивый, ловкий, коммуникабельный и т.д., и т.п., но совсем не раскрыто, зачем вообще эта штатная единица нужна. Чем ум и красота продакта отличается от ума/красоты проджекта? Тимлида? Эккаунта? Любого другого чего-угодно-менеджера или -лида?

Концепция краткой энциклопедии

0
Проблема отделения важного от второстепенного, ИМХО, не имеет решения в общем виде.

Мне кажется, чего сейчас не хватает — это практической энциклопедии, которая бы отталкивалась от «пустого мира». Представьте себе, что вы попали в необитаемый мир, идентичный Земле, но только совсем без цивилизации. Единственное, что у вас есть из нашей цивилизации — это полноценный широкополосный доступ в наш человеческий Интернет. К вечеру захотелось пожрать. Гуглим «как поймать рыбку» и получаем подробные обзоры удочек, лесок и крючков разных производителей, и сразу кучу выгодных предложений заказать это всё в Амазоне и на Али-экспресс. Но у нас нет ни амазона, ни алиэкспресса. У нас вокруг куча разных руд и прочих природных материалов, но мы не знаем, что с этим делать. Мы умеем только заказывать готовый товар с доставкой на дом.
Как опознают железную руду? Какие существуют способы сделать из неё железо? Как превращают песок в стекло? Как хлопок превратить в ткань? И так вплоть до реактивного двигателя, компьютера и смываемой втулки туалетной бумаги.

Код живой и мёртвый. Часть первая. Объекты

+2
То есть навернуть уровень абстракции. Как говорится, мы всегда так делаем.

Ну ОК, навернули. Дальше начинается прикольное:
1. Оказывается, вместе с Weapon в JSON полезно закатывать объекты, на которые weapon ссылается. Например, если Damage у нас не общий, а для каждого врага разный (огнемёт лавовому монстру только в радость), то в Weapon у нас массив объектов, в которых Damage и ссылка на тип врага. Кое-что из свойств врага, кстати, тоже оказывается полезно закатать в JSON. Как всегда происходит в подобных случаях, наш новый прекрасный уровень абстракции начинает усложняться, разрастаться, и в результате сам превращается в монстра хуже лавового.
2. Нежданчик. Оказывается, нам нужно иногда генерить разные JSONы. Ну то есть для хранения один, для сайта другой, для отправки в налоговую инспекцию по электронному документообороту третий, для годового отчёта Вельзевулу четвёртый. Будем усложнять уровень абстракции?

Это у нас только JSON. А есть ещё отображение, динамика, печать на бланке, контроль консистентности, репликация и штучки три интеграции с другими системами по ETL (как водится, в обе стороны, и совсем не через JSON). В какой-то момент времени мы титаническими усилиями приходим к тому, что со всем справились. Но тут вдруг возникает необходимость (не «хотелка», а именно суровая необходимость) добавить новую сущность. Какое-нибудь Remedy. По аналогии с Weapon. Мы смотрим, как у нас обвешан загадочными гроздьями мета-штук Weapon и понимаем, что зря пошли в программисты.

Код живой и мёртвый. Часть первая. Объекты

0
Расплывчатое понимание догмы и контекстнозависимое её применение — это Вы какую-то бездуховность сейчас проповедуете. Прямо фашизм какой-то.

Код живой и мёртвый. Часть первая. Объекты

+1
Буква «S» в наборе «SOLID» прямым текстом говорит нам, что не должно быть так, чтобы объект сам себя менеджил, провайдил, гетил, сетил, ридил, райтил, валидэйтил, энкодил, декодил, диспетчил. Это бы прямо нарушало принцип «single responsibility». SOLID — святое. Догма. Принимается без дискуссии и включения мозга. Вот и городим зоопарк.

Криптография в Java. Класс Certificate

0
Который является частью… ну да, сертификата.
Странно получается. По сути, файл с расширением «cer» — это публичный ключ. Этот ключ дополнен подписью удостоверяющего центра, которая подтверждает, что бинарные данные ключа соответствуют описательным полям (субъект, мэйл, то-сё). Но самая мякотка, суть и смысл существования этого файла — всё же ключ. Всё остальное, в том числе подпись УЦ — это дополнительные данные разной степени полезности.

Почему же ключ не назвать ключом? Почему мы стабильно запрягаем телегу впереди лошади? Почему допускаем понятийную путаницу?

Когда генерится ключевая пара, мы имеем два ключа — секретный и публичный. Публичный мы можем снабдить сертификатом соответствия. А можем и не снабжать. Можем снабдить, но оформить отдельным файликом. Почему бы и нет? Заливка ключа и сертификата к нему в один файл — это всего лишь один из возможных вариантов. В том же Биткоине, например, асимметричная криптография используется вовсю, но никаких сертификаций там отродясь нет.

Криптография в Java. Класс Certificate

0
Мой вопрос покажется совсем чайниковским, но, уверяю, это не так.
… представляет собой сертификат удостоверяющий принадлежность некоторому субъекту, например, пользователю.
Принадлежность чего? Не может же ведь быть «просто принадлежность». Одну сторону отношения «принадлежит» мы обозначили (это у нас пользователь), но что у нас на другой стороне?

Автоматы против спагетти-кода

Как запретить стандартные пароли и заставить всех тебя ненавидеть

+1
Расстояние Левенштейна — это та шняга, через которую обычно составляют список вариантов замены для подчёркнутых красненьким слов. Минимальное количество мутаций (вставок/удалений/замен), через которые можно одну последовательность буковок превратить в другую. Там довольно прикольный быстрый алгоритм.

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

Как запретить стандартные пароли и заставить всех тебя ненавидеть

+3
Всё так, но если внимательно посмотреть на саму задачу улучшения качества паролей, то можно заметить, что повсеместно практикуемый подход, мягко говоря, дебильный.
Пароль — это то, что подлинный пользователь знает, а злоумышленник узнать не может. Банальность, конечно, но это полезно вспомнить, чтобы попытаться за это зацепиться. Из этой формулировки сразу следуют две полезные вещи:
1. Пароль должен быть чем-то таким, что пользователь может помнить, не прибегая к дополнительным костылям. Например, пароль «gX3K$9Lwfj%29E#» выглядит хорошим, но его невозможно запомнить, и поэтому пользователь запишет его на бумажку и подсунет под клавиатуру. Это плохой пароль.
2. Существуют способы подбора паролей, которые используются для взлома. Они эволюционируют, но не то что бы бурно. Эволюционируют скорее количественно (облачные вычисления, CUDA, ботнеты, ASIC), чем качественно. Чего-то совсем радикально нового по этой части, насколько мне известно, не появлялось уже очень давно. То есть нам известно, от чего нужно защищаться. Если пароль не может быть с разумными затратами подобран известными методами, то его можно и нужно считать стойким.

Итого имеем два критерия: лёгкость запоминания пользователем и стойкость к известным методам подбора. Где в этих двух простых критериях про регистр букв, цифры и спецсимволы? Да нигде. Повсеместно используемые формальные критерии сложности пароля — попытка загнать большую и сложную проблему в прокрустово ложе некоторого набора правил, составленных без оглядки на те критерии, которые действительно имеют отношение к делу.

В порядке «критикуешь — предлагай». Основа подбора паролей — пробивка словарей с последующим поиском в ширину по мутациям. В качестве словаря берутся:
1. Популярные пароли (всякие «123456», «password», «admin» и далее по списку).
2. Словари слов на разных языках.
3. Базы сломанных аккаунтов.
Поиск в ширину от первых двух имеет смысл, от третьего — слишком затратно. По первым двум ищем минимум расстояния Левенштейна, по третьему просто смотрим попадание. Для п.1 расстояние Левенштейна требуем не меньше, например, 5, а по п.2 — не меньше 3. В результате и алгоритмы подбора остаются не у дел, и не парим пользователя дурацкими требованиями про цифры и спецсимволы.

Как запретить стандартные пароли и заставить всех тебя ненавидеть

0
начиная с двадцати разрешить пароли про лошадей без спецсимволов
Можно. Вот только знают об этом меньше 1% админов. И поэтому по умолчанию требуют спецсимволы :(

Как запретить стандартные пароли и заставить всех тебя ненавидеть

+12
Все эти парольные политики бесят неимоверно. Они мешают мне иметь хорошие пароли.

Если меня не насилуют этим идиотизмом, и мне для чего-то нужен действительно мощный пароль, одна из моих стратегий примерно такая:
1. Иду на what3words.com
2. «Показать карту»
3. Нахожу место, с которым связано что-то личное. Какой-нибудь жизненный эпизод. Это место не должно быть туристическим (т.е. макушка Эйфелевой башни не годится) или знаменитым (центр храма Кааба тоже не подойдёт). Например, меня как-то на трассе штрафанули за превышение скорости на 300 рублей в точке «храпящий.инвертировать.плодовитый». Соответственно, сочиняю себе пароль: «храпящий инвертировать плодовитый 300». В блокнотик записываю себе подсказку: «обидно, но могло быть больше».

Удачи алгоритмам подбора пароля. Она им пригодится. Также удачи тем, кто по подсказке будет пытаться угадать, о чём вообще речь.
Сразу этот пароль я, конечно, не запомню. Запомню только после того, как десяток раз схожу за ним в what3words.

Заводишь такой по всем разумным критериям прекрасный пароль, и получаешь в лицо, что, дескать, слабоват, не обеспечивает требований домена. Ну ладно, ну ОК, держите w0rd123Pa$$, плохие злые люди. Подавитесь своей политикой.

Настало ли время для URL, содержащих эмодзи?

+1
Впредь буду осторожнее
Ни в коем случае!!! Так оно даже лучше получилось ;)

Настало ли время для URL, содержащих эмодзи?

+6
Особенно понравилось вот это:
И это только одна из проблем людей, использующих в URL эмодзи.
Другие проблемы: потаявший смузи, порвавшийся свитшот, обморожение в зоне подворота штанин.

Эх, даже немножко жаль, что это первоапрельский пост :))

5 трендов Интернета Вещей, о которых должен знать каждый

0
Да ладно, всё не так уж и суицидально, ежели в корень посмотреть. Включаем здоровый прагматизм, разбираемся в собственных жизненных приоритетах, и то, что действительно нам важно (свобода, вопросы жизни и смерти, ядро собственной личности, а также что там у каждого из нас есть личного святого) оставляем под полным личным контролем, а прочую неважную суету — нахрен в облако.
Да, и не забывать фронидировать и стебаться над энтузиазмом поклонников подхода «нахрен всё в облако без остатка».
1 There