Их работа не важнее (и что самое главное не сложнее) работы инженеров, которые делают, предположим автомобили.
За эти чужие слова стыдно почему-то мне:
это мы программисты отправили его туда
они бы не добились этого без нас.
мы программисты вложили в отправку этого сообщения больше, чем кто-либо другой.
У меня в прошлом работа конструктором, технологом как на Российских оборонных предприятиях, так и на зарубежных (Boeing). Я могу скзазать точно, что все ведущие инженеры владели формальной логикой, матаном и способностью разбираться в чем-то новом в достаточной мере чтобы сесть и написать рабочую программу на каком-нибудь C/Asm/C++. Да, без хипстерских выкрутасов, но это будет абсолютно рабочий и надёжный код. Это не считалось чем-то сверхъестественным, если ты умеешь составлять алгоритмы будучи инженером.
Ты их постоянно составляешь — как правильно изготовить деталь? Как собрать узел? Как установить её в сборку? Как в итоге создать самолёт? Эти вопросы решает технолог на основе готовой конструкции.
А создать конструкцию… Ну я вам скажу, программистам до этого уровня организации рабочего процесса идти ещё десятилетия. И требования к тем же самолётам, автомобилям, лифтам, да хотя бы к зданиям в которых мы живём гораздо суровее чем к вебсервисам или сайтам.
Если автор вещает за всех программистов, то я пожалуй останусь инженером.
Оно ж с MVC слилось в экстазе когда ms осознал что две параллельные реализации контроллеров и инфраструктуры вокруг них не есть хорошо. М?
ну да слилось, это плохо? Старые MVC неймспейсы убрали (System.Web.Mvc стал Microsoft.AspNetCore.Mvc), унифицировали работу с контроллерами, но в целом это тот же самый старый добрый WebApi.
Я сам из тех, которые на F# лепят.
Он очень даже при том.
Получаете кучу бонусов в языке, синтаксисе, системе типов, но теряете немного в IDE (Visual Studio днищенски поддерживает F#, VS Code — норм, Rider EAP 2018.1 уже тоже норм), в тулах (нет ничего подобного R#, но учитывая что язык гораздо менее бойлерплейтный и защищает от ошибок намного сильнее, надобность уже не та. Так же нет нормальных декомпиляторов, если dotPeek'ом тыкаться, получаем бесплатную обфускацию)
А главное dll те же, dotnet xxx.dll всё так же работает, поэтому хоть в Azure, хоть в AWS Lambda заливается абсолютно одинаково.
Ну и если чо, компилятор и темплейты проектов F# в .NetCore SDK уже встроены.
И не потому, что я люблю системное программирование или производительность, а потому что я на него смотрю высокоуровнево, и для меня отсутствие null в языке это одна-единственная возможность, ради которой можно многое простить.
В том же ASP.NET MVC адаптируются в IDependencyResolver.
Опускаясь на уровень этого интерфейса все эти контейнеры полностью теряют уникальные фичи (Ninject — auto discovery, SimpleNinject — проверку на собираемость и т.д.) что делает наличие такого большого кол-ва реализации контейнеров бессмысленным.
Кстати, в Visual Studio файлы проектов уже можно писать с нуля руками
Уж пару лет как. Не уверен за самую раннюю версию msbuild, которая может понимать сокращённый *.csproj, но чтобы написать webapp какой-нибудь достаточно пару строчек.
и не могу это сделать на .Net (привет web.config, который “по сути” тот же web.xml, только еще и перемешанный с конфигом).
Я вот пишу облачные микросервисы в Azure (serverless и webapp) и чот мне ни разу не потребовалось включать web.config в проект. Всё можно из кода настроить. Пишу под netcoreapp2.0
Максимум для удобства быстрой настройки логирования или параметров приложения вообще (connection strings) подключается app.config (который JSON)
Генератор в данной реализаций так и реализован, он не генерирует новые кораблики пока место в «туннели» не освободиться. Он засыпает.
Тогда ваше требование о независимости генератора от туннеля не выполняется.
И вместо поллинга со стороны генератора лучше сделать pull данных со стороны туннеля.
Я вообще сам дотнетчик, но знаю что в Scala есть Akka Streams, хз юзабельно оно или нет из Java
A typical problem applications (not using Akka Streams) like this often face is that they are unable to process the incoming data fast enough, either temporarily or by design, and will start buffering incoming data until there’s no more space to buffer, resulting in either OutOfMemoryError s or other severe degradations of service responsiveness.
Работа генератора кораблей не должна зависеть от работы причалов и наоборот
Оно таки может привести к проблеме fast producer — slow consumer.
Генератор не должен генерить новые корабли если причалы ещё загружают, а "тунель" полон.
Есть разные стратегии обработки таких сценариев:
1) Pull. Туннель будет буфером на 5 кораблей, когда буфер неполон, он сам просит нагенерить ему ещё кораблей, а в это время причалы грузят нонстоп, все довольны.
Т.е. генератор выступает тут итератором, у которого есть метод — CreateNext()
2) Drop. Если генератор ну очень хочет генерить корабли постоянно, а тунель не справляется, то можно дропать все корабли сверх лимита. Под словом дропать можно понимать разное: именно что дропать и забывать навсегда, или же поднимать новый "тунель" и засылать в него.
Ну это если также расслаблено работать как в среднем офисе. То да, придётся тратить 60-80 часов в неделю.
Это работа на износ.
Я вот как-то хотел отпуск долгий взять и договорился с начальством поработать 2 недели по 12ч/день. С учётом транспорта, в нерабочее время я успевал только поспать.
В конце первой недели я пожалел что согласился, хотя самочувствие было нормальным.
На второй неделе я уже просто "отсиживал" вторую половину рабочего времени, т.к. голова думать отказывалась.
По результату я понял что 8ч в день С УЧЁТОМ перерывов (чаёк, поболтать, митинги всякие, обед и пр) — это ВЕРХНИЙ предел рабочего времени в день, приносящего пользу. Можно даже меньше. Ну и пожить банально не получается. Дети там, семья, друзья, в игрушки погонять банально.
Зачем такая работа, которая не даёт наслаждаться жизнью?
Бизнес должен зарабатывать денег. Точка. И в конкурентной борьбе платить нормальные деньги.
Тогда можно забыть о:
1) Найме молодых женщин (невыгодно, уходят рожать постоянно)
2) Найме инвалидов (невыгодно, надо делать безбарьерную среду, проще не нанимать)
3) Вообще о белой з/п, т.к. гораздо выгоднее платить чёрную. Даже при той же сумме, любое возмущение со стороны работника можно погасить невыплатой/удержанием. Она ж чёрная.
4) Постоянным стремлением к наебалову — нечестное поведение приносит денег больше честного. Ну и монополии стараться создавать, душа конкурентов, картельные сговоры конечно тоже помогут в зарабатывании денег. Это же самая главная цель, зачем ограничиваться в средствах?
Бизнес ДОЛЖЕН быть социально ответственным. А тех кто не хочет — надо заставлять. Для этого придумали ТК. За это люди боролись столетиями.
То есть закрытый дескриптор под вашу формулу пересчёта кода в баги не подходит?
Передёргивание. Я такую "формулу" не приводил. Но приводил ту, которая может посчитать надёжность системы из надёжностей её элементов.
И она не моя, вы мне льстите.
Всё хорошо, кроме того, что вы приравняли «код» и «систему».
Ну пожалуйста, объясните чего ж такого магического в коде, что его нельзя рассматривать как систему объектов, друг с другом взаимодействующих.
Ну вообще есть, но ей никто не пользуется
По умолчанию таски в TPL горячие.
фиксанул ссылку
Программисты зазнались.
Их работа не важнее (и что самое главное не сложнее) работы инженеров, которые делают, предположим автомобили.
За эти чужие слова стыдно почему-то мне:
У меня в прошлом работа конструктором, технологом как на Российских оборонных предприятиях, так и на зарубежных (Boeing). Я могу скзазать точно, что все ведущие инженеры владели формальной логикой, матаном и способностью разбираться в чем-то новом в достаточной мере чтобы сесть и написать рабочую программу на каком-нибудь C/Asm/C++. Да, без хипстерских выкрутасов, но это будет абсолютно рабочий и надёжный код. Это не считалось чем-то сверхъестественным, если ты умеешь составлять алгоритмы будучи инженером.
Ты их постоянно составляешь — как правильно изготовить деталь? Как собрать узел? Как установить её в сборку? Как в итоге создать самолёт? Эти вопросы решает технолог на основе готовой конструкции.
А создать конструкцию… Ну я вам скажу, программистам до этого уровня организации рабочего процесса идти ещё десятилетия. И требования к тем же самолётам, автомобилям, лифтам, да хотя бы к зданиям в которых мы живём гораздо суровее чем к вебсервисам или сайтам.
Если автор вещает за всех программистов, то я пожалуй останусь инженером.
А потом изобретут настоящий ИИ, который заменит всех программистов.
И вот тут-то художники и артисты всех мастей оторвутся!
3.000% и 3.456% равновероятны.
Выпадение КОНКРЕТНОГО числа маловероятно, но они все одинаково вероятны.
ну да слилось, это плохо? Старые MVC неймспейсы убрали (
System.Web.MvcсталMicrosoft.AspNetCore.Mvc), унифицировали работу с контроллерами, но в целом это тот же самый старый добрый WebApi.Живее всех живых короче.
Так это оно и есть.
Я сам из тех, которые на F# лепят.
Он очень даже при том.
Получаете кучу бонусов в языке, синтаксисе, системе типов, но теряете немного в IDE (Visual Studio днищенски поддерживает F#, VS Code — норм, Rider EAP 2018.1 уже тоже норм), в тулах (нет ничего подобного R#, но учитывая что язык гораздо менее бойлерплейтный и защищает от ошибок намного сильнее, надобность уже не та. Так же нет нормальных декомпиляторов, если dotPeek'ом тыкаться, получаем бесплатную обфускацию)
А главное dll те же,
dotnet xxx.dllвсё так же работает, поэтому хоть в Azure, хоть в AWS Lambda заливается абсолютно одинаково.Ну и если чо, компилятор и темплейты проектов F# в .NetCore SDK уже встроены.
Поэтому встречный вопрос:
А почему не F#?
Тут мне кое-кто шепнул, что на дотнете есть F#.
В .Net есть варианты (перечислю самые, на мой взгляд, популярные):
dotnet add package Newtonsoft.Json)Опускаясь на уровень этого интерфейса все эти контейнеры полностью теряют уникальные фичи (Ninject — auto discovery, SimpleNinject — проверку на собираемость и т.д.) что делает наличие такого большого кол-ва реализации контейнеров бессмысленным.
Ну я вас умоляю, мы ж не в каменном веке. Package Manager'ы же есть.
Уж пару лет как. Не уверен за самую раннюю версию msbuild, которая может понимать сокращённый *.csproj, но чтобы написать webapp какой-нибудь достаточно пару строчек.
Я вот пишу облачные микросервисы в Azure (serverless и webapp) и чот мне ни разу не потребовалось включать web.config в проект. Всё можно из кода настроить. Пишу под netcoreapp2.0
Максимум для удобства быстрой настройки логирования или параметров приложения вообще (connection strings) подключается app.config (который JSON)
Тогда ваше требование о независимости генератора от туннеля не выполняется.
И вместо поллинга со стороны генератора лучше сделать pull данных со стороны туннеля.
Я вообще сам дотнетчик, но знаю что в Scala есть Akka Streams, хз юзабельно оно или нет из Java
Полезное чтиво:
https://doc.akka.io/docs/akka/2.5/stream/stream-quickstart.html#back-pressure-in-action
Оно таки может привести к проблеме fast producer — slow consumer.
Генератор не должен генерить новые корабли если причалы ещё загружают, а "тунель" полон.
Есть разные стратегии обработки таких сценариев:
1) Pull. Туннель будет буфером на 5 кораблей, когда буфер неполон, он сам просит нагенерить ему ещё кораблей, а в это время причалы грузят нонстоп, все довольны.
Т.е. генератор выступает тут итератором, у которого есть метод — CreateNext()
2) Drop. Если генератор ну очень хочет генерить корабли постоянно, а тунель не справляется, то можно дропать все корабли сверх лимита. Под словом дропать можно понимать разное: именно что дропать и забывать навсегда, или же поднимать новый "тунель" и засылать в него.
Это работа на износ.
Я вот как-то хотел отпуск долгий взять и договорился с начальством поработать 2 недели по 12ч/день. С учётом транспорта, в нерабочее время я успевал только поспать.
В конце первой недели я пожалел что согласился, хотя самочувствие было нормальным.
На второй неделе я уже просто "отсиживал" вторую половину рабочего времени, т.к. голова думать отказывалась.
По результату я понял что 8ч в день С УЧЁТОМ перерывов (чаёк, поболтать, митинги всякие, обед и пр) — это ВЕРХНИЙ предел рабочего времени в день, приносящего пользу. Можно даже меньше. Ну и пожить банально не получается. Дети там, семья, друзья, в игрушки погонять банально.
Зачем такая работа, которая не даёт наслаждаться жизнью?
Т.е. чтобы отработать 40ч в неделю в Crossover, надо работать как 60-80ч в офисе? Это если что, 7-10 восьмичасовых рабочих дня. В неделю!
И на это люди добровольно соглашаются? Может сразу ярмо на шею и на плантации?
Тогда можно забыть о:
1) Найме молодых женщин (невыгодно, уходят рожать постоянно)
2) Найме инвалидов (невыгодно, надо делать безбарьерную среду, проще не нанимать)
3) Вообще о белой з/п, т.к. гораздо выгоднее платить чёрную. Даже при той же сумме, любое возмущение со стороны работника можно погасить невыплатой/удержанием. Она ж чёрная.
4) Постоянным стремлением к наебалову — нечестное поведение приносит денег больше честного. Ну и монополии стараться создавать, душа конкурентов, картельные сговоры конечно тоже помогут в зарабатывании денег. Это же самая главная цель, зачем ограничиваться в средствах?
Бизнес ДОЛЖЕН быть социально ответственным. А тех кто не хочет — надо заставлять. Для этого придумали ТК. За это люди боролись столетиями.
Я вообще не хочу считать.
Передёргивание. Я такую "формулу" не приводил. Но приводил ту, которая может посчитать надёжность системы из надёжностей её элементов.
И она не моя, вы мне льстите.
Ну пожалуйста, объясните чего ж такого магического в коде, что его нельзя рассматривать как систему объектов, друг с другом взаимодействующих.
Конечно можно, кто ж мешает. Если заняться нечем в ближайшие пару лет.
Если вы не знаете зачем применяют ретраи в IO, ничем не могу помочь. Не от закрытого дескриптора строкой выше, нет.
Почему же? Дополнительные фейловер инстансты моей системы — это как раз оно самое, что не так? Одна упадёт, другая подхватит.