Самой высокооплачиваемой профессий на удаленке в России является программист-аналитик 1С, работодатели готовы платить до 270 тыс. рублей в месяц, следует из исследования сервиса Работа.ру.
Программист-аналитик? Это примерно как доярка-тракторист. Две профессии в одной.
Напротив, Сергей. Сейчас понятие "программист" весьма узкоспециализировано. И если сравнивать разработку ПО с приемом стоматолога, то один специалист должен осматривать полость рта, второй сверлить зуб, третий пломбировать, четвертый собирать анамнез у пациента, пятый вести записи в медицинской карте. Очень эффективно, и главное, обеспечивается полная занятость. Пациент, правда, финансово ...
Напротив, Сергей. Сейчас понятие "программист" весьма узкоспециализировано. И если сравнивать разработку ПО с приемом стоматолога, то один специалист должен осматривать полость рта, второй сверлить зуб, третий пломбировать, четвертый собирать анамнез у пациента, пятый вести записи в медицинской карте. Очень эффективно, и главное, обеспечивается полная занятость. Пациент, правда, финансово страдает, но мы ему объясним, что это такая современная суперпупертехнология. Скоро появятся специалисты по сверлению зубов в верхней челюсти, по сверлению зубов в нижней челюсти, по открыванию дверей и проветриванию окон. Главное, чтобы финансы на это выделяли.
С П, увы, не закончила. Уж не знаю, хорошо это для тебя или плохо. Вот, сижу, занимаюсь пожарной разработкой в сроки, за которые никто не берется, поскольку все разводят руками и ничего не понимают, и только объяснить команде, как что должно работать, и почему -- это одна-две недели. А принимать решение о разработке, проектировать программу, разрабатывать и сдавать готовый продукт заказчику у меня ...
С П, увы, не закончила. Уж не знаю, хорошо это для тебя или плохо. Вот, сижу, занимаюсь пожарной разработкой в сроки, за которые никто не берется, поскольку все разводят руками и ничего не понимают, и только объяснить команде, как что должно работать, и почему -- это одна-две недели. А принимать решение о разработке, проектировать программу, разрабатывать и сдавать готовый продукт заказчику у меня было всего несколько дней.
С Π, во вторник -- обнаружена аварийная обработка на некоторых цепочках документов, за среду-четверг я проанализировала проблему у заказчика, запустила два решения -- быстрое, в качестве "обходного пyти", и более качественное, уже в составе продукта, выдала пять дополнительных задач на разработку, сформулировав и скомпоновав технические требования для достижения нужных мне результатов, и ...
С Π, во вторник -- обнаружена аварийная обработка на некоторых цепочках документов, за среду-четверг я проанализировала проблему у заказчика, запустила два решения -- быстрое, в качестве "обходного пyти", и более качественное, уже в составе продукта, выдала пять дополнительных задач на разработку, сформулировав и скомпоновав технические требования для достижения нужных мне результатов, и взяла одну исследовательскую задачу на себя, потому что за нее все равно никто в такие сроки не возьмется.
В результате у меня в пятницу утром обходной пyть был готов, сегодня установлен у заказчика. Угадай, что мне выдали по 5 задачам, при условии, что разработчик далеко даже не старшее звено, а специалист очень высокого уровня. В воскресенье было прорешано, но не полностью протестировано две из них, возникли вопросы. Мы их обсуждали по телефону. Разумеется, у заказчика таких сроков нет, и сегодня я уже на свой страх и риск закинула наскоро разработанный "обходной". Небольшую корректировку делала "на живую". Все работает.
Теперь жду остальное для более качественного решения, но основной пожар потушен.
Давай, валяй про преимущества специализации разработчиков.
Dark Night, Я сам программист с 20 летним стажем. Конечно можно ностальгировать по временам когда везде был один только Фортран с Алголом. Но в настоящее время слишком много технологий в этой отрасли накопилось. Всё их в одной голове удержать просто невозможно. Есть конечно fullstack'и но и они далеко не full. так что напрасно вы....
Dark Night, Вы берёте узкий круг задач, которыми занимаетесь именно вы. А как одному спецу разобраться в трёхзвенных структурах? Где есть процедуры в БД, есть код на сервере приложений и есть код на скрипте для броузера? Конечно это возможно, но такие спецы как правило знают вообще, но в каждой конкретной области слабее узких специалистов. Потому и набираются команды и разрабатываются API, ...
Dark Night, Вы берёте узкий круг задач, которыми занимаетесь именно вы. А как одному спецу разобраться в трёхзвенных структурах? Где есть процедуры в БД, есть код на сервере приложений и есть код на скрипте для броузера? Конечно это возможно, но такие спецы как правило знают вообще, но в каждой конкретной области слабее узких специалистов. Потому и набираются команды и разрабатываются API, для общения между подсистемами.
Сергей, я прекрасно понимаю проблематику сегодняшней разработки, хотя в полной мере в технологии и не участвую. Действительно, технологий на сегодня существует даже слишком много. Но находясь вне технологической цепочки, я вижу ее тотальную неэффективность, которая держится исключительно на западных высокооплачиваемых традициях. Как только перестанут плaтить сверхдоходы, руководство IT-фирм будет вынуждено ...
Сергей, я прекрасно понимаю проблематику сегодняшней разработки, хотя в полной мере в технологии и не участвую. Действительно, технологий на сегодня существует даже слишком много. Но находясь вне технологической цепочки, я вижу ее тотальную неэффективность, которая держится исключительно на западных высокооплачиваемых традициях. Как только перестанут плaтить сверхдоходы, руководство IT-фирм будет вынуждено сокращать штат втрое. Вот тогда и начнут плaтить кадрам, которые задачу видят в целом, вглубь и вширь, а линейные программисты будут вынуждены не только свой код знать, но и как минимум иметь представление о том, что делается в соседних рабочих группах, и сносно знать то, что делается в их группе. А также хоть на каком-то уровне владеть смежными стеками.
Я встречала разных специалистов разной квалификации. Если под термином "слабее" понимать "знают меньше стандартных библиотек", то соглашусь, это так. А вот если понимать умение писать программу, а не кодить код -- то не соглашусь категорически. И когда такие программисты задают вопрос, почему у них программа не работает, то я их просто прошу показать текст. И, не зная язык в деталях, не имея представлений о вызываемых библиотеках и их функционале, я четко поясняю, откуда может возникнуть ошибка, где она может находиться, а если мне дают код детально, то показываю место ошибки и говорю, как ее можно исправить. Это касается и скриптового кода, и кода сервера, и баз данных, и файловых структур, и многих других элементов информационных систем (документов, таблиц, изображений, схем и проч.
Резонно задать вопрос: а если меня посадить за проектирование, смогу ли я заменить разработчика? Я знаю ответ. Когда нам нужно было разработать информационную систему на уровне прототипа с нуля за 2 месяца, а выдать продукт за 5 месяцев, и у нас не было ничего, даже технического задания, и у меня в команде был только один разработчик, все, что я спросила -- на каком языке пишешь и в какой СУБД ты хорошо ориентируешься? Взяла книгу, через 2 недели знала язык, через 4 было готово основное алгоритмическое ядро системы, проект был сдан в срок. Работали вдвоем, разбив задачу крупноблочно, и помогая друг другу в случае проблем.
Кстати, Сергей. Летом пришлось писать заплатку для информационной системы -- ну не было возможности сделать все нормально и вовремя, а результат требовался. Я потом для интереса подсчитала -- использовала 5 различных языков. Некоторые из которых впервые вижу.
Dark Night, Это конечно здорово, но вот например JAVA, без которой WEB приложения сейчас просто невозможны. Там крайне высок уровень вхождения. Как минимум 2-3 года. Если кто говорит, что меньше - плюньте ему в рожу. Да и чтобы эффективно писать на SQL надо как минимум пару-тройку лет опыта. Иначе такое получается, что волосы дыбом встают.
Сергей, программирование, как и любая инженерная специальность, требует опыта. Я с этим не спорю. Никогда не измеряла, сколько лет я знакома с тем или иным языком и на каком уровне. В языке Java не писала, ничего принципиально нового в нем не заметила; будет необходимость -- придется писать и на Java. Кстати, насчет SQL. Если бы не повсеместная тяга бизнес-кошельков к созданию своих диалектов SQL, ...
Сергей, программирование, как и любая инженерная специальность, требует опыта. Я с этим не спорю. Никогда не измеряла, сколько лет я знакома с тем или иным языком и на каком уровне. В языке Java не писала, ничего принципиально нового в нем не заметила; будет необходимость -- придется писать и на Java. Кстати, насчет SQL. Если бы не повсеместная тяга бизнес-кошельков к созданию своих диалектов SQL, можно было бы написать вполне неплохой портируемый язык. А так он превращается в очередной набор бессмысленных заклинаний, каждое из которых будет интерпретировано платформой (причем одного и того же производителя) по-своему.
Dark Night, ANSI по SQL поддерживает любая БД. Проcто не пользуйтесь плюшками конкретной реализации и будет вам счастье. В джаве принципиально нового не так много, но тем не менее имеет место быть ))). Только вот сам язык мёртв без библиотек. А там их до какой то матери. И освоить даже минимальный набор требует значительного времени.
Dark Night, Команды SQL написанные по стандарту ANSI, работают правильно на любой БД. Эффективность выполнения конечно будет разная, но результат одинаковый гарантирован.
Сергей, ну нет же. Не работают одинаково. Начиная с элементарной кодировки текста/бинарных вставок, и заканчивая методами планирования запроса, способами обхода результатов и многим другим.
И, наконец, ну какое же это счастье -- писать на голом SQL? И это с размерами сегодняшних баз и нынешними задачами по обработке данных? Это все равно что сегодня писать программы на Basic 80-х годов: вроде как ...
Сергей, ну нет же. Не работают одинаково. Начиная с элементарной кодировки текста/бинарных вставок, и заканчивая методами планирования запроса, способами обхода результатов и многим другим.
И, наконец, ну какое же это счастье -- писать на голом SQL? И это с размерами сегодняшних баз и нынешними задачами по обработке данных? Это все равно что сегодня писать программы на Basic 80-х годов: вроде как и Print есть, и циклы как бы в наличии, а развернуться негде.
Методики доступа к данным безнадежно устарели, не отвечают сегодняшним реалиям. Ничего принципиально нового не предлагается, потому что реляционная алгебра была разработана в 70-х годах и с тех пор никакие фундаментальные исследования не проводились, а коммерческие компании в таких исследованиях не заинтересованы.
Все базы данных сегодня вынужденно так или иначе падают на реляционную модель, а единичные наработки отдельных разработчиков по другим типам моделей только подчеркивают ужасающую бедность инструментария обработки и хранения данных.
Немного знакома с JS. Довольно легкий в изучении, но я в нем не нашла изюминку. Наши спецы говорят, что на сегодня это наиболее полный по охвату язык. Разбираться некогда, верю им на слово. =))
Dark Night, JS лёгкий в изучении? ну-ну. Там новые технологии чуть ли не каждую неделю появляются. С первого взгляда он конечно лёгкий. А потом программер , привыкший к строгим языкам, начинает матом разговаривать и надолго. Так что не верьте.
Dark Night, Тем больше я с вами общаюсь, тем более убеждаюсь, что в БД вы, мягко говоря, не очень. На реляционных БД всё оптимизировано для максимальной производительности доступа к данным. И в этом случае простые запросы - самое оно. Если вам мало, берите ОРМ и пользуйтесь, там функционал - закачаешься, но на производительность тогда не жалуйтесь ))) ОРМ такие запросы генерирует порой, ...
Dark Night, Тем больше я с вами общаюсь, тем более убеждаюсь, что в БД вы, мягко говоря, не очень. На реляционных БД всё оптимизировано для максимальной производительности доступа к данным. И в этом случае простые запросы - самое оно. Если вам мало, берите ОРМ и пользуйтесь, там функционал - закачаешься, но на производительность тогда не жалуйтесь ))) ОРМ такие запросы генерирует порой, что волосы дыбом встают.
Сергей, получается, Вы не слышали о нереляционных базах и моделях данных? Самый простой современный пример -- XML/XSD/XSLT. Из более старых, но известных примеров -- Windows Registry. И таких примеров очень много.
Dark Night, Я про это прекрасно слышал, только вот для высоконагруженных систем с развитой бизнеслогикой внутри БД это всё не катит от слова вообще. Уж поверьте человеку, которые на таких сисnемах работает очень давно )))
Все зависит от задачи. Я видела немало реализаций, где реляционная СУБД была подключена потому, что: а) все так делают; б) так работает быстрее; в) а какие еще бывают? г) у нас нет других разработчиков; д) да какая разница. А бизнес-логику делать на SQL -- это должна быть достаточно примитивная логика, которая, например, может быть реализована на уровне хранимых процедур. Можно, конечно. Но далеко ...
Все зависит от задачи. Я видела немало реализаций, где реляционная СУБД была подключена потому, что: а) все так делают; б) так работает быстрее; в) а какие еще бывают? г) у нас нет других разработчиков; д) да какая разница. А бизнес-логику делать на SQL -- это должна быть достаточно примитивная логика, которая, например, может быть реализована на уровне хранимых процедур. Можно, конечно. Но далеко не всегда.
Основное преимущество реляционной модели -- способность быстро работать с небольшими атомарными значениями, в частности, числами, которые находятся в большом количестве однородных кортежей. Для обработки текста или иных объектов (например, графики, геоданных) она не подходит, и для таких задач создаются специальные расширения. Для обработки разных по структуре объектов не подходит совершенно, -- какие только кульбиты не совершают разработчики ради унификации своих данных под правила реляционной модели!
Если хотите пример, где от реляционной БД остаются рожки да ножки -- пожалуйста: текстовые запросы пользователей. Скажем, Яндекс (немаленькая такая организация, не с одним лишь неттопом на обработке данных) пользуется нереляционной базой данных для обработки и хранения сведений запросов, построения портретов пользователей, назначения контекстной рекламы.
Dark Night, Насчёт примитивной логики. Спасибо, смешно. Это только лишний раз говорит о вашей некомпетентности в БД. Всё что можно реализовать на сервере приложений можно реализовать и на БД в хранимых процедурах. Только в разы быстрее работать будет. Я работал достаточно долго как фулстэк и могу сравнивать вполне компетентно. А по текстовому поиску, то тот же ПГ по неявным совпадениям по ...
Dark Night, Насчёт примитивной логики. Спасибо, смешно. Это только лишний раз говорит о вашей некомпетентности в БД. Всё что можно реализовать на сервере приложений можно реализовать и на БД в хранимых процедурах. Только в разы быстрее работать будет. Я работал достаточно долго как фулстэк и могу сравнивать вполне компетентно. А по текстовому поиску, то тот же ПГ по неявным совпадениям по триграммам работает не медленнее того же эластика например. Только мало кто об этом знает. Я же в основном говорю о тяжёлых высоконагруженных приложениях для корпоративного учёта. Ту пока альтернативы реляционным БД просто нет.
Dark Night, насчёт того ,что реляционные СУБД не подходят для графики или геоданных расскажите Ораклу. Поднимите им настроение. Пусть от души посмеются люди. Чтобы построить грамотную реляционную модель нужен профессионал, которых просто мbзерно мало на фоне тех, кто научился делать left join и уже считает себя профи по SQL. А кульбиты все от неграмотности и низкого профессионализма.
Сергей, есть предложение сбавить тон. У меня нет желания превращать тему непонятно во что. Если обсуждаем, то обсуждаем. Если хочется добавить эмоций, это не ко мне, у меня на это времени нет. Работы хватает.
Миллион раз про самые разные системы слышала о том, что "на этом языке можно реализовать всё". Ну, реализуйте обход сильно разветвленного графа, например, средствами хранимых процедур. ...
Сергей, есть предложение сбавить тон. У меня нет желания превращать тему непонятно во что. Если обсуждаем, то обсуждаем. Если хочется добавить эмоций, это не ко мне, у меня на это времени нет. Работы хватает.
Миллион раз про самые разные системы слышала о том, что "на этом языке можно реализовать всё". Ну, реализуйте обход сильно разветвленного графа, например, средствами хранимых процедур. Или обеспечьте матмоделирование движения объектов в реальном времени. Кстати, за счет чего будет быстрее работать? Что сервер мощнее рабочей станции? Так в этом случае и не один запрос будет, а тысяча, например. Со всех рабочих станций одновременно. И это преимущество по мощности мгновенно становится недостатком.
Не вопрос, пусть Оракл смеется. Но Вам бы стоит читать мои сообщения внимательнее. Обработка изображений и геоданных (а также аудио- и видеоданных и многого другого) обеспечивается не собственно SQL-технологией, а дополнительными специальными расширениями, например, ArcGIS, где работает совсем другая платформа, а SQL ей нужен как пятому колесу нога, обеспечивая транспорт "запрос-табличный ответ", и никоим образом не участвуя в расчете результата.
Что касается профессионалов, то они нужны везде. И если Вам когда-нибудь захочется реализовать тот же граф или дерево на SQL-технологии, то после долгих мытарств Вы ее проклянете. Не вопрос, есть расширения типа Graph. Но у них есть и ограничения. И как только Вы упираетесь в ограничения, то Вам придется переписывать все своими руками.
Dark Night, Ещё раз. SQL и вообще реляционные СУБД предназначены для быстрого поиска и обработки структурированных связанных данных. Да это не везде применимо. Но в корпоративных системах учёта ,которых на рынке более 50 процентов от всех программных систем, они просто незаменимы. Я работаю именно на этом рынке. Если вы работаете на другом, то это не повод обвинять реляционные СУБД и SQL ...
Dark Night, Ещё раз. SQL и вообще реляционные СУБД предназначены для быстрого поиска и обработки структурированных связанных данных. Да это не везде применимо. Но в корпоративных системах учёта ,которых на рынке более 50 процентов от всех программных систем, они просто незаменимы. Я работаю именно на этом рынке. Если вы работаете на другом, то это не повод обвинять реляционные СУБД и SQL во всех грехах. Всему своё место. Просто не надо обобщать. Кстати в тех же колончатых БД используется по сути тот же самый SQL, хотя область применения таковых вообще другая. Переписывать не надо. )) Надо сразу выбирать наиболее подходящий инструментарий. )) Вот для этого и нужны профессионалы и желательно широкого профиля.
Для большинства систем учета -- согласна. И в голову не приходило в чем-то обвинять SQL, это хороший инструмент, но со своей областью применения, которую часто приходится неспецифически расширять.
Кстати, вопрос как к специалисту. Как в современных системах решается вопрос хранения несбалансированных древовидных структур? Простые примеры -- дерево товаров, дерево клиентов, дерево сотрудников. ...
Для большинства систем учета -- согласна. И в голову не приходило в чем-то обвинять SQL, это хороший инструмент, но со своей областью применения, которую часто приходится неспецифически расширять.
Кстати, вопрос как к специалисту. Как в современных системах решается вопрос хранения несбалансированных древовидных структур? Простые примеры -- дерево товаров, дерево клиентов, дерево сотрудников. Не просто сохранить через ссылки "сами на себя", а иметь возможность эффективным SQL-запросом получать доступ к любой ветви или любому листу дерева. Не выходя за рамки реляционных таблиц, т.е. "json в ячейке" или "xml в ячейке" не подходит.
Dark Night, есть специальные инструменты для хранения графов, но с ними близко не сталкивался. В подобных инструментах обычно всё хорошо, если не приходится изменять что-то в середине дерева. То есть, если это системы просто накапливающие информацию, но без изменения уже существующей. В общем нет в жизни абсолютного счастья. ))) А для изменяемых данных и по быстрому поиску в них самое то ...
Dark Night, есть специальные инструменты для хранения графов, но с ними близко не сталкивался. В подобных инструментах обычно всё хорошо, если не приходится изменять что-то в середине дерева. То есть, если это системы просто накапливающие информацию, но без изменения уже существующей. В общем нет в жизни абсолютного счастья. ))) А для изменяемых данных и по быстрому поиску в них самое то колончатые БД. Но там уже никаких процедур внутри БД. Вообще. Только запросы.
подробнее
подробнее
подробнее
подробнее
подробнее
подробнее
подробнее
подробнее
подробнее
подробнее
подробнее
подробнее
подробнее
подробнее