forum.opennet.ru

Форум Программирование под UNIX (Perl)
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Утилитарные задачи веб прогр. от простого к сложному, ddp (?), 24-Ноя-22, (0) [смотреть все]

не нужно начинать програмить в 40, если не готов быть джуном лет 5 И точно не н, pavel_simple. (?), 08:24 , 24-Ноя-22, (1) //

кхм, а с чего это вы взяли что джун это нулевые знания вообще, джун должен зна, Аноним (3), 02:21 , 27-Ноя-22, (3) //

Тебе бы к доктору Сслылки на твои фантазии будут на job ru Тысячами, раз ты так , Валерий (??), 02:44 , 28-Ноя-22, (4)
Д Артаньян Это ты , pavel_simple. (?), 09:39 , 28-Ноя-22, (6)

Перл отлично учится по книжкам с ламой и Higher Order Perl Больше ничего не нуж, Аноним (2), 15:48 , 24-Ноя-22, (2) +2 //

Higher Order Perl не замечал, спасибо за ответы, ddp (?), 08:23 , 30-Ноя-22, (10)
gt оверквотинг удален может, тогда лучше настоящий язык для ФП выучить для пер, Аноним (-), 22:57 , 30-Ноя-22, (13) +1 //

Что значит лучше Языки учат не чтобы найти единственный и до пенсии на нем писа, Аноним (16), 13:23 , 01-Дек-22, (16)

А почему, собственно, перл Он не то, чтобы сильно популярен в настоящее время , username (??), 09:39 , 28-Ноя-22, (5) //

Перл стоит учить, потому что это один из языков, которые делают программиста сил, Аноним (16), 11:12 , 29-Ноя-22, (8)
Опять же, много что пишут в этих ваших интернетрах про ЯП, но в моем случае, эта, ddp (?), 08:20 , 30-Ноя-22, (9) //

Именно по этому вам лучше не рассчитывать на технологии, которые будут приводить, Azudim (??), 16:43 , 30-Ноя-22, (12)
Перловики делятся на два в общем типа Это нестандартные пхпшники либо умелые си, Аноним (16), 09:59 , 01-Дек-22, (14)

Хочешь освоить технологию - сперва продай её Без шуток Свой первый проект на P, Azudim (??), 14:11 , 30-Ноя-22, (11) //

А вот наглядный пример, почему легаси ERP CRM на перле такое гуано Вы не освоил, Аноним (16), 12:04 , 01-Дек-22, (15) //

Обо мне вы кажется знаете даже больше, чем о ERP на Perl --Алло, вы программы , Azudim (??), 13:28 , 01-Дек-22, (17) //

Так уже давно все должно быть автоматизировано В экселе на коленке люди со врем, Аноним (16), 17:44 , 01-Дек-22, (18)

Кто то разве сказал про изучение неважно что Возьмем отчет об инфраструктуре, Azudim (??), 22:12 , 01-Дек-22, (19)

Сообщения [Сортировка по времени | RSS]

11. "Утилитарные задачи веб прогр. от простого к сложному" +/–

Сообщение от Azudim (??), 30-Ноя-22, 14:11

> Все книги хороши, везде много чего написано про перл, но где бы
> набрать этакий путеводитель по веб прогр. так, чтобы протащил адекватной, посильной
> и утилитарной работойпрактикой по программе обучения языку до более-менее рабочего уровня.
Хочешь освоить технологию - сперва продай её! Без шуток! Свой первый проект на Perl я продал до того, как узнал, что такое Catalyst (15 лет назад), пришлось освоить за считанные дни. Ответственность перед заказчиком и материальное вознаграждение - лучшие мотиваторы в обучении.
Если мы про WEB-разработку - нужно четко понимать в каких проектах мы участвуем и какие роли можем на себя взять. Если проектов нет - разработчиком не стать. Лучше искать "своего" заказчика - будет возможность выбирать роли. Нет своего заказчика - придется идти в команду, пытаться взять роль.
WEB решает частные задачи и бизнес-задачи. Деньги и заказчики там, где бизнес. Проекты есть для широкой аудитории (сайты, порталы, сервисы) и для узкой (ограниченное число пользователей, внутренние сервисы, типа CRM, ERP).
Проекты с большим количеством пользователей - акцент на дизайн, UI, производительность, тут доля работы с фронтом значительно выше, чем с бэком, от сюда и набор технологий: CSS (SCSS,SASS), реактивные JS фреймворки VUE, React, Angular. Бэк тут часто только отдает порцию данных в простом, нешаблонизированном виде (API), такая вот тонкая прослойка между БД и красивым фронтом.
Проекты для "внутрикорпоративного" использования - можно обходиться простейшим фронтом, где достаточно jQuery, а весь интерфейс рендерить на бэке. Вот тут как раз Perl Catalyst подошел бы, если бы..
Если бы у приложений жизненный цикл был пол года, разработка проходила бы за неделю - можно было бы собирать практически любой стэк технологий.. На практике приложение для бизнеса будет работать 10 лет, и 5 из них будет в каком то виде дорабатываться, тиражироваться, перетекать из проекта в проект. Выбирать приходится инструмент, который не "загнется" через пол года.. У заказчика есть риск смены разработчика.. Новый разработчки через 3-5 лет должен подхватить проект, технология должна быть еще жива, интересна новому разработчику и самих разработчиков на рынке должно быть достаточно. Все эти нюансы явно не в пользу Perl.
Разумеется, в WEB-разработке не только лишь эти два полюса. Я это к тому, что если душа просит автоматизации, нужно искать среду, в которой можно реализоваться. Автоматизатор дожен видеть где он может быть полезен и уметь превратить предпосылки в целесообразные проекты. Зашел в кабинет, увидел девченки что то в Excel пилят, задумался - сколько часов они на это тратят, сколько одновременно пользователей работают, нужно ли с другим офисом обмениваться данными, приходят ли данные из внешних сервисов.. может есть смысл переложить на WEB-проект? :)

Ответить | Правка | Наверх | Cообщить модератору

15. "Утилитарные задачи веб прогр. от простого к сложному" +/–

Сообщение от Аноним (16), 01-Дек-22, 12:04

А вот наглядный пример, почему легаси ERP/CRM на перле такое гуано. Вы не освоили ни перл, ни технологию.
>искать "своего" заказчика
Заказчик, который готов платить неопытному разработчику за некачественную работу, в наше время очень редок. Либо это жлоб, которому возможность напрямую трахать мозги программисту и низкая оплата важнее результата, либо идиот (работать с идиотами себе дороже, особенно начинающему). Хотя, какое нафиг либо.
Денег в таком формате минимум, стресса максимум. Лучше в команду пойти джуном и за полгода обтереться, чем культивировать собственный непрофессионализм, пребывая в иллюзиях, что если платят, то ты уже программист. Если возьмут при нынешней конъюктуре - уже успех.
> Выбирать приходится инструмент, который не "загнется" через пол года
Если бы это было так, никто бы не выбирал модные фронтенд-фреймворки. Однако, это происходит постоянно. Сам бизнес требует модные фреймворки и стек "новых" технологий. Менеджеры хотят имидж современного продукта. Разработчики хотят в резюме баззворды. Никого не волнует, что будет даже через два года. Даже через год. Дотащить до релиза и сплавить другой команде - в корпоративной среде постоянно. Или даже не дотащить до релиза, прожрать бюджет и свалить.
>Зашел в кабинет, увидел девченки
В какой кабинет, блин. Сейчас так никто не работает. На горизонте 5 лет никаких кабинетов с "девченками" уже не будет.
>может есть смысл переложить на WEB-проект?
Так появляется проект-урод, впаренный директору мальчиком-программистом, никому не нужный, работе с которым надо обучать (никому это не надо, все плюются).
Какой-то привет из 2005-го года, ей богу.

Ответить | Правка | Наверх | Cообщить модератору

17. "Утилитарные задачи веб прогр. от простого к сложному" +/–

Сообщение от Azudim (??), 01-Дек-22, 13:28

> А вот наглядный пример, почему легаси ERP/CRM на перле такое гуано. Вы
> не освоили ни перл, ни технологию.
Обо мне вы кажется знаете даже больше, чем о ERP на Perl :)

>>искать "своего" заказчика
> Заказчик, который готов платить неопытному разработчику за некачественную работу, в наше
> время очень редок. Либо это жлоб, которому возможность напрямую трахать мозги
> программисту и низкая оплата важнее результата, либо идиот
--Алло, вы программы разрабатываете? Я только сразу скажу, я идиот!
--Разрабатываем, только сразу предупреждаю, у нас в штате только джуны!
(это я к тому, что выяснить ху-из-ху не всегда сразу получается)
> Лучше в команду пойти джуном
> и за полгода обтереться, чем культивировать собственный непрофессионализм
Что будет культивироваться от постоянной практики - зависит от многих факторов. Есть и self-made профессионалы, есть и коллективы, где ни то что наставника не найти, ревью то не допросишься, да и качество не сильно волнует.
>> Выбирать приходится инструмент, который не "загнется" через пол года
> Если бы это было так, никто бы не выбирал модные фронтенд-фреймворки.
Эти фреймворки хотя бы все на JS, что плюс для резюме разработчика, а выбор какого ни будь нишевого тулкита это время потраченное напрасно..
>>Зашел в кабинет, увидел девченки
> Так появляется проект-урод, впаренный директору мальчиком-программистом, никому не нужный,
> работе с которым надо обучать (никому это не надо, все плюются).
Не важно кто и как делал и кто как покупал, если был расчет эффективности от внедрения. Знаю массу проектов, от которых современного человека должно коробить от одного внешнего вида (управленка на MS Access с товародвижением, складами, кешфло, расчетом ЗП..), однако заказчик своевременно получил конкурентное преимущество.

> Какой-то привет из 2005-го года, ей богу.
А в автоматизации с тех пор что то сильно изменилось?

Ответить | Правка | Наверх | Cообщить модератору

18. "Утилитарные задачи веб прогр. от простого к сложному" +/–

Сообщение от Аноним (16), 01-Дек-22, 17:44

> А в автоматизации с тех пор что то сильно изменилось?
Так уже давно все должно быть автоматизировано. В экселе на коленке люди со времен 1С семерки ничего не делают. Если память не изменяет, уже есть облачная бухгалтерия, которая полностью автоматом отчеты делает. То есть, если бы не креатив в отчетности и мутагенез в первичной документации, бухгалтера были бы уже не нужны.
>Эти фреймворки хотя бы все на JS, что плюс для резюме разработчика
JS типичный разработчик под %современный JS фреймворк% знает плохо или очень плохо, цена таким резюме ноль, зеро.
>выбор какого ни будь нишевого тулкита
>это время потраченное напрасно
Дрозофильное мышление. Изучить неважно что и успеть скачать как можно больше бабла, пока дают. Сэкономленное на изучении языков и тулкитов время (и заработанные лишние деньги) потратить на каком-нибудь пляжном курорте или просто пролежать, прожрать.
В итоге, в голове меньше, карьерные перспективы меньше, при сокращениях шансы вылететь выше.

Ответить | Правка | Наверх | Cообщить модератору

19. "Утилитарные задачи веб прогр. от простого к сложному" +/–

Сообщение от Azudim (??), 01-Дек-22, 22:12

> Дрозофильное мышление. Изучить неважно что и успеть скачать как можно больше бабла,
> пока дают. Сэкономленное на изучении языков и тулкитов время (и заработанные
> лишние деньги) потратить на каком-нибудь пляжном курорте или просто пролежать, прожрать.
Кто то разве сказал про изучение "неважно что" ?
Возьмем отчет об инфраструктуре крупного проекта (Яндекс, Ламода и т.п.), посмотрим что пишут о причинах выбора их технологий, поймем какие задачи они решают.. Посмотрим пару десятков вакансий.. и вот уже какое то представление есть.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

11. "Утилитарные задачи веб прогр. от простого к сложному"	+/–
Сообщение от Azudim (??), 30-Ноя-22, 14:11
> Все книги хороши, везде много чего написано про перл, но где бы > набрать этакий путеводитель по веб прогр. так, чтобы протащил адекватной, посильной > и утилитарной работойпрактикой по программе обучения языку до более-менее рабочего уровня. Хочешь освоить технологию - сперва продай её! Без шуток! Свой первый проект на Perl я продал до того, как узнал, что такое Catalyst (15 лет назад), пришлось освоить за считанные дни. Ответственность перед заказчиком и материальное вознаграждение - лучшие мотиваторы в обучении. Если мы про WEB-разработку - нужно четко понимать в каких проектах мы участвуем и какие роли можем на себя взять. Если проектов нет - разработчиком не стать. Лучше искать "своего" заказчика - будет возможность выбирать роли. Нет своего заказчика - придется идти в команду, пытаться взять роль. WEB решает частные задачи и бизнес-задачи. Деньги и заказчики там, где бизнес. Проекты есть для широкой аудитории (сайты, порталы, сервисы) и для узкой (ограниченное число пользователей, внутренние сервисы, типа CRM, ERP). Проекты с большим количеством пользователей - акцент на дизайн, UI, производительность, тут доля работы с фронтом значительно выше, чем с бэком, от сюда и набор технологий: CSS (SCSS,SASS), реактивные JS фреймворки VUE, React, Angular. Бэк тут часто только отдает порцию данных в простом, нешаблонизированном виде (API), такая вот тонкая прослойка между БД и красивым фронтом. Проекты для "внутрикорпоративного" использования - можно обходиться простейшим фронтом, где достаточно jQuery, а весь интерфейс рендерить на бэке. Вот тут как раз Perl Catalyst подошел бы, если бы.. Если бы у приложений жизненный цикл был пол года, разработка проходила бы за неделю - можно было бы собирать практически любой стэк технологий.. На практике приложение для бизнеса будет работать 10 лет, и 5 из них будет в каком то виде дорабатываться, тиражироваться, перетекать из проекта в проект. Выбирать приходится инструмент, который не "загнется" через пол года.. У заказчика есть риск смены разработчика.. Новый разработчки через 3-5 лет должен подхватить проект, технология должна быть еще жива, интересна новому разработчику и самих разработчиков на рынке должно быть достаточно. Все эти нюансы явно не в пользу Perl. Разумеется, в WEB-разработке не только лишь эти два полюса. Я это к тому, что если душа просит автоматизации, нужно искать среду, в которой можно реализоваться. Автоматизатор дожен видеть где он может быть полезен и уметь превратить предпосылки в целесообразные проекты. Зашел в кабинет, увидел девченки что то в Excel пилят, задумался - сколько часов они на это тратят, сколько одновременно пользователей работают, нужно ли с другим офисом обмениваться данными, приходят ли данные из внешних сервисов.. может есть смысл переложить на WEB-проект? :)
Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Утилитарные задачи веб прогр. от простого к сложному"	+/–
	Сообщение от Аноним (16), 01-Дек-22, 12:04
	А вот наглядный пример, почему легаси ERP/CRM на перле такое гуано. Вы не освоили ни перл, ни технологию. >искать "своего" заказчика Заказчик, который готов платить неопытному разработчику за некачественную работу, в наше время очень редок. Либо это жлоб, которому возможность напрямую трахать мозги программисту и низкая оплата важнее результата, либо идиот (работать с идиотами себе дороже, особенно начинающему). Хотя, какое нафиг либо. Денег в таком формате минимум, стресса максимум. Лучше в команду пойти джуном и за полгода обтереться, чем культивировать собственный непрофессионализм, пребывая в иллюзиях, что если платят, то ты уже программист. Если возьмут при нынешней конъюктуре - уже успех. > Выбирать приходится инструмент, который не "загнется" через пол года Если бы это было так, никто бы не выбирал модные фронтенд-фреймворки. Однако, это происходит постоянно. Сам бизнес требует модные фреймворки и стек "новых" технологий. Менеджеры хотят имидж современного продукта. Разработчики хотят в резюме баззворды. Никого не волнует, что будет даже через два года. Даже через год. Дотащить до релиза и сплавить другой команде - в корпоративной среде постоянно. Или даже не дотащить до релиза, прожрать бюджет и свалить. >Зашел в кабинет, увидел девченки В какой кабинет, блин. Сейчас так никто не работает. На горизонте 5 лет никаких кабинетов с "девченками" уже не будет. >может есть смысл переложить на WEB-проект? Так появляется проект-урод, впаренный директору мальчиком-программистом, никому не нужный, работе с которым надо обучать (никому это не надо, все плюются). Какой-то привет из 2005-го года, ей богу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Утилитарные задачи веб прогр. от простого к сложному"	+/–
	Сообщение от Azudim (??), 01-Дек-22, 13:28
	> А вот наглядный пример, почему легаси ERP/CRM на перле такое гуано. Вы > не освоили ни перл, ни технологию. Обо мне вы кажется знаете даже больше, чем о ERP на Perl :) >>искать "своего" заказчика > Заказчик, который готов платить неопытному разработчику за некачественную работу, в наше > время очень редок. Либо это жлоб, которому возможность напрямую трахать мозги > программисту и низкая оплата важнее результата, либо идиот --Алло, вы программы разрабатываете? Я только сразу скажу, я идиот! --Разрабатываем, только сразу предупреждаю, у нас в штате только джуны! (это я к тому, что выяснить ху-из-ху не всегда сразу получается) > Лучше в команду пойти джуном > и за полгода обтереться, чем культивировать собственный непрофессионализм Что будет культивироваться от постоянной практики - зависит от многих факторов. Есть и self-made профессионалы, есть и коллективы, где ни то что наставника не найти, ревью то не допросишься, да и качество не сильно волнует. >> Выбирать приходится инструмент, который не "загнется" через пол года > Если бы это было так, никто бы не выбирал модные фронтенд-фреймворки. Эти фреймворки хотя бы все на JS, что плюс для резюме разработчика, а выбор какого ни будь нишевого тулкита это время потраченное напрасно.. >>Зашел в кабинет, увидел девченки > Так появляется проект-урод, впаренный директору мальчиком-программистом, никому не нужный, > работе с которым надо обучать (никому это не надо, все плюются). Не важно кто и как делал и кто как покупал, если был расчет эффективности от внедрения. Знаю массу проектов, от которых современного человека должно коробить от одного внешнего вида (управленка на MS Access с товародвижением, складами, кешфло, расчетом ЗП..), однако заказчик своевременно получил конкурентное преимущество. > Какой-то привет из 2005-го года, ей богу. А в автоматизации с тех пор что то сильно изменилось?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Утилитарные задачи веб прогр. от простого к сложному"	+/–
	Сообщение от Аноним (16), 01-Дек-22, 17:44
	> А в автоматизации с тех пор что то сильно изменилось? Так уже давно все должно быть автоматизировано. В экселе на коленке люди со времен 1С семерки ничего не делают. Если память не изменяет, уже есть облачная бухгалтерия, которая полностью автоматом отчеты делает. То есть, если бы не креатив в отчетности и мутагенез в первичной документации, бухгалтера были бы уже не нужны. >Эти фреймворки хотя бы все на JS, что плюс для резюме разработчика JS типичный разработчик под %современный JS фреймворк% знает плохо или очень плохо, цена таким резюме ноль, зеро. >выбор какого ни будь нишевого тулкита >это время потраченное напрасно Дрозофильное мышление. Изучить неважно что и успеть скачать как можно больше бабла, пока дают. Сэкономленное на изучении языков и тулкитов время (и заработанные лишние деньги) потратить на каком-нибудь пляжном курорте или просто пролежать, прожрать. В итоге, в голове меньше, карьерные перспективы меньше, при сокращениях шансы вылететь выше.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Утилитарные задачи веб прогр. от простого к сложному"	+/–
	Сообщение от Azudim (??), 01-Дек-22, 22:12
	> Дрозофильное мышление. Изучить неважно что и успеть скачать как можно больше бабла, > пока дают. Сэкономленное на изучении языков и тулкитов время (и заработанные > лишние деньги) потратить на каком-нибудь пляжном курорте или просто пролежать, прожрать. Кто то разве сказал про изучение "неважно что" ? Возьмем отчет об инфраструктуре крупного проекта (Яндекс, Ламода и т.п.), посмотрим что пишут о причинах выбора их технологий, поймем какие задачи они решают.. Посмотрим пару десятков вакансий.. и вот уже какое то представление есть.
	Ответить \| Правка \| Наверх \| Cообщить модератору