Букмекеры (а точнее компании, у которых букмекеры покупают коэфициенты) и так используют data science для расчёта вероятностей. Тем-более с их финансовыми возможностями у них есть доступ и к более полной исторической информации, и к более продвинутым специалистам в области DS.
Так что никуда они не денутся, наоборот — теперь с ними ещё сложнее соревноваться.
Да, это вполне очевидное предположение. Но больше всего напрягает именно это молчание. Спрашиваешь, «В чём у тебя проблемы в этой задаче? Что негативно повлияло на срок исполнения? Может, тебе нужна помощь?», а человек просто смотрит в пол и ничего не говорит.
Но даже если считать, что дело только в интересности задач — к сожалению, мало кто может игнорировать неинтересные задачи. И особенно это касается джуниоров. На мой взгляд, одной из важных черт профессионала как раз является способность справляться с неинтересными обязанностями почти так же хорошо, как и с интересными.
Пока что приходилось увольнять только троих джуниоров (из шести). Все трое были приятными, добрыми и отзывчивыми людьми, но при этом как работники были так себе. Причём это «так себе» было настолько сложно уловимо, что уверенность в необходимости увольнения у нас формировалась только после 1.5-2 лет работы сотрудника.
То есть, в какой-то момент ты начинаешь замечать, что человек работает в 2-3 раза медленнее остальных и уже хочешь его уволить, как вдруг он прекращает тупить и работает на хорошем уровне. И только ты расслабился, как всё начинается заново. При этом ни в одном из трёх случаев ни мне, ни другим коллегам не удалось найти какую-либо закономерность — что же так сильно влияет на умственные способности или мотивацию наших джуниоров? Никакие беседы на эту тему не помогали — люди просто молчали, хотя вообще были очень разговорчивыми.
Да, забавное совпадение — у всех троих было одно и то же имя. Никогда не считал себя суеверным, но скорее всего я вряд-ли когда-нибудь ещё возьму обладателя этого имени разработчиком.
До релиза 2.2. мы считаем весь код — публичным, т.е. на все классы распространяется политика обратной совместимости. Не только на классы, помеченные api. Разделение концепта на публичный и приватный начнется с 2.2 релиза.
Просто до этой фразы мне из статьи не было понятно, что это только начиная с 2.2. И что если модуль зависит от приватного кода, то ветки придётся держать не только по мажорным версиям, но и по патч версиям, которые меняют то, от чего модуль зависит. Но если это только с 2.2 и если там действительно можно будет обойтись без зависимостей от приватного кода, то отлично.
Двоякое впечатление от статьи. Звучит всё красиво, вот только разрабатывать модули под М2 стало намного проблематичнее. Буду рад, если ошибаюсь.
Практика показывает, что без зависимости от приватного кода сделать можно далеко не всё. Особенно это касается JS части. А значит прощай, обратная совместимость для многих модулей. В этом случае, я так понимаю, единственный выбор — либо держать несколько веток для модуля, либо забивать на старые версии Magento. Первый вариант, мягко говоря, не очень удобен, а второй нереален, если вспомнить, как разработчики в одном из обновлений поломали всю мультисайтовость и потом долго тянули с переносом bugfix из develop ветки. При этом, в М1 с версии 1.4 на моей памяти никогда не было такого, что функционал разительно менялся в рамках одной и той же мажорной версии. Бывало, что закрывали какой-то спорный функционал, но ты всегда мог выпустить новую версию модуля, которая бы работала и на старых версиях тоже. В М2 — не уверен.
Поэтому, допустим, мы всё таки будем держать несколько веток модуля и при каждом багфиксе обновлять их все. Как организовать удобную доставку модуля клиенту исходя из его версии Magento? Казалось бы, ответ очевиден — Magento Marketplace. Нам надо только расписать какие версии модуля подходят для каких версий М2 и Marketplace/composer сам решит, что отдать клиенту. Но в Marketplace ещё надо попасть. А это, как оказалось, в отличие от Magento Connect, совсем нетривиальная задача, решение которой от разработчика вообще мало зависит. Выложить модуль — не меньше месяца ожидания. Выложить обновление модуля — не меньше. Не хочешь использовать Marketplace, ставь себе Satis или какой-нибудь другой аналог packagist для приватных модулей — может, и не суперсложно, но это ещё одна вещь, в которой нужно разобраться.
В результате получается, что по сравнению с разработкой модулей для М1, разработка для М2, которая и так занимает значительно больше времени, обрастает ещё и дополнительными накладными временными расходами, которые далеко не каждый разработчик может себе позволить.
А у меня как раз после обновления включилось аппаратное ускорение (Tools->Options->Advanced->Use hardware acceleration when available) и пока я его не отключил, у меня вместо браузера было чёрное окно.
Мы сталкивались с этой проблемой пару лет назад. Направление вы выбрали правильное, но, как вы и сами отметили, у данной реализации куча минусов:
1) Метод formatPrice вызывается далеко не везде, лучше переписывать formatTxt в Mage_Directory_Model_Currency. Он находится глубже, да и меньше вероятность того, что будет конфликт с другим модулем.
2) Эта функция не используется в JS, отсюда проблема с конфигурационными товарами — при выборе подтовара всё равно вылезут копейки.
3) Проверка привязана к символу валюты «руб». Для евро или доллара, конечно, можно изменить проверку, но если на сайте несколько store view и у каждого своя валюта — способ надо дорабатывать.
Если вдруг кому-то нужно или просто интересно, можете попробовать наш модуль. Помимо этого функционала в нём ещё много всего для работы с валютами.
Чтобы не изобретать такие велосипеды, уже давно был написан OpenHoldem, который берёт на себя и распознавание карт, ставок и всего остального, и высчитывает вероятности, и может брать статистику по игрокам из PokerTracker. От вас требуется только написать логику принятия решений на встроенном языке, Perl или любом другом в виде DLL.
Спасибо, конечно, буду иметь в виду. Вам как разработчику системы виднее, но, на мой взгляд, пока что самый лучший выход для обеспечения совместимости с 1.3 это всё-таки default/default. Кстати, зачем её вообще оставили, если её функции теперь выполняет base/default?
В base/default кидать действительно не рекомендуется, потому что:
1) Это просто плохой стиль, так как эта папка предназначена для хранения основной темы, а не для изменений в ней.
2) До версии 1.4 такой папки просто не существовало, а некоторые магазины до сих пор сидят на 1.3.
Но по теме на каждый модуль это как-то слишком много тем получается. Обычно всё кладётся в default/default. Во всяком случае все модули, которые я видел, так делают.
1. Если вам предлагают купить выигрывающего бота — вас разводят в 99% случаев. Человеку просто незачем продавать такого бота.
2. Для написания покерных ботов в основном используются уже готовые платформы, где от вас требуется только запрограммировать алгоритм принятия решений. Остальное — получение информации из клиента путём распознавания картинки, нажимание на кнопки и т.д. платформа берёт на себя. Изобретать велосипед заново хоть и интересно, но ужасно неэффективно.
3. Пока что самый эффективный метод защиты бота от обнаружение система из 2 компьютеров (один может быть виртуальным), на одном из которых запущен клиент и сервер для удалённой администрации, а на втором запущен бот, который подсоединяется к первому и играет удалённо.
Не пугайте так человека :) Ведь даже с форматированием несложно разобраться. Именно по темизации документации достаточно, за день, максимум два можно понять систему шаблонов. А дальше уже обычная вёрстка. Серьёзные проблемы встретятся только, если нужно сделать что-то, что не предусматривается логикой Magento (например, сделать так, чтобы категория товаров первого уровня отображалась не так, как второго).
Спасибо, интересный линк. Практическое применение сомнительно, так как на данный момент CMS в Магенто, наверное, самая слабая составляющая. Но сам факт того, что это можно сделать безусловно интересен.
К сожалению, в силу особенностей компании, где я работаю, ТЗ на интернет-магазин нет, так как платформу выбирали именно непрограммисты — те, кто торгует. Мой работодатель — крупная по местным меркам сеть магазинов, которая только полтора года назад решила выйти с продажами и в интернет. От нашего отдела потребовали варианты быстрой реализации интернет-магазина (самим разрабатывать запрещалось, так как у отдела было много других не менее срочных задач). Мы предоставили на выбор порядка десяти платформ, в числе которых были Магенто и osCommerce. Выбирали только по функциональности, так вот в Магенто нашли много того, чего нет в других системах, поэтому его и выбрали. И наши торговцы действительно практически всей этой функциональностью пользуются.
Насчёт самостоятельной разработки на zf… Если вы сможете за неделю, или даже за месяц повторить весь арсенал функциональности Магенто, тогда вам определённо стоит подумать над выходом на рынок платформ для интернет магазинов. Мы бы точно не смогли.
Вы не поняли. Мне нравится работать с Магенто не из-за сложности, а наоборот — из-за отличной архитектуры, с которой работать как раз таки легко. Бывают, конечно, свои проблемы, но без них не обойдёшься ни в одной готовой системе. И в данный момент мне намного проще работать с Магенто, чем с другой системой.
К тому же, если я правильно понял, вы просто смотрите на Магенто с точки зрения программиста, а не продавца. В платформе для интернет-магазина главное — функциональность, а не архитектура, в которой некоторые не могут разобраться. И выбирают Магенто в основном не из-за пиара, а именно из-за огромной заложенной в неё функциональности.
В общем, ладно, я понимаю, что это не убедит человека, который в Магенто не разобрался. Считайте это моим субъективным мнением.
Полтора года работаю с Магенто вместе ещё с 3 программистами. Кстати, тот неофициальный перевод на форуме, делал начальник нашего отдела.
Когда выбирали платформу для крупного интернет-магазина, пересмотрели около десяти альтернатив. Выбирали в первую очередь по функционалу, поэтому и остановились на Магенто. В этом плане претензий практически нет, не считая низкой производительности (сначала было просто ужасно, после оптимизации стало терпимо).
С точки зрения программирования, конечно, там всё не так солнечно. Документации практически нет, только какие-то обрывки. Есть только одна нормальная книга, к которой разработчики всех недовольных и отсылают. В общем, разобраться во внутренностях довольно сложно. Но зато когда разберётесь, поймёте, насколько удобна и логична такая архитектура. Поэтому несмотря на то, что при создании очередного модуля иногда хочется выбросить компьютер в окно, никто из нас не жалеет, что мы выбрали именно Magento.
Так что никуда они не денутся, наоборот — теперь с ними ещё сложнее соревноваться.
Но даже если считать, что дело только в интересности задач — к сожалению, мало кто может игнорировать неинтересные задачи. И особенно это касается джуниоров. На мой взгляд, одной из важных черт профессионала как раз является способность справляться с неинтересными обязанностями почти так же хорошо, как и с интересными.
То есть, в какой-то момент ты начинаешь замечать, что человек работает в 2-3 раза медленнее остальных и уже хочешь его уволить, как вдруг он прекращает тупить и работает на хорошем уровне. И только ты расслабился, как всё начинается заново. При этом ни в одном из трёх случаев ни мне, ни другим коллегам не удалось найти какую-либо закономерность — что же так сильно влияет на умственные способности или мотивацию наших джуниоров? Никакие беседы на эту тему не помогали — люди просто молчали, хотя вообще были очень разговорчивыми.
Да, забавное совпадение — у всех троих было одно и то же имя. Никогда не считал себя суеверным, но скорее всего я вряд-ли когда-нибудь ещё возьму обладателя этого имени разработчиком.
Просто до этой фразы мне из статьи не было понятно, что это только начиная с 2.2. И что если модуль зависит от приватного кода, то ветки придётся держать не только по мажорным версиям, но и по патч версиям, которые меняют то, от чего модуль зависит. Но если это только с 2.2 и если там действительно можно будет обойтись без зависимостей от приватного кода, то отлично.
Практика показывает, что без зависимости от приватного кода сделать можно далеко не всё. Особенно это касается JS части. А значит прощай, обратная совместимость для многих модулей. В этом случае, я так понимаю, единственный выбор — либо держать несколько веток для модуля, либо забивать на старые версии Magento. Первый вариант, мягко говоря, не очень удобен, а второй нереален, если вспомнить, как разработчики в одном из обновлений поломали всю мультисайтовость и потом долго тянули с переносом bugfix из develop ветки. При этом, в М1 с версии 1.4 на моей памяти никогда не было такого, что функционал разительно менялся в рамках одной и той же мажорной версии. Бывало, что закрывали какой-то спорный функционал, но ты всегда мог выпустить новую версию модуля, которая бы работала и на старых версиях тоже. В М2 — не уверен.
Поэтому, допустим, мы всё таки будем держать несколько веток модуля и при каждом багфиксе обновлять их все. Как организовать удобную доставку модуля клиенту исходя из его версии Magento? Казалось бы, ответ очевиден — Magento Marketplace. Нам надо только расписать какие версии модуля подходят для каких версий М2 и Marketplace/composer сам решит, что отдать клиенту. Но в Marketplace ещё надо попасть. А это, как оказалось, в отличие от Magento Connect, совсем нетривиальная задача, решение которой от разработчика вообще мало зависит. Выложить модуль — не меньше месяца ожидания. Выложить обновление модуля — не меньше. Не хочешь использовать Marketplace, ставь себе Satis или какой-нибудь другой аналог packagist для приватных модулей — может, и не суперсложно, но это ещё одна вещь, в которой нужно разобраться.
В результате получается, что по сравнению с разработкой модулей для М1, разработка для М2, которая и так занимает значительно больше времени, обрастает ещё и дополнительными накладными временными расходами, которые далеко не каждый разработчик может себе позволить.
1) Метод formatPrice вызывается далеко не везде, лучше переписывать formatTxt в Mage_Directory_Model_Currency. Он находится глубже, да и меньше вероятность того, что будет конфликт с другим модулем.
2) Эта функция не используется в JS, отсюда проблема с конфигурационными товарами — при выборе подтовара всё равно вылезут копейки.
3) Проверка привязана к символу валюты «руб». Для евро или доллара, конечно, можно изменить проверку, но если на сайте несколько store view и у каждого своя валюта — способ надо дорабатывать.
Если вдруг кому-то нужно или просто интересно, можете попробовать наш модуль. Помимо этого функционала в нём ещё много всего для работы с валютами.
1) Это просто плохой стиль, так как эта папка предназначена для хранения основной темы, а не для изменений в ней.
2) До версии 1.4 такой папки просто не существовало, а некоторые магазины до сих пор сидят на 1.3.
Но по теме на каждый модуль это как-то слишком много тем получается. Обычно всё кладётся в default/default. Во всяком случае все модули, которые я видел, так делают.
2. Для написания покерных ботов в основном используются уже готовые платформы, где от вас требуется только запрограммировать алгоритм принятия решений. Остальное — получение информации из клиента путём распознавания картинки, нажимание на кнопки и т.д. платформа берёт на себя. Изобретать велосипед заново хоть и интересно, но ужасно неэффективно.
3. Пока что самый эффективный метод защиты бота от обнаружение система из 2 компьютеров (один может быть виртуальным), на одном из которых запущен клиент и сервер для удалённой администрации, а на втором запущен бот, который подсоединяется к первому и играет удалённо.
Насчёт самостоятельной разработки на zf… Если вы сможете за неделю, или даже за месяц повторить весь арсенал функциональности Магенто, тогда вам определённо стоит подумать над выходом на рынок платформ для интернет магазинов. Мы бы точно не смогли.
К тому же, если я правильно понял, вы просто смотрите на Магенто с точки зрения программиста, а не продавца. В платформе для интернет-магазина главное — функциональность, а не архитектура, в которой некоторые не могут разобраться. И выбирают Магенто в основном не из-за пиара, а именно из-за огромной заложенной в неё функциональности.
В общем, ладно, я понимаю, что это не убедит человека, который в Магенто не разобрался. Считайте это моим субъективным мнением.
Когда выбирали платформу для крупного интернет-магазина, пересмотрели около десяти альтернатив. Выбирали в первую очередь по функционалу, поэтому и остановились на Магенто. В этом плане претензий практически нет, не считая низкой производительности (сначала было просто ужасно, после оптимизации стало терпимо).
С точки зрения программирования, конечно, там всё не так солнечно. Документации практически нет, только какие-то обрывки. Есть только одна нормальная книга, к которой разработчики всех недовольных и отсылают. В общем, разобраться во внутренностях довольно сложно. Но зато когда разберётесь, поймёте, насколько удобна и логична такая архитектура. Поэтому несмотря на то, что при создании очередного модуля иногда хочется выбросить компьютер в окно, никто из нас не жалеет, что мы выбрали именно Magento.