Поддерживаю! Именно нормальная командная строка, история команд, просмотра, редактирования, отсутствие необходимости использования мыши, хороший вьювер с нормальным подчитыванием а-ля тейл, хороший редактор. Именно, для людей, кто хочет быстро работать.
Да, комбайн мощный. Все можно настроить и сделать. Мне нравится его инсталляция: сам себя программирует - прям бользам на душу. У меня один друг сделал себе полность среду разработки на емаксе. Но настройка настолько нетривиальная и столько занимает времени!...
Баг при распаковке архивов с длинными именами файлов: имена обрезаются и в результате образуются дубликаты файлов и т.д. и т.п. Может уже исправили, но 2 года назад крови попил. После этого архивы с гита только в консоле распаковываю. К тому же быстрей выходит, т.к. плагин архивов в МС на перле написан криво. Как-то несколько лет назад правил другой баг там и была возможность оценить код. Может руки дойдут поправить и этот с длинными путями и именами.
Вообще, работа с архивами примитивная
Нет шортката открыть тот же путь на второй панели.
Уже упомянали отсутствие ctrl-c/v. Хотя, это заявленна как особенность работы с любыми терминалами. Самое смешное, что его механизм у меня на одном amd устройстве тоже нестабильно работает: теряет свой файл буфера обмена.
Редактор не такой продвинутый , как в Far'е
Но все равно МС удобней всех этих Крусаедеров и прочих Тоталов, т.к. не нужна мыша, а пальцев 10!:)
"Мутная" тема, т.к. ею не занимаются серьезно, а берут, зачастую, сроки "с потолка". Или после заявленных сроков менеджер делит на два, а то и больше.
Если новая тема, то нужно выделять время на исследование и эти исследования тоже контролировать. Т.е. не абстрактные "полгода", а, например:
3 дня на исследование вопроса: как народ решает подобные задачи, какие библиотеки и какие отзывы. Представление отчета по исследованиям с презентацией и обсуждением.
По результатам обсуждений выбираем направление, или несколько, и для них точно также выделяем: дизайн, разработка, тестирование, отладка, выпуск. И их оцениваем. Т.е. ничего сверестественного и нормально все оценивается и слона едим частями.
Принято считать, что ИТ молодая отрасль и этот миф взращивается нерадивыми менеджерами, которые привыкли в мутной воде удить рыбу.
Все проблемы сборки возникают от непонимания задач разработчика. Основная задача разработчика - автоматизировать рутинные операции для большей производительности. Если разработчик даже свою работу не в состоянии автоматизировать и упростить, начиная с изучения горячих клавиш, то ... ой!
Одна из следующих по критичности задача - обеспечение повторяемости результата. Если вы работаете с множеством проектов и разными настройками, то настройки в переменных окружения - не вариант. А плагины IDE могут вносить свои коллизии из-за разных версий и своей идеологии.
Используйте системы сборки как с общими настройками, так и частными под проект. Инструменты же тут могут быть разнообразные. Как говориться: "На вкус и цвет". Но даже с системами сборки не забывайте про макросы, шаблоны, bash/bat-скрипты и симлинки (в Windows они тоже есть), т.к. автоматизировать и оптимизировать можно, практически, до бесконечности.
Ой, не то, что пионерлагерь, так и цырк с конями в одном флаконе! Понабирали подешевле, видимо, чтоб потом можно было заменить ИИ безболененно.
Ему говоришь, что нужно идти по спецификации, что написано, то и делать. Если какой-то случай не покрыт или что-то некрасиво, поднимаешь вопрос, описываем и реализуем. А он все равно педалит как "видит", а видит мало ввиду отсутствия опыта. Чтоб декомпозицию делать, нужно понимать, что неправильно и что нужно в данном случае делать. Для много шагового рефакторинга нужно держать всю картину в голове. А там в голове своя вселенная. У меня бы и собес многие не прошли, т.к. нет даже базовых знаний.
Я до сих пор помню, как был шокирован и потрясен, когда впервые увидел Eclipse и POM. И, между прочим, дело во мне!
А в чем, собственно, проблема? Т.е. вы захотели съесть стейк, а, оказывается, его нужно готовить! Как-то раньше ни кого не шокировал ни компилятор, ни линковщик, ни отдельный отладчик. Я, как раз, за прогресс. Сам не люблю ни Eclipse ни Maven.
Но когда новичок, даже, не готов прикладывать усилия, то и результат будет такой же. Как раз посмотрите на все языки с низким порогом вхождения и что видим? Синоним бардака и антипаттернов - и так сойдет! А так хоть какой-то естественный отбор :)
Это если есть возможно взять и переписать. Например, мне нужно месяц, чтоб переписать проект с нуля, но чем будет заниматься команда? Это, конечно, вопрос к манагеру, почему он джунов набрал туда, где мидлу тяжко, но это факт. Вот и приходится занимать всю команду и идти шаг за шагом, чтоб и манагеру показать прогресс, и все заняты и учатся.
Прежде чем переписывать, нужно описать поведение существуещего, а тут как раз чаще всего и кроется основная проблема - никто не знает как оНо работает и требований нет. Начинаешь разбираться, описывать выявлять кучу скрытых багов и т.п. Вроде все собрал, а потом оказывается, что система закрыта - типа, черный ящик - по правилам. Но, система неотзывчива. Какие состояния?! О чем вы?! Никакой четкой логики, все зависит от ретраградного меркурия, но это не точно. Что делать?
Обвязываешь всю эту кашу и делаешь каркас из состояний через наблюдателей (переодически опрашиваешь, например, какие-то показатели в базе), т.к. внутрь залезть нельзя. Наподобие, как выращиваешь рецепторы. И получаешь обратную связь. Потом уже можно это тестировать и рефакторить.
В 2005 году в одной компании в США мы не смогли доказать, что на летнее время во всем мире переходят не так, как в Штатах. Зато как пришли угрозы штрафов от компаний-пользователей, т.к. сервера не перешли во время и некоторые потеряли на трафике несколько часов, то кинулись изучать вопрос, чтобы при переходе на зимнее время такого не повторилось.
Буквально прошлым летом в одной крупной логистической компании в качестве поля для даты int на пару байт в новом коде! И как они считают даты даже страшно было смотреть. А тут проблема високосного года...
Аналогично было, только наши фронари. Бизнес дал фотки как есть, дизайнер в отпуске, а они, видите ли "не дизайнеры", чтобы 4К уменьшить до 200 пикселей. Самое смешное, что пришел дизайнер и оказалось, что не может рисовать, поэтому чистить и править фото он не будет. Пришлось самому все быстренько исправлять. Такие спецы - за 21 день - зато дешево!
То вы не застали, когда по Мак работала только определенная версия Java и UI глючил безбожно. У многих стойкая аллегия на Мак после того.
У одного друга вообще был квест с Апплом и Маком. Презентовали ему 32 дюйма Аппл монитор. Круто! Давненько уже было, поэтому пришлось ставить 2ю карту на свой десктоп, чтоб потянул разверку. Включил. Опа, а через весь монитор полоса в пиксель-два! Т.е. несогласованность карт, типа. Взял Самсунг 32, а там такого нет. Давай искать мак, чтоб в родного воткнуть. Нашел, а он тупо не тянет. Монитор Аппл продал, мак оставил, типо, круто. Сидел на маке полгода-год кодил на С - все на маках и я. Потом плюнул, после очередного глючного патча и накатил линукс на него. Ходил потом, аж светился: "Чего я мучался столько?!"
Все работает для Canon. Просто идете на азиатские сайты и берете драйвера оттуда. Японцы давно делают под линукс, но не всегда легко их найти на официальных сайтах для стран.
У меня Ubunta был диск с одним из первых релизов, когда они рассылали. Потом Kubunta стоял на coLinux, но тоже недолго. Но на том и закончилось. Даже на Fedora сидел, но лишь бы не на Ubunta. Потому что если стал, то намертво. На работе стокнулся с последними версиями - хорошо, что не у меня! То на 14ю не накатывалась 16я, потом 18я с бубном... У меня дома openSuse c 2011 обновляется на Dell xps 17 и только на Nvidia дрова подбрасываю свои.
Здорово, что встретился человек, который помог вам взглянуть на мир другими глазами. Расширяйте границы возможного. Рассмотрите текущую ситуацию с разных сторон. Пройдет эйфория от первого успеха и опять встанет вопрос: "Что дальше?!". Нужно учиться самому справляться с выбором, без помощи явного ментора. Вы сами себе в состоянии помогать. Больше читайте, расширяйте кругозор.
В том же Бильдерберском клубе, несколько лет назад, проблему адекватного восприятия реальности людьми поставили как одну из приоритетных проблем. Это уже мешает накоплению капитала, т.к. грезы не создают реальный продукт.
После прочтения 5ти причин сразу возник вопрос: "Ну и при чем тут Agile?!" Если каждая из сторон имеет разные интересы, не понимает, что делать, начиная с найма нужных людей, то, какую форму управления не прими будет одинаково печальный результат. Более того! Чаще всего в такой ситуации все "танцы с бубном" по поддержанию правильного Agile, куча митингов всей командой без реального результата, приводят к огромным затратам, если сесть и посчитать все аккуратно.
Сейчас, как раз, "исправляю" один такой проект. Скрам мастер, даже, на митинг планирования спринта запланировал 3 часа от того, что не понимает ничего ни процессах, ни в предметной области, ни в разработке, ни в инструментах, как Jira. И нужна куча времени, чтобы просто, даже, набить спринт задачами. Получается, ему говорят чтот писать и что делать, а он выступает в роли печатающей машинки. Все уже кричат, что куча времени уходит на эти митинги, но у нас процесс! Точнее его отсутствие. Плюс уровень команды разработчиков не соответствует уровню поставленной задачи. И если бы это был стартап с инвестициями, то уже б все закончилось, т.к. закончились денеги.
Отсутствие понимания предметной области, целей и способов достижения, как найм, вовлечение подходящих на проекты людей, а не то, что есть, а там прорвемся.
Поддерживаю! Именно нормальная командная строка, история команд, просмотра, редактирования, отсутствие необходимости использования мыши, хороший вьювер с нормальным подчитыванием а-ля тейл, хороший редактор. Именно, для людей, кто хочет быстро работать.
Да, комбайн мощный. Все можно настроить и сделать. Мне нравится его инсталляция: сам себя программирует - прям бользам на душу. У меня один друг сделал себе полность среду разработки на емаксе. Но настройка настолько нетривиальная и столько занимает времени!...
Перед распаковкой или архивирование перл-скрипт готовит список файлов проблема именно в этом скрипте.
Зависание - это беда всех фоновых операций в мс.
Да, это была проблема моей инсталляции.
Баг при распаковке архивов с длинными именами файлов: имена обрезаются и в результате образуются дубликаты файлов и т.д. и т.п. Может уже исправили, но 2 года назад крови попил. После этого архивы с гита только в консоле распаковываю. К тому же быстрей выходит, т.к. плагин архивов в МС на перле написан криво. Как-то несколько лет назад правил другой баг там и была возможность оценить код. Может руки дойдут поправить и этот с длинными путями и именами.
Вообще, работа с архивами примитивная
Нет шортката открыть тот же путь на второй панели.
Уже упомянали отсутствие ctrl-c/v. Хотя, это заявленна как особенность работы с любыми терминалами. Самое смешное, что его механизм у меня на одном amd устройстве тоже нестабильно работает: теряет свой файл буфера обмена.
Редактор не такой продвинутый , как в Far'е
Но все равно МС удобней всех этих Крусаедеров и прочих Тоталов, т.к. не нужна мыша, а пальцев 10!:)
"Мутная" тема, т.к. ею не занимаются серьезно, а берут, зачастую, сроки "с потолка". Или после заявленных сроков менеджер делит на два, а то и больше.
Если новая тема, то нужно выделять время на исследование и эти исследования тоже контролировать. Т.е. не абстрактные "полгода", а, например:
3 дня на исследование вопроса: как народ решает подобные задачи, какие библиотеки и какие отзывы. Представление отчета по исследованиям с презентацией и обсуждением.
По результатам обсуждений выбираем направление, или несколько, и для них точно также выделяем: дизайн, разработка, тестирование, отладка, выпуск. И их оцениваем. Т.е. ничего сверестественного и нормально все оценивается и слона едим частями.
Принято считать, что ИТ молодая отрасль и этот миф взращивается нерадивыми менеджерами, которые привыкли в мутной воде удить рыбу.
Все проблемы сборки возникают от непонимания задач разработчика. Основная задача разработчика - автоматизировать рутинные операции для большей производительности. Если разработчик даже свою работу не в состоянии автоматизировать и упростить, начиная с изучения горячих клавиш, то ... ой!
Одна из следующих по критичности задача - обеспечение повторяемости результата. Если вы работаете с множеством проектов и разными настройками, то настройки в переменных окружения - не вариант. А плагины IDE могут вносить свои коллизии из-за разных версий и своей идеологии.
Используйте системы сборки как с общими настройками, так и частными под проект. Инструменты же тут могут быть разнообразные. Как говориться: "На вкус и цвет". Но даже с системами сборки не забывайте про макросы, шаблоны, bash/bat-скрипты и симлинки (в Windows они тоже есть), т.к. автоматизировать и оптимизировать можно, практически, до бесконечности.
Ой, не то, что пионерлагерь, так и цырк с конями в одном флаконе! Понабирали подешевле, видимо, чтоб потом можно было заменить ИИ безболененно.
Ему говоришь, что нужно идти по спецификации, что написано, то и делать. Если какой-то случай не покрыт или что-то некрасиво, поднимаешь вопрос, описываем и реализуем. А он все равно педалит как "видит", а видит мало ввиду отсутствия опыта. Чтоб декомпозицию делать, нужно понимать, что неправильно и что нужно в данном случае делать. Для много шагового рефакторинга нужно держать всю картину в голове. А там в голове своя вселенная. У меня бы и собес многие не прошли, т.к. нет даже базовых знаний.
А в чем, собственно, проблема? Т.е. вы захотели съесть стейк, а, оказывается, его нужно готовить! Как-то раньше ни кого не шокировал ни компилятор, ни линковщик, ни отдельный отладчик. Я, как раз, за прогресс. Сам не люблю ни Eclipse ни Maven.
Но когда новичок, даже, не готов прикладывать усилия, то и результат будет такой же. Как раз посмотрите на все языки с низким порогом вхождения и что видим? Синоним бардака и антипаттернов - и так сойдет! А так хоть какой-то естественный отбор :)
Это если есть возможно взять и переписать. Например, мне нужно месяц, чтоб переписать проект с нуля, но чем будет заниматься команда? Это, конечно, вопрос к манагеру, почему он джунов набрал туда, где мидлу тяжко, но это факт. Вот и приходится занимать всю команду и идти шаг за шагом, чтоб и манагеру показать прогресс, и все заняты и учатся.
Прежде чем переписывать, нужно описать поведение существуещего, а тут как раз чаще всего и кроется основная проблема - никто не знает как оНо работает и требований нет. Начинаешь разбираться, описывать выявлять кучу скрытых багов и т.п. Вроде все собрал, а потом оказывается, что система закрыта - типа, черный ящик - по правилам. Но, система неотзывчива. Какие состояния?! О чем вы?! Никакой четкой логики, все зависит от ретраградного меркурия, но это не точно. Что делать?
Обвязываешь всю эту кашу и делаешь каркас из состояний через наблюдателей (переодически опрашиваешь, например, какие-то показатели в базе), т.к. внутрь залезть нельзя. Наподобие, как выращиваешь рецепторы. И получаешь обратную связь. Потом уже можно это тестировать и рефакторить.
Citrix реально до сих пор не исправил проблему.
В 2005 году в одной компании в США мы не смогли доказать, что на летнее время во всем мире переходят не так, как в Штатах. Зато как пришли угрозы штрафов от компаний-пользователей, т.к. сервера не перешли во время и некоторые потеряли на трафике несколько часов, то кинулись изучать вопрос, чтобы при переходе на зимнее время такого не повторилось.
Буквально прошлым летом в одной крупной логистической компании в качестве поля для даты int на пару байт в новом коде! И как они считают даты даже страшно было смотреть. А тут проблема високосного года...
Аналогично было, только наши фронари. Бизнес дал фотки как есть, дизайнер в отпуске, а они, видите ли "не дизайнеры", чтобы 4К уменьшить до 200 пикселей. Самое смешное, что пришел дизайнер и оказалось, что не может рисовать, поэтому чистить и править фото он не будет. Пришлось самому все быстренько исправлять. Такие спецы - за 21 день - зато дешево!
Хм, странно, 2 года просидел с коннектом такого не было ни разу. На телефоне коннект отваливался пару раз...
То вы не застали, когда по Мак работала только определенная версия Java и UI глючил безбожно. У многих стойкая аллегия на Мак после того.
У одного друга вообще был квест с Апплом и Маком. Презентовали ему 32 дюйма Аппл монитор. Круто! Давненько уже было, поэтому пришлось ставить 2ю карту на свой десктоп, чтоб потянул разверку. Включил. Опа, а через весь монитор полоса в пиксель-два! Т.е. несогласованность карт, типа. Взял Самсунг 32, а там такого нет. Давай искать мак, чтоб в родного воткнуть. Нашел, а он тупо не тянет. Монитор Аппл продал, мак оставил, типо, круто. Сидел на маке полгода-год кодил на С - все на маках и я. Потом плюнул, после очередного глючного патча и накатил линукс на него. Ходил потом, аж светился: "Чего я мучался столько?!"
Все работает для Canon. Просто идете на азиатские сайты и берете драйвера оттуда. Японцы давно делают под линукс, но не всегда легко их найти на официальных сайтах для стран.
У меня Ubunta был диск с одним из первых релизов, когда они рассылали. Потом Kubunta стоял на coLinux, но тоже недолго. Но на том и закончилось. Даже на Fedora сидел, но лишь бы не на Ubunta. Потому что если стал, то намертво. На работе стокнулся с последними версиями - хорошо, что не у меня! То на 14ю не накатывалась 16я, потом 18я с бубном... У меня дома openSuse c 2011 обновляется на Dell xps 17 и только на Nvidia дрова подбрасываю свои.
Не, ну после Винды так сразу в Arch! :)
Да, ребята из Arch сообщества часто помогают в сложных ситуациях, хотя я на openSuse последние 12 лет сижу.
Здорово, что встретился человек, который помог вам взглянуть на мир другими глазами. Расширяйте границы возможного. Рассмотрите текущую ситуацию с разных сторон. Пройдет эйфория от первого успеха и опять встанет вопрос: "Что дальше?!". Нужно учиться самому справляться с выбором, без помощи явного ментора. Вы сами себе в состоянии помогать. Больше читайте, расширяйте кругозор.
Можно подумать во всем мире как-то иначе :)
В том же Бильдерберском клубе, несколько лет назад, проблему адекватного восприятия реальности людьми поставили как одну из приоритетных проблем. Это уже мешает накоплению капитала, т.к. грезы не создают реальный продукт.
После прочтения 5ти причин сразу возник вопрос: "Ну и при чем тут Agile?!" Если каждая из сторон имеет разные интересы, не понимает, что делать, начиная с найма нужных людей, то, какую форму управления не прими будет одинаково печальный результат. Более того! Чаще всего в такой ситуации все "танцы с бубном" по поддержанию правильного Agile, куча митингов всей командой без реального результата, приводят к огромным затратам, если сесть и посчитать все аккуратно.
Сейчас, как раз, "исправляю" один такой проект. Скрам мастер, даже, на митинг планирования спринта запланировал 3 часа от того, что не понимает ничего ни процессах, ни в предметной области, ни в разработке, ни в инструментах, как Jira. И нужна куча времени, чтобы просто, даже, набить спринт задачами. Получается, ему говорят чтот писать и что делать, а он выступает в роли печатающей машинки. Все уже кричат, что куча времени уходит на эти митинги, но у нас процесс! Точнее его отсутствие. Плюс уровень команды разработчиков не соответствует уровню поставленной задачи. И если бы это был стартап с инвестициями, то уже б все закончилось, т.к. закончились денеги.
Отсутствие понимания предметной области, целей и способов достижения, как найм, вовлечение подходящих на проекты людей, а не то, что есть, а там прорвемся.
И при чем тут Agile?!