Да! Я прочитал эту книжку лет за 10 до того как услышал слово «нейросеть», и лишь много-много позже вспомнил и осознал, как точно (для детского уровня) описан процесс её обучения. Здорово, что ещё кто-то вспомнил!
Ну почему вы сами пишете, что отношение может быть предвзятым, а потом утверждаете, что достаточно быть на одном уровне?
Нет, ну понятно, что на работу спеца таки возьмут. Но Махмуду придётся сходить, допустим на 5 собеседований, а Майку хватит 3-х. Или он тоже сходит на 5, но найдёт работу с зарплатой повыше. Может, разница будет не очень большой, но статистически значимой.
Так их весь мир знает, конечно им уже не надо ничего доказывать. Но если вы не знаете человека, видите его первый раз в жизни?
Просто вы же сами написали, что большинство европейцев при прочих равных предпочтёт взять на работу «Александра» а не «Махмуда». Вот и получается, что даже если этот Махмуд, как вы сказали, специалист в своём деле, ему нужно быть не «не хуже», а лучше белых, чтобы конкурировать с ними на равных на рынке труда.
Я потому и вспомнил Ливию, что подумал о трубах. Масштабы, конечно, сравнивать трудно, но больше, кажется, не с чем.
Обидно, что при общественных обсуждениях большая часть возражений — не по объективным техническим недостаткам, а на основе эмоциональных доводов без внятного обоснования — типа «в экологию нельзя вмешиваться от слова совсем» или вообще «негоже человеку замахиваться на такое».
Грустно это, на самом деле. С одной стороны, байесовская классификация по расе/национальности реально работает. С другой стороны, одному человеку всю жизнь приходится доказывать, что он не верблюд, а другому — нет. По честному, смотреть-то надо на верблюдность, а не национальность, но люди склонны упрощать себе процесс решения. В итоге оба варианта вырождаются до уродливых крайних форм :-(
Насчёт скорости течения, я просто подумал, что чем быстрее течёт вода, тем меньше её успеет испариться/впитаться по дороге, разве нет?
А вообще, как и с другими крупными проектами, на этом, возможно, крест поставила недооценка технических трудностей — как раз таких как потери и расход энергии. Насчёт телепорта вы хорошо сказали. С другой стороны, сама мысль: вот тут воды много, тут мало, и расстояние явно меньше, чем от Амазонки до Сахары — всё же захватывает.
Я вспомнил ливийскую систему водоснабжения — «Великая рукотворная река». Там вроде общая протяжённость труб получается сходной. Расход, конечно, раз в 20 меньше…
Ну во-первых пропускная способность там указывается пиковая, а средний поток был бы скорее всего в полтора-два раза меньше. По поводу Иртыша я бы ещё расставил в статье на Вики запросы источников, но ленюсь.
Во-вторых, спасение Арала всё-таки вещь вторичная. Как выше заметили, главное — поддержка сельского хозяйства, на котором основана местная экономика. Да и чисто по-человечески это важнее.
Насчёт потерь не смогу ничего сказать конкретно, но могу предположить, что потери зависят от скорости движения воды. По каналу Москва-Волга я плавал — течение там небыстрое…
Ну и ГМО вы зря помянули — как раз недавно выходила статья об очередном исследовании, не выявившем никакого их вреда кроме пользы. Понятно, что в экологии, как и во многих других областях, если где-то прибывает, где-то убывает. Но по-моему в данном случае совокупная польза превзошла бы вред.
Как внук инженера по гидросистемам, не понаслышке знакомого с климатом и водоснабжением в Средней Азии, и сын инженера-нефтегазовика, не понаслышке знакомого с климатом Западной Сибири, я не могу пройти мимо упоминания о повороте сибирских рек.
Во-первых, поворачивать все реки никто не собирался. Общие объёмы должны были составлять единицы процентов от стока. Повернуть такую реку как Обь целиком сейчас просто нереально.
Во-вторых, количество воды на Западно-сибирской низменности таково, что огромные пространства представляют из себя просто болота. Снижение избыточного увлажнения вряд ли сильно отрицательно сказалось бы на регионе. Не говоря уже о регулярных половодьях на реках, текущих с юга на север.
В то же время, в-третьих, Средняя Азия уже тогда страдала от недостатка воды, а сейчас тем более. Тут упомянули Арал — а возможно, его бы не ждала столь печальная участь.
Кажется, с проектом сыграло злую шутку то, что по советской традиции он получил громкое наименование — «поворот рек», — а потом времена поменялись, и его стали воспринимать в ключе «и возгордились люди».
Что касается индусов — могу только пожелать им успехов в их начинаниях. Ганг, кстати, несёт больше воды, чем Обь — почти как Лена, а Брахмапутра — ещё больше, как Енисей.
Да, я вас понял. Но дело в том, что у нас иногда требуется какое-то поле передать на клиент под другим именем, или вообще не нужно передавать. Простой пример: в базе в сущности User хранится поле manager_id, а клиенту удобнее передавать поле manager, чтобы там оперировать полями связанной сущности Manager как user.manager.name, а не user.manager_id.name. Сейчас мы просто пишем в аннотации к полю manager_id
Если для другого клиента понадобится другой набор полей или другие их имена, то всю эту информацию всё равно придётся где-то хранить.
Если же говорить о формате данных, то сериализацией и сейчас, конечно, ведает отдельный класс. Если вдруг понадобится отдавать данные не в JSON, а в XML, то нужно будет просто добавить новый сериализатор.
Что касается прав доступа, то их проверка находится в ведении контроллера, отдающего сущность клиенту. Он может, например, обнулить секретные поля.
Вообще я так с ходу даже не могу придумать, кто третий может прийти в наше уютненькое приложение с фронтендом и бэкендом. Но да, в существующей архитектуре знания сущности умножатся. Это не кажется мне большой проблемой, учитывая что 90% полей передаются как есть из базы, не требуя дополнительного описания, а для оставшихся мы сейчас используем симпатичные аннотации. Механизм из примера с возвратом массива — это старый вариант, который мы ещё не везде переписали. Если же клиенты размножатся до проблемного количества, придётся задуматься над рефакторингом.
Я старался везде подчёркивать, что речь идёт именно о статической локальной переменной, а статические свойства классов вообще не использовал.
То, что методы (обычные, не статические!) связаны с классом, где они написаны, а не с объектом и про вызове в них просто прокидывается $this — мне думалось, что общеизвестно…
Вы правы, но на деле всё получается несколько сложнее. Контекст статических переменных (и некоторая другая информация) создаётся отдельно для каждого класса, даже если сам метод в нём не объявлен (см. мой пример 1).
Там ещё, кстати, про планарную технологию было.
Нет, ну понятно, что на работу спеца таки возьмут. Но Махмуду придётся сходить, допустим на 5 собеседований, а Майку хватит 3-х. Или он тоже сходит на 5, но найдёт работу с зарплатой повыше. Может, разница будет не очень большой, но статистически значимой.
Просто вы же сами написали, что большинство европейцев при прочих равных предпочтёт взять на работу «Александра» а не «Махмуда». Вот и получается, что даже если этот Махмуд, как вы сказали, специалист в своём деле, ему нужно быть не «не хуже», а лучше белых, чтобы конкурировать с ними на равных на рынке труда.
Обидно, что при общественных обсуждениях большая часть возражений — не по объективным техническим недостаткам, а на основе эмоциональных доводов без внятного обоснования — типа «в экологию нельзя вмешиваться от слова совсем» или вообще «негоже человеку замахиваться на такое».
То есть обращения президента к нации вы не смотрите? ;-)
Зато как приятно, продравшись через дебри, написать ответ на этот вопрос =)
А вообще, как и с другими крупными проектами, на этом, возможно, крест поставила недооценка технических трудностей — как раз таких как потери и расход энергии. Насчёт телепорта вы хорошо сказали. С другой стороны, сама мысль: вот тут воды много, тут мало, и расстояние явно меньше, чем от Амазонки до Сахары — всё же захватывает.
Я вспомнил ливийскую систему водоснабжения — «Великая рукотворная река». Там вроде общая протяжённость труб получается сходной. Расход, конечно, раз в 20 меньше…
Ага, мы вернёмся от моего примера 3 к примеру 2.
Я придумал, надо этот метод оставить
protected, но пометить какfinal, чтобы никто потом не тянулся к нему грязным ручками.Во-вторых, спасение Арала всё-таки вещь вторичная. Как выше заметили, главное — поддержка сельского хозяйства, на котором основана местная экономика. Да и чисто по-человечески это важнее.
Насчёт потерь не смогу ничего сказать конкретно, но могу предположить, что потери зависят от скорости движения воды. По каналу Москва-Волга я плавал — течение там небыстрое…
Ну и ГМО вы зря помянули — как раз недавно выходила статья об очередном исследовании, не выявившем никакого их вреда кроме пользы. Понятно, что в экологии, как и во многих других областях, если где-то прибывает, где-то убывает. Но по-моему в данном случае совокупная польза превзошла бы вред.
Во-первых, поворачивать все реки никто не собирался. Общие объёмы должны были составлять единицы процентов от стока. Повернуть такую реку как Обь целиком сейчас просто нереально.
Во-вторых, количество воды на Западно-сибирской низменности таково, что огромные пространства представляют из себя просто болота. Снижение избыточного увлажнения вряд ли сильно отрицательно сказалось бы на регионе. Не говоря уже о регулярных половодьях на реках, текущих с юга на север.
В то же время, в-третьих, Средняя Азия уже тогда страдала от недостатка воды, а сейчас тем более. Тут упомянули Арал — а возможно, его бы не ждала столь печальная участь.
Кажется, с проектом сыграло злую шутку то, что по советской традиции он получил громкое наименование — «поворот рек», — а потом времена поменялись, и его стали воспринимать в ключе «и возгордились люди».
Что касается индусов — могу только пожелать им успехов в их начинаниях. Ганг, кстати, несёт больше воды, чем Обь — почти как Лена, а Брахмапутра — ещё больше, как Енисей.
Позднее статическое связывание тут не поможет, придётся определять
protected static $cache;в каждом дочернем классе (http://stackoverflow.com/a/4577202/2821101).Лучше уж такой вариант https://habrahabr.ru/post/301478/#comment_9622288.
ну по правде говоря, да =)
Такая архитектура, конечно, более гибкая, но придётся делать по преобразователю для каждой сущности и клиента...
Да, я вас понял. Но дело в том, что у нас иногда требуется какое-то поле передать на клиент под другим именем, или вообще не нужно передавать. Простой пример: в базе в сущности
Userхранится полеmanager_id, а клиенту удобнее передавать полеmanager, чтобы там оперировать полями связанной сущностиManagerкакuser.manager.name, а неuser.manager_id.name. Сейчас мы просто пишем в аннотации к полюmanager_idЕсли для другого клиента понадобится другой набор полей или другие их имена, то всю эту информацию всё равно придётся где-то хранить.
Если же говорить о формате данных, то сериализацией и сейчас, конечно, ведает отдельный класс. Если вдруг понадобится отдавать данные не в JSON, а в XML, то нужно будет просто добавить новый сериализатор.
Что касается прав доступа, то их проверка находится в ведении контроллера, отдающего сущность клиенту. Он может, например, обнулить секретные поля.
Вообще я так с ходу даже не могу придумать, кто третий может прийти в наше уютненькое приложение с фронтендом и бэкендом. Но да, в существующей архитектуре знания сущности умножатся. Это не кажется мне большой проблемой, учитывая что 90% полей передаются как есть из базы, не требуя дополнительного описания, а для оставшихся мы сейчас используем симпатичные аннотации. Механизм из примера с возвратом массива — это старый вариант, который мы ещё не везде переписали. Если же клиенты размножатся до проблемного количества, придётся задуматься над рефакторингом.
А какую архитектуру вы предлагаете?
Вы правы, но на деле всё получается несколько сложнее. Контекст статических переменных (и некоторая другая информация) создаётся отдельно для каждого класса, даже если сам метод в нём не объявлен (см. мой пример 1).