Как то не много полезных плюшек в этом пакете. Пожалуй, пока продолжу использовать https://github.com/samber/lo Там и слайсы и мапы и прочие полезности, нужные в повседневной работе.
Я видел такое в крупных проектах: "Ты должен решать только свою задачу", "Не лезь чужую зону ответственности", "Тебя об этом думать не просили", "Забыть ты это слово - рефакторинг", "Не трать время на то, о чем тебя не просили", "Если ты это исправишь, ты можешь дать 100% гарантии что ничего не сломается?", "Здесь так не принято", "Это сделали умные люди, ты что, считаешь себе умнее их?" и т.д. (Именно в таких резких выражениях это озвучивается не часто, но посыл такой) И ничего удивительного что проект через несколько лет развития представляют собой кошмарную архитектурную лапшу и сплошной легаси. Даже у новичков с горящими глазами быстро отбивается желание сделать проект лучше и они начинают просто "закрывать свои задачи".
Конечно, не надо по каждому поводу сразу кидаться в рефакторинг, но такие идеи надо сразу обсуждать. И не выкидывать в бесконечный бэклог-помойку.
К тому же новички могут взглянуть на проект свежим не замыленным взглядом, или принести какие то хорошие решения с предыдущих мест работы. И у них еще не отбито желание сделать что то лучше.
Когда дело движется к офферу, вопрос "комфортной" зарплаты обычно поднимается снова. Можно понять планку. Все понимают, что если офферов будет несколько, возможно вы выберите тот, где предложат больше.
Можно указать комфортную зарплату в резюме, можно не указывать. Но точно нельзя недооценивать себя в деньгах.
Вот в моем резюме другая проблема, которая отпугивает рекрутеров. 16 лет работы на одном месте в мелкой фирме. На самом деле я владелец этой фирмы, а сейчас по сути являюсь фрилансером, который оказывает услуги по разработке через собственное юридическое лицо.
К сожалению, это очень выбивается из стандартного резюме, а первичные рекрутеры как правило не хотят разбираться. Обычно они хотят видеть что то стандартное, типа менял работодателя раз в несколько лет с повышением и список известных работодателей.
Я лучше привьюсь официальной вакциной сейчас. А то вокруг меня без маски слишком много людей, которые пытаються воздушно-капельным путем мне привить иммунитет «неофициальной вакциной» с живым вирусом. От официальной вакцины в любом случае меньше побочек.
Пугает пожизненное ограничение на любую потенциально возможную аденовекторную генную терапию
Не понял. Это ограничение будет только на аденовирусы 5-го и 26-го серотипов? А сколько всего этих серотипов возможно использовать? Если произойдет такая массовая вакцинация, то я так понимаю, просто все последующие терапии будут строится на других аденовирусах.
И вообще, это что же получается? Если я до этого делал какие то прививки созданные по схожей технологии, то ни Спутник-V и ни какая другая схожая вакцина уже на мне не сработает?
в результате повторного введения, «машина с пассажиром» просто не успеет доехать до клетки, а будет сразу уничтожена антителами, которые образуются в результате предыдущего «знакомства».
А этот иммунитет на «машину» точно пожизненный? Вроде как большинство прививок действуют всего несколько лет. Потом надо перевакцинироваться.
Работаю удаленно около 5 лет. Fullstack разработчик (преимущественно PHP). Собственный малый бизнес по разработке софта. Вот мое сегодняшнее рабочее место дома:
Но иногда бывают и другие рабочие места. Например вот, за окном Венеция:
Красиво, но не очень интуитивно понятно, особенно для сторонних разработчиков. А в ряде случаев вообще больше похоже на «смотри как я еще могу». Поэтому я большинстве случаев я бы выбрал более классические методы. По себе я помню лишь несколько случаев когда reduce() действительно органично вписался в задачу.
Последние лет я 5 наблюдал отсутствие интернета только в самолетах. На счет закидывания файлов на телефон я вспоминаю эти навыки только перед посадкой в самолет.
Бывает в метро кратковременно пропадает интернет, нажал ссылку, а страница не отрывается, приходится ждать минуту пока связь восстановится. В крупных городах России и Европы вроде покрытие полное. Вот еще был как то в глухой деревне за 100 км от всех городов, там если зайти в лес тоже бывает связь не стабильная.
Все правильно говорите на счет изучения, вакансий, перспектив…
Но абстрагируясь от этого хочется сказать, человечество почти утратило умение быстро и просто создавать целый пласт ПО используя визуальные IDE. Раздувается сложность, производительность разработчиков падает.
Мне часто кажется что в некоторых областях разработка реально деградирует и бессмысленно усложняется. И Delphi хороший тому пример.
На Delphi (сюда же C++ Builder, Visual Basic и т.п.) можно было очень быстро написать типичные корпоративные приложения, разработка которых всегда была очень востребована. В данном случае я имею ввиду приложения вида: база данных, таблички, формочки, отчеты… В Delphi такое приложение зачастую можно было на 80% сделать визуально (формошлепство), а потом быстро дописать недостающую логику.
Зачастую, приложение типа корпоративной базы данных или какую нибудь несложную CRM, на десяток таблиц, сотню полей и десяток красивых отчетов, писались студентами на 1-2 дня и за коробку Сникерсов. Приложения отлично работали и исправно служили лет по 10.
А как сейчас? Сейчас так не получится. Сейчас практически нет визуального программирования. Корпоративное приложение это сложный комплекс из специально настроенного под него сервера, база данных, сервер приложения, веб сервер, какой нибудь фреймворк типа Laravel или Symfony, на котором вручную программируется куча CRUD операций, вручную сверстанный фронтент, который тоже в свою очередь тянет целый стек. Над созданием приложения трудится куча народу и тратят на это человеко-месяцы! И все вручную!
А в чем плюс таких приложений по сравнению с древним приложением на Delphi? Часто лишь в модном красивом дизайне, как говориться «свистелки-#ерделки», плюс работа через браузер без установки софта. А по мне это может быть и минус, потому как каждый разработчик делает интерфейс в своем уникальном стиле, а несчастные пользователи вынуждены разбираться с каждым новым приложением.
Сам я последний раз писал на Delphi 20 лет назад. Сейчас разрабатываю фулстек веб-приложения в соответствии с современными традициями. И постоянно ловлю себя на мысли что сейчас все сложно, дорого и запутанно, а раньше было быстро и просто. Если бы разработка в стиле Delphi развивалась последние 20 лет, насколько бы прекрасной она могла стать? Но увы. Да и понятно почему так случилось, история развития отрасли прошла перед глазами.
Все что я говорю, я говорю о приложениях типа корпоративных баз данных, CRM-ERP средней сложности, других подобных приложениях, главная задача которых это CRUD и удобный вывод информации для пользователей. Но это я бы сказал 75% от всех софтверных работ.
CRUD, построение GUI, редактируемых таблиц, деревьев, формочек, графиков, отчетов, вывод информации — требуется повсеместно. Программировать это руками — крайне скучная и рутиная задача. Современные фрейворки лишь немного упрощают эти задачи. На мой взгляд такие вещи вообще должны быть максимально упрощены и быть преимещественно визуальными, чтобы позволить разработкам сосредоточится на действительно сложных задачах, не ручном программировании GUI и CRUD операций. Кажется за 20 лет это область не то что развилась, а просто ушла в историю. Сейчас конечно есть какие то инструменты, но они или мало распространены или бессистемны. Все, я нанылся, теперь возвращаюсь к пилению своего текущего веб приложения на Laravel-Vue. Надо еще десяток CRUD операций написать ручками и десяток форм сверстать на HTML-CSS-JS, все ручками, никакого визуального программирования… Долго, скучно и печально
Вроде как разломали и уничтожили раритетное изделие. Но сделано это с уважением. Теперь это не просто железяка валяющаяся у кого то на полке. Это достояние общественности, и каждый увлеченный данной тематикой, может изучить изделие во всех подробностях, а не просто оценить внешний вид.
С некоторыми заказчиками гибкие методологии вам не помогут. Например с гос заказом вы по закону обязаны работать только по waterfall с четкими этапами и никак иначе. Внутрениие процессы организуйте как вам угодно, но с заказчиком извольте только через waterfall.
Ну и если заказчик крупный и не гибкий, то он будет навязывать свой подход мотивируя это «мы так не работаем», «у нас так не делается», «так нам не согласуют сверху»… Некоторые корпорации еще менее гибкие чем гос структуры.
По моему опыту, в таких проектах надо сначала внимательно выслушать и опросить представителей стороны заказачика, провести с ними несколько встреч. Но потом уже писать ТЗ самому, никого больше не слушая, давить авторитетом, и говорить что ты лучше знаешь как реализовать такой проект. Конечно, по ходу написания ТЗ нужно задавать заказчику появляющиеся вопросы, но ни в коем случае не давать ему влезать в составление проекта. Включайте режим «Мы вас выслушали, мы профессионалы, теперь мы объясняем что и как надо делать.»
В противном случае проект практически гарантированно утонет в обсуждениях, новых «гениальных» идеях, и бесконечном потоке псевдоэкспертов со стороны заказчика.
Утверждают что почти все популярные истории, мифы, сказки, легенды, фильмы, книги вообще сводятся в одной и той же сюжетной линии если снять с нее внешнюю оболочку. Причем это не зависит от страны, времени и культуры. Подробнее в Википедии по слову «Мономиф»
Как то не много полезных плюшек в этом пакете. Пожалуй, пока продолжу использовать https://github.com/samber/lo Там и слайсы и мапы и прочие полезности, нужные в повседневной работе.
Я видел такое в крупных проектах: "Ты должен решать только свою задачу", "Не лезь чужую зону ответственности", "Тебя об этом думать не просили", "Забыть ты это слово - рефакторинг", "Не трать время на то, о чем тебя не просили", "Если ты это исправишь, ты можешь дать 100% гарантии что ничего не сломается?", "Здесь так не принято", "Это сделали умные люди, ты что, считаешь себе умнее их?" и т.д. (Именно в таких резких выражениях это озвучивается не часто, но посыл такой)
И ничего удивительного что проект через несколько лет развития представляют собой кошмарную архитектурную лапшу и сплошной легаси. Даже у новичков с горящими глазами быстро отбивается желание сделать проект лучше и они начинают просто "закрывать свои задачи".
Конечно, не надо по каждому поводу сразу кидаться в рефакторинг, но такие идеи надо сразу обсуждать. И не выкидывать в бесконечный бэклог-помойку.
К тому же новички могут взглянуть на проект свежим не замыленным взглядом, или принести какие то хорошие решения с предыдущих мест работы. И у них еще не отбито желание сделать что то лучше.
Особого смысла в этом не было. Но, кажется, и так понятно о ком шла речь.
Когда дело движется к офферу, вопрос "комфортной" зарплаты обычно поднимается снова. Можно понять планку. Все понимают, что если офферов будет несколько, возможно вы выберите тот, где предложат больше.
Можно указать комфортную зарплату в резюме, можно не указывать. Но точно нельзя недооценивать себя в деньгах.
Бывает и не редко. Наверное об этом тоже стоило написать, чтобы это ни для кого не оказалось шоком.
-
К сожалению, это очень выбивается из стандартного резюме, а первичные рекрутеры как правило не хотят разбираться. Обычно они хотят видеть что то стандартное, типа менял работодателя раз в несколько лет с повышением и список известных работодателей.
И вообще, это что же получается? Если я до этого делал какие то прививки созданные по схожей технологии, то ни Спутник-V и ни какая другая схожая вакцина уже на мне не сработает?
А этот иммунитет на «машину» точно пожизненный? Вроде как большинство прививок действуют всего несколько лет. Потом надо перевакцинироваться.
Но иногда бывают и другие рабочие места. Например вот, за окном Венеция:
Бывает в метро кратковременно пропадает интернет, нажал ссылку, а страница не отрывается, приходится ждать минуту пока связь восстановится. В крупных городах России и Европы вроде покрытие полное. Вот еще был как то в глухой деревне за 100 км от всех городов, там если зайти в лес тоже бывает связь не стабильная.
Но абстрагируясь от этого хочется сказать, человечество почти утратило умение быстро и просто создавать целый пласт ПО используя визуальные IDE. Раздувается сложность, производительность разработчиков падает.
На Delphi (сюда же C++ Builder, Visual Basic и т.п.) можно было очень быстро написать типичные корпоративные приложения, разработка которых всегда была очень востребована. В данном случае я имею ввиду приложения вида: база данных, таблички, формочки, отчеты… В Delphi такое приложение зачастую можно было на 80% сделать визуально (формошлепство), а потом быстро дописать недостающую логику.
Зачастую, приложение типа корпоративной базы данных или какую нибудь несложную CRM, на десяток таблиц, сотню полей и десяток красивых отчетов, писались студентами на 1-2 дня и за коробку Сникерсов. Приложения отлично работали и исправно служили лет по 10.
А как сейчас? Сейчас так не получится. Сейчас практически нет визуального программирования. Корпоративное приложение это сложный комплекс из специально настроенного под него сервера, база данных, сервер приложения, веб сервер, какой нибудь фреймворк типа Laravel или Symfony, на котором вручную программируется куча CRUD операций, вручную сверстанный фронтент, который тоже в свою очередь тянет целый стек. Над созданием приложения трудится куча народу и тратят на это человеко-месяцы! И все вручную!
А в чем плюс таких приложений по сравнению с древним приложением на Delphi? Часто лишь в модном красивом дизайне, как говориться «свистелки-#ерделки», плюс работа через браузер без установки софта. А по мне это может быть и минус, потому как каждый разработчик делает интерфейс в своем уникальном стиле, а несчастные пользователи вынуждены разбираться с каждым новым приложением.
Сам я последний раз писал на Delphi 20 лет назад. Сейчас разрабатываю фулстек веб-приложения в соответствии с современными традициями. И постоянно ловлю себя на мысли что сейчас все сложно, дорого и запутанно, а раньше было быстро и просто. Если бы разработка в стиле Delphi развивалась последние 20 лет, насколько бы прекрасной она могла стать? Но увы. Да и понятно почему так случилось, история развития отрасли прошла перед глазами.
Все что я говорю, я говорю о приложениях типа корпоративных баз данных, CRM-ERP средней сложности, других подобных приложениях, главная задача которых это CRUD и удобный вывод информации для пользователей. Но это я бы сказал 75% от всех софтверных работ.
CRUD, построение GUI, редактируемых таблиц, деревьев, формочек, графиков, отчетов, вывод информации — требуется повсеместно. Программировать это руками — крайне скучная и рутиная задача. Современные фрейворки лишь немного упрощают эти задачи. На мой взгляд такие вещи вообще должны быть максимально упрощены и быть преимещественно визуальными, чтобы позволить разработкам сосредоточится на действительно сложных задачах, не ручном программировании GUI и CRUD операций. Кажется за 20 лет это область не то что развилась, а просто ушла в историю. Сейчас конечно есть какие то инструменты, но они или мало распространены или бессистемны.
Все, я нанылся, теперь возвращаюсь к пилению своего текущего веб приложения на Laravel-Vue. Надо еще десяток CRUD операций написать ручками и десяток форм сверстать на HTML-CSS-JS, все ручками, никакого визуального программирования… Долго, скучно и печально
Ну и если заказчик крупный и не гибкий, то он будет навязывать свой подход мотивируя это «мы так не работаем», «у нас так не делается», «так нам не согласуют сверху»… Некоторые корпорации еще менее гибкие чем гос структуры.
В противном случае проект практически гарантированно утонет в обсуждениях, новых «гениальных» идеях, и бесконечном потоке псевдоэкспертов со стороны заказчика.