Я ничего не хочу сказать плохого про Go, но статья выглядит как «Мы не способны ввести единый стандарт кодирования в нашей команде, зато способны заставить всех разработчиков учить новый язык и теперь у нас три стандарта кодирования (два от scala и один от GO)». Если есть проблема с механизмом сборки SBT почему не взять другую систему сборки? Если проблемы в том что команда пишет в двух разных стилях, почему не разделить команду на разные проекты или железно заставить писать в одном стиле? Как code review пропустил код, написанный так, что его никто в команде больше не понимает?
В целом, решение чисто административных проблем, описанных в статье, переходом на новый язык выглядит как попытка переименовать милицию в полицию, в расчете что это победит коррупцию.
что этот скрипт писать просто бессмысленно, так как по вышеперечисленной мной причине эта капча после гугловской на куках является практически непробивной
Эээ, почему вы так считаете? Задача определения пола относительно простая для машинного обучения (по сравнению с поиском произвольного объекта). В конце концов, есть же сервис how-old.net, достаточно скармливать ему нужные фотки и получать пол с большой вероятностью (конечно, у how-old.net скорее всего есть какая-то защита от ботов, но её всегда можно обойти, например банально запуская скрипт из браузера и польностью имитируя действия пользователя).
На самом деле, вопрос даже не в том что изменение объекта в проверке спорная практика, а том что разработчики на Java не привыкли к трюкам вида «if(set.add(item))» или «put(...put( ))», поэтому если писать код, который будешь читать только ты — такое допустимо, а вот если ещё куча народа, то я лучше «if(!set.contains(item))… » напишу, чтобы не обяснять всем и каждому на код ревью, что я хотел тут сделать.
В течении примерно месяца этот рейтинг обнуляется. То есть это как лучшие авторы за месяц. Лучше смотреть по вкладу автора в хаб, если хочется понять место автора в Хабре.
Одно дело — брать то, что изначально выложено в открытой доступ.
Более того, иногда парсинг сайтов вполне полезен для сайта-источника, например сервисы по определению поисковых характеристик, ошибок верстки или способы интеграции сайта магазина с сайтом оптовика.
тут дан ответ.
1,3) Даже по вашему примера, видно что человек не напишет «не требует подключенния электричества» для раковины и т.п. ерунды, хотите помочь клиенту, дайте ширину, длину, вес, цвета, кол-во на складе, цену и условия доставки. Это уже сделает объявление уникальным для поисковика. А автогенерация трех строчек никакой пользы не принесет.
2) ответил выше,
В целом, проблема даже не в том что автогенерация все равно мешает пользователям, чтобы вы не говорили, а в том что автогенерация, в том виде как приведено у вас, мало полезна, Есть способы заработка на автогенерации, но это не шаблонные описания в интернет магазине. ИМХО.
1) расценки на 1000 знаков в среднем несколько раз ниже,
2) в приведенном вами примере не 1 тысяча знаков,
3) у каждого начинающего магазина 10000 товарных наименований?
4) (и самое главное) на самом деле, в уникальном описании товара на 1 тыс. знаков на 10 тыс. наименований смысла мало, так как поисковики прекрасно знают что описания товаров не уникальны и не обращают на это внимания (посмотрите описания сотовых телефонов с их характеристиками они почти везде одинаковые), да описание товара из трех строчек (как у вас выше) все равно будет уникальным, так как на сайте будут ещё цены, условия доставки, наличие на складе, цвета в наличии. Этого более чем достаточно для того чтобы такое описание поисковик посчитал уникальным. Соответственно, делать уникальные тексты имеет только для избранного товара в виде достаточно большой статьи (например, в виде обзора нового телефона). При этом уникальный текст это лишь 1% от того что нужно сделать для продвижения этого товара и, естественно, тут нет никакого смысла экономить.
Лучше прочитать хороший копипаст (взятый с сайта производителя, например), чем такое.
Вообще, нормальные магазины платят копипастерам и рерайтерам на ручную генерацию уникального текста (пересказ чужого текста, перевод или реальное придумывание) одновременно оптимизированного для пользователей и для поисковиков. Это со одной стороны дает уникальные тексты, с другой хорошую конверсию и имидж. Причем не сказать что на это требуются какие-то нереальные деньги… А автогенерация… выглядит ещё хуже чем кривой страшный дизайн за три копейки на вроде бы супер пупер интернет магазине.
интересы пользователей и владельцев сайта в данном случае совпадают
Нет, если я набираю «товар такой-то отзывы», «товар такой-то характеристики», то я не хочу читать автогенерируемые описания для роботов. Вообще, если магазин не может заплатить три копейки за заказ у копирайтера нормального человеческого описания товаров о каком доверии может идти речь?
Нагенерить кучу описаний не сложно, но этим не выйти в топ поисковика. Потратить кучу денег на рекламу и продвижение и иметь конверсию ниже плинтуса и риск блокировки поисковиками магазина по ручным жалобам пользователей? За такую жадность можно даже не втрое заплатить, а значительно больше…
Боюсь даже представить как будет какой-нибудь WebStorm работать на планшете с Windows, когда вполне современный ноут с 4 Гб памяти у меня умирал при одном запуске.
Если в крупном городе можно выбирать из, условно говоря, 100 резюме по теме, то в маленьком есть Вася и Петя, вот и и весь выбор.
Да, что ещё хуже Вася и Петя отлично знают 1С и Delphi, а фирме нужны опытные разработчики на Go и Питоне, а их нет потому что в регионе не было фирм, которым это нужно. Тут либо тратить огромные деньги на переобучение, либо не ходить на такой рынок.
. Может уезжают не лучшие, а подвижные? По-моему это очень зашоренный, штампованный взгляд, что в Москву уезжают лучшие специалисты.
На самом деле, это не важно. Рынку на самом деле важны и нужны не лучшие специалисты, а разные. Лучшие специалисты это люди вроде Линуса Т́орвальдса, их все равно мало кто себе может позволить (да и сами они работают на себя), рынку важно чтобы в каждой ценовой категории специалисты были.
Ну, вот пример в Самаре, где я долго работал, на рынке труда можно найти Java, C#, C++, найти специалиста по каком-нибудь Haskel'у будет проблематично, да и за Java разработчиков конкуренция идет высокая, чтобы открыть новый филиал и быстро привлечь к себе много Java разработчиков надо платить раза в полтора больше, но тут при это зар.платы становятся уже сопоставимыми со средними по Москве. Сэкономить на офисе по сравнению с Москвой можно, но в филиал нужно нанимать местного HR, админа, офис.менеджера, что то на то и выйдет. Плюс командировки в филиал тех кто будет контролировать и обучать. Ну и чем больше ИТ компаний будет переезжать в регион, тем выше будет конкуренция на рынке труда, пока зар.платы и издержки не станут сопоставимыми с Московскими или даже их превысят.
В целом, нет тут никакой Матрицы, вполне обычный бизнес, те ИТ компании, которым это было выгодно, давно уже открыли офисы в регионах (более того одна из компаний, в которой я работал, открыла офис в Индии), остальным это просто не особо выгодно. Просто бизнес, как бы вам не хотелось чтобы ИТ компании рванули в регионы.
Зависят, компания из США предпочтет заплатить чуть больше, но ребятам из соседнего офиса чем непонятной компании из Нигерии, по многим причинам (от стабильности и надежности, до простоты общения и возможности личной встречи в любой момент).
Это строителям, чтобы строить дом нужно непосредственно находиться на месте стройки
А руководителям, бизнес аналитикам и продажникам нужно непосредственно встречаться с клиентами. Тут либо тратить большие деньги на постоянные командировки, либо держать офисы рядом с клиентом и получать проблемы с взаимодействием удаленных команд. Это далеко не всегда окупается.
заказчик может быть хоть на другой стороне земного шара
В теории да, на практике разные временные зоны создают проблемы при коммуникации и поддержки, программисты не любят не спать ночами, а заказчики не любят оставаться без саппорта в середине рабочего дня.
Почему ИТ-компании этого не делают?
Делают, проблема в том что чем дальше от столицы тем меньше рынок разработчиков и далеко не каждый разработчик согласится уехать в деревню Большие Васюки даже если там предлагают неплохую зар.плату. Самые хорошие специалисты уезжают где рынок больше и зар.платы выше. Опять-таки, для Западных компаний переводить офисы в нестабильные страны может выйти боком. Увы, удаленная работа и фриланс тоже содержат в себе много подводных камней для заказчика, распределенные команды почти всегда взаимодействуют и учаться хуже, чем те кто сидит в одном офисе.
В целом, ИТ компании пытаются переносить производство, но зачастую слишком жадному приходится платить трижды, так что не все так просто.
Почему нужно? Берем и пишем строку «pakage mypackage; public class Class1234 { public void execute(» + object.getClass() + " p) {" + object.getClass() + ".execute() };" закидываем её в класс loader одной из библиотек по генерации байт кода, генерим класс и вызываем class1234.execute(object); Для одиночного класса — дорого, но если каждый раз приходят тысячи и десятки тысяч классов каждого типа, то создав мапу <тип, сгенеренный класс> можно их выполнять намного быстрее рефлексии.
В случае third-party бинарников или даже поделки коллег из соседнего отдела нужно или очень настойчиво попросить об этом автора или ildasm.
Создаем пустые классы-наследники от классов third-party бинарников, которые реализуеют нужные нам интерфейсы и уже подобные wrapper классы, которые все реализуют один нужный нам интерфейс с методом execute.
То есть
public class ThridPartyClass { // чужой класс
public void execute() {
// что делает
}
}
public interface IExecuted {
void execute();
}
public class ThridPartyClassWrapper extends ThridPartyClass implements IExecuted {
}
ThridPartyClassWrapper вполне уже реализует IExecuted интерфейс и может использоваться для приведения типов.
потому что
1) язык со статической типизацией != компилируемый,
2) из списка C,C++,C#,Java — лишь половина компилируемые языки, ни С#, ни Java — не являются компилируемыми языками, это одновременно и интерпретируемые и компилируемые языки, а которых возможна и кодогенерация на лету и evel и работа в интерпретируемым режиме,
3) никакой проблемы в получении нормальный дамп нет ни в C#, ни в Java достаточно определить toString любым из ручных и автоматических способов, насчет С++ — не скажу,
4) полный аналог js «console.log(JSON.stringify(object))» на java записывается как «log.debug(gson.toJson(object))», на C# скорее всего не сложнее,
Вывод: утверждение «в таких языках посмотреть, что представляет из себя переменная, можно только в отладчике» совершенно неверно.
сложность получить все поля с их типами и значениями для некоторой сложной структуры.
Любая Java IDE позволяет автоматически сгенерить toString() для любого класса за секунду. Есть способы автоматически генерить toString для всех классов проекта. Все коллекции и важные библиотечные классы уже имеют переопределенный toString. В целом, это не проблема от слова совсем.
вызвать метод Execute() у совершенно произвольного объекта
Может привести хоть какой-то практический пример когда нужно вызвать метод у совершенно произвольного объекта? Так чтобы это не нарушало все принципы ООП и было хоть мало мальским оправданным с точки зрения качества кода?
Если мы говорим о своих объектах, то никто не мешает нам добавить им явный интерфейс, если мы используем чужие объекты с одинаковым методом, то фабрика, wrapper или proxy легко позволят привести их к одному виду. Ну и создавать публичный API, который принимает любой объект у которого есть метод Execute, тоже выглядит бредово. Честно говоря, не могу представить ни одного случая когда возможность «вызвать метод Execute() у совершенно произвольного объекта» было бы обоснованно, чем-то большим чем «так мы сможем наговнокодить на 5 минут быстрее».
Единственный способ вызвать метод Execute() у совершенно произвольного объекта — использовать рефлексию.
Нет, в Java можно ещё использовать кодегенерацию на лету, для отдельного объекта это дольше, но для огромного потока разных объектов — быстрее.
В целом, решение чисто административных проблем, описанных в статье, переходом на новый язык выглядит как попытка переименовать милицию в полицию, в расчете что это победит коррупцию.
Эээ, почему вы так считаете? Задача определения пола относительно простая для машинного обучения (по сравнению с поиском произвольного объекта). В конце концов, есть же сервис how-old.net, достаточно скармливать ему нужные фотки и получать пол с большой вероятностью (конечно, у how-old.net скорее всего есть какая-то защита от ботов, но её всегда можно обойти, например банально запуская скрипт из браузера и польностью имитируя действия пользователя).
Более того, иногда парсинг сайтов вполне полезен для сайта-источника, например сервисы по определению поисковых характеристик, ошибок верстки или способы интеграции сайта магазина с сайтом оптовика.
1,3) Даже по вашему примера, видно что человек не напишет «не требует подключенния электричества» для раковины и т.п. ерунды, хотите помочь клиенту, дайте ширину, длину, вес, цвета, кол-во на складе, цену и условия доставки. Это уже сделает объявление уникальным для поисковика. А автогенерация трех строчек никакой пользы не принесет.
2) ответил выше,
В целом, проблема даже не в том что автогенерация все равно мешает пользователям, чтобы вы не говорили, а в том что автогенерация, в том виде как приведено у вас, мало полезна, Есть способы заработка на автогенерации, но это не шаблонные описания в интернет магазине. ИМХО.
2) в приведенном вами примере не 1 тысяча знаков,
3) у каждого начинающего магазина 10000 товарных наименований?
4) (и самое главное) на самом деле, в уникальном описании товара на 1 тыс. знаков на 10 тыс. наименований смысла мало, так как поисковики прекрасно знают что описания товаров не уникальны и не обращают на это внимания (посмотрите описания сотовых телефонов с их характеристиками они почти везде одинаковые), да описание товара из трех строчек (как у вас выше) все равно будет уникальным, так как на сайте будут ещё цены, условия доставки, наличие на складе, цвета в наличии. Этого более чем достаточно для того чтобы такое описание поисковик посчитал уникальным. Соответственно, делать уникальные тексты имеет только для избранного товара в виде достаточно большой статьи (например, в виде обзора нового телефона). При этом уникальный текст это лишь 1% от того что нужно сделать для продвижения этого товара и, естественно, тут нет никакого смысла экономить.
Однако ни на одном графике она даже 1% не получила. Интересно какой же процент остался у «аськи» теперь?
Вообще, нормальные магазины платят копипастерам и рерайтерам на ручную генерацию уникального текста (пересказ чужого текста, перевод или реальное придумывание) одновременно оптимизированного для пользователей и для поисковиков. Это со одной стороны дает уникальные тексты, с другой хорошую конверсию и имидж. Причем не сказать что на это требуются какие-то нереальные деньги… А автогенерация… выглядит ещё хуже чем кривой страшный дизайн за три копейки на вроде бы супер пупер интернет магазине.
Нет, если я набираю «товар такой-то отзывы», «товар такой-то характеристики», то я не хочу читать автогенерируемые описания для роботов. Вообще, если магазин не может заплатить три копейки за заказ у копирайтера нормального человеческого описания товаров о каком доверии может идти речь?
Нагенерить кучу описаний не сложно, но этим не выйти в топ поисковика. Потратить кучу денег на рекламу и продвижение и иметь конверсию ниже плинтуса и риск блокировки поисковиками магазина по ручным жалобам пользователей? За такую жадность можно даже не втрое заплатить, а значительно больше…
Да, что ещё хуже Вася и Петя отлично знают 1С и Delphi, а фирме нужны опытные разработчики на Go и Питоне, а их нет потому что в регионе не было фирм, которым это нужно. Тут либо тратить огромные деньги на переобучение, либо не ходить на такой рынок.
На самом деле, это не важно. Рынку на самом деле важны и нужны не лучшие специалисты, а разные. Лучшие специалисты это люди вроде Линуса Т́орвальдса, их все равно мало кто себе может позволить (да и сами они работают на себя), рынку важно чтобы в каждой ценовой категории специалисты были.
Ну, вот пример в Самаре, где я долго работал, на рынке труда можно найти Java, C#, C++, найти специалиста по каком-нибудь Haskel'у будет проблематично, да и за Java разработчиков конкуренция идет высокая, чтобы открыть новый филиал и быстро привлечь к себе много Java разработчиков надо платить раза в полтора больше, но тут при это зар.платы становятся уже сопоставимыми со средними по Москве. Сэкономить на офисе по сравнению с Москвой можно, но в филиал нужно нанимать местного HR, админа, офис.менеджера, что то на то и выйдет. Плюс командировки в филиал тех кто будет контролировать и обучать. Ну и чем больше ИТ компаний будет переезжать в регион, тем выше будет конкуренция на рынке труда, пока зар.платы и издержки не станут сопоставимыми с Московскими или даже их превысят.
В целом, нет тут никакой Матрицы, вполне обычный бизнес, те ИТ компании, которым это было выгодно, давно уже открыли офисы в регионах (более того одна из компаний, в которой я работал, открыла офис в Индии), остальным это просто не особо выгодно. Просто бизнес, как бы вам не хотелось чтобы ИТ компании рванули в регионы.
Зависят, компания из США предпочтет заплатить чуть больше, но ребятам из соседнего офиса чем непонятной компании из Нигерии, по многим причинам (от стабильности и надежности, до простоты общения и возможности личной встречи в любой момент).
А руководителям, бизнес аналитикам и продажникам нужно непосредственно встречаться с клиентами. Тут либо тратить большие деньги на постоянные командировки, либо держать офисы рядом с клиентом и получать проблемы с взаимодействием удаленных команд. Это далеко не всегда окупается.
В теории да, на практике разные временные зоны создают проблемы при коммуникации и поддержки, программисты не любят не спать ночами, а заказчики не любят оставаться без саппорта в середине рабочего дня.
Делают, проблема в том что чем дальше от столицы тем меньше рынок разработчиков и далеко не каждый разработчик согласится уехать в деревню Большие Васюки даже если там предлагают неплохую зар.плату. Самые хорошие специалисты уезжают где рынок больше и зар.платы выше. Опять-таки, для Западных компаний переводить офисы в нестабильные страны может выйти боком. Увы, удаленная работа и фриланс тоже содержат в себе много подводных камней для заказчика, распределенные команды почти всегда взаимодействуют и учаться хуже, чем те кто сидит в одном офисе.
В целом, ИТ компании пытаются переносить производство, но зачастую слишком жадному приходится платить трижды, так что не все так просто.
Создаем пустые классы-наследники от классов third-party бинарников, которые реализуеют нужные нам интерфейсы и уже подобные wrapper классы, которые все реализуют один нужный нам интерфейс с методом execute.
То есть
ThridPartyClassWrapper вполне уже реализует IExecuted интерфейс и может использоваться для приведения типов.
1) язык со статической типизацией != компилируемый,
2) из списка C,C++,C#,Java — лишь половина компилируемые языки, ни С#, ни Java — не являются компилируемыми языками, это одновременно и интерпретируемые и компилируемые языки, а которых возможна и кодогенерация на лету и evel и работа в интерпретируемым режиме,
3) никакой проблемы в получении нормальный дамп нет ни в C#, ни в Java достаточно определить toString любым из ручных и автоматических способов, насчет С++ — не скажу,
4) полный аналог js «console.log(JSON.stringify(object))» на java записывается как «log.debug(gson.toJson(object))», на C# скорее всего не сложнее,
Вывод: утверждение «в таких языках посмотреть, что представляет из себя переменная, можно только в отладчике» совершенно неверно.
В C++ нет, но вы не только про C++ говорили.
Эээ, что за морока, почему я никогда с ней не встречался за 10 лет в Java? И что значит промахнулся со строчкой?
Я и имел в виду hot deploy со специально предназначенными для этого инструментами…
Любая Java IDE позволяет автоматически сгенерить toString() для любого класса за секунду. Есть способы автоматически генерить toString для всех классов проекта. Все коллекции и важные библиотечные классы уже имеют переопределенный toString. В целом, это не проблема от слова совсем.
Может привести хоть какой-то практический пример когда нужно вызвать метод у совершенно произвольного объекта? Так чтобы это не нарушало все принципы ООП и было хоть мало мальским оправданным с точки зрения качества кода?
Если мы говорим о своих объектах, то никто не мешает нам добавить им явный интерфейс, если мы используем чужие объекты с одинаковым методом, то фабрика, wrapper или proxy легко позволят привести их к одному виду. Ну и создавать публичный API, который принимает любой объект у которого есть метод Execute, тоже выглядит бредово. Честно говоря, не могу представить ни одного случая когда возможность «вызвать метод Execute() у совершенно произвольного объекта» было бы обоснованно, чем-то большим чем «так мы сможем наговнокодить на 5 минут быстрее».
Нет, в Java можно ещё использовать кодегенерацию на лету, для отдельного объекта это дольше, но для огромного потока разных объектов — быстрее.