По всей видимости, это будет (или уже есть) тенденция, создавать кадры. Я вот знаю ИТ контору в самой что ни на есть «глубинке», которая занимается доп.образованием на базе школы и университета — готовит себе кадры. Для школьников это вообще бесплатно, а студенты подписывают договор вида «или плати, или отработай на нас 3 года после выпуска».
Крупные предприятия, сохранившиеся с советских времён, занимаются примерно тем же. В вузах есть такая вещь, «целевой набор» называется. И спецкурсы, которые ведут сотрудники заинтересованного предприятия.
И на них глядючи, я думаю, что от государства здесь требуется только не мешать. Бизнес, нуждающийся в кадрах, вполне способен их воспитать.
и пишет программу для РЕАЛЬНОЙ задачи, а не «олимпиадное программирование», где – стыдно сказать – качество оформления кода программы важнее её работоспособности!
Во-первых, к распространённым олимпиадам по программированию это не относится, там считается ровно наоборот. И это часто называют главной проблемой спортивного программирования. Хотя я допускаю, что бывают какие-нибудь местячковые олимпиады, где кто-то смотрит в код
Во-вторых, по опыту, в «индустриальном программировании» дело именно так и обстоит: качество оформления кода важнее работоспособности. Потому что работоспособность проверит отдел QA и вернёт на доработку, это одноразовая процедура. А от качества кода зависит стоимость дальнейшей поддержки, это по эн человеко-дней за каждый год жизни продукта.
Ну, я может немного утрирую, но в целом оно так.
Наиболее опытные из моих коллег в таких случаях на вопрос ПМа «прошу оценить трудоёмкость и сроки» отвечают: «на оценку трудоёмкости потребуется 2ч.д, приступить смогу на следующей неделе.»
Можно читать технические книги или статьи в блогах в обеденный перерыв или в транспорте по пути на работу.
Ало, а почему же вместо этого в обеденный перерыв не навестить ребёнка в детском саду!? :) Улыбнуло: вечером увлекаться программированием плохо, а в обеденный перерыв самое то.
Гипотеза: это связано через переключение задач при исполнении на одном ядре. Предиктор, скорее всего, анализирует набор инструкций, которые сейчас в конвейере процессора (если бы он читал инструкции прямо из ОЗУ, он был бы слишком тормозным). А когда происходит переключение задач, конвейер процессора сбрасывается (по крайней мере раньше так было, думаю что и сейчас так же). Соответственно, если задачи часто переключаются, то в среднем команд в конвейере меньше, и у предиктора меньше данных для работы, и он хуже работает. Зато, если предиктор особо умный, то он может своей эффективностью компенсировать снижение производительности от частого переключения задач.
ошибка у них была все-таки в системном проектировании и управлении качеством, а не в коде.
Не совсем так. Ошибка в коде, конечно, была (плохая обработка исключительной ситуации — это ошибка). Другое дело, что при современных подходах к коммерческой разработке ПО ошибки в коде принято рассматривать не как ОШИБКИ, а как допуски. Ну вот токарный станок делает шайбы с допуском в 0.1мм, а иногда получаются с допуском в 0.2мм — это никого не смущает, просто есть контроль качества и плохие шайбы выкидывают или допиливают напильником. Так же и с ошибками в коде: ну ладно, забыл программист на null проверить, подумаешь. Тестировщики нашли, программист поправил, продукт зарелизили, все довольны. Вот если тестировщики не нашли — вот это уже проблема: это значит что либо плохо тестировали, либо плохо объяснили тестировщикам требования, против которых надо тестировать, либо изначально требования не так сформулировали… короче да, с точки зрения современной софтверной индустрии — проблема в процессе / управлении качеством.
А вот какие подходы к управлению разработкой / управлению качеством в космической отрасли, тем более какими они были в бородатом 1996 — я не знаю; допускаю, что по меркам современной софтверной индустрии подходы дедовские, т.к. отрасль скорее всего очень консервативная. Если там, как в древнем софтостроении (или как в мелких стартапах сегодня) — «тестировщики? какие тестировщики?» — то ответственность за соответствие софта требованиям лежит только на программистах, т.к. больше просто не на ком.
Если транзакция прошла с 3DS-аутентификацией, то действительно, оспорить её очень сложно. Но и подделка 3DS-аутентификации сложна: надо перехватывать sms-ки или что-нибудь в этом духе.
Зато, если у вас на карточке включена подписка на 3DS, и по ней как-то провели транзакцию без 3DS — диспут однозначно разрешается в вашу пользу, сумма транзакции и все неустойки ложатся на торговца.
Вообще-то по-хорошему эта статья должна бы иметь в конце предложение альтернативы и доводы, почему она лучше.
Я несколько альтернатив видел (в разной степени), и ни про одну не могу сказать что она лучше чем текст:
* UML и другие воплощения идеи «а давайте у нас менеджеры будут программировать диаграммами». Коротко говоря: ужасно. Причин несколько: 1) менеджеры это не программисты, 2) утечка абстракций, 3) проприетарные закрытые ни с чем не совместимые форматы данных и средства разработки, 4) широко распространённые средства работы с исходниками (sed/grep/diff/merge итд) не работают с этими форматами, 5) итд. В общем, это скорее средства для попила бюджетов, чем для программирования.
* Исходники на каком-нибудь DSL (хорошо если основанном на чём-то широко известном), снабжённые метаинформацией и вместе с ней хранимые в XML. Т.е. вместо просто имени переменной идёт xml-элемент, содержащий её имя, описание, тип и чёрте знает что ещё. Коротко говоря: очень плохо. Причин несколько: 1) специализированный ни с чем не совместимый XML, 2) следствие: разрабатывать возможно только в одной специализированной среде, у которой куча проблем с юзабилити и производительностью, 3) опять же, всякие диффы плохо работают с XML, 4) итд
* Исходники на DSL, хранимые вместе с метаинформацией в бинарном формате. Коротко: очень плохо. Причины те же что с предыдущим, только стандартные средства ещё хуже работают с бинарными файлами, а формат конечно же уникальный и ни с чем не совместимый.
Некоторые — допускаю (хотя ни я ни мои знакомые с таким не сталкивались); но даже если через суд — закон на вашей стороне и деньги вы заведомо получите, только конечно потратите кучу времени и нервов.
С другой стороны, «юзер» (покупатель, картхолдер) сейчас как раз наиболее защищённая сторона во всей этой истории. Во-первых, у юзеров уводят гораздо меньшие суммы, чем у банков/процессингов — это и так понятно, у юзеров просто нет много денег. Во-вторых, если вы как юзер видите фродовую транзакцию в выписке — вы пишете в банке заявление и в разумные сроки почти всегда получаете деньги назад (многие банки предпочитают всегда возвращать деньги клиенту, независимо от исхода диспута). А вот банк как минимум вынужден оплачивать организацию диспута, да ещё и саму сумму транзакции в случае, если деньги клиенту он уже выдал, а от платёжной системы/мошенника/wtf не получил. Ну и самые незащищённые — торговцы.
Крупные предприятия, сохранившиеся с советских времён, занимаются примерно тем же. В вузах есть такая вещь, «целевой набор» называется. И спецкурсы, которые ведут сотрудники заинтересованного предприятия.
И на них глядючи, я думаю, что от государства здесь требуется только не мешать. Бизнес, нуждающийся в кадрах, вполне способен их воспитать.
Во-первых, к распространённым олимпиадам по программированию это не относится, там считается ровно наоборот. И это часто называют главной проблемой спортивного программирования. Хотя я допускаю, что бывают какие-нибудь местячковые олимпиады, где кто-то смотрит в код
Во-вторых, по опыту, в «индустриальном программировании» дело именно так и обстоит: качество оформления кода важнее работоспособности. Потому что работоспособность проверит отдел QA и вернёт на доработку, это одноразовая процедура. А от качества кода зависит стоимость дальнейшей поддержки, это по эн человеко-дней за каждый год жизни продукта.
Ну, я может немного утрирую, но в целом оно так.
Проверил. Это так, но не настолько красиво как хотелось бы: p=7, q=7, r=11. Красивых (без повторяющихся чисел) решений нет.
Ало, а почему же вместо этого в обеденный перерыв не навестить ребёнка в детском саду!? :) Улыбнуло: вечером увлекаться программированием плохо, а в обеденный перерыв самое то.
Не совсем так. Ошибка в коде, конечно, была (плохая обработка исключительной ситуации — это ошибка). Другое дело, что при современных подходах к коммерческой разработке ПО ошибки в коде принято рассматривать не как ОШИБКИ, а как допуски. Ну вот токарный станок делает шайбы с допуском в 0.1мм, а иногда получаются с допуском в 0.2мм — это никого не смущает, просто есть контроль качества и плохие шайбы выкидывают или допиливают напильником. Так же и с ошибками в коде: ну ладно, забыл программист на null проверить, подумаешь. Тестировщики нашли, программист поправил, продукт зарелизили, все довольны. Вот если тестировщики не нашли — вот это уже проблема: это значит что либо плохо тестировали, либо плохо объяснили тестировщикам требования, против которых надо тестировать, либо изначально требования не так сформулировали… короче да, с точки зрения современной софтверной индустрии — проблема в процессе / управлении качеством.
А вот какие подходы к управлению разработкой / управлению качеством в космической отрасли, тем более какими они были в бородатом 1996 — я не знаю; допускаю, что по меркам современной софтверной индустрии подходы дедовские, т.к. отрасль скорее всего очень консервативная. Если там, как в древнем софтостроении (или как в мелких стартапах сегодня) — «тестировщики? какие тестировщики?» — то ответственность за соответствие софта требованиям лежит только на программистах, т.к. больше просто не на ком.
Зато, если у вас на карточке включена подписка на 3DS, и по ней как-то провели транзакцию без 3DS — диспут однозначно разрешается в вашу пользу, сумма транзакции и все неустойки ложатся на торговца.
Я несколько альтернатив видел (в разной степени), и ни про одну не могу сказать что она лучше чем текст:
* UML и другие воплощения идеи «а давайте у нас менеджеры будут программировать диаграммами». Коротко говоря: ужасно. Причин несколько: 1) менеджеры это не программисты, 2) утечка абстракций, 3) проприетарные закрытые ни с чем не совместимые форматы данных и средства разработки, 4) широко распространённые средства работы с исходниками (sed/grep/diff/merge итд) не работают с этими форматами, 5) итд. В общем, это скорее средства для попила бюджетов, чем для программирования.
* Исходники на каком-нибудь DSL (хорошо если основанном на чём-то широко известном), снабжённые метаинформацией и вместе с ней хранимые в XML. Т.е. вместо просто имени переменной идёт xml-элемент, содержащий её имя, описание, тип и чёрте знает что ещё. Коротко говоря: очень плохо. Причин несколько: 1) специализированный ни с чем не совместимый XML, 2) следствие: разрабатывать возможно только в одной специализированной среде, у которой куча проблем с юзабилити и производительностью, 3) опять же, всякие диффы плохо работают с XML, 4) итд
* Исходники на DSL, хранимые вместе с метаинформацией в бинарном формате. Коротко: очень плохо. Причины те же что с предыдущим, только стандартные средства ещё хуже работают с бинарными файлами, а формат конечно же уникальный и ни с чем не совместимый.