Хороший показатель — гарантированный годовой доход. Вот он — показатель.
Когда то я ходил собеседоваться в одну из дочек сбера и там предлагали гарантированные квартальные премии в размере 75% зп. Надо ли говорить, что годовой доход получался серьёзно выше конкурентов по зарплате? )
ЗЫ: но я туда не пошёл.
ЗЫЫ: и это было реально давненько ) Но премии при выборе работы всегда надо учитывать.
В озоне, по слухам, минимум раз в полгода происходит пересмотр зарплат сотрудников и что то порядка 30-40% получают прибавку. Это очень неплохой подход, хоть и не классическая индексация. =)
ЗЫ: годовые премии были в том или ином виде везде где я работал. Где то 0.7 оклада, где то и до 2-3. Странно работать в фирме, которая не зарабатывает нормально )
ЗЫЫ: а вот индексацию я видел только в одном месте.
ЗЫЫЫ: Про индексацию порадовало на одном собеседовании: У нас, говорят, ежегодная индексация ЗП. Правда последние три года не индексировали, но тем не менее…
Ну, годовая премия, к примеру, в размер зарплаты — это +8.3% к зп. Т.е. если такая премия в фирме есть, то она даже с зп на 8% ниже ОЗОН-а уже выгоднее.
Так что это чисто «маркетинговый» ход с накруткой зп. =)
Не все догмы чистого кода стоит использовать.
Не все догмы чистого кода которые стоит использовать стоит использовать всегда.
Все догмы чистого кода которые всё-же используете стоит использовать с умом, оглядкой и в согласовании с командой.
Чистый код и похожие методики надо внедрять на уровне код-ревью и стандартов программирования в проекте/программе.
Фулстек обычно занимается интеграционными задачами или небольшими тасками не требующими глубокого погружения.
Бэк делает крупные проекты с большой логикой и сложностью. Обычно именно бэк делает логику происходящего, а это — самое важное для бизнеса.
Имхо, конечно.
Э-э… нет. Если планировщик достаточно мощный — количество необходимых вмешательств становится очень невелико.
Это легко описать простой зависимостью — чем проще задачи, в которых планировщику требуется подсказка — тем фиговей он. И наоборот — чем сложнее задачи, начинающие требовать явные подсказки — тем лучше.
Если планировщик плох — код будет выглядеть как нагромаждение нечитаемых костылей, призванных обойти проблемы планировщика…
Не хотел бы критиковать конкретные системы, но первый пример меня огорчил. =(
Никогда не минусовал, потому что не имею такой возможности. И желания, в прочем.
А вот плюс статье хотелось поставить…
Но, по мне, причина проставления минусов достаточно проста:
— Человек к тебе негативно отнёсся.
Причины зависят от человека и того что он прочёл (и в какое время).
-Может ты показался ему непонятливым?
-Задел за больное?
-Не согласен?
-Согласен не с тем?
-Задаёшь слишком много вопросов?
-Не понял юмора?
-Слишком строг/мягок?
Да мало ли. Люди разные и у них вызывают негатив очень разные вещи. И этот негатив в явном виде выражается в минусах. Карма в чистом виде ) Вы человеку негатив — он вам карму.
Стоит заметить, что очень часто автор поста может не понять и даже не догадывать о том, что сгенерировал в чьём то мозгу негатив.
Ну, вот, в MSSQL значительного выигрыша нет… потому что планировщик умеет раскладывать подзапросы. =)
Почти уверен, что оракл тоже должен нормально обработать такой случай.
В MSSQL планы почти идентичны. Между «оптимизированым» и «не очень» из данной статьи.
По моим ощущениям у мелкомягки планировщик немного умнее в этом плане. (с поправкой на особенности принципов работы бд).
1. Про ID хотелось бы заметить, что если писать нормальные алиасы, то нет необходимости дублировать информацию в названии ключа. Более того — замучаешься эти ключи постоянно писать.
2. NULL — имеет свои особенности и их надо знать. То что с ними кто то не умеет работать — совсем не повод от них избавляться.
Поводом служила бы сложная оптимизация моментов связанных с NULL, особенности хранения NULL на дисках или реальные ошибки логики которые придётся с трудом обходить.
Точно так же можно сказать что надо избегать неявного приведения типов, скобочек, дат, битовых типов и прочего-прочего — при использовании их неподготовленными людьми может произойти трагедия!
3. NOT NULL в определении колонок нужен там где он нужен, а не где только можно.
4.По поводу ключей — мне понравилась идея, так же, начинать наименования ключей с pk/fk/bk соответственно, что бы знать, что это не просто поле и что на него наложены ограничения и какие.
5. Не раскрыта тема использования схем и префиксов в названиях (функция? процедура? таблица? вьюха?). Надо? Не надо? Почему?
6. Т.е. в названиях не должно быть заглавных букв?
ЗЫ: вряд ли я пошёл бы туда, где зарплата будет сильно ниже не зная о премиях на собеседование. =)
Про после года работы — это есть такое, но есть и без этой фигни. =)
ну, я ищу работу, обычно, с желанием на ней задержаться, а не уволиться. =)
Когда то я ходил собеседоваться в одну из дочек сбера и там предлагали гарантированные квартальные премии в размере 75% зп. Надо ли говорить, что годовой доход получался серьёзно выше конкурентов по зарплате? )
ЗЫ: но я туда не пошёл.
ЗЫЫ: и это было реально давненько ) Но премии при выборе работы всегда надо учитывать.
В озоне, по слухам, минимум раз в полгода происходит пересмотр зарплат сотрудников и что то порядка 30-40% получают прибавку. Это очень неплохой подход, хоть и не классическая индексация. =)
ЗЫ: годовые премии были в том или ином виде везде где я работал. Где то 0.7 оклада, где то и до 2-3. Странно работать в фирме, которая не зарабатывает нормально )
ЗЫЫ: а вот индексацию я видел только в одном месте.
ЗЫЫЫ: Про индексацию порадовало на одном собеседовании: У нас, говорят, ежегодная индексация ЗП. Правда последние три года не индексировали, но тем не менее…
Так что это чисто «маркетинговый» ход с накруткой зп. =)
Напомнить просто, что к любым таким рекомендациям надо подходить с умом, а не слепо. =)
Да и в статье об этом не написано.
Не все догмы чистого кода которые стоит использовать стоит использовать всегда.
Все догмы чистого кода которые всё-же используете стоит использовать с умом, оглядкой и в согласовании с командой.
Чистый код и похожие методики надо внедрять на уровне код-ревью и стандартов программирования в проекте/программе.
Бэк делает крупные проекты с большой логикой и сложностью. Обычно именно бэк делает логику происходящего, а это — самое важное для бизнеса.
Имхо, конечно.
Это легко описать простой зависимостью — чем проще задачи, в которых планировщику требуется подсказка — тем фиговей он. И наоборот — чем сложнее задачи, начинающие требовать явные подсказки — тем лучше.
Если планировщик плох — код будет выглядеть как нагромаждение нечитаемых костылей, призванных обойти проблемы планировщика…
Не хотел бы критиковать конкретные системы, но первый пример меня огорчил. =(
А вот плюс статье хотелось поставить…
Но, по мне, причина проставления минусов достаточно проста:
— Человек к тебе негативно отнёсся.
Причины зависят от человека и того что он прочёл (и в какое время).
-Может ты показался ему непонятливым?
-Задел за больное?
-Не согласен?
-Согласен не с тем?
-Задаёшь слишком много вопросов?
-Не понял юмора?
-Слишком строг/мягок?
Да мало ли. Люди разные и у них вызывают негатив очень разные вещи. И этот негатив в явном виде выражается в минусах. Карма в чистом виде ) Вы человеку негатив — он вам карму.
Стоит заметить, что очень часто автор поста может не понять и даже не догадывать о том, что сгенерировал в чьём то мозгу негатив.
Почти уверен, что оракл тоже должен нормально обработать такой случай.
По моим ощущениям у мелкомягки планировщик немного умнее в этом плане. (с поправкой на особенности принципов работы бд).
*MS SQL
2. NULL — имеет свои особенности и их надо знать. То что с ними кто то не умеет работать — совсем не повод от них избавляться.
Поводом служила бы сложная оптимизация моментов связанных с NULL, особенности хранения NULL на дисках или реальные ошибки логики которые придётся с трудом обходить.
Точно так же можно сказать что надо избегать неявного приведения типов, скобочек, дат, битовых типов и прочего-прочего — при использовании их неподготовленными людьми может произойти трагедия!
3. NOT NULL в определении колонок нужен там где он нужен, а не где только можно.
4.По поводу ключей — мне понравилась идея, так же, начинать наименования ключей с pk/fk/bk соответственно, что бы знать, что это не просто поле и что на него наложены ограничения и какие.
5. Не раскрыта тема использования схем и префиксов в названиях (функция? процедура? таблица? вьюха?). Надо? Не надо? Почему?
6. Т.е. в названиях не должно быть заглавных букв?
Тема статьи хорошая, но дюже холиварная. =)
В этом плане лайтнинг намного надёжнее выглядит.