Comments 293
они выявляют ошибки по всей глубине стэка приложенияВот тут погодите. Это характеристика end-to-end тестов. Те которые через GUI как правило. А их то, как раз, разрабатывать не редко сложнее, (например из-за отсутствия нормального интерфейса для доступа «робота» к графической оболочке, постоянного изменения или динамики/анимаций в графическом интерфейсе), и они дороже.
это рутина, это рабский трудЭто систематический подход. Да, может в выявлении ошибок не самый эффективный способ, но систематический.
Я боюсь, что в fuzzing тесте, ошибку скорее сделают при составлении граничных значений для параметров. Например 0-255, и толку тут от рандомизации, если область определения недостаточна, нет отрицательных значений. А при составлении юнит-теста, ты возьмешь четыре значения и все. И если я захочу делать рефакторинг — мне будет спокойней от прогона юнит тестов. Они скажут мне, что все то, что работало до этого работает и теперь. Что я никому не наступил на ногу, т.е. не нарушил никаких контрактов с другими подсистемами. А сколько прогонов случайных тестов нужно чтобы убедиться, что все работает как и раньше? Вот вам и вывод, что fuzzing тесты нельзя сравнивать с юнит тестами. Полезны и те и те, и нужно понимать где, когда и зачем применять разные методики тестирования.
Ну естественно. Моё IMHO, было относительно ключевых слов «провинились». Я как-бы не против юнит тестов, ибо «Они ничем не провинились».
> Вот тут погодите. Это характеристика end-to-end тестов. Те которые через GUI как правило.
Согласен, моя ошибка, — fuzzing тест выступит в данной ситуации вместо GUI.
> Я боюсь, что в fuzzing тесте, ошибку скорее сделают при составлении граничных значений для параметров. Например 0-255
Fuzzing тесты делаются не для того, что-бы вводить граничные параметры, а что-бы выявить при каких условиях происходит сбой, в этом их вся суть. Если вы разрабатываете систему fuzzing тестов, которые как-либо ограничены в «рандоме данных», то это неправильные fuzzing тесты. Более того range overflow это один из базовых fuzzing кейсов.
> А сколько прогонов случайных тестов нужно чтобы убедиться, что все работает как и раньше?
Дни, недели… Какая разница, сколько, если тест предназначен для того, что-бы свалить систему, а не для проверки работоспособности её компонент?
Они скажут мне, что все то, что работало до этого работает и теперь.
Они могут только сказать о том, что сломалось. По построению.
А вот фаззинг не предназначен для тестирование логики. Мне вообще не понятен его смысл, он только толкает делать ненадежный код.
Когда на каждый лишний if приходиться писать отдельный тест
просто невозможно покрыть говно-метод
Вот из-за такого использования тестов у разработчиков и появляется отвращение к тестированию и мысли типа юнит-тесты не нужны. Потому что где-то на каком-то проекте уже успели наесться такими тестами, где надо покрыть каждый if, потому что чуть что может и сборка упасть из-за недостаточного code coverage.
Когда просто невозможно покрыть говно-метод из 500 строк.
Вы к тому, что захочется его переписать или к тому, что захочется просто забить и протестировать по методу «вроде работает»?
— Если ты изменил поведение — они напомнят тебе, что раньше было иначе и надо бы изменить юнит тесты (т.е. документацию)
— Новый человек может неверно понять принципы работы модуля. Когда он сделает правку, которая противоречит дизайну — юнит тесты скорее всего об этом оповестят.
— В юнит тестах можно подсмотреть примеры вызова методов и того, что они возвращают.
— Ну и наконец это отличный способ отладки модуля в процессе разработки, чтобы не стартовать все приложение.
1. Не существует тестов, которые гарантируют правильность работы программы. Тесты лишь фиксируют поведение программы при определённых наборах входных данных и обеспечивают сохранение поведения программы при вмешательстве в код.
2. Тесты — это, в первую очередь, документация. Если из теста непонятно, как работает тестируемый кусок кода, значит, это плохой тест.
Мы пошли совсем просто, наняли математика, он доказывает что наши функции «работают», или же не «работают». И естественно занимается оптимизацией алгоритмов. Для него юзается а-ля псевдокод, наибоычнейший с-образный с примесью паскаля, что бы он перешел потом в тестеры.
Наш математик ошибки ловит наура, на бумашке))
Достаточно сложно было объяснить почему байты и инты и почему иногда юзать два инта выгоднее чем лонг, но он въехал) Более того, он щяс топит за стек ну потому что наконец-то понял как он работает, и уже полез в спид-тесты.
Что бы мы без него делали я хз… Незаменимый человек.
И да, теперь для меня тесты делятся на логические, ну это когда 2+2 все же равно четыре, или не равно.
И скоростные, т.е. тут оптимизация алгоритмов, структур данных и собственно хаки.
Так вот все кроме хаков сваливается на проверку математику, и это дает фееричные результаты) Иногда он приходит и вместо наших монструозных конструкций выдает гениальные решения в одну строку псевдокода, которая имеет абсолютные мат.доказательства на трех листах, которые даже тестить не надо, ибо оно совершенно бессмысленно.
Но это наш путь) Ага, мы странные ребята, делаем как положено логически железобетонно, а не как заведено у всех непонятно кем и главное зачем?
Если не секрет, чем вы занимаетесь?
Потому что появился математик, а значит можно заниматься «всем».
Давайте поясню.
Боролись со шрифтами, искали нормальную библиотеку, и естественно не нашли. Откуда ей взяться, если оные либы пишут дурачьки?
Задача: сообразить универсальную библиотеку, работающую с любыми шрифтами и способную рендерить шрифты хоть под что хоть где.
Обыскались) и не нашли, оного не существует в природе.
Написали свою, за неделю, но готовились к написанию два месяца, в развалку.
В итоге сделали следующее: писано оно на фреймворке втором, потому что его можно запустить хоть где, и еще кое какие причины имеются на это. Сами шрифты специально обработаны, не спрашивайте зачем. Шрифты внедрены в либу и хитро запакованы. Сама либа следит за вызываемыми шрифтами из нее, и имеет свой кеш, но кешируются ФонтФемили, а не шрифты Фонт. Кеш сам следит когда почистить неуправляемый gdi например. Почему gdi? Потому что только gdi выдает вменяемые результаты на винде. Потому что gdi способен работать без видеокарты вообще. А значит оное работает на серверах и оно работает) Более того, математик разработал свой рендер. Он въехал как шрифты рендерятся виндой, и написал очень эффективный кеш в котором хранится именно готовое графическое представление строк. В системах где оно стандартным способом не будет работать — можно запросить битмапы с графикой. И да, он заодно разобрался с dpi, т.е. выдал формулу как его считать корректно))) И он нашел кучу ошибок, почему нынешний расчет dpi люто гонит. Только он предложил кешировать самые частовстречающиеся сочетания символов, и сразу хранить не графику отдельных символов, а наборы символов. И на это тоже он рассчитал и написал алгоритм)
Теперь хоть где мы можем шрифт прицепить вот так просто: System.Drawing.Font f = SysDrawing.Fonts.Metro.Get(14, SysDrawing.Weight.SemiBold, SysDrawing.Style.Italic);
И да, только у нас шрифты наконец-то видятся любых начертаний. Если вы думаете что это просто — да, это просто) Но вы попробуйте сделать так же, у вас ничего не получится, причин этому неимоверная гора. Все эти причины вы должны обойти, и получить ровно то что нужно хоть где работающее.
Нужно всего-то разбираться в шрифтах, разработать точную архитектуру библиотеки, рендер на всякий случай, и написать все в кучу почти готовое за неделю) Что и было сделано. Без математика мы бы погрязли в чортовых тестах. Щяс же ничего не тестилось вообще, зачем?
А есть совсем банальные вещи. Вы как конвертите число в шестнадцатеричную строку?) И даже на это есть математик. Потому что он доказал, что можно конверитить без массива чаров, и без единого if-а) Код ровно в одну строчку. Казалось бы а оно надо? Надо)) Там где вы будете массово конвертить числа в hex-строчки — вам понадобится производительность.
А с криптографией что вы будете делать? Опять сами? Ой да не смешите… Вы не специалист никак, вашу криптографию мой математик пробьет нараз) А вы мою не пробьете, потому что она писана моим математиком) А он знает что делает.
А с трехмерными и прочими штуками вы что делать будете? Или снова и опять с первым курсом аналитической геометрии сунетесь в это?))
Послушайте, есть вы — программист, но это не значит что вы шарите в математике. А значит?.. Наймите математика)
И через час я получаю псевдокод каторый пишу десять минут и мне ничего тестить не нужно) Причем, то что я переписываю с бумашки — я в этом вообще почти ничего не понимаю. Я почти не понимаю как оно работает. Но математически доказано, что оно будет работать. И я и не обязан понимать математику. Потому что это не моя работа.
И да, имейте ввиду, что математик НЕ МОЖЕТ ОШИБАТЬСЯ. Потому что это математик) Он пользуется принципиально иными способами «тестирования», а именно доказательствами. Каторые тестировать нет никакого смысла. Проще говоря — тестировать за математиком — полнейший бред. Или вы собрались тестировать математику?) Ого…
Напомню, что даже реальное доказательство 1997 года содержало ошибки, и до их исправлений было неверным.
НО!
Одно дело ошибаться в новом. А другое дело разруливать то что известно и известно хорошо.
При этом. Тут как бы два угла зрения. Например мой, программистский, на известные математикам вещи. Но для меня они сложные, для меня это как раз почти теорема Ферма) А для математика это банальность. Так вот люди в банальностях не ошибаются. И доказательства тут достаточно простые, т.е. для математиков это банальщина. А для меня и для вас — это почти темный лес.
Плюс ко всему конечно же тут нужно иметь ввиду то, что доказывать можно по-разному, оценочно например, или получать доказательства принципиально разными мат.методами. Наш Миша этим сильно грешит) Когда у него уже и так все доказано, а на основе этого уже и так все работает, он все равно с упорством числогрыза иногда приносит доказательства вдовесок. При этом, эти доказательства только улучшают старые доказательства. При этом, иногда получается так, что новыми доказательствами он расширяет область доказуемого, т.е. делает доказательство более обобщенным. А значит?)) А это значит, что у нас появляются мысли на более общий код. Без математика обобщить что-либо программистом вообще никогда не получится.
И т.д. и т.п.
О том как мы раскалупали адобовский код обрабатывающий цветовые профили, и о том что только математик понял на какой формуле оно работает и какое преобразование применяется? И о том как мы это дело увели под себя? Это можете и вы. Легко. Но вы ничего не поймете) И никто не поймет. Поймут только математики) Ну и зачем такая статья, которую ни я ни вы не понимаете?
Увести можно все, запрограммировать можно все, но как понять на основе чего оно работает, что бы перепилить под себя? В основе математика со сложным матаном — оно вам надо вообще?)) Мне — НЕТ.
Или может быть замутить статью о четверичном кодировании представления картографических данных, например в викимапии старой версии, где я отчасти понял кое что, но у меня на это ушло два года))) А математик это понимает за пять минут. Про это написать?) Увольте…
Деньги на этом никак не экономятся.
У нас другой смысл.
Без математика никак нельзя собрать что-либо вменяемое. А мы собираем свое. Потому что нет смысла юзать чужое готовое. Оно невменяемое. Невменяемость заключается в том, что не понятно — работает оно или нет. Весь свободный код — не вменяемый совершенно. Как только свободный код становится вменяемым — он резко перестает быть свободным. Тут вариантов не много. Или пользоваться чужим и свободным, но абсолютно кривым, или коммерческим и не свободным, и тоже кривым. В любом случае вы не будете знать как оно работает и все тестами никогда не покроете.
Остается поглядеть как написали другие или же украсть, и дописать свое. Но в обоих случаях всегда лежит математический алгоритм, и знает как оно работает только математик.
Мы пришли к простой мысли. Контроль за кодом только один — когда он наш и мы понимаем как он работает.
Собственно тут ничего хитрого и нет. Когда-то были времена например мобильной джавы, так вот базовых классов там было всего штук пятнадцать, а все остальное пишите сами. Т.е. из коробки там ничего и не было. Берете и сами все пишите, с чистого листа.
Ровно так же делаем и мы. Вот по-этому у нас все работает. А там где не работает — всегда можно посмотреть и подправить.
Других вариантов программирования для нас уже не существует. Мы устали бороться с чужими багами. Тем более это абсолютно бессмысленно.
Смотрите как оно было когда-то. Во времена чистого функционального программирования без этих ваших юи и прочих излишеств программировали математики) Ну потому что важен был алгоритм, а как что выводится — на это ваще всем было пофигу. Никаких «странных» телодвижений типа ооп вообще не было. Так называемые старперы до сих пор так и прогают. Им важна суть, а не хрень какая-то непонятная и не нужная. Ну это их взгляд на программирование, чисто математический.
Далее все чуть поменялось. Появились какие-то окошечки-кнопачки и прочий трешак. Те программисты которые математики — начали удаляться, потому что это уже не их.
Щяс же все упарываются в эти самые окошечки и прочую хрень, где математика вообще не используется.
Смотря что вы программируете. Если хрень — ну да, вам естественно дико за мысль, что программист — это математик прежде всего. Вы же собираете из готового. А позвольте вас спросить — А ГОТОВОЕ ВАМ КТО СОБИРАЕТ?)
Так вот собирают фреймворки, компиляторы и прочие крутые штуки как раз таки эти самые старперы-математики. И хрен они затаращщили на эти ваши окошечки. Резвитесь с ними сами, потому что это вообще ни уму ни сердцу. С этим справится любая обизьяна. И конечно же математики там нет и не будет.
«смотрите какую мы хрень сделали, а математик принес вот это, мы переделали, и получилось вот так. Так вот мы экономим по 1М ежемесячно, заодно поднимая общее качество кода»Мы не делаем что-то новое) Мы не пишем велосипеды. Мы берем решения или же воруем их, разбираемся с ними, смотрим какое лучше, перепиливаем под себя и получаем почти то же самое.
Что на выходе? То же самое))) Почти.
Разница тут в том, что мы понимаем как оно работает и где косяки. Где нужно тестить, а где не нужно тестить.
Что-то перепиливаем под собственный фреймворк, он работает гораздо лучше и понятнее, чем все что есть щяс из коробок.
Что такое качество кода я понятия не имею. Это похоже термин из юриспруденции что ли… Хз)
Unit-тесты помогают дробить систему или какой-то блок системы на отдельные элементы (юниты). Если кто-то тестирует 1+1=2
, это его проблемы. Тем не менее, unit-тестами можно тестировать и довольно сложную логику. А если еще эти тесты написаны как следует, то можно и по ним понять, как работает этот отдельный юнит.
Я считаю такие интервью вредными потому, что их могут прочесть настоящие дураки,
и принять их как руководство к действию.
Просто миграционным службам плевать сколько у человека звезд на github'е, ему бумажку хочется увидеть.
Некоторые страны да, но есть и те, кому плевать на бумажки, скилл важнее. Нидерланды, например.
Документально подтвердить эти 5-10 лет будет сложнее, чем диплом показать. Или думаете вам на слово поверят?
" ACS Australia assesses the skills of the applicant, who do not have ICT qualifications or any tertiary ICT qualifications. "
«вышка» давно уже перестала быть исключительной необходимостью для эмиграции айтишного люда.
Если что-то технически сложное, что обычно пишут на C/C++ — диплом спрашивают весьма часто(сужу по вакансиям). Если это ВЕБ — диплом вообще никого не интересует, 1С/Мобильная разработка — иногда спрашивают диплом только у кандидатов, что ещё не имеют опыта.
Я в 17 устроился (месяц назад), никто не спрашивал где/как я учусь(Пошёл в колледж ради того чтобы быстрее влиться в рабочую среду).
Если малый бывал за границей, можете рассказать ему что дорога туда в 90% с вышкой, может передумает =)
Сначала мы тратим время чтобы получить деньги, потом тратим деньги чтобы купить время
Вечный вопрос — в чём смысл жизни?
По фото подумал что очередной смузи-хипстор.
Хотя далее по тексту видно что вроде действительно выгоревший/выгорающий опытный разраб.
По фото подумал что очередной смузи-хипстор.
Та же фигня. Начинаю читать и думаю — «сейчас начнется про новые фреймворки для node.js или про очередную конференцию...»
Ан нет, внезапно годнота.
Но меня заинтересовала ваша логика связи ваты с консервативными программистами. Возможно, что я ошибаюсь, но в кустах мерещится камуфлированный наступательный диван)
К тому же лично я «смузи-хипсторами» склонен называть тех, кто только и делает, что бесконечно катается по конференциям, фанатично рекламирует какие-то супер новые фреймворки и библиотеки, языки и модные концепции, пишет претенциозные «лонгриды» о том, как нам правильно программировать и на чем, но не делает главного для программиста дела — не пишет, собственно говоря, программный кот.
Я же описал человека, который НЕ занимается кодингом вообще, и вся его деятельность заключается в том, что (см. выше), однако же он считает себя зомфг разработчиком и двигателем нового в массы. Мы просто рассмотрели черный и белый случаи, а тут, думается мне, серенький-то все-таки идеален — когда человек сочетает и конференции, и кодописательство. А бездумные кодеры, равно как и бесполезные болтуны со сцены — это такое себе.
У вас нет монополии на преувеличения.
Зато часто читаю комменты вот таких лесорубов как вы
Ну на личности-то зачем, нормально же сидели.
При это никогда не видел их вклада в сообщество.
А что, все те, кто не считает нужным вкладывать в сообщество — второй сорт и «лесорубы»?
Без обид, но со стороны ваши комменты звучат как нытье обиженного неудачника.
Меня это не волнует совсем абсолютно никак, тем более, что вы ошибаетесь.
Так что в философии "programming motherfucker" — что-то есть.
Он просто за день может разгрести кучу с которой трое за неделю не управятся.
Но ведь "всякие автоматизации" нужны, чтобы баги предотвращать, а не чинить.
Если оценивать эффективность работы метрикой "количество закрытых багов в день", то можно добиться просто космических результатов.
А что будет, когда этот человек решит уйти из компании?
Говоря в общем случае — тогда будет команда как все. И тогда мне наверное мне тоже захочется уйти. Потому, что весь этот западный детсад-стайл-менеджмент, философии компании, игра в аджайл и прочаяя муть «зальют водой» и утопят проект через год.
У меня не самый плохой девбокс, но с одним значимым минусом — я попытался сэкономить и купил проц от амд. Это был страшный провал. Не смотря на высокую заявленную мощность, этот кусок говна прогоняет мои тесты в 5!!! раз медленнее, чем его интеловский аналог.
Вот это кстати вызвало наибольший вопрос. Я собирался апгрейдить свой компьютер на Ryzen, потому что по всем тестам он сильно выигрывает у интела. А тут такой облом. Нет, я не буду покупать проц в котором все так плохо, даже будь он в 2 раза дешевле :)
Мне иногда кажется, что с таким подходом у меня нет морального права искать себе работу. Я оправдываю себя тем, что по отношению к системе нельзя быть моральным или аморальным. Абстрактность корпораций помогает дистанцироваться от мысли, что можешь навредить реальным людям — поэтому я беру работу только от больших компаний.
При этом меня смущает, насколько огромные для своего города деньги я получаю за один пулл реквест. Как будто высокий скилл разработчика даёт мне право жить в десять раз лучше чем куча людей, которые в поте лица делают полезное дело по восемь часов в день.
Мне кажется, человек плохо понимает, насколько один PR может принести пользу человечеству. Ведь если каждый коммит увеличивает продуктивность каждого пользователя технологии в 1.000000001 раз, то очень быстро их продуктивность изменится просто в разы. Кумулятивность эффекта программирования и взаимной помощи (особенно в OSS) это очень мощная штука. По крайней мере, когда я задумывался над этим, я пришел именно к таким выводам.
Иногда кажется, раз я смог переиграть бизнес на собесе, то я в какой-то мере достоин того, что имею. Из-за этого я утрачиваю связь с реальностью, и мне начинает казаться, что так всё и должно быть.
Не знаю, как это можно совмещать, но я обожаю разрабатывать и ненавижу работать разработчиком. Я пытаюсь успокоить себя тем, что просто мне ещё не попался интересный проект, но в то же время сам в это не верю. С этим действительно тяжело жить.
Мне кажется достаточно адекватный разработчик может уйти на ЗП в 2 раза ниже текущей, и перестать выгорать, не потеряв при этом возможности содержать семью. Траты на психолога и потенциальные срывы дороже выйдут в итоге.
Чем юнит-тесты провинились тоже непонятно. Зависимые типы ни в одном мейнстрим языке еще не появились (и, наверное, не случайно), а без них многие отношения в коде не выдержать. Я лично не знаю другого изолированного способа воспроизводимо тестировать функционал. Я пользоваляся иногда тулзами типа quickcheck! (которые автоматически генерируют кейсы, и в случае провала пытаются сформировать MRE), но я их считал теми же юнит тестами. И без них весьма тяжко.
Что касается пожеланий:
Вывод типов и компайл-тайм иммутабельность — System.Collections.Immutable. Проблемы только с иммутабельными классами, проблему осветил Джон Скит на дотнексте.
Чтобы разработчики C# послали, наконец, к чертям собачьим обратную совместимость — не случится никогда
Автоматические backing fields в C#, какой-нибудь сахар над Func<T1,T2>. — непонятно, что имеется ввиду. Автоматические филды есть, ручные я почти не вижу в реальном коде. Сахар для Func<T1,T2> непонятно какой имеется ввиду. Я бы предпочел иметь адекватный Unit-тип, чтобы объединить наконец Func/Action, Task/Task/…
Контракты для C# — есть пропозал, вроде даже чемпион
Аналог jsx для языка F#. — мне казалось jsx во-первых устарел (все фронты просто .js используют), а во-вторых функциональщина с интерфейсами как по мне слабо сочетается. Мб не прав, тут не знаю, не использовал серьезно
Чтобы сообщество пришло к пониманию, что юнит-тесты — бесполезный мусор — выше написал
Чтобы архитектура процессоров была больше рассчитана на функциональный подход. — ограничения физики это не то, что можно легко обойти. Лисп-машины были не сильно удачными, и не потому, что их не старались сделать производительными. На низком уровне императив правит миром, а языки, которые близки к ним идейно — быстрые. Вряд ли с этим глобально можно что-то сделать
Оптимизация хвостовой рекурсии в js/ts — не вижу особых проблем, чтобы это реализовали в любое время, это ведь совсем несложно.
Опциональная возможность статической типизации в js из коробки
1. не будет сделано никогда
2. уже есть ts, смысла большого нет
Чтобы штуки вроде web-assembly прочно заняли своё место в практиках — так и будет
Значимого усовершенствования web-клиентов гитхаба и ему подобных. — неплохая идея, будем надеяться. Пока что гитхаб даже ревью не очень показывает, приходится использовать сторонние сервисы
Больше конвенций по совместимости. Насколько бы всё было бы проще, если бы jvm умела интерпретировать и jit-ить дотнетный cil. — было бы наверное неплохо, но кмк это нереализуемо, чтобы было и эффективно, не говоря про саму возможность договора между MS и Oracle.
У меня несколько своих проектов с друзьями. Люблю специально делать им пассивно-агрессивные код-ревью («не мог бы ты предложить мотивацию для использования столь непродуманного решения?») и наблюдать, как это меняет наши взаимоотношения.
Лучший способ поссориться с людьми, которыми дорожишь. Иронизировать и подкалывать — это одно, а ПА атаковать — другое.
Учебная — «clr via C#» Джеффри Рихтера. Столько знаний про то, как устроен дотнетный рантайм в одном труде — настоящая находка. Если заучить эту книгу, пройдёшь любой собес на дотнетера.
Вот сколько читаю про дотнетеров — все на эту книжку чуть ли не молятся. Пробовал читать её дважды — оба раза не мог дойти дальше 50 странцы. Столько воды, что засыпаешь на ходу. Про устройство дотнета намного полнее и интереснее было почитать Pro .Net Performance за авторством Саши Гольдштейна. Вот уж и глубоко, и понятно, и приколы вроде фич, которые есть в CLR, но не доступны напрямую из C#. Очень рекомендую.
— Ну и ответ на вопрос, конечно же
— Изучение какой технологии вызвало у тебя наибольшее удовольствие в процессе?
Сначала Delphi после pascal, потом схожие чувства от C# после Delphi, сейчас же Rust после C#.
купил проц от амд. Это был страшный провал. Не смотря на высокую заявленную мощность, этот кусок говна прогоняет мои тесты в 5!!! раз медленнее, чем его интеловский аналог
— тут не ясно о какой модели идет речь. У меня Ryzen 7 1700X 3.4 GGz — я доволен как слон (перед этим была мать с двумя двухядерными ксеонами — AMD кратно их превзошел). Вероятно проблема в том что используются однопоточные приложения на которых мощь многоядерной системы не раскрывается.
Вероятно проблема в том что используются однопоточные приложения на которых мощь многоядерной системы не раскрывается.
Очевидно, речь о прогоне юнит-тестов в VS средставми самой IDE или R#. Конечно же, они прогоняются параллельно, я лично видел до 16 тестов одновременно на 8-ядерном (с HT) процессоре. Так что вопрос явно не в однопотоке (он кстати по тестам у рязани нормальный).
Скорее всего да. Рязань у коллег-дотнетчиков рвет и мечет не только в синтетических тестах.
Текущее на то время решение состояло из 37 проектов и примерно 5к юнит тестов, прогон тестов на интеле шел в фоне, никак не отражаясь на работе VS, на амд начались лютые фризы всей студии. Пришлось отдать рязань племяшу под игрушки и задуматься о i9.
Возможно это кривая оптимизация винды/студии для амд. Но мне, честно, пофиг. Я хочу чтобы все работало, так быстро, как это возможно, не создавая дискомфорта. И если амд не может мне это обеспечить, то извините пожалуйста.
Все открывается за доли секунды. Но скальп все же требуется если 5.0.
Так что берите :)
P.S. Лучше в связке с 970 pro.
Рейзн пока толком не щупал (пришли первые 3 компа с 2400g, но на моём рабочем компе стоит 7, а на них — 10, напрямую не могу сравнить), но и7 славится затупами при высокой нагрузке — что на зионах замечал, что на текущем станционарнике, что на ноутах.
Ну и биосы сырые, сырые и ещё раз сырые — очень много нового добавили, в целом, платформу наконец более-менее вылизали, но надо обновиться, а производители материнок не спешат как-то.
Очевидно, речь о прогоне юнит-тестов в VS средставми самой IDE или R#.
— для меня не очевидно (VS я не пользовался никогда), а в тексте статьи явных указаний на то как именно интервьюируемый гонял тесты (и какие? может интеграционные?) нет.
Мне кажется, человек плохо понимает, насколько один PR может принести пользу человечеству. Ведь если каждый коммит увеличивает продуктивность каждого пользователя технологии в 1.000000001 раз, то очень быстро их продуктивность изменится просто в разы. Кумулятивность эффекта программирования и взаимной помощи (особенно в OSS) это очень мощная штука. По крайней мере, когда я задумывался над этим, я пришел именно к таким выводам.
Мне кажется это сложный вопрос. Я вот не знаю, растет ли моя продуктивность. Каждый день каждый разработчик создает все новые PR'ы. В итоге, чем дальше, тем больше тратишь времени не на работу, а на изучение того, что изменилось, починку того, что поломалось (вышел какой-нибудь MegaElasticRedisSearch версии 7.5 — половина кода поломалась, тратишь от 4 часов до нескольких дней на починку)… У меня есть интуитивное ощущение, что через 5 лет такими темпами можно будет утром писать код, который к вечеру будет уже устаревать.
А помогает ли это все человечеству в целом?.. Не уверен.
Мне кажется достаточно адекватный разработчик может уйти на ЗП в 2 раза ниже текущей, и перестать выгорать, не потеряв при этом возможности содержать семью. Траты на психолога и потенциальные срывы дороже выйдут в итоге.
Утопия. Никогда так не будет, скорее всего. Причины выгорания скорее не в зарплате, а в отношении к работе.
а языки с динамической типизацией (не путать со слабой) — самый крупный провал в истории индустрии.
Автоматические филды есть
Автор имел виду backing fields, как в Kotlin, автоматически доступные в геттерах/сеттерах, и только в них, чтобы для свойства вида int Age { get; set; } не приходилось объявлять поле int _age, если вдруг нужно реализовать какие-то проверки или иные действия в геттере/сеттере.
А только в геттере/сеттере поля должны быть доступны, не только, чтобы не засорять код декларациями, но и чтобы не было разнобоя в обращениями внутри класса Age или _age (поди разбери, когда то или иное обращение было сделано специально, а когда от неаккуратности).
2. Есть пропозал, когда-нибудь добавят.
В приложениях с UI их очень много, взять хотя бы INotifyPropertyChanged.
Правильно ли вас понимаю, что от вас требуют, к примеру, обосновать, почему вы используете, допустим новые конструкции C# 6-7 — паттерн матчинг (новое слово when в switch/case), фильтр исключений (when), или какие-то новые конструкции, связанные с тем же паттерн матчингом в части апгрейда работы с is/as, или "out var _"?
Если так, то странно, если учесть, что автор высказал много пожеланий в части апгрейда того же C# (именно в части радикального обновления конструкций и подходов) и JS до кучи.
Лично на мой взгляд, не плохой подход — пытаться опровергнуть решение для получения доказательств его верности.
На мой взгляд, так себе решение — это неплохо работает в математике, но в человеческих и рабочих отношениях работает уже сильно хуже, с учетом моментов психологии.
И еще хуже работает в ИТ, где есть такой тренд — под маской критики и вопросов прятать троллинг и/или желание ничего не менять.
На фоне всех этих успешных успехов, как глоток свежего воздуха.
Сам выгорел из-за однообразной рутинной работы и ушёл в никуда. Перед уходом поймал себя на мысли, что интересный проект лично для меня — приоритет номер 1. Если этого нет, то даже высокая ЗП и плюшки — это временная радость. А фрустрация — это вещь, которую нельзя просто оставить за порогом офиса.
Не знаю, как это можно совмещать, но я обожаю разрабатывать и ненавижу работать разработчиком
Это, пожалуй, лучшее описание моего внутреннего состояния. Точнее и не скажешь.
Чтобы сообщество пришло к пониманию, что юнит-тесты — бесполезный мусор
Тут ещё вопрос, что считать юнит-тестом. Unit — единица весьма условная. Но вообще по моему опыту бэкенд веб-дева получалось так, что чистых юнит-тестов в проекте меньше всего. Не складывается пирамидка-то :)
Т.е они не совсем бесполезны, но очень часто их пишут просто до кучи и это не более, чем бесполезный шум. Имитация бурного тестирования :)
Да и вообще, было неожиданно интересно.
Не совсем так. Если вы сразу начинаете работать в энтерпрайзе, в котором автор и работает, то современная индустрия построена именно так, что вам просто не дадут сделать что-то, чтобы на этот вопрос "что сделано, чем можно гордиться" ответить положительно.
Навскидку:
- Разработать движок EAV-базы для нашей задачи? — Велосипеды не нужны, есть готовые фреймворки и графовые базы.
- Задействуем готовый фреймворк или графовую базу? — Бизнесу это не нужно, нужно делать продуктовые таски.
- Переведем проект на .NET Core? —
А что это?Не нужно. - Мы много месяцев делаем однообразные таски, тратим на каждый много времени, при этом копипастя один и тот же код. Может, вынесем общий код в базовый класс, а под каждую таску будем делать легкий класс-наследник? — Не нужно, давай к пятнице закроем такую очередную таску.
- У нас в истории и трекера несколько лет и на ближайшие полгода вперед какие-то одинаковые баги, постоянно переотрываются и/или заводятся очень похожие. Они относятся к двум-трем блокам в приложении. За месяц-два стало ясно, как их сгруппировать, и что нужно сделать в каждой группе, чтобы "закрыть" каждый блок на 95%, потратим по 2 недели на каждый блок? — Бизнесу это не нужно.
- Далее везде.
В итоге, чтобы ответить на подобные вопросы, "что классного было сделано", нужно либо рассказывать stories (что и делает большинство), либо таки найти возможность сделать что-то крутое, но это будет наперекор индустрии и мейнстриму.
Или только «сильные» программисты любят свою работу?
Как бы одно является следствием другого. Программист и стал сильными, потому что любил свою работу, лучше усваивал опыт и даже искал его во вне рабочее время, таким образом получив преимущество над остальными коллегами.
Остальное меньшинство вполне можно называть фанатиками, верно.
Хорошо. В какое количество человекочасов можно оценить типичную собственную работу из портфолио художника?
При сравнении еще важно понимать, что программисты крайне редко создают самостоятельный продукт, в отличие от художников. Более того, программные продукты чаще всего закрытые, а наиболее интересные нюансы алгоритмов еще и под NDA попадают.
программисты крайне редко создают самостоятельный продуктВсе опенсорс сообщество смотрит с недоумением на этот коммент.
Мне, к примеру, есть что рассказать и про продуктовую работу, и свои (не)маленькие проекты.
Но я вам обрисовал общую ситуацию, и намекнул на масштаб усилий, чтобы было что рассказать.
Суть в том, что проблема есть, и проистекает из заведомо противоречивых требований индустрии. Например, на собеседовании вас могут спрашивать про графовые базы, но могут не дать поработать с графовой базе в легаси проекте (которых в том же .NET мире процентов 95).
Или могут спрашивать про авторизацию клиента на ендпойтах REST-контроллеров с помощью встроенных воможностей ASP.NET (тот же атрибут Authorize) или готового стороннего фреймворка, но попробовать вы могли это действительно только в своем pet-проекте, т.к. в предыдущем продуктовом легаси проекте вы добавляли методы в готовые контроллеры с велосипедной авторизацией клиента (ну когда у вас свой контейнер сессий, вы передаете в методы id клиента и токены, и прочая).
Гораздо приятнее взять в руки гитару или кисть с красками, лобзик или напильник, гантелю или шпагу. Пойти пробежаться или с женой в лесу погулять, в конце концов.
Но нет, программистом у нас имеет право называться только тот, кто пялится в монитор 24/7. Обязательно аккаунт на гитхабе с тыщей звёзд, пачка статей на хабре, непременно свой проект, в котором обязательно должны присутствовать блокчейн, машин лёрнинг, биг дата, nosql и десять фреймворков не старше одного месяца.
Но нет, программистом у нас имеет право называться только тот, кто пялится в монитор 24/7. Обязательно аккаунт на гитхабе с тыщей звёзд, пачка статей на хабре, непременно свой проект, в котором обязательно должны присутствовать блокчейн, машин лёрнинг, биг дата, nosql и десять фреймворков не старше одного месяца.Это вы сами выдумали, я такого не говорил. Бывает, что программисту не хватает рабочих задач, чтобы попробовать свои идеи, тогда он начинает что-то писать дома. Мне кажется, это нормально. То что вы написали выглядит, будто бы вы просто сдаете свой мозг в аренду на фиксированное время за фиксированную плату, и только когда приходите домой, то начинаете заниматься тем, что вам действительно нравится в жизни.
Я тоже отдаю работе все силы. И когда прихожу домой, мне даже сложную книгу или кино тяжело посмотреть.
Поэтому я поражаюсь людям наподобие Гвидо ван Россума, у которых не только работа на полный рабочий день, но еще и проект, в котором помимо кодинга надо решать кучу организационных вопросов.
Просто не понимаю, как таким людям удается все успевать.
ну зачем так) это же популярная тема — "to tell a story", "рассказать историю", это давно пропагандируется в статьях про собеседования, и здесь, на хабре, не раз говорилось, что это, мол, помогает производить впечатление.
чуть ниже BingoBongo привел хороший пример, позволю себе протицировать:
Это рассказать о ситуации из прошлого, например, когда от тебя ждали версию игры для показа на выставке в Германии, но внезапно обнаружилось, что билд стал крашиться без причины в случайные моменты времени. И на часах уже 22:00, выставка завтра, а ты единственный кто может что-то сделать.
Но ваша реакция оправдана, да, верно, у "рассказать историю" есть душок:
когда за неимением реальных достижений (например, вам удалось разработать архиректуру и процесс разработки, когда ничего не крешится), вы вспоминаете что-то такое:
"Был какой-то кипиш, я прямо из аэропорта за 10 минут до показа закоммитил исправление опечатки моего коллеги в develop-ветке, из-за которой билд не собирался, он там забыл поставить точку с запятой в строке int i = j +1;"
Ну и рассказываете это в выгодном для себя свете, хотя это было ненужное геройство после чужих залетов, и это уже не важно, и никто не помнит, и бизнесу тоже не важно, что вы поставили какую-то точку с запятой 2 года назад — не было важно ни тогда, ни сейчас.
И самое плохое, что сложившаяся ситуация в индустрии побуждает именно вот к таким вещам.
Очень трудно продвинуть реализацию действительно крутых и важных (в т.ч. в средне- и долгосрочных перспективах) вещей и потом презентовать и доказать, что это действительно важно (пустые стори с душком лучше заходят).
Это рассказать о ситуации из прошлого, например, когда от тебя ждали версию игры для показа на выставке в Германии, но внезапно обнаружилось, что билд стал крашиться без причины в случайные моменты времени. И на часах уже 22:00, выставка завтра, а ты единственный кто может что-то сделать.
К стати, по поводу историй — как рассказать историю чтобы соблюсти грань между рассказыванием излишних подробностей и инфы, которую разглашать нельзя и/или не стоило бы и тем, чтоб не рассказывать «В полночь че-то сломалось. я полез разираться, а там все плохо. полночи провозился, но пофиксил».
upd.
Упс… промахнулся с ответом.
как рассказать историю чтобы соблюсти грань между рассказыванием излишних подробностей и инфы, которую разглашать нельзя
История должна содержать изящное решение технической проблемы, а не бизнес-задачи. Если без опоры на предметную область никак не объяснить, то интервьюера такая куллстори и не заинтересует.
а ты единственный кто может что-то сделать.
Кто виноват в том, что у команды такой bus factor? Уж точно не программист.
п.с. Для маленьких проектов, которые, по сути, ведет один программист, а остальные нужны чтобы разгрузить от «тупых задач» — это частое явление. Поэтому ваш bus factor в пролете.
А зачем тут вообще искать виноватых? Или вы просто любите найти грязь?
Опасная близость к переходу на личности — признак того, что аргументы заканчиваются. И да, виноватых искать всегда надо хотя бы потому, чтобы не допустить подобного в дальнейшем.
Конечно, зачем обвинять менеджера/тимлида, который не учел, что у него басфактор равен единичке, проще позвонить кодеру, пофигу, что 22 вечера на часах, ничего, встанет как миленький, да пофиксит… а если не встанет, мы его премии лишим, а то и по собственному написать попросим, так, что-ли?
Для маленьких проектов
… которые кровь из носу должны быть показаны завтра на выставке в Германии, но кто-то сломал твой маленький билд?
У вас одно с другим не вяжется.
Опасная близость к переходу на личности — признак того, что аргументы заканчиваются.Так и зачем вы перешли со своим bus facor'ом, намекая что знаете больше меня и лучше разбираетесь в ситуации?
И да, виноватых искать всегда надо хотя бы потому, чтобы не допустить подобного в дальнейшем.Вам какое дело до этого? Каждый день случается что-то подобное — вы за всеми бегаете? Или вы думаете, что без вашего комментария я не понял что и как произошло?
Конечно, зачем обвинять менеджера/тимлида, который не учел, что у него басфактор равен единичке, проще позвонить кодеру, пофигу, что 22 вечера на часах, ничего, встанет как миленький, да пофиксит… а если не встанет, мы его премии лишим, а то и по собственному написать попросим, так, что-ли?Менеджер, тим лид и прочие виноватые — это я.
которые кровь из носу должны быть показаны завтра на выставке в Германии, но кто-то сломал твой маленький билд?Решение о внезапном участии в выставке принимается генеральным директором. Наша задача подготовить билд за неделю (хотя игра только-только начала разрабатываться) или обосновать почему это невозможно сделать. После размышлений оказалось, что подготовить билд вполне посильно.
п.с. Предупреждая вашу дальнейшую атаку: все усилия конечно же были компенсированы хорошим денежным вознаграждением по итогу проекта.
Так и зачем вы перешли со своим bus facor'ом, намекая что знаете больше меня и лучше разбираетесь в ситуации?
Да упаси боже меня на что-то намекать, я просто выразил свое мнение по данной ситуации. Я не учу людей жить, пусть поступают, как хотят — это их свобода их жизнь.
Вам какое дело до этого?
Вы задали вопрос — я на него ответил, только и всего. А с вашей стороны сразу какая-то агрессия пошла.
Менеджер, тим лид и прочие виноватые — это я.
Ну допустим кодер не взял трубку, дальше как развивалась бы ситуация, можете обрисовать? Мне действительно интересно.
п.с. Предупреждая вашу дальнейшую атаку: все усилия конечно же были компенсированы хорошим денежным вознаграждением по итогу проекта.
Да бога ради, главное — чтобы всех все устраивало, и гендиректора, который получил билд за премию разработчикам, и разработчиков, которые считают нормальным то, что им звонят в ночи с просьбой пофиксить внезапно сломавшийся билд.
Я выражал только свое личное отношение — в эти игры с ночными звонками я наигрался 12 лет назад, и успешно от них избавился. Но если кому-то нравится что его дергают и постфактум платят за это — кто я такой, чтобы осуждать?
С другой стороны, если работодатель ожидает от меня, что я отвечу на рабочий звонок в свое личное время — пусть платит мне за нахождение в режиме ожидания звонка. Пусть платит мне за то, что я не напиваюсь, не ухожу далеко от компа, не уезжаю туда, где в принципе связи нет. Это называется «дежурство», и именно так это должно быть организовано. В принципе, в той сфере, где я работаю, а это куда более life-critical вещи, нежели мобильные игрушки, это именно так и организовано, что позволяет сильно снизить уровень стресса — ты просто знаешь, что вот в эти сутки тебя могут набрать и попросить чего-то там пофиксить, и точно так же знаешь, что в эти сутки — никто тебя не дернет. А уж если ты в отпуске — смело клади рабочий мобильник на полку.
Ну допустим кодер не взял трубку, дальше как развивалась бы ситуация, можете обрисовать? Мне действительно интересно.Во-первых, я же сказал, что тим лид — это тоже я, когда баг критичный и «непонятный», то помощь простого кодера = 0 (если только это не тот кодер, который очень любит работу и даже пишет дома что-то свое).
Во-вторых, с чего вы взяли, что кто-то нужный вообще ушел домой? )
Ответ на ваш дальнейший большой абзац: в игровой индустрии все не так. В некоторых фирмах кранчи — это вообще норма. Проблема не в людях, а в требованиях самой индустрии. Вы себе неправильно все представляете. Но все не так плохо, потому что в остальное время работа идет весело и расслабленно — у меня таких историй вообще всего две или три за 5 лет.
Считаю, тему лучше закрыть.
Во-первых, я же сказал, что тим лид — это тоже я
Нет-нет, меня прежде всего интересовали последствия для кодера, вот я о чем.
Во-вторых, с чего вы взяли, что кто-то нужный вообще ушел домой? )
С того, что у него есть трудовой договор с указанным в нем временем работы, нэ? :)
В некоторых фирмах кранчи — это вообще норма.
А вы — лично вы — как думаете, это норма? Мне интересно ваше мнение.
Проблема не в людях, а в требованиях самой индустрии. Вы себе неправильно все представляете.
Помилуйте, гейм девелопмент это же не телеком какой, не медицина, не спецслужбы наконец. Почему там кранч на кранче и никто не уходит домой, что им не пишется спокойно «весело и расслабленно»? Это не троллинг, я действительно не знаю специфику этой области, оттого и удивляюсь.
Хотя, могу представить — если у вас таких историй 2 или 3 за пять лет, разумеется, никто не будет тратить деньги/ресурсы на организацию полноценных дежурств.
Считаю, тему лучше закрыть.
Отнюдь, самое интересное только начинается.
Задействуем готовый фреймворк или графовую базу?
А этим надо гордиться? Я всегда это видел как обычную рутинную часть работы.
Несомненно это намного интереснее чем фиксить очередной баг или добавлять еще один вызов к API/впиливать кнопочку в приложение, но чем тут гордиться я не особо понимаю.
По сути вашего вопроса:
Использование графовой базы позволит избавиться от реляционной EAV-базы, которая выполянет несвойственные ей функции и приводит к резкому снижению производительности.
Таким образом, использование графовой базы позволит решить и предметную задачу — «возможность связывания с записью в базе разнородной, заранее не детерминированной информации», и избавиться от недостатков реляционных баз.
Вполне себе интересная задача, которой, да, можно гордиться — это интересная и важная задача и для бизнеса, и для архитектора, и для аналитика, и для программиста.
Но да, рассказ об этом будет выглядеть иначе, чем stories, как эта.
вам просто не дадут сделать что-то, чтобы на этот вопрос «что сделано, чем можно гордиться» ответить положительно.
воспринял ваши примеры как то, чем можно было бы гордиться, но реалии энтерпрайза не дают этим заниматься.
Я нисколько не пытался сказать что прикрутить графовую базу — это мелочь и гордиться тут нечем. Я пытался показать почему некоторые разработчики могут просто не воспринимать такие вещи как что-то чем нужно гордиться просто потому что им кажется, что это такая же рутинная часть их работы как и «написание формочек».
Мне бы, например, не пришло в голову рассказать про прикручивание графовой базы в качестве ответа на такой вопрос HR.
Ну и конкретно эту фразу вы вырвали из контекста, обратите внимание (это было как продолжение диалога к первой фразе).
Но это делали. Проблема тут шире, включая порочность вопроса:
Чем гордиться? — Рассказать story, как ты за 5 минут до дедлайна решил проблемы, являющимися следствием чужих (или, еще хуже, ваших) залетов? — Сомнительное геройство.
Рассказать о том, как ты выбрал и задействовал нужные фреймворки, при необходимости дописав свои механизмы (с минимизацией ведосипедостроения), разработал архитектуру и внедрил процессы, дающие эффект в том числе и в ваше отсутствие, и в средне- и долгорочной перспективе?
Тоже где тут предмет гордости — обычная квалификация, в связи с которой и ведутся переговоры и месте приложении своих сил в проекте/компании и компенсации за это.
Или предмет гордости — способность генерировать плохо пахнущий код «здесь и сейчас» (а дальше хоть трава не расти)? Тоже что-то сомнительное, на что поведется не самый лучший менеджер.
Довольно трудно чем-то гордиться, так как постоянно всё меняется, особенно в IT. И то, что раньше котировалось, через некоторое время забывается и никому не нужно. Я например когда жутко гордился, что работал на БЭСМ-6 в системе «краб» в институте гидродинамики. И что? Когда-то гордился, что запустил первый браузер Мозаик и увидел одну из первых веб страниц. Если я это на интервью скажу, никто не поймет о чем речь.
сплошные костыли и хаки, порожденные ограничениями технологий
А я бы про это почитал )
Особенно если это истории из геймдева.
Могу, впрочем, ошибаться, но не приснилось же мне это.
p.s. с моим любимым ФП, кстати, та же история.
Мое возмущение заключалось в этом, никого не хотел обидеть!
Лично мое мнение, дотнет и в целом все что связано с windows, такое себе, но это лишь мое мнение
Рекомендую пересмотреть это мнение. Каждой задаче — свой инструмент, возможно вам придется по вкусу. Хотя, если есть подобное отношение в майкрософту, то стоит взять какой-нибудь котлин который не сильно хуже.
Но почему человек который имеет основной профиль в ООП под одну платформу, судит о новом языке, в котором вообще не разбирается и даже толком не изучал его?
Ну, я например тоже на го не писал, но читал очень много статей, и для себя сделал вывод, что на нем писать адекватному разработчику невозможно. Почему? Потому что он слишком простой, и это становится ограничивающим фактором. Окончательно для себя я на нем поставил крест после статьи who needs generics, в котором гуру Go на полном серьезе советует:
But what if a project just seems to cry for generics?
- Step back and revisit the requirements. Review the technical or functional specification (you should have one). Do the specs really demand the use of generics? Consider that while other languages may support a design that is based on type systems, Go’s philosophy is different
- Consider copy & paste
Человек на полном серьезе дает совет «ну если нужны генерики, вы ими не пользуйтесь, ну или накопипастите что хотите». Подобные извраты тоже на пользу не идут.
Ну и окончательную точку в вопросе поставила статья о причинах, побудивших проектировать язык именно так.
Поэтому да, я признаю, если бы я пописал на этом языке, возможно я проникся бы философией и всем таким. Но пока по сторонним признакам похоже на то, что это будет неприятный опыт. Примерно как сделать язык из одного только молотка (чтобы не учить людей пользоваться отверткой и шпателем), а потом радоваться, как все вокруг похоже на гвозди. ИМХО.
P.S. Я признаю, что могу быть неправым. Если вы несогласны, опишите в комментариях, какой момент я упускаю. Потому что я уже почти год пытаюсь понять, что же такого хорошего в го, и все, что я нашел — что гугл экономит на обучении студентов (что хорошо для гугла, но плохо для них), и как следствие зарабатывает много денег.
P.P.S. На вопрос в го чате в телеге «почему го так жрёт cpu на этом коде» ответ был «покажите какой у вас бюджет проекта что вас так cpu волнует».
Во первых, дотнет это уже давно не только про винду.
Во вторых, это не обазательно ООП, т.к. для дотнета есть, например, F#.
Любимый текстовый редактор — Visual Studio Code
Текстовый редактор? лолшто?
Пришёл к директору, сказал: «я — бесполезный дурак, и хочу уволиться, чтобы не мучить вас». Но в ответ мне сильно подняли з/п.Прикольно, у нас з/п поднимают, когда ты хорошо работаешь, а не когда плачешься в жилетку начальства.
Разрядка иногда нужна, как ни крути.Мне тоже, но я в это никого не вовлекаю.
А в том, чтобы признать собственные ошибки — нет ничего постыдного.Конечно нет, просто не надо спектакль разыгрывать.
Про «хочу работать на 30%» — нужно иметь стальные яйца для того, чтобы такое озвучить во всеуслышанье, достойно уважения.
а ннет, вот оно как ещё бывает.
Прочёл, и прямо настроение поднялось!
UNIX (Android, Linux, FreeBSD, QNX)
OpenGL, GLSL
Python, Lua.
Qt, PostreSQL.
В конце концов, если прям сильно нужны деньги, ну на худой конец Oracle SQL.
Для формочек есть Qt например. Для других задач — другие библиотеки, которые поддерживают тысячи талантливых программистов по всему миру.
.NET находиться в руках одной корпорации, которая использует труд рабов, а во главу угла ставяться деньги и пиар. Что хорошего может получиться из такой технологии?
В Unix-way на каждую задачу существует отдельный инструмент.
Для формочек есть Qt например.
Забавно. Qt противники как раз ругают за то, что *nix-way — это не про него (ведь действительно, GUI — это всего пару модулей из целой кучи), а заступники — сравнивают функциональности и универсальности с .NET
.NET находиться в руках одной корпорации
Тот же Qt контролирует не одна корпорация? Да и .NET уже вполне себе опенсорсный.
Конечно, всё имеет свою цену:
— Нативность даёт более высокий шанс словить платформозависимые ахтунги.
— C++. Есть конечно у Qt привязки к другим языкам, но в первую очередь он написан для плюсов. Если бы не моя любовь к нативности и отсутствию тормозов, я бы наверно для написания UI предпочёл бы что-нибудь по новее. C# или Java. Думаю они больше подходят для этого.
Кстати, в плане UI Unix-way варианты тоже есть. Переходя на линукс, сильно удивился обилию разнообразных UI библиотек и фреймворков. Но используются они видимо энтузиастами или когда уж очень сильно припрёт.
Удивительно, как в ветках не вспомнили Electron. Сейчас тоже хайповая штука. Учитывая скорость появления всякого софта на нём, наверное по удобству и скорости разработки потягаться может. Вот правда скорость и прожорливость оставляют желать лучшего.
Для формочек есть Qt например. Для других задач — другие библиотеки, которые поддерживают тысячи талантливых программистов по всему миру.
Надо полагать, .Net это такой монолит, в котором все есть. Но нет, даже стандартная библиотека распилена на ~1000 мелких пакетов, каждый их которых "решает одну задачу"™.
.NET находиться в руках одной корпорации, которая использует труд рабов, а во главу угла ставяться деньги и пиар.
- .Net не находится в руках одной корпорации, около 40% коммитов после открытия дотнета — от сообщества
- Деньги и пиар во главе угла — можно пруф? Я пока майкрософту ни копейки не заплатил, но он мне уже подарил бесплатно лицензию на VS pro и Win10, просто за участие в бета-тестировании. Не вижу каких-то денег во главе угла, зайдите на csharplang репозиторий, покажите, где там фичи принимают из разряда "за это будут платить бабки".
- Про рабство тоже очень интересно было бы почитать.
В итоге складывается впечатление, что вы из тех людей, которые не видят за деревьями леса, оперируете стереотипами (что странно сочетается с человеком, профессия которого по сути интеллектуальная элита 21 века, кто бы что там про сантехников не говорил), который выбирает технологии не из практических соображений, а по религиозным.
P.S. не сочтите за переход на личности, но вы перенесли свои проекты с опенсорсного гитхатаба на проприетарный гитлаб после его покупки злым Майкрософтом? Просто любопытствую.
P.S.S.
.NET находиться в руках одной корпорации, которая использует труд рабов, а во главу угла ставяться деньги и пиар. Что хорошего может получиться из такой технологии?
Но все же смысла в паническом бегстве с гитхаба я в итоге так и не понял. Люди разломали себе CI и все процессы, и больше месяца их восстанавливали, просто чтобы перелезть на такую же платформу (GitLab EE), но не связанную с MS.
Прочитайте еще раз статью автора) Вам светит то же самое. Это если мозги есть. Если мозгов нет — значит вам вообще ничего не светит.
Исключительно и только кнопачки на формачках гонять. Не более.
И да, открою вам наистрашнейший секрет) Фреймворк из дот.нета писан для студентов, в целях ознакомления. И он никак не является тем, на чем можно и нужно писать.
button1_ClickЭто особенно из ядерных кошмаров.
Кто вам запрещает наследоваться от кнопки, замутить свой объект Button1 и без проблем в нем переопределить метод OnClick()?
Даже этим дот.нет ужасен. До блевоты.
И НЕ ПИШИТЕ НИКОГДА Button1, У ВАС ЧТО ВООБЩЕ МОЗГА НЕТ??
Вы это к чему вообще? И причем тут дельфи?
Вы когда стравниваетесь, то сравнивайтесь с хорошим, а не с плохим. И уже прывыкните к этому, что сравниваться с плохим — это по-определению удел дегенератов. Потому что сравниваясь с плохим вы заведомо ставите себя в якобы выгодное положение. Но это не так. Подумайте.
Сильно похоже на ватное «ну вы поглядите как у пиндосов, у них еще хуже».
Логика у вас тут сильно хромает, сравнение не корректное никак.
«При этом меня смущает, насколько огромные для своего города деньги я получаю за один пулл реквест. Как будто высокий скилл разработчика даёт мне право жить в десять раз лучше чем куча людей, которые в поте лица делают полезное дело по восемь часов в день.»
Уперся в потолок в своём городе. 24 года — вся жизнь впереди! Нужно развиваться, почему бы не переехать в другое место, где будут адекватно платить за каждый пул реквест (относительно других рабочих в городе)? Смена обстановки нехило так освежает :)
Нужно выправлять work-life balance: коллега одно время работал 4 дня в неделю, а 3 отдыхал. Ещё можно попробовать дауншифтинг (появление 2-го ребенка не за горами) или, наоборот, пойти выше — в архитекторы. Новый вызов нужен, и срочно.
Новый вызов нужен, и срочно.
Если что-то и нужно, то только то, чтобы человека все устраивало. Если его устраивает жизнь без «срочных вызовов» — это его жизнь, и пусть он так и живет. Ну не хочет он превозмогать, так это его право.
"Мне кажется, я выгорел и больше не готов работать на бизнес идейно. Даже страх быть уволенным и лишиться привычного образа жизни не может заставить меня глубоко погружаться в проект. А я отец полутора детей — страх очень серьезный. Но однотипность и бессмысленность всего, что я делал, сейчас причиняет мне почти физическую боль.
Мне иногда кажется, что с таким подходом у меня нет морального права искать себе работу."
Что-то не чувствуется, что всё устраивает.
С другой стороны, тут говорится о разработке .NET, а это вполне могут быть реально жернова «разработка-подакшен» из которого не видно выхода, хотя если герой Senior software development engineer, то как бы должен быть некий иммунитет уже выработан, рабочий опыт должен быть уже и из статьи видно что есть.
Я пишу на C#, и у меня отличный интересный стек, тут и ELK, и блокчейн (хотя его назвать интересным тяжело, но все же bleeding edge имеет некоторые плюсы), и кроссплатформенная разработка, и даже поконтрибьютить в Parity (ethereum-client) получилось. Мне 25, выгорания не видно, с удовольствием занимаюсь пет-проектами (в том числе такими, чтобы помогали работе). В свободное время увлекаюсь в основном компьютерными стратегиями, полгода назад открыл для себя europa universalis, с тех пор ненарадуюсь на неё.
C# прекрасный язык, на нем можно реально писать и отдыхать. Нужно только найти подходящих коллег (или быть в компании единственным бек-разработчиком шарпистом на 20 котлинистов, как на моём текущем месте :) )
Серьёзно, в языке, для которого весьма нередок код в стиле IDictionnary<IMyStupidType, IMyStupidType2> Foo(Func<IMySupidType, int, bool, string> reallyStrangeCallback не сделать норм алиасы типов — это оооочень странное решение.
- class DictAlias: IDictionnary<IMyStupidType, IMyStupidType2> {}
- delegate IMySupidType FuncAlias(int, bool, string);
- Совмещаем 1 и 2: DictAlias Foo(FuncAlias reallyStrangeCallback)
Чем ему это не угодило то?
2. два делегата с одинаковой сигнатурой считаются разными типами. На мой взгляд очень глупо, но как есть. Соответственно сценарии использования сильно ограничены, если не держать где-то сборку всех используемых делегатов во всех смежных проектах.
Это все костыли, причем не очень удобные.
— Погодите, я немного не понял, как это работает:
class DictAlias: IDictionnary<IMyStupidType, IMyStupidType2> {}
Вы предлагаете реализовывать весь IDictionary? Ведь вы увидели, что наследуетесь от интерфейса, а не от Dictionary? Потому что если в случае Dictionary этот костыль может еще работать, то с интерфейсами — нет.
P.S. алиасить sealed-типы как предлагаете?
using MyDictAlias = IDictionary<string, string>;
public void Method(MyDictAlias dict)
{
dict.Add("","");
}
но в скоупе проекта\солюшена, а не только класса.
Вы предлагаете реализовывать весь IDictionary?
Пардон, я имел ввиду это
interface DictAlias : IDictionary<IMyStupidType, IMyStupidType2> { }
Конечно ограничения есть, но
В общем всё, что связано с рефлекшном работать не будет
это сильное заявление. Вместо
if(typeof(obj).GetGenericDefinition() == typeof(Dictionary<>))
можно
if(obj is IDictionary<int, int>)
Можно юзать Type.IsAssignableFrom и т.д. ну вы поняли.
Если вы делаете "жесткую" проверку типа, на то должны быть причины.
алиасить sealed-типы как предлагаете?
в стандартной библиотеке нет sealed типов с длинным названием, в вашем коде sealed можно убрать, навесив на алиас. В целом такие типы редки и большой проблемы не представляют.
два делегата с одинаковой сигнатурой считаются разными типами. На мой взгляд очень глупо, но как есть. Соответственно сценарии использования сильно ограничены, если не держать где-то сборку всех используемых делегатов во всех смежных проектах.
Да уж, не удобно, но можно и не делать:
delegate void A();
delegate void B();
class Test
{
public void Run(A a) => a();
}
B b = () => Console.WriteLine("qqq");
Test t = new Test();
t.Run(b); // Error: Cannot convert from B to A
t.Run(b.Invoke); // Works :)
Пардон, я имел ввиду это
interface DictAlias : IDictionary<IMyStupidType, IMyStupidType2> { }
Конечно ограничения есть, но
А дальше как? Где имплементацию DictAlias взять? Каст словаря к DictAlias то не сработает.
Пардон, я имел ввиду это
И что дальше? Нет ни одного калсса (в стандартной библиотеке) который бы реализовывал этот интерфейс. В каком-нибудь расте можно было бы написать
trait MyDict : IDictionnary<IMyStupidType, IMyStupidType2> {}
impl<T> MyDict for T where T : IDictionnary<IMyStupidType, IMyStupidType2>
и получить автоматическую реализацию для всех классов, но увы. Хотя раст нормальные алиасы поддерживает...
Когда-нибудь эту проблему решат концептами, но сильно лучше решение от этого не станет.
Можно юзать Type.IsAssignableFrom и т.д. ну вы поняли.
Если вы делаете "жесткую" проверку типа, на то должны быть причины.
Конечно, они есть. Например, когда я пишу (де)сериализатор.
Планирую запилить робота-программиста. Могу рассказать.
«Я бесполезный дурак и хочу уволиться» — 10 вопросов программисту, пилотный выпуск