Я немного не уловил разницу в этих двух подходах. В обоих случаях создается некая заглушка. В первом случае заглушку генерит Moq, во втором вы пишите её руками. Если в коде что-то меняется так, что первый вариант нужно переписать, то с вероятностью близкой в 1, второй вариант тоже надо будет переписать. Так в чем же разница?
Знающие люди, поясните за модули в Java. Владимир Ситников предполагает, что это поможет избежать перекомпиляции кода при каждом запуске и позволит собирать более компактные jvm с урезанной стандартной библиотекой. Но ведь для этих целей модули вообще не нужны. Проверить изменения jar-ника можно по «inode + дата изменения + размер» или по хешу в крайнем случае. Модули ведь не дают больше гарантий, чем такая простая проверка? А что касается стандартной библиотеки, можно один большой jar разбить на 50 маленьких и при старте просто проверять наличие/отсутствие файлов по списку. Такая проверка, опять же, ничего не стоит. Получается, что потратили 5 лет (или не знаю, сколько, но много), усложнили жизнь некоторым разработчикам, но зачем?
Я всё жду статью, которая объяснит мне, зачем это делать. Пока лишь вижу какую-то субъективщину и вкусовщину. К тому же ряд возможностей scala, которые некоторые пытаются занести в недостатки, мне нравятся и их будет не хватать. Тот же implicit можно использовать безопасно и удобно в куче сценариев. А без pattern matching'а вообще не понятно как писать компактный код, это ж java какая-то получается.
Всё что я увидел из этой статьи, по большому счету, что kotlin нравится тем, что в нем нет некоторых возможностей scala и парой мест, где дело исключительно во вкусе. И, получается, что из-за этого некоторая компания год назад перешла с одного языка на другой. И при этом почти сразу после появления второго языка. Есть подозрение, что если эта компания и существует, то состоит она примерно из одного сотрудника.
Я согласен, что это достаточно грязный трюк получается.
А что касается работы через api, то тут возможностей у фейсбука гораздо больше появляется, т.к. api он полностью контролирует. И хотя теоретически обойти можно любую подобную защиту, но на практике сложность будет гораздо выше, чем сделать adblock целиком. Поэтому в подобном сценарии такая компания как фейсбук, могла бы себе позволить помериться силами с сообществом.
зы: ну и понятно, что подобный способ показать рекламу обычный сайт позволить себе не сможет.
Предлагаю способ, который трудно будет заблокировать. Нужно часть полезного контента вместе с рекламой рендерить на <canvas>. Сейчас большинство браузеров этот элемент поддерживают и это можно проверять. А вот заблокировать это будет очень сложно, если вместе с рекламой будет действительно важный контент, типа меню и пр. При этом для пользователя можно выделить все что нужно согласно закону. Тогда нужно будет делать отдельное расширение, которое будет воссоздавать заблокированную часть страницы, но наверное и с этим можно что-то сделать. В целом интересная техническая задача для каждой из сторон.
Благодарю за свое мнение. В принципе я с ним согласен. А что касатеся статьи, было бы конечно интересно почитать что-то выходящее за рамки очевидного, что было бы применимо к более широкому кругу ситуаций, чем общение с соседом по рабочему месту.
Ну конечно же я вашего мнения и спрашивал, а не автора оригинала. Понятно, что я имею право высказывать любое свое мнение. Однако противоположная сторона в ответ обязательно воспользуется своим правом заставить вас пожалеть о своем мнении. И как же поступать в ситуации, когда вы в подчиненном и просто более слабом положении. Возможно часть советов здесь применима, только когда имеешь дело с равным коллегой или есть какие-то дополнения для подобных неравных ситуаций?
В ответ на указание явной манипуляции (из пункта 3) в первом комментарии, его автор не только нагадил в карму но и не поленился сделать тоже самое на гиктаймсе. Применяю пункт 1 и рассказываю об этом окружающим. Как считает автор статьи, правильно ли я поступаю в ситуации, когда манипулятор обладает влиянием, или это приведет к дальнейшему ухудшению ситуации?
Это, кстати, достаточно естественно выглядит. Т.к. математика напрямую отображается в команды процессора без особых накладных расходов. Как я понимаю, основные проблемы возникают при работе с памятью. Т.е., допустим, я не могу накопить массив байтов и потом конвертировать его в строку без копирования. И подобные копирования в очень многих местах при работе с java встречаются. В то же время на c/c++/rust подоных копирований можно избежать не теряя читабельность кода и не изобретая свои велосипеды под конкретные случаи.
А вообще в природе есть эти самые тесты реальных программ, которые показывают, что ява быстрая? Я как-то в основном натыкаюсь на тесты, которые этого, скажем так, не показывают. Т.е. мне действительно было бы интересно почитать такие сравнения с другими языками как раз на реальных программах, а не на тестах в 10 строк.
Вообще, при интенсивном использовании любой библиотеки, почти всегда наталкиваешься на какой-то код который работает не так, как этого ожидаешь. И вот тогда неминуемо приходится лезть в исходники. Тут на хабре с год назад эпизод был (ссылку сейчас не найду), когда пытались разобраться, что делает какой-то метод из старой версии Scalaz (в текущей подобного уже нет) и в итоге так никто и не осилил. Если бы подобные библиотеки действительно можно было использовать как «черный ящик», то вопросов бы к ним не было, но на практике это обычно не получается.
Не хотел обидеть
Ну что вы, никто и не думал обижатся. Мы тут, по возможности конструктивно, просто обмениваемся личными мнениями, а они не обязаны совпадать )
В плане демострации каких-то математических абстракций может быть действительно это оптимальный подход. Но когда речь идет о таких обыденных вещах, как работа с xml и json, лично мне было бы приятнее работать с библиотекой, по коду которой я без проблем могу сказать, что она делает, не тратя часы на то самое разматывание кода. Ну и опять же, в хаскеле подобный код читается легче из-за большей заточенности языка под функциональный подход и там можно разбираться даже в текстовом редакторе, что как бы говорит о том, что одни и те же вещи можно реализовать с разной красотой и аккуратностью.
Здесь конечно слишком мало кода, чтобы можно было оценить возможную обфусцированность. Гораздо интереснее в этом смысле читается код самой Scalaz.
вот это я вообще каждый раз удивляюсь как встречаю, что IDE отменили? вроде уже даже Eclipse умеет переходить в имплиситы и подчёркивать их
В том то и дело, что для того, чтобы понять, что же происходит, надо по каждому методу тыкать ctrl+click и смотреть куда в итоге попадешь, а имплиситы могут быть и многоуровневыми (особенно во всяких Scalaz). В то время как обычный код можно просто читать. Из-за этого разница в скорости понимания происходящего будет в разы.
Получилось конечно кратко, но на мой взгляд проблема подобного кода в том, что без соответствующей статьи с пояснениями его поддерживать невозможно. Такое лучше писать на хаскеле хотя бы потому, что там подобный код будет более читаемым и понятным, а на скале с кучей имплиситов можно потом очень долго пытаться понять какие преобразования и откуда применились в этой функции на пять строк. Кроме того, описанная тут задача решается даже на яве без необходимости написания сотен строк копипасты. В общем применение подобного подхода в целом и Scalaz в частности кажется здесь весьма надуманным и сильно усложнит жизнь тем, кому с этим потом придется работать.
А что касается работы через api, то тут возможностей у фейсбука гораздо больше появляется, т.к. api он полностью контролирует. И хотя теоретически обойти можно любую подобную защиту, но на практике сложность будет гораздо выше, чем сделать adblock целиком. Поэтому в подобном сценарии такая компания как фейсбук, могла бы себе позволить помериться силами с сообществом.
зы: ну и понятно, что подобный способ показать рекламу обычный сайт позволить себе не сможет.
В ответ на указание явной манипуляции (из пункта 3) в первом комментарии, его автор не только нагадил в карму но и не поленился сделать тоже самое на гиктаймсе. Применяю пункт 1 и рассказываю об этом окружающим. Как считает автор статьи, правильно ли я поступаю в ситуации, когда манипулятор обладает влиянием, или это приведет к дальнейшему ухудшению ситуации?
Ну что вы, никто и не думал обижатся. Мы тут, по возможности конструктивно, просто обмениваемся личными мнениями, а они не обязаны совпадать )
В том то и дело, что для того, чтобы понять, что же происходит, надо по каждому методу тыкать ctrl+click и смотреть куда в итоге попадешь, а имплиситы могут быть и многоуровневыми (особенно во всяких Scalaz). В то время как обычный код можно просто читать. Из-за этого разница в скорости понимания происходящего будет в разы.