По своему опыту скажу, что даже обладая знаниями не всегда можно заставить программу делать то, что нужно. Если требуется решить задачу, выходящую за пределы «обычных» и хорошо изъезженных вопросов аля пройти собеседование (например, сортировка) очень трудно разработать сложный алгоритм, потому что результат работы сложно проверить, т.к. любому результату нельзя доверять. Если тестовые данные не совпали с результатом, то непонятно — это результат правильный, а мои тестовые данные неверны или результат неверный, а тестовые данные верны? И даже если тестовые данные совпадают с результатом, то не ошибся ли я везде — и в тестах и в алгоритме? Простите, что отвожу беседу немного в сторону, но что по этому поводу вообще можно сказать? (Как-то даже не знаю, может ли математика сказать что-то вообще? как-то всё запутано...) :)
И почему многие думают, что ИИ захочет нас убить? Может он просто ржать над нами будет постоянно? Мы ж для него тупые и может он будет про себя придумывать шутки про нас —
«Ну, человеки, ну тупые!!!»
«Слетай на Нептун, потом учи меня жить»
Надо вести себя как младенцы и убедить, что мы произошли от него и тогда он не захочет нас убивать, а захочет заботиться. :) Психология!
Я верно понял автора, что врачом, пилотом, связистом стать проще?
Ваше утверждение не совсем верно. Было бы странно так упрощённо понимать другие профессии. К тому же автор не сравнивал профессию программиста с другими. В любой области есть некий порог вхождения в профессию. И в программировании он достаточно высок безотносительно уровня вхождения в другие профессии. Думаю, что автор имел в виду именно это.
В быту и обычной жизни всё это никак не используется.
Это как посмотреть. Я вот с утра выполняю кучу процедур — погладить штаны, взять из холодильника напиток на работу, посмотреть прогноз, одеться в уличную одежду в соответствии с прогнозом, взять сумку, ключи от квартиры и машины, убедиться, что ничего не забыл (элементарная проверка CRC по количеству вещей в кармане), на выходе закрыть дверь. И так каждый день. Это и есть цикл. Да программирование оно вообще везде, только без компьютеров. Их надо просто увидеть. Так что программирование — это упорядочивание мышления, а в остальном, всё верно.
Я бы добавил, что программирование оно не как физкультура. Смог поднять 10 кг яблок, поэтому подниму и 10 кг железа и 10 кг резины и пр. А вот научился программированию на JavaScript, а вот Java придётся осваивать заново. Быстрее, конечно, чем JavaScript, но всё равно не быстро. Третий язык уже быстрее, 10-м языком можно уже за день начинать писать полноценную программу. Но пока до абитуриентов дойдёт, что мыслительный процесс, которому они учатся полгода или год на самом деле можно уложить в день пройдёт время, иногда и не один год.
Это круто! Правда!
Коллеги, меня интересует один момент. Не задумывались ли вы над таким функционалом при разработке, чтобы поиск по проекту был из одной точки? Т.е. вот есть исходный код, документация в wiki и т.д. Не пробовали объединить поиск по всему проекту? У меня, например, все проекты находятся в gitlab, много информации я выкладываю в виде html-страниц. Наверняка похожие мысли могли проскакивать?
Коллеги, не забыли про документацию к программе? Наверное раздел «Разработчику» идеально надо писать сразу после первого удачного запуска самой первой версии приложения и поддерживать её на уровне, чтобы любой новый разработчик мог её у себя запустить самостоятельно, а то нарушается п.9.
Что-то я не понял. Если рассматривать бесплатный софт как альтернатива платному, то бесплатный выигрывает в любом случае, даже если он импортный? Ну запретят покупать MSOFFICE (вот больше запретить нечего?), и народ станет ставить Libre (предположим, что с совместимостью всё ок), он же всё равно импортный? В чём подвох?
у меня нет, мне больше 40. maven, grunt, bower, chrome dev, linux/make install — небольшой перечень инструментов, которые я использую каждый день ну или через день. Без них как без рук. Без работы не сижу.
Экономическое обоснование автоматизации — сокращение затрат, а не целевое сокращение затрат именно на персонал. Кроме того есть задачи, которые без автоматизации вообще были бы не выполнимы.
Взгляните на ситуацию с другой стороны. Устроились вы в фирму на работу, а фирма только благодаря ранее внедрённой автоматизации и расширила свой штат, благодаря чему вы и попали в данном примере на работу. А до этого долго её искали. Жалоб нет?
Далее. Таких ситуаций в истории человечества было много. Когда в Китае прокладывали железные дороги несколько сотен тысяч носильщиков лишились работы. В Англии во время промышленной революции были забастовки ткачей. Так что СЭД — далеко не первая и уж точно не самая большая волна поводов для сокращений. Но именно благодаря промышленной революции и железной дороге в Китае сегодня имеем производство iphone в Китае. Результат-то хороший получился?
Иногда стоит задуматься что-то поменять в жизни. И если вы уйдёте, а СЭД не будет внедряться у вас на работе, вы работодателя же жалеть не будете, что ему может быть тяжело без вас, как без специалиста :)
Ну зато маленькие организации и разваливаются быстрее и СЭД их не спасёт. Зато если будет разваливаться крупная, то можно успеть выйти на пенсию, а она всё ещё тонет.
Мне кажется, что программисты вообще должны больше всех бояться автоматизации, которая автоматизирует их работу. Но что-то я не наблюдаю такого, чтобы все программисты вдруг возмутились и сказали — мы не будем пользоваться средствами автоматизации, потому что это сокращает наши рабочие места. Наоборот — программисты в целом стали работать гораздо быстрее и эффективнее.
>> Это касается не только СЭД, но и автоматизации процессов вообще.
Ну, а на вредных производствах автоматизация необходима.
Автоматизация предполагает более быстрое выполнение уже устоявшихся бизнес-процессов, но за этим ускорением для бизнеса всегда открывается новое поле деятельности и если бизнес построен грамотно, то тут либо увеличение ФОТ, либо новые рабочие места. Это суть прогресса. Лично я за автоматизацию.
Как это не понадобятся??? А работать кто будет? Работа же не из входящих/исходящих писем состоит? СЭД должен упростить документооборот, но не отменить работу!?
А по мне так дело не в прозрачности работы, потому что можно сделать прозрачным и левак, но только для своих. Система безопасности должна это обеспечить. Просто надо делать программу для человека и чтобы программа способствовала сплочению людей, а так получается, что человек должен думать, как удовлетворить программу, а не получает удовольствия от того, что программа удовлетворяет его. Поэтому СЭД в таком виде не очень хорош, потому что заставляет человека расходовать очень ценный ресурс — напрягать мозг, где раньше можно было обойтись без напряжения извилин. Бюрократия не должна напрягать мозг, она должна сама понимать, что он неё нужно.
Вот если бы было так — даёшь СЭДу файл, а она уже сама его проанализирует и подскажет, что «кажется — этот файл является письмом, зарегистрировать его как входящее?» или «Это письмо похоже на ответ на другое входящее. Зарегистрировать это как исходящее и отправить Петру Иванычу?» Вот это было бы круто, а так я должен вспомнить, какие классификации действий в моей СЭД есть, и сколько раз я должен нажать мышкой, чтобы в итоге дождаться того диалогового окна, в который я смогу загрузить файл, но не сразу, а пока не назначу исполнителя, не выберу какого-нибудь заместителя исполнителя и не напишу комментарий «после дождичка в четверг». Простите, коллеги, но такой СЭД, нам, пользователям, не нужен. ) Мы хотим тот СЭД, который нас, пользователей, понимает и старается предугадать наши действия.
Из личных ощущений — лично мне хочется, чтобы какое-либо действие в СЭД можно было бы выполнить перед исполнением желания пойти налить себе кофейку. Например, мой срез по мыслям:
— а не пойти ли налить кофейку, мистер Фикс?
— одну секундочку, мистер Фикс, только документ на согласование отправлю?
И пойти налить себе кофе, а не налить себе кофе, чтобы за чашкой кофе отправить документ на согласование.
У меня два соображения на этот счет:
1. Если тому человеку видится, как переписать тот легаси код на scala и видится, что это просто — пусть покажет пример простого переписывания какой-нибудь функции по вашему выбору на скала.
2. Со времен написания легаси кода скорее всего много воды утекло, и даже может быть сильно изменились всякие компоненты и модули. Если взглянуть на тот код по крупному, то можно поискать более совершенные фреймворки для того легаси кода, чтобы переписать его с минимальным напрягом? Иногда можно сделать новую структуру и даже лучше старой.
А по крупному — ну ведь работает же? Это самое главное! Так что вы должны настаивать, что имеете права выбора, вам же работать.
Спасибо за gridmanager. Три месяца назад просто замучился настраивать форму с 50-ю полями для ввода (внутрикорпоративная форма резюме). Тогда так и не смог найти внятного инструмента, теперь есть. А впереди интеграция с 1С…
Для моего случая надо было немного доработать это решение. В проекте Windows.Form есть зависимость от WPF (Проект не чистый WPF). Может кому пригодиться, поэтому оставлю это здесь:
Здесь «технология разработки ПО», а не «технологии в программировании».
Выработка тербований, проектирование, документирование, поддержка, само написание кода — все входит в «процесс разработки ПО»
И что из перечисленного вами не должен делать программист или другой участник команды, который имеет отношение к коду? По мне так даже программист должен словами написать в коммите, что он закодировал, а ещё лучше писать документацию, что сделано. Это можно делать в конце дня и это не занимает больше 10-15 минут времени в день. А другим проще будет понять, что делает сосед. Всё-таки программы пишутся для людей и именно другие люди должны понимать, что сделано.
Но то что вы описали про сборку/репозитории — это совсем из другой оперы
Все слова и договорённости должны каким-то образом учитываться в коде и попадать в сборку. Или нет?
«Ну, человеки, ну тупые!!!»
«Слетай на Нептун, потом учи меня жить»
Надо вести себя как младенцы и убедить, что мы произошли от него и тогда он не захочет нас убивать, а захочет заботиться. :) Психология!
Ваше утверждение не совсем верно. Было бы странно так упрощённо понимать другие профессии. К тому же автор не сравнивал профессию программиста с другими. В любой области есть некий порог вхождения в профессию. И в программировании он достаточно высок безотносительно уровня вхождения в другие профессии. Думаю, что автор имел в виду именно это.
Это как посмотреть. Я вот с утра выполняю кучу процедур — погладить штаны, взять из холодильника напиток на работу, посмотреть прогноз, одеться в уличную одежду в соответствии с прогнозом, взять сумку, ключи от квартиры и машины, убедиться, что ничего не забыл (элементарная проверка CRC по количеству вещей в кармане), на выходе закрыть дверь. И так каждый день. Это и есть цикл. Да программирование оно вообще везде, только без компьютеров. Их надо просто увидеть. Так что программирование — это упорядочивание мышления, а в остальном, всё верно.
Я бы добавил, что программирование оно не как физкультура. Смог поднять 10 кг яблок, поэтому подниму и 10 кг железа и 10 кг резины и пр. А вот научился программированию на JavaScript, а вот Java придётся осваивать заново. Быстрее, конечно, чем JavaScript, но всё равно не быстро. Третий язык уже быстрее, 10-м языком можно уже за день начинать писать полноценную программу. Но пока до абитуриентов дойдёт, что мыслительный процесс, которому они учатся полгода или год на самом деле можно уложить в день пройдёт время, иногда и не один год.
Коллеги, меня интересует один момент. Не задумывались ли вы над таким функционалом при разработке, чтобы поиск по проекту был из одной точки? Т.е. вот есть исходный код, документация в wiki и т.д. Не пробовали объединить поиск по всему проекту? У меня, например, все проекты находятся в gitlab, много информации я выкладываю в виде html-страниц. Наверняка похожие мысли могли проскакивать?
Это аксиома! Только так и начинаю новую работу.
Это отличная формулировка и не только в IT.
Коллеги, не забыли про документацию к программе? Наверное раздел «Разработчику» идеально надо писать сразу после первого удачного запуска самой первой версии приложения и поддерживать её на уровне, чтобы любой новый разработчик мог её у себя запустить самостоятельно, а то нарушается п.9.
Экономическое обоснование автоматизации — сокращение затрат, а не целевое сокращение затрат именно на персонал. Кроме того есть задачи, которые без автоматизации вообще были бы не выполнимы.
Взгляните на ситуацию с другой стороны. Устроились вы в фирму на работу, а фирма только благодаря ранее внедрённой автоматизации и расширила свой штат, благодаря чему вы и попали в данном примере на работу. А до этого долго её искали. Жалоб нет?
Далее. Таких ситуаций в истории человечества было много. Когда в Китае прокладывали железные дороги несколько сотен тысяч носильщиков лишились работы. В Англии во время промышленной революции были забастовки ткачей. Так что СЭД — далеко не первая и уж точно не самая большая волна поводов для сокращений. Но именно благодаря промышленной революции и железной дороге в Китае сегодня имеем производство iphone в Китае. Результат-то хороший получился?
Иногда стоит задуматься что-то поменять в жизни. И если вы уйдёте, а СЭД не будет внедряться у вас на работе, вы работодателя же жалеть не будете, что ему может быть тяжело без вас, как без специалиста :)
Мне кажется, что программисты вообще должны больше всех бояться автоматизации, которая автоматизирует их работу. Но что-то я не наблюдаю такого, чтобы все программисты вдруг возмутились и сказали — мы не будем пользоваться средствами автоматизации, потому что это сокращает наши рабочие места. Наоборот — программисты в целом стали работать гораздо быстрее и эффективнее.
>> Это касается не только СЭД, но и автоматизации процессов вообще.
Ну, а на вредных производствах автоматизация необходима.
Автоматизация предполагает более быстрое выполнение уже устоявшихся бизнес-процессов, но за этим ускорением для бизнеса всегда открывается новое поле деятельности и если бизнес построен грамотно, то тут либо увеличение ФОТ, либо новые рабочие места. Это суть прогресса. Лично я за автоматизацию.
Вот если бы было так — даёшь СЭДу файл, а она уже сама его проанализирует и подскажет, что «кажется — этот файл является письмом, зарегистрировать его как входящее?» или «Это письмо похоже на ответ на другое входящее. Зарегистрировать это как исходящее и отправить Петру Иванычу?» Вот это было бы круто, а так я должен вспомнить, какие классификации действий в моей СЭД есть, и сколько раз я должен нажать мышкой, чтобы в итоге дождаться того диалогового окна, в который я смогу загрузить файл, но не сразу, а пока не назначу исполнителя, не выберу какого-нибудь заместителя исполнителя и не напишу комментарий «после дождичка в четверг». Простите, коллеги, но такой СЭД, нам, пользователям, не нужен. ) Мы хотим тот СЭД, который нас, пользователей, понимает и старается предугадать наши действия.
Из личных ощущений — лично мне хочется, чтобы какое-либо действие в СЭД можно было бы выполнить перед исполнением желания пойти налить себе кофейку. Например, мой срез по мыслям:
— а не пойти ли налить кофейку, мистер Фикс?
— одну секундочку, мистер Фикс, только документ на согласование отправлю?
И пойти налить себе кофе, а не налить себе кофе, чтобы за чашкой кофе отправить документ на согласование.
1. Если тому человеку видится, как переписать тот легаси код на scala и видится, что это просто — пусть покажет пример простого переписывания какой-нибудь функции по вашему выбору на скала.
2. Со времен написания легаси кода скорее всего много воды утекло, и даже может быть сильно изменились всякие компоненты и модули. Если взглянуть на тот код по крупному, то можно поискать более совершенные фреймворки для того легаси кода, чтобы переписать его с минимальным напрягом? Иногда можно сделать новую структуру и даже лучше старой.
А по крупному — ну ведь работает же? Это самое главное! Так что вы должны настаивать, что имеете права выбора, вам же работать.
Для моего случая надо было немного доработать это решение. В проекте Windows.Form есть зависимость от WPF (Проект не чистый WPF). Может кому пригодиться, поэтому оставлю это здесь:
В проект добавил references:
System.Reflection;
System.Globalization;
System.IO;
В код нужно добавить ссылки:
using System.Reflection;
using System.Globalization;
using System.IO;
немного изменил метод Main:
И что из перечисленного вами не должен делать программист или другой участник команды, который имеет отношение к коду? По мне так даже программист должен словами написать в коммите, что он закодировал, а ещё лучше писать документацию, что сделано. Это можно делать в конце дня и это не занимает больше 10-15 минут времени в день. А другим проще будет понять, что делает сосед. Всё-таки программы пишутся для людей и именно другие люди должны понимать, что сделано.
Все слова и договорённости должны каким-то образом учитываться в коде и попадать в сборку. Или нет?