Почему обслуживании? Создание с нуля. Асинхронная работа с большими объемами данных. Защита от взлома и мошенничества. Нагруженный реактивными компонентами фронтенд. Интеграция с различными сервисами. Сложные отчеты и статистика на Бэк-офисе.
И 20-70 активно играющих - это не одна тысяча зарегистрированных
Зачем-то вы вырвали фразу из контекста. Далее в тексте раскрывается тема.
Да, наверняка много спортсбуков, которые создаются только для агрессивного маркетинга и кидания пользователей. Я в таких не работал. Я работал в таких, которые стараются вывести бизнес на IPO, или хотя бы продать тому, кто будет стараться вывести его на IPO.
Никакие спортсбуки не любят вилочников, бонусхантеров, мультиаккаунщиков и прочих не обычных игроков. Поэтому в правилах этих спортсбуков прописан запрет на такую деятельность. Поэтому если ты этим занимаешься, будь готов быть пойманным и выгнанным. Самое худшее что в моем случае происходило - возврат всех депозитов за вычетом сделанных выводов. Когда я работал по другую сторону огня, делал кастомный софт для арбитражников, то они всегда были готовы к блокировке аккаунта и относились к этому спокойно. Потому что на чужой территории они нарушают чужие правила. Вилочника видно издалека невооруженным взглядом.
Единственные невыплаты у нас были только по таким случаям, явно нарушающим правила. Помню игрока, который ставил по 1-2 тысячи и постоянно выигрывал. У него были последовательности по 10 выигрышей подряд. Было понятно, что он не читер, и по нему вопросы по выплатам не возникало. Поэтому не надо в кучу мешать более-менее порядочный бизнес и явное мошенничество.
Странный вопрос А зачем какому-то программисту идти в Сбер/Яндекс/Wildberries?
Там получишь какой-то особенный опыт?
Да, очень много именно технического опыта и навыков получено именно при решении задач в этой области. Те же навыки могли быть получены в любой иной сфере
Можно по вашей критике провести аналогию с музыкой Java - это классическая музыка. Kotlin - рок. Golang - Моргерштерн.
Популярен у молодёжи последний, но он пришел и уйдет, а консерватории будут всегда, и музыку для фильмов в большинстве своем будут писать те, кто окончили консерваторию. И даже хороший рок будут писать те, кто окончили консерваторию. Как подработку.
В профиле на ЛинкдИне у меня указано три языка из первой пятерки рейтинга, так звонят только по Java. Причем проекты не старые
Для b2c, b2b или pet проектов использую JavaScript для фронта (Vue.js, SPA), и PHP (API) на бэке для быстрого MVP-рования. После выхода на какую-то нагрузку определяю критичные места и переписываю на Java. Преимущественно, ванильной. А можно оставить на PHP.
Написанное на Java работает бесперебойно месяцами, и туда можно не заглядывать.
На этапе альфа и бетта девелопмента docs-as-code очень удобна. При меняющемся коде отдельная документация быстро устаревает, у разработчиков пропадает мотивация ее поддерживать (отнимает много времени и усилий)
Javadoc (странно, что он ни разу не упомянут) является в данном случае для меня идеалом данного подхода, и за 25 лет использования доказал свою практичность.
Однако проблема в средствах генерации для других систем.
Взять популярные фреймворки - Vue.js например. Есть отдельные индивидуальные попытки создать jsdoc и прочее, но хорошего качественного средства так почему-то никто и не сделал. А жаль. Это очень нужная штука даже для команды из одного-двух программеров, не говоря уж больших группах разработчиков.
Когда текста для перевода много, удобно делать локали не файлами json, а подпапками с файлами json
Подпапка 'ru' В ней файлы account.json, footer.json и так далее В каждом соответствующие переводы, иерархично Обращение: $t("account.profile.usernameTitle")
можно в этих файлах задействовать массивы и выводить их циклом в тэгах li или p по надобности
Много текста, но так и не понял, чем подход кастомных иконок лучше <q-icon name="mdiDogSide" /> (в моем случае, самописный <base-icon> с font-size, color и другими няшками вроде умения работать со спрайтами)
Зачем плодить лишние сущности компоненты?
Придет новый программер Увидит компонент Начнет искать его и увидит сложную генерацию Тихо заматерится, на "прозрачный и красивый код"
Бенчмарки есть. Разные. Большинство, конечно, аффилированных, так что лучше самому повыбирать, если интересно
Slim, по сути, просто роутинг, а может понадобиться еще MVC, приблуды для Rest , а model CI4 данных вообще очень приятная и красивая штука для работы с БД.
По закону 20/80 CI4 дает 80% нужного функционала за 20% "сложности" проекта
Ну, начать с того, что у тысяч пользователей запросили большие деньги за продление зарегистрированных ими «бесплатных» доменов
У кого-то (включая меня) просто пропал доступ в контрольную панель
И жаловаться некуда
Бесплатный сыр
Почему обслуживании? Создание с нуля. Асинхронная работа с большими объемами данных. Защита от взлома и мошенничества. Нагруженный реактивными компонентами фронтенд. Интеграция с различными сервисами. Сложные отчеты и статистика на Бэк-офисе.
И 20-70 активно играющих - это не одна тысяча зарегистрированных
Зачем-то вы вырвали фразу из контекста. Далее в тексте раскрывается тема.
Да, наверняка много спортсбуков, которые создаются только для агрессивного маркетинга и кидания пользователей. Я в таких не работал. Я работал в таких, которые стараются вывести бизнес на IPO, или хотя бы продать тому, кто будет стараться вывести его на IPO.
Никакие спортсбуки не любят вилочников, бонусхантеров, мультиаккаунщиков и прочих не обычных игроков. Поэтому в правилах этих спортсбуков прописан запрет на такую деятельность. Поэтому если ты этим занимаешься, будь готов быть пойманным и выгнанным. Самое худшее что в моем случае происходило - возврат всех депозитов за вычетом сделанных выводов. Когда я работал по другую сторону огня, делал кастомный софт для арбитражников, то они всегда были готовы к блокировке аккаунта и относились к этому спокойно. Потому что на чужой территории они нарушают чужие правила. Вилочника видно издалека невооруженным взглядом.
Единственные невыплаты у нас были только по таким случаям, явно нарушающим правила. Помню игрока, который ставил по 1-2 тысячи и постоянно выигрывал. У него были последовательности по 10 выигрышей подряд. Было понятно, что он не читер, и по нему вопросы по выплатам не возникало. Поэтому не надо в кучу мешать более-менее порядочный бизнес и явное мошенничество.
Странный вопрос
А зачем какому-то программисту идти в Сбер/Яндекс/Wildberries?
Там получишь какой-то особенный опыт?
Да, очень много именно технического опыта и навыков получено именно при решении задач в этой области. Те же навыки могли быть получены в любой иной сфере
Познавательно, спасибо, но статья не ориентирована только на граждан РФ
Можно по вашей критике провести аналогию с музыкой
Java - это классическая музыка. Kotlin - рок. Golang - Моргерштерн.
Популярен у молодёжи последний, но он пришел и уйдет, а консерватории будут всегда, и музыку для фильмов в большинстве своем будут писать те, кто окончили консерваторию. И даже хороший рок будут писать те, кто окончили консерваторию. Как подработку.
Попробовал - приятный, но тормозит безбожно
В профиле на ЛинкдИне у меня указано три языка из первой пятерки рейтинга, так звонят только по Java. Причем проекты не старые
Для b2c, b2b или pet проектов использую JavaScript для фронта (Vue.js, SPA), и PHP (API) на бэке для быстрого MVP-рования. После выхода на какую-то нагрузку определяю критичные места и переписываю на Java. Преимущественно, ванильной. А можно оставить на PHP.
Написанное на Java работает бесперебойно месяцами, и туда можно не заглядывать.
На этапе альфа и бетта девелопмента docs-as-code очень удобна. При меняющемся коде отдельная документация быстро устаревает, у разработчиков пропадает мотивация ее поддерживать (отнимает много времени и усилий)
Javadoc (странно, что он ни разу не упомянут) является в данном случае для меня идеалом данного подхода, и за 25 лет использования доказал свою практичность.
Однако проблема в средствах генерации для других систем.
Взять популярные фреймворки - Vue.js например. Есть отдельные индивидуальные попытки создать jsdoc и прочее, но хорошего качественного средства так почему-то никто и не сделал. А жаль. Это очень нужная штука даже для команды из одного-двух программеров, не говоря уж больших группах разработчиков.
Это два подхода, но намного более важные, чем кажется
Первый отражает концепции абстракции и инкапсуляции ООП
base-icon
- это класс. С определенными свойствами и методами. Иконка - свойство.Вы же вместо создания объектов одного класса создаете множество классов
Классы, абстрагирование, инкапсуляция нужны на уровне программиста, а не компилятора или сборщика. Именно чтобы код был "прозрачный и красивый"
И Vue.js возможно более других фронтэнд фреймворков старается придерживаться ООП парадигмы
У вас в шаблоне новый тэг
Это и есть новый web component
Пришедший программер начнет его искать и не найдет
Свой
base-icon
- 30 строчек ясного кода и переиспользуемый! для производительности при надобности Vue компонентВаш подход - необоснованное закулисывание очевидной логики, усложнение билда, усложнение читаемости кода
Когда текста для перевода много, удобно делать локали не файлами json, а подпапками с файлами json
Подпапка 'ru'
В ней файлы account.json, footer.json и так далее
В каждом соответствующие переводы, иерархично
Обращение:
$t("account.profile.usernameTitle")
можно в этих файлах задействовать массивы и выводить их циклом в тэгах li или p по надобности
Много текста, но так и не понял, чем подход кастомных иконок лучше <q-icon name="mdiDogSide" /> (в моем случае, самописный <base-icon> с font-size, color и другими няшками вроде умения работать со спрайтами)
Зачем плодить лишние
сущностикомпоненты?Придет новый программер
Увидит компонент
Начнет искать его и увидит сложную генерацию
Тихо заматерится, на "прозрачный и красивый код"
И для большого проекта глобальные переменные уже плохо идут. Удобней иметь конфиг в json формате -
app.config.json
И доступ -
Vue.$appConfig.oauth.google.clientId
Удобно также иметь app.config.local.json с переопределенными локальными переменными
vue.config.js:
main.js:
Что и в каком формате лежит в директории docs?
Или для переводной статьи это спрашивать нет смысла?
Вроде бы говорили о простых PHP фреймворках
Не понимаю, как перескочили на Yii
Бенчмарки есть. Разные. Большинство, конечно, аффилированных, так что лучше самому повыбирать, если интересно
Slim, по сути, просто роутинг, а может понадобиться еще MVC, приблуды для Rest , а model CI4 данных вообще очень приятная и красивая штука для работы с БД.
По закону 20/80 CI4 дает 80% нужного функционала за 20% "сложности" проекта
Restful API со сложной бизнес логикой и трехэтажными запросами к БД отлично идёт на CI4
С учетом того, что SPA нынче вполне себе стандарт в web приложениях, CI4 прекрасно подходит для полноценного бэкэнда
Ну а его простота даёт ему скорость по сравнению с другими PHP фреймворками
Я выиграл
Они подали апелляцию, но пропустили срок
У кого-то (включая меня) просто пропал доступ в контрольную панель
И жаловаться некуда
Бесплатный сыр