Джуны (да и другие) уходят иногда. и это нормально. Не надо делать из этого трагедию. Надо просто принять как факт.
1) они делали свою работу, когда были джунами
2) это норм, что они уходят, если вы не можете обеспечить им «хорошую среду» (писал выше про задачи, команду и все такое). Я думаю и ты можешь перейти в другую компанию, если тебя заинтересуют, или если будет «плохо» на текущей.
Хороший вопрос.
Скорей всего многие ответят на него по разному и имеют разные причины.
Я вижу так:
Во-первых, удивительно, но на «рынке» реально мало толковых специалистов. Даже мидлов. Сейчас есть много ребят, которые прошли курс на, условно, JavaRush и хотят сразу 100500 в минуту и быть синьорами. И получается, что легче компании «вырастить» своего условного мидла. Который будет и с хорошими техническими знаниями. И сразу еще со знаниями бизнес-процессов внутри компании и ее целями.
Во-вторых, в этом есть что-то… (Не знаю какое слово подобрать правильнее.)
Если у компании есть возможность взять стажеров и джунов и дать им хорошие и качественные знания, то почему бы и нет? На рынке будет больше хороших специалистов. Будет больше конкуренция среди них, подталкивающая их больше развиваться.
Тут главное понимать, что есть условная команда «в мыле», которая и так загруженна «по самые уши», то такой команде нельзя давать (или брать) Джуна. Я про то и пиши в статье, что это ответственный шаг. И команда должна быть готова к нему. Нельзя взять Джуна и просто забить на него. Так будет только хуже всем.
Я согласен с одним из комментаторов выше. Джун ничего не должен ни вам, ни компании. Не нужно его считать «своим». Он такой же разработчик, как и все другие.
И тут задача работодателя обеспечить такую среду, из которой он не захочет уходить к другим: хорошая команда, возможности для развития, возможности проявить себя, интересные задачи.
Зп тоже влияет. Но она не всегда на первом месте. Человек может жертвовать частью зп ради «плюшек» описанных выше. Но и платить годами человеку зп, которую он перерос давно — не правильно.
Зависит от.
Тут нет единой правильной формулы и правильного пути. Все люди разные.
Для кого-то стартап будет отличным вариантом. Ответственность и неизвестность сыграет отличным мотиватором. И он быстро «прокачается» на разноплановых задачах
Кому-то намного комфортнее пройти этот путь в большой компании «с методом под боком»
Сервер может иметь соединение только с одним сетевым ключом одной серии. При исчерпании лицензий в одном сетевом ключе поиск в сети других ключей той же самой серии не выполняется.
т.е., найдя сетевой ключ, например, на 100 пользователей и использовав его полностью, даже при наличии в сети еще одного ключа на 100, он его не будет использовать :( дальше ему подавай на 300 или 500 пользователей уже.
И теперь представьте, что лучше: если иметь 5 ключей по 100 и один из 5 вдруг сломается. Или 1 на 500, и он вдруг сломается?
А скажите, плиз, в 8.3.6 отказоустойчевый сервер перестанет отказывать?
И почему вы выбрали именно такой путь с лицензирования? а именно, что нельзя использовать два сетевых пользовательских ключа одинакового типа?
1) В очередной раз спасибо. Теперь хотя бы понятно, что будут со мной делать, если решусь на этот шаг. И что лучше Фемто-LASIK.
2) У меня очень «хороший» рефлекс закрытия глаза. Т.е. даже просто закапать капли — это целая проблема. Сам себе уж точно не могу. Это нормально?
3) А могли бы рассказать как работает аппарат, для проверки зрения. Такой, в котором наводится резкость на «домик стоящий в поле». И как он понимает, что я действительно стал его четко видеть?
После проведения операции флэп расправляется обратно и не требует какой-то особой фиксации
Во-первых, спасибо В очередной раз с удовольствием прочитал.
Во-вторых, даже с учетом комментариев, я так и не понял, флэп — это, если я правильно понимаю, самый настоящий разрез? Он сам «прирастает» потом? а не может быть типо шрама, или что-то еще? И как долго он будет заживать?
Спасибо. Я тоже после Яка ждал версию SpeechKit под винфон.
Но, можно вопрос? Скорее риторический. Почему документация в первую очередь на английском? Нет, я понимаю, что все делается ради бизнеса и дохода, но иногда обидно, что даже русские фирмы, в первую очередь делают документацию не на родном языке.
и подключать ВИДом рабочую базу удобно если нужно многое брать от туда и анализировать, а если просто делать выкладку, то все же лучше старым добрым инсертом и апдейтом. Но это конечно же только ИМХО.
Обмен по xml или json это все хорошо и действительно быстрее стандартных средств (и более гибко), но, это все-равно медленно.
был опыт следующего обмена:
1) из 1С в промежуточную таблицу/БД (она так же может быть в облаке)
2) от туда в таблицу/БД с которой работает сайт
3) сайт берет из своей таблицы/БД
имхо, работа с бд всегда быстрее, чем с файлом.
Зачем делали промежуточную БД? За выгрузку и загрузку отвечали разные люди и что бы из 1с ничего не испортить в боевой бд сайта, решили сделать промежуточный узел
1) они делали свою работу, когда были джунами
2) это норм, что они уходят, если вы не можете обеспечить им «хорошую среду» (писал выше про задачи, команду и все такое). Я думаю и ты можешь перейти в другую компанию, если тебя заинтересуют, или если будет «плохо» на текущей.
Скорей всего многие ответят на него по разному и имеют разные причины.
Я вижу так:
Во-первых, удивительно, но на «рынке» реально мало толковых специалистов. Даже мидлов. Сейчас есть много ребят, которые прошли курс на, условно, JavaRush и хотят сразу 100500 в минуту и быть синьорами. И получается, что легче компании «вырастить» своего условного мидла. Который будет и с хорошими техническими знаниями. И сразу еще со знаниями бизнес-процессов внутри компании и ее целями.
Во-вторых, в этом есть что-то… (Не знаю какое слово подобрать правильнее.)
Если у компании есть возможность взять стажеров и джунов и дать им хорошие и качественные знания, то почему бы и нет? На рынке будет больше хороших специалистов. Будет больше конкуренция среди них, подталкивающая их больше развиваться.
Тут главное понимать, что есть условная команда «в мыле», которая и так загруженна «по самые уши», то такой команде нельзя давать (или брать) Джуна. Я про то и пиши в статье, что это ответственный шаг. И команда должна быть готова к нему. Нельзя взять Джуна и просто забить на него. Так будет только хуже всем.
И тут задача работодателя обеспечить такую среду, из которой он не захочет уходить к другим: хорошая команда, возможности для развития, возможности проявить себя, интересные задачи.
Зп тоже влияет. Но она не всегда на первом месте. Человек может жертвовать частью зп ради «плюшек» описанных выше. Но и платить годами человеку зп, которую он перерос давно — не правильно.
Тут нет единой правильной формулы и правильного пути. Все люди разные.
Для кого-то стартап будет отличным вариантом. Ответственность и неизвестность сыграет отличным мотиватором. И он быстро «прокачается» на разноплановых задачах
Кому-то намного комфортнее пройти этот путь в большой компании «с методом под боком»
А расскажите немного больше про код ревью.
С помощью какого инструмента вы его делаете?
т.е., найдя сетевой ключ, например, на 100 пользователей и использовав его полностью, даже при наличии в сети еще одного ключа на 100, он его не будет использовать :( дальше ему подавай на 300 или 500 пользователей уже.
И теперь представьте, что лучше: если иметь 5 ключей по 100 и один из 5 вдруг сломается. Или 1 на 500, и он вдруг сломается?
И почему вы выбрали именно такой путь с лицензирования? а именно, что нельзя использовать два сетевых пользовательских ключа одинакового типа?
2) У меня очень «хороший» рефлекс закрытия глаза. Т.е. даже просто закапать капли — это целая проблема. Сам себе уж точно не могу. Это нормально?
3) А могли бы рассказать как работает аппарат, для проверки зрения. Такой, в котором наводится резкость на «домик стоящий в поле». И как он понимает, что я действительно стал его четко видеть?
www.sputnik.ru/settings
Во-первых, спасибо В очередной раз с удовольствием прочитал.
Во-вторых, даже с учетом комментариев, я так и не понял, флэп — это, если я правильно понимаю, самый настоящий разрез? Он сам «прирастает» потом? а не может быть типо шрама, или что-то еще? И как долго он будет заживать?
Но, можно вопрос? Скорее риторический. Почему документация в первую очередь на английском? Нет, я понимаю, что все делается ради бизнеса и дохода, но иногда обидно, что даже русские фирмы, в первую очередь делают документацию не на родном языке.
и подключать ВИДом рабочую базу удобно если нужно многое брать от туда и анализировать, а если просто делать выкладку, то все же лучше старым добрым инсертом и апдейтом. Но это конечно же только ИМХО.
Обмен по xml или json это все хорошо и действительно быстрее стандартных средств (и более гибко), но, это все-равно медленно.
был опыт следующего обмена:
1) из 1С в промежуточную таблицу/БД (она так же может быть в облаке)
2) от туда в таблицу/БД с которой работает сайт
3) сайт берет из своей таблицы/БД
имхо, работа с бд всегда быстрее, чем с файлом.
Зачем делали промежуточную БД? За выгрузку и загрузку отвечали разные люди и что бы из 1с ничего не испортить в боевой бд сайта, решили сделать промежуточный узел