Зависимости «живут», пока «живёт» сервис, ничего удалять и повторно создавать не нужно
Как минимум, на одном соединении к СУБД вы долго не протянете и надо будет их создавать и удалять. Причём бездумно не получится, потому что есть такая штука как транзакции, запросы которых должны быть в рамках одного соединения. И вот у вас уже есть поддерево зависимостей, которое должно создаваться и удаляться динамически. И таких кейсов может быть много. Посмотрите на реализации DI/IoC в Java/C#, там приложения тоже запускаются один раз и всё, но разработчикам дают выбор скоупа зависимостей
В бигтехе задача от продактов идёт бизнес-аналитикам, архитекторам, системным аналитикам, проджектам и только потом уже к вам. А вас никто не будет спрашивать, надо ли им это, раз задача у вас, значит надо, а решение уже в задаче от архитекора или системного аналитика, вам и предлагать нечего, вам надо ТОЛЬКО сделать. Тестированием будут заниматься QA-инженеры, развёрткой - ваш тимлид или девопс, инфрой - админы и девопсы. Такова ужасная жизнь корпоратов, где у каждого своя роль, и как у программиста у вас роль именно программировать, а не всё прочее. Если хотите более широких полномочий, то работайте в компаниях меньше - чем меньше компания, тем шире ответственность.
Очередная библиотека для реактивного программирования, а чем она лучше того же RxJS? Быстрее? Понятнее? Или всё вместе?
Я в общем-то не любитель реактивного программирования, но с простотой чтения кода соглашусь, а вот написание кода очень сомнительно, по сути каждая такая библиотека - это отдельный язык внутри языка и буквально приходится сидеть с документацией, выискивая - а какая же функция мне тут нужна. Обычные синтаксические конструкции того же JavaScript просто так не возьмёшь, потому что другая парадигма, и иногда их использовать не получится в принципе
Попробуйте теперь взять получившийся код и деобфусцировать его
getData(n) - заменяем изменяем на результат этой функции, а имена переменных и функций можно вручную переименовывать в зависимости от контекста, так как это не особо отличается от обычной минификации, от любого бандлера
Приходилось по кое-какой нужде так делать, ничего сложного, пара часов и готово. А если код изначально использует много объектов, классов и тд, то там восстанавливать вообще нечего, так как обфускатору все аксессоры (филды, методы, геттеры, сеттеры и тд) нужно или оставлять в том же виде, чтобы не поломать ничего, или через тот же механизм getData, который довольно просто вернуть в исходное состояние.
Хороший обфускатор должен что-то заинлайнить, всё переименовать, простые операции заменить на много непонятных так, чтобы результаты были теми же и тд, а потом ещё это и хорошенечко зашифровать в eval, вызов которого тоже обфусцировать.
Так как мы говорим про JavaScript, то действительно хорошая обфускация просто убьёт производительность и размер вашего приложения, при том, что кто надо, тот всё равно вернёт код в приемлемое состояние. Как неплохой вариант действительно важный код переписать под WebAssembly, так восстанавливать код из ассемблера не самое приятное занятие, хоть и возможное + есть вероятность, что работать побыстрее будет. Пора уже смирится - всё, что вы отдаёте пользователям, становится общедоступным. Свои крутые алгоритмы переносите на сервер и не надо будет думать, как бы вам код обфусцировать, чтоб конкуренты не спёрли.
Тут скорее борьба автоматического и ручного маппинга. Для себя я решил так - если объекты небольшие или маппинг нужен в 1-2 других классов, то можно и руками, а если начинается чехорда, когда объекты крупные и их надо в кучу других классов маппить, то использую автомаппер, желательно, который использует кодогенерацию, чтобы не было ошибок в рантайме
По поводу первого пункта не совсем согласен. Если ты уровня стажор/джун, то можно и за 20к поработать, главное, во время уйти (через 3-6 месяцев) и потом спокойно просить x3-x4, а то и гораздо больше, а не сидеть и ждать, пока тебя заметят и магическим образом повысят зп.
А если уж очень хочется денег и ментально готов впахивать за четверых, то можно соврать об опыте и просить ещё больше.
Если вы обучились плохо русскому языку, то виноваты вы сами или ваш учитель по русскому языку и литературы, но никак не автор статьи, раз вы не различаете слова компания и кампания. Судя по некоторым другим вашим комментариям вам ещё и манерам надо бы научиться.
Зависит от модели партнёрства. Если CPA (Cost-Per-Action), то только за первый заказ приведённого пользователя, а если RevShare (Revenue Share), то с каждого заказа приведённого пользователя. В статье компания именно по CPA модели работала.
Потому что за те же деньги, можно получать больший доход, просто заполняя работой не нагруженное время. А когда нагрузка плюс-минус будет равномерной, можно будет и подумать об увеличении штата, чтобы ещё больше заказов в день принимать, ну а в лучшем случае и над второй точкой, пока конкурент тратит кучу денег на сотрудников, которые большую часть времени простаивают и не "генерируют" прибыль. Бизнес штука такая, что затраты нужно правильно планировать, а расходы уменьшать. Нет никакого смысла ради сиюминутных процентов маржи вваливать кучу денег, если расходы не оптимизированы
Это никак не связано с оптимизацией... чтобы не было необходимости хостить выделенный сервер
Оптимизация - это более широкое понятие, чем улучшение кода по времени/памяти, поэтому это вполне себе оптимизация (инфраструктуры)
Но, опять же, это зависит от того, насколько хотят взломать
Согласен, только при ПОЛНОЙ обработке всех действий (в том числе и итоговая картинка экрана) на сервере компании разработчика читы действительно будут убиты, но в современных реалях это будет стоит очень дорого, а по сути превращаться в клауд-гейминг
По сути, второй и третий пункт вышли из первого
DI-библиотеки просто решают проблему инъекции зависимостей, чтобы руками не прописывать, архитектура тут может быть любая, а про неё ни слова
Как минимум, на одном соединении к СУБД вы долго не протянете и надо будет их создавать и удалять. Причём бездумно не получится, потому что есть такая штука как транзакции, запросы которых должны быть в рамках одного соединения. И вот у вас уже есть поддерево зависимостей, которое должно создаваться и удаляться динамически. И таких кейсов может быть много. Посмотрите на реализации DI/IoC в Java/C#, там приложения тоже запускаются один раз и всё, но разработчикам дают выбор скоупа зависимостей
В бигтехе задача от продактов идёт бизнес-аналитикам, архитекторам, системным аналитикам, проджектам и только потом уже к вам. А вас никто не будет спрашивать, надо ли им это, раз задача у вас, значит надо, а решение уже в задаче от архитекора или системного аналитика, вам и предлагать нечего, вам надо ТОЛЬКО сделать. Тестированием будут заниматься QA-инженеры, развёрткой - ваш тимлид или девопс, инфрой - админы и девопсы. Такова ужасная жизнь корпоратов, где у каждого своя роль, и как у программиста у вас роль именно программировать, а не всё прочее. Если хотите более широких полномочий, то работайте в компаниях меньше - чем меньше компания, тем шире ответственность.
Очередная библиотека для реактивного программирования, а чем она лучше того же RxJS? Быстрее? Понятнее? Или всё вместе?
Я в общем-то не любитель реактивного программирования, но с простотой чтения кода соглашусь, а вот написание кода очень сомнительно, по сути каждая такая библиотека - это отдельный язык внутри языка и буквально приходится сидеть с документацией, выискивая - а какая же функция мне тут нужна. Обычные синтаксические конструкции того же JavaScript просто так не возьмёшь, потому что другая парадигма, и иногда их использовать не получится в принципе
getData(n) - заменяем изменяем на результат этой функции, а имена переменных и функций можно вручную переименовывать в зависимости от контекста, так как это не особо отличается от обычной минификации, от любого бандлера
Приходилось по кое-какой нужде так делать, ничего сложного, пара часов и готово. А если код изначально использует много объектов, классов и тд, то там восстанавливать вообще нечего, так как обфускатору все аксессоры (филды, методы, геттеры, сеттеры и тд) нужно или оставлять в том же виде, чтобы не поломать ничего, или через тот же механизм getData, который довольно просто вернуть в исходное состояние.
Хороший обфускатор должен что-то заинлайнить, всё переименовать, простые операции заменить на много непонятных так, чтобы результаты были теми же и тд, а потом ещё это и хорошенечко зашифровать в eval, вызов которого тоже обфусцировать.
Так как мы говорим про JavaScript, то действительно хорошая обфускация просто убьёт производительность и размер вашего приложения, при том, что кто надо, тот всё равно вернёт код в приемлемое состояние. Как неплохой вариант действительно важный код переписать под WebAssembly, так восстанавливать код из ассемблера не самое приятное занятие, хоть и возможное + есть вероятность, что работать побыстрее будет. Пора уже смирится - всё, что вы отдаёте пользователям, становится общедоступным. Свои крутые алгоритмы переносите на сервер и не надо будет думать, как бы вам код обфусцировать, чтоб конкуренты не спёрли.
Где
успешнозабываем включить Row Level Security, из-за чего потом у нас угоняют базуЯ понимаю, проект больше для обучения механики, но стоило хотя бы упомянуть
Тут скорее борьба автоматического и ручного маппинга. Для себя я решил так - если объекты небольшие или маппинг нужен в 1-2 других классов, то можно и руками, а если начинается чехорда, когда объекты крупные и их надо в кучу других классов маппить, то использую автомаппер, желательно, который использует кодогенерацию, чтобы не было ошибок в рантайме
У Яндекса, который имеет юр.лица в Нидерландах, Сербии, Казахстане и, возможно, ещё в куче стран, с этим не должно быть проблем
Потому что кому-то нужны одни настройки, кому-то ещё другие, в итоге и получается дефолтный management ui plugin с очень многими настройками
Ещё надо спросить, сколько уволили и сколько ушли сами
По моему опыту, average lifetime джуна в компании - не более полугода, так как уже через 3 месяца работы у него будут предложения минимум x2 к текущим
Да и то, если в DTO много именно текстовых данных, это особо не улучшит ситуацию
Которую использовали китайцы для майнинга, а продавец взял у них её за 20к
Да, справа снизу от поиска показывает город, выберите там любой из РФ
По поводу первого пункта не совсем согласен. Если ты уровня стажор/джун, то можно и за 20к поработать, главное, во время уйти (через 3-6 месяцев) и потом спокойно просить x3-x4, а то и гораздо больше, а не сидеть и ждать, пока тебя заметят и магическим образом повысят зп.
А если уж очень хочется денег и ментально готов впахивать за четверых, то можно соврать об опыте и просить ещё больше.
Если вы обучились плохо русскому языку, то виноваты вы сами или ваш учитель по русскому языку и литературы, но никак не автор статьи, раз вы не различаете слова компания и кампания. Судя по некоторым другим вашим комментариям вам ещё и манерам надо бы научиться.
Яндекс в URL добавляет метки, по которым мы можем отслеживать, что пользователь пришёл с него
Зависит от модели партнёрства. Если CPA (Cost-Per-Action), то только за первый заказ приведённого пользователя, а если RevShare (Revenue Share), то с каждого заказа приведённого пользователя. В статье компания именно по CPA модели работала.
Потому что за те же деньги, можно получать больший доход, просто заполняя работой не нагруженное время. А когда нагрузка плюс-минус будет равномерной, можно будет и подумать об увеличении штата, чтобы ещё больше заказов в день принимать, ну а в лучшем случае и над второй точкой, пока конкурент тратит кучу денег на сотрудников, которые большую часть времени простаивают и не "генерируют" прибыль. Бизнес штука такая, что затраты нужно правильно планировать, а расходы уменьшать. Нет никакого смысла ради сиюминутных процентов маржи вваливать кучу денег, если расходы не оптимизированы
Оптимизация - это более широкое понятие, чем улучшение кода по времени/памяти, поэтому это вполне себе оптимизация (инфраструктуры)
Согласен, только при ПОЛНОЙ обработке всех действий (в том числе и итоговая картинка экрана) на сервере компании разработчика читы действительно будут убиты, но в современных реалях это будет стоит очень дорого, а по сути превращаться в клауд-гейминг