Книги Скотта Майерса можно за 1-2 вечера прочитать. Вот только если у тебя нет за плечами опыта в разработке на С++, то пользы от этого прочтения будет даже меньше, чем от прочтения дамского слезливого романа.
Ну ладно бы 9 месяцев только на С++ учили писать… Но тут обещают, что из тебя за это время выйдет «и шнец и жнец, и на дуде дудец»
Самое веселое, это то, что после всего этого, тебе обещают, что ты сможешь поработать на дядю 3 месяца после окончания курсов без оплаты… Ой сорри, почему я решил, что без оплаты… Ты же за курсы заплатил!
Вы уж определитесь, это простая задача, которая может рассматриваться, как «практика для изучающих программирование» и «тестовое задание для отбора кандидатов», или все же сложная задача для «интересного времяпрепровождения опытных разработчиков»
SELECT * FROM Schuhe_Farbe SF, Schuhe_Groesse SG, Alle_Sache AS WHERE SG.Groesse = :Groesse AND SG.Groesse_id = AS.Groesse_id AND AS.Farbe_id = SF.Farbe_id
Проблема в том, что язык программирования, это немного больше чем названия команд и зарезервированных слов.
Язык программирования включает в себя большой набор прадигм, правил хорошего стиля кода и т.д. и т.п.
Показав человеку, что в двух ЯП, используемых как правило в различных областях, есть ключевые слова с подобными названиями, это как сравнивать русский и английский языки, рассказывая, что в них есть слова и буквы с одинаковым звучанием, и надеясь что знание русского языка, на этом основании, станет некоторым руководством для людей, которые хотят изучить английский язык, зная русский.
Когда первые наработки умных чемоданов появились, уже тогда говорили, что их запретят провозить в самолетах. Но похоже кто-то не мог на шаг вперет планировать.
Ну и подозреваю, что дело далеко не в авиакомпаниях, разработать чемодан со съемной не бог весть какая сложная задача. Да, переналадка производственной линии денег стоит, но был бы реальный спрос — перенастроили бы.
— Не беспокойтесь, — сказал Остап, — мой проект гарантирует вашему городу неслыханный расцвет производительных сил. Подумайте, что будет, когда турнир окончится и когда уедут все гости. Жители Москвы, стесненные жилищным кризисом, бросятся в ваш великолепный город. Столица автоматически переходит в Васюки. Сюда переезжает правительство. Васюки переименовываются в Нью-Москву, а Москва — в Старые Васюки. Ленинградцы и харьковчане скрежещут зубами, но ничего не могут поделать. Нью-Москва становится элегантнейшим центром Европы, а скоро и всего мира.
— Всего мира!!! — застонали оглушенные васюкинцы.
— Да! А впоследствии и вселенной. Шахматная мысль, превратившая уездный город в столицу земного шара, превратится в прикладную науку и изобретет способы междупланетного сообщения. Из Васюков полетят сигналы на Марс, Юпитер и Нептун. Сообщение с Венерой сделается таким же легким, как переезд из Рыбинска в Ярославль. А там, как знать, может быть, лет через восемь в Васюках состоится первый в истории мироздания междупланетный шахматный турнир!
Остап вытер свой благородный лоб. Ему хотелось есть до такой степени, что он охотно съел бы зажаренного шахматного коня.
Не факт. Если придерживаться правила, что геттеров и сеттеров не имею только простые структуры, а доступ к членам более/менее сложных классов осуществляется только через геттеры и сеттеры, то это сильно упрощает жизнь в будущем. Например в будущем может понадобится, чтобы обновление поля дублироваллось соответствующей записью в БД, или при обновлении нужно будет добавить верификацию данных.
Прелесть геттеров и сеттеров программист начинает ценить, когда 10-й раз переделывает интерфейс из-за того, что возникает необходимость изменить поведение объекта на установку или запрос какого-то поля.
Ну простые искажения, типа «поиграться с яркостью/контрастом» действительно не помогут, т.к. у perceptual hash эти хэши строятся не на основании оригинальной картинки, а у ее производной. Но вот изменение яркости + смещение/обрезание + добавление текста обойдет такой хеш без особых проблем.
Может perceptual hash. Боюсь что и они обходятся обрезанием и искажением картинки. Тот же TinEye не всегда способен найти картинку, которая гарантированно есть в Интернете, но правильно искажена.
Просто завтра напишут программу заменяющую 1 пиксель на фотографии, и вся система накроется медным тазом, потому как типичная(ый) пользователь сможет ее скачать и использовать.
P.S. Меня убивает это выражение «типичный западный пользователь». Неужели кто-то еще верит, что на западе «ну тупые они, тупые» (С)
Вся правда заключается в том, что если поднять зарплату и убрать премию, то депремировать не получится, т.к. трудовое законодательство прямо запрещает такое. Вот и остается единственный вариант, описанный автором.
Задачу менеджера я вижу именно в том, что бы настроить процессы таким образом, что бы они максимально выполнялись без участия руководства.
Не могу понять эту фразу, как ни кручу.
Во первых, что она не имеет смысла, т.к. «manager» с английского буквально переводится как «руководитель», т.е. грубоговоря написано «задачу руководителя я вижу именно в том, что бы настроить процессы таким образом, что бы они максимально выполнялись без участия руководства.» — мало того, что такого не бывает, та еще и возникает вопрос, нахрена нам менеджер, после того, как процессы настроенны?
Я против ручного управления и предпочитаю работать с сильными специалистами, которые могут для своих рутинных работ и приоритеты верно настроить, и продумать последствия своих действий.
И поэтому ты предлагаешь их депремировать, вот этих вот «сильных специалистов», которые благодаря настроенным процессам могут взять инициативу в свои руки, верно определять приоритеты и думать о последствиях своих действий?
Более того, если у специалиста бэкап перед накаткой изменений прописан, а он не сделал — то в первую очередь кужно разобраться, почему, может его вообще на проекте лучше не держать, а может его 2-ю неделю овертаймить заставляют.
Ну а если такой бэкап в процессах не прописан, то менеджера нужно пороть, а не специалиста
Депремирование приводит к тому, что люди перестают браться за трудные задачи (можно накосячить = лишиться премии). Перестают помогать другим (можно со своей таской не успеть = лишиться премии). Принимать ответственные решения (можно ошибиться = лишиться премии)
У депремирования есть только одна хорошая сторона, оно позволяет без проблем от некоторых людей избавиться. Но и тут есть нехилая вероятность, что уйдут не те, кто нихрена не делает, а те, кто проект на себе тащил.
По поводу округлений, автор предлагает сейчас писать процессорозависимый код. Отличное решение! Пусть программист пишет под все типы процессоров, которые на текущий момент имеются. А про преждевременную оптимизацию — это для лохов сказано. И не важно, скажем, что программа будет терять по 10-15 секунд на постоянных обращениях к БД, зато на процессорах семейства Pentium, она будет выполнять округление на 0.00001 с быстрее.
И на счет банковского округления мне понравилось. Автор решил, что это самый «правильный» метод округления, значит тому и быть.
Ты не понял, мой посыл в том, что теги не так универсальны, как хотелось бы.
— Во первых, не однозначность использования слов для самих тегов. В 2014 году я помечал фотографии словом «фото», потом «фотки», потом «фотографии» потом еще как-то. В свою очередь год можно пометить как «2000», «2000г», «2000 г.» и т.д. Можно сказать, что это пользователь виноват. Да, это так, вот только проблема, пользователь не обязан ни только быть аккуратным, он вообще не обязан даже теги расставлять.
Кстати — это хорошо демонстрируют различные сайты, на которых контент создается пользователями.
— Во вторых, теги имеют свойство плодиться. К примеру Вася, был в Египте 10 раз, 2 раза в 2000 году, два рада с 5-ю друзьями, один — с 10-ю, в остальные разы с 1 — 3-мя друзьями. Друзья в его поездках пересекаются, у некоторых друзей одинаковые имена. И т.д.
В результате в начале он даст фоткам теги Египет, потом начнет добавлять тег года, потом ему может понадобиться указать имена друзей, далее, из-за того, что имена могут пересекаться — еще и фамилии. И так далее. А еще он может не только в Египет ездит. А некоторые теги — дублируются, как в п.1 и т.д. Как думаешь, сколько пользователей начнут этим заморачиваться? По мне, так хорошо, если 10-15%. А большинство и одного тега не дадут.
Книги Скотта Майерса можно за 1-2 вечера прочитать. Вот только если у тебя нет за плечами опыта в разработке на С++, то пользы от этого прочтения будет даже меньше, чем от прочтения дамского слезливого романа.
Самое веселое, это то, что после всего этого, тебе обещают, что ты сможешь поработать на дядю 3 месяца после окончания курсов без оплаты… Ой сорри, почему я решил, что без оплаты… Ты же за курсы заплатил!
Это как бы взаимоисключающие понятия.
Это делается так
Язык программирования включает в себя большой набор прадигм, правил хорошего стиля кода и т.д. и т.п.
Показав человеку, что в двух ЯП, используемых как правило в различных областях, есть ключевые слова с подобными названиями, это как сравнивать русский и английский языки, рассказывая, что в них есть слова и буквы с одинаковым звучанием, и надеясь что знание русского языка, на этом основании, станет некоторым руководством для людей, которые хотят изучить английский язык, зная русский.
Ну и подозреваю, что дело далеко не в авиакомпаниях, разработать чемодан со съемной не бог весть какая сложная задача. Да, переналадка производственной линии денег стоит, но был бы реальный спрос — перенастроили бы.
Просто завтра напишут программу заменяющую 1 пиксель на фотографии, и вся система накроется медным тазом, потому как типичная(ый) пользователь сможет ее скачать и использовать.
P.S. Меня убивает это выражение «типичный западный пользователь». Неужели кто-то еще верит, что на западе «ну тупые они, тупые» (С)
Не могу понять эту фразу, как ни кручу.
Во первых, что она не имеет смысла, т.к. «manager» с английского буквально переводится как «руководитель», т.е. грубоговоря написано «задачу руководителя я вижу именно в том, что бы настроить процессы таким образом, что бы они максимально выполнялись без участия руководства.» — мало того, что такого не бывает, та еще и возникает вопрос, нахрена нам менеджер, после того, как процессы настроенны?
И поэтому ты предлагаешь их депремировать, вот этих вот «сильных специалистов», которые благодаря настроенным процессам могут взять инициативу в свои руки, верно определять приоритеты и думать о последствиях своих действий?
Серьезно?!
Ну а если такой бэкап в процессах не прописан, то менеджера нужно пороть, а не специалиста
Депремирование приводит к тому, что люди перестают браться за трудные задачи (можно накосячить = лишиться премии). Перестают помогать другим (можно со своей таской не успеть = лишиться премии). Принимать ответственные решения (можно ошибиться = лишиться премии)
У депремирования есть только одна хорошая сторона, оно позволяет без проблем от некоторых людей избавиться. Но и тут есть нехилая вероятность, что уйдут не те, кто нихрена не делает, а те, кто проект на себе тащил.
И на счет банковского округления мне понравилось. Автор решил, что это самый «правильный» метод округления, значит тому и быть.
— Во первых, не однозначность использования слов для самих тегов. В 2014 году я помечал фотографии словом «фото», потом «фотки», потом «фотографии» потом еще как-то. В свою очередь год можно пометить как «2000», «2000г», «2000 г.» и т.д. Можно сказать, что это пользователь виноват. Да, это так, вот только проблема, пользователь не обязан ни только быть аккуратным, он вообще не обязан даже теги расставлять.
Кстати — это хорошо демонстрируют различные сайты, на которых контент создается пользователями.
— Во вторых, теги имеют свойство плодиться. К примеру Вася, был в Египте 10 раз, 2 раза в 2000 году, два рада с 5-ю друзьями, один — с 10-ю, в остальные разы с 1 — 3-мя друзьями. Друзья в его поездках пересекаются, у некоторых друзей одинаковые имена. И т.д.
В результате в начале он даст фоткам теги Египет, потом начнет добавлять тег года, потом ему может понадобиться указать имена друзей, далее, из-за того, что имена могут пересекаться — еще и фамилии. И так далее. А еще он может не только в Египет ездит. А некоторые теги — дублируются, как в п.1 и т.д. Как думаешь, сколько пользователей начнут этим заморачиваться? По мне, так хорошо, если 10-15%. А большинство и одного тега не дадут.