Мм, нет. С точки зрения отзывчивости(можно сказать скорости) интерфейса линукс может дать фору винде, просто за счёт тайловых оконных менеджеров.
После полугода использования i3wm в арче — на винде первое время мне всё казалось крайне медленным заторможенным.
<offtop/>
Возвращался из-за того, что на работе под виндой велась разработка.
Сейчас убунта и по сравнению с виндой — проблем куда больше специфичных. Притом в чистой системе, которую ставил на совершенно чистый пк. Не критичные проблемы, но периодически раздражают.</offtop/>
Я просто не понимаю вот этого вот «дурной тон», как-то очень категорично прозвучало. такое ощущение, что у вас прямо кровь из глаз льётся каждый раз, когда Вы слово «Vector» видите в коде.
Когда вы, в 2019 году будете писать стандартами 2000 года — это дурной тон. Крови из глаз не будет, однако наладить коммуникацию с коллегами вам будет куда сложнее.
Банально, видя ваши постоянные for и vector — на ревью к вам постоянно будут подходить и, скажем так, вбивать в голову — что так писать нельзя. Есть более подходящие инструменты.
Про veсtor и arrayList прекрасно написано тут, stackoverflow.com/questions/1386275/why-is-java-vector-and-stack-class-considered-obsolete-or-deprecated
Эта ссылка была в бенчмарке, который я кидал выше.
Несерьёзно как-то :)
И, если вы не измените своё мнение и стиль разработки после таких ревью, то коллеги просто не захотят с вами работать. Вы будете причиной негативной атмосферы в коллективе, которая ведёт к негативным последствиям для разработки продукта.
Если для вас это несерьёзно, то… что ж, ваш выбор.
Вам уже десяток людей сказала — потому что для обычных коллекций в большинстве случаев принято использовать ArrayList.
Почему? Потому что Vector медленнее и в большинстве случаев синхронизация излишняя.
И суммарно, если вы будете использовать Vector, то вы будете этим показывать свой низкий уровень владения языком, поскольку в 95% случаев это будет не оправданным решением, а лишь потому что вы так привыкли и вам так удобнее.
И, помнится, вы так ратовали за то, что использование foreach накладывает оверхед и лучше обходиться простым for с индексацией. Раз вы так боретесь за оверхед, то почему же используете Vector, который его вносит? Не находите противоречие?
Если вы пишете программы, которые будут читать другие разработчики на этом языке, то использовать Vector — дурной тон. Одного этого вам должно быть достаточно, чтобы не использовать его.
Если же вы пишете программы себе в ящик, которые никто, кроме вас и видеть не будет — вы вольны использовать, что пожелаете, но убеждать и спорить с людьми по поводу этого вам не стоит, выставляете себя лишь в плохом свете.
Мне сложно понять, какой конкретно острый угол фреймворка вызывает у вас такое яростное неприятие, поскольку инструмент с большего крайне удобен, интуитивно понятен, да и вообще хорошо и быстро работает. Изъяны есть.
Но люди пришедшие из WinForms, Swing, Delphi и ожидающие увидеть доску на которую накидываются контролы, порой, с мороза, чувствуют себя неуютно. Им всё кажется излишне сложным и избыточным
Вот примерно с этого угла и вызывает неприятие. Все свои UI я конструировал в конструкторах, по-типу Delphi, VisualStudio. В последнем, сот-но winforms и WPF. Да, в впф появилось больше возможностей, но в нём всё ещё было комфортно конструировать «по старому», набросал на доску, пара кликов и все ивенты нужные созданы, все элементы с доски доступны в твоём скоупе, никаких проблем, даблклик и счастье наяву.
Простые инструменты для входа с сокрытием сложности и автогенерацией кода. Если не выходить за рамки обычного десктопа, простых игрушек, то всё элементарно и вызывает лишь радость.
Перейдя на Java я просто запомнил, что на ней такого уровня конструкторов нет и особо не интересовался UI, перейдя в сторону бекенда. И, когда узнал про javaFX и про SceneBuilder — решил попробовать и начал пытаться делать всё по старому.
Но… автогенерации кода тут нет, всё ручками-ручками, лишь IDE помогает, но суммарно каждое изменение формы через SceneBuilder вызывало отторжение. Изменил там, сохранил, перешел в текстовое описание интерфейса, протыкал по всем созданным элементам, создал их в контроллере с помощью IDE. И так каждый раз. И, на самом деле, это было неприятным, но не критическим фактором. Добивающим фактором для меня стала просто отвратительная работа самого конструктора. Топорный, элементы располагаются с трудом, постоянно сползают при переносе и регулярные зависания самой программы. Особенно, если пытаешься использовать встроенный SceneBuilder через Idea.
Собственно, я прекрасно понимаю, что просто использовал инструмент не так, как полагается и поэтому к самому JavaFX у меня нет никаких негативных эмоций. Но я всё жду, когда кто-нибудь про неё напишет занимательный цикл статей с посылом «Хэй, JavaFx жив и удобен в наше время! Он реально классный!».) Мечты-мечты.
… на сегодняшний день… (с поправкой в том числе и на количество доступных специалистов на рынке)… и OpenJFX ..
Я, конечно, практически не изучал данный вопрос, но разве по FX есть достаточное количество вакансий\проектов\специалистов? Да даже хотя бы обширное коммьюнити с достаточным количеством мануалов и гайдов?
Чисто по внешнему впечатлению, развитие этого продукта остановилось, им никто не интересуется, статьи о нём не пишутся на тот же хабр. Не слышал о нём за последние два года ни разу, вот от вас только, хотя постоянно слежу за общим фоном Java-мира.
Пробовал изучать FX и просто по удобству использования использования и удобству разработки сравнивал с шарповыми WinForm\WPF, которые под mono спокойно запускались на линуксах в том числе. Сравнивал чисто в пользовательском смысле.
И, FX безумно проигрывал по скорости разработки и удобству. Безумное количество лишних действий, которые не удобны в том числе из SceneBuilder. И сам SceneBuilder тормознутое, топорное и чудное… было пару лет назад.
Я, разумеется, его не правильно готовил, с этим спорить не приходится, тем не менее — общее состояние дел как-то изменилась за эти два года или всё примерно на том же уровне? Использовал FX-8
Наверное мы с вами очень по-разному понимаем слово нищета.
У вас с вашим собеседником разные посылы.
Он говорит, что за 65к в Берлине ВЫ будете нормально жить, ВЫ будете способны позволить себе что-то сверх обычного.
А за те же 65к в Мюнхене ВЫ будете ВЫЖИВАТЬ, скажем так. ВЫ будете нищетой. Капсом просто акценты.
А у вас посыл — что ВОКРУГ вас всё плохо. Не лично у ВАС, а ВОКРУГ.
Если коротко, то, как я понял — Мюнхен слишком догорой по стоимости жизни там, поэтому 65к — мало.
Существующие пути обучения несовершенны, это несомненно. Но всем ментора не предоставить, да и не все ими хотят быть. А лучшего способа обучить человека, кроме как личный ментор, я не знаю.
Я вам больше скажу — если бы я нанимал такого человека, меня бы очень смутило отсутствие практики в виде реальных проектов — хотя надо сказать, что опыт администрирования без разработки при этом пожалуй бы зачелся.
А когда вы бывших студентов нанимаете без опыта реальных проектов — вас не смущает этот пункт? А студент, фактически, 3-5 лет учился программированию, а опыта всё так же нет.
Это я к тому, что если человек прямо заявляет, что переучивался и пришел в эту профессию из другой профессии — ожидать от него опыта участия в реальном проекте довольно глупая идея. Единственные проекты, которые у него могли быть — учебные, которые делали по результатам курсов.
И, если сравнивать студентов и рабочего человека — его путь, пусть и героический, но не такой долгий, как мог быть, пойди он учиться вторым высшим на программиста.
Где-то год-полтора и уходит у людей, которые хотят сменить профессию.
Возможно, еще от офиса зависит. На Кутузе вроде в конце лета- начале осени централизованно следить начали за этим делом, но чем закончилось — не знаю
Я ушел в июле и точно помню, как за пару месяцев(или пол года) до этого в сигму прилетело письмо из разряда «сотрудники совсем офигели и не ходят на работу. Уважаемые руководители, следите за своими бездарями, особенно в Питере, мать вашу!»
Суть была в том, что в отделении Питера сотрудники были замечены в том, что мало посещают работу или мало работают, поэтому, усиляйте контроль, товарищи.
У нас в первый месяц после этого тоже провели пару бесед, но в целом всем так же было особо пофиг. Поэтому, думаю, контроль точно усилили после этого.)
Если человек попробует изменить файл и написать git add file; git push origin HEAD;
то у него ничего не появится в удалённом репозитории.
Поэтому ваше объяснение трещит по швам при подходе в лоб. Зачем сохранять в локальный репозиторий? Сразу сохраню в удалённый и… не работает. Потому что объяснение некорректно.
Но, если он даже не удосужился прочитать первую статью из запроса «как работать с git», то… я даже не знаю, что. Для него работа с гитом будет адом и страданиями, поскольку человек не удосужился даже просто почитать мануалы по работе с инструментом и совершенно ничего о нём не знает. Но в таком случае этот человек — ссзб.
И вся эта ветка началась с того, что людям задавали базовый вопрос о отличиях этих двух команд, как небольшой этап пред-собеседования. Поэтому ваше ответвление про новичков некорректно. Когда человек начинает изучать инструмент — ему можно давать упрощающие объяснение из разряда ваших, но в случае вопроса на собеседовании ваш ответ будет некорректен.
А теперь придираетесь к словам.
Что сказать, спорить с вами ради спора мне не интересно. Захотите конструктивно поспорить — пожалуйста, а сейчас — удачи в жизни.
Уточнение, напоследок: если вы не сделаете коммит, то ваши изменения не зафиксируются в системе управления версиями. Ни в вашем локальном репозитории, ни в удалённом.
И что вы доказали? Только подтвердили мои слова. Коммит — фиксация, Пуш — транспорт.
Сделали реп, сделали туда пару коммитов, склонировали реп с этими коммитами и запушили(перенесли) эти же коммиты в удалённый реп.
Коммиты никуда не делись, они так же хранятся на вашем компьютере локально.
И вуаля, мы не сделали ни одного комита локально, но изменения, которые у нас есть, перенеслись на удаленный репозиторий.
Вы, кажется, путаете изменения и коммиты. Если вы что-то поменяли у себя в репозитории, то без коммита эти изменения нигде не появятся, ни на вашей машине, ни на удалённой — нигде. В вашем случае вы ничего не меняли, а просто перемещали ранее созданные коммиты из репозитория в репозиторий.
И… нет.
Коммит фиксирует изменения в локальном репозитории, пуш — переносит зафиксированные коммиты в удалённый репозиторий. Коммит — фиксация, пуш — транспорт. Не более того.
Если бы была ваша правда, то мы могли бы написать git push, не делая ни одного коммита и все наши изменения перенеслись бы в удалённый репозиторий, не фиксируясь локально.
в которых жор энергии исправили (от Darwin 4 или Monte Cristo 2 например).
Так вот почему, имея на руках MonteCristo2 я абсолютно не понимал, почему люди постоянно писали о «жоре» ониксов. У меня книжка при регулярном использовании пол месяца-месяц живёт без проблем, а если в режиме пару часов в неделю, то вообще может месяца 4(а может и больше, фз) жить и не знать проблем. Автономность сказка, никаких претензий не было ни разу.
Теперь ясно, что я просто умудрился купить сразу фикшенную версию книги. :D
Спасибо за разъяснение.
Так вы можете назвать свой грейд.
Насколько я помню, это не попадает под NDA. И эта цифра совершенно ничего не скажет левым людям, однако другие Сберовцы из неё смогут понять, как минимум, пул ваших задач, обязанности, которые у вас предположительно могли быть и просто уровень, на который вас оценили\вы договорились. Это будет хорошим дополнением к статье.
Не постоянно, конечно, да и далеко не большинство, но как минимум некая часть джавистов думает про то, сколько объектов скрывается за этим сахаром, сколько промежуточных коллекций создастся в этом месте. И, при случае, если выбор стоит между примерно одинаковыми по чтению вариантами, то несомненно выберут вариант с меньшим количеством лишних объектов.
Думаю, в шарпах подобное имеет место быть.
Поэтому, с некоторыми правками, можно сказать, что утверждение не ложно. ;)
После полугода использования i3wm в арче — на винде первое время мне всё казалось крайне медленным заторможенным.
<offtop/>
Возвращался из-за того, что на работе под виндой велась разработка.
Сейчас убунта и по сравнению с виндой — проблем куда больше специфичных. Притом в чистой системе, которую ставил на совершенно чистый пк. Не критичные проблемы, но периодически раздражают.</offtop/>
Когда вы, в 2019 году будете писать стандартами 2000 года — это дурной тон. Крови из глаз не будет, однако наладить коммуникацию с коллегами вам будет куда сложнее.
Банально, видя ваши постоянные for и vector — на ревью к вам постоянно будут подходить и, скажем так, вбивать в голову — что так писать нельзя. Есть более подходящие инструменты.
Про veсtor и arrayList прекрасно написано тут, stackoverflow.com/questions/1386275/why-is-java-vector-and-stack-class-considered-obsolete-or-deprecated
Эта ссылка была в бенчмарке, который я кидал выше.
И, если вы не измените своё мнение и стиль разработки после таких ревью, то коллеги просто не захотят с вами работать. Вы будете причиной негативной атмосферы в коллективе, которая ведёт к негативным последствиям для разработки продукта.
Если для вас это несерьёзно, то… что ж, ваш выбор.
Вам уже десяток людей сказала — потому что для обычных коллекций в большинстве случаев принято использовать ArrayList.
Почему? Потому что Vector медленнее и в большинстве случаев синхронизация излишняя.
Бенчмарки гуглятся за полторы минуты, будь у вас такое желание.
stackoverflow.com/questions/17471913/java-vector-vs-arraylist-performance-test
www.baeldung.com/java-arraylist-vs-vector
И суммарно, если вы будете использовать Vector, то вы будете этим показывать свой низкий уровень владения языком, поскольку в 95% случаев это будет не оправданным решением, а лишь потому что вы так привыкли и вам так удобнее.
И, помнится, вы так ратовали за то, что использование foreach накладывает оверхед и лучше обходиться простым for с индексацией. Раз вы так боретесь за оверхед, то почему же используете Vector, который его вносит? Не находите противоречие?
Если же вы пишете программы себе в ящик, которые никто, кроме вас и видеть не будет — вы вольны использовать, что пожелаете, но убеждать и спорить с людьми по поводу этого вам не стоит, выставляете себя лишь в плохом свете.
Вот примерно с этого угла и вызывает неприятие. Все свои UI я конструировал в конструкторах, по-типу Delphi, VisualStudio. В последнем, сот-но winforms и WPF. Да, в впф появилось больше возможностей, но в нём всё ещё было комфортно конструировать «по старому», набросал на доску, пара кликов и все ивенты нужные созданы, все элементы с доски доступны в твоём скоупе, никаких проблем, даблклик и счастье наяву.
Простые инструменты для входа с сокрытием сложности и автогенерацией кода. Если не выходить за рамки обычного десктопа, простых игрушек, то всё элементарно и вызывает лишь радость.
Перейдя на Java я просто запомнил, что на ней такого уровня конструкторов нет и особо не интересовался UI, перейдя в сторону бекенда. И, когда узнал про javaFX и про SceneBuilder — решил попробовать и начал пытаться делать всё по старому.
Но… автогенерации кода тут нет, всё ручками-ручками, лишь IDE помогает, но суммарно каждое изменение формы через SceneBuilder вызывало отторжение. Изменил там, сохранил, перешел в текстовое описание интерфейса, протыкал по всем созданным элементам, создал их в контроллере с помощью IDE. И так каждый раз. И, на самом деле, это было неприятным, но не критическим фактором. Добивающим фактором для меня стала просто отвратительная работа самого конструктора. Топорный, элементы располагаются с трудом, постоянно сползают при переносе и регулярные зависания самой программы. Особенно, если пытаешься использовать встроенный SceneBuilder через Idea.
Собственно, я прекрасно понимаю, что просто использовал инструмент не так, как полагается и поэтому к самому JavaFX у меня нет никаких негативных эмоций. Но я всё жду, когда кто-нибудь про неё напишет занимательный цикл статей с посылом «Хэй, JavaFx жив и удобен в наше время! Он реально классный!».) Мечты-мечты.
Я, конечно, практически не изучал данный вопрос, но разве по FX есть достаточное количество вакансий\проектов\специалистов? Да даже хотя бы обширное коммьюнити с достаточным количеством мануалов и гайдов?
Чисто по внешнему впечатлению, развитие этого продукта остановилось, им никто не интересуется, статьи о нём не пишутся на тот же хабр. Не слышал о нём за последние два года ни разу, вот от вас только, хотя постоянно слежу за общим фоном Java-мира.
Пробовал изучать FX и просто по удобству использования использования и удобству разработки сравнивал с шарповыми WinForm\WPF, которые под mono спокойно запускались на линуксах в том числе. Сравнивал чисто в пользовательском смысле.
И, FX безумно проигрывал по скорости разработки и удобству. Безумное количество лишних действий, которые не удобны в том числе из SceneBuilder. И сам SceneBuilder тормознутое, топорное и чудное… было пару лет назад.
Я, разумеется, его не правильно готовил, с этим спорить не приходится, тем не менее — общее состояние дел как-то изменилась за эти два года или всё примерно на том же уровне? Использовал FX-8
У вас с вашим собеседником разные посылы.
Он говорит, что за 65к в Берлине ВЫ будете нормально жить, ВЫ будете способны позволить себе что-то сверх обычного.
А за те же 65к в Мюнхене ВЫ будете ВЫЖИВАТЬ, скажем так. ВЫ будете нищетой. Капсом просто акценты.
А у вас посыл — что ВОКРУГ вас всё плохо. Не лично у ВАС, а ВОКРУГ.
Если коротко, то, как я понял — Мюнхен слишком догорой по стоимости жизни там, поэтому 65к — мало.
Существующие пути обучения несовершенны, это несомненно. Но всем ментора не предоставить, да и не все ими хотят быть. А лучшего способа обучить человека, кроме как личный ментор, я не знаю.
А когда вы бывших студентов нанимаете без опыта реальных проектов — вас не смущает этот пункт? А студент, фактически, 3-5 лет учился программированию, а опыта всё так же нет.
Это я к тому, что если человек прямо заявляет, что переучивался и пришел в эту профессию из другой профессии — ожидать от него опыта участия в реальном проекте довольно глупая идея. Единственные проекты, которые у него могли быть — учебные, которые делали по результатам курсов.
И, если сравнивать студентов и рабочего человека — его путь, пусть и героический, но не такой долгий, как мог быть, пойди он учиться вторым высшим на программиста.
Где-то год-полтора и уходит у людей, которые хотят сменить профессию.
Я ушел в июле и точно помню, как за пару месяцев(или пол года) до этого в сигму прилетело письмо из разряда «сотрудники совсем офигели и не ходят на работу. Уважаемые руководители, следите за своими бездарями, особенно в Питере, мать вашу!»
Суть была в том, что в отделении Питера сотрудники были замечены в том, что мало посещают работу или мало работают, поэтому, усиляйте контроль, товарищи.
У нас в первый месяц после этого тоже провели пару бесед, но в целом всем так же было особо пофиг. Поэтому, думаю, контроль точно усилили после этого.)
git add file; git push origin HEAD;то у него ничего не появится в удалённом репозитории.
Поэтому ваше объяснение трещит по швам при подходе в лоб. Зачем сохранять в локальный репозиторий? Сразу сохраню в удалённый и… не работает. Потому что объяснение некорректно.
Но, если он даже не удосужился прочитать первую статью из запроса «как работать с git», то… я даже не знаю, что. Для него работа с гитом будет адом и страданиями, поскольку человек не удосужился даже просто почитать мануалы по работе с инструментом и совершенно ничего о нём не знает. Но в таком случае этот человек — ссзб.
И вся эта ветка началась с того, что людям задавали базовый вопрос о отличиях этих двух команд, как небольшой этап пред-собеседования. Поэтому ваше ответвление про новичков некорректно. Когда человек начинает изучать инструмент — ему можно давать упрощающие объяснение из разряда ваших, но в случае вопроса на собеседовании ваш ответ будет некорректен.
Что сказать, спорить с вами ради спора мне не интересно. Захотите конструктивно поспорить — пожалуйста, а сейчас — удачи в жизни.
Уточнение, напоследок: если вы не сделаете коммит, то ваши изменения не зафиксируются в системе управления версиями. Ни в вашем локальном репозитории, ни в удалённом.
Сделали реп, сделали туда пару коммитов, склонировали реп с этими коммитами и запушили(перенесли) эти же коммиты в удалённый реп.
Коммиты никуда не делись, они так же хранятся на вашем компьютере локально.
Вы, кажется, путаете изменения и коммиты. Если вы что-то поменяли у себя в репозитории, то без коммита эти изменения нигде не появятся, ни на вашей машине, ни на удалённой — нигде. В вашем случае вы ничего не меняли, а просто перемещали ранее созданные коммиты из репозитория в репозиторий.
Коммит фиксирует изменения в локальном репозитории, пуш — переносит зафиксированные коммиты в удалённый репозиторий. Коммит — фиксация, пуш — транспорт. Не более того.
Если бы была ваша правда, то мы могли бы написать git push, не делая ни одного коммита и все наши изменения перенеслись бы в удалённый репозиторий, не фиксируясь локально.
Так вот почему, имея на руках MonteCristo2 я абсолютно не понимал, почему люди постоянно писали о «жоре» ониксов. У меня книжка при регулярном использовании пол месяца-месяц живёт без проблем, а если в режиме пару часов в неделю, то вообще может месяца 4(а может и больше, фз) жить и не знать проблем. Автономность сказка, никаких претензий не было ни разу.
Теперь ясно, что я просто умудрился купить сразу фикшенную версию книги. :D
Спасибо за разъяснение.
Насколько я помню, это не попадает под NDA. И эта цифра совершенно ничего не скажет левым людям, однако другие Сберовцы из неё смогут понять, как минимум, пул ваших задач, обязанности, которые у вас предположительно могли быть и просто уровень, на который вас оценили\вы договорились. Это будет хорошим дополнением к статье.
Думаю, в шарпах подобное имеет место быть.
Поэтому, с некоторыми правками, можно сказать, что утверждение не ложно. ;)
Ни разу не приходилось думать о таком даже. ;)
Однако, этот код заставил меня задуматься над тем, что может стоит глянуть в сторону Хаскеля и изучить его. Спасибо за приведённый пример. ;)